Kategorien
Blog Software

Mail for the WordPress Docker setup

After setting up the docker containers for WordPress and the NGINX Proxy Manager I still had one open issue: Sending mail was not possible. So I was looking for a solution to set up mail for the WordPress Docker setup.

I had the following options in mind:

  1. Setting up a separate docker container with an e-mail server. More or less I just needed a so-called Smarthost, that takes sent-out e-mails from any docker container and forwards them to my e-mail provider, Gmail. I struggled to find a proper, small image of a mail server running on an RPi for a long time. Then open the ports of the WordPress containers and send the e-mail from the WordPress containers to the container with the Smarthost Mail server. Nevertheless, you must install any kind of mailer within the container to handle the mail() call coming from WordPress.
  2. Set up an email server on the host (I used exim4) and let all Docker containers send their e-mails to the host, which will then be forwarded to the real e-mail provider by exim4. Still, you must install any kind of mailer within the container to handle the mail() call coming from WordPress. There were the following sub steps necessary:
  3. Setting up a WordPress Plugin, connecting via SMTP to the e-mail provider.

The variants 1 & 2 generated so many problems during the setup, that I finally decided to go with variant . This was set up in 30 minutes only!

For this SMTP service, I’m using the plugin WP Mail SMTP.

Kategorien
Blog Software

Setting up a WordPress staging system with docker

I wanted a WordPress staging system to play around with new plugins, new WordPress versions, and PHP versions.

The primary goals of my mini-project were:

  • Have a staging system for WordPress available for testing new WordPress versions and Plugins
  • Enhance the Performance of the actual WordPress Blog

How can we do it?

Here is a network diagram of the current system setup.

OK, the ideas were quite clear. Now we need a migration plan. And this looks like that:

  1. Install Raspian on the RPi5 SSD, with the Raspberry Pi imager
  2. Install docker and Portainer on the RPi5, based on the Heise description
  3. Install the following docker containers via „docker compose“
    1. Nginx Reverse Proxy
    2. Maria DB for WordPress Staging 
    3. WordPress Staging
    4. Maria DB for WordPress Production
    5. WordPress Production
    6. (Setting up Home Assistant also as a docker container is not a good idea as we lose the functionality of Add-Ons)
  4. With the current live system I’m doing a regular backup via Updraft, so let’s import these backups into the two WordPress instances
  5. At the DNS provider define the new subdomains and route them also to the Dynamic DNS provider
  6. Configure the NPM (Nginx Proxy Manager) with these domains and define the forwarding to the different instances
    1. Setup SSL via Let’s encrypt 
    2. Add also the local Home Assistant server/Port as the target
  7. Reconfigure the port forwarding of the router to the NPM
  8. Shutdown the old RPi4

So, let’s dive a little bit deeper into the different steps.

Configure the new RPi5 hardware and software

OK, let’s get the first new hardware, which means the new high-performance RPi5.

It took some time to be available on the market and the announced performance numbers looked promising.

As the power supply is quite strong I attached directly a SSD drive to the USB3 port.

So no need anymore for a USB hub!

Installing the latest Rasbian operating system on the SSD was pretty easy using the Raspian Imager.

I also configured the SSH access for it, of course.

So, how are we going further?

Install docker on the RPi5

As I wanted to run a WordPress life system and a WordPress staging system in my local network, I thought it would be a good idea to go with:

  • Docker to run multiple images/containers
  • Nginx Reverse Proxy to manage/route the traffic to/from these containers to the outside world

Install the docker containers

  • Setup a docker network manually
docker network create dockerwp 
  • Create a directory for wp_prod, wp_staging, nginx
  • Define a file for common parameters used as anonymized volumes in the docker containers
  • Create docker-compose.yml for the Nginx Proxy
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy
    restart: unless-stopped
    ports:
      # These ports are in format <host-port>:<container-port>
      - '80:80' # Public HTTP Port
      - '443:443' # Public HTTPS Port
      - '81:81' # Admin Web Port
      # Add any other Stream port you want to expose
      # - '21:21' # FTP

    # Uncomment the next line if you uncomment anything in the section
    # environment:
      # Uncomment this if you want to change the location of
      # the SQLite DB file within the container
      # DB_SQLITE_FILE: "/data/database.sqlite"

      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'

    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

networks:
  dockerwp:
    external: true
  • Create docker-compose.yml for the MariaDB and the WordPress container (one for the staging and one for the production system)
services:
  mysqldb0:
    image: mariadb:11.3.2
    container_name: prod_db
    environment:
      MARIADB_ROOT_PASSWORD: "secret"
      MARIADB_DATABASE: "wordpress"
      MARIADB_USER: "wordpress"
      MARIADB_PASSWORD: "secret"
    volumes:
      - 'mysqldb0:/var/lib/mysql'
    restart: always
    networks:
      -  mysqldb0


  wordpress0:
    image: wordpress:6.5.3
    container_name: prod_wp
    environment:
      WORDPRESS_DB_HOST: "mysqldb0"
      WORDPRESS_DB_USER: "wordpress"
      WORDPRESS_DB_PASSWORD: "secret"
      WORDPRESS_DB_NAME: "wordpress"
      WORDPRESS_CONFIG_EXTRA: |
        define('AUTOMATIC_UPDATER_DISABLED', true);

   volumes:
      - 'wordpress0:/var/www/html/wp-content'
      - '../uploads.ini:/usr/local/etc/php/conf.d/uploads.ini'
    restart: always
    ports:
      - "8001:80"
    depends_on:
      - mysqldb0
    networks:
      - mysqldb0
      - dockerwp

volumes:
  mysqldb0:
  wordpress0:

networks:
  mysqldb0:
    internal: true
  dockerwp:
    external: true

Setup the WordPress content

As I backed up the WordPress blog site with updraft, we are restoring the backup to the new WordPress staging and WordPress production system, respectively.

Configure the Sub-Domains

Go to your DNS provider and configure the new Sub-domains with a CNAME entry.

If you have a dynamic IP address, route the Sub-Domain entries to the same Dynamic DNS entry of your DynDNS Provider.

Configure the NPM

Define the target of the routing for all the Sub-Domains, e.g. the Ports of your WordPress containers.

Let the Sub-Domain for the Home Assistant point to the separate HA RPi3.

Add the SSL certificates from Let’s Encrypt.

Additional configuration for the Home Assistant

We must add the following configuration steps to make the Home Assistant run with an external Sub Domain, based on ademalidurmus.

1.) At the NPM, enter the following entry in the advanced config for the Home Assistant Host.

location / {
        proxy_pass              http://10.0.0.5:8123;
        proxy_set_header        Host            $host;
        proxy_redirect          http://         https://;
        proxy_set_header        Authorization   $http_authorization;
        proxy_pass_header       Authorization;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection “upgrade”;
 }

In the Home Assistant configuration.yml file add:

http:
  cors_allowed_origins:
    - https://public.domain.tld # my public domain
  use_x_forwarded_for: true
  trusted_proxies:
    - 10.0.0.3 # nginx proxy manager internal IP adress

At the „Home Assistant URL“ page enter:

Internet: [External Domain]
Local network: [Internal IP]:8123

Reconfigure the Port forwarding at your router

The Ports 80 for HTTP and 443 for HTTPS must now be reconfigured to forward the traffic from these two ports to the NPM.

Here is the network diagram of the new setup.

WordPress staging system with docker

Let’s now check our goals from the beginning. Did we reach them?

  • Have a staging system for WordPress available for testing new versions and Plugins: Available
  • Enhance Performance of the actual WordPress Blog: Super fast!
Kategorien
Blog Software

Multiroom sound System erweitert

Ich habe mein Multiroom Sound System, basierend auf einem rPi Netzwerk, um eine Funktion erweitert. Nun kann man als Eingang auch einen Chromecast ansprechen.

Die allgemeine Beschreibung habe ich unter HomeNetwork aktualisiert.

Multiroom sound System

Der Setup dazu sieht so aus:

Handy –> Chromecast –> HDMI Splitter –> USB SoundCard –> rPI –> WaveIn Plugin of SqueezeBox –> SqueezeLight music clients

Ich habe dazu folgende Geräte verwendet:

Auf der SqueezeBox muss man zuerst das Wavein Plugin installieren.

Unter Linux dann folgenden Befehl eingeben, um herauszufinden, welches Gerät (die USB Soundkarte) man ansprechen muss:

pi@max2play:~ $ arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: Device [USB Audio Device], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0

Bei mir ist es also das Gerät 1, subdevice 0.

Nun auf der SqueezeBox einen neuen Favoriten mit einem beliebigen Namen anlegen und bei der URL folgendes konfigurieren (wavin:plughw:[Gerät],[subdevice]):

wavin:plughw:1,0

Auf dem mobilen Gerät kann jede beliebige Applikation verwendet werden, die an ein Chromcast Gerät streamen kann, wie z.B. TuneIn, BubbleUPnP, VRadio, Youtube,…

Wie man sieht kann man das eigene Multiroom sound System immer noch besser machen 😉

Kategorien
Blog Software

Upgrade to a RPi4 plus SSD

After having some trouble with my existing system I decided to upgrade to a RPi4 powered system, together with a SSD as a new storage medium.

As I wanted to migrate the old data to the new system I had to come up with a strategy how to get there.

First I prepared the RPi4 to boot from another storage device as the standard SD card, based on the following tutorial.

Then I flashed the SSD with the currently available latest raspbian buster version and attached it to the blue USB 3.0 slot.

While booting I got some errors from the fsck utility, but after some booting time it ran through. I tested a bit further and was rebooting a few times. Every time another error occured and finally – after some hours – I had the idea to put an USB hub between the SSD and the RPi4. So it looks that the USB hub solves the problem, although it’s not even powered. Weird, isn’t it?

And, voila, from now onwards the booting and also the working of the system was perfect.

Upgrade to a RPi4

Now as the base system was running and the RPi4 was able to boot from the SSD I had to migrate the software and the data of the old system to the new system.

For this I used the backup of the old system I made with raspiBackup, just flashing it completely onto the SSD.

The final step was now, to copy the .elf and .dat files from the still existing boot partition of the SD card to the boot partition of the SSD, so that the RPi is booting from the SSD.

Now the system is up and running and it is really very fast 🙂

But hold on, we are not done yet!

IP and DNS entries

I have setup the new system with a new IP address, running in parallel to the RPi3 live system. I thought, „OK, let’s just switch the port forwarding of the router to the new IP address with the ports 80, 443, for IPV4 and IPV6 addresses and it should work.“

Unfortunately it did not work.

I forgot, that I had to reconfigure also the DNS forwarding at my domain hoster with updating the CNAME. And, unfortunately again, there is a time to live (TTL) set for the CNAME entry. So it’s much recommended to set this TTL value to the lowest possible value some days in advance. Otherwise it takes a few hours that the CNAME changes are taking effect through all the DNS servers.

So have fun to upgrade to a RPi4 on yourself 🙂

Kategorien
Blog Software

Raspbian Upgrade kills the RaspberryPi

It all started that I wanted to upgrade the PHP from version 7.0 to version 7.3/4, because wordpress was blaming about it. And I never would have imagined that an Raspbian Upgrade kills the RaspberryPi.

But first things first, that’s how the story goes that occupied my for two days.

Raspbian Upgrade kills the RaspberryPi

The base version of my Raspbian is Jessie, running on a standard RPi version 3. So I wanted to fetch the 7.3 PHP packages from the buster version of Raspbian. But I was unable to finish that process as the upgrade said, I had to break the 7.0. So I was afraid and stopped it.

The result was, that the system was completely messed up. The curl to the HTTPS world was no longer working. And I saw that even the udev package had some unmet dependencies. So I rebooted the system and it stopped completely while booting.

First attempt

What to do now?

I decided to install raspbian buster on a new hard disc (I once configured the RPi to boot directly from the USB hard drive) and install all the necessary applications based on the following tutorials:

https://projects.raspberrypi.org/en/projects/lamp-web-server-with-wordpress

https://bitreporter.de/raspberrypi/webserver-mit-wordpress-blog-auf-dem-raspberry-pi-einrichten/

For configuring the php fpm module I used https://tecadmin.net/install-apache-php-fpm-debian-10/

The last software part was getting an HTTPS certificate from let’s encrypt based on https://pimylifeup.com/raspberry-pi-ssl-lets-encrypt/

All these are really very good tutorials and worked like a charm (I just replaced once the mysql-server with mariadb-server). For connecting to the WordPress jetpack service you need also php-xml to be installed.

Fortunately I was performing a regular backup of the system with updraft. The restore worked perfectly. I was also using standard backups of the system that helped me a bit, but due to the HDD configuration I did not have a backup that I just could use, e.g. like an image to copy on the hard disk.

As I have a bit of a special wordpress installation (site URL != wordpress URL) I had to move the wordpress directory from „html“ to „wordpress“ and had to adapt the apache vhost configuration slightly.

After configuring all that the site was up and running again after around 5h.

So I thought, „Ok, let’s make a reboot.“ And the system stopped during boot.

What a shit!

The error message was:

usb usb1-port1: Cannot enable. Maybe the USB cable is bad?
usb usb1-port1: attempt power cycle

„Ok“ I thought as I was using a quite old hard disc, maybe it’s somthing wrong with the cable now. I decided to just flash the fine running hard disc of my former life system and do the process again (I was faster now, took me just 3h!)

Second attempt

After configuring everthing again, I made the reboot and…the system stopped again with the same error message.

„Ok, it cannot be that we are having here now exactly the same hardware problem with another hardware. So it must be a software issue. What did I do except just the install of new software? What was hardware related?“

There was one command:

pi@raspberrypi3:~ $ sudo apt-get upgrade
Reading package lists… Done
Building dependency tree
Reading state information… Done
Calculating upgrade… Done
The following package was automatically installed and is no longer required:
rpi-eeprom-images
Use 'sudo apt autoremove' to remove it.
The following packages will be upgraded:
ca-certificates firmware-atheros firmware-brcm80211 firmware-libertas firmware-misc-nonfree firmware-realtek
libgnutls30 libraspberrypi-bin libraspberrypi-dev libraspberrypi-doc libraspberrypi0 raspberrypi-bootloader
raspberrypi-kernel raspi-config rpi-eeprom rpi-eeprom-images
16 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 127 MB of archives.
After this operation, 6,477 kB disk space will be freed.
Do you want to continue? [Y/n]

After issuing this command the system did not boot anymore.

Final attempt

So, I did the installation process a third time (2h now), this time without the upgrade, and the system just works.

Since 2013 I’m working with this setup and it never happened that an upgrade of the operating system resulted in such a disaster!

Update from 16.08.2020

It works now. I did the upgrade in some package chunks to find out which packge caused the problem with the command:

sudo apt-get install --only-upgrade <package-name>

But I think it would have been not necessary. I have no idea, which package was changed in the mean time.