[OpenAFS] new infrastructure-afs home and backup questions
Wed, 11 May 2005 16:00:56 +0200
Chris Huebsch schrieb:
> On Wed, 11 May 2005, Klaas Hagemann wrote:
>> I would recommend to leave the user-home on the local file system and
>> to link all the very important directories into it after login. We
>> suffered under performance-problems, because some applications do
>> save temporary files under users home-directory. With this
>> symlink-solution, you can decide for every application where to store
>> its files and keep afs-volumes smaller.
> I guess, your users do not move around, but use the same computer every
> day. Do they remote-login into other computers?
No, they moved around and where able to move around. But their rights
were very restricted, standard-desktop, standard-icons,
standard-applications. We had complete home-directories in afs, but i
wish we had customised local home-directories. It would have improved
speed and stability.
> Do you create their homes dynamically (via pam_creteuserdir or something
> like that)?
We wrote our own pam-module, which executes some shell-skripts for doing
all these stuff....
>> Another point is, that many login-managers (like kdm or gdm) require
>> access to the users-home directory, for which no ticket is available
>> at this point.
> Really? I think a correct PAM-configuration does handle that.
> I know 3 different installation (2 with AFS, 1 with pam_createuserdir),
> which work with <any>DM.
We tested kdm and gdm. Ok, we did not play around with special
configurations, but they all wanted to access users homedir for looking
the last used window mananger. And that was the point it was failing.
>> For the location of the home-directories i implementet rules where
>> this directories are mountet, eg:
>> /afs/cell.name/usr/<first letter of login-name>/login-name
>> If you have lots of users, you can devide them into more
>> subdirectories. Then you can find this directories script-based and
>> symlink them under /home/
> Yes. That is recommended. But perhaps not usr, but home (i have the
> impression, that binaries are in usr-directories).
>> 1. user backup-volumes and mount them seperately for the user. So
>> every user can access his backup under a subdirectory.
>> A backup-volume is a logical snapshot of a volume, which needs only
>> very little space on the file-system. You can mount this volume with
>> fs mkmount <volumename>.backup anywehre in afs-space.
> Only if the content of the volume does not change too much. If the user
> changes all files during 2 vos-backups, the backup-clones need the same
> space as the rw-original.
Ok, but if you have lots of users and do the vos backup every day, you
should only need one quarter (?) more disk space.
> The backups need to be recreated on a regular basis!
>> A backup-volumes does not cover hardware-failures...
> That is true!
>> 2. I did the backup with vos dump and saved the dump-files on a
>> third-party backup-system. Here you have many possibilities to
>> restore older configurations. Read-Only Clones are not useful,
>> because the client will access read-only clones by default and so the
>> home-directory will not work.
> Of course they are. You have to mount the rw-originals with "fs mkmount
> $HOME <volume> -rw" in order to reach them via $HOME. The ro-clones can
> be used as an additional backup. (And this even on an other fileserver!)
Ok, that is another way to do this.