vmlintu | We are seeing some weird behaviour when nbd-proxy is in use. Disabling nbd-proxy and using nbd-client directly helps fix this, but I'm wondering what causes this to happen: https://bugs.launchpad.net/ltsp/+bug/589034 | 09:38 |
---|---|---|
ubottu | Ubuntu bug 589034 in LTSP "nbd-proxy hangs the nbd-connection to server" [Undecided,New] | 09:38 |
vmlintu | Disabling nbdswap or changing flow control settings didn't help | 09:40 |
alkisg | vmlintu: stgraber gets here later on, maybe you should try again in e.g. 8 hours... | 10:01 |
vmlintu | alkisg: yep, my timezone isn't really compatible with US&Canada.. | 10:09 |
LedHed | I built a fat client, then chroot to /opt/ltsp/fat-i386 | 16:13 |
LedHed | then apt-get install openssh-server | 16:13 |
LedHed | I also copy a couple scripts to /usr/local/bin | 16:13 |
LedHed | I exit chroot | 16:13 |
LedHed | then run ltsp-update-image -a fat-i386 | 16:14 |
LedHed | when I boot the fat client, there is no sshd nor are my scripts in /usr/local/bin | 16:14 |
LedHed | what am I doing wrong? | 16:15 |
alkisg | Which fat client how-to are you following? | 16:15 |
LedHed | alkisg, I'm using Ubuntu 10.04 | 16:16 |
alkisg | Do you have 2 chroots? | 16:17 |
LedHed | https://help.ubuntu.com/community/UbuntuLTSP/FatClients | 16:17 |
LedHed | Thats the howto | 16:17 |
LedHed | alkisg, yes. | 16:17 |
LedHed | initially I created an amd64 thinclient chroot, and then I wanted to test out fat clients to I created another chroot of /opt/ltsp/fat-i386 | 16:18 |
LedHed | the process I outlined worked fine on the amd64 image, but no luck on the fat image. | 16:19 |
alkisg | grep nbd /etc/inetd.conf | 16:20 |
alkisg | What does that tell you? | 16:20 |
LedHed | on the server? | 16:21 |
alkisg | Yes | 16:22 |
alkisg | (or on a thin client) | 16:22 |
LedHed | 2000 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/amd64.img | 16:22 |
LedHed | 2001 stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/nbdrootd /opt/ltsp/images/fat-i386.img | 16:22 |
LedHed | it has both images | 16:22 |
alkisg | You're probably just sending the wrong image there | 16:23 |
alkisg | grep filename /etc/ltsp/dhcpd.conf | 16:23 |
LedHed | I use a windows DHCP server, but I updated it to reflect ltsp/fat-i386/pxelinux0 | 16:24 |
LedHed | pxelinux.0 | 16:24 |
alkisg | OK, so, grep vmlinuz /var/lib/tftpboot/ltsp/fat-i386/pxelinux.cfg/default | 16:25 |
LedHed | kernel vmlinuz | 16:25 |
alkisg | sorry, my bad. grep append /var/lib/tftpboot/ltsp/fat-i386/pxelinux.cfg/default | 16:26 |
LedHed | nbdport=2001 | 16:27 |
LedHed | which was the fat-i386 image | 16:27 |
alkisg | so the complete line is: append ro initrd=initrd.img quiet splash nbdport=2001 ? | 16:27 |
LedHed | yes | 16:27 |
alkisg | Hmmm... | 16:28 |
alkisg | And, sudo chroot /opt/ltsp/fat-i386 dpkg -l openssh-server | 16:28 |
LedHed | its listed | 16:29 |
alkisg | And if you run that on a fat client you don't see it installed? | 16:30 |
alkisg | *without the chroot, of course... | 16:30 |
LedHed | 1 sec. but I dont think so | 16:30 |
LedHed | claims its installed, but I cant find it | 16:35 |
LedHed | nor can I find my scripts. | 16:36 |
alkisg | dpkg -L openssh-server shows you the files | 16:37 |
LedHed | lol. I missed the capital | 16:38 |
LedHed | did -l | 16:38 |
LedHed | wow | 16:39 |
LedHed | scratch that, its not installed. | 16:40 |
LedHed | I must have booted a thinclinet by mistake. | 16:40 |
LedHed | anyhow. openssh-server is not installed on the fatclient. | 16:40 |
LedHed | dpkg -L openssh-server on the fatclient says not installed. | 16:41 |
alkisg | Erm, what? dpkg -l openssh-server show the version, and dpkg -L openssh-server says not installed?! | 16:42 |
LedHed | dpkg -L openssh-server returns 'openssh-server is not installed' | 16:42 |
LedHed | dpkg -l openssh-server returns Name: openssh-server, Version: <none> | 16:43 |
LedHed | ran uname -a, and its running an i686 kernel, so this is in fact my fat client. | 16:44 |
alkisg | OK because you said ==> (06:29:32 μμ) LedHed: its listed | 16:44 |
alkisg | I assume you rebooted the fat client after updating the image, right? | 16:45 |
LedHed | alkisg, I think I goofed on that. I ran dpkg -l and saw openssh-server, and assumed it was installed. | 16:45 |
alkisg | Also, try to see if the date on `ls -l /opt/ltsp/images` matches the time when you run the ltsp-update-image command. | 16:46 |
LedHed | k | 16:47 |
LedHed | alkisg, I have a fat-i386.img.tmp, would that indicate that the image update failed? | 16:49 |
alkisg | Possibly | 16:49 |
LedHed | when I ran the update it said that it was successful | 16:49 |
LedHed | maybe I updated the image wrong. | 16:50 |
LedHed | alkisg, ltsp-update-image -a fat-i386 | 16:50 |
LedHed | I couldnt figure out a way to tell it what chroot to use, so I assumed that specifying fat-i386 as the architecture would work. maybe I was wrong. | 16:51 |
alkisg | No you did it ok | 16:51 |
alkisg | Try this: mv the.tmp file to the .img file | 16:51 |
LedHed | its way too small | 16:52 |
alkisg | Ah | 16:52 |
LedHed | like 1/2 the size it should be | 16:52 |
LedHed | I'll update the image again and see what happense | 16:52 |
alkisg | Urm... it shouldn't say "finished successfully" if it didn't move the image | 16:52 |
alkisg | (I mean, by reading the code, it shouldn't be doing that) | 16:53 |
LedHed | it didnt say that specificaly, but I remember readign something that made me thing that it completed corectly. | 16:57 |
LedHed | alkisg, do fat clients auth against the server or the local passwd file? | 17:03 |
alkisg | While on ldm, they auth against the server. Later on (e.g. on a sudo call or for screensaver unlocking) locally, which fails because there's not shadow entry there. | 17:04 |
LedHed | humm | 17:04 |
LedHed | maybe what I should do is just build a diskless linux image. | 17:05 |
LedHed | might be easier | 17:05 |
alkisg | What do you need to do? | 17:05 |
LedHed | I have 13 diskless atom nettops | 17:05 |
LedHed | I want a desktop with a link to our Webmail and a link to tn5250. | 17:06 |
LedHed | should be identical for all the nettops | 17:07 |
LedHed | I only need 1 user account which should autologin | 17:07 |
alkisg | Why were you installing ssh? | 17:08 |
LedHed | so that I can remote to the nettops and reboot them if need be | 17:08 |
LedHed | or shutdown, then to a WOL to wake them up at a later time. | 17:09 |
alkisg | ssh isn't a good method for that | 17:09 |
LedHed | alkisg, oh. | 17:09 |
LedHed | if theres a better way please tell. | 17:09 |
LedHed | the other thing is that the less dependent on the server the nettops are the better, | 17:10 |
alkisg | There are some methods outlined here: https://help.ubuntu.com/community/UbuntuLTSP/ | 17:11 |
alkisg | For shutdown, wol etc | 17:11 |
LedHed | they ultimately just connect to our exchange server and an AS/400, so if the /home dirs and auth isnt handled on the server then the nettops could continue to run even if the server goes down. | 17:11 |
alkisg | But I didn't like any of those either :) | 17:11 |
alkisg | So we just developed our own scripts for controlling clients... unfortunately we didn't have time yet to internationalize it, it's in greek only: http://wiki.ubuntu-gr.org/sch-scripts/screenshots | 17:12 |
alkisg | Automatic client discovery, sending commands either to the system (root) or the session (user), | 17:13 |
alkisg | wol, reboot, logoff etc, viewing screens... | 17:13 |
LedHed | wow, so you can remote view the clients, and shutdown | 17:13 |
alkisg | So if you don't mind blindly clicking on a greek caption, it can work fine for you. | 17:13 |
LedHed | :) | 17:13 |
alkisg | (or the toolbar :)) | 17:14 |
LedHed | maybe I could google translate it, :) | 17:14 |
alkisg | It also contains a wizard to automatically build a fat chroot etc | 17:14 |
alkisg | screen locking, sound on/off, lots of stuff there | 17:15 |
LedHed | thats cool. I wish I spoke greek so I could help with the translation | 17:15 |
LedHed | how are the /home dirs mounted on fat clients, NFS? | 17:17 |
LedHed | I must have screwed something up because now I cant login to the fat client. | 17:18 |
LedHed | after updating the image. | 17:18 |
alkisg | You can choose that with lts.conf, either nfs or sshfs | 17:18 |
alkisg | I'm using nfs because evolution doesn't run with sshfs, and I don't really care about the security implications | 17:19 |
LedHed | I havent created a lts.conf for my fat clients yet. | 17:20 |
LedHed | alkisg, any idea what would cause the fat client to stop authintacing? I cant login | 17:21 |
alkisg | Try putting SCREEN_02=shell and SCREEN_07=ldm on lts.conf | 17:21 |
alkisg | Then, reboot the client, switch to vt2 with alt+ctrl+f2, and try to ssh to the server from there. | 17:22 |
LedHed | consequently, after updating the fat client image, I can ssh to them now. | 17:22 |
LedHed | would be nice if LTSP supported building standalone images. | 17:23 |
LedHed | meaning that the client could stan on its own. | 17:24 |
alkisg | You mean without authenticating on the server? | 17:24 |
alkisg | and, how would the image be booted? | 17:25 |
LedHed | pxe | 17:25 |
LedHed | same as ltsp, image resides on a tftp server | 17:25 |
alkisg | (nbd server) - so where's the difference? | 17:29 |
LedHed | no nbd, entire image is loaded into ram | 17:29 |
LedHed | so a striped down distro similar to the LiveCD | 17:30 |
LedHed | gets loaded into a RAM disk on the client | 17:30 |
LedHed | then the client is standalone | 17:30 |
alkisg | And why would you need ltsp for that? | 17:30 |
alkisg | Just remaster the live cd to put whatever you wish, and serve it however you want... | 17:31 |
LedHed | just because I like the simplicity of the ltsp-build/update scripts. | 17:31 |
alkisg | And, if the server is needed to boot the clients anyway, why would you waste 1-2 GB RAM for the image and 5 minutes to boot the terminals? | 17:32 |
alkisg | Just to be able to disconnect the server later on? | 17:32 |
LedHed | shouldnt take 5 minutes, a CD sized image should take less than 1 minute to download | 17:33 |
alkisg | Right, so for 10 clients, 10 minutes | 17:33 |
LedHed | each client has fill bandwidth, so only about 1 minute per device | 17:34 |
alkisg | How much data can the server transfer? | 17:34 |
LedHed | the disks? | 17:34 |
alkisg | Divide that by number of clients * size of disk, to find out the minutes | 17:34 |
alkisg | E.g. 30 seconds for sending a cd to one client => 13 * 30 seconds for 13 clients | 17:35 |
LedHed | the chance that they all boot at exactly the same time is slim | 17:36 |
alkisg | Ah, ok then (I'm booting all of my clients at once) | 17:36 |
LedHed | my nettops are scattered over 1 sq mile (2.6 sq km) | 17:37 |
LedHed | so if I have to reboot the ltsp server, all the nettops immediately fail, which means I have to run a marathin to restart them all. | 17:38 |
LedHed | marathon | 17:38 |
alkisg | How much ram do they have? | 17:40 |
LedHed | 1GB | 17:41 |
alkisg | They'll need 1 Gb for the image | 17:41 |
alkisg | So there's no ram left to actually run the os | 17:41 |
alkisg | You'd need 2 Gb at least... | 17:41 |
alkisg | ...or some cut-down distro like DSL | 17:41 |
LedHed | not a big deal to upgrade the ram | 17:41 |
LedHed | DSL would work also. | 17:42 |
alkisg | OK, then you could patch the ltsp_nbd script a little, to download the image, and then mount it locally | 17:42 |
LedHed | I just need the ability to lock the user environment down. | 17:42 |
alkisg | It shouldn't take more than 1-2 hours to do what you wanted over ltsp | 17:42 |
LedHed | 1-2 hrs if you know what you're doing. I do not. :) | 17:43 |
alkisg | You could hire a developer to do the work for you, it should be much cheaper than the ram upgrade :D | 17:43 |
LedHed | true | 17:43 |
LedHed | are you such a developer? | 17:43 |
alkisg | moment, phone... | 17:44 |
LedHed | sure | 17:45 |
alkisg | LedHed: still around? | 18:12 |
LedHed | alkisg, back | 18:15 |
alkisg | LedHed: I'm talking to you on a private window... | 18:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!