2025-02-06T11:50:23Z

Technician: /* Tips on the usage of ldap commands */

The member database of the FeministWiki is stored via LDAP. This page explains some details about the setup.

=== Structure ===

The basic structure looks like this:

dc=feministwiki,dc=org
ou=members
- cn=''username''
objectClass: fwMember
cn: ''username''
uid: ''username''
sn: ''Display name''
userPassword: {SSHA}''saltedhash''
mail: ''username''@feministwiki.org
fwRecoveryMail: ''user@example.org''
- cn=''username2''
objectClass: fwMembe
cn: ''username2''
uid: ''username2''
sn: ''Display name''
userPassword: {SSHA}''saltedhash2''
mail: ''username2''@feministwiki.org
manager: cn=''username'',ou=members,dc=feministwiki,dc=org
- ...
ou=groups
cn=members
objectClass: groupOfNames
cn: members
member: ''username''
member: ''username2''
member: ...

Notes:
* The <code>cn</code> (common name) and <code>uid</code> (user ID) fields both contain the username. This is because some software is preconfigured to look at <code>uid</code>, while most look at <code>cn</code>.
* The <code>sn</code> (surname) field is used to hold a display name that may be different from the username. The field is filled with the username by default.
* The <code>mail</code> field holds the primary mail address for communication with the member. It's filled with the FeministWiki mail address of the member by default, but can be changed freely.
* The <code>fwRecoveryMail</code> field may hold a mail address that will be used for password reset requests. It's different from the primary mail address because that one may be the member's FeministWiki address, which they can't access if they've lost their password.
* The <code>manager</code> contains the DN (distinguished name) of the member who added the member. It may be empty for special member accounts like "Administrator" or the "Deleted" pseudo-account.

=== Tips on the usage of ldap commands ===

Commands such as ldapsearch, ldapmodify, etc. require authentication. The correct method depends on whether you want to interact with the configuration database found in {{C|/etc/ldap/slapd.d}}, or the actual data database found in {{C|/var/lib/ldap}}.

For configuration, use {{C|-Y external -H ldapi://}} to connect directly with root permissions, so no actual LDAP domain login is needed.

For data, use {{C|-xy ~/pwd/ldap}} to use the LDAP domain admin password. The file {{C|~/.ldaprc}} should contain the following, so you don't have to specify the domain admin explicitly every time:

BINDDN cn=admin,dc=feministwiki,dc=org

=== Read-only user ===

For security purposes, it's a good idea to have a "read-only" user for LDAP read operations, instead of using the admin for everything.

# Add read-only user
ldapadd -xy ~/pwd/ldap <<EOF
dn: cn=readonly,dc=feministwiki,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: readonly
description: Read-only user
userPassword: $(cat ~/pwd/ldap-readonly)
EOF

No fiddling with access control is needed, since read-only access is the default.

=== Custom objectClass ===

The following command creates the <code>fwMember</code> object class.

ldapadd -Y external -H ldapi:// <<EOF
dn: cn=feministwiki,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: feministwiki
olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.99.1.1
NAME 'fwRecoveryMail'
DESC 'FeministWiki password recovery mail'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.99.2.1
NAME 'fwMember'
DESC 'FeministWiki member'
SUP inetOrgPerson
STRUCTURAL
MAY ( fwRecoveryMail ) )
EOF

=== Attribute permissions ===

We want to make the following changes to the default LDAP permissions:

* Members should be able to change their own display name (<code>sn</code>) and e-mail address (<code>mail</code>).
* The read-only user should be able to find users via the combination of their username and recovery mail address (<code>fwRecoveryMail</code>), but not actually see their recovery mail addresses. (The password reset mechanism uses this.)
* Members should not be able to see who a member was added by (the <code>manager</code> field).

The following command makes the necessary access control changes:

ldapmodify -Y external -H ldapi:// <<EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {2}to attrs=sn,mail by self write
olcAccess: {3}to attrs=fwRecoveryMail by self write by dn.exact="cn=readonly,dc=feministwiki,dc=org" search
olcAccess: {4}to attrs=manager by self read
EOF

Note that <code>olcAccess</code> entries are evaluated in order, and the first match takes effect. This can affect performance. In the statement above, we start inserting entries from index 2, because indexes 0 and 1 already have some meaningful default entries.

=== Password policy ===

To make sure passwords are stored with the <code>{SSHA}</code> scheme rather than plain text, the <code>ppolicy</code> "password policy overlay" is used. ZYTRAX has a very nice book about LDAP which documents how to enable this: http://www.zytrax.com/books/ldap/ch6/ppolicy.html

In short, the steps go as follows (these commands ''should'' work verbatim):

# Only needed on old versions of slapd, to add the ppolicy schema
#ldapadd -Y external -H ldapi:// < /etc/ldap/schema/ppolicy.ldif

# Enable the ppolicy dynamic module
ldapmodify -Y external -H ldapi:// <<EOF
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy
EOF

# Add the ppolicy overlay with olcPPolicyHashCleartext set to TRUE
ldapadd -Y external -H ldapi:// <<EOF
dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyHashCleartext: TRUE
EOF

Further, <code>ppolicy</code> is used to enable brute-force protection. For this, we need to add an entry of the object class <code>pwdPolicy</code> to the directory, add attributes related to brute-force protection, and then set it as the default password policy:

# Add an OU for password policies
ldapadd -xy ~/pwd/ldap <<EOF
dn: ou=pwdPolicies,dc=feministwiki,dc=org
objectClass: organizationalUnit
ou: pwdPolicies
EOF

# Add the pwdPolicy object
ldapadd -xy ~/pwd/ldap <<EOF
dn: cn=default,ou=pwdPolicies,dc=feministwiki,dc=org
objectClass: applicationProcess
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdLockout: TRUE
pwdLockoutDuration: 3600
pwdMaxFailure: 10
pwdFailureCountInterval: 3600
EOF

# Set it as the default password policy
ldapmodify -Y external -H ldapi:// <<EOF
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
changetype: modify
add: olcPPolicyDefault
olcPPolicyDefault: cn=default,ou=pwdPolicies,dc=feministwiki,dc=org
EOF

With these settings, ten consecutive authentication failures with a username will lock the account for an hour. Login failures are also cleared after an hour. This means it's possible to try ten passwords per hour during a brute-force attack, which won't get the attacker very far.

=== Time of last login ===

The <code>lastbind</code> module of OpenLDAP keeps track of when a user last logged in.

# Load the module
ldapmodify -Y external -H ldapi:// <<EOF
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: lastbind
EOF

# Enable the overlay
ldapadd -Y external -H ldapi:// <<EOF
dn: olcOverlay=lastbind,olcDatabase={1}mdb,cn=config
objectClass: olcLastBindConfig
olcOverlay: lastbind
olcLastBindPrecision: 60
EOF

FeministWiki:About

2024-12-05T16:13:29Z

Technician:

FeministWiki.org is a project by the German LLC:

WikiWiz UG (haftungsbeschränkt)

Richard-Wagner-Str. 25

DE-35321 Laubach

USt-IdNr. DE414203449

District court Gießen, HRB 10100

Legal correspondent: Taylan Ulrich Kammer

E-Mail: info@feministwiki.org

Main Page

2024-11-13T11:50:32Z

Technician: /* Who's behind the project? */

{{PageSeo
|description = Welcome to the FeministWiki, a digital platform for feminism consisting of a wiki, forum, chat, blog hosting, and more.
}}

''[[:de:Hauptseite|Deutsch]] - [[:es:Página_principal|Español]] - [[:fr:Accueil|Français]] - [[:it:Pagina_principale|Italiano]] - [[:pt:Página_principal|Português]]''

Welcome to '''FeministWiki''', a wiki and integrated digital platform for feminism.

A wiki is a knowledge-base like an encyclopedia, but managed by the public. The FeministWiki specializes on feminism, and is managed by feminists and their supporters. It aims to archive and present information relevant to feminism, and explain feminist perspectives to the reader.

Further, the FeministWiki aims to offer a complete integrated digital platform for feminists, with components such as a blogging platform, a discussion forum, a messaging/chat system, private and shared online storage for large files, and more. You don't need to provide any personally identifying information to become a member, nor do you need to pay; the modest number of users makes the platform cheap to run.

There are a few ways to become a member:
* Use the [https://account.feministwiki.org/register.html Registration Request] form to ask for an account.
* Contact an existing member and have them create an account for you by using the [https://account.feministwiki.org/add-member.html Add Member] form.
* Ask for an account by manually contacting technician@feministwiki.org or by messaging an official social media account of the FeministWiki.

Spinster: [https://spinster.xyz/@FeministWiki @FeministWiki] (preferred) 
Twitter: [https://twitter.com/@FeministWiki @FeministWiki] 
Facebook: [https://www.facebook.com/FeministWiki/ FeministWiki]

Once you are a member, you will be given a username and password with which you can log in to all FeministWiki services. For example, to log in to the wiki itself (which you are reading right now), use the small "Log in" link at the top right of the page.

See the '''[[FW:Welcome|Welcome page]]''' for further information on the FeministWiki, written with new members in mind.

Heads up: '''the FeministWiki needs you'''. All of the technical infrastructure of the FeministWiki is only useful if there's a community making use of it, and content on the wiki doesn't write itself! Be bold, don't shy off of asking for membership, and let the community and the world benefit from your added knowledge. You can become a member even if you have no intention to contribute to the actual wiki; feel free to chat away with other members, discuss matters important to you on the forum, or use the file storage to have a central place to store your favorite information-material on feminism.

== Check out some articles ==

=== Notable feminists ===

* [[Magdalen Berns]]

=== Sex, gender, and trans activism ===

* [[Gender]]
* [[Transgender ideology]]
* [[Cisgender]]
* [[Autogynephilia]]
* [[TERF]]
* [[Transwomen in women's sports]]

=== Sex industry ===

* [[Nordic Model]]

=== Black feminism ===

* [[Black feminism]]

== What is feminism? ==

There are a variety of ideological groupings which call themselves feminism, and some of them are in contradiction with each other. As such, one cannot support all types of feminism at the same time. The FeministWiki is for people who adhere to a relatively straightforward and classical interpretation of feminism: the liberation of female people from male supremacism. This is sometimes called ''radical feminism'' because male supremacism is a radical notion for many people, and its elimination requires radical changes to society.

Male supremacism refers to social and political systems that use stereotypes, myths, discrimination, belittlement, violence, and other means to keep men in power and women oppressed. Women are then exploited for reproductive and domestic labor, men's sexual gratification, and more. Male supremacism also causes collateral damage to some men and boys. For instance, effeminate boys and gay men are often targeted with punishment for failing to uphold the myth that men are inherently masculine.

The FeministWiki promotes second-wave feminist literature:

* [https://radfem.org/ Radical Feminist Archives]

The FeministWiki is in full support of the Women's Human Rights Campaign:

* [https://www.womensdeclaration.com/ Declaration on Women's Sex-Based Rights]

The FeministWiki recommends Spinster as a feminism-friendly social media platform:

* [https://spinster.xyz Spinster.xyz]

Further, the FeministWiki promotes and stands in solidarity with the following groups and organizations:

* [http://lgballiance.org.uk LGB Alliance]: The LGB Alliance
* [http://womensliberationfront.org/ WoLF]: The Women's Liberation Front
* [https://feministcurrent.com/ Feminist Current]: Canadian feminist news, commentary, and podcasts
* [https://www.rapereliefshelter.bc.ca/ Vancouver Rape Relief]: Female-only rape-relief and women's shelter
* [https://nordicmodelnow.org/ Nordic Model Now]: Educational movement for the abolition of prostitution
* [http://www.spaceintl.org/ SPACE International]: Survivors of Prostitution Abuse Calling for Enlightenment
* [https://womansplaceuk.org/ Woman's Place UK]: Women's campaigning group scrutinizing gender self-identification
* [https://speakupforwomen.nz/ Speak Up for Women]: New Zealand group opposing gender self-identification
* [https://feministstruggle.org/ Feminists in Struggle - FIST]: US-based female-only radical feminist network

== Who's behind the project? ==

The FeministWiki platform is offered to the public for free by the German LLC '''WikiWiz UG (haftungsbeschränkt)'''.

The technical infrastructure is managed by [[FW:Technician|the technician]], who also offers user support. For support, please contact technician@feministwiki.org.

For legal inquiries please contact info@feministwiki.org or feministwiki@gmail.com.



[[de:Hauptseite]] [[es:Página_principal]] [[fr:Accueil]] [[it:Pagina_principale]] [[pt:Página_principal]]

FeministWiki:About

2024-10-11T08:30:01Z

Technician:

FeministWiki.org is a project by the German LLC:

WikiWiz UG (haftungsbeschränkt)

Richard-Wagner-Str. 25

DE-35321 Laubach

District court Gießen, HRB 10100

Legal correspondent: Taylan Ulrich Kammer

E-Mail: info@feministwiki.org

2024-01-12T19:51:30Z

Technician: /* Copy over the live data one more time */

These are the steps required to set up a new FeministWiki Debian or Ubuntu server. The guide assumes that you're comfortable connecting to a host with SSH and using the shell for various administration tasks, such as using {{C|systemctl}}, editing configuration files, installing packages, setting up SSH keys, and so on.

== Initial setup of the new server ==

This section describes various initialization tasks for the new server that are independent of the old server.

=== Configure reverse DNS ===

In the settings of the VPS host (e.g. Strato AG), you can configure reverse-DNS for the IP address of the server. Set the FQDN for the IP address to {{C|feministwiki.org}}. It's good to do this early since it can take some time to propagate.

=== 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 {{C|A}} entries of the {{C|feministwiki.dev}} DNS settings to point to the IP address of the new server.

=== Update & upgrade ===

First of all, let's make sure the system is up to date.

apt-get update
apt-get upgrade
apt-get dist-upgrade

=== Install miscellaneous tools ===

Some of these are needed further down, some are just good to have.

apt-get install automysqlbackup \
bsdutils \
certbot \
curl \
dnsutils \
emacs-nox \
git \
imagemagick \
ldap-utils \
mg \
moreutils \
net-tools \
netcat-openbsd \
nmap \
rsync \
tree

=== Copy SSH key from old server ===

Copy over {{C|~/.ssh/id_rsa}} and {{C|~/.ssh/id_rsa.pub}} from the old server onto the new one. Make sure to set the permissions for the private key correctly: {{C|chmod 600 ~/.ssh/id_rsa}}

=== Set up SSH access from the old server ===

Some of the commands further below need SSH access from the old server to the new server, using the {{C|feministwiki.dev}} domain name. Since we've just copied over the public key of the old server, we can enable access from the old server with this simple command:

# Run on new server
cat .ssh/id_rsa.pub >> .ssh/authorized_keys

Further, to make our life easier, we can edit the SSH configuration on the old server so we don't have to manually specify the custom SSH port number every time. Add a block like the following into {{C|~/.ssh/config}} on the old server, replacing {{C|<SSH_PORT>}} with the actual port number:

Host feministwiki.dev
Port <SSH_PORT>

=== Tighten security of SSH access ===

Port 22 will get lots of malicious login attempts. It's a good idea to change the SSH port, and also to disable password authentication in favor of key-based authentication. Both can be done by editing {{C|/etc/ssh/sshd_config}}.

Before restarting the SSH service, make sure you've actually added your public key (the contents of {{C|~/.ssh/id_rsa.pub}} on your computer) to {{C|/root/.ssh/authorized_keys}} on the server, or you'll lock yourself out.

=== Set up firewall ===

For now, block everything but SSH.

apt-get install ufw
ufw allow proto tcp to 0.0.0.0/0 port ${SSH_PORT} # Replace with actual port number
ufw enable

=== Fetch scripts & config repo ===

Having copied the {{C|.ssh/id_rsa}} from the old server will give you access to the GitHub FeministWiki repo:

cd
mkdir repo
git clone git@github.com:FeministWiki/FeministWiki.git repo/fw
cp -ai repo/fw/root/* repo/fw/root/.??* .
sh repo/fw/decrypt-pwd.sh

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.

=== Enable extra repositories ===

We might want to add some additional package repositories so we can use the latest version of some of the used software.

Backports is always OK to add since the packages don't get priority over the stable ones:

# Debian
# May not be necessary; see if there's a commented out line in /etc/apt/sources.list that you can activate.
echo deb http://deb.debian.org/debian $(lsb_release -sc)-backports main contrib non-free > /etc/apt/sources.list.d/backports.list

# Ubuntu
echo deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc)-backports main universe > /etc/apt/sources.list.d/backports.list

Usually you want up-to-date versions of Apache2, Nginx, and PHP. Ondřej provides them:

# Debian
for repo in apache2 nginx-mainline php
do
curl https://packages.sury.org/$repo/apt.gpg > /etc/apt/trusted.gpg.d/sury-$repo.gpg
echo "deb https://packages.sury.org/$repo/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/sury-$repo.list
done

# Ubuntu
add-apt-repository ppa:ondrej/apache2
add-apt-repository ppa:ondrej/nginx
add-apt-repository ppa:ondrej/php

It may be necessary to increase the priority of some repositories if you encounter errors about dependencies that can't be fulfilled, due to apt-get thinking it has to prioritize older versions of some packages. This was last observed while trying to install {{C|nginx-extras}}, due to some library dependencies having the "epoch" part of the version number set in the regular Debian repository, but not set in the Sury repository. The solution is to create a file in {{C|/etc/apt/preferences.d}} such as:

Package: *
Pin: origin packages.sury.org
Pin-Priority: 700

Elasticsearch, if you want CirrusSearch for MediaWiki:

curl https://artifacts.elastic.co/GPG-KEY-elasticsearch | gpg --dearmor -o /etc/apt/trusted.gpg.d/elasticsearch.gpg
# As of January 2024, CirrusSearch only supports Elasticsearch 7.x
echo 'deb https://artifacts.elastic.co/packages/7.x/apt stable main' > /etc/apt/sources.list.d/elastic.list

=== Create vmail user ===

groupadd -g 5000 vmail
useradd -u 5000 -g vmail -s /usr/sbin/nologin -d /home/vmail -m vmail

=== Install server components ===

Now we can install all the software used for the various FeministWiki services:

apt-get install
apache2 \
dovecot-core \
dovecot-imapd \
dovecot-ldap \
dovecot-pop3d \
ejabberd \
elasticsearch \
fail2ban \
inspircd \
mariadb-server \
nginx-extras \
opendkim \
postfix \
postfix-ldap \
slapd

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:

apt-get install ejabberd/$(lsb_release -sc)-backports # e.g. ejabberd/bookworm-backports

=== Install PHP and modules ===

This should really be part of the last section, but due to the sheer number of PHP modules we want to install, it's in its own section:

php_version=8.1 # or whatever version we're on

apt-get install php${php_version} \
php${php_version}-apcu \
php${php_version}-bcmath \
php${php_version}-cli \
php${php_version}-curl \
php${php_version}-fpm \
php${php_version}-gd \
php${php_version}-gmp \
php${php_version}-imagick \
php${php_version}-intl \
php${php_version}-ldap \
php${php_version}-mbstring \
php${php_version}-mysql \
php${php_version}-opcache \
php${php_version}-readline \
php${php_version}-xml \
php${php_version}-zip

=== Copy over certificates ===

Copy over the certs from the old server:

# Run on old server
rsync -avz /etc/fw-certs feministwiki.dev:/etc/fw-certs

The {{C|/etc/fw-certs}} directory and its contents should be owned by the group {{C|ssl-cert}}. Make sure this is the case on the new server after running the command above, since the group ID might be different on the new server. If the group doesn't exist at all, just create it.

Further, files in that directory which contain the private key ({{C|privkey.pem}} and {{C|bundle.pem}}) should only be readable by group members. That is, their permission mode should be 640, displayed as {{C|-rw-r-----}} in the output of {{C|ls -l}}. Make sure this really the case.

Then, to allow certain services to read those files containing the private key, add them to the {{C|ssl-cert}} group:

# Run on new server
adduser ejabberd ssl-cert
adduser irc ssl-cert

Also copy over the certificates stored directly in {{C|/etc/letsencrypt}}:

# Run on old server
rsync -avz /etc/letsencrypt/{archive,live} feministwiki.dev:/etc/letsencrypt

=== Put config files in place ===

The principle is simple: take all the config files from {{C|/root/repo/etc}} and put them where they belong in {{C|/etc}}. However, since a new server might mean much newer software, it's possible that some config files aren't compatible anymore, or that some new sensible defaults might be overwritten by the old config. Sadly, figuring out these incompatibilities is a manual process: compare the new default config with the old default config, and/or with our own config saved in the repo, to figure out what our new config files should look like.

There's a number of things important to remember:

* Don't forget to revert the redactions of sensitive information. Search files for {{C|[REDACTED]}}.
* After copying {{C|/etc/aliases}}, run {{C|newaliases}} to create the alias database file.
* After copying Postfix configuration, run {{C|postmap /etc/postfix/sender-access}} and {{C|postalias /etc/postfix/virtual-aliases}}.
* Make sure the executable bit is set on all {{C|cron}} scripts, {{C|/etc/rc.local}}, and scripts in {{C|/etc/letsencrypt/renewal-hooks}}.

=== Apache modules and configuration ===

Enable PHP FPM and other Apache modules:

a2enmod expires headers proxy_fcgi
a2enconf php${php_version}-fpm

=== OpenLDAP configuration database ===

First of all, check if there are important changes in the base configuration of slapd. For this, we can copy the old configuration into some directory on the new server and run a recursive diff:

# Run on old server
rsync -az /etc/ldap/slapd.d/ feministwiki.dev:/tmp/slapd.d

# Run on new server
diff -ru --color=always /tmp/slapd.d /etc/ldap/slapd.d | less -R

There are going to be a number of changes that are expected. Namely:

# CRCs, UIDs, timestamps, and other such auto-generated fields
# FeministWiki-specific things that only exists in the old configuration

If these are the '''only''' differences you can see, then it should be safety to completely override the config on the new server with the old one, using the instructions in the following section.

Otherwise, skip to the section after that and recreate the FeministWiki-specific configuration from scratch.

==== Complete copying of old configuration ====

''Note: This is an '''alternative''' method to that described in the '''next''' section. See above for which one to choose.''

Stop the LDAP server and delete the configuration database '''on the new server (careful!)''':

# Commands to run on the NEW (fresh) server:
systemctl stop slapd
rm -r /etc/ldap/slapd.d/*

Then copy over the configuration database, by running the following commands from the old server:

# Run on old server
slapcat -n 0 | ssh feministwiki.dev 'sudo -u openldap slapadd -n 0 -F /etc/ldap/slapd.d'

==== Recreation of FeministWiki configuration ====

''Note: This is an '''alternative''' method to that described in the '''previous''' section. See above for which one to choose.''

First run {{C|dpkg-reconfigure slapd}} to fill in some basic information such as the domain name and admin password. You can reuse the old admin password found in {{C|/root/pwd/ldap}}.

Then, running the following sequence of commands, taken from [[FeministWiki:LDAP Schema]], should do the rest:

# Create fwMember object class
ldapadd -Y external -H ldapi:// <<EOF
dn: cn=feministwiki,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: feministwiki
olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.99.1.1
NAME 'fwRecoveryMail'
DESC 'FeministWiki password recovery mail'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.99.2.1
NAME 'fwMember'
DESC 'FeministWiki member'
SUP inetOrgPerson
STRUCTURAL
MAY ( fwRecoveryMail ) )
EOF

# Set attribute permissions
ldapmodify -Y external -H ldapi:// <<EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {2}to attrs=sn,mail by self write
olcAccess: {3}to attrs=fwRecoveryMail by self write by dn.exact="cn=readonly,dc=feministwiki,dc=org" search
olcAccess: {4}to attrs=manager by self read
EOF

# Enable the ppolicy dynamic module
ldapmodify -Y external -H ldapi:// <<EOF
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy
EOF

# Add the ppolicy overlay with olcPPolicyHashCleartext set to TRUE
ldapadd -Y external -H ldapi:// <<EOF
dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyHashCleartext: TRUE
EOF

# Set the default password policy
# The policy object referenced here doesn't exist yet,
# but will exist once we copy over the main database.
ldapmodify -Y external -H ldapi:// <<EOF
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
changetype: modify
add: olcPPolicyDefault
olcPPolicyDefault: cn=default,ou=pwdPolicies,dc=feministwiki,dc=org
EOF

# Load the lastbind module
ldapmodify -Y external -H ldapi:// <<EOF
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: lastbind
EOF

# Enable the lastbind overlay
ldapadd -Y external -H ldapi:// <<EOF
dn: olcOverlay=lastbind,olcDatabase={1}mdb,cn=config
objectClass: olcLastBindConfig
olcOverlay: lastbind
olcLastBindPrecision: 60
EOF

==== Breaking changes in OpenLDAP ====

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}}. Following are two examples of this.

These particular issues won't apply anymore when you're reading this guide, since they are one-time issues related to migrating to a newer OpenLDAP version, but they serve as good examples. (Also, no such clear explanation of the first problem seems to be found anywhere on the web, so maybe someone who searches the related error message below will come upon this guide and be happy!)

===== OpenLDAP Migration: Example Problem 1 =====

This problem occurs when migrating from OpenLDAP 2.4.42 or earlier, to 2.4.43 or later.

The ppolicy overlay gained a new attribute in OpenLDAP version 2.4.43, so if you simply run the command above which copies over the configuration database onto the new server, it 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 {{C|/etc/ldap/schema/ppolicy.ldif}} and search for {{C|pwdMaxRecordedFailure}}. You will see an {{C|olcAttributeTypes: ...}} entry that defines it. 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 {{C|slapcat -n 0}} to a file, open it in a text editor, and search for the block where the {{C|ppolicy}} schema is defined. It should start with the line {{C|<nowiki>dn: cn={4}ppolicy,cn=schema,cn=config</nowiki>}} (the {{C|<nowiki>{4}</nowiki>}} 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.

===== OpenLDAP Migration: Example Problem 2 =====

This problem occurs when migrating to OpenLDAP 2.5, and although the change is bigger, the fix is easier. The issue is actually documented in the OpenLDAP 2.5 Administrator's Guide, Appendix B.2:

https://www.openldap.org/doc/admin25/appendix-upgrading.html

The second paragraph tells us what to do:

<blockquote>In OpenLDAP 2.4 the slapo-ppolicy(5) overlay relied on a separate schema file to be included for it to function. This schema is now implemented internally in the slapo-ppolicy module. When upgrading slapd.conf(5) deployments the include statement for the schema must be removed. For slapd-config(5) deployments, the config database must be exported via slapcat and the old ppolicy schema removed from the export. The resulting config database can then be imported.</blockquote>

In simpler terms:

# Save the output of {{C|slapcat -n 0}} from the old server in a file:
#: <pre>slapcat -n 0 > slapcat.n0.out</pre>
# Open the file in a text editor and delete the block starting with the line {{C|<nowiki>dn: cn={4}ppolicy,cn=schema,cn=config</nowiki>}}, up to the next empty line (before the next block starting with a {{C|dn: ...}} line), and save the file.
# Feed the file to {{C|slapadd -n 1}} on the new server:
#: <pre>cat slapcat.n0.out | ssh feministwiki.dev 'sudo -u openldap slapadd -n 0 -F /etc/ldap/slapd.d'</pre>

== Copying over live data ==

We want to make a first run of this copy process purely for testing purposes. Note that although some of the steps described in this section take a long time to finish, they can be done in parallel.

=== LDAP database ===

Make sure slapd is not running and delete the existing database '''on the new server (careful!)''':

# Run on new server!
systemctl stop slapd
rm /var/lib/ldap/data.mdb

Then copy over the database by running the following command from the old server:

# Run on old server
slapcat -n 1 | zstd | ssh feministwiki.dev 'zstd -d | sudo -u openldap slapadd -n 1'

Start slapd again in the new server afterwards:

# Run on new server
systemctl start slapd

=== Contents of /var/www ===

This is very simple but takes a lot of time to finish. '''Run it from the old server:'''

rsync -azP --delete /var/www/ feministwiki.dev:/var/www

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 ===

Run the following command from the old server:

mariadb-dump -u root -p"$(cat /root/pwd/mariadb)" \
--add-drop-database \
--databases feministblogs \
feministfiles \
feministforum \
feministmail \
feministwiki \
feministwiki_de \
feministwiki_es \
feministwiki_fr \
feministwiki_it \
feministwiki_pt \
fff \
| zstd | ssh feministwiki.dev 'zstd -d | /root/bin/sql'

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 ===

This is a simple one. Run this command from the old server:

rsync -az --delete /home/vmail/ feministwiki.dev:/home/vmail

Note that the trailing slash in {{C|/home/vmail/}} is important.

=== Elasticsearch ===

Temporarily stop Elasticsearch on the old server and copy over the data:

systemctl stop elasticsearch
rsync -az --delete /var/lib/elasticsearch/ feministwiki.dev:/var/lib/elasticsearch
systemctl start elasticsearch

=== Mailman data ===

GNU Mailman uses a filesystem-based "database" so we can transfer over its data as follows; run this from the old server:

cd /var/lib/mailman
rsync -az --delete archives data lists feministwiki.dev:/var/lib/mailman

And then this on the new server:

check_perms -f

The {{C|check_perms}} command, which is part of GNU Mailman, will take care of fixing file ownership and permissions.

== Recreate SQL users ==

If the versions of MariaDB on the old and new server are compatible enough, you might be able to dump the {{C|mysql.user}} table and import it on the new server, but it's safer to recreate the users from scratch. To do so, run this on the new server:

/root/bin/sql << EOF
create user 'feministblogs'@localhost identified by '$(cat ~/pwd/mariadb-feministblogs)';
create user 'feministfiles'@localhost identified by '$(cat ~/pwd/mariadb-feministfiles)';
create user 'feministforum'@localhost identified by '$(cat ~/pwd/mariadb-feministforum)';
create user 'feministmail'@localhost identified by '$(cat ~/pwd/mariadb-feministmail)';
create user 'feministwiki'@localhost identified by '$(cat ~/pwd/mariadb-feministwiki)';
create user 'fff'@localhost identified by '$(cat ~/pwd/mariadb-fff)';
EOF

Now grant them access to their corresponding databases. Remember that this has to be done '''after''' the databases have been copied over:

/root/bin/sql << EOF
grant all on feministblogs.* to feministblogs@localhost;
grant all on feministfiles.* to feministfiles@localhost;
grant all on feministforum.* to feministforum@localhost;
grant all on feministmail.* to feministmail@localhost;
grant all on feministwiki.* to feministwiki@localhost;
grant all on feministwiki_de.* to feministwiki@localhost;
grant all on feministwiki_es.* to feministwiki@localhost;
grant all on feministwiki_fr.* to feministwiki@localhost;
grant all on feministwiki_it.* to feministwiki@localhost;
grant all on feministwiki_pt.* to feministwiki@localhost;
grant all on fff.* to fff@localhost;
EOF

== Test ==

It's important to test the new server to make sure everything works well!

=== Reboot ===

We could restart a lot of services manually to ensure they've read their new config, but it's easiest to just reboot. (The new server, obviously.)

=== Open ports ===

We need to open all the ports used by the various FeministWiki services:

for port in 25 80 443 465 587 993 995 5222 5223 5269 5270 5443 6697 7777
do ufw allow proto tcp to 0.0.0.0/0 port $port
done

=== Test! ===

At this point you should test everything using the feministwiki.dev domain name.

Some things may not work correctly because they're hard-coded to work as "feministwiki.org" and not under the "feministwiki.dev" name. Here's a list of known issues related to this:

* WordPress normally redirects clients to the canonical address of a blog if it's visited through an alternative domain name. This means we get redirected back to the old server if we try to visit {{C|blogs.feministwiki.dev}}. To work around this, we use {{C|RequestHeader set Host}} in the Apache2 site configuration, which fools WordPress into believing it's being accessed through the canonical domain name. Still, the HTML/CSS/JS sent back to the browser refers to some resources on the {{C|.org}} domain, which then fail to load due to CORS violation.

If you want to be extra thorough, you can edit your {{C|/etc/hosts}} file to make {{C|feministwiki.org}}, various {{C|*.feministwiki.org}} subdomains, and maybe even other aliases (such as {{C|fem.wiki}}) point to the new server, and then test the few stubborn services that won't otherwise play nice.

=== Deactivate again ===

After we're done testing, we can "deactivate" the new server again to prepare it for the final switch-over:

for port in 25 80 443 465 587 993 995 5222 5223 5269 5270 5443 6697 7777
do ufw delete allow proto tcp to 0.0.0.0/0 port $port
done

systemctl stop apache2
systemctl stop dovecot
systemctl stop ejabberd
systemctl stop elasticsearch
systemctl stop inspircd
systemctl stop nginx
systemctl stop postfix
systemctl stop slapd

== Finishing up ==

'''Now, all services on the old server should be stopped, because we will begin the final transfer of live data.'''

=== Stop services on the old server ===

Stop all the services that interface with users and/or are responsible for modifying live data:

systemctl stop apache2
systemctl stop dovecot
systemctl stop ejabberd
systemctl stop elasticsearch
systemctl stop inspircd
systemctl stop nginx
systemctl stop postfix
systemctl stop slapd

Close all the relevant ports just to be double-sure:

for port in 25 80 443 465 587 993 995 5222 5223 5269 5270 5443 6697 7777
do ufw delete allow proto tcp to 0.0.0.0/0 port $port
done

=== Copy over the live data one more time ===

'''Simply repeat the whole section ''Copying over live data''.'''

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|mariadb-dump}} command help to make sure of this.

So just repeat the steps from that section exactly one more time.

=== Reboot the new server ===

At this point we can reboot the new server again, to make sure all services are properly restarted.

=== Open ports on the new server ===

Now we can open the ports again on the new server:

for port in 25 80 443 465 587 993 995 5222 5223 5269 5270 5443 6697 7777
do ufw allow proto tcp to 0.0.0.0/0 port $port
done

=== Update DNS entries ===

You have to change the configuration of the following domains:

* feministwiki.org
* feministwiki.net
* feministwiki.de
* fem.wiki
* feminism.wiki
* feminist.wiki
* fffrauen.de

==== feministwiki.org ====

You only have to change three DNS entries, since most of the subdomains work via CNAME entries:

* The main {{C|A}} entry for {{C|@}} (self-reference i.e. feministwiki.org)
* The {{C|A}} entry for {{C|smtp}} 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

==== Other domains ====

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

=== Configure LetsEncrypt ===

Since we changed the DNS settings, we can now set up certbot:

certbot register -n --agree-tos -m technician@feministwiki.org
letsencrypt-refresh

=== Finishing up ===

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