Local domain name resolution with Fritz!Box

The Yunohosts running in the local network were initially unreachable due to different causes, the cause depending on whether the request was made from the local net or from the public internet.

The local case was easily worked around using the hosts file, by adding a line to /etc/hosts of each device on the local net (and suppressing ensuing headaches):

127.0.0.1      localhost.localdomain localhost
80.127.182.180 online.osba.nl

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.

Print this entry

Not enough swap

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 steps for creating and using a swap file:

fallocate -l 512M /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile

I used a 1GB file, and when lxml still wouldn’t compile, I added another gig of swap.

“yunohost app install synapse” is running. If it ends in an error once more, I need to check whether the cause actually is still (out of) memory-related.


Print this entry

Fediverse with Nextcloud on Yunohost: cloud ID @localhost :-(

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:

sudo -u nextcloud php ./occ config:list social
{
  "apps": {
    "social": {
      "address": "http:\/\/localhost\/index.php",
      "enabled": "yes",
      "installed_version": "0.1.4",
      "types": ""
    }
  }
}

Then update to the required domain:

sudo -u nextcloud php ./occ config:app:set social address --value="http://online.osba.nl/nextcloud/index.php"
Config value address for app social set to http://online.osba.nl/nextcloud/index.php

and check again

sudo -u nextcloud php ./occ config:list social
{
  "apps": {
    "social": {
      "address": "http:\/\/online.osba.nl\/nextcloud\/index.php",
      "enabled": "yes",
      "installed_version": "0.1.4",
      "types": ""
    }
  }
}

The warning about webfinger seems solved, but is replaced by a popup:

Failed to load account details wbk@online.osba.nl

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.

To be continued…

Print this entry

Yunohost on Orange Pi Zero with Armbian

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:

SoC H2+
DRAM 256 MiB or 512 MiB DDR3
Power DC 5V DC-IN via µUSB or pin headers or PoE (optional)
Features
Video CVBS (on pin headers)
Audio microphone, stereo line-out on pin headers
Network 10/100Mbps Ethernet and XR819 Wi-Fi
Storage µSD
USB 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:

curl https://install.yunohost.org | bash

When it is done, run post install:

yunohost tools postinstall

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:

yunohost backup restore 'backupname'

After that, get a LetsEncrypt-certificate:

yunohost domain cert-install your.domain.tld

Reading this text probably takes more time than executing those steps. I used 32G uSD cards, at least class 10, preferably with ‘App performance’ label (A1 or higher).

Print this entry