Autor: Gerd

webkit1.0 und Fedora 27

Fedora 27 fehlt ein Paket für webkit1.0. Wenn man es jedoch dennoch braucht (z.B. für den Citrix Receiver) hilft folgender Trick. gnucash bringt webkit1.0 mit. sudo dnf -y install gnucash cd /usr/lib64 sudo ln -s gnucash/libwebkitgtk-1.0.so.0.22.17 /lib64 sudo ln -s gnucash/libwebkitgtk-1.0.so.0 /lib64 sudo ln -s gnucash/libwebkitgtk-1.0.so /lib64 sudo ln -s gnucash/libjavascriptcoregtk-1.0.so /lib64 sudo ln -s … „webkit1.0 und Fedora 27“ weiterlesen

Fedora 27 fehlt ein Paket für webkit1.0. Wenn man es jedoch dennoch braucht (z.B. für den Citrix Receiver) hilft folgender Trick. gnucash bringt webkit1.0 mit.


sudo dnf -y install gnucash
cd /usr/lib64
sudo ln -s gnucash/libwebkitgtk-1.0.so.0.22.17 /lib64
sudo ln -s gnucash/libwebkitgtk-1.0.so.0 /lib64
sudo ln -s gnucash/libwebkitgtk-1.0.so /lib64
sudo ln -s gnucash/libjavascriptcoregtk-1.0.so /lib64
sudo ln -s gnucash/libjavascriptcoregtk-1.0.so.0 /lib64
sudo ln -s gnucash/libjavascriptcoregtk-1.0.so.0.16.19 /lib64

PS: Alles auf eigene Gefahr, denn webkit1.0 ist depricated.

vim Swap File löschen

vim löscht auch nach dem recovern (wiederherstellen) kein swapfile. Beim Öffnen kommt wieder die Meldung was getan werden soll, darum einfach im vim selbst löschen: :!rm .%.swp

vim löscht auch nach dem recovern (wiederherstellen) kein swapfile. Beim Öffnen kommt wieder die Meldung was getan werden soll, darum einfach im vim selbst löschen:

:!rm .%.swp

Statische Routen mit dem NetworkManager

Ich hatte eben das Problem, dass ich statische Routen für eines meiner OpenVPN Tunnel anlegen wollte. Das Problem war jedoch, dass der NetworkManger keine „pseudo“ IPs via vpn_gateway oder ähnliches akzeptiert. Daher blieb mir nur der Weg über ein Skript. Beim Up und Down einer Netzwerkverbindung ruft der NetworkManager die Dispatcher Skripte unter /etc/NetworkManager/dispatcher.d/ auf. … „Statische Routen mit dem NetworkManager“ weiterlesen

Ich hatte eben das Problem, dass ich statische Routen für eines meiner OpenVPN Tunnel anlegen wollte. Das Problem war jedoch, dass der NetworkManger keine „pseudo“ IPs via vpn_gateway oder ähnliches akzeptiert. Daher blieb mir nur der Weg über ein Skript. Beim Up und Down einer Netzwerkverbindung ruft der NetworkManager die Dispatcher Skripte unter /etc/NetworkManager/dispatcher.d/ auf. Daher habe ich

  1. Der entsprechenden NetworkManager Verbindung ein fixes Interface zugeordnet (im Beispiel tun2) und
  2. Mir folgendes Skript /etc/NetworkManager/dispatcher.d/98-private-routes gebaut:

    [shell]
    #!/bin/sh

    if [ „$1“ == „tun2“ ]; then

    GW=`route -n | grep tun2 | grep „0.0.0.0“ | grep „255.255.255.255“ | cut -f1 -d“ „`
    echo $1“ „$2“ „$GW > /tmp/foo

    case „$2“ in
    up|vpn-up)
    ip r a 192.168.128.12/32 via $GW # VM
    ip r a 10.0.0.0/16 via $GW # 10er Netz
    ;;
    esac

    fi

    [/shell]
    Down ist nicht notwendig, da die Routen sowieso mit dem Interface wegfliegen

Softraid und regelmäßige Checks

Mein Softraid checkt sich jede Woche Sonntags, nachdem ich aber das a) zu häufig finde und b) ich lieber Montags checke habe ich folgende Änderung gemacht: /etc/cron.d/raid-check # Run system wide raid-check once a week on Sunday at 1am by default #0 1 * * Sun root /usr/sbin/raid-check # Run system wide raid-check once a … „Softraid und regelmäßige Checks“ weiterlesen

Mein Softraid checkt sich jede Woche Sonntags, nachdem ich aber das a) zu häufig finde und b) ich lieber Montags checke habe ich folgende Änderung gemacht:

/etc/cron.d/raid-check

# Run system wide raid-check once a week on Sunday at 1am by default
#0 1 * * Sun root /usr/sbin/raid-check

# Run system wide raid-check once a month on Monday at 1am by default
0 1 1-7 * * root [ "$(date '+%a')" == "Mon" ] && /usr/sbin/raid-check

Manuell lassen sich übrigens Raidcheck wie folgt anstoßen:
echo "check" >/sys/block/md0/md/sync_action
und abbrechen:
echo "idle" >/sys/block/md0/md/sync_action

a more aggressiv fail2ban

So manche IP-Ranges aus dem Reich der Mitte können einen ganz schön auf die Nerven gehen. Kaum blockt fail2ban eine IP geht es gleich mit der nächsten aus dem gleichen Class C Netz weiter. Ich hab jetzt mal mein fail2ban so umgebaut, dass nicht nur einfach eine IP geblockt wird, sondern gleich das ganze Class … „a more aggressiv fail2ban“ weiterlesen

So manche IP-Ranges aus dem Reich der Mitte können einen ganz schön auf die Nerven gehen. Kaum blockt fail2ban eine IP geht es gleich mit der nächsten aus dem gleichen Class C Netz weiter. Ich hab jetzt mal mein fail2ban so umgebaut, dass nicht nur einfach eine IP geblockt wird, sondern gleich das ganze Class C Netz. Ich bin wie folgt vorgegangen:

  1. action kopieren
    cp /etc/fail2ban/action.d/shorewall.conf /etc/fail2ban/action.d/shorewall24.conf
  2. actionban und actionunban angepassen
    jeweils /24 ergänzen:
    actionban = shorewall drop <ip>/24
    actionunban = shorewall allow <ip>/24
  3. default banaction ändern
    in /etc/fail2ban/jail.conf die folgende Zeile um 24 ergänzen
    banaction = shorewall24
  4. fail2ban neu starten
    /etc/init.d/fail2ban restart

Fertig.

PS: das ganze geht natürlich auch wenn man nicht die Shorewall sondern iptables-multiport als banaction verwendet. Dann eben halt statt shorewall überall iptables-multiport verwenden.