Auf einem Debian9 System habe ich das Froxlor auf libnss-extrausers mit Dateien im User eingestellt. Die shadow, passwd und group Dateien in /var/lib/extrausers werden generiert und auch die nsswitch.conf ist wie im Froxlor Backend vorgegeben konfiguriert.

Einige User werden auch korrekt mit "id username" aufgelöst. Andere hingegen nicht.

root@web:~# id kundeftp1
id: 'kundeftp1': no such user
root@web:~# id kundeftp3
uid=10379(kundeftp3) gid=10379(kunde) groups=10379(kunde)

wenn man in der /var/lib/extrausers/shadow jetzt aber nach kundeftp1 sucht, dann gibt es diesen Eintrag auch:

kundeftp1:$zensiert:17912:0:99999:7:::

 

Außerdem fällt auf, dass alle User mit einem "-" im Namen, also bspw "web-kunde" nicht aufgelöst werden können.

 

Mir fehlt ein wenig der Ansatz, wo der Fehler sein könnte. Da einige User aufgelöst werden und andere eben nicht. Auch ein Neustart vom nscd hilft nicht. Es kommt die aktuelle Froxlor Version 0.9.40.1 zum Einsatz.

Das Debian ist ein Debian 9.6

ii  libnss-extrausers               0.6-4                          amd64        nss module to have an additional passwd, shadow and group file
ii  nscd                            2.24-11+deb9u3                 amd64        GNU C Library: Name Service Cache Daemon

 

Ich habe in der nscd.conf den Loglevel mal sehr hoch gesetzt. Dadurch kriege ich ein wenig Infos raus. Im Beispiel von kundeftp1

 

Thu 17 Jan 2019 04:07:54 PM CET - 4027:     GETPWBYNAME (kundeftp1)
Thu 17 Jan 2019 04:07:54 PM CET - 4027: Haven't found "kundeftp1" in password cache!
Thu 17 Jan 2019 04:07:54 PM CET - 4027: add new entry "kundeftp1" of type GETPWBYNAME for passwd to cache (first)
Thu 17 Jan 2019 04:08:04 PM CET - 4027: considering GETPWBYNAME entry "kundeftp1", timeout 1547737694
Thu 17 Jan 2019 04:08:19 PM CET - 4027: considering GETPWBYNAME entry "kundeftp1", timeout 1547737694
Thu 17 Jan 2019 04:08:19 PM CET - 4027: remove GETPWBYNAME entry "kundeftp1"

 

 

 

Direkt nach dem Neustart von nscd kommt

 

Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file /etc/passwd for database passwd
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file `/etc/passwd` (1)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring directory `/etc` (2)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file /etc/group for database group
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file `/etc/group` (3)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring directory `/etc` (2)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file /etc/hosts for database hosts
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file `/etc/hosts` (4)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring directory `/etc` (2)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file /etc/resolv.conf for database hosts
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file `/etc/resolv.conf` (5)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring directory `/etc` (2)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file /etc/services for database services
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file `/etc/services` (6)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring directory `/etc` (2)
Thu 17 Jan 2019 04:07:34 PM CET - 4027: monitoring file /etc/netgroup for database netgroup
Thu 17 Jan 2019 04:07:34 PM CET - 4027: disabled inotify-based monitoring for file `/etc/netgroup': No such file or directory
Thu 17 Jan 2019 04:07:34 PM CET - 4027: stat failed for file `/etc/netgroup'; will try again later: No such file or directory
Thu 17 Jan 2019 04:07:36 PM CET - 4027: handle_request: request received (Version = 2) from PID 4054
Thu 17 Jan 2019 04:07:36 PM CET - 4027:         GETFDPW
Thu 17 Jan 2019 04:07:36 PM CET - 4027: provide access to FD 7, for passwd
Thu 17 Jan 2019 04:07:36 PM CET - 4027: handle_request: request received (Version = 2) from PID 4054
Thu 17 Jan 2019 04:07:36 PM CET - 4027:         GETPWBYUID (100)
Thu 17 Jan 2019 04:07:36 PM CET - 4027: Haven't found "100" in password cache!
Thu 17 Jan 2019 04:07:36 PM CET - 4027: add new entry "100" of type GETPWBYUID for passwd to cache (first)
Thu 17 Jan 2019 04:07:36 PM CET - 4027: add new entry "systemd-timesync" of type GETPWBYNAME for passwd to cache
Thu 17 Jan 2019 04:07:36 PM CET - 4027: handle_request: request received (Version = 2) from PID 4054
Thu 17 Jan 2019 04:07:36 PM CET - 4027:         GETPWBYUID (105)
Thu 17 Jan 2019 04:07:36 PM CET - 4027: Haven't found "105" in password cache!
Thu 17 Jan 2019 04:07:36 PM CET - 4027: add new entry "105" of type GETPWBYUID for passwd to cache (first)
Thu 17 Jan 2019 04:07:36 PM CET - 4027: add new entry "messagebus" of type GETPWBYNAME for passwd to cache
Thu 17 Jan 2019 04:07:36 PM CET - 4027: handle_request: request received (Version = 2) from PID 4054
Thu 17 Jan 2019 04:07:36 PM CET - 4027:         GETPWBYUID (107)
Thu 17 Jan 2019 04:07:36 PM CET - 4027: Haven't found "107" in password cache!
Thu 17 Jan 2019 04:07:36 PM CET - 4027: add new entry "107" of type GETPWBYUID for passwd to cache (first)
Thu 17 Jan 2019 04:07:36 PM CET - 4027: add new entry "proftpd" of type GETPWBYNAME for passwd to cache
Thu 17 Jan 2019 04:07:49 PM CET - 4027: pruning passwd cache; time 1547737669
Thu 17 Jan 2019 04:07:49 PM CET - 4027: considering GETPWBYUID entry "0", timeout 1547737702

 

Hat da jemand einen Rat für mich?

 

Interessant ist noch, dass ein "getent passwd" nicht alle User auflistet die in der /var/lib/extrausers drinstehen sondern nur einige.

Irgendwie wird es immer spannender... getent passwd löst nicht alles auf. getent shadow hingegen kann es:

 

root@web:/etc# getent shadow kundeftp3
kundeftp3:$ZENSIERT:17912:0:99999:7:::

root@web:/etc# getent shadow kundeftp1
kundeftp1:$6ZENSIERT:0:99999:7:::

root@web:/etc# getent passwd kundeftp1

root@web:/etc# getent passwd kundeftp3
kundeftp3:x:10379:10379:Froxlor User:/customers/webs/kunde/:/bin/false

Oh man! Auf sowas muss man auch erstmal kommen..... Anscheinend schleppe ich da seit Ewigkeiten einen "BUG" in meiner Froxlor Userdatenbank mit mir rum. Folgendes:
 

kundeftp1:x:10379:33:Froxlor User:/customers/webs/kunde/www/:/bin/false

 

Die Gruppe steht bei allen Usern die nicht erkannt wird auf 33. Das ist die default www-data Gruppe. Wenn ich die Gruppe ändere auf etwas, das nicht www-data ist funktioniert es 1a.

Würd mich ja jetzt schon interessieren wie da die 33 reinkommt ? uid und gid werden beim anlegen eigentlich auf die Kunden-UID gesetzt, d.h. das kann eigentlich garkeine unterschiedlichen werte haben

@d00p das ist, sagen wir mal, "historisch bedingt". Bevor auf dem System Froxlor eingesetzt wurde, war es per Hand verwaltet. Noch ohne PHP-FPM sondern mit dem PHP Modul vom Apache etc aber zeitgleich mit Logins die per chroot eingeschränkt waren. Da wurde überall bei den Usern die Gruppe www-data eingesetzt. Das ganze ist dann immer mal wieder hin- und hergezogen zwischen Servern, SysCP und Froxlor-Versionen. Und offenbar hat den Part bei einigen Usern nie einer aufgeräumt. Froxlor (bzw deren Vorgänger SysCP) waren nie schuld daran ;)

 

Yay