Bug 16287 - Sync-Fehler mit nicht-Scalix-Benutzer in Scalix-Gruppe
Sync-Fehler mit nicht-Scalix-Benutzer in Scalix-Gruppe
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: ZZZ - Trash - Scalix for UCS
UCS 2.0
All Linux
: P4 normal (vote)
: ---
Assigned To: Bugzilla Mailingliste
:
: 9220 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-09 08:55 CET by Janis Meybohm
Modified: 2011-12-16 14:16 CET (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Janis Meybohm univentionstaff 2009-11-09 08:55:29 CET
1) Im LDAP werden zwei Benutzer angelegt, einer als Scalix-Objekt, einer 
nicht als Scalix-Objekt (uid=else)
2) Es wird eine neue Benutzergruppe als Scalix-Objekt angelegt, beide im 
ersten Schritt erstellten Benutzer werden als Mitglieder eingetragen. 
Die PDL wird korrekt nur mit einem Benutzer angelegt.
3) Der zweite Benutzer wird mit der Option "Scalix-Objekt" versehen. Der 
Benutzer wird korrekt in Scalix übernommen, jedoch nicht in die PDL 
aufgenommen.
4) Der zweite Benutzer wird im LDAP wieder aus der Benutzergruppe 
entfernt. Beim omldapsync kommt es zu einem Fehler:

2007-07-16 16:44:54 STATUS: apply membdelete data against Scalix ...
Enter CAA Password: --------> Sending SOAP Request to 
Ubermanager@http://ugs-master150.hosts3.invalid/caa/ for 
method:DeleteMembersFromGroup
--------> Received SOAP Response from 
Ubermanager@http://ugs-master150.hosts3.invalid/caa/
error: Response contains failure report
>>>>>>>>SOAP Request
SOAP part:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Header/>
    <SOAP-ENV:Body>
        <scalix-caa:CAARequestMessage 
xmlns:scalix-caa="http://www.scalix.com/caa">
            <ServiceType>scalix.res</ServiceType>
            <Credentials id="12345">
                <Identity name="ucsldapimport" passwd="xxxxxxxx"/>
            </Credentials>
            <FunctionName>DeleteMembersFromGroup</FunctionName>
            <DeleteMembersFromGroupParameters 
id="5cc61a38-c7f6-102b-9500-fd4972a4ca21">
                <member fa="uid=else,cn=users,dc=hosts3,dc=invalid"/>
            </DeleteMembersFromGroupParameters>
        </scalix-caa:CAARequestMessage>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
>>>>>>>>SOAP Response
SOAP part:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP-ENV:Body>
        <SOAP-ENV:Fault>
            <faultcode>SOAP-ENV:Server</faultcode>
            <faultstring>CAA Service Error</faultstring>
            <detail>
                <scalix-caa:fault-details 
xmlns:scalix-caa="http://www.scalix.com/caa">
                    <message>ugs-master150.hosts3.invalid:omdelpdln : 
[OM 18025] The requested name is not in the PDL  ORN-ADDRESS=CN=Els
e Kling/G=Else/S=Kling/OU1=ugs-master150</message>
                    <errorcode>OM 18025</errorcode>
                </scalix-caa:fault-details>
            </detail>
        </SOAP-ENV:Fault>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>
0 entries passed
1 entries failed
0 entries warned
2007-07-16 16:44:56 ERROR: failed to run omldapagent
Comment 1 Janis Meybohm univentionstaff 2009-11-09 08:56:40 CET
(In reply to comment #1)
> Bei einem Kunden erneut aufgetreten, Ticket: 2008081210000064

(In reply to comment #2)
> Das Problem besteht in Scalix 11.4.1 auch noch. Ich halte das für ein Problem
> auf Scalix Seite und habe deshalb Scalix um Mithilfe gebeten. Mail liegt im
> Shared Folder.

(In reply to comment #4)
> Vom Scalix Support kam dazu folgendes:
> *******************************************************
> Moin,
> die Lösung hatte ich meiner Ansicht nach auch Euch schon mal mitgeteilt.
> Zumindest bin ich mir fast sicher, dass im Training auch erwähnt zu
> haben. Wieauchimmer.
> 
> Sie steckt jedenfalls in der sync.cfg:
> # IM_FAIL2WARN_OPCODES: space separated list of opcodes that will be changed
> # from failure to warning, a way to auto ignore certain type of error
> # opcodes for add/modify/delete users=1/4/7 and groups=2/5/8
> # opcodes for add/modify/delete members=3/3/9 and limits=12/12/-
> # NOTE: should use a whole set, e.g. "3 9" to auto ignore all members error
> IM_FAIL2WARN_OPCODES=
> 
> 
> Das ist etwas irritierend geschrieben und sollte dann wie folgt gesetzt
> werden:
> IM_FAIL2WARN_OPCODES=3 3 9
> *******************************************************
> 
> Dadurch bekommt man die Fehlermeldungen nicht mehr, allerdings ist der Benutzer
> danach auch nicht in der Gruppe.

(In reply to comment #5)
> Mail vom Scalix-Support:
>
> Hallo,
> > ich habe das gerade getestet. Ich bekomme jetzt keine Fehlermeldungen
> > mehr,
> > allerdings ist der zweite Benutzer, nachdem dieser zum Scalix Benutzer
> > wurde,
> > nicht in der PDL vorhanden. Nochmal der Ablauf:
> > - Scalix Benutzer anlegen
> > - Nicht Scalix Benutzer anlegen
> > - Gruppe mit den beiden Benutzern anlegen
> > - Nicht Scalix Benutzer zu einem Scalix Benutzer machen
> > 
> > Jetzt ist der neue Scalix Benutzer da, aber nicht in der Gruppe. Wenn
> > ich von
> > der Gruppe jetzt die Scalix Option entfernen, wird die Gruppe auf
> > Scalix
> > Seite gelöscht, füge ich die Option wieder hinzu, dann wird die Gruppe
> > wieder
> > angelegt und hat auch beide Benutzer als Mitglieder. Lösche ich von
> > einem
> > Benutzer die Scalix Option, dann wird dieser auch automatisch aus der
> > Gruppe
> > entfernt.
> > 
> Ja, das ist (leider) richtig. Bei der ersten Synchronisation wird
> versucht, den nicht vorhandenen Nutzer in die Gruppe zu packen. Das
> schlägt fehl, erzeugt aber keinen harten Fehler und wird somit bei den
> nächsten Läufen ignoriert (Eintrag ist in search.last vorhanden).
> 
> Das ist ein bekanntes Design-Problem. Es ist nicht geplant, hier noch
> Änderungen vorzunehmen. Für Scalix 12 ist eine wesentliche
> Design-Änderung geplant. Das derzeitige X.400 Verzeichnis wird entweder
> durch ein eigenes LDAP ersetzt oder dockt komplett an ein externes LDAP an. 
> Damit entfällt selbstredend auch die Notwendigkeit einer Synchronisation.
> 
> 
> Mein Workaround wäre aber wie folgt:
> - den fraglichen Nutzer in UCS für Scalix aktivieren
> - den fraglichen Nutzer in UCS aus der Gruppe entfernen
> - spätestens jetzt einmal speichern/omldapsync laufen lassen
> - den fraglichen Nutzer wieder in die Gruppe hinzufügen.
> - speichern bzw. ldapsync
> 
> Die gesamte Gruppe im Scalix zu löschen und wieder anzulegen hat den
> negativen Effekt, dass sie für eine Weile aus dem Verzeichnis
> verschwindet. Bei Outlook-Nutzern u.U. für die Dauer der aktuellen Sitzung.
Comment 2 Janis Meybohm univentionstaff 2009-11-09 08:58:43 CET
*** Bug 9220 has been marked as a duplicate of this bug. ***
Comment 3 Tobias Scherer univentionstaff 2010-05-05 17:31:46 CEST
Dieses Verhalten wurde auch an Ticket#: 2010041910000269 berichtet, UCS 2.2 Scalix 11.4.6
Comment 4 Stefan Gohmann univentionstaff 2011-12-16 14:16:57 CET
Die Pflege von Scalix4UCS soll direkt durch Scalix erfolgen:

http://www.univention.de/univention/presse/pressemitteilungen/univention-und-scalix-definieren-kooperation-neu/

Hier ist von uns keine weitere Aktion notwendig, deshalb WONTFIX.