welcome: please sign in

The following 554 words could not be found in the dictionary of 7 words (including 7 LocalSpellingWords) and are highlighted below:
about   above   access   Access   acronyms   Actual   actual   addition   administrators   affect   afs   after   afterwards   aklog   all   All   almost   also   an   and   another   any   Anyone   anyuser   apply   are   argument   arguments   as   As   assigned   at   At   authenticate   authenticating   Authentication   automates   automatically   aware   away   background   bash   basically   Be   be   because   before   beforehand   beginning   best   better   bin   blob   bugzilla   but   by   call   called   calling   can   cannot   case   Category   caution   challenging   change   chapter   check   children   choice   clarify   clean   Clinton   code   combination   come   command   commands   Commands   complete   completely   concept   concepts   configured   configuring   contain   contained   Contents   contrast   control   controlled   Coop   correct   course   Create   create   created   Creating   creating   cron   Cron   crontab   curious   current   daemon   daemons   data   database   Date   defines   delayed   deliver   describes   detail   determined   different   Directories   directories   Directory   directory   discourages   discover   do   documentation   does   doing   each   Each   easily   Ebadi   Edit   effect   either   enabling   encouraged   Ensure   enter   entry   equivalent   escape   essence   Essential   etc   even   events   ex   example   Example   Examples   examples   except   exec   executables   Execute   execute   execution   existing   expanded   expanding   expiring   explained   exported   exporting   external   extra   facility   fact   fail   fg   fi   file   files   find   first   Folks   follow   following   Following   For   for   foreground   free   freedom   from   fs   fsr   ftp   further   general   git   give   gives   granting   Group   Gs   has   have   Have   having   hb   hcoop   helpful   here   Here   hinted   holding   home   how   However   http   hypertext   id   identities   identity   if   If   immediately   impersonate   implies   importance   impossible   in   In   include   influence   influencing   information   ing   inherit   instead   instructions   interactive   Interactive   interch   interchange   into   introduce   Invoke   is   Issues   it   It   its   job   jobs   just   Justification   K5start   k5start   keep   Kerberos   key   keys   keytab   keytabs   kinit   klist   know   la   leads   least   lies   line   list   List   lists   local   located   log   Login   login   long   look   Ls   machine   machines   mail   Maildir   major   make   Make   makes   Manual   manual   manually   may   means   Member   members   mention   might   Mire   misc   misleading   mkdir   model   more   moved   must   name   named   need   needed   Needs   needs   net   never   new   no   Non   Normal   not   Note   noticing   numerical   obtain   obtained   Obtaining   obtaining   Of   of   off   on   Once   one   only   openafs   or   order   other   otherwise   Our   Outright   outside   over   Overview   own   ownership   page   pages   pagless   Pagsh   pagsh   parent   part   Part   Particular   password   performed   periodic   periodically   permission   permissions   place   plain   Please   portal   possible   preference   present   previous   principal   Privileges   privileges   probably   process   Process   Processes   processes   profile   protected   provide   provided   providing   purposes   Quick   quickly   random   rather   read   readable   reason   reboot   Recipes   recursively   refreshing   regarding   relevant   rely   remote   replace   Replace   residing   restricting   revision   right   rights   rl   rlidwka   root   rules   Run   run   running   Running   runs   sa   same   saved   scope   script   Script   scripts   Scripts   second   secret   section   security   self   separate   series   service   Service   services   session   sessions   set   setting   setup   sh   shared   shebang   shell   short   should   So   so   some   Someone   space   spaces   specific   specified   ssh   start   started   starting   steps   strategies   stress   subdirectories   subdirectory   subprocesses   such   sudo   supported   sure   system   T06   Table   take   taken   tasks   tells   terminal   than   that   That   the   The   themselves   then   Then   there   Therefore   they   things   this   This   those   though   ticket   Ticket   tickets   Time   to   To   token   Token   tokens   Tokens   tree   Ts   two   type   typical   unattended   Unattended   under   unique   Unix   Unnecessary   unrelated   untranslated   up   use   used   Used   useful   user   username   users   Using   using   usr   usually   valid   Verify   very   viewed   volumes   want   way   Ways   we   well   When   when   Where   where   which   While   while   who   why   wiki   will   wish   With   with   Within   within   Without   without   work   Work   would   wrapper   write   You   you   Your   your   yourself  

Clear message
Edit

MemberManual / RunningUnattendedCommands

This is the chapter of the MemberManual that describes how to periodically run unattended commands, either as long-running processes (daemons) or as short periodic tasks from cron or at.

This manual page needs major revision. Issues include

  • Outright misleading information regarding PAGs (pagsh is almost never helpful!)

  • Unnecessary detail. Folks who want to know about TGTs and PAGs can read the relevant external documentation. At least use hypertext to clarify concepts instead of just expanding acronyms.
  • Essential information is on other pages: e.g. RunningUnattendedCommandsWithoutRunInPagsh.

    • run-in-pagsh might work, but is at best not encouraged or supported so it should be moved off to another page. Justification: using k5start is no more challenging than configuring run-in-pagsh.

    • Anyone running a daemon probably needs to know about @reboot cron jobs without having to self-discover MemberManual/UsingCron

    • It does not stress the importance of the -t argument to k5start

Quick Example

In order to execute a long-running or unattended command:

  1. Ensure that any directories needed to read/write have the right permission for the ${USER}.daemon (otherwise file access will start to fail)
  2. Execute the command with k5start to keep the process authenticating while it runs

For the first part, replace "DIRECTORY" with the directory that the process will need to read or write from:

fs sa DIRECTORY ${USER}.daemon read
fs sa DIRECTORY ${USER}.daemon write

For the second part, replace "COMMANDHERE" with the command you wish to run:

k5start -t -U -f /etc/keytabs/user.daemon/${USER} -- COMMANDHERE

Overview

All users' home directories in HCoop setup are located on AFS volumes. The use of AFS implies the use of Kerberos. In essence, your Kerberos (and AFS) "identity" is completely unrelated to your Unix username. While you automatically obtain Kerberos and AFS identity (so-called "tokens") when you log-in to HCoop machines over ssh, be aware that Unix and Kerberos/AFS login are two separate things. That's why the scripts you run unattended cannot write (or read) files because, without extra steps taken, they do not have any useful identity or access privileges to volumes where all the relevant data is residing.

So, in general, when you want to access AFS space (that means any file in your home directory), you first need to authenticate with Kerberos to obtain a valid TGT ("Ticket-granting ticket"). As the name implies, the TG Ticket is then used in automatically obtaining further tickets for access to your files (in AFS) or to specific services (such as to ssh, ftp, bugzilla or members portal).

The AFS "Login" Process

Following the above, here's the complete, "expanded" series of events that take place in a typical remote shell session:

  1. You log in by providing your Unix username and password
  2. You authenticate to Kerberos and obtain the TGT by running kinit. (Verify with klist -5).

  3. You use the TGT to obtain AFS "token" by running aklog. (Verify with tokens).

  4. You access files in the AFS space. Actual access privileges are determined by the combination of the token you are holding and the access control lists (ACLs) set on a directory. (List access rules with fs la DIRECTORY).

Interactive SSH process

Our SSH service is configured in such a way that your password is, in fact, the secret Kerberos key. So when you log in over SSH, steps 1 to 3 above are performed for you automatically and you can use AFS right away.

Non-interactive (Unattended) Processes

When a script is started in your Unix name by Cron, At or any other delayed/controlled-execution facility, no Kerberos ticket (or AFS token) is obtained automatically. Part of the reason lies in the fact that Kerberos' security model makes it almost impossible - even for root users - to authenticate as yourself if the password is not provided. (Where in Unix we would use "sudo" to easily impersonate any user, here it is impossible).

So the way to obtain Kerberos ticket and AFS token from unattended processes will be explained.

Ways of Obtaining AFS Tokens from Unattended Scripts

As hinted before, a password must be present to obtain any Kerberos identity. However, that password may come either from an interactive terminal, or from a file. (A file that is residing outside of the AFS space, of course!).

Kerberos discourages exporting of actual password keys into files, so at HCoop we create two Kerberos "identities" for each user: one named USER (your Unix username) for interactive sessions, and the other named USER.daemon for unattended sessions.

  1. Your USER principal has the password saved only in the protected Kerberos database and it is not possible to obtain its ticket without providing the password.
  2. Your USER.daemon principal has a very long random secret assigned to it and its key exported to a file named /etc/keytabs/user.daemon/USER. Your scripts will use the file /etc/keytabs/user.daemon/USER as a password in obtaining Kerberos/AFS identity "USER.daemon". In fact, all shared HCoop daemons also use that file to obtain permissions to write into your home directory (such as to deliver mail). Of course, Unix permissions and ownership on the keytab file are such that no other user can read your keytab file.

Token "scope"

Kerberos and AFS introduce a concept called Process Authentication Group ("PAG").

To "enter" a PAG, you start shell named /usr/bin/pagsh.openafs. With SSH, even though you find yourself in the shell of preference, a PAG is created for you just beforehand. (Verify by running id and noticing one numerical, untranslated entry such as 1105575254). Once within a PAG, there is basically no way to "escape" from it, so in effect, it is not possible to affect Kerberos/AFS identity of any of your other running processes by SSH-ing into a machine and doing kinit as a different principal or obtaining different AFS tokens - they only apply to your current shell and its subprocesses.

In contrast, when unattended processes are started in your name, they are free of a PAG so you have the freedom of choice - influencing all "pagless" processes running under your Unix username, or starting pagsh manually and restricting influence to the current process and its children.

This quickly leads to two possible strategies:

  1. Have one pagless process running which is refreshing USER.daemon token periodically (to keep it from expiring), and also run all scripts pagless - they will automatically find themselves to have that USER.daemon token.
  2. Invoke all your scripts with shell /usr/bin/pagsh.openafs (can be in the #! "shebang" line) and obtain AFS token immediately after. Then rely on all subprocesses started from that script to inherit the obtained identity.

Unattended Access Privileges

In any case, using file /etc/keytabs/user.daemon/USER to obtain your Kerberos/AFS identity will "log you in" into AFS as USER.daemon, not USER. Therefore, make sure that all directories you want to access from unattended scripts have read or write permission for USER.daemon in addition to USER.

For example, here's how the permissions look for your ~/Maildir/ which gives USER.daemon write access:

$ fs la ~/Maildir/

Access list for /afs/hcoop.net/user/U/US/USER/Maildir/ is
Normal rights:
  system:administrators rlidwka
  USER rlidwka
  USER.daemon rlidwka

To give read permission on a directory, use

fs sa DIRECTORY USER.daemon read

To give write permission on a directory, use

fs sa DIRECTORY USER.daemon write

To recursively give write permission for all subdirectories,

find DIRECTORY -type d -exec fs sa {} ${USER}.daemon write \;

Note that we mention directory permissions only - in AFS, there are no file permissions. Directory permissions apply to all contained files, except subdirectories. Each subdirectory defines its own permissions. When new subdirectories are created, they inherit the ACL list from the parent directory. If you want to change ACLs on an existing directory tree, just use the fsr command in place of fs, with the same arguments.

Recipes and Examples

While you can use kinit to obtain tokens, we will use k5start in all examples. K5start is equivalent or better to kinit for all purposes.

Example 1: unattended.sh

1. Create a script, ex: unattended.sh, in your ~/bin that is readable by USER.daemon.

#!/bin/sh
k5start -t -U -f /etc/keytabs/user.daemon/USER -- COMMANDHERE

(Replace USER with your username and COMMANDHERE with the command you want to run)

2. Edit your crontab to call the script as ~/bin/unattended.sh

Creating the Directories Used in Examples

Create a directory that will contain your local executables and give USER.daemon read permission to it:

$ mkdir ~/bin/
$ fs sa ~/bin USER.daemon read

Make sure your ~/.bash_profile or equivalent file has ~/bin/ at the beginning of PATH, by enabling this within ~/.bash_profile:

# set PATH so it includes user's private bin if it exists
if [ -d ~/bin ] ; then
    PATH=~/bin:"${PATH}"
fi

Create a directory that will contain PID files for all your user processes:

$ mkdir ~/.run
$ fs sa ~/.run system:anyuser rl
$ fs sa ~/.run USER.daemon write

Script to Run a Particular Service Within Pagsh

Please be sure to also check RunningUnattendedCommandsWithoutRunInPagsh.

Someone should write a better script that automates k5start and setting up an @reboot cron job instead of this -- ClintonEbadi 2013-07-13 10:11:39

A wrapper script that runs a user-specified daemon is provided on Mire as run-in-pagsh. When calling it, the first argument should be a unique name with no spaces that describes the daemon, and then provide the command line for calling that daemon afterwards. Be sure to follow the instructions in the previous section for creating a ~/.run directory with correct permissions.

Here is an example of calling this script:

run-in-pagsh interch ~/bin/interchange

If you want to run a command from cron then use the following instead. The --fg argument tells run-in-pagsh that the command will run in the foreground, rather than the background.

run-in-pagsh --fg clean-mail ~/scripts/clean-mail

For the curious, the run-in-pagsh script may be viewed here.


CategoryNeedsWork CategoryMemberManual CategoryNeedsWork

MemberManual/RunningUnattendedCommands (last edited 2023-04-05 15:42:46 by 128)