[OpenAFS] Nomenclature Follow-Up
Thomas Kula
kula@tproa.net
Wed, 2 Sep 2009 14:11:35 -0400
On Mon, Aug 10, 2009 at 06:14:27AM -0700, beelz wrote:
>
>
> Well, I got my AFS server up and running and have a better understanding of
> the hierarchy and mount points so please disregard my previous question. I
> still don't have LDAP configured but so far I've been able to connect and
> move files with a few different client OSs. Very satisfying after a
> considerable amount of time spent on this project.
>
> I've decided to keep my volumes at approximately 100 GB. I do not have
> multiple servers and I would appreciate any suggestions people have as to
> sizing volumes, and whether there have been any problems with large (like,
> around 100 GB) ones. Also, what is a good way to create a volume that will
> be shared by multiple users? There's a lot of information about creating
> new home directories, but what about those not associated with specific
> users?
>
Here at UMich we will give volumes out to 100GB or so. Past that they
currently are just to unwieldy to move about and to backup smoothly
the way we do things. Test that in your environment, though. We like
being able to move volumes around and have them backed up, and the
way we do things 100GB is the upper limit (currently) for what we
feel confortable with.
As for shared volumes, we create things called group volumes. I've
also seen places call them project volumes, or something similar.
When we create a group volume for a project, let's call it `someproject',
we do the following:
- Create a volume called g.someproject (g. for `group', this is pure
convention).
- Mount that volume at /afs/umich.edu/group/s/someproject (again, pure
convention).
- Create a pts group `someproject' that owns itself.
- Create a pts group `someproject:members', owned by someproject.
- Give `someproject' admin rights to
/afs/umich.edu/group/s/someproject and give
`someproject:members' write rights to the same directory.
- Add appropriate people to the pts groups.
I've also been tempted to create `someproject:guests' and give
them read-only access. Again, all of this is pure convention, but
it seems to work well.
--
Thomas L. Kula | kula@tproa.net | http://kula.tproa.net/