Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry,
On 01/23/17 17:45, thierry bordaz wrote:
>
>
> On 01/23/2017 05:09 PM, Harald Dunkel wrote:
>>
>> I created a full replica (including CA) in an LXC container today
>> ("ipabak"). The idea is to take a snapshot of the whole container,
>> run ipabak without network connection, and then create and verify
>> a shell script to fix the disconnected replica. On problems I can
>> roll ipabak back to the snapshot. Maybe it needs some iterations to
>> create a working script.
>
> Do you want to run ipabak against ipa1 or ipa2 server ?
ipabak is a replica of ipa1:
# ipa-replica-manage -v list ipabak.vs.example.de
Directory Manager password:
ipa1.example.de: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2017-01-24 10:13:13+00:00
# ipa-csreplica-manage -v list ipabak.vs.example.de
Directory Manager password:
ipa1.example.de
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2017-01-24 10:14:01+00:00
ipa1 is the first master. ipabak was setup using
# ssh r...@ipa1.example.de ipa-replica-prepare ipabak.vs.example.de
# scp -p
r...@ipa1.example.de:/var/lib/ipa/replica-info-ipabak.vs.example.de.gpg
/var/lib/ipa/
# ipa-replica-install /var/lib/ipa/replica-info-ipabak.vs.example.de.gpg
--setup-ca
Do you think this is OK?
BTW, freeipa doesn't provide DNS in my net.
>>
>> When the script appears to be fine I can revert the ipabak container
>> to the most recent snapshot again, connect it to the network to sync
>> it with ipa1 and then run the script with multisite replication
>> enabled.
>>
>> Do you think this could work?
>
> It should work if you run ipabak against ipa1 or ipa2. But then how to
> prevent that ipa1/ipa2 get more conflicts with the iterations of tests ?
>
ipabak is not supposed to be connected to ipa1 again, if it has
been modified by the script in development. It has to be reverted
back to the snapshot first. From ipa1's point of view, ipabak just
goes offline for some time, but it never comes back modified.
The development iterations are not cumulative, except for the
script. In each cycle I add code to the script, revert the dis-
connected ipabak back to the snapshot, and test the whole script.
The snapshot is not overwritten.
The snapshot of a LXC container is just an exact copy of its root
directory, taken while the container was off. To revert a LXC
container back to its snapshot, I have to turn it off, replace
its root directory by a copy of the snapshot, and turn it on
again.
To create a new snapshot I revert ipabak to the current snapshot,
connect it to the network, sync it with ipa1, disconnect it and
copy the containers root directory to the new snapshot directory.
The old snapshot has to be removed then.
When the script appears to be ready I have to revert and sync
ipabak again as above, but instead of disconnecting it from the
network I have to stop all ipa servers in parallel to take a
snapshot of each. (All ipa servers are LXC containers.) Next
start the ipa servers again and run the script on ipabak, now
connected with ipa1. This should make the changes "official".
Did I miss something here?
Harri
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/24/2017 12:36 PM, Harald Dunkel wrote:
Hi Thierry,
On 01/23/17 17:45, thierry bordaz wrote:
On 01/23/2017 05:09 PM, Harald Dunkel wrote:
I created a full replica (including CA) in an LXC container today
("ipabak"). The idea is to take a snapshot of the whole container,
run ipabak without network connection, and then create and verify
a shell script to fix the disconnected replica. On problems I can
roll ipabak back to the snapshot. Maybe it needs some iterations to
create a working script.
Do you want to run ipabak against ipa1 or ipa2 server ?
ipabak is a replica of ipa1:
# ipa-replica-manage -v list ipabak.vs.example.de
Directory Manager password:
ipa1.example.de: replica
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2017-01-24 10:13:13+00:00
# ipa-csreplica-manage -v list ipabak.vs.example.de
Directory Manager password:
ipa1.example.de
last init status: None
last init ended: 1970-01-01 00:00:00+00:00
last update status: Error (0) Replica acquired successfully: Incremental
update succeeded
last update ended: 2017-01-24 10:14:01+00:00
ipa1 is the first master. ipabak was setup using
# ssh r...@ipa1.example.de ipa-replica-prepare ipabak.vs.example.de
# scp -p
r...@ipa1.example.de:/var/lib/ipa/replica-info-ipabak.vs.example.de.gpg
/var/lib/ipa/
# ipa-replica-install /var/lib/ipa/replica-info-ipabak.vs.example.de.gpg
--setup-ca
Do you think this is OK?
Yes it looks ok.
BTW, freeipa doesn't provide DNS in my net.
When the script appears to be fine I can revert the ipabak container
to the most recent snapshot again, connect it to the network to sync
it with ipa1 and then run the script with multisite replication
enabled.
Do you think this could work?
It should work if you run ipabak against ipa1 or ipa2. But then how to prevent
that ipa1/ipa2 get more conflicts with the iterations of tests ?
ipabak is not supposed to be connected to ipa1 again, if it has
been modified by the script in development. It has to be reverted
back to the snapshot first. From ipa1's point of view, ipabak just
goes offline for some time, but it never comes back modified.
The development iterations are not cumulative, except for the
script. In each cycle I add code to the script, revert the dis-
connected ipabak back to the snapshot, and test the whole script.
The snapshot is not overwritten.
The snapshot of a LXC container is just an exact copy of its root
directory, taken while the container was off. To revert a LXC
container back to its snapshot, I have to turn it off, replace
its root directory by a copy of the snapshot, and turn it on
again.
To create a new snapshot I revert ipabak to the current snapshot,
connect it to the network, sync it with ipa1, disconnect it and
copy the containers root directory to the new snapshot directory.
The old snapshot has to be removed then.
If I understand correctly the iterations of development I do not
understand why, at this point, you need to reconnect ipabak.
After you create ipabak replica, you take a snapshot of it (let
ipabak_0), then disconnect it from ipa1/ipa2.
Then you may start incremental dev of the script on the offline ipabak.
Before each test of the script, you just need to get ipabak to ipabak_0.
Am I missing something ?
When the script appears to be ready I have to revert and sync
ipabak again as above, but instead of disconnecting it from the
network I have to stop all ipa servers in parallel to take a
snapshot of each. (All ipa servers are LXC containers.) Next
start the ipa servers again and run the script on ipabak, now
connected with ipa1. This should make the changes "official".
How do you know if the script is ready ? When it resolves all the
conflict entries ?
thanks
thierry
Did I miss something here?
Harri
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/24/17 12:57, thierry bordaz wrote: > > If I understand correctly the iterations of development I do not understand > why, at this point, you need to reconnect ipabak. > After you create ipabak replica, you take a snapshot of it (let ipabak_0), > then disconnect it from ipa1/ipa2. > > Then you may start incremental dev of the script on the offline ipabak. > Before each test of the script, you just need to get ipabak to ipabak_0. > Am I missing something ? > ipa1 is not idle while the script is in development. I do not know if these conflicting entries pop up in some new entries on ipa1 while the script is in development. When the script seems to be ready, then I have to verify it with very recent copy of the database before the final run. > >> When the script appears to be ready I have to revert and sync >> ipabak again as above, but instead of disconnecting it from the >> network I have to stop all ipa servers in parallel to take a >> snapshot of each. (All ipa servers are LXC containers.) Next >> start the ipa servers again and run the script on ipabak, now >> connected with ipa1. This should make the changes "official". > > How do you know if the script is ready ? When it resolves all the conflict > entries ? > Hopefully yes, but there were 2 conflicts that already made some problems: deleting entry "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first. deleting entry "cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de" ldap_delete: Operations error (1) I got these problems before I became more careful with this. Regards Harri -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/24/2017 02:22 PM, Harald Dunkel wrote: On 01/24/17 12:57, thierry bordaz wrote: If I understand correctly the iterations of development I do not understand why, at this point, you need to reconnect ipabak. After you create ipabak replica, you take a snapshot of it (let ipabak_0), then disconnect it from ipa1/ipa2. Then you may start incremental dev of the script on the offline ipabak. Before each test of the script, you just need to get ipabak to ipabak_0. Am I missing something ? ipa1 is not idle while the script is in development. I do not know if these conflicting entries pop up in some new entries on ipa1 while the script is in development. When the script seems to be ready, then I have to verify it with very recent copy of the database before the final run. I would be surprised that new conflicts are popping up on ipa1/ipa2 during develop of the script. But yes when the script is ready, you need to sync ipabak/ipa1 to be sure the script will run successfully on all conflicts (old and new). When the script appears to be ready I have to revert and sync ipabak again as above, but instead of disconnecting it from the network I have to stop all ipa servers in parallel to take a snapshot of each. (All ipa servers are LXC containers.) Next start the ipa servers again and run the script on ipabak, now connected with ipa1. This should make the changes "official". How do you know if the script is ready ? When it resolves all the conflict entries ? Hopefully yes, but there were 2 conflicts that already made some problems: deleting entry "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first. deleting entry "cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de" ldap_delete: Operations error (1) I got these problems before I became more careful with this. This will be a difficulty to setup that script. You may be unable to delete some entries (managed entry, tombstones..). I think one target of the script is to get the 'valid' entries at the expected level: having the expected set of attribute/values. A kind of merge of valid/conflict entries. Then you may have to moddn some conflict children under the valid entry. At the end, remove the conflict entries. As I said, setting up such script could take you more time than fixing manually the 43 conflicts. regards thierry Regards Harri -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
Hi Thierry, On 01/24/17 15:01, thierry bordaz wrote: >> Hopefully yes, but there were 2 conflicts that already made some >> problems: >> >> deleting entry >> "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" >> ldap_delete: Server is unwilling to perform (53) >> additional info: Deleting a managed entry is not allowed. It >> needs to be manually unlinked first. >> >> >> deleting entry >> "cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de" >> ldap_delete: Operations error (1) >> >> I got these problems before I became more careful with this. > > This will be a difficulty to setup that script. > You may be unable to delete some entries (managed entry, tombstones..). > > I think one target of the script is to get the 'valid' entries at the > expected level: having the expected set of attribute/values. A kind of merge > of valid/conflict entries. > Then you may have to moddn some conflict children under the valid entry. > At the end, remove the conflict entries. I agree. But I still need to work on a snapshot first, without the risk of making things worse. Would you suggest to disconnect ipabak from the network and ipa1, cleanup the mess as far as possible, and then connect ipabak to the network again to rely upon the regular replica synchroni- zation? > > As I said, setting up such script could take you more time than fixing > manually the 43 conflicts. > Maybe there is a misunderstanding about "script" here: Its not a high-end shell script with man page and command line flags and so on. It is just a sequence of variable assignments and commands to run. Goal is to avoid having to type the same stuff twice, and to make use of copy and paste in an editor. One key feature is to get something reproducible. Every helpful advice is highly welcome Harri -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]
On 01/24/2017 04:18 PM, Harald Dunkel wrote: Hi Thierry, On 01/24/17 15:01, thierry bordaz wrote: Hopefully yes, but there were 2 conflicts that already made some problems: deleting entry "cn=ipaservers+nsuniqueid=109be304-ccd911e6-a5b3d0c8-d8da17db,cn=ng,cn=alt,dc=example,dc=de" ldap_delete: Server is unwilling to perform (53) additional info: Deleting a managed entry is not allowed. It needs to be manually unlinked first. deleting entry "cn=ipaservers+nsuniqueid=109be302-ccd911e6-a5b3d0c8-d8da17db,cn=hostgroups,cn=accounts,dc=example,dc=de" ldap_delete: Operations error (1) I got these problems before I became more careful with this. This will be a difficulty to setup that script. You may be unable to delete some entries (managed entry, tombstones..). I think one target of the script is to get the 'valid' entries at the expected level: having the expected set of attribute/values. A kind of merge of valid/conflict entries. Then you may have to moddn some conflict children under the valid entry. At the end, remove the conflict entries. I agree. But I still need to work on a snapshot first, without the risk of making things worse. Would you suggest to disconnect ipabak from the network and ipa1, cleanup the mess as far as possible, and then connect ipabak to the network again to rely upon the regular replica synchroni- zation? Yes, as soon as ipaback is in sync with ipa1 and you took a snapshot of ipaback, I think you can disconnect ipaback and run your script on it (iterating with the snapshot). As I said, setting up such script could take you more time than fixing manually the 43 conflicts. Maybe there is a misunderstanding about "script" here: Its not a high-end shell script with man page and command line flags and so on. It is just a sequence of variable assignments and commands to run. Goal is to avoid having to type the same stuff twice, and to make use of copy and paste in an editor. One key feature is to get something reproducible. Every helpful advice is highly welcome Harri -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] HBAC trust groups inconsistent
Hello, I have been testing Freeipa since 4.2 and am very impressed overall. A pending issue I have not been able to resolve is getting HBAC to work consistently. I’m limited to an AD-trust scenario where AD groups are mapped to Posix groups. While ‘id user@domain’ will return all groups for new queries, or after a reset of the cache and a restart of SSSD, this does not *always* seem to be the case with kerberized HTTP. (http://www.freeipa.org/page/Web_App_Authentication) With the HBAC rule allowing access from a particular Posix mapped group to a custom service (‘HTTP’) I typically see it sometimes working, and then randomly failing after some delay ( minutes – hours), hinting at a cache miss of some sort. Performing an HTTP GET to the kerberized webserver may at first fail. After a short delay it may sometimes start working out of the blue. In some cases disabling and enabling HBAC rules or performing ‘id user@domain’ helps with sorting the issue. As you can see from the logging the first time SSSD gathers 38 groups, failing to get the Posix mapped group, but a few minutes later getting 39 groups, including the ‘sambatesters’ mapped group that the HBAC rule applies to. Failing: (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [hbac_eval_user_element] (0x1000): [38] groups for [user@domain.local] (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=SG_ROLE_PROXY_PROD_Change,OU=Roles,OU=Groups,DC=domain,DC=local] ... * Skipping all underscore_seperated_group CNs * (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=* ICT Infrastructure Unix,OU=Distribution,OU=Groups,DC=domain,DC=local] (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x21a9f4 (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x21e99e0 (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Running timer event 0x21a9f40 "ltdb_callback" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Destroying timer event 0x21e99e0 "ltdb_timeout" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Ending timer event 0x21a9f40 "ltdb_callback" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x21c90c0 (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x21b6e00 (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Running timer event 0x21c90c0 "ltdb_callback" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Destroying timer event 0x21b6e00 "ltdb_timeout" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Ending timer event 0x21c90c0 "ltdb_callback" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x21eb880 (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x21b6e00 (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Running timer event 0x21eb880 "ltdb_callback" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Destroying timer event 0x21b6e00 "ltdb_timeout" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Ending timer event 0x21eb880 "ltdb_callback" (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [sdap_id_op_destroy] (0x4000): releasing operation connection (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, ) [Success] (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [be_pam_handler_callback] (0x0100): Sending result [6][domain.local] (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [be_pam_handler_callback] (0x0100): Sent result [6][domain.local] (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [sdap_process_result] (0x2000): Trace: sh[0x21a6b10], connected[1], ops[(nil)], ldap[0x21ab2b0] (Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! Succeeding: (Tue Jan 24 19:06:58 2017) [sssd[be[unix.domain.local]]] [hbac_eval_user_element] (0x1000): [39] groups for [user@domain.local] (Tue Jan 24 19:06:58 2017) [sssd[be[unix.domain.local]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=SG_ROLE_PROXY_PROD_Change,OU=Roles,OU=Groups,DC=domain,DC=local] ... (Tue Jan 24 19:06:58 2017) [sssd[be[unix.domain.local]]] [hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=AFD-ICT-DM Change,OU=_SOMEOU,OU=Groups,DC=domain,DC=l
Re: [Freeipa-users] Backend & UI plugin update for 4.4.x
And now I'm convinced this has nothing to do with my plugin and
instead is a bug somewhere in FreeIPA.
I removed the entirety of the "astrocustom" plugin that I wrote,
restarted httpd, and force reloaded the page in chrome. I clicked to
add a new user, gave the basic information, and clicked "add and
edit". The bottom of the page shows the "Employee information" on the
left side bottom, and the manager drop-down is empty. I entered '1'
in the "employee type" field and clicked save, and now "Employee
Information" is on the right side directly under "Contact settings",
and the manager drop-down is populated with the list of UIDs on the
system.
When the UI is in the failed state, the "email address" field is also
blank, but when things switch to how they should be (after submitting
a change) it is populated with the email address in the record. I
just tested by adding a telephone number to the record, and that also
made the contact information and employee information facets refresh
with the proper data. Pressing shift-reload again makes all the
information disappear (including the telephone number I just entered).
This is with ipa-server-4.4.0-14.el7_3.4
On Mon, Jan 23, 2017 at 1:55 PM, Steve Huston
wrote:
> Just tested again, and this is still baffling:
>
> * Create a stage user with the right data, works fine, can be edited.
> * Enable that user, and now the two fields ('manager' and
> 'employeeType') appear to have bogus data in the UI, and I cannot save
> the page without changing them to something else.
> * Once that user is saved, the "Employee Information" facet moves to
> the right side of the page, and now shows not only the current data in
> the manager drop down but also the other choices (uids). Change the
> value of manager and employeetype back to what they were previously
> and it saves.
> * An ldapsearch run when the user is first created (as the directory
> manager), and after having two edits (one to change the values to
> something else to let the webui save them, and one to change them back
> to what they should be and were the first time) produce completely
> identical results.
> * The output of "ipa user-show --all --raw" is also identical at
> those same steps.
>
> So something, somewhere, is being saved in a way that prevents the
> webui from displaying them properly, that gets fixed when those values
> are manually changed via the webui.
>
> On Thu, Jan 19, 2017 at 2:44 PM, Steve Huston
> wrote:
>> Even more interesting...
>>
>> I tried to modify one of the records that was not displaying properly
>> in the "active users" group, and sure enough the webui complained that
>> the "Requested By" (relabeled "manager") field was not filled in since
>> it was blank. It also, however, complained that the "User tier"
>> (relabeled "employeetype") was incorrect, even though it showed the
>> label associated with the value 1. I clicked the search drop-down for
>> manager, typed in my own uid, and even though everything had been
>> blank in the drop down before now my uid showed up. I clicked on it,
>> and my uid was now in the manager field. I then clicked the drop down
>> for employeetype, and chose one of the other options. I was now able
>> to save the changes to the record.
>>
>> Upon reloading the page, the "Employee Information" facet now shoed up
>> on the right side bottom, instead of the left side bottom where it was
>> appearing. I was also now able to change the drop-down fields for
>> manager and employeetype to another value, and save them, and they
>> worked fine even filling in all the data that should have been there.
>> This almost seemed like the data being returned by the server was
>> flawed somehow, and confusing the webui, but once it was forced to
>> have the right data and re-saved it worked fine subsequently.
>>
>> I looked at the output of "ipa user-show --all --raw" both
>> before and after making such changes on a user, and can detect no
>> difference between them.
>>
>> On Thu, Jan 19, 2017 at 1:14 PM, Alexander Bokovoy
>> wrote:
>>> On to, 19 tammi 2017, Steve Huston wrote:
On Thu, Jan 19, 2017 at 11:16 AM, Alexander Bokovoy
wrote:
>
> In short, FreeIPA 4.2 -> 4.4 change was by splitting server and client
> side plugins into different paths (ipaserver/plugins and
> ipaclient/plugins instead of being common in ipalib/plugins). The client
> code was also changed to always read metadata about API from the server
> side. This means the client can adopt to any server version that
> supports API metadata.
Right, and I think that the most of the plugin I had belongs
server-side; in fact, that's where I migrated it to, and things work
fine. I haven't tested if I can change those values with the cli, but
I'm less concerned about that at the moment.
> In my sample external plugin you referenced above you can see that I
> have client-side change that replaces an inpu
