Once the headaches of trying to edit host files on Android devices promised heavier than those I prospected finding the cause in the local network, I set out finding that cause. It turned out to be DNS rebind protection in the modem/router, an up-to-date (07.01, as of writing) Fritz!Box.
An entry on Marphys blog pointed me to the setting in question:
The list was empty, of course, and after adding online.osba.nl the entries in the hosts files were not needed anymore.
Installing lxml (for Synapse/Matrix) gave problems on one of the Yunohosts ended in an error all the time.
The error indicated not enough memory available at some point. The machines are fairly limited in RAM, so that explains. Extra swap space to the rescue!
Armbian creates a swap partition and resizes the system partition (and the file system) to fit the uSD-card during first boot, so there is no space available to increase swap space.
Unfortunately, shrinking an ext4 file system is not as trivial as growing/extending it. It helps that the uSD-card can easily be put in another system, avoiding the need to resize a (semi-) online root partition. One bit of information made me rethink my shrink-root, grow-swap strategy: ostensibly a lot of writing might go on while resizing:
The filesystems considered here tend to disperse data throughout the underlying block device, so a large amount of copying may be needed even if the filesystem has never been filled beyond the size it is being reduced to. Do not start resize2fs unless you are confident you can allow it to finish. You can request a progress bar using the -p option.
That is not what I expected or had taken in account.
Since I do expect it to be a temporary measure, I decided to create a swap file instead of a swap partition. Arch, as usual, has a very helpful page on their wiki. There are some warnings against using swap files for other file system types especially with non-contigous swap files, but ext4 has no special mention.
The Nextcloud Social App nags about .well-known/webfinger being not set up properly:
.well-known/webfinger isn't properly set up!
Social needs the .well-known automatic discovery to be properly set up. If Nextcloud is not installed in the root of the domain, it is often the case that Nextcloud can't configure this automatically. To use Social, the admin of this Nextcloud instance needs to manually configure the .well-known redirects: Open documentation ↗
The documentation states that a line in the config is to be uncommented; since that block of configuration is not there in the nginx nextcloud.conf that Yunohost created, I added it just above the .well-known’s for carddav and caldav, ie, on top of the config.
The nextcloud instance does not run in the root of the domain, so the rewrite rule has to account for that:
# The following rule is only needed for the Social app.
# Uncomment it if you're planning to use this app.
rewrite ^/.well-known/webfinger /nextcloud/public.php?service=webfinger last;
After that things still don’t run smoothly, searching the Nextcloud forum pointed me to occ. First check the current config for the social app:
The warning about webfinger seems solved, but is replaced by a popup:
Failed to load account details firstname.lastname@example.org
After /var/www/nextcloud# sudo -u nextcloud php ./occ social:reset and confirming I was sure about resetting anything and everything social, I was able to ‘follow’ and ‘unfollow’ users on the same system. Also possible, it seems, is following Nextcloud on Mastodon.xyz. No messages yet, though. Not yet possible: following users on another nextcloud instance near here.
Orange Pi has a neat range of microcomputers. The smallest cost less than 10 Euro’s. For that price it is remarkably complete and powerful enough to run a suite of web services. They are easily installed and managed via Yunohost.
The hardware in short, specs copied from the excellent Sunxi-wiki:
1 USB 2.0 Host, 1 USB 2.0 OTG, 2 x USB 2.0 on pin headers
The 512 MB-option costs almost 25% more than the 256 MB-option, but spending two Euro’s there saves a lot of headaches later on. Depending on experience with the first handful of Zero-boards I might opt for the OPi PC later. An important factor that made me choose the OPi Zero, is that it draws little enougd power to run of regular USB and that it can be converted to run off power over ethernet. I haven’t tried that yet: it only supports passive PoE, and I am not sure my switches work with anything but 802.3af PoE.
Yunohost does not (yet) have images for the OPi zero with H2+ processor. Armbian does have an image, ready made for flashing to uSD.
I am not the only one running Armbian on this board; there are enough people downloading for that specific board to have the image appear on the Armbian front-page
Armbian advices to flash a uSD card using Etcher. Etcher is relatively heavy for the job on hand, but is a comfortable tool. On some of my computers Etcher refuses to find the uSD card because of the layout of the other disks (perhaps related to software RAID or LVM). In that case I use dd with a block size of 1 and a sync afterwards.
After flashing, on first boot of Armbian, change the default password from 1234 for root to something useful. On those first boots I do use a serial interface. At first I worried I might hook it up incorrectly and break something (which I did not, but have subsequently done more than once). The one thing I did check carefully (using a multimeter) was the working voltage of the serial interface of the USB2TTL / USB2serial convertor: it has to be 3.3V for the OPi Zero. At 5V something might get fried.
Running a serial connection to a headless board is a lot of fun: it seems your computer’s display (or terminal window) is the devices’ screen. Everything from the first boot messages scrolls by.
Using a serial interface saves looking for the IP of the device to get connected. So you have to think of ordering some of those convertors, but they’ll save some hassle later on.
After the first boot of Armbian, reboot (for seeing everything is OK with your new password).
Yunohost has a curl-able script for installing the Yunohost-base-system on top of Debian:
Edit december 2019, from the Yunohost documentation: alternatively, restore a backup instead of postinstalling. Upload the archive to the server and place it in /home/yunohost.backup/archive; instead of postinstall, run: