Adding X-Clacks-Overhead

For a long time on my to-do list, but postponed due to perceived complexity: adding X-Clacks-Overhead.

Now I got around to looking into what is actually involved, and… It’s not all that convoluted. For nginX it a single line to be added in a server, location or http block.

add_header X-Clacks-Overhead "GNU Terry Pratchett" always;

Next up was finding the right file in the Yunohost setup of nginX: I did find a single (default) sites-available, but no sites-enabled.

All configuration is put in the conf-directories, where I put the additional header in the conf of the main site in the server section.

vi /etc/nginx/conf.d/mysite.tld.conf

Now first see that the header is not there before reloading nginX:

~# curl -IL mysite.tld
 HTTP/1.1 302 Moved Temporarily
 Server: nginx
 Date: Sat, 28 Dec 2019 11:23:13 GMT
 Content-Type: text/html
 Content-Length: 154
 Connection: keep-alive
 X-SSO-WAT: You've just been SSOed
 Location: https://mysite.tld/yunohost/sso/?r=aHR0cHM6Ly9zYW55aS5ubC8=

See? No X-Clacks header. Reload nginX…

service nginx reload 

… and have a look at the headers again:

~# curl -IL mysite.tld
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Sat, 28 Dec 2019 11:25:52 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
X-SSO-WAT: You've just been SSOed
Location: https://mysite.tld/yunohost/sso/?r=aHR0cHM6Ly9zYW55aS5ubC8=
X-Clacks-Overhead: GNU Terry Pratchett

It now shows at the bottom line.

Actually the X-Clacks-Overhead is only added to the HTTP 1.1 headers. The HTTP 2 headers omit the header at the moment. After rereading the config, I added the header to the server listening at port 80 over HTTP 1.1; it gets forwarded to port 443 over HTTP 2. That block did not have the header. After adding the header there as well, the HTTP 2 headers show the X-Clacks-Overhead as well:

~# curl -IL mysite.tld
 HTTP/2 404 
 server: nginx
 date: Sat, 28 Dec 2019 11:33:18 GMT
 content-type: text/html
 content-length: 162
 x-sso-wat: You've just been SSOed
 set-cookie: SSOwAuthRedirect=;; Path=/yunohost/sso/; Expires=Thu, 01 Jan 1970 00:00:00 UTC; Secure; HttpOnly; SameSite=Lax ;;
 strict-transport-security: max-age=63072000; includeSubDomains; preload
 content-security-policy: upgrade-insecure-requests
 content-security-policy-report-only: default-src https: data: 'unsafe-inline' 'unsafe-eval'
 x-content-type-options: nosniff
 x-xss-protection: 1; mode=block
 x-download-options: noopen
 x-permitted-cross-domain-policies: none
 x-frame-options: SAMEORIGIN
 x-clacks-overhead: GNU Terry Pratchett

One difference between the two header blocks, is that the HTTP1.1 block is capitalized, whereas the HTTP2 block is not. Fine with me 🙂

So, two points of my mental to-do list, one for the Clacks itself and one for moving it from a mental to-do list to a physical (of some sort) to-do list.

Wireless floor heating thermostat

We installed infrared floor heating film. It has not yet been connected, lacking a thermostat. My idea from the start was to use Arduino or compatible to build the thermostat myself. There were some reasons for that: it was cheaper than a ready built device, more flexible and an excellent reason to get started with Arduino.

So, to prevent any misunderstandings: although the floor is not wired yet, it is not wireless. The thermostat will be wireless on one end, the end to the user interface. From the thermostat to the floor it wires all the way down.

In the mean time the parts have arrived:

  • ESP32, the brains of each thermostat
  • Relays, to actually switch on or off the infra red film
  • 10k NTC’s are already under the floor, together with the film itself

The separate functions I need/want to integrate are easily found, and integrating them went quite quickly at first. The result was almost what I needed, lacking only the sensor for ambient temperature. And it only would work in the wrong order. Which functions are they and what went wrong in the first iteration?

  • Temperature measurement
  • Thermostat setting
    • On the one hand ambient temperature: the temperature we find comfortable in the room
    • On the other hand the floor temperature: the floor temperature is not allowed to raise above 29 degrees Celsius
  • Switching a relay based on measured temperature and thermostat setting
  • Accessible via WiFi on the internal domotica network

As stated, each separate function got its examples for Arduino as well as, fewer, for ESP32. I ended up with a loop that:

  • Connect to WiFi
  • Shows a web interface to turn on or off the relay
  • Measures the temperature on pushing the on or off button
  • Actually switching on or off based on measured floor temperature

So the thermostat would not interfere with the relay until a button was pressed. The loop should work in reverse order:

  • Check relay state
    • if off, measure ambient temperature and compare to thermostat value
    • if on, measure floor temperature and compare to set maximum temperature
  • Depending on above, switch the relay state or keep as is
  • Connect to WiFi for a minute
  • Show the web interface
  • Allow the thermostat to be set
  • Return to above

The next step is to have a domotica server serving the thermostat interface, and the ESP querying the domotica server every now and again for changes. That way, less time is spent broadcasting a web interface via WiFi, improving power efficiency and security. At first it will be a stand alone setup though.

Pins

What connections/pins do I need? Which pins are they on the board?

  • Ralay; the relay needs three pins:
    • Ground;
    • VCC, the relay needs 5V, but it sits on a PCB with additional logic to let it switch with 3.3V supplied;
    • Switching signal, 3.3V as well; that also drives the process towards the “floor is to hot”- or the “room is not warm enough”-branch.
    • I’m free to use any digital-out pin for this
  • Floor sensor; the floor sensor needs three pins as well:
    • Ground;
    • VCC, any, as long as it is known and constant. I’ll use 3.3V as supplied by the ESP32;
    • Sensor pin;
    • The sensor-pin; any analog-read pin will do. It will read the voltage ‘halfway’ the ground-NTC-sensor-resistor-VCC series. The read voltage is then converted to a temperature.
  • Ambient sensor; just like the floor sensor:
    • Ground;
    • VCC;
    • Sensor pin / analog read.

I have some trouble converting the pin-examples I find on the Net to the actual pins on my ESP32. The names of the pins in those pictures are just a few letters different from the names of the pins silkscreened on the PCB. The pins that are supposed to be called ‘sensor VP’ and ‘sensor VN’, are called ‘SP’ and ‘SN’, and are moved one pin because I got an extra 3.3V pin on one side and extra GND pin on the other side.

Most of the pins are called Gnn, with nn being a number ranging from 0 to 36, in seemingly random order. G0 is between G2 and G4, and then G17 and G16 come before G5. G could stand for GPIO, and sometimes they match the notation on the images I find online. Of course not all options for each pin can be silkscreened on the tiny PCB. With my currently limited knowledge of Arduino programming, it does not help understanding the code I find in the wild. How should I assign a name to an input or output? Lets just try it with simple programs, building and understanding from there instead of hacking something together and hoping for the best: there is no lack of basic tutorials, it just takes some time to apply them to my ESP32-board, test its behaviour and measure electric properties of pins.

Test with ‘touch’ pin

While reading up on the pins and how to interact with them, I come across an explanation of ‘touch’ pins. They presumably can be used as input by just touching them. I’ll make sure to test that and keep it in mind as another way of setting the temperature.

Actually writing a simple program myself has taught me more than reading five of them and then flinging together something complicated to see what sticks. Namely:

  • Arduino is touchy about casing. Be sure to write analogRead, not analogread or Analogread: it won’t be recognized.
  • Same goes for semicolons. Forget one, and the compiler complains that there is an unexpected } instead of a ;
  • Prototyping is fast once you got something you understand that is working.
  • Use the right function for the type of input you’re working with. In case of the touch pins:
    • My first guess was using analogRead. It ‘works’, giving 12 bit high values (4095) when licking the connected wire or touching either the 3.3V or the 5V pin, 0 when connecting with GND. Using my fingers, the most intuitive way to interact with touch interfaces, gives fluctuating readings. Above 2000 when I draw blood with the pin, slowly descending values when I let go of it. Conclusion so far: it might work, but only when using more than one button and reading all of them to infer which one actually has been touched (and educating users not to touch more than one button at a time).
    • Next up was digitalRead. That gave 1 instead of 4095, 0 just as analogRead, and random 1 or 0 in between.
    • The actual function to use for touch pins is touchRead. It gives quite low (10+/-10) readings when touching the pin, and around 60 when not touching. Surprisingly, it gives 1 when touching 3.3V and 0 for GND,
    • The wire tastes as if there is some current on the line, my multimeter gives 0.7V as the amount between ground and GPIO4/T0 on the one hand and 0.6V between GPIO4/T0 and 3.3V. From GPIO4/T0 to 5V gives 2.1V, so there is some more logic involved somewhere behind GPIO4/T0.
  • Pins can be assigned in the header, above ‘void setup()’, using four indicators:
    • Type, for example ‘int’;
    • Name of the variable for the pin, for example ‘touch_pin’
    • Assignment using the equal sign (=);
    • GPIO number, just ‘4’ in this case;
    • Don’t forget the semicolon!
    • The whole assignment looks like: int touch_pin = 4
    • While reading: touchRead (touch_pin)
  • Pins can be read inline without assigning a variable as well: just write the number of the GPIO on the spot where it is needed:
    • touchRead (4)
  • Arduino is not touchy about spaces between brackets and letters. A space “touchRead ( 4 )” gives the same result as no space “touchRead(4)”.

For future reference, the file with the code is attached.

Fritz!Box configuration editing – as text

AVM offers a friendly user interface with Fritz!OS for their Fritz!Box’es to unleash a nice range of features. Many things are possible, though some things take quite a few clicks.

One of the things that take many clicks, is arranging port fortwarding for hosts on the LAN.

The easiest way, after a fashion, is to make a backup of the configuration, make changes and import the file again. The difficulty here is that the file is checksummed, and Fritz refuses to read the configuration.

While the ages, solutions have been written in various languages. I use a python script, fritzchecksum, written by Mementum/DRe.

It is an pip-installable module, pip install fritzchecksum, takes a Fritz-file as input and returns the old and new checksum for easy search and replace. The program supports automatic editing of the file as well, I have always replaced by hand.

For future reference, the zip contains the current download from github. Should not be necessary to download it here, but you never know!

Open vSwitch on Proxmox

Since Open vSwitch (ovs) and Linux bridging can’t mix, it is advised to switch to ovs before creating a whole lot of bridges.

# apt install openvswitch-switch

In networking of the node, I deleted vmbr0 of type=linux bridge, and added a new bridge vmbr0 of type ovs bridge. Proxmox likes to reboot after that, perhaps a restart of networking had been enough. Only restarting openvswitch-switch was not enough.

A presentation on an Open vSwitch conference suggested to edit two files:

  • /etc/default/lxc-net
    • set USE_LXC_BRIDGE=”false”
  • /etc/lxc/default.conf
    • set lxc.net.0.link = ovsbr1 ; would be vmbr0 in my case

The first is already set in /etc/default/lxc. The file lxc-net does not exist (though it is referenced in the lxc file).

The second file is almost empty, it has only the line ‘lxc.net.0.type = empty’.

Adding a new container uses vmbr0 by default; now I don’t know whether that is because I named the new bridge the same as the old one, or because OVS is being used by default.

Anyway: the container asked for a DHCP lease and received it from the router.

Proxmox first impressions

Once rebooted after installation I visited the IP of the server at port 8006. Unable to connect. Now what?

SSH does answer, a quick search for ‘proxmox installation complete no answer on 8006’ turned up someone without pve-manager installed. I did have it installed, but did not see proxmox repositories in /etc/apt/sources.list.

Servethehome has a checklist for proxmox 6, I took the pve-no-subscribtion repository from there:

deb http://download.proxmox.com/debian buster pve-no-subscription

Apt update complains about missing keys for jessie. Not a problem for my installation as such, but might break something that does not expect warnings (even a simple apt update && apt upgrade -y will halt), so add the key:

# wget http://download.proxmox.com/debian/key.asc
http://download.proxmox.com/debian/key.asc
Resolving download.proxmox.com (download.proxmox.com)... 2a01:7e0:0:424::249, 212.224.123.70
Connecting to download.proxmox.com (download.proxmox.com)|2a01:7e0:0:424::249|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1703 (1.7K) [application/octet-stream]
Saving to: ‘key.asc’
key.asc 100%[===========================>] 1.66K --.-KB/s in 0s
# apt-key add key.asc
OK

Retrying the web interface. Still no go: “the connection was reset”. Hmm… That is no ‘not found’, should I perhaps take the trouble of manually pointing at the https-protocol? Yes, that did it, add https:// in front of the IP and log in.

Shiny interface, just like in the screenshots 🙂

The summary view in the second-level tree-menu will stay active while clicking through the first-level tree-menu on the left hand, with the datacenter and node list. It shows different statistics and in a different representation (meters or graphs), depending on the subject, which is helpful in recognizing and remembering what I am looking at.

I now realize that I do have close to 30GB of space for the basic install (my 15GB * 2 for copies = 2), but no separate partition for /var. I’ll let it be, keep an eye on the level of free space and add space when needed. Reinstalling based on Debian Buster is well-documented, but with no experience with proxmox I’ll keep the installation close to default.

To see how much of the assigned space is used in which way, I compared the different views and some relations are not directly clear to me. I expected around 30GB at some level, and 15GB at another. What I actually see, is:

  • Bare sectors, fdisk: 61863937 * 512 ~ 29,5 GB
  • At ‘datacenter’ level: 2.2GB of 54.0GB used
  • At node level: 2.2GB of 28.0GB used
  • Two storage objects:
    • local: 2.2GB of 28.0GB used
    • local-ZFS: 0 of 25.8GB used

I can see the relation between 28 and 54, and between 28 and 25.8, but not between 54GB on the datacenter and 29.5GB actual usage on disk.

After defining ‘copies = 2’, I had expected all downstream values to be half of what I see here. Some thinking further: is the read value of fdisk is inside the node, not on the actual hardware? Then I would not see the total size of the SSD. I posted a question on the proxmox-forum, awaiting moderation and a reaction.

Proxmox

Once I decided on visualization and settled on Proxmox as the host platform for the new NAS, I stranded in decisions to make with regard to the installation.

The first problem was the installation medium itself: I wrote the installer to a uSD card, put it in an adapter to regular SD, that into SD2USB and finally in the USB3 port of the NAS.

Booting OK, installer menu OK, but starting the installer: not OK.

I tried a few times, but the image seemed broken. The kernel would halt somewhere between loading the initial ramdisk and actually starting the installer.

I checked the SHA256-checksum, reflashed on another memory card, used another SD-card-reader: all to no avail. In the end I started trying other USB ports; not just USB3 in front, but first USB3 on the back, and in the end USB2 on the backside.

That worked. The card readers are USB3, but maybe the uSD cards get upset at some point. Anyway, on to the installation.

Target harddisk: SSD or HDD? Which file system? Am I happy with automatic partitioning?

System disk: SSD. I want to be able to spin down as many HDD’s as soon as possible, as long as possible. If I start building the system on one of the spinning disks, it is more difficult to replace it in the future and am I stuck with it. Besides that, the base system should take only tens of GB’s, so there is enough space left for caching, swap and other things that also benefit from increased I/O.

Which file system? As long as I can remember, I have used LVM, the last ten years in combination with EXT4 on a md-stacks. It is very flexible and offers live resizing of nearly anything.

Proxmox does not do LVM out of the box, but it does offer ZFS (ZoL, ZFS on Linux). I have been postponing ZFS usage for a couple of years now, and am still hesitant to take the plunge. How many disks? How many pools? What size? Shit, non-ECC-RAM; and how about mirrors with differently sized disks? What about TRIM on the SSD?

I started reading about ZFS on a single device pool, retraced my steps and considered a pool with SSD and spinning disk mirrored. I found one viable option is to combine the 1TB spinning disk with the SSD for some reasons:

  • It is the only non-SMR-disk I have available at the moment;
  • It is similar in size to the 1TB SSD;
  • I am not committed to keeping either the 4TB disk or the 6TB disk in the machine:
    • I might take one or the other out and use it in a USB case for external back up
    • I might swap either for a disk the size of the other, to create another mirrored set.

I hope that the pool will be smart enough not to spin up the HDD for read, that would nullify the benefit of the non-spinning SSD. If that is the case, I’ll investigate how to make a single device pool out of it.

The other option is running the pool on a single device with copies = 2; I’d use double the space, but there is no spinning disk involved.

Then there’s the question of partitioning. Just the root partition could do with some 10GB. I’d put at least /var on a separate partition, so that log files and temporary files don’t cause / to fill to 100%, some 3GB. ZFS copies = 2 means some 30GB. With swap equal to RAM is another 32GB, and then a couple of GB for ZFS ZIL. That leaves roughly 900GB of unpartitoned space.

It is all a bit theoretical up front; I hesitate to just take the defaults and see down the road. Those times I did that, I regretted it later on. Now in particular, with the quad-level flash disk and less than 400 rewrites per cell (360, according to Samsung), I prefer not to start on the wrong footing. Anyway, it can’t be helped so I just have to bite the bullet. All things considered, I take the SSD-only way for the initial installation.

Phew, that took just four nights to get through the first screen of the installer!

That was the single choice to make then; from there to installation complete and reboot took about five minutes.

A new NAS

For my birthday I got parts for a new server/NAS, complete up to a 1-TB-SSD. After adding some HDD’s that where not in use elsewhere, the hardware is like:

  • Intel J5005, 4 single thread cores at 2GHz, give or take
  • 32GB of DDR4 memory
  • 1 TB of SSD storage
  • 11 TB of spinning storage, spread over
    • 6TB SMR
    • 4TB SMR
    • 1TB regular PMR
  • 1GBit ethernet
  • 1 PCIe 2x connection

The total box should run at 5W or less when idle, with HDD’s powered spinned down. At boot, when the disks spin up, peak usage could hit 100W, while active use with spinning disks should cost about 20W.

All is powered by a 90W power brick and a 120W PicoPSU; no software is installed yet, so actual measurements have to wait.

The server comes just in time: the current home server is running out of both disk space and SATA ports. The NAS will have multiple roles:

  • Provide space for photos and videos;
  • Provide a backup target for laptops;
  • Replace a host of ARM-powered Yunohosts
  • Provide reverse proxying for Yunohosts that will not get virtualized and Yunohosts that are in the household temporarily (while being installed or while waiting for an appointment with the host-household)
  • Domotica-related things (suse.AI, sensors, remote switching), VPN, firewall, the list goes on!

I am somewhat nervous about running backups and web servers on the same hardware, but after playing with virtualization ‘on premise’ and at hosting providers, I feel confident it is a viable combination.

As the NAS is a step up from the old one memory wise, virtualization should run fine. Still, 32GB is not a huge amount, so my first thoughts went to LXC and Docker. After diving into stories of others’ installations, I found Proxmox.

There are some caveats; the advanced options of the Debian installer are not available (option: install Debian, add Proxmox), being bound to the decisions the Proxmox team makes with regard to development of the platform and, unhelpful enough: root-login needs to be enabled.

Most things I read about Proxmox are positive. Management of storage space is flexible, LXC hosts and VM’s are easily managed and there is a large community. It goes without saying that the platform is Free/Libre Open Source software. All in all, the benefits made me prepare an installation medium.

Not knowing exactly what I want, what I need and what the result will be in the long run (software maintenance, storage options), made the installation less than straightforward.

Fediverse with Nextcloud/nginX on Yunohost deel II

The result of part I was being able to find users on the same system. Nice, but not the goal. Over the past weeks I spent some evenings glancing over the problem, hoping to read a post with a nice oneliner as a solution. No such luck.

Today I spent more time than I hoped, but did find part of the solution. The result is now that the webfinger testtool returns a result:

https://webfinger.net/lookup/?resource=wbk%40online.osba.nl

returns

Request log

18:20:13 Looking up WebFinger data for acct:wbk@online.osba.nl
18:20:13 GET https://online.osba.nl/.well-known/webfinger?resource=acct%3Awbk%40online.osba.nl

JSON Resource Descriptor (JRD)

{
  "subject": "acct:wbk@online.osba.nl",
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "http://online.osba.nl/nextcloud/nextcloud/index.php/apps/social/@wbk"
    },
    {
      "rel": "http://ostatus.org/schema/1.0/subscribe"
    }
  ]
}

It used to return an error, 404, not found.

More details are at the Yunohost forum, but the important bit is the configuration and where to put it. The config file is the Nginx-configuration at

/etc/nginx/conf.d/online.osba.nl.conf

There are two servers defined, one on port 80 and one on port 443. The first one had a preconfigured redirect, while there was none in the secure section. That was strange, but it didn’t raise any alarms with me. It turns out that the redirect has to be available over TSL as well, and that it has to be a combined redirect/rewrite.

The combined stanza looks like:

location = /.well-known/webfinger {
  rewrite ^ https://online.osba.nl/nextcloud/public.php?service=webfinger&$1 last; # $1 will use the first parameter (?resource=…)
}

Put this bit between the include-stanza’s and the log-definitions.

Even though the test at webfinger.org succeeds, I have no such succes when contacting this Nextcloud from a Nextcloud on another Yunohost.

To be continued…

Public IPv4 subnet with Fritz!Box

AVM does not write in large letters on their website that the Fritz!Boxes can handle public IP subnets. The feature is mentioned in the online help; enabling it in the first place happens via Home Network / item Network / tab Network Settings / header IP Adresses / button IPv4 Adresses / header Public IPv4 Subnet, at the bottom of the page.

And then? Then I got stuck. For evenings in a row. After some tries I got lucky at the XS4all helpline and spoke with someone knowledgeable on the subject. Managed to make a device reachable from the outside world on the public IPv4 on a single port. All happy, hung up the phone and tried another device and another port forwarding. Access denied, ‘An error occurred. Error description: A device with this name has already been configured.’

The awful thing is: not any port forwarding can be added or altered anymore. After contacting the AVM helpdesk, we found some hints of causes:

  • Renaming
  • Multiple NIC’s on one system

Renaming: that has to do with renaming the device, and later deleting the device under its new name. Some residual config stays behind under the old name. Since the new devices all came up as ‘Yunohost’ + a number initially, I would rename them to their given host name. Later the next device would come online, initially as Yunohost again. The left over config from the previous round now collides with this Yunohost.

Multiple NIC’s: AVM warned that one machine, connected to the Fritzbox via more than one cable, is not supported and will cause difficult to diagnose problems.

Even after learning some of the possible causes, the situation still has returned. I have a backup of a working configuration now, in which most machines got a basic profile that has most forwardings in place. If something runs amok, I can put that configuration back.

Assigning a public IP

To avoid the situation altogether, I don’t rename temporary devices anymore. The best cure is to be able to assign a device its public IP before connecting it to the FB for the first time. In a headless device that is not always practical.

Specifically for a temporary Yunohost with Armbian on Orange Pi Zero I now do things along these convoluted lines:

  • Just connect in any way to the FB and request an IP via DHCP
  • Leave the name as-is
  • Configure anything needed via SSH on the local IP
  • Make sure an ethernet cable as well as a serial connection are available
  • Use nmtui to configure the ethernet port for a public IP
    • Do not yet activate the new configuration
  • Disconnect the ethernet cable
  • Use the serial connection to reboot
  • Wait for the FB to move the device from active connections to idle connections in the network connections section of the home network.
  • Delete the stale configuration
    • That is only possible when the FB thinks the device is inactive
    • It has only effect when the name of the device has not been changed from what it was when it was first encountered by the FB
    • Sometimes it helps to reboot the FB, but it is not necessary and also does not always speed things up
  • Once deleted, reconnect the ethernet cable
  • After a while (network manager will find a connected cable, and activate the configuration) the host will come up in the FB under its new (public) IPv4.
    • Some chance it’s difficult to spot, because it got a new generic name, based on the IP address.
  • Now the device should be reachable on its public IPv4. Configuration of port forwarding should not pose difficulties.

Troubleshooting

Direct troubleshooting is not really an option via the web interface. AVM asked me to generate support data. After reviewing the detailed logs, I could guess the cause of the problem before sending it to the patient people at AVM.

The support data can be generated by clicking the contents at the left hand bottom, and then FRITZ!Box Support. There are two variants, ‘Generate Support Data’ and ‘Generate Advanced Support Data’. The ‘basic’ version had all that was necessary to point at the cause problem.

The problem, once introduced, is very difficult to resolve from the available functionality in the web interface. There used to be a telnet option, but that was on an older model Fritzbox, with a much earlier version of the OS, at a time when we still had a handset in the house that we could connect to the phone port of the Fritzbox. A quick lookup learns that it needed #96*7* typed on the connected phone to enable telnet, but lacking such a device I have no known option to enable it anymore. Options might be still there with alternative firmwares, but at the moment things run OK.

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.