FeministWiki

« FeministWiki:Server setup » : différence entre les versions

Page de projet Discussion

FeministWiki:Server setup (voir la source)

Version du 20 août 2021 à 01:45

93 octets ajoutés ,  20 août 2021
→‎Copying over live data
Ligne 149 : Ligne 149 :
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 /var/www ===
Note that although some of the steps described in this section take a long time to finish, they can be done in parallel.
 
=== 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:
 
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!)
 
=== Contents of /var/www ===


This is very simple but takes a lot of time to finish.  '''Run it from the old server:'''
This is very simple but takes a lot of time to finish.  '''Run it from the old server:'''
Ligne 157 : Ligne 188 :
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.
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.


While this command is running, you can do the next two steps in parallel.
=== SQL databases ===
 
=== Copy over SQL databases ===


Run the following command from the old server:
Run the following command from the old server:
Ligne 179 : Ligne 208 :
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.
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.
=== Emails ===
 
=== 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:
 
User Schema load failed for attribute "pwdMaxRecordedFailure". Error code 17: attribute type undefined


The solution is as follows:
This is a simple one.  Run this command from the old server:


# 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.
  rsync -a --delete /home/vmail/ root@feministwiki.dev:/home/vmail
# 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!)


=== Mailman data ===
=== Mailman data ===
Récupérée de « https://feministwiki.org/fr/wiki/Spécial:MobileDiff/1160 »