02:07 | _UsUrPeR__ (~jsass@fw.acurrus.com) left irc: Max SendQ exceeded | |
02:08 | thefinn93 (u1039@gateway/web/irccloud.com/x-gkcruciimudtdneu) left irc: Max SendQ exceeded | |
02:09 | _UsUrPeR__ (~jsass@fw.acurrus.com) joined #ltsp. | |
02:11 | _UsUrPeR__ (~jsass@fw.acurrus.com) left irc: Max SendQ exceeded | |
02:12 | mistik1_ (mistik1@173.225.244.123) joined #ltsp. | |
02:12 | _UsUrPeR__ (~jsass@fw.acurrus.com) joined #ltsp. | |
02:12 | _UsUrPeR__ (~jsass@fw.acurrus.com) left irc: Max SendQ exceeded | |
02:12 | _UsUrPeR__ (~jsass@fw.acurrus.com) joined #ltsp. | |
02:13 | mistik1_ (mistik1@173.225.244.123) left irc: Changing host | |
02:13 | mistik1_ (mistik1@unaffiliated/mistik1) joined #ltsp. | |
02:14 | _UsUrPeR__ (~jsass@fw.acurrus.com) left irc: Max SendQ exceeded | |
02:15 | _UsUrPeR__ (~jsass@fw.acurrus.com) joined #ltsp. | |
02:15 | _UsUrPeR__ (~jsass@fw.acurrus.com) left irc: Max SendQ exceeded | |
02:15 | _UsUrPeR__ (~jsass@fw.acurrus.com) joined #ltsp. | |
02:18 | alkisg (~alkisg@ubuntu/member/alkisg) got netsplit. | |
02:18 | mistik1 (mistik1@unaffiliated/mistik1) got netsplit. | |
02:18 | Selveste1 (~Selveste1@88.83.86.20.static.dong.customer.smilecontent.dk) got netsplit. | |
02:18 | Nick change: mistik1_ -> mistik1 | |
02:18 | Possible future nick collision: mistik1 | |
02:24 | ltsplogbot (~ltsplogbo@ip-97-74-72-29.ip.secureserver.net) left irc: Ping timeout: 276 seconds | |
02:25 | ltsplogbot joined #ltsp. | |
02:29 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) joined #ltsp. | |
02:44 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) left irc: Quit: Konversation terminated! | |
02:44 | xavier_brochard (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) joined #ltsp. | |
02:45 | vmlintu (~vmlintu@nblzone-240-143.nblnetworks.fi) joined #ltsp. | |
02:46 | Nick change: xavier_brochard -> xavierb | |
02:49 | Trixboxer (~Trixboxer@office.supportdepartment.net) joined #ltsp. | |
03:00 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) left irc: Ping timeout: 248 seconds | |
03:19 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) joined #ltsp. | |
03:31 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
03:38 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) left irc: Ping timeout: 250 seconds | |
03:46 | Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) joined #ltsp. | |
04:49 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) joined #ltsp. | |
04:56 | leio (~leio@gentoo/developer/leio) left irc: Read error: Connection reset by peer | |
04:58 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Ping timeout: 248 seconds | |
05:00 | tompa82 (~quassel@c-92abe155.94-9-64736c11.cust.bredbandsbolaget.se) joined #ltsp. | |
05:01 | leio (~leio@gentoo/developer/leio) joined #ltsp. | |
05:06 | tompa82 (~quassel@c-92abe155.94-9-64736c11.cust.bredbandsbolaget.se) left irc: Remote host closed the connection | |
05:07 | 77CAADQTK (~quassel@c-92abe155.94-9-64736c11.cust.bredbandsbolaget.se) joined #ltsp. | |
05:13 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) left irc: Quit: Konversation terminated! | |
05:13 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) joined #ltsp. | |
05:21 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) left irc: Ping timeout: 246 seconds | |
06:16 | jtwood (~jtwood@74.81.111.2) joined #ltsp. | |
06:17 | <jtwood> anybody use gconf-editor in an LTSP setup --- or other recommendations for configuring options and limiting user interaction with the system?
| |
06:32 | nothingman (~joshua@32.139.80.31) joined #ltsp. | |
06:33 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
06:36 | laprag (~ragnar@c425C45C1.dhcp.bluecom.no) joined #ltsp. | |
06:41 | laprag (~ragnar@c425C45C1.dhcp.bluecom.no) left irc: Client Quit | |
06:49 | Gremble (~Ben@cpc12-aztw24-2-0-cust146.aztw.cable.virginmedia.com) left irc: Quit: I Leave | |
06:59 | joshua__ (~joshua@32.139.84.7) joined #ltsp. | |
07:00 | nothingman (~joshua@32.139.80.31) left irc: Ping timeout: 252 seconds | |
07:02 | laprag (~ragnar@c425C45C1.dhcp.bluecom.no) joined #ltsp. | |
07:03 | laprag (~ragnar@c425C45C1.dhcp.bluecom.no) left irc: Client Quit | |
07:08 | 77CAADQTK (~quassel@c-92abe155.94-9-64736c11.cust.bredbandsbolaget.se) left irc: Remote host closed the connection | |
07:11 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving. | |
07:36 | Nick change: joshua__ -> nothingman | |
07:42 | MorningSon (~MorningSo@cpe-70-114-21-95.satx.res.rr.com) joined #ltsp. | |
07:51 | xavierb (~xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) joined #ltsp. | |
07:54 | xavierb (xavier@lns-bzn-27-82-248-0-213.adsl.proxad.net) left #ltsp. | |
08:01 | nothingman (~joshua@32.139.84.7) left irc: Ping timeout: 276 seconds | |
08:07 | cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Ping timeout: 255 seconds | |
08:08 | cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp. | |
08:26 | <Roasted> I have two LTSP servers on the domain via Likewise Open. When logged in as a domain user and you click on a windows file server link, one server lets you right in because it sees your domain account that you're logged into. The other asks for authentication, despite being logged into a domain account. On my problematic server, it works fine if you're at the server - it just requires authentication when you're on a client. Is this an LTSP issue or LW-Op
| |
08:26 | en?
| |
08:49 | jtwood (~jtwood@74.81.111.2) left irc: Read error: Connection reset by peer | |
08:57 | Roasted (~jason@unaffiliated/roasted) left irc: Ping timeout: 246 seconds | |
08:57 | roasted (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp. | |
09:20 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
09:22 | roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp. | |
09:28 | bobby_C (~bobby@188.20.161.210) joined #ltsp. | |
09:37 | <Appiah> roasted_: by windows file server link do you mean a shortcut to a smb share?
| |
09:38 | <roasted_> Appiah, yes
| |
09:38 | Appiah, I have links on the desktop that point to smb://server/share
| |
09:39 | Appiah, on my one test environment, the users just authenticated instantly since they were logged in to a domain account. The same way it does on windows.
| |
09:39 | Appiah, but with my other setup (tho its set up as identical as I can remember) requires authentication, which is kind of a PITA when you try and introduce this to a thousand students.
| |
09:39 | just curious if there's a way around it or what I did wrong
| |
09:40 | <Appiah> so you have one that it works on and one that it does not
| |
09:40 | check the pam files
| |
09:40 | Are they running same dist? same version?
| |
09:40 | <roasted_> Appiah, sure are. 10.10 edubuntu 64 bit.
| |
09:40 | Appiah, where are the pam files at?
| |
09:41 | <Appiah> somewhere in /etc/
| |
09:42 | I'd check where likewise edits these files..
| |
09:42 | (and I dont know where)
| |
09:42 | <roasted_> yeah
| |
09:43 | and the likewise forum has about 3 visitors per month
| |
09:43 | it's just weird because the server is fine
| |
09:43 | if I log in as myself on the server, I hit the file server without issue. it just pops right up. bam.
| |
09:43 | on the clients connected to that LTSP server? Nope.
| |
09:45 | <Appiah> /usr/share/pam-configs/likewise-open those that file give you an idea?
| |
09:45 | does*
| |
09:46 | but if I understand you correctly, 1 server this works just fine (client does not get prompted)
| |
09:46 | ?
| |
09:46 | <roasted_> the client DOES get prompted
| |
09:46 | the server does not
| |
09:46 | so if I'm on LTSP server, I hit windows, it works.
| |
09:47 | If I'm on LTSP client to the server above, I hit windows, oh hi who are you again?
| |
09:47 | <Appiah> "one server lets you right in because it sees your domain account"
| |
09:47 | <roasted_> right
| |
09:47 | <Appiah> I guess that's ON not ONE then :D
| |
09:47 | <roasted_> let me rewind
| |
09:47 | I have 2 servers
| |
09:47 | both identically set up
| |
09:48 | both servers can log in to windows file server fine
| |
09:48 | server A's clients also work
| |
09:48 | server B's clients do not work
| |
09:48 | <Appiah> ok
| |
09:48 | <roasted_> so while both SERVERS work okay, the clients are a 50 50 batch
| |
09:48 | one batch no, one batch yes
| |
09:48 | <Appiah> are you using the same chroot on server A and B?
| |
09:48 | <roasted_> that's where I began to get confused if it was LWOpen or what
| |
09:48 | no
| |
09:48 | one is thin clients
| |
09:48 | the other is fat
| |
09:48 | the one giving me an issue is fat
| |
09:48 | <Appiah> well..
| |
09:49 | that's something missing in your fatclients chroot
| |
09:49 | <roasted_> so it would be an LTSP issue
| |
09:49 | <Appiah> na
| |
09:49 | could be likewise
| |
09:49 | or gnome
| |
09:49 | <roasted_> failing to see how it wouldn't be
| |
09:49 | if server works
| |
09:49 | yet chroot doesn't
| |
09:49 | that looks a little black and white to me
| |
09:49 | <Appiah> but the thin client chroot does work
| |
09:49 | the fat does not
| |
09:50 | and these 2 are different
| |
09:50 | <roasted_> from what I've experienced
| |
09:50 | fat and thin work very differently
| |
09:50 | <Appiah> ok
| |
09:50 | <roasted_> I know it's thought they work identically or whatever
| |
09:50 | and maybe I'm wrong
| |
09:50 | but I feel like they are two different beasts when Is et them up
| |
09:51 | <Appiah> I have little experince with fatclients , and none has ever used likewise (only openldap)
| |
09:51 | https://help.ubuntu.com/community/LocalAppsAndLikewise-Open
| |
09:51 | might help you
| |
09:52 | guess the localapps dont know they are in a AD
| |
09:52 | <roasted_> what are you referring to with localapps? What in this situation is a localapp?
| |
09:53 | <Appiah> localapps is fatclients and thinclients with applications running from the chroot
| |
09:53 | <roasted_> and this is likewise 5.4 or earlier
| |
09:53 | I'm on 6
| |
09:53 | <Appiah> and not from the server
| |
09:53 | "If you are using likewise-open 5.4 (or later)"
| |
09:53 | <roasted_> stop lying
| |
09:53 | :P
| |
09:53 | perhaps I need to invest in those things
| |
09:53 | called uh
| |
09:53 | eh
| |
09:53 | glasses?
| |
09:54 | <Appiah> well good luck to you sir
| |
09:54 | <roasted_> I wish alkisg could comment on this :P
| |
09:54 | (ping)
| |
09:54 | thanks Appiah
| |
09:54 | * alkisg has never seen likewise, can't comment on it | |
09:54 | <roasted_> have you ever heard of the issue I'm seeing?
| |
09:55 | <alkisg> I didn't read the chat you guys had
| |
09:55 | <roasted_> to sum it up...
| |
09:55 | on my server, if I'm on as a domain account and I click on the link I set up to a windows file server, it works fine
| |
09:55 | if I'm on a fat client connected to that server, using the same domain account, it asks for credentials.
| |
09:56 | I need to bypass that credential screen and make it work in 1 fluent action, just like my OTHER server does in the other building using thin clients.
| |
09:56 | like I said... works if I'm logged in as steve_jobs (domain account) on server, but the same account on client it asks me who I am again.
| |
09:56 | <alkisg> Where are the credentials stored?
| |
09:56 | <roasted_> alkisg, this may go back to that time thing the other day.
| |
09:56 | <alkisg> gnome keyring?
| |
09:56 | <roasted_> but I set the time in lts.conf
| |
09:56 | <alkisg> likewise keyring? kerberos? somewhere else?
| |
09:57 | <roasted_> I have no idea. I just know I joined the server to the domain under likewise-open.
| |
09:57 | <alkisg> I mean, cached, not stored
| |
09:57 | <roasted_> Where it gets the creds from there I'm not sure.
| |
09:57 | <alkisg> So you need to join the fat clients to the domain?
| |
09:58 | <roasted_> I'm not sure. If that would fix it, sure.
| |
09:58 | <alkisg> Anyway, I've no clue about how likewise works, can't comment on it.
| |
09:58 | <roasted_> Is it possible to do that?
| |
09:58 | to join a fat client?
| |
09:58 | That just sounds strange... a domain chroot on a domain server :P
| |
10:00 | And on top of tha, my other server running thin clients in the other building works perfectly.
| |
10:00 | Do you think the chroot being fat in this case has something to do with it? After all, if I'm physically on the server and I log in, it works...
| |
10:17 | bobby_C (~bobby@188.20.161.210) left irc: Quit: Goin' down hard | |
10:26 | <alkisg> That may be because you joined the server to the domain but you didn't join the fat chroot
| |
10:26 | But as I said I've no idea about how likewise works so I can't comment
| |
10:30 | <Appiah> like I said
| |
10:30 | dont think the localapp is aware
| |
10:30 | localapps/fatclient
| |
10:52 | komunista (~slavko@adsl-195-098-015-248.dynamic.nextra.sk) joined #ltsp. | |
11:03 | <roasted_> Appiah, the thing I don't get is, wouldn't the fat client have the same hostname as the server? Therefore both joined... that won't really work.
| |
11:06 | NeonLicht (~NeonLicht@darwin.ugr.es) left irc: Ping timeout: 276 seconds | |
11:12 | moldy (~rene@unaffiliated/moldy) left irc: Ping timeout: 250 seconds | |
11:15 | NeonLicht (~NeonLicht@darwin.ugr.es) joined #ltsp. | |
11:18 | moldy (~rene@unaffiliated/moldy) joined #ltsp. | |
11:19 | <Appiah> roasted_: nope
| |
11:22 | <alkisg> roasted_: as yourself. You boot a PC that has a local installation of Ubuntu, not related to LTSP. What do you need to do to have it work like you want with likewise?
| |
11:22 | When you got the answer to that question, apply it to the fat chroot
| |
11:22 | <roasted_> so I truly have to treat the fat chroot as an independent OS installation
| |
11:23 | <alkisg> Yup
| |
11:23 | <roasted_> true or false - I have to do the SAME thing with a thin client
| |
11:23 | <alkisg> No, because a thin client IS the server
| |
11:23 | <roasted_> gotchaaaaaaaaaa
| |
11:23 | THATS why my darn thin client box works
| |
11:23 | alkisg, why are you so smart
| |
11:23 | knock it off :P
| |
11:23 | <alkisg> :P
| |
11:23 | <roasted_> alkisg, don't forget about that beer if you get to PA, USA :P
| |
11:24 | <alkisg> Heh, I think I got about 50 beers if I ever come to the USA. Now I'm only missing the tickets :D
| |
11:24 | <roasted_> alkisg, I don't deny that. Your time with helping me has certainly warranted far more than just 1 :P
| |
11:25 | alkisg, I'm actually working on a presentation now. I'm showing this to the board on monday at work.
| |
11:25 | alkisg, the plan was to do this in summer, until my boss had a whoopsie and we ended up having to move *fast* on this.
| |
11:25 | <alkisg> I see. So you're working overtime, Saturdays etc?
| |
11:26 | <roasted_> alkisg, a bit. I'm using my laptop as a "server", along with 3-4 other laptops in the board room.
| |
11:26 | <alkisg> I'm using a lot of vbox VMs for testing
| |
11:26 | <roasted_> I want to take the hard drives out of the board room laptops and boot the laptops to LTSP on my laptop... just for an extra "ohhh, yeah... wow..."
| |
11:26 | <alkisg> Next week I'll be doing a demo too.
| |
11:27 | <roasted_> The presentation isn't just about LTSP. It's about open source software in general, because with LTSP we need to itnroduce Ubuntu, etc.
| |
11:27 | <alkisg> Unfortunately it'll be on a 100 mbps lab with windows
| |
11:27 | <roasted_> LTSP with windows?
| |
11:27 | <alkisg> So I'll be using 6 USB hard drives to boot 6 of the windows PCs and transform them to ltsp servers,
| |
11:27 | <roasted_> fun stuff
| |
11:27 | <alkisg> and the rest 20 PCs will be thin + fat clients
| |
11:27 | So that the people attending can see all 3 roles, server, thin and fat
| |
11:28 | <roasted_> nice, nice
| |
11:28 | <alkisg> So I had to make some scripts to make "roaming" ltsp servers. Fun
| |
11:28 | <roasted_> sounds it :P
| |
11:28 | alkisg, if I join the fat chroot to the domain, would I have to reboot the server or just update the ch root?
| |
11:28 | since joining to the domain normally warrants a reboot...
| |
11:29 | <alkisg> ltsp-update-image, reboot client
| |
11:29 | <roasted_> no need to reboot server?
| |
11:29 | <alkisg> No, the server is a separate machine from the chroot
| |
11:29 | You have 2 PCs to maintain now. The server (along with the thin clients), and the fat chroot.
| |
11:29 | They're 2 separate PCs that only connect with ssh and lts.conf
| |
11:29 | <roasted_> I understand. I just wasn't sure if rebooting due to domain joining would be handled by simply updating it.
| |
11:33 | alkisg, does the update process actually "reboot" the chroot?
| |
11:43 | cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Ping timeout: 246 seconds | |
11:52 | <pmatulis> roasted_: reboot a chroot?
| |
11:54 | <alkisg> The chroot is a disk. You don't reboot disks, you reboot clients.
| |
11:54 | I.e. the fat client booting from that chroot.
| |
11:57 | <roasted_> pmatulis, I was just curious if the update process, in some way, "rebooted" the chroot.
| |
11:57 | I was just trying to understand what update does, basically :P
| |
11:58 | <pmatulis> roasted_: it rebuilds the client chroot image
| |
11:58 | <roasted_> since most OS's you have to reboot at times to "apply" settings, I was just trying to see the relationship between traditional OS's and the chroot for fat clients
| |
11:59 | <pmatulis> roasted_: in order to gain access to any change to the image you need to reboot
| |
12:00 | <roasted_> the client
| |
12:00 | yes
| |
12:00 | I'm talking about the server/chroot
| |
12:00 | <pmatulis> roasted_: stop talking about the server
| |
12:00 | roasted_: we're talking about a file on the server
| |
12:00 | <roasted_> but this file acts as an OS, essentially
| |
12:00 | an image
| |
12:01 | an install
| |
12:01 | <pmatulis> roasted_: so?
| |
12:01 | <roasted_> that's all I'm asking
| |
12:01 | <pmatulis> roasted_: i can only repeat myself. if you change the image you need to reboot the client in order to take advantage of the change
| |
12:02 | <roasted_> I know.
| |
12:02 | I was just trying to understand what "updating" the image on the chroot does.
| |
12:02 | but nevermind.
| |
12:02 | <pmatulis> roasted_: i just told you
| |
12:03 | roasted_: it rebuilds it
| |
12:04 | <roasted_> k
| |
12:04 | thanks
| |
12:05 | <pmatulis> roasted_: btw, the image *is* the chroot
| |
12:05 | <roasted_> I know
| |
12:05 | <pmatulis> roasted_: you said "image on the chroot"
| |
12:05 | <roasted_> ah
| |
12:05 | I did
| |
12:05 | I knew the image was the chroot though
| |
12:06 | I think I meant server
| |
12:06 | image/chroot on the server
| |
12:06 | does chroot stand for something in particular?
| |
12:07 | <pmatulis> roasted_: "change the root" i guess
| |
12:07 | <alkisg> When we say "chroot" here in #ltsp, we mean the /opt/ltsp/i386 directory
| |
12:07 | <roasted_> yar
| |
12:07 | I gotcha
| |
12:07 | <alkisg> And when we say "nbd image", we mean the /opt/ltsp/image/i386.img file
| |
12:08 | When you run ltsp-update-image, you compress the chroot into the nbd image
| |
12:08 | <roasted_> do I have to use --arch i386 when I update?
| |
12:08 | <alkisg> Think like zipping a folder with winzip
| |
12:08 | <roasted_> cause I do, out of habit for some reason
| |
12:08 | 64b server, 32b chroot
| |
12:08 | <alkisg> Yes
| |
12:08 | <roasted_> if I'm on a fat client, do I have to use --fat-client when updating?
| |
12:08 | or just when building it initially?
| |
12:09 | <alkisg> So when you change something in the chroot (the folder), then in ubuntu you need to update the nbd image, and then you need to reboot the client for the changes to take effect
| |
12:09 | There's no --fat-client option in ltsp-update-image
| |
12:09 | Try `man ltsp-update-image` or `ltsp-update-image --help`
| |
12:09 | <roasted_> k
| |
12:10 | I still gotta DL those packages too
| |
12:10 | I forgot to do that on my box at work
| |
12:20 | what would happen if I wouldnt use --arch i386 when updating a 32b client on a 64b server? would I revamp the client to be 64b?
| |
13:01 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) joined #ltsp. | |
13:01 | Trixboxer (~Trixboxer@office.supportdepartment.net) left irc: Quit: "Achievement is not the end, its the beginning of new journey !!!" | |
13:42 | <dgroos> alkisg: ping
| |
13:43 | <alkisg> dgroos: pong in 10 mins, write if you will
| |
13:44 | <dgroos> For sure.
| |
13:44 | I'm wondering if you've had further thoughts about your idea on clustering over wifi.
| |
13:47 | Having 8 recycled P4's as elements of a cluster, connected via wifi, then each of these elements would be connected via ethernet to a few computers at the table.
| |
13:50 | Thus, the fat clients would be able to boot via cable as they are designed to do, but they wouldn't need network cables leaving the tables.
| |
14:01 | 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/ | |
14:06 | ogra_ (~ogra@p5098ed03.dip0.t-ipconnect.de) left irc: Ping timeout: 250 seconds | |
14:07 | bobby_C (~bobby@188.20.161.210) joined #ltsp. | |
14:09 | <alkisg> Took a bit more :) reading...
| |
14:10 | dgroos: sounds reasonable
| |
14:10 | And you would have 1 authentication server and a common nfs home for everyone?
| |
14:10 | Or local nfs homes on those clusters?
| |
14:12 | <dgroos> I wasn't sure if one would want 1 powerful server as the backbone so to say of all of the low-power servers in the cluster, and...
| |
14:12 | if there would be memory limits since the p4 elements are 32 b arch.
| |
14:13 | <alkisg> The fat client servers don't need CPU. A bit of RAM, to cache parts of the fat nbd image, and a fast network
| |
14:13 | <dgroos> or, if there would be compatability issues with a 64b machine along with several 32 b machines.
| |
14:13 | <alkisg> No, it doesn't matter at all, the fat client servers are only serving an nbd image etc
| |
14:14 | They could even be... mac or arm
| |
14:14 | <dgroos> Wow--so I could get some very small hardware to do the job--fits in the table better.
| |
14:16 | Would I even need a strong server in the cluster? I'm thinking of storing the home folders there--is that how you would recommend it?
| |
14:16 | <alkisg> Do the kids change places? If you can force them to use the same cluster each time, then yes, I'd recomment putting both authentication + homes there
| |
14:17 | And only use wifi for internet access
| |
14:17 | I.e. 1 cluster == 1 independed fat ltsp setup
| |
14:17 | Of course you can clone the servers for installation
| |
14:18 | roasted__ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp. | |
14:19 | <dgroos> Kids would definitely change places several times throughout the year--practice in working with new teams etc.
| |
14:19 | <alkisg> Then you'd need /home over wifi
| |
14:20 | Or some clever way of moving /home/username every time a student moves to a different cluster
| |
14:20 | <dgroos> OK that doesn't sound like it would generally be an issue. Would it get loaded locally on the fat client when a student logs in?
| |
14:20 | <alkisg> The fat client would access /home/username with sshfs by default, or if you prefer with nfs
| |
14:21 | That's over wifi
| |
14:21 | So for 10 students trying to access /home over wifi the bandwidth would drop a lot
| |
14:21 | roasted_ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Ping timeout: 246 seconds | |
14:21 | roasted (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Ping timeout: 246 seconds | |
14:21 | <dgroos> 'k
| |
14:21 | roasted (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) joined #ltsp. | |
14:21 | <alkisg> How many students using a single wifi access point? And what speed? 50 mbps?
| |
14:21 | (seats, not students)
| |
14:22 | <dgroos> I suppose we would use n networking standard, not sure where it's at...
| |
14:23 | <alkisg> That would suffice for a lot of seats
| |
14:24 | <dgroos> And, I wonder if I could put a couple of access points, at least 15 (for 2-1 ration) or better yet 30 separate users at any time in a classroom.
| |
14:25 | <alkisg> I think I'd implement the other option, the "syncing /home/username locally when the student logs on"
| |
14:26 | locally == in the cluster server
| |
14:26 | <dgroos> Would I need a regular (dual-core xeon) server if I had all home folders on it and was using pentium 4 fat clients?
| |
14:26 | <alkisg> No, you wouldn't need a big server at all
| |
14:26 | <dgroos> OK, I wonder how difficult some script like that would be?
| |
14:27 | <alkisg> Not very much, writing such a script + debugging it should take less than a day
| |
14:27 | <dgroos> would this work with sch-scripts, that fancy program coming of that famous app-shop? ;)
| |
14:27 | <alkisg> (it would be best if it only synced when the student actually changed cluster, not every time)
| |
14:28 | Hehe
| |
14:28 | <dgroos> sure.
| |
14:28 | <alkisg> Each cluster could have its own versions of sch-scripts, you'd need a master one?
| |
14:29 | <dgroos> When you say each cluster, you mean each element of a cluster?
| |
14:29 | <alkisg> Would be possible too, but it would need some tweaking with the different servers
| |
14:29 | With cluster I mean a table consisting of 1 fat-client-server and 4-8 fat clients
| |
14:29 | Maybe not the right word, I can call it "table" from now on :)
| |
14:30 | <dgroos> OK I was thinking that each of the 'servers' at the table would unite and be part of a single 'cluster'--I didn't have the under-the-hood visualized, however.
| |
14:31 | <alkisg> Maybe you want to have a look at ltsp-cluster? Never looked at it, don't know if it'll suit you
| |
14:32 | I'd just use 1 master server for central authentication and for nfs homes, which would be rsynced locally when needed
| |
14:32 | <dgroos> That's what I was imagining when you said cluster!
| |
14:33 | <alkisg> I.e. the fat servers on the tables wouldn't have any user accounts at all
| |
14:33 | <dgroos> And the fat client images would be at the table-servers...
| |
14:34 | <alkisg> Right, just for speed
| |
14:34 | You wouldn't need to maintain those, you could maintain the fat image on the master server, and copy it to the table servers when updated
| |
14:36 | <dgroos> Right, so as you say, the entire master server (master server? sounds paradoxical!) would have all the table servers rsync to it for everything BUT the home folders...
| |
14:37 | <alkisg> No, not for everything. They wouldn't need /opt/ltsp/i386
| |
14:37 | They'd only need /opt/ltsp/images/i386.img
| |
14:37 | They wouldn't need ubuntu-desktop or even X
| |
14:37 | But they'd need some gigabytes for /home, for the students that connected there
| |
14:39 | So, ltsp-update-image on the server should also rsync /opt/ltsp/images/i386.img to the client,
| |
14:39 | <dgroos> OK, right, each night or whenever, I could rsync the master home directories with the home directories on the table-server (for just the students who sit at that table).
| |
14:39 | <alkisg> and a login script should rsync /home/username to the table server
| |
14:39 | *sorry I said client above, I meant table server
| |
14:41 | <dgroos> This is almost sounding like a done deal (ignorance is bliss :D ).
| |
14:41 | <alkisg> The syncing part is a bit more complicated than that
| |
14:42 | I.e. when logging off, the local copy is more recent than the "master" on
| |
14:42 | e
| |
14:42 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) left irc: Ping timeout: 240 seconds | |
14:42 | <alkisg> So I'd prefer to use a login syncing script, which would sync from the last logon server
| |
14:43 | <dgroos> Isn't there an option with rsync to take the most recent version?
| |
14:43 | "last logon server"?
| |
14:43 | <alkisg> Kid sits on table A
| |
14:43 | The next hour he sits on table B
| |
14:44 | Describe to me how you got his documents transfered to table B :)
| |
14:45 | <dgroos> At this point in the project that senario wouldn't happen (they've only got this in their science class) but I see your point. So,
| |
14:47 | are you envisioning when a user logs out the changes get exported from the table server to the home folders on the master server, then when that student logs in the next day or at a different table they get updated back at the table server?
| |
14:48 | <alkisg> (1) how often would kids change tables? and (2) do you keep daily backups for /home?
| |
14:50 | <dgroos> 1) every couple of weeks in my class but in come teachers classes it could be almost every day and in others 1 time a month. 2) I haven't kept daily backups but I could I guess.
| |
14:51 | <alkisg> Based on your answers, I'd use the "last logon server" solution I described above,
| |
14:51 | <dgroos> I didn't really get that solution...
| |
14:52 | <alkisg> In that solution, there is no /home on the "master server". All /home/usernames are local to the tables
| |
14:52 | So the kid logs on to table A, and gets his /home/username folder there
| |
14:52 | The next day he logs on again to table A. No syncing happens at all. Very very fast.
| |
14:53 | The next day he logs on to table B.
| |
14:53 | The script sees that the last logon location was on table A.
| |
14:53 | So it rsyncs directly from table A to table B, and updates the entry about the most recent login, which is now on table B.
| |
14:53 | <NeonLicht> And what happens if tablet A is off/broken/lost?
| |
14:54 | <alkisg> Then a clean folder is used, or, if an old one is available, the old one. But the user should be prompted on that case.
| |
14:55 | The same would happen with the "master server" /home too, it's not something specific to this solution
| |
14:55 | And it's even better with /home over wifi/nfs, because now there's at least the option for the kids to work in case the "master /home" would be down
| |
14:56 | (and faster too)
| |
14:56 | *better than, not better with
| |
14:56 | <dgroos> So, there would be a complete set of home folders at each table-server, however, the only ones up-to-date would be the home folders of the students who last logged in at that table,
| |
14:56 | <alkisg> Exactly
| |
14:56 | <NeonLicht> The master can use a NAS, with RAID, or ZFS. A tablet can very easily gets moved soemwhere (borroewd to another classroom/office), or off for any reason, or broken, etc.
| |
14:57 | A sync back to the server after use could be a good idea, I think.
| |
14:57 | <dgroos> and when a student moved from one table to the next there would be updating of the student's new table-server home folder. Slick!
| |
14:58 | <alkisg> dgroos: are you planning on frequently moving the tables, i.e. is the possibility of the "last logon table missing" high?
| |
14:58 | <dgroos> NeonLicht: The NAS would be for backup purposes then?
| |
14:59 | <alkisg> NeonLicht: table, not tablet
| |
14:59 | <NeonLicht> Why for backup?
| |
14:59 | <alkisg> Tables with 4-8 fat clients
| |
14:59 | <NeonLicht> Ah, alkisg, OK, sorry, I though you were speaking about tablets :(
| |
15:00 | Fat clients are totally different, of course :)
| |
15:00 | <alkisg> My english are poor, I didn't choose nice words, but I think dgroos understood me :)
| |
15:01 | <NeonLicht> So is mine, haha :D
| |
15:01 | <dgroos> Tables true--https://picasaweb.google.com/djgroos/GrowingCommunitiesOfScientists#5576223461332828498
| |
15:02 | <alkisg> Being a teacher that also doesn't backup every day... It would be enough for me to have a backup from last week in table "A", even in the case where the hard disk in the most recent logon table "B" was destroyed
| |
15:02 | <dgroos> I does get ur english purdy mch but I often have a hard time with the deltas and omegas!
| |
15:02 | <alkisg> :D
| |
15:03 | <dgroos> Yes, that would pretty much work especially since a lot of the students work and the info they access is on web servers.
| |
15:03 | <NeonLicht> I do an incremental backup every 6 hours :D
| |
15:04 | <alkisg> I did a backup on my school 6 years ago. :D
| |
15:04 | <NeonLicht> hahaha
| |
15:04 | <alkisg> NeonLicht: hehe, where are you working?
| |
15:04 | <NeonLicht> University.
| |
15:04 | <dgroos> of?
| |
15:04 | <NeonLicht> Granada, Spain.
| |
15:05 | I am a geneticist.
| |
15:05 | <dgroos> ? I was thinking 'Licht' german :)
| |
15:05 | <NeonLicht> It is german, indeed :)
| |
15:06 | <dgroos> geneticist... can you guess the activity the students are doing in the above-reference photo? :)
| |
15:06 | <NeonLicht> http://www.youtube.com/watch?v=iPDCiHLsFMU <--- NeonLicht
| |
15:07 | I have no clue, should I?
| |
15:07 | <abeehc> angry birds
| |
15:07 | <alkisg> Relaxing music... reminds me of cartoons from my childhood :D
| |
15:10 | <dgroos> Nice--back from my days (college days, that is).
| |
15:10 | The students are building--I guess just starting to build so not much to see yet--of a section of DNA.
| |
15:18 | alkisg: Thanks again so much for your knowledgeable and creative ideas. I'll be working on this over the summer with 11.04, though I like to have ideas cooking on the back burners of my head, so to say.
| |
15:20 | ... Which is why I needed to talk more about it now.
| |
15:35 | <alkisg> dgroos: you're welcome - me, I'll wait for 12.04 :)
| |
15:35 | night all
| |
15:35 | alkisg (~alkisg@ubuntu/member/alkisg) left irc: Quit: Leaving. | |
15:56 | bobby_C (~bobby@188.20.161.210) left irc: Quit: Goin' down hard | |
16:14 | dgroos_ (~dgroos@63.225.132.145) joined #ltsp. | |
16:14 | dgroos (~dgroos@63.225.132.145) left irc: Read error: Connection reset by peer | |
16:14 | Nick change: dgroos_ -> dgroos | |
16:19 | irule (~irule@189.162.3.218) joined #ltsp. | |
16:37 | komunista (~slavko@adsl-195-098-015-248.dynamic.nextra.sk) left irc: Quit: Leaving. | |
16:54 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) joined #ltsp. | |
18:22 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) left irc: Ping timeout: 250 seconds | |
18:24 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) joined #ltsp. | |
18:32 | cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp. | |
19:28 | vagrantc (~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) left irc: Ping timeout: 240 seconds | |
19:30 | Nick change: zz_evil_root -> evil_root | |
19:32 | Nick change: evil_root -> zz_evil_root | |
19:33 | irule (~irule@189.162.3.218) left irc: Ping timeout: 248 seconds | |
19:46 | irule (~irule@189.162.3.218) joined #ltsp. | |
20:05 | nothingman (~joshua@32.137.2.188) joined #ltsp. | |
20:42 | nothingman (~joshua@32.137.2.188) left irc: Ping timeout: 246 seconds | |
20:46 | roasted__ (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Ping timeout: 246 seconds | |
20:46 | roasted (~Jason@c-174-54-217-48.hsd1.pa.comcast.net) left irc: Ping timeout: 240 seconds | |
20:50 | cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Ping timeout: 250 seconds | |
20:54 | cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp. | |
21:10 | dgroos (~dgroos@63.225.132.145) left irc: Quit: dgroos | |
21:20 | F-GT (~phantom@ppp121-45-178-157.lns20.syd7.internode.on.net) left irc: Ping timeout: 240 seconds | |
21:28 | MorningSon (~MorningSo@cpe-70-114-21-95.satx.res.rr.com) left irc: Quit: WeeChat 0.3.0 | |
21:34 | F-GT (~phantom@ppp121-45-177-217.lns20.syd7.internode.on.net) joined #ltsp. | |
21:34 | irule (~irule@189.162.3.218) left irc: Read error: Connection reset by peer | |
21:50 | artista_frustrad (~artista_f@189.75.139.149) left irc: Ping timeout: 250 seconds | |
21:59 | alkisg (~alkisg@ubuntu/member/alkisg) joined #ltsp. | |
22:12 | Nick change: zz_evil_root -> evil_root | |
23:09 | cyberorg (~cyberorg@opensuse/member/Cyberorg) left irc: Ping timeout: 264 seconds | |
23:10 | cyberorg (~cyberorg@opensuse/member/Cyberorg) joined #ltsp. | |
23:22 | Kicer86 (~Kicer86@host-5db0eeee.sileman.net.pl) joined #ltsp. | |
23:33 | Nick change: evil_root -> zz_evil_root | |
00:00 | --- Sun Mar 27 2011 | |