OX deaktivieren löscht - wie genau ist das gemeint

Apps & App Center
#1

Moin,
Wenn der OX im UCS installiert ist, gibt es ja beim Benutzer unter “Konto” die “Deaktivieren” Funktion
Die Frage ist hier: Was genau wird “gelöscht” bei Nutzung der “Deaktivieren” Funktion?
Der komplette OX-User, das Mail-Konto, oder nur die Kalender / Kontakte / Aufgaben des Users?
Hintergrund ist folgende Anfrage:

 vermutlich nach dem „deaktivieren und wieder aktivieren“ eines OX-Users

in der UMC ist nun der Login nicht mehr möglich. Die Fehlermeldung lautet:
Ein Benutzer mit der ID “petrak” konnte nicht im Kontext 10 gefunden werden.
(USR-0015).

 Können Sie da etwas tun? Ich habe allerlei probiert – es scheint aber, als

wenn irgendwo im LDAP o.ä. eine Verknüpfung fehlt.

Danke für etwaige Erleuchtungsversuche

Liebe Grüße

Sascha

#2

Hallo Sascha,

Ich vermute hier ist nicht der UMC-login, sonder OX-login gemeint?

Also wenn der User “deaktiviert” wird, dann wird der OX-user in der OX-DB (MySQL) komplett gelöscht, inkl. aller seiner PIM-Daten (Kalender / Kontakte / Aufgaben) und Einstellungen.

Emails sind davon nicht betroffen. Diese zeigt OX nur an, werden aber tatsächlich von Postfix+Dovecot/Cyrus gehandhabt. Mailboxen werden nur gelöscht, wenn der User bzw. seine mailPrimaryAddress gelöscht wird und mail/{cyrus,dovecot}/mailbox/delete=yes.

Grüße
Daniel

#3

Hi Daniel,

danke für Deine Antwort, habe ich mir genau so gedacht, wollte nur sicher gehen.
Nur:
Wenn ich den User (das Mailkonto ist ja schliesslich noch da) wieder aktivieren will für OX, dann sollte der login doch wieder funktionieren, oder? Das hat aber in diesem Fall nicht funktioniert.
Klar, der Nutzer wäre dann ein “neuer” OX User mit leerem kalender und Adressbuch, aber die Mails solten wieder vollständig sein.
Könnt Ihr vielleicht nachstellen, ob ein “Reaktivieren” wirklich nicht funktioniert?

Danke
Sascha

#4

Hallo,

bei mir funktioniert das - hab’s gerade getestet.
Im listener.log sollten sich Hinweise darauf finden was passiert ist. create/delete-Aufrufe lassen sich schnell so finden:

egrep 'command /opt/open-xchange/sbin.*username=test1' /var/log/univention/listener.log
2017-07-26 09:56:50 INFO: command /opt/open-xchange/sbin/deleteuser --username=test1 --adminuser=oxadmin --contextid=10
2017-07-26 09:57:18 INFO: command /opt/open-xchange/sbin/createuser --adminuser=oxadmin --contextid=10 --username=test1 --email= [..]

Nach dem createuser muss dann im logfile das Problem stehen.

Gruß
Daniel

#5

Hi,
hier finde ich dazu leider in allen logs nichts…

ls -lah
insgesamt 25M
drwxr-xr-x 2 root root 4,0K Jul 26 10:28 .
drwx------ 8 root root 4,0K Jul 26 10:27 …
-rw-r----- 1 root adm 1,3M Jul 26 10:25 listener.log
-rw-r----- 1 root adm 2,8M Jul 23 06:25 listener.log.1
-rw-r----- 1 root adm 3,8K Mai 18 13:04 listener.log.10
-rw-r----- 1 root adm 497 Mai 7 06:26 listener.log.11
-rw-r----- 1 root adm 497 Apr 30 06:26 listener.log.12
-rw-r----- 1 root adm 2,9M Jul 16 06:25 listener.log.2
-rw-r----- 1 root adm 2,8M Jul 9 06:25 listener.log.3
-rw-r----- 1 root adm 2,8M Jul 2 06:25 listener.log.4
-rw-r----- 1 root adm 2,8M Jun 25 06:25 listener.log.5
-rw-r----- 1 root adm 2,8M Jun 18 06:25 listener.log.6
-rw-r----- 1 root adm 2,8M Jun 11 06:25 listener.log.7
-rw-r----- 1 root adm 2,8M Jun 4 06:25 listener.log.8
-rw-r----- 1 root adm 1,6M Mai 28 06:25 listener.log.9
root@office:~/listener# egrep ‘command /opt/open-xchange/sbin.*username=testuser’ listener.log *

aber gut, wenn Du sagst, dass das bei Dir geht, dann weiss ich, dass es grundsätzlich gehen sollte.
So kann ich dass ja weitergeben.

liebe Grüße und Dank

Sascha

#6

Vermutlich sind listener/debug/level oder ox/debug/level zu niedrig, so dass diese Aufrufe nicht geloggt werden.

#7

Hallo Sascha,

Kurze Ergänzung:

Wir hatten das Problem auch mal vor langer Zeit festgestellt und das sind meine Erfahrungen von damals:
OX hat intern einen Caching-Mechanismus, der bestimmte Infos “ein paar Minuten” vorhält (bitte frag mich nicht nach den genauen Timeouts :slight_smile: ). Wenn der User gelöscht und neu angelegt wird, bekommt er dadurch intern eine neue OX-User-Id, es wird aber erstmal versucht, den User mit der alten OX-User-Id aus dem Cache anzumelden, was dann AFAIR zu der genannten Fehlermeldung führt.

Ein Weg, um den Cache zu invalidieren, ist mir nicht bekannt, aber i.d.R. hat Abwarten ausgereicht. D.h. nach einiger Zeit müsste es wieder gehen. Das “Deaktivieren → Aktivieren” ist ja meist kein Vorgang, den man regelmäßig macht.

Viele Grüße

Sönke

Mastodon