gelöst: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Probleme mit Samba, NFS, FTP und Co.
Antworten
chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

gelöst: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 01.02.2017 22:13:10

Hallo zusammen,

auch wenn es schon ein paar ähnliche Beiträge gibt: es ist doch wieder anders.

Die Konfiguration des Active Directory funktioniert "eigentlich" schon seit längerem gut, orientiert habe ich mich (unter anderem) an der Anleitung von: http://wiki.debian.org/AuthenticatingLi ... eDirectory
Gefühlt seit dem Update auf Debian 8.7 gibt es aber vermehrt Probleme bei der Anmeldung von Domänenbenutzern (Anmeldung nicht möglich):

journalctl liefert folgende Erkenntnis:

Code: Alles auswählen

pam_krb5(sshd:auth): authentication failure; logname=...
pam_unix(sshd:auth): check pass; user unknown
pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=...
und auch "getent passwd" listet entweder nur die lokalen Benutzer auf, oder braucht bis zu 18 Sekunden(!), um die (ca. 800) Domänenbenutzer anzuzeigen.
Danach (oder behelfsweise mit einem "service winbind restart") funktioniert wieder alles perfekt.
Es scheint so, als hängt winbind beim Kontakt zum Domänenkontroller.

/etc/samba/smb.conf

Code: Alles auswählen

[global]
   security = ads
   realm = XXX.ABCD
   workgroup = XXX

   # Wir haben den Windows DC und brauchen nicht "Samba name server" zu sein.
   local master = no

   # Für Kerberos:
   client use spnego = yes
   client ntlmv2 auth = yes
   encrypt passwords = yes
   restrict anonymous = 2

   # Für winbind:
   idmap config * : backend = tdb
   idmap config * : range = 11000-20000

   winbind enum groups = yes
   winbind enum users = yes

   winbind use default domain = yes
   winbind refresh tickets = yes

   template homedir = /home/%D/%U
   template shell = /bin/bash
/etc/nsswitch

Code: Alles auswählen

passwd: compat winbind
group:  compat winbind
shadow: compat

hosts:  files wins
libpam-winbind und libnss-winbind sind installiert und das ist meine

/etc/pam.d/common-auth

Code: Alles auswählen

# here are the per-package modules (the "Primary" block)
auth	[success=4 default=ignore]	pam_krb5.so minimum_uid=1000
auth	sufficient                      pam_script.so 
auth	[success=2 default=ignore]	pam_unix.so nullok_secure try_first_pass
auth	[success=1 default=ignore]	pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
# here's the fallback if no module succeeds
auth	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config
Geht es noch jemandem so, oder gibt es Ideen, was da falsch läuft?
Zuletzt geändert von chmeyer am 10.09.2017 21:27:17, insgesamt 1-mal geändert.

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 02.02.2017 07:02:47

Nachtrag:

Vielleicht sollte ich bei winbind / NSS Problemen noch schreiben, das ich keinen Cacher für NSS einsetzte, weil der AD-Server ja "eigentlich" immer verfügbar ist und auch nur dann eine Anmeldung möglich sein soll, wenn der Windows-Server "bereit" ist.

Aber vielleicht habe ich ja auch etwas falsch verstanden und genau hier liegt das Problem. Dann stoßt mich bitte mit der Nase darauf.

Wie auch immer:
nsscache, libnss-cache, nscd, unscd, libnss-ldap sind nicht installiert und bisher dachte ich auch immer, das das gut so ist.

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 07.02.2017 20:54:38

Update: Das Problem zeigt sich mittlerweile von einer anderen Seite:
Zunächst habe ich probeweise dann doch nscd installiert. Das konnte das Problem aber nicht (vollständig?) lösen.
Vor allem nach einem Systemstart dauert es oft mehrere Versuche, bis sich ein Domänenbenutzer anmelden kann.

Kurzerhand habe ich zur Fehlersuche einen systemd System-Service eingerichtet, der die Bedingungen während des Starts untersucht.

Code: Alles auswählen

[Unit]
Description=Debug Startskript
Requires=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/debug.sh boot
ExecStop=/usr/local/bin/debug.sh shutdown
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Klar (Requires=network-online.target): Das Netzwerk läuft und der Windows DomainController lässt sich anpingen.
Allerdings: Während z.B. eine virtuelle Maschine sofort "net ads testjoin"-Anfragen beantwortet bekommt, laufen bei anderen Rechnern LDAP-, Winbind- und Sambaanfragen ins Leere und auch nach 30 Sekunden erhalte ich:

Code: Alles auswählen

ads_connect: No logon servers
Feb 07 XX:XX:XX HOSTNAME Debug.sh[605]: Join to domain is not valid: No logon servers

Update 2:
Nach nscd habe ich jetzt auch libnss-ldap installiert in der Hoffnung auf eine Besserung beim Verbindungsaufbau zum Active Directory Server: Leider negativ.

Dafür habe ich in etwa 10% der Logs einen Hinweis auf ein Problem bei nmbd gefunden:

Code: Alles auswählen

nmbd[983]:   STATUS=daemon 'nmbd' : No local IPv4 non-loopback interfaces available, waiting for interface ...NOTE: NetBIOS name resolution is not supported for Internet Protocol Version
Es scheint, das nmbd gestartet wird bevor das Netzwerk "richtig" online ist - zumindest manchmal - und dann natürlich nicht funktionieren kann.

Bisher hat ein "service nmbd restart" auch den gewünschten Erfolg gebracht.
Auch gibt es reichlich ähnliche Berichte (auch bei anderen Distributionen):
https://wyldeplayground.net/problems-jo ... ded-setup/
https://bbs.archlinux.org/viewtopic.php?id=214646
http://unix.stackexchange.com/questions ... al-restart
Samba tries to start before network is ready and then it can bind to the interfaces... Before systemd it looks like Samba was only started after the network was ready and everything worked fine. Right now it tries to start before causing issues to bind to the interfaces that aren't yet there
Die dort vorgeschlagenen Lösungen scheinen zwar zu funktionieren, sind aber nicht allzu elegant, am besten gefällt mir bisher das Anhängen von "post-up /etc/init.d/smbd restart" und "post-up /etc/init.d/nmbd restart" (bzw. deren systemd Ersatz: service ... retstart) an die Datei /etc/network/interfaces.
Bei Gelegenheit werde ich nochmal im BTS nachsehen. Vielleicht gibt es ja auch noch eine bessere Lösung.

Ich werde es jedenfalls weiter im Blick behalten. Ich Frage mich auch, ob das mein ursprüngliches Problem war.
Falls bis dahin jemand eine andere gute Idee hat: Bitte immer her damit.

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 28.02.2017 17:37:43

Nachdem ich nun schon reichlich Lektüre[1] hatte und viele Ideen ausprobiert habe, hier ein kurzes Update für alle mit ähnlichen Problemen:

Hilfreiche Lektüre:
- Feststellen und Lösen von Problemen unter Samba [2]
- Der Fehlerbaum (Schritt für Schritt Fehlersuche) [3]

Zunächst war es hilfreich[4], aber auch zeitintensiv, den Log-Level auf 3 zu erhöhen (mehr ist nicht nötig) und die nmbd bzw. winbind Meldungen zu loggen:

Code: Alles auswählen

log level = 1 winbind:3 nmbd:3
Bei mir war es offensichtlich ("Server nicht gefunden") ein Problem mit der Namensauflösung der NetBIOS-Namen [5].
nscd (und jeder andere Cacher) war die völlig falsche Idee: " Do not under any circumstances run nscd on any system on which winbindd is running." [6].

Meine nsswicth.conf war (Anleitungsgemäß) auf

Code: Alles auswählen

files wins
gesetzt. "files" nutzt die lokalen Dateien (/etc/hosts), "wins" ist ein "Namens-Auflösungs-Server" für NetBIOS-Namen.
Für Samba benutzt winbind statt dessen nmbd zur Namensauflösung.
Für Samba wird das in der smb.conf eingestellt [5],[7]. Bei mir war kein WINS Server festgelegt, wahrscheinlich hat nmbd "irgendwann" (daher die lange Wartezeit) eine Broadcast-Antwort des Domain Controllers bekommen.
Also ausprobieren:

Code: Alles auswählen

wins server = IP_des_Windows_AD_DCs
macht es nicht besser, im Gegenteil: Es hagelt Fehlermeldungen wie

Code: Alles auswählen

[2017/AA/BB CC:DD:EE.EEEEEE,  2] ../source3/nmbd/nmbd_nameregister.c:193(wins_registration_timeout)
  wins_registration_timeout: WINS server 172.XX.XX.XX timed out registering IP 172.YY.YY.YY
Jetzt wäre es nur noch interessant, warum der DC das nicht mag. Also wims vorerst wieder raus. Statt dessen habe ich jetzt erst einmal die Datei /etc/samba/lmhosts angelegt [8], die zumindest lokal den Active Directory Server auflöst. Standard für die Namensauflösung ist:

Code: Alles auswählen

name resolve order = host lmhost wins bcast
Außerdem gab es (wie schon geschrieben) ein Problem mit der Reihenfolge der Services beim Systemstart. Hier hat sich die Lösung "post-up /etc/init.d/nmbd restart" in der /etc/network/interfaces bewährt.

Auch ist mir aufgefallen, dass winbind nicht so stabil läuft, wie ich es mir wünsche. Hier findet sich bei "service winbind status" öfter ein toter Service (sig[15]) während dessen der Login nicht möglich ist. Als Workaround frage ich das mit cron ab und starte bei Bedarf winbind neu.




[1] https://www.samba.org/samba/docs/using_samba/toc.html
und https://www.samba.org/samba/docs/man/Sa ... nbind.html
[2] http://lug.krems.cc/docu/samba/ch09_01.html
auch: Chapter 38. The Samba Checklist, Part V. Troubleshooting
https://www.samba.org/samba/docs/man/Sa ... nosis.html
[3] http://lug.krems.cc/docu/samba/ch09_02.html
besonders: Troubleshooting von Nameservices
http://lug.krems.cc/docu/samba/ch09_02.html#ch09-23768
[4] http://www.oreilly.com/openbook/samba/book/ch09_01.html "Troubleshooting Samba"
[5] https://www.samba.org/samba/docs/using_samba/ch07.html
[6] https://www.samba.org/samba/docs/man/Sa ... nbind.html
[7] http://lug.krems.cc/docu/samba/ch07_03.html
[8] https://www.samba.org/samba/docs/man/ma ... sts.5.html

Paddie

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von Paddie » 28.02.2017 19:49:14

Gibt es vielleicht im Windows DC in der Ereignisanzeige irgendeinen Fehler oder Hinweis?

Der Windows DC ist ja auch als Nameserver in der Samba-Kiste eingetragen und die Aufloesung funktioniert auch richtig? (OK, muss es ja, sonst haettest du nicht joinen koennen... ;-))

Zeit-Syncronisierung laeuft auch? Windows DC also als Zeitserver?

Kerberos funktioniert?

Das sind jetzt so die Dinge mit denen ich zu kaempfen hatte bis es richtig gelaufen ist. Allerdings laeuft jetzt bei uns ein Samba als AD-DC...

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 28.02.2017 23:43:37

Gibt es vielleicht im Windows DC in der Ereignisanzeige irgendeinen Fehler oder Hinweis?
Bisher habe ich nur gesehen, dass sich der DC über unverschlüsselte LDAP Anfragen beschwert hat. Das ist aber etwas anderes. Den WINS-Server muss ich mir also auch nochmal näher ansehen.
Der Windows DC ist ja auch als Nameserver in der Samba-Kiste eingetragen und die Aufloesung funktioniert auch richtig?
Ja, ping klappt immer, ssh auch. nmblookup in etwa 95% der Fälle.
Mich stören die restlichen 5%. (ca. 2-4 von 40 Rechnern (mit identischer Software und Konfiguration) haben "immer wieder einmal" Probleme). Es sind aber auch nicht immer die selben Rechner, wobei einige ältere Computer bevorzugt "rum-zicken" - auch nach einer Neuinstallation (mit FAI). Manchmal geht es nach kurzer Zeit "von selbst" wieder, gelegentlich ist ein Neustart hilfreich, hin und wieder muss ich manuell "herumspielen" (mit Netzwerkkabeln, nmbd, nmblookup, winbind, getent, wninfo, ...) und dann geht es wieder ohne das ich wirklich etwas gemacht hätte. Es nervt halt ziemlich und ist nicht reproduzierbar.
Jetzt hoffe ich, dass meine minimale lmhosts-Datei (nur mit dem DC als Eintrag) seine Wirkung entfaltet. Abwarten.
Zeit-Syncronisierung laeuft auch? Windows DC also als Zeitserver?
Ja. NTP, Ja.

Code: Alles auswählen

# net ads -P info

LDAP server: 172.16.XX.YY
LDAP server name: WindowsDC.AAA.bbbb
Realm: AAA.BBBB
Bind Path: dc=AAA,dc=BBBB
LDAP port: 389
Server time: Di, 28 Feb 2017 23:36:58 CET
KDC server: 172.16.XX.YY
Server time offset: 0
Kerberos funktioniert?
Ja. Ich bekomme ein TGT und auch die verschiedenen Service-Tickets. Zumindest in den 95%, wo "es" klappt.

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 21.03.2017 21:35:10

Ein neues Update:
Das Problem wird langsam besser, ist aber noch nicht völlig gelöst.
Für alle Interessierten, für künftige Rat-suchenden und für mich als Erinnerung:
  1. nscd war der totale Reinfall. In der Samba-doc steht: "unbedingt deinstallieren."
  2. Die Namensauflösung muss klappen: ping -> nmblookup -> winbind -P

    In der Dokumentation findet sich immer wieder der WINS-Server, der bei unserem Active Directory nicht installiert war und bei "neueren" Installationen wohl auch nicht mehr üblich ist.

    Für nmblookup ist auch /etc/samba/lmhosts nützlich, hier hatte ich den Domain-Controller eingetragen.
    Es ist aber nicht notwendig, wenn der Client Mitglied in der AD-Domain ist, denn hier liefert der Windows-Server die IPs zu NetBIOS-Namen per DNS aus. DNS sollte natürlich klappen und in /etc/smb.conf muss unter "name resolve order = lmhosts host bcast" eingetragen sein. ("host" steht für die lokale Namensauflösung, auch DNS - falls konfiguriert.)

    Außerdem muss beim Systemstart (init / systemd) nmbd vor winbind gestartet werden. Hier gab es auch einen Debian-Bug für Stretch, der mit samba-common 2:4.5.6+dfsg-1 behoben sein soll.
    Bis dahin hilft es, winbind wie schon erwähnt über die /etc/network/interfaces zu starten. Leider ist bei mir winbind auch hin- und wieder im laufenden Betrieb abgestürzt. Das habe ich mit einem Cronjob abgefragt und winbind bei Bedarf mit "service winbind restart" neu gestartet.
  3. Kerberos
    Kerberos ist zur Rechteverwaltung im Netzwerk immens wichtig. Ich konnte "schon immer" Tickets abrufen und verwalten. Trotzdem fand ich noch einen Hinweis für den Abschnitt realms in der Datei /etc/krb5.conf, hier sollte unter "kdc" und "admin_server" nicht nur der Hostname, sondern auch noch der Domänenname eingetragen werden:

    Code: Alles auswählen

    [realms]
        XXX.ABCD = {
            kdc = MYDC.XXX.ABCD:88
            admin_server = MYDC.XXX.ABCD:464
            default_domain = XXX.ABCD
        }
    
    Trotzdem gab es immer wieder Probleme bei der Verbindung zum "Logon server", selbst wenn "winbind -P" keine Probleme damit hatte. Dazu fand ich folgendes heraus:
    - libpam-krb5 ist nicht nötig, winbind erledigt das mit.
    - "net ads status" (oder ähnliches) möchte den Server angegeben haben mit "-S Server"

    Seither ist es schon um Einiges besser geworden. libpam-krb5 hatte sich bei PAM vor unix.so eingetragen. Scheinbar hat es (warum auch immer) eine andere Namensauflösung als winbind verwendet und ist (warum auch immer) daran gescheitert.
  4. realmd
    Was mich noch wundert ist realmd, das durch "irgendwelche" Abhängigkeiten (auch unter Jessie) mit installiert worden ist und den Umgang mit Domänen vereinfachen soll. Ich habe es bisher nicht bemerkt und auch nicht nicht konfiguriert. Trotzdem erkennt es meine Domain:

    Code: Alles auswählen

    realm discover XXX.abcd
    XXX.abcd
      type: kerberos
      realm-name: XXX.ABCD
      domain-name: xxx.abcd
      configured: kerberos-member
      server-software: active-directory
      client-software: winbind
      required-package: winbind
      required-package: libpam-winbind
      required-package: samba-common-bin
      login-formats: %U
      login-policy: allow-any-login
    xxx.abcd
      type: kerberos
      realm-name: XXX.ABCD
      domain-name: xxx.abcd
      configured: no
    
    Meine Domain wird zweimal erkannt (Upper- und LowerCase). UpperCase scheint alles fein zu sein, bei LowerCase stört mich das "configured: no".
    Interessanterweise scheint die Verbindung zum DomainController auch [nur|besser] zu funktionieren, wenn realmd NICHT läuft. "Started Realm and Domain Configuration." -> "quitting realmd service after timeout"
Hat schon jemand Erfahrung mir realmd? Ich glaube, ich werde es testweise einfach einmal deinstallieren. ...

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 04.04.2017 20:49:12

Ein weiteres Update:
realmd wird nur durch "Empfehlungen" anderer Pakete installiert. Also weg damit, es klappt wunderbar ohne.

Mittlerweile habe ich viele Probleme (vor allem mit Winbind) behoben. Besonders gut war auch eine systemd-Abhängigkeit von gdm zu winbind:
/etc/systemd/system/gdm.service.d/winbind.conf

Code: Alles auswählen

[Unit]
Wants=winbind.service
After=winbind.service
Damit startet die Benutzeranmeldung auch tatsächlich erst dann, wenn winbind bereit ist.

Es bleibt noch ein (scheinbar letztes?) Problem: Winbind stürzt gerne einmal ab ("Got sig[15] terminate (is_parent=0)"), vor allem kurz nach dem Systemstart. Im Moment lasse ich alle drei Minuten einen Cronjob laufen, der das überprüft und ggfs. winbind neu startet.
Eine "wirkliche" Lösung wäre natürlich besser, deshalb fürs Erste einmal der Auszug aus dem journal während eines (fehlgeschlagenen) Anmeldeversuchs. Vielleicht hat ja doch noch jemand eine Idee. Wie bereits gesagt: Es passiert bei 30-40 Rechnern mit Debian Jessie vielleicht 1-3 mal am Tag:

Code: Alles auswählen

10:16:07 My-Computer gdm-password][1821]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=myuser
10:16:07 My-Computer gdm-password][1821]: pam_winbind(gdm-password:auth): getting password (0x00000388)
10:16:07 My-Computer gdm-password][1821]: pam_winbind(gdm-password:auth): pam_get_item returned a password
10:16:08 My-Computer gdm-password][1821]: pam_winbind(gdm-password:auth): user 'myuser' granted access
10:16:08 My-Computer pam-script[1821]: can not stat /usr/share/libpam-script/pam_script_acct
10:16:08 My-Computer systemd[1]: Stopping LSB: start Winbind daemon...
10:16:08 My-Computer winbindd[1074]: [2017/04/04 10:16:08.835232,  0] ../source3/winbindd/winbindd.c:266(winbindd_sig_term_handler)
10:16:08 My-Computer winbindd[1702]: [2017/04/04 10:16:08.835232,  0] ../source3/winbindd/winbindd.c:266(winbindd_sig_term_handler)
10:16:08 My-Computer winbindd[1704]: [2017/04/04 10:16:08.835251,  0] ../source3/winbindd/winbindd.c:266(winbindd_sig_term_handler)
10:16:08 My-Computer winbindd[1071]: [2017/04/04 10:16:08.835430,  0] ../source3/winbindd/winbindd.c:266(winbindd_sig_term_handler)
10:16:08 My-Computer winbindd[1036]: [2017/04/04 10:16:08.835509,  0] ../source3/winbindd/winbindd.c:266(winbindd_sig_term_handler)
10:16:08 My-Computer winbindd[1036]: Got sig[15] terminate (is_parent=1)
10:16:08 My-Computer winbind[1834]: Stopping the Winbind daemon: winbind.
10:16:08 My-Computer systemd[1]: Starting LSB: start Winbind daemon...
10:16:08 My-Computer winbindd[1702]: Got sig[15] terminate (is_parent=0)
10:16:08 My-Computer winbindd[1074]: Got sig[15] terminate (is_parent=0)
10:16:08 My-Computer winbindd[1071]: Got sig[15] terminate (is_parent=0)
10:16:08 My-Computer winbindd[1704]: Got sig[15] terminate (is_parent=0)
10:16:08 My-Computer winbind[1844]: Starting the Winbind daemon: winbind.
10:16:08 My-Computer systemd[1]: Started LSB: start Winbind daemon.
10:16:09 My-Computer gdm-session-worker[1821]: groups: myuser: Einen solchen Benutzer gibt es nicht
10:16:09 My-Computer gdm-session-worker[1821]: [85B blob data]
10:16:09 My-Computer gdm-password][1821]: pam_unix(gdm-password:session): session opened for user myuser by (unknown)(uid=0)
10:16:09 My-Computer gdm-password][1821]: pam_systemd(gdm-password:session): Failed to get user data.
10:16:09 My-Computer gdm-password][1821]: pam_systemd(gdm-password:session): Failed to get user data.
10:16:09 My-Computer gdm-password][1821]: gkr-pam: error looking up user information for: myuser

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 03.05.2017 23:01:32

Ein weiteres Update:
Im Moment sehe ich 3-4 verschiedene Winbind-Abstürze in verschiedensten Kontexten.
Winbind ist wirklich noch nicht stabil und die schon seit Jahren offenen Bug-Reports werden nicht wirklich bearbeitet. Um nur die zu nennen, an die ich mich erinnert fühle:
Debian Bugreport759592, Debian Bugreport784656, https://bugs.launchpad.net/ubuntu/+sour ... bug/667269, https://bugs.launchpad.net/ubuntu/+sour ... ug/1346825

Schade. Winbind ist eigentlich genau das was ich suche, aber diese Bugs sind für "meine Anwender" bzw. für mich ein wichtiger Grund, warum "Linux" nicht wirklich gut nutzbar ist und damit auch keine Alternative zum kaputten Windows. ...

Für Workarounds, andere Denkansätze o.ä. bin ich natürlich weiterhin dankbar.

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 10.09.2017 21:26:42

Ein letztes Update:
Winbind ist besser als zuletzt behauptet und auch die Maintainer sind recht hilfsbereit.
Auch wenn ich "alles" nach FAQS, HowTos, Guides, ... eingerichtet habe, ist die Entwicklung und auch die Konfiguration weitergegangen. Es wimmelt aber nur so von alten (=überholten) und fehlerhaften Anleitungen im Netz.

Eine funktionierende aktuelle Konfiguration ist hier beschrieben:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=862580

Christian

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: gelöst: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von scientific » 11.09.2017 00:45:51

Wenn winbind so oft abstürzt und du alle 3 Minuten einen cronjob laufen lässt, kannst du das aber auch gleich systemd erledigen lassen.

Ich nehme einmal an, die Service-Unit für winbind liegt in /lib/systemd/system/.
Poste dazu bitte einmal die Ausgabe von

Code: Alles auswählen

systemctl cat windbind.service
Am einfachsten (und das übersteht auch ein Update des Service-Files) legst du ein neues Verzeichnis und darin eine neue Datei an:

Alle Befehle als root

Code: Alles auswählen

mkdir -p /etc/systemd/system/winbind.service.d
Dann erstellst du die Datei auch als root

Code: Alles auswählen

editor /etc/systemd/system/winbind.service.d/unit.conf
Und in die Datei fügst du folgenden Inhalt ein:

Code: Alles auswählen

[Service]
Restart=always
RestartSec=1
Danach

Code: Alles auswählen

systemctl daemon-reload && systemctl restart winbind.service
Den cronjob deaktivere probehalber zuvor.

Dieses sogenannte "Drop-In" ergänzt die vom Maintainer ausgelieferte Service-Unit für winbind. Und damit wird festgelegt, dass der Service auch im Absturzfalle neu gestartet wird (Restart=always) aber 1 Sekunde gewartet wird, bis der Service neu gestartet wird (RestartSec=1)

Das kannst du ausprobieren, indem du mittels kill oder killall winbind abschießt. Führe zuvor ein

Code: Alles auswählen

systemctl status winbind
, dann kille den Prozess und nochmals den Befehl, und du wirst sehen, der läuft und hat eine neue MainPID. (kannst du alternativ aber auch mit ps kontrollieren!!!)

lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

chmeyer
Beiträge: 96
Registriert: 03.02.2010 21:09:12
Wohnort: RLP

Re: gelöst: AD: Anmeldung schlägt fehl, getent passwd SEHR langsam

Beitrag von chmeyer » 11.09.2017 21:35:13

Hallo scientific und Danke für Deine Antwort.

Du hast natürlich Recht, systemd die Aufgaben machen zu lassen, für die es eigentlich entwickelt wurde. Diese "Drop-Ins" von systemd kannte ich aber noch nicht.

Das cron Script habe ich auch nur deshalb "aufgemotzt", weil es schon aus einem anderen Grund vorhanden war. Im Moment bin ich aber wieder am "abrüsten", weil ich glaube, das das Problem mittlerweile gelöst ist (siehe auch den Betreff) - zumindest laufen meine Rechner seit ein paar Wochen ohne Probleme.

Für das nächste Problem werde ich mir aber Deine Anleitung im Hinterkopf behalten.
Vielen Dank dafür.

Christian

Antworten