Tag: software

um ipv6 auf einem debian buster system zu deaktivieren, muss man folgendes machen:

am ende der datei /etc/sysctl.conf eine zeile einfuegen:

echo 'net.ipv6.conf.all.disable_ipv6 = 1' >> /etc/sysctl.conf

und die config neu einlesen mit

sysctl -p

wenn man das nur auf einem statt auf allen netzwerk interfaces machen will, muss man das “all” durch das entsprechende interface ersetzen:

echo 'net.ipv6.conf.ens18.disable_ipv6 = 1' >> /etc/sysctl.conf

statt in die eine allgemeingueltige sysctl.conf rein zu schreiben, kann man auch eine gesonderte datei anlegen:

echo 'net.ipv6.conf.all.disable_ipv6 = 1' > /etc/sysctl.d/90-disable-ipv6.conf

diese muss man beim neu einlesen aber auch explizit angeben:

sysctl -p -f /etc/sysctl.d/90-disable-ipv6.conf

ich benutze unbound als resolver fuer meine mailserver. nach dem upgrade von stretch auf buster wurde nichts mehr ins logfile unbound.log unter /var/log/unbound/ geschrieben.

die berechtigungen passen alle, owner und group sind “unbound” und schreiben duerfen beide auch.

wie sich rausgestellt hat, ist apparmor hier das problem. um das schreiben in die logfiles wieder zu erlauben, muss eine zeile in die datei /etc/apparmor.d/local/usr.sbin.unbound eingefuegt werden:

echo "/var/log/unbound/unbound.log rw," >> /etc/apparmor.d/local/usr.sbin.unbound

danach die config datei neu laden

apparmor_parser -r /etc/apparmor.d/usr.sbin.unbound

und unbound neu starten.

service unbound restart

that’s it.

…sagt der automat im mcdonalds. ob das encoding problem irgendwann mal verschwindet?

seit phpmyadmin 4.8 gibt es endlich eine logging funktion fuer die fehlgeschlagenen logins. diese kann man dann wunderbar per fail2ban auswerten. frueher war das eher eine wurschtelei mit customized apache logs oder gar aenderungen an den installierten phpmyadmin dateien (welche nach einem update wieder futsch waren). standardmaessig ist diese logging funktion auch enabled und schreibt die fehlgeschlagenen logins ins php error logfile oder syslog. der parameter in der config.inc.php heisst $cfg[‘AuthLog’] und hat den wert “auto”. phpmyadmin entscheidet dann selbststaendig, ob es ins php error log oder syslog schreibt. in meinem falle machte es das ins php error log. wenn nicht, kann man den wert entsprechend setzen.

hier ist das die datei /var/www/webxxxx/logs/priv/php_errors.log. die eintraege im log haben dieses format:

[19-May-2019 21:07:49 Europe/Berlin] user denied: phpmyadmin (mysql-denied) from 46.246.65.167

zuerst muss man einen entsprechenden filter fuer fail2ban konfigurieren. dazu einfach die datei /etc/fail2ban/filter.d/phpmyadmin.conf mit diesem inhalt anlegen:

[Definition]
denied = mysql-denied|allow-denied|root-denied|empty-denied
failregex = ^.*(%(denied)s).* from $
ignoreregex =

beim debuggen seiner eigenen regex kann die seite debuggex.com sehr hilfreich sein. testen kann man seinen selbst erstellten filter mit diesem befehl:

fail2ban-regex /var/www/webxxxx/logs/priv/php_errors.log /etc/fail2ban/filter.d/phpmyadmin.conf

im ergebnis sollten dann irgendwie so in der art aussehen:

[...]
Lines: 31 lines, 0 ignored, 10 matched, 21 missed
[...]

bei “matched” sollte eine entsprechende anzahl groesser 0 auftauchen. wenn dem so ist, braucht man noch eine “jail” konfiguration fuer phpmyadmin. dazu die datei
/etc/fail2ban/jail.d/phpmyadmin.conf mit diesem inhalt anlegen:

[phpmyadmin]
enabled = true
port = http,https
filter = phpmyadmin
logpath = /var/www/webxxxx/logs/priv/php_errors.log

einmal neu laden ….

service fail2ban reload

… und einfach mal ein paar fehlerhafte loginversuche ausloesen. im php error log sieht das so aus:

[24-May-2019 07:51:45 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx
[24-May-2019 07:51:46 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx
[24-May-2019 07:51:47 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx
[24-May-2019 07:51:48 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx
[24-May-2019 07:51:49 Europe/Berlin] user denied: dasdsadsadas (empty-denied) from 87.xxx.xx.xx

und korrespondierend im fail2ban logfile:

/var/log/fail2ban.log

2019-05-24 07:51:45,862 fail2ban.filter         [1144]: INFO    [phpmyadmin] Found 87.xxx.xx.xx
2019-05-24 07:51:46,936 fail2ban.filter         [1144]: INFO    [phpmyadmin] Found 87.xxx.xx.xx
2019-05-24 07:51:47,952 fail2ban.filter         [1144]: INFO    [phpmyadmin] Found 87.xxx.xx.xx
2019-05-24 07:51:48,832 fail2ban.filter         [1144]: INFO    [phpmyadmin] Found 87.xxx.xx.xx
2019-05-24 07:51:49,592 fail2ban.filter         [1144]: INFO    [phpmyadmin] Found 87.xxx.xx.xx
2019-05-24 07:51:50,303 fail2ban.actions        [1144]: NOTICE  [phpmyadmin] Ban 87.xxx.xx.xx
2019-05-24 08:01:51,276 fail2ban.actions        [1144]: NOTICE  [phpmyadmin] Unban 87.xxx.xx.xx

bei dem jail greifen hier die fail2ban standard werte einer debian 9 installation. nach 5 fehlerhaften logins von einer IP wird diese fuer 10 minuten per iptables geblockt.

that’s it.

…grad ein freenas 11.2 installiert mit dem motherboard asus P10S-I, kam das:

ich war halt per ipmi auf der kiste drauf und da macht “remote media” halt usb devices. und da scheints geklemmt zu haben. abhilfe brachte diese bios einstellung:

to bind pihole-FTL to certain ip adresses, you need to add parameters to dnsmasq. if not exist, create a file /etc/dnsmasq.d/99-my-settings.conf with the following settings:

listen-address=127.0.0.1,10.10.60.9,10.10.61.9,10.10.66.9
bind-interfaces

restart pihole-FTL and verify the result

root@ph:~# netstat -nltup
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
[...]
tcp        0      0 10.10.61.9:80           0.0.0.0:*               LISTEN      762/lighttpd        
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1752/pihole-FTL     
tcp        0      0 10.10.61.9:53           0.0.0.0:*               LISTEN      1752/pihole-FTL     
tcp        0      0 10.10.60.9:53           0.0.0.0:*               LISTEN      1752/pihole-FTL     
tcp        0      0 10.10.66.9:53           0.0.0.0:*               LISTEN      1752/pihole-FTL     
[...]

in zusammenhang mit >diesem< artikel sei hier noch beschrieben, was man machen muss, falls "das eine etwas" fehlt auf dem system, auf dem man die datei ausfuehren moechte.

sudo apt-get install icedtea-netx

und dann einfach den befehl “javaws” mit der entsprechenden file ausfuehren:

javaws filename.jnlp

after removing a pve cluster node that was also a ceph osd and monitor node i realised that i forgot to remove the ceph stuff before removing the node from the cluster. there is no possibility to remove it with the pve gui, so i have to do it on the command line.

to delete it from the ceph crush map:

ceph osd crush rm nodenametoremove

to remove the monitor:

ceph mon remove nodenametoremove

the edit the file /etc/ceph/ceph.conf and remove the complete section for the node.

then edit the file /etc/ceph/storage.conf and remove the ip address of the dead monitor node. this step can also be done via the gui.

in mein kleines serverchen habe ich ein “ASMB8-iKVM” rein gesteckt, damit ich nicht immer in den keller rennen muss, wenn ich mal ne vlan config versaut hab und die kiste nicht mehr erreichbar ist 😉

beim starten der java KVM console kam dieser fehler:

Fatal: Application Error: Cannot grant permissions to unsigned jars.

um das zu beheben, muss man in der datei java.security in dieser zeile:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

...das "MD5" entfernen. (zeile kopieren, auskommentieren, aendern)

#jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024
jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024

bei meinem linux mint liegt die datei unter: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security

gleich vorneweg: nicht offiziell von proxmox unterstuetzt, aber (fuer mich) funktionieren tuts. 😉

fuer meine aktuelle “spielwiesen-evaluierung” habe ich als boot platte eine 500 GB ssd gekauft. da das betriebsystem und swap nur wenige gigabytes benoetigen, moechte den restlichen platz als OSD fuer ceph verwenden. proxmox unterstuetzt von haus aus nur kompletten festplatten als OSD. mit ein paar tricks kann man das aber trotzdem eintueten. dafuer muessen ein paar vorraussetzungen eingehalten und die folgenden schritte ausgefuehrt werden.

1. als grundlage habe ich ein debian stretch installiert. dabei waehlt man am besten den modus “expert install” aus, da man nur in diesem den typ der partition table der festplatte setzen kann. der installer macht standardmaessig eine MBR patrition table, aber wir brauchen zwingend eine des typs GPT!

2. das debian system samt proxmox und ceph installieren (siehe proxmox wiki)

3. danach muss die OSD partition wie folgt angelegt und praepariert werden:

als erstes setzen wir ein paar variablen… der partition typecode “is designating a Ceph data disk”

PTYPE_UUID=4fbd7e29-9d25-41b8-afd0-062c0ceff05d

die festplatte, die verwendet werden soll:

disk=/dev/sda

die nuemmer der partition ist die naechste freie nummer:

part=4

und eine zufaellige UUID wird benoetigt, um die neue OSD zu identifizieren:
(wenns nicht funktioniert, vorher noch das paket “uuid-runtime” installieren)

OSD_UUID=`uuidgen -r`

wenn all diese variablen gesetzt sind, kann mit dem sgdisk kommando die neue partition angelegt werden:

sgdisk --largest-new=$part --change-name="${part}:ceph" --partition-guid=${part}:$OSD_UUID --typecode=${part}:$PTYPE_UUID $disk

der output koennte so aussehen:

Setting name!
partNum is 3
REALLY setting name!
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

um die proxmox boardmittel nutzen zu koennen, muss man ein bischen in einem perl script rumpfuschen… und zwar das: /usr/share/perl5/PVE/API2/Ceph.pm
vorher bitte eine sicherungskopie anlegen, damit man die originale datei im anschluss wiederherstellen kann. (funktioniert mit pve 5.2)
suche in der datei nach diesem string:

$devname =~ s|/dev/||;

…und kommentiere diese und die folgenden zeilen bis zu dieser aus:

my $devpath = $diskinfo->{devpath};

dann fuege diese zeile darunter ein:

my $devpath = $devname;

jetzt suche nach

my $cmd = ['ceph-disk', 'prepare', '--zap-disk',

…und entferne am ende das argument “–zap-disk”, so dass die zeile so aussieht:

my $cmd = ['ceph-disk', 'prepare', 

dann kann man endlich die OSD erstellen:

pveceph createosd /dev/sda4 --bluestore=0

(wenn die fehlermeldung “not a valid block device” kommt, ist noch ein reboot notwendig, damit der kernel die oben abgeaenderte partition table frisst.)

ich habe hier bluestore auf 0 gesetzt, da es bei mir nicht funktioniert hatte. (ich bin mir garnicht sicher, ob man bluestore ueberhaupt mit einer partition verwenden kann… vermutlich eher nicht.) so wird der herkoemmliche typ “filestore genommen und die partition mit xfs formatiert.
der output koennte so aussehen:

create OSD on /dev/sda4 (xfs)
meta-data=/dev/sda4              isize=2048   agcount=4, agsize=29150209 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0, rmapbt=0, reflink=0
data     =                       bsize=4096   blocks=116600833, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=56934, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

und zum schluss noch die OSD aktivieren, wodurch die partition gemountet und der zugehoerige OSD daemon gestartet wird

ceph-disk activate /dev/sda4

und schon ist die partiton unter proxmox als OSD verfuegbar. in der proxmox oberflaeche wird die ganze festplatte als OSD angezeigt, was mich aber nicht weiter stoert 😉