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…

Print this entry

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.

Print this entry

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