|
cron Job
% fs listacl -path <directory>
(See the
listacl manual page for more info.)
You can't restrict access to an individual file - access permissions (ACLs) are per-directory. Any files within a particular directory have the same access constraints - which are inherited at directory creation time (but can be changed subsequently). Note that access permission to a file will change if it is moved to another directory with a different ACL.
(See the "Directory Level Access Control" section in the User Guide for more info.)
You should use "fs setacl" (which can be
abbreviated to "fs sa"). For example:
% fs setacl -dir <directory> -acl <username>:<groupname> rl
This gives permissions (read & list) for group
<groupname> to <directory> (or "."
for current working directory). Note this command is NOT recursive and only sets permissions for the directory specified.
To set the permissions recursively so that subdirectories will also inherit the ACL use the "fsr" command.
% fsr setacl -dir <directory> -acl <username>:<groupname> rl
(See the setacl manual page for more info.)
Directory permissions are:
File permissions are:
(See the "AFS ACL Permissions" section in the User Guide for more info.)
Yes, but they don't behave in quite the same way. Mode bits on directories are ignored, and only the user set of mode bits are used for files - these can be used to grant or deny read and/or write access to everyone. Note that this only applies to files in AFS filespace.
(See the "How AFS Uses the UNIX Mode Bits" section in the User Guide for more info.)
% pts creategroup -name <myusername>:<groupname>
% pts adduser -user <username(s)> -group <groupname>
This creates a group <groupname>, and adds
<username(s)> to it. (Note that a group can
contain users and/or machines.) Also note that we
synchronise our existing Unix groups in to AFS but with a
"inf:" prefix, eg staff becomes inf:staff.
CAUTION: After being added as a group member, a currently authenticated user must reauthenticate (for example, by issuing the klog command) to obtain permissions granted to the group on an access control list (ACL).
(See the creategroup and the adduser manual pages for more info.)
Note that short term jobs (within the lifetime of
normal credentials - currently 18 hours) will just
work. Though you probably want to renc just
before running that job to make sure you get the full 18
hours, not what's left of the original 18 hours when you last
logged in.
For medium term jobs (more than 18 hours, and less
than 28 days), use krenew (see the man page for
more info). Some user accounts do not automatically have the permissions
enabled to run medium term jobs. If you find krenew does not work, please contact us
via the Support Form. You can then set up longer running jobs as follows:
Get credentials into a seperate credentials cache by doing:
export KRB5CCNAME=/tmp/mykerbcred
You can substitute a different filename in /tmp if you wish!
You then need to run kinit as follows:
kinit -r28day
Run the job with 'krenew'. See krenew manpage for more details.
krenew -k /tmp/mykerbcred -t <jobname>
For long term jobs (greater than 28 days), additional
admin is required - this ability will need to be requested via
the Support Form.
NEW for April 2012
There is now a wrapper script called longjob to simplify the above commandsTo be able to serve files (web pages) to web browsers, the web server daemon (apache) needs to be able to read the file it is going to serve. In NFS this typically meant making sure that the "other" user had read permissions on the necessary files (and execute permission on directories). In AFS you need to make sure the "system:afswebservers" user has similar access (assuming that the pages are served by our groups.inf web server). If the files are being served by another web, eg perhaps a self-managed one, then the files would need to be world readable "system:anyuser", but it would be better to enquire about getting an AFS identity for that other web server.
For example:
fs setacl ~ system:afswebservers l
fs setacl ~/public_html system:afswebservers rl
If your "public_html" directory contained sub-directories that
should also be accessible by apache, then you need to give
"system:afswebservers" rl access. See this
document for more details.
If your query about AFS and web pages relates to "public_html" type directories, then really you should be using the homepages.inf service. We can setup redirections from legacy dai|dcs|cogsci ~user URLs to homepages.inf.
A web server that is not AFS-aware can't access pages inside an AFS home directory - but if the ACLs on a user's home & public_html directories were sufficiently lax, then the AFS-unaware web server could read the required files (because everyone could).
Permissions (ACLs) would need to be set to allow anyone to lookup (list) contents - but not (necessarily) be able to read them. Anyone could then get a list of filenames, but shouldn't (necessarily) be able to see contents. Permissions (ACLs) would also need to be set on the public_html directory (and any directories below it) to allow anyone to lookup (list) and read contents (it is PUBLIC_html, after all). This would be sufficient to fix the problem. ACL permissions (similar to those above) can be set with:
fs setacl ~ system:anyuser l
fs setacl ~/public_html system:anyuser rl
Be aware that the "system:anyuser" permissions apply to
anyone, anywhere in the world.
Preferred alternatives would be to move these web pages to /public/homepages/<user>/web, or to somewhere below /group/project and have them available via <http://groups.inf.ed.ac.uk>. In either case, the original URL could - as mentioned - be redirected to the new location so that backward-compatibility would be preserved.
cron Job
You MUST add "HOME=/tmp;" as the first part of
your cron job to stop the local cron daemon trying to access
your AFS home directory (which will fail if your AFS tokens
have expired, or cron is not running as you). This can be
added to the cron entry (as listed by "crontab
-l"), and appear something like:
1 * * * * HOME=/tmp; <cron command>
or alternatively you can add:
HOME=/tmp
as a separate line at the top of your crontab
file to avoid having to incorporate it into every
crontab entry.
Note also that you shouldn't need to add
"HOME=/tmp" to your script, since it is
only cron that's affected - by default, our version of cron
tries to look for configuration settings in your home
directory - more accurately, the value of $HOME - and if it
can't read that location (which it won't be able to if it's
on AFS and restricted by ACLs) it will fail. Setting
"HOME=/tmp" for the environment in which cron
runs should prevent it trying to look in your AFS home
directory. Setting this in/for any scripts is a separate
issue, which may or may not be appropriate.
Note that this will only work for non-AFS filespace. Any cron jobs that access AFS filespace will need an alternative mechanism.
Though technically secure shell public keys can be made to work, it is unlikely that it will grant you the password-less access you are looking for. We do not recommend you persist with this, and indeed ssh public keys are no longer supported, and at some point we may disable the function.
Using a kerberised ssh on your client machine is more likely to achieve what you are looking for. If you really do want to use ssh public key access, then please see the SSH Public Keys document.
Your X11 fonts directory has to be read-accessible to system:anyuser, since the X server is running as root, not as you.
Unison is a tool used to keep copies of a local and remote
file area in synchronisation. Normally people will use
ssh (Secure Shell) to establish the link to the
remote file system (their home directory) so that files can be
compared and transferred as necessary. This will just continue
to work if you are providing your DICE password when
connecting via ssh.
However some people use unison along with ssh
public keys (see above) to remove the need to enter a password
when synchronising. As stated in the ssh public key section,
this will not work, as without a password the ssh daemon will
not obtain the necessary kerberos and AFS tokens to be able to
access their AFS home directory. There are 3 solutions if this
is how you use Unison:
kinit
uun@INF.ED.AC.UK" once a day on your local machine,
and then ssh-ing to DICE machines will work without
prompting for a password.
unison to
synchronise between the AFS path and your local files,
rather than via ssh.
For details about setting up kerberos and AFS on your machine, see:
You can have around 64,000 files (directory entries) in an AFS directory if the filenames are all less than 16 characters long - if there are filenames with 16 characters or more, then the maximum number of files decreases.
There are 64,000 filename "slots" per directory. Each file of less than 16 characters takes 1 slot, and additional slots are required to store entries with names that are longer than 15 characters. The longer a filename is, the more slots it needs, and hence the number of files the directory can hold is reduced.
Once a filename reaches 16 characters, another slot is required - and each such slot allows an additional 32 characters of filename, so two slots allow filenames of up to 48 characters (but if all filenames in a directory were 16-48 characters long, the maximum number of files that the directory could contain would be halved).
You can give external collaborators with iFriend identities access to your AFS files via ACLs. Then providing your collaborator has kerberos and AFS, they will be able to access your files appropriately. See iFriend AFS Access for details.
|
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk Please contact our webadmin with any comments or corrections. Logging and Cookies Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh |
