FeministWiki:Server setup: Difference between revisions

Change all uses of the code HTML tag to the "C" template.
(Change all uses of the code HTML tag to the "C" template.)
Line 7: Line 7:
=== Make feministwiki.dev point to the new server ===
=== Make feministwiki.dev point to the new server ===


During setup and testing of the new server, we want to make it accessible under the '''feministwiki.dev''' domain.  So change the <code>A</code> entry of the feministwiki.dev DNS settings to point to the IP address of the new server.
During setup and testing of the new server, we want to make it accessible under the '''feministwiki.dev''' domain.  So change the {{C|A}} entry of the feministwiki.dev DNS settings to point to the IP address of the new server.


=== Update & upgrade ===
=== Update & upgrade ===
Line 36: Line 36:
=== Fetch scripts & config repo ===
=== Fetch scripts & config repo ===
    
    
Set up GitHub ssh access by copying the <code>.ssh/id_rsa</code> from the old server.  After that:
Set up GitHub ssh access by copying the {{C|.ssh/id_rsa}} from the old server.  After that:
    
    
  cd ~
  cd ~
Line 43: Line 43:
  sh repo/decrypt-pwd.sh
  sh repo/decrypt-pwd.sh


The decryption script will prompt you for a password the first time it's used.  Enter the password stored in <code>/root/pwd/meta</code> on the old server.
The decryption script will prompt you for a password the first time it's used.  Enter the password stored in {{C|/root/pwd/meta}} on the old server.


=== Set up firewall ===
=== Set up firewall ===
Line 92: Line 92:
  apt-get install slapd
  apt-get install slapd


If any installation asks you for a password, remember that most passwords are found in <code>/root/pwd</code>.
If any installation asks you for a password, remember that most passwords are found in {{C|/root/pwd}}.


Example for installing ejabberd from backports instead:
Example for installing ejabberd from backports instead:
Line 170: Line 170:
  ufw delete allow 80
  ufw delete allow 80


Our <code>letsencrypt-refresh</code> script makes sure that the cert files are found in <code>/etc/fw-certs</code> and that the private key and cert-and-key bundle are owned by the "ssl-cert" group and are readable by group members.  A number of users have to be added to this group so they can read said files:
Our {{C|letsencrypt-refresh}} script makes sure that the cert files are found in {{C|/etc/fw-certs}} and that the private key and cert-and-key bundle are owned by the "ssl-cert" group and are readable by group members.  A number of users have to be added to this group so they can read said files:


  adduser ejabberd ssl-cert
  adduser ejabberd ssl-cert
Line 195: Line 195:
==== Breaking changes in OpenLDAP ====
==== Breaking changes in OpenLDAP ====


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>.
There might be incompatible changes between OpenLDAP (aka {{C|slapd}}) versions which require manual editing of the {{C|slapcat}} output before it's read in on the new server with {{C|slapadd}}.


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


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 {{C|/var/www/}} is important; if not provided, it will copy the directory to {{C|/var/www/www}} on the new server.


=== SQL databases ===
=== SQL databases ===
Line 234: Line 234:
   | gzip | ssh root@feministwiki.dev 'gunzip | /root/bin/sql'
   | gzip | ssh root@feministwiki.dev 'gunzip | /root/bin/sql'


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 {{C|show databases;}} 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 {{C|--all-databases}} option includes system databases that we don't want to copy.


=== Emails ===
=== Emails ===
Line 323: Line 323:
=== Copy over the live data one more time ===
=== Copy over the live data one more time ===


The techniques and commands described above in the section '''Copying over live data''' are ''idempotent'', meaning you can simply repeat them and they will make sure that the new copy of the live data is fresh and doesn't leave any outdated data on the new server.  (For instance, the <code>--delete</code> argument to the <code>rsync</code> command and the <code>--add-drop-database</code> argument to the <code>mysqldump</code> command help to make sure of this.)
The techniques and commands described above in the section '''Copying over live data''' are ''idempotent'', meaning you can simply repeat them and they will make sure that the new copy of the live data is fresh and doesn't leave any outdated data on the new server.  (For instance, the {{C|--delete}} argument to the {{C|rsync}} command and the {{C|--add-drop-database}} argument to the {{C|mysqldump}} command help to make sure of this.)


So in short, just repeat the steps from that section exactly one more time.
So in short, just repeat the steps from that section exactly one more time.
Line 341: Line 341:
You only have to change three DNS entries, since most of the subdomains work via CNAME entries:
You only have to change three DNS entries, since most of the subdomains work via CNAME entries:


* The main <code>A</code> entry for <code>@</code> (self-reference i.e. feministwiki.org)
* The main {{C|A}} entry for {{C|@}} (self-reference i.e. feministwiki.org)
* The <code>A</code> entry for <code>smtp</code> since this is not allowed to be a CNAME
* The {{C|A}} entry for {{C|smtp}} since this is not allowed to be a CNAME
* The <code>A</code> entry for <code>xmpp</code> since this is not allowed to be a CNAME
* The {{C|A}} entry for {{C|xmpp}} since this is not allowed to be a CNAME


==== feministwiki.net, feministwiki.de, fem.wiki, fffrauen.de ====
==== feministwiki.net, feministwiki.de, fem.wiki, fffrauen.de ====


For these, you only have to change the main <code>A</code> entry, since they don't use SMTP or XMPP.
For these, you only have to change the main {{C|A}} entry, since they don't use SMTP or XMPP.


=== Update the certificate ===
=== Update the certificate ===


Run the <code>letsencrypt-refresh</code> script to get a new certificate which includes all our domain names, since we had started out with just feministwiki.dev.
Run the {{C|letsencrypt-refresh}} script to get a new certificate which includes all our domain names, since we had started out with just feministwiki.dev.


After this, everything should be functional.  If not, it's time for some debugging!
After this, everything should be functional.  If not, it's time for some debugging!