From grass-lists-owner@max.cecer.army.mil Thu Nov 19 15:26:06 1992
We've been trying to get grass 4.0 running on a Sun4 server, with several
Sparcs as terminals. The basic program is running, but there are some
problems. Can anyone offer some advice?We are having some permission problems. I have a data set in my home
directory. Others members of my group have been unable to access those
files with grass, even though they have full UNIX permission and I turned
on the grass permission for that data set.--
Michael Zajac (Dept of Landscape Architecture)
University of Manitoba, Winnipeg, MB R3T 2N2
phone: (204) 474 6449
[sorry folks, this got a bit long - I would have sent email directly
to the sender, but I want to see if anyone else has comments on this
topic. I am sure others have come up with different ways to manage
multiple user access to a database, and I would like to hear about
them.]
I'll take a shot at the permission question. It seems that a user
can't use a mapset as their $MAPSET unless they *own* it.
Group or world permissions won't do it.
One option is to have a GRASS login account that all can use, and
individuals can have separate mapsets in that account.
From what I can tell, this is how GRASS was meant to be used
(at least originally)
We don't do this, since we have too many users of our GRASS
installation, especially when we are using it for classes. In
addition, our network's admins frown upon wide-open access to
accounts or files.
Therefore, our method is to have a map database for the installation
we call 'permanent' that is readable by all. In the user's account,
we create a data directory. Under this are directories for each
permanent mapset they want access to. (i.e. world, spearfish, usa,
whatever). Now, in those directories we create a symbolic link
(with the 'ln -s' command) to the appropriate directory in the
grass account. then the user declares their mapset to be
'workspace' or some other arbitrary name. With the g.mapsets command,
one can set up a search path of mapsets so that both 'permanent'
and 'workspace' will be searched for database elements.
OK, let's say your main grass database is /usr/grass/data,
and you have a map database of the world, so in /usr/grass/data
you create world/permanent directories. In permanent are
are all the grass data dirs, like cell, dig, colr, etc.
Now, let's say your user's home directory is
/home/zajac, and he has created a /home/zajac/data/world
directory, in which he did a:
ln -s /usr/grass/data/world/permanent permanent
to create a link to the main data set.
Now he runs grass, and fills in the the initial questions grass
asks like this:
LOCATION: world
MAPSET: workspace
DATABASE: /home/zajac/data
grass will look in /home/zajac/data/world and find the permanent dir
but no workspace and say the same. It will also ask if the user
wants to create a workspace mapset. Answer yes and things will be
set. The user will be able to access the maps in /usr/grass's
database, but any operation that creates a map or file will do
so in the workspace mapset, which they own. To access another
user's maps, another symbolic link can be created, and g.mapsets
can be used to put that mapset in the current search path.
---
Chris Rewerts rewerts@ecn.purdue.edu
Agricultural Engineering, Purdue University