Currently adding an image to a user is only achievable via ldapmodify. Would be useful to be able to achieve this with 'ipa user-mod' instead.
e.g Add user
[root@ds01 ~]# ipa user-add First name: Bruce Last name: Banner User login [bbanner]: ----------------- Added user "bbanner" ----------------- User login: bbanner First name: Bruce Last name: Banner Full name: Bruce Banner Display name: Bruce Banner Initials: BB Home directory: /home/bbanner GECOS field: Bruce Banner Login shell: /bin/bash Kerberos principal: bbanner@EXAMPLE.COM Email address: bbanner@example.com UID: 212800019 GID: 212800019 Password: False Kerberos keys available: False [root@ds01 ~]#
create bbanner.ldif as follows
dn: uid=bbanner,cn=users,cn=accounts,dc=example,dc=com changetype: modify add: jpegPhoto jpegPhoto:< file:///root/hulk.jpg
add file to user
[root@ds01 ~]# ldapmodify -Y GSSAPI -f bbanner.ldif Enter LDAP Password: modifying entry "uid=bbanner,cn=users,cn=accounts,dc=example,dc=com"
The above encodes the jpg file into a base64 output which is loaded into ldap, when trying to achieve this with "ipa user-mod tuser1 --setattr="jpegphoto=base64 hulk.jpg -w 0" it uploads a hash of the text "hulk.jpg -w 0" instead of uploading the actual encoding of the image itself.
base64 hulk.jpg -w 0
Testing so far has not yeilded any success using an ipa user-mod command.
Replying to [ticket:4073 dbmacartney]:
... The above encodes the jpg file into a base64 output which is loaded into ldap, when trying to achieve this with "ipa user-mod tuser1 --setattr="jpegphoto=base64 hulk.jpg -w 0" it uploads a hash of the text "hulk.jpg -w 0" instead of uploading the actual encoding of the image itself.
This is strange. When I run base64 hulk.jpg -w 0 I get base64 of the FILE, not the string itself:
# base64 hulk.jpg -w 0 /9j/4AAQSkZJRg...WjRz/2Q==
Replying to [comment:1 mkosek]:
Replying to [ticket:4073 dbmacartney]: ... The above encodes the jpg file into a base64 output which is loaded into ldap, when trying to achieve this with "ipa user-mod tuser1 --setattr="jpegphoto=base64 hulk.jpg -w 0" it uploads a hash of the text "hulk.jpg -w 0" instead of uploading the actual encoding of the image itself. This is strange. When I run base64 hulk.jpg -w 0 I get base64 of the FILE, not the string itself: {{{ base64 hulk.jpg -w 0 /9j/4AAQSkZJRg...WjRz/2Q== }}}
{{{
/9j/4AAQSkZJRg...WjRz/2Q== }}}
When running base64 imagename.jpg -w 0 the output is as expected. On a small image it would give a good few thousand character output, however when running
ipa user-mod todinson --setattr="'jpegphoto=base64 Thor.jpg -w 0'"
the output of "ipa user-show --all todinson" for the jpegPhoto attrib is as follows
jpegphoto: YmFzZTY0IFRob3IuanBnIC13IDA=
instead of the expected which would look similar to
jpegphoto: /9j/4AAQSkZJRgABAgEASABIAAD/4RCMRXhpZgAATU0AKgAAAAgABwESAAMAAAABAAEAAAEaAAUAAAABAAAAYgEbAAUAAAABAAAAagEoAAMAAAABAAIAAAExAAIAAAAUAAAAcgEyAAIAAAAUAAAAhodpAAQAAAABAAAAnAAAAMgAAABIAAAAAQAAAEgAAAABQWRvYmUgUGhvdG9zaG9wIDcuMAAyMDA4OjA2OjIxIDE2OjA0OjMwAAAAAAOgAQADAAAAAf//AACgAgAEAAAAAQAAAHigAwAEAAAAAQAAAHoAAAAAAAAABgEDAAMAAAABAAYAAAEaAAUAAAABAAABFgEbAAUAAAABAAABHgEoAAMAAAABAAIAAAIBAAQAAAABAAABJgICAAQAAAABAAAPXgAAAAAAAABIAAAAAQAAAEgAAAAB/9j/4AAQSkZJRgABAgEASABIAAD/7QAMQWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAHoAeAMBIgACEQEDEQH/3QAEAAj/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOczs7Jxb20UNoZUyjG2tONju1dj0WPJfZQ97tz3uf73KuOq5/8AwH/sLjf+86L1UfrY0/7T4v8A7bY6qBpPCKkp6p1Hxo0/7q43/vMkOqdRPej54uN/7zKLa/FS9MJKW/avURP8wf8A0Fxv/eZP+18//gP/AGFxv/eZP6IPA54ULq249YstENJjxKBoJolc9Xzx/oP/AGFxv/edQPWOoeNH/sLjf+8yz7OpY8+xrj5nRC+31E/QcPgkqvJ1f2z1Hxo/9hcX/wB5k37a6h/wH/sLjf8AvMq9FJvrFjZDHcEjU/JKzGtYJEOb4jlDiF1auE9kp651KeaP/YXF/wDeZP8AtzqPjR/7C4v/ALzKkY47qDhGvCKG+eudR/eo/wDYXF/95k37c6lMTR/7C4v/ALzLNmVMCElOz0zqeXl5bsbIFFlL6Mnc37Njt1bj32MIfXQx7XNexrva5JVehn/KTf8AiMr/ANtclJJT/9DnupCclv8A4Xxf/bbHVUNCvdRb+nZ/4X
trac is removing the backticks from commands. To stop that, surround commands with triple braces when writing comments here (see [[WikiFormatting]]. Or use the $() syntax:[[BR]] {{{ipa user-mod tuser1 --setattr="jpegphoto=$(base64 hulk.jpg -w 0)"}}}
$()
Thanks for pointing that out. Note that we resolved the issue with dbmacartney on IRC, he was forgotting some backtick. But the jpegphoto attribute was not correctly filled anyway, it seems that ldapmodify encodes the file differently - I did investigate the exact reason.
jpegphoto
ldapmodify
Replying to [comment:4 mkosek]:
The problem is simple. You are not supposed to base64 encode the contents. They are shown base64 encoded by ldapsearch, it does that when the content is a binarey string (not utf8) but it is saved as binary in ldap.
In an ldif you would have to use double colonds (::) after the attribute argument to tell it it should base64 decode before storing to ldap, but this is not something available to the ipa utility.
I suggest we rather implement jpegPhoto so that you pass in 'file://path/to/jpeg' and the framework takes care of properly formatting the content for ldap use.
Metadata Update from @dbmacartney: - Issue assigned to jcholast - Issue set to the milestone: Future Releases
Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.