forum.opsi.org

opsi support forum
https://forum.opsi.org/

Probleme nach dem Update von Opsi 4.1 auf 4.2

https://forum.opsi.org/viewtopic.php?t=12636

Seite 1 von 1

Probleme nach dem Update von Opsi 4.1 auf 4.2

Verfasst: 22 Okt 2021, 11:23
von Elryion
Erst mal ein Hallo ins Board und eine bitte um Hilfe. Ich bin mit opsi seit Anfang des Jahres unterwegs und bis jetzt sehr zufrieden und mit einigen Informationen aus dem Forum gut zurechtgekommen. Leider habe ich jetzt ein Problem nach dem Update von opsi 4.1 auf opsi 4.2.

Das Update ist so weit durchgelaufen nach der offiziellen Anleitung durchgelaufen und ich habe wie es auch in der Anleitung beschrieben wurde die ACL-Config durch die neue ersetzt. Jedoch bekomme ich jetzt immer, wenn ich Pakete aktualisiere, installiere oder lösche Fehlermeldungen, dass die Rechte für die config.ini nicht gesetzt werden können.

Paket Installation:

Code: Alles auswählen

[PackageInstallation(1/1)]               [5] [2021-10-22 11:10:41.574] [               ] Installing package 'pdf24-creator-64x_10.6.0-1.opsi' on depot 'vm-opsi.franke.local'   (opsipackagemanager.py:1344)
[PackageInstallation(1/1)]               [4] [2021-10-22 11:10:45.122] [               ] Failed to set rights for path '/var/lib/opsi/config/config.ini': [Errno 1] Operation not permitted: '/var/lib/opsi/config/config.ini'   (File.py:270)
[PackageInstallation(1/1)]               [5] [2021-10-22 11:10:45.129] [               ] Installation of package '/var/lib/opsi/workbench/pdf24-creator-64x_10.6.0-1.opsi' on depot 'vm-opsi.franke.local' successful   (opsipackagemanager.py:1396)
Paket Deinstallation:

Code: Alles auswählen

[Paket-Deinstallation ...(1/1)]          [5] [2021-10-22 11:22:24.250] [               ] Uninstalling package 'pdf24-creator-64x' on depot 'vm-opsi.franke.local'   (opsipackagemanager.py:1464)
[Paket-Deinstallation ...(1/1)]          [4] [2021-10-22 11:22:24.584] [               ] Failed to set rights for path '/var/lib/opsi/config/config.ini': [Errno 1] Operation not permitted: '/var/lib/opsi/config/config.ini'   (File.py:270)
[Paket-Deinstallation ...(1/1)]          [5] [2021-10-22 11:22:24.589] [               ] Uninstall of package 'pdf24-creator-64x' on depot 'vm-opsi.franke.local' finished   (opsipackagemanager.py:1488)
Zudem habe ich auch das Problem beim Packen mit dem opsi PackageBuilder das es wieder Probleme mit dem Zugriff auf die Datei "/etc/opsi/modules" gibt. Ob das miteinander zusammen hängt, weiß ich nicht, war aber bei der 4.1 Version nicht das Problem. Ich habe keine kostenpflichtigen Lizenzen, also fehlt die Datei logischerweise bei mir.
Ein weiteres Problem, das ich nach dem Update hatte, war das zwei Clients keine Verbindungen mehr hatten, weil ich der OpsiHostKey falsch sei. Dies konnte ich nur mit einer Neuinstallation der Clients beheben.

Die üblichen Verdächtigen gerade wegen der Probleme mit den Rechten habe ich durch. Ich habe die beiden Befehle "opsi-setup --init-current-config" "opsi-setup --set-rights" schon probiert und sie halfen mir nicht weiter. Mein Benutzer 'opsi' ist auch Mitglied der Gruppe 'opsiadmin' und auch der Benutzer 'pcpatch' kann über SSH auf die Dateien zugreifen. Ich bin, was die Fehlermeldung mit den Rechten angeht etwas überfragt und hoffe, ihr könnt mir helfen. Vielen Dank schon mal für eure Mühe.

Grüße
Elryion

Re: Probleme nach dem Update von Opsi 4.1 auf 4.2

Verfasst: 22 Okt 2021, 13:50
von mattiasmab
Da sich die Benutzergruppe pcpatch geändert hat und ich nicht weiß, ob das Update inplace erfolgt ist, vielleicht einmal die Gruppenzugerhörigkeiten der Benutzer überprüfen. Was sagt z.B.

Code: Alles auswählen

id -Gn BENUTZER
(für opsiconfd, adminuser, pcpatch, und ggf. eigene Nutzer). Das sollte neuerdings (wenn keine Änderung an der Config u.a. vorgenommen) folgende Gruppen anzeigen: opsiadmin opsifileadmins

Auch gerne mal die Rechte auf dem Weg zu der Datei aus dem Beispiel durchsehen, ob dort an einer Stelle etwas seltsam ist:

Code: Alles auswählen

namei -l /var/lib/opsi/config/config.ini
Wenn das alles nichts gebracht hat einmal prüfen unter welcher Nutzerkennung der Prozess läuft, den man nutzt. Dazu id per z.B. `ps -Af | grep [o]psiconfd` o.d.g. heraussuchen und optional genauer mit `cat /proc/ID_VON_GREP/status` auf die Daten schauen.
Auch schauen, ob der Mountpoint von Var oder einem Unterzweig vielleicht eingeschränkt worden ist.

Re: Probleme nach dem Update von Opsi 4.1 auf 4.2

Verfasst: 08 Nov 2021, 14:12
von Elryion
Danke schon mal für deine Hilfe.
Ich das Problem tatsächlich so noch nicht identifizieren können. Die User pcpatch, opsiconfd und opsi haben allesamt die Gruppenzugehörigkeit zu pcpatch und opsiadmin. Ich habe nur pcpatch der Gruppe opsiadmin hinzugefügt, was leider nichts änderte.

Code: Alles auswählen

id -Gn opsiconfd
pcpatch shadow opsiadmin
id -Gn opsi
opsi cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner pcpatch opsiadmin
id -Gn pcpatch
pcpatch opsiadmin
Die Rechte liegen beim User opsiconfd und der Gruppe pcpatch:

Code: Alles auswählen

namei -l /var/lib/opsi/config/config.ini
f: /var/lib/opsi/config/config.ini
drwxr-xr-x root      root    /
drwxr-xr-x root      root    var
drwxr-xr-x root      root    lib
drwxrwx--- opsiconfd pcpatch opsi
drwxrwx--- opsiconfd pcpatch config
-rwxrwx--- opsiconfd pcpatch config.ini

/var/lib/opsi/config# ls -al
insgesamt 52
drwxrwx--- 7 opsiconfd pcpatch  4096 Okt 22 10:49 .
drwxrwx--- 9 opsiconfd pcpatch  4096 Okt 22 10:53 ..
drwxrwx--- 2 opsiconfd pcpatch  4096 Feb  5  2021 audit
-rw-rw---- 1 opsiconfd pcpatch   530 Okt 15 10:05 clientgroups.ini
drwxrwx--- 2 opsiconfd pcpatch  4096 Okt 19 13:26 clients
-rwxrwx--- 1 opsiconfd pcpatch 15939 Nov  8 13:51 config.ini
drwxrwx--- 2 opsiconfd pcpatch  4096 Feb  5  2021 depots
-rw-rw---- 1 opsiconfd pcpatch  1021 Okt 15 10:05 productgroups.ini
drwxrwx--- 2 opsiconfd pcpatch  4096 Nov  8 13:37 products
drwxrwx--- 2 opsiconfd pcpatch  4096 Feb  5  2021 templates
Dies sieht auch ungefähr in allen Verzeichnissen ähnlich aus, die ich da geprüft habe. Scheint also für mich so weit in Ordnung zu sein. Die Dienste, die ich im Nachgang geprüft habe laufen, wenn ich das richtig verstanden habe unter dem Benutzer opsiconfd und root. Ich habe die komplette Ausgabe aber einmal hier. Uid und Gid 0 ist natürlich root. Gid 992 ist pcpatch und Uid 993 ist der Benutzer opsiconfd. Gid 1001 ist die Gruppe opsiadmin.

Code: Alles auswählen

/var/lib/opsi/config# ps -Af | grep [o]psiconfd
root        738      1  0 13:46 ?        00:00:00 ./opsiconfd start --log-level-stderr=0
opsicon+    745    738  0 13:46 ?        00:00:02 ./opsiconfd start --log-level-stderr=0
opsicon+   1088    745  0 13:46 ?        00:00:00 /usr/lib/opsiconfd/opsiconfd -B -S -E -s -c from multiprocessing.semaphore_tracker import main;main(23)
opsicon+   1089    745  1 13:46 ?        00:00:06 /usr/lib/opsiconfd/opsiconfd --multiprocessing-fork tracker_fd=24 pipe_handle=26

/var/lib/opsi/config# cat /proc/738/status
Name:   opsiconfd
Umask:  0022
State:  S (sleeping)
Tgid:   738
Ngid:   0
Pid:    738
PPid:   1
TracerPid:      0
Uid:    0       0       0       0
Gid:    0       0       0       0
FDSize: 128
Groups:
NStgid: 738
NSpid:  738
NSpgid: 738
NSsid:  738
VmPeak:     4732 kB
VmSize:     4732 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:       804 kB
VmRSS:       804 kB
RssAnon:              96 kB
RssFile:             708 kB
RssShmem:              0 kB
VmData:      304 kB
VmStk:       132 kB
VmExe:        32 kB
VmLib:      1608 kB
VmPTE:        44 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
CoreDumping:    0
Threads:        1
SigQ:   0/7342
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: fffffffffff2feff
CapInh: 0000000000000000
CapPrm: 0000003fffffffff
CapEff: 0000003fffffffff
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Speculation_Store_Bypass:       thread vulnerable
Cpus_allowed:   ffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list:      0-239
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        8
nonvoluntary_ctxt_switches:     25

/var/lib/opsi/config# cat /proc/745/status
Name:   opsiconfd
Umask:  0022
State:  S (sleeping)
Tgid:   745
Ngid:   0
Pid:    745
PPid:   738
TracerPid:      0
Uid:    993     993     993     993
Gid:    992     992     992     992
FDSize: 64
Groups: 42 992 1001
NStgid: 745
NSpid:  745
NSpgid: 738
NSsid:  738
VmPeak:  1011652 kB
VmSize:   954568 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    109504 kB
VmRSS:    109504 kB
RssAnon:           89124 kB
RssFile:           20380 kB
RssShmem:              0 kB
VmData:   188236 kB
VmStk:       276 kB
VmExe:        32 kB
VmLib:     29968 kB
VmPTE:       756 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
CoreDumping:    0
Threads:        13
SigQ:   0/7342
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000180004003
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Speculation_Store_Bypass:       thread vulnerable
Cpus_allowed:   ffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list:      0-239
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        2555
nonvoluntary_ctxt_switches:     2659

cat /proc/1088/status
Name:   opsiconfd
Umask:  0022
State:  S (sleeping)
Tgid:   1088
Ngid:   0
Pid:    1088
PPid:   745
TracerPid:      0
Uid:    993     993     993     993
Gid:    992     992     992     992
FDSize: 64
Groups: 42 992 1001
NStgid: 1088
NSpid:  1088
NSpgid: 738
NSsid:  738
VmPeak:   137360 kB
VmSize:   137360 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:     39224 kB
VmRSS:     39224 kB
RssAnon:           27868 kB
RssFile:           11356 kB
RssShmem:              0 kB
VmData:    27784 kB
VmStk:       132 kB
VmExe:        32 kB
VmLib:     13204 kB
VmPTE:       300 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
CoreDumping:    0
Threads:        1
SigQ:   0/7342
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001005002
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Speculation_Store_Bypass:       thread vulnerable
Cpus_allowed:   ffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list:      0-239
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        1
nonvoluntary_ctxt_switches:     195

/var/lib/opsi/config# cat /proc/1089/status
Name:   opsiconfd
Umask:  0022
State:  S (sleeping)
Tgid:   1089
Ngid:   0
Pid:    1089
PPid:   745
TracerPid:      0
Uid:    993     993     993     993
Gid:    992     992     992     992
FDSize: 64
Groups: 42 992 1001
NStgid: 1089
NSpid:  1089
NSpgid: 738
NSsid:  738
VmPeak:   993964 kB
VmSize:   992020 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:    128272 kB
VmRSS:    126948 kB
RssAnon:          105640 kB
RssFile:           21308 kB
RssShmem:              0 kB
VmData:   229164 kB
VmStk:       132 kB
VmExe:        32 kB
VmLib:     30092 kB
VmPTE:       800 kB
VmSwap:        0 kB
HugetlbPages:          0 kB
CoreDumping:    0
Threads:        16
SigQ:   0/7342
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000001001000
SigCgt: 0000000180004003
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs:     0
Seccomp:        0
Speculation_Store_Bypass:       thread vulnerable
Cpus_allowed:   ffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list:      0-239
Mems_allowed:   00000000,00000001
Mems_allowed_list:      0
voluntary_ctxt_switches:        9735
nonvoluntary_ctxt_switches:     2131
Ich finde auch hier keine Differenz zu dem Dateisystem, es seiden ich übersehe hier etwas gnadenlos. Die konfigurierten Gruppen sind in der /etc/opsi/opsi.conf folgende:

Code: Alles auswählen

[groups]
admingroup = opsiadmin
fileadmingroup = pcpatch

[packages]
use_pigz = True
Ich bin wirklich etwas ratlos. Vielleicht habt ihr ja noch eine Idee.

Vielen Dank noch mal
Elryion

Re: Probleme nach dem Update von Opsi 4.1 auf 4.2

Verfasst: 08 Nov 2021, 16:49
von mattiasmab
Auf den ersten Blick sieht wirklich alles soweit i.O. aus. Ich habe auch mal in den Code geschaut und die entsprechende Funktion, die die Meldung gibt macht nur einen simplen os.chown (siehe: https://github.com/opsi-org/python-opsi ... #L251-L269).

Ich hätte jetzt noch ein paar typische Verdächtige in Reihenfolge der Wahrscheinlichkeit:
  1. Ist SELinux/AppArmor an und blockt den Zugriff evtl.? Schalte das jeweilige System testweise mal aus (SELinux: `setenforce 0`/AppArmor `sudo service apparmor teardown` bzw. `systemctl stop ...`)
  2. Sind aus unerklärlichen Gründen ACLs gesetzt. Da man sie standardmäßig nirgends sieht, wären sie in den bisherigen Ausführung nicht aufgetaucht. Führe mal für alle Zwischenlevel bis zu dem Zielordner (bereits im Post vorhanden) folgendes aus `ls -lZ` und schaue nach einem Eintrag mit einem Plus-Symbol ganz am Ende der Berechtigungen
  3. Prüfe mit `lsof`, ob etwas die Datei blockiert (dürfte das Setzen der Rechte zwar nicht stören - so meine ich - aber ein Versuch Wert)
  4. Dürfte mit dem Problem noch weniger zu tun haben, da die Nutzerrechte stimmen, aber vielleicht wird unpreviligiert gestartet. Was sagt deine sudo-Config? Sind dort auch die Gruppen korrekt drin, wodurch Rechte hin oder her mit Root-Rechten Zugriffrechte gesetzt werden dürfen?
Alle Zeiten sind UTC+02:00
Seite 1 von 1

Powered by phpBB® Forum Software © phpBB Limited

Deutsche Übersetzung durch phpBB.de