[OpenAFS] How to store homedir for Linux, Solaris, Windows, OS X win AFS?
Jose Calhariz
jose.calhariz@tagus.ist.utl.pt
Mon, 10 Apr 2006 18:39:25 +0100
--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Apr 09, 2006 at 09:43:46PM +0200, Sergio Gelato wrote:
> [Copying you since I'm not sure you're subscribed to the list.]
>=20
> * Jose Calhariz [2006-04-08 20:30:50 +0100]:
> > I would like hear experiences about the best way to store the homedir
> > for all OS inside the volume of the user, and others special dirs like
> > web, mail, backups. I am searching in Google, but I didn't find
> > anything interesting until now.
> >=20
> > In my campus the solution was to create individuals directories inside
> > the volume: linux, mac, sun, win, web, public, private, old_files,
> > Maildir. =20
>=20
> And $HOME points to the linux/ subdirectory on Linux, to the mac/
> subdirectory on OS X, etc.? While this may help with some applications
> that store platform-specific pathnames in their dot-files (e.g., the
> Solaris and Linux builds of GNOME may have different filesystem layouts)
> I'm not sure the duplication is desirable for the vast majority of
> applications. The average Firefox user may be upset to find that his
> collection of bookmarks is not shared across platforms.
In the campus where this system is working, for more than 3 years,
they don't complain about it. Because is the only place in the
University where the homedir are stored in a network filesystem. I
wasn't working here when this system was designed, but I have been
told that GNOME in Solaris was incompatible with GNOME in Linux in the
same homedir. That's way there is 4 homedirs. I don't know if in the
present GNOME in Fedora, Debian, Gentoo, Mandrive, Solaris play nice
between them. Anyone have experience with it?
>=20
> This is by no means an AFS-specific problem; you're going to face this
> issue with any kind of network share. I think most people would go for
> using the same home directory everywhere; among other things, it
> saves one from having to massage the "home directory" information from=20
> LDAP/NIS/whatever in a different way on each platform.
The LDAP have 4 fields with the diferents homedirs, no problem with it
in the campus, where I control the LDAP, AFS and the clients. A big
problem in the University where exists much more labs and OSs, and the
labs are managed outside of the administration of AFS/LDAP.
>=20
> AFS has an advantage over some other network filesystems: a pathname
> that contains @sys as a component can point to different directories
> on different platforms. So if you need to keep, say, your=20
> $HOME/.mozilla/plugins/ directories system-specific you can just=20
> "ln -s @sys/plugins $HOME/.mozilla/" (and create the required
> subdirectories).
I have think about it, but I would like to know if anyone is using it,
and how are using it for anything diferent that bin dirs.
>=20
> > But the University is implementing a new AFS cell, and is considering
> > a different design. Give full permissions to the root of the user's
> > volume and place inside the special directories.
>=20
> There is an AFS-specific difference here: the owner of the root of a
> volume can always obtain full access to directories in the volume.
> This might save you a few support calls (if the users involved have
> at least half a clue, which is by no means guaranteed).
I believe that AFS volumes don't have ownership, authorization is only
regulated by ACLs and the three bits of read, write and execute.
> =20
> > I am asking for your's experience as a way to judge the pros and the
> > cons of the various approaches.
> >=20
> > Jose Calhariz
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20
Jose Calhariz
--=20
A alegria esta na luta, na tentativa, no sofrimento=20
envolvido. Nao na vitoria propriamente dita.
-- Mahatma Gandhi=20
--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEOphNVNiv5i0lZUgRAo3kAKDRFbyRdfLf1dPPcLATLcUu/lerRQCdG0Fu
KZMmXfcmiVzrcXTSI4ucojk=
=oYRs
-----END PGP SIGNATURE-----
--T4sUOijqQbZv57TR--