Hylafax streikt wg. ldap

Hallo,

seit gestern nimmt Hylafx keine Faxe mehr entgegen. Im betrtffenden log findet man diese Zeile dazu

Jul 29 14:13:28 oekologie HylaFAX[2341]: nss_ldap: could not search LDAP server - Server is unavailable
Jul 29 14:13:30 oekologie HylaFAX[2343]: nss_ldap: could not search LDAP server - Server is unavailable

In der listener.log tauchen zwischendurch auch immer mal wieder diese Hinweise auf

29.07.08 05:54:27  LISTENER    ( WARN    ) : no data is available (i.e. timeout elasped)
29.07.08 05:54:27  LISTENER    ( ERROR   ) : failed to get alive answer
29.07.08 05:54:27  LISTENER    ( ERROR   ) : listener: 1
29.07.08 05:54:27  LISTENER    ( WARN    ) : received signal 2
29.07.08 05:54:32  DEBUG_INIT
29.07.08 05:54:32  LDAP        ( ERROR   ) : start_tls: Can't contact LDAP server
29.07.08 05:54:32  LISTENER    ( WARN    ) : can not connect to ldap server (dmoeko.gri-oekonet.de)
29.07.08 05:54:32  LISTENER    ( WARN    ) : can not connect to any ldap server, retrying in 30 seconds
29.07.08 05:55:03  LISTENER    ( WARN    ) : choose as server: dmoeko.gri-oekonet.de
29.07.08 05:55:03  LDAP        ( ERROR   ) : start_tls: Can't contact LDAP server
29.07.08 05:55:03  LISTENER    ( WARN    ) : can not connect to ldap server (dmoeko.gri-oekonet.de)
29.07.08 05:55:03  LISTENER    ( WARN    ) : can not connect to any ldap server, retrying in 30 seconds
29.07.08 05:55:33  LISTENER    ( WARN    ) : choose as server: dmoeko.gri-oekonet.de
29.07.08 05:58:42  LDAP        ( ERROR   ) : start_tls: Can't contact LDAP server
29.07.08 05:58:42  LISTENER    ( WARN    ) : can not connect to ldap server (dmoeko.gri-oekonet.de)
29.07.08 05:58:42  LISTENER    ( WARN    ) : can not connect to any ldap server, retrying in 30 seconds
29.07.08 05:59:12  LISTENER    ( WARN    ) : choose as server: dmoeko.gri-oekonet.de
29.07.08 05:59:12  LISTENER    ( ERROR   ) : connection okay to host dmoeko.gri-oekonet.de
UNIVENTION_DEBUG_BEGIN  : uldap.__open host=oekologie.gri-oekonet.de port=389 base=dc=gri-oekonet,dc=de
UNIVENTION_DEBUG_END    : uldap.__open host=oekologie.gri-oekonet.de port=389 base=dc=gri-oekonet,dc=de
29.07.08 14:05:00  LISTENER    ( WARN    ) : received signal 15
29.07.08 14:08:47  DEBUG_INIT
29.07.08 14:08:47  LISTENER    ( ERROR   ) : connection okay to host dmoeko.gri-oekonet.de

Da der Hylafx auf dem Slave läuft, habe ich mal dies überprüft

root@oekologie:/var/log# ldapsearch -x -ZZ -s base -h dmoeko.gri-oekonet.de
# extended LDIF
#
# LDAPv3
# base <> with scope base
# filter: (objectclass=*)
# requesting: ALL
#

# gri-oekonet.de
dn: dc=gri-oekonet,dc=de
objectClass: top
objectClass: krb5Realm
objectClass: univentionPolicyReference
objectClass: nisDomainObject
objectClass: domainRelatedObject
objectClass: univentionBase
objectClass: domain
objectClass: univentionMailDomain
dc: gri-oekonet
krb5RealmName: GRI-OEKONET.DE
nisDomain: gri-oekonet.de
associatedDomain: gri-oekonet.de
univentionPolicyReference: cn=default-settings,cn=thinclient,cn=policies,dc=gr
 i-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=boot,cn=dhcp,cn=policies,dc=
 gri-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=dns,cn=dhcp,cn=policies,dc=g
 ri-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=routing,cn=dhcp,cn=policies,
 dc=gri-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=pwhistory,cn=users,cn=polici
 es,dc=gri-oekonet,dc=de
univentionPolicyReference: cn=default-users,cn=admin-settings,cn=users,cn=poli
 cies,dc=gri-oekonet,dc=de
mailRelay: oekologie.gri-oekonet.de

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1

Sieht o.k. aus. Auch getent passwd liefert die Domänenbenuzer zurück.

Dienste wurde alle korrekt (neu-)gestartet.

root@oekologie:/var/log# capiinfo
Number of Controllers : 1
Controller 1:
Manufacturer: AVM GmbH
CAPI Version: 2.0
Manufacturer Version: 3.101-07  (49.23)
Serial Number: 1000001
BChannels: 2
Global Options: 0x00000039
   internal controller supported
   DTMF supported
   Supplementary Services supported
   channel allocation supported (leased lines)
B1 protocols support: 0x4000011f
   64 kbit/s with HDLC framing
   64 kbit/s bit-transparent operation
   V.110 asynconous operation with start/stop byte framing
   V.110 synconous operation with HDLC framing
   T.30 modem for fax group 3
   Modem asyncronous operation with start/stop byte framing
B2 protocols support: 0x00000b1b
   ISO 7776 (X.75 SLP)
   Transparent
   LAPD with Q.921 for D channel X.25 (SAPI 16)
   T.30 for fax group 3
   ISO 7776 (X.75 SLP) with V.42bis compression
   V.120 asyncronous mode
   V.120 bit-transparent mode
B3 protocols support: 0x800000bf
   Transparent
   T.90NL, T.70NL, T.90
   ISO 8208 (X.25 DTE-DTE)
   X.25 DCE
   T.30 for fax group 3
   T.30 for fax group 3 with extensions
   Modem

  0100
  0200
  39000000
  1f010040
  1b0b0000
  bf000080
  00000000 00000000 00000000 00000000 00000000 00000000
  01000001 00020000 00000000 00000000 00000000

Supplementary services support: 0x000003ff
   Hold / Retrieve
   Terminal Portability
   ECT
   3PTY
   Call Forwarding
   Call Deflection
   MCID
   CCBS

root@oekologie:/var/log#

und

Jul 28 13:26:51.51: [29035]: c2faxrecv - INFO: Controller=1 : IncomingMSNs=586661
Jul 28 13:26:51.51: [29035]: c2faxrecv - INFO:
Started in Hylafax mode and waiting on incoming calls.
Jul 29 14:08:37.47: [ 2022]: c2faxrecv - INFO:
Device "faxCAPI" uses 2 receive thread(s) with the following config:
Jul 29 14:08:37.49: [ 2022]: c2faxrecv - INFO: Controller=1 : IncomingMSNs=586661
Jul 29 14:08:37.49: [ 2022]: c2faxrecv - INFO:
Started in Hylafax mode and waiting on incoming calls.

Faxstat liefert dies:

root@oekologie:/var/log# faxstat -a
HylaFAX scheduler on oekologie.gri-oekonet.de: Running
root@oekologie:/var/log#

Jetzt bin ich mit meinem Latain am Ende. Was sollte ich denn noch überprüfen?

MfG

Hallo,

aus Ihrem Log-Auszug ist zu ersehen das die Verbindung zum LDAP-Server “dmoeko” nicht konsistent ist. Dies könnte evtl. durch eine Trennung der Netzwerkverbindungen verursacht worden sein. Können Sie einmal ermitteln um was für eine Serverrolle es sich bei dem Server “oekologie” handelt. Dies können Sie am einfachsten über die Univention Configuration Registry-Variable server/role in Erfahrung bringen. Außerdem sollten Sie auch noch den Wert der Univention Configuration Registry-Variable ldap/server/name in Erfahrung bringen. Dazu können Sie die folgenden Befehle verwenden:

univention-config-registry get server/role
univention-config-registry get ldap/server/name

Falls es sich bei dem Server um einen DC Master, DC Backup oder DC Slave handelt, dann muss der LDAP-Server Name auf die FQDN “oekologie.gri-oekonet.de” verweisen, andernfalls muss dies entsprechend angepasst werden. Anschließend können Sie einmal überprüfen ob der Zugriff auf den lokalen LDAP-Server funktioniert. Dazu können Sie den folgenden Befehl verwenden:

ldapsearch -x -ZZ -s base -h oekologie.gri-oekonet.de

Mit freundlichen Grüßen
Murat Odabas

Hallo,

root@oekologie:~# univention-config-registry get server/role -bash: univention-config-registry: command not found root@oekologie:~# root@oekologie:~# univention-config-registry get ldap/server/name -bash: univention-config-registry: command not found root@oekologie:~#

Liegt wohl daran, dass wir UCS 1.3 einsetzen, oder?

Zugriff auf den lokalen Ldapserver, der ein DC-SLAVE ist, funktioniert

root@oekologie:~# ldapsearch -x -ZZ -s base -h oekologie.gri-oekonet.de
# extended LDIF
#
# LDAPv3
# base <> with scope base
# filter: (objectclass=*)
# requesting: ALL
#

# gri-oekonet.de
dn: dc=gri-oekonet,dc=de
objectClass: top
objectClass: krb5Realm
objectClass: univentionPolicyReference
objectClass: nisDomainObject
objectClass: domainRelatedObject
objectClass: univentionBase
objectClass: domain
objectClass: univentionMailDomain
krb5RealmName: GRI-OEKONET.DE
associatedDomain: gri-oekonet.de
dc: gri-oekonet
nisDomain: gri-oekonet.de
univentionPolicyReference: cn=default-settings,cn=thinclient,cn=policies,dc=gr
 i-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=boot,cn=dhcp,cn=policies,dc=
 gri-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=dns,cn=dhcp,cn=policies,dc=g
 ri-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=routing,cn=dhcp,cn=policies,
 dc=gri-oekonet,dc=de
univentionPolicyReference: cn=default-settings,cn=pwhistory,cn=users,cn=polici
 es,dc=gri-oekonet,dc=de
univentionPolicyReference: cn=default-users,cn=admin-settings,cn=users,cn=poli
 cies,dc=gri-oekonet,dc=de
mailRelay: oekologie.gri-oekonet.de

# search result
search: 3
result: 0 Success

# numResponses: 2
# numEntries: 1
root@oekologie:~#

MfG

Hallo,

das Problem hat sich leider noch nicht von selbst gelöst.

root@oekologie:~# univention-baseconfig get ldap/server/name
oekologie.gri-oekonet.de
root@oekologie:~# univention-baseconfig get server/role
domaincontroller_slave
root@oekologie:~#

Dies wollte ich noch eben nachreichen.

MfG

Hallo,

mit UCS 2.0 wurde “univention-baseconfig” in "univention-config-registry"umbenannt. Da “univention-baseconfig” unter UCS 2.0 ein Sym. Link zu “univention-config-registry” ist, kann “univention-baseconfig” weiterhin verwendet werden. Wie sind Sie bei der Anbindung von Hylafax an das UCS LDAP vorgegangen und zu welchem Zweck?

Mit freundlichen Grüßen
Murat Odabas

Hallo,

ich habe Hylafax nicht ans LDAP gebunden, lediglich die Standardinstallation auf dem UCS-System durchgeführt. Es hat ja auch 1 Jahr lang ohne Probleme funktioniert, nur ab dem 24.07.08 ging es nicht mehr, wie man den logs entnehmen kann. Wieso Hylafax das LDAP braucht kann ich ihnen nicht sagen, jedoch meint das log dies

Jul 29 14:13:28 oekologie HylaFAX[2341]: nss_ldap: could not search LDAP server - Server is unavailable
Jul 29 14:13:30 oekologie HylaFAX[2343]: nss_ldap: could not search LDAP server - Server is unavailable

Diese Fehlermeldung ist unmittelbar an ein ankommendes Fax gekoppelt. Nun muss unsere altmodische Faxmaschine die Faxe entgegennehmen, denn Hylafax will nicht.

Mit freundlichem Gruß

Hallo,

um die Fehlerursache weiter eingrenzen zu können, werden im folgenden einige Punkte benannt die Sie bitte einmal überprüfen/durchführen sollten:
[ul]
[] Wie lauten die aktuellen Hylafax spezifischen Meldungen?[/]
[]Überprüfen Sie im Verzeichnis “/var/log/” die Log-Dateien “daemon.log”, “syslog”, “messages” und “auth.log”, zusätzlich noch die Log-Datei “/var/log/univention/listener.log” nach Hylafax spezifischen und generellen Meldungen die mit dem Hylafax-Dienst zusammenhängen.[/]
[]Überprüfen Sie in der Konfigurationsdatei “/etc/libnss-ldap.conf” ob die Angaben für “host” und “base” Korrekt sind.[/]
[]Ggf. hilft ein Neustarten des nscd Dienstes mit “/etc/init.d/nscd restart”, Leeren des nscd Caches mit “nscd -i group”, “nscd -i hosts” und “nscd -i passwd”. Anschließend sollten Sie überprüfen ob Faxe jetzt angenommen oder versendet werden können.[/]
[]Während Hylafax versucht sich mit dem LDAP zu verbinden, kann der LDAP Debug-Level erhöht werden, um noch detailiertere Meldungen zu erhalten. Dazu können Sie die Univention Baseconfig-Variable “ldap/debug/level” z.B. auf den Wert 256 erhöhen. Das folgende Kommando kann dazu verwendet werden:
univention-baseconfig set ldap/debug/level=256
Anschließend muss ein Neustart des LDAP-Servers mit “/etc/init.d/slapd restart” vorgenommen werden. Der neue Wert für den Debug-Level des LDAP Servers erzeugt sehr viele Meldungen, von daher sollte der Debug-Level nach der Fehlersuche wieder auf den ursprünglichen Wert gesetzt werden. Die erzeugten Meldungen werden in der Log-Datei “/var/log/syslog” protokolliert. Nähere Informationen hierzu können Sie den man-Pages von “slapd.conf” entnehmen.[/
]
[]Erneute Überprüfung der Ausgabe des “getent passwd” Befehls. Aus dieser Ausgabe des Befehls sollten auch alle LDAP Benutzer zu ersehen sein.[/]
[]Überprüfen der SSL-Zertifikate auf dem Master und dem Server auf dem der Hylafax-Dienst läuft, evtl. sind die Zertifikate abgelaufen. Nähere Informationen dazu finden Sie auch im entsprechenden Forum-Artikel unter der folgenden URL: [url]Erneuern der SSL-Zertifikate][/]
[/ul]
Mit freundlichen Grüßen
Murat Odabas

Mastodon