Hi Richard, thanks for your reply. I'm calling it thin client as the image I'm building is meant only to run rdp , citrix ica or nx clients. I've tested some ready-made configurations ( eg. thinstation ) but I'd like to have more control over what it's doing. It should autodiscover if its on the internet or on the local network. That's also the reason I need the image on local storage. Plug the device in on the local network and it will automatically be updated to the latest version of the image. Of course, pxe doesn't work on the internet either so I'll need to configure grub too every time a new image is downloaded. The second reason for local storage is our remote offices. The leased line has low bandwith, so I don't want a nfs connection over that nor do I want a download of new images. The local image should remain there untill it is plugged in in our head offices' network. In fact, I want the devices to be able to run on their own if no dhcp/nfs server can be reached. Every month, someone passes by the remote offices, so just replacing all devices with other ones that have been updated and then plugging those in in the head office to update and using them for another remote office ... would be the easiest no-brain solution. So you see, nfs is not really an option. Thanks for the link, I'm downloading the iso right now. I'll see if it is useful. I'll continue reading through the debian live scripts as the documentation is rather thin. Kindest regards, Peter. On Saturday 25 April 2009 04:41:27 Richard Nelson wrote: > Greetings, > > On Fri, Apr 24, 2009 at 3:47 AM, Peter Van Biesen > <peter.vanbiesen@vaph.be> wrote: > > Hi, > > > > I'm preparing a live image for a thin client installation. The thin client has 1Gb of local storage and we have about 20 running in 'the field' at the moment. I'd like to have a way to automatically update them. I currently use a netboot and the standard nfs mount. However, when the nfs server goes down, all thin clients go down. > > Well without knowing the layout I would say make a redundant nfs > setup. I run a setup with several hundred units and I have a > proximity nfs server and a failsafe nfs server in case the proximity > fails. The user selects the boot server via pxe boot menu. You could > also have the proximity nfs also double as a dhcp. > > fwiw: I like to call netboot clients Not So Thin (NST) clients. > > > If the dhcp/tftp server goes down, the clients continue running but starting new ones failes ( this is not a problem as this affects only few clients ). > > > > What I'd like to do is > > - pxe boot > > - get kernel and initrd from tftp server > > - get the id of the latest filesystem.squashfs from a webserver > > If the id is newer than the one on local storage ( /dev/hda1 ), download it from the webserver > > If not, keep the one on local storage > > - mount and use the filesystem from local storage > > As I recall seems like http://www.ulteo.com/home/en/home?autolang=en > used to do something similar to what you describe. > > On systems I want to upgrade that use local storage I keep them in > groups in my dhcp.conf file and I move them to the new location when I > am ready. I like keeping all the images on the server and not the > clients. Also I like a plain fs type so I can just chroot in for fleet > modifications. > > ymmv: The only reason I ever looked at a local storage was for offline > clients or low bandwidth (and I always come back to usb stick for > that). So with this model I expect users who want to upgrade to plug > in to the network with pxe boot set at a higher boot priority and then > I give them a pxe boot menu with a test for update option that boots a > basic netboot with a custom rc.local designed to check versions then > upgrade if need be and then reboot. > > > > > Is this possible with the current installation or should I write my own scipts ? > > Well even in the above example you would need to craft your own > rc.local for testing what you want. So there will most likely be some > custom scripting needed. > > > > > Thanks in advance, > > > > Hope this reply helps. > > > Peter. > > -- > > Peter Van Biesen > > Sysadmin VAPH > > > > tel: +32 (0) 2 225 85 70 > > fax: +32 (0) 2 225 85 88 > > e-mail: peter.vanbiesen@vaph.be > > PGP: http://www.vaph.be/pgpkeys > > --------------------------------------------------------------------------------- > > DISCLAIMER : > > De personeelsleden van het agentschap doen hun best om in e-mails > > betrouwbare informatie te geven. Toch kan niemand rechten doen gelden op > > basis van deze inhoud. Als in de e-mail een stellingname voorkomt, is > > dat niet noodzakelijk het standpunt van het agentschap. Rechtsgeldige > > beslissingen of officiele standpunten worden alleen per brief toegestuurd. > > > > > > -- > > To UNSUBSCRIBE, email to debian-live-request@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org > > > > > > -- Peter Van Biesen Sysadmin VAPH tel: +32 (0) 2 225 85 70 fax: +32 (0) 2 225 85 88 e-mail: peter.vanbiesen@vaph.be PGP: http://www.vaph.be/pgpkeys
Attachment:
signature.asc
Description: This is a digitally signed message part.
--------------------------------------------------------------------------------- DISCLAIMER : De personeelsleden van het agentschap doen hun best om in e-mails betrouwbare informatie te geven. Toch kan niemand rechten doen gelden op basis van deze inhoud. Als in de e-mail een stellingname voorkomt, is dat niet noodzakelijk het standpunt van het agentschap. Rechtsgeldige beslissingen of officiele standpunten worden alleen per brief toegestuurd.