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