Saturday, February 25, 2012

Reestablishing access

After last year's break-in, the new regime for access to resources changed, and everyone had to reestablish access under the new system. I've only recently finished all the required steps so that I can both host the man-pages Git repository on and upload release tarballs to the download directory.

To remind myself, and perhaps help others who may in the future need to do some of these steps, here's what I needed to do (corrections and comments welcome):

  1. As per H. Peter Anvin's instructions, create a (new) PGP key.
  2. Upload the PGP public key to the keyserver system (I used, but any of the interconnected keyserver systems will do).
  3. Get my PGP key signed by others in the ecosystem, so that my key can be considered trustworthy. Luckily, I was at LinuxCon in Prague last year when a lot other people, including many of the kernel developers at the collocated Kernel Summit, were trying to do exactly the same thing, so I managed to get a healthy set of signatures on my key. One way or another, you need to get such signatures on your key. (If you don't come into regular contact with some core kernel developers, or see them at conferences, this map may help.)
  4. Send the key ID and fingerprint to
  5. Since my key was well signed, I soon afterward received an email from the admins. That mail was encrypted using my public PGP key, and after decrypting, decompressing, and untarring, it contained three files:
    • mtk: A private ssh key generated for me by the admins. (The file has the same name as my username.) The public key is stored on The private key is needed for gitolite and kup access.
    • welcome.readme: Various information, including
      • The name of the host providing gitolite access (
      • My username on that host (mtk)
      • The password for my SSH key
      • Some basic information on working with gitolite
    • ssh_keygen.output: Information on the generation of my RSA key pair.
  6. Configure SSH to know about my new key:
    • copy (and rename) the file mtk to ~/.ssh/
    • add the new key to my SSH config, by adding the following lines to ~/.ssh/config:
       IdentityFile ~/.ssh/
  7. Use ssh-keygen to change the password on my SSH key to something more memorable.
  8. Create a new empty man-pages Git repo on
    $ git clone
  9. Set up my local man-pages Git repo to use gitolite. No software installation is required on the client side to use gitolite, but the local Git repo must be configured to use the gitolite protocol. Now, I have the following in my .git/config:
    [remote "origin"]
     url =
     fetch = +refs/heads/*:refs/remotes/origin/*
    [branch "master"]
     remote =
     merge = refs/heads/master
    [remote ""]
     url =
     push = +refs/heads/master:refs/heads/master
  10. Push my Git repo to
    $ git push
    $ git push --tags
  11. Set a description for the repo:
  12. $ echo "Linux man pages Sections 2, 3, 4, 5, and 7" | \
        ssh setdesc /pub/scm/docs/man-pages/man-pages.git
    Enter passphrase for key '/home/mtk/.ssh/':
    $ ssh getdesc /pub/scm/docs/man-pages/man-pages.git
    Enter passphrase for key '/home/mtk/.ssh/':
    Linux man pages Sections 2, 3, 4, 5, and 7
    Update, August 2013: The way to do this nowadays is something like:
    $ ssh desc pub/scm/docs/man-pages/man-pages "Linux man pages Sections 2, 3, 4, 5, and 7"
  13. Install kup, by cloning the kup Git repo, which provides a perl script that is the kup client.
    $ git clone git://
    Along the way, I installed gnupg-agent and libconfig-simple-perl. This was a recently rebuilt system, so some pieces like this were still missing; the libconfig-simple-perl package was essential to run the kup perl script. (There are kup packages or kup-client packages available for RPM-based systems, and a kup-client package for Debian-based systems.)
  14. Set up a kup config file, ~/.kuprc, containing:
    host =
    rsh = /usr/bin/ssh -a -x -k -T
    As noted in a Nov 2011 message to the users mailing list, is the domain used for kup uploads on
  15. Configure SSH to use my SSH key on, by adding the following lines to ~/.ssh/config:
     IdentityFile ~/.ssh/
  16. Sign and upload a man-pages tarball to the directory to which the admins had already given me access:
    $ gpg --detach-sig man-pages-3.35.tar
    $ ls man-pages-3.35.tar*
    man-pages-3.35.tar  man-pages-3.35.tar.sig
    $ kup put man-pages-3.35.tar man-pages-3.35.tar.sig \
    Enter passphrase for key '/home/mtk/.ssh/':
    7813120 [==================================================] 100%
    Compressing: .bz2:100% .gz:100% .xz:100%
    And then allow a moment before checking that the upload is visible at
Updated 2012-02-27 to add a piece to step 10, and add a step (11) to set the repo description.

Sunday, February 19, 2012

Seeking a Solaris test system

The Solaris system that I used for comparative tests connected with the man-pages project (and also for code in The Linux Programming Interface), has gone away. If you (or someone you know) would be able to provide me with ssh access to a Solaris box in order to run test programs, that would be much appreciated. I'd only be using it occasionally (probably weeks between logins) and running small test programs (we're talking code with minimal CPU and RAM requirements). Please email me at

Wednesday, February 15, 2012

Git repo and release tarballs restored to

I've now done most of the steps to reestablish access on The man-pages release tarballs can once more be downloaded from And the man-pages Git repo is back in its original location, and can be cloned via:

$ git clone
(For the moment, I'll probably maintain the duplicate upstream repo on GitHub, but I may well delete it in the near future, unless some folk tell me they find it useful.)