A common user question is that they are unable to change their SSH
key. This can happen if their email client somehow has trouble sending
a PGP signature correctly. Most often than not, this is because their
email client does a line wrap or somehow corrupts the OpenPGP
signature in the email.
A good place to start looking for such problems is the log files on
the LDAP server (currently alberti). For example, this has a trace
of all the emails received by the changes@ alias:
A common problem is people using --clearsign instead of --sign
when sending an SSH key. When that hapepns, many email clients
(including Gmail) will word-wrap the SSH key after the comment,
breaking the signature. For example, this might happen:
-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKxqYYEeus8dRXBHhLsp0SjH7ut2X8UM9hdXN=wJIl89otcJ5qKoXj90K9hq8eBjG2KuAZtp0taGQHqzBOFK+sFm9/gIqvzzQ07Pn0xtkmg10Hunq=vPKMj4gDFLIqTF0WSPA2E6L/TWaeVJ+IiGuE49j+0Ohd7UFDEquM1H/zno22vIEm/dxWLPWD9gG=MmwBghvfK/dRyzSEDGlAVeWLzoIvVOG12/ANgic3TlftbhiLKTs52hy8Qhq/aQBqd0McaE4JGxe=9k71OCg+0WHVS4q7HVdTUqT3VFFfz0kjDzYTYQQcHMqPHvYzZghxMVCmteNdJNwJmGSNPVaUeJG=MumJ9anarcat@curie-----BEGIN PGP SIGNATURE-----[...]-----END PGP SIGNATURE-----
Using --sign --armor will work around this problem, as the original
message will all be ascii-armored.
Restoring from backups
There's no special backup procedures for the LDAP server: it's backed
up like everything else in the howto/backup system.
To restore the OpenLDAP database, you need to head over the Bacula
director, and enter the console:
ssh -tt bacula-director-01 bconsole
Then call the restore command and select 6: Select backup for a client before a specified time. Then pick the server (currently
alberti.torproject.org) and a date. Then you need to "mark" the
cd /var/lib/ldapmark *done
Then confirm the restore. The files will end up in
/var/tmp/bacula-restores on the LDAP server.
The next step depends on whether this is a partial or total
If you only need to access a specific field or user or part of the
database, you can use slapcat to dump the database from the restored
files even if the server is not running. You first need to "configure"
a "fake" server in the restore directory. You will need to create two
files under /var/tmp/bacula-restores:
Note that this will only work on the LDAP host itself or on
whitelisted hosts which are few right now. This is mostly documented
for TPA members.
Modifying the schema
If you need to add, change or remove a field in the schema of the
LDAP database, it is a different, and complex operation. You will only
need to do this if you launch a new service that (say) requires a new
password specifically for that service.
The schema is maintained in the userdir-ldap.git repository. It
is stored in the userdir-ldap.schema file. Assuming the modified
object is a user, you would need to edit the file in three places:
as a comment, in the beginning, to allocate a new field, for
This is purely informative, but it is important as it serves as a
central allocation point for that numbering system. Also note that
the entire schema lives under a branch of the Debian.org IANA OID
create the actual attribute, somewhere next to a similar attribute
or after the previous OID, in this case we created an attributed
called mailPassword right after rtcPassword, since other
passwords were also grouped there:
attributetype ( 126.96.36.199.4.1.95188.8.131.52.48 NAME 'mailPassword' DESC 'mail password for SMTP' EQUALITY octetStringMatch SYNTAX 184.108.40.206.4.1.14220.127.116.11.40 )
finally, the new attribute needs to be added to the
objectclass. in our example, the field was added alongside the
other password fields in the debianAccount objectclass, which
looked like this after the change:
objectclass ( 18.104.22.168.4.1.9522.214.171.124.1 NAME 'debianAccount' DESC 'Abstraction of an account with POSIX attributes and UTF8 support' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber ) MAY ( userPassword $ loginShell $ gecos $ homeDirectory $ description $ mailDisableMessage $ sudoPassword $ webPassword $ rtcPassword $ mailPassword $ totpSeed ) )
Once that schema file is propagated to the LDAP server, this should
automatically be loaded by slapd when it is restarted (see
below). But the ACL for that field should also be modified. In our
case, we had to add the mailPassword field to two ACLs:
--- a/userdir-ldap-slapd.conf.in+++ b/userdir-ldap-slapd.conf.in@@ -54,7 +54,7 @@ access to attrs=privateSub by * break # allow users write access to an explicit subset of their fields-access to attrs=c,l,loginShell,ircNick,labeledURI,icqUIN,jabberJID,onVacation,birthDate,mailDisableMessage,gender,emailforward,mailCallout,mailGreylisting,mailRBL,mailRHSBL,mailWhitelist,mailContentInspectionAction,mailDefaultOptions,facsimileTelephoneNumber,telephoneNumber,postalAddress,postalCode,loginShell,onVacation,latitude,longitude,VoIP,userPassword,sudoPassword,webPassword,rtcPassword,bATVToken+access to attrs=c,l,loginShell,ircNick,labeledURI,icqUIN,jabberJID,onVacation,birthDate,mailDisableMessage,gender,emailforward,mailCallout,mailGreylisting,mailRBL,mailRHSBL,mailWhitelist,mailContentInspectionAction,mailDefaultOptions,facsimileTelephoneNumber,telephoneNumber,postalAddress,postalCode,loginShell,onVacation,latitude,longitude,VoIP,userPassword,sudoPassword,webPassword,rtcPassword,mailPassword,bATVToken by self write by * break@@ -64,7 +64,7 @@ access to attrs=c,l,loginShell,ircNick,labeledURI,icqUIN,jabberJID,onVacation,bi ## # allow authn/z by anyone-access to attrs=userPassword,sudoPassword,webPassword,rtcPassword,bATVToken+access to attrs=userPassword,sudoPassword,webPassword,rtcPassword,mailPassword,bATVToken by * compare # readable only by self
If those are the only required changes, it is acceptable to directly
make those changes directly on the LDAP server, as long as the exact
same changes are performed in the git repositoy.
It is preferable, however, to build and
uploaduserdir-ldap as a Debian package instead.
LDAP is not accessible to the outside world, so you need to be behind
the firewall. Once that's resolved, you can use ldapvi(1) or
ldapsearch(1) to inspect the database. User documentation on that
process is in doc/accounts.
The LDAP setup at Tor is based on the one from
Debian.org. /etc/password and groups files are synchronized from
the central LDAP server using the sshdist account, which means
things keep working when LDAP is down. Most operations can be
performed on the db.torproject.org site or by email.
DNS zone files are also managed (at least partly) in LDAP. This is
automated through cron jobs, but if you're in a hurry, the zones get
generated by ud-generate on alberti (as sshdist?) and replicate
(?) on nevii with ud-replicate (as root?).