Checkmk /opt/omd Migration auf eine neue Disk

Global Community Deutsch
1

Hallo,

folgendes Problem: Die Check_MK Installation läuft auf einer Debian 11 VM. Leider haben wir bei der Installation von Debian zum einem mit dem Platz gegeizt und alles auf eine Volume gepackt. Es wurde auch kein LVM aktiviert.

Kurz um, aktuell haben wir ein Platz Problem.

Also haben wir eine weiter Disk eingehängt, Mount Point und fstap angepasst, das /opt mit rsynk -aHv kopiert. Das ganze haben wir vorher mit einem Testsystem getestet alles prima.

Machen wir diese Schritte mit unserem Prod.-System bekommen wir folgenden Fehler nach dem omd Site Start: “is suid bit set on mkeventd open 514? is “no suid” not set on the filesystem” und es wird nur ein Teil von omd gestartet.

Vielleicht ist es ja ganz einfach, wenn das notwendige Wissen vorhanden wäre, was wir sicher nicht haben. :roll_eyes:

Gibt es hier einen Hinweis was wir falsch machen!

Vielen Dank

2

Checkmk verwendet extended attributes, um den Diensten auch im Userspace gewisse Sonderrechte zu geben.

$ xattr -l /opt/omd/versions/default/bin/mkeventd_open514 
security.capability:
0000   01 00 00 02 00 04 00 00 00 00 00 00 00 00 00 00    ................
0010   00 00 00 00                                        ....

Um diese mit rsync zu kopieren, wird das Flag -X benötigt. Das ist in -aHv nicht enthalten.

1 Like
3

Nur etwas verwirrend, wenn die Fehlermeldung statt von extended attributes von einem fehlenden suid bit spricht …

4

Nur kurz mein Einwurf - wenn das ne VM ist warum nicht einfach die Platte größer machen.
Spart den ganzen Kopierkram :wink:

1 Like
5

hatte ich eingangs schon beschrieben. Liegt alles im root Volume und kein LVM bei der Installation verwendet. Wir haben auch nicht die Erfahrung zu Fuß das ganze zu erweitern. Darum war für uns das naheliegendste ein weitere Disk einzuhängen um das ganz etwas zu entzerren um für die Zukunft diesem Problem aus dem Wege zu gehen.
Aber ich glaube das der Fehler vor der Tastatur sitzt :frowning:
Nur weiß ich noch nicht was ich für einen Fehler gemacht habe, da auf dem Testsystem alles funktioniert!

6

es hat sich nun folgendes Kuriosum ergeben, ich versuch es zu erklären:
Es gibt eine VM Debian mit einem Volume darauf ist unter anderem auch omd installiert.
Aus Platzgründen haben wir eine weitere Disk nur für das omd eingehängt.
Dann habe ich das omd Verzeichnis mit rsync kopiert, wie eingangs schon beschrieben, und die fstab mit der uuid der Disk eingefügt. Nach dem Start von omd kommt der beschriebene Fehler. Dann habe ich den Hinweis von Martin versucht um zusetzten. Dabei ist mir folgendes aufgefallen als ich eine Sicherheitskopie der Datei /opt/omd/versions/default/bin/mkeventd_open514 erstellt habe, das diese Kopie auch im Original vorhanden ist. Zur Erklärung: Ich habe das funktionierende /opt/omd umbenannt, also /opt nach /opt.org per mv umbenannt. Wenn ich als Beispiel eine Date erstelle im /opt existiert diese dann auch im /opt.org? Ich bin mir ziemlich sicher, das ich eine Denkfehler bei meiner Vorgehensweise mache, aber welchen.
Hier mal die Aktuell Konfiguration: root@blvcmk01:/# cat /etc/fstab

/etc/fstab: static file system information.

Use ‘blkid’ to print the universally unique identifier for a

device; this may be used with UUID= as a more robust way to name devices

that works even if disks are added and removed. See fstab(5).

/dev/mapper/blvcmk01–vg-root / ext4 errors=remount-ro 0 1

/boot was on /dev/sda1 during installation

UUID=6b40e603-98f4-42aa-b4c5-8a48fad015e0 /boot ext2 defaults 0 2
/dev/mapper/blvcmk01–vg-swap_1 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
tmpfs /opt/omd/sites/pieroth/tmp tmpfs noauto,user,mode=755,uid=pieroth,gid=pieroth 0 0
#/dev/disk/by-uuid/98e0d896-8dc1-4858-85ca-51c01d7c38bf /opt auto nosuid,nodev,nofail 0 0
#/dev/disk/by-uuid/98e0d896-8dc1-4858-85ca-51c01d7c38bf /opt auto nosuid,nodev,nofail,x-gvfs-show 0 0
#/dev/disk/by-uuid/98e0d896-8dc1-4858-85ca-51c01d7c38bf /opt.test auto nosuid,nodev,nofail 0 0
root@blvcmk01:/#

root@blvcmk01:/# df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
udev 5,9G 0 5,9G 0% /dev
tmpfs 1,2G 1,4M 1,2G 1% /run
/dev/mapper/blvcmk01–vg-root 90G 56G 30G 65% /
tmpfs 5,9G 20K 5,9G 1% /dev/shm
tmpfs 5,0M 0 5,0M 0% /run/lock
/dev/sda1 234M 161M 61M 73% /boot
tmpfs 1,2G 108K 1,2G 1% /run/user/1000
tmpfs 5,9G 22M 5,9G 1% /opt/omd/sites/pieroth/tmp
root@blvcmk01:/#

root@blvcmk01:/# fdisk -l
Disk /dev/sda: 100 GiB, 107374182400 bytes, 209715200 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x13c80924

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 499711 497664 243M 83 Linux
/dev/sda2 501758 209713151 209211394 99,8G 5 Extended
/dev/sda5 501760 209713151 209211392 99,8G 8e Linux LVM

Disk /dev/sdb: 100 GiB, 107374182400 bytes, 209715200 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8b5fa565

Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 209715199 209713152 100G 83 Linux

Disk /dev/mapper/blvcmk01–vg-root: 91,74 GiB, 98507423744 bytes, 192397312 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/blvcmk01–vg-swap_1: 8 GiB, 8585740288 bytes, 16769024 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@blvcmk01:/#

7

=> CLI output + command markieren, STRG+E drücken :wink:

aber zu den Problemenen: du kannst die Datei permissions manchmal auch durch eine reinstallation deiner verwendeten checkmk version beheben, der Paketmanager zieht dann normal die fehlenden Permissions zurecht.

Sonst hatte ich mir mal bei ner Umgebung notiert wo wir an die rpm/deb Datei für eine Reinstallation nicht rankamen:

#alles als root 
setcap cap_net_raw+ep /omd/versions/default/lib/cmc/icmpsender
setcap cap_net_raw+ep /omd/versions/default/lib/cmc/icmpreceiver

# setcap wollte zumindest bei mir kein icmp*, daher die einzelnen Aufrufe
# wenn snmp traps verarbeitet werden sollen, dann braucht auch noch ein binary extra capabilites
setcap cap_net_bind_service+ep /opt/omd/versions/default/bin/mkeventd_open514

# für aktive icmp checks genauso: 
setcap cap_net_raw+ep /opt/omd/versions/default/lib/nagios/plugins/check_icmp
1 Like
8

Hallo,
vielen Dank für die Unterstützung.
Aktuell ist das System wieder vollständig was die check’s angeht.
Werde nächste Woche das omd hoch patchen.
=> Hinweis ist angekommen :slight_smile:

9

Ich liebe es, dass mein kleiner Ausfall immer noch Aufmerksamkeit findet. :smiling_face_with_three_hearts:

1 Like
10

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.