When replacing a client there are several things that have to be taken into 

account:

In the case of a thick client, personalization data has to be transferred from 

the old replaced client or restored from backup.

Configuration files need to be copied over.

Care has to be taken that using the old name for the system will not lead to 

extra unnecessary problems.

When using a new name on a replacement, make sure that the old name is 

removed from server side configurations.

Important:

 In the case of winbind being used, take care to copy the winbind 

idmap file from the replaced client. Since this keeps track of domain user to 

uid/gid matching this is very important for file ownership.

On Red Hat systems the winbind idmap file is:

/var/cache/samba/winbindd_idmap.tdb

On Novell/SuSE systems the winbind idmap file is:

/var/lib/samba/winbindd_idmap.tdb

4.5.5  Backup of clients

Backup of the client is only important if there is changing data locally on the 

client. If all changing data is kept on a reliably backed up server, then replacing a 

broken client just means resetting with a clean initial client image or install.

If the client contains important application data, this has to be backed up. This is 

generally implemented in a client server configuration where a client of the 

backup software is installed on the client that sends its data to the backup server. 

The backup server will then write the data to offline storage (tape). One such 

product that supports Linux clients for this purpose is IBM Tivoli Storage 

Manager.

However, as stated before, some configuration and cache files are important and 

do contain changing data even if no applications write data to local file systems. 

For example, end users can be allowed to make some changes to their desktop. 

Restoring these changes after a replacement of the client can be seen as a 

service to the end user. Otherwise, the end user might have to spend several 

hours getting it just right again.

We could make sure all the necessary files are kept by making an inventory of all 

these needed files during early migration or proof of concept and implementing a 

 Chapter 4. Technical planning 

71