Freifunk Hamburg migriert grade zu Gluon v2018.1.1.
Aktuell haben wir da noch 4 Firmwares für 4 Domains, einer der nächsten Schritte wird sein, das in eine Multi-Domain firmware zusammenzufassen.
Das dürfte einerseits unseren Builder entlasten. Ein voller Build dauert aktuell etwa 12 Stunden.
Andererseits würden wir uns damit das umflashen sparen, wenn Knoten innerhalb der Stadt umziehen.
Gluon v2018.1.1 ist raus. Da wird wohl bald eine Firmware-Update-Welle durch die Communities schwappen.

Release Notes: Gluon 2018.1.1 — Gluon 2018.1.1 documentation

Wer noch nicht auf Gluon v2018.1 ist, hat wohl Glück, unter anderem wurde dieser Bug gefixt:
Fix a bug leading to configuration loss on upgrade under certain circumstances (#1496)
The issue can only occur when upgrading from 2018.1 and there are multiple mirror entries in site.conf (specifically, an early failure for one of the mirrors, e.g. during DNS resolution, followed by a successful upgrade from a different mirror triggers the issue).
Posts not delivered to my hub or not displayed

!Hubzilla Support Forum
I'm trying to figure out how to best follow this forum and possibly other public channels.
I've got a connection, apparently I can post to the support forum and I receive replies to my posts. However I seem to be lacking all the other unrelated posts generated recently: They do not show up im my /network.
I can view them just fine when I visit the channel.
Is there any way I can debug this?
With the logging set to normal I see these messages in my log:
2018-08-16T20:26:43Z:LOG_INFO:6b3096781d:Cron.php:31:run: cron: start
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:5168:zot_reply_notify: notify received from https://zotadel.net
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:HTTPSig.php:170:verify: Content_Valid: true
2018-08-16T20:32:20Z:LOG_INFO:3c0ab27513:zot.php:5168:zot_reply_notify: notify received from https://zotadel.net
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1381:zot_import: public post
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1428:zot_import: No deliveries on this site
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1381:zot_import: public post
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1428:zot_import: No deliveries on this site
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1381:zot_import: public post
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1428:zot_import: No deliveries on this site
2018-08-16T20:32:20Z:LOG_INFO:3c0ab27513:HTTPSig.php:170:verify: Content_Valid: true
2018-08-16T20:32:21Z:LOG_INFO:3c0ab27513:zot.php:1289:zot_import: remote pickup failed: nothing to pick up
2018-08-16T20:33:17Z:LOG_INFO:bc8d923805:network.php:391:http_status: .well-known/nodeinfo:404 Error
2018-08-16T20:33:17Z:LOG_INFO:780d2ff6ad:network.php:391:http_status: .well-known/x-social-relay:404 Error
2018-08-16T20:36:49Z:LOG_INFO:3bbbc486e9:Cron.php:31:run: cron: start

So I believe the server of the support-Channel pings my server.
How can I find out why the posts are not shown to me?
These are the relevant lines:

2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:5168:zot_reply_notify: notify received from https://zotadel.net
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:HTTPSig.php:170:verify: Content_Valid: true
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1381:zot_import: public post
2018-08-16T20:32:20Z:LOG_INFO:f6830daa85:zot.php:1428:zot_import: No deliveries on this site

This says a message arrived, and it's valid. It's a public message, but *nobody on this site is accepting messages from this sender*. This is probably due either to your channel permissions role or specific permissions settings granted by your channel to the support channel.

If you need to debug what's happening, the function which finds deliveries to be performed on this site in the case of public messages is made in include/zot.php: public_recips()

The function is a bit convoluted but at a high level it fetches a list of channels on this site and checks which allow 'send_stream' permissions for the sender.
I think it was the send stream permission causing that. It was set to explicitly granted, not accepted connections.
I'll watch what happens now.
Thanks Mike!
Yep, I already got the first post, so setting the correct send_stream permission solved this.
Welcome to the NixOS channel. I've opened it provide a platform on hubzilla for questions, posts regarding NixOS or to showcase stuff. Feel free to use it to send out NixOS-related content.
  last edited: Mon, 13 Aug 2018 00:50:16 +0200  
Hallo im Freifunk Forum bei Hubzilla.
ich habe das Forum einfach mal aufgemacht, falls es hier bei Hubzilla Personen gibt die sich darüber austauschen wollen oder Fragen haben.
Ich werde vielleicht auch mal ein paar generelle Informationen darüber verteilen, wenn es Neues gibt das nicht nur einzelne Communities betrifft, aber hauptsächlich ist Ziel, damit vielleicht noch ein paar weiteren Personen Freifunk nahe zu bringen und erste Fragen zu beantworten.
!Hubzilla Support Forum
How long does it take for old channels to completely expire and disappear from the network?
I had a redmatrix instance a couple of years back that I just deleted. The channel daniel@rm.besaid.de still floats around the network, despite the server being down for at least 2 years, probably more.
Is there any way to get rid of it if I cannot import it somewhere and then delete it?

Another interesting detail: When browsing the directory and limiting it to just my hub I see my old channel, despite the difference in the URL (rm.besaid.de vs besaid.de).
If you just deleted your old instance, you probably did not delete your channel. That means the channel is not marked deleted anywhere.
If you still have the old channel somewhere, you could probably revive it and delete properly.
I'm pretty sure I have no backup anywhere.
That's probably a bug. If a channel doesn't ping a directory server once a month it should be marked dead after a month or two and should stop being shown in the directory. The "site" query might not look for this.
Hubzilla on NixOS

PHP webapplications usually ignore all sensible conventions that exist in the unix world.
Your typical php webservice needs to be put directly into the document root or a subdirectory of the webserver. That's not a big deal if it is completely static. But usually it is not, it typically needs a somewhat static config.php containing a database password, it may need a temporary directory, a log directory and maybe another directory for long-term storage.
This is bad, because you can't just change a link to point to a different version. This is bad in terms of security because the program must reside in a writeable directory. This is bad because config.php with your precious database password is in a directory that's readable by the webserver.
Typically you have another problem: all php webservices share a common user that they run as.

NixOS and its package manager Nix completely clashes with that.
All derivations are put into /nix/store world-readable and immutable. There's no place for a config.php with a database password in /nix/store. Even root cannot write to /nix/store.
The distinction between application and data is enforced by NixOS.
You could put the webapplication into /srv/www or a similar directory, but you would lose all of the features that make Nix so good.
Instead there's no other sensible option than to split the webapplication into the program and data part. The trick is to set symlinks during the build.
I'm going to use hubzilla as an obvious example here.

Building hubzilla with Nix
Nix first needs some generic information about how and where to download Hubzilla:
{ stdenv, lib, fetchgit, php, dataDir ? null }:
stdenv.mkDerivation rec {
  name = "hubzilla-${version}";
  version = "3.6.1";
  rev = "${version}";

  src = fetchgit {
    inherit rev;
    url = "https://framagit.org/hubzilla/core.git";
    sha256 = "1zaczw4mxxbv7p6xmmf8wpy54jmnf980yd21c4kfncmh3ri0mrf6";

  nativeBuildInputs = [ php ];

  phases = [ "unpackPhase" "installPhase" ];
  installPhase = ''
    cp -Rp ./ $out/
    cd "$out"
    echo Building documentation...
    TEMP=$(mktemp -d)
    ln -s $TEMP/store $out/store
    mkdir -p "$TEMP/store/[data]/smarty3"
    php util/importdoc
    rm -rf "$out/store" "$TEMP/store"
    ${lib.optionalString (dataDir != null) ''
      ln -s ${dataDir}/htconfig.php $out/.htconfig.php
      ln -s ${dataDir}/addon $out/addon
      ln -s ${dataDir}/extend $out/extend
      ln -s ${dataDir}/store $out/store
      mv $out/view/theme $out/view/theme.dist
      ln -s ${dataDir}/view/theme $out/view/theme
      ln -s ${dataDir}/widget $out/widget

If you store the above code in default.nix and build it with nix-build -E 'with import <nixpkgs> { }; callPackage ./default.nix { }', you already get the hubzilla source in a /nix/store and even updated documentation in there. Not special so far.
Try to build it with nix-build -E 'with import <nixpkgs> { }; callPackage ./default.nix { dataDir = "/var/lib/hubzilla" }'.
Now you get a special version that expects its writeable directories and config file in /var/lib/hubzilla. Everytime you change that directory you obviously get a new derivation in /nix/store.
The nice thing about this is that a version upgrade is just a change of the version number in the file and thus rollbacks should work - as long as the database is not upgraded.
I also like that I can give the dataDir permissions that forbid the webserver any access. Only the php processes can access dataDir.

I haven't noticed any downsides yet, but I haven't delved into themes or addons yet, so there may be some issues later.

NixOS is a linux distribution that has a very different approach compared to other distributions.

You do not change configuration files of applications.
You just change the build instructions that the package manager Nix uses to build the system.
On NixOS the full system is rebuilt everytime you want to change even a minor detail.
A rebuild means that the Nix package manager reads in NixPKGs, then reads in your local build instructions (e.g. "services.openssh.enable = true") to complement them and then builds all derivations that are required for this specific configuration.
A derivation is roughly similar to a package in other distributions, but in NixOS even /etc/ssh/sshd_config has its own derivation, meaning that it gets built automatically.
Every derivation that gets built, ends up in a directory in /nix/store, indexed with a checksum over all its version information, build instruction and all its dependencies.
That means when you change the build instructions (even if you just insert an irrelevant space in a field somewhere), change a dependency or update to a newer version, Nix will put it into a different directory in /nix/store.
That in turn means that Nix can easily determine if it has already built a specific configuration or program with its specific dependencies. If the path in /nix/store exist, it has already been built.
Oh, and /nix/store is immutable. You are not supposed to change any files in there and there are many good reasons to just accept that and not even try it. If you want to make a change, edit the build instructions or the system configuration and let Nix rebuild the system.
By following that, you gain the ability to just rollback to older versions (called generations) of your system configuration.
Made a change and noticed that it doesn't work well?
sudo nixos-rebuild --rollback
And you're good.
The system doesn't boot anymore because of a software problem?
Hit space in the boot manager and boot an older generation.
Your harddisk failed and you have to reinstall your system?
With NixOS you still have to partition your drive manually from the installation CD/DVD, that's a bit annoying. But then you just copy /etc/nixos from your backup, tell Nix to install the system (completely non-interactive). Finally restore your /home from the latest backup and your system will be in exactly the same state as before the disk failure. Well ok: it will be in the same state as your last backup.
But there is no question about the packages you had installed or their versions.
Also the system configuration is completely included in /etc/nixos, so just backing up /etc/nixos and /home is sufficient for a desktop or laptop.
For servers you obviously may need other directories as well, but that depends on the applications running on them.

On my systems /etc/nixos is a git repository. That's enough to allow me to share this system configuration on multiple systems.
I'm using NixOS since 2015 now and I really don't want to go back.
Ansible and Puppet are just workarounds for the package and /etc hell.
  last edited: Sat, 11 Aug 2018 17:25:33 +0200 Expires: Sun, 30 Sep 2018 17:22:00 +0200  
Good morning.
It appears my old channel is still floating around the network, even though the server has been down for at least 2 years now.
No idea how I can get rid of it, so I'll just ignore it.
I'm back to Redmatrix... or Hubzilla as it's called now.
I'm going to explore the network a bit again and probably write a couple of posts about technical things every now and then.

To give you a rough idea of my interests:
I'm active in the Freifunk Hamburg community, every now and then in the hacker space of the CCCHH and working as a Solaris and Linux system administrator.
I use NixOS, so expect some posts regarding this linux flavour.