Practical experiences from every day IT

  • Saltstack not recognizing new branches even if configured and salt-master restarted

    When working with Saltstack, it happens that when adding new branches via the salt-master configuration, the branches do not immediately get picked up. IMHO it is an unpractical flaw, but the people remaining to develop Saltstack may have other opinions or deeper knowledge about the constraints the git backends gitpython and pygit2 may impose.

    I figured two easy options to get the new branches to work immediately:

    Variant 1: Change config, flush the gitfs caches and restart

    systemctl stop salt-master && rm -rf /var/cache/salt/master/gitfs/* && rm -rf /var/cache/salt/master/file_lists/* && systemctl start salt-master

    Variant 2: Change config, restart, commit & push to the new branch, salt-run filesystem.update (or wait for the git update interval)

    systemctl restart salt-master

# Alibi edit something
# git commit -m "Test"
# git push

salt-run fileserver.update # Or wait for the git update interval

    If you run any salt-syndic, apply the same measures there, too.

  • How does an ATA Secure Erase speed up old SATA SSD’s?

    I recently came across an interesting quirk that I had tasked myself with investigating and figuring out. I had a couple older model Samsung SSD’s which, ran in conjunction with a PERC H730 controller. Unfortunately, as soon as the 1GB controller cache was full, they tumbled from their 500 MB/s design limitation (SATA-3, 6 Gbps) down to something like 30-40 MB/s, which is a horrible performance value for that hardware.

    Unaware of the actual reason for this, I started to poke around in the controller, switching between RAID and non-RAID (HBA-mode), retesting, and turning the controller cache on and off. But nothing really helped; they remained slow.

    As part of poking around I they tried a ATA Secure Erase procedure on one of the disks. The procedure requires 2-3 commands and is described excellently in the Thomas Krenn-Wiki.

    (more…)

  • Grafana replaces datasources from older imported dashboards with the default datasource

    … potentially rewriting the dashboard json code in sometimes unexpected and unwanted ways.

    When importing some old dashboard that used “null” as datasource, newer instances of Grafana do replace this with the default datasource. In my case, where datasources such as Graphite and Prometheus are mixed, this can be very annoying when importing a dashboard that was made for Prometheus.

    One solution can be to bulk-change the occurrences of

    "datasource": null

    with sed:

    sed -i 's/"datasource": null/"datasource": {"type": "prometheus", "uid": "${DS_PROMETHEUS}"}/g' dashboard.json

    This declares the datasource to be a variable datasource to be chosen by a custom annotation.

    It also prevents Grafana from removing correct Prometheus queries for panels, which it does, if it things that the datasource is a Graphite datasource.

  • Kingston SUV500 with Dell PERC H730

    Both the PERC H730 and the Kingston SUV500 are really old hardware. Not only that, they also served two completely different markets: Enterprise versus Consumer. But that should not be a reason for the problem I describe next: There is some strange incompatibility running the Kingston SUV500 with a DELL PERC RAID-Controller (both in RAID- and HBA-mode).

    I recently had acquired some old server hardware to solve the recent, sometimes unpredictable, pricing changes for virtual and dedicated servers. Since the R330’s have plenty of free slots, I have had someone print me a couple of DELL 2,5 inch caddys and off we went to install the machines.

    After the initial installation on the SUV500 as a OS-disk, I started to encounter strange anomalies:

    • getting stuck at “Booting from Harddisk C:”
    • getting stuck at PERC controller initialization “FW initializing 33%”
    • slow performance after controller cache was used

    Forth and back I tried to play with the cache settings as well as HBA-mode, with no success. Updating the SUV500’s firmware on a Windows box that I luckily had around, with no success. Then I researched the problem a little and found that I am not the only one with problems in that constellation.

    And despite the forum members in some forums spreading useless, even stupid misinformation about the interoperability of enterprise- and consumer-hardware, the core truth stays the same: Somewhere in the firmware of at least one of the components there is something wrong. The complexity of reproducing and analyzing the problem deeper might make it impossible or at least very unfeasible for me.

    I went and installed another 2,5 inch SSD for the OS, some Samsung PM8xx model with 256GB. All went fine.

  • Does the MikroTik USB port work with an BELKIN F5D8053 v6?

    Unfortunately, as of May 2026 and RouterOS 7.23, no.

    The BELKIN F5D8053 v6 is basically a Realtek RTL8191SU/RTL8192SU, which currently does not seem to be supported to act as a Wifi interface for RouterOS on ARM32.

  • External USB to ethernet adapter on MikroTik USB port – does that work?

    Short: Yes, it does. But likely only with specific network chips.

    In my case, I tested with a small USB-C docking adapter, which I connected to my hAP ax S via USB-A to USB-C adapter as shown in the picture below. The chip is a Realtek RTL8153, which was immediately recognized by RouterOS and added as “ether6” interface to my interface list. (The hAP ax S without USB attachments features 5 ethernet ports called ether1-5 and 1 SFP port called “sfp1”.)

    MikroTik as of right now does not feature a compatibility list of attachable network chipsets. They have a page called “Peripherals” which poses as a compatibility list for LTE modems, SFP modules and U.2 disks. I will inquire with MikroTik support if they see sense in adding a section for ethernet adapters.

Neueste Beiträge

Englische Beiträge

Eigene Links

Kategorien

Archiv

Links