Tag Archives: server

Posted on
by

So, I recently performed some long overdue upgrades on my work computers, which involved performing a complete from scratch rebuild of the house server.

This involved, among other things, moving the OpenLDAP directory in which I store, among other things, my email address book. Easier said than done.

Previously, when I had done this, it was a simple matter of installing slapd, copying /etc/ldap and /var/lib/ldap and restarting slapd. This time proved more tricky; slapd initially spat out errors complaining that the database was corrupt. Check out https://www.sapphire.net/mss/incident-response-services/ for more information on the benefits of improving your cybersecurity at work.

Fixing the corrupt database could be done in one of two ways: 1) deleting /var/lib/ldap/DB_CONFIG, forcing slapd to recover the database, or 2) running db_recover directly. After this was done, slapcat displayed the directory as expected, and slapd restarted, however any queries on the database – via phpldapadmin, ldapsearch or the email address book – caused the answering slapd process to lock with no error. Each subsequent query would cause another slapd thread to lock, eventually bringing down the whole ldap server.

Hmm…

I’m not entirely sure what was going on, perhaps it was a bug in my particular version of slapd, or perhaps it was the fact that I was moving from 32bit to 64bit, who knows. I eventually found a solution, and I write this down primarily as a note for myself.

The workaround

    1. Install slapd, copy the config and db over, then run a db recover on the database:

      db_recover -v -h /var/lib/ldap

    2. You should now be able to list the directory with slapcat, so dump it to a file:

      slapcat > /tmp/directory.ldif

    3. Next, we need to nuke the database and force slapd to create a fresh blank database. There’s probably an easy way of doing this, but the quickest way I found was to delete /var/lib/ldap/* and reinstall slapd:

      cd /var/lib/ldap; rm *; apt-get remove slapd; apt-get install slapd.

The apt-get remove will remove the program but by default it’ll leave your configuration intact, if it doesn’t you might need to copy your config back as well.

  1. Next, stop slapd and import your ldif file.

    /etc/init.d/slapd stop; slapadd -l /tmp/directory.ldif; /etc/init.d/slapd start

If you had the same problem as me, your OpenLDAP directory should now be back in place, imported into the new database. For me, my address book now functions correctly and phpldapadmin no longer hangs.

There are probably easier ways, but I was tired. Let me have your thoughts in the comments below!

Posted on
by

Gitosis is a GIT server system which, using ssh, lets you run a central git repository in much the same way as github does. This let you manage multiple developers easier, as well as providing a convenient place to access repositories while out and about, and for deployment.

Unfortunately, gitosis is no longer maintained, and has been removed from more recent versions of the major linux distributions. This was preventing me from performing some much needed server upgrades, so it was therefore necessary to migrate to another bit of software.

Gitolite is the recommended replacement for Gitosis, and acts as a drop in replacement. Perform the migration right, and you’re users will never notice that you did anything at all.

So, in hopes that this may be useful to someone, here’s how I migrated my gitosis server over.

The initial setup

The initial server configuration was as follows:

  • Debian server
  • Gitosis installed as user “git”

My goal was to replace the gitosis server, still on the GIT user, so my users would not need to modify any of the remote repository paths in any checked out repositories.

Migration

Start off by taking a backup, just incase this goes horribly wrong, then…

  1. Belts and braces, get rid of the old gitosis update hooks and prevent any new sessions by removing the authorized_keys file: mv git/repositories/gitosis-admin/hooks/post-update git/repositories/gitosis-admin/hooks/post-update.old; mv git/.ssh/authorized_keys git/.ssh/authorized_keys.old
  2. Move the old gitosis home directory out of the way: mv git git_old
  3. Install gitolite: apt-get install gitolite
  4. I then needed to reconfigure gitolite so it used the same user id as the previous gitosis install: dpkg-reconfigure gitolite
  5. Copy your old repositories to your newly created git directory: cp -a git_old/repositories git/
  6. Gitolite had trouble using my existing public ssh keys for the admin account, probably because they were already used as login keys, or perhaps because they were in the foo@bar.pub format. Either way, the simplest thing was to generate an admin key specifically for gitolite administration.
    1. Generate a new key, making sure you have at least one “.” after the “@”, so that the key looks like an email address: ssh-keygen -t rsa -C "gitoliteadmin@myserver.local" -f gitoliteadmin@myserver.local
    2. Make sure root, or whoever is going to admin your gitolite repo has a copy of these keys, as you’ll need them to make any configuration changes. You can simplify this somewhat by making a host alias for the gitolite admin user in the ~/.ssh/config file

      Host gitolite-admin
          HostName myserver.local
          User git
          IdentityFile ~/.ssh/gitoliteadmin@myserver.local

  7. On the server, change to the git user: su git
  8. Then initialise the gitolite repository, passing the location of your newly created admin key: gl-setup /path/to/gitoliteadmin@myserver.local
  9. Clone the gitolite-admin repository, note the use of the gitolite-admin host repository: git clone git@gitolite-admin
  10. Convert your gitosis settings file using gl-conf-convert, which if you’re running this on the server, can be found in /usr/share/gitolite. This script can be run in isolation, so it’s ok to copy it about if you need to run this on a different machine: /path/to/gl-conf-convert < /path/to/gitosis-admin/gitosis.conf >> /path/to/gitolite-admin/conf/gitolite.conf
  11. Now, check your gitolite.conf for errors, and if ok commit and push your changes. Since I had a number of keys in the format of user@machine, I had to change the occurrence of those users in the file to just the username before the “@” character. E.g. foo@machine becomes just foo
  12. Things should now be working on gitolite. You can verify that gitolite rather than gitosis is fielding your requests using ssh: ssh git@myserver.local info, you should see a list of the repositories on the server that your user has access to.

All being well, your migration over to gitolite should now be complete, and remotes in any existing clones of repositories on the server should still function.

Hope this helps!

Posted on
by

Sometime in the next couple of weeks I will be performing a major software upgrade on the server that hosts this blog, as well as a number of services I host on behalf of my clients.

What this means to you

Hopefully nothing.

All being well, there should be no significant downtime and the services hosted by this server will continue uninterrupted.

If you are a client of mine, I will be contacting you directly in the next few days with more details about when the upgrade will be performed and how it might affect you.

I apologise in advance for any possible inconvenience this may cause.