[Savannah-cvs] [178] wording, typos

[karl]

Revision: 178
          
http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=178
Author:   karl
Date:     2016-01-17 00:05:02 +0000 (Sun, 17 Jan 2016)
Log Message:
-----------
wording, typos

Modified Paths:
--------------
    trunk/sviki/Mirmon.mdwn
    trunk/sviki/UserAuthentication.mdwn

Modified: trunk/sviki/Mirmon.mdwn
===================================================================
--- trunk/sviki/Mirmon.mdwn     2016-01-16 21:12:35 UTC (rev 177)
+++ trunk/sviki/Mirmon.mdwn     2016-01-17 00:05:02 UTC (rev 178)
@@ -1,3 +1,6 @@
+Mirmon at Savannah
+==================
+
 Our [mirmon](http://www.staff.science.uu.nl/~penni101/mirmon/) instance
 operates on download.savannah.gnu.org.  We run [three instances of
 mirmon](http://download.savannah.gnu.org/mirmon/): one each for http
@@ -58,8 +61,8 @@
 - which is automatically created by `dl:/root/bin/mirrors-gnu.sh`
   from the current mirmon state and the http-only list of mirrors in
   `dl:/usr/local/share/GeoIP/gnu-download.txt`,
-- which in turn is updated nightly by a `dl:/etc/cron.d/mirmon` cron job
-  running `dl:/root/bin/gnu-mirmon.pl`.
+- which in turn is updated nightly by a `dl:/etc/cron.d/mirmon` cron entry
+  which runs `dl:/root/bin/gnu-mirmon.pl`.
 
 The mirmon state and redirection lists are updated hourly for both
 multiplexors (gnu, nongnu), each of which has its own script,
@@ -69,7 +72,7 @@
 `dl:/usr/local/share/GeoIP`.
 
 A special thing about allgnu: because we want to check rsync urls, we
-want at least mirmon version 1.39 (ca.2009), which is newer than what
+need at least mirmon version 1.39 (ca.2009), which is newer than what
 the OS version on dl provides.  So the current mirmon is in
 `dl:/usr/local/share/mirmon` (just unpacking the tarball suffices) and
 the allgnu mirmon job uses that, instead of the OS mirmon.

Modified: trunk/sviki/UserAuthentication.mdwn
===================================================================
--- trunk/sviki/UserAuthentication.mdwn 2016-01-16 21:12:35 UTC (rev 177)
+++ trunk/sviki/UserAuthentication.mdwn 2016-01-17 00:05:02 UTC (rev 178)
@@ -1,3 +1,5 @@
+## User authentication on Savannah
+
 ### User account creation
 
 1. Anyone can register a Savannah user account using the web interface:
@@ -8,12 +10,12 @@
 4. ssh public keys are stored in the MySQL database server on
    `internal.sv.gnu.org` (see [[SavannahServices]]).
 
-User information is can be viewed on the Savannah web site.
-Example for user 'agn': <https://sv.gnu.org/users/agn/> .
+User information can be viewed by anyone on the Savannah web site.
+Example for user 'agn': <https://sv.gnu.org/users/agn/>
 
 ### Database access
 
-On `internal.sv.gnu.org`, the following SQL commands can be used to examine
+On `internal.sv.gnu.org`, the following sql commands can be used to examine
 user accounts:
 
     $ echo "select
@@ -32,14 +34,14 @@
 The `authorized_keys` field contains all the user's SSH public keys,
 concatenated with a `###` delimiter, as a one-line string.
 (The database currently contains some malformed/invalid keys - when
-users uploaded invalid keys.)
+a user uploaded invalid keys.)
 
 ### Reactivating a user
 
 It's possible to do this in the web interface: Main page -> Browse Users
-List -> find user -> "[Activate]" in the Actions column.
+List -> find user -> [Activate] in the Actions column.
 
-Also possible to do it in sql, of course.  Check the status, do the
+Also possible to do in sql, of course.  Check the status, do the
 update as safely as possible, check again:
 
     mysql> select user_id,user_name,status from user where user_name = 'FOO';
@@ -48,7 +50,7 @@
 
 ### User/group accounts
 
-In Savannah systems, there is a unix user for *each* Savannah
+In Savannah systems, there is a Unix user for *each* Savannah
 registered user:
 
      vcs:~# getent passwd agn
@@ -78,17 +80,6 @@
     vcs:~# getent group gawk
     gawk:x:6731:ajschorr,arnold,eliz,jkahrs,scldad,wb8tyw
 
-> **NOTE:**
->
-> Savannah users who are not members of any projects (i.e. do not have
-> write-access to any repository) will *not* have SSH login access on
-> `vcs` even if they've setup their SSH pubkeys. `getent passwd USER` will
-> return empty results for such users, even if they are valid users in the
-> database (i.e. they exist in the `users` mysql table).
->
-> Techinically, this is due to the libnss-mysql (see below) script doing
-> an SQL join on the `user` and `user_group` tables, and requiring having
-> at least one record in the `user_group` table).
 
 ### Authentication mechanisms
 
@@ -97,12 +88,23 @@
 access and their public keys. See [[SavannahServices]] for details about the
 available services on these servers.
 
+Savannah users who are not members of any project (i.e., do not have
+write access to any repository) do not have ssh login access on `vcs`
+even if they have set up their ssh keys. `getent passwd USER` will
+return empty results for such users, even if they are valid users in the
+database (i.e., they exist in the `users` mysql table).
+
+Technically, this is due to the libnss-mysql (see below) script doing an
+sql join on the `user` and `user_group` tables, and requiring having at
+least one record in the `user_group` table.  Maybe someday this will be
+changed.
+
 These servers use the MySQL database in two ways:
 
 * Unix user management, using
   [nsswitch](http://en.wikipedia.org/wiki/Name_Service_Switch) and
   [libnss-mysql](http://libnss-mysql.sourceforge.net/).
-* SSH key authentication, using the custom `AuthorizedKeysExec` option.
+* ssh key authentication, using the custom `AuthorizedKeysExec` option.
 
 ### nsswitch and libnss-mysql
 
@@ -125,7 +127,7 @@
      download:~# getent passwd agn
      agn:x:131035:1003:Assaf Gordon:/srv:/usr/local/bin/sv_membersh
 
-(Notice the `uidNumber` from the mysql database is the user's unix
+(Notice the `uidNumber` from the mysql database is the user's Unix
 uid.)
 
 The sql statements (to extract information from the mysql database on
@@ -220,7 +222,7 @@
 
 ### fencepost
 
-`fencepost.gnu.org` is general-purpose server for GNU hackers (for more
+`fencepost.gnu.org` is the general-purpose server for GNU hackers (for more
 information: <https://www.gnu.org/software/README.accounts.html>).
 
 It is managed by FSF sysadmin, and not managed by Savannah people in any
@@ -228,7 +230,7 @@
 
 Users on `fencepost.gnu.org` conventionally use the same username as
 Savannah accounts, and public ssh keys are copied (manually) from
-Savannah database (i.e.  users requesting access to `fencepost` should
+Savannah database (i.e., users requesting access to `fencepost` should
 setup accounts on Savannah with ssh public keys). Other than that - user
 management on `fencepost` is separate from the rest of Savannah servers.