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 :).
