Greetings,

2009/4/27 Peter Van Biesen <[email protected]>:
> 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.
>

You could consider having a boot option that performed a test for
update with custom boot param. This is how I do vmware desktop
sessions where the snapshots are stored on the client and the master
big chunks are stored on the server. I just do a simple test for a
variable in a release file and if the master on network does not match
the client I perform an update.

> 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.
>

Perhaps you could run a base image in persistence and just inject a
small amount of settings. Here is the link for persistence in the
manual:

http://live.debian.net/manual/html/persistence.html

If the boot param hook= was operational it to could be leveraged to
provide a solution as well. hook= has a bug report filed about it
being broken. But I believe that it would be the best option to custom
script a solution that does what you want.

Let us know what you find out for your solution.

Thanks.

> 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
>> <[email protected]> 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: [email protected]
>> > 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 [email protected]
>> > with a subject of "unsubscribe". Trouble? Contact 
>> > [email protected]
>> >
>> >
>>
>>
>
>
>
> --
> Peter Van Biesen
> Sysadmin VAPH
>
> tel: +32 (0) 2 225 85 70
> fax: +32 (0) 2 225 85 88
> e-mail: [email protected]
> 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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]

Reply via email to