Samba, nscd and winbind

samba
winbind

#1

Hi anybody,

is it nessesary to have the NSCD daemon running in a samba3 (non AD) environment? The other day we checked system state via system diagnostics in UMC. The diagnostics complain on a missing WINBIND daemon.
In the Samba Howto Winbind I read that it’s not a good idea to run both NSCD and WINBIND on the same host.

If so I’d prefer winbind anyway, because NSCD still shuts down every day for unknown reason. Seems to be a pretty old bug?

cheers
sebastian


#2

Good day audiolinux,

you need both NSCD and WINBIND running in the SAMBA3 enviroment.
Concerning the issue of the nscd shutting down, you can provide the nscd with a debug level and a logfile

ucr set nscd/logfile=/var/log/nscd.log nscd/debug/level=4

/etc/init.d/nscd restart

you can then look into the log file and send post a copy.

less /var/log/nscd.log

Regards
Anna Takang


#3

Hey Anna,

Thank you for the hint. At a first glance to NSCDs logfile, I couldn’t find anything special there. It seems NSCD is just giving up at one point.

Fr 03 Nov 2017 02:45:01 CET - 25945:    INITGROUPS (root)
Fr 03 Nov 2017 02:45:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30055
Fr 03 Nov 2017 02:45:01 CET - 25945:    GETFDHST
Fr 03 Nov 2017 02:45:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30055
Fr 03 Nov 2017 02:45:01 CET - 25945:    GETHOSTBYNAME (SERVER)
Fr 03 Nov 2017 02:45:01 CET - 25945: »SERVER« ist im Host-Cache nicht vorhanden!
Fr 03 Nov 2017 02:45:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30055
Fr 03 Nov 2017 02:45:01 CET - 25945:    GETAI (SERVER.DOMAIN)
Fr 03 Nov 2017 02:45:06 CET - 25945: Bereinige »passwd« cache; Zeit 1509673506
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYNAME Eintrag »Administrator«, Timeout 1509674091
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYNAME Eintrag »postfix«, Timeout 1509673506
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYUID Eintrag »2002«, Timeout 1509674091
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYNAME Eintrag »nobody«, Timeout 1509673506
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYNAME Eintrag »administrator«, Timeout 1509674091
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYUID Eintrag »2004«, Timeout 1509674091
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYUID Eintrag »101«, Timeout 1509673506
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYUID Eintrag »0«, Timeout 1509673491
Fr 03 Nov 2017 02:45:06 CET - 25945: »0« erneut in den Password-Cache laden!
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYNAME Eintrag »join-backup«, Timeout 1509674091
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYUID Eintrag »65534«, Timeout 1509673506
Fr 03 Nov 2017 02:45:06 CET - 25945: betrachte GETPWBYNAME Eintrag »root«, Timeout 1509674106
Fr 03 Nov 2017 02:45:21 CET - 25945: Bereinige »passwd« cache; Zeit 1509673521
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYNAME Eintrag »Administrator«, Timeout 1509674091
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYNAME Eintrag »postfix«, Timeout 1509673506
Fr 03 Nov 2017 02:45:21 CET - 25945: »postfix« erneut in den Password-Cache laden!
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYUID Eintrag »2002«, Timeout 1509674091
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYNAME Eintrag »nobody«, Timeout 1509673506
Fr 03 Nov 2017 02:45:21 CET - 25945: »nobody« erneut in den Password-Cache laden!
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYNAME Eintrag »administrator«, Timeout 1509674091
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYUID Eintrag »2004«, Timeout 1509674091
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYUID Eintrag »101«, Timeout 1509674121
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYUID Eintrag »0«, Timeout 1509674106
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYNAME Eintrag »join-backup«, Timeout 1509674091
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYUID Eintrag »65534«, Timeout 1509674121
Fr 03 Nov 2017 02:45:21 CET - 25945: betrachte GETPWBYNAME Eintrag »root«, Timeout 1509674106
Fr 03 Nov 2017 02:49:53 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 2892
Fr 03 Nov 2017 02:49:53 CET - 25945:    GETAI (SERVER.DOMAIN)
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30438
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETFDPW
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30438
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETPWBYNAME (root)
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30439
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETFDPW
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30439
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETPWBYNAME (root)
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30443
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETFDPW
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30443
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETPWBYNAME (root)
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30445
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETFDGR
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30445
Fr 03 Nov 2017 02:50:01 CET - 25945:    INITGROUPS (root)
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30444
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETFDPW
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30444
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETPWBYNAME (root)
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30452
Fr 03 Nov 2017 02:50:01 CET - 25945:    GETFDGR
Fr 03 Nov 2017 02:50:01 CET - 25945: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30452
Fr 03 Nov 2017 02:50:01 CET - 25945:    INITGROUPS (root)
Fr 03 Nov 2017 02:51:01 CET - 30520: Registriere Trace-Datei »/etc/passwd« für die Datenbank »passwd«
Fr 03 Nov 2017 02:51:01 CET - 30520: Registriere Trace-Datei »/etc/hosts« für die Datenbank »hosts«
Fr 03 Nov 2017 02:51:01 CET - 30520: Registriere Trace-Datei »/etc/resolv.conf« für die Datenbank »hosts«
Fr 03 Nov 2017 02:51:01 CET - 30520: handle_request: Anforderung empfangen (Version = 2) vom Prozess 30532
Fr 03 Nov 2017 02:51:01 CET - 30520:    SHUTDOWN

I am surprised that nscd isn’t restarting, even if it is set via ucr variables

nscd/.*/negative_time_to_live: <empty>
nscd/.*/persistent: <empty>
nscd/.*/positive_time_to_live: <empty>
nscd/autostart: yes
nscd/debug/level: 4
nscd/group/enabled: no
nscd/group/invalidate_cache_on_changes: false
nscd/group/maxdbsize: 62914560
nscd/group/negative_time_to_live: 60
nscd/group/positive_time_to_live: 3600
nscd/group/size: 56003
nscd/hosts/enabled: <empty>
nscd/hosts/maxdbsize: <empty>
nscd/hosts/negative_time_to_live: 20
nscd/hosts/positive_time_to_live: 3600
nscd/hosts/size: 6007
nscd/logfile: <empty>
nscd/passwd/enabled: <empty>
nscd/passwd/maxdbsize: <empty>
nscd/passwd/negative_time_to_live: 20
nscd/passwd/positive_time_to_live: 600
nscd/passwd/size: 6007
nscd/restart/interval: <empty>
nscd/restart: yes
nscd/threads: <empty>

cheers
Sebastian


#4

Good afternoon Sebastian,

The displayed log message shows a manual shutdown of nscd and not a crash.

Which version of UCS do you have, is it UCS 4.2? If it is, then immediately after trying to restart, and enabling the program:

# systemctl enable nscd
# systemctl restart nscd
# systemctl status nscd

take a look at the

# journalctl -xn

file.

Also check if the error occurs if nscd/restart is disabled, see here:

root@ucsMaster1:~# ucr search nscd/restart
nscd/restart/interval: <empty>
 If the automatic NSCD restart has been activated through the variable nscd/restart, the restart interval in seconds can be configured here. If no value is set, the restart occurs hourly.

nscd/restart: <empty>
 If this variable is activated (possible values: yes/no) NSCD is restarted in fixed intervals (configurable through the variable nscd/restart/interval). This option can be used to address memory leaks.

root@ucsMaster1:~# 

The proper functioning of nscd is important because, it retrieves the data e.g. users, computers etc.from the LDAP Server.

Regards

Anna Takang


#5

Hey Anna,

since we unset the nscd/restart parameters, nscd does’nt seem to stop anymore :wink: Thank you very much.

Unfortunately, we know recognize some strange situations, when users try to login to the domain, via Windows7 clients. We noticed that:

  • some clients don’t execute the logon-script anymore (Users complain about not seeing any mapped network shares anymore)
  • some users cannot login at all
  • some clients wait “forever” to receive their roaming profile

To Hotfix the situation I deactivated winbind daemon. Since then everything seems to be fine.
Is there anything special with winbindd’s configuration?
Our configuration looks like this:

samba/winbind/max/clients: <empty>
 The maximum number of connections Winbind can serve. If the variable is unset, 500 applies.

samba/winbind/nested/groups: no
 UCS supports nested groups (groups as members of groups). If this variable is set to 'yes', Winbind resolves these nested groups.

samba/winbind/rpc/only: <empty>
 If this variable is set to 'yes', Winbind will use RPC instead of LDAP to retrieve information from AD compatible Domain Controllers.

samba/winbind/trusted/domains/only: yes
 If this variable is set to 'yes', Samba member servers are allowed to use Unix accounts stored in LDAP as UIDs for Winbind users.

winbind/autostart: yes

Cheers
Sebastian


#6

Hi audiolinux,

  • Which system role does your system have? If it is a member server, then it is okay.

You can also check the status of winbind. Even if it is not autostart:

/etc/init.d/winbind status

Regards

Anna Takang.


#7

Hi Anna,

the samba-system is a slave. The problem was, that - for what reason, I can’t remember - we had enabled, the parameter
samba/winbind/nested/groups: yes
I set this to no again. Since then we don’t have any problem anymore.

Thank you very much for your support.

Sebastian