savannah-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-cvs] [117] small edits, typos, downcasing


From: karl
Subject: [Savannah-cvs] [117] small edits, typos, downcasing
Date: Fri, 21 Nov 2014 23:53:02 +0000

Revision: 117
          
http://svn.sv.gnu.org/viewvc/?view=rev&root=administration&revision=117
Author:   karl
Date:     2014-11-21 23:52:50 +0000 (Fri, 21 Nov 2014)
Log Message:
-----------
small edits, typos, downcasing

Modified Paths:
--------------
    trunk/sviki/AdminSvnImport.mdwn
    trunk/sviki/CvsRsyncWriteAccess.mdwn
    trunk/sviki/HowToAdminThisWiki.mdwn
    trunk/sviki/ImportingCVSRepository.mdwn
    trunk/sviki/SavannahServices.mdwn
    trunk/sviki/UserAuthentication.mdwn

Modified: trunk/sviki/AdminSvnImport.mdwn
===================================================================
--- trunk/sviki/AdminSvnImport.mdwn     2014-11-21 02:21:42 UTC (rev 116)
+++ trunk/sviki/AdminSvnImport.mdwn     2014-11-21 23:52:50 UTC (rev 117)
@@ -6,9 +6,9 @@
 
 For Savannah administrators: here's how to import an SVN repository.
 
-Make sure that SVN is already enabled for the project (Select Features).
-This will create the svn repository with the correct ownership and
-permissions.
+Make sure that SVN is already enabled for the project (under Main ->
+Administer -> Select Features).  This will create the svn repository
+with the correct ownership and permissions.
 
 The project developers need to create an SVN dump as explained at
 [[SvnImportExistingRepo]].
@@ -20,25 +20,27 @@
     screen # or whatever, see below
     cd /root/vcs-imports
     proj=THEIRPROJECT
-    wget http://url/to/$proj-dump.bz2
-    # or whatever, e.g.,
-    # scp dl.sv.gnu.org:/srv/download/$proj/$proj-dump.bz2 .
-    bzcat $proj-dump.bz2 | nice svnadmin load /srv/svn/$proj/ 
>/tmp/$proj.svimport.out 2>/tmp/$proj.svimport.err
+    # get their dump file, e.g.:
+    dumpfile=$proj-dump.bz2
+    #scp dl.sv.gnu.org:/srv/download/$proj/$dumpfile .
+    # or whatever they give, e.g.,
+    #wget http://url/to/$dumpfile
+    bzcat $dumpfile | nice svnadmin load /srv/svn/$proj/ 
>/tmp/$proj.svimport.out 2>/tmp/$proj.svimport.err
     tail /tmp/$proj.svimport.err
     tail /tmp/$proj.svimport.out
-    rm $proj-dump.bz2
+    rm $dumpfile
 
 Sometimes we may be given a tar of their svn repository.  In this case,
 we must ask for a proper svn dump (produced by `svnadmin dump`).  Using
 a direct tar is not safe because we may not be using the same versions
 of SVN, and sometimes the format changes with the new versions of SVN.
 
-The svnadmin load is machine intensive and time consuming; it can easily
-take several seconds per revision.  Meaning that this import might
-easily take several hours to load on a project with any significant
-history.  Planning accordingly by running the task under a screen
-session, or using nohup, or some such, so that it can complete even if
-your connection to it is dropped is a good idea.
+The `svnadmin load` is machine intensive and time consuming; it can
+easily take several seconds per revision.  Meaning that this import
+might easily take several hours to load on a project with any
+significant history.  Planning accordingly by running the task under a
+screen session, or using nohup, or some such, so that it can complete
+even if your connection to it is dropped is a good idea.
 
 If converting from another version control system on Savannah then as a
 final step the prior system should be disabled to prevent further commit
@@ -58,8 +60,8 @@
     find /srv/svn/$proj/db -type d -exec chgrp $proj {} +
     find /srv/svn/$proj/db -type f -exec chgrp $proj {} +
 
-In particular be sure to leave the "hooks" directory (along with the
-others) owned by root:root and with secure permissions only for the
+In particular, be sure to leave the `hooks` directory (along with the
+others) owned by `root:root` and with secure permissions only for the
 root user.
 
 These steps are all done automatically when the repository is created

Modified: trunk/sviki/CvsRsyncWriteAccess.mdwn
===================================================================
--- trunk/sviki/CvsRsyncWriteAccess.mdwn        2014-11-21 02:21:42 UTC (rev 
116)
+++ trunk/sviki/CvsRsyncWriteAccess.mdwn        2014-11-21 23:52:50 UTC (rev 
117)
@@ -9,10 +9,11 @@
     can also lead to situations where it's not clear who exactly sent a
     given commit.
 -   security; we do not provide shell access to Savannah, so that users
-    cannot send arbitratry commands to the system (fork bombs, twisted
-    calls to ptrace...). Granting CVS direct write access provide a way
+    cannot send arbitrary commands to the system (fork bombs, twisted
+    calls to ptrace, many more). Granting CVS direct write access would
+    provide a way
     to do so by creating a distinct CVSROOT/ directory. Such CVS root
-    could also be used to trick CVS users with few experience into
+    could also be used to trick CVS users into
     executing malicious hooks under their username.
 
 So providing cvs write access is currently something we refuse.

Modified: trunk/sviki/HowToAdminThisWiki.mdwn
===================================================================
--- trunk/sviki/HowToAdminThisWiki.mdwn 2014-11-21 02:21:42 UTC (rev 116)
+++ trunk/sviki/HowToAdminThisWiki.mdwn 2014-11-21 23:52:50 UTC (rev 117)
@@ -1,6 +1,5 @@
 Wiki Administration
 ===================
-
 This wiki is based on ikiwiki.  Access is through Subversion (no
 web-based editing).  Specifically, to update the pages:
 
@@ -21,7 +20,6 @@
 
 Using Git
 ---------
-
 The repository is an Subversion repository.  It is possible to access
 Subversion repositories using Git through `git-svn`, which
 is an optional addition to the git suite of tools.
@@ -55,14 +53,14 @@
 are simply a matter of having the files be writable to the desired Unix
 users.
 
-For Savannah, we really wanted the source repository to be accessible in
-the standard Savannah ways, that is, through the `administration`
+For Savannah, we very much wanted the source repository to be accessible
+in the standard Savannah ways, that is, through the `administration`
 project (<http://savannah.gnu.org/projects/administration>, which holds
-all the live Savannah stuff which is checked into version control).  That
-way, access would be controlled just as to any other source repository.
-We used the Subversion repository in `administration` as the wiki source
-partly because it was otherwise unused and partly because Karl (who did
-all this) likes Subversion.
+all the live Savannah stuff which is checked into version control).
+That way, access would be controlled just as to any other source
+repository.  We used the Subversion repository in `administration` as
+the wiki source partly because it was otherwise unused and partly
+because Karl (who did all this) likes Subversion.
 
 Well, using a Savannah project means that source repository lives on one
 host (vcs) while the web-accessible wiki lives on another (frontend).
@@ -88,7 +86,77 @@
 then it will never be accessed again (due to the options with which
 `sv_ikiwiki_refresh` invokes ssh).
 
+Running this wiki locally
+-------------------------
+To edit and review changes locally (before commiting, or submitting a patch
+to the address@hidden mailing list), install `ikiwiki`
+and checkout the svn repository:
 
+    $ sudo apt-get install ikiwiki
+    $ svn co svn://svn.savannah.gnu.org/administration
+
+The markdown files will be in `./administration/trunk/sviki`:
+
+    $ ls ./administration/trunk/sviki/
+    AboutTranslations.mdwn         MigrationFromSourceForge.mdwn
+    AccessToCVSROOT.mdwn           Mirmon.mdwn
+    AdminSvnImport.mdwn            MirroringExternalRepository.mdwn
+    AnnouncementMailingList.mdwn   ModerationAutomation.mdwn
+    ApprovingSubmission.mdwn       ModifyingGroupType.mdwn
+    ...
+
+
+### Manual wiki rendering
+
+For a one-time (or occasional) wiki rendering, run `ikiwiki` manually:
+
+    $ mkdir /tmp/sviki/
+    $ ikiwiki --verbose --rebuild \
+          ./administration/trunk/sviki \
+          /tmp/sviki
+
+The HTML files will be rendered and stored in `/tmp/sviki`.
+
+`--rebuild` should be used if rebuilding the wiki in a new directory, to
+ensure caching of previous rendering are ignored.
+
+The files can be viewed by simply visiting <file:///tmp/sviki/index.html> -
+however, navigation will be slightly problematic as IkiWiki requires a
+`DirectoryIndex` like option which automatically renders `index.html` as the
+default HTML file in a directory.
+
+### Apache configuration
+
+If you have an apache server running locally, the following configuration
+mimics the GNU Savannah settings:
+
+    Alias /maintenance "/tmp/sviki"
+    <Directory "/tmp/sviki">
+        Options Indexes
+        AllowOverride None
+        order deny,allow
+        allow from all
+        DirectoryIndex index.html
+    </Directory>
+
+### Quicker Updates
+
+For quicker rendering, use `ikiwiki` without `--rebuild` - will only update
+the changed files. In this case, it is better to clean the cache once with
+`--clean` and `--rebuild`:
+
+    # Clean the cache (just once)
+    $ ikiwiki --verbose --clean ./administration/trunk/sviki /tmp/sviki
+
+    # Rebuild the entire wiki (just once)
+    $ ikiwiki --verbose --rebuild ./administration/trunk/sviki /tmp/sviki
+
+After any further changes, just update the relevant files (without `--rebuild`,
+the default `ikiwiki` operation is `--refresh`):
+
+    $ ikiwiki --verbose ./administration/trunk/sviki /tmp/sviki
+
+
 Initial setup
 -------------
 For posterity, here is how the initial setup went.
@@ -203,76 +271,4 @@
     rc5.d/K02zope2.10 -> ../init.d/zope2.10
     rc6.d/K02zope2.10 -> ../init.d/zope2.10
 
-Maybe we are back in business.
-
-
-Running This Wiki Locally
--------------------------
-
-To edit and review changes locally (before commiting, or submitting a patch
-to the address@hidden mailing list), install `ikiwiki`
-and checkout the svn repository:
-
-    $ sudo apt-get install ikiwiki
-    $ svn co svn://svn.savannah.gnu.org/administration
-
-The markdown files will be in `./administration/trunk/sviki`:
-
-    $ ls ./administration/trunk/sviki/
-    AboutTranslations.mdwn         MigrationFromSourceForge.mdwn
-    AccessToCVSROOT.mdwn           Mirmon.mdwn
-    AdminSvnImport.mdwn            MirroringExternalRepository.mdwn
-    AnnouncementMailingList.mdwn   ModerationAutomation.mdwn
-    ApprovingSubmission.mdwn       ModifyingGroupType.mdwn
-    ...
-
-
-### Manual wiki rendering
-
-For a one-time (or occasional) wiki rendering, run `ikiwiki` manually:
-
-    $ mkdir /tmp/sviki/
-    $ ikiwiki --verbose --rebuild \
-          ./adminitration/trunk/sviki \
-          /tmp/sviki
-
-The HTML files will be rendered and stored in `/tmp/sviki`.
-
-`--rebuild` should be used if rebuilding the wiki in a new directory, to
-ensure caching of previous rendering are ignored.
-
-The files can be viewed by simply visiting <file:///tmp/sviki/index.html> -
-however, navigation will be slightly problematic as IkiWiki requires a
-`DirectoryIndex` like option which automatically renders `index.html` as the
-default HTML file in a directory.
-
-### Apache configuration
-
-If you have an apache server running locally, the following configuration
-mimics the GNU Savannah settings:
-
-    Alias /maintenance "/tmp/sviki"
-    <Directory "/tmp/sviki">
-        Options Indexes
-        AllowOverride None
-        order deny,allow
-        allow from all
-        DirectoryIndex index.html
-    </Directory>
-
-### Quicker Updates
-
-For quicker rendering, use `ikiwiki` without `--rebuild` - will only update
-the changed files. In this case, it is better to clean the cache once with
-`--clean` and `--rebuild`:
-
-    # Clean the cache (just once)
-    $ ikiwiki --verbose --clean ./adminitration/trunk/sviki /tmp/sviki
-
-    # Rebuild the entire wiki (just once)
-    $ ikiwiki --verbose --rebuild ./adminitration/trunk/sviki /tmp/sviki
-
-After any further changes, just update the relevant files (without `--rebuild`,
-the default `ikiwiki` operation is `--refresh`):
-
-    $ ikiwiki --verbose ./adminitration/trunk/sviki /tmp/sviki
+And we were back in business.

Modified: trunk/sviki/ImportingCVSRepository.mdwn
===================================================================
--- trunk/sviki/ImportingCVSRepository.mdwn     2014-11-21 02:21:42 UTC (rev 
116)
+++ trunk/sviki/ImportingCVSRepository.mdwn     2014-11-21 23:52:50 UTC (rev 
117)
@@ -53,8 +53,8 @@
 to be transfered to their project's repository. Time is essential for
 such an operation since the project contributors want to work on the new
 repository on Savannah and stop using the old. When the author asks us,
-ask him to send the tarbal by mail or send a URL from which it can be
-downloaded. Make an appointement with him and guarantee that the
+ask him to send the tarball by mail or send a URL from which it can be
+downloaded. Make an appointment with him and guarantee that the
 repository will be untared on subversions with 24 hours maximum. The
 project contributor must first create a project on Savannah. When you
 have the tarball, untar it at /savannah/cvsroot/project/cvsroot/project.

Modified: trunk/sviki/SavannahServices.mdwn
===================================================================
--- trunk/sviki/SavannahServices.mdwn   2014-11-21 02:21:42 UTC (rev 116)
+++ trunk/sviki/SavannahServices.mdwn   2014-11-21 23:52:50 UTC (rev 117)
@@ -11,7 +11,7 @@
 - [[SavannahArchitecture]]
 - [[GnuArchitecture]]
 
-## Conventions Used
+## Conventions
 
 - Host names
     - `X.gnu.org` and `X.nongnu.org` point to the same IP.
@@ -27,7 +27,7 @@
     - Filenames without server name - the server is assumed to be deduced from
       the context.
 
-## Frontend
+## frontend
 
 The `frontend.sv.gnu.org` VM runs the Savannah website (the PHP code).
 
@@ -43,7 +43,7 @@
   <http://savannah.gnu.org/projects/administration>.
 
 
-## VCS
+## vcs
 
 The `vcs.sv.gnu.org` VM holds the source code (bzr,cvs,hg,git,svn) and
 webpages (cvs only) repositories, providing various access methods.
@@ -55,7 +55,7 @@
 course.)
 
 
-### VCS - project member access (commits)
+### vcs - project member access (commits)
 
 - SSH: used for read/write access to the repositories by members
     of a project.  Before using SSH, the Savannah user must upload a
@@ -73,7 +73,7 @@
     - svn: `svn co 
svn+ssh://<USER>@svn.savannah.gnu.org/<PROJECT>/<modulename>`
     - webcvs: `cvs -d:ext:<USER>@cvs.savannah.nongnu.org:/web/<PROJECT> co 
<PROJECT>`
 
-### VCS - public anonymous access (read-only)
+### vcs - public anonymous access (read-only)
 
 - RSYNC - read-only anonymous access to the raw repository files.
     configuration in `vcs:/etc/rsync.conf`, started with `xinetd` in
@@ -104,7 +104,7 @@
     configured with `xinetd` in `vcs:/etc/xinetd.d/svn`.
     - svn: `svn co svn://svn.savannah.gnu.org/texinfo/modulename`
 
-### VCS - web browsing
+### vcs - web browsing
 
 Source code repositories:
 
@@ -145,44 +145,47 @@
     - WebGit viwer: <http://web.git.savannah.gnu.org/gitweb/>
 
 
-## DL - download
+## download
 
 The `dl.sv.gnu.org` hosts the following:
 
-* The 'Downloads' (aka 'Releases') for projects hosted on GNU Sanannah.
+* The 'downloads' (aka 'releases') for projects hosted on GNU Sanannah.
 * The content of <http://audio-video.gnu.org>
-* The old GNU Arch repositories
+* The (old, obsolete) GNU Arch repositories
 
+See [[Mirmon]] for more information about the auto-redirection mentioned
+below.
+
 Configuration details:
 
-- Mirror Multiplexor for `ftp.gnu.org`:
-  **NOTE:** The official `ftp.gnu.org` server is not managed by GNU Savannah
-  administrators. This page redirects to mirrors around the world.
-    - Web Access: <http://ftpmirror.gnu.org>
+- Mirror multiplexor for `ftp.gnu.org`:
+  **NOTE:** The official `ftp.gnu.org` server is managed by the FSF,
+  and Savannah administrators have no access to it.
+    - Web access: <http://ftpmirror.gnu.org> (this url auto-redirects).
     - Apache conf: `dl:/etc/apache2/sites-available/download`
     - Uses `Apache2::Geo::Mirror` to redirect based on GeoIP.
 
-- Non-GNU Downloads/Releases
-  **NOTE:** These are mostly inteded for Non-GNU projects, as GNU projects are
-  expected to put released version on `ftp.gnu.org` as detailed in the
-  GNU Maintainer Guide, Section 11.6 'Automated FTP Uploads':
+- Savannah-hosted downloads/releases:
+  **NOTE:** These are mostly intended for Non-GNU projects, as GNU
+  projects are expected to put releases on `ftp.gnu.org`, as detailed in
+  the GNU Maintainer Information
   <https://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html>.
     - Web Access: <http://download.savannah.gnu.org/releases/>,
     - Apache conf: `dl:/etc/apache2/sites-available/download`
     - Disk Location: `dl:/srv/download/`
 
-- Mirrored Downloads/Releases
+- Mirrored downloads/releases:
     - Web Access: <http://download.savannah.gnu.org/releases-redirect/>
     - Apache conf: `dl:/etc/apache2/sites-available/download`
     - Uses `Apache2::Geo::Mirror` to redirect based on GeoIP.
 
-- Mirror-multiplexing downloads.
-    - **NOTE:** These should not be used directly by end-users.
+- Savannah top-level download urls:
+    - **NOTE:** These are not especially useful for end-users.
     - <http://download-mirror.savannah.gnu.org>
     - <http://ctan-mirror.savannah.gnu.org>
     - Apache conf: `dl:/etc/apache2/sites-available/download`
 
-- GNU Audio-Video Host:
+- GNU audio-video host:
     - Web Access: <http://audio-video.gnu.org> and 
<https://audio-video.gnu.org>
     - HTTP Apache conf: `dl:/etc/apache2/sites-available/audio-video`
     - HTTPS apache conf: `dl:/etc/apache2/sites-available/audio-video-ssl`
@@ -197,7 +200,7 @@
 
 - RSYNC Access
     - rsync start-up configuration file: `dl:/etc/default/rsync`. The
-      configuration uses `xinet`, and so all other options in this file are
+      configuration uses `xinetd`, and so all other options in this file are
       ignored. Instead, the parameters in `dl:/etc/xinetd.d/rsync` are used.
     - RSYNC Configuration file: `dl:/etc/rsyncd.conf`.
       Available modules:
@@ -210,7 +213,7 @@
     - All GNU Savannah members can access RSYNC services, using the SSH public
       key configured on GNU Savannah website (see SSH section of VCS server,
       above).
-    - Downlaod a file using SSH Public KEY + GNU Savannah User:
+    - Download a file using SSH Public KEY + GNU Savannah User:
       `rsync -avhP <USER>@dl.sv.gnu.org:/releases/<PROJECT>/<FILE> LOCALFILE`
     - Uploading a file (only to projects in which USER is a member):
       `rsync -avhP LOCALFILE  
<USER>@dl.sv.gnu.org/srv/download/<PROJECT>/<FILE>`
@@ -219,12 +222,10 @@
     - `sftp <USER>@dl.sv.gnu.org`
 
 
-Downloads are multiplexed across mirrors through [[Mirmon]].
+## internal
 
-## Internal
-
 The `internal.sv.gnu.org` VM runs the GNU Savannah database (mysql),
-and the Domain name server for GNU Savannah VMs.
+and dns (bind) for GNU Savannah VMs.
 
 * DNS server - `bind`
     * startup configuration file: `int:/etc/default/bind9`
@@ -233,19 +234,20 @@
         * `int:/etc/bind/named.conf` which includes
         * `int:/etc/bind/named.conf.local` which includes
         * `int:/etc/bind/master/savannah.{gnu,nongnu}.org` which include:
-        * `int:/etc/bind/master/savannah.header` - Name servers and Serial
-          update timestamp
+        * `int:/etc/bind/master/savannah.header` - name servers and
+          serial update timestamp
         * `int:/etc/bind/master/savannah.footer` - `A` and `CNAME` dns records
           for all GNU Savannah VMs (e.g. `dl` / `vcs` / `fe`)
     * The server does *not* answer DNS queries directly. Instead, it propagates
       its DNS configuration to `ns1.gnu.org`, and only answers queries from
       `ns1.gnu.org` (enforced with `iptables` rules).
     * Information about updating DNS is here: [[DNS]].
+
 * GNU Savannah Database - `mysql`
-    * Used in two contexes:
+    * Used in two contexts:
         1. The database for the GNU Savannah PHP code (based on old SourceForge
-           code base). These are the GNU Savannah registered users, registered
-           projects, 'trackers' ( tasks, support tickets, bug reports), etc.  
+           code base). These are the registered users on Savannah, registered
+           projects, trackers (tasks, bugs, etc.), etc.
            Users upload their public SSH keys to GNU Savannah web interface,
            and those are also stored in the database.
         2. All VMs which allow SSH access based on public SSH keys connect to
@@ -257,7 +259,7 @@
       `iptables` rules).
     * MySQL configuration file: `int:/etc/mysql/my.cnf`
 
-## MGT - management
+## mgt - management
 
 --moretowrite--
 The `mgt.sv.gnu.org` VM runs munin, and what else?  Provides access

Modified: trunk/sviki/UserAuthentication.mdwn
===================================================================
--- trunk/sviki/UserAuthentication.mdwn 2014-11-21 02:21:42 UTC (rev 116)
+++ trunk/sviki/UserAuthentication.mdwn 2014-11-21 23:52:50 UTC (rev 117)
@@ -1,6 +1,6 @@
-## User Authentication on GNU Savannah Systems
+## User authentication on GNU Savannah systems
 
-### User Account Creation Work-flow
+### User account creation
 
 1. Any person can register a GNU Savannah user account using the web interface
    at <https://savannah.gnu.org/account/register.php> .
@@ -14,7 +14,7 @@
 Users' information is can be viewed on the GNU Savannah web site.
 Example for user 'agn': <https://sv.gnu.org/users/agn/> .
 
-### Database Access
+### Database access
 
 On `internal.sv.gnu.org`, the following SQL commands can be used to examine
 user accounts:
@@ -33,11 +33,10 @@
     
+---------+-----------+----------+--------------+-----------+-----------------+
 
 The `authorized_keys` field contains all the user's SSH public keys,
-concatenated with `###` delimiter, as a one-line string.
+concatenated with a `###` delimiter, as a one-line string.
+(The database currently contains some malformed/invalid keys - when
+users uploaded invalid keys.)
 
-**NOTE**: The database currently contains some malformed/invalid keys - when
-users uploaded invalid keys.
-
 ### User/group accounts
 
 In GNU Savannah systems, there is a unix user for *each* GNU Savannah
@@ -51,11 +50,12 @@
     vcs:~# getent group datamash
     datamash:x:77800:agn
 
-Access control is based on unix group membership.
+Access control is based on Unix group membership.
 
 Example:
 
-The GNU Awk project (<http://sv.gnu.org/p/gawk>) has six members as of Nov. 
2014
+The `gawk` (GNU Awk) project (<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:
@@ -69,7 +69,7 @@
     vcs:~# getent group gawk
     gawk:x:6731:ajschorr,arnold,eliz,jkahrs,scldad,wb8tyw
 
-### Authentication Mechanisms
+### 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
@@ -104,12 +104,14 @@
      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 account 
number).
+(Notice the `uidNumber` from the mysql database is the user's Unix
+uid.)
 
-The SQL statements (to extract information from the mysql database on 
`internal`)
-are defined in `dl:/etc/libnss-mysql.cfg` and `vcs:/etc/libnss-mysql.cfg`.
+The SQL statements (to extract information from the mysql database on
+`internal`) are defined in `dl:/etc/libnss-mysql.cfg` and
+`vcs:/etc/libnss-mysql.cfg`.
 
-### SSH Authentication
+### SSH authentication
 
 The file `/etc/ssh/sshd_config` on `dl:` and `vcs:` servers contains the
 following statement:
@@ -125,7 +127,7 @@
 > 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 differntly named option `AuthorizedKeysCommand`.  
+> using a differently named option `AuthorizedKeysCommand`.  
 > This option (and not `AuthorizedKeysExec`) is available in most OpenSSH
 > installations.  
 > If GNU Savannah servers are ever upgraded, these configuration files should 
 > be
@@ -137,7 +139,7 @@
 
 The user is therefore known, and OpenSSH needs to find the user's public keys.
 The `/usr/local/bin/sv_get_authorized_keys` perl script simply queries
-the SSH public keys of the user (while splitting them by `###` delimiter):
+the SSH public keys of the user (splitting them by `###` delimiter):
 
     ...
     my ($authorized_keys) = $dbd->selectrow_array(q[




reply via email to

[Prev in Thread] Current Thread [Next in Thread]