IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 27 March 2011   (all times are UTC)

02:26bencer_ (~bencer@heal.cauterized.net) left irc: Read error: Connection reset by peer
02:26bencer (~bencer@heal.cauterized.net) joined #ltsp.
02:38roasted (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp.
02:38roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp.
02:38roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Client Quit
02:39roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp.
03:15Trixboxer (~Trixboxer@office.supportdepartment.net) joined #ltsp.
03:48komunista (~slavko@adsl-195-098-015-248.dynamic.nextra.sk) joined #ltsp.
06:01dgroos (~dgroos@63.225.132.145) joined #ltsp.
06:27Nubae (~Nubae@opensuse/member/nubae) joined #ltsp.
06:27
<Nubae>
man... there seem to be so few books on linux automation
06:47cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Remote host closed the connection
06:49
<alkisg>
Nubae: maybe because you can automate soooo much stuff with linux, you could fill a whole encyclopedia with it :D
06:50
<Nubae>
not a bad idea :-)
06:51
the linux automation encyclopedia
06:52
could be the the be all and end all of linux based management... sort of like a principia discordia
06:52
;-)
06:52
wanna help write it?
06:52cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp.
06:53
<alkisg>
Sure, if we find a way to push a pause button while we devote 10 years in it :P
06:53
<Nubae>
I mean... focusing on LTSP, LDAP, Puppet, CFengine, and shell scripts to be reused would be a great start
06:54
well, even if it took 20 years... its the kind of info that wouldn't really get outdated I'd imagine
06:54
well... it could be written that way I mean
06:55
I dont mean to presume linux et al. aren't going to change for the next 20 years
06:56
LTSP is sort of the closest all round tool we have for linux automation
06:56
but it has many limitations...
06:56
<alkisg>
I don't know if ltsp, ldap, puppet, cfengine etc are going to be around in 20 years :) I think there's a good possibility that linux will be around, though :)
06:56
<Nubae>
hehe, yeah
06:57
cfengine has been around for 15 years u know... good chance it could be around in 29
06:57
20--- not 29
06:57
ldap too for that matter
06:58
<alkisg>
20 years is a very long time in the computer industry to make forecasts
06:58
<Nubae>
but perhaps the best approach would be to make it as generic as possible, so it really would be relevant even in 20 years
06:58
I mean automation is something that is so essential to any sysadmin
06:58
<alkisg>
E.g. you might not even have local installations at that time
06:58
So why would you need automation then? :)
06:59
<Nubae>
u will always need automation
06:59
I cannot imagine that will change, can u?
06:59
<alkisg>
Sure, for sysadmins, I can imagine it
07:00
<Nubae>
the way it happens... that will surely change... even the name might change
07:00
<alkisg>
If we have hardware thin clients + a big server, we don't need much automation, we just administrer 1 installation
07:00
<Nubae>
but the concept of replicating a system and maintaining its stability
07:00
thats pretty important stuff
07:00
yup... but wireless is still a ways off before that can work effectively
07:01
I keep thinking xmpp / telepathy / dbus could be the answer for these things
07:01
<alkisg>
In 20 years I'm sure screens will have enough CPU to function as something like thin clients. Like pcoip or old hardware X terminals
07:02
And the server will have enough cpu to even run 3d apps for all its clients
07:02
<Nubae>
yeah but if we are writing something for now and 20 years, we cannot assume what tech will be available then :p
07:02
<alkisg>
But that's a naive forecast, probably better methods will emerge
07:03
<Nubae>
hopefully it will all be brain jacking and stuff
07:03
but who knows
07:03
<alkisg>
What are you trying to automate currently?
07:03
<Nubae>
right now though... I've found 1 book on automation.... 1.... incredible
07:04
well, still working on dextrose server
07:04
The idea currently goes something like this:
07:05
master server sends out a pxe based iso + packages that make up the school server
07:05
that master server also starts up puppet or cfengine, including client on school server
07:05
for later maintenance
07:05
nagios too
07:05
ejabberd for xmpp comms
07:05
and moodle
07:06
so... the point is, be it gpxe or pxe, the installation (automation) happens over the network
07:06
its teh
07:06
fastest most efficient method I could think of
07:07
of course... the master server must be able to create a full iso if the sysadmin wants that
07:07
say cause he needs to go to some extreme remote location
07:08
but anyway, the problems are: power, network connectivity, sysadmin inexperience, XO wireless multicasting saturation
07:09
but... so far, I have done both a deb6 and a redhat el6 iso of the master server
07:09
deb I did wit FAI
07:09
and redhat with kickstart
07:09
basically I got all the info from the one book I found
07:09
and I can tell you... I really really looked for other books... there was nothing...
07:10
just seems that writing something that combines what I've written above together with LTSP would be a pretty cool book on Automating linux in general
07:10
u know for rpm and deb based systems
07:11
http://wiki.sugarlabs.org/go/Dextrose/Server/Building
07:11
thats the redhat instructions
07:11
<alkisg>
Yup I've read those before, I remember the mouse cursor in that page:D
07:11
<Nubae>
stilll needs a lot of refining... but its there
07:12
hehe thats right I'm noticing now
07:12
well I'm going to upload the deb one soon, which might be interesting to u, since it should work for ubuntu too
07:13
<alkisg>
Here each IT teacher is responsible for his own computer lab in his school
07:13
So we don't need to automate mass installations
07:13
Just the LTSP server installation
07:13
Completely different set of problems
07:14
<Nubae>
:-) well thats a nice perfect situation... I wish it could be the same for all of South America
07:14
but I fear, I need this automation due to lack of skilled technicians
07:15
<alkisg>
Indeed. If it was up to me, I'd use mass automation here too, and administer all the school labs centrally.
07:15
<Nubae>
it would certainly force users to work according to a set policy
07:16
Policy is something very few companies take notice of, but its sooooooo important
07:26artista_frustrad (~artista_f@187.54.58.224) joined #ltsp.
07:30artista_frustrad (~artista_f@187.54.58.224) left irc: Excess Flood
07:31artista_frustrad (~artista_f@187.54.58.224) joined #ltsp.
07:34
<Nubae>
alkisg don't u think it would be a worthwhile thing to think about? a book on automation? (LTSP and builder replication, server hardening within that replication)
07:34
I mean, all joking aside... a lot of the written material is already kinda out there
07:34
<alkisg>
Nubae: seriously? no, I wouldn't, it would take a lot of months to write it that wouldn't be paid back
07:35
<Nubae>
u dont think it could get published?
07:35
<alkisg>
I don't believe the audience is big enough to pay for those months
07:35
<Nubae>
yah maybe...
07:35
perhaps in 20 years ;-)
07:35
<alkisg>
And personally I don't have the interest in writing something like that
07:35
I'd prefer to develop better ways to automate than write a book about the current methods ;)
07:36
(which i don't even know :P)
07:37
<Nubae>
well that would be the point
07:37
the only difference would be its documented
07:37
instead of just in alkisg's head
07:54alkisg (~alkisg@ubuntu/member/alkisg) left irc: Ping timeout: 250 seconds
08:13vagrantc (~vagrant@c-24-21-191-93.hsd1.or.comcast.net) joined #ltsp.
08:21alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
08:33MorningSon (~MorningSo@cpe-70-114-21-95.satx.res.rr.com) joined #ltsp.
09:19
<roasted_>
Due to some recent discussion yesterday I was under the impression I have to join the fat client chroot to the domain in my environment. Not just the server itself, but the fat chroot as well. This calls for naming /etc/hostname and /etc/hosts. /etc/hostname is blank, which I found a little odd it's blank by default, and /etc/hosts says - This is a ltsp chroot and this file will be rewritten in boot process of terminal. That being said,
09:19
can I even *name* the fat chroot before joining it to the domain??
09:22
<alkisg>
Domain PCs need to have specific hostnames?
09:22
<roasted_>
yes
09:22
<alkisg>
If so, you would need to do that for all of your possible hostnames
09:22
ltsp123, ltsp124, ltsp125...
09:22
<roasted_>
I don't care what the clients are. I just want to join the thing to the server so it acts like a normal computer.
09:22
Because right now, it's not working for me.
09:23
like if I name the chroot will it retain that name?
09:23
because the comment in /etc/hosts has me a little curious
09:23
<alkisg>
Suppose you have 1 standalone ubuntu pc
09:23
You join it to the domain
09:23
The you clone it to 20 pcs
09:23
Then you change the hostnames
09:23
<roasted_>
yep
09:23
<alkisg>
Are you saying that you'd need to rejoin the domain for each one of them?
09:23
<roasted_>
yep
09:23
that's what I do with cloning Windows
09:24
they all come down as 1 name so I rename them, reboot, and join to domain
09:24
<alkisg>
Then you can't do that in the chroot
09:24
The chroot only has 1 name
09:24
<roasted_>
I don't care what the tclients do.
09:24
<alkisg>
The other hostnames are generated when you boot the clients
09:24
<roasted_>
look at it this way
09:24
<alkisg>
Aren't you looking to join the fat clients to the domain?
09:25
<roasted_>
my thin client server is on the domain, so when users log in under their domain account, they can go to windows file servers without it barking at them because it authenticates against their username.
09:25
That way the server allows them where they can/can't go based on windows permissions on the folders themselves.
09:25
In the fat client environment, it asks who they are, requiring them to log in a 2nd time even though they are logged in under their domain account.
09:25Trixboxer (~Trixboxer@office.supportdepartment.net) left irc: Quit: "Achievement is not the end, its the beginning of new journey !!!"
09:25
<roasted_>
So this made me think based on our conversation yesterday that the fat client chroot must be on the domain.
09:26
In the thin client environment, that box has 1 name. MSLibrary, because it belongs in the Middle School Library.
09:26
And that works, even though that's 1 box serving everybody. The important factor is that the users are auto-authenticated because of their domain logins. No 2nd login required to get on the Windows file server.
09:26
That's what I want with the fat clients.
09:26
<alkisg>
And based on our current conversation, it's worthless to have the chroot join the domain, because it depends on the hostname, which will change on boot
09:26
But
09:27
<roasted_>
I don't care if each box gets a different name. I just want the clients to auto authenticate like the thin clients do.
09:27
<alkisg>
If it works for you, you can tell all fat clients to use the same hostname
09:27
I haven't thought the implications of that, but you can set the same hostname for all fat clients in lts.conf
09:27
Or
09:27
<roasted_>
But what good does that do me, setting all fat client hsotnames.
09:28knipwim (~wim@ip4da83870.direct-adsl.nl) left irc: Read error: Operation timed out
09:28
<alkisg>
You go to the chroot. Set the hostname. Join the domain
09:28knipwim (~wim@ip4da83870.direct-adsl.nl) joined #ltsp.
09:28
<alkisg>
Then you boot the fat clients with the same hostname
09:29
Based on what you say, that might work. Unless windows checks that there aren't multiple pcs with the same hostname
09:29
Or
09:29
<Nubae>
just out of curiosity, whats the usage of fat vs thin clients?
09:29
<roasted_>
resource allocation
09:29
thin uses server
09:29
fat uses their own local resources
09:29
<alkisg>
You find some way to script the domain joining, and have it run as a startup script
09:29
<roasted_>
script the domain joining sounds like a nightmare
09:29
it's not something I want to rely on
09:30
I'd drop fat client usage before I went that route, to be blunt about i
09:30
it
09:30
<alkisg>
Sure
09:30
In any case it's not an LTSP problem
09:30
<roasted_>
I wouldn't want to rely on Windows successfully joining 30 clients each time they fire up.
09:30
<Nubae>
well both samba and ldap should be able to do domain joining
09:30
<alkisg>
It's a likewise/windows problem
09:30
<roasted_>
I'm not understanding how it's a LWOpen problem.
09:30
In a thin client environment, it works great.
09:30
In a fat client environment, it's the way the chroot is separated, it seems.
09:31
<Nubae>
I would go the ldap route
09:31
<roasted_>
What gets me is I don't understand how I can log in tot he domain now.
09:31
The fat client server is on the domain, not Windows. Yet I can log into my domain account. So it's authenticating somehow.
09:31
But when I try to get to our file server, we get that neat little message as if it has no idea who we are.
09:32
Because due to our current login session, it should see that I'm bob_jones and I have access to ABC/XYZ shares and let me in no problem.
09:32
<Nubae>
the file server is on a different machine?
09:32
<roasted_>
yes
09:32
<Nubae>
ah well, could be that then, machine authentication is another issue
09:32
not necessarily related to user logins
09:33
<roasted_>
but they are
09:33
they absolutely are
09:33
are you familiar with windows domain environments?
09:33
<Nubae>
alkisg I meant... how many people are using thin vs fat clients, in your opinion?
09:33
<alkisg>
Nubae: most people are using thin. But lots are starting to switch to fat, imho
09:34
I only have good stats for Greece, where fat client installations are automated
09:34
<Nubae>
roasted_ slightly... I'm much more linux than windows... but I do know that each machine handshakes with a different password
09:34
<alkisg>
More than 50% here use fat
09:34
<Nubae>
AD is pretty much LDAP
09:34
with kerberos
09:34
<roasted_>
Nubae, everything revolves around the domain. If I'm on a computer on the network not on the domain and I try to go to start - run - \\fileserver, it comes up with a login to authenticate.
09:35
Nubae, If I'm on a PC on the domain, it doesn't do that, because it takes my login info I'm already using AS that authentication to the file server.
09:35
<Nubae>
right, machine login or user login?
09:35
<roasted_>
Nubae, THAT'S my problem here. Thin clients do that. Fat clients do not. That's what I'm trying to figure out.
09:35
<Nubae>
ah
09:35
<roasted_>
Thin clients take the user login and no 2nd authentication is there. Fat clients are wondering who the heck I am.
09:35
So you would think, well just log in and be done with it. There's several hundred students in our environment who will be using this. It's a bridge I need to cross. :(
09:36
<Nubae>
strange, as far as I understood, authentication in fat and thin is now the same
09:36
<roasted_>
So that's why the discussion came up, maybe I need to have the fat client chroot on the domain.
09:36
Which.. makes sense to me.
09:36
Since the fat client chroot is supposedly a completely indepedent "instance" of an OS, as different as two computers sitting side by side.
09:36
<Nubae>
so u're using AD to authenticate?
09:36
<roasted_>
Yes.
09:36
Via Likewise-Open.
09:36
<Nubae>
ok
09:37
it is, but the authentication part.... just goes through ssh, fat or thin
09:37
alkisg? am I right about that?
09:38
<alkisg>
Nubae: sure, but now it's not about authentication against the ltsp server
09:38
It's about authentication to a windows share
09:38
<roasted_>
Which is done through Likewise-Open.
09:38
<alkisg>
So if windows needs to check if the client has joined a domain, then well, the fat client has not
09:38
<Nubae>
I have no idea what likewise-open is
09:39
<alkisg>
And if windows depends on a specific hostname to keep a client joined, then that won't work with live booted environments
09:39
<roasted_>
Likewise-Open is a utility to join mac/unix/linux systems to a Windows domain.
09:39
<Nubae>
but why not just create a samba server?
09:39
<roasted_>
Nubae, do you have ANY idea how massive of an undertakting (and simply impossible) that request is?
09:39
We're in a very large school district.
09:39
It's just not in the cards.
09:39
We have a Windows file server. It's here. It works. It's not moving.
09:40
<Nubae>
samba is essentialy the same as a windows file server
09:40
<roasted_>
Doesn't matter.
09:40
<Nubae>
y wouldnt notice the difference
09:40
<roasted_>
There's no way that's in the cards.
09:40
<Nubae>
ok
09:40
and.... using something other than likewise-open?
09:40
<roasted_>
Since likewise open has worked so well for us, it is also not in the cards to remove it.
09:41
The program just works flawlessly, from what I can see.
09:41
<Nubae>
till now :p
09:41
<roasted_>
How do you know it's a LW Open problem?
09:41
To me, it seems quite obvious it's not.
09:41
It works with thin clients. Why would it look at fat clients and be like ahh I don't like you.
09:41
<Nubae>
well if u cant login to it
09:41
<roasted_>
THAT makes no sense to me.
09:41
Because if the fat chroot is separated, it makes sense.
09:41
It may be I just have to join it to the domain.
09:42
<Nubae>
welll the only thing that comes to mind is the machine handshaking
09:42
right
09:42
<roasted_>
alkisg, but that concerns me. Does each client boot into a live session each time a fat client fires up?
09:42
<Nubae>
its the domain joining part
09:42
<alkisg>
roasted_: yes, ltsp clients can be thought of as live sessions
09:42
<Nubae>
well, not if u're not logged in
09:42
<roasted_>
alkisg, even the fat chroot? Would the fat chroot retain its domain join?
09:43
<alkisg>
roasted_: I don't know, that's a windows/likewise question
09:43
<roasted_>
Or would it be treated as a live session if I would reboot it?
09:43
haha
09:43
<alkisg>
That's why I keep saying that your question is not related to ltsp
09:43
<roasted_>
I fail to see how it is, but we'll agree to disagree.
09:43
<Nubae>
I agree with alkisg, this sounds like a handshaking thing/domain joining thing to me
09:43
<roasted_>
This could be a huge problem for us...
09:43
<alkisg>
If you tell me which specific actions are needed to join a live Ubuntu CD to the domain, I can tell you how to do it with ltsp
09:43
<roasted_>
one that forces us to get RAM and make the lab thin.
09:44
<Nubae>
thats not got anything to do with ltsp really.... but... u can at least take a look at the logs
09:44
<alkisg>
Which files are modified, on which params the joining depends etc
09:44
<roasted_>
Likewise Open comes down as a .bin.
09:44
<alkisg>
That's windows/likewise knowledge
09:44
<roasted_>
grant +x perms to it, install it, and during the installation process it asks what domain do you want to join.
09:44
<alkisg>
Not ltsp knowledge
09:44
<roasted_>
Put your domain in, put a user in that can authenticate (domain admins), bam you're done.
09:44
Reboot and you're on the domain now.
09:44
<alkisg>
roasted_: ok, now clone the process
09:44
What do you need to do next?
09:45
<roasted_>
In a regular environment, I wouldn't join all of them to the domain. I'd rename them. Then I'd join them.
09:45
Once it's on the domain, you're done.
09:45
<alkisg>
LTSP renames the client when booted
09:45
So you need to join each one of them when they boot
09:45
<roasted_>
Okay, so that at least tells me that each fat client would have a different hostname.
09:45
<alkisg>
(according to your description)
09:46
<roasted_>
Which is good. The same hostname on multiple hosts is not good.
09:46
The question is... would the user on the fat client be able to go to nautilus and hit smb://windows/fileserver and it not bark at him?
09:46
<alkisg>
Read what you said
09:46
<roasted_>
like I said, thin clients work flawlessly with this idea.
09:46
<alkisg>
"after cloning I need to join the domain"
09:46
So I'm saying
09:46
"ltsp is like cloning"
09:46
So that results in:
09:47
"after booting ltsp fat clients you need to join the domain"
09:47
<roasted_>
well
09:47
<alkisg>
On each and every boot
09:47
<Nubae>
for each machine
09:47
<roasted_>
looks like fat clients are a bust then
09:47
sorry
09:47
<alkisg>
Sure
09:47
But again, it's not an ltsp problem
09:47
It's a windows/likewise problem
09:47
LTSP is about "I take a new pc and plug it and it plays"
09:47
<Nubae>
nah sure there is a solution within AD
09:47
<alkisg>
Windows domain is "I don't know this pc I don't give access"
09:48
<roasted_>
I don't think it's really a "problem" with Windows or LWOpen.
09:48
I think it's just due to the fat client design.
09:48
And the way how it works with a live environment each time.
09:48
<alkisg>
So if windows doesn't like unknown PCs, you need to work around that
09:48
<roasted_>
That structure just doesn't mesh up with the way LWOpen works.
09:48
Not that I'm saying the design is off.
09:48
I'm just saying, THAT seems why.
09:48
Domains are meant to join and be done with it. Not joined over, and over, and over each time it reboots.
09:49
So you have two clashing structures, between domain setups and the way LTSP fat clients work.
09:49
<alkisg>
And LTSP is about booting unknown machines. So you have an incompatibility there
09:49
<roasted_>
Right.
09:49
<alkisg>
Thin clients are also unknown machines
09:49
<roasted_>
but thin clients *work*
09:49
<alkisg>
You just don't need to access the domain through them
09:49
No, they don't
09:49
<roasted_>
so there has to be a different
09:49
<alkisg>
The server works
09:49
<roasted_>
difference
09:49
right
09:49
the server works, and the server is the chroot
09:49
<alkisg>
If you try to access the domain from a localapp, it won't work
09:49
<roasted_>
yes
09:49
it does
09:50
<alkisg>
No
09:50
<roasted_>
if I'm on a thin client
09:50
<alkisg>
It won't. Localapp. Runs locally.
09:50
<roasted_>
and I go to smb://windows/file/server
09:50
it works
09:50
<alkisg>
Read what I said
09:50
<roasted_>
what are you referring to
09:50
what localapp
09:50
<alkisg>
Do you know what localapps are?
09:50
<roasted_>
Yes. You're saying this assuming I predefined localapps?
09:51
<alkisg>
No, I'm saying that thin clients are also unknown to your windows server
09:51
<roasted_>
Are you suggesting thin clients would also be unable to authenticate to the windows file server?
09:52
<alkisg>
Yes, *localapps* running on thin clients would also cause the authentication dialog to popup
09:52
*localapps*
09:52
<roasted_>
I'm not running localapps.
09:52
<alkisg>
Yes
09:52
<roasted_>
But my thin clients *do* work with the windows file server.
09:52
<alkisg>
Yes
09:54
<roasted_>
Well, I guess I just thought the fat chroot being on the domain would help.
09:54
I guess I thought if the chroot was on the domain, it would act the same way the thin client setup works.
09:54cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Read error: Operation timed out
09:54
<roasted_>
in regard to my issue
09:54
<alkisg>
You can make the chroot part of your domain
09:54
But when fat clients boot with that chroot, they change their hostname
09:55
It's *windows/likewise* knowledge "what would happen in that case"
09:55
<roasted_>
So you don't think the clients wuold look at the server chroot and see, oh hey, I'm authenticated.
09:55
<alkisg>
If windows doesn't like different hostnames, then you'd have a problem
09:55
You said yourself that windows doesn't like cloned machines
09:55
<roasted_>
Well, *windows* doesn't like the same hostname. If you have 2 hostnames on 1 network, Windows barks at you.
09:55
<alkisg>
Fat clients are like cloned machines
09:55
<roasted_>
Windows. as in, Windows clients.
09:56
Like if I have a lab of 30 Windows XP boxes with the same name, 29 will have a popup saying a duplicate name exists.
09:56
But here's the catch.
09:56
I don't think the Windows server cares.
09:56
So if I have the fat chroot on the domain, maybe it won't matter if it's 1 computer or 30.
09:56
computer = clients
09:56
<alkisg>
That's probably because they try to publish the name in a list on the master browser of the domain
09:56
<roasted_>
Maybe the windows server will see the entire lab as 1 name, even though there's multiple clients.
09:56cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp.
09:56
<roasted_>
And if it does that, that's fine.
09:57
<alkisg>
Linux hosts don't have a master browser. They use mdns
09:57
<roasted_>
I don't care if Windows thinks I have 2 clients with the same name or 200.
09:57
<alkisg>
I don't care at all what windows thinks :)
09:57
<roasted_>
to be honest, nor do I
09:57
But when you try to introduce a linux variable to the existing windows environment, it's a beast to do.
09:57
work has been so much more fun with a little variety in the mix.
09:57
<alkisg>
I'm just trying to help you pinpoint your problem, so that you can better find a way to solve it, if possible
09:58
<roasted_>
I understand.
09:58
I really wonder if joining to the fat chroot would help
09:58
<alkisg>
Backup, test, revert if unsuccesful
09:59
<roasted_>
Because you're saying fat clients get a different hostname each time. But that may not matter with the systems being linux. So if the clients can somehow "see" the fact the fat chroot is on the domain, we might be okay...
09:59
and you know
09:59
WORST case scenario, people have to log in twice to get to the file server.
09:59
That's truly worst case scenario, which isn't a big deal.
09:59
But it's something I WANT to get fixed.
09:59
<alkisg>
Or, you might find that windows have other means for not prompting for a password
10:00
<roasted_>
Because if we introduce this in the middle school or elementary school... that's a problem. High school isn't a big deal though.
10:00
<alkisg>
E.g. a kerberos ticket or whatever
10:00
<roasted_>
Yeah, that's true.
10:00
I guess I had jsut assumed it would react the same. I didn't take into account fat clients are like live sessions.
10:00
with the hostname, etc.
10:00
<alkisg>
But again, all this, is not related to ltsp. So by asking the appropriate questions and in the appropriate places it's easier to find your way to answers.
10:01
E.g. maybe in #samba or in #windows you can get better ideas
10:01
<roasted_>
yeah
10:01
Not sure about windows though.
10:01
<alkisg>
Ask like this:
10:01
<roasted_>
Those people don't like discussing Linux, because once I do a ton of other users get on the band wagon. :P
10:01
<alkisg>
"I have a copy of livexp"
10:01
<roasted_>
"Windows sucks" and "Linux is so much easier to use" etc.
10:01
<alkisg>
"I want to do something on it, so that if I boot 20 PCs with it, I'm joined to a domain"
10:02
It's the same question, in a different way
10:02
<roasted_>
yeah
10:02
this makes me want to drive to work and see if it works
10:02
<alkisg>
No linux involved in the question. Yet an answer there will get you an answer for your case too.
10:02
<roasted_>
It's just frustrating when it works on the server, ya know.
10:02
<alkisg>
Tjat
10:03
<roasted_>
If I log in as myself to the server, I can hit the file server fine.
10:03
But it makes sense.
10:03
<alkisg>
That's because you "rdesktop" to the server from the thin clients
10:03
And the server has manually joined the domain
10:03
<roasted_>
yeah.
10:03
well it doesn't work as me on the thin clients.
10:03
it only works for me AT the server
10:03
but that makes sense as to why
10:03
er
10:03
- thin
10:03
"on the clients"
10:04
The fortunate thing is, with the fact I can just rebuild the fat client chroot, if it tanks that's all I have to do
10:04
it's not like a reinstall of the server
10:04
speaking of which
10:05
can I just rename /opt/ltsp/i386 to like i386-backup
10:05
and build a new image?
10:05
and if the new image doesn't work with my testing, rename the old one back, update, and be back in business?
10:05
<alkisg>
Sure, but better rename the whole /opt/ltsp/ dir, so that /opt/ltsp/images/i386 doesn't get overwritten
10:05
I.e. sudo mv /opt/ltsp /opt/ltsp-backup
10:06
<roasted_>
gotcha
10:06
that sounds like an easy test
10:06
with minimal consequence for failure
10:06
<alkisg>
You can also copy it, it'll be faster
10:06
<roasted_>
yeah
10:07
that said, I need to get on with my day here. Appreciate the time, as always, alkisg
10:07
I gotta get this presentation ready for tomorrow :P
10:07
<alkisg>
Me too
10:07
<roasted_>
ahh, your's is too?
10:07cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Ping timeout: 246 seconds
10:08
<alkisg>
Not tomorrow, it's next week, but I took the chance to write some scripts for live ltsp servers
10:08
<roasted_>
nice, nice.
10:08
How thick is Windows usage in Greece?
10:09
Is it pre tty uncommon?
10:09
<alkisg>
Maybe 99%? something like that
10:09
<roasted_>
I just threw up a little bit.
10:09
<alkisg>
Fortunately we switched about 5% of secondary schools to linux this year
10:09
<roasted_>
Good going!
10:09cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp.
11:10ry (~ry@static-71-183-64-28.nycmny.fios.verizon.net) left irc: Quit: Leaving
11:32GodFather (~rcc@c-98-250-128-114.hsd1.mi.comcast.net) left irc: Quit: Ex-Chat
11:41
<highvoltage>
alkisg: awesome :)
11:51irule (~irule@189.162.3.218) joined #ltsp.
11:52
<irule>
hi, how mature is version 5?
11:55bobberty (~martian_l@124-197-42-208.callplus.net.nz) joined #ltsp.
11:57
<vagrantc>
irule: it's the only version that's seen any development in the last 4-5 years...
11:57
irule: of ltsp?
11:59
<irule>
I have a few 4 servers and wonder wether its a good idea to upgrade haha
12:07TheProf (~jbishay@cmr-208-124-154-250.cr.net.cable.rogers.com) joined #ltsp.
12:08
<TheProf>
Good day. I hope everyone is doing well. I am looking for help on how to allow a thin client to burn an ISO to CD. Running Edubuntu 10.10. Help? :)
12:13
<bobberty>
the prof: you may need to allow your thin client users to use the CD drive(s) in the users and groups dialogue?
12:14
<vagrantc>
TheProf: you'll need to run the burner program as a localapp
12:14
<TheProf>
bobberty, Do you mean to add the user to the group "cdrom"?
12:15
vagrantc, so it's not possible unless I have a local app setup running?
12:15
<vagrantc>
TheProf: correct
12:15
i mean, there may be a way to do so, but not through any standard LTSP magic
12:16
simplest way is to run it as a localapp
12:16
<TheProf>
Oh Interesting. I hadn't ever done that as I was not sure if it was overly complex.
12:16
My thin clients are fairly good machines but I was enjoying the fact they just work automagically :)
12:16
<vagrantc>
it's not hard. probably even enabled by default
12:17
<bobberty>
theprof: i mean tick, 'allow user to use the CD drive', or something like that under their privellages?
12:17
<vagrantc>
or, at least, the infrastructure to do so
12:17
<TheProf>
bobberty, I checked -- there was no option to allow user to use CD.
12:17
<vagrantc>
bobberty: it definitely is not simply a group permissions issue
12:17
<alkisg>
bobberty: that would allow the user to access the server cdrom drive
12:19
<vagrantc>
you need access to the local hardware ... ltspfs/localdev support merely adds a remote filesystem, it doesn't give you access to the CD drive itself
12:19
<TheProf>
I follow. Do you have a link to how to proceed online perhaps?
12:20
A lot of the LTSP wiki links don't lead to a page with any info.
12:21
http://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LocalApps has nothing on it.
12:26vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) left irc: Ping timeout: 240 seconds
12:29irule (~irule@189.162.3.218) left irc: Read error: Connection reset by peer
12:40bobberty (martian_l@124-197-42-208.callplus.net.nz) left #ltsp.
12:47bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp.
12:53vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) joined #ltsp.
12:55TheProf (jbishay@cmr-208-124-154-250.cr.net.cable.rogers.com) left #ltsp ("Ex-Chat").
13:03vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) left irc: Ping timeout: 240 seconds
13:08dlezcano (~dlezcano@AToulouse-159-1-83-102.w92-136.abo.wanadoo.fr) left irc: Ping timeout: 276 seconds
13:21dlezcano (~dlezcano@AToulouse-159-1-69-67.w92-134.abo.wanadoo.fr) joined #ltsp.
13:24Kicer86 (~Kicer86@host-5db0eeee.sileman.net.pl) left irc: Quit: KVIrc Insomnia 4.0.2, revision: 4740, sources date: 20100627, built on: 2010-08-08 18:29:00 UTC http://www.kvirc.net/
13:30vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) joined #ltsp.
13:37bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) left irc: Ping timeout: 250 seconds
14:29alexqwesa (~alex@alexo-veto.broker.freenet6.net) left irc: Remote host closed the connection
14:30alexqwesa (~alex@alexo-veto.broker.freenet6.net) joined #ltsp.
14:41mistik1_ (mistik1@unaffiliated/mistik1) joined #ltsp.
14:45mistik1 (mistik1@unaffiliated/mistik1) left irc: Ping timeout: 276 seconds
14:45Nick change: mistik1_ -> mistik1
14:57alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving.
14:59NeonLicht (~NeonLicht@darwin.ugr.es) left irc: Ping timeout: 246 seconds
15:02NeonLicht (~NeonLicht@darwin.ugr.es) joined #ltsp.
15:09komunista (~slavko@adsl-195-098-015-248.dynamic.nextra.sk) left irc: Quit: Leaving.
16:00_LoveStorm (storm@thepcrepair.info) left irc: Ping timeout: 264 seconds
17:43cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Ping timeout: 250 seconds
17:45bobberty (~martian_l@124-197-42-208.callplus.net.nz) joined #ltsp.
18:07bobberty (martian_l@124-197-42-208.callplus.net.nz) left #ltsp.
18:28_LoveStorm (storm@bb219-74-6-27.singnet.com.sg) joined #ltsp.
18:48ry (~ry@static-71-183-64-28.nycmny.fios.verizon.net) joined #ltsp.
19:48artista_frustrad (~artista_f@187.54.58.224) left irc: Ping timeout: 248 seconds
19:49MorningSon (~MorningSo@cpe-70-114-21-95.satx.res.rr.com) left irc: Quit: WeeChat 0.3.0
20:01artista_frustrad (~artista_f@187.54.58.224) joined #ltsp.
20:04vagrantc (~vagrant@c-24-21-191-93.hsd1.or.comcast.net) left irc: Quit: leaving
20:43dgroos (~dgroos@63.225.132.145) left irc: Quit: dgroos
21:00stgraber (~stgraber@ubuntu/member/stgraber) left irc: Quit: leaving
21:30alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
22:03cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp.
22:23stgraber (~stgraber@ubuntu/member/stgraber) joined #ltsp.
22:28alkisg (~alkisg@ubuntu/member/alkisg) left irc: Ping timeout: 240 seconds
22:47alexqwesa (~alex@alexo-veto.broker.freenet6.net) left irc: Read error: Operation timed out
22:48alexqwesa (~alex@alexo-veto.broker.freenet6.net) joined #ltsp.
22:52mrcarrot (~lasse@unaffiliated/mrcarrot) joined #ltsp.
22:54
<mrcarrot>
can anyone point me to some documentation on how to set up a local booting client? with this i mean a client with hard disk and everything booting from the hard disk instead of PXE, but otherwise completely working like a normal ltsp client
23:01
<NeonLicht>
mrcarrot, at boot time select PXE booting if the box allows it, otherways, use s floppy/CD with gPXE (I think now it is called iPXE or ePXE).
23:02bobby_C (~bobby@81.94.56.177) joined #ltsp.
23:07Appiah (~appiah@ip69.hethane.riksnet.nu) left irc: Ping timeout: 255 seconds
23:07Appiah (~appiah@ip69.hethane.riksnet.nu) joined #ltsp.
23:10bobby_C (~bobby@81.94.56.177) left irc: Ping timeout: 252 seconds
23:49alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp.
23:51Kicer86 (~Kicer86@host-5db0eeee.sileman.net.pl) joined #ltsp.
23:57
<alkisg>
mrcarrot: I'm not aware of any available docs on this. Which distro will you be using as base? E.g. for Ubuntu you'd need to hack the initramfs a bit.
23:57
Also, why? If your bandwidth is low, then your session will also probably be slow => not worth it, better use nx or something
23:57
<mrcarrot>
NeonLicht: the reason i am asking is because in this school a couple of computers are in really special use and will need some really special programs and drivers
23:57
alkisg: ^^
23:58
the rest will just use PXE
23:58
those computers are attached to something that is called "clever board"
23:58
so they will need the program and the drivers for that
23:58
<alkisg>
mrcarrot: still, why not use a separate chroot for them?
23:58
Why locally?
23:59
<mrcarrot>
how do i specify what chroot a certain computer will use?
00:00--- Mon Mar 28 2011