Jump to content

FeministWiki:Server setup: Difference between revisions

Line 145: Line 145:
We want to make a first run of this copy process purely for testing purposes, before shutting down the services on the old server and repeating it to ensure integrity of live data.
We want to make a first run of this copy process purely for testing purposes, before shutting down the services on the old server and repeating it to ensure integrity of live data.


=== Copy over LDAP databases ===
=== Copy over /var/www ===


Stop the LDAP server and delete the existing configuration and data '''on the new server (careful there)''':
This is very simple but takes a lot of time to finish.  '''Run it from the old server:'''


  systemctl stop slapd
  rsync -a --delete /var/www/ root@feministwiki.dev:/var/www
rm -r /etc/ldap/slapd.d/*
rm /var/lib/ldap/data.mdb


Then copy over the config and data by running these commands from the old server:
Note that the trailing slash in <code>/var/www/</code> is important; if not provided, it will copy the directory to <code>/var/www/www</code> on the new server.


slapcat -n 0 | ssh feministwiki.dev 'sudo -u openldap slapadd -n 0 -F /etc/ldap/slapd.d'
While this command is running, you can do the next two steps in parallel.
slapcat -n 1 | ssh feministwiki.dev 'sudo -u openldap slapadd -n 1'
 
Note:
 
'''There might be incompatible changes between OpenLDAP (aka <code>slapd</code>) versions which require manual editing of the <code>slapcat</code> output before it's read in on the new server with <code>slapadd</code>.'''
 
Here's one example that occurs when updating from OpenLDAP 2.4.42 or earlier to 2.4.43 or later: the ppolicy overlay has a new attribute in the newer version, so if you simply run the commands above, the first one (the one that copies the config database) will produce the following error message:
 
User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined
 
The solution is as follows:
 
# On the new server, open <code>/etc/ldap/schema/ppolicy.ldif</code> and search for <code>pwdMaxRecordedFailure</code>.  You will note that there is a <code>olcAttributeTypes: ...</code> entry that defines it, and also it's listed in the <code>MAY</code> attributes block of the <code>olcObjectClasses: ...</code> entry that defines the <code>pwdPolicy</code> object class.
# On the old server, save the output of <code>slapcat -n 0</code> to a file, open the file, and search for the block where the <code>ppolicy</code> schema is defined.  It should start with the line <code>dn: cn={4}ppolicy,cn=schema,cn=config</code> (the <code>{4}</code> part might contain a different integer, that's OK).  There, note that the <code>olcAttributeTypes: ...</code> entry for <code>pwdMaxRecordedFailure</code> is missing, and also it's not listed in the <code>MAY</code> list of the <code>pwdPolicy</code> object class definition.  Copy over the attribute type definition from the <code>ppolicy.ldif</code> file on the new server, and amend the <code>MAY</code> list to include it.
 
The above is explained only for instructive purposes, since this particular fix will already have been applied by the time someone reads this guide.  It's meant to give you an idea as to how backwards incompatible changes in OpenLDAP schema files can be amended when migrating to a newer version.  (Also, no such clear explanation of the fix seems to be found anywhere on the web, so maybe someone who searches the error message above will come upon this guide and be happy!)


=== Copy over SQL databases ===
=== Copy over SQL databases ===


Stop the database server '''on the new server (careful)''':
Stop the database server '''on the new server (careful!)''':


  systemctl stop mariadb
  systemctl stop mariadb


The following command can be used to create a dump of all databases and import it on the new server.  You can use the <code>show databases;</code> command in the SQL console to make sure that the list of databases is complete.  (Unfortunately they have to be listed manually, because using the <code>--all-databases</code> option includes system databases that we don't want to copy.)
Then run the following command from the old server:
 
You have to run it from the old server:


  mysqldump -u root -p"$(cat /root/pwd/mysql)" \
  mysqldump -u root -p"$(cat /root/pwd/mysql)" \
Line 199: Line 179:
   | ssh root@feministwiki.dev 'mysql -u root -p"$(cat /root/pwd/mysql)"'
   | ssh root@feministwiki.dev 'mysql -u root -p"$(cat /root/pwd/mysql)"'


=== Copy over /var/www ===
You can use the <code>show databases;</code> command in the SQL console to make sure that the list of databases is complete.  Unfortunately they have to be listed manually, because using the <code>--all-databases</code> option includes system databases that we don't want to copy.
 
While the above command is still running, you can do the next step in parallel.
 
=== Copy over LDAP databases ===
 
Stop the LDAP server and delete the existing configuration and data '''on the new server (careful!)''':
 
# Commands to run on the NEW (fresh) server:
systemctl stop slapd
rm -r /etc/ldap/slapd.d/*
rm /var/lib/ldap/data.mdb
 
Then copy over the config and data by running these commands from the old server:
 
slapcat -n 0 | ssh feministwiki.dev 'sudo -u openldap slapadd -n 0 -F /etc/ldap/slapd.d'
slapcat -n 1 | ssh feministwiki.dev 'sudo -u openldap slapadd -n 1'
 
Note:
 
'''There might be incompatible changes between OpenLDAP (aka <code>slapd</code>) versions which require manual editing of the <code>slapcat</code> output before it's read in on the new server with <code>slapadd</code>.'''
 
Here's one example that occurs when updating from OpenLDAP 2.4.42 or earlier to 2.4.43 or later: the ppolicy overlay has a new attribute in the newer version, so if you simply run the commands above, the first one (the one that copies the config database) will produce the following error message:


This is very simple but takes a lot of time to finish; run it from the old server:
User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined


  rsync -a --delete /var/www/ root@feministwiki.dev:/var/www
The solution is as follows:
 
# On the new server, open <code>/etc/ldap/schema/ppolicy.ldif</code> and search for <code>pwdMaxRecordedFailure</code>. You will note that there is a <code>olcAttributeTypes: ...</code> entry that defines it, and also it's listed in the <code>MAY</code> attributes block of the <code>olcObjectClasses: ...</code> entry that defines the <code>pwdPolicy</code> object class.
# On the old server, save the output of <code>slapcat -n 0</code> to a file, open the file, and search for the block where the <code>ppolicy</code> schema is defined.  It should start with the line <code>dn: cn={4}ppolicy,cn=schema,cn=config</code> (the <code>{4}</code> part might contain a different integer, that's OK). There, note that the <code>olcAttributeTypes: ...</code> entry for <code>pwdMaxRecordedFailure</code> is missing, and also it's not listed in the <code>MAY</code> list of the <code>pwdPolicy</code> object class definition.  Copy over the attribute type definition from the <code>ppolicy.ldif</code> file on the new server, and amend the <code>MAY</code> list to include it.


Note that the trailing slash in <code>/var/www/</code> is important; if not provided, it will copy the directory to <code>/var/www/www</code> on the new server.
The above is explained only for instructive purposes, since this particular fix will already have been applied by the time someone reads this guide.  It's meant to give you an idea as to how backwards incompatible changes in OpenLDAP schema files can be amended when migrating to a newer version.  (Also, no such clear explanation of the fix seems to be found anywhere on the web, so maybe someone who searches the error message above will come upon this guide and be happy!)


== Test ==
== Test ==