CRITICAL: ldap Could not bind to the LDAP server

Hallo Community,

nach erfolgreichem Update auf mobydick 7.12.01 erscheinte die im Betreff genannte Fehlermeldung im Admin-Bereich.
Das Telefonbuch scheint aber zu funktionieren, am Client kann ich die eingetragenen Nummern sehen.
Jemand eine Idee?
Wofür ist die Funktion relevant, wenn Sie nciht läuft?

Grüße und Danke vorab

Ralph

Hi,

das Telefonbuch ist in der Datenbank des Commanders gespeichert, hierauf greift auch das XML-Telefonbuch, Client usw. zu. Die Datenbank wird beim Anwenden in den LDAP repliziert.
Da es so einige Hardware Geräte gibt, die leider nur LDAP sprechen.
Kannst du auf der Shell bitte “ps -ef | grep slapd” ausführen um zu sehen, ob der ldap-Dienst läuft bzw. mit /etc/init.d/slapd restart durchführen.

Gruß
Markus

Hallo Markus,

vielen Dank!

ps -ef | grep slapd bringt
root 16883 16872 0 05:50 pts/1 00:00:00 grep slapd


/etc/init.d/slapd restart
bringt
ok ] Stopping OpenLDAP: slapd.
[FAIL] Starting OpenLDAP: slapd failed!

das Starten des LDAP ist also das Problem denke ich.
Hast du auch eine Lösung?

Gruß
Ralph

Re,

was steht denn im /var/log/syslog dazu?

Gruß
Markus

Re,

bzw. du könntest auf der shell noch “exdjob.pl tsk010105” ausführen.

Gruß
Markus

Hallo Markus,

das Ergebnis des Shell-Befehls ist
2016-04-21 16:01:37 tsk010105: Starte Task 010105 ‘LDAP Server konfigurieren’, Parameter: ], User-ID: [1]
2016-04-21 16:01:37 Stoppe LDAP Server
2016-04-21 16:01:37 . Starte [/etc/init.d/slapd stop]
2016-04-21 16:01:37 … Stopping OpenLDAP: slapd.
2016-04-21 16:01:37 . Exit: [0]
2016-04-21 16:01:37 Optimizing phonebook entries
2016-04-21 16:01:37 Processing [8] entries
2016-04-21 16:01:37 Done! [0] updated
2016-04-21 16:01:37 Starte LDAP Server
2016-04-21 16:01:37 . Starte [/etc/init.d/slapd start]
2016-04-21 16:01:38 … Starting OpenLDAP: slapd failed!
2016-04-21 16:01:38 . Exit: [1]

Im syslog steht nur
Apr 21 15:40:01 localhost /USR/SBIN/CRON[2848]: (root) CMD (/var/rrd/mobydickrrd 1>/dev/null 2>&1)
Apr 21 15:45:01 localhost /USR/SBIN/CRON[3296]: (root) CMD (/sbin/mdcheckicinga.sh)
Apr 21 15:45:01 localhost /USR/SBIN/CRON[3299]: (root) CMD (/var/rrd/mobydickrrd 1>/dev/null 2>&1)
Apr 21 15:50:01 localhost /USR/SBIN/CRON[3829]: (root) CMD (/var/rrd/mobydickrrd 1>/dev/null 2>&1)
Apr 21 15:52:04 localhost icinga: Auto-save of retention data completed successfully.
Apr 21 15:55:01 localhost /USR/SBIN/CRON[4260]: (root) CMD (/var/rrd/mobydickrrd 1>/dev/null 2>&1)
Apr 21 16:00:01 localhost /USR/SBIN/CRON[4707]: (root) CMD (/var/rrd/mobydickrrd 1>/dev/null 2>&1)
Apr 21 16:00:01 localhost /USR/SBIN/CRON[4708]: (root) CMD (/sbin/mdcheckicinga.sh)
Apr 21 16:01:38 localhost slapd[4888]: @(#) $OpenLDAP: slapd (Sep 11 2015 15:18:47) $#012#011buildd@x86-csail-01:/build/openldap-e51fz0/openldap-2.4.31/debian/build/servers/slapd

Merci vorab

Hallo Markus,

hat es ggf. was damit zu tun? Ich bekomme seit nun auch eine Mail
/etc/cron.daily/exim4-base:
LOG: MAIN
Warning: purging the environment.
Suggested action: use keep_environment.

Gruß
Ralph

Hi Ralph,

nein die email ist “eine andere Baustelle”. Lösung findest Du hier -> http://community.pascom.net/showthread.php?2038-exim4-config-in-der-7-12-xx-bitte-anpassen

Grüße

Maik

Hi Maik,

vielen Dank! das versuche ich mal. Für das LDAP-Problem scheint es keine Lösung zu geben…

Hi rodney76,

setze einmal in der /etc/ldap/slapd.conf loglevel von 0 auf -1 und versuche den LDAP mit /etc/init.d/slapd start zu starten.
Hast Du anschließend in der /var/log/debug auch den folgenden Eintrag:

Apr 27 17:58:14 localhost slapd[24822]: line 38 (dbname md)
Apr 27 17:58:14 localhost slapd[24822]: line 39 (dbuser#011mobydickcmd)
Apr 27 17:58:14 localhost slapd[24822]: line 40 (lastmod off)
Apr 27 17:58:14 localhost slapd[24822]: line 41 (has_ldapinfo_dn_ru no)
Apr 27 17:58:14 localhost slapd[24822]: line 43 (insentry_query “”)
Apr 27 17:58:14 localhost slapd[24822]: /etc/ldap/slapd.conf: line 43: unknown directive <insentry_query> inside backend database definition.

Gruß,

Stefan

Hi,

wenn man insentry_query durch insentry_stmt ersetzt, dann startet der LDAP wieder.

Gruß,

Stefan

Hi Stefan,

würde sagen, ein wenig anders sieht es aus…

Apr 27 18:38:09 localhost slapd[17280]: line 38 (dbname md)
Apr 27 18:38:09 localhost slapd[17280]: line 39 (dbuser#011mobydickcmd)
Apr 27 18:38:09 localhost slapd[17280]: line 40 (lastmod off)
Apr 27 18:38:09 localhost slapd[17280]: line 41 (has_ldapinfo_dn_ru no)
Apr 27 18:38:09 localhost slapd[17280]: line 44 (upper_func “upper”)
Apr 27 18:38:09 localhost slapd[17280]: line 45 (strcast_func “text”)
Apr 27 18:38:09 localhost slapd[17280]: line 46 (concat_pattern “?||?”)

glaube hier ist der Fehler, bin aber nicht so firm in Linus, sorry…
Apr 27 18:38:09 localhost slapd[17281]: slapd startup: initiated.
Apr 27 18:38:09 localhost slapd[17281]: backend_startup_one: starting “cn=config”
Apr 27 18:38:09 localhost slapd[17281]: config_back_db_open
Apr 27 18:38:09 localhost slapd[17281]: config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context
Apr 27 18:38:09 localhost slapd[17281]: config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “cn=config”
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “cn=module{0}”
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “cn=schema”
Apr 27 18:38:09 localhost slapd[17281]: >>> dnNormalize: <cn={0}core>
Apr 27 18:38:09 localhost slapd[17281]: <<< dnNormalize: <cn={0}core>
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “cn={0}core”
Apr 27 18:38:09 localhost slapd[17281]: >>> dnNormalize: <cn={1}cosine>
Apr 27 18:38:09 localhost slapd[17281]: <<< dnNormalize: <cn={1}cosine>
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “cn={1}cosine”
Apr 27 18:38:09 localhost slapd[17281]: >>> dnNormalize: <cn={2}inetorgperson>
Apr 27 18:38:09 localhost slapd[17281]: <<< dnNormalize: <cn={2}inetorgperson>
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “cn={2}inetorgperson”
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “olcDatabase={-1}frontend”
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “olcDatabase={0}config”
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “olcDatabase={1}sql”
Apr 27 18:38:09 localhost slapd[17281]: config_build_entry: “olcOverlay={0}sssvlv”
Apr 27 18:38:09 localhost slapd[17281]: backend_startup_one: starting “dc=mobydick”
Apr 27 18:38:09 localhost slapd[17281]: ==>backsql_db_open(): testing RDBMS connection
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): subtree search SQL condition not specified (use “subtree_cond” directive in slapd.conf); preparing default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “upper(ldap_entries.dn) LIKE upper(’%’||?)” as default “subtree_cond”
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): children search SQL condition not specified (use “children_cond” directive in slapd.conf); preparing default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “upper(ldap_entries.dn) LIKE upper(’%,’||?)” as default “children_cond”
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): DN match search SQL condition not specified (use “dn_match_cond” directive in slapd.conf); preparing default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “upper(ldap_entries.dn)=upper(?)” as default “dn_match_cond”
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): objectclass mapping SQL statement not specified (use “oc_query” directive in slapd.conf)
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings” by default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): attribute mapping SQL statement not specified (use “at_query” directive in slapd.conf)
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?” by default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): entry insertion SQL statement not specified (use “insentry_stmt” directive in slapd.conf)
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)” by default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): entry deletion SQL statement not specified (use “delentry_stmt” directive in slapd.conf)
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “DELETE FROM ldap_entries WHERE id=?” by default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): entry deletion SQL statement not specified (use “renentry_stmt” directive in slapd.conf)
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “UPDATE ldap_entries SET dn=?,parent=?,keyval=? WHERE id=?” by default
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): objclasses deletion SQL statement not specified (use “delobjclasses_stmt” directive in slapd.conf)
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): setting “DELETE FROM ldap_entry_objclasses WHERE entry_id=?” by default
Apr 27 18:38:09 localhost slapd[17281]: ==>backsql_get_db_conn()
Apr 27 18:38:09 localhost slapd[17281]: ==>backsql_open_db_handle()
Apr 27 18:38:09 localhost slapd[17281]: backsql_open_db_handle(): SQLConnect() to database “md” failed.
Apr 27 18:38:09 localhost slapd[17281]: Return code: -1
Apr 27 18:38:09 localhost slapd[17281]: nativeErrCode=0 SQLengineState=01000[unixODBC][Driver Manager]Can’t open lib ‘/usr/lib/x86_64-linux-gnu/odbc/psqlodbca.so’ : file not found msg="[unixODBC][Driver Manager]Can’t open lib '/usr/l$
Apr 27 18:38:09 localhost slapd[17281]: backsql_db_open(): connection failed, exiting
Apr 27 18:38:09 localhost slapd[17281]: backend_startup_one (type=sql, suffix=“dc=mobydick”): bi_db_open failed! (1)
Apr 27 18:38:09 localhost slapd[17281]: slapd shutdown: initiated
Apr 27 18:38:09 localhost slapd[17281]: ==>backsql_db_close()
Apr 27 18:38:09 localhost slapd[17281]: <==backsql_db_close()
Apr 27 18:38:09 localhost slapd[17281]: slapd destroy: freeing system resources.
Apr 27 18:38:09 localhost slapd[17281]: ==>backsql_db_destroy()
Apr 27 18:38:09 localhost slapd[17281]: ==>backsql_free_db_env()
Apr 27 18:38:09 localhost slapd[17281]: <==backsql_free_db_env()
Apr 27 18:38:09 localhost slapd[17281]: ==>destroy_schema_map()
Apr 27 18:38:09 localhost slapd[17281]: <==destroy_schema_map()
Apr 27 18:38:09 localhost slapd[17281]: <==backsql_db_destroy()
Apr 27 18:38:09 localhost slapd[17281]: slapd stopped.

Merci vorab!!

Hi Ralph,

was sagt Dein System zu den beiden folgenden Kommandos:

ls -l /usr/lib/x86_64-linux-gnu/odbc/psql*

dpkg -l | grep odbc

Gruß,

Stefan

Hallo Stefan,

zunächst Danke!
Das Verzeichnis x86_64-linux-gnu existiert bei mir nicht
Zugriff auf /usr/lib/x86_64-linux-gnu/odbc/psql* nicht möglich: Datei oder Verzeichnis nicht gefunden


bei
dpkg -l | grep odbc kommt nur
ii libmyodbc:i386 5.1.10-2+deb7u1 i386 the MySQL ODBC driver
ii libodbc1:i386 2.2.14p2-5 i386 ODBC library for Unix
ii odbc-postgresql:i386 1:09.01.0100-1+deb7u1 i386 ODBC driver for PostgreSQL
ii odbcinst 2.2.14p2-5 i386 Helper program for accessing odbc ini files
ii odbcinst1debian2:i386 2.2.14p2-5 i386 Support library for accessing odbc ini files

DANKE!!

Hallo Ralph,

aha, Du ein 32bit System und es wird nach einem 646bit Verzeichnis gesucht.

Versuche es einmal mit

ln -s /usr/lib /usr/lib/x86_64-linux-gnu
ldconfig

Und mich würden die Ausgaben der folgenden Befehle interessieren:

dpkg -l odbc-postgresql

cat /etc/ld.so.conf

cat /etc/ld.so.conf.d/*

Gruß,

Stefan

Hallo Stefan,

Asche auf mein Haupt. Linux ist echt nicht mein Ding :wink:
Also Befehl 1 und 2 ohne Fehlermeldung!
Befehl 3 kommt folgendes


root@MDPBX:/etc/admin# dpkg -l odbc-postgresql
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name Version Architektur Beschreibung
++±==============-============-============-=================================
ii odbc-postgresq 1:09.01.0100 i386 ODBC driver for PostgreSQL
root@MDPBX:/etc/admin#


Cat 1 bringt
include /etc/ld.so.conf.d/*.conf


Cat 2

Multiarch support

/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu

libc default configuration

/usr/local/lib


Nochmals ein Dankeschön vorab

Hi,

Mist, Tippfehler, es sollte sein:

dpkg -L odbc-postgresql

Gruß,

Stefan

Die Antwort lautet:
/.
/usr
/usr/lib
/usr/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu/odbc
/usr/lib/i386-linux-gnu/odbc/psqlodbcw.so
/usr/lib/i386-linux-gnu/odbc/psqlodbca.so
/usr/share
/usr/share/doc
/usr/share/doc/odbc-postgresql
/usr/share/doc/odbc-postgresql/copyright
/usr/share/doc/odbc-postgresql/docs
/usr/share/doc/odbc-postgresql/docs/howto-accessvba.html
/usr/share/doc/odbc-postgresql/docs/howto-vb.html
/usr/share/doc/odbc-postgresql/docs/config-opt.html
/usr/share/doc/odbc-postgresql/docs/config.html
/usr/share/doc/odbc-postgresql/docs/release.html
/usr/share/doc/odbc-postgresql/docs/howto-vblo.html
/usr/share/doc/odbc-postgresql/docs/faq.html
/usr/share/doc/odbc-postgresql/docs/howto-ch.html
/usr/share/doc/odbc-postgresql/docs/win32-compilation.html
/usr/share/doc/odbc-postgresql/docs/howto-bo.html
/usr/share/doc/odbc-postgresql/docs/unix-compilation.html
/usr/share/doc/odbc-postgresql/docs/howto-accesslo.html
/usr/share/doc/odbc-postgresql/docs/index.html
/usr/share/doc/odbc-postgresql/docs/howto-csharp.html
/usr/share/doc/odbc-postgresql/README.Debian
/usr/share/doc/odbc-postgresql/NEWS.Debian.gz
/usr/share/doc/odbc-postgresql/changelog.Debian.gz
/usr/share/doc/odbc-postgresql/examples
/usr/share/doc/odbc-postgresql/examples/odbc.ini.template
/usr/share/psqlodbc
/usr/share/psqlodbc/odbcinst.ini.template

Gruß Ralph

Hi Ralph,

rm /usr/lib/x86_64-linux-gnu
ln -s /usr/lib/i386-linux-gnu /usr/lib/x86_64-linux-gnu
ldconfig
/etc/init.d/slapd start

Ist der LDAP nun gewillt zu starten?

Gruß,

Stefan

Hi Stefan,

grandios! läuft! muss ich da jetzt nochwas tun? oder einfach 1millliunnenmal DANKE sagen!!!

Gruß
Ralph