Monday 19 April 2021

Kubernetes (k3s) and certificates

 Oh, Kubernetes, how I love thee.

I've been learning and running a small cluster at home on a mix of several Raspberry Pi and a laptop. It's been a great learning experience and although it was all for internal use, I finally decided I'd try to install some certificates.

Ouch! That took a lot longer to figure out than I wanted!

Turns out that if you read up on Kubernetes and cert-manager the recommended practice is to use the nginx-ingress-controller. But when I was trying that it didn't seem to work. 

It turns out that if I had searched for k3s, then I wouldn't have had to do that deployment and I could run it all with Traefik - which is installed by default in k3s. 

So thanks but here is the right way to run cert-manager and Traefik and deploy certificates (like from LetsEncrypt.)

Wednesday 10 March 2021

Home Assistant and Zoneminder troubleshooting

 I've been using Home Assistant for a while, but never really spending a lot of time on it. 

However, as of recently, I've started playing with it a bit more and one of the things that I wanted to do was incorporate my Zoneminder cameras onto the platform.

This is rather easy with a few lines in the configuration.yaml according to the documentation at the Home Assistant page.

zoneminder:

  - host: ZM_HOST

    username: ZM_USER

    password: ZM_PASSWORD

You can add path and path_zms variables if you want.

However, I was having some problems. I kept on getting a json decoder error. 

simplejson.errors.jsondecodeerror: expecting value: line 2 column 1 (char 1)

I initially only had the host, username and password but decided to add the paths. That didn't help. I googled for answers and nothing came up that would suit this.

I couldn't figure out what was going on for a while until I did a tcpdump on the pod and noticed I was getting redirected for certain lines and 404 in others. I then looked at the server longs and that's when I realised, I was hitting the wrong site. 

What I mean is, I run multiple applications on this one host and I was going to the host by IP. I was therefore was getting a different site than intended. At first, I disabled the site to test until it finally clicked. I'm going to the host by IP in my Home Assistant configuration. 

I switched the host value from IP to FQDN and voila! Everything started working.

Monday 5 October 2020

DHCP and DNS - HA at home AKA bind-hole

What is more annoying to people at home, that having their internet services go down? How about the internet service is still working, but other services like DHCP and DNS aren't working and therefore blaming the internet service.

As it turns out, my wifi router at home isn't great at running both of those services. Not only that but because they're on the router, I can't do things like block malware and ads like you can with a pi-hole. If you don't know about the pi-hole, I really think you should give take a look at it. Using a Raspberry Pi, you can run DNS and even DHCP on it and it'll filter all of those ads for you. So, I did that.

Service DID improve quite a bit. People were happy! But, whenever I had to do work on the Pi, like update it, reboot it, etc, then the service would once again go down.

That was when I decided to look at creating a more robust service. Enter 2 Raspberry Pi and ISC's implementation of DHCP. And while I was at it, thought I'd look to see if I could get the same malware and ad blocking as you can with ISC's BIND. The short answer to that was, yes, yes you can.

DHCP


Install DHCP with apt.

sudo apt install isc-dhcpd

DHCP as HA is a piece of cake. Just following the documentation at https://kb.isc.org/docs/aa-00502

You can copy the configs and set the options that are right for your environment. I've put a copy (but slightly modified) version of what I am using. The main thing is to change the key and your IP ranges. Also, if you don't have a domain, you should buy one, they're relatively cheap. You could use the pseudo-tld ".home" so setting up "ns1.yourname.home" would work instead of "ns1.example.org" shown below.

Primary dhcp server


# option definitions common to all supported networks...
option domain-name "bulteel.home";
option domain-name-servers ns1.bulteel.home, ns2.bulteel.home;

default-lease-time 3600;
max-lease-time 7200;

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

failover peer "failover-partner" {
     primary;
     address dhcp-primary.bulteel.home;
     port 519;
     peer address dhcp-secondary.bulteel.home;
     peer port 520;
     max-response-delay 60;
     max-unacked-updates 10;
     mclt 3600;
     split 128;
     load balance max seconds 3;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
  option routers 192.168.1.1, router.bulteel.home;
  pool {
    failover peer "failover-partner";
    range 192.168.1.50 192.168.1.250;
  }

}
# insert this (with your own key text substituted) into dhcpd.conf on primary and secondary.

omapi-port 7911;
omapi-key omapi_key;

key omapi_key {
     algorithm hmac-md5;
     secret generate-this-with-dnssec-keygen-see-isc-docs==;
}

Secondary dhcp server


# option definitions common to all supported networks...
option domain-name "bulteel.home";
option domain-name-servers ns1.bulteel.home, ns2.example.bulteel.home;

default-lease-time 3600;
max-lease-time 7200;

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# This is a very basic subnet declaration.

#subnet 10.254.239.0 netmask 255.255.255.224 {
#  range 10.254.239.10 10.254.239.20;
#  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}

failover peer "failover-partner" {
     secondary;
     address dhcp-secondary.bulteel.home;
     port 520;
     peer address dhcp-primary.bulteel.home;
     peer port 519;
     max-response-delay 60;
     max-unacked-updates 10;
     load balance max seconds 3;
}

subnet 192.168.1.0 netmask 255.255.255.0 {
  option routers 192.168.1.1, router.bulteel.home;
  option domain-name-servers 192.168.1.7, 192.168.1.9;
  pool {
    failover peer "failover-partner";
    range 192.168.1.50 192.168.1.250;
  }

}

# insert this (with your own key text substituted) into dhcpd.conf on primary and secondary.

omapi-port 7911;
omapi-key omapi_key;

key omapi_key {
     algorithm hmac-md5;
     secret generate-this-with-dnssec-keygen-see-isc-docs-copy-from-primary==;
}

Just restart both dhcp servers and make sure they're set to boot up. (systemctl enable isc-dhcp-server ; systemctl restart isc-dhcp-server)

DNS


Now there are two things you need to do for DNS. You need to setup RPZ(s) and then a master/slave setup. Neither of these is hard to do.

First, let's do the master/slave setup.

Install the software on both Pi.

sudo apt install bind9 dns-utils

Configure the master. Configure the slave. Job done. Do you have your own domain and you want to have internal DNS resolution of a host? You can even setup DHCP to dynamically update DNS. 

Bind on Debian separates things into named.conf.local and named.conf.options files.

In the named.conf.local of the master

zone "rpz.example.com" {
        type master;
also-notify { 192.168.1.5; };
        file "/var/lib/bind/db.rpz.example.com";
};


zone "bulteel.home" {
type master;
also-notify { 192.168.1.5; };
file "/var/lib/bind/bulteel.home.hosts";
allow-transfer { 192.168.0.9; };
allow-update { key "rndc-key"; };
};

zone "1.168.192.in-addr.arpa" {
type master;
also-notify { 192.168.1.5; };
file "/var/lib/bind/db.1.168.192.in-addr.arpa";
allow-transfer { 192.168.1.5; };
allow-update { key "rndc-key"; };
};


In the named.conf.local of the slave:

zone "rpz.example.com" {
        type slave;
        file "/var/lib/bind/db.rpz.example.com";
        masters { 192.168.1.4; };
};

zone "bulteel.home" {
type slave;
file "/var/lib/bind/bulteel.home.hosts";
        masters { 192.168.1.4; };
};

zone "1.168.192.in-addr.arpa" {
        type slave;
        file "/var/lib/bind/db.1.168.192.in-addr.arpa";
        masters { 192.168.1.4; };
        };

Once that's done, you add domains to the RPZ file using the py-hole-bind script located

https://github.com/glenpp/py-hole/blob/master/py-hole-bind9RPZ

So, you might be asking about how to get stats and a nice dashboard? Well, that'll be for another blog post. 


Tuesday 31 December 2019

Happy New Year!

2019. The year of crazy! I thought there would be some sanity in the world, but boy was I wrong.

I hope that THIS new year will be great. That 2020 will bring you success.

That 2020 brings sanity! Ohhh, the insanity.

I hope you get to spend it with your family and friends. That the year treats you well.

I don't know what my 2020 will look like. Joy? 2019 sure had its share of emotions.

Well, I wish you all a Happy 2020.

Happy New Year!

Thursday 19 September 2019

Netscaler VPN client on Linux seems to have issues with libraries.

I have to use the Netscaler VPN client on Linux to do some work. However, I noticed that after upgrading to a newer version of Linux (via wipe/reinstall) the client now doesn't seem to work.

The error appears when you run the client on the CLI, otherwise you get nothing. It says:

./NSGClient: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

Great! Let's install libssl. Oh, it's installed. Let's check what libraries it needs/are missing.

ldd NSGClient 
./NSGClient: /lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./NSGClient)
linux-vdso.so.1 (0x00007ffef68d9000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f4a1b1b3000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f4a1b125000)
        ... <cut more output - all libraries present>
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f4a17286000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f4a17263000)

Two things to note from that output.

1. libcurl.so.4 complains about CURL_OPENSSL_3 not found.
2. Two libraries are not found.

So I tried a couple of things all of which complained that the OpenSSL version of the library was needed. A search on my system came up with the steam directory containing the libraries I required!

Well, that's convenient.

I did the following in the /opt/Citrix/NSGClient/bin/ directory.

ln -s /home/user/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libssl.so.1.0.0
ln -s /home/user/.steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
ln -s /home/user/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libcurl.so.4
ln -s /home/user/.steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/librtmp.so.0

Job done. NSG VPN Client now works.

So, if you are in need of the right libraries for your VPN client, install Steam!

Tuesday 23 July 2019

Server: WebProxy/1.0 Pre-Alpha errors? Are you tethering?


Today, I had to tether to my phone and run a few web requests top build a Raspberry Pi. However, the requests were failing. It would "sit there" and it didn't seem to work. I couldn't see anything wrong on the server, but I decided I would try a simple "curl -v" to see what would happen and to avoid TLS issues, I tried HTTP.

I was greeted with:

 < HTTP/1.1 503 Service Unavailable
 < Server: WebProxy/1.0 Pre-Alpha
 < Date: Tue, 23 Jul 2019 10:04:43 GMT
 < Content-Length: 0< Connection: keep-alive

What the heck? I knew my mobile provider had some proxies. I googled and noticed a few people complain about the same thing and then it occurred to me. I'm tethered, could this be my device? Would rebooting fix the issue?

So, since one of the troubleshooting tasks I'd suggest would be "Did you turn it off and back on" I decided to give it a whirl.

Guess what! That fixed the issue.

Monday 20 May 2019

Kodi, inputstream.adaptive and Netflix not working...

In a previous post, I mentioned how I finally solved an issue with the Netflix add-on for Kodi and how items didn't play properly but sound worked fine. It was due to the Raspberry Pi not being powerful enough since it has to do software decoding.

However, I did an update from 9.0.1 version of Libreelec to 9.0.2 and for some reason, Netflix wouldn't even play the video.

Looking through the logs I could see that the /usr/lib/kodi/addons/inputstream.adaptive/ directory couldn't be found which lead to a lot of Googling and no answers. I tried uninstalling, re-installing inputstream.adaptive and tweaking with its settings, even changing LD_LIBRARY_PATH to point to a different location... all in vain.

How did I solve it? I uninstalled the Netflix addon, and reinstalled it.

I removed all settings prior to the removal, but you might not need to do that. I just didn't want to have to deal with it not working and thought it might be a good idea.

So, there you go. Neflix not working on Libreelec (doesn't matter which version) on a Raspberry Pi. Uninstall the addon and add it back in! Why? Not sure... but at least it's working now.