Difference between revisions of "Sysadmin/Add shell account"

From Sugar Labs
Jump to navigation Jump to search
Line 3: Line 3:
  
 
== Guidelines ==
 
== Guidelines ==
 +
 +
Ask users to follow diligently the [[Sysadmin/Shell_account_request]] procedure.
  
 
Users should briefly motivate their request. "I'd like to distribute some
 
Users should briefly motivate their request. "I'd like to distribute some
 
Sugar-related files on people.sugarlabs.org" would suffice.
 
Sugar-related files on people.sugarlabs.org" would suffice.
  
Shell accounts shouldn't be granted to untrusted individuals without
+
'''Shell accounts shouldn't be granted to untrusted individuals without referrals.'''
referrals. Shell accounts that are known to be unused should be disabled.
+
'''Shell accounts that are known to be unused should be disabled with <tt>system-userdel</tt>.'''
  
 
== Account creation on shell.sugarlabs.org ==
 
== Account creation on shell.sugarlabs.org ==
Line 16: Line 18:
 
  system-useradd <username> <first_name> <last_name> <email>
 
  system-useradd <username> <first_name> <last_name> <email>
  
At some point, the script will prompt you to paste the user's ssh key.
+
At some point the script will prompt you to paste the user's ssh key.
 
You can skip this part and edit ~user/.ssh/authorized_keys manually.
 
You can skip this part and edit ~user/.ssh/authorized_keys manually.
  
Line 22: Line 24:
 
The email is also copied to ~user/welcome, in case they loose the
 
The email is also copied to ~user/welcome, in case they loose the
 
original message.
 
original message.
 
== Creating accounts on other hosts ==
 
 
'''NOTE:''' accounts on [[Machine/lightwave]], [[Machine/jita]] and other high-security machines shouldn't be given out lightly.'''
 
 
You can automate account creation and provisioning on any Sugar Labs host using remote-useradd from sunjammer:
 
 
  remote-useradd <remote host> <username> [<group>...]
 
 
Of course, you need sudo access on the remote host
 
 
== Copying user keys to other hosts ==
 
 
  remote-auth <remote host> <username> [<remote user>]
 
 
== Passwords ==
 
 
The users are supposed to update their password by going to
 
 
https://ldap.sugarlabs.org/passwd
 
 
Password logins are not permitted on any of our machines. The password
 
is used by other authentication protocols: HTTP, IMAP, SMTP...
 
 
We currently don't have single-sign-on on most of our web applications,
 
but users can use our OpenID provider (id.sugarlabs.org).
 
 
 
== Removing shell accounts ==
 
 
Use:
 
 
system-userdel <user>
 
 
== Groups ==
 
 
To add groups:
 
 
system-groupadd
 
 
To remove groups, there's no script. Simply use "ldapvi" with no arguments.
 
 
== User information changes ==
 
 
Use ldapvi directly
 
 
 
== Password reset ==
 
 
If the users have forgotten their password, you can hack the password
 
information manually with ldapvi. Alternatively, go to the password
 
web form and type sunjammer's root password in place of the user's
 
old password.
 
 
If the user knows how to use GPG, send them the new password
 
encrypted. In any case, ask them to change it immediately.
 
  
 
== See also ==
 
== See also ==
 
+
* [[Sysadmin/User_management]] -- all other operations on user accounts
* [[Sysadmin/User_management]], for the sysadmin side of this procedure.
 

Revision as of 16:17, 17 September 2011

Users normally do follow the Sysadmin/Shell account request. The account requests arrive to a support queue on our RT system (Machine/treehouse/rt).

Guidelines

Ask users to follow diligently the Sysadmin/Shell_account_request procedure.

Users should briefly motivate their request. "I'd like to distribute some Sugar-related files on people.sugarlabs.org" would suffice.

Shell accounts shouldn't be granted to untrusted individuals without referrals. Shell accounts that are known to be unused should be disabled with system-userdel.

Account creation on shell.sugarlabs.org

To create an account, become root on Machine/sunjammer and type:

system-useradd <username> <first_name> <last_name> <email>

At some point the script will prompt you to paste the user's ssh key. You can skip this part and edit ~user/.ssh/authorized_keys manually.

The procedure automatically sends a welcome email to the user. The email is also copied to ~user/welcome, in case they loose the original message.

See also