[Savannah-cvs] [577] proofread and update

[ineiev]

Revision: 577
          
http://svn.savannah.gnu.org/viewvc/?view=rev&root=administration&revision=577
Author:   ineiev
Date:     2023-02-13 05:00:44 -0500 (Mon, 13 Feb 2023)
Log Message:
-----------
proofread and update

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

Modified: trunk/sviki/UserAuthentication.mdwn
===================================================================
--- trunk/sviki/UserAuthentication.mdwn 2023-02-13 08:04:43 UTC (rev 576)
+++ trunk/sviki/UserAuthentication.mdwn 2023-02-13 10:00:44 UTC (rev 577)
@@ -1,23 +1,23 @@
-## User authentication on Savannah
+## User authentication at Savannah
 
 ### User account creation
 
-1. Anyone can register a Savannah user account using the web interface:
+1. Anyone can register a Savannah account using the web interface:
    <https://savannah.gnu.org/account/register.php>
-2. These user accounts are used across all Savannah systems.
+2. These accounts are used across all Savannah systems.
 3. Users can upload ssh public keys using the web interface at:
    <https://savannah.gnu.org/my/admin/editsshkeys.php>
-4. ssh public keys are stored in the MySQL database server on
+4. ssh public keys are stored in the MySQL database on
    `internal0.savannah.gnu.org` (see [[SavannahServices]]).
 
-User information can be viewed by anyone on the Savannah web site.
-Example for user 'agn': <https://sv.gnu.org/users/agn/>
+User information can be viewed by anyone on Savannah website.
+Example for user `agn`: <https://sv.gnu.org/users/agn/>
 
 ### Database access
 
-In the SQL database, currently `internal0.savannah.gnu.org` but
-accessible from the collection of hosts, the following sql commands
-can be used to examine user accounts:
+In the MySQL database, currently `internal0.savannah.gnu.org` but
+accessible from a set of hosts, the following SQL commands
+can be used to examine accounts:
 
     $ echo "select
               user_id, user_name, email, realname,
@@ -32,34 +32,27 @@
     |   94790 | agn       | [email]  | Assaf Gordon |    131035 | ssh-rsa 
AAAAB3Nz|
     
+---------+-----------+----------+--------------+-----------+-----------------+
 
-The `authorized_keys` field contains all the user's SSH public keys,
+The `authorized_keys` field contains all user's SSH public keys,
 concatenated with a `###` delimiter, as a one-line string.
-Users upload their GPG key and this data is stored in this database
-record.  Some users have uploaded malformed and invalid GPG key
+Users upload their GPG keys, and they are stored in the database.
+Some users have uploaded malformed and invalid GPG key
 information.  Therefore some of these records are invalid due to
-having had invalid information uploaded.
+having invalid information uploaded.
 
-### Reactivating a user
+### Activating accounts
 
-It's possible to do this in the web interface: Main page -> Browse Users
+This is done via the web siteadmin interface: Main page -> Browse Users
 List -> find user -> [Activate] in the Actions column.
 
-Also possible to do in sql, of course.  Check the status, do the
-update as safely as possible, check again:
+### Groups and accounts
 
-    mysql> select user_id,user_name,status from user where user_name = 'FOO';
-    mysql> update user set status='A' where user_id=N and user_name='FOO' 
limit 1;
-    mysql> select user_id,user_name,status from user where user_name = 'FOO';
-
-### User/group accounts
-
 In Savannah systems, there is a Unix user for *each* Savannah
-registered user:
+registered account:
 
      vcs0:~# getent passwd agn
      agn:x:131035:1003:Assaf Gordon:/srv:/usr/local/bin/sv_membersh
 
-and a unix group for *each* Savannah registered project:
+and a unix group for *each* Savannah registered group:
 
     vcs0:~# getent group datamash
     datamash:x:77800:agn
@@ -68,11 +61,11 @@
 
 Example:
 
-The `gawk` (GNU Awk) project (<http://sv.gnu.org/p/gawk>) has six
+The `gawk` (GNU Awk) group (<http://sv.gnu.org/p/gawk>) has six
 members as of Nov. 2014
 (<http://sv.gnu.org/project/memberlist.php?group=gawk>).
 
-The git repository on `vcs.sv.gnu.org` is group-owned by `gawk` group:
+The git repository on `vcs.sv.gnu.org` belongs in the `gawk` group:
 
     vcs0:~# ls -ld /srv/git/gawk.git/
     drwxrwsr-x 8 root gawk 4096 Nov  4 01:23 /srv/git/gawk.git/
@@ -86,11 +79,11 @@
 ### Authentication mechanisms
 
 For VCS repositories (git/hg/bzr/svn/cvs on `vcs.sv.gnu.org`) and
-download/releases (on `dl.sv.gnu.org`), users are authenticated using SSH
+download area (on `dl.sv.gnu.org`), users are authenticated using SSH
 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
+Savannah users who are not members of any group (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
@@ -97,7 +90,7 @@
 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
+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.
 
@@ -119,7 +112,7 @@
     shadow:         compat mysql
     ...
 
-Bob Proulx 
[explains](http://lists.gnu.org/archive/html/savannah-hackers-public/2014-11/msg00029.html):
+Bob Proulx explains:
 
 That is how libc is configured.  'compat' means /etc/passwd in the
 normal compatible way.  'mysql' means if not found in the first compat
@@ -129,28 +122,27 @@
      download0:~# getent passwd agn
      agn:x:131035:1003:Assaf Gordon:/srv:/usr/local/bin/sv_membersh
 
-The sql statements (to extract information from the mysql database on
-`internal0`) are defined in `download0:/etc/libnss-mysql.cfg` and
+The SQL statements to extract information from the database on
+`internal0` are defined in `download0:/etc/libnss-mysql.cfg` and
 `vcs0:/etc/libnss-mysql.cfg`.
 
 ### uidNumber
 
 Savannah users have two IDs in the database: `user.user_id` and
-`user.uidNumber`. `user_id` is used in the PHP web-frontend alone
+`user.uidNumber`. `user_id` is used in the PHP frontend alone
 (it is the primary key for the user table). `uidNumber` is the
-user's unix account user id (used by `getent` above).
+user's unix account user ID (used by `getent` above).
 
-When a new user is registerd on savannah, the `user_id` will be
-unique but the `uidNumber` will be *NULL*.
+When a new user is registerd on Savannah, the `user_id` will be
+unique, but the `uidNumber` will be *NULL*.
 
-A cron job (`mgt0:/etc/cron.d/savannah`) calls a script (
-[sv_assign_uid_gid](https://git.savannah.gnu.org/cgit/administration/savane.git/tree/backend/accounts/sv_assign_uid_gid.in))
-which scans the new users in the database, and creates unix user-ids and
-group ids if needed (if a user is not part of any group - they won't need
-ssh access and thus won't need user-id).
+A cron job (`mgt0:/etc/cron.d/savannah`) calls a script (sv_assign_uid_gid)
+which scans the new users in the database, and creates unix user IDs and
+group IDs if needed (if users are not part of any group, they won't need
+ssh access and thus won't need user ID).
 
 Search for `sv_assign_uid_gid` in [[SavannahInternals]] to see
-how it is called (but note that the page is out-dated: the script now
+how it is called (but note that the page is outdated: the script now
 runs as a cron job on `mgt0`, not `internal0`).
 
 ### ssh authentication
@@ -157,27 +149,14 @@
 
 The file `/etc/ssh/sshd_config` on `download0:` and `vcs0:` servers have the 
line:
     ...
-    AuthorizedKeysExec      /usr/local/bin/sv_get_authorized_keys
+    AuthorizedKeysCommand      /root/bin/sv_get_authorized_keys
     ...
 
-> **Historical Note:**  
-> `AuthorizedKeysExec` was a patch submitted by GNU Hacker
-> Michael J. Flickinger (<http://sv.gnu.org/u/mjflick>) to OpenSSH in
-> 
[2011](http://lists.mindrot.org/pipermail/openssh-unix-dev/2011-December/030080.html).
-> It appears the patch was never formally accepted by upstream OpenSSH.  
-> In 2012 a similar patch was
-> [accepted from RedHat](http://marc.info/?l=openbsd-cvs&m=135163261632479&w=2)
-> using a differently named option `AuthorizedKeysCommand`.  
-> This option (and not `AuthorizedKeysExec`) is available in most OpenSSH
-> installations.  
-> If Savannah servers are ever upgraded, these configuration files should be
-> updated from `AuthorizedKeysExec` to `AuthorizedKeysCommand`.
+When users log in to Savannah servers using ssh, they specify the account:
 
-When users login to Savannah servers using ssh, they specify the user account:
-
     git clone agn@git.sv.gnu.org:/srv/git/datamash.git
 
-The user is therefore known, and OpenSSH needs to find the user's public keys.
+The user is therefore known, and OpenSSH needs to find user's public keys.
 The `/usr/local/bin/sv_get_authorized_keys` Perl script simply queries
 the ssh public keys of the user (splitting them by `###` delimiter):
 
@@ -196,7 +175,7 @@
     ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvs [...]
     ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ [...]
 
-To validate the user's keys on `vcs`, use the following script:
+To validate user's keys on `vcs`, use the following script:
 
     vcs0:~# ~/bin/check-user-pubkeys.sh agn
     gordon@host1     2048 fe:61:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx 
/tmp/pubkey.check.9WvGnA/key.00 (RSA)
@@ -220,7 +199,7 @@
 root access to `mgt0` (and from there to the other Savannah servers) is
 controlled by `mgt0:/root/.ssh/authorized_keys`. This file is updated
 **manually** by existing Savannah administrators, adding ssh public keys
-of authorized savannah hackers.
+of authorized Savannah hackers.
 
 ssh access to `mgt0` is only possible from `fencepost` (and other
 internal FSF machines to which no one outside the FSF has access).
@@ -235,22 +214,10 @@
 It is managed by FSF sysadmin, and not managed by Savannah people in any
 way whatsoever.
 
-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
-setup accounts on Savannah with ssh public keys). Other than that - user
-management on `fencepost` is separate from the rest of Savannah servers.
+### GNU webpage repository access for www members
 
-Each user on `fencepost` has a home directory with `~/.ssh/authorized_keys`
-files, enabling ssh access:
-
-    $ getent passwd agn
-    agn:x:1557:1562:Assaf Gordon,,,:/home/a/agn:/bin/bash
-
-### GNU webpages repository access for www members
-
 Members of the www group (= GNU webmasters) have write access to the
-webpage repository for all gnu (not nongnu) projects.  This is
+webpage repository for all gnu (not nongnu) groups.  This is
 accomplished with ACLs.  See ChangeLog entries by Beuc for 2006-06-28
 and 2006-05-10, recorded in
 
<http://lists.gnu.org/archive/html/savannah-hackers-public/2016-05/msg00031.html>.
@@ -261,9 +228,8 @@
 
 To set all of them I think this is needed.  Testing it now.
 
-    setfacl -m group:www:rw- project/CVSROOT/history
-    find project/project -type d -exec setfacl -m default:group:www:rwx -m 
group:www:rwx {} +
+    setfacl -m group:www:rw- group/CVSROOT/history
+    find group/group -type d -exec setfacl -m default:group:www:rwx -m 
group:www:rwx {} +
     find . -name CVSROOT -prune -o -type f -exec setfacl -m group:www:rw- {} +
 
-The `Cvs.pm` Savane module apparently installs this access for new gnu
-projects and directories.
+The `Cvs.pm` Savane module installs this access for new gnu groups.