• 08621 - 9 88 30 88

Autor-Archiv cubewerk

Voncubewerk

Java ILO 3 – unknown ressource

Windows 10, altes HP ILO, beim Starten der JavaWS-Anwendung kommt nur unknown ressource.

Lösung ist, im IlO unter Administration -> Security > Encryption – Enforce zu aktivieren.

Voncubewerk

InnoDB: is in the future! Your database may be corrupt

Heutige Übung. Warum? Kunde hat im Betrieb die USV des Servers gewechselt.

Nach dem Wiederanlauf war die DB eines Kopano-Servers defekt. Was tun?

DB starten mit innodb_force_recovery=1. Wenn 1 nicht reicht, jeweils vorsichtigt hochzählen, bis die DB läuft.

DB abziehen, die vermutlich die defekte ist. mysqldump -u root -p kopano > sqldump.sql

Daumen drücken.

defekte DB löschen via mysql-Konsole mit drop database kopano;

Exportiere DB importieren mit mysql -u root -p kopano < sqldump.sql

innodb_force_recovery wieder deaktivieren (aus Konfig nehmen).

DB starten und hoffen.

Falls die DB meckert ala

ERROR 1813 (HY000) at line 25: Tablespace for table ‚kopano.abchanges‚ exists. Please DISCARD the tablespace before IMPORT.

in /var/lib/mysql/kopano/ alle Dateien löschen und erneut versuchen.

Voncubewerk

pfsense 2.4.5 to 2.5 vpn issue

Check the compression. PFsense 2.5 has a more secure compression setup by default.

Voncubewerk

HE ipfire ipv6 tunnel Ladeproblem von Webseiten, MTU

If you have a dual stack network you can have different MTU settings for ipv4 and ipv6.

Even though the adapter itself shows only one MTU, for ipv6 connections, the v6-MTU can be different.

As the hurricane electric tunnel has a maximum MTU of 1480, one needs to lower the interface MTU to a reasonable value.

If you have a pfsense firewall, simply set the LAN interface MTU to the value you would like to announce via radvd.

This leads to the following network/path-mtu for a linux system:

2: enp0s25: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 3c:97:0e:eb:a1:c4 brd ff:ff:ff:ff:ff:ff

But thats only the IPv4 MTU. For ipv6 we see:

$ cat /proc/sys/net/ipv6/conf/enp0s25/mtu
1450

Voncubewerk

Ceph Disks erscheinen nicht in Proxmox

Fügt man über die Proxmox-GUI neue Ceph-OSDs hinzu, und sind oder waren diese schon einmal im Einsatz, sperrt sich ceph.

Manuell folgender Ablauf um den Fehler und die Lösung anwenden zu können:

Alle Partitionen der alten Disk löschen mit fdisk

Sicherheitshalber erneut Anfang überschreiben mit

dd if=/dev/zero of=/dev/sdh bs=1M count=1024

pveceph createosd /dev/sdh

ceph-disk activate –reactivate /dev/sdh1

command_with_stdin: Error EEXIST: entity osd.5 exists but key does not match

mount_activate: Failed to activate
‚[‚ceph‘, ‚–cluster‘, ‚ceph‘, ‚–name‘, ‚client.bootstrap-osd‘, ‚–keyring‘, ‚/var/lib/ceph/bootstrap-osd/ceph.keyring‘, ‚-i‘, ‚-‚, ‚osd‘, ’new‘, u’76f18359-8316-4c87-9d8c-347bc28b13e2′]‘ failed with status code 17

ceph auth del osd.5

updated

ceph-disk activate –reactivate /dev/sdh1
creating /var/lib/ceph/tmp/mnt.RmzzZA/keyring

Voncubewerk

Hafnium Exchange Lücke – Was ist zu tun?

hiermit möchten wir Sie über ein kritisches IT-Sicherheitsproblem informieren, welches umgehenden Handlungsbedarf erfordert. Sicherlich wurden Sie bereits von Ihrem IT-Dienstleister darüber informiert. Wir möchten nur sicher gehen!

Worum geht es?

Derzeit findet ein großangelegter Hackerangriff auf Microsoft Mailserver statt. In Deutschland sind es bereits zehntausende betroffene Systeme.
Mit jeder Stunde werden weitere Systeme infiziert.

Bin ich betroffen?

Wenn Sie selbst einen Microsoft Exchange Mailserver besitzen, besteht der erhebliche Verdacht, dass Ihr Mailsystem bereits angegriffen wurde oder noch angegriffen wird. Dringendes und umsichtiges Handeln ist erforderlich. Ein reines Einspielen der von Microsoft bereitgestellten Updates reicht keineswegs aus.

Verwenden Sie ausschließlich Exchange online, sind Sie hiervon nicht betroffen.
Alle cubewerk-Installationen sind reine Linux-basierte Mailsysteme und von dieser Angriffswelle nicht betroffen.


Welches Ziel verfolgen die Angreifer?

Da die Lücke dem Hersteller seit mehreren Monaten bekannt ist, jedoch erst seit wenigen Tagen Updates zur Verfügung gestellt wurden, existiert ein zeitlicher Bereich von ca. 3 Monaten, die Hacker als Vorsprung besitzen.

In der Regel verschaffen sich die Angreifer vollen Zugang zum internen Mailsystem, installieren Hintertüren und leiten darüber Daten aus oder begehen über Ihr System als Sprungbrett, weitere Angriffe auf Systeme Dritter. Auch eine spätere Lösegeldforderung ist vorstellbar.

Was passiert, wenn ich nicht sofort reagiere?

Kann bei sofortiger Reaktion u.U. ein Angriff noch abgewendet werden, fällt mit jeder Stunde die Chance. Sind einmal interne Systeme durch Hacker übernommen, entstehen erhebliche Kosten für die Wiederinbetriebnahme Ihrer IT-Landschaft. Aber auch der Arbeits- und Produktionsausfall darf nicht unterschätzt werden.
Hinzu kommen datenschutz- und strafrechtliche Vergehen, falls personenbezogene Daten ausgeleitet wurden oder weitere Angriffe auf Unbeteiligte, über Ihre IT-Landschaft erfolgen.


Was sollte ich tun?
 

  • Sprechen Sie umgehend mit Ihrem IT-Dienstleister
  • Installieren Sie umgehend alle verfügbaren Updates
  • Prüfen Sie alle Log-Dateien Ihrer Mail- und Domänenkontroller auf auffällige Einträge mit Ihrem IT-Dienstleister im 4-Augen-Prinzip
  • Führen Sie umfangreiche Offline-Prüfungen der beteiligten Systeme durch
  • Prüfen Sie Firewall- und IDS-Systeme auf Alarme
  • Überwachen Sie Prozesse- und Benutzeranmeldungen an zentraler Stelle



Ich wurde erfolgreich angegriffen – was kann ich tun?
 

  • Melden Sie den Vorfall umgehend der Datenschutzaufsichtsbehörde in Ihrem Bundesland
  • Nehmen Sie infizierte Systeme sofort vom Netz
  • Analysieren Sie den Vorfall im 4-Augen-Prinzip mit Ihrem internen oder externen IT-Dienstleister
  • Führen Sie eine forensische Analyse durch und erstellen einen Notfallplan für die Wiederinbetriebnahme
Voncubewerk

proxmox zeigt keine Images im Ceph Pool rbd error: rbd: listing images failed

Heute beim Klonen einer VM passiert. Der Klon-Vorgang hat sich aufgehängt. Auf einmal keine Images mehr in der Proxmox-GUI einsehbar und wird mit obiger Fehlermeldung quittiert.

Lösung (auf der Konsole):

ceph ls rbd_nvme (oder wie euer Pool heißt)

Zeigt dann am Anfang den Übeltäter bzw. das „faule“ Image:

2021-03-09 18:43:59.960 7fc7e1ffb700 -1 librbd::io::AioCompletion: 0x563bab8db530 fail: (2) No such file or directory
rbd: error opening vm-705-disk-0: (2) No such file or directory
NAME SIZE PARENT FMT PROT LOCK

Lösung ist, das faule Image zu löschen mit

root@proxmox:~# rbd rm rbd_nvme/vm-705-disk-0
Removing image: 100% complete…done.
root@proxmox:~# rbd ls -l rbd_nvme
NAME SIZE PARENT FMT PROT LOCK
vm-103-disk-0 96 GiB 2 excl

Voncubewerk

ceph rename disks / disks umbenennen

Verfügbare disks/volumes anzeigen mit

rbd ls

Umbennen dann mit

rbd mv pool_name/old_image pool_name/new_image

rbd mv rbd_nvme_storage/vm-699-disk-0 rbd_nvme_storage/vm-699-disk-6

Voncubewerk

ldap_modify: Other (e.g., implementation specific) error (80) SOLVED / LÖSUNG

If you want to have SSL-support in openldap/slapd, you need to specify the certificate & key and let slapd listen on appropriate port.

Make sure you have cert & key in place and prepare following ldif file:

dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/cert.pem

dn: cn=config
changetype: modify
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/key.key

ldapmodify -Y EXTERNAL -H ldapi:/// -f enable_ssl.ldif -v

If you fail at this step with

ldap_modify: Other (e.g., implementation specific) error (80)

check the following things:

  • Can the openldap-user read both files and can the directory itself be accessed?
  • does the cert and key really match? REALLY!.

Both output must be the same:

# openssl rsa -noout -modulus -in /etc/ldap/key.key | openssl md5
(stdin)= 45b4165df200817a20857fb453acd33e
# openssl x509 -noout -modulus -in /etc/ldap/cert.pem | openssl md5
(stdin)= 45b4165df200817a20857fb453acd33e

  • is the key and cert-file really a key and cert?

# head -n2 /etc/ldap/cert.pem
—–BEGIN CERTIFICATE—–
MIIFmDCCBICgAwIBAgIQBFMR6HMGTGjQIjSj4sQX+TANBgkqhkiG9w0BAQsFADBu
# head -n2 /etc/ldap/key.key
—–BEGIN RSA PRIVATE KEY—–
MIIEowIBAAKCAQEAvrDddMwXoy10diqDpqd45jaC8HiGKz7KC5X3W0ZLvCshylu0

a successful import looks like the following:

ldapmodify -Y EXTERNAL -H ldapi:/// -f enable_ssl.ldif -v

ldap_initialize( ldapi:///??base )
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
add olcTLSCertificateFile:
/etc/ldap/cert.pem
modifying entry „cn=config“
modify complete

add olcTLSCertificateKeyFile:
/etc/ldap/key.key
modifying entry „cn=config“
modify complete

Voncubewerk

kopano Die Ordnerberechtigungen konnten nicht gesetzt werden

Ziel war, dass ein Postfach für andere Benutzer geteilt werden soll. Rechtsklick auf Ordner, Eigenschafte, Berechtigungen, Benutzer auswählen und peng, obige Fehlermeldung.

Grund war, dass die Ansicht nach dem Klick auf Benutzer auswählen, veraltet war. Der Kunde hatte zwischenzeitlich Kontakte aus dem globalen Adressbuch ausgeblendet. Dadurch war der User zwar noch zwischengespeichert in der Übersicht, tatsächlich aber nur noch eine Referenz ins Leere.

Abhilfe schafft, Benutzer kurzfristig im globalen Adressbuch einblenden, freigeben, ausblenden. Im UCS-Server wie folgt erkennbar in der GUI:

Bug dahinter: https://jira.kopano.io/browse/KW-2731 (2018…)