7iApp-123 // 7iApp-Dokuwiki // 7iApp-Wordpress

[mschmitz]

Hallo,

wenn ich auf meinem ucs slave (3.2.2-errata156) aus dem AppCenter die obigen Apps installieren möchte bekomme ich im Anschluss an die Installation (bei den join skripten) folgende Fehlermeldung:

[code]univention-run-join-scripts started
Di 5. Aug 13:55:10 CEST 2014

RUNNING 70iiiiiii4ucs.inst
Permission denied.
Permission denied.
LDAP Error: No such object
E: object not found
LDAP Error: No such object
E: object not found
LDAP Error: No such object
E: object not found
LDAP Error: No such object
E: object not found
EXITCODE=0
RUNNING 71iiiiiii4ucs-udm.inst
EXITCODE=0

Di 5. Aug 13:55:14 CEST 2014
univention-run-join-scripts finished[/code]

Was muss ich machen bzw überprüfen ??

Danke

mschmitz

[mphofmann]

Hallo Herr Schmitz,

Ich vermute die Installation der LDAP-Felder ging im UCS irgendwie nicht.
Das anschliessende Script “70iiiiiii4ucs.inst” passt danach das UDM an und liest die entsprechenden LDAP-Felder.

Lösungsvorschlag:

• Paket mit LDAP-Schema nochmals installieren.
• UDM reseten

Login als root:
apt-get install 7i4ucs-common-schema --reinstall
7i4ucs udm reset

Gruss,
Michael Hofmann

[mschmitz]

Hallo,

Danke für die Antwort…

Leider gibt es in der Konsole auch die selbe Fehlermeldung.

root@ucs-slave1:/var/log/univention# apt-get install 7i4ucs-common-schema --reinstall Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut Statusinformationen werden eingelesen... Fertig 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 0 nicht aktualisiert. Es müssen noch 0 B von 1.620 B an Archiven heruntergeladen werden. Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt. (Lese Datenbank ... 112511 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Ersetzen von 7i4ucs-common-schema 2014.07.14.1252 (durch .../7i4ucs-common-schema_2014.07.14.1252_all.deb) ... Ersatz für 7i4ucs-common-schema wird entpackt ... Trigger für univention-config werden verarbeitet ... Kein Paket gefunden, das auf 7i4ucs passt. Kein Paket gefunden, das auf ldapacl_66univention-appcenter_app.acl passt. Kein Paket gefunden, das auf 7i4ucs-schema passt. 7i4ucs-common-schema (2014.07.14.1252) wird eingerichtet ... Multifile: /etc/ldap/slapd.conf Multifile: /etc/ldap/slapd.conf Restarting ldap server(s). Stopping ldap server(s): slapd ...done. Check database: ...done. Starting ldap server(s): slapd ...done.

root@ucs-slave1:/var/log/univention# 7i4ucs udm reset Permission denied. Permission denied. LDAP Error: No such object E: object not found LDAP Error: No such object E: object not found LDAP Error: No such object E: object not found LDAP Error: No such object E: object not found LDAP Error: No such object E: object not found

[mphofmann]

Hallo,

Kein Paket gefunden, das auf 7i4ucs passt.
Kein Paket gefunden, das auf 7i4ucs-schema passt.

Die Pakete heissen: 7i4ucs-common, 7i4ucs-common-schema und 7i4ucs-common-udm
Das System sucht nach 7i4ucs und 7i4ucs-schema. Diese Pakete gab es nie wirklich. Ich glaube unser allererster Entwurf (~April) hatte diese Pakete auf unseren Testservern - danach jedoch nicht mehr.

Da stimmt etwas mit den Sources nicht auf diesem Server.
Ist das eventuell ein Testsystem?

@Univention: Wie können wir die Paket-Abhängigkeiten für diesen Server überprüfen?

Gruss,
Michael Hofmann
7iSolutions

[mschmitz]

Guten morgen,

“Testsystem” ist richtig, da wir uns im Test befinden

Der Server ist von der Installations DVD installiert worden UCS 3.2 (Borgfeld) und im Anschluss mit allen Updates versorgt worden.

Ich installiere gerade ein “frisches” System in der VM und teste dort - werde gleich hierzu Rückmeldung geben.

Danke

mschmitz

[mschmitz]

Hallo,

habe jetzt mit dem “frischen” System getestet…

Leider ohne Erfolg - der Fehler besteht weiterhin…

mschmitz

[mphofmann]

Hallo,

Ich habe soeben einen neuen Server aufgesetzt, aktualiert und alle unsere Pakete installiert. Funktionierte reibungslos.

@Univention: Wie ist hier weiter vorzugehen? Was können wir hier noch tun?

Gruss,
Michael Hofmann

[dwiesent]

Hallo,

ich habe mir das Verhalten einmal angeschaut. Ich vermute, der Grund liegt hier:

auf meinem ucs slave (3.2.2-errata156)

Es handelt sich um ein Slave-System. Solche Systeme haben keine Schreibrechte in UDM. Nicht-Master-Systeme dürfen nicht einfach Container, Extended Attributes usw. anlegen, modifizieren, löschen. Solche Aktionen müssen mit den Berechtigungen eines Administrators ausgeführt werden. Dafür gibt es die Join-Skripte, die auf einem Slave auch nach Nutzername/Passwort fragen.

In der Regel sehen dann UDM-Aufrufe in Join-Skripten so aus:
univention-directory-manager settings/extended_attribute remove “$@” --dn …

Das “$@” beinhaltet Nutzername/Passwort, das dem Skript übergeben wurde. So wie ich das jetzt gerade sehe, wird in 70iiiiiii4ucs.inst ein externes Skript aufgerufen (PHP) und darin werden sys-calls abgesetzt. Auf dem Weg dorthin sind allerdings die Argumente in “$@” verloren gegangen. Deshalb klappt es auf Nicht-Master-Systemen nicht. Was die Sache noch ein bisschen hinterhältiger macht: /usr/bin/7i4ucs bricht offenbar nicht ab, das Join-Skript wird als “erfolgreich durchlaufen” markiert.

Ein DC Master hingegen kann als Fallback auf das LDAP-Passwort für cn=admin zugreifen (genauer: root auf dem DC Master kann das). Deshalb wird das Skript auf einem Master auch durchlaufen (weil postinst mit root-Rechten läuft und dort das Skript ausgeführt wird).

Ich vermute, 7i4ucs braucht ein Update und zwar derart, dass die system()-Aufrufe aus dem PHP-Skript ins Join-Skript verlagert werden (man kann natürlich auch dem PHP-Skript die Argumente übergeben und PHP übergibt sie dem system($cmd)). Bis dahin läuft es nur auf einem DC Master.

Viele Grüße
Dirk Wiesenthal

[mschmitz]

Hallo,

Danke für die Rückinfo…

Dann werde ich mich wohl an dieser Anleitung versuchen https://www.dokuwiki.org/plugin:authldap:ucs

[code] <?php
/**
* Univention Corporate Server configuration for LDAP Auth Plugin
* See https://www.dokuwiki.org/plugin:authldap:ucs for details and explanation
*/
$conf[‘useacl’] = 1;
$conf[‘openregister’]= 0;
$conf[‘superuser’] = ‘@Domain Admins’;
$conf[‘authtype’] = ‘authldap’;

$conf['plugin']['authldap']['server']      = 'ldap://1.2.3.4:389';
$conf['plugin']['authldap']['starttls']    = 1;
$conf['plugin']['authldap']['usertree']    = 'cn=users, dc=basedn';
$conf['plugin']['authldap']['grouptree']   = 'cn=groups, dc=basedn';
$conf['plugin']['authldap']['userfilter']  = '(&(uid=%{user})(objectClass=posixAccount))';
$conf['plugin']['authldap']['groupfilter'] = '(&(objectClass=posixGroup)(|(gidNumber=%{gid})(uniqueMember=%{dn})))';
 
$conf['plugin']['authldap']['mapping']['mail'] = 'mailprimaryaddress';

[/code]

Gruß
mschmitz

[mphofmann]

Hallo,

Wir haben diesen Bug behoben und einen neue Version ins AppCenter hochgeladen.

In ein paar Tagen sollte die korrigierte Version dann live sein.

Freundliche Grüsse,
Michael Hofmann