Bug 26872 - Absturz des Modulprozesses bei binären Daten für jpegPhoto
Absturz des Modulprozesses bei binären Daten für jpegPhoto
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: UMC - Users
UCS 3.0
Other Linux
: P3 normal (vote)
: UCS 3.0-2
Assigned To: Alexander Kläser
Lukas Walter
: interim-3
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-23 15:09 CEST by Alexander Kläser
Modified: 2013-02-25 12:23 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
Skript zum Setzen von jpegPhoto via ldapmodify (493 bytes, text/plain)
2012-07-06 17:18 CEST, Alexander Kläser
Details
Skript zum Setzen von jpegPhoto via ldapmodify (1.40 KB, text/plain)
2012-07-09 10:41 CEST, Alexander Kläser
Details
Skript zum Setzen von jpegPhoto via ldapmodify (1.91 KB, text/plain)
2012-07-09 15:32 CEST, Alexander Kläser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kläser univentionstaff 2012-04-23 15:09:17 CEST
In UCS 2.4 wurden Benutzerfotos (Eigenschaft jpegPhoto) anscheinend als Binärdaten abgespeichert. Nach einem Update auf 3.0 stürzt der UDM-Modulprozess bei betroffenen Benutzern ab, sobald ein udm/get ausgeführt wird, da davon ausgegangen wird, dass die Daten base64-kodiert sind. Die Konvertierung nach JSON schlägt fehl und der Modulprozess stürzt dabei ab.

Dieses scheint ein generelles Problem zu sein.
Comment 1 Alexander Kläser univentionstaff 2012-04-23 15:13:26 CEST
Ich sehe zwei mögliche Wege:

(1) Es könnte mit einem Skript bei einem Update sichergestellt werden, dass die Fotodaten nach base64 konvertiert werden.

(2) Die interne Behandlung der Daten prüft, ob die Daten binär oder base64-encoded vorliegen.

Hier der Traceback, dafür wurde in der get()-Methode in udm/__init__.py der Aufruf als Thread auskommentiert:

> Traceback (most recent call last):
>   File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 97, in execute
>     func( request )
>   File "/usr/lib/pymodules/python2.6/univention/management/console/modules/udm/__init__.py", line 382, in get
>     self.finished( request.id, result )
>   File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 155, in finished
>     self.result( res )
>   File "/usr/lib/pymodules/python2.6/univention/management/console/modules/__init__.py", line 162, in result
>     self.signal_emit( 'success', response )
>   File "/usr/lib/pymodules/python2.6/notifier/signals.py", line 68, in signal_emit
>     self.__signals[ signal ].emit( *args )
>   File "/usr/lib/pymodules/python2.6/notifier/signals.py", line 34, in emit
>     if args: cb( *args )
>   File "/usr/lib/pymodules/python2.6/notifier/__init__.py", line 104, in __call__
>     return self._function( *tmp, **self._kwargs )
>   File "/usr/lib/pymodules/python2.6/univention/management/console/protocol/modserver.py", line 97, in _reply
>     self.response( msg )
>   File "/usr/lib/pymodules/python2.6/univention/management/console/protocol/modserver.py", line 262, in response
>     data = str( msg )
>   File "/usr/lib/pymodules/python2.6/univention/management/console/protocol/message.py", line 96, in __str__
>     data = json.dumps( self.body )
>   File "/usr/lib/pymodules/python2.6/simplejson/__init__.py", line 261, in dumps
>     return _default_encoder.encode(obj)
>   File "/usr/lib/pymodules/python2.6/simplejson/encoder.py", line 214, in encode
>     chunks = self.iterencode(o, _one_shot=True)
>   File "/usr/lib/pymodules/python2.6/simplejson/encoder.py", line 282, in iterencode
>     return _iterencode(o, 0)
> UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 0: invalid start byte
Comment 2 Alexander Kläser univentionstaff 2012-04-23 15:41:32 CEST
JPEG-Daten sind vorgesehen, dass sie binär im LDAP abgespeichert werden:

  http://www.oid-info.com/get/1.3.6.1.4.1.1466.115.121.1.28

Demnach sollten...

* bisherigen Einträge, die als base64 abgespeichert wurden, konvertiert und binär abgespeichert werden
* ein Mapping in user.py eingerichtet werden, das base64 Daten aus dem UDM nach Binärdaten für LDAP konvertiert und umgekehrt
* die jpegPhoto-Syntax angepasst werden, da die tostring-Methode dann nicht mehr notwendig scheint (die Daten werden dann ja über das Mapping nach base64 konvertiert)
Comment 3 Alexander Kläser univentionstaff 2012-07-06 17:18:12 CEST
Created attachment 4516 [details]
Skript zum Setzen von jpegPhoto via ldapmodify
Comment 4 Alexander Kläser univentionstaff 2012-07-09 10:41:03 CEST
Created attachment 4518 [details]
Skript zum Setzen von jpegPhoto via ldapmodify
Comment 5 Alexander Kläser univentionstaff 2012-07-09 10:47:28 CEST
(In reply to comment #4)
> Created an attachment (id=4518) [details]
> Skript zum Setzen von jpegPhoto via ldapmodify

Bei dem nachfolgenden get-Aufruf für den Benutzer Administrator stürzt der Modulprozess ab:

> umc-command -U Administrator -P univention udm/get -f users/user -l -o "uid=Administrator,cn=users,dc=univention,dc=qa"
Comment 6 Alexander Kläser univentionstaff 2012-07-09 15:32:44 CEST
Created attachment 4521 [details]
Skript zum Setzen von jpegPhoto via ldapmodify

Finales Test-Skript, dass Testbenutzer mit binären und base64-kodierten JPEG-Bildern anlegt.
Comment 7 Alexander Kläser univentionstaff 2012-07-09 15:51:01 CEST
Der Fehler wurde behoben. Dazu wurde:

(a) das Tool convert-user-base64-photos erstellt, dass die entsprechenden LDAP-Einträge mit dem Attribute jpegPhoto ausmacht und sie anzeigt sowie zu Binärdaten konvertiert; die Einträge werden beim Paket-Update automatisch angepasst

(b) ein entsprechendes Mapping von Base64- zu Binärdaten hinzugefügt
→ QA: Das Benutzerzertifikat und jpegPhoto benutzen nun dasselbe Mapping, bitte in der QA auch noch einmal überprüfen, dass dort keine Probleme entstehen.


 univention-directory-manager-modules (7.0.274-1) unstable; urgency=low
 .
   * added tool convert-user-base64-photos
   * the attribute jpegPhoto is treated as binary format in LDAP now
   * base64 encoded jpegPhoto values are converted automatically when
     updating
   Bug #26872
Comment 8 Stefan Gohmann univentionstaff 2012-07-11 20:56:14 CEST
Diese Meldung sehe ich beim Update eines UCS@school 3.0-1 System (DC Slave):

univention-directory-manager-tools (7.0.283-4.849.201207111821) wird eingerichtet ...
Not updating directory/manager/cmd/debug/level
Not updating directory/manager/cmd/timeout
Traceback (most recent call last):
  File "/usr/share/univention-directory-manager-tools/convert-user-base64-photos", line 117, in <module>
    run(args[0], verbose = options.verbose)
  File "/usr/share/univention-directory-manager-tools/convert-user-base64-photos", line 53, in run
    lo = univention.uldap.getAdminConnection()
  File "/usr/lib/pymodules/python2.6/univention/uldap.py", line 68, in getAdminConnection
    bindpw=open('/etc/ldap.secret').read()
IOError: [Errno 2] No such file or directory: '/etc/ldap.secret'
Comment 9 Alexander Kläser univentionstaff 2012-07-12 12:18:07 CEST
(In reply to comment #8)
> Diese Meldung sehe ich beim Update eines UCS@school 3.0-1 System (DC Slave):
> 
> univention-directory-manager-tools (7.0.283-4.849.201207111821) wird
> eingerichtet ...
> Not updating directory/manager/cmd/debug/level
> Not updating directory/manager/cmd/timeout
> Traceback (most recent call last):
>   File
> "/usr/share/univention-directory-manager-tools/convert-user-base64-photos",
> line 117, in <module>
>     run(args[0], verbose = options.verbose)
>   File
> "/usr/share/univention-directory-manager-tools/convert-user-base64-photos",
> line 53, in run
>     lo = univention.uldap.getAdminConnection()
>   File "/usr/lib/pymodules/python2.6/univention/uldap.py", line 68, in
> getAdminConnection
>     bindpw=open('/etc/ldap.secret').read()
> IOError: [Errno 2] No such file or directory: '/etc/ldap.secret'

Stimmt, danke für den Hinweis, das Skript sollte nur auf einem DC-Master ausgeführt werden. Das wurde angepasst.


 univention-directory-manager-modules (7.0.283-5) unstable; urgency=low
 .
   * only call convert-user-base64-photos on a DC master in the postinst;
     Bug #26872
Comment 10 Lukas Walter univentionstaff 2012-07-13 15:03:03 CEST
- nach dem Update eines UCS 3.0-1 Masters auf UCS 3.0-2 waren alle zuvor base64 codiert im ldap abgelegten jpegPhotos decodiert

- beim Update eines UCS 3.0-1 Slaves auf UCS 3.0-2 wurde das Konvertierungsscript nicht ausgeführt

- beim Anlegen eines Benutzers via cli mit base64 codiertem string als jpegPhoto wird das Bild decodiert ins ldap gemappt

- beim Anlegen eines Benutzers via UMC mit .jpeg Bild wird dieses ebenfalls korrekt ins ldap übertragen

- Modulprozess stirbt nicht mehr wie beschrieben



Changelog in Ordnung,
Verified.
Comment 11 Stefan Gohmann univentionstaff 2012-07-20 15:25:27 CEST
UCS 3.0-2 has been released: 
  http://forum.univention.de/viewtopic.php?f=54&t=1905

If this error occurs again, please use "Clone This Bug".