-------------------------------------------
  * **selfhostedwp** 
  * **Jonathan Haack**
  * **Haack's Networking**
  * **netcmnd@jonathanhaack.com**

-------------------------------------------

//selfhostedwp//

-------------------------------------------

This tutorial is for setting up a self-hosted WordPress instance on Debian GNU/Linux. This tutorial assumes you have some familiarity setting up a LAMP stack. If you need help with that, check out [[https://wiki.haacksnetworking.com/doku.php?id=computing:apachesurvival|Apache Survival]]. Alright, let's install our LAMP stack and required/optional php modules. //Make sure to review what your instance requires and don't install or configure modules you don't need.//

  sudo apt install apache2 mariadb-server php8.2 php-common php-cgi php-cli php-zip php-mysql php-mbstring php-intl php-fpm php-curl php-gd php-imagick php-xml php-xmlrpc php-soap php-opcache php-apcu php-bcmath memcached wget unzip
  
Sometimes dpkg can choose which version of php you want and it's not always the version you want. In those cases, you can explicitly specify the version you need. Some packages are only available as ''php-xx'' so run the above command first and then the command below when those situations arise:
  
  sudo apt-get install php8.2-{common,cgi,cli,zip,mysql,mbstring,intl,fpm,curl,gd,imagick,xml,xmlrpc,soap,opcache,apcu,bcmath}
  
Apache2 will set up a 000-default.conf automatically and your host should now resolve. Be sure to set up TLS with certbot. Here's my preferred method:

  sudo apt install certbot letsencrypt python3-certbot-apache
  sudo certbot --authenticator standalone --installer apache -d site1.com --pre-hook "systemctl stop apache2" --post-hook "systemctl start apache2"
  crontab -e
  <30 2 * * 1 /usr/bin/certbot renew >> /var/log/le-renew.log>
  
Once you have the LAMP stack setup and TLS properly configured, it's time to make some decisions on your php handler and your apache2 multi-processing module (mpm). There's extensive debate on this which you can read up on [[https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/#prefork-mpm|here]]. In this tutorial, I've chosen not to use mpm_prefork and libapache2-mod-php. Instead I am using mpm_event and php-fpm. This is not necessary for many smaller instances or self-hosted scenarios. If you are new to self-hosting, simply run ''sudo apt install libapache2-mod-php8.x'' and remove the php-fpm and mpm_event steps below.
  
  sudo apt remove libapache2-mod-php* --purge
  sudo apt install php8.3-fpm php8.3-cgi
  sudo a2enmod ssl
  sudo a2enmod headers
  sudo a2enmod cache
  sudo a2enmod rewrite
  sudo a2enmod setenvif
  sudo a2dismod php8.1
  sudo a2dismod php8.2
  sudo a2dismod php8.3
  sudo a2dismod mpm_prefork
  sudo a2enmod mpm_event
  sudo a2enmod proxy
  sudo a2enmod proxy_fcgi
  sudo a2enconf php8.3-fpm
  sudo a2enconf php8.3-cgi
  sudo apache2ctl configtest  
  sudo systemctl restart apache2
  sudo systemctl restart php8.3-fpm

There are two standard ways to configure php-fpm. One of those is to use ProxyPassReverse, however, this will disable the use of .htaccess in your WordPress root which is not ideal. The next common way which I prefer and use here, is to add a FilesMatch condition to your virtual host as follows. Within the <Include> and </Include> portion of your default-ssl.conf virtual host, add something like:

  <FilesMatch ".+\.ph(ar|p|tml)$">
      SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost"
  </FilesMatch>

That takes care of configuring php-fpm and mpm_event. Before proceeding, navigate to your tld.domain in a web browser and make sure that your site resolves properly. If it does not, then you should debug your setup. To do that, there's three tools that can help: phpmyadmin, phpinfo page, and configuration checking. If your page does not even resolve, your first recourse should be to check the php handler, multi-processing modules, and your apache config files:

  sudo apachectl -M | grep 'mpm'
  sudo apachectl -M | grep 'proxy'
  sudo apache2ctl configtest

The output of mpm should show mpm_event and the output of proxy grep should show proxy_module and proxy_fcgi_module in use. If not, trace back over the steps above and see what went wrong. As for configtest, it should either tell you what's wrong or return "Syntax OK". If the output of the above commands is incorrect and/or you simply want a graphical way to check your handler and mult-processing module, then you can either create a phpinfo page or install phpadmin. There are many additional benefits to using phpmyadmin, so let's review how to install that first:

  sudo apt install phpmyadmin
  sudo htpasswd -c /etc/apache2/.phpmyadmin phpmyadmin  
  sudo nano /usr/share/phpmyadmin/.htaccess  
  <AuthType Basic>
  <AuthName "Restricted Files">
  <AuthUserFile /etc/apache2/.phpmyadmin>
  <Require valid-user>

If you don't need something as heavy as phpmyadmin, you can optionally create a phpinfo page instead:

  sudo nano /var/www/wordpress.com/public_html/info.php
  sudo htpasswd -c /etc/apache2/.phpinfo phpinfo  
  sudo nano /usr/share/phpinfo/.htaccess  
  <AuthType Basic>
  <AuthName "Restricted Files">
  <AuthUserFile /etc/apache2/.phpinfo>
  <Require valid-user>

Use these tools to make sure your handler and multi-processing module are configured to your preference and functional. After that's all working, let's make sure that your WordPress index.php is set to top priority as follows:
  
  sudo nano /etc/apache2/mods-enabled/dir.conf
  <DirectoryIndex //index.php// index.html index.cgi index.pl index.xhtml index.htm>

Close and save the file. Let's now set up a database now for the WordPress instance as follows:

  sudo mysql -u root -p
  CREATE DATABASE databasename DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
  GRANT ALL ON databasename.* TO 'databaseuser'@'localhost' IDENTIFIED BY 'passwordhere';
  FLUSH PRIVILEGES;
  EXIT;

Next up, it is time to allow overrides in your primary apache configuration. This is optional but/and it allows WordPress extensions to make configuration changes to .htaccess and/or other changes to the web server. It's often helpful, but you can leave it off if you prefer and configure everything manually.

  sudo nano /etc/apache2/apache2.conf
  <AllowOverride All>
  
Let's now shell into our instance and set up WordPress.

  ssh root@site1.com
  curl -O https://wordpress.org/latest.tar.gz
  tar xzvf latest.tar.gz
  mv wordpress /var/www/site1.com/public_html
  
Okay, we will need the files and directories I created once we get it running.  Now, let's move the wordpress directory to the proper location for self-hosting.

  sudo mv ~/Downloads/wpdownload/wordpress /var/www/site1.com/public_html

Now, create proper permissions for your Word Press directories and files:

  sudo chown -R www-data:www-data /var/www/site1.com/public_html
  sudo find /var/www/site1.com/public_html -type d -exec chmod g+s {} \;
  sudo chmod 755 /var/www/site1.com/public_html/wp-content
  sudo chmod -R 755 /var/www/site1.com/public_html/wp-content/themes
  sudo chmod -R 755 /var/www/site1.com/public_html/wp-content/plugins

It's now time to configure your ''wp-config.php'' file. To do that, however, we need to replace the example salts in the configuration file with random ones from WordPress. They have an API tool that does that for us automatically:
  
  curl -s https://api.wordpress.org/secret-key/1.1/salt/
  sudo nano /var/www/site1.com/public_html/wp-config.php
  <Replace the example salts with those you just downloaded using copy/paste>
  
Sometimes, for reasons I am not sure about, WordPress does not allow users direct uploading. If/when that happens, add the entry to wp-config.php. If anyone knows why this is needed, please let me know!

  sudo nano /var/www/site1.com/public_html/wp-config.php
  <define('FS_METHOD','direct');>

Let's now visit site1.com in a web browser. Enter the credentials that you created for the database above. Choose the settings you prefer and set up an admin account and record your credentials securely. You should now have a proper WordPress site! Now that you have a WordPress, check the SiteHealth tab and follow its advice and/or know why you don't. In my case, I typically adjust cache, rewrites, and headers.

  apt install memcached
  nano /etc/default/memcached
  <ENABLE_MEMCACHED=yes>
  a2enmod cache
  a2enmod expires
  a2enmod headers
  a2enmod rewrite

After isntalling memcached and enabling those modules, navigate to your web root and adjust your .htaccess as follows:

  <IfModule mod_expires.c>
          ExpiresActive On
          ExpiresByType image/jpg "access 1 year"
          ExpiresByType image/jpeg "access 1 year"
          ExpiresByType image/gif "access 1 year"
          ExpiresByType image/png "access 1 year"
          ExpiresByType text/css "access 1 week"
          ExpiresByType text/html "access 1 month"
          ExpiresByType text/x-javascript "access 1 week"
          ExpiresDefault "access 1 month"
  </IfModule>

  <IfModule mod_rewrite.c>
          RewriteEngine On
          RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
          RewriteBase /
          RewriteRule ^index\.php$ - [L]
          RewriteCond %{REQUEST_FILENAME} !-f
          RewriteCond %{REQUEST_FILENAME} !-d
          RewriteRule . /index.php [L]
          <FilesMatch "\.(js|css|jpe?g|png|gif|eot|otf|svg|ttf|woff2?)$">
                  Header set Timing-Allow-Origin "*"
          </FilesMatch>
  </IfModule>

  <IfModule mod_headers.c>
          Header always set X-Content-Type-Options "nosniff"
          <IfModule mod_setenvif.c>
                  SetEnvIf Origin "^(.+)$" CORS=$0
          </IfModule>
          Header set Access-Control-Allow-Origin %{CORS}e env=CORS
          Header set Access-Control-Allow-Credentials "true" env=CORS
          <FilesMatch "\.(php|html)$">
                  Header set X-Frame-Options "ALLOW"
                  Header set X-XSS-Protection "0"
                  Header set X-Download-Options "noopen"
                  Header set X-Permitted-Cross-Domain-Policies "none"
                  Header set X-DNS-Prefetch-Control "on"
                  Header set Pragma "no-cache"
                  Header set Age "0"
                  Header set Cache-Control ""
                  Header set Strict-Transport-Security "max-age=0" env=HTTPS
                  Header set Referrer-Policy ""
                  Header set Cross-Origin-Embedder-Policy "unsafe-none"
                  Header set Cross-Origin-Opener-Policy "unsafe-none"
                  Header set Report-To '{"max_age": 0, "endpoints": [{"url": ""}]}'
                  Header set Content-Security-Policy "default-src * data:; script-src https: 'unsafe-inline' 'unsafe-eval'; style-src https: 'unsafe-inline'"
                  Header set Referrer-Policy "no-referrer-when-downgrade"
                  Header set Feature-Policy "camera 'none'; fullscreen 'self'; geolocation *; microphone 'self' https://plaza.pvpfrontier/*"
          </FilesMatch>
  </IfModule>

Personally, I don't think anyone should be using ftp. Sftp is fine, and if someone needs that, here's an example of a simple sftp server using proftp:

  sudo apt install proftpd ftp ftp-ssl 
  sudo a2enmod tls
  cd /etc/proftpd
  sudo openssl req -new -x509 -days 7305 -nodes -out ftpd-rsa.pem -keyout ftpd-rsa-key.pem
  sudo nano /etc/proftpd/proftpd.conf
  <enter parameters>
  
Next, enter the TLS module in tls.conf underneath ''#Include /etc/proftpd/tls.conf'' and then restart the service: 

  sudo nano /etc/proftpd/tls.conf
  <IfModule mod_tls.c>
     TLSEngine on
     TLSLog /var/log/proftpd-tls.log
     TLSProtocol TLSv1
     # Are clients required to use FTP over TLS when talking to this server?
     TLSRequired off
     TLSRSACertificateFile    /etc/proftpd/ftpd-rsa.pem
     TLSRSACertificateKeyFile /etc/proftpd/ftpd-rsa-key.pem
     # Authenticate clients that want to use FTP over TLS?
     TLSVerifyClient off
     TLSOptions NoSessionReuseRequired
  </IfModule>
  sudo systemctl restart proftpd.service
  
Refresh WordPress and it should see the sftp server and allow you to make changes that way. Note: The sftp server is public and anyone can access this with proper credentials even if it not for WordPress so use a proper password and make sure your TLS configuration is working. Your instance should now be pretty solid. The only other thing you might want is more than one WordPress site subdomain, for example, site1.cooldomain.com, site2.cooldomain.com, etc. If that's the case, then hop on over to my [[https://wiki.haacksnetworking.com/doku.php?id=computing:wpmultisite|Word Press Multisite]] tutorial. 

 --- //[[jonathan@haacksnetworking.org|oemb1905]] 2023/06/30 03:23//