Re: [Freeipa-devel] [MAN] [PATCH] 0004 Fix phrasing in man page for stageuser.py
On 07/04/2015 02:03 PM, Jérôme Fenal wrote: > Hi all, > > A quick patch to the man page part of stageuser to avoid ambiguity in > the phrasing, spotted while translating the page. > > Regards, > > J. > > > Thanks, ACK. I will not push this patch to master until we branch off 4.2 development branch as it would disrupt already translated strings in the other languages. 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] [PATCHES 0252-0253, 268, 50 - 51] DNSSEC: allow to move DNSSEC key master to another IPA server
On 07/01/2015 12:47 PM, Petr Spacek wrote: > On 1.7.2015 12:35, Martin Basti wrote: >> On 30/06/15 22:09, Petr Spacek wrote: >>> On 30.6.2015 16:04, Martin Basti wrote: On 30/06/15 10:25, Martin Basti wrote: > On 29/06/15 15:16, Martin Basti wrote: >> On 25/06/15 13:46, Petr Spacek wrote: >>> On 17.6.2015 13:37, Martin Basti wrote: On 17/06/15 13:26, Petr Spacek wrote: > On 16.6.2015 15:40, Martin Basti wrote: >> On 05/06/15 12:54, Petr Spacek wrote: >>> On 20.5.2015 18:00, Martin Basti wrote: This patch allows to disable DNSSEC key master on IPA server, or replace current DNSSEC key master with another IPA server. Only for master branch. https://fedorahosted.org/freeipa/ticket/4657 Patches attached. >>> NACK. This happens on DNSSEC key master: >>> $ ipa-dns-install --disable-dnssec-master >>> >>> Do you want to disable current DNSSEC key master? [no]: yes >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> TypeError: sequence item 0: expected string, DNSName found >>>2015-06-05T10:52:35Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line >>> 733, in run_script >>> return_value = main_function() >>> >>> File "/sbin/ipa-dns-install", line 128, in main >>> dns_installer.disable_dnssec_master(options.unattended) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dns.py", >>> line >>> 112, >>> in disable_dnssec_master >>> ", ".join(dnssec_zones)) >>> >>> 2015-06-05T10:52:35Z DEBUG The ipa-dns-install command failed, >>> exception: >>> TypeError: sequence item 0: expected string, DNSName found >>> >> Updated patches attached. >> >> Due new installers, more changes were required. > Sorry, NACK, I'm not able to apply this patch set to current master > (69607250b9762a6c9b657dd31653b03d54a7b411). > Rebased patches attached. >>> NACK. >>> >>> >>> 0) ipa-dns-install --replace-dnssec-master always puts file into >>> /root/ipa-kasp.db. >>> >>> It would be better to put it into local working directory or >>> /var/lib/ipa (as >>> with replica files). >>> >>> >>> 1) I installed DNSSEC key master role on the vm-134 but DNSSEC services >>> were >>> not stopped by ipactl stop: >>> >>> [root@vm-134 review]# ipactl stop >>> Stopping ipa-otpd Service >>> Stopping httpd Service >>> Stopping ipa_memcached Service >>> Stopping kadmin Service >>> Stopping krb5kdc Service >>> Stopping Directory Service >>> ipa: INFO: The ipactl command was successful >>> >>> [root@vm-134 review]# ipactl start >>> Starting Directory Service >>> Starting krb5kdc Service >>> Starting kadmin Service >>> Starting named Service >>> Starting ipa_memcached Service >>> Starting httpd Service >>> Starting ipa-otpd Service >>> Starting ipa-ods-exporter Service >>> Starting ods-enforcerd Service >>> Starting ipa-dnskeysyncd Service >>> >>> Subsequent ipactl stop worked fine, only the first one is affected. >>> >>> >>> 2a) vm-134 was the original master. I ran this: >>> >>> [root@vm-134 review]# ipa-dns-install >>> --replace-dnssec-master=vm-090.abc.idm.lab.eng.brq.redhat.com >>> >>> ... and then attempted to install master to vm-059: >>> [root@vm-059 review]# ipa-dns-install --dnssec-master >>> >>> This command was accepted despite of missing --kasp-db option and wrong >>> replica name. >>> >>> It should error out and tell the user to run the command with --kasp-db >>> option. >>> >>> Even better, we could get rid of explicit replica name specification in >>> --replace-dnssec-master option and allow to run installation with >>> --kasp-db on >>> any replica as long as the kasp.db file is provided. >>> >>> >>> >>> 2b) Attempt to move DNSSEC key master from vm-134 to vm-090 *without* >>> specifying --kasp-db option was accepted. >>> >>> [root@vm-090 review]# ipa-dns-install --dnssec-master >>> >>> As in case (2a), it should print what user is supposed to do. >>> >>> I propose following text: >>> >>> Current DNSSEC key master is >>> being >>> moved to different server. >>> >>> You need to copy kasp.db file from >>> >>> and >>> run following command to complete the transition: >>> >>> # ipa-dns-install --dnssec-master --kasp-db=/path/to/the/copied/kasp.db >>> >>> >>> >>> 3) [root@vm-134 rev
Re: [Freeipa-devel] [PATCH] 892 webui: add mangedby tab to otptoken
On 07/03/2015 02:49 PM, Martin Babinsky wrote: > On 07/01/2015 06:59 PM, Petr Vobornik wrote: >> Added managedby_user tab to manage users who can manage the token. >> >> https://fedorahosted.org/freeipa/ticket/5003 >> >> Nathaniel, I could not reproduce the following part of the ticket: >> """ >> Careful interaction is required here. In the current code, this also >> creates a bug since all UI created tokens are owned but not managed. >> When users of these tokens are deleted, their self-created tokens are >> orphaned rather than deleted. >> >> Self-created tokens MUST be both self-owned AND self-managed. >> """ >> >> The self-created tokens which I created in Web UI as admin or normal >> user were in both cases managed by the same user who created them. >> >> > (Once again, this time also reply to the list) > > The patch itself does what it is supposed to. > > So ACK from me. > > However, I have found out that the token's manager is correctly set > *only* when it is directly created by the user that should own it. In > this case when the manager is not specified, the code works as expected > and fill in the logged-in user as manager. > > However, if e.g. admin creates a token for another user and does not set > him as the manager explicitly, the 'managedBy' attribute is not set. > Pushed to: master: b258bcee8337063259aa38b4387b9bb5721fb380 ipa-4-1: 5439e7a8fa46a8eab0d23689807a4894f20ecea7 -- 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] error handling in httpd.service and ipa-httpd-kdcproxy
Hello, I like to ask for your opinion regarding the pre-exec hook 'ipa-httpd-kdcproxy' in httpd.service. Alex has asked me to handle error cases like LDAP connection timeout more gracefully. At the moment any error causes the script to return a non-zero exit code. This breaks the service and apparently also offline RPM upgrades. How should I handle error cases? I can change httpd.service to simply ignore the exit code of ipa-httpd-kdcproxy. But that might lead to an invalid state. I could modify the script to catch connection errors and to disable kdcproxy in case of an error. The options are: 1) httpd.service ignores exit code of ipa-httpd-kdcproxy 2) ipa-httpd-kdcproxy removes kdcproxy config file in case of a connection error 3) 1 + 2 What do you think? Christian signature.asc Description: OpenPGP digital signature -- 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] CA ACL enforcement when authenticated as root
On Fri, Jul 03, 2015 at 10:53:54AM -0400, Simo Sorce wrote: > On Sat, 2015-07-04 at 00:32 +1000, Fraser Tweedale wrote: > > On Wed, Jul 01, 2015 at 04:06:11PM +1000, Fraser Tweedale wrote: > > > Hi everyone, > > > > > > With the addition of CA ACLs, there are now two levels of > > > permissions checked by the `cert-request' command: > > > > > > - LDAP permission checks. This check is performed against the bind > > > principal; `admin' has permission to write the userCertificate > > > attribute of any principal. > > > > > > - CA ACLs: whether issuing a certificate to a particular principal > > > using a particular profile is permitted. This check is performed > > > against the principal for whom the certificate is being requested, > > > which might or might not be the bind principal. > > > > > > Some questions came up after the recent GSS IdM test day: > > > > > > 1) It was requested to add a caacl rule to allow `admin' to issue a > > > certificite for itself via any profile. This is straightforward, > > > but what are the use cases for the `admin' account issuing > > > certificates to itself? > > > > > > 2) When `admin' (as bind principal) requests a certificate for > > > another principal and there is no CA ACL allowing issuance of a > > > certificate for that principal+profile, the request is currently > > > rejected. Should we change the behaviour to allow `admin' to issue > > > a certificate to any principal, using any profile? (This would be > > > accomplished by skipping CA ACL checks in `cert-request' when > > > authenticated as admin.) > > > > > > (Note, if the answer to (2) is "yes", (1) is subsumed.) > > There should be a group (of which admin will be part of by default) that > can do this. It is needed to be able to provide certificates to hosts > that respond to multiple names, wildcard names and so on. > > So, yes. > > Simo. > Thanks; good idea. I filed a ticket: https://fedorahosted.org/freeipa/ticket/5099 > > > > Cheers, > > > Fraser > > > > > > -- > > > 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 > > > > Ping. Anyone got feels about this? Otherwise a patch will appear > > implementing (2), because that is a smaller patch :) > > > > > -- > 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
