This may eventually turn into something with more documentation on the new user management features in ORBIT Trac.

== The {{{useradmin}}} account ==

The useradmin account has permission to do stuff like {{{mkdir /export/home/foo}}} on repository2.  The idea is that automated processes do stuff by logging into it using ssh keypairs.  For example, here's a quick test to see if you can do things as useradmin@repostiory2 as www-data on external1:

{{{
(Wed Sep 10 14:38:43) (root@external1:~)
bash> su - www-data
www-data@external1:~$ ssh-add
Could not open a connection to your authentication agent.
www-data@external1:~$ ssh-agent 
SSH_AUTH_SOCK=/tmp/ssh-MBTyO32174/agent.32174; export SSH_AUTH_SOCK;
SSH_AGENT_PID=32175; export SSH_AGENT_PID;
echo Agent pid 32175;
www-data@external1:~$ SSH_AUTH_SOCK=/tmp/ssh-MBTyO32174/agent.32174; export SSH_AUTH_SOCK;
www-data@external1:~$ SSH_AGENT_PID=32175; export SSH_AGENT_PID;
www-data@external1:~$ echo Agent pid 32175;
Agent pid 32175
www-data@external1:~$ ssh-add
Identity added: /var/www/.ssh/id_rsa (/var/www/.ssh/id_rsa)
www-data@external1:~$ ssh useradmin@repository2 sudo mkdir /export/home/corge
www-data@external1:~$ ssh useradmin@repository2 sudo rmdir /export/home/corge
}}}

The lack of password protection on the private key in {{{~www-data/.ssh}}} is a concern, but pretty much the best way to go when www-data is going to be all automated web scripts.  Feel free to add more public keys to {{{~useradmin/.ssh/authorized_keys}}}.