[Savannah-cvs] [83] talk about setting up shell access for savannah workers

[karl]

Revision: 83
          http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=83
Author:   karl
Date:     2014-04-18 16:57:59 +0000 (Fri, 18 Apr 2014)
Log Message:
-----------
talk about setting up shell access for savannah workers

Modified Paths:
--------------
    trunk/sviki/Mirmon.mdwn
    trunk/sviki/SavannahArchitecture.mdwn
    trunk/sviki/ShellAccess.mdwn

Modified: trunk/sviki/Mirmon.mdwn
===================================================================
--- trunk/sviki/Mirmon.mdwn     2014-04-01 17:29:05 UTC (rev 82)
+++ trunk/sviki/Mirmon.mdwn     2014-04-18 16:57:59 UTC (rev 83)
@@ -16,7 +16,7 @@
 - nongnu mirror list -
     <http://dl.sv.gnu.org/releases-noredirect/00_MIRRORS.html>
     (maintained by hand)
-- nongnu mirmon conf - /etc/mirmon.conf
+- nongnu mirmon conf - `/etc/mirmon.conf`
 - nongnu mirmon web page - <http://download.savannah.gnu.org/mirmon/savannah/>
 - nongnu multiplexor example - <http://dl.sv.nongnu.org/releases/cybop/>
 - nongnu direct, not multiplexed -
@@ -26,7 +26,7 @@
 <http://www.gnu.org/server/mirror.html>.
 
 dl.sv also runs the multiplexor for CTAN, although we do not run mirmon.
-/root/mirmon/ctan, /root/bin/ctan-mirror.sh, etc.
+`/root/mirmon/ctan`, `/root/bin/ctan-mirror.sh`, etc.
 
 More details:
 
@@ -45,5 +45,5 @@
 The geo location data is stored in `dl:/usr/local/share/GeoIP`, updated
 monthly via `/etc/cron.d/maxmind`.
 
-Savannah admins: process for adding new nongnu mirrors at end of
-[[DownloadArea]] page.
+Savannah admins: process for adding new nongnu mirrors is at the end of
+the [[DownloadArea]] page.

Modified: trunk/sviki/SavannahArchitecture.mdwn
===================================================================
--- trunk/sviki/SavannahArchitecture.mdwn       2014-04-01 17:29:05 UTC (rev 82)
+++ trunk/sviki/SavannahArchitecture.mdwn       2014-04-18 16:57:59 UTC (rev 83)
@@ -36,7 +36,7 @@
 Savannah operates with five critical Xen domU's:
 
 -   mgt.savannah.gnu.org (140.186.70.74)
--   internal.savannah.gnu.org. (140.186.70.75)
+-   internal.savannah.gnu.org (140.186.70.75)
 -   frontend.savannah.gnu.org (140.186.70.70, 140.186.70.71)
 -   vcs.savannah.gnu.org (140.186.70.72)
 -   download.savannah.gnu.org (140.186.70.73)

Modified: trunk/sviki/ShellAccess.mdwn
===================================================================
--- trunk/sviki/ShellAccess.mdwn        2014-04-01 17:29:05 UTC (rev 82)
+++ trunk/sviki/ShellAccess.mdwn        2014-04-18 16:57:59 UTC (rev 83)
@@ -1,14 +1,18 @@
-Currently, for user shell access, we use custom C executables for cvs.sv
-and symlink to `sftp-server` for arch.sv.
+Savannah does not provide general shell accounts, since running
+arbitrary commands is far too large an attack vector.  We do use the
+Unix login mechanism and [[SshAccess]] but only certain commands can be
+run to do, e.g., vc operations.  Validation is done against the
+databases on internal.
 
-Savane distributes sv\_membersh, a simple Perl script, that loads
+Savane distributes `sv_membersh`, a simple Perl script, that loads
 another Perl script in /etc for configuration. Using a Perl script as a
-login shell may yeld some efficiency concerns.
+login shell may yeld some efficiency concerns.  (But I think that is
+what we do on Savannah? --karl)
 
 Another tool is `rssh`
 (<http://packages.debian.org/stable/net/rssh>).
 This package does not check the command line arguments to `cvs` (in
-util.c), though it faced some security issues that sv\_membersh was also
+util.c), though it faced some security issues that `sv_membersh` was also
 vulnerable to
 (<https://gna.org/bugs/?func=detailitem&item_id=4824>).
 It is interesting to check upon that tool even if we do not use it for
@@ -16,5 +20,54 @@
 it is not a good idea to use it (plus we'd have to patch the CVS
 validation).
 
-I think a good move is to use sv\_membersh and to translate it to C if
-we think that can reduce the load.
+I (Sylvain) think a good move is to use `sv_membersh` and to translate it
+to C if we think that can reduce the load.  This has not been necessary.
+
+
+Shell access for Savannah workers
+---------------------------------
+Now, for those working on savannah, of course shell and root access is
+needed.  Generally, the idea to date has been to log in directly as
+root, with your ssh keys installed in the necessary places.  For most
+hosts, ssh has to go through fencepost or another known location, it's
+not open to the whole Internet.
+
+However, a few sv hackers like to have personal accounts on the servers.
+The best approach for this is to have it be completely separate from
+normal user-level savannah access.  Here was the process for `luca` in
+April 2014:
+
+0. Set up a normal account in the web interface to avoid someone later
+claiming the name.  But this should not be used for other purposes.
+
+0. On internal, get the assigned uid:
+
+    mysql -u root -p
+    select uidnumber from savane.user where user_name='luca';
+    ... 130932 ...
+
+This number is different from the user_id field which shows up in the
+savannah profile as the "Id:" <https://savannah.gnu.org/users/luca>.
+
+0. On mgt, add the obvious passwd entry using that uid.  It's not
+technically necessary that the uid's match, but it seems cleaner to
+avoid possible conflicts.
+
+0. In Luca's case, the only need was for access to download.sv.gnu.org,
+for audio-video maintenance.  So the account on mgt can't log in.  On
+dl, copy in the new passwd entry, make the shell `/bin/bash`, make the
+`/etc/shadow` entry.
+
+0. On dl, add luca to savannahroot in /etc/group.  This allows sudo.
+
+0. On dl, create `/etc/ssh/authorized_keys/luca` with his pub keys.
+This lets him log in.
+
+
+Bitter truth: the above is the clean way to do it.  However, previous sv
+shell accounts that have been set up (karl, rdoyle, mjflick) conflated
+shell access and savannah web access.  Obviously this can work and be a
+bit more convenient, and equally obviously it makes the default VC
+checkout paths and other things fail.  I (Karl) am not going to explain
+all that here.  If you don't know what I'm talking about or can't figure
+it out, don't create such an account :).