[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-cvs]  wording, typos
[Savannah-cvs]  wording, typos
Sun, 17 Jan 2016 00:05:10 +0000
Date: 2016-01-17 00:05:02 +0000 (Sun, 17 Jan 2016)
--- 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
-- 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 @@
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.
--- 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
$ 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
vcs:~# getent passwd agn
@@ -78,17 +80,6 @@
vcs:~# getent group gawk
-> 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
These servers use the MySQL database in two ways:
* Unix user management, using
-* 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
-(Notice the `uidNumber` from the mysql database is the user's unix
+(Notice the `uidNumber` from the mysql database is the user's Unix
The sql statements (to extract information from the mysql database on
@@ -220,7 +222,7 @@
-`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
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.
|[Prev in Thread]
||[Next in Thread]|
- [Savannah-cvs]  wording, typos,