simonszu's questions

I am in a situation where i have multiple interfaces for multiple docker networks. All docker networks should be able to access the internet, so i currently have the following nftables snippet:

chain forward {
  type filter hook forward priority 0; policy drop;
  iifname docker0 ct state new accept comment "Accept forwards from docker0"
  iifname dck-backend ct state new accept comment "Accept forwards from dck-backend"
}

Since both rules are very similar but the interface name, i want to merge them into one, if possible. I tried to create a set of interface names:

set docker_interfaces {
    type ifname; flags interval;
    elements = {
      docker0,dck-backend
    }
  }

However, using the set in the rule with

iifname @docker_interfaces accept comment "Accept traffic from docker containers"

results in an error:

Okt 07 10:55:26 naugol nft[968969]: /etc/nftables.conf:40:5-11: Error: Byteorder mismatch: expected big endian, got host endian
Okt 07 10:55:26 naugol nft[968969]:     iifname @docker_interfaces accept comment "Accept traffic from docker containers"
Okt 07 10:55:26 naugol nft[968969]:     ^^^^^^^
Okt 07 10:55:26 naugol systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE

How can i specify more than one interface in a rule, or do i really need several similar rules for achieving this?

According to the docs the Prometheus operator on a OpenShift 3.11 cluster is self-upgrading. However, i have upgraded the cluster to 3.11.141 yesterday, but the operator is still stuck on 3.11.117. There are prometheus images for 3.11.141 available, so i am wondering when this self-update will take place. Can i somehow trigger it manually, maybe deleting the old pods?

OpenShift 3.11 has a builtin Prometheus/Alertmanager/Grafana Stack, which is managed by an Operator. The default Prometheus settings are written in a secret called prometheus-k8s.

I'd like to know how to edit this configuration without the hassle of exporting it, decoding the base64, encoding it again and re-creating the secret, only in risk that the Operator resets the secret to its default setting.

Is the configuration considered to be editable by Red Hat at all, or should i rather deploy my own Prometheus? Or is there a means to extend this secret with my own configuration?

I have an OpenShift Cluster which is spanned between two physical separated datacenters for georedundancy. The nodes are labeled according to their location.

Now i'm searching for a way to configure the scheduler in such a way that if a pod is running with one replica (which is in one of the two datacenters), and an additional replica is started, the additional replica starts in the other datacenters? So that if the deployment is running with an even number of replicas, the replicas are evenly distributed between both datacenters?

I was searching in the pod/node affinity documentation as well as scheduler configuration, but i didn't find anything i need. Maybe i'm just googling wrong?

Any help is greatly appreciated.

I have a configured a cronjob in OpenShift. Its crontab entry looks like this:

spec:
  schedule: "0 3 * * 1-5"
  jobTemplate:

So it should run at 03:00 in the morning on weekdays. All cluster nodes are configured to use our local timezone, CET, which is UTC+1. This is visible via the date command. OpenShift documentation says that cronjobs are executed via the crontab matching the configured time zone of the master nodes, so i expect the cronjobs to actually run at 03:00 CET.

However, according to the logs, the cronjobs are executed at 04:00 which is 03:00 CET in UTC. The strange part is that oc describe cronjob reveals:

Last Schedule Time:  Mon, 14 Jan 2019 04:00:00 +0100

So, the server actually knows that the cronjob is executed one hour too late.

My question is: Why is the cronjob executed one hour too late, why does the server know about it, and how can i fix this?

I have a server with several lxc containers. In some of the containers there is a docker installed. Usually a docker compose action in these LXC containers results in container names with the format appname_service_1, e.g. wordpress_app_1 and wordpress_db_1, when app and db are two services which are called in the wordpress compose file - you know it.

But today i created another LXC container and installed docker in it. The setup is identical to the other containers, thanks to ansible. However, the docker container names are different, e.g. wordpress_db_1_c9de200f9abd. The hash at the end differs whenever i delete the container and re-create it.

Since this makes containers not so disposable as they should be, because it destroys any routes between the containers, i'd like to know why this hashes are appended at all. All LXC containers have the same docker and the same docker-compose version installed. I'd like to prevent these hashes in my docker container names at all.

Why are they now occuring and didn't occur before?

Currently we have a situation where some applications running on our OpenShift cluster request very high resource load, and thus making the worker node they are running on unresponsive. However, we usually only see the process IDs when running top or similar tools on the affected node, plus the executable path, which is the encapsulated path in the pod.

Is there a chance that one can get the associated namespace to these processes which are only known by their PIDs?

I want to set up an instance of Synapse behind an nginx for reverse proxying. Since the nginx is set up with TLS for HTTPS, this somewhat outdated blogpost recommends to set up matrix-synapse with the TLS stuff already used in the nginx vhost, since this is the TLS stuff other servers will see when talking to my instance.

So far i have managed to set up the server so that it is running on its own, and users on this instance can talk to each other. The main problem is the server-2-server-communication, or as the matrix guys calls it, "federation".

This is my TLS setup in matrix-synapse:

tls_certificate_path: "/var/lib/acme/live/matrix.simonszu.de/fullchain"

# PEM encoded private key for TLS
tls_private_key_path: "/etc/matrix-synapse/homeserver.tls.key"

# PEM dh parameters for ephemeral keys
tls_dh_params_path: "/etc/ssl/dhparams/matrix.simonszu.de_dhparams.pem"

# Don't bind to the https port
no_tls: True

The blogpost above states that you can completely comment out the tls_private_key_path, since you have set no_tlsto True (since every TLS stuff is managed by the nginx instance). I have noticed that this does not really work, because in this case, matrix-synapse will search for a key file in obscure places. I cannot link to the associated key file to the certificate, because key management is done by acmetool to obtain certificates from Let's Encrypt, and the automatic renewal process fails if any other file permission than 0600 is set to the key file. But since TLS stuff is managed by nginx anyway, synapse does need this certificate only for the fingerprint presentation for other synapse instances, and effectively ignores the key_path.

I have made sure that this synapse instance is reachable via browser, and that one can fetch the signatures manually. But unfortunately, the initial handshake when communicating with other instances fail.

I have access to another host with its own synapse instance (which is not behind a reverse proxy) and i am able to look at its log files during the handshake process. I get the following errors in its log file: SynapseError: 401: No key for matrix.simonszu.de with id ['ed25519:a_LiWb'].

Further googling led me to a tool called matrixtool, installable via cpan App::MatrixTool so i could check federation communication via command line. The result was also a hint that led me to the idea that there is still something wrong with my TLS setup:

$ matrixtool server-key matrix.simonszu.de
[INFO] Connected to 5.189.143.28:443
[FAIL] TLS fingerprint does not match any listed
[OK] Verified using origin=matrix.simonszu.de key_id=ed25519:a_LiWb
v2 keys from matrix.simonszu.de:

Key id ed25519:a_LiWb
  base64::VF2Cxq3wVEe8NIplwnHK+yKIhdBkgBmzqUfT1k0aMgg
[INFO] Matches cached key

So, i am effectively running out of ideas. During the all the research i realized that i was not the only one with this problem, but the main solution for other users was to give up, and create a matrix-synapse installation without reverse-proxying. So i went, and wrote this question here, to make it clear for once and all times: How do you properly set up matrix-synapse behind a TLS enabled reverse proxy?

i have two machines participating in the DN42 network, a darknet driven by the Chaos Computer Club and others to play around with advanced routing techniques like BGP and stuff.

The machines are connected via an OpenVPN connection and can ping each other. Now, my challenge is: Since i own both machines, i'd like to establish an iBGP connection between them, so that they work in the same AS. I already have successful BGP peerings with other AS, but in this specific case, the propagated routes are marked as unreachable.

If that helps: One of the machine is a debian server, the other one is an OpenWRT router. I am using BIRD to get the BGP connections.

I am quite new to this advanced routing stuff, so i would be glad to receive some help. This is the example BIRD config from one of the machines, the config on the other machine looks similar.

# Configure logging
log syslog { debug, trace, info, remote, warning, error, auth, fatal, bug };

# Override router ID
router id 172.23.211.129;

define myas = 4242421111;

protocol kernel {
    scan time 20;           # Scan kernel routing table every 20 seconds
    import all;
    export where source != RTS_STATIC;
}

protocol device {
    scan time 10;           # Scan interfaces every 10 seconds
}

protocol static {
    route 172.23.211.128/25 via 172.23.211.129;
    #route 172.23.211.0/25 via 172.23.211.1;
}

# Protocol template
template bgp PEERS {
    import all;
    export all;
    #export where source = RTS_STATIC;
 }

 protocol bgp PEER2 from PEERS
{
    description "iBGP to home router";
    #direct;
    local 172.23.211.129 as myas;
    neighbor 172.23.211.1 as myas;
 }

As you can see, i have one /24 assigned to my AS, and i want to split it into two /25 subnets, the first assigned to my home machine, the second assigned to a server in a datacenter. So, now the routes between both machines are imported and exported, but birdc shows them as unreachable, and the kernel routing table shows them without any interface identifier. When i try to reach through the connection to ping some peers of the other machine, the network is unreachable...so, please help me.

I am trying to install Icinga on a FreeBSD 9.1 box with Apache 2.4. I use the Apache config which was provided with the Icinga port.

But when i try to access the web frontend, i get the following error in my log:

AH01276: Cannot serve directory /usr/local/www/icinga/: No matching DirectoryIndex (none) found, and server-generated directory index forbidden by Options directive

I have a DirectoryIndex directive in my httpd.conf, but not in the Icinga config snippet, which uses index.html as an index. The Options directive is Options None.

When i try to specify a custom Directory Index in the Icinga config snippet, i get the following error:

Invalid command 'DirectoryIndex', perhaps misspelled or defined by a module not included in the server configuration

So Google tells me that maybe my mod_dir isn't enabled. Well, it is not in the modules list in httpd.conf where i can uncomment the modules to load, but i have a DirectoryIndex directive in my httpd.conf which is accepted by Apache.

So i am struggling to get the Icinga web frontend to work, and i was hoping that anyone can help me.

I have a custom server running behind an apache reverse proxy. Since the custom server can only handle HTTP traffic, i am trying to use apache for wrapping proper SSL around it, and for some kind of HTTP authentication.

So i enabled mod_proxy and mod_ssl and modified sites-available/default-ssl. The config is as following:

<Location /server>
    order deny,allow
    allow from all
    AuthType Basic
    AuthName "Please log in"
    AuthUserFile /etc/apache2/htpasswd
    Require valid-user
    ProxyPass http://192.168.1.102:8181/server
    ProxyPassReverse http://192.168.1.102:8181/server
</Location>

The custom server is accessible from the internal network via the location specified in the ProxyPass directive.

However, when the proxy is accessed from the outside, it presents the login prompt, and after successfully authenticated, i get a blank page with the words The resource can be found at http://192.168.1.102:8181/server. When i type the external URL again in an already authenticated browser instance, i am properly redirected to the server frontend.

The access.log is full of entrys stating that my browser does successful GET requests, and the proxy is happily serving the /server ressource. However, the ressource isn't containing the server's frontend, but this blank page with these words on it.