IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 27 March 2011 (all times are UTC)
| 02:26 | bencer_ (~bencer@heal.cauterized.net) left irc: Read error: Connection reset by peer | |
| 02:26 | bencer (~bencer@heal.cauterized.net) joined #ltsp. | |
| 02:38 | roasted (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp. | |
| 02:38 | roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp. | |
| 02:38 | roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Client Quit | |
| 02:39 | roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp. | |
| 03:15 | Trixboxer (~Trixboxer@office.supportdepartment.net) joined #ltsp. | |
| 03:48 | komunista (~slavko@adsl-195-098-015-248.dynamic.nextra.sk) joined #ltsp. | |
| 06:01 | dgroos (~dgroos@63.225.132.145) joined #ltsp. | |
| 06:27 | Nubae (~Nubae@opensuse/member/nubae) joined #ltsp. | |
| 06:27 | <Nubae> man... there seem to be so few books on linux automation
| |
| 06:47 | cyberorg (~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:52 | cyberorg (~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:26 | artista_frustrad (~artista_f@187.54.58.224) joined #ltsp. | |
| 07:30 | artista_frustrad (~artista_f@187.54.58.224) left irc: Excess Flood | |
| 07:31 | artista_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:54 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Ping timeout: 250 seconds | |
| 08:13 | vagrantc (~vagrant@c-24-21-191-93.hsd1.or.comcast.net) joined #ltsp. | |
| 08:21 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
| 08:33 | MorningSon (~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:25 | Trixboxer (~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:28 | knipwim (~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:28 | knipwim (~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:54 | cyberorg (~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:56 | cyberorg (~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:07 | cyberorg (~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:09 | cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp. | |
| 11:10 | ry (~ry@static-71-183-64-28.nycmny.fios.verizon.net) left irc: Quit: Leaving | |
| 11:32 | GodFather (~rcc@c-98-250-128-114.hsd1.mi.comcast.net) left irc: Quit: Ex-Chat | |
| 11:41 | <highvoltage> alkisg: awesome :)
| |
| 11:51 | irule (~irule@189.162.3.218) joined #ltsp. | |
| 11:52 | <irule> hi, how mature is version 5?
| |
| 11:55 | bobberty (~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:07 | TheProf (~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:26 | vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) left irc: Ping timeout: 240 seconds | |
| 12:29 | irule (~irule@189.162.3.218) left irc: Read error: Connection reset by peer | |
| 12:40 | bobberty (martian_l@124-197-42-208.callplus.net.nz) left #ltsp. | |
| 12:47 | bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp. | |
| 12:53 | vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) joined #ltsp. | |
| 12:55 | TheProf (jbishay@cmr-208-124-154-250.cr.net.cable.rogers.com) left #ltsp ("Ex-Chat"). | |
| 13:03 | vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) left irc: Ping timeout: 240 seconds | |
| 13:08 | dlezcano (~dlezcano@AToulouse-159-1-83-102.w92-136.abo.wanadoo.fr) left irc: Ping timeout: 276 seconds | |
| 13:21 | dlezcano (~dlezcano@AToulouse-159-1-69-67.w92-134.abo.wanadoo.fr) joined #ltsp. | |
| 13:24 | Kicer86 (~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:30 | vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) joined #ltsp. | |
| 13:37 | bobby_C (~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) left irc: Ping timeout: 250 seconds | |
| 14:29 | alexqwesa (~alex@alexo-veto.broker.freenet6.net) left irc: Remote host closed the connection | |
| 14:30 | alexqwesa (~alex@alexo-veto.broker.freenet6.net) joined #ltsp. | |
| 14:41 | mistik1_ (mistik1@unaffiliated/mistik1) joined #ltsp. | |
| 14:45 | mistik1 (mistik1@unaffiliated/mistik1) left irc: Ping timeout: 276 seconds | |
| 14:45 | Nick change: mistik1_ -> mistik1 | |
| 14:57 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving. | |
| 14:59 | NeonLicht (~NeonLicht@darwin.ugr.es) left irc: Ping timeout: 246 seconds | |
| 15:02 | NeonLicht (~NeonLicht@darwin.ugr.es) joined #ltsp. | |
| 15:09 | komunista (~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:43 | cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Ping timeout: 250 seconds | |
| 17:45 | bobberty (~martian_l@124-197-42-208.callplus.net.nz) joined #ltsp. | |
| 18:07 | bobberty (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:48 | ry (~ry@static-71-183-64-28.nycmny.fios.verizon.net) joined #ltsp. | |
| 19:48 | artista_frustrad (~artista_f@187.54.58.224) left irc: Ping timeout: 248 seconds | |
| 19:49 | MorningSon (~MorningSo@cpe-70-114-21-95.satx.res.rr.com) left irc: Quit: WeeChat 0.3.0 | |
| 20:01 | artista_frustrad (~artista_f@187.54.58.224) joined #ltsp. | |
| 20:04 | vagrantc (~vagrant@c-24-21-191-93.hsd1.or.comcast.net) left irc: Quit: leaving | |
| 20:43 | dgroos (~dgroos@63.225.132.145) left irc: Quit: dgroos | |
| 21:00 | stgraber (~stgraber@ubuntu/member/stgraber) left irc: Quit: leaving | |
| 21:30 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
| 22:03 | cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp. | |
| 22:23 | stgraber (~stgraber@ubuntu/member/stgraber) joined #ltsp. | |
| 22:28 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Ping timeout: 240 seconds | |
| 22:47 | alexqwesa (~alex@alexo-veto.broker.freenet6.net) left irc: Read error: Operation timed out | |
| 22:48 | alexqwesa (~alex@alexo-veto.broker.freenet6.net) joined #ltsp. | |
| 22:52 | mrcarrot (~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:02 | bobby_C (~bobby@81.94.56.177) joined #ltsp. | |
| 23:07 | Appiah (~appiah@ip69.hethane.riksnet.nu) left irc: Ping timeout: 255 seconds | |
| 23:07 | Appiah (~appiah@ip69.hethane.riksnet.nu) joined #ltsp. | |
| 23:10 | bobby_C (~bobby@81.94.56.177) left irc: Ping timeout: 252 seconds | |
| 23:49 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
| 23:51 | Kicer86 (~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 | |