As a follow up to my previous post as curiosity got the better of me. I decided to see how difficult it would be to set up MariaDB/Grafana/NodeRED on my Synology 1815+. Come to find out it is not that difficult to do so once you figure out the quirks of the UI you have to use.
Here is how to setup docker like I have but in a Synology system.
Recently I got the itch to learn something new and I chose to explore Grafana. Of course, I needed something to graph or make a dashboard out of. So I pondered for a while and during that time I had some trouble with my internet connection. This of course had me looking at my cable modem stats page and that’s where I found my inspiration. So many numbers that are a point in time snapshot that I wished I had a historical graph of. So I set about figuring out how to install Grafana in docker and pull the data in. I quickly found that grafana is a display thing and not a collector and display. This meant that I had to collect the data and store it so that grafana could display it. For this, I figured I could store it in MariaDB, as using that in grafana looked simple enough. The problem I had was getting the data off of the modems stats page. I plinked around with a bash script and a python script, neither did that great for me. About this time I remembered that nodered has some power to it and tried that. I managed to pull the data and store it into MariaDB via nodered. I then managed to display the data via grafana and was rather satisfied with myself.
I have written instructions on how to do this for an SB6183, it might work on an SB6190 with a bit of editing to support the extra channels in grafana. Any other modem you will have to figure out the HTML and how to slice it up and make possibly major changes to the NodeRED flow and possibly the database.
I ran into an issue re-enabling SELinux on my little fleet of CentOS 7 boxes in my home lab. Basically when I installed them I had disabled SELinux at install and thus enabling SELinux was causing all the systems to freeze up after a reboot.
A little googling/digging around mailing lists. I stumbled upon a post that gave a perfect answer to fix the problem I was having.
# setenforce 0
# yum remove selinux-policy\*
# rm -rf /etc/selinux/targeted /etc/selinux/config
# yum install selinux-policy-targeted
# yum install selinux-policy-devel policycoreutils-gui *** Only if these were removed byt the yum remove.
# touch /.autorelabel; reboot
Basically temporary disable SELinux, remove selinux-policy*, remove the old targeted dir and config file, and re-install selinux. Followed by the usualy autorelabel and reboot.
The only thing I would add would be to check your network and ifup the interface after setenforce 0.
Here is a bonus post. I am not going to go into deep details but should be enough to give a good idea on how to do this.
First thing I would suggest creating a second zerotier network from the routed LAN for all the mobile devices. I would make sure the IP subnet is different than anything else, so following example, 10.10.0.0/24 for example. Next set the range to .10-250 of the last octet under advanced. The reason for this is we are going to set a bit on the routervms and turn them into nat routers on their own IPs. Also use one of the higher ips (say .254 perhaps?) as floating IP between the VMs. This way when we route, we route to the .254 and if something having problems, just move the .254 to another host and count to 30 and things should work again.
Now what will make this work for the clients. You need to add routes in the zerotier network. You can do two options and I will give comments on each.
- 0.0.0.0/0 via 10.10.0.254
- This is the most common most people would use. It is a simple common route to push for default route to send everything. The problem I ran into is not everything can take a default route like this out of the box. So I gamed the system with the next one.
- Or Add
- 0.0.0.0/1 via 10.10.0.254
- 188.8.131.52/1 via 10.10.0.254
- The reason this works is we can push two routes and neither is technically default. The reason why this works is that they are more specific. This means these routes would be picked over the default in most cases.
At this point it is time to edit all the routervms to enable nat routing and put the IPs on them.
- Join the routervms to the new VPN network
- Run the following to disable routes pushing to the routervms (that would cause some problems for routing).
- Edit /etc/sysctl.conf and add the following to the bottom
- Edit /etc/sysconfig/iptables
- Now add .1-? to the routervms network configs. So one gets .1 and another gets .2 and so on. This way when they get rebooted they at least show up on the network.
- Now add .254 to only one of the routervms via,
If everything was done right (and I did not skip a step) you should now be able to join a new device and approve it for your network. It should then start sending all its traffic to the designated routervm and hopefully have interent connectivity.
Now the real reason for sending all traffic to the .254 and having it as a secondary ip. I have yet to try to configure this but it should be possible to setup heartbeat or pacemaker to control the .254 address. So that it auto moves for you between the hosts as the fail on the network. Thus ensuring you will always have access across the “VPN”.
At this point if everything works you should be able to ping between the networks. If that isn’t working then you need to troubleshoot what is breaking down communication wise. This could be anything from the two local routers not sharing routes to the routers not talking over zerotier. The point I am trying to push across is that there is no simple gotchas I can offer troubleshooting steps for.
Once connectivity across the LANs is working, the next good thing you want to do is break it of course. First simple break I would suggest is just reboot the router vms. Ideally if everything is setup right and once they are booted back up and the services start, routing should be restored and everything should work again. Again if things do not work the next thing to do is troubleshoot and solve, as there are to many possibilities to mention. I would even suggest break the routing demons and make sure you can repair them as needed.
At the end of this now you have a working multi-site lan that each site has its own working IP subnet.
Final comment: People have asked me is it possible to bridge LANs? The answer is yes but that is an entirely different process and one I would not recommend.