[09:38] <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:40] <vmlintu> Disabling nbdswap or changing flow control settings didn't help
[10:01] <alkisg> vmlintu: stgraber gets here later on, maybe you should try again in e.g. 8 hours...
[10:09] <vmlintu> alkisg: yep, my timezone isn't really compatible with US&Canada..
[16:13] <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:14] <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:15] <LedHed> what am I doing wrong?
[16:15] <alkisg> Which fat client how-to are you following?
[16:16] <LedHed> alkisg, I'm using Ubuntu 10.04
[16:17] <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:18] <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:19] <LedHed> the process I outlined worked fine on the amd64 image,  but no luck on the fat image.
[16:20] <alkisg> grep nbd /etc/inetd.conf
[16:20] <alkisg> What does that tell you?
[16:21] <LedHed> on the server?
[16:22] <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:23] <alkisg> You're probably just sending the wrong image there
[16:23] <alkisg> grep filename /etc/ltsp/dhcpd.conf
[16:24] <LedHed> I use a windows DHCP server,  but I updated it to reflect ltsp/fat-i386/pxelinux0
[16:24] <LedHed> pxelinux.0
[16:25] <alkisg> OK, so, grep vmlinuz /var/lib/tftpboot/ltsp/fat-i386/pxelinux.cfg/default
[16:25] <LedHed> kernel vmlinuz
[16:26] <alkisg> sorry, my bad. grep append /var/lib/tftpboot/ltsp/fat-i386/pxelinux.cfg/default
[16:27] <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:28] <alkisg> Hmmm...
[16:28] <alkisg> And, sudo chroot /opt/ltsp/fat-i386 dpkg -l openssh-server
[16:29] <LedHed> its listed
[16:30] <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:35] <LedHed> claims its installed,  but I cant find it
[16:36] <LedHed> nor can I find my scripts.
[16:37] <alkisg> dpkg -L openssh-server shows you the files
[16:38] <LedHed> lol.  I missed the capital
[16:38] <LedHed> did -l
[16:39] <LedHed> wow
[16:40] <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:41] <LedHed> dpkg -L openssh-server on the fatclient says not installed.
[16:42] <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:43] <LedHed> dpkg -l openssh-server returns  Name: openssh-server,  Version: <none>
[16:44] <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:45] <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:46] <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:47] <LedHed> k
[16:49] <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:50] <LedHed> maybe I updated the image wrong.
[16:50] <LedHed> alkisg, ltsp-update-image -a fat-i386
[16:51] <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:52] <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:53] <alkisg> (I mean, by reading the code, it shouldn't be doing that)
[16:57] <LedHed> it didnt say that specificaly, but I remember readign something that made me thing that it completed corectly.
[17:03] <LedHed> alkisg, do fat clients auth against the server or the local passwd file?
[17:04] <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:05] <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:06] <LedHed> I want a desktop with a link to our Webmail and a link to tn5250.
[17:07] <LedHed> should be identical for all the nettops
[17:07] <LedHed> I only need 1 user account which should autologin
[17:08] <alkisg> Why were you installing ssh?
[17:08] <LedHed> so that I can remote to the nettops and reboot them if need be
[17:09] <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:10] <LedHed> the other thing is that the less dependent on the server the nettops are the better,
[17:11] <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:12] <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:13] <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:14] <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:15] <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:17] <LedHed> how are the /home dirs mounted on fat clients, NFS?
[17:18] <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:19] <alkisg> I'm using nfs because evolution doesn't run with sshfs, and I don't really care about the security implications
[17:20] <LedHed> I havent created a lts.conf for my fat clients yet.
[17:21] <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:22] <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:23] <LedHed> would be nice if LTSP supported building standalone images.
[17:24] <LedHed> meaning that the client could stan on its own.
[17:24] <alkisg> You mean without authenticating on the server?
[17:25] <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:29] <alkisg> (nbd server) - so where's the difference?
[17:29] <LedHed> no nbd,  entire image is loaded into ram
[17:30] <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:31] <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:32] <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:33] <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:34] <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:35] <alkisg> E.g. 30 seconds for sending a cd to one client => 13 * 30 seconds for 13 clients
[17:36] <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:37] <LedHed> my nettops are scattered over 1 sq mile (2.6 sq km)
[17:38] <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:40] <alkisg> How much ram do they have?
[17:41] <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:42] <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:43] <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:44] <alkisg> moment, phone...
[17:45] <LedHed> sure
[18:12] <alkisg> LedHed: still around?
[18:15] <LedHed> alkisg, back
[18:17] <alkisg> LedHed: I'm talking to you on a private window...