Today I experienced an interesting story with my Mikrotik router at home. While updating the PiHole instance the system hat quite some problems obtaining either system updates but also the PiHole update packages. A ping on 188.8.131.52 showed that the Raspberry – on which the PiHole was hosted – had somewhat between 70-80% packet loss. Pinging the same IP from a Windows machine resulted in 0% packet.
All this happened only on wired connections but did not cause any problmes when connected via wifi.
As the Raspberry is directly attached to the Mikrotik router I also tried to connect it via a switch in between as that’s the setup for the windows machine. Same behavior. Running pings from 3 Linux systems in the network and two Windows systems (even with exchanging network connections to be directly connected to the Mikrotik and connecting through the switch) came up with an interesting result: All Windows machines had hardly any packet loss in 10 mins (<3%) and all the Linux systems had somewhat between 70%-80% packet loss (tested with a ping). Any ping that involved the Mikrotik routers L2 functionality seemed to result in packet loss on the Linux machines. Pinging any other machine on the same subnet worked without problems, but as soon as there was one hob in between the problem occurred.
Interestingly the problem vanished as far as the Torch tool was activated and no more packet loss occurred on any of the systems.
After some additional troubleshooting time (and disabling nearly all Mikrotik-configuration -> Firewall-Rules/Interfaces) the problem seemed to be with the Bridge interface used. It seems that the deactivation of the IP Firewall for the bridge interface caused the problem. After enabling it the behavior vanished and all systems no longer had any packet loss issues.
The repository contains a python-script which can be used to subscribe to an MQTT-server (e.q. mosquitto) and forward all MQTT-message to Zabbix. There the Template can be used to monitore the values sent via MQTT. Currently the Template is mainly intended as an example and requires adaption to your current setup/configuration of tasmote.
Commands to query the auditlog for Zabbix relevant queries and create/import a compiled policy file within Zabbix
Could be adapted to generate policies for any other system.
The suggestion is to set SELinux to permissive (setenforce=0) execute the action and afterwards create the policy based on the logged events. If the policy does not work on the first try after re-enabeling SELinux again it it could happen that a call was blocked (which is also logged within the auditlog) that was not blocked with SELinux in permissive mode. Therefore it could help creating a new human readable policy (.te-file) and checking the first version vs. the second version + merging them.
Sometimes it could happen that we want to run multiple tasks after configuration file has changed instead of just one.
My specific usecase is, that I’m having a role that configures a SSL-certificate and additional SSL settings for an Apache webserver which could run standalone on a server or as a pacemaker resource.
If it is running directly on the server it’s quite simple and a handler is sufficient to restart the Apache service after the role ran through. In case the Apache is running as a pacemaker resource the resource should be restarted instead of the whole service to make sure pacemaker does not get confused. Therefore it is necessary to first check if we have the service running as a pacemaker resource first and execute the corresponding task afterwards so a single task (within our handler) is not sufficient. Using the block statement will also not lead to success but fail with : ERROR! The requested handler 'Apply Apache Config' was not found in either the main handlers list nor in the listening handlers list
My approach to tackle this issue was to “missuse” the handler to only set a variable if something changed. At the end of the role I’m checking if the variable is ture and if so, I’m including/executing my “handler-block”.
# handlers file for common_linux_zabbix_server_web_certificate
#set a fact which is checked at the end of the role-tasks
- name: "Apply Apache Config"
all your other tasks are executed before these following tasks
# workaround to run multiple tasks within a handler -> run the handlers if any of the above tasks did change something to notify the handler
- meta: flush_handlers
- name: "Run multiple tasks as a handler"
- name: "Check if cluster resource exists"
shell: "pcs resource | grep zbx_srv_httpd"
- name: "Restart cluster resource:"
shell: "pcs resource restart zbx_srv_httpd"
when: check.rc == 0
msg: "An error occured when restarting the cluster resurce!"
when: resource_restart.rc != 0
#Just restart the httpd service if no cluster resource was found
- name: "Restart httpd service"
when: check.rc != 0[
Pioneers AV receivers support network control over a proprietary protocol (SC-55 IP) that used a raw IP connection to the AV receivers port 8102.
This provides the possibility to easily control the AV receiver from the smartphone with tools like Tasker to automatically turn on the AV receiver, switch to the Bluetooth adapter, connect to the receiver and play music just by pressing one button instead of fiddling around for a minute will everything is working. However, Tasker itself does not support RAW IP connections and in my experience the Send/Except-Plugin which could be used for sending the commands to the receiver, isn’t as stable as I’d wish that it was.
So I wrote a little flask restful application that works as a HTTP to RAW Pioneer gateway. The script is hosted on a little Raspberry Pi that runs 24/7 and forwards the commands to the AV receiver.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!