Re: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi
Dne 4.8.2015 v 17:02 Robbie Harwood napsal(a): Michael Šimáček msima...@redhat.com writes: Attaching new revision of the patch that performs the full negotiation cycle. Looks good to me, thanks! IPA compiles and installs fine with the patch applied, so ACK. Pushed to master: f0b4c4487ed77a3037cbbc46206d598c58f06bb1 -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work
Hi, Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): I've been carrying these patches in my tree for a while, I think it is time to put them in master as they stand on their own. Simo. Patch 530: ACK Patch 531: ACK Patch 532: The methods should be static methods: @staticmethod def setOption(name, value): ... Honza -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged
- Original Message - From: thierry bordaz tbor...@redhat.com To: Jan Cholasta jchol...@redhat.com Cc: freeipa-devel@redhat.com Sent: Monday, August 3, 2015 5:34:02 PM Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged On 07/28/2015 12:34 PM, Jan Cholasta wrote: Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): Dne 27.7.2015 v 17:59 Martin Basti napsal(a): On 23/07/15 14:43, Martin Basti wrote: Hello, I tried to fix #5145 and I partially succeeded. However, I cannot fix this part of ticket, where user is prompted to write name and surname. $ ipa stageuser-add tuser --from-delete First name: this will be ignored Last name: this will be also ignored Added stage user tuser As the first name and last name are mandatory attributes of stageuser-add command, but they are not needed by when the --from-delete option is used. I would like to ask how to fix this issue, IMO this will be huge hack in internal API. Or should we just document this bug as known issue (thierry wrote that this is not use case that should be used often)? The best solution would be separate command, but this idea was rejected in thread [Freeipa-devel] User life cycle: question regarding the design Regards Martin^2 Hello, as was mentioned before, we have issue with current internal API and the stageuser-add --from-delete command. We discussed this today, and we did not find a nice way how to fix it, so we propose this (which is IMO the best solution): * stageuser-add --from-delete should be deprecated +1 * create new option for user-undel: used-undel --to-staged (or create new command) that will handle moving deleted users to staged area as --from-delete did. Make it new command please. Instead of stageuser-add and option --from-delete, which work totally different, the command user-undel does similar operation than stage-user --from-delete, it just uses different container. NACK on stuffing everything into a single command just because it does something similar. How about making it a 'stageuser-undel'? The 'user-undel' moves preserved user to active, so the 'stageuser-undel' would move preserved to staged. The action is similar, but has slightly different specifics (which attributes are preserved etc.), and for me the 'stageuser-undel' feels more natural than 'user-undel --to-staged' since it's basically the same as there is 'stageuser-add' for creating a staged user, not 'user-add --to-staged'. It would be in the same style as all the other commands concerning operations with users in staged container. Well, user-undel is the opposite of user-del, and stageuser-undel should be the opposite of stageuser-del. The stageuser-undel you are suggesting is not. Also I'm not sure if we want to (always) remove the deleted user once a staged user is created from it, but -undel behaves like that. I don't think the command should be limited to deleted users only. Active and deleted users share the same namespace, so it is an arbitrary limitation. preserved users has been valid active user. In that sense active/preserved are managed by a same set of CLI (user-find,user-del,user-show) because a preserved user is a 'user'. So I would vote for continuing with a 'user-*' commands and use 'user-undel --to-stage'. But then if we will make any incompatible change between user-undel and user-undel --to-stage we may hit this issue again. I agree with Honza, this should be a separate command. Martin2 I think that what we are looking for is the opposite of stageuser-activate. So maybe user-stage? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged
On 08/05/2015 11:27 AM, Martin Basti wrote: - Original Message - From: thierry bordaz tbor...@redhat.com To: Jan Cholasta jchol...@redhat.com Cc: freeipa-devel@redhat.com Sent: Monday, August 3, 2015 5:34:02 PM Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged On 07/28/2015 12:34 PM, Jan Cholasta wrote: Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): Dne 27.7.2015 v 17:59 Martin Basti napsal(a): On 23/07/15 14:43, Martin Basti wrote: Hello, I tried to fix #5145 and I partially succeeded. However, I cannot fix this part of ticket, where user is prompted to write name and surname. $ ipa stageuser-add tuser --from-delete First name: this will be ignored Last name: this will be also ignored Added stage user tuser As the first name and last name are mandatory attributes of stageuser-add command, but they are not needed by when the --from-delete option is used. I would like to ask how to fix this issue, IMO this will be huge hack in internal API. Or should we just document this bug as known issue (thierry wrote that this is not use case that should be used often)? The best solution would be separate command, but this idea was rejected in thread [Freeipa-devel] User life cycle: question regarding the design Regards Martin^2 Hello, as was mentioned before, we have issue with current internal API and the stageuser-add --from-delete command. We discussed this today, and we did not find a nice way how to fix it, so we propose this (which is IMO the best solution): * stageuser-add --from-delete should be deprecated +1 * create new option for user-undel: used-undel --to-staged (or create new command) that will handle moving deleted users to staged area as --from-delete did. Make it new command please. Instead of stageuser-add and option --from-delete, which work totally different, the command user-undel does similar operation than stage-user --from-delete, it just uses different container. NACK on stuffing everything into a single command just because it does something similar. How about making it a 'stageuser-undel'? The 'user-undel' moves preserved user to active, so the 'stageuser-undel' would move preserved to staged. The action is similar, but has slightly different specifics (which attributes are preserved etc.), and for me the 'stageuser-undel' feels more natural than 'user-undel --to-staged' since it's basically the same as there is 'stageuser-add' for creating a staged user, not 'user-add --to-staged'. It would be in the same style as all the other commands concerning operations with users in staged container. Well, user-undel is the opposite of user-del, and stageuser-undel should be the opposite of stageuser-del. The stageuser-undel you are suggesting is not. Also I'm not sure if we want to (always) remove the deleted user once a staged user is created from it, but -undel behaves like that. I don't think the command should be limited to deleted users only. Active and deleted users share the same namespace, so it is an arbitrary limitation. preserved users has been valid active user. In that sense active/preserved are managed by a same set of CLI (user-find,user-del,user-show) because a preserved user is a 'user'. So I would vote for continuing with a 'user-*' commands and use 'user-undel --to-stage'. But then if we will make any incompatible change between user-undel and user-undel --to-stage we may hit this issue again. I agree with Honza, this should be a separate command. What do you mean 'incompatible change' ? --to-stage option would only select a different container that the 'Active' one ? thanks thierry Martin2 I think that what we are looking for is the opposite of stageuser-activate. So maybe user-stage? -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged
Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): On 08/05/2015 11:27 AM, Martin Basti wrote: - Original Message - From: thierry bordaz tbor...@redhat.com To: Jan Cholasta jchol...@redhat.com Cc: freeipa-devel@redhat.com Sent: Monday, August 3, 2015 5:34:02 PM Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged On 07/28/2015 12:34 PM, Jan Cholasta wrote: Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): Dne 27.7.2015 v 17:59 Martin Basti napsal(a): On 23/07/15 14:43, Martin Basti wrote: Hello, I tried to fix #5145 and I partially succeeded. However, I cannot fix this part of ticket, where user is prompted to write name and surname. $ ipa stageuser-add tuser --from-delete First name: this will be ignored Last name: this will be also ignored Added stage user tuser As the first name and last name are mandatory attributes of stageuser-add command, but they are not needed by when the --from-delete option is used. I would like to ask how to fix this issue, IMO this will be huge hack in internal API. Or should we just document this bug as known issue (thierry wrote that this is not use case that should be used often)? The best solution would be separate command, but this idea was rejected in thread [Freeipa-devel] User life cycle: question regarding the design Regards Martin^2 Hello, as was mentioned before, we have issue with current internal API and the stageuser-add --from-delete command. We discussed this today, and we did not find a nice way how to fix it, so we propose this (which is IMO the best solution): * stageuser-add --from-delete should be deprecated +1 * create new option for user-undel: used-undel --to-staged (or create new command) that will handle moving deleted users to staged area as --from-delete did. Make it new command please. Instead of stageuser-add and option --from-delete, which work totally different, the command user-undel does similar operation than stage-user --from-delete, it just uses different container. NACK on stuffing everything into a single command just because it does something similar. How about making it a 'stageuser-undel'? The 'user-undel' moves preserved user to active, so the 'stageuser-undel' would move preserved to staged. The action is similar, but has slightly different specifics (which attributes are preserved etc.), and for me the 'stageuser-undel' feels more natural than 'user-undel --to-staged' since it's basically the same as there is 'stageuser-add' for creating a staged user, not 'user-add --to-staged'. It would be in the same style as all the other commands concerning operations with users in staged container. Well, user-undel is the opposite of user-del, and stageuser-undel should be the opposite of stageuser-del. The stageuser-undel you are suggesting is not. Also I'm not sure if we want to (always) remove the deleted user once a staged user is created from it, but -undel behaves like that. I don't think the command should be limited to deleted users only. Active and deleted users share the same namespace, so it is an arbitrary limitation. preserved users has been valid active user. In that sense active/preserved are managed by a same set of CLI (user-find,user-del,user-show) because a preserved user is a 'user'. So I would vote for continuing with a 'user-*' commands and use 'user-undel --to-stage'. But then if we will make any incompatible change between user-undel and user-undel --to-stage we may hit this issue again. I agree with Honza, this should be a separate command. What do you mean 'incompatible change' ? --to-stage option would only select a different container that the 'Active' one ? That's not sufficient. The command should do the reverse of stageuser-activate, which is ADD and DELETE, possibly with some modifications of the entry between them, not MODRDN like user-undel does. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] 0032 Fix otptoken-remove-managedby command summary
On 08/05/2015 07:51 AM, Fraser Tweedale wrote: Small doc fix. Cheers, Fraser ACK, thanks for catching this. Pushed to: master: e28a45072004d93ced9bf81b3810fbd2652664b5 ipa-4-2: dc0745650a0172bb66350fb453ec4285e31a32ad Tomas -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged
On 08/05/2015 12:13 PM, Jan Cholasta wrote: Dne 5.8.2015 v 11:55 thierry bordaz napsal(a): On 08/05/2015 11:27 AM, Martin Basti wrote: - Original Message - From: thierry bordaz tbor...@redhat.com To: Jan Cholasta jchol...@redhat.com Cc: freeipa-devel@redhat.com Sent: Monday, August 3, 2015 5:34:02 PM Subject: Re: [Freeipa-devel] Replace stageuser-add --from-delete with user-undel --to-staged On 07/28/2015 12:34 PM, Jan Cholasta wrote: Dne 28.7.2015 v 11:36 Lenka Doudova napsal(a): Dne 28.7.2015 v 11:27 Jan Cholasta napsal(a): Dne 27.7.2015 v 17:59 Martin Basti napsal(a): On 23/07/15 14:43, Martin Basti wrote: Hello, I tried to fix #5145 and I partially succeeded. However, I cannot fix this part of ticket, where user is prompted to write name and surname. $ ipa stageuser-add tuser --from-delete First name: this will be ignored Last name: this will be also ignored Added stage user tuser As the first name and last name are mandatory attributes of stageuser-add command, but they are not needed by when the --from-delete option is used. I would like to ask how to fix this issue, IMO this will be huge hack in internal API. Or should we just document this bug as known issue (thierry wrote that this is not use case that should be used often)? The best solution would be separate command, but this idea was rejected in thread [Freeipa-devel] User life cycle: question regarding the design Regards Martin^2 Hello, as was mentioned before, we have issue with current internal API and the stageuser-add --from-delete command. We discussed this today, and we did not find a nice way how to fix it, so we propose this (which is IMO the best solution): * stageuser-add --from-delete should be deprecated +1 * create new option for user-undel: used-undel --to-staged (or create new command) that will handle moving deleted users to staged area as --from-delete did. Make it new command please. Instead of stageuser-add and option --from-delete, which work totally different, the command user-undel does similar operation than stage-user --from-delete, it just uses different container. NACK on stuffing everything into a single command just because it does something similar. How about making it a 'stageuser-undel'? The 'user-undel' moves preserved user to active, so the 'stageuser-undel' would move preserved to staged. The action is similar, but has slightly different specifics (which attributes are preserved etc.), and for me the 'stageuser-undel' feels more natural than 'user-undel --to-staged' since it's basically the same as there is 'stageuser-add' for creating a staged user, not 'user-add --to-staged'. It would be in the same style as all the other commands concerning operations with users in staged container. Well, user-undel is the opposite of user-del, and stageuser-undel should be the opposite of stageuser-del. The stageuser-undel you are suggesting is not. Also I'm not sure if we want to (always) remove the deleted user once a staged user is created from it, but -undel behaves like that. I don't think the command should be limited to deleted users only. Active and deleted users share the same namespace, so it is an arbitrary limitation. preserved users has been valid active user. In that sense active/preserved are managed by a same set of CLI (user-find,user-del,user-show) because a preserved user is a 'user'. So I would vote for continuing with a 'user-*' commands and use 'user-undel --to-stage'. But then if we will make any incompatible change between user-undel and user-undel --to-stage we may hit this issue again. I agree with Honza, this should be a separate command. What do you mean 'incompatible change' ? --to-stage option would only select a different container that the 'Active' one ? That's not sufficient. The command should do the reverse of stageuser-activate, which is ADD and DELETE, possibly with some modifications of the entry between them, not MODRDN like user-undel does. That is a good point. Do we need to modify anything from a deleted entry to a add it in the stage container. Already delete entry have been purged of several values (password, krb keys, membership,..) do you think of other attributes to remove ? IIRC the use case is a support engineer who activated too early an entry. So you are right he wants to unactivate it. A question is does the unactivation requires more modifications than the one did by 'user-del --preserve'. Note that we can not retrieve the attribute values when the entry was activated from stage. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Exporting users access formulars
On 08/04/2015 03:13 PM, Florian Crouzat wrote: Hey, For security reason (mostly PCI-DSS) I have to print and sign-off access formular for every users, and also to maintain these formulars in time which means that every time I add a host to a hostgroup for example, I should reprint all access formulars for users with access to this hostgroup... I was wondering if it was possible to develop a feature that would allow one to select a user(s) from GUI and generate a csv/pdf/whatever file with all direct and indirect memberships/access for HBAC, groups and sudo-rule for the selected user(s). Maybe a first step would be to script something around ipa CLI commands (not sure if possible to dig into HBAC and groups from CLI though). What are your thoughts on such need, am I the only one wanting to export my users privileges directly from the software managing these privileges ? Regards, Florian I'd recommend building a script to generate such a report, I'm not really sure it's a feature that would fit directly into the core at this state. You can access IPA's API directly using Python, which can be leveraged to generate a report using a suitable Python library, such as reportlab. Using the API you will get access to all the information available to you via the ipa command line tool. Examples of using Python API are available on the net, for example here's one user's submission which landed on the list some time ago: https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py API can be easily inspected in 4.2 using our new API browser: https://fedorahosted.org/freeipa/ticket/3129 If you're on a older release, adding -vv flag to any ipa command will do the job as well. HTH, Tomas -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Exporting users access formulars
On 08/05/2015 12:53 PM, Tomas Babej wrote: On 08/04/2015 03:13 PM, Florian Crouzat wrote: Hey, For security reason (mostly PCI-DSS) I have to print and sign-off access formular for every users, and also to maintain these formulars in time which means that every time I add a host to a hostgroup for example, I should reprint all access formulars for users with access to this hostgroup... I was wondering if it was possible to develop a feature that would allow one to select a user(s) from GUI and generate a csv/pdf/whatever file with all direct and indirect memberships/access for HBAC, groups and sudo-rule for the selected user(s). Maybe a first step would be to script something around ipa CLI commands (not sure if possible to dig into HBAC and groups from CLI though). What are your thoughts on such need, am I the only one wanting to export my users privileges directly from the software managing these privileges ? Regards, Florian I'd recommend building a script to generate such a report, I'm not really sure it's a feature that would fit directly into the core at this state. You can access IPA's API directly using Python, which can be leveraged to generate a report using a suitable Python library, such as reportlab. Using the API you will get access to all the information available to you via the ipa command line tool. Examples of using Python API are available on the net, for example here's one user's submission which landed on the list some time ago: https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py API can be easily inspected in 4.2 using our new API browser: https://fedorahosted.org/freeipa/ticket/3129 If you're on a older release, adding -vv flag to any ipa command will do the job as well. HTH, Tomas ipa user-show USER --all should show user and all group memberships, including special roles or permission in the RBAC. I am not sure about finding respective HBAC or SUDO rules, hbac-find or sudorule-find does not offer searching by user. I am afraid that for current versions, raw ldapsearch would need to be used. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Exporting users access formulars
On 08/05/2015 02:32 PM, Martin Kosek wrote: On 08/05/2015 12:53 PM, Tomas Babej wrote: On 08/04/2015 03:13 PM, Florian Crouzat wrote: Hey, For security reason (mostly PCI-DSS) I have to print and sign-off access formular for every users, and also to maintain these formulars in time which means that every time I add a host to a hostgroup for example, I should reprint all access formulars for users with access to this hostgroup... I was wondering if it was possible to develop a feature that would allow one to select a user(s) from GUI and generate a csv/pdf/whatever file with all direct and indirect memberships/access for HBAC, groups and sudo-rule for the selected user(s). Maybe a first step would be to script something around ipa CLI commands (not sure if possible to dig into HBAC and groups from CLI though). What are your thoughts on such need, am I the only one wanting to export my users privileges directly from the software managing these privileges ? Regards, Florian I'd recommend building a script to generate such a report, I'm not really sure it's a feature that would fit directly into the core at this state. You can access IPA's API directly using Python, which can be leveraged to generate a report using a suitable Python library, such as reportlab. Using the API you will get access to all the information available to you via the ipa command line tool. Examples of using Python API are available on the net, for example here's one user's submission which landed on the list some time ago: https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py API can be easily inspected in 4.2 using our new API browser: https://fedorahosted.org/freeipa/ticket/3129 If you're on a older release, adding -vv flag to any ipa command will do the job as well. HTH, Tomas ipa user-show USER --all should show user and all group memberships, including special roles or permission in the RBAC. I am not sure about finding respective HBAC or SUDO rules, hbac-find or sudorule-find does not offer searching by user. I am afraid that for current versions, raw ldapsearch would need to be used. I wrote a shell script (bash+awk) that do the job by using ipa user-show FOO and looping over each hbac (ipa hbacrule-show), sudo (ipa sudorule-show), and groups (ipa group-show) ... But it's ugly and really dependant on the output of these commands. As Tomas said, there is an API and I could probably do it from python but I'm no dev so I'll stick my poor's man script for the moment... I was just hoping that this need would meet other people needs and hopefully justify the addition of a button in the GUI to export all theses informations automagically... But I know it's a lot to ask, and definitely not the top priority. Florian -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] Exporting users access formulars
On 08/05/2015 02:39 PM, Florian Crouzat wrote: On 08/05/2015 02:32 PM, Martin Kosek wrote: On 08/05/2015 12:53 PM, Tomas Babej wrote: On 08/04/2015 03:13 PM, Florian Crouzat wrote: Hey, For security reason (mostly PCI-DSS) I have to print and sign-off access formular for every users, and also to maintain these formulars in time which means that every time I add a host to a hostgroup for example, I should reprint all access formulars for users with access to this hostgroup... I was wondering if it was possible to develop a feature that would allow one to select a user(s) from GUI and generate a csv/pdf/whatever file with all direct and indirect memberships/access for HBAC, groups and sudo-rule for the selected user(s). Maybe a first step would be to script something around ipa CLI commands (not sure if possible to dig into HBAC and groups from CLI though). What are your thoughts on such need, am I the only one wanting to export my users privileges directly from the software managing these privileges ? Regards, Florian I'd recommend building a script to generate such a report, I'm not really sure it's a feature that would fit directly into the core at this state. You can access IPA's API directly using Python, which can be leveraged to generate a report using a suitable Python library, such as reportlab. Using the API you will get access to all the information available to you via the ipa command line tool. Examples of using Python API are available on the net, for example here's one user's submission which landed on the list some time ago: https://github.com/firemanxbr/freeipa-tools/blob/master/freeipa.py API can be easily inspected in 4.2 using our new API browser: https://fedorahosted.org/freeipa/ticket/3129 If you're on a older release, adding -vv flag to any ipa command will do the job as well. HTH, Tomas ipa user-show USER --all should show user and all group memberships, including special roles or permission in the RBAC. I am not sure about finding respective HBAC or SUDO rules, hbac-find or sudorule-find does not offer searching by user. I am afraid that for current versions, raw ldapsearch would need to be used. I wrote a shell script (bash+awk) that do the job by using ipa user-show FOO and looping over each hbac (ipa hbacrule-show), sudo (ipa sudorule-show), and groups (ipa group-show) ... But it's ugly and really dependant on the output of these commands. Right, this is not ideal and you may hit speed problems when you have hundreds of SUDO or HBAC rules. So as I said, it may be better to do ldapsearch with proper filter to find out all SUDO/HBAC rules for given user, get the name of such rule and if show it with show command if needed. As Tomas said, there is an API and I could probably do it from python but I'm no dev so I'll stick my poor's man script for the moment... I was just hoping that this need would meet other people needs and hopefully justify the addition of a button in the GUI to export all theses informations automagically... But I know it's a lot to ask, and definitely not the top priority. Florian -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] cert profiles - test plan + patches
Hi list,
I'm sending the test plan [1] for certificate profiles and preliminary
patches for it.
The plan covers basic CRUD test and some corner cases. I'm open to more
suggestions.
More complicated tests involving certificate profiles will require the
code (and tests)
for CA ACLs merged, so it's not there at the moment.
There are some unfinished test cases in places I wasn't sure what the
result should be.
We need to iterate through these to fix it.
[1]: http://www.freeipa.org/page/V4/Certificate_Profiles/Test_Plan
Cheers,
Milan
From 67a27ee0f032fe1ba6da0a1a24f52c0e1d0960d1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Milan=20Kub=C3=ADk?= mku...@redhat.com
Date: Wed, 10 Jun 2015 14:48:33 +0200
Subject: [PATCH 1/2] ipatests: Add Certprofile tracker class implementation
https://fedorahosted.org/freeipa/ticket/57
---
ipatests/test_xmlrpc/test_certprofile_plugin.py | 143
1 file changed, 143 insertions(+)
create mode 100644 ipatests/test_xmlrpc/test_certprofile_plugin.py
diff --git a/ipatests/test_xmlrpc/test_certprofile_plugin.py b/ipatests/test_xmlrpc/test_certprofile_plugin.py
new file mode 100644
index ..010da86b20f33d62af818d2030106921be7979ac
--- /dev/null
+++ b/ipatests/test_xmlrpc/test_certprofile_plugin.py
@@ -0,0 +1,143 @@
+# -*- coding: utf-8 -*-
+#
+# Copyright (C) 2015 FreeIPA Contributors see COPYING for license
+#
+
+
+Test the `ipalib.plugins.certprofile` module.
+
+
+import os
+import tempfile
+import base64
+
+import pytest
+
+from ipapython import ipautil
+from ipalib import api, errors, x509
+from ipapython.dn import DN
+from ipatests.test_xmlrpc.ldaptracker import Tracker
+from ipatests.test_xmlrpc.xmlrpc_test import (XMLRPC_test,
+fuzzy_uuid, fuzzy_digits, fuzzy_hash, fuzzy_date, fuzzy_issuer, # noqa
+fuzzy_hex, raises_exact) # noqa
+from ipatests.test_xmlrpc import objectclasses
+from ipatests.util import assert_deepequal
+
+
+class CertprofileTracker(Tracker):
+Tracker class for certprofile plugin.
+
+
+retrieve_keys = {
+'dn', 'cn', 'description', 'ipacertprofilestoreissued'
+}
+retrieve_all_keys = retrieve_keys | {'objectclass'}
+create_keys = retrieve_keys | {'objectclass'}
+update_keys = retrieve_keys - {'dn'}
+managedby_keys = retrieve_keys
+allowedto_keys = retrieve_keys
+
+def __init__(self, name, store=False, desc='dummy description',
+ profile=None, default_version=None):
+super(CertprofileTracker, self).__init__(
+default_version=default_version
+)
+
+self.store = store
+self.description = desc
+self._profile_path = profile
+
+self.dn = DN(('cn', name), 'cn=certprofiles', 'cn=ca',
+ self.api.env.basedn)
+
+@property
+def profile(self):
+if not self._profile_path:
+return None
+
+if os.path.isabs(self._profile_path):
+path = self._profile_path
+else:
+path = os.path.join(os.path.dirname(__file__),
+self._profile_path)
+
+with open(path, 'r') as f:
+content = f.read()
+return unicode(content)
+
+def make_create_command(self, force=True):
+if not self.profile:
+raise RuntimeError('Tracker object without path to profile '
+ 'cannot be used to create profile entry.')
+
+return self.make_command('certprofile_import', self.name,
+ description=self.description,
+ ipacertprofilestoreissued=self.store,
+ file=self.profile)
+
+def check_create(self, result):
+assert_deepequal(dict(
+value=self.name,
+summary=u'Imported profile {}'.format(self.name),
+result=dict(self.filter_attrs(self.create_keys))
+), result)
+
+def track_create(self):
+self.attrs = dict(
+dn=unicode(self.dn),
+cn=[self.name],
+description=[self.description],
+ipacertprofilestoreissued=[unicode(self.store).upper()]
+)
+self.exists = True
+
+def make_delete_command(self):
+return self.make_command('certprofile_del', self.name)
+
+def check_delete(self, result):
+assert_deepequal(dict(
+value=[self.name], # correctly a list?
+summary=u'Deleted profile {}'.format(self.name),
+result=dict(failed=[]),
+), result)
+
+def make_retrieve_command(self, all=False, raw=False):
+return self.make_command('certprofile_show', self.name, all=all, raw=raw) # noqa
+
+def check_retrieve(self, result, all=False, raw=False):
+if all:
+expected = self.filter_attrs(self.retrieve_all_keys)
+else:
+expected = self.filter_attrs(self.retrieve_keys)
+
+assert_deepequal(dict(
+
Re: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work
On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: Hi, Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): I've been carrying these patches in my tree for a while, I think it is time to put them in master as they stand on their own. Simo. Patch 530: ACK Patch 531: ACK Patch 532: The methods should be static methods: @staticmethod def setOption(name, value): ... Care to explain why ? @staticmethod is not used anywhere else in that file. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH 0355] Fix incorrect type comparison in trust-fetch-domains
Hi,
Value needs to be unpacked from the list and converted before comparison.
https://fedorahosted.org/freeipa/ticket/5182
From dee59d971acb733c1dee06a61cc0d79ac2f4fdb7 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Wed, 5 Aug 2015 17:31:47 +0200
Subject: [PATCH] Fix incorrect type comparison in trust-fetch-domains
Value needs to be unpacked from the list and converted before comparison.
https://fedorahosted.org/freeipa/ticket/5182
---
ipalib/plugins/trust.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py
index 91ffaf7feadba0d180e0e95c54f7187cf71d0170..940e06a5ffa387c6cc18983d7b56f089f58a236e 100644
--- a/ipalib/plugins/trust.py
+++ b/ipalib/plugins/trust.py
@@ -1487,7 +1487,7 @@ class trust_fetch_domains(LDAPRetrieve):
result['truncated'] = False
# For one-way trust fetch over DBus. we don't get the list in this case.
-if trust['ipanttrustdirection'] TRUST_BIDIRECTIONAL != TRUST_BIDIRECTIONAL:
+if int(trust['ipanttrustdirection'][0]) != TRUST_BIDIRECTIONAL:
fetch_trusted_domains_over_dbus(self.api, self.log, keys[0])
result['summary'] = unicode(_('List of trust domains successfully refreshed. Use trustdomain-find command to list them.'))
return result
--
2.1.0
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH 0355] Fix incorrect type comparison in trust-fetch-domains
On Wed, 05 Aug 2015, Tomas Babej wrote: Hi, Value needs to be unpacked from the list and converted before comparison. https://fedorahosted.org/freeipa/ticket/5182 One more -- this is bug https://bugzilla.redhat.com/show_bug.cgi?id=1250190, I think. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] [PATCH] 0194 Fix selector of protocol for LSA RPC binding string
Hi, attached patch fixes a bug https://bugzilla.redhat.com/show_bug.cgi?id=1249455 details are in the commit message. -- / Alexander Bokovoy From 3e5edd4d8f334c053bf2e216d25b14f40590a7c4 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy aboko...@redhat.com Date: Wed, 5 Aug 2015 21:33:45 +0300 Subject: [PATCH] Fix selector of protocol for LSA RPC binding string For Windows Server 2012R2 and others which force SMB2 protocol use we have to specify right DCE RPC binding options. For using SMB1 protocol we have to omit specifying SMB2 protocol and anything else or otherwise SMB1 would be considered a pipe to connect to. This is by design of a binding string format. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1249455 diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index be6313e..f334eef 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -855,8 +855,8 @@ class TrustDomainInstance(object): We try NCACN_NP before NCACN_IP_TCP and use SMB2 before SMB1 or defaults. transports = (u'ncacn_np', u'ncacn_ip_tcp') -options = ( u'smb2', u'smb1', u'') -binding_template=lambda x,y,z: u'%s:%s[%s,print]' % (x, y, z) +options = ( u'smb2,print', u'print') +binding_template=lambda x,y,z: u'%s:%s[%s]' % (x, y, z) return [binding_template(t, remote_host, o) for t in transports for o in options] def retrieve_anonymously(self, remote_host, discover_srv=False, search_pdc=False): -- 2.4.3 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCHES] changes in preparation of replica promotion work
Dne 5.8.2015 v 17:24 Simo Sorce napsal(a): On Wed, 2015-08-05 at 08:20 +0200, Jan Cholasta wrote: Hi, Dne 31.7.2015 v 12:46 Simo Sorce napsal(a): I've been carrying these patches in my tree for a while, I think it is time to put them in master as they stand on their own. Simo. Patch 530: ACK Patch 531: ACK Patch 532: The methods should be static methods: @staticmethod def setOption(name, value): ... Care to explain why ? @staticmethod is not used anywhere else in that file. Because the methods do not use any instance or class state. They will of course work fine even if they are normal methods, but making them static methods is cleaner. -- Jan Cholasta -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
[Freeipa-devel] Installation issue on F23
Hi, Just FYI, the recent IPA installation issue on F23 has been fixed: https://bugzilla.redhat.com/show_bug.cgi?id=1250724 by installing a new TomcatJSS package: https://admin.fedoraproject.org/updates/tomcatjss-7.1.3-1.fc23 The PKI dependency on TomcatJSS will be updated in the following ticket: https://fedorahosted.org/pki/ticket/1542 Once this is completed, please update the IPA dependency on PKI. Thanks. -- Endi S. Dewata -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
