Diskless workstations

Daniel J Walsh dwalsh at redhat.com
Thu Jul 24 17:12:10 UTC 2003


Stephen Smoogen wrote:

>Is it is simple to rename .snapshot to soemthing else. The NFS server is
>a netapp :)
>
Not really sure what you are asking.  /.snapshot is a directory on the 
client that mounts a client specific directory on the server.  The 
server directories could be on a netapp server, but you would then have 
the problem of upgrading over NFS.  One other solution would be to have 
a Diskfull machine that you could upgrade and the rsync to the netapp 
server.

>
>On Thu, 2003-07-24 at 10:11, Daniel J Walsh wrote:
>  
>
>>This diskless is a single /root directory containing all files and a 
>>/.snapshot directory containing
>>files that are specific to the client. (A very small subset).  It then 
>>uses mount -o bind to mount the
>>snapshot files over the /root files on the client.  You need to do a 
>>chroot on the server to up2date it
>>or rpm install it.    It will not support older versions of RH.  It 
>>should work on RH9 or greater and
>>it might work on RH8.
>>
>>Dan
>>
>>
>>Stephen Smoogen wrote:
>>
>>    
>>
>>>Thanks I will try to look at this next week. What I am trying to figure
>>>out is the best/fastest way to set up new diskless clients that have
>>>'full' installs.
>>>
>>>Currently we have two systems here. 
>>>
>>>The first is  where /usr and some other directories are stored on the
>>>master tree and then the few remaining (/lib /var /etc /initrd etc) are
>>>seperate per machine. This is very fast to bring up a new machine
>>>because the date to be copied is small (20-40 megs on average). However
>>>it is a pain in the ass to update as all the clients have to be rebuilt
>>>after errata that change /etc, /lib etc occur.
>>>
>>>The second is much more disk intensive but easier to maintain. In this
>>>version each client gets a complete install in an NFS tree. This allows
>>>for a lot of customization per client (some can run 7.1 while others run
>>>9.0). Maintenance is much easier because RPM can be run on each of the
>>>trees seperately. However installs are SLOW because they are either
>>>server side using a chroot anaconda (which I havent gotten working
>>>seamlessly) or the client is doing all the writes via NFS.
>>>
>>>
>>>On Thu, 2003-07-24 at 07:23, Daniel J Walsh wrote:
>>> 
>>>
>>>      
>>>
>>>>I have been working on a package called redhat-config-netboot that 
>>>>allows you to setup diskless environments
>>>>using NFS, as well as network installations.  It is based somewhat off 
>>>>of LTSB.  It is basically a series of scripts and python code that sets 
>>>>up a PXE boot environment and an diskless NFS partition.  
>>>>
>>>>ftp://people.redhat.com/dwalsh/netboot
>>>>
>>>>Comments welcome.
>>>>
>>>>Dan
>>>>
>>>>Chuck Wolber wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>No we do everything via NFS at the moment. Using a big ramdisk would cut
>>>>>>into why all the machines have so much memory and CPU's. Basically the
>>>>>>idea is that all CPU cycles are local and all data is foreign. The
>>>>>>approach to this seems to follow either SGI or Sun ways of doing
>>>>>>diskless clients. I like the Sun way of doing it (with each client
>>>>>>getting its own tree) versus the SGI where most is common with the
>>>>>>server and clients need a rebuild if server code changes.
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>Can a user move to another workstation and resume their session? I've seen 
>>>>>this done with RFID tags that automatically detach your session if you 
>>>>>move away from the terminal and re-attach you when you move closer.
>>>>>
>>>>>-Chuck
>>>>>
>>>>>
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>Rhl-devel-list mailing list
>>>>Rhl-devel-list at redhat.com
>>>>http://www.redhat.com/mailman/listinfo/rhl-devel-list
>>>>   
>>>>
>>>>        
>>>>
>>
>>
>>--
>>Rhl-devel-list mailing list
>>Rhl-devel-list at redhat.com
>>http://www.redhat.com/mailman/listinfo/rhl-devel-list
>>    
>>







More information about the fedora-devel-list mailing list