Creating the basis of an account for a non-human user that provides a shared service is automated through a shell script (UserManagement).
The automated process creates a kerberos principal with a random key and an afs home directory for the user. You will need to manually extract the keytab to the appropriate notes, and update any configurations to use the principle as needed.
The process of creating a service key (e.g. postgres/$host.hcoop.net) is not automated. Follow the GSSAPI documentation of the appropriate service.
1. General Service Account
TBD, general processes for generic services accounts that don't need to do things like serve websites
2. System Service Account
TBD: process for things like postgresql, ssh, ... that use a traditional MitKerberos service/$host principal to allow GSSAPI auth
3. Web Service Account
TBD: process for accounts that will run cgis, usually controlled by the hcoop user via domtool, and that can never log in
4. Obsolete Info
Some of these things may be actively misleading, proceed with caution. This is being kept around to aid in writing the improved documentation above.
here's the final procedure you should follow (for installing service "SERVICE" (mysql) on host "HOST" (deleuze)):
1. create local user SERVICE in /etc/passwd:
(usually already done by Debian postinst scripts in form of "adduser --system SERVICE". (--system ensures that the assigned ID is in range 100 < ID < 1000 .))
2. create Kerberos principal:
kadmin.local -q "addprinc -policy service -randkey SERVICE/HOST"
3. export user's keys to /etc/keytabs/SERVICE.HOST and chmod the file properly:
kadmin.local -q "ktadd -k /etc/keytabs/SERVICE.HOST SERVICE/HOST" chown SERVICE:wheel /etc/keytabs/SERVICE.HOST chmod 440 /etc/keytabs/SERVICE.HOST
4. create OpenAFS user SERVICE.HOST
(You must make sure that the UID chosen in AFS is above 1000. You can't use UIDs <1000 because those are reserved for local system's IDs, and so such uids in AFS would mess up reported Unix ownership of files).
pts cu SERVICE.HOST.hcoop.net
5. create OpenAFS group "SERVICE" if it doesn't exist, and add SERVICE.HOST to it:
pts cg SERVICE pts ad SERVICE.HOST SERVICE
6. modify service's init script in /etc/init.d/ in the following way:
- Change shell at the top of script to "#!/usr/bin/pagsh.openafs"
- Change start-stop-daemon invocation in action 'start':
start-stop-daemon --start --pidfile $PIDFILE \ -c SERVICE:SERVICE \ --exec /usr/bin/k5start -- -U -b -f /etc/keytabs/SERVICE.`hostname` \ -K 300 -t -p $PIDFILE \ <The original start command>
- Or if the service does not use start-stop-daemon itself, you still use it in
action 'start' to run k5start on a line before <The original start command> and later in 'stop' to close it:
start-stop-daemon --start --pidfile /var/run/SERVICE/k5start-SERVICE.pid \ -c SERVICE:SERVICE \ --exec /usr/bin/k5start -- -U -b -K 300 -t -p /var/run/SERVICE/k5start-SERVICE.pid \ -f /etc/keytabs/SERVICE.`hostname` sleep 2
start-stop-daemon --stop --pidfile /var/run/SERVICE/k5start-SERVICE.pid rm -f /var/run/SERVICE/k5start-SERVICE.pid
7. You give permissions in AFS space to group "SERVICE", or to user "SERVICE.HOST" if specific instance is important. (Mostly, you just add permissions to "SERVICE").