Re: [Savannah-hackers] Creating new accounts...

[Loic Dachary]

Jamshed Kakar writes:
 > Hi,
 > 
 > I'm working to catch up on a tonne of outstanding account-creation
 > requests.  I've been asking everyone to create savannah accounts and
 > upload SSH keys, et al. as appropriate.
 > 
 > This has been fine up until the point that I've need to actually
 > create an account... =) How do I get data out of savannah to create an
 > account?
 > 

        Please check the Creating an account chapter in sysadmin.texi:

@node Creating an account, Deleting an account, Ongoing tasks, Top
@chapter Creating an account

Whenever you do something related to account creation, including
simply emailing a reply, make sure to let the other volunteers know at
@email{accounts@@gnu.org}, to avoid duplication of effort.

When someone asks for an account, first determine whether they are
entitled to one.  In general, we give accounts to anyone at the
request of a GNU maintainer.  The official list of GNU maintainers is
in @file{fencepost:/gd/gnuorg/maintainers}.

If they do not appear to be entitled to an account, send them
@file{fencepost:/gd/gnuorg/account-reject.txt}, possibly customized if
appropriate.  Make sure to cc @email{accounts@@gnu.org}.

If they are entitled to an account, email them
@file{fencepost:/gd/gnuorg/account-new.txt}, possibly customized if
appropriate.

The instructions ask them to create an account on savannah, and to
email us after that is done.

@itemize @bullet
@item
If they've requested shell access to other machines, you must create
accounts on those machines using the same account name as they have on
savannah.

To do this on fencepost, gnudist, or gnuftp, run @code{adduser
--disabled-password @var{username}} on each machine and answer the
questions.  Then edit @file{/etc/shadow} and change the `!' to a `*'
on the user's line.

If they'll be using OpenSSH for shell access, they should've
registered their SSH keys with savannah, in which case they'll be in
@file{subversions:/subversions/sourceforge/dumps/accounts.txt}.  This
file is updated daily by a cron job, and contains a block of lines for
each user, with blank lines in between.  The first three lines of each
user block contain the username, full name, and email address.  The
remaining lines, if any, contain the user's OpenSSH keys.  There is
one very long line per key, containing mostly digits.  See
@url{http://savannah.gnu.org/savannah.html#Account%20Management} for
more details.

You must copy the appropriate lines of that file to
@file{~/.ssh/authorized_keys} on the other machines they need access
to.  Be careful not to insert any additional linefeeds while copying
the lines; you might want to run ``wc -l'' on the resulting file as a
sanity check.  Also, make sure to @code{chown} the newly copied file
and .ssh directory.

You may also need to add them to certain groups on these machines.
The most common cases are:

@itemize @bullet
@item
If they need access to the ftp server on fencepost (alpha.gnu.org)
you should add them to the ftp group.

@item
If they are a webmaster who needs shell access to gnudist, add them to
the www group. Most webmaster related tasks can be carried out using
the www.gnu.org CVS tree. Check @url{http://savannah.gnu.org/projects/www/}
for more information.

@item
If they are an ftp-upload volunteer, add them to the ftp group on
gnuftp.

@item
If they are a maintainer who wants access to their ftp directory on
gnuftp, the preferred method is to simply make them the owner of
~ftp/gnu/xxx and its subdirectories.  However, if multiple users need
write access to the same directory, we must add them to the ftp group.

@end itemize

@item
If they've requested LSH for CVS access, they should've sent us their
LSH DSA keys.  You must then do the following:

@enumerate
@item
Log into subversions as root, and then @code{su - username}.
If there is no such account of that name, search for ``login account''
above for an explanation.

@item
For each LSH public key they sent, copy the key to a file on
subversions, and run @code{lsh-authorize the-key.pub}.

@end enumerate

@item
If they've requested Kerberos access, you'll need to create a Kerberos
principal for them, as follows:

Run kadmin, give it your admin password, and say @code{addprinc
lusername}, then type their password twice and then quit that program.
The password you assign to them should have at least 8 characters and
contain some uppercase characters, digits, and/or punctuation.

You should then send them their Kerberos password via the secure method
they requested, either GnuPG encrypted email, phone, or postal mail.

It is very important that you not send the password in unencrypted
email.

It is best to run kadmin on your own machine instead of a GNU machine
if you can get MIT krb5 installed without too much hassle.  Otherwise,
run kadmin from fencepost.

@item
TODO: Write some up-to-date documentation to send people after their
account has been created.

@end itemize

-- 
Loic   Dachary         http://www.dachary.org/  address@hidden
24 av Secretan         http://www.senga.org/      address@hidden
75019    Paris         Tel: 33 1 42 45 09 16        address@hidden
        GPG Public Key: http://www.dachary.org/loic/gpg.txt