From rcritten at redhat.com Mon Apr 1 19:52:00 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Apr 2013 15:52:00 -0400 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <511B8632.7000709@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> Message-ID: <5159E560.6030603@redhat.com> Tomas Babej wrote: > On 02/12/2013 06:23 PM, Simo Sorce wrote: >> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> This patch adds a check for krbprincipalexpiration attribute to >>>> pre_bind operation >>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >>>> denied and LDAP_INVALID_CREDENTIALS along with the error message is >>>> sent back to the client. Since krbprincipalexpiration attribute is >>> not >>>> mandatory, if there is no value set, the check is passed. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3305 >> >> Comments inline. >>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>> goto done; >>> } >>> + /* check the krbPrincipalExpiration attribute is present */ >>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>> &attr); >>> + if (!ret) { >> ret is not a boolean so probably better ti use (ret != 0) >> >>> + /* if it is, check whether the principal has not expired */ >>> + >>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>> + "krbprincipalexpiration"); >>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>> + >>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", &expire_tm)){ >> style issue missing space between ) and { >> >>> + expire_time = mktime(&expire_tm); >>> + /* this might have overflown on 32-bit system */ >> This comment does not help to point out what you want to put in >> evidence. >> if there is an overflow what is the consequence ? Or does it mean the >> next condition is taking that into account ? > Yeah, this was rather ill-worded. Replaced by a rather verbose > comment that hopefully clears things out. >> >>> + if (current_time > expire_time && expire_time > 0){ >> style issue missing space between ) and { >> >>> + LOG_FATAL("kerberos principal has expired in user >>> entry: %s\n", >>> + dn); >> I think a better phrasing would be: "The kerberos principal on %s is >> expired\n" >> >>> + errMesg = "Kerberos principal has expired."; >> s/has/is/ >> >> The rest looks good to me. >> >> Simo. > Styling issues fixed and updated patch attached :) Small nit, the expiration error should probably use 'in' not 'on'. I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This implies that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM is probably more correct here. It is what we return on other policy failures. rob From rcritten at redhat.com Mon Apr 1 20:01:14 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Apr 2013 16:01:14 -0400 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <5124AA2F.1040009@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> Message-ID: <5159E78A.9090902@redhat.com> Tomas Babej wrote: > On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> The checks make sure that SELinux is: >>>>>> - installed and enabled (on server install) >>>>>> - installed and enabled OR not installed (on client install) >>>>>> >>>>>> Please note that client installs with SELinux not installed are >>>>>> allowed since freeipa-client package has no dependency on SELinux. >>>>>> (any objections to this approach?) >>>>>> >>>>>> The (unsupported) option --allow-no-selinux has been added. It can >>>>>> used to bypass the checks. >>>>>> >>>>>> Parts of platform-dependant code were refactored to use newly added >>>>>> is_selinux_enabled() function. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>> >>>>>> Tomas >>>>> >>>>> I forgot to edit the man pages. Thanks Rob! >>>>> >>>>> Updated patch attached. >>>>> >>>>> Tomas >>>> >>>> After a bit of off-line discussion I don't think we're quite ready yet >>>> to require SELinux by default on client installations (even with a >>>> flag to work around it). The feeling is this would be disruptive to >>>> existing automation. >>>> >>>> Can you still do the check but not enforce it, simply display a big >>>> warning if SELinux is disabled? >>>> >>>> rob >>>> >>> >>> Sure, here is the updated patch. >>> >>> I edited the commit message, RFE description and man pages according to >>> the new behaviour. >>> >>> Tomas >> >> The patch looks good, I'm just wondering about one thing. The default >> value for is_selinux_enabled() is True in ipapython/services.py.in. >> >> So this means that any non-Red Hat/non-Fedora system, by default, is >> going to assume that SELinux is enabled. >> >> My hesitation has to when we call check_selinux_status(). It may >> incorrectly error out. I suspect that the user would have to work >> around this using --allow-selinux-disabled but this wouldn't make a >> lot of sense since they actually do have SELinux disabled. > > Yes, you're right. And the error message would not even be helpful since > it would tell the user to install policycoreutils package. This would be > the > case both with server and client installs when selinux would not be > installed > at all. > >> What do you think? >> >> rob > > Well we have 2 options as I see it: > > 1.) We can either return None as default, and add checks to > check_selinux_status, restore_context and install scripts that would > ensure that we behave properly when is_selinux_enabled() is not > implemented. > > 2.) We can remove the default value, since it would cause forementioned > crash and add comment that this function needs to be implemented > properly in every platform file. > > I'm probably for option 2, there's no need to clutter the code with checks > that compensate for improper platform file implementations. > > Tomas I agree with you on option 2. rob From rcritten at redhat.com Mon Apr 1 21:37:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Apr 2013 17:37:47 -0400 Subject: [Freeipa-devel] [PATCH] 0119 Switch client to JSON-RPC In-Reply-To: <511CF3D3.80107@redhat.com> References: <50F53F2B.4020406@redhat.com> <511CF3D3.80107@redhat.com> Message-ID: <5159FE2B.306@redhat.com> Petr Viktorin wrote: > On 01/15/2013 12:36 PM, Petr Viktorin wrote: >> I meant to hold this patch a while longer to let it mature, but from >> what Brian Smith asked on the user list it seems it could help him. >> >> Design: http://freeipa.org/page/V3/JSON-RPC >> Ticket: https://fedorahosted.org/freeipa/ticket/3299 >> >> See the design page for what the patch does. >> >> >> As much as I've tried to avoid them, the code includes some workarounds: >> It extends xmlrpclib to also support JSON. This is rather intrusive, but >> to not do that I'd need to write a parallel stack for JSON, without the >> help of a standard library. >> The registration of either jsonclient or xmlclient as "rpcclient" in the >> API also needs a bit of magic, since the framework requires the class >> name to match the attribute. >> >> >> To prevent backwards compatibility problems, we need to ensure that all >> official JSON clients send the API version, so this patch should be >> applied after my patches 0104-0106. >> > > Updating to current master. Please reverse this change in ipalib/rpc.py: @@ -665,8 +788,6 @@ class xmlclient(Connectible): except Exception, e: if not fallback: raise - else: - self.log.info('Connection to %s failed with %s', url, e) serverproxy = None This logs connection errors when the client fails over to another server. The changes look really good. The show stopper is that using jsonrpc doesn't create a session key. I noticed that xmlrpc_uri is hardcoded into ipalib/session.py but it appears the issue is deeper than that. I did some basic testing with an old client against this server and things seem to be fine. I get the same results running the unit tests with both rpclib settings. rob From rrelyea at redhat.com Tue Apr 2 00:14:10 2013 From: rrelyea at redhat.com (Robert Relyea) Date: Mon, 01 Apr 2013 17:14:10 -0700 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <5155A7EF.50304@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> <515581A8.7040902@redhat.com> <5155A7EF.50304@redhat.com> Message-ID: <515A22D2.9060106@REDHAT.COM> On 03/29/2013 07:40 AM, John Dennis wrote: > On 03/29/2013 07:57 AM, Petr Viktorin wrote: >> On 03/27/2013 04:40 PM, John Dennis wrote: >>> On 03/27/2013 11:23 AM, Petr Viktorin wrote: >>>> I don't want to check the subject because this RFE was prompted by >>>> IPA's >>>> normal CA rejecting valid wildcart certs. Is there a reasonable way to >>>> ask NSS if it will trust the cert? >>> >>> Yes. NSS provides a variety of tools to test validation. >>> >>> Going just on memory here, our current version of python-nss has a >>> simple call to test validation. Sometime in the last year I added a >>> fair >>> amount of new support for certificate validation including getting back >>> diagnostic information for validation failures, however if I recall >>> correctly the extended functionality in python-nss has not been >>> released >>> yet. >> >> Does the new code include downloading and importing CRLs? > > Cert verification is a complex topic. This is further exacerbated by > the introduction of PKIX. My understanding is NSS had "classic" > verification code and later introduced PKIX. There has been an > evolution between classic verification and PKIX. This is outside my > domain of expertise. How and when CRL's are loaded in NSS is not > something I can give advice on, especially in an area undergoing change. > > I'm going to have to defer to an expert in this area, Bob Relyea, I've > CC'ed him on this email. It's hard to get the context in the middle, and and John had noted, NSS is transitioning from the old Cert_Verify interface to the new PKIX_ code. I'll answer the question for the traditional CERTVerify code, which is the only you get in SSL by default, and the one most people still use: No, CRLs are not downloaded and imported automatically, but if you download and import CRL's, NSS will use them. There's an installable PKCS #11 module which can be configured to download and install CRLs, then provide them to NSS. It's call mod_revocator. The expected revocation strategy NSS uses is OCSP, and you can turn on automatic OCSP fetching. > > Bob, to put this in context [1] the functionality in python-nss being > discussed is the binding of the CERT_VerifyCertificate() function, > something I added recently. Now the question arises as to how CRL's > are meant to play into the verification process. Can you please > explain how NSS expects this to be done? Pointers to existing > documentation and code examples would also be helpful. There's a separate CERT_ImportCRL() which will import the CRL into the database. mod_revocator() can also be used to do the fetching for you, Matthew has examples on how various servers set them up (I believe the only NSS set up is installing the module in your secmod.db/pkcs11.txt with modutil. > > It would also be helpful to understand the PKIX roadmap and how this > might affect coding decisions at the API level. the PKIX interface is available now, and is actually used by Chrome (for all certs) and Firefox (for ev processing). Firefox is in the process of moving to libpkix for everything. There is an environment variable you can set (I don't remember it specifically, but I could look it up for you if you want) that will cause the transitional CERT_VerifyCertificate() interface to use the libpkix engine, but it keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert fetching).. With libpkix, the revocation options are quite broad and complexed. We really expect people would use a set of preconfigured policies, though libpkix API allows for quite some variance. It would take me some time to dig up all the descriptions, but I can if you want them. > > [1] Some additional context, the original motivation for exposing NSS > cert verification to IPA was to solve the following problem. If > someone wants to make the IPA CA a sub-CA (as opposed to a self-signed > CA) we want to validate the externally provided CA cert *before* > proceeding with the IPA installation. This is because if the CA cert > is invalid everything will hugely blow-up (because we use the CA cert > to sign all the certs issued in IPA, especially those used to validate > cooperating components/agents, if those certs do not work nothing in > IPA works). In addition to this narrow goal we in general want to be > able to perform cert verification correctly in other contexts as well > so the extent to which you can educate us in general on this topic > will be appreciated. OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless you specifically need some of the advanced libpkix features. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4521 bytes Desc: S/MIME Cryptographic Signature URL: From tbabej at redhat.com Tue Apr 2 08:05:06 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Apr 2013 10:05:06 +0200 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <5159E78A.9090902@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> <5159E78A.9090902@redhat.com> Message-ID: <515A9132.6030404@redhat.com> On Mon 01 Apr 2013 10:01:14 PM CEST, Rob Crittenden wrote: > Tomas Babej wrote: >> On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The checks make sure that SELinux is: >>>>>>> - installed and enabled (on server install) >>>>>>> - installed and enabled OR not installed (on client install) >>>>>>> >>>>>>> Please note that client installs with SELinux not installed are >>>>>>> allowed since freeipa-client package has no dependency on SELinux. >>>>>>> (any objections to this approach?) >>>>>>> >>>>>>> The (unsupported) option --allow-no-selinux has been added. It can >>>>>>> used to bypass the checks. >>>>>>> >>>>>>> Parts of platform-dependant code were refactored to use newly added >>>>>>> is_selinux_enabled() function. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> I forgot to edit the man pages. Thanks Rob! >>>>>> >>>>>> Updated patch attached. >>>>>> >>>>>> Tomas >>>>> >>>>> After a bit of off-line discussion I don't think we're quite ready >>>>> yet >>>>> to require SELinux by default on client installations (even with a >>>>> flag to work around it). The feeling is this would be disruptive to >>>>> existing automation. >>>>> >>>>> Can you still do the check but not enforce it, simply display a big >>>>> warning if SELinux is disabled? >>>>> >>>>> rob >>>>> >>>> >>>> Sure, here is the updated patch. >>>> >>>> I edited the commit message, RFE description and man pages >>>> according to >>>> the new behaviour. >>>> >>>> Tomas >>> >>> The patch looks good, I'm just wondering about one thing. The default >>> value for is_selinux_enabled() is True in ipapython/services.py.in. >>> >>> So this means that any non-Red Hat/non-Fedora system, by default, is >>> going to assume that SELinux is enabled. >>> >>> My hesitation has to when we call check_selinux_status(). It may >>> incorrectly error out. I suspect that the user would have to work >>> around this using --allow-selinux-disabled but this wouldn't make a >>> lot of sense since they actually do have SELinux disabled. >> >> Yes, you're right. And the error message would not even be helpful since >> it would tell the user to install policycoreutils package. This would be >> the >> case both with server and client installs when selinux would not be >> installed >> at all. >> >>> What do you think? >>> >>> rob >> >> Well we have 2 options as I see it: >> >> 1.) We can either return None as default, and add checks to >> check_selinux_status, restore_context and install scripts that would >> ensure that we behave properly when is_selinux_enabled() is not >> implemented. >> >> 2.) We can remove the default value, since it would cause forementioned >> crash and add comment that this function needs to be implemented >> properly in every platform file. >> >> I'm probably for option 2, there's no need to clutter the code with >> checks >> that compensate for improper platform file implementations. >> >> Tomas > > I agree with you on option 2. > > rob I updated the patch accordingly. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0027-4-Add-checks-for-SELinux-in-install-scripts.patch Type: text/x-patch Size: 13793 bytes Desc: not available URL: From jcholast at redhat.com Tue Apr 2 08:48:46 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Apr 2013 10:48:46 +0200 Subject: [Freeipa-devel] [PATCHES] 0197-0207 Installing without a CA, with custom SSL certs In-Reply-To: <5155A5BA.9060505@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> <51547A7F.8050907@redhat.com> <5155696E.9030209@redhat.com> <51556AE1.7000104@redhat.com> <5155A5BA.9060505@redhat.com> Message-ID: <515A9B6E.1090603@redhat.com> On 29.3.2013 15:31, Petr Viktorin wrote: > On 03/29/2013 11:20 AM, Jan Cholasta wrote: >> On 29.3.2013 11:14, Jan Cholasta wrote: >>> Also I was able to install IPA with revoked certificates, but it doesn't >>> seem to break anything - the CRL specified in the certificates' CRL >>> distribution point is not automatically imported into any of the NSS >>> databases and when it is imported manually, everything still seems to >>> work fine. I haven't checked OCSP. Can and/or do we want to do something >>> about this? >> >> Update: the ipa command does not work: >> >> $ ipa host-show $HOSTNAME --all --raw >> ipa: ERROR: cert validation failed for "CN=ipa.example.com,O=Example" >> ((SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked.) >> ipa: ERROR: cannot connect to 'https://ipa.example.com/ipa/xml': [Errno >> -8180] (SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been >> revoked. > > I think we can live with not checking CRLs now. I haven't found a way to > download CRLs with certutil or python-nss (short of explicitly examining > the certs, downloading the CRL and importing it, but I don't think IPA > is the place for that). > I've asked John. OK, thanks. > >>> Patch 205: >>> >>> Can we instead require the PKCS#12 files to always contain the whole >>> certificate chain? IMO that way it would be more obvious what should >>> actually be in the files and it would make things easier should there >>> ever be need for --root-ca-subject. > > Not requiring the root CA is a convenient shortcut. It's common to have > certs signed directly by the CA, and in this case you can use either a > single-cert PKCS#12 or one with the full chain. > Actually, originally the full chain was required, and a user already > complained :) > > If we add a new option, we can specify its requirements on the other > options. No problem. > > Adding a new patch for client installation. > This is nothing critical, but I think that make-testcert should check if dogtag is installed and when it's not, print a message informing the user that they should issue the test certificate manually and place it in the appropriate location. Besides that, ACK. Honza -- Jan Cholasta From tbabej at redhat.com Tue Apr 2 09:19:10 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 02 Apr 2013 11:19:10 +0200 Subject: [Freeipa-devel] [RFE] Multiple trust servers per realm In-Reply-To: <20130308131625.GA18359@redhat.com> References: <20130308131625.GA18359@redhat.com> Message-ID: <515AA28E.9080402@redhat.com> On Fri 08 Mar 2013 02:16:26 PM CET, Alexander Bokovoy wrote: > Hi, > > http://www.freeipa.org/page/V3/MultipleTrustServers covers RFE to have > multiple domain controllers exposed to trusted domains. > > Attached patch also implements needed changes for ipa-adtrust-install > part. Global trust configuration options are already implemented and > available in git master, while Web UI support for them needs to be > added. > > The patch attached actually fixes our current (rather wrong) way of > exposing all LDAP- and Kerberos-related SRV records to default site > configuration and _msdcs SRV namespace. This was wrong because it > assumed that all servers mentioned in SRV records could be domain > controllers, that is, they are usable to contact over SMB protocol. > The latter isn't true until we ran ipa-adtrust-install on them. > > The patch only exposes those servers which manage cifs/fqdn at REALM > services and only if those services are also members of cn=adtrust > agents container. This is fairly strict filter and it allows also to > have other types of SMB servers as part of the realm. > > Below is a copy of the RFE: > ================================================================== > __NOTOC__ > > = Overview = > > Ticket [https://fedorahosted.org/freeipa/ticket/2189 #2189]; > > Each FreeIPA server in the realm has potential to serve as domain > controller in the cross-forest realm trust. This page outlines design > for implementing multiple servers support in FreeIPA. > > = Use Cases = > > Once ipa-adtrust-install ran on the FreeIPA server, the server > can handle requests from trusted domains by means of Samba project's > smbd and winbindd daemons. > > Hosts in FreeIPA realm may be enrolled against specific FreeIPA replica > server. User from trusted domain can access these hosts and their > identities will be resolved against the replica. However, if replica > server does not have trust support configured, these identities will not > be processed since running winbindd process is required to > contact the trusted domain's domain controllers and Global Catalog > servers. > > Domain controllers are advertised to clients via SRV records in DNS. > Since replica servers may be arranged in a specific topology, adding new > domain controller would need to respect the topology design. It means > priority/weight of the domain controller compared to other domain > controllers should be adjustable. Prime use case for this is branch > office deployments. > > = Design= > * Each domain controller uses separate identity and service key to talk > to FreeIPA LDAP server. The identity is tied to the server hostname. > > * Service principal is cifs/hostname at REALM, identified in LDAP > as krbprincipalname=cifs/hostname at REALM. > > * All identities are members of cn=adtrust > agents,cn=sysaccounts,cn=etc,$SUFFIX. > Thus, all replica servers can see what other servers are providing > domain controller service. > > * Replica server only becomes domain controller when > ipa-adtrust-install utility was executed on it. It means all > DC setup is delivered via the ipa-adtrust-install. > > * ipa-adtrust-install should be able to detect other DCs by > looking at existing identities as members of the cn=adtrust > agents,cn=sysaccounts,cn=etc,$SUFFIX > tree and modify list of SRV records under _msdcs and default > site configuration if DNS is controlled by FreeIPA. > > * Domain Controller priority/weight can be modified at run time since it > only affects SRV records in the DNS (if FreeIPA controls the DNS). > Normal ipa dnsrecord-mod commands should be used for this > purpose, operating on SRV records for _msdcs and default site > configuration. > > * There are trust properties that are global for the realm. Some of them > are modifiable, some not. Thus, ipa trustconfig-show and > ipa trustconfig-mod should reflect both global and local > settings (realm-wise and DC-wise). > > * Following properties of the trust are global for the realm: > ** NetBIOS domain name (read-only, affects existing trusts) > ** Domain name (read-only, affects existing trusts) > ** Domain GUID (read-only, informational) > ** Additional domain suffixes exposed to the trusted party, handled as > black list against global list of additional domains associated > with our > or transitive realm, read/write > ** Fallback primary group (read-write) > > * Following properties of the trust are per Domain Controller: > ** priority of the DC and GC services (read-write, DNS SRV record) > > Details on ipa trustconfig commands design are available at > http://www.freeipa.org/page/V3/Trust_config_command > Details on additional domain suffixes handling are available at > http://www.freeipa.org/page/V3/Domain_suffixes > > = Implementation = > Implementation-wise there are three parts: > > * ipa-adtrust-install: > ** Gather list of CIFS services that are also members of cn=adtrust > agents and add SRV records for them to _msdcs in > > ipaserver/install/adtrustinstance.py:ADTrustInstance::__add_dns_service_records(). > > ** Once Global Catalog Server implementation will be ready, configure > its use as one of ADTrustInstance setup steps. > > * IPA framework: > ** Add display and modification of trust properties as ipa > trustconfig-* commands, including listing DC and GC servers. > ** NOTE: there is no need to modify trust creation procedure since it > appears that AD DC assumes LSA CreateTrustedDomainEx2 call comes from > the DC (in Windows the UI to establish trust is only on DC) and > therefore does not do DNS discovery during validation step. Since smbd > running on the same host that 'ipa trust-add' runs on will contact the > same host's LDAP server, there is no issue in replication at this stage. > > * IPA Web UI > ** Add support for ipa trustconfig-* to Web UI. > > = Major configuration options and enablement = > No additional options to ipa-adtrust-install > > = Replication = > All data is already in a replicated namespace. > > = Updates and Upgrades = > No changes to schema, no need to run anything additional on updates or > upgrades > > = Dependencies = > No additional dependencies beyond AD trusts support > > = External Impact = > Once ipa-adtrust-install install ran on replica, the replica > will be advertised via _msdcs SRV namespace as a domain > controller. > ================================================================== > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I tested with various topologies with up to 8 replicas, worked fine, ACK. Tomas From jcholast at redhat.com Tue Apr 2 09:24:46 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 02 Apr 2013 11:24:46 +0200 Subject: [Freeipa-devel] [PATCH] 273 Add ipakrbokasdelegate option to service and host Web UI pages In-Reply-To: <5155C000.2070002@redhat.com> References: <5155BCE4.2050100@redhat.com> <5155C000.2070002@redhat.com> Message-ID: <515AA3DE.90900@redhat.com> Hi, On 29.3.2013 17:23, Petr Vobornik wrote: > On 03/29/2013 05:10 PM, Petr Vobornik wrote: >> >> https://fedorahosted.org/freeipa/ticket/3329 >> > > Attaching new rebased version. > It seems everything works fine, ACK. Honza -- Jan Cholasta From akrivoka at redhat.com Tue Apr 2 09:57:15 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 02 Apr 2013 11:57:15 +0200 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <513DA347.8040100@redhat.com> References: <5135D5BC.5030909@redhat.com> <5135DF5A.4040902@redhat.com> <5136FF15.6080505@redhat.com> <5137318A.2010505@redhat.com> <513DA347.8040100@redhat.com> Message-ID: <515AAB7B.4010506@redhat.com> On 03/11/2013 10:26 AM, Martin Kosek wrote: > On 03/06/2013 01:07 PM, Petr Spacek wrote: >> On 6.3.2013 09:32, Martin Kosek wrote: >>> + error=u'CNAME record is not allowed to coexist with >>> any >>> other record'), >> >> Sorry for nitpicking again, but I would add note '(RFC 1034, section >> 3.6.2)'. >> >> Thank you! >> > > Fixed. > > Martin > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Patches 379 and 380 need rebasing. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Apr 2 10:05:35 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Apr 2013 12:05:35 +0200 Subject: [Freeipa-devel] [PATCHES] 0197-0207 Installing without a CA, with custom SSL certs In-Reply-To: <515A9B6E.1090603@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> <51547A7F.8050907@redhat.com> <5155696E.9030209@redhat.com> <51556AE1.7000104@redhat.com> <5155A5BA.9060505@redhat.com> <515A9B6E.1090603@redhat.com> Message-ID: <515AAD6F.3030805@redhat.com> On 04/02/2013 10:48 AM, Jan Cholasta wrote: > On 29.3.2013 15:31, Petr Viktorin wrote: >> On 03/29/2013 11:20 AM, Jan Cholasta wrote: >>> On 29.3.2013 11:14, Jan Cholasta wrote: >>>> Also I was able to install IPA with revoked certificates, but it >>>> doesn't >>>> seem to break anything - the CRL specified in the certificates' CRL >>>> distribution point is not automatically imported into any of the NSS >>>> databases and when it is imported manually, everything still seems to >>>> work fine. I haven't checked OCSP. Can and/or do we want to do >>>> something >>>> about this? >>> >>> Update: the ipa command does not work: >>> >>> $ ipa host-show $HOSTNAME --all --raw >>> ipa: ERROR: cert validation failed for "CN=ipa.example.com,O=Example" >>> ((SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked.) >>> ipa: ERROR: cannot connect to 'https://ipa.example.com/ipa/xml': [Errno >>> -8180] (SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been >>> revoked. >> >> I think we can live with not checking CRLs now. I haven't found a way to >> download CRLs with certutil or python-nss (short of explicitly examining >> the certs, downloading the CRL and importing it, but I don't think IPA >> is the place for that). >> I've asked John. > > OK, thanks. > >> >>>> Patch 205: >>>> >>>> Can we instead require the PKCS#12 files to always contain the whole >>>> certificate chain? IMO that way it would be more obvious what should >>>> actually be in the files and it would make things easier should there >>>> ever be need for --root-ca-subject. >> >> Not requiring the root CA is a convenient shortcut. It's common to have >> certs signed directly by the CA, and in this case you can use either a >> single-cert PKCS#12 or one with the full chain. >> Actually, originally the full chain was required, and a user already >> complained :) >> >> If we add a new option, we can specify its requirements on the other >> options. > > No problem. > >> >> Adding a new patch for client installation. >> I found one more bug: the replica wasn't setting the ra_plugin option properly, preventing installing a replica of a replica. I squashed the following change into 204: diff --git a/install/tools/ipa-replica-install b/install/tools/ipa-replica-install index 8fce3a8..af80c1e 100755 --- a/install/tools/ipa-replica-install +++ b/install/tools/ipa-replica-install @@ -539,6 +539,9 @@ def main(): fd.write("ra_plugin=dogtag\n") fd.write("dogtag_version=%s\n" % dogtag.install_constants.DOGTAG_VERSION) + else: + fd.write("enable_ra=False\n") + fd.write("ra_plugin=none\n") fd.write("mode=production\n") fd.close() finally: > This is nothing critical, but I think that make-testcert should check if > dogtag is installed and when it's not, print a message informing the > user that they should issue the test certificate manually and place it > in the appropriate location. > > Besides that, ACK. I'll make another patch so this set is not delayed. > Honza > -- Petr? From pviktori at redhat.com Tue Apr 2 10:06:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Apr 2013 12:06:31 +0200 Subject: [Freeipa-devel] [PATCHES] 0197-0207 Installing without a CA, with custom SSL certs In-Reply-To: <515AAD6F.3030805@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> <51547A7F.8050907@redhat.com> <5155696E.9030209@redhat.com> <51556AE1.7000104@redhat.com> <5155A5BA.9060505@redhat.com> <515A9B6E.1090603@redhat.com> <515AAD6F.3030805@redhat.com> Message-ID: <515AADA7.2030209@redhat.com> On 04/02/2013 12:05 PM, Petr Viktorin wrote: > On 04/02/2013 10:48 AM, Jan Cholasta wrote: >> On 29.3.2013 15:31, Petr Viktorin wrote: >>> On 03/29/2013 11:20 AM, Jan Cholasta wrote: >>>> On 29.3.2013 11:14, Jan Cholasta wrote: >>>>> Also I was able to install IPA with revoked certificates, but it >>>>> doesn't >>>>> seem to break anything - the CRL specified in the certificates' CRL >>>>> distribution point is not automatically imported into any of the NSS >>>>> databases and when it is imported manually, everything still seems to >>>>> work fine. I haven't checked OCSP. Can and/or do we want to do >>>>> something >>>>> about this? >>>> >>>> Update: the ipa command does not work: >>>> >>>> $ ipa host-show $HOSTNAME --all --raw >>>> ipa: ERROR: cert validation failed for "CN=ipa.example.com,O=Example" >>>> ((SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked.) >>>> ipa: ERROR: cannot connect to 'https://ipa.example.com/ipa/xml': [Errno >>>> -8180] (SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been >>>> revoked. >>> >>> I think we can live with not checking CRLs now. I haven't found a way to >>> download CRLs with certutil or python-nss (short of explicitly examining >>> the certs, downloading the CRL and importing it, but I don't think IPA >>> is the place for that). >>> I've asked John. >> >> OK, thanks. >> >>> >>>>> Patch 205: >>>>> >>>>> Can we instead require the PKCS#12 files to always contain the whole >>>>> certificate chain? IMO that way it would be more obvious what should >>>>> actually be in the files and it would make things easier should there >>>>> ever be need for --root-ca-subject. >>> >>> Not requiring the root CA is a convenient shortcut. It's common to have >>> certs signed directly by the CA, and in this case you can use either a >>> single-cert PKCS#12 or one with the full chain. >>> Actually, originally the full chain was required, and a user already >>> complained :) >>> >>> If we add a new option, we can specify its requirements on the other >>> options. >> >> No problem. >> >>> >>> Adding a new patch for client installation. >>> > > I found one more bug: the replica wasn't setting the ra_plugin option > properly, preventing installing a replica of a replica. > I squashed the following change into 204: > > diff --git a/install/tools/ipa-replica-install > b/install/tools/ipa-replica-install > index 8fce3a8..af80c1e 100755 > --- a/install/tools/ipa-replica-install > +++ b/install/tools/ipa-replica-install > @@ -539,6 +539,9 @@ def main(): > fd.write("ra_plugin=dogtag\n") > fd.write("dogtag_version=%s\n" % > dogtag.install_constants.DOGTAG_VERSION) > + else: > + fd.write("enable_ra=False\n") > + fd.write("ra_plugin=none\n") > fd.write("mode=production\n") > fd.close() > finally: > I forgot to attach the patches; here they are. > >> This is nothing critical, but I think that make-testcert should check if >> dogtag is installed and when it's not, print a message informing the >> user that they should issue the test certificate manually and place it >> in the appropriate location. >> >> Besides that, ACK. > > I'll make another patch so this set is not delayed. > >> Honza >> > > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0197.6-ipa-server-install-Make-temporary-pin-files-availabl.patch Type: text/x-patch Size: 6417 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0198.6-ipa-server-install-Remove-the-selfsign-option.patch Type: text/x-patch Size: 10375 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0200.6-Remove-unused-ipapython.certdb.CertDB-class.patch Type: text/x-patch Size: 6266 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0201.6-ipaserver.install.certs-Introduce-NSSDatabase-as-a-m.patch Type: text/x-patch Size: 13843 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0202.6-Trust-CAs-from-PKCS-12-files-even-if-they-don-t-have.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0203.6-dsinstance-httpinstance-Don-t-hardcode-Server-Cert.patch Type: text/x-patch Size: 5772 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0204.6-Support-installing-with-custom-SSL-certs-without-a-C.patch Type: text/x-patch Size: 23096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0205.6-Load-the-CA-cert-into-server-NSS-databases.patch Type: text/x-patch Size: 11090 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0206.6-Do-not-call-cert-commands-in-host-plugin-if-a-RA-is-.patch Type: text/x-patch Size: 10403 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0207.6-ipa-client-install-Do-not-request-host-certificate-i.patch Type: text/x-patch Size: 3996 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 2 10:12:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Apr 2013 12:12:02 +0200 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <515AAB7B.4010506@redhat.com> References: <5135D5BC.5030909@redhat.com> <5135DF5A.4040902@redhat.com> <5136FF15.6080505@redhat.com> <5137318A.2010505@redhat.com> <513DA347.8040100@redhat.com> <515AAB7B.4010506@redhat.com> Message-ID: <515AAEF2.3070103@redhat.com> On 04/02/2013 11:57 AM, Ana Krivokapic wrote: > On 03/11/2013 10:26 AM, Martin Kosek wrote: >> On 03/06/2013 01:07 PM, Petr Spacek wrote: >>> On 6.3.2013 09:32, Martin Kosek wrote: >>>> + error=u'CNAME record is not allowed to coexist with any >>>> other record'), >>> >>> Sorry for nitpicking again, but I would add note '(RFC 1034, section 3.6.2)'. >>> >>> Thank you! >>> >> >> Fixed. >> >> Martin >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Patches 379 and 380 need rebasing. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > Rebased patches attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-378-4-change-cname-and-dname-attributes-to-single-valued.patch Type: text/x-patch Size: 5397 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-379-4-improve-cname-record-validation.patch Type: text/x-patch Size: 8171 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-380-4-improve-dname-record-validation.patch Type: text/x-patch Size: 7996 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 2 10:40:08 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Apr 2013 12:40:08 +0200 Subject: [Freeipa-devel] [RFE] Multiple trust servers per realm In-Reply-To: <515AA28E.9080402@redhat.com> References: <20130308131625.GA18359@redhat.com> <515AA28E.9080402@redhat.com> Message-ID: <515AB588.7040107@redhat.com> On 04/02/2013 11:19 AM, Tomas Babej wrote: > On Fri 08 Mar 2013 02:16:26 PM CET, Alexander Bokovoy wrote: >> Hi, >> >> http://www.freeipa.org/page/V3/MultipleTrustServers covers RFE to have >> multiple domain controllers exposed to trusted domains. >> >> Attached patch also implements needed changes for ipa-adtrust-install >> part. Global trust configuration options are already implemented and >> available in git master, while Web UI support for them needs to be >> added. >> >> The patch attached actually fixes our current (rather wrong) way of >> exposing all LDAP- and Kerberos-related SRV records to default site >> configuration and _msdcs SRV namespace. This was wrong because it >> assumed that all servers mentioned in SRV records could be domain >> controllers, that is, they are usable to contact over SMB protocol. >> The latter isn't true until we ran ipa-adtrust-install on them. >> >> The patch only exposes those servers which manage cifs/fqdn at REALM >> services and only if those services are also members of cn=adtrust >> agents container. This is fairly strict filter and it allows also to >> have other types of SMB servers as part of the realm. >> >> Below is a copy of the RFE: >> ================================================================== >> __NOTOC__ >> >> = Overview = >> >> Ticket [https://fedorahosted.org/freeipa/ticket/2189 #2189]; >> >> Each FreeIPA server in the realm has potential to serve as domain >> controller in the cross-forest realm trust. This page outlines design >> for implementing multiple servers support in FreeIPA. >> >> = Use Cases = >> >> Once ipa-adtrust-install ran on the FreeIPA server, the server >> can handle requests from trusted domains by means of Samba project's >> smbd and winbindd daemons. >> >> Hosts in FreeIPA realm may be enrolled against specific FreeIPA replica >> server. User from trusted domain can access these hosts and their >> identities will be resolved against the replica. However, if replica >> server does not have trust support configured, these identities will not >> be processed since running winbindd process is required to >> contact the trusted domain's domain controllers and Global Catalog >> servers. >> >> Domain controllers are advertised to clients via SRV records in DNS. >> Since replica servers may be arranged in a specific topology, adding new >> domain controller would need to respect the topology design. It means >> priority/weight of the domain controller compared to other domain >> controllers should be adjustable. Prime use case for this is branch >> office deployments. >> >> = Design= >> * Each domain controller uses separate identity and service key to talk >> to FreeIPA LDAP server. The identity is tied to the server hostname. >> >> * Service principal is cifs/hostname at REALM, identified in LDAP >> as krbprincipalname=cifs/hostname at REALM. >> >> * All identities are members of cn=adtrust >> agents,cn=sysaccounts,cn=etc,$SUFFIX. >> Thus, all replica servers can see what other servers are providing >> domain controller service. >> >> * Replica server only becomes domain controller when >> ipa-adtrust-install utility was executed on it. It means all >> DC setup is delivered via the ipa-adtrust-install. >> >> * ipa-adtrust-install should be able to detect other DCs by >> looking at existing identities as members of the cn=adtrust >> agents,cn=sysaccounts,cn=etc,$SUFFIX >> tree and modify list of SRV records under _msdcs and default >> site configuration if DNS is controlled by FreeIPA. >> >> * Domain Controller priority/weight can be modified at run time since it >> only affects SRV records in the DNS (if FreeIPA controls the DNS). >> Normal ipa dnsrecord-mod commands should be used for this >> purpose, operating on SRV records for _msdcs and default site >> configuration. >> >> * There are trust properties that are global for the realm. Some of them >> are modifiable, some not. Thus, ipa trustconfig-show and >> ipa trustconfig-mod should reflect both global and local >> settings (realm-wise and DC-wise). >> >> * Following properties of the trust are global for the realm: >> ** NetBIOS domain name (read-only, affects existing trusts) >> ** Domain name (read-only, affects existing trusts) >> ** Domain GUID (read-only, informational) >> ** Additional domain suffixes exposed to the trusted party, handled as >> black list against global list of additional domains associated >> with our >> or transitive realm, read/write >> ** Fallback primary group (read-write) >> >> * Following properties of the trust are per Domain Controller: >> ** priority of the DC and GC services (read-write, DNS SRV record) >> >> Details on ipa trustconfig commands design are available at >> http://www.freeipa.org/page/V3/Trust_config_command >> Details on additional domain suffixes handling are available at >> http://www.freeipa.org/page/V3/Domain_suffixes >> >> = Implementation = >> Implementation-wise there are three parts: >> >> * ipa-adtrust-install: >> ** Gather list of CIFS services that are also members of cn=adtrust >> agents and add SRV records for them to _msdcs in >> >> ipaserver/install/adtrustinstance.py:ADTrustInstance::__add_dns_service_records(). >> >> >> ** Once Global Catalog Server implementation will be ready, configure >> its use as one of ADTrustInstance setup steps. >> >> * IPA framework: >> ** Add display and modification of trust properties as ipa >> trustconfig-* commands, including listing DC and GC servers. >> ** NOTE: there is no need to modify trust creation procedure since it >> appears that AD DC assumes LSA CreateTrustedDomainEx2 call comes from >> the DC (in Windows the UI to establish trust is only on DC) and >> therefore does not do DNS discovery during validation step. Since smbd >> running on the same host that 'ipa trust-add' runs on will contact the >> same host's LDAP server, there is no issue in replication at this stage. >> >> * IPA Web UI >> ** Add support for ipa trustconfig-* to Web UI. >> >> = Major configuration options and enablement = >> No additional options to ipa-adtrust-install >> >> = Replication = >> All data is already in a replicated namespace. >> >> = Updates and Upgrades = >> No changes to schema, no need to run anything additional on updates or >> upgrades >> >> = Dependencies = >> No additional dependencies beyond AD trusts support >> >> = External Impact = >> Once ipa-adtrust-install install ran on replica, the replica >> will be advertised via _msdcs SRV namespace as a domain >> controller. >> ================================================================== >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I tested with various topologies with up to 8 replicas, worked fine, ACK. > > Tomas Thanks. Pushed to master and ipa-3-1 too as the fix is pretty self-contained. Martin From pviktori at redhat.com Tue Apr 2 11:13:32 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Apr 2013 13:13:32 +0200 Subject: [Freeipa-devel] [PATCH] 0208 make-testcert: Add better messages for errors with CA-less In-Reply-To: <51470169.1090308@redhat.com> References: <51470169.1090308@redhat.com> Message-ID: <515ABD5C.9020500@redhat.com> On 03/18/2013 12:58 PM, Petr Viktorin wrote: > Hello, > While the work is not complete, these patches allowed me to install an > IPA server without a CA, using PKCS#12 files for the server certs. > > The patches don't break normal installation. > The --selfsign option (but not yet the code behind it) is removed. > > The absence of a CA is indicated by `enable_ra=False` in the IPA config. > > ipa-replica-install will still refuse to run; I'll look into that next. > > I removed some unused code that got in my way: Dogtag 9 installation (we > can run a Dogtag 9-style CA, but we never *install* it), and > ipapython.certdb.CertDB (unused, not to be confused with ipaserver's > CertDB). Hello, This improves a developer testing tool. Details inside. Submitting separately so any problems don't hold back the big batch of CA-less patches. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0208-make-testcert-Add-better-messages-for-errors-with-CA.patch Type: text/x-patch Size: 2044 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 2 13:38:13 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Apr 2013 15:38:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0197-0207 Installing without a CA, with custom SSL certs In-Reply-To: <515AADA7.2030209@redhat.com> References: <51470169.1090308@redhat.com> <51478621.9090503@redhat.com> <5149E1AA.3020701@redhat.com> <5149F1CA.6080904@redhat.com> <5149F339.5070802@redhat.com> <514AF66E.2070901@redhat.com> <514C5B04.4010101@redhat.com> <5151C36B.5090009@redhat.com> <51542791.10809@redhat.com> <51547A7F.8050907@redhat.com> <5155696E.9030209@redhat.com> <51556AE1.7000104@redhat.com> <5155A5BA.9060505@redhat.com> <515A9B6E.1090603@redhat.com> <515AAD6F.3030805@redhat.com> <515AADA7.2030209@redhat.com> Message-ID: <515ADF45.2070603@redhat.com> On 04/02/2013 12:06 PM, Petr Viktorin wrote: > On 04/02/2013 12:05 PM, Petr Viktorin wrote: >> On 04/02/2013 10:48 AM, Jan Cholasta wrote: >>> On 29.3.2013 15:31, Petr Viktorin wrote: >>>> On 03/29/2013 11:20 AM, Jan Cholasta wrote: >>>>> On 29.3.2013 11:14, Jan Cholasta wrote: >>>>>> Also I was able to install IPA with revoked certificates, but it >>>>>> doesn't >>>>>> seem to break anything - the CRL specified in the certificates' CRL >>>>>> distribution point is not automatically imported into any of the NSS >>>>>> databases and when it is imported manually, everything still seems to >>>>>> work fine. I haven't checked OCSP. Can and/or do we want to do >>>>>> something >>>>>> about this? >>>>> >>>>> Update: the ipa command does not work: >>>>> >>>>> $ ipa host-show $HOSTNAME --all --raw >>>>> ipa: ERROR: cert validation failed for "CN=ipa.example.com,O=Example" >>>>> ((SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been revoked.) >>>>> ipa: ERROR: cannot connect to 'https://ipa.example.com/ipa/xml': [Errno >>>>> -8180] (SEC_ERROR_REVOKED_CERTIFICATE) Peer's Certificate has been >>>>> revoked. >>>> >>>> I think we can live with not checking CRLs now. I haven't found a way to >>>> download CRLs with certutil or python-nss (short of explicitly examining >>>> the certs, downloading the CRL and importing it, but I don't think IPA >>>> is the place for that). >>>> I've asked John. >>> >>> OK, thanks. >>> >>>> >>>>>> Patch 205: >>>>>> >>>>>> Can we instead require the PKCS#12 files to always contain the whole >>>>>> certificate chain? IMO that way it would be more obvious what should >>>>>> actually be in the files and it would make things easier should there >>>>>> ever be need for --root-ca-subject. >>>> >>>> Not requiring the root CA is a convenient shortcut. It's common to have >>>> certs signed directly by the CA, and in this case you can use either a >>>> single-cert PKCS#12 or one with the full chain. >>>> Actually, originally the full chain was required, and a user already >>>> complained :) >>>> >>>> If we add a new option, we can specify its requirements on the other >>>> options. >>> >>> No problem. >>> >>>> >>>> Adding a new patch for client installation. >>>> >> >> I found one more bug: the replica wasn't setting the ra_plugin option >> properly, preventing installing a replica of a replica. >> I squashed the following change into 204: >> >> diff --git a/install/tools/ipa-replica-install >> b/install/tools/ipa-replica-install >> index 8fce3a8..af80c1e 100755 >> --- a/install/tools/ipa-replica-install >> +++ b/install/tools/ipa-replica-install >> @@ -539,6 +539,9 @@ def main(): >> fd.write("ra_plugin=dogtag\n") >> fd.write("dogtag_version=%s\n" % >> dogtag.install_constants.DOGTAG_VERSION) >> + else: >> + fd.write("enable_ra=False\n") >> + fd.write("ra_plugin=none\n") >> fd.write("mode=production\n") >> fd.close() >> finally: >> > > I forgot to attach the patches; here they are. > >> >>> This is nothing critical, but I think that make-testcert should check if >>> dogtag is installed and when it's not, print a message informing the >>> user that they should issue the test certificate manually and place it >>> in the appropriate location. >>> >>> Besides that, ACK. >> >> I'll make another patch so this set is not delayed. >> >>> Honza >>> ACK for the small diff change. The rest was already reviewed by Jan. Thanks to both! Pushed all patches to master. Martin From mkosek at redhat.com Tue Apr 2 13:38:56 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Apr 2013 15:38:56 +0200 Subject: [Freeipa-devel] [PATCHES] 0197-0204 Installing without a CA, with custom SSL certs In-Reply-To: <5155D062.2030000@redhat.com> References: <51470169.1090308@redhat.com> <5155CC94.3060208@redhat.com> <5155D062.2030000@redhat.com> Message-ID: <515ADF70.2090204@redhat.com> On 03/29/2013 06:33 PM, Petr Viktorin wrote: > On 03/29/2013 06:17 PM, Petr Vobornik wrote: >> Hello, >> >> attaching Web UI part. >> >> Petr >> > > Works well for me, if someone can check if the Javascript looks fine then ACK. > I think that functional review is OK in this case, there are no architectonic changes... Pushed to master. Martin From rcritten at redhat.com Tue Apr 2 13:46:57 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 02 Apr 2013 09:46:57 -0400 Subject: [Freeipa-devel] [PATCH 0043] Properly handle ipa-replica-install when its zone is not managed by IPA In-Reply-To: <5155B087.5030309@redhat.com> References: <5151C5DE.7090902@redhat.com> <515593DD.3090405@redhat.com> <5155A124.1090601@redhat.com> <5155A9CB.5010605@redhat.com> <5155ACA8.2090408@redhat.com> <5155B087.5030309@redhat.com> Message-ID: <515AE151.802@redhat.com> Ana Krivokapic wrote: > On 03/29/2013 04:00 PM, Tomas Babej wrote: >> On 03/29/2013 03:48 PM, Ana Krivokapic wrote: >>> On 03/29/2013 03:11 PM, Tomas Babej wrote: >>>> On 03/29/2013 02:15 PM, Ana Krivokapic wrote: >>>>> On 03/26/2013 04:59 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> The ipa-replica-install script tries to add replica's A and PTR >>>>>> records to the master DNS, if master does manage DNS. However, >>>>>> master need not to manage replica's zone. Properly handle this use >>>>>> case. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3496 >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> >>>>> The patch works well and fixes the issue. >>>>> >>>>> Just a couple of nitpicks: >>>>> >>>>> 1) "However, master need not to manage replica's zone." -- This >>>>> sentence sounds a little strange to me, but I am not a native >>>>> speaker so I may be wrong about that. >>>> >>>> The phrase should be ok. I assume you're worried about "need not" >>>> construct, which may sound a bit unusal as opposed to, for example, >>>> "does not need to". >>>> >>>> One could argue that it sounds archaic. However, consider the >>>> following chart, which clearly proves the opposite: >>>> >>>> http://books.google.com/ngrams/chart?content=need%20not%2Cneeds%20not%2Cdoes%20not%20need%20to%2Cdoesn%20'%20t%20need%20to&corpus=0&smoothing=3&year_start=1800&year_end=2000 >>>> >>>> >>>> For more detailed explanation, see: >>>> >>>> http://english.stackexchange.com/questions/29409/why-use-need-not-instead-of-do-not-need-to >>>> >>> Actually, the part that sounded weird to me is the "to" that comes >>> after "need not" in your commit message. Also, the stackexchange link >>> you provided states: "This /need/ is a *modal verb*: it always >>> requires an infinitive without /to/;". >>> >>> Sorry that I wasn't clear about this in my first email. >> Yes, that's a mistake on my part, thanks fot catching that. Fixed the >> commit message. >>> >>>>> >>>>> 2) There are three PEP8 501 errors introduced by the patch, but >>>>> given the recent discussion on this subject, I think it is really >>>>> up to you if you want to take the time to fix these. >>>> >>>> Sure I do. Thanks for the catch. Updated patch attached. >>> There is still one line with E501: >>> >>> install/tools/ipa-replica-install:303:80: E501 line too long (80 > 79 >>> characters) >> I left that one so intentionally. Imho, it would only mangle the line >> unnecessarily, the line is exactly 80 characters long with no nice >> point where to break it. > > OK, makes sense. >>> >>>> >>>>> >>>>> ACK from the functional perspective. >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> Ana Krivokapic >>>>> Associate Software Engineer >>>>> FreeIPA team >>>>> Red Hat Inc. >>>> >>> >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >> > > ACK Pushed to master and ipa-3-1 rob From pviktori at redhat.com Tue Apr 2 14:01:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Apr 2013 16:01:45 +0200 Subject: [Freeipa-devel] [RFE] Drop --selfsign In-Reply-To: <5149DF9E.7080209@redhat.com> References: <5149DF9E.7080209@redhat.com> Message-ID: <515AE4C9.3030305@redhat.com> On 03/20/2013 05:11 PM, Petr Viktorin wrote: > Here is a RFE for https://fedorahosted.org/freeipa/ticket/3494. > It's for dropping the --selfsign option from ipa-server-install. The > functionality itself stays in for now (on upgraded self-signed masters). > > http://freeipa.org/page/V3/Drop_selfsign > Since the patch was pushed, I've linked the RFE in http://freeipa.org/page/V3_Designs -- Petr? From pviktori at redhat.com Tue Apr 2 14:01:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Apr 2013 16:01:46 +0200 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <514C4A35.2060200@redhat.com> References: <514C4A35.2060200@redhat.com> Message-ID: <515AE4CA.7030301@redhat.com> On 03/22/2013 01:10 PM, Petr Viktorin wrote: > The design page for CA-less installation with user-provided SSL certs is > available at http://freeipa.org/page/V3/CA-less_install. I've also > copied it to this mail. > > Does it answer all your questions? > Since the patches were pushed, I've linked the RFE in http://freeipa.org/page/V3_Designs -- Petr? From pspacek at redhat.com Tue Apr 2 14:02:54 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 16:02:54 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <514C4880.6000203@redhat.com> References: <514C4880.6000203@redhat.com> Message-ID: <515AE50E.9030801@redhat.com> On 22.3.2013 13:03, Petr Spacek wrote: > Hello, > > this patch set separates master zones (idnsZone objectClass) from forward > zones (idnsForwardZone objectClass). Support for forward zones in idnsZone > objectClass is still present to ease upgrades. > > See each commit message for all the gory details. I encountered a crash caused by bug in patch 126. Fixed version is attached. Diff between patch 126 version 1 and 2: --- a/src/ldap_helper.c +++ b/src/ldap_helper.c @@ -3391,7 +3391,7 @@ update_zone(isc_task_t *task, isc_event_t *event) CHECK(dn_to_dnsname(inst->mctx, pevent->dn, &currname, NULL)); - if (result == ISC_R_SUCCESS && + if (ldap_qresult_zone != NULL && HEAD(ldap_qresult_zone->ldap_entries) != NULL) { entry_zone = HEAD(ldap_qresult_zone->ldap_entries); CHECK(ldap_entry_getclass(entry_zone, &objclass)); -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0126-2-Add-support-for-pure-forward-zones-idnsForwardZone-o.patch Type: text/x-patch Size: 30313 bytes Desc: not available URL: From akrivoka at redhat.com Tue Apr 2 14:53:51 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 02 Apr 2013 16:53:51 +0200 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <515AAEF2.3070103@redhat.com> References: <5135D5BC.5030909@redhat.com> <5135DF5A.4040902@redhat.com> <5136FF15.6080505@redhat.com> <5137318A.2010505@redhat.com> <513DA347.8040100@redhat.com> <515AAB7B.4010506@redhat.com> <515AAEF2.3070103@redhat.com> Message-ID: <515AF0FF.7050902@redhat.com> On 04/02/2013 12:12 PM, Martin Kosek wrote: > On 04/02/2013 11:57 AM, Ana Krivokapic wrote: >> On 03/11/2013 10:26 AM, Martin Kosek wrote: >>> On 03/06/2013 01:07 PM, Petr Spacek wrote: >>>> On 6.3.2013 09:32, Martin Kosek wrote: >>>>> + error=u'CNAME record is not allowed to coexist with any >>>>> other record'), >>>> Sorry for nitpicking again, but I would add note '(RFC 1034, section 3.6.2)'. >>>> >>>> Thank you! >>>> >>> Fixed. >>> >>> Martin >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Patches 379 and 380 need rebasing. >> >> -- >> Regards, >> >> Ana Krivokapic >> Associate Software Engineer >> FreeIPA team >> Red Hat Inc. >> > Rebased patches attached. > > Martin The first patch (schema update) correctly changes both CNAME and DNAME attributes to single valued attributes. I tested the newly introduced validation rules, trying to add: * more than 1 cname record with the same name * cname + ptr * cname + dname * cname + any other record * more than 1 dname * dname + ns * dname + ns (root zone) As expected, validation fails for all the above cases except the last one (dname + ns in the root zone). ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mkosek at redhat.com Tue Apr 2 15:10:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Apr 2013 17:10:52 +0200 Subject: [Freeipa-devel] [PATCH] 399 Require 389-base-base 1.3.0.5 Message-ID: <515AF4FC.2020407@redhat.com> Pulls the following fixes: - upgrade deadlock caused by DNA plugin reconfiguration - CVE-2013-1897: unintended information exposure when rootdse is enabled https://fedorahosted.org/freeipa/ticket/3540 ACKed by Rob on IRC, pushed to master, ipa-3-1. I will bump this Requires also for Fedora 18 and F19 build. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-399-require-389-base-base-1.3.0.5.patch Type: text/x-patch Size: 1937 bytes Desc: not available URL: From atkac at redhat.com Tue Apr 2 15:17:10 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 2 Apr 2013 17:17:10 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <514C4880.6000203@redhat.com> References: <514C4880.6000203@redhat.com> Message-ID: <20130402151709.GA21126@redhat.com> On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: > Hello, > > this patch set separates master zones (idnsZone objectClass) from > forward zones (idnsForwardZone objectClass). Support for forward > zones in idnsZone objectClass is still present to ease upgrades. > > See each commit message for all the gory details. Since patches are non-trivial, I will review them "per partes" (i.e. each patch in separate mail). Please check my comments below. Regards, Adam > From d0c598ea7e9c02a1ec786c6f1c596ae1be7ac1e2 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 22 Mar 2013 12:17:07 +0100 > Subject: [PATCH] Add helper functions for generic iteration over RBT. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/99 > > Signed-off-by: Petr Spacek > --- > src/rbt_helper.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/rbt_helper.h | 29 +++++++++++ > 2 files changed, 179 insertions(+) > create mode 100644 src/rbt_helper.c > create mode 100644 src/rbt_helper.h > > diff --git a/src/rbt_helper.c b/src/rbt_helper.c > new file mode 100644 > index 0000000000000000000000000000000000000000..70ab06134694e36a6ae049284d506bbf5bc3a977 > --- /dev/null > +++ b/src/rbt_helper.c > @@ -0,0 +1,150 @@ > +#include > + > +#include "rbt_helper.h" > + > +#define LDAPDB_RBTITER_MAGIC ISC_MAGIC('L', 'D', 'P', 'I') > + > +/** > + * Copy the RBT node name, i.e. copies the name pointed to by RBT iterator. > + * > + * @param[in] iter Initialized RBT iterator. > + * @param[out] nodename Target dns_name suitable for rbt_fullnamefromnode() call. > + * > + * @pre Nodename has pre-allocated storage space. > + * > + * @retval ISC_R_SUCCESS Actual name was copied to nodename. > + * @retval ISC_R_NOTFOUND Iterator doesn't point to any node. > + * @retval DNS_R_EMPTYNAME Iterator points to name without assigned data, > + * nodename is unchanged. > + * @retval others Errors from dns_name_concatenate() and others. > + * > + */ > +static isc_result_t > +rbt_iter_getnodename(rbt_iterator_t *iter, dns_name_t *nodename) { > + isc_result_t result; > + dns_rbtnode_t *node = NULL; > + > + REQUIRE(iter != NULL); > + REQUIRE(nodename != NULL); > + REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); > + > + CHECK(dns_rbtnodechain_current(&iter->chain, NULL, NULL, &node)); > + if (node->data == NULL) > + return DNS_R_EMPTYNAME; > + > + CHECK(dns_rbt_fullnamefromnode(node, nodename)); > + result = ISC_R_SUCCESS; > + > +cleanup: > + return result; > +} > + > +/** > + * Initialize RBT iterator, lock RBT and copy name of the first node with > + * non-NULL data. Empty RBT nodes (with data == NULL) are ignored. > + * > + * RBT remains locked after iterator initialization. RBT has to be > + * unlocked by reaching end of iteration or explicit rbt_iter_stop() call. > + * > + * @param[in,out] rwlock guard for RBT, will be read-locked > + * @param[out] iter iterator structure, will be initialized > + * @param[out] nodename dns_name with pre-allocated storage > + * > + * @pre Nodename has pre-allocated storage space. > + * > + * @retval ISC_R_SUCCESS Node with non-NULL data found, > + * RBT is in locked state, iterator is valid, > + * nodename holds copy of actual RBT node name. > + * @retval ISC_R_NOTFOUND Node with non-NULL data is not present, > + * RBT is in unlocked state, iterator is invalid. > + * @retval others Any error from rbt_iter_getnodename() and > + * rbt_iter_next(). > + */ > +isc_result_t > +rbt_iter_first(isc_mem_t *mctx, dns_rbt_t *rbt, isc_rwlock_t *rwlock, > + rbt_iterator_t *iter, dns_name_t *nodename) { > + > + isc_result_t result; > + > + REQUIRE(rbt != NULL); > + REQUIRE(rwlock != NULL); > + REQUIRE(iter != NULL); > + > + ZERO_PTR(iter); > + > + isc_mem_attach(mctx, &iter->mctx); > + dns_rbtnodechain_init(&iter->chain, mctx); > + iter->rbt = rbt; > + iter->rwlock = rwlock; > + iter->locktype = isc_rwlocktype_read; > + iter->magic = LDAPDB_RBTITER_MAGIC; > + > + RWLOCK(iter->rwlock, iter->locktype); > + > + result = dns_rbtnodechain_first(&iter->chain, rbt, NULL, NULL); > + if (result != DNS_R_NEWORIGIN) { > + rbt_iter_stop(iter); > + return result; I would substitute those two lines with "goto cleanup;". > + } > + > + result = rbt_iter_getnodename(iter, nodename); > + if (result == DNS_R_EMPTYNAME) > + result = rbt_iter_next(iter, nodename); > + if (result == ISC_R_NOMORE) > + result = ISC_R_NOTFOUND; In my opinion this function should leave rbt in locked state only when it returns ISC_R_SUCCESS. All other cases should unlock the tree. I recommend to add this statement: cleanup: if (result != ISC_R_SUCCESS) rbt_iter_stop(iter); > + > + return result; > +} > + > +/** > + * Copy name of the next non-empty node in RBT. > + * > + * @param[in] iter valid iterator > + * @param[out] nodename dns_name with pre-allocated storage > + * > + * @pre Nodename has pre-allocated storage space. > + * > + * @retval ISC_R_SUCCESS Nodename holds independent copy of RBT node name, > + * RBT is in locked state. > + * @retval ISC_R_NOMORE Iteration ended, RBT is in unlocked state, > + * iterator is no longer valid. > + * @retval others Errors from dns_name_concatenate() and others. > + */ > +isc_result_t > +rbt_iter_next(rbt_iterator_t *iter, dns_name_t *nodename) { > + isc_result_t result; > + > + REQUIRE(iter != NULL); > + REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); > + REQUIRE(iter->locktype != isc_rwlocktype_none); > + > + do { > + result = dns_rbtnodechain_next(&iter->chain, NULL, NULL); > + if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) > + goto cleanup; > + > + result = rbt_iter_getnodename(iter, nodename); > + } while (result == DNS_R_EMPTYNAME); > + > +cleanup: > + if (result != ISC_R_SUCCESS) > + rbt_iter_stop(iter); I think rbt_iter_stop() shouldn't be called here. Imagine this piece of code: CHECK(rbt_iter_first(..)); for (..) { CHECK(isc_mem_alloc(..)); CHECK(rbt_iter_next(..)); } cleanup: if (rbt_iter_first_was_called) // Now you should call rbt_iter_stop() only when isc_mem_alloc fails // but not when rbt_iter_next() fails. However how do you figure out // which function failed? Due to this reason, I recommend to drop rbt_iter_stop() call from the rbt_iter_next(). > + > + return result; > +} > + > +/** > + * Stop RBT iteration and unlock RBT. > + */ > +void > +rbt_iter_stop(rbt_iterator_t *iter) { > + REQUIRE(iter != NULL); > + REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); > + > + if (iter->locktype != isc_rwlocktype_none) > + isc_rwlock_unlock(iter->rwlock, iter->locktype); > + > + dns_rbtnodechain_invalidate(&iter->chain); > + isc_mem_detach(&(iter->mctx)); > + ZERO_PTR(iter); > +} > diff --git a/src/rbt_helper.h b/src/rbt_helper.h > new file mode 100644 > index 0000000000000000000000000000000000000000..9c9bcd202cafafb39a3018bbafff6bbd3c9189a9 > --- /dev/null > +++ b/src/rbt_helper.h > @@ -0,0 +1,29 @@ > +#ifndef _LD_RBT_HELPER_H_ > +#define _LD_RBT_HELPER_H_ > + > +#include > +#include > +#include "util.h" > + > +struct rbt_iterator { > + unsigned int magic; > + isc_mem_t *mctx; > + dns_rbt_t *rbt; > + isc_rwlock_t *rwlock; > + isc_rwlocktype_t locktype; > + dns_rbtnodechain_t chain; > +}; There is no reason to have struct rbt_iterator exported in header if I read patchset correctly. Please move it into rbt_helper.c and leave only typedef below here. > + > +typedef struct rbt_iterator rbt_iterator_t; > + > +isc_result_t > +rbt_iter_first(isc_mem_t *mctx, dns_rbt_t *rbt, isc_rwlock_t *rwlock, > + rbt_iterator_t *iter, dns_name_t *nodename); > + > +isc_result_t > +rbt_iter_next(rbt_iterator_t *iter, dns_name_t *nodename); > + > +void > +rbt_iter_stop(rbt_iterator_t *iter); > + > +#endif /* !_LD_RBT_HELPER_H_ */ > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Apr 2 15:18:53 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 2 Apr 2013 17:18:53 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <514C4880.6000203@redhat.com> References: <514C4880.6000203@redhat.com> Message-ID: <20130402151852.GC21126@redhat.com> On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: > Hello, > > this patch set separates master zones (idnsZone objectClass) from > forward zones (idnsForwardZone objectClass). Support for forward > zones in idnsZone objectClass is still present to ease upgrades. > > See each commit message for all the gory details. > > -- > Petr^2 Spacek Ack for patch 0124. > From 005707761a5b99d50871de91252f9f23a7441d19 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 22 Mar 2013 12:19:02 +0100 > Subject: [PATCH] Add missing includes to util.h. > > Now include "util.h" should be enough for util.h usage. > > Signed-off-by: Petr Spacek > --- > src/util.h | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/src/util.h b/src/util.h > index d6d3c73e6d25657805eee904e6047c542e52a656..17a3f3b4ca65ab4a80c4e4fcc9ea909bb7a9178c 100644 > --- a/src/util.h > +++ b/src/util.h > @@ -21,10 +21,17 @@ > #ifndef _LD_UTIL_H_ > #define _LD_UTIL_H_ > > -extern isc_boolean_t verbose_checks; /* from settings.c */ > +#include > + > +#include > +#include > +#include > +#include > > #include "log.h" > > +extern isc_boolean_t verbose_checks; /* from settings.c */ > + > #define CLEANUP_WITH(result_code) \ > do { \ > result = (result_code); \ > -- > 1.7.11.7 -- Adam Tkac, Red Hat, Inc. From mkosek at redhat.com Tue Apr 2 15:20:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Apr 2013 17:20:50 +0200 Subject: [Freeipa-devel] [PATCH] 378-380 Improved CNAME and DNAME validation In-Reply-To: <515AF0FF.7050902@redhat.com> References: <5135D5BC.5030909@redhat.com> <5135DF5A.4040902@redhat.com> <5136FF15.6080505@redhat.com> <5137318A.2010505@redhat.com> <513DA347.8040100@redhat.com> <515AAB7B.4010506@redhat.com> <515AAEF2.3070103@redhat.com> <515AF0FF.7050902@redhat.com> Message-ID: <515AF752.1040305@redhat.com> On 04/02/2013 04:53 PM, Ana Krivokapic wrote: > On 04/02/2013 12:12 PM, Martin Kosek wrote: >> On 04/02/2013 11:57 AM, Ana Krivokapic wrote: >>> On 03/11/2013 10:26 AM, Martin Kosek wrote: >>>> On 03/06/2013 01:07 PM, Petr Spacek wrote: >>>>> On 6.3.2013 09:32, Martin Kosek wrote: >>>>>> + error=u'CNAME record is not allowed to coexist with any >>>>>> other record'), >>>>> Sorry for nitpicking again, but I would add note '(RFC 1034, section 3.6.2)'. >>>>> >>>>> Thank you! >>>>> >>>> Fixed. >>>> >>>> Martin >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Patches 379 and 380 need rebasing. >>> >>> -- >>> Regards, >>> >>> Ana Krivokapic >>> Associate Software Engineer >>> FreeIPA team >>> Red Hat Inc. >>> >> Rebased patches attached. >> >> Martin > > The first patch (schema update) correctly changes both CNAME and DNAME > attributes to single valued attributes. > > I tested the newly introduced validation rules, trying to add: > * more than 1 cname record with the same name > * cname + ptr > * cname + dname > * cname + any other record > * more than 1 dname > * dname + ns > * dname + ns (root zone) > > As expected, validation fails for all the above cases except the last > one (dname + ns in the root zone). > > ACK > Thanks. Pushed to master. Martin From atkac at redhat.com Tue Apr 2 15:30:05 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 2 Apr 2013 17:30:05 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <514C4880.6000203@redhat.com> References: <514C4880.6000203@redhat.com> Message-ID: <20130402153004.GA21905@redhat.com> On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: > Hello, > > this patch set separates master zones (idnsZone objectClass) from > forward zones (idnsForwardZone objectClass). Support for forward > zones in idnsZone objectClass is still present to ease upgrades. > > See each commit message for all the gory details. > > -- > Petr^2 Spacek Ack for patch 125 as is. > From 48fb17f8242d2d5d71898758ef6e58f0341df3f3 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 22 Mar 2013 12:32:40 +0100 > Subject: [PATCH] Use new RBT iterators for zone deletion. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/99 > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 109 ++++++++++------------------------------------------ > src/ldap_helper.h | 4 ++ > src/zone_register.c | 44 +++++++++++++++++++-- > src/zone_register.h | 9 ++++- > 4 files changed, 74 insertions(+), 92 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 72105e6093cea7b0bc9fdfc96229afded7650dce..ed1b76857116579f9f9e8ce2fc1ef2af67c9608e 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -327,10 +327,6 @@ static isc_result_t modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_ > static isc_result_t soa_serial_increment(isc_mem_t *mctx, ldap_instance_t *inst, > dns_name_t *zone_name); > > -static isc_result_t > -ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock, > - isc_boolean_t preserve_forwarding); > - > /* Functions for maintaining pool of LDAP connections */ > static isc_result_t ldap_pool_create(isc_mem_t *mctx, unsigned int connections, > ldap_pool_t **poolp); > @@ -521,7 +517,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > CHECK(setting_get_bool("psearch", ldap_inst->local_settings, &psearch)); > CHECK(setting_get_uint("connections", ldap_inst->local_settings, &connections)); > > - CHECK(zr_create(mctx, ldap_inst->global_settings, > + CHECK(zr_create(mctx, ldap_inst, ldap_inst->global_settings, > &ldap_inst->zone_register)); > > CHECK(isc_mutex_init(&ldap_inst->kinit_lock)); > @@ -579,9 +575,6 @@ void > destroy_ldap_instance(ldap_instance_t **ldap_instp) > { > ldap_instance_t *ldap_inst; > - dns_rbtnodechain_t chain; > - dns_rbt_t *rbt = NULL; > - isc_result_t result = ISC_R_SUCCESS; > const char *db_name; > isc_sockaddr_t *addr; > > @@ -593,68 +586,6 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > > db_name = ldap_inst->db_name; /* points to DB instance: outside ldap_inst */ > > - /* > - * Unregister all zones already registered in BIND. > - * > - * NOTE: This should be probably done in zone_register.c > - */ > - if (ldap_inst->zone_register != NULL) > - rbt = zr_get_rbt(ldap_inst->zone_register); > - if (rbt == NULL) > - result = ISC_R_NOTFOUND; > - > - /* Potentially ISC_R_NOSPACE can occur. Destroy codepath has no way to > - * return errors, so kill BIND. > - * DNS_R_NAMETOOLONG should never happen, because all names were checked > - * while loading. */ > - > - dns_rbtnodechain_init(&chain, ldap_inst->mctx); > - while (result != ISC_R_NOMORE && result != ISC_R_NOTFOUND) { > - dns_fixedname_t name; > - dns_fixedname_t origin; > - dns_fixedname_t concat; > - dns_fixedname_init(&name); > - dns_fixedname_init(&origin); > - dns_fixedname_init(&concat); > - > - dns_rbtnodechain_reset(&chain); > - result = dns_rbtnodechain_first(&chain, rbt, NULL, NULL); > - RUNTIME_CHECK(result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN || > - result == ISC_R_NOTFOUND); > - > - /* Search for first zone in zone register and omit auxiliary nodes. */ > - while (result != ISC_R_NOMORE && result != ISC_R_NOTFOUND) { > - dns_rbtnode_t *node = NULL; > - > - result = dns_rbtnodechain_current(&chain, dns_fixedname_name(&name), > - dns_fixedname_name(&origin), &node); > - RUNTIME_CHECK(result == ISC_R_SUCCESS); > - > - if (node->data != NULL) { /* Auxiliary nodes have data == NULL. */ > - result = dns_name_concatenate(dns_fixedname_name(&name), > - dns_fixedname_name(&origin), > - dns_fixedname_name(&concat), > - NULL); > - RUNTIME_CHECK(result == ISC_R_SUCCESS); > - break; > - } > - > - result = dns_rbtnodechain_next(&chain, NULL, NULL); > - RUNTIME_CHECK(result == ISC_R_SUCCESS || result == DNS_R_NEWORIGIN || > - result == ISC_R_NOMORE); > - } > - if (result == ISC_R_NOMORE || result == ISC_R_NOTFOUND) > - break; > - > - result = ldap_delete_zone2(ldap_inst, > - dns_fixedname_name(&concat), > - ISC_TRUE, ISC_FALSE); > - RUNTIME_CHECK(result == ISC_R_SUCCESS); > - } > - > - dns_rbtnodechain_invalidate(&chain); > - > - /* TODO: Terminate psearch watcher sooner? */ > if (ldap_inst->watcher != 0) { > ldap_inst->exiting = ISC_TRUE; > /* > @@ -671,13 +602,15 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > ldap_inst->watcher = 0; > } > > + /* Unregister all zones already registered in BIND. */ > + zr_destroy(&ldap_inst->zone_register); > + fwdr_destroy(&ldap_inst->fwd_register); > + > ldap_pool_destroy(&ldap_inst->pool); > dns_view_detach(&ldap_inst->view); > > DESTROYLOCK(&ldap_inst->kinit_lock); > > - zr_destroy(&ldap_inst->zone_register); > - > while (!ISC_LIST_EMPTY(ldap_inst->orig_global_forwarders.addrs)) { > addr = ISC_LIST_HEAD(ldap_inst->orig_global_forwarders.addrs); > ISC_LIST_UNLINK(ldap_inst->orig_global_forwarders.addrs, addr, link); > @@ -853,6 +786,22 @@ configure_zone_ssutable(dns_zone_t *zone, const char *update_str) > > /* Delete zone by dns zone name */ > static isc_result_t > +delete_forwarding_table(ldap_instance_t *inst, dns_name_t *name, > + const char *msg_obj_type, const char *dn) { > + isc_result_t result; > + > + result = dns_fwdtable_delete(inst->view->fwdtable, name); > + if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) { > + log_error_r("%s '%s': failed to delete forwarders", > + msg_obj_type, dn); > + return result; > + } else { > + return ISC_R_SUCCESS; /* ISC_R_NOTFOUND = nothing to delete */ > + } > +} > + > +/* Delete zone by dns zone name */ > +isc_result_t > ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock, > isc_boolean_t preserve_forwarding) > { > @@ -941,22 +890,6 @@ cleanup: > return result; > } > > -static isc_result_t > -delete_forwarding_table(ldap_instance_t *inst, dns_name_t *name, > - const char *msg_obj_type, const char *dn) { > - isc_result_t result; > - > - /* Clean old fwdtable. */ > - result = dns_fwdtable_delete(inst->view->fwdtable, name); > - if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) { > - log_error_r("%s '%s': failed to delete forwarders", > - msg_obj_type, dn); > - return result; > - } else { > - return ISC_R_SUCCESS; /* ISC_R_NOTFOUND = nothing to delete */ > - } > -} > - > /** > * Read forwarding policy (from idnsForwardingPolicy attribute) and > * list of forwarders (from idnsForwarders multi-value attribute) > diff --git a/src/ldap_helper.h b/src/ldap_helper.h > index 86c3d4ec040a073df8c89d67b93cbd9e1b3bfb77..fe54687fa1e8ec16d83105e08e1a17cdec68614e 100644 > --- a/src/ldap_helper.h > +++ b/src/ldap_helper.h > @@ -84,6 +84,10 @@ void destroy_ldap_instance(ldap_instance_t **ldap_inst); > isc_result_t > refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only); > > +isc_result_t > +ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock, > + isc_boolean_t preserve_forwarding); > + > /* Functions for writing to LDAP. */ > isc_result_t write_to_ldap(dns_name_t *owner, ldap_instance_t *ldap_inst, > dns_rdatalist_t *rdlist); > diff --git a/src/zone_register.c b/src/zone_register.c > index e8d844f7bd1de83a6c894ea18fed127af081fd0f..949219ffc2e2adb40943709a3420014e672c88e6 100644 > --- a/src/zone_register.c > +++ b/src/zone_register.c > @@ -35,6 +35,7 @@ > #include "zone_register.h" > #include "rdlist.h" > #include "settings.h" > +#include "rbt_helper.h" > > /* > * The zone register is a red-black tree that maps a dns name of a zone to the > @@ -50,6 +51,7 @@ struct zone_register { > isc_rwlock_t rwlock; > dns_rbt_t *rbt; > settings_set_t *global_settings; > + ldap_instance_t *ldap_inst; > }; > > typedef struct { > @@ -88,6 +90,15 @@ static const setting_t zone_settings[] = { > end_of_settings > }; > > +isc_result_t > +zr_rbt_iter_init(zone_register_t *zr, rbt_iterator_t *iter, > + dns_name_t *nodename) { > + if (zr->rbt == NULL) > + return ISC_R_NOTFOUND; > + > + return rbt_iter_first(zr->mctx, zr->rbt, &zr->rwlock, iter, nodename); > +} > + > dns_rbt_t * > zr_get_rbt(zone_register_t *zr) > { > @@ -105,19 +116,23 @@ zr_get_mctx(zone_register_t *zr) { > * Create a new zone register. > */ > isc_result_t > -zr_create(isc_mem_t *mctx, settings_set_t *glob_settings, zone_register_t **zrp) > +zr_create(isc_mem_t *mctx, ldap_instance_t *ldap_inst, > + settings_set_t *glob_settings, zone_register_t **zrp) > { > isc_result_t result; > zone_register_t *zr = NULL; > > + REQUIRE(ldap_inst != NULL); > + REQUIRE(glob_settings != NULL); > REQUIRE(zrp != NULL && *zrp == NULL); > > CHECKED_MEM_GET_PTR(mctx, zr); > ZERO_PTR(zr); > isc_mem_attach(mctx, &zr->mctx); > CHECK(dns_rbt_create(mctx, delete_zone_info, mctx, &zr->rbt)); > CHECK(isc_rwlock_init(&zr->rwlock, 0, 0)); > zr->global_settings = glob_settings; > + zr->ldap_inst = ldap_inst; > > *zrp = zr; > return ISC_R_SUCCESS; > @@ -132,19 +147,42 @@ cleanup: > return result; > } > > -/* > - * Destroy a zone register. > +/** > + * Destroy a zone register and unload all zones registered in it. > + * > + * @warning > + * Potentially ISC_R_NOSPACE can occur. Destroy codepath has no way to > + * return errors, so kill BIND. DNS_R_NAMETOOLONG should never happen, > + * because all names were checked while loading. > */ > void > zr_destroy(zone_register_t **zrp) > { > + DECLARE_BUFFERED_NAME(name); > zone_register_t *zr; > + rbt_iterator_t iter; > + isc_result_t result; > > if (zrp == NULL || *zrp == NULL) > return; > > zr = *zrp; > > + /* It is not safe to iterate over RBT and delete nodes at the same > + * time. Restart iteration after each change. */ > + do { > + INIT_BUFFERED_NAME(name); > + result = zr_rbt_iter_init(zr, &iter, &name); > + RUNTIME_CHECK(result == ISC_R_SUCCESS || result == ISC_R_NOTFOUND); > + if (result == ISC_R_SUCCESS) { > + rbt_iter_stop(&iter); > + result = ldap_delete_zone2(zr->ldap_inst, > + &name, > + ISC_TRUE, ISC_FALSE); > + RUNTIME_CHECK(result == ISC_R_SUCCESS); > + } > + } while (result == ISC_R_SUCCESS); > + > RWLOCK(&zr->rwlock, isc_rwlocktype_write); > dns_rbt_destroy(&zr->rbt); > RWUNLOCK(&zr->rwlock, isc_rwlocktype_write); > diff --git a/src/zone_register.h b/src/zone_register.h > index 3f4114d2256c1e8af5f67c69f1829900c9c7b2e9..7ef40f7abdf4ed17cb32414907b5b7283456bb22 100644 > --- a/src/zone_register.h > +++ b/src/zone_register.h > @@ -23,11 +23,14 @@ > > #include "cache.h" > #include "settings.h" > +#include "rbt_helper.h" > +#include "ldap_helper.h" > > typedef struct zone_register zone_register_t; > > isc_result_t > -zr_create(isc_mem_t *mctx, settings_set_t *glob_settings, zone_register_t **zrp); > +zr_create(isc_mem_t *mctx, ldap_instance_t *ldap_inst, > + settings_set_t *glob_settings, zone_register_t **zrp); > > void > zr_destroy(zone_register_t **zrp); > @@ -54,6 +57,10 @@ zr_get_zone_ptr(zone_register_t *zr, dns_name_t *name, dns_zone_t **zonep); > isc_result_t > zr_get_zone_settings(zone_register_t *zr, dns_name_t *name, settings_set_t **set); > > +isc_result_t > +zr_rbt_iter_init(zone_register_t *zr, rbt_iterator_t *iter, > + dns_name_t *nodename); > + > dns_rbt_t * > zr_get_rbt(zone_register_t *zr); > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pviktori at redhat.com Tue Apr 2 15:33:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 02 Apr 2013 17:33:06 +0200 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515A22D2.9060106@REDHAT.COM> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> <515581A8.7040902@redhat.com> <5155A7EF.50304@redhat.com> <515A22D2.9060106@REDHAT.COM> Message-ID: <515AFA32.5050704@redhat.com> On 04/02/2013 02:14 AM, Robert Relyea wrote: > On 03/29/2013 07:40 AM, John Dennis wrote: >> On 03/29/2013 07:57 AM, Petr Viktorin wrote: >>> On 03/27/2013 04:40 PM, John Dennis wrote: >>>> On 03/27/2013 11:23 AM, Petr Viktorin wrote: >>>>> I don't want to check the subject because this RFE was prompted by >>>>> IPA's >>>>> normal CA rejecting valid wildcart certs. Is there a reasonable way to >>>>> ask NSS if it will trust the cert? >>>> >>>> Yes. NSS provides a variety of tools to test validation. >>>> >>>> Going just on memory here, our current version of python-nss has a >>>> simple call to test validation. Sometime in the last year I added a >>>> fair >>>> amount of new support for certificate validation including getting back >>>> diagnostic information for validation failures, however if I recall >>>> correctly the extended functionality in python-nss has not been >>>> released >>>> yet. >>> >>> Does the new code include downloading and importing CRLs? >> >> Cert verification is a complex topic. This is further exacerbated by >> the introduction of PKIX. My understanding is NSS had "classic" >> verification code and later introduced PKIX. There has been an >> evolution between classic verification and PKIX. This is outside my >> domain of expertise. How and when CRL's are loaded in NSS is not >> something I can give advice on, especially in an area undergoing change. >> >> I'm going to have to defer to an expert in this area, Bob Relyea, I've >> CC'ed him on this email. > It's hard to get the context in the middle, and and John had noted, NSS > is transitioning from the old Cert_Verify interface to the new PKIX_ code. > > I'll answer the question for the traditional CERTVerify code, which is > the only you get in SSL by default, and the one most people still use: > > No, CRLs are not downloaded and imported automatically, but if you > download and import CRL's, NSS will use them. There's an installable > PKCS #11 module which can be configured to download and install CRLs, > then provide them to NSS. It's call mod_revocator. > > The expected revocation strategy NSS uses is OCSP, and you can turn on > automatic OCSP fetching. > >> Bob, to put this in context [1] the functionality in python-nss being >> discussed is the binding of the CERT_VerifyCertificate() function, >> something I added recently. Now the question arises as to how CRL's >> are meant to play into the verification process. Can you please >> explain how NSS expects this to be done? Pointers to existing >> documentation and code examples would also be helpful. > > There's a separate CERT_ImportCRL() which will import the CRL into the > database. mod_revocator() can also be used to do the fetching for you, > Matthew has examples on how various servers set them up (I believe the > only NSS set up is installing the module in your secmod.db/pkcs11.txt > with modutil. > >> >> It would also be helpful to understand the PKIX roadmap and how this >> might affect coding decisions at the API level. > > the PKIX interface is available now, and is actually used by Chrome (for > all certs) and Firefox (for ev processing). Firefox is in the process of > moving to libpkix for everything. There is an environment variable you > can set (I don't remember it specifically, but I could look it up for > you if you want) that will cause the transitional > CERT_VerifyCertificate() interface to use the libpkix engine, but it > keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert > fetching).. > > With libpkix, the revocation options are quite broad and complexed. We > really expect people would use a set of preconfigured policies, though > libpkix API allows for quite some variance. It would take me some time > to dig up all the descriptions, but I can if you want them. > >> [1] Some additional context, the original motivation for exposing NSS >> cert verification to IPA was to solve the following problem. If >> someone wants to make the IPA CA a sub-CA (as opposed to a self-signed >> CA) we want to validate the externally provided CA cert *before* >> proceeding with the IPA installation. This is because if the CA cert >> is invalid everything will hugely blow-up (because we use the CA cert >> to sign all the certs issued in IPA, especially those used to validate >> cooperating components/agents, if those certs do not work nothing in >> IPA works). In addition to this narrow goal we in general want to be >> able to perform cert verification correctly in other contexts as well >> so the extent to which you can educate us in general on this topic >> will be appreciated. > OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless > you specifically need some of the advanced libpkix features. The original context is sanity checking: is a SSL server cert we get from a user valid? If it is then we install the corresponding server. Requirements here are: - No extra information from the user, other than the cert itself (the admin gives us a cert, we don't want to ask how to find out if it's valid) - It needs to be a simple call/tool, since there's little gain over just documenting that we want good certs. So it looks it's not worth it to go there. The new context, as far as I understand, is cert validation in *clients*. We connect to a server; how to find out if its cert is valid? In contrast to the sanity checking, we can have complexity and config options here. This is important to get right, and we don't want any assumptions (other than that everything is under some wacky corporate policy). It looks like libpkix is the way to go here. I assume Python bindings aren't available for it yet? -- Petr? From pspacek at redhat.com Tue Apr 2 15:56:23 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 17:56:23 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <20130402151709.GA21126@redhat.com> References: <514C4880.6000203@redhat.com> <20130402151709.GA21126@redhat.com> Message-ID: <515AFFA7.2070909@redhat.com> On 2.4.2013 17:17, Adam Tkac wrote: > On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: >> Hello, >> >> this patch set separates master zones (idnsZone objectClass) from >> forward zones (idnsForwardZone objectClass). Support for forward >> zones in idnsZone objectClass is still present to ease upgrades. >> >> See each commit message for all the gory details. > > Since patches are non-trivial, I will review them "per partes" (i.e. each patch > in separate mail). Please check my comments below. > > Regards, Adam > >> From d0c598ea7e9c02a1ec786c6f1c596ae1be7ac1e2 Mon Sep 17 00:00:00 2001 >> From: Petr Spacek >> Date: Fri, 22 Mar 2013 12:17:07 +0100 >> Subject: [PATCH] Add helper functions for generic iteration over RBT. >> >> https://fedorahosted.org/bind-dyndb-ldap/ticket/99 >> >> Signed-off-by: Petr Spacek >> --- >> src/rbt_helper.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> src/rbt_helper.h | 29 +++++++++++ >> 2 files changed, 179 insertions(+) >> create mode 100644 src/rbt_helper.c >> create mode 100644 src/rbt_helper.h >> >> diff --git a/src/rbt_helper.c b/src/rbt_helper.c >> new file mode 100644 >> index 0000000000000000000000000000000000000000..70ab06134694e36a6ae049284d506bbf5bc3a977 >> --- /dev/null >> +++ b/src/rbt_helper.c >> @@ -0,0 +1,150 @@ >> +#include >> + >> +#include "rbt_helper.h" >> + >> +#define LDAPDB_RBTITER_MAGIC ISC_MAGIC('L', 'D', 'P', 'I') >> + >> +/** >> + * Copy the RBT node name, i.e. copies the name pointed to by RBT iterator. >> + * >> + * @param[in] iter Initialized RBT iterator. >> + * @param[out] nodename Target dns_name suitable for rbt_fullnamefromnode() call. >> + * >> + * @pre Nodename has pre-allocated storage space. >> + * >> + * @retval ISC_R_SUCCESS Actual name was copied to nodename. >> + * @retval ISC_R_NOTFOUND Iterator doesn't point to any node. >> + * @retval DNS_R_EMPTYNAME Iterator points to name without assigned data, >> + * nodename is unchanged. >> + * @retval others Errors from dns_name_concatenate() and others. >> + * >> + */ >> +static isc_result_t >> +rbt_iter_getnodename(rbt_iterator_t *iter, dns_name_t *nodename) { >> + isc_result_t result; >> + dns_rbtnode_t *node = NULL; >> + >> + REQUIRE(iter != NULL); >> + REQUIRE(nodename != NULL); >> + REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); >> + >> + CHECK(dns_rbtnodechain_current(&iter->chain, NULL, NULL, &node)); >> + if (node->data == NULL) >> + return DNS_R_EMPTYNAME; >> + >> + CHECK(dns_rbt_fullnamefromnode(node, nodename)); >> + result = ISC_R_SUCCESS; >> + >> +cleanup: >> + return result; >> +} >> + >> +/** >> + * Initialize RBT iterator, lock RBT and copy name of the first node with >> + * non-NULL data. Empty RBT nodes (with data == NULL) are ignored. >> + * >> + * RBT remains locked after iterator initialization. RBT has to be >> + * unlocked by reaching end of iteration or explicit rbt_iter_stop() call. >> + * >> + * @param[in,out] rwlock guard for RBT, will be read-locked >> + * @param[out] iter iterator structure, will be initialized >> + * @param[out] nodename dns_name with pre-allocated storage >> + * >> + * @pre Nodename has pre-allocated storage space. >> + * >> + * @retval ISC_R_SUCCESS Node with non-NULL data found, >> + * RBT is in locked state, iterator is valid, >> + * nodename holds copy of actual RBT node name. >> + * @retval ISC_R_NOTFOUND Node with non-NULL data is not present, >> + * RBT is in unlocked state, iterator is invalid. >> + * @retval others Any error from rbt_iter_getnodename() and >> + * rbt_iter_next(). >> + */ >> +isc_result_t >> +rbt_iter_first(isc_mem_t *mctx, dns_rbt_t *rbt, isc_rwlock_t *rwlock, >> + rbt_iterator_t *iter, dns_name_t *nodename) { >> + >> + isc_result_t result; >> + >> + REQUIRE(rbt != NULL); >> + REQUIRE(rwlock != NULL); >> + REQUIRE(iter != NULL); >> + >> + ZERO_PTR(iter); >> + >> + isc_mem_attach(mctx, &iter->mctx); >> + dns_rbtnodechain_init(&iter->chain, mctx); >> + iter->rbt = rbt; >> + iter->rwlock = rwlock; >> + iter->locktype = isc_rwlocktype_read; >> + iter->magic = LDAPDB_RBTITER_MAGIC; >> + >> + RWLOCK(iter->rwlock, iter->locktype); >> + >> + result = dns_rbtnodechain_first(&iter->chain, rbt, NULL, NULL); >> + if (result != DNS_R_NEWORIGIN) { >> + rbt_iter_stop(iter); >> + return result; > > I would substitute those two lines with "goto cleanup;". > >> + } >> + >> + result = rbt_iter_getnodename(iter, nodename); >> + if (result == DNS_R_EMPTYNAME) >> + result = rbt_iter_next(iter, nodename); >> + if (result == ISC_R_NOMORE) >> + result = ISC_R_NOTFOUND; > > In my opinion this function should leave rbt in locked state only when it > returns ISC_R_SUCCESS. All other cases should unlock the tree. I recommend to > add this statement: > > cleanup: > if (result != ISC_R_SUCCESS) > rbt_iter_stop(iter); > >> + >> + return result; >> +} >> + >> +/** >> + * Copy name of the next non-empty node in RBT. >> + * >> + * @param[in] iter valid iterator >> + * @param[out] nodename dns_name with pre-allocated storage >> + * >> + * @pre Nodename has pre-allocated storage space. >> + * >> + * @retval ISC_R_SUCCESS Nodename holds independent copy of RBT node name, >> + * RBT is in locked state. >> + * @retval ISC_R_NOMORE Iteration ended, RBT is in unlocked state, >> + * iterator is no longer valid. >> + * @retval others Errors from dns_name_concatenate() and others. >> + */ >> +isc_result_t >> +rbt_iter_next(rbt_iterator_t *iter, dns_name_t *nodename) { >> + isc_result_t result; >> + >> + REQUIRE(iter != NULL); >> + REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); >> + REQUIRE(iter->locktype != isc_rwlocktype_none); >> + >> + do { >> + result = dns_rbtnodechain_next(&iter->chain, NULL, NULL); >> + if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) >> + goto cleanup; >> + >> + result = rbt_iter_getnodename(iter, nodename); >> + } while (result == DNS_R_EMPTYNAME); >> + >> +cleanup: >> + if (result != ISC_R_SUCCESS) >> + rbt_iter_stop(iter); > > I think rbt_iter_stop() shouldn't be called here. Imagine this piece of code: > > CHECK(rbt_iter_first(..)); > for (..) { > CHECK(isc_mem_alloc(..)); > CHECK(rbt_iter_next(..)); > } > > cleanup: > if (rbt_iter_first_was_called) > // Now you should call rbt_iter_stop() only when isc_mem_alloc fails > // but not when rbt_iter_next() fails. However how do you figure out > // which function failed? > > Due to this reason, I recommend to drop rbt_iter_stop() call from the > rbt_iter_next(). > >> + >> + return result; >> +} >> + >> +/** >> + * Stop RBT iteration and unlock RBT. >> + */ >> +void >> +rbt_iter_stop(rbt_iterator_t *iter) { >> + REQUIRE(iter != NULL); >> + REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); >> + >> + if (iter->locktype != isc_rwlocktype_none) >> + isc_rwlock_unlock(iter->rwlock, iter->locktype); >> + >> + dns_rbtnodechain_invalidate(&iter->chain); >> + isc_mem_detach(&(iter->mctx)); >> + ZERO_PTR(iter); >> +} >> diff --git a/src/rbt_helper.h b/src/rbt_helper.h >> new file mode 100644 >> index 0000000000000000000000000000000000000000..9c9bcd202cafafb39a3018bbafff6bbd3c9189a9 >> --- /dev/null >> +++ b/src/rbt_helper.h >> @@ -0,0 +1,29 @@ >> +#ifndef _LD_RBT_HELPER_H_ >> +#define _LD_RBT_HELPER_H_ >> + >> +#include >> +#include >> +#include "util.h" >> + >> +struct rbt_iterator { >> + unsigned int magic; >> + isc_mem_t *mctx; >> + dns_rbt_t *rbt; >> + isc_rwlock_t *rwlock; >> + isc_rwlocktype_t locktype; >> + dns_rbtnodechain_t chain; >> +}; > > There is no reason to have struct rbt_iterator exported in header if I read > patchset correctly. Please move it into rbt_helper.c and leave only typedef > below here. > >> + >> +typedef struct rbt_iterator rbt_iterator_t; >> + >> +isc_result_t >> +rbt_iter_first(isc_mem_t *mctx, dns_rbt_t *rbt, isc_rwlock_t *rwlock, >> + rbt_iterator_t *iter, dns_name_t *nodename); >> + >> +isc_result_t >> +rbt_iter_next(rbt_iterator_t *iter, dns_name_t *nodename); >> + >> +void >> +rbt_iter_stop(rbt_iterator_t *iter); >> + >> +#endif /* !_LD_RBT_HELPER_H_ */ >> -- >> 1.7.11.7 Discussion on IRC revealed that interface with 'rbt_iterator_t **iter' (instead of 'rbt_iterator_t *iter') will be cleaner and safer. I will prepare separate patch with this change. -- Petr^2 Spacek From mkosek at redhat.com Tue Apr 2 16:32:12 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 02 Apr 2013 18:32:12 +0200 Subject: [Freeipa-devel] Announcing FreeIPA 3.2.0 Prerelease 1 Message-ID: <515B080C.8000600@redhat.com> The FreeIPA team is proud to announce a first PRERELEASE of FreeIPA v3.2.0. We would like to welcome any early testers of this prerelase to provide us feedback and help us stabilize this feature release which we plan to release as final in the beginning of May 2013. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 19 Alpha, if it does not appear in your Fedora 19 yet, you can download the build from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=408311 == Highlights in 3.2.0 Prerelease 1 == === New features === * Support installing FreeIPA without an embedded Certificate Authority, with user-provided SSL certificates for the HTTP and Directory servers. [1] * New cert-find command. Search certificates in the Dogtag database based on their serial number, validity or revocation details. This feature is available both as a CLI command and Web UI page. [2] * New trustconfig-show and trustconfig-mod command. Show or modify AD Trust settings generated during AD Trust installation (ipa-adtrust-install) [3] * Multiple FreeIPA servers can now be designated as Domain Controllers for trusts with Active Directory [12] * New realmdomains-show and realmdomains-mod command. Manage list of DNS domains associated with FreeIPA realm (realmdomains sommand). This list is primarily used by AD, which can pull all domains managed by FreeIPA and use that list for routing authentication requests for domains which do not match FreeIPA realm name. [4] * Support trusted domain users in HBAC test command (hbactest command). * Allow filtering incoming trusted domain SIDs per-trust (trust-mod command). [5] * Configurable PAC type for services. Service commands can now configure a set of PAC types (MS-PAC, PAD, no PAC) that are supported and handled for the service. * Faster UI loading. FreeIPA Web UI application is now packaged in minimalized format. FreeIPA web server is now also able to transmit data in compressed format. [6] [7] * UI now accepts confirmation of cancel of its dialogs via keyboard [11] * Client reenrollment. A host that has been recreated can now be reenrolled to FreeIPA server using a backed up host keytab or admin credentials [8] * Service and Host commands now provide options to add or remove selected Kerberos flags [9] === Prerelease 1 limitations === * List of DNS domains associated with FreeIPA realm currently only works with a special Samba build available for Fedora 18: http://koji.fedoraproject.org/koji/taskinfo?taskID=5184105. One needs to rebuild FreeIPA 3.2.0 prerelease 1 against this Samba version in order to get it working. * Test of trusted domain users in HBAC rules is accessible to only to members of 'Trust Admins' group due to privilege limitations * Same applies to any other trust-specific operations that require translation between user/group name and its security identifier (SID) === Bug fixes === * Fixed migration from OpenLDAP. FreeIPA is now able to migrate users and groups from OpenLDAP database instances. * Migration process is now also a lot faster and provides more debug output (to httpd error log). * SUDO rules disabled by sudorule-disable command are now removed from ou=sudoers compat tree without a need to restart 389 Directory Server instance. * Fixed LDAP schema upgrade when upgrading from a pre-2.2.0 release * Fixed server installation with external CA (--external-ca) * Consolidate on-line help system, show help without need of valid Kerberos credentials (ipa help) * New LDAP plugin (ipa_dns) has been added to add missing idnsSOASerial attribute for replicas which either do not have integrated DNS service enabled to which have disabled SOA serial autoincrement * LDAP lockout plugin has been fixed so that lockout policies are applied consistently both for LDAP binds and Kerberos authentication * ... and many others stabilization fixes, see Detailed changelog for full details == Changes in API or CLI == === Dropped --selfsign option === FreeIPA servers prior to 3.2.0 could be installed with --selfsign option. This configured the server with a NSS database based Certificate Authority with a selfsigned CA certificate and limited certificate operation support. This option was always intended for development or testing purposes only and was not intended for use in production. This release drops this option and deprecates the functionality. Current FreeIPA servers installed with --selfsigned option will still work, instructions on how to migrate to supported certificate options will be provided. FreeIPA servers version 3.2.0 and later supports the following 2 flavors of certificate management: * FreeIPA with pki-ca (dogtag) with either a self-signed certificate or with a certificate signed by external CA (--external-ca option) * FreeIPA with no pki-ca installed with certificates signed and provided by an external CA [1] === Dropped CSV support === FreeIPA client CLI supported CSV in some arguments so that multiple values could be added with just one convenient option: ipa permission-add some-perm --permissions=read,write --attrs=sn,cn ipa dnsrecord-add example.com --a-rec=10.0.0.1,10.0.0.2 CSV parsing however introduces great difficulty when trying to include a value with an embedded space in it. Escaping these values is not intuitive and made it very difficult to add such values. The level of effort in working around the CSV problems has come to the point where the benefits of it are outweighed by the problems which lead to decision to drop CSV support in CLI altogether [10]. There are several ways to workaround lack of CSV: Provide an argument multiple times on the command-line: ipa permission-add some-perm --permissions=read --permissions=write --attrs=sn --attrs=cn ipa dnsrecord-add example.com --a-rec=10.0.0.1 --a-rec=10.0.0.2 Let BASH do the expansion for you: ipa permission-add some-perm --permissions={read,write} --attrs={sn,cn} ipa dnsrecord-add example.com --a-rec={10.0.0.1,10.0.0.2} == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Documentation == * [1] http://www.freeipa.org/page/V3/CA-less_install * [2] http://www.freeipa.org/page/V3/Cert_find * [3] http://www.freeipa.org/page/V3/Trust_config_command * [4] http://www.freeipa.org/page/V3/Realm_Domains * [5] http://www.freeipa.org/page/V3/Configurable_SID_Blacklists * [6] http://www.freeipa.org/page/V3/WebUI_gzip_compression * [7] http://www.freeipa.org/page/V3/WebUI_build * [8] http://www.freeipa.org/page/V3/Forced_client_re-enrollment * [9] http://www.freeipa.org/page/V3/Kerberos_Flags * [10] http://www.freeipa.org/page/V3/Drop_CSV * [11] http://www.freeipa.org/page/V3/WebUI_keyboard_confirmation * [12] http://www.freeipa.org/page/V3/MultipleTrustServers == Detailed Changelog since 3.1.0 == Alexander Bokovoy (7): * Update plugin to upload CA certificate to LDAP * ipasam: use base scope when fetching domain information about own domain * ipaserver/dcerpc: enforce search_s without schema checks for GC searching * ipa-replica-manage: migrate to single_value after LDAPEntry updates * Process exceptions when talking to Dogtag * ipasam: add enumeration of UPN suffixes based on the realm domains * Enhance ipa-adtrust-install for domains with multiple IPA server Ana Krivokapic (10): * Raise ValidationError for incorrect subtree option. * Add crond as a default HBAC service * Take into consideration services when deleting replicas * Add list of domains associated to our realm to cn=etc * Improve error messages for external group members * Remove check for alphabetic only characters from domain name validation * Fix internal error for ipa show-mappings * Realm Domains page * Use default NETBIOS name in unattended ipa-adtrust-install * Add mkhomedir option to ipa-server-install and ipa-replica-install Brian Cook (1): * Add DNS Setup Prompt to Install JR Aquino (1): * Allow PKI-CA Replica Installs when CRL exceeds default maxber value Jakub Hrozek (1): * Allow ipa-replica-conncheck and ipa-adtrust-install to read krb5 includedir Jan Cholasta (24): * Pylint cleanup. * Drop ipapython.compat. * Add support for RFC 6594 SSHFP DNS records. * Raise ValidationError on invalid CSV values. * Run interactive_prompt callbacks after CSV values are split. * Add custom mapping object for LDAP entry data. * Add make_entry factory method to LDAPConnection. * Remove the Entity class. * Remove the Entry class. * Use the dn attribute of LDAPEntry to set/get DNs of entries. * Preserve case of attribute names in LDAPEntry. * Aggregate IPASimpleLDAPObject in LDAPEntry. * Support attributes with multiple names in LDAPEntry. * Use full DNs in plugin code. * Remove DN normalization from the baseldap plugin. * Remove support for DN normalization from LDAPClient. * Fix remove while iterating in suppress_netgroup_memberof. * Remove disabled entries from sudoers compat tree. * Fix internal error in output_for_cli method of sudorule_{enable,disable}. * Do not fail if schema cannot be retrieved from LDAP server. * Allow disabling LDAP schema retrieval in LDAPClient and IPAdmin. * Allow disabling attribute decoding in LDAPClient and IPAdmin. * Disable schema retrieval and attribute decoding when talking to AD GC. * Add Kerberos ticket flags management to service and host plugins. John Dennis (2): * Cookie Expires date should be locale insensitive * Use secure method to acquire IPA CA certificate Lynn Root (4): * Switch %r specifiers to '%s' in Public errors * Added the ability to do Beta versioning * Fixed the catch of the hostname option during ipa-server-install * Raise ValidationError when CSR does not have a subject hostname Martin Kosek (58): * Add Lynn Root to Contributors.txt * Enable SSSD on client install * Fix delegation-find command --group handling * Do not crash when Kerberos SRV record is not found * permission-find no longer crashes with --targetgroup * Avoid CRL migration error message * Sort LDAP updates properly * Upgrade process should not crash on named restart * Installer should not connect to 127.0.0.1 * Fix migration for openldap DS * Remove unused krbV imports * Use fully qualified CCACHE names * Fix permission_find test error * Add trusconfig-show and trustconfig-mod commands * ipa-kdb: add sentinel for LDAPDerefSpec allocation * ipa-kdb: avoid ENOMEM when all SIDs are filtered out * ipa-kdb: reinitialize LDAP configuration for known realms * Add SID blacklist attributes * ipa-kdb: read SID blacklist from LDAP * ipa-sam: Fill SID blacklist when trust is added * ipa-adtrust-install should ask for SID generation * Test NetBIOS name clash before creating a trust * Generalize AD GC search * Do not hide SID resolver error in group-add-member * Add support for AD users to hbactest command * Fix hbachelp examples formatting * ipa-kdb: remove memory leaks * ipa-kdb: fix retry logic in ipadb_deref_search * Add autodiscovery section in ipa-client-install man pages * Avoid internal error when user is not Trust admin * Use fixed test domain in realmdomains test * Bump FreeIPA version for development branch * Remove ORDERING for IA5 attributeTypes * Fix includedir directive in krb5.conf template * Use new 389-ds-base cleartext password API * Do not hide idrange-add errors when adding trust * Preserve order of servers in ipa-client-install * Avoid multiple client discovery with fixed server list * Update named.conf parser * Use tkey-gssapi-keytab in named.conf * Do not force named connections on upgrades * ipa-client discovery with anonymous access off * Use temporary CCACHE in ipa-client-install * Improve client install LDAP cert retrieval fallback * Configure ipa_dns DS plugin on install and upgrade * Fix structured DNS record output * Bump selinux-policy requires * Clean spec file for Fedora 19 * Remove build warnings * Remove syslog.target from ipa.server * Put pid-file to named.conf * Update mod_wsgi socket directory * Normalize RA agent certificate * Require 389-base-base 1.3.0.5 * Change CNAME and DNAME attributes to single valued * Improve CNAME record validation * Improve DNAME record validation * Become 3.2.0 Prerelease 1 Petr Spacek (1): * Add 389 DS plugin for special idnsSOASerial attribute handling Petr Viktorin (101): * Sort Options and Outputs in API.txt * Add the CA cert to LDAP after the CA install * Better logging for AdminTool and ipa-ldap-updater * Port ipa-replica-prepare to the admintool framework * Make ipapython.dogtag log requests at debug level, not info * Don't add another nsDS5ReplicaId on updates if one already exists * Improve `ipa --help` output * Print help to stderr on error * Store the OptionParser in the API, use it to print unified help messages * Simplify `ipa help topics` output * Add command summary to `ipa COMMAND --help` output * Mention `ipa COMMAND --help` as the preferred way to get command help * Parse command arguments before creating a context * Add tests for the help command & --help options * In topic help text, mention how to get help for commands * Check SSH connection in ipa-replica-conncheck * Use ipauniqueid for the RDN of sudo commands * Prevent a sudo command from being deleted if it is a member of a sudo rule * Update sudocmd ACIs to use targetfilter * Add the version option to all Commands * Add ipalib.messages * Add client capabilities, enable messages * Rename the "messages" Output of the i18n_messages command to "texts" * Fix permission validation and normalization in aci.py * Remove csv_separator and csv_skipspace Param arguments * Drop support for CSV in the CLI client * Update argument docs to reflect dropped CSV support * Update plugin docstrings (topic help) to reflect dropped CSV support * cli: Do interactive prompting after a context is created * Remove some unused imports * Remove unused methods from Entry, Entity, and IPAdmin * Derive Entity class from Entry, and move it to ldapupdate * Use explicit loggers in ldap2 code * Move LDAPEntry to ipaserver.ipaldap and derive Entry from it * Remove connection-creating code from ShemaCache * Move the decision to force schema updates out of IPASimpleLDAPObject * Move SchemaCache and IPASimpleLDAPObject to ipaserver.ipaldap * Start LDAPConnection, a common base for ldap2 and IPAdmin * Make IPAdmin not inherit from IPASimpleLDAPObject * Move schema-related methods to LDAPConnection * Move DN handling methods to LDAPConnection * Move filter making methods to LDAPConnection * Move entry finding methods to LDAPConnection * Remove unused proxydn functionality from IPAdmin * Move entry add, update, remove, rename to LDAPConnection * Implement some of IPAdmin's legacy methods in terms of LDAPConnection methods * Replace setValue by keyword arguments when creating entries * Use update_entry with a single entry in adtrustinstance * Replace entry.getValues() by entry.get() * Replace entry.setValue/setValues by item assignment * Replace add_s and delete_s by their newer equivalents * Change {add,update,delete}_entry to take LDAPEntries * Remove unused imports from ipaserver/install * Remove unused bindcert and bindkey arguments to IPAdmin * Turn the LDAPError handler into a context manager * Remove dbdir, binddn, bindpwd from IPAdmin * Remove IPAdmin.updateEntry calls from fix_replica_agreements * Remove IPAdmin.get_dns_sorted_by_length * Replace IPAdmin.checkTask by replication.wait_for_task * Introduce LDAPEntry.single_value for getting single-valued attributes * Remove special-casing for missing and single-valued attributes in LDAPUpdate._entry_to_entity * Replace entry.getValue by entry.single_value * Replace getList by a get_entries method * Remove toTupleList and attrList from LDAPEntry * Rename LDAPConnection to LDAPClient * Replace addEntry with add_entry * Replace deleteEntry with delete_entry * Fix typo and traceback suppression in replication.py * replace getEntry with get_entry (or get_entries if scope != SCOPE_BASE) * Inline inactivateEntry in its only caller * Inline waitForEntry in its only caller * Proxy LDAP methods explicitly rather than using __getattr__ * Remove search_s and search_ext_s from IPAdmin * Replace IPAdmin.start_tls_s by an __init__ argument * Remove IPAdmin.sasl_interactive_bind_s * Remove IPAdmin.simple_bind_s * Remove IPAdmin.unbind_s(), keep unbind() * Use ldap instead of _ldap in ipaldap * Do not use global variables in migration.py * Use IPAdmin rather than raw python-ldap in migration.bind * Use IPAdmin rather than raw python-ldap in ipactl * Remove some uses of raw python-ldap * Improve LDAPEntry tests * Fix installing server with external CA * Change DNA magic value to -1 to make UID 999 usable * Move ipaldap to ipapython * Remove ipaserver/ipaldap.py * Use IPAdmin rather than raw python-ldap in ipa-client-install * Use IPAdmin rather than raw python-ldap in migration.py and ipadiscovery.py * Remove unneeded python-ldap imports * Don't download the schema in ipadiscovery * ipa-server-install: Make temporary pin files available for the whole installation * ipa-server-install: Remove the --selfsign option * Remove unused ipapython.certdb.CertDB class * ipaserver.install.certs: Introduce NSSDatabase as a more generic certutil wrapper * Trust CAs from PKCS#12 files even if they don't have Friendly Names * dsinstance, httpinstance: Don't hardcode 'Server-Cert' * Support installing with custom SSL certs, without a CA * Load the CA cert into server NSS databases * Do not call cert-* commands in host plugin if a RA is not available * ipa-client-install: Do not request host certificate if server is CA-less Petr Vobornik (38): * Make confirm_dialog a base class of revoke and restore certificate dialogs * Make confirm_dialog a base class for deleter dialog * Make confirm_dialog a base class for message_dialog * Confirm mixin * Confirm adder dialog by enter * Confirm error dialog by enter * Focus last dialog when some is closed * Confirm association dialogs by enter * Standardize login password reset, user reset password and host set OTP dialogs * Focus first input element after 'Add and Add another' * Enable mod_deflate * Use Uglify.js for JS optimization * Dojo Builder * Config files for builder of FreeIPA UI layer * Minimal Dojo layer * Web UI development environment directory structure and configuration * Web UI Sync development utility * Move of Web UI non AMD dep. libs to libs subdirectory * Move of core Web UI files to AMD directory * Update JavaScript Lint configuration file * AMD config file * Change Web UI sources to simple AMD modules * Updated makefiles to build FreeIPA Web UI layer * Change tests to use AMD loader * Fix BuildRequires: rhino replaced with java-1.7.0-openjdk * Develop.js extended * Allow to specify modules for which builder doesn't raise dependency error * Web UI build profile updated * Combobox keyboard support * Fix dirty state update of editable combobox * Fix handling of no_update flag in Web UI * Web UI: configurable SID blacklists * Web UI:Certificate pages * Web UI:Choose different search option for cert-find * Fixed Web UI build error caused by rhino changes in F19 * Nestable checkbox/radio widget * Added Web UI support for service PAC type option: NONE * Web UI: Disable cert functionality if a CA is not available Rob Crittenden (16): * Convert uniqueMember members into DN objects. * Add Ana Krivokapic to Contributors.txt * Do SSL CA verification and hostname validation. * Don't initialize NSS if we don't have to, clean up unused cert refs * Update anonymous access ACI to protect secret attributes. * Make certmonger a (pre) requires on server, restart it before upgrading * Use new certmonger locking to prevent NSS database corruption. * Improve migration performance * Add LDAP server fallback to client installer * Prevent a crash when no entries are successfully migrated. * Implement the cert-find command for the dogtag CA backend. * Add missing v3 schema on upgrades, fix typo in schema. * Don't base64-encode the CA cert when uploading it during an upgrade. * Extend ipa-replica-manage to be able to manage DNA ranges. * Improve some error handling in ipa-replica-manage * Fix lockout of LDAP bind. Simo Sorce (2): * Log info on failure to connect * Upload CA cert in the directory on install Sumit Bose (17): * ipa-kdb: remove unused variable * ipa-kdb: Uninitialized scalar variable in ipadb_reinit_mspac() * ipa-sam: Array compared against 0 in ipasam_set_trusted_domain() * ipa-kdb: Dereference after null check in ipa_kdb_mspac.c * ipa-lockout: Wrong sizeof argument in ipa_lockout.c * ipa-extdom: Double-free in ipa_extdom_common.c * ipa-pwd: Unchecked return value ipapwd_chpwop() * Revert "MS-PAC: Special case NFS services" * Add NFS specific default for authorization data type * ipa-kdb: Read global defaul ipaKrbAuthzData * ipa-kdb: Read ipaKrbAuthzData with other principal data * ipa-kdb: add PAC only if requested * Add unit test for get_authz_data_types() * Mention PAC issue with NFS in service plugin doc * Allow 'nfs:NONE' in global configuration * Add support for cmocka C-Unit Test framework * ipa-pwd-extop: do not use dn until it is really set Timo Aaltonen (1): * convert the base platform modules into packages Tomas Babej (18): * Relax restriction for leading/trailing whitespaces in *-find commands * Forbid overlapping rid ranges for the same id range * Fix a typo in ipa-adtrust-install help * Prevent integer overflow when setting krbPasswordExpiration * Add option to specify SID using domain name to idrange-add/mod * Prevent changing protected group's name using --setattr * Use default.conf as flag of IPA client being installed * Make sure appropriate exit status is returned in make-test * Make options checks in idrange-add/mod consistent * Add trusted domain range objectclass when using idrange-mod * Perform secondary rid range overlap check for local ranges only * Add support for re-enrolling hosts using keytab * Make sure uninstall script prompts for reboot as last * Remove implicit Str to DN conversion using *-attr * Enforce exact SID match when adding or modifying a ID range * Allow host re-enrollment using delegation * Add logging to join command * Properly handle ipa-replica-install when its zone is not managed by IPA sbose (1): * ipa-kdb: Free talloc autofree context when module is closed -- Martin Kosek Senior Software Engineer - Identity Management Team Red Hat Inc. From atkac at redhat.com Tue Apr 2 16:34:13 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 2 Apr 2013 18:34:13 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <514C4880.6000203@redhat.com> References: <514C4880.6000203@redhat.com> Message-ID: <20130402163412.GB21905@redhat.com> On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: > Hello, > > this patch set separates master zones (idnsZone objectClass) from > forward zones (idnsForwardZone objectClass). Support for forward > zones in idnsZone objectClass is still present to ease upgrades. > > See each commit message for all the gory details. Just check one comment below, otherwise ack. > From 71fc42de24d3709efbe7dee24973c1b456b37fe4 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 22 Mar 2013 12:38:55 +0100 > Subject: [PATCH] Add support for pure forward zones - idnsForwardZone > objectClass. > > Master zones are stored in zone_register and pure forward zones > are stored in fwd_register. > > This patch doesn't remove support for forward zones within > idnsZone objectClass. Support for forward zones in both > objectClasses enables incremental update, where old and new > plugin versions operate on the same LDAP database. > > Support for forward zones defined by idnsZone objectClass > will be removed in near future. > > Forward zones defined in idnsZone objectClass are not disabled > after removing from LDAP if persistent search is disabled > (see ticket #106). > This problem doesn't affect zones defined with idnsForwardZone > objectClass. > > https://fedorahosted.org/bind-dyndb-ldap/ticket/99 > > Signed-off-by: Petr Spacek > --- > src/Makefile.am | 4 + > src/fwd_register.c | 156 +++++++++++++++++++++++++ > src/fwd_register.h | 35 ++++++ > src/ldap_entry.c | 33 ++++-- > src/ldap_entry.h | 7 +- > src/ldap_helper.c | 334 ++++++++++++++++++++++++++++++++++------------------- > 6 files changed, 440 insertions(+), 129 deletions(-) > create mode 100644 src/fwd_register.c > create mode 100644 src/fwd_register.h > > diff --git a/src/Makefile.am b/src/Makefile.am > index 252255788b01e003031f5f0ee2fc8469b53633be..87c3252736fa4f918f105166497b32b0219ef8ea 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -5,11 +5,13 @@ HDRS = \ > acl.h \ > cache.h \ > compat.h \ > + fwd_register.h \ > krb5_helper.h \ > ldap_convert.h \ > ldap_entry.h \ > ldap_helper.h \ > log.h \ > + rbt_helper.h \ > rdlist.h \ > semaphore.h \ > settings.h \ > @@ -23,12 +25,14 @@ ldap_la_SOURCES = \ > $(HDRS) \ > acl.c \ > cache.c \ > + fwd_register.c \ > krb5_helper.c \ > ldap_convert.c \ > ldap_driver.c \ > ldap_entry.c \ > ldap_helper.c \ > log.c \ > + rbt_helper.c \ > rdlist.c \ > semaphore.c \ > settings.c \ > diff --git a/src/fwd_register.c b/src/fwd_register.c > new file mode 100644 > index 0000000000000000000000000000000000000000..c663b25909b0e393421c49950d1f29a1352cfe6c > --- /dev/null > +++ b/src/fwd_register.c > @@ -0,0 +1,156 @@ > +#include > +#include > + > +#include "rbt_helper.h" > +#include "fwd_register.h" > +#include "util.h" > + > +struct fwd_register { > + isc_mem_t *mctx; > + isc_rwlock_t rwlock; > + dns_rbt_t *rbt; > +}; > + > +isc_result_t > +fwdr_create(isc_mem_t *mctx, fwd_register_t **fwdrp) > +{ > + isc_result_t result; > + fwd_register_t *fwdr = NULL; > + > + REQUIRE(fwdrp != NULL && *fwdrp == NULL); > + > + CHECKED_MEM_GET_PTR(mctx, fwdr); > + ZERO_PTR(fwdr); > + isc_mem_attach(mctx, &fwdr->mctx); > + CHECK(dns_rbt_create(mctx, NULL, NULL, &fwdr->rbt)); > + CHECK(isc_rwlock_init(&fwdr->rwlock, 0, 0)); > + > + *fwdrp = fwdr; > + return ISC_R_SUCCESS; > + > +cleanup: > + if (fwdr != NULL) { > + if (fwdr->rbt != NULL) > + dns_rbt_destroy(&fwdr->rbt); > + MEM_PUT_AND_DETACH(fwdr); > + } > + > + return result; > +} > + > +void > +fwdr_destroy(fwd_register_t **fwdrp) > +{ > + fwd_register_t *fwdr; > + > + if (fwdrp == NULL || *fwdrp == NULL) > + return; > + > + fwdr = *fwdrp; > + > + RWLOCK(&fwdr->rwlock, isc_rwlocktype_write); > + dns_rbt_destroy(&fwdr->rbt); > + RWUNLOCK(&fwdr->rwlock, isc_rwlocktype_write); > + isc_rwlock_destroy(&fwdr->rwlock); > + MEM_PUT_AND_DETACH(fwdr); > + > + *fwdrp = NULL; > +} > + > +/* > + * Add forward zone to the forwarding register 'fwdr'. Origin of the zone > + * must be absolute and the zone cannot already be in the register. > + */ > +isc_result_t > +fwdr_add_zone(fwd_register_t *fwdr, dns_name_t *name) > +{ > + isc_result_t result; > + void *dummy = NULL; > + > + REQUIRE(fwdr != NULL); > + REQUIRE(name != NULL); > + > + if (!dns_name_isabsolute(name)) { > + log_bug("forward zone with bad origin"); > + return ISC_R_FAILURE; > + } > + > + RWLOCK(&fwdr->rwlock, isc_rwlocktype_write); > + > + /* > + * First make sure the node doesn't exist. Partial matches mean > + * there are also child zones in the LDAP database which is allowed. > + */ > + result = dns_rbt_findname(fwdr->rbt, name, 0, NULL, &dummy); > + if (result != ISC_R_NOTFOUND && result != DNS_R_PARTIALMATCH) { > + if (result == ISC_R_SUCCESS) > + result = ISC_R_EXISTS; > + log_error_r("failed to add forward zone to the forwarding register"); > + goto cleanup; > + } > + > + CHECK(dns_rbt_addname(fwdr->rbt, name, FORWARDING_SET_MARK)); > + > +cleanup: > + RWUNLOCK(&fwdr->rwlock, isc_rwlocktype_write); > + > + return result; > +} > + > +isc_result_t > +fwdr_del_zone(fwd_register_t *fwdr, dns_name_t *name) > +{ > + isc_result_t result; > + void *dummy = NULL; > + > + REQUIRE(fwdr != NULL); > + REQUIRE(name != NULL); > + > + RWLOCK(&fwdr->rwlock, isc_rwlocktype_write); > + > + result = dns_rbt_findname(fwdr->rbt, name, 0, NULL, (void **)&dummy); > + if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > + /* We are done */ > + CLEANUP_WITH(ISC_R_SUCCESS); > + } else if (result != ISC_R_SUCCESS) { > + goto cleanup; > + } > + > + CHECK(dns_rbt_deletename(fwdr->rbt, name, ISC_FALSE)); > + > +cleanup: > + RWUNLOCK(&fwdr->rwlock, isc_rwlocktype_write); > + > + return result; > +} > + > +isc_result_t > +fwdr_zone_ispresent(fwd_register_t *fwdr, dns_name_t *name) { > + > + isc_result_t result; > + void *dummy = NULL; > + > + REQUIRE(fwdr != NULL); > + REQUIRE(name != NULL); > + > + RWLOCK(&fwdr->rwlock, isc_rwlocktype_read); > + > + result = dns_rbt_findname(fwdr->rbt, name, 0, NULL, (void **)&dummy); > + if (result == DNS_R_PARTIALMATCH) > + CLEANUP_WITH(ISC_R_NOTFOUND); > + > +cleanup: > + RWUNLOCK(&fwdr->rwlock, isc_rwlocktype_read); > + > + return result; > +} > + > +isc_result_t > +fwdr_rbt_iter_init(fwd_register_t *fwdr, rbt_iterator_t *iter, > + dns_name_t *nodename) { > + if (fwdr->rbt == NULL) > + return ISC_R_NOTFOUND; > + > + return rbt_iter_first(fwdr->mctx, fwdr->rbt, &fwdr->rwlock, iter, > + nodename); > +} > diff --git a/src/fwd_register.h b/src/fwd_register.h > new file mode 100644 > index 0000000000000000000000000000000000000000..0bee3cba82d1deca1aa2fce235be118d076332f0 > --- /dev/null > +++ b/src/fwd_register.h > @@ -0,0 +1,35 @@ > +#ifndef _LD_FWD_REGISTER_H_ > +#define _LD_FWD_REGISTER_H_ > + > +#include > +#include > + > +#define FORWARDING_SET_MARK ((void *)1) > +/* > +#if FORWARDING_SET_MARK == NULL > + #error "FAIL!" > +#endif > +*/ > + > +typedef struct fwd_register fwd_register_t; > + > +isc_result_t > +fwdr_create(isc_mem_t *mctx, fwd_register_t **fwdrp); > + > +void > +fwdr_destroy(fwd_register_t **fwdrp); > + > +isc_result_t > +fwdr_add_zone(fwd_register_t *fwdr, dns_name_t *zone); > + > +isc_result_t > +fwdr_del_zone(fwd_register_t *fwdr, dns_name_t *zone); > + > +isc_result_t > +fwdr_zone_ispresent(fwd_register_t *fwdr, dns_name_t *name); > + > +isc_result_t > +fwdr_rbt_iter_init(fwd_register_t *fwdr, rbt_iterator_t *iter, > + dns_name_t *nodename); > + > +#endif /* !_LD_FWD_REGISTER_H_ */ > diff --git a/src/ldap_entry.c b/src/ldap_entry.c > index d32dc86ecc3af4866105bc96a6012d0ee964f4f5..3e82b39d31c7ed13255de61d0763800b4d01efef 100644 > --- a/src/ldap_entry.c > +++ b/src/ldap_entry.c > @@ -395,32 +395,51 @@ cleanup: > return result; > } > > -ldap_entryclass_t > -ldap_entry_getclass(ldap_entry_t *entry) > +isc_result_t > +ldap_entry_getclass(ldap_entry_t *entry, ldap_entryclass_t *class) > { > ldap_valuelist_t values; > ldap_value_t *val; > ldap_entryclass_t entryclass; > > REQUIRE(entry != NULL); > + REQUIRE(class != NULL); > > entryclass = LDAP_ENTRYCLASS_NONE; > > - /* XXX Can this happen? */ > + /* ObjectClass will be missing if search parameters didn't request > + * objectClass attribute. */ > if (ldap_entry_getvalues(entry, "objectClass", &values) > - != ISC_R_SUCCESS) > - return entryclass; > + != ISC_R_SUCCESS) { > + log_bug("entry without objectClass"); > + return ISC_R_UNEXPECTED; > + } > > for (val = HEAD(values); val != NULL; val = NEXT(val, link)) { > if (!strcasecmp(val->value, "idnsrecord")) > entryclass |= LDAP_ENTRYCLASS_RR; > else if (!strcasecmp(val->value, "idnszone")) > - entryclass |= LDAP_ENTRYCLASS_ZONE; > + entryclass |= LDAP_ENTRYCLASS_MASTER; > + else if (!strcasecmp(val->value, "idnsforwardzone")) > + entryclass |= LDAP_ENTRYCLASS_FORWARD; > else if (!strcasecmp(val->value, "idnsconfigobject")) > entryclass |= LDAP_ENTRYCLASS_CONFIG; > } > > - return entryclass; > + if (class == LDAP_ENTRYCLASS_NONE) { > + log_error("entry '%s' has no supported object class", > + entry->dn); > + return ISC_R_NOTIMPLEMENTED; > + > + } else if ((entryclass & LDAP_ENTRYCLASS_MASTER) && > + (entryclass & LDAP_ENTRYCLASS_FORWARD)) { > + log_error("zone '%s' has to have type either " > + "'master' or 'forward'", entry->dn); > + return ISC_R_UNEXPECTED; > + } > + > + *class = entryclass; > + return ISC_R_SUCCESS; > > #if 0 > /* Preserve current attribute iterator */ > diff --git a/src/ldap_entry.h b/src/ldap_entry.h > index 5a027e672b7591ae57551c175764e7517acea758..43a3824f1506e6f295379ae214ec355e59aab53c 100644 > --- a/src/ldap_entry.h > +++ b/src/ldap_entry.h > @@ -64,8 +64,9 @@ struct ldap_attribute { > > #define LDAP_ENTRYCLASS_NONE 0x0 > #define LDAP_ENTRYCLASS_RR 0x1 > -#define LDAP_ENTRYCLASS_ZONE 0x2 > +#define LDAP_ENTRYCLASS_MASTER 0x2 > #define LDAP_ENTRYCLASS_CONFIG 0x4 > +#define LDAP_ENTRYCLASS_FORWARD 0x8 > > typedef unsigned char ldap_entryclass_t; > > @@ -116,8 +117,8 @@ ldap_entry_getfakesoa(ldap_entry_t *entry, const char *fake_mname, > * Get entry class (bitwise OR of the LDAP_ENTRYCLASS_*). Note that > * you must ldap_search for objectClass attribute! > */ > -ldap_entryclass_t > -ldap_entry_getclass(ldap_entry_t *entry); > +isc_result_t > +ldap_entry_getclass(ldap_entry_t *entry, ldap_entryclass_t *class); > > /* > * ldap_attr_nextvalue > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index ed1b76857116579f9f9e8ce2fc1ef2af67c9608e..24be4d04d6d8dd07f27f2bce6a6557aac24e8371 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -79,6 +79,8 @@ > #include "util.h" > #include "zone_manager.h" > #include "zone_register.h" > +#include "rbt_helper.h" > +#include "fwd_register.h" > > > /* Max type length definitions, from lib/dns/master.c */ > @@ -153,6 +155,7 @@ struct ldap_instance { > > /* Our own list of zones. */ > zone_register_t *zone_register; > + fwd_register_t *fwd_register; > > /* krb5 kinit mutex */ > isc_mutex_t kinit_lock; > @@ -519,6 +522,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > > CHECK(zr_create(mctx, ldap_inst, ldap_inst->global_settings, > &ldap_inst->zone_register)); > + CHECK(fwdr_create(ldap_inst->mctx, &ldap_inst->fwd_register)); > > CHECK(isc_mutex_init(&ldap_inst->kinit_lock)); > > @@ -784,7 +788,6 @@ configure_zone_ssutable(dns_zone_t *zone, const char *update_str) > return acl_configure_zone_ssutable(update_str, zone); > } > > -/* Delete zone by dns zone name */ > static isc_result_t > delete_forwarding_table(ldap_instance_t *inst, dns_name_t *name, > const char *msg_obj_type, const char *dn) { > @@ -806,6 +809,7 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock, > isc_boolean_t preserve_forwarding) > { > isc_result_t result; > + isc_result_t isforward = ISC_R_NOTFOUND; > isc_boolean_t unlock = ISC_FALSE; > isc_boolean_t freeze = ISC_FALSE; > dns_zone_t *zone = NULL; > @@ -823,16 +827,20 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock, > } > > if (!preserve_forwarding) { > - result = dns_fwdtable_delete(inst->view->fwdtable, name); > - if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) > - log_error_r("zone '%s': failed to delete forwarders", > - zone_name_char); > + CHECK(delete_forwarding_table(inst, name, "zone", > + zone_name_char)); > + isforward = fwdr_zone_ispresent(inst->fwd_register, name); > + if (isforward == ISC_R_SUCCESS) > + CHECK(fwdr_del_zone(inst->fwd_register, name)); > } > > result = zr_get_zone_ptr(inst->zone_register, name, &zone); > if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > + if (isforward == ISC_R_SUCCESS) > + log_info("forward zone '%s': shutting down", zone_name_char); > log_debug(1, "zone '%s' not found in zone register", zone_name_char); > - CLEANUP_WITH(ISC_R_SUCCESS); > + result = dns_view_flushcache(inst->view); > + goto cleanup; > } else if (result != ISC_R_SUCCESS) > goto cleanup; > > @@ -851,7 +859,7 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock, > if (dns_zone_getdb(zone, &dbp) == ISC_R_SUCCESS) { > dns_db_detach(&dbp); /* dns_zone_getdb() attaches DB implicitly */ > dns_zone_unload(zone); > - log_debug(1, "zone '%s' unloaded", zone_name_char); > + dns_zone_log(zone, ISC_LOG_INFO, "shutting down"); > } else { > log_debug(1, "zone '%s' not loaded - unload skipped", zone_name_char); > } > @@ -1164,9 +1172,49 @@ cleanup: > return ISC_R_SUCCESS; > } > > -/* Parse the zone entry */ > +/* Parse the forward zone entry */ > static isc_result_t > -ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > +ldap_parse_fwd_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > +{ > + const char *dn; > + dns_name_t name; > + char name_txt[DNS_NAME_FORMATSIZE]; > + isc_result_t result; > + > + REQUIRE(entry != NULL); > + REQUIRE(inst != NULL); > + > + dns_name_init(&name, NULL); > + > + /* Derive the DNS name of the zone from the DN. */ > + dn = entry->dn; > + CHECK(dn_to_dnsname(inst->mctx, dn, &name, NULL)); > + > + result = configure_zone_forwarders(entry, inst, &name); > + if (result != ISC_R_DISABLED && result != ISC_R_SUCCESS) { > + log_error_r("forward zone '%s': could not configure forwarding", dn); > + goto cleanup; > + } > + > + result = fwdr_zone_ispresent(inst->fwd_register, &name); > + if (result == ISC_R_NOTFOUND) { > + CHECK(fwdr_add_zone(inst->fwd_register, &name)); > + dns_name_format(&name, name_txt, DNS_NAME_FORMATSIZE); > + log_info("forward zone '%s': loaded", name_txt); > + } > + else if (result != ISC_R_SUCCESS) > + log_error_r("forward zone '%s': could not read forwarding register", dn); > + > +cleanup: > + if (dns_name_dynamic(&name)) > + dns_name_free(&name, inst->mctx); > + > + return result; > +} > + > +/* Parse the master zone entry */ > +static isc_result_t > +ldap_parse_master_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > { > const char *dn; > ldap_valuelist_t values; > @@ -1210,6 +1258,7 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > goto cleanup; > > /* > + * TODO: Remove this hack, most probably before Fedora 20. > * Forwarding has top priority hence when the forwarders are properly > * set up all others attributes are ignored. > */ > @@ -1353,14 +1402,21 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > if (zone_dynamic) > dns_zone_notify(zone); > } > + if (publish) > + dns_zone_log(zone, ISC_LOG_INFO, "loaded serial %u", ldap_serial); > > cleanup: > if (publish && !published) { /* Failure in ACL parsing or so. */ > log_error_r("zone '%s': publishing failed, rolling back due to", > entry->dn); > + result = delete_forwarding_table(inst, &name, "zone", entry->dn); > + if (result != ISC_R_SUCCESS) > + log_error_r("zone '%s': rollback failed: forwarding", > + entry->dn); > result = zr_del_zone(inst->zone_register, &name); > if (result != ISC_R_SUCCESS) > - log_error_r("zone '%s': rollback failed", entry->dn); > + log_error_r("zone '%s': rollback failed: zone register", > + entry->dn); > } > if (unlock) > isc_task_endexclusive(task); > @@ -1374,10 +1430,7 @@ cleanup: > } > > /* > - * Search in LDAP for zones. If 'create' is true, create the zones. Otherwise, > - * we assume that we are past the configuration phase and no new zones can be > - * added. In that case, only modify the zone's properties, like the update > - * policy. > + * Search in LDAP for zones. > * > * @param delete_only Do LDAP vs. zone register cross-check and delete zones > * which aren't in LDAP, but do not load new zones. > @@ -1393,9 +1446,10 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > ldap_qresult_t *ldap_config_qresult = NULL; > ldap_qresult_t *ldap_zones_qresult = NULL; > int zone_count = 0; > + ldap_entryclass_t zone_class; > ldap_entry_t *entry; > - dns_rbt_t *rbt = NULL; > - isc_boolean_t invalidate_nodechain = ISC_FALSE; > + dns_rbt_t *master_rbt = NULL; /** < Master zones only */ > + dns_rbt_t *forward_rbt = NULL; /** < Forward zones only */ > isc_boolean_t psearch; > const char *base = NULL; > char *config_attrs[] = { > @@ -1406,7 +1460,7 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > char *zone_attrs[] = { > "idnsName", "idnsUpdatePolicy", "idnsAllowQuery", > "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", > - "idnsAllowDynUpdate", "idnsAllowSyncPTR", NULL > + "idnsAllowDynUpdate", "idnsAllowSyncPTR", "objectClass", NULL > }; > > REQUIRE(ldap_inst != NULL); > @@ -1427,7 +1481,8 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > CHECK(ldap_pool_getconnection(ldap_inst->pool, &ldap_conn)); > CHECK(ldap_query(ldap_inst, ldap_conn, &ldap_zones_qresult, base, > LDAP_SCOPE_SUBTREE, zone_attrs, 0, > - "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + "(&(idnsZoneActive=TRUE)" > + "(|(objectClass=idnsZone)(objectClass=idnsForwardZone)))")); > > /* Do not touch configuration from psearch watcher thread, otherwise > * BIND will crash. The problem is that isc_task_beginexclusive() > @@ -1448,109 +1503,132 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > } > > /* > - * Create RB-tree with all zones stored in LDAP for cross check > - * with registered zones in plugin. > + * Create RB-trees with all master and forward zones stored in LDAP > + * for cross check with zones registered in plugin. > */ > - CHECK(dns_rbt_create(ldap_inst->mctx, NULL, NULL, &rbt)); > - > + CHECK(dns_rbt_create(ldap_inst->mctx, NULL, NULL, &master_rbt)); > + CHECK(dns_rbt_create(ldap_inst->mctx, NULL, NULL, &forward_rbt)); > + > for (entry = HEAD(ldap_zones_qresult->ldap_entries); > entry != NULL; > entry = NEXT(entry, link)) { > + if (ldap_entry_getclass(entry, &zone_class) != ISC_R_SUCCESS) > + continue; > > /* Derive the dns name of the zone from the DN. */ > dns_name_t name; > dns_name_init(&name, NULL); > result = dn_to_dnsname(ldap_inst->mctx, entry->dn, &name, NULL); > if (result == ISC_R_SUCCESS) { > log_debug(5, "Refresh %s", entry->dn); > /* Add found zone to RB-tree for later check. */ > - result = dns_rbt_addname(rbt, &name, NULL); > + if (zone_class & LDAP_ENTRYCLASS_MASTER) > + result = dns_rbt_addname(master_rbt, &name, NULL); > + else In my opinion you should use "else if (zone_class & LDAP_ENTRYCLASS_FORWARD)" here. > + result = dns_rbt_addname(forward_rbt, &name, NULL); > } > if (dns_name_dynamic(&name)) > dns_name_free(&name, ldap_inst->mctx); > - > + > if (result != ISC_R_SUCCESS) { > log_error("Could not parse zone %s", entry->dn); > continue; > } > > - if (!delete_only) > - CHECK(ldap_parse_zoneentry(entry, ldap_inst)); > - zone_count++; > + if (!delete_only) { > + if (zone_class & LDAP_ENTRYCLASS_MASTER) > + result = ldap_parse_master_zoneentry(entry, ldap_inst); > + else if (zone_class & LDAP_ENTRYCLASS_FORWARD) > + result = ldap_parse_fwd_zoneentry(entry, ldap_inst); > + } > + if (result == ISC_R_SUCCESS) > + zone_count++; > + else > + log_error_r("error parsing zone '%s'", entry->dn); > } > > - dns_rbtnode_t *node; > - dns_rbtnodechain_t chain; > - isc_boolean_t delete = ISC_FALSE; > - > - DECLARE_BUFFERED_NAME(fname); > - DECLARE_BUFFERED_NAME(forig); > - DECLARE_BUFFERED_NAME(aname); > - > - INIT_BUFFERED_NAME(fname); > - INIT_BUFFERED_NAME(forig); > - INIT_BUFFERED_NAME(aname); > - > - dns_rbtnodechain_init(&chain, ldap_inst->mctx); > - invalidate_nodechain = ISC_TRUE; > - result = dns_rbtnodechain_first(&chain, zr_get_rbt(ldap_inst->zone_register), NULL, NULL); > - > - while (result == DNS_R_NEWORIGIN || result == ISC_R_SUCCESS) { > - dns_name_reset(&aname); > - delete = ISC_FALSE; > - node = NULL; > - > - result = dns_rbtnodechain_current(&chain, &fname, &forig, &node); > - if (result != ISC_R_SUCCESS) { > - if (result != ISC_R_NOTFOUND) > - log_error_r( > - "unable to walk through RB-tree during zone_refresh"); > - goto next; > - } > + /* Walk through master zone register and remove all zones which > + * disappeared from LDAP. */ > + rbt_iterator_t iter; > + char name_txt[DNS_NAME_FORMATSIZE]; > + DECLARE_BUFFERED_NAME(registered_name); > + DECLARE_BUFFERED_NAME(ldap_name); > > - result = dns_name_concatenate(&fname, &forig, &aname, > - aname.buffer); > - if (result != ISC_R_SUCCESS) { > - log_error_r("unable to concatenate DNS names " > - "during zone_refresh"); > - goto next; > - } > + INIT_BUFFERED_NAME(registered_name); > + result = zr_rbt_iter_init(ldap_inst->zone_register, &iter, ®istered_name); > + while (result == ISC_R_SUCCESS) { > + void *data = NULL; > + INIT_BUFFERED_NAME(ldap_name); > > - /* Do not remove auxiliary (= non-zone) nodes. */ > - char buf[DNS_NAME_FORMATSIZE]; > - dns_name_format(&aname, buf, DNS_NAME_FORMATSIZE); > - if (!node->data) { > - log_debug(11,"auxiliary zone/node '%s' will not be removed", buf); > - goto next; > + result = dns_rbt_findname(master_rbt, ®istered_name, > + DNS_RBTFIND_EMPTYDATA, > + &ldap_name, &data); > + if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > + rbt_iter_stop(&iter); > + dns_name_format(®istered_name, name_txt, DNS_NAME_FORMATSIZE); > + log_debug(1, "master zone '%s' is being removed", name_txt); > + result = ldap_delete_zone2(ldap_inst, ®istered_name, > + ISC_FALSE, ISC_FALSE); > + if (result != ISC_R_SUCCESS) { > + log_error_r("unable to delete master zone '%s'", name_txt); > + } else { > + /* Deletion invalidated the chain, restart iteration. */ > + result = zr_rbt_iter_init(ldap_inst->zone_register, > + &iter, ®istered_name); > + continue; > + } > + } else if (result != ISC_R_SUCCESS) { > + break; > } > + result = rbt_iter_next(&iter, ®istered_name); > + } > + if (result != ISC_R_NOTFOUND && result != ISC_R_NOMORE) > + goto cleanup; > > - DECLARE_BUFFERED_NAME(foundname); > - INIT_BUFFERED_NAME(foundname); > - > + /* Walk through forward zone register and remove all zones which > + * disappeared from LDAP. */ > + INIT_BUFFERED_NAME(registered_name); > + result = fwdr_rbt_iter_init(ldap_inst->fwd_register, &iter, ®istered_name); > + while (result == ISC_R_SUCCESS) { > void *data = NULL; > - if (dns_rbt_findname(rbt, &aname, DNS_RBTFIND_EMPTYDATA, > - &foundname, &data) == ISC_R_SUCCESS) { > - goto next; > + INIT_BUFFERED_NAME(ldap_name); > + > + result = dns_rbt_findname(forward_rbt, ®istered_name, > + DNS_RBTFIND_EMPTYDATA, > + &ldap_name, &data); > + if (result == ISC_R_NOTFOUND || result == DNS_R_PARTIALMATCH) { > + rbt_iter_stop(&iter); > + dns_name_format(®istered_name, name_txt, DNS_NAME_FORMATSIZE); > + log_debug(1, "forward zone '%s' is being removed", name_txt); > + result = delete_forwarding_table(ldap_inst, ®istered_name, > + "forward zone", name_txt); > + if (result != ISC_R_SUCCESS) { > + log_error_r("could not remove forwarding for zone '%s': " > + "forward register mismatch", name_txt); > + } > + result = fwdr_del_zone(ldap_inst->fwd_register, ®istered_name); > + if (result == ISC_R_SUCCESS) { > + /* Deletion invalidated the chain, restart iteration. */ > + result = fwdr_rbt_iter_init(ldap_inst->fwd_register, > + &iter, ®istered_name); > + continue; > + } else { > + log_error_r("unable to delete forward zone '%s' " > + "from forwarding register", name_txt); > + } > + } else if (result != ISC_R_SUCCESS) { > + break; > } > - /* Log zone removing. */ > - log_debug(1, "Zone '%s' has been removed from database.", buf); > - > - delete = ISC_TRUE; > -next: > - result = dns_rbtnodechain_next(&chain, NULL, NULL); > - > - if (delete == ISC_TRUE) > - ldap_delete_zone2(ldap_inst, &aname, ISC_FALSE, > - ISC_FALSE); > + result = rbt_iter_next(&iter, ®istered_name); > } > - > + if (result == ISC_R_NOTFOUND || result == ISC_R_NOMORE) > + goto cleanup; > > cleanup: > - if (rbt != NULL) > - dns_rbt_destroy(&rbt); > - > - if (invalidate_nodechain) > - dns_rbtnodechain_invalidate(&chain); > + if (master_rbt != NULL) > + dns_rbt_destroy(&master_rbt); > + if (forward_rbt != NULL) > + dns_rbt_destroy(&forward_rbt); > > ldap_query_free(ISC_FALSE, &ldap_config_qresult); > ldap_query_free(ISC_FALSE, &ldap_zones_qresult); > @@ -1669,15 +1747,17 @@ ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry, > { > isc_result_t result; > dns_rdataclass_t rdclass; > + ldap_entryclass_t objclass; > dns_ttl_t ttl; > dns_rdatatype_t rdtype; > dns_rdata_t *rdata = NULL; > dns_rdatalist_t *rdlist = NULL; > ldap_attribute_t *attr; > const char *dn = ""; > const char *data = ""; > > - if ((ldap_entry_getclass(entry) & LDAP_ENTRYCLASS_ZONE) != 0) > + CHECK(ldap_entry_getclass(entry, &objclass)); > + if ((objclass & LDAP_ENTRYCLASS_MASTER) != 0) > CHECK(add_soa_record(mctx, qresult, origin, entry, > rdatalist, fake_mname)); > > @@ -3263,7 +3343,7 @@ cleanup: > } > > /* > - * update_action routine is processed asynchronously so it cannot assume > + * update_zone routine is processed asynchronously so it cannot assume > * anything about state of ldap_inst from where it was sent. The ldap_inst > * could have been already destroyed due server reload. The safest > * way how to handle zone update is to refetch ldap_inst, > @@ -3278,57 +3358,70 @@ update_zone(isc_task_t *task, isc_event_t *event) > ldap_instance_t *inst = NULL; > ldap_qresult_t *ldap_qresult_zone = NULL; > ldap_qresult_t *ldap_qresult_record = NULL; > + ldap_entryclass_t objclass; > ldap_entry_t *entry_zone = NULL; > ldap_entry_t *entry_record = NULL; > isc_mem_t *mctx; > dns_name_t prevname; > + dns_name_t currname; > char *attrs_zone[] = { > "idnsName", "idnsUpdatePolicy", "idnsAllowQuery", > "idnsAllowTransfer", "idnsForwardPolicy", "idnsForwarders", > - "idnsAllowDynUpdate", "idnsAllowSyncPTR", NULL > + "idnsAllowDynUpdate", "idnsAllowSyncPTR", "objectClass", NULL > }; > char *attrs_record[] = { > "objectClass", "dn", NULL > }; > > UNUSED(task); > > mctx = pevent->mctx; > + dns_name_init(&currname, NULL); > dns_name_init(&prevname, NULL); > > CHECK(manager_get_ldap_instance(pevent->dbname, &inst)); > > result = ldap_query(inst, NULL, &ldap_qresult_zone, pevent->dn, > LDAP_SCOPE_BASE, attrs_zone, 0, > - "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))"); > + "(&(|(objectClass=idnsZone)" > + "(objectClass=idnsForwardZone))" > + "(idnsZoneActive=TRUE))"); > if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) > goto cleanup; > > + CHECK(dn_to_dnsname(inst->mctx, pevent->dn, &currname, NULL)); > + > if (result == ISC_R_SUCCESS && > HEAD(ldap_qresult_zone->ldap_entries) != NULL) { > entry_zone = HEAD(ldap_qresult_zone->ldap_entries); > - CHECK(ldap_parse_zoneentry(entry_zone, inst)); > + CHECK(ldap_entry_getclass(entry_zone, &objclass)); > + if (objclass & LDAP_ENTRYCLASS_MASTER) > + CHECK(ldap_parse_master_zoneentry(entry_zone, inst)); > + else if (objclass & LDAP_ENTRYCLASS_FORWARD) > + CHECK(ldap_parse_fwd_zoneentry(entry_zone, inst)); > > if (PSEARCH_MODDN(pevent->chgtype)) { > if (dn_to_dnsname(inst->mctx, pevent->prevdn, &prevname, NULL) > == ISC_R_SUCCESS) { > CHECK(ldap_delete_zone(inst, pevent->prevdn, > ISC_TRUE, ISC_FALSE)); > } else { > - log_debug(5, "update_action: old zone wasn't managed " > - "by plugin, dn '%s'", pevent->prevdn); > + log_debug(5, "update_zone: old zone wasn't managed " > + "by plugin, dn '%s'", pevent->prevdn); > } > > /* fill the cache with records from renamed zone */ > - CHECK(ldap_query(inst, NULL, &ldap_qresult_record, pevent->dn, > - LDAP_SCOPE_ONELEVEL, attrs_record, 0, > - "(objectClass=idnsRecord)")); > + if (objclass & LDAP_ENTRYCLASS_MASTER) { > + CHECK(ldap_query(inst, NULL, &ldap_qresult_record, pevent->dn, > + LDAP_SCOPE_ONELEVEL, attrs_record, 0, > + "(objectClass=idnsRecord)")); > > - for (entry_record = HEAD(ldap_qresult_record->ldap_entries); > - entry_record != NULL; > - entry_record = NEXT(entry_record, link)) { > + for (entry_record = HEAD(ldap_qresult_record->ldap_entries); > + entry_record != NULL; > + entry_record = NEXT(entry_record, link)) { > > - psearch_update(inst, entry_record, NULL); > + psearch_update(inst, entry_record, NULL); > + } > } > } > > @@ -3345,6 +3438,8 @@ cleanup: > > ldap_query_free(ISC_FALSE, &ldap_qresult_zone); > ldap_query_free(ISC_FALSE, &ldap_qresult_record); > + if (dns_name_dynamic(&currname)) > + dns_name_free(&currname, inst->mctx); > if (dns_name_dynamic(&prevname)) > dns_name_free(&prevname, inst->mctx); > isc_mem_free(mctx, pevent->dbname); > @@ -3647,12 +3742,7 @@ psearch_update(ldap_instance_t *inst, ldap_entry_t *entry, LDAPControl **ctrls) > isc_mem_t *mctx = NULL; > isc_taskaction_t action = NULL; > > - class = ldap_entry_getclass(entry); > - if (class == LDAP_ENTRYCLASS_NONE) { > - log_error("psearch_update: ignoring entry with unknown class, dn '%s'", > - entry->dn); > - return; /* ignore it, it's OK */ > - } > + CHECK(ldap_entry_getclass(entry, &class)); > > if (ctrls != NULL) > CHECK(ldap_parse_entrychangectrl(ctrls, &chgtype, &prevdn_ldap)); > @@ -3681,7 +3771,9 @@ psearch_update(ldap_instance_t *inst, ldap_entry_t *entry, LDAPControl **ctrls) > > if ((class & LDAP_ENTRYCLASS_CONFIG) != 0) > action = update_config; > - else if ((class & LDAP_ENTRYCLASS_ZONE) != 0) > + else if ((class & LDAP_ENTRYCLASS_MASTER) != 0) > + action = update_zone; > + else if ((class & LDAP_ENTRYCLASS_FORWARD) != 0) > action = update_zone; > else if ((class & LDAP_ENTRYCLASS_RR) != 0) > action = update_record; > @@ -3851,14 +3943,18 @@ restart: > ret = ldap_search_ext(conn->handle, > base, > LDAP_SCOPE_SUBTREE, > - /* > - * (objectClass==idnsZone AND idnsZoneActive==TRUE) > - * OR (objectClass == idnsRecord) > - * OR (objectClass == idnsConfigObject) > - */ > - "(|(&(objectClass=idnsZone)(idnsZoneActive=TRUE))" > - "(objectClass=idnsRecord)" > - "(objectClass=idnsConfigObject))", > + /* class = record > + * OR class = config > + * OR class = zone > + * OR class = forward > + * > + * Inactive zones are handled > + * in update_zone. */ > + "(|" > + "(objectClass=idnsRecord)" > + "(objectClass=idnsConfigObject)" > + "(objectClass=idnsZone)" > + "(objectClass=idnsForwardZone))", > NULL, 0, conn->serverctrls, NULL, NULL, > LDAP_NO_LIMIT, &conn->msgid); > if (ret != LDAP_SUCCESS) { > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Apr 2 17:13:55 2013 From: atkac at redhat.com (Adam Tkac) Date: Tue, 2 Apr 2013 19:13:55 +0200 Subject: [Freeipa-devel] [PATCH 0134] Make RBT iterators more resilient. In-Reply-To: <515B0C31.40608@redhat.com> References: <515B0C31.40608@redhat.com> Message-ID: <20130402171355.GA23781@redhat.com> On Tue, Apr 02, 2013 at 06:49:53PM +0200, Petr Spacek wrote: > Hello, > > Make RBT iterators more resilient. > > This patch implements more resilient interface for RBT iterators, as > I promised in thread about patches 123-126. > > Now multiple calls to rbt_iter_stop() with the same argument do not hurt. Ack > From 9ee8cb1b9be0db6ca1530b43e96547b130181519 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 2 Apr 2013 18:46:48 +0200 > Subject: [PATCH] Make RBT iterators more resilient. > > Signed-off-by: Petr Spacek > --- > src/fwd_register.c | 2 +- > src/fwd_register.h | 2 +- > src/ldap_helper.c | 4 +++- > src/rbt_helper.c | 66 ++++++++++++++++++++++++++++++++++++----------------- > src/rbt_helper.h | 15 +++--------- > src/zone_register.c | 4 ++-- > src/zone_register.h | 2 +- > 7 files changed, 56 insertions(+), 39 deletions(-) > > diff --git a/src/fwd_register.c b/src/fwd_register.c > index c663b25909b0e393421c49950d1f29a1352cfe6c..81eaac5b66ff66890935e7e6a94138c5e854332d 100644 > --- a/src/fwd_register.c > +++ b/src/fwd_register.c > @@ -146,7 +146,7 @@ cleanup: > } > > isc_result_t > -fwdr_rbt_iter_init(fwd_register_t *fwdr, rbt_iterator_t *iter, > +fwdr_rbt_iter_init(fwd_register_t *fwdr, rbt_iterator_t **iter, > dns_name_t *nodename) { > if (fwdr->rbt == NULL) > return ISC_R_NOTFOUND; > diff --git a/src/fwd_register.h b/src/fwd_register.h > index 0bee3cba82d1deca1aa2fce235be118d076332f0..5fb96c0eb9b07e7374f4591d9cc166714abc23bd 100644 > --- a/src/fwd_register.h > +++ b/src/fwd_register.h > @@ -29,7 +29,7 @@ isc_result_t > fwdr_zone_ispresent(fwd_register_t *fwdr, dns_name_t *name); > > isc_result_t > -fwdr_rbt_iter_init(fwd_register_t *fwdr, rbt_iterator_t *iter, > +fwdr_rbt_iter_init(fwd_register_t *fwdr, rbt_iterator_t **iter, > dns_name_t *nodename); > > #endif /* !_LD_FWD_REGISTER_H_ */ > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 72456228ba9d223d239f34ae88d63192e0ffbbb4..99d67724a61304a2f39a0d3fa9391ce35f12b72f 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1549,7 +1549,7 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > > /* Walk through master zone register and remove all zones which > * disappeared from LDAP. */ > - rbt_iterator_t iter; > + rbt_iterator_t *iter = NULL; > char name_txt[DNS_NAME_FORMATSIZE]; > DECLARE_BUFFERED_NAME(registered_name); > DECLARE_BUFFERED_NAME(ldap_name); > @@ -1588,6 +1588,7 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > /* Walk through forward zone register and remove all zones which > * disappeared from LDAP. */ > INIT_BUFFERED_NAME(registered_name); > + iter = NULL; > result = fwdr_rbt_iter_init(ldap_inst->fwd_register, &iter, ®istered_name); > while (result == ISC_R_SUCCESS) { > void *data = NULL; > @@ -1625,6 +1626,7 @@ refresh_zones_from_ldap(ldap_instance_t *ldap_inst, isc_boolean_t delete_only) > goto cleanup; > > cleanup: > + rbt_iter_stop(&iter); > if (master_rbt != NULL) > dns_rbt_destroy(&master_rbt); > if (forward_rbt != NULL) > diff --git a/src/rbt_helper.c b/src/rbt_helper.c > index 70ab06134694e36a6ae049284d506bbf5bc3a977..ab37e3c754d06c1b49e389e2e85a5340d4317db2 100644 > --- a/src/rbt_helper.c > +++ b/src/rbt_helper.c > @@ -4,6 +4,16 @@ > > #define LDAPDB_RBTITER_MAGIC ISC_MAGIC('L', 'D', 'P', 'I') > > +struct rbt_iterator { > + unsigned int magic; > + isc_mem_t *mctx; > + dns_rbt_t *rbt; > + isc_rwlock_t *rwlock; > + isc_rwlocktype_t locktype; > + dns_rbtnodechain_t chain; > +}; > + > + > /** > * Copy the RBT node name, i.e. copies the name pointed to by RBT iterator. > * > @@ -47,7 +57,7 @@ cleanup: > * unlocked by reaching end of iteration or explicit rbt_iter_stop() call. > * > * @param[in,out] rwlock guard for RBT, will be read-locked > - * @param[out] iter iterator structure, will be initialized > + * @param[out] iterp iterator structure, will be initialized > * @param[out] nodename dns_name with pre-allocated storage > * > * @pre Nodename has pre-allocated storage space. > @@ -62,14 +72,16 @@ cleanup: > */ > isc_result_t > rbt_iter_first(isc_mem_t *mctx, dns_rbt_t *rbt, isc_rwlock_t *rwlock, > - rbt_iterator_t *iter, dns_name_t *nodename) { > + rbt_iterator_t **iterp, dns_name_t *nodename) { > > isc_result_t result; > + rbt_iterator_t *iter = NULL; > > REQUIRE(rbt != NULL); > REQUIRE(rwlock != NULL); > - REQUIRE(iter != NULL); > + REQUIRE(iterp != NULL && *iterp == NULL); > > + CHECKED_MEM_GET_PTR(mctx, iter); > ZERO_PTR(iter); > > isc_mem_attach(mctx, &iter->mctx); > @@ -82,69 +94,81 @@ rbt_iter_first(isc_mem_t *mctx, dns_rbt_t *rbt, isc_rwlock_t *rwlock, > RWLOCK(iter->rwlock, iter->locktype); > > result = dns_rbtnodechain_first(&iter->chain, rbt, NULL, NULL); > - if (result != DNS_R_NEWORIGIN) { > - rbt_iter_stop(iter); > - return result; > - } > + if (result != DNS_R_NEWORIGIN) > + goto cleanup; > > result = rbt_iter_getnodename(iter, nodename); > if (result == DNS_R_EMPTYNAME) > - result = rbt_iter_next(iter, nodename); > + result = rbt_iter_next(&iter, nodename); > if (result == ISC_R_NOMORE) > result = ISC_R_NOTFOUND; > > +cleanup: > + if (result == ISC_R_SUCCESS) > + *iterp = iter; > + else > + rbt_iter_stop(&iter); > + > return result; > } > > /** > * Copy name of the next non-empty node in RBT. > * > - * @param[in] iter valid iterator > + * @param[in] iterp valid iterator > * @param[out] nodename dns_name with pre-allocated storage > * > * @pre Nodename has pre-allocated storage space. > * > * @retval ISC_R_SUCCESS Nodename holds independent copy of RBT node name, > * RBT is in locked state. > * @retval ISC_R_NOMORE Iteration ended, RBT is in unlocked state, > * iterator is no longer valid. > * @retval others Errors from dns_name_concatenate() and others. > + * RBT is in unlocked state, iterator is no longer valid. > */ > isc_result_t > -rbt_iter_next(rbt_iterator_t *iter, dns_name_t *nodename) { > +rbt_iter_next(rbt_iterator_t **iterp, dns_name_t *nodename) { > isc_result_t result; > > - REQUIRE(iter != NULL); > - REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); > - REQUIRE(iter->locktype != isc_rwlocktype_none); > + REQUIRE(iterp != NULL && *iterp != NULL); > + REQUIRE(ISC_MAGIC_VALID(*iterp, LDAPDB_RBTITER_MAGIC)); > + REQUIRE((*iterp)->locktype != isc_rwlocktype_none); > > do { > - result = dns_rbtnodechain_next(&iter->chain, NULL, NULL); > + result = dns_rbtnodechain_next(&(*iterp)->chain, NULL, NULL); > if (result != ISC_R_SUCCESS && result != DNS_R_NEWORIGIN) > goto cleanup; > > - result = rbt_iter_getnodename(iter, nodename); > + result = rbt_iter_getnodename(*iterp, nodename); > } while (result == DNS_R_EMPTYNAME); > > cleanup: > if (result != ISC_R_SUCCESS) > - rbt_iter_stop(iter); > + rbt_iter_stop(iterp); > > return result; > } > > /** > * Stop RBT iteration and unlock RBT. > + * @param[in] iterp valid iterator or NULL > */ > void > -rbt_iter_stop(rbt_iterator_t *iter) { > - REQUIRE(iter != NULL); > +rbt_iter_stop(rbt_iterator_t **iterp) { > + rbt_iterator_t *iter; > + > + REQUIRE(iterp != NULL); > + iter = *iterp; > + > + if (iter == NULL) > + return; > + > REQUIRE(ISC_MAGIC_VALID(iter, LDAPDB_RBTITER_MAGIC)); > - > + iter->magic = 0; > if (iter->locktype != isc_rwlocktype_none) > isc_rwlock_unlock(iter->rwlock, iter->locktype); > > dns_rbtnodechain_invalidate(&iter->chain); > - isc_mem_detach(&(iter->mctx)); > - ZERO_PTR(iter); > + MEM_PUT_AND_DETACH(*iterp); > } > diff --git a/src/rbt_helper.h b/src/rbt_helper.h > index 9c9bcd202cafafb39a3018bbafff6bbd3c9189a9..98aef20f217c68b74e497f91e549081ea3160225 100644 > --- a/src/rbt_helper.h > +++ b/src/rbt_helper.h > @@ -5,25 +5,16 @@ > #include > #include "util.h" > > -struct rbt_iterator { > - unsigned int magic; > - isc_mem_t *mctx; > - dns_rbt_t *rbt; > - isc_rwlock_t *rwlock; > - isc_rwlocktype_t locktype; > - dns_rbtnodechain_t chain; > -}; > - > typedef struct rbt_iterator rbt_iterator_t; > > isc_result_t > rbt_iter_first(isc_mem_t *mctx, dns_rbt_t *rbt, isc_rwlock_t *rwlock, > - rbt_iterator_t *iter, dns_name_t *nodename); > + rbt_iterator_t **iter, dns_name_t *nodename); > > isc_result_t > -rbt_iter_next(rbt_iterator_t *iter, dns_name_t *nodename); > +rbt_iter_next(rbt_iterator_t **iter, dns_name_t *nodename); > > void > -rbt_iter_stop(rbt_iterator_t *iter); > +rbt_iter_stop(rbt_iterator_t **iter); > > #endif /* !_LD_RBT_HELPER_H_ */ > diff --git a/src/zone_register.c b/src/zone_register.c > index 949219ffc2e2adb40943709a3420014e672c88e6..dd2e78098cef9e3fac181c0aa38d311e26a76a74 100644 > --- a/src/zone_register.c > +++ b/src/zone_register.c > @@ -91,7 +91,7 @@ static const setting_t zone_settings[] = { > }; > > isc_result_t > -zr_rbt_iter_init(zone_register_t *zr, rbt_iterator_t *iter, > +zr_rbt_iter_init(zone_register_t *zr, rbt_iterator_t **iter, > dns_name_t *nodename) { > if (zr->rbt == NULL) > return ISC_R_NOTFOUND; > @@ -160,7 +160,7 @@ zr_destroy(zone_register_t **zrp) > { > DECLARE_BUFFERED_NAME(name); > zone_register_t *zr; > - rbt_iterator_t iter; > + rbt_iterator_t *iter = NULL; > isc_result_t result; > > if (zrp == NULL || *zrp == NULL) > diff --git a/src/zone_register.h b/src/zone_register.h > index 7ef40f7abdf4ed17cb32414907b5b7283456bb22..091b3d53aba168f54ac60b0c9e86e8fff3347950 100644 > --- a/src/zone_register.h > +++ b/src/zone_register.h > @@ -58,7 +58,7 @@ isc_result_t > zr_get_zone_settings(zone_register_t *zr, dns_name_t *name, settings_set_t **set); > > isc_result_t > -zr_rbt_iter_init(zone_register_t *zr, rbt_iterator_t *iter, > +zr_rbt_iter_init(zone_register_t *zr, rbt_iterator_t **iter, > dns_name_t *nodename); > > dns_rbt_t * > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Tue Apr 2 16:49:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 18:49:53 +0200 Subject: [Freeipa-devel] [PATCH 0134] Make RBT iterators more resilient. Message-ID: <515B0C31.40608@redhat.com> Hello, Make RBT iterators more resilient. This patch implements more resilient interface for RBT iterators, as I promised in thread about patches 123-126. Now multiple calls to rbt_iter_stop() with the same argument do not hurt. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0134-Make-RBT-iterators-more-resilient.patch Type: text/x-patch Size: 9220 bytes Desc: not available URL: From akrivoka at redhat.com Tue Apr 2 18:14:12 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 02 Apr 2013 20:14:12 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Remove CA cert on client uninstall Message-ID: <515B1FF4.1060206@redhat.com> Hello, The CA cert (/etc/ipa/ca.crt) was not being removed on client uninstall, causing failure on subsequent client installation in some cases. https://fedorahosted.org/freeipa/ticket/3537 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0011-Remove-CA-cert-on-client-uninstall.patch Type: text/x-patch Size: 1471 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 2 18:11:00 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:11:00 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <20130402163412.GB21905@redhat.com> References: <514C4880.6000203@redhat.com> <20130402163412.GB21905@redhat.com> Message-ID: <515B1F34.6090604@redhat.com> On 2.4.2013 18:34, Adam Tkac wrote: > On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch set separates master zones (idnsZone objectClass) from >> >forward zones (idnsForwardZone objectClass). Support for forward >> >zones in idnsZone objectClass is still present to ease upgrades. >> > >> >See each commit message for all the gory details. > Just check one comment below, otherwise ack. [...] >> >> if (result == ISC_R_SUCCESS) { >> log_debug(5, "Refresh %s", entry->dn); >> /* Add found zone to RB-tree for later check. */ >> - result = dns_rbt_addname(rbt, &name, NULL); >> + if (zone_class & LDAP_ENTRYCLASS_MASTER) >> + result = dns_rbt_addname(master_rbt, &name, NULL); >> + else > > In my opinion you should use "else if (zone_class & LDAP_ENTRYCLASS_FORWARD)" > here. > >> + result = dns_rbt_addname(forward_rbt, &name, NULL); >> } Fixed version pushed to master: 760bebb0e8744301420cf6e4918690ed171529a2 -- Petr^2 Spacek From pspacek at redhat.com Tue Apr 2 18:11:03 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:11:03 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <20130402151852.GC21126@redhat.com> References: <514C4880.6000203@redhat.com> <20130402151852.GC21126@redhat.com> Message-ID: <515B1F37.1040806@redhat.com> On 2.4.2013 17:18, Adam Tkac wrote: > On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch set separates master zones (idnsZone objectClass) from >> >forward zones (idnsForwardZone objectClass). Support for forward >> >zones in idnsZone objectClass is still present to ease upgrades. >> > >> >See each commit message for all the gory details. >> > >> >-- >> >Petr^2 Spacek > Ack for patch 0124. Pushed to master: 59b157618c2b241740f3b3125e6da6230fa0314c -- Petr^2 Spacek From pspacek at redhat.com Tue Apr 2 18:11:05 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:11:05 +0200 Subject: [Freeipa-devel] [PATCH 0137-0138] Preparation for 3.0 release Message-ID: <515B1F39.4000402@redhat.com> Hello, attached patches update NEWS and SPEC files. Pushed to master: eb8059eb25912d1c4b262e00ba35d9c44767e1dc 8397ba4ff819825e645b9554fdd17a0d239cc8a9 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0138-Update-NEWS-file-for-upcoming-3.0-release.patch Type: text/x-patch Size: 1442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0139-Bump-NVR-to-3.0.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 2 18:11:07 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:11:07 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <20130402151709.GA21126@redhat.com> References: <514C4880.6000203@redhat.com> <20130402151709.GA21126@redhat.com> Message-ID: <515B1F3B.5040707@redhat.com> On 2.4.2013 17:17, Adam Tkac wrote: > On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch set separates master zones (idnsZone objectClass) from >> >forward zones (idnsForwardZone objectClass). Support for forward >> >zones in idnsZone objectClass is still present to ease upgrades. >> > >> >See each commit message for all the gory details. > Since patches are non-trivial, I will review them "per partes" (i.e. each patch > in separate mail). Please check my comments below. > > Regards, Adam After discussion I pushed original version to master: 9d073c1ef7c28e29397a766320d12ecdb7e1941b -- Petr^2 Spacek From pspacek at redhat.com Tue Apr 2 18:11:08 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:11:08 +0200 Subject: [Freeipa-devel] [PATCH 0123-0126] Separate master and forward zones (add idnsForwardZone object class) In-Reply-To: <20130402153004.GA21905@redhat.com> References: <514C4880.6000203@redhat.com> <20130402153004.GA21905@redhat.com> Message-ID: <515B1F3C.2000900@redhat.com> On 2.4.2013 17:30, Adam Tkac wrote: > On Fri, Mar 22, 2013 at 01:03:12PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch set separates master zones (idnsZone objectClass) from >> >forward zones (idnsForwardZone objectClass). Support for forward >> >zones in idnsZone objectClass is still present to ease upgrades. >> > >> >See each commit message for all the gory details. >> > >> >-- >> >Petr^2 Spacek > Ack for patch 125 as is. Pushed to master: edb6dbcf7a81605e6ccbd8efe1e323862710e0f7 -- Petr^2 Spacek From pspacek at redhat.com Tue Apr 2 18:11:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:11:13 +0200 Subject: [Freeipa-devel] [PATCH 0134] Make RBT iterators more resilient. In-Reply-To: <20130402171355.GA23781@redhat.com> References: <515B0C31.40608@redhat.com> <20130402171355.GA23781@redhat.com> Message-ID: <515B1F41.8020306@redhat.com> On 2.4.2013 19:13, Adam Tkac wrote: > On Tue, Apr 02, 2013 at 06:49:53PM +0200, Petr Spacek wrote: >> >Hello, >> > >> > Make RBT iterators more resilient. >> > >> >This patch implements more resilient interface for RBT iterators, as >> >I promised in thread about patches 123-126. >> > >> >Now multiple calls to rbt_iter_stop() with the same argument do not hurt. > Ack Pushed to master: dc3c3014d6f2fbba447efc1489a0488dd34ad625 -- Petr^2 Spacek From pspacek at redhat.com Tue Apr 2 18:11:16 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:11:16 +0200 Subject: [Freeipa-devel] [PATCH 0135-0137] Schema updates Message-ID: <515B1F44.4020001@redhat.com> Hello, schema was updated to match latest development. Pushed to master: 3bf0d6fa6e6fe1bd81882a6819e9680e9c069997 b5bb6bc3b731c9e3b9d2efc4fb7a4420803ef55d 9bb52d52189f5e7a74b4994653a40de84fc8f4ea -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0135-Add-idnsForwardZone-objectClass-to-the-schema.patch Type: text/x-patch Size: 886 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0136-Change-DNAME-record-attribute-to-single-valued.patch Type: text/x-patch Size: 1029 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0137-Add-notes-about-OID-allocation-and-contacts-to-the-s.patch Type: text/x-patch Size: 2051 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 2 18:41:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 02 Apr 2013 20:41:53 +0200 Subject: [Freeipa-devel] [Freeipa-interest] Announcing bind-dyndb-ldap version 3.0 Message-ID: <515B2671.6070904@redhat.com> The FreeIPA team is proud to announce bind-dyndb-ldap version 3.0. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/. The new version has also been built for Fedora 19: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-3.0-1.fc19 This release includes several fixes and new features. == Changes in 3.0 == [1] DNAME records are supported. DNAME attribute was changed to single-valued. https://fedorahosted.org/bind-dyndb-ldap/ticket/63 [2] Master and forward zones now have separate object classes: idnsZone and idnsForwardZone. idnsForward* attributes in idnsZone object class will have old semantics for some time. https://fedorahosted.org/bind-dyndb-ldap/ticket/99 [3] Settings system was heavily refactored. From now, unknown options in configuration file cause error. DNS dynamic updates should create slightly lower load on LDAP server because of settings 'cache'. https://fedorahosted.org/bind-dyndb-ldap/ticket/53 https://fedorahosted.org/bind-dyndb-ldap/ticket/81 [4] Deadlock triggered by PTR record synchronization was fixed. https://fedorahosted.org/bind-dyndb-ldap/ticket/113 == Upgrading == An server can be upgraded simply by installing updated rpms. BIND has to be restarted manually after the RPM installation. You will need to clean up configuration file /etc/named.conf if your configuration contains typos or other unsupported options. Downgrading back to any 2.x version is supported under following conditions: - new object class idnsForwardZone is not utilized - DNAME records are not utilized - configured connection count is >= 3 (to prevent deadlocks in 2.x releases) == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr Spacek Software engineer Red Hat From jdennis at redhat.com Tue Apr 2 21:07:41 2013 From: jdennis at redhat.com (John Dennis) Date: Tue, 02 Apr 2013 17:07:41 -0400 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515AFA32.5050704@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> <515581A8.7040902@redhat.com> <5155A7EF.50304@redhat.com> <515A22D2.9060106@REDHAT.COM> <515AFA32.5050704@redhat.com> Message-ID: <515B489D.4050309@redhat.com> On 04/02/2013 11:33 AM, Petr Viktorin wrote: > On 04/02/2013 02:14 AM, Robert Relyea wrote: >> On 03/29/2013 07:40 AM, John Dennis wrote: >>> On 03/29/2013 07:57 AM, Petr Viktorin wrote: >>>> On 03/27/2013 04:40 PM, John Dennis wrote: >>>>> On 03/27/2013 11:23 AM, Petr Viktorin wrote: >>>>>> I don't want to check the subject because this RFE was prompted by >>>>>> IPA's >>>>>> normal CA rejecting valid wildcart certs. Is there a reasonable way to >>>>>> ask NSS if it will trust the cert? >>>>> >>>>> Yes. NSS provides a variety of tools to test validation. >>>>> >>>>> Going just on memory here, our current version of python-nss has a >>>>> simple call to test validation. Sometime in the last year I added a >>>>> fair >>>>> amount of new support for certificate validation including getting back >>>>> diagnostic information for validation failures, however if I recall >>>>> correctly the extended functionality in python-nss has not been >>>>> released >>>>> yet. >>>> >>>> Does the new code include downloading and importing CRLs? >>> >>> Cert verification is a complex topic. This is further exacerbated by >>> the introduction of PKIX. My understanding is NSS had "classic" >>> verification code and later introduced PKIX. There has been an >>> evolution between classic verification and PKIX. This is outside my >>> domain of expertise. How and when CRL's are loaded in NSS is not >>> something I can give advice on, especially in an area undergoing change. >>> >>> I'm going to have to defer to an expert in this area, Bob Relyea, I've >>> CC'ed him on this email. >> It's hard to get the context in the middle, and and John had noted, NSS >> is transitioning from the old Cert_Verify interface to the new PKIX_ code. >> >> I'll answer the question for the traditional CERTVerify code, which is >> the only you get in SSL by default, and the one most people still use: >> >> No, CRLs are not downloaded and imported automatically, but if you >> download and import CRL's, NSS will use them. There's an installable >> PKCS #11 module which can be configured to download and install CRLs, >> then provide them to NSS. It's call mod_revocator. >> >> The expected revocation strategy NSS uses is OCSP, and you can turn on >> automatic OCSP fetching. >> >>> Bob, to put this in context [1] the functionality in python-nss being >>> discussed is the binding of the CERT_VerifyCertificate() function, >>> something I added recently. Now the question arises as to how CRL's >>> are meant to play into the verification process. Can you please >>> explain how NSS expects this to be done? Pointers to existing >>> documentation and code examples would also be helpful. >> >> There's a separate CERT_ImportCRL() which will import the CRL into the >> database. mod_revocator() can also be used to do the fetching for you, >> Matthew has examples on how various servers set them up (I believe the >> only NSS set up is installing the module in your secmod.db/pkcs11.txt >> with modutil. >> >>> >>> It would also be helpful to understand the PKIX roadmap and how this >>> might affect coding decisions at the API level. >> >> the PKIX interface is available now, and is actually used by Chrome (for >> all certs) and Firefox (for ev processing). Firefox is in the process of >> moving to libpkix for everything. There is an environment variable you >> can set (I don't remember it specifically, but I could look it up for >> you if you want) that will cause the transitional >> CERT_VerifyCertificate() interface to use the libpkix engine, but it >> keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert >> fetching).. >> >> With libpkix, the revocation options are quite broad and complexed. We >> really expect people would use a set of preconfigured policies, though >> libpkix API allows for quite some variance. It would take me some time >> to dig up all the descriptions, but I can if you want them. >> >>> [1] Some additional context, the original motivation for exposing NSS >>> cert verification to IPA was to solve the following problem. If >>> someone wants to make the IPA CA a sub-CA (as opposed to a self-signed >>> CA) we want to validate the externally provided CA cert *before* >>> proceeding with the IPA installation. This is because if the CA cert >>> is invalid everything will hugely blow-up (because we use the CA cert >>> to sign all the certs issued in IPA, especially those used to validate >>> cooperating components/agents, if those certs do not work nothing in >>> IPA works). In addition to this narrow goal we in general want to be >>> able to perform cert verification correctly in other contexts as well >>> so the extent to which you can educate us in general on this topic >>> will be appreciated. >> OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless >> you specifically need some of the advanced libpkix features. > > The original context is sanity checking: is a SSL server cert we get > from a user valid? If it is then we install the corresponding server. > Requirements here are: > - No extra information from the user, other than the cert itself (the > admin gives us a cert, we don't want to ask how to find out if it's valid) > - It needs to be a simple call/tool, since there's little gain over just > documenting that we want good certs. > So it looks it's not worth it to go there. > > > The new context, as far as I understand, is cert validation in *clients*. > We connect to a server; how to find out if its cert is valid? > In contrast to the sanity checking, we can have complexity and config > options here. This is important to get right, and we don't want any > assumptions (other than that everything is under some wacky corporate > policy). > > It looks like libpkix is the way to go here. I assume Python bindings > aren't available for it yet? We have python bindings for CERT_VerifyCertificate (I'm pretty sure that API has been in the python bindings for a while now). Bob can correct me if I'm wrong but I believe that CERT_VerifyCertificate is more than adequate for client's which want to validate a certificate, especially if the CRL is loaded or OCSP is enabled. The environment variable Bob is referring to is NSS_ENABLE_PKIX_VERIFY. However PKIX verification can also be enabled via the CERT_SetUsePKIXForValidation() entry point, which is part of the current python-nss bindings (but I don't think that's been released yet, I'd have to double check.). python-nss currently does not have entry points for enabling/disabling OCSP checking but it would be trivial to add. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rrelyea at redhat.com Wed Apr 3 01:01:54 2013 From: rrelyea at redhat.com (Robert Relyea) Date: Tue, 02 Apr 2013 18:01:54 -0700 Subject: [Freeipa-devel] [RFE] CA-less install In-Reply-To: <515B489D.4050309@redhat.com> References: <514C4A35.2060200@redhat.com> <515305C9.4070600@redhat.com> <51530F05.607@redhat.com> <515312D8.3000502@redhat.com> <515581A8.7040902@redhat.com> <5155A7EF.50304@redhat.com> <515A22D2.9060106@REDHAT.COM> <515AFA32.5050704@redhat.com> <515B489D.4050309@redhat.com> Message-ID: <515B7F82.7080803@REDHAT.COM> On 04/02/2013 02:07 PM, John Dennis wrote: > On 04/02/2013 11:33 AM, Petr Viktorin wrote: >> On 04/02/2013 02:14 AM, Robert Relyea wrote: >>> On 03/29/2013 07:40 AM, John Dennis wrote: >>>> On 03/29/2013 07:57 AM, Petr Viktorin wrote: >>>>> On 03/27/2013 04:40 PM, John Dennis wrote: >>>>>> On 03/27/2013 11:23 AM, Petr Viktorin wrote: >>>>>>> I don't want to check the subject because this RFE was prompted by >>>>>>> IPA's >>>>>>> normal CA rejecting valid wildcart certs. Is there a reasonable >>>>>>> way to >>>>>>> ask NSS if it will trust the cert? >>>>>> >>>>>> Yes. NSS provides a variety of tools to test validation. >>>>>> >>>>>> Going just on memory here, our current version of python-nss has a >>>>>> simple call to test validation. Sometime in the last year I added a >>>>>> fair >>>>>> amount of new support for certificate validation including >>>>>> getting back >>>>>> diagnostic information for validation failures, however if I recall >>>>>> correctly the extended functionality in python-nss has not been >>>>>> released >>>>>> yet. >>>>> >>>>> Does the new code include downloading and importing CRLs? >>>> >>>> Cert verification is a complex topic. This is further exacerbated by >>>> the introduction of PKIX. My understanding is NSS had "classic" >>>> verification code and later introduced PKIX. There has been an >>>> evolution between classic verification and PKIX. This is outside my >>>> domain of expertise. How and when CRL's are loaded in NSS is not >>>> something I can give advice on, especially in an area undergoing >>>> change. >>>> >>>> I'm going to have to defer to an expert in this area, Bob Relyea, I've >>>> CC'ed him on this email. >>> It's hard to get the context in the middle, and and John had noted, NSS >>> is transitioning from the old Cert_Verify interface to the new PKIX_ >>> code. >>> >>> I'll answer the question for the traditional CERTVerify code, which is >>> the only you get in SSL by default, and the one most people still use: >>> >>> No, CRLs are not downloaded and imported automatically, but if you >>> download and import CRL's, NSS will use them. There's an installable >>> PKCS #11 module which can be configured to download and install CRLs, >>> then provide them to NSS. It's call mod_revocator. >>> >>> The expected revocation strategy NSS uses is OCSP, and you can turn on >>> automatic OCSP fetching. >>> >>>> Bob, to put this in context [1] the functionality in python-nss being >>>> discussed is the binding of the CERT_VerifyCertificate() function, >>>> something I added recently. Now the question arises as to how CRL's >>>> are meant to play into the verification process. Can you please >>>> explain how NSS expects this to be done? Pointers to existing >>>> documentation and code examples would also be helpful. >>> >>> There's a separate CERT_ImportCRL() which will import the CRL into the >>> database. mod_revocator() can also be used to do the fetching for you, >>> Matthew has examples on how various servers set them up (I believe the >>> only NSS set up is installing the module in your secmod.db/pkcs11.txt >>> with modutil. >>> >>>> >>>> It would also be helpful to understand the PKIX roadmap and how this >>>> might affect coding decisions at the API level. >>> >>> the PKIX interface is available now, and is actually used by Chrome >>> (for >>> all certs) and Firefox (for ev processing). Firefox is in the >>> process of >>> moving to libpkix for everything. There is an environment variable you >>> can set (I don't remember it specifically, but I could look it up for >>> you if you want) that will cause the transitional >>> CERT_VerifyCertificate() interface to use the libpkix engine, but it >>> keeps the old CERT_VerifyCertificate semantics (like no CRL or AIA cert >>> fetching).. >>> >>> With libpkix, the revocation options are quite broad and complexed. We >>> really expect people would use a set of preconfigured policies, though >>> libpkix API allows for quite some variance. It would take me some time >>> to dig up all the descriptions, but I can if you want them. >>> >>>> [1] Some additional context, the original motivation for exposing NSS >>>> cert verification to IPA was to solve the following problem. If >>>> someone wants to make the IPA CA a sub-CA (as opposed to a self-signed >>>> CA) we want to validate the externally provided CA cert *before* >>>> proceeding with the IPA installation. This is because if the CA cert >>>> is invalid everything will hugely blow-up (because we use the CA cert >>>> to sign all the certs issued in IPA, especially those used to validate >>>> cooperating components/agents, if those certs do not work nothing in >>>> IPA works). In addition to this narrow goal we in general want to be >>>> able to perform cert verification correctly in other contexts as well >>>> so the extent to which you can educate us in general on this topic >>>> will be appreciated. >>> OK, thanks. I'd go ahead and start with CERT_VerifyCertificate() unless >>> you specifically need some of the advanced libpkix features. >> >> The original context is sanity checking: is a SSL server cert we get >> from a user valid? If it is then we install the corresponding server. >> Requirements here are: >> - No extra information from the user, other than the cert itself (the >> admin gives us a cert, we don't want to ask how to find out if it's >> valid) >> - It needs to be a simple call/tool, since there's little gain over just >> documenting that we want good certs. The admin should have told you the CA that can sign the cert. NSS doesn't ask the user if a cert is valid, though an application may choose to. NSS validates against the installed list of CA's. >> So it looks it's not worth it to go there. >> >> >> The new context, as far as I understand, is cert validation in >> *clients*. >> We connect to a server; how to find out if its cert is valid? The server's cert needs to be signed by a CA that the administrater installed on the client as a trusted CA. The rest of the chain is sent through the SSL protocol, so you will need the whole chain to validate. If you are using NSS for the SSL connection this happens automatically unless you take action to handle certificate authentication yourself. >> In contrast to the sanity checking, we can have complexity and config >> options here. This is important to get right, and we don't want any >> assumptions (other than that everything is under some wacky corporate >> policy). >> >> It looks like libpkix is the way to go here. I assume Python bindings >> aren't available for it yet? > > We have python bindings for CERT_VerifyCertificate (I'm pretty sure > that API has been in the python bindings for a while now). Bob can > correct me if I'm wrong but I believe that CERT_VerifyCertificate is > more than adequate for client's which want to validate a certificate, > especially if the CRL is loaded or OCSP is enabled. yes, that's the same function NSS calls (by default) when it makes an SSL connection. Servers actually use the same function to validate client certificates. There's a usage parameter that tells if you are validating an SSL_server cert or an SSL client cert (Or an S/MIME or Object Signing cert for that matter). The CA is installed by the admin with the appropriate flags for what type of cert is expected to validate.. this trust can be further narrowed by extensions in any intermediate CA between the base CA and the leaf cert you are validating). bob > > The environment variable Bob is referring to is > NSS_ENABLE_PKIX_VERIFY. However PKIX verification can also be enabled > via the CERT_SetUsePKIXForValidation() entry point, which is part of > the current python-nss bindings (but I don't think that's been > released yet, I'd have to double check.). > > python-nss currently does not have entry points for enabling/disabling > OCSP checking but it would be trivial to add. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4521 bytes Desc: S/MIME Cryptographic Signature URL: From pviktori at redhat.com Wed Apr 3 08:02:51 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Apr 2013 10:02:51 +0200 Subject: [Freeipa-devel] String freeze Message-ID: <515BE22B.2030604@redhat.com> Hello, IPA 3.2.0 is in string freeze now. I've uploaded the source strings to Transifex. -- Petr? From pviktori at redhat.com Wed Apr 3 09:57:19 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 03 Apr 2013 11:57:19 +0200 Subject: [Freeipa-devel] [PATCH] 0209 Display full command documentation in online help Message-ID: <515BFCFF.4060600@redhat.com> This fixes a regression in the help improvements. More info in the patch. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0209-Display-full-command-documentation-in-online-help.patch Type: text/x-patch Size: 2707 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 3 11:13:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 03 Apr 2013 13:13:20 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Remove CA cert on client uninstall In-Reply-To: <515B1FF4.1060206@redhat.com> References: <515B1FF4.1060206@redhat.com> Message-ID: <515C0ED0.2040801@redhat.com> On Tue 02 Apr 2013 08:14:12 PM CEST, Ana Krivokapic wrote: > Hello, > > The CA cert (/etc/ipa/ca.crt) was not being removed on client uninstall, > causing failure on subsequent client installation in some cases. > > https://fedorahosted.org/freeipa/ticket/3537 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Tomas From tbabej at redhat.com Wed Apr 3 11:19:55 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 03 Apr 2013 13:19:55 +0200 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <515A9132.6030404@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> <5159E78A.9090902@redhat.com> <515A9132.6030404@redhat.com> Message-ID: <515C105B.6030304@redhat.com> On Tue 02 Apr 2013 10:05:06 AM CEST, Tomas Babej wrote: > On Mon 01 Apr 2013 10:01:14 PM CEST, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>>>> Tomas Babej wrote: >>>>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> The checks make sure that SELinux is: >>>>>>>> - installed and enabled (on server install) >>>>>>>> - installed and enabled OR not installed (on client install) >>>>>>>> >>>>>>>> Please note that client installs with SELinux not installed are >>>>>>>> allowed since freeipa-client package has no dependency on SELinux. >>>>>>>> (any objections to this approach?) >>>>>>>> >>>>>>>> The (unsupported) option --allow-no-selinux has been added. It can >>>>>>>> used to bypass the checks. >>>>>>>> >>>>>>>> Parts of platform-dependant code were refactored to use newly >>>>>>>> added >>>>>>>> is_selinux_enabled() function. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> I forgot to edit the man pages. Thanks Rob! >>>>>>> >>>>>>> Updated patch attached. >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> After a bit of off-line discussion I don't think we're quite ready >>>>>> yet >>>>>> to require SELinux by default on client installations (even with a >>>>>> flag to work around it). The feeling is this would be disruptive to >>>>>> existing automation. >>>>>> >>>>>> Can you still do the check but not enforce it, simply display a big >>>>>> warning if SELinux is disabled? >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Sure, here is the updated patch. >>>>> >>>>> I edited the commit message, RFE description and man pages >>>>> according to >>>>> the new behaviour. >>>>> >>>>> Tomas >>>> >>>> The patch looks good, I'm just wondering about one thing. The default >>>> value for is_selinux_enabled() is True in ipapython/services.py.in. >>>> >>>> So this means that any non-Red Hat/non-Fedora system, by default, is >>>> going to assume that SELinux is enabled. >>>> >>>> My hesitation has to when we call check_selinux_status(). It may >>>> incorrectly error out. I suspect that the user would have to work >>>> around this using --allow-selinux-disabled but this wouldn't make a >>>> lot of sense since they actually do have SELinux disabled. >>> >>> Yes, you're right. And the error message would not even be helpful >>> since >>> it would tell the user to install policycoreutils package. This >>> would be >>> the >>> case both with server and client installs when selinux would not be >>> installed >>> at all. >>> >>>> What do you think? >>>> >>>> rob >>> >>> Well we have 2 options as I see it: >>> >>> 1.) We can either return None as default, and add checks to >>> check_selinux_status, restore_context and install scripts that would >>> ensure that we behave properly when is_selinux_enabled() is not >>> implemented. >>> >>> 2.) We can remove the default value, since it would cause forementioned >>> crash and add comment that this function needs to be implemented >>> properly in every platform file. >>> >>> I'm probably for option 2, there's no need to clutter the code with >>> checks >>> that compensate for improper platform file implementations. >>> >>> Tomas >> >> I agree with you on option 2. >> >> rob > > I updated the patch accordingly. > > Tomas Sorry, wrong patch. Correct version attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0027-5-Add-checks-for-SELinux-in-install-scripts.patch Type: text/x-patch Size: 14062 bytes Desc: not available URL: From akrivoka at redhat.com Wed Apr 3 13:29:01 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 03 Apr 2013 15:29:01 +0200 Subject: [Freeipa-devel] [PATCH] 0209 Display full command documentation in online help In-Reply-To: <515BFCFF.4060600@redhat.com> References: <515BFCFF.4060600@redhat.com> Message-ID: <515C2E9D.7070508@redhat.com> On 04/03/2013 11:57 AM, Petr Viktorin wrote: > This fixes a regression in the help improvements. More info in the patch. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Apr 3 13:34:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 03 Apr 2013 15:34:09 +0200 Subject: [Freeipa-devel] [PATCH] 0209 Display full command documentation in online help In-Reply-To: <515C2E9D.7070508@redhat.com> References: <515BFCFF.4060600@redhat.com> <515C2E9D.7070508@redhat.com> Message-ID: <515C2FD1.4000008@redhat.com> On 04/03/2013 03:29 PM, Ana Krivokapic wrote: > On 04/03/2013 11:57 AM, Petr Viktorin wrote: >> This fixes a regression in the help improvements. More info in the patch. >> >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. Pushed to master, ipa-3-1. Martin From tbabej at redhat.com Thu Apr 4 09:48:54 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 04 Apr 2013 11:48:54 +0200 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <514C64B4.1020004@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> <514C64B4.1020004@redhat.com> Message-ID: <515D4C86.6070305@redhat.com> On 03/22/2013 03:03 PM, Martin Kosek wrote: > On 03/21/2013 06:10 PM, Petr Vobornik wrote: >> On 03/21/2013 05:10 PM, Martin Kosek wrote: >>> On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: >>>> On 3/12/2013 11:28 AM, Petr Vobornik wrote: >>>>> Here's a patch for filtering groups by type. >>>>> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >>>>> >>>>> The interface is: >>>>>> StrEnum('type?', >>>>>> cli_name='type', >>>>>> label=_('Type'), >>>>>> doc=_('Group type'), >>>>>> values=(u'posix', u'normal', u'external'), >>>>>> ), >>>>> I have two design questions. >>>>> 1. Is --type the right option name? >>>> Fine by me, it matches the label and description. >>>> >>>>> 2. Is `normal` the right name for non-posix, non-external group? The >>>>> default group type (when adding group) is posix. Should the name be >>>>> something else: `simple`, `plain`, `ordinary`? >>>> We also use 'normal' in the group adder dialog, so it's consistent. Other >>>> options are 'basic', 'standard', 'regular'. >>>> >>>>> I didn't want to create an option for each type. IMO it brings more >>>>> complexity. >>>> Maybe the group-add/mod command should use the same --type option? >>>> >>>>> https://fedorahosted.org/freeipa/ticket/3483 >>>> ACK from me, but maybe others might have some comments. >>>> >>> I am just thinking about if the new API is right. For example, when we add an >>> external group, we use ipa group-add --external. But when we search for >>> external groups, we suddenly use >>> # ipa group-find --type=external >>> and not >>> # ipa group-find --external >>> or >>> # ipa group-find --nonposix >>> >>> Wouldn't that cause confusion? I am looking for same second opinion on this one. >>> >>> I also did not like "normal" group type very much, maybe we should just call it >>> "nonposix"? As that's the option you use when you are creating such group: >>> # ipa group-add --nonposix foo >>> >>> Otherwise, the patch looks good functionally. >>> >>> Martin >>> >> I have to note that external group is also non-posix. Following command is valid: >> # ipa group-add foo --desc=a --external --nonposix >> >> By that logic >> # ipa group-find --nonposix >> >> Would also list external groups. >> >> I fine with renaming 'normal' to something better (will also require Web UI >> change), but it is not 'nonposix'. > I think this logic is flawed as well. Then you could say that posix group is > also nonposix, because it contains the same objectclasses as nonpoxis group + > posixGroup objectclass. > > "nonposix" is the term we already use (see --nonposix), not something > artificial or new, so I would not be afraid of it. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Let us try to move on with this, here are my 2 cents: 1.) normal is not a suitable name for non-posix, non-external group. As a user, I would assume that # ipa group-find --type=normal would return the groups that I created using simple # ipa group-add testgroup command. By that logic, any other suggested synonym implying there's nothing special about this group is not suitable. 2.) If not normal (or any other synonym implying there's nothing special about this group) then what? We can either: - use exact but complicated --non-posix-non-external - use --nonposix and deal with the fact that sets defined by the type are not disjunct - make up our own new term and define it While none of these options are fortunate, let's look for the least resistance: - exact, but complicated names are ugly and do not keep interface simple - nonposix groups are superset of external groups - confuses the user and makes the learning curve steeper From this I would go for option 2, indeed, if you think about --nonposix / --external as flags, where the external takes priority before nonposix, this kind of makes sense. If the user does not think about the implementation (that every external group is nonposix), he may indeed find himself in this mindset. 3.) I'm fine both with --type=external and --external approaches. The latterr is more consistent with the way we do things, *-find commands search mainly on selected subset of attributes, so using the flag analogy I mentioned an paragraph ago, you would expect --external to behave as an attribute, especially if group-add command accepts it in this form. Having 3 options instead of one will clutter things a bit more, but if we keep them in the same place (in the list of options) it should not cause much confusion, more so if the descriptions would be nearly the same, one would quickly see that these belong together. Tomas From mkosek at redhat.com Thu Apr 4 10:02:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Apr 2013 12:02:20 +0200 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <515D4C86.6070305@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> <514C64B4.1020004@redhat.com> <515D4C86.6070305@redhat.com> Message-ID: <515D4FAC.2030705@redhat.com> On 04/04/2013 11:48 AM, Tomas Babej wrote: > On 03/22/2013 03:03 PM, Martin Kosek wrote: >> On 03/21/2013 06:10 PM, Petr Vobornik wrote: >>> On 03/21/2013 05:10 PM, Martin Kosek wrote: >>>> On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: >>>>> On 3/12/2013 11:28 AM, Petr Vobornik wrote: >>>>>> Here's a patch for filtering groups by type. >>>>>> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >>>>>> >>>>>> The interface is: >>>>>>> StrEnum('type?', >>>>>>> cli_name='type', >>>>>>> label=_('Type'), >>>>>>> doc=_('Group type'), >>>>>>> values=(u'posix', u'normal', u'external'), >>>>>>> ), >>>>>> I have two design questions. >>>>>> 1. Is --type the right option name? >>>>> Fine by me, it matches the label and description. >>>>> >>>>>> 2. Is `normal` the right name for non-posix, non-external group? The >>>>>> default group type (when adding group) is posix. Should the name be >>>>>> something else: `simple`, `plain`, `ordinary`? >>>>> We also use 'normal' in the group adder dialog, so it's consistent. Other >>>>> options are 'basic', 'standard', 'regular'. >>>>> >>>>>> I didn't want to create an option for each type. IMO it brings more >>>>>> complexity. >>>>> Maybe the group-add/mod command should use the same --type option? >>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3483 >>>>> ACK from me, but maybe others might have some comments. >>>>> >>>> I am just thinking about if the new API is right. For example, when we add an >>>> external group, we use ipa group-add --external. But when we search for >>>> external groups, we suddenly use >>>> # ipa group-find --type=external >>>> and not >>>> # ipa group-find --external >>>> or >>>> # ipa group-find --nonposix >>>> >>>> Wouldn't that cause confusion? I am looking for same second opinion on this >>>> one. >>>> >>>> I also did not like "normal" group type very much, maybe we should just >>>> call it >>>> "nonposix"? As that's the option you use when you are creating such group: >>>> # ipa group-add --nonposix foo >>>> >>>> Otherwise, the patch looks good functionally. >>>> >>>> Martin >>>> >>> I have to note that external group is also non-posix. Following command is >>> valid: >>> # ipa group-add foo --desc=a --external --nonposix >>> >>> By that logic >>> # ipa group-find --nonposix >>> >>> Would also list external groups. >>> >>> I fine with renaming 'normal' to something better (will also require Web UI >>> change), but it is not 'nonposix'. >> I think this logic is flawed as well. Then you could say that posix group is >> also nonposix, because it contains the same objectclasses as nonpoxis group + >> posixGroup objectclass. >> >> "nonposix" is the term we already use (see --nonposix), not something >> artificial or new, so I would not be afraid of it. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > Let us try to move on with this, here are my 2 cents: > > 1.) normal is not a suitable name for non-posix, non-external group. As a user, > I would assume that > # ipa group-find --type=normal > > would return the groups that I created using simple > # ipa group-add testgroup > > command. By that logic, any other suggested synonym implying there's nothing > special about this > group is not suitable. > > 2.) If not normal (or any other synonym implying there's nothing special about > this group) then what? > We can either: > - use exact but complicated --non-posix-non-external > - use --nonposix and deal with the fact that sets defined by the type are not > disjunct > - make up our own new term and define it > > While none of these options are fortunate, let's look for the least resistance: > - exact, but complicated names are ugly and do not keep interface simple > - nonposix groups are superset of external groups > - confuses the user and makes the learning curve steeper > > From this I would go for option 2, indeed, if you think about --nonposix / > --external as flags, where > the external takes priority before nonposix, this kind of makes sense. If the > user does not think > about the implementation (that every external group is nonposix), he may indeed > find himself in this mindset. > > 3.) I'm fine both with --type=external and --external approaches. The latterr > is more consistent with the way we do things, > *-find commands search mainly on selected subset of attributes, so using the > flag analogy I mentioned an paragraph ago, > you would expect --external to behave as an attribute, especially if group-add > command accepts it in this form. > > Having 3 options instead of one will clutter things a bit more, but if we keep > them in the same place (in the list of options) > it should not cause much confusion, more so if the descriptions would be nearly > the same, one would quickly see that these > belong together. > > Tomas > Thanks Tomas for your opinion, I can agree with that. To make it more in an actual design, this is API following this discussion that I would propose: This is API we already have in IPA: ipa group-add --external ipa group-add --nonposix ipa group-find --private This is API that I would propose to add to be consistent with what we already have: ipa group-find --nonposix ipa group-find --posix ipa group-find --external --nonposix would only match groups added with --nonposix flag in group-add, i.e. no --external groups. As Tomas said, these should also be close together. We can even add a specific option group for them, like there are with ipa dnsrecord-add, named for example "Group Types". We may also raise OptionError when these option are used together to make this less confusing - e.g. OptionError("group type options (--nonposix, --posix and --external) are mutually exclusive"). Martin From mkosek at redhat.com Thu Apr 4 10:51:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Apr 2013 12:51:58 +0200 Subject: [Freeipa-devel] [PATCH] 0011 Remove CA cert on client uninstall In-Reply-To: <515C0ED0.2040801@redhat.com> References: <515B1FF4.1060206@redhat.com> <515C0ED0.2040801@redhat.com> Message-ID: <515D5B4E.7060103@redhat.com> On 04/03/2013 01:13 PM, Tomas Babej wrote: > On Tue 02 Apr 2013 08:14:12 PM CEST, Ana Krivokapic wrote: >> Hello, >> >> The CA cert (/etc/ipa/ca.crt) was not being removed on client uninstall, >> causing failure on subsequent client installation in some cases. >> >> https://fedorahosted.org/freeipa/ticket/3537 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK. > > Tomas Pushed to master, ipa-3-1. Martin From mkosek at redhat.com Thu Apr 4 10:55:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 04 Apr 2013 12:55:27 +0200 Subject: [Freeipa-devel] [PATCH] 273 Add ipakrbokasdelegate option to service and host Web UI pages In-Reply-To: <515AA3DE.90900@redhat.com> References: <5155BCE4.2050100@redhat.com> <5155C000.2070002@redhat.com> <515AA3DE.90900@redhat.com> Message-ID: <515D5C1F.4040807@redhat.com> On 04/02/2013 11:24 AM, Jan Cholasta wrote: > Hi, > > On 29.3.2013 17:23, Petr Vobornik wrote: >> On 03/29/2013 05:10 PM, Petr Vobornik wrote: >>> >>> https://fedorahosted.org/freeipa/ticket/3329 >>> >> >> Attaching new rebased version. >> > > It seems everything works fine, ACK. > > Honza > Pushed to master. Martin From rcritten at redhat.com Thu Apr 4 13:04:31 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Apr 2013 09:04:31 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <5151C859.6040208@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> Message-ID: <515D7A5F.3050703@redhat.com> Rob Crittenden wrote: > Petr Viktorin wrote: >> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>> There are strict limits on what can be restored where. Only exact >>> matching hostnames and versions are allowed right now. We can probably >>> relax the hostname requirement if we're only restoring data, and the >>> version perhaps for only the the first two values (so you can restore a >>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >> >> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >> Or is what they put in /var/lib guaranteed portable across versions? > > An interesting question. I'd imagine that a major db change would also > require a major update to IPA, therefore if we restrict by IPA version > we should be ok. I AM doing an untar of files though so yeah, there is a > risk here. > >> >> >> That's good to hear! >> >> I think while developing, you should run with -v to get all the output. >> And for production, please have the commands log by default (set >> log_file_name). > > Yes, I plan on adding that in the future. > >> >>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>> password because we need to contact remote servers to enable/disable >>> replication. >> >> The restore assumes that ipa is already installed, right? I can't just >> run it on a clean machine? Id would be good to check/document this. > > It depends. > > For a full backup you can actually restore to an uninstalled server. In > fact, you could restore to a machine w/no IPA bits on it at all in all > likelihood (which wouldn't be very nice, but not exactly wrong either > IMHO). > > I tested this with: > - ipa-server-install > - ipa-backup > - ipa-server-install --uninstall -U > - ipa-restore > - ran the unit tests > >> I looked in the backup tarball and saw dirsrv PID file and lock >> directories. Are these needed? > > Probably not. I gathered some of the files to backup based on watching > what files that changed during an install that are independent of us. > I'll take another pass through it, there may be other oddities too. > >> The tool runners (install/tools/ipa-backup and >> install/tools/ipa-restore) are missing, so IPA doesn't build. Probably >> just a forgotten git add. > > Yup. > >> >> The patch adds an extra backslash in install/tools/man/Makefile.am; >> consider adding $(NULL) at the end. > > I'll take a look. > >> >> Backup.dirs, Backup.files, Backup.logs: >> The code modifies these class-level attributes. This means you can't run >> the command more than once in one Python session, so it can't be used as >> a library (e.g. in a hypothetical test suite). >> Please make the class atrributes immutable (tuples), then in __init__ do >> `self.dirs = list(self.dirs)` to to get instance-specific lists. > > Ok, fair point. > >> Code that creates temporary files/directories or does chdir() should be >> next to (or in) a try block whose finally: restores things. > > Yes, I mean to add a big try/finally block around everything in run > eventually (or the equivalent anyway). > >> >> Instead of star imports (from ipapython.ipa_log_manager import *), >> please explicitly import whatever you're using from that package. In >> this case, nothing at all! > > Yeah, I haven't run this through pylint yet to see all the bad imports I > cobbled together. > >> If there's a get_connection() method, it should return the connection, >> and it should always be used to get it. Store the connection in >> self._conn, and rather than: >> self.get_connection() >> self.conn.do_work() >> do: >> conn = self.get_connection() >> conn.do_work() >> This makes forgetting to call get_connection() impossible. > > My purpose was to avoid creating multiple connections. > >> If a variable is only used in a single method, like `filename` in >> Restore.extract_backup, don't store it in the admintool object. >> In general, try to avoid putting data in self if possible. It's >> convenient but it allows complex interdependencies. >> (Yes, I'm guilty of not following this myself.) > > Yes, there is certainly a bit of cleanup to do. I was in a bit of a rush > to get this WIP out. > >> In several places, the backup tool logs critical errors and then just >> continues on. Is that by design? I think a nonzero exit code would be >> appropriate. > > I'll take a look at them, all I can say at this point is maybe. > >> In the ipa-restore man page, --backend is not documented. >> >> In db2ldif, db2bak, etc., a more conscise way to get the time string is >> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >> >> When validating --gpg-keyring, it would be good to check both files >> (.sec and .pub). > > Ok, I can do those. > >> >> Here: >> if (self.backup_type != 'FULL' and not options.data_only and >> not instances): >> raise admintool.ScriptError('Cannot restore a data backup into >> an empty system') >> did you mean `(self.backup_type != 'FULL' or options.data_only) and not >> instances`? (I'd introduce a `data_only` flag to prevent confusion.) > > Yeah, looks like that should be an or. > >> In the ReplicationManager.check_repl_init reporting: use >> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >> include full days. I don't think anyone would wait long enough for the >> overflow, but better to be correct. > > Sure, I doubt anyone would wait 24 hours either but its a no-brainer to > make it safe. I think I've addressed just about everything. The reason that /var/run/dirsrv and var/lock/dirsrv are included in the backup is for the case of a full restore. These directories are not created/provided by the package itself, but by installing the first instance, so we need the ownership/SELinux context preserved. One thing I need tested is restoring over top of new data with multiple replicas. So basically install, do a backup, add a bunch of data, restore, re-initialize all the other masters and then confirm that ALL the new data is gone. I think I've got the sequence right but this is critical. This should work on fresh installs and upgrades from 3.0 (e.g. dogtag 9/multi-instance DS configurations). One thing I tested was: - ipa-server-install - ipa-backup - ipa-server-install --uninstall -U - ipa-restore ipa-full-... This will actually get your server back EXCEPT that dogtag won't start. This is because the log directories are created by the instance creation. There are two solutions: backup with --logs or manually re-create the log directories (there are several, depending on dogtag version). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1093-2-backup.patch Type: text/x-patch Size: 76336 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 4 14:25:44 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Apr 2013 10:25:44 -0400 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <515C105B.6030304@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> <5159E78A.9090902@redhat.com> <515A9132.6030404@redhat.com> <515C105B.6030304@redhat.com> Message-ID: <515D8D68.1060901@redhat.com> Tomas Babej wrote: > On Tue 02 Apr 2013 10:05:06 AM CEST, Tomas Babej wrote: >> On Mon 01 Apr 2013 10:01:14 PM CEST, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>>>>> Tomas Babej wrote: >>>>>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> The checks make sure that SELinux is: >>>>>>>>> - installed and enabled (on server install) >>>>>>>>> - installed and enabled OR not installed (on client install) >>>>>>>>> >>>>>>>>> Please note that client installs with SELinux not installed are >>>>>>>>> allowed since freeipa-client package has no dependency on SELinux. >>>>>>>>> (any objections to this approach?) >>>>>>>>> >>>>>>>>> The (unsupported) option --allow-no-selinux has been added. It can >>>>>>>>> used to bypass the checks. >>>>>>>>> >>>>>>>>> Parts of platform-dependant code were refactored to use newly >>>>>>>>> added >>>>>>>>> is_selinux_enabled() function. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> >>>>>>>> I forgot to edit the man pages. Thanks Rob! >>>>>>>> >>>>>>>> Updated patch attached. >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> After a bit of off-line discussion I don't think we're quite ready >>>>>>> yet >>>>>>> to require SELinux by default on client installations (even with a >>>>>>> flag to work around it). The feeling is this would be disruptive to >>>>>>> existing automation. >>>>>>> >>>>>>> Can you still do the check but not enforce it, simply display a big >>>>>>> warning if SELinux is disabled? >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Sure, here is the updated patch. >>>>>> >>>>>> I edited the commit message, RFE description and man pages >>>>>> according to >>>>>> the new behaviour. >>>>>> >>>>>> Tomas >>>>> >>>>> The patch looks good, I'm just wondering about one thing. The default >>>>> value for is_selinux_enabled() is True in ipapython/services.py.in. >>>>> >>>>> So this means that any non-Red Hat/non-Fedora system, by default, is >>>>> going to assume that SELinux is enabled. >>>>> >>>>> My hesitation has to when we call check_selinux_status(). It may >>>>> incorrectly error out. I suspect that the user would have to work >>>>> around this using --allow-selinux-disabled but this wouldn't make a >>>>> lot of sense since they actually do have SELinux disabled. >>>> >>>> Yes, you're right. And the error message would not even be helpful >>>> since >>>> it would tell the user to install policycoreutils package. This >>>> would be >>>> the >>>> case both with server and client installs when selinux would not be >>>> installed >>>> at all. >>>> >>>>> What do you think? >>>>> >>>>> rob >>>> >>>> Well we have 2 options as I see it: >>>> >>>> 1.) We can either return None as default, and add checks to >>>> check_selinux_status, restore_context and install scripts that would >>>> ensure that we behave properly when is_selinux_enabled() is not >>>> implemented. >>>> >>>> 2.) We can remove the default value, since it would cause forementioned >>>> crash and add comment that this function needs to be implemented >>>> properly in every platform file. >>>> >>>> I'm probably for option 2, there's no need to clutter the code with >>>> checks >>>> that compensate for improper platform file implementations. >>>> >>>> Tomas >>> >>> I agree with you on option 2. >>> >>> rob >> >> I updated the patch accordingly. >> >> Tomas > > Sorry, wrong patch. Correct version attached. > > Tomas I'm sorry to throw this back again after so long (and having agreed with the approach). So I was thinking about how another distro maintainer would have to deal with this. By default with this patch check_selinux_status() returns None which is evaluated as False, so the warning will get thrown. If they set it to be True to avoid the warning then other things may blow up because SELinux really isn't enabled, so we really haven't gotten anywhere. I think the problem is we're trying to cram too much into one function. I wonder if a is_selinux_available() command would help which would short-circuit all of this. While trying to figure out how this worked I found httpinstance.configure_selinux_for_httpd() which makes a similar call to see if SELinux is available, so maybe we should convert that as well. rob From pviktori at redhat.com Thu Apr 4 15:15:15 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 04 Apr 2013 17:15:15 +0200 Subject: [Freeipa-devel] [PATCHES] 0210-0213 Drop selfsign server functionality Message-ID: <515D9903.1080807@redhat.com> Hello, These patches convert selfsign masters to CA-less on upgrade, and remove all selfsign-related code The files the CA uses are left around for admins to pick up cert management manually. Instructions for that are provided in the design document. They pretty much just document what the selfsign CA did. Removing the automation may seem like a step backwards, but when the steps are just a wiki page, the admins can adjust for their needs (e.g. issue wildcart certs). For an automated solution we have Dogtag. Design: http://freeipa.org/page/V3/Drop_selfsign_functionality Ticket: https://fedorahosted.org/freeipa/ticket/3494 (Note that removing the --selfsign *option*, not functionality, has a separate ticket and design doc.) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0210-Uninstall-selfsign-CA-on-upgrade.patch Type: text/x-patch Size: 5782 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0211-Remove-obsolete-self-sign-references-from-man-pages-.patch Type: text/x-patch Size: 6039 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0212-Drop-selfsign-server-functionality.patch Type: text/x-patch Size: 55265 bytes Desc: not available URL: From abokovoy at redhat.com Thu Apr 4 15:28:24 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Apr 2013 18:28:24 +0300 Subject: [Freeipa-devel] [PATCH] 0101 specfile: detect Kerberos DAL driver ABI change from installed krb5-devel package Message-ID: <20130404152824.GT6823@redhat.com> Find out Kerberos middle version to infer ABI changes in DAL driver. We cannot load DAL driver into KDC with wrong ABI. This is also needed to support ipa-devel repository where krb5 1.11 is available for Fedora 18. Right now krb5 1.11 is in ipa-devel repo for Fedora 18 and FreeIPA git master packages built against it but bear wrong Requires, resulting in inability to install FreeIPA on Fedora 18. -- / Alexander Bokovoy -------------- next part -------------- >From 8774f12c75c119df2fa38322769a4136cd4f9e01 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Apr 2013 18:20:25 +0300 Subject: [PATCH] spec: detect Kerberos DAL driver ABI change from installed krb5-devel Find out Kerberos middle version to infer ABI changes in DAL driver. We cannot load DAL driver into KDC with wrong ABI. This is also needed to support ipa-devel repository where krb5 1.11 is available for Fedora 18. --- freeipa.spec.in | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 5e84453..93bba9c 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -74,6 +74,11 @@ BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: java-1.7.0-openjdk +# Find out Kerberos middle version to infer ABI changes in DAL driver +# We cannot load DAL driver into KDC with wrong ABI. +# This is also needed to support ipa-devel repository where krb5 1.11 is available for F18 +%global krb5_dal_version %{expand:%(rpmquery --qf='%{VERSION}' krb5-devel|cut -d. -f2)} + %description IPA is an integrated solution to provide centrally managed Identity (machine, user, virtual machines, groups, authentication credentials), Policy @@ -92,10 +97,10 @@ Requires: 389-ds-base >= 1.3.0.5 Requires: openldap-clients Requires: nss Requires: nss-tools -%if 0%{?fedora} >= 19 +%if 0%{?krb5_dal_version} >= 11 Requires: krb5-server >= 1.11 %else -%if 0%{?fedora} == 18 +%if 0%{krb5_dal_version} == 10 # krb5 1.11 bumped DAL interface major version, a rebuild is needed Requires: krb5-server < 1.11 Requires: krb5-server >= 1.10 -- 1.8.1.4 From rcritten at redhat.com Thu Apr 4 15:59:42 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Apr 2013 11:59:42 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1362754629.9093.10.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> Message-ID: <515DA36E.7020003@redhat.com> Nathaniel McCallum wrote: > On Fri, 2013-03-08 at 09:50 -0500, Simo Sorce wrote: >> On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: >>> On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: >>>> Patch is attached. >>>> >>>> There are currently a few security downsides to this patch: >>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously >>>> 2. ipatokenRadiusSecret is readable by an anonymous bind >>>> >>>> This patch also adds some new dependencies, namely: >>>> 1. libverto (a dependency of krb5) >>>> 2. systemd >>>> 3. a krb5 patched for libk5radius support [1] >>>> >>>> In the interest of trying to meet the Fedora Features deadline, I am >>>> providing the patch in spite of the above issues. >>>> >>>> Nathaniel >>>> >>>> 1 - http://bit.ly/ZqtK79 >>> >>> Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the >>> schema. This will need to be verified and finalized. >> >> I reserved this OID space for ipa OTP schema. > > Thanks! For posterity, where is this documented? > > Nathaniel In daemons/configure.ac you fix up the inconsistent tab/spacing we use when displaying a summary for IPA Server, except you add a tab in the CFLAGS line. Trailing white space in 70ipaotp.ldif Just a style thing, you use tmp as a variable a lot to do somewhat beefy things (e.g. find_base()) Does hostname need to be fully-qualified? We enforce this during the install but things change. I don't know if that is important for this daemon. ENOMEM is used as an error code when some things fail, sometimes in favor of the real error message: + /* Set Service-Type. */ + retval = k5_radius_attrset_add_number(ctx.attrs, + k5_radius_attr_name2num("Service-Type"), + K5_RADIUS_SERVICE_TYPE_AUTHENTICATE_ONLY); + if (retval != 0) { + log_err(ENOMEM, "Unable to set Service-Type"); + goto error; + } No man pages In setup_ldap() there might be an inconsequential memory leak. If there is no base, and one is found, but some later part of the LDAP sequence fails an error will be returned but the base will remain set. It seems that you quit on all setup_ldap() failures so this is probably no big deal. In on_query_readable() is it an error if multiple entries are returned? And there is tmp again. I had to do a double-take on the return value of the parse_ commands to realize that tmp was the error string. It doesn't look like the LDAP entry is freed in on_query_readable(). We'll need to handle upgrades eventually too. Can you add the ticket(s) to the git commit message. If there are any wiki design pages it would help to point to those. You'll need to add the new BuildRequires to freeipa.spec.in too. There isn't a lot of documentation on what each of these files/functions are supposed to do. rob From abokovoy at redhat.com Thu Apr 4 17:07:10 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 4 Apr 2013 20:07:10 +0300 Subject: [Freeipa-devel] [PATCH] 0101 specfile: detect Kerberos DAL driver ABI change from installed krb5-devel package In-Reply-To: <20130404152824.GT6823@redhat.com> References: <20130404152824.GT6823@redhat.com> Message-ID: <20130404170710.GV6823@redhat.com> On Thu, 04 Apr 2013, Alexander Bokovoy wrote: >Find out Kerberos middle version to infer ABI changes in DAL driver. > >We cannot load DAL driver into KDC with wrong ABI. This is also needed >to support ipa-devel repository where krb5 1.11 is available for Fedora 18. > >Right now krb5 1.11 is in ipa-devel repo for Fedora 18 and FreeIPA git >master packages built against it but bear wrong Requires, resulting in >inability to install FreeIPA on Fedora 18. After discussing with Simo, now discover real DAL ABI version: 3 is Kerberos 1.10 4 is Kerberos 1.11 so far. I'm using 'cpp -dM' to extract list of defined macros instead of grepping /usr/include/kdb.h directly to avoid breakage if kdb.h would be split out at some point (if any). -- / Alexander Bokovoy -------------- next part -------------- >From 3cdde9b8441434ee80bbcba8c0e6a687c057a19a Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 4 Apr 2013 18:20:25 +0300 Subject: [PATCH] spec: detect Kerberos DAL driver ABI change from installed krb5-devel Find out Kerberos middle version to infer ABI changes in DAL driver. We cannot load DAL driver into KDC with wrong ABI. This is also needed to support ipa-devel repository where krb5 1.11 is available for Fedora 18. --- freeipa.spec.in | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 5e84453..3461e06 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -74,6 +74,11 @@ BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: java-1.7.0-openjdk +# Find out Kerberos middle version to infer ABI changes in DAL driver +# We cannot load DAL driver into KDC with wrong ABI. +# This is also needed to support ipa-devel repository where krb5 1.11 is available for F18 +%global krb5_dal_version %{expand:%(echo "#include "|cpp -dM|grep KRB5_KDB_DAL_MAJOR_VERSION|cut -d' ' -f3)} + %description IPA is an integrated solution to provide centrally managed Identity (machine, user, virtual machines, groups, authentication credentials), Policy @@ -92,10 +97,10 @@ Requires: 389-ds-base >= 1.3.0.5 Requires: openldap-clients Requires: nss Requires: nss-tools -%if 0%{?fedora} >= 19 +%if 0%{?krb5_dal_version} >= 4 Requires: krb5-server >= 1.11 %else -%if 0%{?fedora} == 18 +%if 0%{krb5_dal_version} == 3 # krb5 1.11 bumped DAL interface major version, a rebuild is needed Requires: krb5-server < 1.11 Requires: krb5-server >= 1.10 @@ -783,6 +788,9 @@ fi %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt %changelog +* Thu Apr 4 2013 Alexander Bokovoy - 3.1.99-3 +- Make sure build against Krb5 1.11 in Fedora 18 environment creates proper dependencies + * Tue Apr 2 2013 Martin Kosek - 3.1.99-2 - Require 389-base-base >= 1.3.0.5 to pull the following fixes: - upgrade deadlock caused by DNA plugin reconfiguration -- 1.8.1.4 From simo at redhat.com Thu Apr 4 17:09:11 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 04 Apr 2013 13:09:11 -0400 Subject: [Freeipa-devel] [PATCH] 0101 specfile: detect Kerberos DAL driver ABI change from installed krb5-devel package In-Reply-To: <20130404170710.GV6823@redhat.com> References: <20130404152824.GT6823@redhat.com> <20130404170710.GV6823@redhat.com> Message-ID: <1365095351.2660.1345.camel@willson.li.ssimo.org> On Thu, 2013-04-04 at 20:07 +0300, Alexander Bokovoy wrote: > On Thu, 04 Apr 2013, Alexander Bokovoy wrote: > >Find out Kerberos middle version to infer ABI changes in DAL driver. > > > >We cannot load DAL driver into KDC with wrong ABI. This is also needed > >to support ipa-devel repository where krb5 1.11 is available for Fedora 18. > > > >Right now krb5 1.11 is in ipa-devel repo for Fedora 18 and FreeIPA git > >master packages built against it but bear wrong Requires, resulting in > >inability to install FreeIPA on Fedora 18. > > After discussing with Simo, now discover real DAL ABI version: > > 3 is Kerberos 1.10 > 4 is Kerberos 1.11 > > so far. > > I'm using 'cpp -dM' to extract list of defined macros instead of > grepping /usr/include/kdb.h directly to avoid breakage if kdb.h would be > split out at some point (if any). Looks good to me. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Apr 4 17:26:39 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Apr 2013 13:26:39 -0400 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <515D4FAC.2030705@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> <514C64B4.1020004@redhat.com> <515D4C86.6070305@redhat.com> <515D4FAC.2030705@redhat.com> Message-ID: <515DB7CF.4040408@redhat.com> Martin Kosek wrote: > On 04/04/2013 11:48 AM, Tomas Babej wrote: >> On 03/22/2013 03:03 PM, Martin Kosek wrote: >>> On 03/21/2013 06:10 PM, Petr Vobornik wrote: >>>> On 03/21/2013 05:10 PM, Martin Kosek wrote: >>>>> On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: >>>>>> On 3/12/2013 11:28 AM, Petr Vobornik wrote: >>>>>>> Here's a patch for filtering groups by type. >>>>>>> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >>>>>>> >>>>>>> The interface is: >>>>>>>> StrEnum('type?', >>>>>>>> cli_name='type', >>>>>>>> label=_('Type'), >>>>>>>> doc=_('Group type'), >>>>>>>> values=(u'posix', u'normal', u'external'), >>>>>>>> ), >>>>>>> I have two design questions. >>>>>>> 1. Is --type the right option name? >>>>>> Fine by me, it matches the label and description. >>>>>> >>>>>>> 2. Is `normal` the right name for non-posix, non-external group? The >>>>>>> default group type (when adding group) is posix. Should the name be >>>>>>> something else: `simple`, `plain`, `ordinary`? >>>>>> We also use 'normal' in the group adder dialog, so it's consistent. Other >>>>>> options are 'basic', 'standard', 'regular'. >>>>>> >>>>>>> I didn't want to create an option for each type. IMO it brings more >>>>>>> complexity. >>>>>> Maybe the group-add/mod command should use the same --type option? >>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3483 >>>>>> ACK from me, but maybe others might have some comments. >>>>>> >>>>> I am just thinking about if the new API is right. For example, when we add an >>>>> external group, we use ipa group-add --external. But when we search for >>>>> external groups, we suddenly use >>>>> # ipa group-find --type=external >>>>> and not >>>>> # ipa group-find --external >>>>> or >>>>> # ipa group-find --nonposix >>>>> >>>>> Wouldn't that cause confusion? I am looking for same second opinion on this >>>>> one. >>>>> >>>>> I also did not like "normal" group type very much, maybe we should just >>>>> call it >>>>> "nonposix"? As that's the option you use when you are creating such group: >>>>> # ipa group-add --nonposix foo >>>>> >>>>> Otherwise, the patch looks good functionally. >>>>> >>>>> Martin >>>>> >>>> I have to note that external group is also non-posix. Following command is >>>> valid: >>>> # ipa group-add foo --desc=a --external --nonposix >>>> >>>> By that logic >>>> # ipa group-find --nonposix >>>> >>>> Would also list external groups. >>>> >>>> I fine with renaming 'normal' to something better (will also require Web UI >>>> change), but it is not 'nonposix'. >>> I think this logic is flawed as well. Then you could say that posix group is >>> also nonposix, because it contains the same objectclasses as nonpoxis group + >>> posixGroup objectclass. >>> >>> "nonposix" is the term we already use (see --nonposix), not something >>> artificial or new, so I would not be afraid of it. >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Let us try to move on with this, here are my 2 cents: >> >> 1.) normal is not a suitable name for non-posix, non-external group. As a user, >> I would assume that >> # ipa group-find --type=normal >> >> would return the groups that I created using simple >> # ipa group-add testgroup >> >> command. By that logic, any other suggested synonym implying there's nothing >> special about this >> group is not suitable. >> >> 2.) If not normal (or any other synonym implying there's nothing special about >> this group) then what? >> We can either: >> - use exact but complicated --non-posix-non-external >> - use --nonposix and deal with the fact that sets defined by the type are not >> disjunct >> - make up our own new term and define it >> >> While none of these options are fortunate, let's look for the least resistance: >> - exact, but complicated names are ugly and do not keep interface simple >> - nonposix groups are superset of external groups >> - confuses the user and makes the learning curve steeper >> >> From this I would go for option 2, indeed, if you think about --nonposix / >> --external as flags, where >> the external takes priority before nonposix, this kind of makes sense. If the >> user does not think >> about the implementation (that every external group is nonposix), he may indeed >> find himself in this mindset. >> >> 3.) I'm fine both with --type=external and --external approaches. The latterr >> is more consistent with the way we do things, >> *-find commands search mainly on selected subset of attributes, so using the >> flag analogy I mentioned an paragraph ago, >> you would expect --external to behave as an attribute, especially if group-add >> command accepts it in this form. >> >> Having 3 options instead of one will clutter things a bit more, but if we keep >> them in the same place (in the list of options) >> it should not cause much confusion, more so if the descriptions would be nearly >> the same, one would quickly see that these >> belong together. >> >> Tomas >> > > Thanks Tomas for your opinion, I can agree with that. To make it more in an > actual design, this is API following this discussion that I would propose: > > This is API we already have in IPA: > ipa group-add --external > ipa group-add --nonposix > ipa group-find --private > > This is API that I would propose to add to be consistent with what we already have: > ipa group-find --nonposix > ipa group-find --posix > ipa group-find --external > > --nonposix would only match groups added with --nonposix flag in group-add, > i.e. no --external groups. > > As Tomas said, these should also be close together. We can even add a specific > option group for them, like there are with ipa dnsrecord-add, named for example > "Group Types". We may also raise OptionError when these option are used > together to make this less confusing - e.g. OptionError("group type options > (--nonposix, --posix and --external) are mutually exclusive"). I chatted with Petr about this in IRC and I think this is the same conclusion we came to. I don't think we should return an error with these mutually-exclusive options, just return nothing. As Petr pointed out, adding additional flags does an AND operation and since there normally isn't an intersection with these flags returning nothing is perfectly ok. rob From simo at redhat.com Thu Apr 4 17:31:44 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 04 Apr 2013 13:31:44 -0400 Subject: [Freeipa-devel] [PATCH] 0101 specfile: detect Kerberos DAL driver ABI change from installed krb5-devel package In-Reply-To: <1365095351.2660.1345.camel@willson.li.ssimo.org> References: <20130404152824.GT6823@redhat.com> <20130404170710.GV6823@redhat.com> <1365095351.2660.1345.camel@willson.li.ssimo.org> Message-ID: <1365096704.2660.1346.camel@willson.li.ssimo.org> On Thu, 2013-04-04 at 13:09 -0400, Simo Sorce wrote: > On Thu, 2013-04-04 at 20:07 +0300, Alexander Bokovoy wrote: > > On Thu, 04 Apr 2013, Alexander Bokovoy wrote: > > >Find out Kerberos middle version to infer ABI changes in DAL driver. > > > > > >We cannot load DAL driver into KDC with wrong ABI. This is also needed > > >to support ipa-devel repository where krb5 1.11 is available for Fedora 18. > > > > > >Right now krb5 1.11 is in ipa-devel repo for Fedora 18 and FreeIPA git > > >master packages built against it but bear wrong Requires, resulting in > > >inability to install FreeIPA on Fedora 18. > > > > After discussing with Simo, now discover real DAL ABI version: > > > > 3 is Kerberos 1.10 > > 4 is Kerberos 1.11 > > > > so far. > > > > I'm using 'cpp -dM' to extract list of defined macros instead of > > grepping /usr/include/kdb.h directly to avoid breakage if kdb.h would be > > split out at some point (if any). > > Looks good to me. > > Simo. > Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Apr 4 19:14:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Apr 2013 15:14:29 -0400 Subject: [Freeipa-devel] [PATCHES] 0210-0213 Drop selfsign server functionality In-Reply-To: <515D9903.1080807@redhat.com> References: <515D9903.1080807@redhat.com> Message-ID: <515DD115.3030501@redhat.com> Petr Viktorin wrote: > Hello, > > These patches convert selfsign masters to CA-less on upgrade, and remove > all selfsign-related code > > The files the CA uses are left around for admins to pick up cert > management manually. Instructions for that are provided in the design > document. They pretty much just document what the selfsign CA did. > Removing the automation may seem like a step backwards, but when the > steps are just a wiki page, the admins can adjust for their needs (e.g. > issue wildcart certs). For an automated solution we have Dogtag. > > Design: http://freeipa.org/page/V3/Drop_selfsign_functionality > Ticket: https://fedorahosted.org/freeipa/ticket/3494 > > (Note that removing the --selfsign *option*, not functionality, has a > separate ticket and design doc.) As I've been looking at this I'm having some reservations about this. It is going to remove functionality from a running server. And once gone I don't think one could easily get it back. I guess I'd be fine deprecating it and no longer providing any support, and strongly recommending that people move away from it, but dropping it mid-release seems rather strict. rob From rcritten at redhat.com Thu Apr 4 20:44:36 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 04 Apr 2013 16:44:36 -0400 Subject: [Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback In-Reply-To: <514C673E.70800@redhat.com> References: <514C673E.70800@redhat.com> Message-ID: <515DE634.6020105@redhat.com> Jan Cholasta wrote: > Hi, > > this patch enables SASL mapping fallback in IPA DS instance, see > . Automated replication > recovery and external user mapping is not part of the patch. > > In order to test this, you need 389-ds-base 1.3.1 packages with patches > from including the last patch, > which is not yet in git. > > Honza This patch works well enough against a devel build at http://nkinder.fedorapeople.org/389-devel/ without the Requires on 1.3.1 (the devel build still claims to be 1.3.0.5). The patch itself doesn't do much yet but it does what it says it does. I can't push it yet because of the missing upstream packages. rob From pvoborni at redhat.com Fri Apr 5 08:45:58 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Apr 2013 10:45:58 +0200 Subject: [Freeipa-devel] [PATCH] 269 Run permission target switch action only for visible widgets In-Reply-To: <514B3321.3010904@redhat.com> References: <514B2883.7090702@redhat.com> <514B3321.3010904@redhat.com> Message-ID: <515E8F46.2020302@redhat.com> On 03/21/2013 05:19 PM, Ana Krivokapic wrote: > On 03/21/2013 04:34 PM, Petr Vobornik wrote: >> Permission details page was incorrectly evaluated as dirty (update >> button enabled) right after load when permission type={subtree,filter} >> and some attrs are set. >> >> Can be reproduced by opening 'Modify Automount maps' permission. >> >> The culprit is that attrs widget is populated and dirty-checked even >> targets where it doesn't belong. >> >> Fixed by running target_mapping action only for visible targets. >> >> https://fedorahosted.org/freeipa/ticket/3527 >> > > The patch fixes the issue. ACK. > Pushed to master. -- Petr Vobornik From pvoborni at redhat.com Fri Apr 5 11:28:29 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 05 Apr 2013 13:28:29 +0200 Subject: [Freeipa-devel] PATCH] 275 Fix regression in group type selection in group adder dialog Message-ID: <515EB55D.30101@redhat.com> Refactoring of radio widget (04325fbb4c64ee4aef6d8c9adf0ff95b8b653101) caused that value is no longer supplied to value_change handler. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0275-Fix-regression-in-group-type-selection-in-group-adde.patch Type: text/x-patch Size: 1299 bytes Desc: not available URL: From tbabej at redhat.com Fri Apr 5 11:45:57 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 05 Apr 2013 13:45:57 +0200 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <515D8D68.1060901@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> <5159E78A.9090902@redhat.com> <515A9132.6030404@redhat.com> <515C105B.6030304@redhat.com> <515D8D68.1060901@redhat.com> Message-ID: <515EB975.5060503@redhat.com> On 04/04/2013 04:25 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On Tue 02 Apr 2013 10:05:06 AM CEST, Tomas Babej wrote: >>> On Mon 01 Apr 2013 10:01:14 PM CEST, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >>>>>> Tomas Babej wrote: >>>>>>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>>>>>> Tomas Babej wrote: >>>>>>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> The checks make sure that SELinux is: >>>>>>>>>> - installed and enabled (on server install) >>>>>>>>>> - installed and enabled OR not installed (on client install) >>>>>>>>>> >>>>>>>>>> Please note that client installs with SELinux not installed are >>>>>>>>>> allowed since freeipa-client package has no dependency on >>>>>>>>>> SELinux. >>>>>>>>>> (any objections to this approach?) >>>>>>>>>> >>>>>>>>>> The (unsupported) option --allow-no-selinux has been added. >>>>>>>>>> It can >>>>>>>>>> used to bypass the checks. >>>>>>>>>> >>>>>>>>>> Parts of platform-dependant code were refactored to use newly >>>>>>>>>> added >>>>>>>>>> is_selinux_enabled() function. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>>>>>> >>>>>>>>>> Tomas >>>>>>>>> >>>>>>>>> I forgot to edit the man pages. Thanks Rob! >>>>>>>>> >>>>>>>>> Updated patch attached. >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> >>>>>>>> After a bit of off-line discussion I don't think we're quite ready >>>>>>>> yet >>>>>>>> to require SELinux by default on client installations (even with a >>>>>>>> flag to work around it). The feeling is this would be >>>>>>>> disruptive to >>>>>>>> existing automation. >>>>>>>> >>>>>>>> Can you still do the check but not enforce it, simply display a >>>>>>>> big >>>>>>>> warning if SELinux is disabled? >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> Sure, here is the updated patch. >>>>>>> >>>>>>> I edited the commit message, RFE description and man pages >>>>>>> according to >>>>>>> the new behaviour. >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> The patch looks good, I'm just wondering about one thing. The >>>>>> default >>>>>> value for is_selinux_enabled() is True in ipapython/services.py.in. >>>>>> >>>>>> So this means that any non-Red Hat/non-Fedora system, by default, is >>>>>> going to assume that SELinux is enabled. >>>>>> >>>>>> My hesitation has to when we call check_selinux_status(). It may >>>>>> incorrectly error out. I suspect that the user would have to work >>>>>> around this using --allow-selinux-disabled but this wouldn't make a >>>>>> lot of sense since they actually do have SELinux disabled. >>>>> >>>>> Yes, you're right. And the error message would not even be helpful >>>>> since >>>>> it would tell the user to install policycoreutils package. This >>>>> would be >>>>> the >>>>> case both with server and client installs when selinux would not be >>>>> installed >>>>> at all. >>>>> >>>>>> What do you think? >>>>>> >>>>>> rob >>>>> >>>>> Well we have 2 options as I see it: >>>>> >>>>> 1.) We can either return None as default, and add checks to >>>>> check_selinux_status, restore_context and install scripts that would >>>>> ensure that we behave properly when is_selinux_enabled() is not >>>>> implemented. >>>>> >>>>> 2.) We can remove the default value, since it would cause >>>>> forementioned >>>>> crash and add comment that this function needs to be implemented >>>>> properly in every platform file. >>>>> >>>>> I'm probably for option 2, there's no need to clutter the code with >>>>> checks >>>>> that compensate for improper platform file implementations. >>>>> >>>>> Tomas >>>> >>>> I agree with you on option 2. >>>> >>>> rob >>> >>> I updated the patch accordingly. >>> >>> Tomas >> >> Sorry, wrong patch. Correct version attached. >> >> Tomas > > I'm sorry to throw this back again after so long (and having agreed > with the approach). > > So I was thinking about how another distro maintainer would have to > deal with this. By default with this patch check_selinux_status() > returns None which is evaluated as False, so the warning will get > thrown. If they set it to be True to avoid the warning then other > things may blow up because SELinux really isn't enabled, so we really > haven't gotten anywhere. > > I think the problem is we're trying to cram too much into one > function. I wonder if a is_selinux_available() command would help > which would short-circuit all of this. > > While trying to figure out how this worked I found > httpinstance.configure_selinux_for_httpd() which makes a similar call > to see if SELinux is available, so maybe we should convert that as well. > > rob I added the is_selinux_available function. Both is_selinux_enabled and is_selinux_available default to False in services.py.in. Maintainer that would want to implement platform file, would have to implement both functions for server install. We require SELinux for server anyway. For client installs, default versions work fine. I converted httpinstance.configure_selinux_for_httpd() to use is_selinux_enabled(). I also found a similar call in adtrustinstance.py Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0027-6-Add-checks-for-SELinux-in-install-scripts.patch Type: text/x-patch Size: 16655 bytes Desc: not available URL: From pspacek at redhat.com Fri Apr 5 12:22:17 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Apr 2013 14:22:17 +0200 Subject: [Freeipa-devel] A new proopsal for Location Based Discovery In-Reply-To: <1358903615.20683.352.camel@willson.li.ssimo.org> References: <1358816342.20683.227.camel@willson.li.ssimo.org> <50FEA0D7.60507@redhat.com> <1358866866.20683.264.camel@willson.li.ssimo.org> <50FECCA9.50705@redhat.com> <1358903615.20683.352.camel@willson.li.ssimo.org> Message-ID: <515EC1F9.7080201@redhat.com> On 23.1.2013 02:13, Simo Sorce wrote: > On Tue, 2013-01-22 at 18:30 +0100, Petr Spacek wrote: >> On 22.1.2013 16:01, Simo Sorce wrote: >> >> Replying to myself for the beginning: >> >> > On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote: >> >>> Server Implementation >> >>> TODO: interaction with DNSSEC >> >> That it *very* important part. I have fear from so many dynamic things inside. >> There is less dynamic things than I thought :-) The only dynamic thing is >> _location.client.domain DNAME record. Proposal of "filters" was omitted in >> this version. >> >> My biggest concern is related to dynamical parts, I like the idea itself. >> >> > Yes this is indeed going to add complexity. No doubt. >> >>>> Creating per-server _locations sub-tree is very easy with current code: Simply >>>> copy&paste new bind-dyndb-ldap section to /etc/named.conf and point base DN to >>>> some server-specific part of LDAP tree: >>>> >>>> dynamic-db "ipa-local" { >>>> // >>>> arg "base cn=srv2.example.com, cn=dns-local, dc=example,dc=com"; >>>> } >>> >>> Unless you have a way to mange it via LDAP this is unworkable. Locations >>> should be managed via the Web UI. So you need to be able to create new >>> locations on the fly and change server's locations dynamically, possibly >>> w/o requiring a server restart, but certainly w/o requiring the DNS >>> admin to have direct SSH access to all boxes to go and manually change >>> named.conf >> Sure, admin will never touch lines above. All data *are* directly in LDAP, so >> any tool can read & change _locations configuration on the fly. > > Ok I can see that now. > >>>> Server specific _locations records live in this sub-tree and each server has >>>> have own view of _locations, i.e. each server could specify mapping between >>>> locations in own way. DNS clients will see merged DNS tree, no change on >>>> client side is required. >>> >>> But this would require to manually change multiple records for multiple >>> servers in the same location, which could go wrong quite easily. >> I agree. This is a problem. It would require a tool to handle all location >> stuff. It definitely needs some clever way for management. > > Yes we are shifting complexity from one place to another. > >>> Each location configuration should be in a single place so that it is >>> consistent for all servers of that location and not a burden for >>> administration. >> I agree, it could be seen as a problem. With LDAP referrals and right tool it >> could be reasonable. > > I am not sure I like the idea of using LDAP referrals for this, I need > to think ab out that, I can see how it can be used to reduce some > duplication. > >>> Also your methods puts location information out of the actual DNS, so >>> you can't lookup location data via DNS except for the 'default'. >> That is not correct. Any client could ask any server for >> something._locations.domain and the reply will contain server's mapping for >> particular location. > > See this is the problem. Because your DNAME is fixed, in order to do > overrides, you have to have a 'server's view of a location. > Ie instead of directing the client to the right place, you 'fake' > information about the place the client thinks it is fetching info for. > > This maintains still a great deal of 'duplication' except the data is > not identical, each server have different data labeled with a name > recurring on other servers in order to cheat clients. This can easily > get out of control. > > Even if the data is not 'duplicated' in the db and it is just all smoke > and mirrors and internal redirects it still a complex maze of redirects > you have to store. It also prevents to have final absolute rules for > some clients. > >>> But that would not be correct, we want to allow a client to lookup >>> location data for a non-default location, because an IPA DNS server may >>> very well be serving multiple locations. >> Sure, that doesn't change. > > Ah but it does, in order to force clients to stick to a location in some > case you are faking data for all location so all locations point to the > same data. > > In my model _location.client.domain returns you arbitrary (dynamic) data > but foo._location.domain is always consistent across all servers. > > In your model _location.client.domain returns 'stable' data but > foo._location.domain may instead return fake data. > > For some reason I prefer the former rather than the latter, although I > recognize it may just be a matter of taste, but is sounds right to me > that the _locations.domain tree is the stable one rather than the > _location.client.domain one. > > >>>> E.g. client has preferred location "brno" but the client is connected to >>>> network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC server has >>>> own "_locations" sub-tree with trivial mapping "brno DNAME nyc". >>>> >>>> How to read the result: Location "Brno" is too far from "NYC", use "NYC" >>>> anyway! Also, "default" location could prefer local server over remote ones, >>>> i.e. local clients without any configuration will prefer local servers. >>> >>> I am not sure how this is different from my proposal, the problem I see >>> is that you loose the ability to force a configuration for select client >>> by actually creating real DNAME records. >> DNAME record stored in the database is only "preferred" location, it could be >> overridden on server side (by different content of _locations.domain sub-tree). > > Yeah but see above about that. > >>>> There is another nice feature: "old" _ntp._udp.domain SRV records could >>>> contain aliases pointing to SRV records in some location, e.g. "default". In >>>> that case also old clients will prefer local servers over remote ones - almost >>>> with no price and with no client reconfiguration. >>>> >>>> No new concepts, no new code :-) >>> >>> We can do that with a DNAME in theory, but I would rather keep current >>> domain records as is for now. >>> >>>> There is still _location DNAME record under client's name, that stay >>>> unchanged. Personally, I don't like any on-the-fly record generation. Is it >>>> really necessary? >>> >>> Who creates this record for new clients ? >> It was mentioned below - 'ipa host-add' + fall-back to 'domain' for new clients. > > This means it doesn't work for clients that join now. They use DNS > update to create records and have no rights to create DNAME. So admins > regularly need to go and add DNAME records or we need to add some code > in DS to automatically create them. So again we've just move around > where the complexity is. It is untrue that we have no new code, the new > code is just elsewhere. > >>> How to you handle 3 locations on a single DNS server ? >>> >>> Say I have a headquarters DNS setup where I want to send clients to the >>> engineering, sales or accounting locations depending on the client but I >>> have a shared local network configuration so all clients use the same >>> DNS server. >> Each client machine has record like "_location DNAME eng._locations.domain.". > > Ok another point here. > If I need to rename a location in my model I just do it. > If I rename NYC to newyork, all I need to do is change > NYC._locations.domain to newyork._locations.domain and in IPA I just > change the name of the group or association or whatever object we use to > group clients (Cos Attribute for example propagates automatically). > > In your scheme we would have to also change all the records for each > client in that location, making a rename quite burdensome. > >>>> In case described above I don't think so. Roaming between locations don't >>>> require changing any record, so configuration is static. >>> >>> Yep 'static' is the issue here, we want it more dynamic, the point of >>> generating is that we can change the way we manage locations in future >>> w/o having to jump through more hops. >> I'm not sure if I understood what "hop" mean. In reality all the CNAME/DNAME >> alias de-referencing is done in single shot if all data are available locally >> (which is our case). > > I was just saying that if data is staic you need to change actual data > if you want to change behavior, if it is synthetic you just need to > change the code that synthesize it. Changing actual stored data is > costly because involves generating replication traffic. > >>>> Old clients would see "default" location and _location record for new clients >>>> could be created during ipa host-add or something similar. >>> >>> We can't give out the privilege to create arbitrary DNAME records to >>> lower level admins, so we would have to add special code. >> IMHO allowing only defined locations (i.e. checking object existence) should >> be fairly simple. > > you are assuming that allowing someone to create redirects to arbitrary > locations is harmless. But is it ? > > What if a junior admin, maliciously or not uses this privilege to > redirect clients trafic to a location it shouldn't go to by DNS updating > the DNAME to point to the wrong location ? > I am not comfortable with that and my solution does not suffer from this > problem. > In order to use stored DNAMEs we would need code on the server to > automatically create them and store them in LDAP,a nd do that according > to the location defined for the client. Or in other world the same > logical process you would need to know how to synthesize the record, > only in a different part of the code. (this is just the logic, of > course, a phantom record involves more than that, so not saying it is > the same) > >>>>> DNS Slave server problem >>>> Without dynamic record generation it would be possible to do zone transfers >>>> without any change to current code. Only one new zone (i.e. _locations part of >>>> DNS sub-tree) has to be set on each slaves and we are done. >>> >>> This is true, and we can opt for this fallback initially, but I do not >>> want to restrict manageability just to make the job easier for one of >>> the cases. >> This problem is closely related to record generation. We need to know at which >> point record has to be generated etc. What we do when somebody asks for: >> _location._location._location... > > ignore > >> _location.blah._location.blah._location... > > ignore > >> _location._ntp._udp.example.com. > > ignore > >> _location._ntp._udp._location._ntp._udp.example.com. > > ignore > >> and other variants. > > Only 1 _location is acceptable, and only 'on top' of an existing A > record, and only if an actual record with the same name doesn't actually > exist. > >> How it will play with wildcards? >> E.g. what we do when somebody asked for _location.client.sub.example.com. >> but >> wildcard *.client.sub.example.com. exists? What about wildcard >> *.sub.example.com.? Etc. > > I think I would create the _location record. We just need to decide what > is the most appropriate behavior for this case though. > > What happen if you have a record foo.example.com and also > *.example.com ? > >> What if labels *preceding* '_location' do not exist? I.e. somebody asked for >> _location.nonexistent-blah.existing-domain. >> (Note: Zone can legally contain names like 'blah.blah' without 'blah' alone.) > > We return an error. > As said above the 'base' must be an A (or AAAA) record. > >> How would it be possible to direct legacy clients (looking for SRV records >> directly in 'domain') to local/optimized location? > > Not sure what is the problem here. > >> Trivial solution came over my mind: >> _ntp._udp.domain. CNAME _ntp._udp._location.dummy_client.domain. >> ... but it results in internal reference to generated record ... that is >> scary! (Note: CNAME/DNAMEs within zone are resolved internally in name server, >> there is no request-response ping-pong between client and server.) > > I wasn't going to change the legacy SRV records, but it might be an idea > as well to redirect them to the 'local' default. I am not sure it is a > good idea. However you wouldn't redirect to the client own location I > don't think. > I think you would redirect to the server default location at most. > And the locations are actual existing records. > >> Again, I like the idea itself, but I see a lot of problems. (Still not digging >> into DNSSEC.) > > Another compromise option I was thinking is to keep the complexity in > LDAP by making up fake DNAME records in LDAP, like we do with the compat > plugin, but then I think we would break persistent searches, so I do not > like that one too much. Pavel Brezina discovered that the design doesn't specify how client should behave if expected _location.client.example.com. record doesn't exist. I propose to let this aspect on implementer's discretion (or configurable). Personally, I would fall back to another pre-configured name, e.g. in case of SSSD to configured 'IPA domain' ... -- Petr Spacek From pbrezina at redhat.com Fri Apr 5 12:29:39 2013 From: pbrezina at redhat.com (=?UTF-8?B?UGF2ZWwgQsWZZXppbmE=?=) Date: Fri, 05 Apr 2013 14:29:39 +0200 Subject: [Freeipa-devel] A new proopsal for Location Based Discovery In-Reply-To: <515EC1F9.7080201@redhat.com> References: <1358816342.20683.227.camel@willson.li.ssimo.org> <50FEA0D7.60507@redhat.com> <1358866866.20683.264.camel@willson.li.ssimo.org> <50FECCA9.50705@redhat.com> <1358903615.20683.352.camel@willson.li.ssimo.org> <515EC1F9.7080201@redhat.com> Message-ID: <515EC3B3.6030905@redhat.com> On 04/05/2013 02:22 PM, Petr Spacek wrote: > On 23.1.2013 02:13, Simo Sorce wrote: >> On Tue, 2013-01-22 at 18:30 +0100, Petr Spacek wrote: >>> On 22.1.2013 16:01, Simo Sorce wrote: >>> >>> Replying to myself for the beginning: >>> >>> > On Tue, 2013-01-22 at 15:23 +0100, Petr Spacek wrote: >>> >>> Server Implementation >>> >>> TODO: interaction with DNSSEC >>> >> That it *very* important part. I have fear from so many dynamic >>> things inside. >>> There is less dynamic things than I thought :-) The only dynamic >>> thing is >>> _location.client.domain DNAME record. Proposal of "filters" was >>> omitted in >>> this version. >>> >>> My biggest concern is related to dynamical parts, I like the idea >>> itself. >>> >>> > Yes this is indeed going to add complexity. No doubt. >>> >>>>> Creating per-server _locations sub-tree is very easy with current >>>>> code: Simply >>>>> copy&paste new bind-dyndb-ldap section to /etc/named.conf and point >>>>> base DN to >>>>> some server-specific part of LDAP tree: >>>>> >>>>> dynamic-db "ipa-local" { >>>>> // >>>>> arg "base cn=srv2.example.com, cn=dns-local, >>>>> dc=example,dc=com"; >>>>> } >>>> >>>> Unless you have a way to mange it via LDAP this is unworkable. >>>> Locations >>>> should be managed via the Web UI. So you need to be able to create new >>>> locations on the fly and change server's locations dynamically, >>>> possibly >>>> w/o requiring a server restart, but certainly w/o requiring the DNS >>>> admin to have direct SSH access to all boxes to go and manually change >>>> named.conf >>> Sure, admin will never touch lines above. All data *are* directly in >>> LDAP, so >>> any tool can read & change _locations configuration on the fly. >> >> Ok I can see that now. >> >>>>> Server specific _locations records live in this sub-tree and each >>>>> server has >>>>> have own view of _locations, i.e. each server could specify mapping >>>>> between >>>>> locations in own way. DNS clients will see merged DNS tree, no >>>>> change on >>>>> client side is required. >>>> >>>> But this would require to manually change multiple records for multiple >>>> servers in the same location, which could go wrong quite easily. >>> I agree. This is a problem. It would require a tool to handle all >>> location >>> stuff. It definitely needs some clever way for management. >> >> Yes we are shifting complexity from one place to another. >> >>>> Each location configuration should be in a single place so that it is >>>> consistent for all servers of that location and not a burden for >>>> administration. >>> I agree, it could be seen as a problem. With LDAP referrals and right >>> tool it >>> could be reasonable. >> >> I am not sure I like the idea of using LDAP referrals for this, I need >> to think ab out that, I can see how it can be used to reduce some >> duplication. >> >>>> Also your methods puts location information out of the actual DNS, so >>>> you can't lookup location data via DNS except for the 'default'. >>> That is not correct. Any client could ask any server for >>> something._locations.domain and the reply will contain server's >>> mapping for >>> particular location. >> >> See this is the problem. Because your DNAME is fixed, in order to do >> overrides, you have to have a 'server's view of a location. >> Ie instead of directing the client to the right place, you 'fake' >> information about the place the client thinks it is fetching info for. >> >> This maintains still a great deal of 'duplication' except the data is >> not identical, each server have different data labeled with a name >> recurring on other servers in order to cheat clients. This can easily >> get out of control. >> >> Even if the data is not 'duplicated' in the db and it is just all smoke >> and mirrors and internal redirects it still a complex maze of redirects >> you have to store. It also prevents to have final absolute rules for >> some clients. >> >>>> But that would not be correct, we want to allow a client to lookup >>>> location data for a non-default location, because an IPA DNS server may >>>> very well be serving multiple locations. >>> Sure, that doesn't change. >> >> Ah but it does, in order to force clients to stick to a location in some >> case you are faking data for all location so all locations point to the >> same data. >> >> In my model _location.client.domain returns you arbitrary (dynamic) data >> but foo._location.domain is always consistent across all servers. >> >> In your model _location.client.domain returns 'stable' data but >> foo._location.domain may instead return fake data. >> >> For some reason I prefer the former rather than the latter, although I >> recognize it may just be a matter of taste, but is sounds right to me >> that the _locations.domain tree is the stable one rather than the >> _location.client.domain one. >> >> >>>>> E.g. client has preferred location "brno" but the client is >>>>> connected to >>>>> network in "nyc", i.e. DNS queries are sent to servers in NYC. NYC >>>>> server has >>>>> own "_locations" sub-tree with trivial mapping "brno DNAME nyc". >>>>> >>>>> How to read the result: Location "Brno" is too far from "NYC", use >>>>> "NYC" >>>>> anyway! Also, "default" location could prefer local server over >>>>> remote ones, >>>>> i.e. local clients without any configuration will prefer local >>>>> servers. >>>> >>>> I am not sure how this is different from my proposal, the problem I see >>>> is that you loose the ability to force a configuration for select >>>> client >>>> by actually creating real DNAME records. >>> DNAME record stored in the database is only "preferred" location, it >>> could be >>> overridden on server side (by different content of _locations.domain >>> sub-tree). >> >> Yeah but see above about that. >> >>>>> There is another nice feature: "old" _ntp._udp.domain SRV records >>>>> could >>>>> contain aliases pointing to SRV records in some location, e.g. >>>>> "default". In >>>>> that case also old clients will prefer local servers over remote >>>>> ones - almost >>>>> with no price and with no client reconfiguration. >>>>> >>>>> No new concepts, no new code :-) >>>> >>>> We can do that with a DNAME in theory, but I would rather keep current >>>> domain records as is for now. >>>> >>>>> There is still _location DNAME record under client's name, that stay >>>>> unchanged. Personally, I don't like any on-the-fly record >>>>> generation. Is it >>>>> really necessary? >>>> >>>> Who creates this record for new clients ? >>> It was mentioned below - 'ipa host-add' + fall-back to 'domain' for >>> new clients. >> >> This means it doesn't work for clients that join now. They use DNS >> update to create records and have no rights to create DNAME. So admins >> regularly need to go and add DNAME records or we need to add some code >> in DS to automatically create them. So again we've just move around >> where the complexity is. It is untrue that we have no new code, the new >> code is just elsewhere. >> >>>> How to you handle 3 locations on a single DNS server ? >>>> >>>> Say I have a headquarters DNS setup where I want to send clients to the >>>> engineering, sales or accounting locations depending on the client >>>> but I >>>> have a shared local network configuration so all clients use the same >>>> DNS server. >>> Each client machine has record like "_location DNAME >>> eng._locations.domain.". >> >> Ok another point here. >> If I need to rename a location in my model I just do it. >> If I rename NYC to newyork, all I need to do is change >> NYC._locations.domain to newyork._locations.domain and in IPA I just >> change the name of the group or association or whatever object we use to >> group clients (Cos Attribute for example propagates automatically). >> >> In your scheme we would have to also change all the records for each >> client in that location, making a rename quite burdensome. >> >>>>> In case described above I don't think so. Roaming between locations >>>>> don't >>>>> require changing any record, so configuration is static. >>>> >>>> Yep 'static' is the issue here, we want it more dynamic, the point of >>>> generating is that we can change the way we manage locations in future >>>> w/o having to jump through more hops. >>> I'm not sure if I understood what "hop" mean. In reality all the >>> CNAME/DNAME >>> alias de-referencing is done in single shot if all data are available >>> locally >>> (which is our case). >> >> I was just saying that if data is staic you need to change actual data >> if you want to change behavior, if it is synthetic you just need to >> change the code that synthesize it. Changing actual stored data is >> costly because involves generating replication traffic. >> >>>>> Old clients would see "default" location and _location record for >>>>> new clients >>>>> could be created during ipa host-add or something similar. >>>> >>>> We can't give out the privilege to create arbitrary DNAME records to >>>> lower level admins, so we would have to add special code. >>> IMHO allowing only defined locations (i.e. checking object existence) >>> should >>> be fairly simple. >> >> you are assuming that allowing someone to create redirects to arbitrary >> locations is harmless. But is it ? >> >> What if a junior admin, maliciously or not uses this privilege to >> redirect clients trafic to a location it shouldn't go to by DNS updating >> the DNAME to point to the wrong location ? >> I am not comfortable with that and my solution does not suffer from this >> problem. >> In order to use stored DNAMEs we would need code on the server to >> automatically create them and store them in LDAP,a nd do that according >> to the location defined for the client. Or in other world the same >> logical process you would need to know how to synthesize the record, >> only in a different part of the code. (this is just the logic, of >> course, a phantom record involves more than that, so not saying it is >> the same) >> >>>>>> DNS Slave server problem >>>>> Without dynamic record generation it would be possible to do zone >>>>> transfers >>>>> without any change to current code. Only one new zone (i.e. >>>>> _locations part of >>>>> DNS sub-tree) has to be set on each slaves and we are done. >>>> >>>> This is true, and we can opt for this fallback initially, but I do not >>>> want to restrict manageability just to make the job easier for one of >>>> the cases. >>> This problem is closely related to record generation. We need to know >>> at which >>> point record has to be generated etc. What we do when somebody asks for: >>> _location._location._location... >> >> ignore >> >>> _location.blah._location.blah._location... >> >> ignore >> >>> _location._ntp._udp.example.com. >> >> ignore >> >>> _location._ntp._udp._location._ntp._udp.example.com. >> >> ignore >> >>> and other variants. >> >> Only 1 _location is acceptable, and only 'on top' of an existing A >> record, and only if an actual record with the same name doesn't actually >> exist. >> >>> How it will play with wildcards? >>> E.g. what we do when somebody asked for >>> _location.client.sub.example.com. >>> but >>> wildcard *.client.sub.example.com. exists? What about wildcard >>> *.sub.example.com.? Etc. >> >> I think I would create the _location record. We just need to decide what >> is the most appropriate behavior for this case though. >> >> What happen if you have a record foo.example.com and also >> *.example.com ? >> >>> What if labels *preceding* '_location' do not exist? I.e. somebody >>> asked for >>> _location.nonexistent-blah.existing-domain. >>> (Note: Zone can legally contain names like 'blah.blah' without 'blah' >>> alone.) >> >> We return an error. >> As said above the 'base' must be an A (or AAAA) record. >> >>> How would it be possible to direct legacy clients (looking for SRV >>> records >>> directly in 'domain') to local/optimized location? >> >> Not sure what is the problem here. >> >>> Trivial solution came over my mind: >>> _ntp._udp.domain. CNAME _ntp._udp._location.dummy_client.domain. >>> ... but it results in internal reference to generated record ... that is >>> scary! (Note: CNAME/DNAMEs within zone are resolved internally in >>> name server, >>> there is no request-response ping-pong between client and server.) >> >> I wasn't going to change the legacy SRV records, but it might be an idea >> as well to redirect them to the 'local' default. I am not sure it is a >> good idea. However you wouldn't redirect to the client own location I >> don't think. >> I think you would redirect to the server default location at most. >> And the locations are actual existing records. >> >>> Again, I like the idea itself, but I see a lot of problems. (Still >>> not digging >>> into DNSSEC.) >> >> Another compromise option I was thinking is to keep the complexity in >> LDAP by making up fake DNAME records in LDAP, like we do with the compat >> plugin, but then I think we would break persistent searches, so I do not >> like that one too much. > > Pavel Brezina discovered that the design doesn't specify how client > should behave if expected _location.client.example.com. record doesn't > exist. > > I propose to let this aspect on implementer's discretion (or configurable). > > Personally, I would fall back to another pre-configured name, e.g. in > case of SSSD to configured 'IPA domain' ... Before I seen the design page, I wanted to implement it in SSSD this way: If '_location.host.domain' gives any result than take it as primary servers and SRV from 'domain' as backup servers. Otherwise use 'domain' result as primary servers. But I'm not so sure now. From simo at redhat.com Fri Apr 5 12:38:48 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Apr 2013 08:38:48 -0400 Subject: [Freeipa-devel] A new proopsal for Location Based Discovery In-Reply-To: <515EC3B3.6030905@redhat.com> References: <1358816342.20683.227.camel@willson.li.ssimo.org> <50FEA0D7.60507@redhat.com> <1358866866.20683.264.camel@willson.li.ssimo.org> <50FECCA9.50705@redhat.com> <1358903615.20683.352.camel@willson.li.ssimo.org> <515EC1F9.7080201@redhat.com> <515EC3B3.6030905@redhat.com> Message-ID: <1365165528.2660.1348.camel@willson.li.ssimo.org> On Fri, 2013-04-05 at 14:29 +0200, Pavel B?ezina wrote: > > > > Pavel Brezina discovered that the design doesn't specify how client > > should behave if expected _location.client.example.com. record > doesn't > > exist. > > > > I propose to let this aspect on implementer's discretion (or > configurable). > > > > Personally, I would fall back to another pre-configured name, e.g. > in > > case of SSSD to configured 'IPA domain' ... > > Before I seen the design page, I wanted to implement it in SSSD this > way: > > If '_location.host.domain' gives any result than take it as primary > servers and SRV from 'domain' as backup servers. Otherwise use > 'domain' > result as primary servers. > > But I'm not so sure now. > This is what I would expect too. If no 'custom' record are available fallback to global records, then fall back to classic SRV records, then fall back to local configuration. Simo. > -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Apr 5 12:54:58 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Apr 2013 14:54:58 +0200 Subject: [Freeipa-devel] A new proopsal for Location Based Discovery In-Reply-To: <1365165528.2660.1348.camel@willson.li.ssimo.org> References: <1358816342.20683.227.camel@willson.li.ssimo.org> <50FEA0D7.60507@redhat.com> <1358866866.20683.264.camel@willson.li.ssimo.org> <50FECCA9.50705@redhat.com> <1358903615.20683.352.camel@willson.li.ssimo.org> <515EC1F9.7080201@redhat.com> <515EC3B3.6030905@redhat.com> <1365165528.2660.1348.camel@willson.li.ssimo.org> Message-ID: <515EC9A2.1040800@redhat.com> On 5.4.2013 14:38, Simo Sorce wrote: > On Fri, 2013-04-05 at 14:29 +0200, Pavel B?ezina wrote: >>> >>> Pavel Brezina discovered that the design doesn't specify how client >>> should behave if expected _location.client.example.com. record >> doesn't >>> exist. >>> >>> I propose to let this aspect on implementer's discretion (or >> configurable). >>> >>> Personally, I would fall back to another pre-configured name, e.g. >> in >>> case of SSSD to configured 'IPA domain' ... >> >> Before I seen the design page, I wanted to implement it in SSSD this >> way: >> >> If '_location.host.domain' gives any result than take it as primary >> servers and SRV from 'domain' as backup servers. Otherwise use >> 'domain' >> result as primary servers. >> >> But I'm not so sure now. >> > This is what I would expect too. > If no 'custom' record are available fallback to global records, What is the difference between 'global records' and 'classic SRV records'? Petr^2 Spacek > then > fall back to classic SRV records, then fall back to local configuration. From akrivoka at redhat.com Fri Apr 5 12:50:18 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 05 Apr 2013 14:50:18 +0200 Subject: [Freeipa-devel] PATCH] 275 Fix regression in group type selection in group adder dialog In-Reply-To: <515EB55D.30101@redhat.com> References: <515EB55D.30101@redhat.com> Message-ID: <515EC88A.1080609@redhat.com> On 04/05/2013 01:28 PM, Petr Vobornik wrote: > Refactoring of radio widget (04325fbb4c64ee4aef6d8c9adf0ff95b8b653101) > caused that value is no longer supplied to value_change handler. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Fri Apr 5 13:57:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 05 Apr 2013 15:57:17 +0200 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <515D7A5F.3050703@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> Message-ID: <515ED83D.50107@redhat.com> On 04/04/2013 03:04 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>> There are strict limits on what can be restored where. Only exact >>>> matching hostnames and versions are allowed right now. We can probably >>>> relax the hostname requirement if we're only restoring data, and the >>>> version perhaps for only the the first two values (so you can restore a >>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>> >>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>> Or is what they put in /var/lib guaranteed portable across versions? >> >> An interesting question. I'd imagine that a major db change would also >> require a major update to IPA, therefore if we restrict by IPA version >> we should be ok. I AM doing an untar of files though so yeah, there is a >> risk here. >> >>> >>> >>> That's good to hear! >>> >>> I think while developing, you should run with -v to get all the output. >>> And for production, please have the commands log by default (set >>> log_file_name). >> >> Yes, I plan on adding that in the future. >> >>> >>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>> password because we need to contact remote servers to enable/disable >>>> replication. >>> >>> The restore assumes that ipa is already installed, right? I can't just >>> run it on a clean machine? Id would be good to check/document this. >> >> It depends. >> >> For a full backup you can actually restore to an uninstalled server. In >> fact, you could restore to a machine w/no IPA bits on it at all in all >> likelihood (which wouldn't be very nice, but not exactly wrong either >> IMHO). >> >> I tested this with: >> - ipa-server-install >> - ipa-backup >> - ipa-server-install --uninstall -U >> - ipa-restore >> - ran the unit tests >> >>> I looked in the backup tarball and saw dirsrv PID file and lock >>> directories. Are these needed? >> >> Probably not. I gathered some of the files to backup based on watching >> what files that changed during an install that are independent of us. >> I'll take another pass through it, there may be other oddities too. >> >>> The tool runners (install/tools/ipa-backup and >>> install/tools/ipa-restore) are missing, so IPA doesn't build. Probably >>> just a forgotten git add. >> >> Yup. >> >>> >>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>> consider adding $(NULL) at the end. >> >> I'll take a look. >> >>> >>> Backup.dirs, Backup.files, Backup.logs: >>> The code modifies these class-level attributes. This means you can't run >>> the command more than once in one Python session, so it can't be used as >>> a library (e.g. in a hypothetical test suite). >>> Please make the class atrributes immutable (tuples), then in __init__ do >>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >> >> Ok, fair point. >> >>> Code that creates temporary files/directories or does chdir() should be >>> next to (or in) a try block whose finally: restores things. >> >> Yes, I mean to add a big try/finally block around everything in run >> eventually (or the equivalent anyway). >> >>> >>> Instead of star imports (from ipapython.ipa_log_manager import *), >>> please explicitly import whatever you're using from that package. In >>> this case, nothing at all! >> >> Yeah, I haven't run this through pylint yet to see all the bad imports I >> cobbled together. >> >>> If there's a get_connection() method, it should return the connection, >>> and it should always be used to get it. Store the connection in >>> self._conn, and rather than: >>> self.get_connection() >>> self.conn.do_work() >>> do: >>> conn = self.get_connection() >>> conn.do_work() >>> This makes forgetting to call get_connection() impossible. >> >> My purpose was to avoid creating multiple connections. >> >>> If a variable is only used in a single method, like `filename` in >>> Restore.extract_backup, don't store it in the admintool object. >>> In general, try to avoid putting data in self if possible. It's >>> convenient but it allows complex interdependencies. >>> (Yes, I'm guilty of not following this myself.) >> >> Yes, there is certainly a bit of cleanup to do. I was in a bit of a rush >> to get this WIP out. >> >>> In several places, the backup tool logs critical errors and then just >>> continues on. Is that by design? I think a nonzero exit code would be >>> appropriate. >> >> I'll take a look at them, all I can say at this point is maybe. >> >>> In the ipa-restore man page, --backend is not documented. >>> >>> In db2ldif, db2bak, etc., a more conscise way to get the time string is >>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>> >>> When validating --gpg-keyring, it would be good to check both files >>> (.sec and .pub). >> >> Ok, I can do those. >> >>> >>> Here: >>> if (self.backup_type != 'FULL' and not options.data_only and >>> not instances): >>> raise admintool.ScriptError('Cannot restore a data backup into >>> an empty system') >>> did you mean `(self.backup_type != 'FULL' or options.data_only) and not >>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >> >> Yeah, looks like that should be an or. >> >>> In the ReplicationManager.check_repl_init reporting: use >>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>> include full days. I don't think anyone would wait long enough for the >>> overflow, but better to be correct. >> >> Sure, I doubt anyone would wait 24 hours either but its a no-brainer to >> make it safe. > > I think I've addressed just about everything. > > The reason that /var/run/dirsrv and var/lock/dirsrv are included in the > backup is for the case of a full restore. These directories are not > created/provided by the package itself, but by installing the first > instance, so we need the ownership/SELinux context preserved. > > One thing I need tested is restoring over top of new data with multiple > replicas. So basically install, do a backup, add a bunch of data, > restore, re-initialize all the other masters and then confirm that ALL > the new data is gone. I think I've got the sequence right but this is > critical. > > This should work on fresh installs and upgrades from 3.0 (e.g. dogtag > 9/multi-instance DS configurations). > > One thing I tested was: > > - ipa-server-install > - ipa-backup > - ipa-server-install --uninstall -U > - ipa-restore ipa-full-... > > This will actually get your server back EXCEPT that dogtag won't start. > This is because the log directories are created by the instance > creation. There are two solutions: backup with --logs or manually > re-create the log directories (there are several, depending on dogtag > version). Could backup without --logs save which directories are there, and restore create empty directories if they don't exist? To me re-initializing a completely wiped machine looks like a big gain for the extra effort. The spec changelog needs a small rebase. I've tested some scenarios and didn't find any other issues so far. I still want to test some more with upgraded masters; installing them takes some time. Also I still need to test CA replicas (with the DNAME patches removed). -- Petr? From rcritten at redhat.com Fri Apr 5 14:13:41 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Apr 2013 10:13:41 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <515ED83D.50107@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> Message-ID: <515EDC15.2040008@redhat.com> Petr Viktorin wrote: > On 04/04/2013 03:04 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>> There are strict limits on what can be restored where. Only exact >>>>> matching hostnames and versions are allowed right now. We can probably >>>>> relax the hostname requirement if we're only restoring data, and the >>>>> version perhaps for only the the first two values (so you can >>>>> restore a >>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>> >>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>> Or is what they put in /var/lib guaranteed portable across versions? >>> >>> An interesting question. I'd imagine that a major db change would also >>> require a major update to IPA, therefore if we restrict by IPA version >>> we should be ok. I AM doing an untar of files though so yeah, there is a >>> risk here. >>> >>>> >>>> >>>> That's good to hear! >>>> >>>> I think while developing, you should run with -v to get all the output. >>>> And for production, please have the commands log by default (set >>>> log_file_name). >>> >>> Yes, I plan on adding that in the future. >>> >>>> >>>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>>> password because we need to contact remote servers to enable/disable >>>>> replication. >>>> >>>> The restore assumes that ipa is already installed, right? I can't just >>>> run it on a clean machine? Id would be good to check/document this. >>> >>> It depends. >>> >>> For a full backup you can actually restore to an uninstalled server. In >>> fact, you could restore to a machine w/no IPA bits on it at all in all >>> likelihood (which wouldn't be very nice, but not exactly wrong either >>> IMHO). >>> >>> I tested this with: >>> - ipa-server-install >>> - ipa-backup >>> - ipa-server-install --uninstall -U >>> - ipa-restore >>> - ran the unit tests >>> >>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>> directories. Are these needed? >>> >>> Probably not. I gathered some of the files to backup based on watching >>> what files that changed during an install that are independent of us. >>> I'll take another pass through it, there may be other oddities too. >>> >>>> The tool runners (install/tools/ipa-backup and >>>> install/tools/ipa-restore) are missing, so IPA doesn't build. Probably >>>> just a forgotten git add. >>> >>> Yup. >>> >>>> >>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>> consider adding $(NULL) at the end. >>> >>> I'll take a look. >>> >>>> >>>> Backup.dirs, Backup.files, Backup.logs: >>>> The code modifies these class-level attributes. This means you can't >>>> run >>>> the command more than once in one Python session, so it can't be >>>> used as >>>> a library (e.g. in a hypothetical test suite). >>>> Please make the class atrributes immutable (tuples), then in >>>> __init__ do >>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>> >>> Ok, fair point. >>> >>>> Code that creates temporary files/directories or does chdir() should be >>>> next to (or in) a try block whose finally: restores things. >>> >>> Yes, I mean to add a big try/finally block around everything in run >>> eventually (or the equivalent anyway). >>> >>>> >>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>> please explicitly import whatever you're using from that package. In >>>> this case, nothing at all! >>> >>> Yeah, I haven't run this through pylint yet to see all the bad imports I >>> cobbled together. >>> >>>> If there's a get_connection() method, it should return the connection, >>>> and it should always be used to get it. Store the connection in >>>> self._conn, and rather than: >>>> self.get_connection() >>>> self.conn.do_work() >>>> do: >>>> conn = self.get_connection() >>>> conn.do_work() >>>> This makes forgetting to call get_connection() impossible. >>> >>> My purpose was to avoid creating multiple connections. >>> >>>> If a variable is only used in a single method, like `filename` in >>>> Restore.extract_backup, don't store it in the admintool object. >>>> In general, try to avoid putting data in self if possible. It's >>>> convenient but it allows complex interdependencies. >>>> (Yes, I'm guilty of not following this myself.) >>> >>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a rush >>> to get this WIP out. >>> >>>> In several places, the backup tool logs critical errors and then just >>>> continues on. Is that by design? I think a nonzero exit code would be >>>> appropriate. >>> >>> I'll take a look at them, all I can say at this point is maybe. >>> >>>> In the ipa-restore man page, --backend is not documented. >>>> >>>> In db2ldif, db2bak, etc., a more conscise way to get the time string is >>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>> >>>> When validating --gpg-keyring, it would be good to check both files >>>> (.sec and .pub). >>> >>> Ok, I can do those. >>> >>>> >>>> Here: >>>> if (self.backup_type != 'FULL' and not options.data_only and >>>> not instances): >>>> raise admintool.ScriptError('Cannot restore a data backup into >>>> an empty system') >>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and not >>>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >>> >>> Yeah, looks like that should be an or. >>> >>>> In the ReplicationManager.check_repl_init reporting: use >>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>> include full days. I don't think anyone would wait long enough for the >>>> overflow, but better to be correct. >>> >>> Sure, I doubt anyone would wait 24 hours either but its a no-brainer to >>> make it safe. >> >> I think I've addressed just about everything. >> >> The reason that /var/run/dirsrv and var/lock/dirsrv are included in the >> backup is for the case of a full restore. These directories are not >> created/provided by the package itself, but by installing the first >> instance, so we need the ownership/SELinux context preserved. >> >> One thing I need tested is restoring over top of new data with multiple >> replicas. So basically install, do a backup, add a bunch of data, >> restore, re-initialize all the other masters and then confirm that ALL >> the new data is gone. I think I've got the sequence right but this is >> critical. >> >> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >> 9/multi-instance DS configurations). >> >> One thing I tested was: >> >> - ipa-server-install >> - ipa-backup >> - ipa-server-install --uninstall -U >> - ipa-restore ipa-full-... >> >> This will actually get your server back EXCEPT that dogtag won't start. >> This is because the log directories are created by the instance >> creation. There are two solutions: backup with --logs or manually >> re-create the log directories (there are several, depending on dogtag >> version). > > Could backup without --logs save which directories are there, and > restore create empty directories if they don't exist? To me > re-initializing a completely wiped machine looks like a big gain for the > extra effort. Yeah, it is right on the edge of scope for what I was doing. It would definitely be nice for users. I think the trick would be to be able to discover what kind of install we have, which I guess we can assume based on the existence of the PKI-IPA instance. I should also note that on uninstall I don't remove any backups. I'm generally pretty cautious when removing user data. Now that I think about it, should we warn users when backups are left over? The big concern is you install IPA for a test, do a bunch of stuff including a backup, uninstall, install for real, backup, then accidentally restore the wrong one out of confusion. I suppose you could restore the right one later, but this could get wierd. > > The spec changelog needs a small rebase. Yeah, a couple of commits right after mine were done. I'll fix it up for the next candidate patch. > I've tested some scenarios and didn't find any other issues so far. > > I still want to test some more with upgraded masters; installing them > takes some time. > Also I still need to test CA replicas (with the DNAME patches removed). > thanks rob From simo at redhat.com Fri Apr 5 14:32:32 2013 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Apr 2013 10:32:32 -0400 Subject: [Freeipa-devel] A new proopsal for Location Based Discovery In-Reply-To: <515EC9A2.1040800@redhat.com> References: <1358816342.20683.227.camel@willson.li.ssimo.org> <50FEA0D7.60507@redhat.com> <1358866866.20683.264.camel@willson.li.ssimo.org> <50FECCA9.50705@redhat.com> <1358903615.20683.352.camel@willson.li.ssimo.org> <515EC1F9.7080201@redhat.com> <515EC3B3.6030905@redhat.com> <1365165528.2660.1348.camel@willson.li.ssimo.org> <515EC9A2.1040800@redhat.com> Message-ID: <1365172352.2660.1353.camel@willson.li.ssimo.org> On Fri, 2013-04-05 at 14:54 +0200, Petr Spacek wrote: > On 5.4.2013 14:38, Simo Sorce wrote: > > On Fri, 2013-04-05 at 14:29 +0200, Pavel B?ezina wrote: > >>> > >>> Pavel Brezina discovered that the design doesn't specify how client > >>> should behave if expected _location.client.example.com. record > >> doesn't > >>> exist. > >>> > >>> I propose to let this aspect on implementer's discretion (or > >> configurable). > >>> > >>> Personally, I would fall back to another pre-configured name, e.g. > >> in > >>> case of SSSD to configured 'IPA domain' ... > >> > >> Before I seen the design page, I wanted to implement it in SSSD this > >> way: > >> > >> If '_location.host.domain' gives any result than take it as primary > >> servers and SRV from 'domain' as backup servers. Otherwise use > >> 'domain' > >> result as primary servers. > >> > >> But I'm not so sure now. > >> > > This is what I would expect too. > > If no 'custom' record are available fallback to global records, > What is the difference between 'global records' and 'classic SRV records'? _ldap._tcp._location.example.com vs _ldap._tcp.example.com Simo. -- Simo Sorce * Red Hat, Inc * New York From xkubik17 at stud.fit.vutbr.cz Fri Apr 5 14:41:47 2013 From: xkubik17 at stud.fit.vutbr.cz (=?ISO-8859-1?Q?Milan_Kub=EDk?=) Date: Fri, 05 Apr 2013 16:41:47 +0200 Subject: [Freeipa-devel] Authentication portal in FreeIPA Message-ID: <515EE2AB.4050904@stud.fit.vutbr.cz> Hello, I'm a student at the Brno University of Technology and intern at Red Hat, working on my bachelor thesis supervised by Jan Zeleny. My project is to implement a system allowing FreeIPA to become an identity provider for technologies such as OpenID or SAML SSO. In attached document I briefly describe my ideas on the project. I have some code written already but I could use a help (or dismissal of my concept) with FreeIPA as well as discuss the concept I propose. For faster communication you can use my corporate email (reply to this email) or irc (#ipa channel). Regards, Milan Kubik -------------- next part -------------- A non-text attachment was scrubbed... Name: concept.pdf Type: application/pdf Size: 84731 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2654 bytes Desc: S/MIME Cryptographic Signature URL: From dpal at redhat.com Fri Apr 5 15:36:33 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Apr 2013 11:36:33 -0400 Subject: [Freeipa-devel] Authentication portal in FreeIPA In-Reply-To: <515EE2AB.4050904@stud.fit.vutbr.cz> References: <515EE2AB.4050904@stud.fit.vutbr.cz> Message-ID: <515EEF81.7030205@redhat.com> On 04/05/2013 10:41 AM, Milan Kub?k wrote: > Hello, > > I'm a student at the Brno University of Technology and intern at Red > Hat, working on my bachelor thesis supervised by Jan Zeleny. > > My project is to implement a system allowing FreeIPA to become an > identity provider for technologies such as OpenID or SAML SSO. In > attached document I briefly describe my ideas on the project. I have > some code written already but I could use a help (or dismissal of my > concept) with FreeIPA as well as discuss the concept I propose. > > For faster communication you can use my corporate email (reply to this > email) or irc (#ipa channel). > > Regards, > > Milan Kubik Milan, This is a good start but we need to get on the same page a bit. What really would help is the component diagram and a sequence diagram. See attached. Please use it as an inspiration and modify to reflect the reality as my understanding of the details might be too shallow. HTH Dmitri > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenID provider.odp Type: application/vnd.oasis.opendocument.presentation Size: 15398 bytes Desc: not available URL: From dpal at redhat.com Fri Apr 5 15:37:32 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Apr 2013 11:37:32 -0400 Subject: [Freeipa-devel] Authentication portal in FreeIPA In-Reply-To: <515EEF81.7030205@redhat.com> References: <515EE2AB.4050904@stud.fit.vutbr.cz> <515EEF81.7030205@redhat.com> Message-ID: <515EEFBC.50202@redhat.com> On 04/05/2013 11:36 AM, Dmitri Pal wrote: > On 04/05/2013 10:41 AM, Milan Kub?k wrote: >> Hello, >> >> I'm a student at the Brno University of Technology and intern at Red >> Hat, working on my bachelor thesis supervised by Jan Zeleny. >> >> My project is to implement a system allowing FreeIPA to become an >> identity provider for technologies such as OpenID or SAML SSO. In >> attached document I briefly describe my ideas on the project. I have >> some code written already but I could use a help (or dismissal of my >> concept) with FreeIPA as well as discuss the concept I propose. >> >> For faster communication you can use my corporate email (reply to >> this email) or irc (#ipa channel). >> >> Regards, >> >> Milan Kubik > > > Milan, > > This is a good start but we need to get on the same page a bit. > What really would help is the component diagram and a sequence diagram. > See attached. > Please use it as an inspiration and modify to reflect the reality as > my understanding of the details might be too shallow. > Forgot to save the deck before sending. Here is an updated one. > HTH > > Dmitri > >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenID provider.odp Type: application/vnd.oasis.opendocument.presentation Size: 16622 bytes Desc: not available URL: From pspacek at redhat.com Fri Apr 5 15:39:24 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 05 Apr 2013 17:39:24 +0200 Subject: [Freeipa-devel] A new proopsal for Location Based Discovery In-Reply-To: <1365172352.2660.1353.camel@willson.li.ssimo.org> References: <1358816342.20683.227.camel@willson.li.ssimo.org> <50FEA0D7.60507@redhat.com> <1358866866.20683.264.camel@willson.li.ssimo.org> <50FECCA9.50705@redhat.com> <1358903615.20683.352.camel@willson.li.ssimo.org> <515EC1F9.7080201@redhat.com> <515EC3B3.6030905@redhat.com> <1365165528.2660.1348.camel@willson.li.ssimo.org> <515EC9A2.1040800@redhat.com> <1365172352.2660.1353.camel@willson.li.ssimo.org> Message-ID: <515EF02C.9060808@redhat.com> On 5.4.2013 16:32, Simo Sorce wrote: > On Fri, 2013-04-05 at 14:54 +0200, Petr Spacek wrote: >> On 5.4.2013 14:38, Simo Sorce wrote: >>> On Fri, 2013-04-05 at 14:29 +0200, Pavel B?ezina wrote: >>>>> >>>>> Pavel Brezina discovered that the design doesn't specify how client >>>>> should behave if expected _location.client.example.com. record >>>> doesn't >>>>> exist. >>>>> >>>>> I propose to let this aspect on implementer's discretion (or >>>> configurable). >>>>> >>>>> Personally, I would fall back to another pre-configured name, e.g. >>>> in >>>>> case of SSSD to configured 'IPA domain' ... >>>> >>>> Before I seen the design page, I wanted to implement it in SSSD this >>>> way: >>>> >>>> If '_location.host.domain' gives any result than take it as primary >>>> servers and SRV from 'domain' as backup servers. Otherwise use >>>> 'domain' >>>> result as primary servers. >>>> >>>> But I'm not so sure now. >>>> >>> This is what I would expect too. >>> If no 'custom' record are available fallback to global records, >> What is the difference between 'global records' and 'classic SRV records'? > > _ldap._tcp._location.example.com > vs > _ldap._tcp.example.com I don't see any definition of the 'global' name _location.domain.com. in the design document [1]. What is the meaning of this 'global' record? Is it site-specific? If it isn't site-specific, why we need it? If it is site-specific, how it will be configured/generated? You proposed to generate artificial record '_location.example.com' only if parent name ('example.com') contains A/AAAA record, but that is not mandatory for zone origin. We should keep number of queries at minimum, so I would not add any 'global' records and other layers of indirection without very very good reason. You know, each query adds latency and network load. Some caching for non-existing records is more than good idea. We should not try to lookup _locations.client.domain and _location.domain during each domain lookup (in case where it is not configured, of course :-). [1] http://www.freeipa.org/page/V3/DNS_Location_Mechanism -- Petr Spacek From rcritten at redhat.com Fri Apr 5 17:43:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Apr 2013 13:43:56 -0400 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <515EB975.5060503@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> <5159E78A.9090902@redhat.com> <515A9132.6030404@redhat.com> <515C105B.6030304@redhat.com> <515D8D68.1060901@redhat.com> <515EB975.5060503@redhat.com> Message-ID: <515F0D5C.5040009@redhat.com> Tomas Babej wrote: > On 04/04/2013 04:25 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On Tue 02 Apr 2013 10:05:06 AM CEST, Tomas Babej wrote: >>>> On Mon 01 Apr 2013 10:01:14 PM CEST, Rob Crittenden wrote: >>>>> Tomas Babej wrote: >>>>>> On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >>>>>>> Tomas Babej wrote: >>>>>>>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>>>>>>> Tomas Babej wrote: >>>>>>>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> The checks make sure that SELinux is: >>>>>>>>>>> - installed and enabled (on server install) >>>>>>>>>>> - installed and enabled OR not installed (on client install) >>>>>>>>>>> >>>>>>>>>>> Please note that client installs with SELinux not installed are >>>>>>>>>>> allowed since freeipa-client package has no dependency on >>>>>>>>>>> SELinux. >>>>>>>>>>> (any objections to this approach?) >>>>>>>>>>> >>>>>>>>>>> The (unsupported) option --allow-no-selinux has been added. >>>>>>>>>>> It can >>>>>>>>>>> used to bypass the checks. >>>>>>>>>>> >>>>>>>>>>> Parts of platform-dependant code were refactored to use newly >>>>>>>>>>> added >>>>>>>>>>> is_selinux_enabled() function. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>>>>>>> >>>>>>>>>>> Tomas >>>>>>>>>> >>>>>>>>>> I forgot to edit the man pages. Thanks Rob! >>>>>>>>>> >>>>>>>>>> Updated patch attached. >>>>>>>>>> >>>>>>>>>> Tomas >>>>>>>>> >>>>>>>>> After a bit of off-line discussion I don't think we're quite ready >>>>>>>>> yet >>>>>>>>> to require SELinux by default on client installations (even with a >>>>>>>>> flag to work around it). The feeling is this would be >>>>>>>>> disruptive to >>>>>>>>> existing automation. >>>>>>>>> >>>>>>>>> Can you still do the check but not enforce it, simply display a >>>>>>>>> big >>>>>>>>> warning if SELinux is disabled? >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>> >>>>>>>> Sure, here is the updated patch. >>>>>>>> >>>>>>>> I edited the commit message, RFE description and man pages >>>>>>>> according to >>>>>>>> the new behaviour. >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> The patch looks good, I'm just wondering about one thing. The >>>>>>> default >>>>>>> value for is_selinux_enabled() is True in ipapython/services.py.in. >>>>>>> >>>>>>> So this means that any non-Red Hat/non-Fedora system, by default, is >>>>>>> going to assume that SELinux is enabled. >>>>>>> >>>>>>> My hesitation has to when we call check_selinux_status(). It may >>>>>>> incorrectly error out. I suspect that the user would have to work >>>>>>> around this using --allow-selinux-disabled but this wouldn't make a >>>>>>> lot of sense since they actually do have SELinux disabled. >>>>>> >>>>>> Yes, you're right. And the error message would not even be helpful >>>>>> since >>>>>> it would tell the user to install policycoreutils package. This >>>>>> would be >>>>>> the >>>>>> case both with server and client installs when selinux would not be >>>>>> installed >>>>>> at all. >>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> rob >>>>>> >>>>>> Well we have 2 options as I see it: >>>>>> >>>>>> 1.) We can either return None as default, and add checks to >>>>>> check_selinux_status, restore_context and install scripts that would >>>>>> ensure that we behave properly when is_selinux_enabled() is not >>>>>> implemented. >>>>>> >>>>>> 2.) We can remove the default value, since it would cause >>>>>> forementioned >>>>>> crash and add comment that this function needs to be implemented >>>>>> properly in every platform file. >>>>>> >>>>>> I'm probably for option 2, there's no need to clutter the code with >>>>>> checks >>>>>> that compensate for improper platform file implementations. >>>>>> >>>>>> Tomas >>>>> >>>>> I agree with you on option 2. >>>>> >>>>> rob >>>> >>>> I updated the patch accordingly. >>>> >>>> Tomas >>> >>> Sorry, wrong patch. Correct version attached. >>> >>> Tomas >> >> I'm sorry to throw this back again after so long (and having agreed >> with the approach). >> >> So I was thinking about how another distro maintainer would have to >> deal with this. By default with this patch check_selinux_status() >> returns None which is evaluated as False, so the warning will get >> thrown. If they set it to be True to avoid the warning then other >> things may blow up because SELinux really isn't enabled, so we really >> haven't gotten anywhere. >> >> I think the problem is we're trying to cram too much into one >> function. I wonder if a is_selinux_available() command would help >> which would short-circuit all of this. >> >> While trying to figure out how this worked I found >> httpinstance.configure_selinux_for_httpd() which makes a similar call >> to see if SELinux is available, so maybe we should convert that as well. >> >> rob > I added the is_selinux_available function. Both is_selinux_enabled and > is_selinux_available default to False in services.py.in. Maintainer that > would want to implement platform file, would have to implement both > functions for server install. We require SELinux for server anyway. For > client installs, default versions work fine. > > I converted httpinstance.configure_selinux_for_httpd() to use > is_selinux_enabled(). I also found a similar call in adtrustinstance.py Ok, this is getting us closer, and opens a philosophical discussion. As implemented, this forces SELinux to be at least be available on the box, and by default required to be enabled. This is our strong recommendation for all users. There is a flag to allow it be in permissive, which will help people work around any policy issues or if they don't want SELinux. They'd still have to run without it completely disabled though. This does leave other platforms in a bad place though, there is no out for them. How about adding a require_selinux() call to the platform code defaulting to True. If someone wants to override that with False they can. A call to that could be added inside the other is_selinux... calls to not pollute the rest of the code with it, and if it's False we just skip all the SELinux stuff. This still leaves us with a hardcoded requirement for SELinux in Fedora/RHEL and should provide some flexibility for other platforms as they come. What do you think? rob From akrivoka at redhat.com Fri Apr 5 17:59:28 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 05 Apr 2013 19:59:28 +0200 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC Message-ID: <515F1100.5000603@redhat.com> Hello list, I have been thinking about the possible implementation for a solution of ticket https://fedorahosted.org/freeipa/ticket/3528. There are several options: 1. Completely remove the commands and command options related to source hosts in HBAC. This might not be a good idea as it could cause problems for older clients. 2. Hide these commands/options from the web UI, but leave them in CLI. This would keep the API intact, but I don't like the idea of introducing inconsistencies between CLI and web UI. 3. Do not remove anything, but issue deprecation warnings. The user will see a warning when using these commands/options, but everything will still work. 4. Do not remove anything, but raise exceptions. This would effectively prevent the user from using these commands/options, as the exception will break the execution of a command. In any case, any reference to source hosts should be removed from help and documentation. I am leaning towards options 3 or 4. Thoughts, comments and ideas are welcome. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From rcritten at redhat.com Fri Apr 5 20:54:46 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Apr 2013 16:54:46 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <515ED83D.50107@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> Message-ID: <515F3A16.9050500@redhat.com> Petr Viktorin wrote: > On 04/04/2013 03:04 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>> There are strict limits on what can be restored where. Only exact >>>>> matching hostnames and versions are allowed right now. We can probably >>>>> relax the hostname requirement if we're only restoring data, and the >>>>> version perhaps for only the the first two values (so you can >>>>> restore a >>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>> >>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>> Or is what they put in /var/lib guaranteed portable across versions? >>> >>> An interesting question. I'd imagine that a major db change would also >>> require a major update to IPA, therefore if we restrict by IPA version >>> we should be ok. I AM doing an untar of files though so yeah, there is a >>> risk here. >>> >>>> >>>> >>>> That's good to hear! >>>> >>>> I think while developing, you should run with -v to get all the output. >>>> And for production, please have the commands log by default (set >>>> log_file_name). >>> >>> Yes, I plan on adding that in the future. >>> >>>> >>>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>>> password because we need to contact remote servers to enable/disable >>>>> replication. >>>> >>>> The restore assumes that ipa is already installed, right? I can't just >>>> run it on a clean machine? Id would be good to check/document this. >>> >>> It depends. >>> >>> For a full backup you can actually restore to an uninstalled server. In >>> fact, you could restore to a machine w/no IPA bits on it at all in all >>> likelihood (which wouldn't be very nice, but not exactly wrong either >>> IMHO). >>> >>> I tested this with: >>> - ipa-server-install >>> - ipa-backup >>> - ipa-server-install --uninstall -U >>> - ipa-restore >>> - ran the unit tests >>> >>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>> directories. Are these needed? >>> >>> Probably not. I gathered some of the files to backup based on watching >>> what files that changed during an install that are independent of us. >>> I'll take another pass through it, there may be other oddities too. >>> >>>> The tool runners (install/tools/ipa-backup and >>>> install/tools/ipa-restore) are missing, so IPA doesn't build. Probably >>>> just a forgotten git add. >>> >>> Yup. >>> >>>> >>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>> consider adding $(NULL) at the end. >>> >>> I'll take a look. >>> >>>> >>>> Backup.dirs, Backup.files, Backup.logs: >>>> The code modifies these class-level attributes. This means you can't >>>> run >>>> the command more than once in one Python session, so it can't be >>>> used as >>>> a library (e.g. in a hypothetical test suite). >>>> Please make the class atrributes immutable (tuples), then in >>>> __init__ do >>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>> >>> Ok, fair point. >>> >>>> Code that creates temporary files/directories or does chdir() should be >>>> next to (or in) a try block whose finally: restores things. >>> >>> Yes, I mean to add a big try/finally block around everything in run >>> eventually (or the equivalent anyway). >>> >>>> >>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>> please explicitly import whatever you're using from that package. In >>>> this case, nothing at all! >>> >>> Yeah, I haven't run this through pylint yet to see all the bad imports I >>> cobbled together. >>> >>>> If there's a get_connection() method, it should return the connection, >>>> and it should always be used to get it. Store the connection in >>>> self._conn, and rather than: >>>> self.get_connection() >>>> self.conn.do_work() >>>> do: >>>> conn = self.get_connection() >>>> conn.do_work() >>>> This makes forgetting to call get_connection() impossible. >>> >>> My purpose was to avoid creating multiple connections. >>> >>>> If a variable is only used in a single method, like `filename` in >>>> Restore.extract_backup, don't store it in the admintool object. >>>> In general, try to avoid putting data in self if possible. It's >>>> convenient but it allows complex interdependencies. >>>> (Yes, I'm guilty of not following this myself.) >>> >>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a rush >>> to get this WIP out. >>> >>>> In several places, the backup tool logs critical errors and then just >>>> continues on. Is that by design? I think a nonzero exit code would be >>>> appropriate. >>> >>> I'll take a look at them, all I can say at this point is maybe. >>> >>>> In the ipa-restore man page, --backend is not documented. >>>> >>>> In db2ldif, db2bak, etc., a more conscise way to get the time string is >>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>> >>>> When validating --gpg-keyring, it would be good to check both files >>>> (.sec and .pub). >>> >>> Ok, I can do those. >>> >>>> >>>> Here: >>>> if (self.backup_type != 'FULL' and not options.data_only and >>>> not instances): >>>> raise admintool.ScriptError('Cannot restore a data backup into >>>> an empty system') >>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and not >>>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >>> >>> Yeah, looks like that should be an or. >>> >>>> In the ReplicationManager.check_repl_init reporting: use >>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>> include full days. I don't think anyone would wait long enough for the >>>> overflow, but better to be correct. >>> >>> Sure, I doubt anyone would wait 24 hours either but its a no-brainer to >>> make it safe. >> >> I think I've addressed just about everything. >> >> The reason that /var/run/dirsrv and var/lock/dirsrv are included in the >> backup is for the case of a full restore. These directories are not >> created/provided by the package itself, but by installing the first >> instance, so we need the ownership/SELinux context preserved. >> >> One thing I need tested is restoring over top of new data with multiple >> replicas. So basically install, do a backup, add a bunch of data, >> restore, re-initialize all the other masters and then confirm that ALL >> the new data is gone. I think I've got the sequence right but this is >> critical. >> >> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >> 9/multi-instance DS configurations). >> >> One thing I tested was: >> >> - ipa-server-install >> - ipa-backup >> - ipa-server-install --uninstall -U >> - ipa-restore ipa-full-... >> >> This will actually get your server back EXCEPT that dogtag won't start. >> This is because the log directories are created by the instance >> creation. There are two solutions: backup with --logs or manually >> re-create the log directories (there are several, depending on dogtag >> version). > > Could backup without --logs save which directories are there, and > restore create empty directories if they don't exist? To me > re-initializing a completely wiped machine looks like a big gain for the > extra effort. I went ahead and made this change, it wasn't a lot of work. > > > > The spec changelog needs a small rebase. Done. > > I've tested some scenarios and didn't find any other issues so far. > > I still want to test some more with upgraded masters; installing them > takes some time. > Also I still need to test CA replicas (with the DNAME patches removed). > rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1093-3-backup.patch Type: text/x-patch Size: 78616 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 5 20:38:33 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Apr 2013 16:38:33 -0400 Subject: [Freeipa-devel] Order of updates Message-ID: <515F3649.7010409@redhat.com> We've had a few problems with permissions come up over the last couple of months and I finally sat down to identify what the problem is (this can be seen sometimes where some unit tests fail). We do some membership manipulation in the updates and there is a task which should fix up memberOf. The problem is that that the updates get added AFTER the update is executed because of the way the sorting is done. There isn't an easy way to make the task DN deeper (I tried), so we need something a bit more clever. My ideas include: - Changing 55-pbacmemberof.update into a POST update plugin - Modifying the way update files are loaded so we apply them in blocks, say 0-89 are all applied, then 90-* are applied. - Adding a new update subdirectory which is applied after the main updates. I'm favoring #2 right now but suspect it could get confusing. This is ticket https://fedorahosted.org/freeipa/ticket/3377 From rcritten at redhat.com Fri Apr 5 20:30:42 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 05 Apr 2013 16:30:42 -0400 Subject: [Freeipa-devel] [PATCH] 1094 fix 2 broken tests Message-ID: <515F3472.9050108@redhat.com> Two tests are failing due to missing attributes since the krb ticket flags patch was pushed. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1094-tests.patch Type: text/x-patch Size: 1277 bytes Desc: not available URL: From jfenal at gmail.com Sat Apr 6 21:01:04 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 6 Apr 2013 23:01:04 +0200 Subject: [Freeipa-devel] Confused by some messages Message-ID: Hi all, I'm currently updating the translations in French for messages in FreeIPA, but I am confused by some of them: Valid not before from this date (YYYY-mm-dd) Valid not before to this date (YYYY-mm-dd) Issued on from this date (YYYY-mm-dd) Issued on to this date (YYYY-mm-dd) Revoked on from this date (YYYY-mm-dd) ?Revoked on to this date (YYYY-mm-dd) May I request a native English speaker to review those in their context (certificates) and possibly clarify those? ?Regards, J.? -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfenal at gmail.com Sat Apr 6 21:05:57 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 6 Apr 2013 23:05:57 +0200 Subject: [Freeipa-devel] Confused by some messages In-Reply-To: References: Message-ID: Same for: Issued on from Issued on to Revoked on from Revoked on to Valid not after from Valid not after to Valid not before from Valid not before to All in ipalib/plugins/internal.py around line 330 Regards, J. 2013/4/6 J?r?me Fenal > Hi all, > > I'm currently updating the translations in French for messages in FreeIPA, > but I am confused by some of them: > > Valid not before from this date (YYYY-mm-dd) > Valid not before to this date (YYYY-mm-dd) > Issued on from this date (YYYY-mm-dd) > Issued on to this date (YYYY-mm-dd) > Revoked on from this date (YYYY-mm-dd) > ?Revoked on to this date (YYYY-mm-dd) > > May I request a native English speaker to review those in their context > (certificates) and possibly clarify those? > > ?Regards, > > J.? > -- > J?r?me Fenal > -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Mon Apr 8 07:49:49 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 08 Apr 2013 09:49:49 +0200 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <515F1100.5000603@redhat.com> References: <515F1100.5000603@redhat.com> Message-ID: <5162769D.2060202@redhat.com> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: > Hello list, > > I have been thinking about the possible implementation for a solution of > ticket https://fedorahosted.org/freeipa/ticket/3528. There are several > options: > > 1. Completely remove the commands and command options related to source > hosts in HBAC. This might not be a good idea as it could cause problems > for older clients. > > 2. Hide these commands/options from the web UI, but leave them in CLI. > This would keep the API intact, but I don't like the idea of introducing > inconsistencies between CLI and web UI. > > 3. Do not remove anything, but issue deprecation warnings. The user will > see a warning when using these commands/options, but everything will > still work. > > 4. Do not remove anything, but raise exceptions. This would effectively > prevent the user from using these commands/options, as the exception > will break the execution of a command. > > In any case, any reference to source hosts should be removed from help > and documentation. > > I am leaning towards options 3 or 4. > > Thoughts, comments and ideas are welcome. > IMHO the main question is whether we want to deprecate it or remove it. SSSD is deprecating it so I would go that way too. #1 and #4 are basically a removal, #4 a bad one. #2 is removal from Web UI perspective. I would do #3 with some changes. In both Web UI and CLI there should be clear label that the section/options are deprecated. We may introduce a deprecated flag. With this change we don't have to show the warning. But in CLI we might because user didn't had to read help beforehand. -- Petr Vobornik From akrivoka at redhat.com Mon Apr 8 07:53:46 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 08 Apr 2013 09:53:46 +0200 Subject: [Freeipa-devel] [PATCH] 1094 fix 2 broken tests In-Reply-To: <515F3472.9050108@redhat.com> References: <515F3472.9050108@redhat.com> Message-ID: <5162778A.2040109@redhat.com> On 04/05/2013 10:30 PM, Rob Crittenden wrote: > Two tests are failing due to missing attributes since the krb ticket > flags patch was pushed. > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel The patch fixes failing tests, ACK. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Apr 8 08:17:27 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Apr 2013 10:17:27 +0200 Subject: [Freeipa-devel] Confused by some messages In-Reply-To: References: Message-ID: <51627D17.4080001@redhat.com> On 04/06/2013 11:05 PM, J?r?me Fenal wrote: > Same for: > > Issued on from > Issued on to > Revoked on from > Revoked on to > Valid not after from > Valid not after to > Valid not before from > Valid not before to > > All inipalib/plugins/internal.py around line 330 These are UI labels for the options below. > 2013/4/6 J?r?me Fenal > > > Hi all, > > I'm currently updating the translations in French for messages in > FreeIPA, but I am confused by some of them: > > Valid not before from this date (YYYY-mm-dd) > Valid not before to this date (YYYY-mm-dd) > Issued on from this date (YYYY-mm-dd) > Issued on to this date (YYYY-mm-dd) > Revoked on from this date (YYYY-mm-dd) > ?Revoked on to this date (YYYY-mm-dd) > > May I request a native English speaker to review those in their > context (certificates) and possibly clarify those? These are help strings for cert-find options. "Valid not before", "Issued on", etc. are terms for the validity dates of a certificate. So "Valid not after from this date" means that the certificate's ending date ("not after") is on or after the given day. Here is the full help for context: $ ipa cert-find --help Usage: ipa [global-options] cert-find [options] Search for existing certificates. Options: -h, --help show this help message and exit --subject=STR Subject --revocation-reason=INT Reason for revoking the certificate (0-10) --min-serial-number=INT minimum serial number --max-serial-number=INT maximum serial number --exactly match the common name exactly --validnotafter-from=STR Valid not after from this date (YYYY-mm-dd) --validnotafter-to=STR Valid not after to this date (YYYY-mm-dd) --validnotbefore-from=STR Valid not before from this date (YYYY-mm-dd) --validnotbefore-to=STR Valid not before to this date (YYYY-mm-dd) --issuedon-from=STR Issued on from this date (YYYY-mm-dd) --issuedon-to=STR Issued on to this date (YYYY-mm-dd) --revokedon-from=STR Revoked on from this date (YYYY-mm-dd) --revokedon-to=STR Revoked on to this date (YYYY-mm-dd) --sizelimit=INT Maximum number of certs returned --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. -- Petr? From mkosek at redhat.com Mon Apr 8 08:31:51 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Apr 2013 10:31:51 +0200 Subject: [Freeipa-devel] Order of updates In-Reply-To: <515F3649.7010409@redhat.com> References: <515F3649.7010409@redhat.com> Message-ID: <51628077.7050106@redhat.com> On 04/05/2013 10:38 PM, Rob Crittenden wrote: > We've had a few problems with permissions come up over the last couple of > months and I finally sat down to identify what the problem is (this can be seen > sometimes where some unit tests fail). > > We do some membership manipulation in the updates and there is a task which > should fix up memberOf. The problem is that that the updates get added AFTER > the update is executed because of the way the sorting is done. BTW why the MemberOf plugin does not fix the memberOfs? It should be alreaduy configured in the update time, so it should just properly generate memberOf data - or am I wrong? > > There isn't an easy way to make the task DN deeper (I tried), so we need > something a bit more clever. > > My ideas include: > > - Changing 55-pbacmemberof.update into a POST update plugin > - Modifying the way update files are loaded so we apply them in blocks, say > 0-89 are all applied, then 90-* are applied. > - Adding a new update subdirectory which is applied after the main updates. > > I'm favoring #2 right now but suspect it could get confusing. > > This is ticket https://fedorahosted.org/freeipa/ticket/3377 > #2 sounds acceptable, we would just need to clearly communicate what we do (maybe in man pages too). Actually, I now came across the updates README (shame on me, this is the first time I read it), maybe we should re-shuffle our updates file naming a bit according a schema we define in the README. Just curious - does the order of updates even still make sense order-wise since we reorder the updates anyway based on number of RDNs in their DNs? But I agree that we can reserve a range 90-99 for POST updates and process it separately in ipa-ldap-updater so that they are run after all other updates... Martin From jfenal at gmail.com Mon Apr 8 08:44:24 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 8 Apr 2013 10:44:24 +0200 Subject: [Freeipa-devel] Confused by some messages In-Reply-To: <51627D17.4080001@redhat.com> References: <51627D17.4080001@redhat.com> Message-ID: Ah OK, in the context of a search, that indeed makes more sense ;) Thanks! J. 2013/4/8 Petr Viktorin > On 04/06/2013 11:05 PM, J?r?me Fenal wrote: > >> Same for: >> >> Issued on from >> Issued on to >> Revoked on from >> Revoked on to >> Valid not after from >> Valid not after to >> Valid not before from >> Valid not before to >> >> All inipalib/plugins/internal.py around line 330 >> > > These are UI labels for the options below. > > > 2013/4/6 J?r?me Fenal > >> >> >> Hi all, >> >> I'm currently updating the translations in French for messages in >> FreeIPA, but I am confused by some of them: >> >> Valid not before from this date (YYYY-mm-dd) >> Valid not before to this date (YYYY-mm-dd) >> Issued on from this date (YYYY-mm-dd) >> Issued on to this date (YYYY-mm-dd) >> Revoked on from this date (YYYY-mm-dd) >> ?Revoked on to this date (YYYY-mm-dd) >> >> May I request a native English speaker to review those in their >> context (certificates) and possibly clarify those? >> > > These are help strings for cert-find options. > "Valid not before", "Issued on", etc. are terms for the validity dates of > a certificate. So "Valid not after from this date" means that the > certificate's ending date ("not after") is on or after the given day. > > > Here is the full help for context: > > $ ipa cert-find --help > Usage: ipa [global-options] cert-find [options] > > Search for existing certificates. > Options: > -h, --help show this help message and exit > --subject=STR Subject > --revocation-reason=INT > Reason for revoking the certificate (0-10) > --min-serial-number=INT > minimum serial number > --max-serial-number=INT > maximum serial number > --exactly match the common name exactly > --validnotafter-from=STR > Valid not after from this date (YYYY-mm-dd) > --validnotafter-to=STR > Valid not after to this date (YYYY-mm-dd) > --validnotbefore-from=STR > > Valid not before from this date (YYYY-mm-dd) > --validnotbefore-to=STR > > Valid not before to this date (YYYY-mm-dd) > --issuedon-from=STR Issued on from this date (YYYY-mm-dd) > --issuedon-to=STR Issued on to this date (YYYY-mm-dd) > --revokedon-from=STR Revoked on from this date (YYYY-mm-dd) > --revokedon-to=STR Revoked on to this date (YYYY-mm-dd) > --sizelimit=INT Maximum number of certs returned > --all Retrieve and print all attributes from the server. > Affects command output. > --raw Print entries as stored on the server. Only affects > output format. > > -- > Petr? > -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcholast at redhat.com Mon Apr 8 08:47:03 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 08 Apr 2013 10:47:03 +0200 Subject: [Freeipa-devel] [PATCH] 123 Message-ID: <51628407.8060603@redhat.com> Hi, this patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-123-Use-http-instead-of-https-for-OCSP-and-CRL-URLs-in-I.patch Type: text/x-patch Size: 4819 bytes Desc: not available URL: From jcholast at redhat.com Mon Apr 8 08:48:54 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 08 Apr 2013 10:48:54 +0200 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <51628407.8060603@redhat.com> References: <51628407.8060603@redhat.com> Message-ID: <51628476.7000203@redhat.com> On 8.4.2013 10:47, Jan Cholasta wrote: > Hi, > > this patch fixes . > > Honza > Re-sending with correct subject. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-123-Use-http-instead-of-https-for-OCSP-and-CRL-URLs-in-I.patch Type: text/x-patch Size: 4819 bytes Desc: not available URL: From tbabej at redhat.com Mon Apr 8 10:28:26 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 08 Apr 2013 12:28:26 +0200 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <515F0D5C.5040009@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> <5159E78A.9090902@redhat.com> <515A9132.6030404@redhat.com> <515C105B.6030304@redhat.com> <515D8D68.1060901@redhat.com> <515EB975.5060503@redhat.com> <515F0D5C.5040009@redhat.com> Message-ID: <51629BCA.4070609@redhat.com> On 04/05/2013 07:43 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 04/04/2013 04:25 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On Tue 02 Apr 2013 10:05:06 AM CEST, Tomas Babej wrote: >>>>> On Mon 01 Apr 2013 10:01:14 PM CEST, Rob Crittenden wrote: >>>>>> Tomas Babej wrote: >>>>>>> On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >>>>>>>> Tomas Babej wrote: >>>>>>>>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>>>>>>>> Tomas Babej wrote: >>>>>>>>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> The checks make sure that SELinux is: >>>>>>>>>>>> - installed and enabled (on server install) >>>>>>>>>>>> - installed and enabled OR not installed (on client install) >>>>>>>>>>>> >>>>>>>>>>>> Please note that client installs with SELinux not installed >>>>>>>>>>>> are >>>>>>>>>>>> allowed since freeipa-client package has no dependency on >>>>>>>>>>>> SELinux. >>>>>>>>>>>> (any objections to this approach?) >>>>>>>>>>>> >>>>>>>>>>>> The (unsupported) option --allow-no-selinux has been added. >>>>>>>>>>>> It can >>>>>>>>>>>> used to bypass the checks. >>>>>>>>>>>> >>>>>>>>>>>> Parts of platform-dependant code were refactored to use newly >>>>>>>>>>>> added >>>>>>>>>>>> is_selinux_enabled() function. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>>>>>>>> >>>>>>>>>>>> Tomas >>>>>>>>>>> >>>>>>>>>>> I forgot to edit the man pages. Thanks Rob! >>>>>>>>>>> >>>>>>>>>>> Updated patch attached. >>>>>>>>>>> >>>>>>>>>>> Tomas >>>>>>>>>> >>>>>>>>>> After a bit of off-line discussion I don't think we're quite >>>>>>>>>> ready >>>>>>>>>> yet >>>>>>>>>> to require SELinux by default on client installations (even >>>>>>>>>> with a >>>>>>>>>> flag to work around it). The feeling is this would be >>>>>>>>>> disruptive to >>>>>>>>>> existing automation. >>>>>>>>>> >>>>>>>>>> Can you still do the check but not enforce it, simply display a >>>>>>>>>> big >>>>>>>>>> warning if SELinux is disabled? >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>> >>>>>>>>> Sure, here is the updated patch. >>>>>>>>> >>>>>>>>> I edited the commit message, RFE description and man pages >>>>>>>>> according to >>>>>>>>> the new behaviour. >>>>>>>>> >>>>>>>>> Tomas >>>>>>>> >>>>>>>> The patch looks good, I'm just wondering about one thing. The >>>>>>>> default >>>>>>>> value for is_selinux_enabled() is True in >>>>>>>> ipapython/services.py.in. >>>>>>>> >>>>>>>> So this means that any non-Red Hat/non-Fedora system, by >>>>>>>> default, is >>>>>>>> going to assume that SELinux is enabled. >>>>>>>> >>>>>>>> My hesitation has to when we call check_selinux_status(). It may >>>>>>>> incorrectly error out. I suspect that the user would have to work >>>>>>>> around this using --allow-selinux-disabled but this wouldn't >>>>>>>> make a >>>>>>>> lot of sense since they actually do have SELinux disabled. >>>>>>> >>>>>>> Yes, you're right. And the error message would not even be helpful >>>>>>> since >>>>>>> it would tell the user to install policycoreutils package. This >>>>>>> would be >>>>>>> the >>>>>>> case both with server and client installs when selinux would not be >>>>>>> installed >>>>>>> at all. >>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> rob >>>>>>> >>>>>>> Well we have 2 options as I see it: >>>>>>> >>>>>>> 1.) We can either return None as default, and add checks to >>>>>>> check_selinux_status, restore_context and install scripts that >>>>>>> would >>>>>>> ensure that we behave properly when is_selinux_enabled() is not >>>>>>> implemented. >>>>>>> >>>>>>> 2.) We can remove the default value, since it would cause >>>>>>> forementioned >>>>>>> crash and add comment that this function needs to be implemented >>>>>>> properly in every platform file. >>>>>>> >>>>>>> I'm probably for option 2, there's no need to clutter the code with >>>>>>> checks >>>>>>> that compensate for improper platform file implementations. >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> I agree with you on option 2. >>>>>> >>>>>> rob >>>>> >>>>> I updated the patch accordingly. >>>>> >>>>> Tomas >>>> >>>> Sorry, wrong patch. Correct version attached. >>>> >>>> Tomas >>> >>> I'm sorry to throw this back again after so long (and having agreed >>> with the approach). >>> >>> So I was thinking about how another distro maintainer would have to >>> deal with this. By default with this patch check_selinux_status() >>> returns None which is evaluated as False, so the warning will get >>> thrown. If they set it to be True to avoid the warning then other >>> things may blow up because SELinux really isn't enabled, so we really >>> haven't gotten anywhere. >>> >>> I think the problem is we're trying to cram too much into one >>> function. I wonder if a is_selinux_available() command would help >>> which would short-circuit all of this. >>> >>> While trying to figure out how this worked I found >>> httpinstance.configure_selinux_for_httpd() which makes a similar call >>> to see if SELinux is available, so maybe we should convert that as >>> well. >>> >>> rob >> I added the is_selinux_available function. Both is_selinux_enabled and >> is_selinux_available default to False in services.py.in. Maintainer that >> would want to implement platform file, would have to implement both >> functions for server install. We require SELinux for server anyway. For >> client installs, default versions work fine. >> >> I converted httpinstance.configure_selinux_for_httpd() to use >> is_selinux_enabled(). I also found a similar call in adtrustinstance.py > > Ok, this is getting us closer, and opens a philosophical discussion. > > As implemented, this forces SELinux to be at least be available on the > box, and by default required to be enabled. This is our strong > recommendation for all users. > > There is a flag to allow it be in permissive, which will help people > work around any policy issues or if they don't want SELinux. They'd > still have to run without it completely disabled though. > > This does leave other platforms in a bad place though, there is no out > for them. > > How about adding a require_selinux() call to the platform code > defaulting to True. If someone wants to override that with False they > can. A call to that could be added inside the other is_selinux... > calls to not pollute the rest of the code with it, and if it's False > we just skip all the SELinux stuff. Having the call to require_selinux inside the is_selinux_* functions would force us to pretend that SELinux is up and in enforcing mode (for both is_selinux_available and is_selinux_enabled to return True). While that will allow us to pass the install checks, it would cause failure in other parts of the code, e.g. in httpinstance.py while setting SELinux booleans. If we want to provide an easy way for other platforms, it comes with the cost of polluting our code with require_selinux(). Personally I'm fine with that, it will just clearly mark which parts of the code are dependant on SELinux. > This still leaves us with a hardcoded requirement for SELinux in > Fedora/RHEL and should provide some flexibility for other platforms as > they come. > > What do you think? > > rob Tomas From akrivoka at redhat.com Mon Apr 8 11:40:47 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 08 Apr 2013 13:40:47 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix output for some CLI commands Message-ID: <5162ACBF.7040207@redhat.com> Hello, This patch addresses https://fedorahosted.org/freeipa/ticket/3503. See the commit message for details. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0012-Fix-output-for-some-CLI-commands.patch Type: text/x-patch Size: 12751 bytes Desc: not available URL: From mkosek at redhat.com Mon Apr 8 12:42:47 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Apr 2013 14:42:47 +0200 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <51628476.7000203@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> Message-ID: <5162BB47.7020400@redhat.com> On 04/08/2013 10:48 AM, Jan Cholasta wrote: > On 8.4.2013 10:47, Jan Cholasta wrote: >> Hi, >> >> this patch fixes . >> >> Honza >> > > Re-sending with correct subject. > I tested the change both for upgrades and for fresh installs and it worked fine both cases, even when testing with Firefox enforcing mode. So far, as the biggest issue in current process I see NSS not being able to fallback to other defined OCSP responder (I tested with Firefox 20). This way, Firefox will fail validating the FreeIPA site when the first tested OCSP responder is not available (e.g. the original IPA CA signing the http cert, or an `ipa-ca.$domain` host that is currently not up). Martin From rcritten at redhat.com Mon Apr 8 13:03:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Apr 2013 09:03:15 -0400 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <5162769D.2060202@redhat.com> References: <515F1100.5000603@redhat.com> <5162769D.2060202@redhat.com> Message-ID: <5162C013.5030708@redhat.com> Petr Vobornik wrote: > On 04/05/2013 07:59 PM, Ana Krivokapic wrote: >> Hello list, >> >> I have been thinking about the possible implementation for a solution of >> ticket https://fedorahosted.org/freeipa/ticket/3528. There are several >> options: >> >> 1. Completely remove the commands and command options related to source >> hosts in HBAC. This might not be a good idea as it could cause problems >> for older clients. >> >> 2. Hide these commands/options from the web UI, but leave them in CLI. >> This would keep the API intact, but I don't like the idea of introducing >> inconsistencies between CLI and web UI. >> >> 3. Do not remove anything, but issue deprecation warnings. The user will >> see a warning when using these commands/options, but everything will >> still work. >> >> 4. Do not remove anything, but raise exceptions. This would effectively >> prevent the user from using these commands/options, as the exception >> will break the execution of a command. >> >> In any case, any reference to source hosts should be removed from help >> and documentation. >> >> I am leaning towards options 3 or 4. >> >> Thoughts, comments and ideas are welcome. >> > > IMHO the main question is whether we want to deprecate it or remove it. > SSSD is deprecating it so I would go that way too. > > #1 and #4 are basically a removal, #4 a bad one. > #2 is removal from Web UI perspective. > > I would do #3 with some changes. In both Web UI and CLI there should be > clear label that the section/options are deprecated. We may introduce a > deprecated flag. With this change we don't have to show the warning. But > in CLI we might because user didn't had to read help beforehand. It has been deprecated for quite a while now. This was raised because we let users enter this data via the UI and CLI and it does absolutely nothing which is terribly misleading. I think that it should be removed from the UI completely. I'm torn with the CLI, though leaning on hiding the options. It might be worthwhile to also raise an exception if anyone tries to use it via a script or otherwise. rob From mkosek at redhat.com Mon Apr 8 13:26:56 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Apr 2013 15:26:56 +0200 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <5162C013.5030708@redhat.com> References: <515F1100.5000603@redhat.com> <5162769D.2060202@redhat.com> <5162C013.5030708@redhat.com> Message-ID: <5162C5A0.2060209@redhat.com> On 04/08/2013 03:03 PM, Rob Crittenden wrote: > Petr Vobornik wrote: >> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: >>> Hello list, >>> >>> I have been thinking about the possible implementation for a solution of >>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are several >>> options: >>> >>> 1. Completely remove the commands and command options related to source >>> hosts in HBAC. This might not be a good idea as it could cause problems >>> for older clients. >>> >>> 2. Hide these commands/options from the web UI, but leave them in CLI. >>> This would keep the API intact, but I don't like the idea of introducing >>> inconsistencies between CLI and web UI. >>> >>> 3. Do not remove anything, but issue deprecation warnings. The user will >>> see a warning when using these commands/options, but everything will >>> still work. >>> >>> 4. Do not remove anything, but raise exceptions. This would effectively >>> prevent the user from using these commands/options, as the exception >>> will break the execution of a command. >>> >>> In any case, any reference to source hosts should be removed from help >>> and documentation. >>> >>> I am leaning towards options 3 or 4. >>> >>> Thoughts, comments and ideas are welcome. >>> >> >> IMHO the main question is whether we want to deprecate it or remove it. >> SSSD is deprecating it so I would go that way too. >> >> #1 and #4 are basically a removal, #4 a bad one. >> #2 is removal from Web UI perspective. >> >> I would do #3 with some changes. In both Web UI and CLI there should be >> clear label that the section/options are deprecated. We may introduce a >> deprecated flag. With this change we don't have to show the warning. But >> in CLI we might because user didn't had to read help beforehand. > > It has been deprecated for quite a while now. This was raised because we let > users enter this data via the UI and CLI and it does absolutely nothing which > is terribly misleading. > > I think that it should be removed from the UI completely. I'm torn with the > CLI, though leaning on hiding the options. > > It might be worthwhile to also raise an exception if anyone tries to use it via > a script or otherwise. > > rob > +1. We could hide it (so that it is not seen in CLI) and raise an exception if some old script tries to use it. I did this for example for no longer supported DNS records in dnsrecord-add (simulated with setattr): # ipa dnsrecord-add example.com apl --setattr=aplrecord="foo" ipa: ERROR: invalid 'aplrecord': DNS RR type "APL" is not supported by bind-dyndb-ldap plugin The param simply has "no_option" flag and its validator always fails. We should remove the parameter altogether at some point, maybe next major version? Martin From pvoborni at redhat.com Mon Apr 8 13:34:17 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 08 Apr 2013 15:34:17 +0200 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <5162C013.5030708@redhat.com> References: <515F1100.5000603@redhat.com> <5162769D.2060202@redhat.com> <5162C013.5030708@redhat.com> Message-ID: <5162C759.8050003@redhat.com> On 04/08/2013 03:03 PM, Rob Crittenden wrote: > Petr Vobornik wrote: >> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: >>> Hello list, >>> >>> I have been thinking about the possible implementation for a solution of >>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are several >>> options: >>> >>> 1. Completely remove the commands and command options related to source >>> hosts in HBAC. This might not be a good idea as it could cause problems >>> for older clients. >>> >>> 2. Hide these commands/options from the web UI, but leave them in CLI. >>> This would keep the API intact, but I don't like the idea of introducing >>> inconsistencies between CLI and web UI. >>> >>> 3. Do not remove anything, but issue deprecation warnings. The user will >>> see a warning when using these commands/options, but everything will >>> still work. >>> >>> 4. Do not remove anything, but raise exceptions. This would effectively >>> prevent the user from using these commands/options, as the exception >>> will break the execution of a command. >>> >>> In any case, any reference to source hosts should be removed from help >>> and documentation. >>> >>> I am leaning towards options 3 or 4. >>> >>> Thoughts, comments and ideas are welcome. >>> >> >> IMHO the main question is whether we want to deprecate it or remove it. >> SSSD is deprecating it so I would go that way too. >> >> #1 and #4 are basically a removal, #4 a bad one. >> #2 is removal from Web UI perspective. >> >> I would do #3 with some changes. In both Web UI and CLI there should be >> clear label that the section/options are deprecated. We may introduce a >> deprecated flag. With this change we don't have to show the warning. But >> in CLI we might because user didn't had to read help beforehand. > > It has been deprecated for quite a while now. This was raised because we > let users enter this data via the UI and CLI and it does absolutely > nothing which is terribly misleading. > > I think that it should be removed from the UI completely. I'm torn with > the CLI, though leaning on hiding the options. Removing it from UI and hiding it in CLI might work for users. I assume that it will break scripts which are using CLI ('error: no such option:'). API based scripts will continue to work. Do we want to break CLI-based scripts and keep compatibility with API-based ones? > > It might be worthwhile to also raise an exception if anyone tries to use > it via a script or otherwise. Wouldn't removing the options raise an exception as well? I don't see a point in keeping them when it will always raise an exception. > > rob -- Petr Vobornik From rcritten at redhat.com Mon Apr 8 13:37:20 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Apr 2013 09:37:20 -0400 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <5162C759.8050003@redhat.com> References: <515F1100.5000603@redhat.com> <5162769D.2060202@redhat.com> <5162C013.5030708@redhat.com> <5162C759.8050003@redhat.com> Message-ID: <5162C810.7060109@redhat.com> Petr Vobornik wrote: > On 04/08/2013 03:03 PM, Rob Crittenden wrote: >> Petr Vobornik wrote: >>> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: >>>> Hello list, >>>> >>>> I have been thinking about the possible implementation for a >>>> solution of >>>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are several >>>> options: >>>> >>>> 1. Completely remove the commands and command options related to source >>>> hosts in HBAC. This might not be a good idea as it could cause problems >>>> for older clients. >>>> >>>> 2. Hide these commands/options from the web UI, but leave them in CLI. >>>> This would keep the API intact, but I don't like the idea of >>>> introducing >>>> inconsistencies between CLI and web UI. >>>> >>>> 3. Do not remove anything, but issue deprecation warnings. The user >>>> will >>>> see a warning when using these commands/options, but everything will >>>> still work. >>>> >>>> 4. Do not remove anything, but raise exceptions. This would effectively >>>> prevent the user from using these commands/options, as the exception >>>> will break the execution of a command. >>>> >>>> In any case, any reference to source hosts should be removed from help >>>> and documentation. >>>> >>>> I am leaning towards options 3 or 4. >>>> >>>> Thoughts, comments and ideas are welcome. >>>> >>> >>> IMHO the main question is whether we want to deprecate it or remove it. >>> SSSD is deprecating it so I would go that way too. >>> >>> #1 and #4 are basically a removal, #4 a bad one. >>> #2 is removal from Web UI perspective. >>> >>> I would do #3 with some changes. In both Web UI and CLI there should be >>> clear label that the section/options are deprecated. We may introduce a >>> deprecated flag. With this change we don't have to show the warning. But >>> in CLI we might because user didn't had to read help beforehand. >> >> It has been deprecated for quite a while now. This was raised because we >> let users enter this data via the UI and CLI and it does absolutely >> nothing which is terribly misleading. >> >> I think that it should be removed from the UI completely. I'm torn with >> the CLI, though leaning on hiding the options. > > Removing it from UI and hiding it in CLI might work for users. I assume > that it will break scripts which are using CLI ('error: no such > option:'). API based scripts will continue to work. > > Do we want to break CLI-based scripts and keep compatibility with > API-based ones? > >> >> It might be worthwhile to also raise an exception if anyone tries to use >> it via a script or otherwise. > > Wouldn't removing the options raise an exception as well? I don't see a > point in keeping them when it will always raise an exception. You seem to be following my line of reasoning: if we remove the options it is going to break CLI-based scripts. If we don't remove them then we need to raise an exception. Or we do some odd combination of both, depending on what our goal is. I would normally argue against removing a command-line option but given that these literally don't do anything now, I'm actually leaning towards removing them. For those using the API directly then yeah, we probably want to raise an exception to be absolutely clear, "don't do it." rob From jcholast at redhat.com Mon Apr 8 13:41:30 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 08 Apr 2013 15:41:30 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix output for some CLI commands In-Reply-To: <5162ACBF.7040207@redhat.com> References: <5162ACBF.7040207@redhat.com> Message-ID: <5162C90A.9070301@redhat.com> Hi, On 8.4.2013 13:40, Ana Krivokapic wrote: > Hello, > > This patch addresses https://fedorahosted.org/freeipa/ticket/3503. See > the commit message for details. > the patch seems OK, I will just run the test suite to make sure you didn't miss anything. Honza -- Jan Cholasta From pviktori at redhat.com Mon Apr 8 13:40:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Apr 2013 15:40:13 +0200 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <515F3A16.9050500@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> Message-ID: <5162C8BD.9080409@redhat.com> On 04/05/2013 10:54 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>>> There are strict limits on what can be restored where. Only exact >>>>>> matching hostnames and versions are allowed right now. We can >>>>>> probably >>>>>> relax the hostname requirement if we're only restoring data, and the >>>>>> version perhaps for only the the first two values (so you can >>>>>> restore a >>>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>>> >>>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>>> Or is what they put in /var/lib guaranteed portable across versions? >>>> >>>> An interesting question. I'd imagine that a major db change would also >>>> require a major update to IPA, therefore if we restrict by IPA version >>>> we should be ok. I AM doing an untar of files though so yeah, there >>>> is a >>>> risk here. >>>> >>>>> >>>>> >>>>> That's good to hear! >>>>> >>>>> I think while developing, you should run with -v to get all the >>>>> output. >>>>> And for production, please have the commands log by default (set >>>>> log_file_name). >>>> >>>> Yes, I plan on adding that in the future. >>>> >>>>> >>>>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>>>> password because we need to contact remote servers to enable/disable >>>>>> replication. >>>>> >>>>> The restore assumes that ipa is already installed, right? I can't just >>>>> run it on a clean machine? Id would be good to check/document this. >>>> >>>> It depends. >>>> >>>> For a full backup you can actually restore to an uninstalled server. In >>>> fact, you could restore to a machine w/no IPA bits on it at all in all >>>> likelihood (which wouldn't be very nice, but not exactly wrong either >>>> IMHO). >>>> >>>> I tested this with: >>>> - ipa-server-install >>>> - ipa-backup >>>> - ipa-server-install --uninstall -U >>>> - ipa-restore >>>> - ran the unit tests >>>> >>>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>>> directories. Are these needed? >>>> >>>> Probably not. I gathered some of the files to backup based on watching >>>> what files that changed during an install that are independent of us. >>>> I'll take another pass through it, there may be other oddities too. >>>> >>>>> The tool runners (install/tools/ipa-backup and >>>>> install/tools/ipa-restore) are missing, so IPA doesn't build. Probably >>>>> just a forgotten git add. >>>> >>>> Yup. >>>> >>>>> >>>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>>> consider adding $(NULL) at the end. >>>> >>>> I'll take a look. >>>> >>>>> >>>>> Backup.dirs, Backup.files, Backup.logs: >>>>> The code modifies these class-level attributes. This means you can't >>>>> run >>>>> the command more than once in one Python session, so it can't be >>>>> used as >>>>> a library (e.g. in a hypothetical test suite). >>>>> Please make the class atrributes immutable (tuples), then in >>>>> __init__ do >>>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>>> >>>> Ok, fair point. >>>> >>>>> Code that creates temporary files/directories or does chdir() >>>>> should be >>>>> next to (or in) a try block whose finally: restores things. >>>> >>>> Yes, I mean to add a big try/finally block around everything in run >>>> eventually (or the equivalent anyway). >>>> >>>>> >>>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>>> please explicitly import whatever you're using from that package. In >>>>> this case, nothing at all! >>>> >>>> Yeah, I haven't run this through pylint yet to see all the bad >>>> imports I >>>> cobbled together. >>>> >>>>> If there's a get_connection() method, it should return the connection, >>>>> and it should always be used to get it. Store the connection in >>>>> self._conn, and rather than: >>>>> self.get_connection() >>>>> self.conn.do_work() >>>>> do: >>>>> conn = self.get_connection() >>>>> conn.do_work() >>>>> This makes forgetting to call get_connection() impossible. >>>> >>>> My purpose was to avoid creating multiple connections. >>>> >>>>> If a variable is only used in a single method, like `filename` in >>>>> Restore.extract_backup, don't store it in the admintool object. >>>>> In general, try to avoid putting data in self if possible. It's >>>>> convenient but it allows complex interdependencies. >>>>> (Yes, I'm guilty of not following this myself.) >>>> >>>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a >>>> rush >>>> to get this WIP out. >>>> >>>>> In several places, the backup tool logs critical errors and then just >>>>> continues on. Is that by design? I think a nonzero exit code would be >>>>> appropriate. >>>> >>>> I'll take a look at them, all I can say at this point is maybe. >>>> >>>>> In the ipa-restore man page, --backend is not documented. >>>>> >>>>> In db2ldif, db2bak, etc., a more conscise way to get the time >>>>> string is >>>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>>> >>>>> When validating --gpg-keyring, it would be good to check both files >>>>> (.sec and .pub). >>>> >>>> Ok, I can do those. >>>> >>>>> >>>>> Here: >>>>> if (self.backup_type != 'FULL' and not options.data_only and >>>>> not instances): >>>>> raise admintool.ScriptError('Cannot restore a data backup >>>>> into >>>>> an empty system') >>>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and >>>>> not >>>>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >>>> >>>> Yeah, looks like that should be an or. >>>> >>>>> In the ReplicationManager.check_repl_init reporting: use >>>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>>> include full days. I don't think anyone would wait long enough for the >>>>> overflow, but better to be correct. >>>> >>>> Sure, I doubt anyone would wait 24 hours either but its a no-brainer to >>>> make it safe. >>> >>> I think I've addressed just about everything. >>> >>> The reason that /var/run/dirsrv and var/lock/dirsrv are included in the >>> backup is for the case of a full restore. These directories are not >>> created/provided by the package itself, but by installing the first >>> instance, so we need the ownership/SELinux context preserved. >>> >>> One thing I need tested is restoring over top of new data with multiple >>> replicas. So basically install, do a backup, add a bunch of data, >>> restore, re-initialize all the other masters and then confirm that ALL >>> the new data is gone. I think I've got the sequence right but this is >>> critical. >>> >>> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >>> 9/multi-instance DS configurations). >>> >>> One thing I tested was: >>> >>> - ipa-server-install >>> - ipa-backup >>> - ipa-server-install --uninstall -U >>> - ipa-restore ipa-full-... >>> >>> This will actually get your server back EXCEPT that dogtag won't start. >>> This is because the log directories are created by the instance >>> creation. There are two solutions: backup with --logs or manually >>> re-create the log directories (there are several, depending on dogtag >>> version). >> >> Could backup without --logs save which directories are there, and >> restore create empty directories if they don't exist? To me >> re-initializing a completely wiped machine looks like a big gain for the >> extra effort. > > I went ahead and made this change, it wasn't a lot of work. > >> >> >> >> The spec changelog needs a small rebase. > > Done. > >> >> I've tested some scenarios and didn't find any other issues so far. >> >> I still want to test some more with upgraded masters; installing them >> takes some time. >> Also I still need to test CA replicas (with the DNAME patches removed). >> > > rob I've tested some more. It works well with 3.2 masters, even one upgraded from 2.2. When there's a 2.2 master in the topology, things are not so nice. When I ran ipa-replica-manage re-initialize, it started printing "update in progress" lines for several minutes with no signs of stopping. The following appeared in the slapd error log on the source server: [08/Apr/2013:13:38:48 +0200] NSMMReplicationPlugin - Replication agreement for agmt="cn=meTovm-084.idm.lab.eng.brq.redhat.com" (vm-084:389) could not be updated. For replication to take place, please enable the suffix and restart the server I somehow doubt that's caused by this patch, though -- was replica re-initialize tested with disparate versions recently? I can test again with a simpler scenario to pinpoint the issue. -- Petr? From pviktori at redhat.com Mon Apr 8 13:44:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Apr 2013 15:44:07 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix output for some CLI commands In-Reply-To: <5162ACBF.7040207@redhat.com> References: <5162ACBF.7040207@redhat.com> Message-ID: <5162C9A7.8020205@redhat.com> On 04/08/2013 01:40 PM, Ana Krivokapic wrote: > Hello, > > This patch addresseshttps://fedorahosted.org/freeipa/ticket/3503. See > the commit message for details. > > -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red > Hat Inc. > > > freeipa-akrivoka-0012-Fix-output-for-some-CLI-commands.patch > > [...] > + msg_summary = _('Deleted zone "%(value)s"') > + We're in string freeze now. This will have to wait for the next version :( -- Petr? From dpal at redhat.com Mon Apr 8 13:47:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Apr 2013 09:47:10 -0400 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <5162BB47.7020400@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> Message-ID: <5162CA5E.2010307@redhat.com> On 04/08/2013 08:42 AM, Martin Kosek wrote: > On 04/08/2013 10:48 AM, Jan Cholasta wrote: >> On 8.4.2013 10:47, Jan Cholasta wrote: >>> Hi, >>> >>> this patch fixes . >>> >>> Honza >>> >> Re-sending with correct subject. >> > I tested the change both for upgrades and for fresh installs and it worked fine > both cases, even when testing with Firefox enforcing mode. > > So far, as the biggest issue in current process I see NSS not being able to > fallback to other defined OCSP responder (I tested with Firefox 20). This way, > Firefox will fail validating the FreeIPA site when the first tested OCSP > responder is not available (e.g. the original IPA CA signing the http cert, or > an `ipa-ca.$domain` host that is currently not up). Have we filed a ticket with FF? > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Mon Apr 8 13:55:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Apr 2013 15:55:44 +0200 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <5159E560.6030603@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> Message-ID: <5162CC60.8040008@redhat.com> On 04/01/2013 09:52 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>> pre_bind operation >>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >>>>> denied and LDAP_INVALID_CREDENTIALS along with the error message is >>>>> sent back to the client. Since krbprincipalexpiration attribute is >>>> not >>>>> mandatory, if there is no value set, the check is passed. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3305 >>> >>> Comments inline. >>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>> goto done; >>>> } >>>> + /* check the krbPrincipalExpiration attribute is present */ >>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>> &attr); >>>> + if (!ret) { >>> ret is not a boolean so probably better ti use (ret != 0) >>> >>>> + /* if it is, check whether the principal has not expired */ >>>> + >>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>> + "krbprincipalexpiration"); >>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>> + >>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", &expire_tm)){ >>> style issue missing space between ) and { >>> >>>> + expire_time = mktime(&expire_tm); >>>> + /* this might have overflown on 32-bit system */ >>> This comment does not help to point out what you want to put in >>> evidence. >>> if there is an overflow what is the consequence ? Or does it mean the >>> next condition is taking that into account ? >> Yeah, this was rather ill-worded. Replaced by a rather verbose >> comment that hopefully clears things out. >>> >>>> + if (current_time > expire_time && expire_time > 0){ >>> style issue missing space between ) and { >>> >>>> + LOG_FATAL("kerberos principal has expired in user >>>> entry: %s\n", >>>> + dn); >>> I think a better phrasing would be: "The kerberos principal on %s is >>> expired\n" >>> >>>> + errMesg = "Kerberos principal has expired."; >>> s/has/is/ >>> >>> The rest looks good to me. >>> >>> Simo. >> Styling issues fixed and updated patch attached :) > > Small nit, the expiration error should probably use 'in' not 'on'. > > I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This implies > that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM is probably > more correct here. It is what we return on other policy failures. > > rob > Additional findings: 1) Lets not try to get current_time every time, but only when its needed (i.e. krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: + /* get current time*/ + current_time = time(NULL); 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find the attribute again when we already have a pointer for the attribute? Would slapi_attr_first_value following slapi_entry_attr_find be faster approach? + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", &attr); + if (ret != 0) { + /* if it is, check whether the principal has not expired */ + + principal_expire = slapi_entry_attr_get_charptr(entry, + "krbprincipalexpiration"); This way, we would not create a copy of this attribute value - we do not need a copy, we just do check against it. 3) Shouldn't we return -1 in the end when the auth fails? We do that in other pre_callbacks. Otherwise we just return 0 (success): + if (auth_failed){ + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, errMesg, + 0, NULL); + } + return 0; Martin From tbabej at redhat.com Mon Apr 8 13:56:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 08 Apr 2013 15:56:08 +0200 Subject: [Freeipa-devel] [PATCH 0044] Update only selected attributes for winsync agreement Message-ID: <5162CC78.6030208@redhat.com> Hi, Trying to insert nsDS5ReplicatedAttributeListTotal and nsds5ReplicaStripAttrs to winsync agreements caused upgrade errors. With this patch, these attributes are skipped for winsync agreements. Made find_ipa_replication_agreements() in replication.py more corresponding to find_replication_agreements. It returns list of entries instead of unicode strings now. https://fedorahosted.org/freeipa/ticket/3522 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0044-Update-only-selected-attributes-for-winsync-agreemen.patch Type: text/x-patch Size: 5291 bytes Desc: not available URL: From dpal at redhat.com Mon Apr 8 14:19:04 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Apr 2013 10:19:04 -0400 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <5162C810.7060109@redhat.com> References: <515F1100.5000603@redhat.com> <5162769D.2060202@redhat.com> <5162C013.5030708@redhat.com> <5162C759.8050003@redhat.com> <5162C810.7060109@redhat.com> Message-ID: <5162D1D8.2090609@redhat.com> On 04/08/2013 09:37 AM, Rob Crittenden wrote: > Petr Vobornik wrote: >> On 04/08/2013 03:03 PM, Rob Crittenden wrote: >>> Petr Vobornik wrote: >>>> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: >>>>> Hello list, >>>>> >>>>> I have been thinking about the possible implementation for a >>>>> solution of >>>>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are >>>>> several >>>>> options: >>>>> >>>>> 1. Completely remove the commands and command options related to >>>>> source >>>>> hosts in HBAC. This might not be a good idea as it could cause >>>>> problems >>>>> for older clients. >>>>> >>>>> 2. Hide these commands/options from the web UI, but leave them in >>>>> CLI. >>>>> This would keep the API intact, but I don't like the idea of >>>>> introducing >>>>> inconsistencies between CLI and web UI. >>>>> >>>>> 3. Do not remove anything, but issue deprecation warnings. The user >>>>> will >>>>> see a warning when using these commands/options, but everything will >>>>> still work. >>>>> >>>>> 4. Do not remove anything, but raise exceptions. This would >>>>> effectively >>>>> prevent the user from using these commands/options, as the exception >>>>> will break the execution of a command. >>>>> >>>>> In any case, any reference to source hosts should be removed from >>>>> help >>>>> and documentation. >>>>> >>>>> I am leaning towards options 3 or 4. >>>>> >>>>> Thoughts, comments and ideas are welcome. >>>>> >>>> >>>> IMHO the main question is whether we want to deprecate it or remove >>>> it. >>>> SSSD is deprecating it so I would go that way too. >>>> >>>> #1 and #4 are basically a removal, #4 a bad one. >>>> #2 is removal from Web UI perspective. >>>> >>>> I would do #3 with some changes. In both Web UI and CLI there >>>> should be >>>> clear label that the section/options are deprecated. We may >>>> introduce a >>>> deprecated flag. With this change we don't have to show the >>>> warning. But >>>> in CLI we might because user didn't had to read help beforehand. >>> >>> It has been deprecated for quite a while now. This was raised >>> because we >>> let users enter this data via the UI and CLI and it does absolutely >>> nothing which is terribly misleading. >>> >>> I think that it should be removed from the UI completely. I'm torn with >>> the CLI, though leaning on hiding the options. >> >> Removing it from UI and hiding it in CLI might work for users. I assume >> that it will break scripts which are using CLI ('error: no such >> option:'). API based scripts will continue to work. >> >> Do we want to break CLI-based scripts and keep compatibility with >> API-based ones? >> >>> >>> It might be worthwhile to also raise an exception if anyone tries to >>> use >>> it via a script or otherwise. >> >> Wouldn't removing the options raise an exception as well? I don't see a >> point in keeping them when it will always raise an exception. > > You seem to be following my line of reasoning: if we remove the > options it is going to break CLI-based scripts. If we don't remove > them then we need to raise an exception. > > Or we do some odd combination of both, depending on what our goal is. > > I would normally argue against removing a command-line option but > given that these literally don't do anything now, I'm actually leaning > towards removing them. > > For those using the API directly then yeah, we probably want to raise > an exception to be absolutely clear, "don't do it." > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Can we just ignore the option and warn if we encounter it? What is the harm of ignoring is it already does not do anything? But it also would not break anyone. Would that be better? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Mon Apr 8 14:33:27 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 08 Apr 2013 16:33:27 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix output for some CLI commands In-Reply-To: <5162C90A.9070301@redhat.com> References: <5162ACBF.7040207@redhat.com> <5162C90A.9070301@redhat.com> Message-ID: <5162D537.6010800@redhat.com> On 8.4.2013 15:41, Jan Cholasta wrote: > Hi, > > On 8.4.2013 13:40, Ana Krivokapic wrote: >> Hello, >> >> This patch addresses https://fedorahosted.org/freeipa/ticket/3503. See >> the commit message for details. >> > > the patch seems OK, I will just run the test suite to make sure you > didn't miss anything. > > Honza > Change dnszone_del summary to "Deleted DNS zone", as we use "DNS zone" (not just "zone") in other commands. Also as Petr pointed out, we're in string freeze now, so we have to wait until it's over before pushing this patch, or split the patch in two. Besides that, ACK. -- Jan Cholasta From mkosek at redhat.com Mon Apr 8 15:09:13 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 08 Apr 2013 17:09:13 +0200 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <5162CA5E.2010307@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> Message-ID: <5162DD99.2030403@redhat.com> On 04/08/2013 03:47 PM, Dmitri Pal wrote: > On 04/08/2013 08:42 AM, Martin Kosek wrote: >> On 04/08/2013 10:48 AM, Jan Cholasta wrote: >>> On 8.4.2013 10:47, Jan Cholasta wrote: >>>> Hi, >>>> >>>> this patch fixes . >>>> >>>> Honza >>>> >>> Re-sending with correct subject. >>> >> I tested the change both for upgrades and for fresh installs and it worked fine >> both cases, even when testing with Firefox enforcing mode. >> >> So far, as the biggest issue in current process I see NSS not being able to >> fallback to other defined OCSP responder (I tested with Firefox 20). This way, >> Firefox will fail validating the FreeIPA site when the first tested OCSP >> responder is not available (e.g. the original IPA CA signing the http cert, or >> an `ipa-ca.$domain` host that is currently not up). > > Have we filed a ticket with FF? AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=797815 Rob seems to have more context about this bug background. Martin From jcholast at redhat.com Mon Apr 8 15:21:41 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 08 Apr 2013 17:21:41 +0200 Subject: [Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback In-Reply-To: <515DE634.6020105@redhat.com> References: <514C673E.70800@redhat.com> <515DE634.6020105@redhat.com> Message-ID: <5162E085.5030709@redhat.com> On 4.4.2013 22:44, Rob Crittenden wrote: > This patch works well enough against a devel build at > http://nkinder.fedorapeople.org/389-devel/ without the Requires on 1.3.1 > (the devel build still claims to be 1.3.0.5). I bumped Requires because says it is planned for 1.3.1. > > The patch itself doesn't do much yet but it does what it says it does. Correct, it is just a pre-requirement for automated replication recovery and external user mapping. Automated replication recovery is currently in beer exchange: . As for external user mapping, I'm going to need more input on that. Alexander and Simo should know more, adding them to CC. Honza -- Jan Cholasta From rcritten at redhat.com Mon Apr 8 15:31:42 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Apr 2013 11:31:42 -0400 Subject: [Freeipa-devel] [PATCH] 122 Enable SASL mapping fallback In-Reply-To: <5162E085.5030709@redhat.com> References: <514C673E.70800@redhat.com> <515DE634.6020105@redhat.com> <5162E085.5030709@redhat.com> Message-ID: <5162E2DE.2090307@redhat.com> Jan Cholasta wrote: > On 4.4.2013 22:44, Rob Crittenden wrote: >> This patch works well enough against a devel build at >> http://nkinder.fedorapeople.org/389-devel/ without the Requires on 1.3.1 >> (the devel build still claims to be 1.3.0.5). > > I bumped Requires because says > it is planned for 1.3.1. > >> >> The patch itself doesn't do much yet but it does what it says it does. > > Correct, it is just a pre-requirement for automated replication recovery > and external user mapping. > > Automated replication recovery is currently in beer exchange: > . > > As for external user mapping, I'm going to need more input on that. > Alexander and Simo should know more, adding them to CC. > > Honza > Sure. I didn't mean to imply anything was wrong with the patch, just that we couldn't push it just yet. It seems to do the right thing according to the 389-ds docs, the bits just aren't ready officially yet. rob From pviktori at redhat.com Mon Apr 8 15:45:30 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 08 Apr 2013 17:45:30 +0200 Subject: [Freeipa-devel] FreeIPA string freeze Message-ID: <5162E61A.5060700@redhat.com> Hello, FreeIPA translators! We wanted to give enough time for translations, so we made an upstream string freeze last week, giving about two weeks of translation time until the beta. We didn't expect most of the translations to be done already -- Ukrainian at 100% and French with 40 strings missing. Thank you!! Meanwhile we have some fixes upstream that add/change additional strings that would have to be postponed for the next release. How much would it inconvenience you if instead of postponing the patches, we'd push each change to Transifex as it is pushed to master? In the past J?r?me said that updating continuously would be better than the string freezes and mass updates we do now. We don't have resources to automate that*, but for slipping a few strings past string freeze it could work. -- Petr? * For the record, before automating it I'd like to first automate archiving the translations somewhere, so a bad Transifex update doesn't wipe out all the existing translations. After that it should be fairly simple to set Transifex up to track our repo. From akrivoka at redhat.com Mon Apr 8 16:15:28 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 08 Apr 2013 18:15:28 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix output for some CLI commands In-Reply-To: <5162D537.6010800@redhat.com> References: <5162ACBF.7040207@redhat.com> <5162C90A.9070301@redhat.com> <5162D537.6010800@redhat.com> Message-ID: <5162ED20.1050500@redhat.com> On 04/08/2013 04:33 PM, Jan Cholasta wrote: > On 8.4.2013 15:41, Jan Cholasta wrote: >> Hi, >> >> On 8.4.2013 13:40, Ana Krivokapic wrote: >>> Hello, >>> >>> This patch addresses https://fedorahosted.org/freeipa/ticket/3503. See >>> the commit message for details. >>> >> >> the patch seems OK, I will just run the test suite to make sure you >> didn't miss anything. >> >> Honza >> > > Change dnszone_del summary to "Deleted DNS zone", as we use "DNS zone" > (not just "zone") in other commands. Also as Petr pointed out, we're > in string freeze now, so we have to wait until it's over before > pushing this patch, or split the patch in two. > > Besides that, ACK. > Thanks for the review. I have changed the summary message to "Deleted DNS zone", and split the patch into two patches that can be applied independently. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0012-02-Fix-output-for-some-CLI-commands.patch Type: text/x-patch Size: 10685 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0013-Add-missing-summary-message-to-dnszone_del.patch Type: text/x-patch Size: 2590 bytes Desc: not available URL: From yurchor at ukr.net Mon Apr 8 15:54:46 2013 From: yurchor at ukr.net (Yuri Chornoivan) Date: Mon, 08 Apr 2013 18:54:46 +0300 Subject: [Freeipa-devel] FreeIPA string freeze In-Reply-To: <5162E61A.5060700@redhat.com> References: <5162E61A.5060700@redhat.com> Message-ID: ???????? Mon, 08 Apr 2013 18:45:30 +0300, Petr Viktorin : > Hello, FreeIPA translators! > > We wanted to give enough time for translations, so we made an upstream > string freeze last week, giving about two weeks of translation time > until the beta. > We didn't expect most of the translations to be done already -- > Ukrainian at 100% and French with 40 strings missing. Thank you!! > > Meanwhile we have some fixes upstream that add/change additional strings > that would have to be postponed for the next release. > How much would it inconvenience you if instead of postponing the > patches, we'd push each change to Transifex as it is pushed to master? > > In the past J?r?me said that updating continuously would be better than > the string freezes and mass updates we do now. We don't have resources > to automate that*, but for slipping a few strings past string freeze it > could work. > Hi, Surely, it would be good to have fixes now (as well as some announce in trans at lists.fedoraproject.org ). And I'm all of the J?r?me's proposal. It is enough to have updates every 3-4 months. That will make the translation process significantly easier. Thanks for your work. Best regards, Yuri From rcritten at redhat.com Mon Apr 8 17:30:20 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Apr 2013 13:30:20 -0400 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <5162D1D8.2090609@redhat.com> References: <515F1100.5000603@redhat.com> <5162769D.2060202@redhat.com> <5162C013.5030708@redhat.com> <5162C759.8050003@redhat.com> <5162C810.7060109@redhat.com> <5162D1D8.2090609@redhat.com> Message-ID: <5162FEAC.2010201@redhat.com> Dmitri Pal wrote: > On 04/08/2013 09:37 AM, Rob Crittenden wrote: >> Petr Vobornik wrote: >>> On 04/08/2013 03:03 PM, Rob Crittenden wrote: >>>> Petr Vobornik wrote: >>>>> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: >>>>>> Hello list, >>>>>> >>>>>> I have been thinking about the possible implementation for a >>>>>> solution of >>>>>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are >>>>>> several >>>>>> options: >>>>>> >>>>>> 1. Completely remove the commands and command options related to >>>>>> source >>>>>> hosts in HBAC. This might not be a good idea as it could cause >>>>>> problems >>>>>> for older clients. >>>>>> >>>>>> 2. Hide these commands/options from the web UI, but leave them in >>>>>> CLI. >>>>>> This would keep the API intact, but I don't like the idea of >>>>>> introducing >>>>>> inconsistencies between CLI and web UI. >>>>>> >>>>>> 3. Do not remove anything, but issue deprecation warnings. The user >>>>>> will >>>>>> see a warning when using these commands/options, but everything will >>>>>> still work. >>>>>> >>>>>> 4. Do not remove anything, but raise exceptions. This would >>>>>> effectively >>>>>> prevent the user from using these commands/options, as the exception >>>>>> will break the execution of a command. >>>>>> >>>>>> In any case, any reference to source hosts should be removed from >>>>>> help >>>>>> and documentation. >>>>>> >>>>>> I am leaning towards options 3 or 4. >>>>>> >>>>>> Thoughts, comments and ideas are welcome. >>>>>> >>>>> >>>>> IMHO the main question is whether we want to deprecate it or remove >>>>> it. >>>>> SSSD is deprecating it so I would go that way too. >>>>> >>>>> #1 and #4 are basically a removal, #4 a bad one. >>>>> #2 is removal from Web UI perspective. >>>>> >>>>> I would do #3 with some changes. In both Web UI and CLI there >>>>> should be >>>>> clear label that the section/options are deprecated. We may >>>>> introduce a >>>>> deprecated flag. With this change we don't have to show the >>>>> warning. But >>>>> in CLI we might because user didn't had to read help beforehand. >>>> >>>> It has been deprecated for quite a while now. This was raised >>>> because we >>>> let users enter this data via the UI and CLI and it does absolutely >>>> nothing which is terribly misleading. >>>> >>>> I think that it should be removed from the UI completely. I'm torn with >>>> the CLI, though leaning on hiding the options. >>> >>> Removing it from UI and hiding it in CLI might work for users. I assume >>> that it will break scripts which are using CLI ('error: no such >>> option:'). API based scripts will continue to work. >>> >>> Do we want to break CLI-based scripts and keep compatibility with >>> API-based ones? >>> >>>> >>>> It might be worthwhile to also raise an exception if anyone tries to >>>> use >>>> it via a script or otherwise. >>> >>> Wouldn't removing the options raise an exception as well? I don't see a >>> point in keeping them when it will always raise an exception. >> >> You seem to be following my line of reasoning: if we remove the >> options it is going to break CLI-based scripts. If we don't remove >> them then we need to raise an exception. >> >> Or we do some odd combination of both, depending on what our goal is. >> >> I would normally argue against removing a command-line option but >> given that these literally don't do anything now, I'm actually leaning >> towards removing them. >> >> For those using the API directly then yeah, we probably want to raise >> an exception to be absolutely clear, "don't do it." >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Can we just ignore the option and warn if we encounter it? > What is the harm of ignoring is it already does not do anything? > But it also would not break anyone. > Would that be better? > We basically ignore it now. The downside is it leaves the impression that you are limiting the rule by source host, which it isn't. rob From pspacek at redhat.com Mon Apr 8 17:42:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Apr 2013 19:42:49 +0200 Subject: [Freeipa-devel] [PATCH 0140] Fix crash caused by zone deletion Message-ID: <51630199.3030006@redhat.com> Hello, Fix crash caused by zone deletion. I found that that I pushed patch bind-dyndb-ldap-pspacek-0126-Add-support-for-pure-forward-zones-idnsForwardZone-o.patch instead of bind-dyndb-ldap-pspacek-0126-2-Add-support-for-pure-forward-zones-idnsForwardZone-o.patch Attached patch is only diff between mentioned versions. Pushed to master: f477d82bcd0ba53ac6f813910ad24919f4edb34a -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0140-Fix-crash-caused-by-zone-deletion.patch Type: text/x-patch Size: 908 bytes Desc: not available URL: From pspacek at redhat.com Mon Apr 8 17:45:06 2013 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Apr 2013 19:45:06 +0200 Subject: [Freeipa-devel] [PATCH 0141] Generalize attribute_name<->rdata_type conversions. Message-ID: <51630222.3010807@redhat.com> Hello, Generalize attribute_name<->rdata_type conversions. Attribute names are generated on-the-fly: String "Record" is appended to textual representation of DNS RDATA type. String "Record" is cut down from the attribute name during attribute name to rdata type conversion. From now, the plugin doesn't add artificial limitation to supported record types. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0141-Generalize-attribute_name-rdata_type-conversions.patch Type: text/x-patch Size: 8009 bytes Desc: not available URL: From dpal at redhat.com Mon Apr 8 19:49:39 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Apr 2013 15:49:39 -0400 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <5162FEAC.2010201@redhat.com> References: <515F1100.5000603@redhat.com> <5162769D.2060202@redhat.com> <5162C013.5030708@redhat.com> <5162C759.8050003@redhat.com> <5162C810.7060109@redhat.com> <5162D1D8.2090609@redhat.com> <5162FEAC.2010201@redhat.com> Message-ID: <51631F53.9080801@redhat.com> On 04/08/2013 01:30 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 04/08/2013 09:37 AM, Rob Crittenden wrote: >>> Petr Vobornik wrote: >>>> On 04/08/2013 03:03 PM, Rob Crittenden wrote: >>>>> Petr Vobornik wrote: >>>>>> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: >>>>>>> Hello list, >>>>>>> >>>>>>> I have been thinking about the possible implementation for a >>>>>>> solution of >>>>>>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are >>>>>>> several >>>>>>> options: >>>>>>> >>>>>>> 1. Completely remove the commands and command options related to >>>>>>> source >>>>>>> hosts in HBAC. This might not be a good idea as it could cause >>>>>>> problems >>>>>>> for older clients. >>>>>>> >>>>>>> 2. Hide these commands/options from the web UI, but leave them in >>>>>>> CLI. >>>>>>> This would keep the API intact, but I don't like the idea of >>>>>>> introducing >>>>>>> inconsistencies between CLI and web UI. >>>>>>> >>>>>>> 3. Do not remove anything, but issue deprecation warnings. The user >>>>>>> will >>>>>>> see a warning when using these commands/options, but everything >>>>>>> will >>>>>>> still work. >>>>>>> >>>>>>> 4. Do not remove anything, but raise exceptions. This would >>>>>>> effectively >>>>>>> prevent the user from using these commands/options, as the >>>>>>> exception >>>>>>> will break the execution of a command. >>>>>>> >>>>>>> In any case, any reference to source hosts should be removed from >>>>>>> help >>>>>>> and documentation. >>>>>>> >>>>>>> I am leaning towards options 3 or 4. >>>>>>> >>>>>>> Thoughts, comments and ideas are welcome. >>>>>>> >>>>>> >>>>>> IMHO the main question is whether we want to deprecate it or remove >>>>>> it. >>>>>> SSSD is deprecating it so I would go that way too. >>>>>> >>>>>> #1 and #4 are basically a removal, #4 a bad one. >>>>>> #2 is removal from Web UI perspective. >>>>>> >>>>>> I would do #3 with some changes. In both Web UI and CLI there >>>>>> should be >>>>>> clear label that the section/options are deprecated. We may >>>>>> introduce a >>>>>> deprecated flag. With this change we don't have to show the >>>>>> warning. But >>>>>> in CLI we might because user didn't had to read help beforehand. >>>>> >>>>> It has been deprecated for quite a while now. This was raised >>>>> because we >>>>> let users enter this data via the UI and CLI and it does absolutely >>>>> nothing which is terribly misleading. >>>>> >>>>> I think that it should be removed from the UI completely. I'm torn >>>>> with >>>>> the CLI, though leaning on hiding the options. >>>> >>>> Removing it from UI and hiding it in CLI might work for users. I >>>> assume >>>> that it will break scripts which are using CLI ('error: no such >>>> option:'). API based scripts will continue to work. >>>> >>>> Do we want to break CLI-based scripts and keep compatibility with >>>> API-based ones? >>>> >>>>> >>>>> It might be worthwhile to also raise an exception if anyone tries to >>>>> use >>>>> it via a script or otherwise. >>>> >>>> Wouldn't removing the options raise an exception as well? I don't >>>> see a >>>> point in keeping them when it will always raise an exception. >>> >>> You seem to be following my line of reasoning: if we remove the >>> options it is going to break CLI-based scripts. If we don't remove >>> them then we need to raise an exception. >>> >>> Or we do some odd combination of both, depending on what our goal is. >>> >>> I would normally argue against removing a command-line option but >>> given that these literally don't do anything now, I'm actually leaning >>> towards removing them. >>> >>> For those using the API directly then yeah, we probably want to raise >>> an exception to be absolutely clear, "don't do it." >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Can we just ignore the option and warn if we encounter it? >> What is the harm of ignoring is it already does not do anything? >> But it also would not break anyone. >> Would that be better? >> > > We basically ignore it now. The downside is it leaves the impression > that you are limiting the rule by source host, which it isn't. > > rob IMO if we add a warning when you try to add, modify or view it (everything other than remove it) we would give admin enough hints without breaking his scripts. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Apr 8 21:41:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Apr 2013 17:41:56 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <5162C8BD.9080409@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5162C8BD.9080409@redhat.com> Message-ID: <516339A4.8080405@redhat.com> Petr Viktorin wrote: > On 04/05/2013 10:54 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>>>> There are strict limits on what can be restored where. Only exact >>>>>>> matching hostnames and versions are allowed right now. We can >>>>>>> probably >>>>>>> relax the hostname requirement if we're only restoring data, and the >>>>>>> version perhaps for only the the first two values (so you can >>>>>>> restore a >>>>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>>>> >>>>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>>>> Or is what they put in /var/lib guaranteed portable across versions? >>>>> >>>>> An interesting question. I'd imagine that a major db change would also >>>>> require a major update to IPA, therefore if we restrict by IPA version >>>>> we should be ok. I AM doing an untar of files though so yeah, there >>>>> is a >>>>> risk here. >>>>> >>>>>> >>>>>> >>>>>> That's good to hear! >>>>>> >>>>>> I think while developing, you should run with -v to get all the >>>>>> output. >>>>>> And for production, please have the commands log by default (set >>>>>> log_file_name). >>>>> >>>>> Yes, I plan on adding that in the future. >>>>> >>>>>> >>>>>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>>>>> password because we need to contact remote servers to enable/disable >>>>>>> replication. >>>>>> >>>>>> The restore assumes that ipa is already installed, right? I can't >>>>>> just >>>>>> run it on a clean machine? Id would be good to check/document this. >>>>> >>>>> It depends. >>>>> >>>>> For a full backup you can actually restore to an uninstalled >>>>> server. In >>>>> fact, you could restore to a machine w/no IPA bits on it at all in all >>>>> likelihood (which wouldn't be very nice, but not exactly wrong either >>>>> IMHO). >>>>> >>>>> I tested this with: >>>>> - ipa-server-install >>>>> - ipa-backup >>>>> - ipa-server-install --uninstall -U >>>>> - ipa-restore >>>>> - ran the unit tests >>>>> >>>>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>>>> directories. Are these needed? >>>>> >>>>> Probably not. I gathered some of the files to backup based on watching >>>>> what files that changed during an install that are independent of us. >>>>> I'll take another pass through it, there may be other oddities too. >>>>> >>>>>> The tool runners (install/tools/ipa-backup and >>>>>> install/tools/ipa-restore) are missing, so IPA doesn't build. >>>>>> Probably >>>>>> just a forgotten git add. >>>>> >>>>> Yup. >>>>> >>>>>> >>>>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>>>> consider adding $(NULL) at the end. >>>>> >>>>> I'll take a look. >>>>> >>>>>> >>>>>> Backup.dirs, Backup.files, Backup.logs: >>>>>> The code modifies these class-level attributes. This means you can't >>>>>> run >>>>>> the command more than once in one Python session, so it can't be >>>>>> used as >>>>>> a library (e.g. in a hypothetical test suite). >>>>>> Please make the class atrributes immutable (tuples), then in >>>>>> __init__ do >>>>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>>>> >>>>> Ok, fair point. >>>>> >>>>>> Code that creates temporary files/directories or does chdir() >>>>>> should be >>>>>> next to (or in) a try block whose finally: restores things. >>>>> >>>>> Yes, I mean to add a big try/finally block around everything in run >>>>> eventually (or the equivalent anyway). >>>>> >>>>>> >>>>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>>>> please explicitly import whatever you're using from that package. In >>>>>> this case, nothing at all! >>>>> >>>>> Yeah, I haven't run this through pylint yet to see all the bad >>>>> imports I >>>>> cobbled together. >>>>> >>>>>> If there's a get_connection() method, it should return the >>>>>> connection, >>>>>> and it should always be used to get it. Store the connection in >>>>>> self._conn, and rather than: >>>>>> self.get_connection() >>>>>> self.conn.do_work() >>>>>> do: >>>>>> conn = self.get_connection() >>>>>> conn.do_work() >>>>>> This makes forgetting to call get_connection() impossible. >>>>> >>>>> My purpose was to avoid creating multiple connections. >>>>> >>>>>> If a variable is only used in a single method, like `filename` in >>>>>> Restore.extract_backup, don't store it in the admintool object. >>>>>> In general, try to avoid putting data in self if possible. It's >>>>>> convenient but it allows complex interdependencies. >>>>>> (Yes, I'm guilty of not following this myself.) >>>>> >>>>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a >>>>> rush >>>>> to get this WIP out. >>>>> >>>>>> In several places, the backup tool logs critical errors and then just >>>>>> continues on. Is that by design? I think a nonzero exit code would be >>>>>> appropriate. >>>>> >>>>> I'll take a look at them, all I can say at this point is maybe. >>>>> >>>>>> In the ipa-restore man page, --backend is not documented. >>>>>> >>>>>> In db2ldif, db2bak, etc., a more conscise way to get the time >>>>>> string is >>>>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>>>> >>>>>> When validating --gpg-keyring, it would be good to check both files >>>>>> (.sec and .pub). >>>>> >>>>> Ok, I can do those. >>>>> >>>>>> >>>>>> Here: >>>>>> if (self.backup_type != 'FULL' and not options.data_only and >>>>>> not instances): >>>>>> raise admintool.ScriptError('Cannot restore a data backup >>>>>> into >>>>>> an empty system') >>>>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and >>>>>> not >>>>>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >>>>> >>>>> Yeah, looks like that should be an or. >>>>> >>>>>> In the ReplicationManager.check_repl_init reporting: use >>>>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>>>> include full days. I don't think anyone would wait long enough for >>>>>> the >>>>>> overflow, but better to be correct. >>>>> >>>>> Sure, I doubt anyone would wait 24 hours either but its a >>>>> no-brainer to >>>>> make it safe. >>>> >>>> I think I've addressed just about everything. >>>> >>>> The reason that /var/run/dirsrv and var/lock/dirsrv are included in the >>>> backup is for the case of a full restore. These directories are not >>>> created/provided by the package itself, but by installing the first >>>> instance, so we need the ownership/SELinux context preserved. >>>> >>>> One thing I need tested is restoring over top of new data with multiple >>>> replicas. So basically install, do a backup, add a bunch of data, >>>> restore, re-initialize all the other masters and then confirm that ALL >>>> the new data is gone. I think I've got the sequence right but this is >>>> critical. >>>> >>>> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >>>> 9/multi-instance DS configurations). >>>> >>>> One thing I tested was: >>>> >>>> - ipa-server-install >>>> - ipa-backup >>>> - ipa-server-install --uninstall -U >>>> - ipa-restore ipa-full-... >>>> >>>> This will actually get your server back EXCEPT that dogtag won't start. >>>> This is because the log directories are created by the instance >>>> creation. There are two solutions: backup with --logs or manually >>>> re-create the log directories (there are several, depending on dogtag >>>> version). >>> >>> Could backup without --logs save which directories are there, and >>> restore create empty directories if they don't exist? To me >>> re-initializing a completely wiped machine looks like a big gain for the >>> extra effort. >> >> I went ahead and made this change, it wasn't a lot of work. >> >>> >>> >>> >>> The spec changelog needs a small rebase. >> >> Done. >> >>> >>> I've tested some scenarios and didn't find any other issues so far. >>> >>> I still want to test some more with upgraded masters; installing them >>> takes some time. >>> Also I still need to test CA replicas (with the DNAME patches removed). >>> >> >> rob > > I've tested some more. It works well with 3.2 masters, even one upgraded > from 2.2. > > When there's a 2.2 master in the topology, things are not so nice. When > I ran ipa-replica-manage re-initialize, it started printing "update in > progress" lines for several minutes with no signs of stopping. > The following appeared in the slapd error log on the source server: > > [08/Apr/2013:13:38:48 +0200] NSMMReplicationPlugin - Replication > agreement for agmt="cn=meTovm-084.idm.lab.eng.brq.redhat.com" > (vm-084:389) could not be updated. For replication to take place, please > enable the suffix and restart the server > > I somehow doubt that's caused by this patch, though -- was replica > re-initialize tested with disparate versions recently? > I can test again with a simpler scenario to pinpoint the issue. > Not sure if we've done any specific testing of this, but this API has been very stable throughout IPA (much of it dates back to v1). Similarly in 389-ds where this is used this stuff has been fairly stable. I did some very basic testing with a 6.3 and 6.4 server and didn't have any issues, so I'm very interested to know what you discover. rob From pviktori at redhat.com Tue Apr 9 10:22:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 09 Apr 2013 12:22:42 +0200 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <515F3A16.9050500@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> Message-ID: <5163EBF2.8080004@redhat.com> On 04/05/2013 10:54 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>>> There are strict limits on what can be restored where. Only exact >>>>>> matching hostnames and versions are allowed right now. We can >>>>>> probably >>>>>> relax the hostname requirement if we're only restoring data, and the >>>>>> version perhaps for only the the first two values (so you can >>>>>> restore a >>>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>>> >>>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>>> Or is what they put in /var/lib guaranteed portable across versions? >>>> >>>> An interesting question. I'd imagine that a major db change would also >>>> require a major update to IPA, therefore if we restrict by IPA version >>>> we should be ok. I AM doing an untar of files though so yeah, there >>>> is a >>>> risk here. >>>> >>>>> >>>>> >>>>> That's good to hear! >>>>> >>>>> I think while developing, you should run with -v to get all the >>>>> output. >>>>> And for production, please have the commands log by default (set >>>>> log_file_name). >>>> >>>> Yes, I plan on adding that in the future. >>>> >>>>> >>>>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>>>> password because we need to contact remote servers to enable/disable >>>>>> replication. >>>>> >>>>> The restore assumes that ipa is already installed, right? I can't just >>>>> run it on a clean machine? Id would be good to check/document this. >>>> >>>> It depends. >>>> >>>> For a full backup you can actually restore to an uninstalled server. In >>>> fact, you could restore to a machine w/no IPA bits on it at all in all >>>> likelihood (which wouldn't be very nice, but not exactly wrong either >>>> IMHO). >>>> >>>> I tested this with: >>>> - ipa-server-install >>>> - ipa-backup >>>> - ipa-server-install --uninstall -U >>>> - ipa-restore >>>> - ran the unit tests >>>> >>>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>>> directories. Are these needed? >>>> >>>> Probably not. I gathered some of the files to backup based on watching >>>> what files that changed during an install that are independent of us. >>>> I'll take another pass through it, there may be other oddities too. >>>> >>>>> The tool runners (install/tools/ipa-backup and >>>>> install/tools/ipa-restore) are missing, so IPA doesn't build. Probably >>>>> just a forgotten git add. >>>> >>>> Yup. >>>> >>>>> >>>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>>> consider adding $(NULL) at the end. >>>> >>>> I'll take a look. >>>> >>>>> >>>>> Backup.dirs, Backup.files, Backup.logs: >>>>> The code modifies these class-level attributes. This means you can't >>>>> run >>>>> the command more than once in one Python session, so it can't be >>>>> used as >>>>> a library (e.g. in a hypothetical test suite). >>>>> Please make the class atrributes immutable (tuples), then in >>>>> __init__ do >>>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>>> >>>> Ok, fair point. >>>> >>>>> Code that creates temporary files/directories or does chdir() >>>>> should be >>>>> next to (or in) a try block whose finally: restores things. >>>> >>>> Yes, I mean to add a big try/finally block around everything in run >>>> eventually (or the equivalent anyway). >>>> >>>>> >>>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>>> please explicitly import whatever you're using from that package. In >>>>> this case, nothing at all! >>>> >>>> Yeah, I haven't run this through pylint yet to see all the bad >>>> imports I >>>> cobbled together. >>>> >>>>> If there's a get_connection() method, it should return the connection, >>>>> and it should always be used to get it. Store the connection in >>>>> self._conn, and rather than: >>>>> self.get_connection() >>>>> self.conn.do_work() >>>>> do: >>>>> conn = self.get_connection() >>>>> conn.do_work() >>>>> This makes forgetting to call get_connection() impossible. >>>> >>>> My purpose was to avoid creating multiple connections. >>>> >>>>> If a variable is only used in a single method, like `filename` in >>>>> Restore.extract_backup, don't store it in the admintool object. >>>>> In general, try to avoid putting data in self if possible. It's >>>>> convenient but it allows complex interdependencies. >>>>> (Yes, I'm guilty of not following this myself.) >>>> >>>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a >>>> rush >>>> to get this WIP out. >>>> >>>>> In several places, the backup tool logs critical errors and then just >>>>> continues on. Is that by design? I think a nonzero exit code would be >>>>> appropriate. >>>> >>>> I'll take a look at them, all I can say at this point is maybe. >>>> >>>>> In the ipa-restore man page, --backend is not documented. >>>>> >>>>> In db2ldif, db2bak, etc., a more conscise way to get the time >>>>> string is >>>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>>> >>>>> When validating --gpg-keyring, it would be good to check both files >>>>> (.sec and .pub). >>>> >>>> Ok, I can do those. >>>> >>>>> >>>>> Here: >>>>> if (self.backup_type != 'FULL' and not options.data_only and >>>>> not instances): >>>>> raise admintool.ScriptError('Cannot restore a data backup >>>>> into >>>>> an empty system') >>>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and >>>>> not >>>>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >>>> >>>> Yeah, looks like that should be an or. >>>> >>>>> In the ReplicationManager.check_repl_init reporting: use >>>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>>> include full days. I don't think anyone would wait long enough for the >>>>> overflow, but better to be correct. >>>> >>>> Sure, I doubt anyone would wait 24 hours either but its a no-brainer to >>>> make it safe. >>> >>> I think I've addressed just about everything. >>> >>> The reason that /var/run/dirsrv and var/lock/dirsrv are included in the >>> backup is for the case of a full restore. These directories are not >>> created/provided by the package itself, but by installing the first >>> instance, so we need the ownership/SELinux context preserved. >>> >>> One thing I need tested is restoring over top of new data with multiple >>> replicas. So basically install, do a backup, add a bunch of data, >>> restore, re-initialize all the other masters and then confirm that ALL >>> the new data is gone. I think I've got the sequence right but this is >>> critical. >>> >>> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >>> 9/multi-instance DS configurations). >>> >>> One thing I tested was: >>> >>> - ipa-server-install >>> - ipa-backup >>> - ipa-server-install --uninstall -U >>> - ipa-restore ipa-full-... >>> >>> This will actually get your server back EXCEPT that dogtag won't start. >>> This is because the log directories are created by the instance >>> creation. There are two solutions: backup with --logs or manually >>> re-create the log directories (there are several, depending on dogtag >>> version). >> >> Could backup without --logs save which directories are there, and >> restore create empty directories if they don't exist? To me >> re-initializing a completely wiped machine looks like a big gain for the >> extra effort. > > I went ahead and made this change, it wasn't a lot of work. > >> >> >> >> The spec changelog needs a small rebase. > > Done. > >> >> I've tested some scenarios and didn't find any other issues so far. >> >> I still want to test some more with upgraded masters; installing them >> takes some time. >> Also I still need to test CA replicas (with the DNAME patches removed). >> > > rob I found a bug with the following topology: [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] Running ipa-restore on the 3.2 instance tries to disable the CA replication agreement between the other two. However, deep in ReplicationManager.agreement_dn it uses its own DS instance name instead of the Dogtag-9-DS one, so the agreement isn't found and the restore fails. -- Petr? From tbabej at redhat.com Tue Apr 9 11:54:36 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 09 Apr 2013 13:54:36 +0200 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage Message-ID: <5164017C.1000101@redhat.com> Hi, In ipa-replica-manage commands, we enforce that hostnames we work with are resolvable. However, this caused errors while deleting or disconnecting a ipa / winsync replica, if that replica was down and authoritative server for itself. https://fedorahosted.org/freeipa/ticket/3524 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0045-Enforce-host-existence-only-where-needed-in-ipa-repl.patch Type: text/x-patch Size: 2712 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 9 13:27:28 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 09 Apr 2013 15:27:28 +0200 Subject: [Freeipa-devel] [PATCH 0142] Improve LDAP error logging Message-ID: <51641740.5040601@redhat.com> Hello, Improve LDAP error logging. Diagnostic error message is logged when it is available. Plugin with this patch produces messages like: LDAP error: Server is unwilling to perform: Minimum SSF not met.: bind to LDAP server failed intead of bind to LDAP server failed: Server is unwilling to perform Second example is: LDAP error: Object class violation: attribute "mgrecord" not allowed : while modifying(add) entry 'idnsName=pspacek, idnsname=example.com,cn=dns,dc=e,dc=test' instead of "" :-D -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0142-Improve-LDAP-error-logging.patch Type: text/x-patch Size: 4023 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 9 13:39:49 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 09 Apr 2013 15:39:49 +0200 Subject: [Freeipa-devel] [PATCH 0143] Treat syntax errors in LDAP filters as fatal Message-ID: <51641A25.4040805@redhat.com> Hello, Treat syntax errors in LDAP filters as fatal. Filters are hardcoded at the moment, this is preventive action. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0143-Treat-syntax-errors-in-LDAP-filters-as-fatal.patch Type: text/x-patch Size: 941 bytes Desc: not available URL: From jcholast at redhat.com Tue Apr 9 13:52:49 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 09 Apr 2013 15:52:49 +0200 Subject: [Freeipa-devel] [PATCH] 125 Do actually stop pki_cad in stop_pkicad instead of starting it Message-ID: <51641D31.90904@redhat.com> Hi, this patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-125-Do-actually-stop-pki_cad-in-stop_pkicad-instead-of-s.patch Type: text/x-patch Size: 1154 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 9 14:02:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Apr 2013 16:02:18 +0200 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <5162DD99.2030403@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> Message-ID: <51641F6A.6030500@redhat.com> On 04/08/2013 05:09 PM, Martin Kosek wrote: > On 04/08/2013 03:47 PM, Dmitri Pal wrote: >> On 04/08/2013 08:42 AM, Martin Kosek wrote: >>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: >>>> On 8.4.2013 10:47, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> this patch fixes . >>>>> >>>>> Honza >>>>> >>>> Re-sending with correct subject. >>>> >>> I tested the change both for upgrades and for fresh installs and it worked fine >>> both cases, even when testing with Firefox enforcing mode. >>> >>> So far, as the biggest issue in current process I see NSS not being able to >>> fallback to other defined OCSP responder (I tested with Firefox 20). This way, >>> Firefox will fail validating the FreeIPA site when the first tested OCSP >>> responder is not available (e.g. the original IPA CA signing the http cert, or >>> an `ipa-ca.$domain` host that is currently not up). >> >> Have we filed a ticket with FF? > > AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: > https://bugzilla.mozilla.org/show_bug.cgi?id=797815 > > Rob seems to have more context about this bug background. > > Martin > We may want to wait with pushing this patch until we get some response in the NSS Bugzilla above. If our request is rejected, we may be forced to use just a single CRL/OCSP (which would be probably the general one) and thus supersede patch 123. Martin From simo at redhat.com Tue Apr 9 14:19:23 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 09 Apr 2013 10:19:23 -0400 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <51641F6A.6030500@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> <51641F6A.6030500@redhat.com> Message-ID: <1365517163.20560.32.camel@willson.li.ssimo.org> On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote: > On 04/08/2013 05:09 PM, Martin Kosek wrote: > > On 04/08/2013 03:47 PM, Dmitri Pal wrote: > >> On 04/08/2013 08:42 AM, Martin Kosek wrote: > >>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: > >>>> On 8.4.2013 10:47, Jan Cholasta wrote: > >>>>> Hi, > >>>>> > >>>>> this patch fixes . > >>>>> > >>>>> Honza > >>>>> > >>>> Re-sending with correct subject. > >>>> > >>> I tested the change both for upgrades and for fresh installs and it worked fine > >>> both cases, even when testing with Firefox enforcing mode. > >>> > >>> So far, as the biggest issue in current process I see NSS not being able to > >>> fallback to other defined OCSP responder (I tested with Firefox 20). This way, > >>> Firefox will fail validating the FreeIPA site when the first tested OCSP > >>> responder is not available (e.g. the original IPA CA signing the http cert, or > >>> an `ipa-ca.$domain` host that is currently not up). > >> > >> Have we filed a ticket with FF? > > > > AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: > > https://bugzilla.mozilla.org/show_bug.cgi?id=797815 > > > > Rob seems to have more context about this bug background. > > > > Martin > > > > We may want to wait with pushing this patch until we get some response in the > NSS Bugzilla above. If our request is rejected, we may be forced to use just a > single CRL/OCSP (which would be probably the general one) and thus supersede > patch 123. Well it will have to depend on when you create certs. The first IPA server own cert should probably point at the ipa server name. Then we should warn in bold letters that the user should create such and such a DNS name if they did not let IPA handle DNS. If we can handle DNS then any other use can refer to the common name which can be an A name with multiple entries (each IPA CA server should be listed there by default and the record should be changed at ca replicas install/decommission time, however we should allow admins to add/remove names as well manually in case they want to add proxies otr conceal some of the CA servers. We may also want to change the RA client code to use that record to fetch certs. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Apr 9 14:23:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Apr 2013 16:23:28 +0200 Subject: [Freeipa-devel] [PATCH] 125 Do actually stop pki_cad in stop_pkicad instead of starting it In-Reply-To: <51641D31.90904@redhat.com> References: <51641D31.90904@redhat.com> Message-ID: <51642460.7070006@redhat.com> On 04/09/2013 03:52 PM, Jan Cholasta wrote: > Hi, > > this patch fixes . > > Honza > Yeah, this does much better job at stopping pki-ca... ACK. Pushed to master, ipa-3-1. Martin From pvoborni at redhat.com Tue Apr 9 14:38:14 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Apr 2013 16:38:14 +0200 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <515D4FAC.2030705@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> <514C64B4.1020004@redhat.com> <515D4C86.6070305@redhat.com> <515D4FAC.2030705@redhat.com> Message-ID: <516427D6.2070500@redhat.com> On 04/04/2013 12:02 PM, Martin Kosek wrote: > On 04/04/2013 11:48 AM, Tomas Babej wrote: >> On 03/22/2013 03:03 PM, Martin Kosek wrote: >>> On 03/21/2013 06:10 PM, Petr Vobornik wrote: >>>> On 03/21/2013 05:10 PM, Martin Kosek wrote: >>>>> On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: >>>>>> On 3/12/2013 11:28 AM, Petr Vobornik wrote: >>>>>>> Here's a patch for filtering groups by type. >>>>>>> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >>>>>>> >>>>>>> The interface is: >>>>>>>> StrEnum('type?', >>>>>>>> cli_name='type', >>>>>>>> label=_('Type'), >>>>>>>> doc=_('Group type'), >>>>>>>> values=(u'posix', u'normal', u'external'), >>>>>>>> ), >>>>>>> I have two design questions. >>>>>>> 1. Is --type the right option name? >>>>>> Fine by me, it matches the label and description. >>>>>> >>>>>>> 2. Is `normal` the right name for non-posix, non-external group? The >>>>>>> default group type (when adding group) is posix. Should the name be >>>>>>> something else: `simple`, `plain`, `ordinary`? >>>>>> We also use 'normal' in the group adder dialog, so it's consistent. Other >>>>>> options are 'basic', 'standard', 'regular'. >>>>>> >>>>>>> I didn't want to create an option for each type. IMO it brings more >>>>>>> complexity. >>>>>> Maybe the group-add/mod command should use the same --type option? >>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3483 >>>>>> ACK from me, but maybe others might have some comments. >>>>>> >>>>> I am just thinking about if the new API is right. For example, when we add an >>>>> external group, we use ipa group-add --external. But when we search for >>>>> external groups, we suddenly use >>>>> # ipa group-find --type=external >>>>> and not >>>>> # ipa group-find --external >>>>> or >>>>> # ipa group-find --nonposix >>>>> >>>>> Wouldn't that cause confusion? I am looking for same second opinion on this >>>>> one. >>>>> >>>>> I also did not like "normal" group type very much, maybe we should just >>>>> call it >>>>> "nonposix"? As that's the option you use when you are creating such group: >>>>> # ipa group-add --nonposix foo >>>>> >>>>> Otherwise, the patch looks good functionally. >>>>> >>>>> Martin >>>>> >>>> I have to note that external group is also non-posix. Following command is >>>> valid: >>>> # ipa group-add foo --desc=a --external --nonposix >>>> >>>> By that logic >>>> # ipa group-find --nonposix >>>> >>>> Would also list external groups. >>>> >>>> I fine with renaming 'normal' to something better (will also require Web UI >>>> change), but it is not 'nonposix'. >>> I think this logic is flawed as well. Then you could say that posix group is >>> also nonposix, because it contains the same objectclasses as nonpoxis group + >>> posixGroup objectclass. >>> >>> "nonposix" is the term we already use (see --nonposix), not something >>> artificial or new, so I would not be afraid of it. >>> >>> Martin >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> Let us try to move on with this, here are my 2 cents: >> >> 1.) normal is not a suitable name for non-posix, non-external group. As a user, >> I would assume that >> # ipa group-find --type=normal >> >> would return the groups that I created using simple >> # ipa group-add testgroup >> >> command. By that logic, any other suggested synonym implying there's nothing >> special about this >> group is not suitable. >> >> 2.) If not normal (or any other synonym implying there's nothing special about >> this group) then what? >> We can either: >> - use exact but complicated --non-posix-non-external >> - use --nonposix and deal with the fact that sets defined by the type are not >> disjunct >> - make up our own new term and define it >> >> While none of these options are fortunate, let's look for the least resistance: >> - exact, but complicated names are ugly and do not keep interface simple >> - nonposix groups are superset of external groups >> - confuses the user and makes the learning curve steeper >> >> From this I would go for option 2, indeed, if you think about --nonposix / >> --external as flags, where >> the external takes priority before nonposix, this kind of makes sense. If the >> user does not think >> about the implementation (that every external group is nonposix), he may indeed >> find himself in this mindset. >> >> 3.) I'm fine both with --type=external and --external approaches. The latterr >> is more consistent with the way we do things, >> *-find commands search mainly on selected subset of attributes, so using the >> flag analogy I mentioned an paragraph ago, >> you would expect --external to behave as an attribute, especially if group-add >> command accepts it in this form. >> >> Having 3 options instead of one will clutter things a bit more, but if we keep >> them in the same place (in the list of options) >> it should not cause much confusion, more so if the descriptions would be nearly >> the same, one would quickly see that these >> belong together. >> >> Tomas >> > > Thanks Tomas for your opinion, I can agree with that. To make it more in an > actual design, this is API following this discussion that I would propose: > > This is API we already have in IPA: > ipa group-add --external > ipa group-add --nonposix > ipa group-find --private > > This is API that I would propose to add to be consistent with what we already have: > ipa group-find --nonposix > ipa group-find --posix > ipa group-find --external > > --nonposix would only match groups added with --nonposix flag in group-add, > i.e. no --external groups. > > As Tomas said, these should also be close together. We can even add a specific > option group for them, like there are with ipa dnsrecord-add, named for example > "Group Types". We may also raise OptionError when these option are used > together to make this less confusing - e.g. OptionError("group type options > (--nonposix, --posix and --external) are mutually exclusive"). > > Martin > New version attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0267-1-Filter-groups-by-type-POSIX-non-POSIX-external.patch Type: text/x-patch Size: 11759 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 9 15:06:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Apr 2013 17:06:38 +0200 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <516427D6.2070500@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> <514C64B4.1020004@redhat.com> <515D4C86.6070305@redhat.com> <515D4FAC.2030705@redhat.com> <516427D6.2070500@redhat.com> Message-ID: <51642E7E.9070203@redhat.com> On 04/09/2013 04:38 PM, Petr Vobornik wrote: > On 04/04/2013 12:02 PM, Martin Kosek wrote: >> On 04/04/2013 11:48 AM, Tomas Babej wrote: >>> On 03/22/2013 03:03 PM, Martin Kosek wrote: >>>> On 03/21/2013 06:10 PM, Petr Vobornik wrote: >>>>> On 03/21/2013 05:10 PM, Martin Kosek wrote: >>>>>> On 03/16/2013 03:32 AM, Endi Sukma Dewata wrote: >>>>>>> On 3/12/2013 11:28 AM, Petr Vobornik wrote: >>>>>>>> Here's a patch for filtering groups by type. >>>>>>>> Design page: http://www.freeipa.org/page/V3/Filtering_groups_by_type >>>>>>>> >>>>>>>> The interface is: >>>>>>>>> StrEnum('type?', >>>>>>>>> cli_name='type', >>>>>>>>> label=_('Type'), >>>>>>>>> doc=_('Group type'), >>>>>>>>> values=(u'posix', u'normal', u'external'), >>>>>>>>> ), >>>>>>>> I have two design questions. >>>>>>>> 1. Is --type the right option name? >>>>>>> Fine by me, it matches the label and description. >>>>>>> >>>>>>>> 2. Is `normal` the right name for non-posix, non-external group? The >>>>>>>> default group type (when adding group) is posix. Should the name be >>>>>>>> something else: `simple`, `plain`, `ordinary`? >>>>>>> We also use 'normal' in the group adder dialog, so it's consistent. Other >>>>>>> options are 'basic', 'standard', 'regular'. >>>>>>> >>>>>>>> I didn't want to create an option for each type. IMO it brings more >>>>>>>> complexity. >>>>>>> Maybe the group-add/mod command should use the same --type option? >>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3483 >>>>>>> ACK from me, but maybe others might have some comments. >>>>>>> >>>>>> I am just thinking about if the new API is right. For example, when we >>>>>> add an >>>>>> external group, we use ipa group-add --external. But when we search for >>>>>> external groups, we suddenly use >>>>>> # ipa group-find --type=external >>>>>> and not >>>>>> # ipa group-find --external >>>>>> or >>>>>> # ipa group-find --nonposix >>>>>> >>>>>> Wouldn't that cause confusion? I am looking for same second opinion on this >>>>>> one. >>>>>> >>>>>> I also did not like "normal" group type very much, maybe we should just >>>>>> call it >>>>>> "nonposix"? As that's the option you use when you are creating such group: >>>>>> # ipa group-add --nonposix foo >>>>>> >>>>>> Otherwise, the patch looks good functionally. >>>>>> >>>>>> Martin >>>>>> >>>>> I have to note that external group is also non-posix. Following command is >>>>> valid: >>>>> # ipa group-add foo --desc=a --external --nonposix >>>>> >>>>> By that logic >>>>> # ipa group-find --nonposix >>>>> >>>>> Would also list external groups. >>>>> >>>>> I fine with renaming 'normal' to something better (will also require Web UI >>>>> change), but it is not 'nonposix'. >>>> I think this logic is flawed as well. Then you could say that posix group is >>>> also nonposix, because it contains the same objectclasses as nonpoxis group + >>>> posixGroup objectclass. >>>> >>>> "nonposix" is the term we already use (see --nonposix), not something >>>> artificial or new, so I would not be afraid of it. >>>> >>>> Martin >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> Let us try to move on with this, here are my 2 cents: >>> >>> 1.) normal is not a suitable name for non-posix, non-external group. As a user, >>> I would assume that >>> # ipa group-find --type=normal >>> >>> would return the groups that I created using simple >>> # ipa group-add testgroup >>> >>> command. By that logic, any other suggested synonym implying there's nothing >>> special about this >>> group is not suitable. >>> >>> 2.) If not normal (or any other synonym implying there's nothing special about >>> this group) then what? >>> We can either: >>> - use exact but complicated --non-posix-non-external >>> - use --nonposix and deal with the fact that sets defined by the type are >>> not >>> disjunct >>> - make up our own new term and define it >>> >>> While none of these options are fortunate, let's look for the least resistance: >>> - exact, but complicated names are ugly and do not keep interface simple >>> - nonposix groups are superset of external groups >>> - confuses the user and makes the learning curve steeper >>> >>> From this I would go for option 2, indeed, if you think about --nonposix / >>> --external as flags, where >>> the external takes priority before nonposix, this kind of makes sense. If the >>> user does not think >>> about the implementation (that every external group is nonposix), he may indeed >>> find himself in this mindset. >>> >>> 3.) I'm fine both with --type=external and --external approaches. The latterr >>> is more consistent with the way we do things, >>> *-find commands search mainly on selected subset of attributes, so using the >>> flag analogy I mentioned an paragraph ago, >>> you would expect --external to behave as an attribute, especially if group-add >>> command accepts it in this form. >>> >>> Having 3 options instead of one will clutter things a bit more, but if we keep >>> them in the same place (in the list of options) >>> it should not cause much confusion, more so if the descriptions would be nearly >>> the same, one would quickly see that these >>> belong together. >>> >>> Tomas >>> >> >> Thanks Tomas for your opinion, I can agree with that. To make it more in an >> actual design, this is API following this discussion that I would propose: >> >> This is API we already have in IPA: >> ipa group-add --external >> ipa group-add --nonposix >> ipa group-find --private >> >> This is API that I would propose to add to be consistent with what we already >> have: >> ipa group-find --nonposix >> ipa group-find --posix >> ipa group-find --external >> >> --nonposix would only match groups added with --nonposix flag in group-add, >> i.e. no --external groups. >> >> As Tomas said, these should also be close together. We can even add a specific >> option group for them, like there are with ipa dnsrecord-add, named for example >> "Group Types". We may also raise OptionError when these option are used >> together to make this less confusing - e.g. OptionError("group type options >> (--nonposix, --posix and --external) are mutually exclusive"). >> >> Martin >> > New version attached. > 1) default=False parameter for Flag is redundant: + Flag('external', + cli_name='external', + doc=_('search for groups with support of external non-IPA members from trusted domains'), + default=False, + ), 2) No need to import StrEnum: +from ipalib import Int, Str, StrEnum 3) This can be simplified: + if len(filters): TO: + if filters: Besides these minor issues, that patch works fine and I think we can push a fixed version. Thanks, Martin From dpal at redhat.com Tue Apr 9 15:18:10 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 09 Apr 2013 11:18:10 -0400 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <1365517163.20560.32.camel@willson.li.ssimo.org> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> <51641F6A.6030500@redhat.com> <1365517163.20560.32.camel@willson.li.ssimo.org> Message-ID: <51643132.1030007@redhat.com> On 04/09/2013 10:19 AM, Simo Sorce wrote: > On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote: >> On 04/08/2013 05:09 PM, Martin Kosek wrote: >>> On 04/08/2013 03:47 PM, Dmitri Pal wrote: >>>> On 04/08/2013 08:42 AM, Martin Kosek wrote: >>>>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: >>>>>> On 8.4.2013 10:47, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this patch fixes . >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> Re-sending with correct subject. >>>>>> >>>>> I tested the change both for upgrades and for fresh installs and it worked fine >>>>> both cases, even when testing with Firefox enforcing mode. >>>>> >>>>> So far, as the biggest issue in current process I see NSS not being able to >>>>> fallback to other defined OCSP responder (I tested with Firefox 20). This way, >>>>> Firefox will fail validating the FreeIPA site when the first tested OCSP >>>>> responder is not available (e.g. the original IPA CA signing the http cert, or >>>>> an `ipa-ca.$domain` host that is currently not up). >>>> Have we filed a ticket with FF? >>> AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: >>> https://bugzilla.mozilla.org/show_bug.cgi?id=797815 >>> >>> Rob seems to have more context about this bug background. >>> >>> Martin >>> >> We may want to wait with pushing this patch until we get some response in the >> NSS Bugzilla above. If our request is rejected, we may be forced to use just a >> single CRL/OCSP (which would be probably the general one) and thus supersede >> patch 123. > Well it will have to depend on when you create certs. > The first IPA server own cert should probably point at the ipa server > name. Then we should warn in bold letters that the user should create > such and such a DNS name if they did not let IPA handle DNS. > > If we can handle DNS then any other use can refer to the common name > which can be an A name with multiple entries (each IPA CA server should > be listed there by default and the record should be changed at ca > replicas install/decommission time, however we should allow admins to > add/remove names as well manually in case they want to add proxies otr > conceal some of the CA servers. > > We may also want to change the RA client code to use that record to > fetch certs. > > Simo. > I see a lot of RFEs in this comment. Are we going to file them? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Apr 9 16:11:00 2013 From: simo at redhat.com (Simo Sorce) Date: Tue, 09 Apr 2013 12:11:00 -0400 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <51643132.1030007@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> <51641F6A.6030500@redhat.com> <1365517163.20560.32.camel@willson.li.ssimo.org> <51643132.1030007@redhat.com> Message-ID: <1365523860.20560.40.camel@willson.li.ssimo.org> On Tue, 2013-04-09 at 11:18 -0400, Dmitri Pal wrote: > On 04/09/2013 10:19 AM, Simo Sorce wrote: > > On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote: > >> On 04/08/2013 05:09 PM, Martin Kosek wrote: > >>> On 04/08/2013 03:47 PM, Dmitri Pal wrote: > >>>> On 04/08/2013 08:42 AM, Martin Kosek wrote: > >>>>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: > >>>>>> On 8.4.2013 10:47, Jan Cholasta wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> this patch fixes . > >>>>>>> > >>>>>>> Honza > >>>>>>> > >>>>>> Re-sending with correct subject. > >>>>>> > >>>>> I tested the change both for upgrades and for fresh installs and it worked fine > >>>>> both cases, even when testing with Firefox enforcing mode. > >>>>> > >>>>> So far, as the biggest issue in current process I see NSS not being able to > >>>>> fallback to other defined OCSP responder (I tested with Firefox 20). This way, > >>>>> Firefox will fail validating the FreeIPA site when the first tested OCSP > >>>>> responder is not available (e.g. the original IPA CA signing the http cert, or > >>>>> an `ipa-ca.$domain` host that is currently not up). > >>>> Have we filed a ticket with FF? > >>> AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: > >>> https://bugzilla.mozilla.org/show_bug.cgi?id=797815 > >>> > >>> Rob seems to have more context about this bug background. > >>> > >>> Martin > >>> > >> We may want to wait with pushing this patch until we get some response in the > >> NSS Bugzilla above. If our request is rejected, we may be forced to use just a > >> single CRL/OCSP (which would be probably the general one) and thus supersede > >> patch 123. > > Well it will have to depend on when you create certs. > > The first IPA server own cert should probably point at the ipa server > > name. Then we should warn in bold letters that the user should create > > such and such a DNS name if they did not let IPA handle DNS. > > > > If we can handle DNS then any other use can refer to the common name > > which can be an A name with multiple entries (each IPA CA server should > > be listed there by default and the record should be changed at ca > > replicas install/decommission time, however we should allow admins to > > add/remove names as well manually in case they want to add proxies otr > > conceal some of the CA servers. > > > > We may also want to change the RA client code to use that record to > > fetch certs. > > > > Simo. > > > I see a lot of RFEs in this comment. > Are we going to file them? We'll see how NSS is going to respond to the ticket, and then adjust accordingly. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Tue Apr 9 16:45:25 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 09 Apr 2013 18:45:25 +0200 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <51642E7E.9070203@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> <514C64B4.1020004@redhat.com> <515D4C86.6070305@redhat.com> <515D4FAC.2030705@redhat.com> <516427D6.2070500@redhat.com> <51642E7E.9070203@redhat.com> Message-ID: <516445A5.8000206@redhat.com> On 04/09/2013 05:06 PM, Martin Kosek wrote: > On 04/09/2013 04:38 PM, Petr Vobornik wrote: >> On 04/04/2013 12:02 PM, Martin Kosek wrote: >>> Thanks Tomas for your opinion, I can agree with that. To make it more in an >>> actual design, this is API following this discussion that I would propose: >>> >>> This is API we already have in IPA: >>> ipa group-add --external >>> ipa group-add --nonposix >>> ipa group-find --private >>> >>> This is API that I would propose to add to be consistent with what we already >>> have: >>> ipa group-find --nonposix >>> ipa group-find --posix >>> ipa group-find --external >>> >>> --nonposix would only match groups added with --nonposix flag in group-add, >>> i.e. no --external groups. >>> >>> As Tomas said, these should also be close together. We can even add a specific >>> option group for them, like there are with ipa dnsrecord-add, named for example >>> "Group Types". We may also raise OptionError when these option are used >>> together to make this less confusing - e.g. OptionError("group type options >>> (--nonposix, --posix and --external) are mutually exclusive"). >>> >>> Martin >>> >> New version attached. >> > > 1) default=False parameter for Flag is redundant: > > + Flag('external', > + cli_name='external', > + doc=_('search for groups with support of external non-IPA members > from trusted domains'), > + default=False, > + ), > > > 2) No need to import StrEnum: > +from ipalib import Int, Str, StrEnum > > 3) This can be simplified: > + if len(filters): > TO: > + if filters: > > > Besides these minor issues, that patch works fine and I think we can push a > fixed version. > > Thanks, > Martin > Additional self-nack. 4) original filter is ignored when some of the new options is used. It prevents from effective searching and also shows private groups when --posix is used. All fixed, new unit test added. New version attached. The fix doesn't touch usage of --private because it's a special case - private groups don't have ipausergroup oc and therefore they are incompatible with original filter. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0267-2-Filter-groups-by-type-POSIX-non-POSIX-external.patch Type: text/x-patch Size: 12108 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 9 17:03:23 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Apr 2013 19:03:23 +0200 Subject: [Freeipa-devel] [PATCH] 267 Filter groups by type (normal, posix, external) In-Reply-To: <516445A5.8000206@redhat.com> References: <513F57B9.9010405@redhat.com> <5143D9A7.3000803@redhat.com> <514B3109.2010307@redhat.com> <514B3F21.2030103@redhat.com> <514C64B4.1020004@redhat.com> <515D4C86.6070305@redhat.com> <515D4FAC.2030705@redhat.com> <516427D6.2070500@redhat.com> <51642E7E.9070203@redhat.com> <516445A5.8000206@redhat.com> Message-ID: <516449DB.2020106@redhat.com> On 04/09/2013 06:45 PM, Petr Vobornik wrote: > On 04/09/2013 05:06 PM, Martin Kosek wrote: >> On 04/09/2013 04:38 PM, Petr Vobornik wrote: >>> On 04/04/2013 12:02 PM, Martin Kosek wrote: >>>> Thanks Tomas for your opinion, I can agree with that. To make it more in an >>>> actual design, this is API following this discussion that I would propose: >>>> >>>> This is API we already have in IPA: >>>> ipa group-add --external >>>> ipa group-add --nonposix >>>> ipa group-find --private >>>> >>>> This is API that I would propose to add to be consistent with what we already >>>> have: >>>> ipa group-find --nonposix >>>> ipa group-find --posix >>>> ipa group-find --external >>>> >>>> --nonposix would only match groups added with --nonposix flag in group-add, >>>> i.e. no --external groups. >>>> >>>> As Tomas said, these should also be close together. We can even add a specific >>>> option group for them, like there are with ipa dnsrecord-add, named for >>>> example >>>> "Group Types". We may also raise OptionError when these option are used >>>> together to make this less confusing - e.g. OptionError("group type options >>>> (--nonposix, --posix and --external) are mutually exclusive"). >>>> >>>> Martin >>>> >>> New version attached. >>> >> >> 1) default=False parameter for Flag is redundant: >> >> + Flag('external', >> + cli_name='external', >> + doc=_('search for groups with support of external non-IPA members >> from trusted domains'), >> + default=False, >> + ), >> >> >> 2) No need to import StrEnum: >> +from ipalib import Int, Str, StrEnum >> >> 3) This can be simplified: >> + if len(filters): >> TO: >> + if filters: >> >> >> Besides these minor issues, that patch works fine and I think we can push a >> fixed version. >> >> Thanks, >> Martin >> > > Additional self-nack. > > 4) original filter is ignored when some of the new options is used. It prevents > from effective searching and also shows private groups when --posix is used. > > All fixed, new unit test added. New version attached. > > The fix doesn't touch usage of --private because it's a special case - private > groups don't have ipausergroup oc and therefore they are incompatible with > original filter. ACK, thanks for the fix. Pushed to master. Please also make sure that you update design page (http://www.freeipa.org/page/V3/Filtering_groups_by_type) with respect to the API change we have discussed above. Thanks, Martin From rcritten at redhat.com Tue Apr 9 21:21:10 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Apr 2013 17:21:10 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <5163EBF2.8080004@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5163EBF2.8080004@redhat.com> Message-ID: <51648646.6070706@redhat.com> Petr Viktorin wrote: > On 04/05/2013 10:54 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>>>> There are strict limits on what can be restored where. Only exact >>>>>>> matching hostnames and versions are allowed right now. We can >>>>>>> probably >>>>>>> relax the hostname requirement if we're only restoring data, and the >>>>>>> version perhaps for only the the first two values (so you can >>>>>>> restore a >>>>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>>>> >>>>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>>>> Or is what they put in /var/lib guaranteed portable across versions? >>>>> >>>>> An interesting question. I'd imagine that a major db change would also >>>>> require a major update to IPA, therefore if we restrict by IPA version >>>>> we should be ok. I AM doing an untar of files though so yeah, there >>>>> is a >>>>> risk here. >>>>> >>>>>> >>>>>> >>>>>> That's good to hear! >>>>>> >>>>>> I think while developing, you should run with -v to get all the >>>>>> output. >>>>>> And for production, please have the commands log by default (set >>>>>> log_file_name). >>>>> >>>>> Yes, I plan on adding that in the future. >>>>> >>>>>> >>>>>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>>>>> password because we need to contact remote servers to enable/disable >>>>>>> replication. >>>>>> >>>>>> The restore assumes that ipa is already installed, right? I can't >>>>>> just >>>>>> run it on a clean machine? Id would be good to check/document this. >>>>> >>>>> It depends. >>>>> >>>>> For a full backup you can actually restore to an uninstalled >>>>> server. In >>>>> fact, you could restore to a machine w/no IPA bits on it at all in all >>>>> likelihood (which wouldn't be very nice, but not exactly wrong either >>>>> IMHO). >>>>> >>>>> I tested this with: >>>>> - ipa-server-install >>>>> - ipa-backup >>>>> - ipa-server-install --uninstall -U >>>>> - ipa-restore >>>>> - ran the unit tests >>>>> >>>>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>>>> directories. Are these needed? >>>>> >>>>> Probably not. I gathered some of the files to backup based on watching >>>>> what files that changed during an install that are independent of us. >>>>> I'll take another pass through it, there may be other oddities too. >>>>> >>>>>> The tool runners (install/tools/ipa-backup and >>>>>> install/tools/ipa-restore) are missing, so IPA doesn't build. >>>>>> Probably >>>>>> just a forgotten git add. >>>>> >>>>> Yup. >>>>> >>>>>> >>>>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>>>> consider adding $(NULL) at the end. >>>>> >>>>> I'll take a look. >>>>> >>>>>> >>>>>> Backup.dirs, Backup.files, Backup.logs: >>>>>> The code modifies these class-level attributes. This means you can't >>>>>> run >>>>>> the command more than once in one Python session, so it can't be >>>>>> used as >>>>>> a library (e.g. in a hypothetical test suite). >>>>>> Please make the class atrributes immutable (tuples), then in >>>>>> __init__ do >>>>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>>>> >>>>> Ok, fair point. >>>>> >>>>>> Code that creates temporary files/directories or does chdir() >>>>>> should be >>>>>> next to (or in) a try block whose finally: restores things. >>>>> >>>>> Yes, I mean to add a big try/finally block around everything in run >>>>> eventually (or the equivalent anyway). >>>>> >>>>>> >>>>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>>>> please explicitly import whatever you're using from that package. In >>>>>> this case, nothing at all! >>>>> >>>>> Yeah, I haven't run this through pylint yet to see all the bad >>>>> imports I >>>>> cobbled together. >>>>> >>>>>> If there's a get_connection() method, it should return the >>>>>> connection, >>>>>> and it should always be used to get it. Store the connection in >>>>>> self._conn, and rather than: >>>>>> self.get_connection() >>>>>> self.conn.do_work() >>>>>> do: >>>>>> conn = self.get_connection() >>>>>> conn.do_work() >>>>>> This makes forgetting to call get_connection() impossible. >>>>> >>>>> My purpose was to avoid creating multiple connections. >>>>> >>>>>> If a variable is only used in a single method, like `filename` in >>>>>> Restore.extract_backup, don't store it in the admintool object. >>>>>> In general, try to avoid putting data in self if possible. It's >>>>>> convenient but it allows complex interdependencies. >>>>>> (Yes, I'm guilty of not following this myself.) >>>>> >>>>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a >>>>> rush >>>>> to get this WIP out. >>>>> >>>>>> In several places, the backup tool logs critical errors and then just >>>>>> continues on. Is that by design? I think a nonzero exit code would be >>>>>> appropriate. >>>>> >>>>> I'll take a look at them, all I can say at this point is maybe. >>>>> >>>>>> In the ipa-restore man page, --backend is not documented. >>>>>> >>>>>> In db2ldif, db2bak, etc., a more conscise way to get the time >>>>>> string is >>>>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>>>> >>>>>> When validating --gpg-keyring, it would be good to check both files >>>>>> (.sec and .pub). >>>>> >>>>> Ok, I can do those. >>>>> >>>>>> >>>>>> Here: >>>>>> if (self.backup_type != 'FULL' and not options.data_only and >>>>>> not instances): >>>>>> raise admintool.ScriptError('Cannot restore a data backup >>>>>> into >>>>>> an empty system') >>>>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and >>>>>> not >>>>>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >>>>> >>>>> Yeah, looks like that should be an or. >>>>> >>>>>> In the ReplicationManager.check_repl_init reporting: use >>>>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>>>> include full days. I don't think anyone would wait long enough for >>>>>> the >>>>>> overflow, but better to be correct. >>>>> >>>>> Sure, I doubt anyone would wait 24 hours either but its a >>>>> no-brainer to >>>>> make it safe. >>>> >>>> I think I've addressed just about everything. >>>> >>>> The reason that /var/run/dirsrv and var/lock/dirsrv are included in the >>>> backup is for the case of a full restore. These directories are not >>>> created/provided by the package itself, but by installing the first >>>> instance, so we need the ownership/SELinux context preserved. >>>> >>>> One thing I need tested is restoring over top of new data with multiple >>>> replicas. So basically install, do a backup, add a bunch of data, >>>> restore, re-initialize all the other masters and then confirm that ALL >>>> the new data is gone. I think I've got the sequence right but this is >>>> critical. >>>> >>>> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >>>> 9/multi-instance DS configurations). >>>> >>>> One thing I tested was: >>>> >>>> - ipa-server-install >>>> - ipa-backup >>>> - ipa-server-install --uninstall -U >>>> - ipa-restore ipa-full-... >>>> >>>> This will actually get your server back EXCEPT that dogtag won't start. >>>> This is because the log directories are created by the instance >>>> creation. There are two solutions: backup with --logs or manually >>>> re-create the log directories (there are several, depending on dogtag >>>> version). >>> >>> Could backup without --logs save which directories are there, and >>> restore create empty directories if they don't exist? To me >>> re-initializing a completely wiped machine looks like a big gain for the >>> extra effort. >> >> I went ahead and made this change, it wasn't a lot of work. >> >>> >>> >>> >>> The spec changelog needs a small rebase. >> >> Done. >> >>> >>> I've tested some scenarios and didn't find any other issues so far. >>> >>> I still want to test some more with upgraded masters; installing them >>> takes some time. >>> Also I still need to test CA replicas (with the DNAME patches removed). >>> >> >> rob > > I found a bug with the following topology: > > [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] > > Running ipa-restore on the 3.2 instance tries to disable the CA > replication agreement between the other two. > However, deep in ReplicationManager.agreement_dn it uses its own DS > instance name instead of the Dogtag-9-DS one, so the agreement isn't > found and the restore fails. > > Yeah, I'm not 100% sure how to address that either. Is it safe to assume that if the port is 7389 then the instance is pki-ca? Or should we test for the existence of the instance name like we do master/clone? I've also figured out why Update in Progress loops forever. It is because the older ipa-replica-manage do not re-enable the replication agreement, so replication can't continue. I'm not entirely sure how we will need to go about fixing this, except through documentation. rob From npmccallum at redhat.com Tue Apr 9 21:39:19 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 09 Apr 2013 17:39:19 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <515DA36E.7020003@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> Message-ID: <1365543559.2015.20.camel@localhost.localdomain> On Thu, 2013-04-04 at 11:59 -0400, Rob Crittenden wrote: > Nathaniel McCallum wrote: > > On Fri, 2013-03-08 at 09:50 -0500, Simo Sorce wrote: > >> On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: > >>> On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: > >>>> Patch is attached. > >>>> > >>>> There are currently a few security downsides to this patch: > >>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously > >>>> 2. ipatokenRadiusSecret is readable by an anonymous bind > >>>> > >>>> This patch also adds some new dependencies, namely: > >>>> 1. libverto (a dependency of krb5) > >>>> 2. systemd > >>>> 3. a krb5 patched for libk5radius support [1] > >>>> > >>>> In the interest of trying to meet the Fedora Features deadline, I am > >>>> providing the patch in spite of the above issues. > >>>> > >>>> Nathaniel > >>>> > >>>> 1 - http://bit.ly/ZqtK79 > >>> > >>> Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the > >>> schema. This will need to be verified and finalized. > >> > >> I reserved this OID space for ipa OTP schema. > > > > Thanks! For posterity, where is this documented? > > > > Nathaniel > > In daemons/configure.ac you fix up the inconsistent tab/spacing we use > when displaying a summary for IPA Server, except you add a tab in the > CFLAGS line. Fixed. > Trailing white space in 70ipaotp.ldif Fixed. > Just a style thing, you use tmp as a variable a lot to do somewhat beefy > things (e.g. find_base()) Fixed. > Does hostname need to be fully-qualified? We enforce this during the > install but things change. I don't know if that is important for this > daemon. Hostname is only used for looking up results in the RADIUS configuration on the server side. It is up to the admin to ensure a match here (the admin will have to do it manually anyway). > ENOMEM is used as an error code when some things fail, sometimes in > favor of the real error message: > > + /* Set Service-Type. */ > + retval = k5_radius_attrset_add_number(ctx.attrs, > + k5_radius_attr_name2num("Service-Type"), > + > K5_RADIUS_SERVICE_TYPE_AUTHENTICATE_ONLY); > + if (retval != 0) { > + log_err(ENOMEM, "Unable to set Service-Type"); > + goto error; > + } Fixed. > No man pages Do we make man pages for socket-activated processes in /usr/libexec? Running this directly never makes sense... > In setup_ldap() there might be an inconsequential memory leak. If there > is no base, and one is found, but some later part of the LDAP sequence > fails an error will be returned but the base will remain set. It seems > that you quit on all setup_ldap() failures so this is probably no big deal. Fixed. > In on_query_readable() is it an error if multiple entries are returned? > And there is tmp again. I had to do a double-take on the return value of > the parse_ commands to realize that tmp was the error string. This is a good question. In theory there should never be multiple entries. Is there something that looks broken here? I'm not sure if we should error in this case or if we should silently proceed... So far I've chosen the second option and I fixed a memory leak that occurs if multiple entries are received. > It doesn't look like the LDAP entry is freed in on_query_readable(). Fixed. > We'll need to handle upgrades eventually too. I'm not sure of the implications here. I thought this was done by copy-schema-to-ca.py. But I guess I'm wrong. > Can you add the ticket(s) to the git commit message. > > If there are any wiki design pages it would help to point to those. http://freeipa.org/page/V3/OTP > You'll need to add the new BuildRequires to freeipa.spec.in too. Fixed. > There isn't a lot of documentation on what each of these files/functions > are supposed to do. Fixed. The latest version of the patch is here: https://github.com/npmccallum/freeipa/commit/0d126d4c2449787527f7b507029ceba8aea1eb4c Also note that you can now build this patch against krb5 1.11 in Fedora rawhide (and f19 when the alpha freeze lifts). Nathaniel From rcritten at redhat.com Tue Apr 9 21:47:18 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Apr 2013 17:47:18 -0400 Subject: [Freeipa-devel] [PATCH 0044] Update only selected attributes for winsync agreement In-Reply-To: <5162CC78.6030208@redhat.com> References: <5162CC78.6030208@redhat.com> Message-ID: <51648C66.3040102@redhat.com> Tomas Babej wrote: > Hi, > > Trying to insert nsDS5ReplicatedAttributeListTotal and > nsds5ReplicaStripAttrs to winsync agreements caused upgrade errors. > With this patch, these attributes are skipped for winsync agreements. > > Made find_ipa_replication_agreements() in replication.py more > corresponding to find_replication_agreements. It returns list of > entries instead of unicode strings now. > > https://fedorahosted.org/freeipa/ticket/3522 > > Tomas This will still do some work against a winsync agreement. Do we need to do that at all? I'm not sure we do. rob From rcritten at redhat.com Tue Apr 9 21:49:06 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Apr 2013 17:49:06 -0400 Subject: [Freeipa-devel] [PATCH] 1094 fix 2 broken tests In-Reply-To: <5162778A.2040109@redhat.com> References: <515F3472.9050108@redhat.com> <5162778A.2040109@redhat.com> Message-ID: <51648CD2.3080501@redhat.com> Ana Krivokapic wrote: > On 04/05/2013 10:30 PM, Rob Crittenden wrote: >> Two tests are failing due to missing attributes since the krb ticket >> flags patch was pushed. >> >> rob >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > The patch fixes failing tests, ACK. pushed to master rob From dpal at redhat.com Tue Apr 9 23:52:34 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 09 Apr 2013 19:52:34 -0400 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <1365523860.20560.40.camel@willson.li.ssimo.org> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> <51641F6A.6030500@redhat.com> <1365517163.20560.32.camel@willson.li.ssimo.org> <51643132.1030007@redhat.com> <1365523860.20560.40.camel@willson.li.ssimo.org> Message-ID: <5164A9C2.2090107@redhat.com> On 04/09/2013 12:11 PM, Simo Sorce wrote: > On Tue, 2013-04-09 at 11:18 -0400, Dmitri Pal wrote: >> On 04/09/2013 10:19 AM, Simo Sorce wrote: >>> On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote: >>>> On 04/08/2013 05:09 PM, Martin Kosek wrote: >>>>> On 04/08/2013 03:47 PM, Dmitri Pal wrote: >>>>>> On 04/08/2013 08:42 AM, Martin Kosek wrote: >>>>>>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: >>>>>>>> On 8.4.2013 10:47, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> this patch fixes . >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> Re-sending with correct subject. >>>>>>>> >>>>>>> I tested the change both for upgrades and for fresh installs and it worked fine >>>>>>> both cases, even when testing with Firefox enforcing mode. >>>>>>> >>>>>>> So far, as the biggest issue in current process I see NSS not being able to >>>>>>> fallback to other defined OCSP responder (I tested with Firefox 20). This way, >>>>>>> Firefox will fail validating the FreeIPA site when the first tested OCSP >>>>>>> responder is not available (e.g. the original IPA CA signing the http cert, or >>>>>>> an `ipa-ca.$domain` host that is currently not up). >>>>>> Have we filed a ticket with FF? >>>>> AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=797815 >>>>> >>>>> Rob seems to have more context about this bug background. >>>>> >>>>> Martin >>>>> >>>> We may want to wait with pushing this patch until we get some response in the >>>> NSS Bugzilla above. If our request is rejected, we may be forced to use just a >>>> single CRL/OCSP (which would be probably the general one) and thus supersede >>>> patch 123. >>> Well it will have to depend on when you create certs. >>> The first IPA server own cert should probably point at the ipa server >>> name. Then we should warn in bold letters that the user should create >>> such and such a DNS name if they did not let IPA handle DNS. >>> >>> If we can handle DNS then any other use can refer to the common name >>> which can be an A name with multiple entries (each IPA CA server should >>> be listed there by default and the record should be changed at ca >>> replicas install/decommission time, however we should allow admins to >>> add/remove names as well manually in case they want to add proxies otr >>> conceal some of the CA servers. >>> >>> We may also want to change the RA client code to use that record to >>> fetch certs. >>> >>> Simo. >>> >> I see a lot of RFEs in this comment. >> Are we going to file them? > We'll see how NSS is going to respond to the ticket, and then adjust > accordingly. > > Simo. > > Well... time to adjust... accordingly ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Wed Apr 10 07:08:22 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Apr 2013 09:08:22 +0200 Subject: [Freeipa-devel] [PATCH] 400 Fix trustconfig-mod primary group error Message-ID: <51650FE6.4070606@redhat.com> As find_entry_by_attr no longer adds $SUFFIX to searched base DN, trustconfig-mod could not find POSIX group to when validating the new ipantfallbackprimarygroup value. This patch fixes this regression. --- Kudos to Petr Vobornik who found this error. There is already a test for this use case, it just wasn't spotted earlier as it is skipped when trusts are not configured. Pushed to master as a one-liner. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-400-fix-trustconfig-mod-primary-group-error.patch Type: text/x-patch Size: 1116 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 10 07:46:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Apr 2013 09:46:55 +0200 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <5164A9C2.2090107@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> <51641F6A.6030500@redhat.com> <1365517163.20560.32.camel@willson.li.ssimo.org> <51643132.1030007@redhat.com> <1365523860.20560.40.camel@willson.li.ssimo.org> <5164A9C2.2090107@redhat.com> Message-ID: <516518EF.8060902@redhat.com> On 04/10/2013 01:52 AM, Dmitri Pal wrote: > On 04/09/2013 12:11 PM, Simo Sorce wrote: >> On Tue, 2013-04-09 at 11:18 -0400, Dmitri Pal wrote: >>> On 04/09/2013 10:19 AM, Simo Sorce wrote: >>>> On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote: >>>>> On 04/08/2013 05:09 PM, Martin Kosek wrote: >>>>>> On 04/08/2013 03:47 PM, Dmitri Pal wrote: >>>>>>> On 04/08/2013 08:42 AM, Martin Kosek wrote: >>>>>>>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: >>>>>>>>> On 8.4.2013 10:47, Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> this patch fixes . >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>> Re-sending with correct subject. >>>>>>>>> >>>>>>>> I tested the change both for upgrades and for fresh installs and it worked fine >>>>>>>> both cases, even when testing with Firefox enforcing mode. >>>>>>>> >>>>>>>> So far, as the biggest issue in current process I see NSS not being able to >>>>>>>> fallback to other defined OCSP responder (I tested with Firefox 20). This way, >>>>>>>> Firefox will fail validating the FreeIPA site when the first tested OCSP >>>>>>>> responder is not available (e.g. the original IPA CA signing the http cert, or >>>>>>>> an `ipa-ca.$domain` host that is currently not up). >>>>>>> Have we filed a ticket with FF? >>>>>> AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=797815 >>>>>> >>>>>> Rob seems to have more context about this bug background. >>>>>> >>>>>> Martin >>>>>> >>>>> We may want to wait with pushing this patch until we get some response in the >>>>> NSS Bugzilla above. If our request is rejected, we may be forced to use just a >>>>> single CRL/OCSP (which would be probably the general one) and thus supersede >>>>> patch 123. >>>> Well it will have to depend on when you create certs. >>>> The first IPA server own cert should probably point at the ipa server >>>> name. Then we should warn in bold letters that the user should create >>>> such and such a DNS name if they did not let IPA handle DNS. >>>> >>>> If we can handle DNS then any other use can refer to the common name >>>> which can be an A name with multiple entries (each IPA CA server should >>>> be listed there by default and the record should be changed at ca >>>> replicas install/decommission time, however we should allow admins to >>>> add/remove names as well manually in case they want to add proxies otr >>>> conceal some of the CA servers. >>>> >>>> We may also want to change the RA client code to use that record to >>>> fetch certs. >>>> >>>> Simo. >>>> >>> I see a lot of RFEs in this comment. >>> Are we going to file them? >> We'll see how NSS is going to respond to the ticket, and then adjust >> accordingly. >> >> Simo. >> >> > Well... time to adjust... accordingly ;-) > Oh yes, see "adjusted" tickets https://fedorahosted.org/freeipa/ticket/3552 and https://fedorahosted.org/freeipa/ticket/3547 with a resolution how to handle the OCSP/CRL URIs. This supersedes the original Jan's patch 123. Martin From pvoborni at redhat.com Wed Apr 10 07:48:46 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 10 Apr 2013 09:48:46 +0200 Subject: [Freeipa-devel] [PATCH] 260-262 Global trust configuration page In-Reply-To: <5147E3E3.4070707@redhat.com> References: <513255B4.8020903@redhat.com> <513739D3.7090606@redhat.com> <513F5941.6060301@redhat.com> <5143E1A6.9020103@redhat.com> <5146FAE8.6010901@redhat.com> <5147E3E3.4070707@redhat.com> Message-ID: <5165195E.2040905@redhat.com> On 03/19/2013 05:04 AM, Endi Sukma Dewata wrote: > On 3/18/2013 6:30 AM, Petr Vobornik wrote: >>> The static page and the code looks good, but do you have a live server >>> that I could take a look at? > >> https://xxxx/ipa/ui/#trusts=trustconfig&ipaserver=trusts&navigation=ipaserver >> > > Thanks. ACK. > pushed to master (262-2, 268) 262-2 has a one-liner change because of API change of group-find command. < + type: 'posix' > + posix: true -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0262-2-Global-trust-config-page.patch Type: text/x-patch Size: 13777 bytes Desc: not available URL: From pvoborni at redhat.com Wed Apr 10 08:14:59 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 10 Apr 2013 10:14:59 +0200 Subject: [Freeipa-devel] PATCH] 275 Fix regression in group type selection in group adder dialog In-Reply-To: <515EC88A.1080609@redhat.com> References: <515EB55D.30101@redhat.com> <515EC88A.1080609@redhat.com> Message-ID: <51651F83.90905@redhat.com> On 04/05/2013 02:50 PM, Ana Krivokapic wrote: > On 04/05/2013 01:28 PM, Petr Vobornik wrote: >> Refactoring of radio widget (04325fbb4c64ee4aef6d8c9adf0ff95b8b653101) >> caused that value is no longer supplied to value_change handler. >> > ACK. > Pushed to master -- Petr Vobornik From pviktori at redhat.com Wed Apr 10 10:37:10 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Apr 2013 12:37:10 +0200 Subject: [Freeipa-devel] FreeIPA string freeze In-Reply-To: References: <5162E61A.5060700@redhat.com> Message-ID: <516540D6.3040001@redhat.com> On 04/08/2013 05:54 PM, Yuri Chornoivan wrote: > ???????? Mon, 08 Apr 2013 18:45:30 +0300, Petr Viktorin > : > >> Hello, FreeIPA translators! >> >> We wanted to give enough time for translations, so we made an upstream >> string freeze last week, giving about two weeks of translation time >> until the beta. >> We didn't expect most of the translations to be done already -- >> Ukrainian at 100% and French with 40 strings missing. Thank you!! >> >> Meanwhile we have some fixes upstream that add/change additional >> strings that would have to be postponed for the next release. >> How much would it inconvenience you if instead of postponing the >> patches, we'd push each change to Transifex as it is pushed to master? >> >> In the past J?r?me said that updating continuously would be better >> than the string freezes and mass updates we do now. We don't have >> resources to automate that*, but for slipping a few strings past >> string freeze it could work. >> > > Hi, > > Surely, it would be good to have fixes now (as well as some announce in > trans at lists.fedoraproject.org ). > > And I'm all of the J?r?me's proposal. It is enough to have updates every > 3-4 months. That will make the translation process significantly easier. > Okay. I've pushed the updates to Transifex (7 new strings, expect a couple more), and I'll do some more frequent updates in the future. I've lurked on trans at lists.fedoraproject.org for a while and haven't seen many announcements from projects. Is it the right list to communicate string freezes/deadlines/releases? -- Petr? From pviktori at redhat.com Wed Apr 10 10:47:11 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Apr 2013 12:47:11 +0200 Subject: [Freeipa-devel] [PATCH] 0214 Remove 'cn' attribute from idnsRecord and idnsZone objectClasses Message-ID: <5165432F.9090206@redhat.com> This removes the "cn" attribute from the idnsRecord objectclass. For more robust upgrades, any existing cn attributes are removed in preupgrade https://fedorahosted.org/freeipa/ticket/3514 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0214-Remove-cn-attribute-from-idnsRecord-and-idnsZone-obj.patch Type: text/x-patch Size: 7336 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 10 10:56:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Apr 2013 12:56:42 +0200 Subject: [Freeipa-devel] [PATCH] 0214 Remove 'cn' attribute from idnsRecord and idnsZone objectClasses In-Reply-To: <5165432F.9090206@redhat.com> References: <5165432F.9090206@redhat.com> Message-ID: <5165456A.6060103@redhat.com> On 04/10/2013 12:47 PM, Petr Viktorin wrote: > This removes the "cn" attribute from the idnsRecord objectclass. > > For more robust upgrades, any existing cn attributes are removed in preupgrade > > https://fedorahosted.org/freeipa/ticket/3514 I am not sure that it is a good idea to silently remove user data on upgrades, User may want to migrate this data elsewhere. Wouldn't it be better to only detect this situation (i.e. some records have CN filled) and report that only as an upgrade warning? Martin From pviktori at redhat.com Wed Apr 10 11:32:48 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Apr 2013 13:32:48 +0200 Subject: [Freeipa-devel] [PATCH] 0214 Remove 'cn' attribute from idnsRecord and idnsZone objectClasses In-Reply-To: <5165456A.6060103@redhat.com> References: <5165432F.9090206@redhat.com> <5165456A.6060103@redhat.com> Message-ID: <51654DE0.3030905@redhat.com> On 04/10/2013 12:56 PM, Martin Kosek wrote: > On 04/10/2013 12:47 PM, Petr Viktorin wrote: >> This removes the "cn" attribute from the idnsRecord objectclass. >> >> For more robust upgrades, any existing cn attributes are removed in preupgrade >> >> https://fedorahosted.org/freeipa/ticket/3514 > > I am not sure that it is a good idea to silently remove user data on upgrades, > User may want to migrate this data elsewhere. > > Wouldn't it be better to only detect this situation (i.e. some records have CN > filled) and report that only as an upgrade warning? > > Martin > After some discussion, I removed the check completely. Searching through the records on each upgrade just to give a warning is overkill (and yum upgrade warnings tend to be problematic anyway). In case of an exising cn, the upgrade will still work, but IPA won't be able to modify the record until the cn is removed (it'll say "attribute "cn" not allowed"). Since the misconfiguration is caused by an admin manually adding a nonsensical attribute, this behavior is appropriate. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0214.2-Remove-cn-attribute-from-idnsRecord-and-idnsZone-obj.patch Type: text/x-patch Size: 5745 bytes Desc: not available URL: From mkosek at redhat.com Wed Apr 10 11:58:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Apr 2013 13:58:37 +0200 Subject: [Freeipa-devel] [PATCH] 0214 Remove 'cn' attribute from idnsRecord and idnsZone objectClasses In-Reply-To: <51654DE0.3030905@redhat.com> References: <5165432F.9090206@redhat.com> <5165456A.6060103@redhat.com> <51654DE0.3030905@redhat.com> Message-ID: <516553ED.1070107@redhat.com> On 04/10/2013 01:32 PM, Petr Viktorin wrote: > On 04/10/2013 12:56 PM, Martin Kosek wrote: >> On 04/10/2013 12:47 PM, Petr Viktorin wrote: >>> This removes the "cn" attribute from the idnsRecord objectclass. >>> >>> For more robust upgrades, any existing cn attributes are removed in preupgrade >>> >>> https://fedorahosted.org/freeipa/ticket/3514 >> >> I am not sure that it is a good idea to silently remove user data on upgrades, >> User may want to migrate this data elsewhere. >> >> Wouldn't it be better to only detect this situation (i.e. some records have CN >> filled) and report that only as an upgrade warning? >> >> Martin >> > > After some discussion, I removed the check completely. Searching through the > records on each upgrade just to give a warning is overkill (and yum upgrade > warnings tend to be problematic anyway). > In case of an exising cn, the upgrade will still work, but IPA won't be able to > modify the record until the cn is removed (it'll say "attribute "cn" not > allowed"). > Since the misconfiguration is caused by an admin manually adding a nonsensical > attribute, this behavior is appropriate. > ACK. Pushed to master. Martin From yurchor at ukr.net Wed Apr 10 12:27:44 2013 From: yurchor at ukr.net (Yuri Chornoivan) Date: Wed, 10 Apr 2013 15:27:44 +0300 Subject: [Freeipa-devel] FreeIPA string freeze In-Reply-To: <516540D6.3040001@redhat.com> References: <5162E61A.5060700@redhat.com> <516540D6.3040001@redhat.com> Message-ID: Wed, 10 Apr 2013 13:37:10 +0300 ???? ???????? Petr Viktorin : > On 04/08/2013 05:54 PM, Yuri Chornoivan wrote: >> ???????? Mon, 08 Apr 2013 18:45:30 +0300, Petr Viktorin >> : >> >>> Hello, FreeIPA translators! >>> >>> We wanted to give enough time for translations, so we made an upstream >>> string freeze last week, giving about two weeks of translation time >>> until the beta. >>> We didn't expect most of the translations to be done already -- >>> Ukrainian at 100% and French with 40 strings missing. Thank you!! >>> >>> Meanwhile we have some fixes upstream that add/change additional >>> strings that would have to be postponed for the next release. >>> How much would it inconvenience you if instead of postponing the >>> patches, we'd push each change to Transifex as it is pushed to master? >>> >>> In the past J?r?me said that updating continuously would be better >>> than the string freezes and mass updates we do now. We don't have >>> resources to automate that*, but for slipping a few strings past >>> string freeze it could work. >>> >> >> Hi, >> >> Surely, it would be good to have fixes now (as well as some announce in >> trans at lists.fedoraproject.org ). >> >> And I'm all of the J?r?me's proposal. It is enough to have updates every >> 3-4 months. That will make the translation process significantly easier. >> > > Okay. I've pushed the updates to Transifex (7 new strings, expect a > couple more), and I'll do some more frequent updates in the future. Thanks for your work. > I've lurked on trans at lists.fedoraproject.org for a while and haven't > seen many announcements from projects. Is it the right list to > communicate string freezes/deadlines/releases? Yes. This is the right list for Fedora translation announces. Personally, I do not know why other Fedora Upstream projects do not announce their translation dates in this list. It is easy to send a message there and target Fedora translation coordinators of many languages at once. Yes, it might happen that you will not obtain much translations at once, but I cannot imagine the other way to contact new translators. Such strategy (regular announces in translator's mailing lists) works fine in many projects (KDE, GNOME, Audacity etc.) It's a win-win situation. You cannot lose if you make even one-sentence announces and do it regularly. Best regards, Yuri From akrivoka at redhat.com Wed Apr 10 12:53:53 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 10 Apr 2013 14:53:53 +0200 Subject: [Freeipa-devel] [RFE] Remove source hosts from HBAC In-Reply-To: <515F1100.5000603@redhat.com> References: <515F1100.5000603@redhat.com> Message-ID: <516560E1.7090006@redhat.com> On 04/05/2013 07:59 PM, Ana Krivokapic wrote: > Hello list, > > I have been thinking about the possible implementation for a solution of > ticket https://fedorahosted.org/freeipa/ticket/3528. There are several > options: > > 1. Completely remove the commands and command options related to source > hosts in HBAC. This might not be a good idea as it could cause problems > for older clients. > > 2. Hide these commands/options from the web UI, but leave them in CLI. > This would keep the API intact, but I don't like the idea of introducing > inconsistencies between CLI and web UI. > > 3. Do not remove anything, but issue deprecation warnings. The user will > see a warning when using these commands/options, but everything will > still work. > > 4. Do not remove anything, but raise exceptions. This would effectively > prevent the user from using these commands/options, as the exception > will break the execution of a command. > > In any case, any reference to source hosts should be removed from help > and documentation. > > I am leaning towards options 3 or 4. > > Thoughts, comments and ideas are welcome. > The design page for deprecating source hosts from HBAC: http://www.freeipa.org/page/V3/HBACSourceHosts -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From tbabej at redhat.com Wed Apr 10 13:13:45 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 10 Apr 2013 15:13:45 +0200 Subject: [Freeipa-devel] [PATCH 0044] Update only selected attributes for winsync agreement In-Reply-To: <51648C66.3040102@redhat.com> References: <5162CC78.6030208@redhat.com> <51648C66.3040102@redhat.com> Message-ID: <51656589.30508@redhat.com> On 04/09/2013 11:47 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> Hi, >> >> Trying to insert nsDS5ReplicatedAttributeListTotal and >> nsds5ReplicaStripAttrs to winsync agreements caused upgrade errors. >> With this patch, these attributes are skipped for winsync agreements. >> >> Made find_ipa_replication_agreements() in replication.py more >> corresponding to find_replication_agreements. It returns list of >> entries instead of unicode strings now. >> >> https://fedorahosted.org/freeipa/ticket/3522 >> >> Tomas > > This will still do some work against a winsync agreement. Do we need > to do that at all? I'm not sure we do. > > rob > I removed the nsds5replicahost attribute update for winsync agreements after discussion. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0044-2-Update-only-selected-attributes-for-winsync-agreemen.patch Type: text/x-patch Size: 4976 bytes Desc: not available URL: From tbabej at redhat.com Wed Apr 10 13:26:57 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 10 Apr 2013 15:26:57 +0200 Subject: [Freeipa-devel] [PATCH 0027] Add checks for SELinux in install scripts In-Reply-To: <51629BCA.4070609@redhat.com> References: <51094671.30701@redhat.com> <51095135.4040501@redhat.com> <510FD1F6.60901@redhat.com> <510FE816.6040609@redhat.com> <5123D476.5000108@redhat.com> <5124AA2F.1040009@redhat.com> <5159E78A.9090902@redhat.com> <515A9132.6030404@redhat.com> <515C105B.6030304@redhat.com> <515D8D68.1060901@redhat.com> <515EB975.5060503@redhat.com> <515F0D5C.5040009@redhat.com> <51629BCA.4070609@redhat.com> Message-ID: <516568A1.7050903@redhat.com> On 04/08/2013 12:28 PM, Tomas Babej wrote: > On 04/05/2013 07:43 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 04/04/2013 04:25 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> On Tue 02 Apr 2013 10:05:06 AM CEST, Tomas Babej wrote: >>>>>> On Mon 01 Apr 2013 10:01:14 PM CEST, Rob Crittenden wrote: >>>>>>> Tomas Babej wrote: >>>>>>>> On Tue 19 Feb 2013 08:37:26 PM CET, Rob Crittenden wrote: >>>>>>>>> Tomas Babej wrote: >>>>>>>>>> On 02/04/2013 04:21 PM, Rob Crittenden wrote: >>>>>>>>>>> Tomas Babej wrote: >>>>>>>>>>>> On 01/30/2013 05:12 PM, Tomas Babej wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> The checks make sure that SELinux is: >>>>>>>>>>>>> - installed and enabled (on server install) >>>>>>>>>>>>> - installed and enabled OR not installed (on client >>>>>>>>>>>>> install) >>>>>>>>>>>>> >>>>>>>>>>>>> Please note that client installs with SELinux not >>>>>>>>>>>>> installed are >>>>>>>>>>>>> allowed since freeipa-client package has no dependency on >>>>>>>>>>>>> SELinux. >>>>>>>>>>>>> (any objections to this approach?) >>>>>>>>>>>>> >>>>>>>>>>>>> The (unsupported) option --allow-no-selinux has been added. >>>>>>>>>>>>> It can >>>>>>>>>>>>> used to bypass the checks. >>>>>>>>>>>>> >>>>>>>>>>>>> Parts of platform-dependant code were refactored to use newly >>>>>>>>>>>>> added >>>>>>>>>>>>> is_selinux_enabled() function. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3359 >>>>>>>>>>>>> >>>>>>>>>>>>> Tomas >>>>>>>>>>>> >>>>>>>>>>>> I forgot to edit the man pages. Thanks Rob! >>>>>>>>>>>> >>>>>>>>>>>> Updated patch attached. >>>>>>>>>>>> >>>>>>>>>>>> Tomas >>>>>>>>>>> >>>>>>>>>>> After a bit of off-line discussion I don't think we're quite >>>>>>>>>>> ready >>>>>>>>>>> yet >>>>>>>>>>> to require SELinux by default on client installations (even >>>>>>>>>>> with a >>>>>>>>>>> flag to work around it). The feeling is this would be >>>>>>>>>>> disruptive to >>>>>>>>>>> existing automation. >>>>>>>>>>> >>>>>>>>>>> Can you still do the check but not enforce it, simply display a >>>>>>>>>>> big >>>>>>>>>>> warning if SELinux is disabled? >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sure, here is the updated patch. >>>>>>>>>> >>>>>>>>>> I edited the commit message, RFE description and man pages >>>>>>>>>> according to >>>>>>>>>> the new behaviour. >>>>>>>>>> >>>>>>>>>> Tomas >>>>>>>>> >>>>>>>>> The patch looks good, I'm just wondering about one thing. The >>>>>>>>> default >>>>>>>>> value for is_selinux_enabled() is True in >>>>>>>>> ipapython/services.py.in. >>>>>>>>> >>>>>>>>> So this means that any non-Red Hat/non-Fedora system, by >>>>>>>>> default, is >>>>>>>>> going to assume that SELinux is enabled. >>>>>>>>> >>>>>>>>> My hesitation has to when we call check_selinux_status(). It may >>>>>>>>> incorrectly error out. I suspect that the user would have to work >>>>>>>>> around this using --allow-selinux-disabled but this wouldn't >>>>>>>>> make a >>>>>>>>> lot of sense since they actually do have SELinux disabled. >>>>>>>> >>>>>>>> Yes, you're right. And the error message would not even be helpful >>>>>>>> since >>>>>>>> it would tell the user to install policycoreutils package. This >>>>>>>> would be >>>>>>>> the >>>>>>>> case both with server and client installs when selinux would >>>>>>>> not be >>>>>>>> installed >>>>>>>> at all. >>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> rob >>>>>>>> >>>>>>>> Well we have 2 options as I see it: >>>>>>>> >>>>>>>> 1.) We can either return None as default, and add checks to >>>>>>>> check_selinux_status, restore_context and install scripts that >>>>>>>> would >>>>>>>> ensure that we behave properly when is_selinux_enabled() is not >>>>>>>> implemented. >>>>>>>> >>>>>>>> 2.) We can remove the default value, since it would cause >>>>>>>> forementioned >>>>>>>> crash and add comment that this function needs to be implemented >>>>>>>> properly in every platform file. >>>>>>>> >>>>>>>> I'm probably for option 2, there's no need to clutter the code >>>>>>>> with >>>>>>>> checks >>>>>>>> that compensate for improper platform file implementations. >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> I agree with you on option 2. >>>>>>> >>>>>>> rob >>>>>> >>>>>> I updated the patch accordingly. >>>>>> >>>>>> Tomas >>>>> >>>>> Sorry, wrong patch. Correct version attached. >>>>> >>>>> Tomas >>>> >>>> I'm sorry to throw this back again after so long (and having agreed >>>> with the approach). >>>> >>>> So I was thinking about how another distro maintainer would have to >>>> deal with this. By default with this patch check_selinux_status() >>>> returns None which is evaluated as False, so the warning will get >>>> thrown. If they set it to be True to avoid the warning then other >>>> things may blow up because SELinux really isn't enabled, so we really >>>> haven't gotten anywhere. >>>> >>>> I think the problem is we're trying to cram too much into one >>>> function. I wonder if a is_selinux_available() command would help >>>> which would short-circuit all of this. >>>> >>>> While trying to figure out how this worked I found >>>> httpinstance.configure_selinux_for_httpd() which makes a similar call >>>> to see if SELinux is available, so maybe we should convert that as >>>> well. >>>> >>>> rob >>> I added the is_selinux_available function. Both is_selinux_enabled and >>> is_selinux_available default to False in services.py.in. Maintainer >>> that >>> would want to implement platform file, would have to implement both >>> functions for server install. We require SELinux for server anyway. For >>> client installs, default versions work fine. >>> >>> I converted httpinstance.configure_selinux_for_httpd() to use >>> is_selinux_enabled(). I also found a similar call in adtrustinstance.py >> >> Ok, this is getting us closer, and opens a philosophical discussion. >> >> As implemented, this forces SELinux to be at least be available on >> the box, and by default required to be enabled. This is our strong >> recommendation for all users. >> >> There is a flag to allow it be in permissive, which will help people >> work around any policy issues or if they don't want SELinux. They'd >> still have to run without it completely disabled though. >> >> This does leave other platforms in a bad place though, there is no >> out for them. >> >> How about adding a require_selinux() call to the platform code >> defaulting to True. If someone wants to override that with False they >> can. A call to that could be added inside the other is_selinux... >> calls to not pollute the rest of the code with it, and if it's False >> we just skip all the SELinux stuff. > Having the call to require_selinux inside the is_selinux_* functions > would force us to pretend that SELinux is up and in enforcing mode > (for both is_selinux_available and is_selinux_enabled to return > True). While that will allow us to pass the install checks, it would > cause failure in other parts of the code, e.g. in httpinstance.py > while setting SELinux booleans. > > If we want to provide an easy way for other platforms, it comes with > the cost of polluting our code with require_selinux(). Personally I'm > fine with that, it will just clearly mark > which parts of the code are dependant on SELinux. > >> This still leaves us with a hardcoded requirement for SELinux in >> Fedora/RHEL and should provide some flexibility for other platforms >> as they come. >> >> What do you think? >> >> rob > > Tomas I implemented the approach. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0027-7-Add-checks-for-SELinux-in-install-scripts.patch Type: text/x-patch Size: 23012 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 10 13:53:45 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Apr 2013 15:53:45 +0200 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <51648646.6070706@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5163EBF2.8080004@redhat.com> <51648646.6070706@redhat.com> Message-ID: <51656EE9.3080108@redhat.com> On 04/09/2013 11:21 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/05/2013 10:54 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>>>>> There are strict limits on what can be restored where. Only exact >>>>>>>> matching hostnames and versions are allowed right now. We can >>>>>>>> probably >>>>>>>> relax the hostname requirement if we're only restoring data, and >>>>>>>> the >>>>>>>> version perhaps for only the the first two values (so you can >>>>>>>> restore a >>>>>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>>>>> >>>>>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>>>>> Or is what they put in /var/lib guaranteed portable across versions? >>>>>> >>>>>> An interesting question. I'd imagine that a major db change would >>>>>> also >>>>>> require a major update to IPA, therefore if we restrict by IPA >>>>>> version >>>>>> we should be ok. I AM doing an untar of files though so yeah, there >>>>>> is a >>>>>> risk here. >>>>>> >>>>>>> >>>>>>> >>>>>>> That's good to hear! >>>>>>> >>>>>>> I think while developing, you should run with -v to get all the >>>>>>> output. >>>>>>> And for production, please have the commands log by default (set >>>>>>> log_file_name). >>>>>> >>>>>> Yes, I plan on adding that in the future. >>>>>> >>>>>>> >>>>>>>> ipa-backup does all its binds using ldapi. ipa-restore needs the DM >>>>>>>> password because we need to contact remote servers to >>>>>>>> enable/disable >>>>>>>> replication. >>>>>>> >>>>>>> The restore assumes that ipa is already installed, right? I can't >>>>>>> just >>>>>>> run it on a clean machine? Id would be good to check/document this. >>>>>> >>>>>> It depends. >>>>>> >>>>>> For a full backup you can actually restore to an uninstalled >>>>>> server. In >>>>>> fact, you could restore to a machine w/no IPA bits on it at all in >>>>>> all >>>>>> likelihood (which wouldn't be very nice, but not exactly wrong either >>>>>> IMHO). >>>>>> >>>>>> I tested this with: >>>>>> - ipa-server-install >>>>>> - ipa-backup >>>>>> - ipa-server-install --uninstall -U >>>>>> - ipa-restore >>>>>> - ran the unit tests >>>>>> >>>>>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>>>>> directories. Are these needed? >>>>>> >>>>>> Probably not. I gathered some of the files to backup based on >>>>>> watching >>>>>> what files that changed during an install that are independent of us. >>>>>> I'll take another pass through it, there may be other oddities too. >>>>>> >>>>>>> The tool runners (install/tools/ipa-backup and >>>>>>> install/tools/ipa-restore) are missing, so IPA doesn't build. >>>>>>> Probably >>>>>>> just a forgotten git add. >>>>>> >>>>>> Yup. >>>>>> >>>>>>> >>>>>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>>>>> consider adding $(NULL) at the end. >>>>>> >>>>>> I'll take a look. >>>>>> >>>>>>> >>>>>>> Backup.dirs, Backup.files, Backup.logs: >>>>>>> The code modifies these class-level attributes. This means you can't >>>>>>> run >>>>>>> the command more than once in one Python session, so it can't be >>>>>>> used as >>>>>>> a library (e.g. in a hypothetical test suite). >>>>>>> Please make the class atrributes immutable (tuples), then in >>>>>>> __init__ do >>>>>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>>>>> >>>>>> Ok, fair point. >>>>>> >>>>>>> Code that creates temporary files/directories or does chdir() >>>>>>> should be >>>>>>> next to (or in) a try block whose finally: restores things. >>>>>> >>>>>> Yes, I mean to add a big try/finally block around everything in run >>>>>> eventually (or the equivalent anyway). >>>>>> >>>>>>> >>>>>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>>>>> please explicitly import whatever you're using from that package. In >>>>>>> this case, nothing at all! >>>>>> >>>>>> Yeah, I haven't run this through pylint yet to see all the bad >>>>>> imports I >>>>>> cobbled together. >>>>>> >>>>>>> If there's a get_connection() method, it should return the >>>>>>> connection, >>>>>>> and it should always be used to get it. Store the connection in >>>>>>> self._conn, and rather than: >>>>>>> self.get_connection() >>>>>>> self.conn.do_work() >>>>>>> do: >>>>>>> conn = self.get_connection() >>>>>>> conn.do_work() >>>>>>> This makes forgetting to call get_connection() impossible. >>>>>> >>>>>> My purpose was to avoid creating multiple connections. >>>>>> >>>>>>> If a variable is only used in a single method, like `filename` in >>>>>>> Restore.extract_backup, don't store it in the admintool object. >>>>>>> In general, try to avoid putting data in self if possible. It's >>>>>>> convenient but it allows complex interdependencies. >>>>>>> (Yes, I'm guilty of not following this myself.) >>>>>> >>>>>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a >>>>>> rush >>>>>> to get this WIP out. >>>>>> >>>>>>> In several places, the backup tool logs critical errors and then >>>>>>> just >>>>>>> continues on. Is that by design? I think a nonzero exit code >>>>>>> would be >>>>>>> appropriate. >>>>>> >>>>>> I'll take a look at them, all I can say at this point is maybe. >>>>>> >>>>>>> In the ipa-restore man page, --backend is not documented. >>>>>>> >>>>>>> In db2ldif, db2bak, etc., a more conscise way to get the time >>>>>>> string is >>>>>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>>>>> >>>>>>> When validating --gpg-keyring, it would be good to check both files >>>>>>> (.sec and .pub). >>>>>> >>>>>> Ok, I can do those. >>>>>> >>>>>>> >>>>>>> Here: >>>>>>> if (self.backup_type != 'FULL' and not options.data_only and >>>>>>> not instances): >>>>>>> raise admintool.ScriptError('Cannot restore a data backup >>>>>>> into >>>>>>> an empty system') >>>>>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and >>>>>>> not >>>>>>> instances`? (I'd introduce a `data_only` flag to prevent confusion.) >>>>>> >>>>>> Yeah, looks like that should be an or. >>>>>> >>>>>>> In the ReplicationManager.check_repl_init reporting: use >>>>>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>>>>> include full days. I don't think anyone would wait long enough for >>>>>>> the >>>>>>> overflow, but better to be correct. >>>>>> >>>>>> Sure, I doubt anyone would wait 24 hours either but its a >>>>>> no-brainer to >>>>>> make it safe. >>>>> >>>>> I think I've addressed just about everything. >>>>> >>>>> The reason that /var/run/dirsrv and var/lock/dirsrv are included in >>>>> the >>>>> backup is for the case of a full restore. These directories are not >>>>> created/provided by the package itself, but by installing the first >>>>> instance, so we need the ownership/SELinux context preserved. >>>>> >>>>> One thing I need tested is restoring over top of new data with >>>>> multiple >>>>> replicas. So basically install, do a backup, add a bunch of data, >>>>> restore, re-initialize all the other masters and then confirm that ALL >>>>> the new data is gone. I think I've got the sequence right but this is >>>>> critical. >>>>> >>>>> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >>>>> 9/multi-instance DS configurations). >>>>> >>>>> One thing I tested was: >>>>> >>>>> - ipa-server-install >>>>> - ipa-backup >>>>> - ipa-server-install --uninstall -U >>>>> - ipa-restore ipa-full-... >>>>> >>>>> This will actually get your server back EXCEPT that dogtag won't >>>>> start. >>>>> This is because the log directories are created by the instance >>>>> creation. There are two solutions: backup with --logs or manually >>>>> re-create the log directories (there are several, depending on dogtag >>>>> version). >>>> >>>> Could backup without --logs save which directories are there, and >>>> restore create empty directories if they don't exist? To me >>>> re-initializing a completely wiped machine looks like a big gain for >>>> the >>>> extra effort. >>> >>> I went ahead and made this change, it wasn't a lot of work. >>> >>>> >>>> >>>> >>>> The spec changelog needs a small rebase. >>> >>> Done. >>> >>>> >>>> I've tested some scenarios and didn't find any other issues so far. >>>> >>>> I still want to test some more with upgraded masters; installing them >>>> takes some time. >>>> Also I still need to test CA replicas (with the DNAME patches removed). >>>> >>> >>> rob >> >> I found a bug with the following topology: >> >> [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] >> >> Running ipa-restore on the 3.2 instance tries to disable the CA >> replication agreement between the other two. >> However, deep in ReplicationManager.agreement_dn it uses its own DS >> instance name instead of the Dogtag-9-DS one, so the agreement isn't >> found and the restore fails. >> >> > > Yeah, I'm not 100% sure how to address that either. Is it safe to assume > that if the port is 7389 then the instance is pki-ca? The port was hardcoded so it is. > Or should we test > for the existence of the instance name like we do master/clone? > > I've also figured out why Update in Progress loops forever. It is > because the older ipa-replica-manage do not re-enable the replication > agreement, so replication can't continue. I'm not entirely sure how we > will need to go about fixing this, except through documentation. -- Petr? From pviktori at redhat.com Wed Apr 10 14:20:01 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 10 Apr 2013 16:20:01 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix output for some CLI commands In-Reply-To: <5162ED20.1050500@redhat.com> References: <5162ACBF.7040207@redhat.com> <5162C90A.9070301@redhat.com> <5162D537.6010800@redhat.com> <5162ED20.1050500@redhat.com> Message-ID: <51657511.5030707@redhat.com> On 04/08/2013 06:15 PM, Ana Krivokapic wrote: > On 04/08/2013 04:33 PM, Jan Cholasta wrote: >> On 8.4.2013 15:41, Jan Cholasta wrote: >>> Hi, >>> >>> On 8.4.2013 13:40, Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch addresses https://fedorahosted.org/freeipa/ticket/3503. See >>>> the commit message for details. >>>> >>> >>> the patch seems OK, I will just run the test suite to make sure you >>> didn't miss anything. >>> >>> Honza >>> >> >> Change dnszone_del summary to "Deleted DNS zone", as we use "DNS zone" >> (not just "zone") in other commands. Also as Petr pointed out, we're >> in string freeze now, so we have to wait until it's over before >> pushing this patch, or split the patch in two. >> >> Besides that, ACK. >> > > Thanks for the review. > > I have changed the summary message to "Deleted DNS zone", and split the > patch into two patches that can be applied independently. > We can break the string freeze with this small change, so ACK to both. -- Petr? From tbabej at redhat.com Wed Apr 10 14:42:59 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 10 Apr 2013 16:42:59 +0200 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <5164017C.1000101@redhat.com> References: <5164017C.1000101@redhat.com> Message-ID: <51657A73.9050006@redhat.com> On 04/09/2013 01:54 PM, Tomas Babej wrote: > Hi, > > In ipa-replica-manage commands, we enforce that hostnames we work > with are resolvable. However, this caused errors while deleting > or disconnecting a ipa / winsync replica, if that replica was down > and authoritative server for itself. > > https://fedorahosted.org/freeipa/ticket/3524 > > Tomas Attaching a fix for ipa-replica-manage which gracelly handles connection timeout. Please apply on top of 0045. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0046-Handle-connection-timeout-in-ipa-replica-manage.patch Type: text/x-patch Size: 2032 bytes Desc: not available URL: From mrorourke at earthlink.net Wed Apr 10 16:18:12 2013 From: mrorourke at earthlink.net (Michael ORourke) Date: Wed, 10 Apr 2013 12:18:12 -0400 (GMT-04:00) Subject: [Freeipa-devel] Wiki edit request Message-ID: <2838818.1365610693556.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Hello, I'd like to submit a HOW TO to the wiki for IPA 3rd party integration with the PWM project (http://code.google.com/p/pwm/). Could someone give me edit access to the wiki? Thanks, Mike From jfenal at gmail.com Wed Apr 10 16:26:58 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Wed, 10 Apr 2013 18:26:58 +0200 Subject: [Freeipa-devel] FreeIPA string freeze In-Reply-To: References: <5162E61A.5060700@redhat.com> <516540D6.3040001@redhat.com> Message-ID: <516592D2.5090207@gmail.com> Le 10/04/2013 14:27, Yuri Chornoivan a ?crit : > Wed, 10 Apr 2013 13:37:10 +0300 ???? ???????? Petr Viktorin > : > >> On 04/08/2013 05:54 PM, Yuri Chornoivan wrote: >>> ???????? Mon, 08 Apr 2013 18:45:30 +0300, Petr Viktorin >>> : >>> >>>> Hello, FreeIPA translators! >>>> >>>> We wanted to give enough time for translations, so we made an upstream >>>> string freeze last week, giving about two weeks of translation time >>>> until the beta. >>>> We didn't expect most of the translations to be done already -- >>>> Ukrainian at 100% and French with 40 strings missing. Thank you!! >>>> >>>> Meanwhile we have some fixes upstream that add/change additional >>>> strings that would have to be postponed for the next release. >>>> How much would it inconvenience you if instead of postponing the >>>> patches, we'd push each change to Transifex as it is pushed to master? >>>> >>>> In the past J?r?me said that updating continuously would be better >>>> than the string freezes and mass updates we do now. We don't have >>>> resources to automate that*, but for slipping a few strings past >>>> string freeze it could work. >>>> >>> >>> Hi, >>> >>> Surely, it would be good to have fixes now (as well as some announce in >>> trans at lists.fedoraproject.org ). >>> >>> And I'm all of the J?r?me's proposal. It is enough to have updates >>> every >>> 3-4 months. That will make the translation process significantly >>> easier. >>> >> >> Okay. I've pushed the updates to Transifex (7 new strings, expect a >> couple more), and I'll do some more frequent updates in the future. > > Thanks for your work. And you have my thank you as well. As we tend to agree for at least two mostly/fully translated languages, I'd say that yes, regular updates (could be every 2 or 3 or 4 weeks to have strings to translate, but not too many in a row) would be easier for everybody to catch up. >> I've lurked on trans at lists.fedoraproject.org for a while and haven't >> seen many announcements from projects. Is it the right list to >> communicate string freezes/deadlines/releases? > > Yes. This is the right list for Fedora translation announces. > Personally, I do not know why other Fedora Upstream projects do not > announce their translation dates in this list. It is easy to send a > message there and target Fedora translation coordinators of many > languages at once. > > Yes, it might happen that you will not obtain much translations at > once, but I cannot imagine the other way to contact new translators. > > Such strategy (regular announces in translator's mailing lists) works > fine in many projects (KDE, GNOME, Audacity etc.) It's a win-win > situation. You cannot lose if you make even one-sentence announces and > do it regularly. What could be done here is to show some role model. While it is good for translators, some projects may also rely on the fact that their own translators catch up by subscribing to their own project updates in Transifex, which gives them the go to translate remaining strings. This is for instance how it works for a few ones in the French team. But I also agree that broadly announced strings freezes, and broad and regular calls to contributions will get further attention for languages that do not have yet the level of contributions Ukrainian or French currently have. Last item, I've been quite busy by day work these days, but I'm also working on a way to automate splitting huge strings such as the plugins help/usage pages in smaller chunks (a 15 min draft of the script seems to work for those plugins, attached if you want to have a look at it). I did not test it yet to see the final result, and I also need to work on doing the same on the .po files in order to avoid manually splitting the translations. I will keep you posted here when I have something. Regards, J. -------------- next part -------------- #!/usr/bin/perl use strict; use warnings; my $huge_string; # read the file completely undef $/; $_=<>; # ok $huge_string = $1 if m{__doc__ \s* = \s* \_ \( \s* ["]["]["] ( .*? ) ["]["]["] \s* \)}imxsg; my $new_string = $huge_string; $new_string =~ s{\n\n}{\n""")\n . _("""\n}g; print $new_string; # ok my $title = $1 if $huge_string =~ m{ \n (.*?) \n }imxs; print "Title: $title\n"; From rcritten at redhat.com Wed Apr 10 18:02:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Apr 2013 14:02:49 -0400 Subject: [Freeipa-devel] [PATCH] 1095 apply updates in order Message-ID: <5165A949.9090700@redhat.com> The original design of the LDAP updater was to use numbered update files which would be applied in order in blocks of 10. We ended up just applying everything together, sorted by length of the DN. This works ok except in the case of roles/privileges/permissions wehre it is possible that a role is added to a permission before the role is created. So the permission has no memberOf attribute and things don't work as expected. So this patch implements the by-10 rule and applies the files 10-19, 20-29, etc. I left the ability to run unstructured updates too by default. We also need to revert this commit which breaks a test case now that roles/permissions are created properly, f7e27b547547be06f511a3ddfaff8db7d0b7898f rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1095-update.patch Type: text/x-patch Size: 6230 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 10 18:27:21 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Apr 2013 14:27:21 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <51656EE9.3080108@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5163EBF2.8080004@redhat.com> <51648646.6070706@redhat.com> <51656EE9.3080108@redhat.com> Message-ID: <5165AF09.2030007@redhat.com> Petr Viktorin wrote: > On 04/09/2013 11:21 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/05/2013 10:54 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 03/23/2013 05:06 AM, Rob Crittenden wrote: >>>>>>>>> There are strict limits on what can be restored where. Only exact >>>>>>>>> matching hostnames and versions are allowed right now. We can >>>>>>>>> probably >>>>>>>>> relax the hostname requirement if we're only restoring data, and >>>>>>>>> the >>>>>>>>> version perhaps for only the the first two values (so you can >>>>>>>>> restore a >>>>>>>>> 3.0.0 backup on 3.0.1 but not on 3.1.0). >>>>>>>> >>>>>>>> Do we also need to limit the versions of Dogtag, 389, Kerberos...? >>>>>>>> Or is what they put in /var/lib guaranteed portable across >>>>>>>> versions? >>>>>>> >>>>>>> An interesting question. I'd imagine that a major db change would >>>>>>> also >>>>>>> require a major update to IPA, therefore if we restrict by IPA >>>>>>> version >>>>>>> we should be ok. I AM doing an untar of files though so yeah, there >>>>>>> is a >>>>>>> risk here. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> That's good to hear! >>>>>>>> >>>>>>>> I think while developing, you should run with -v to get all the >>>>>>>> output. >>>>>>>> And for production, please have the commands log by default (set >>>>>>>> log_file_name). >>>>>>> >>>>>>> Yes, I plan on adding that in the future. >>>>>>> >>>>>>>> >>>>>>>>> ipa-backup does all its binds using ldapi. ipa-restore needs >>>>>>>>> the DM >>>>>>>>> password because we need to contact remote servers to >>>>>>>>> enable/disable >>>>>>>>> replication. >>>>>>>> >>>>>>>> The restore assumes that ipa is already installed, right? I can't >>>>>>>> just >>>>>>>> run it on a clean machine? Id would be good to check/document this. >>>>>>> >>>>>>> It depends. >>>>>>> >>>>>>> For a full backup you can actually restore to an uninstalled >>>>>>> server. In >>>>>>> fact, you could restore to a machine w/no IPA bits on it at all in >>>>>>> all >>>>>>> likelihood (which wouldn't be very nice, but not exactly wrong >>>>>>> either >>>>>>> IMHO). >>>>>>> >>>>>>> I tested this with: >>>>>>> - ipa-server-install >>>>>>> - ipa-backup >>>>>>> - ipa-server-install --uninstall -U >>>>>>> - ipa-restore >>>>>>> - ran the unit tests >>>>>>> >>>>>>>> I looked in the backup tarball and saw dirsrv PID file and lock >>>>>>>> directories. Are these needed? >>>>>>> >>>>>>> Probably not. I gathered some of the files to backup based on >>>>>>> watching >>>>>>> what files that changed during an install that are independent of >>>>>>> us. >>>>>>> I'll take another pass through it, there may be other oddities too. >>>>>>> >>>>>>>> The tool runners (install/tools/ipa-backup and >>>>>>>> install/tools/ipa-restore) are missing, so IPA doesn't build. >>>>>>>> Probably >>>>>>>> just a forgotten git add. >>>>>>> >>>>>>> Yup. >>>>>>> >>>>>>>> >>>>>>>> The patch adds an extra backslash in install/tools/man/Makefile.am; >>>>>>>> consider adding $(NULL) at the end. >>>>>>> >>>>>>> I'll take a look. >>>>>>> >>>>>>>> >>>>>>>> Backup.dirs, Backup.files, Backup.logs: >>>>>>>> The code modifies these class-level attributes. This means you >>>>>>>> can't >>>>>>>> run >>>>>>>> the command more than once in one Python session, so it can't be >>>>>>>> used as >>>>>>>> a library (e.g. in a hypothetical test suite). >>>>>>>> Please make the class atrributes immutable (tuples), then in >>>>>>>> __init__ do >>>>>>>> `self.dirs = list(self.dirs)` to to get instance-specific lists. >>>>>>> >>>>>>> Ok, fair point. >>>>>>> >>>>>>>> Code that creates temporary files/directories or does chdir() >>>>>>>> should be >>>>>>>> next to (or in) a try block whose finally: restores things. >>>>>>> >>>>>>> Yes, I mean to add a big try/finally block around everything in run >>>>>>> eventually (or the equivalent anyway). >>>>>>> >>>>>>>> >>>>>>>> Instead of star imports (from ipapython.ipa_log_manager import *), >>>>>>>> please explicitly import whatever you're using from that >>>>>>>> package. In >>>>>>>> this case, nothing at all! >>>>>>> >>>>>>> Yeah, I haven't run this through pylint yet to see all the bad >>>>>>> imports I >>>>>>> cobbled together. >>>>>>> >>>>>>>> If there's a get_connection() method, it should return the >>>>>>>> connection, >>>>>>>> and it should always be used to get it. Store the connection in >>>>>>>> self._conn, and rather than: >>>>>>>> self.get_connection() >>>>>>>> self.conn.do_work() >>>>>>>> do: >>>>>>>> conn = self.get_connection() >>>>>>>> conn.do_work() >>>>>>>> This makes forgetting to call get_connection() impossible. >>>>>>> >>>>>>> My purpose was to avoid creating multiple connections. >>>>>>> >>>>>>>> If a variable is only used in a single method, like `filename` in >>>>>>>> Restore.extract_backup, don't store it in the admintool object. >>>>>>>> In general, try to avoid putting data in self if possible. It's >>>>>>>> convenient but it allows complex interdependencies. >>>>>>>> (Yes, I'm guilty of not following this myself.) >>>>>>> >>>>>>> Yes, there is certainly a bit of cleanup to do. I was in a bit of a >>>>>>> rush >>>>>>> to get this WIP out. >>>>>>> >>>>>>>> In several places, the backup tool logs critical errors and then >>>>>>>> just >>>>>>>> continues on. Is that by design? I think a nonzero exit code >>>>>>>> would be >>>>>>>> appropriate. >>>>>>> >>>>>>> I'll take a look at them, all I can say at this point is maybe. >>>>>>> >>>>>>>> In the ipa-restore man page, --backend is not documented. >>>>>>>> >>>>>>>> In db2ldif, db2bak, etc., a more conscise way to get the time >>>>>>>> string is >>>>>>>> `time.strftime('export_%Y_%m_%d_%H_%M_%S')`. >>>>>>>> >>>>>>>> When validating --gpg-keyring, it would be good to check both files >>>>>>>> (.sec and .pub). >>>>>>> >>>>>>> Ok, I can do those. >>>>>>> >>>>>>>> >>>>>>>> Here: >>>>>>>> if (self.backup_type != 'FULL' and not options.data_only and >>>>>>>> not instances): >>>>>>>> raise admintool.ScriptError('Cannot restore a data backup >>>>>>>> into >>>>>>>> an empty system') >>>>>>>> did you mean `(self.backup_type != 'FULL' or options.data_only) and >>>>>>>> not >>>>>>>> instances`? (I'd introduce a `data_only` flag to prevent >>>>>>>> confusion.) >>>>>>> >>>>>>> Yeah, looks like that should be an or. >>>>>>> >>>>>>>> In the ReplicationManager.check_repl_init reporting: use >>>>>>>> int(d.total_seconds()) instead of d.seconds, as the latter doesn't >>>>>>>> include full days. I don't think anyone would wait long enough for >>>>>>>> the >>>>>>>> overflow, but better to be correct. >>>>>>> >>>>>>> Sure, I doubt anyone would wait 24 hours either but its a >>>>>>> no-brainer to >>>>>>> make it safe. >>>>>> >>>>>> I think I've addressed just about everything. >>>>>> >>>>>> The reason that /var/run/dirsrv and var/lock/dirsrv are included in >>>>>> the >>>>>> backup is for the case of a full restore. These directories are not >>>>>> created/provided by the package itself, but by installing the first >>>>>> instance, so we need the ownership/SELinux context preserved. >>>>>> >>>>>> One thing I need tested is restoring over top of new data with >>>>>> multiple >>>>>> replicas. So basically install, do a backup, add a bunch of data, >>>>>> restore, re-initialize all the other masters and then confirm that >>>>>> ALL >>>>>> the new data is gone. I think I've got the sequence right but this is >>>>>> critical. >>>>>> >>>>>> This should work on fresh installs and upgrades from 3.0 (e.g. dogtag >>>>>> 9/multi-instance DS configurations). >>>>>> >>>>>> One thing I tested was: >>>>>> >>>>>> - ipa-server-install >>>>>> - ipa-backup >>>>>> - ipa-server-install --uninstall -U >>>>>> - ipa-restore ipa-full-... >>>>>> >>>>>> This will actually get your server back EXCEPT that dogtag won't >>>>>> start. >>>>>> This is because the log directories are created by the instance >>>>>> creation. There are two solutions: backup with --logs or manually >>>>>> re-create the log directories (there are several, depending on dogtag >>>>>> version). >>>>> >>>>> Could backup without --logs save which directories are there, and >>>>> restore create empty directories if they don't exist? To me >>>>> re-initializing a completely wiped machine looks like a big gain for >>>>> the >>>>> extra effort. >>>> >>>> I went ahead and made this change, it wasn't a lot of work. >>>> >>>>> >>>>> >>>>> >>>>> The spec changelog needs a small rebase. >>>> >>>> Done. >>>> >>>>> >>>>> I've tested some scenarios and didn't find any other issues so far. >>>>> >>>>> I still want to test some more with upgraded masters; installing them >>>>> takes some time. >>>>> Also I still need to test CA replicas (with the DNAME patches >>>>> removed). >>>>> >>>> >>>> rob >>> >>> I found a bug with the following topology: >>> >>> [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] >>> >>> Running ipa-restore on the 3.2 instance tries to disable the CA >>> replication agreement between the other two. >>> However, deep in ReplicationManager.agreement_dn it uses its own DS >>> instance name instead of the Dogtag-9-DS one, so the agreement isn't >>> found and the restore fails. >>> >>> >> >> Yeah, I'm not 100% sure how to address that either. Is it safe to assume >> that if the port is 7389 then the instance is pki-ca? > > The port was hardcoded so it is. Ok, just thanks for the other set of eyes. Updated patch attached. rob > >> Or should we test >> for the existence of the instance name like we do master/clone? >> >> I've also figured out why Update in Progress loops forever. It is >> because the older ipa-replica-manage do not re-enable the replication >> agreement, so replication can't continue. I'm not entirely sure how we >> will need to go about fixing this, except through documentation. > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1093-4-backup.patch Type: text/x-patch Size: 78709 bytes Desc: not available URL: From akrivoka at redhat.com Wed Apr 10 18:44:24 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Wed, 10 Apr 2013 20:44:24 +0200 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts Message-ID: <5165B308.2020804@redhat.com> Hello, This patch set deprecates HBAC source hosts from IPA. See commit messages and the design page[1] for details. https://fedorahosted.org/freeipa/ticket/3528 [1] http://www.freeipa.org/page/V3/HBACSourceHosts -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0014-Remove-HBAC-source-hosts-from-web-UI.patch Type: text/x-patch Size: 7134 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0015-Remove-any-reference-to-HBAC-source-hosts-from-help.patch Type: text/x-patch Size: 3933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0016-Deprecate-HBAC-source-hosts-from-CLI.patch Type: text/x-patch Size: 33566 bytes Desc: not available URL: From rcritten at redhat.com Wed Apr 10 19:35:48 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Apr 2013 15:35:48 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365543559.2015.20.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> Message-ID: <5165BF14.40209@redhat.com> Nathaniel McCallum wrote: > On Thu, 2013-04-04 at 11:59 -0400, Rob Crittenden wrote: >> Nathaniel McCallum wrote: >>> On Fri, 2013-03-08 at 09:50 -0500, Simo Sorce wrote: >>>> On Wed, 2013-03-06 at 13:04 -0500, Nathaniel McCallum wrote: >>>>> On Wed, 2013-03-06 at 12:56 -0500, Nathaniel McCallum wrote: >>>>>> Patch is attached. >>>>>> >>>>>> There are currently a few security downsides to this patch: >>>>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously >>>>>> 2. ipatokenRadiusSecret is readable by an anonymous bind >>>>>> >>>>>> This patch also adds some new dependencies, namely: >>>>>> 1. libverto (a dependency of krb5) >>>>>> 2. systemd >>>>>> 3. a krb5 patched for libk5radius support [1] >>>>>> >>>>>> In the interest of trying to meet the Fedora Features deadline, I am >>>>>> providing the patch in spite of the above issues. >>>>>> >>>>>> Nathaniel >>>>>> >>>>>> 1 - http://bit.ly/ZqtK79 >>>>> >>>>> Also, I assumed the usability of 2.16.840.1.113730.3.8.16 for the >>>>> schema. This will need to be verified and finalized. >>>> >>>> I reserved this OID space for ipa OTP schema. >>> >>> Thanks! For posterity, where is this documented? >>> >>> Nathaniel >> >> In daemons/configure.ac you fix up the inconsistent tab/spacing we use >> when displaying a summary for IPA Server, except you add a tab in the >> CFLAGS line. > > Fixed. > >> Trailing white space in 70ipaotp.ldif > > Fixed. > >> Just a style thing, you use tmp as a variable a lot to do somewhat beefy >> things (e.g. find_base()) > > Fixed. > >> Does hostname need to be fully-qualified? We enforce this during the >> install but things change. I don't know if that is important for this >> daemon. > > Hostname is only used for looking up results in the RADIUS configuration > on the server side. It is up to the admin to ensure a match here (the > admin will have to do it manually anyway). Ok. Kerberos can be twitchy about FQDN :-) >> ENOMEM is used as an error code when some things fail, sometimes in >> favor of the real error message: >> >> + /* Set Service-Type. */ >> + retval = k5_radius_attrset_add_number(ctx.attrs, >> + k5_radius_attr_name2num("Service-Type"), >> + >> K5_RADIUS_SERVICE_TYPE_AUTHENTICATE_ONLY); >> + if (retval != 0) { >> + log_err(ENOMEM, "Unable to set Service-Type"); >> + goto error; >> + } > > Fixed. > >> No man pages > > Do we make man pages for socket-activated processes in /usr/libexec? > Running this directly never makes sense... I suppose not. Then again someone might see this in ps output and wonder what the heck it is :-) Not a show stopper IMHO. >> In setup_ldap() there might be an inconsequential memory leak. If there >> is no base, and one is found, but some later part of the LDAP sequence >> fails an error will be returned but the base will remain set. It seems >> that you quit on all setup_ldap() failures so this is probably no big deal. > > Fixed. You don't actually seem to use the rv from setup_ldap() other than whether it is non-zero so it may not be important. Think about where problems might occur and what debugging would be useful in tracking down the fixes. It may be that simply adding logging is ok and returning 1/0 is enough. My problem with systemd is that it seems to make things more opaque. It is hard to do even simple things like an strace on process startup because the shell is completely detached from execution. Which means that your logging needs to be top-notch so when things go wrong we can look somewhere and say "aha, it's X" >> In on_query_readable() is it an error if multiple entries are returned? >> And there is tmp again. I had to do a double-take on the return value of >> the parse_ commands to realize that tmp was the error string. > > This is a good question. In theory there should never be multiple > entries. Is there something that looks broken here? I'm not sure if we > should error in this case or if we should silently proceed... So far > I've chosen the second option and I fixed a memory leak that occurs if > multiple entries are received. It wasn't a leading question. If there won't be multiple entries returned then I think we're ok. >> It doesn't look like the LDAP entry is freed in on_query_readable(). > > Fixed. > >> We'll need to handle upgrades eventually too. > > I'm not sure of the implications here. I thought this was done by > copy-schema-to-ca.py. But I guess I'm wrong. When upgrading an IPA server new LDIF files are not copied around. We are actually working on changing this in the future, but for now you'll need to create a .update file in install/updates which creates the schema. You can use install/updates/10-selinuxusermap.update as an example. >> Can you add the ticket(s) to the git commit message. >> >> If there are any wiki design pages it would help to point to those. > > http://freeipa.org/page/V3/OTP With commit messages the format should be something like: One-line description of reason for commit (you're good there). One or more paragraphs describing the problem and solution. Anything that can be useful. Space is cheap, so write a book if you want (see some of John's commits). URL for trac ticket Design URL (if any) When we close the ticket we will include the commit messages. This way it is easy to find a ticket or a fix multiple ways, and to some extent helps us figure out what release a change dropped into. >> You'll need to add the new BuildRequires to freeipa.spec.in too. > > Fixed. > >> There isn't a lot of documentation on what each of these files/functions >> are supposed to do. > > Fixed. You might want to add a README with either a pointer to the design URL or the architecture statement from the design page. That pretty well describes what this is supposed to do. Again, not a show-stopper, just think of the poor developer who comes along in a year to try to understand how this works. I was a little baffled by the reason for the whole stdio stuff until I saw the design page. > The latest version of the patch is here: > https://github.com/npmccallum/freeipa/commit/0d126d4c2449787527f7b507029ceba8aea1eb4c > > Also note that you can now build this patch against krb5 1.11 in Fedora > rawhide (and f19 when the alpha freeze lifts). I'm not sure how I'd test it if I got it built. Overall looks really good. rob From simo at redhat.com Wed Apr 10 19:41:30 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Apr 2013 15:41:30 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <5165BF14.40209@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> Message-ID: <1365622890.20560.95.camel@willson.li.ssimo.org> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > My problem with systemd is that it seems to make things more opaque. > It > is hard to do even simple things like an strace on process startup > because the shell is completely detached from execution. Which means > that your logging needs to be top-notch so when things go wrong we > can > look somewhere and say "aha, it's X" > Actually with systemd logging has become easier. All you need to do is spit stuff to stdout (of course you must avoid closing stdout if the daemon does so as they used to do to cope with sysv init madness :) Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Apr 10 19:46:06 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Apr 2013 15:46:06 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365622890.20560.95.camel@willson.li.ssimo.org> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365622890.20560.95.camel@willson.li.ssimo.org> Message-ID: <5165C17E.60409@redhat.com> Simo Sorce wrote: > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: >> My problem with systemd is that it seems to make things more opaque. >> It >> is hard to do even simple things like an strace on process startup >> because the shell is completely detached from execution. Which means >> that your logging needs to be top-notch so when things go wrong we >> can >> look somewhere and say "aha, it's X" >> > > Actually with systemd logging has become easier. > All you need to do is spit stuff to stdout (of course you must avoid > closing stdout if the daemon does so as they used to do to cope with > sysv init madness :) Yes, it is a mixed bag. Doesn't replace the sweetness of strace /etc/init.d/service start to find startup permission issues. If your daemon doesn't log that it is failing because it can't open some file then you're in deep. rob From simo at redhat.com Wed Apr 10 19:56:28 2013 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Apr 2013 15:56:28 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <5165C17E.60409@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365622890.20560.95.camel@willson.li.ssimo.org> <5165C17E.60409@redhat.com> Message-ID: <1365623788.20560.100.camel@willson.li.ssimo.org> On Wed, 2013-04-10 at 15:46 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > >> My problem with systemd is that it seems to make things more opaque. > >> It > >> is hard to do even simple things like an strace on process startup > >> because the shell is completely detached from execution. Which means > >> that your logging needs to be top-notch so when things go wrong we > >> can > >> look somewhere and say "aha, it's X" > >> > > > > Actually with systemd logging has become easier. > > All you need to do is spit stuff to stdout (of course you must avoid > > closing stdout if the daemon does so as they used to do to cope with > > sysv init madness :) > > Yes, it is a mixed bag. Doesn't replace the sweetness of strace > /etc/init.d/service start to find startup permission issues. If your > daemon doesn't log that it is failing because it can't open some file > then you're in deep. OTOH strace /etc/init.d/service start will almost certainly run unconfined, so if the access issue is due to selinux policy you'll be left with a fist of flies anyway. That said I think you can change the systemd unit file to run a shell script with strace /usr/bin/myexec in it, have not tried that one yet though. Simo. -- Simo Sorce * Red Hat, Inc * New York From npmccallum at redhat.com Wed Apr 10 20:02:37 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Wed, 10 Apr 2013 16:02:37 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365623788.20560.100.camel@willson.li.ssimo.org> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365622890.20560.95.camel@willson.li.ssimo.org> <5165C17E.60409@redhat.com> <1365623788.20560.100.camel@willson.li.ssimo.org> Message-ID: <1365624157.21323.0.camel@localhost.localdomain> On Wed, 2013-04-10 at 15:56 -0400, Simo Sorce wrote: > On Wed, 2013-04-10 at 15:46 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > > >> My problem with systemd is that it seems to make things more opaque. > > >> It > > >> is hard to do even simple things like an strace on process startup > > >> because the shell is completely detached from execution. Which means > > >> that your logging needs to be top-notch so when things go wrong we > > >> can > > >> look somewhere and say "aha, it's X" > > >> > > > > > > Actually with systemd logging has become easier. > > > All you need to do is spit stuff to stdout (of course you must avoid > > > closing stdout if the daemon does so as they used to do to cope with > > > sysv init madness :) > > > > Yes, it is a mixed bag. Doesn't replace the sweetness of strace > > /etc/init.d/service start to find startup permission issues. If your > > daemon doesn't log that it is failing because it can't open some file > > then you're in deep. > > OTOH strace /etc/init.d/service start will almost certainly run > unconfined, so if the access issue is due to selinux policy you'll be > left with a fist of flies anyway. > > That said I think you can change the systemd unit file to run a shell > script with strace /usr/bin/myexec in it, have not tried that one yet > though. I'd love an option to start a socket activated daemon in valgrind. That would be very useful... Nathaniel From rcritten at redhat.com Wed Apr 10 22:01:25 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 10 Apr 2013 18:01:25 -0400 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts In-Reply-To: <5165B308.2020804@redhat.com> References: <5165B308.2020804@redhat.com> Message-ID: <5165E135.1090007@redhat.com> Ana Krivokapic wrote: > Hello, > > This patch set deprecates HBAC source hosts from IPA. > > See commit messages and the design page[1] for details. > > https://fedorahosted.org/freeipa/ticket/3528 > > [1] http://www.freeipa.org/page/V3/HBACSourceHosts Been a while since I've run the UI but I get an error in FF 18: Timestamp: 04/10/2013 05:43:31 PM Error: TypeError: e.messages is undefined Source File: https://rawhide2.greyoak.com/ipa/ui/js/freeipa/app.js Line: 1 The other changes seem to operate fine. I tested with an older client and got reasonable error messages back when I tried to do the various sourcehost things. I got an unknown error message with --add-sourcehost but it did include the text that the command is deprecated so I think this is acceptable. There isn't a lot we can do, I'm sorry we didn't add this exception in the beginning. I do wonder if we should leave the warning in hbactest if sourcehost is set though, for those cases where there are already options set. rob From dpal at redhat.com Wed Apr 10 23:26:11 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Apr 2013 19:26:11 -0400 Subject: [Freeipa-devel] Wiki edit request In-Reply-To: <2838818.1365610693556.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> References: <2838818.1365610693556.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Message-ID: <5165F513.70300@redhat.com> On 04/10/2013 12:18 PM, Michael ORourke wrote: > Hello, > > I'd like to submit a HOW TO to the wiki for IPA 3rd party integration with the PWM project (http://code.google.com/p/pwm/). > > Could someone give me edit access to the wiki? > > Thanks, > Mike > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Done. Let me know if it did not work. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Apr 10 23:26:50 2013 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Apr 2013 19:26:50 -0400 Subject: [Freeipa-devel] Wiki edit request In-Reply-To: <2838818.1365610693556.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> References: <2838818.1365610693556.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net> Message-ID: <5165F53A.8010106@redhat.com> On 04/10/2013 12:18 PM, Michael ORourke wrote: > Hello, > > I'd like to submit a HOW TO to the wiki for IPA 3rd party integration with the PWM project (http://code.google.com/p/pwm/). > > Could someone give me edit access to the wiki? > > Thanks, > Mike > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Do you plan to develop a special plugin for the FreeIPA UI? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Thu Apr 11 09:30:18 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 11 Apr 2013 11:30:18 +0200 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <516518EF.8060902@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> <51641F6A.6030500@redhat.com> <1365517163.20560.32.camel@willson.li.ssimo.org> <51643132.1030007@redhat.com> <1365523860.20560.40.camel@willson.li.ssimo.org> <5164A9C2.2090107@redhat.com> <516518EF.8060902@redhat.com> Message-ID: <516682AA.2040206@redhat.com> On 10.4.2013 09:46, Martin Kosek wrote: > On 04/10/2013 01:52 AM, Dmitri Pal wrote: >> On 04/09/2013 12:11 PM, Simo Sorce wrote: >>> On Tue, 2013-04-09 at 11:18 -0400, Dmitri Pal wrote: >>>> On 04/09/2013 10:19 AM, Simo Sorce wrote: >>>>> On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote: >>>>>> On 04/08/2013 05:09 PM, Martin Kosek wrote: >>>>>>> On 04/08/2013 03:47 PM, Dmitri Pal wrote: >>>>>>>> On 04/08/2013 08:42 AM, Martin Kosek wrote: >>>>>>>>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: >>>>>>>>>> On 8.4.2013 10:47, Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> this patch fixes . >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>> Re-sending with correct subject. >>>>>>>>>> >>>>>>>>> I tested the change both for upgrades and for fresh installs and it worked fine >>>>>>>>> both cases, even when testing with Firefox enforcing mode. >>>>>>>>> >>>>>>>>> So far, as the biggest issue in current process I see NSS not being able to >>>>>>>>> fallback to other defined OCSP responder (I tested with Firefox 20). This way, >>>>>>>>> Firefox will fail validating the FreeIPA site when the first tested OCSP >>>>>>>>> responder is not available (e.g. the original IPA CA signing the http cert, or >>>>>>>>> an `ipa-ca.$domain` host that is currently not up). >>>>>>>> Have we filed a ticket with FF? >>>>>>> AFAIU, this is rather NSS issue, that Firefox issue. There is a bug open for NSS: >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=797815 >>>>>>> >>>>>>> Rob seems to have more context about this bug background. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> We may want to wait with pushing this patch until we get some response in the >>>>>> NSS Bugzilla above. If our request is rejected, we may be forced to use just a >>>>>> single CRL/OCSP (which would be probably the general one) and thus supersede >>>>>> patch 123. >>>>> Well it will have to depend on when you create certs. >>>>> The first IPA server own cert should probably point at the ipa server >>>>> name. Then we should warn in bold letters that the user should create >>>>> such and such a DNS name if they did not let IPA handle DNS. >>>>> >>>>> If we can handle DNS then any other use can refer to the common name >>>>> which can be an A name with multiple entries (each IPA CA server should >>>>> be listed there by default and the record should be changed at ca >>>>> replicas install/decommission time, however we should allow admins to >>>>> add/remove names as well manually in case they want to add proxies otr >>>>> conceal some of the CA servers. >>>>> >>>>> We may also want to change the RA client code to use that record to >>>>> fetch certs. >>>>> >>>>> Simo. >>>>> >>>> I see a lot of RFEs in this comment. >>>> Are we going to file them? >>> We'll see how NSS is going to respond to the ticket, and then adjust >>> accordingly. >>> >>> Simo. >>> >>> >> Well... time to adjust... accordingly ;-) >> > > Oh yes, see "adjusted" tickets > https://fedorahosted.org/freeipa/ticket/3552 > and > https://fedorahosted.org/freeipa/ticket/3547 > with a resolution how to handle the OCSP/CRL URIs. > > This supersedes the original Jan's patch 123. > Martin > Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-123.1-Use-http-instead-of-https-for-OCSP-and-CRL-URLs-in-I.patch Type: text/x-patch Size: 6573 bytes Desc: not available URL: From tbabej at redhat.com Thu Apr 11 10:05:05 2013 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 11 Apr 2013 12:05:05 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets Message-ID: <51668AD1.5000600@redhat.com> Hi, Makes DNAME target validation less strict and allows underscore. This is requirement for IPA sites. https://fedorahosted.org/freeipa/ticket/3550 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0047-Allow-underscore-in-DNAME-targets.patch Type: text/x-patch Size: 1744 bytes Desc: not available URL: From pviktori at redhat.com Thu Apr 11 10:11:04 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Apr 2013 12:11:04 +0200 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <5165AF09.2030007@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5163EBF2.8080004@redhat.com> <51648646.6070706@redhat.com> <51656EE9.3080108@redhat.com> <5165AF09.2030007@redhat.com> Message-ID: <51668C38.8020607@redhat.com> On 04/10/2013 08:27 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/09/2013 11:21 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 04/05/2013 10:54 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: [...] >>>>>>>>> And for production, please have the commands log by default (set >>>>>>>>> log_file_name). >>>>>>>> >>>>>>>> Yes, I plan on adding that in the future. One more comment here, shouldn't the log file be /var/log/iparestore.log rather than /var/log/ipa_restore.log, to match all the other IPA logs? [...] >>>>>> Could backup without --logs save which directories are there, and >>>>>> restore create empty directories if they don't exist? To me >>>>>> re-initializing a completely wiped machine looks like a big gain for >>>>>> the >>>>>> extra effort. >>>>> >>>>> I went ahead and made this change, it wasn't a lot of work. Another issue: if a CA was never installed on the host, pkiuser doesn't exist, and ipa-restore will fail on pwd.getpwnam(PKI_USER). And since /etc/passwd is restored, the obvious workaround of adding the user doesn't work. We need to mention in the docs that ipa-restore overwrites files we don't fully control (/etc/passwd, /ect/group, /etc/pki/nssdb/). We also restore named configuration even if IPA DNS is not installed, and smb.conf without AD trusts. [...] >>>> I found a bug with the following topology: >>>> >>>> [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] >>>> >>>> Running ipa-restore on the 3.2 instance tries to disable the CA >>>> replication agreement between the other two. >>>> However, deep in ReplicationManager.agreement_dn it uses its own DS >>>> instance name instead of the Dogtag-9-DS one, so the agreement isn't >>>> found and the restore fails. >>>> >>>> >>> >>> Yeah, I'm not 100% sure how to address that either. Is it safe to assume >>> that if the port is 7389 then the instance is pki-ca? >> >> The port was hardcoded so it is. > > Ok, just thanks for the other set of eyes. Updated patch attached. Yup, this is fixed, thanks. >>> Or should we test >>> for the existence of the instance name like we do master/clone? >>> >>> I've also figured out why Update in Progress loops forever. It is >>> because the older ipa-replica-manage do not re-enable the replication >>> agreement, so replication can't continue. I'm not entirely sure how we >>> will need to go about fixing this, except through documentation. Documentation works, but note that it'll affect anyone with a bunch of upgraded (Dogtag-9 style) instances. It may be a pretty common case in the wild. Maybe we need to recommend reinstalling replicas entirely, rather than re-initializing, just to be on the safe side. -- Petr? From akrivoka at redhat.com Thu Apr 11 11:09:33 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 11 Apr 2013 13:09:33 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS Message-ID: <516699ED.6060509@redhat.com> Integrate realmdomains with IPA DNS Add an entry to realmdomains when a DNS zone is added to IPA. Delete the related entry from realmdomains when the DNS zone is deleted from IPA. https://fedorahosted.org/freeipa/ticket/3544 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0017-Integrate-realmdomains-with-IPA-DNS.patch Type: text/x-patch Size: 1616 bytes Desc: not available URL: From pspacek at redhat.com Thu Apr 11 11:13:20 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Apr 2013 13:13:20 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516699ED.6060509@redhat.com> References: <516699ED.6060509@redhat.com> Message-ID: <51669AD0.30004@redhat.com> On 11.4.2013 13:09, Ana Krivokapic wrote: > Integrate realmdomains with IPA DNS > > Add an entry to realmdomains when a DNS zone is added to IPA. Delete the > related entry from realmdomains when the DNS zone is deleted from IPA. > > https://fedorahosted.org/freeipa/ticket/3544 I would add a TXT record as I described in https://fedorahosted.org/freeipa/ticket/3544#comment:8 Any objections? AB? -- Petr^2 Spacek From pspacek at redhat.com Thu Apr 11 11:14:13 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Apr 2013 13:14:13 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516699ED.6060509@redhat.com> References: <516699ED.6060509@redhat.com> Message-ID: <51669B05.30709@redhat.com> On 11.4.2013 13:09, Ana Krivokapic wrote: > Integrate realmdomains with IPA DNS > > Add an entry to realmdomains when a DNS zone is added to IPA. Delete the > related entry from realmdomains when the DNS zone is deleted from IPA. > > https://fedorahosted.org/freeipa/ticket/3544 I would add a TXT record as I described in https://fedorahosted.org/freeipa/ticket/3544#comment:8 This integration probably should go to both commands, realmdomains-* dnszone-*. Any objections? AB? -- Petr^2 Spacek From abokovoy at redhat.com Thu Apr 11 11:24:21 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Apr 2013 14:24:21 +0300 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <51669B05.30709@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> Message-ID: <20130411112421.GE6823@redhat.com> On Thu, 11 Apr 2013, Petr Spacek wrote: >On 11.4.2013 13:09, Ana Krivokapic wrote: >>Integrate realmdomains with IPA DNS >> >>Add an entry to realmdomains when a DNS zone is added to IPA. Delete the >>related entry from realmdomains when the DNS zone is deleted from IPA. >> >>https://fedorahosted.org/freeipa/ticket/3544 > >I would add a TXT record as I described in >https://fedorahosted.org/freeipa/ticket/3544#comment:8 > >This integration probably should go to both commands, realmdomains-* dnszone-*. > >Any objections? AB? Adding TXT record is probably harmless. I would actually add the TXT record creation only to realmdomains-* and trigger it only in case we manage our DNS and DNS zone is there. This way a hook from dnszone-add will trigger adding TXT record back (via call to realmdomains-mod --add and then TXT record addition from there). Also the fact that admin added manually some domain to realmdomains mapping means that it is implied to be used in obtaining TGTs, so TXT record is helpful there as well. -- / Alexander Bokovoy From pspacek at redhat.com Thu Apr 11 11:26:27 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Apr 2013 13:26:27 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <20130411112421.GE6823@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> Message-ID: <51669DE3.60904@redhat.com> On 11.4.2013 13:24, Alexander Bokovoy wrote: > On Thu, 11 Apr 2013, Petr Spacek wrote: >> On 11.4.2013 13:09, Ana Krivokapic wrote: >>> Integrate realmdomains with IPA DNS >>> >>> Add an entry to realmdomains when a DNS zone is added to IPA. Delete the >>> related entry from realmdomains when the DNS zone is deleted from IPA. >>> >>> https://fedorahosted.org/freeipa/ticket/3544 >> >> I would add a TXT record as I described in >> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >> >> This integration probably should go to both commands, realmdomains-* >> dnszone-*. >> >> Any objections? AB? > Adding TXT record is probably harmless. > > I would actually add the TXT record creation only to realmdomains-* and > trigger it only in case we manage our DNS and DNS zone is there. > This way a hook from dnszone-add will trigger adding TXT record back (via call to > realmdomains-mod --add and then TXT record addition from there). Also > the fact that admin added manually some domain to realmdomains mapping > means that it is implied to be used in obtaining TGTs, so TXT record is > helpful there as well. Okay, it makes sense. We will see how it will work in reality. -- Petr^2 Spacek From mkosek at redhat.com Thu Apr 11 11:28:06 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Apr 2013 13:28:06 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <51669DE3.60904@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> Message-ID: <51669E46.8060300@redhat.com> On 04/11/2013 01:26 PM, Petr Spacek wrote: > On 11.4.2013 13:24, Alexander Bokovoy wrote: >> On Thu, 11 Apr 2013, Petr Spacek wrote: >>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>> Integrate realmdomains with IPA DNS >>>> >>>> Add an entry to realmdomains when a DNS zone is added to IPA. Delete the >>>> related entry from realmdomains when the DNS zone is deleted from IPA. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3544 >>> >>> I would add a TXT record as I described in >>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>> >>> This integration probably should go to both commands, realmdomains-* >>> dnszone-*. >>> >>> Any objections? AB? >> Adding TXT record is probably harmless. >> >> I would actually add the TXT record creation only to realmdomains-* and >> trigger it only in case we manage our DNS and DNS zone is there. >> This way a hook from dnszone-add will trigger adding TXT record back (via >> call to >> realmdomains-mod --add and then TXT record addition from there). Also >> the fact that admin added manually some domain to realmdomains mapping >> means that it is implied to be used in obtaining TGTs, so TXT record is >> helpful there as well. > > Okay, it makes sense. We will see how it will work in reality. > This whole patch and functionality should also be covered with unit tests... Martin From pviktori at redhat.com Thu Apr 11 11:38:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Apr 2013 13:38:54 +0200 Subject: [Freeipa-devel] [PATCH] 1095 apply updates in order In-Reply-To: <5165A949.9090700@redhat.com> References: <5165A949.9090700@redhat.com> Message-ID: <5166A0CE.4080709@redhat.com> On 04/10/2013 08:02 PM, Rob Crittenden wrote: > The original design of the LDAP updater was to use numbered update files > which would be applied in order in blocks of 10. We ended up just > applying everything together, sorted by length of the DN. Why not just sort the files lexicographically, and _run_updates after each one? I can kind of see the reasoning behind the blocks of ten, but it looks pretty arbitrary and unnecessarily complex. It will allow you to create/update parents and children anywhere in the block of 10 and they'll be sorted properly, but outside of the blocks you have to watch the ordering. This is pretty confusing; if it's really needed it should at least be in the README. > This works ok except in the case of roles/privileges/permissions wehre > it is possible that a role is added to a permission before the role is > created. So the permission has no memberOf attribute and things don't > work as expected. > > So this patch implements the by-10 rule and applies the files 10-19, > 20-29, etc. I left the ability to run unstructured updates too by default. > > We also need to revert this commit which breaks a test case now that > roles/permissions are created properly, > f7e27b547547be06f511a3ddfaff8db7d0b7898f \o/ In the README, 10 - 19 should be Schema & configuration. While you're at it you can update the FDS Server reference (FDS was Fedora Directory Server, right?) -- Petr? From abokovoy at redhat.com Thu Apr 11 11:43:04 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Apr 2013 14:43:04 +0300 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <51669DE3.60904@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> Message-ID: <20130411114304.GF6823@redhat.com> On Thu, 11 Apr 2013, Petr Spacek wrote: >On 11.4.2013 13:24, Alexander Bokovoy wrote: >>On Thu, 11 Apr 2013, Petr Spacek wrote: >>>On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>Integrate realmdomains with IPA DNS >>>> >>>>Add an entry to realmdomains when a DNS zone is added to IPA. Delete the >>>>related entry from realmdomains when the DNS zone is deleted from IPA. >>>> >>>>https://fedorahosted.org/freeipa/ticket/3544 >>> >>>I would add a TXT record as I described in >>>https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>> >>>This integration probably should go to both commands, realmdomains-* >>>dnszone-*. >>> >>>Any objections? AB? >>Adding TXT record is probably harmless. >> >>I would actually add the TXT record creation only to realmdomains-* and >>trigger it only in case we manage our DNS and DNS zone is there. >>This way a hook from dnszone-add will trigger adding TXT record back (via call to >>realmdomains-mod --add and then TXT record addition from there). Also >>the fact that admin added manually some domain to realmdomains mapping >>means that it is implied to be used in obtaining TGTs, so TXT record is >>helpful there as well. > >Okay, it makes sense. We will see how it will work in reality. One more thing to check is that we don't do this for our own domain. -- / Alexander Bokovoy From mkosek at redhat.com Thu Apr 11 11:53:57 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Apr 2013 13:53:57 +0200 Subject: [Freeipa-devel] [PATCH] 123 Use http instead of https for OCSP and CRL URLs in IPA certificate profile In-Reply-To: <516682AA.2040206@redhat.com> References: <51628407.8060603@redhat.com> <51628476.7000203@redhat.com> <5162BB47.7020400@redhat.com> <5162CA5E.2010307@redhat.com> <5162DD99.2030403@redhat.com> <51641F6A.6030500@redhat.com> <1365517163.20560.32.camel@willson.li.ssimo.org> <51643132.1030007@redhat.com> <1365523860.20560.40.camel@willson.li.ssimo.org> <5164A9C2.2090107@redhat.com> <516518EF.8060902@redhat.com> <516682AA.2040206@redhat.com> Message-ID: <5166A455.1070904@redhat.com> On 04/11/2013 11:30 AM, Jan Cholasta wrote: > On 10.4.2013 09:46, Martin Kosek wrote: >> On 04/10/2013 01:52 AM, Dmitri Pal wrote: >>> On 04/09/2013 12:11 PM, Simo Sorce wrote: >>>> On Tue, 2013-04-09 at 11:18 -0400, Dmitri Pal wrote: >>>>> On 04/09/2013 10:19 AM, Simo Sorce wrote: >>>>>> On Tue, 2013-04-09 at 16:02 +0200, Martin Kosek wrote: >>>>>>> On 04/08/2013 05:09 PM, Martin Kosek wrote: >>>>>>>> On 04/08/2013 03:47 PM, Dmitri Pal wrote: >>>>>>>>> On 04/08/2013 08:42 AM, Martin Kosek wrote: >>>>>>>>>> On 04/08/2013 10:48 AM, Jan Cholasta wrote: >>>>>>>>>>> On 8.4.2013 10:47, Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> this patch fixes . >>>>>>>>>>>> >>>>>>>>>>>> Honza >>>>>>>>>>>> >>>>>>>>>>> Re-sending with correct subject. >>>>>>>>>>> >>>>>>>>>> I tested the change both for upgrades and for fresh installs and it >>>>>>>>>> worked fine >>>>>>>>>> both cases, even when testing with Firefox enforcing mode. >>>>>>>>>> >>>>>>>>>> So far, as the biggest issue in current process I see NSS not being >>>>>>>>>> able to >>>>>>>>>> fallback to other defined OCSP responder (I tested with Firefox 20). >>>>>>>>>> This way, >>>>>>>>>> Firefox will fail validating the FreeIPA site when the first tested OCSP >>>>>>>>>> responder is not available (e.g. the original IPA CA signing the http >>>>>>>>>> cert, or >>>>>>>>>> an `ipa-ca.$domain` host that is currently not up). >>>>>>>>> Have we filed a ticket with FF? >>>>>>>> AFAIU, this is rather NSS issue, that Firefox issue. There is a bug >>>>>>>> open for NSS: >>>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=797815 >>>>>>>> >>>>>>>> Rob seems to have more context about this bug background. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> We may want to wait with pushing this patch until we get some response >>>>>>> in the >>>>>>> NSS Bugzilla above. If our request is rejected, we may be forced to use >>>>>>> just a >>>>>>> single CRL/OCSP (which would be probably the general one) and thus >>>>>>> supersede >>>>>>> patch 123. >>>>>> Well it will have to depend on when you create certs. >>>>>> The first IPA server own cert should probably point at the ipa server >>>>>> name. Then we should warn in bold letters that the user should create >>>>>> such and such a DNS name if they did not let IPA handle DNS. >>>>>> >>>>>> If we can handle DNS then any other use can refer to the common name >>>>>> which can be an A name with multiple entries (each IPA CA server should >>>>>> be listed there by default and the record should be changed at ca >>>>>> replicas install/decommission time, however we should allow admins to >>>>>> add/remove names as well manually in case they want to add proxies otr >>>>>> conceal some of the CA servers. >>>>>> >>>>>> We may also want to change the RA client code to use that record to >>>>>> fetch certs. >>>>>> >>>>>> Simo. >>>>>> >>>>> I see a lot of RFEs in this comment. >>>>> Are we going to file them? >>>> We'll see how NSS is going to respond to the ticket, and then adjust >>>> accordingly. >>>> >>>> Simo. >>>> >>>> >>> Well... time to adjust... accordingly ;-) >>> >> >> Oh yes, see "adjusted" tickets >> https://fedorahosted.org/freeipa/ticket/3552 >> and >> https://fedorahosted.org/freeipa/ticket/3547 >> with a resolution how to handle the OCSP/CRL URIs. >> >> This supersedes the original Jan's patch 123. >> Martin >> > > Updated patch attached. > > Honza > I tested both with new installs and with upgrades. With upgrade, I just had to use certmonger to reissue httpd certificate and then I got OCSP validation working again (tested in Firefox with strict OCSP validation). ACK. Pushed to master, ipa-3-1. Martin From pspacek at redhat.com Thu Apr 11 12:18:31 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Apr 2013 14:18:31 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <20130411114304.GF6823@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> Message-ID: <5166AA17.4050406@redhat.com> On 11.4.2013 13:43, Alexander Bokovoy wrote: > On Thu, 11 Apr 2013, Petr Spacek wrote: >> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>> Integrate realmdomains with IPA DNS >>>>> >>>>> Add an entry to realmdomains when a DNS zone is added to IPA. Delete the >>>>> related entry from realmdomains when the DNS zone is deleted from IPA. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>> >>>> I would add a TXT record as I described in >>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>> >>>> This integration probably should go to both commands, realmdomains-* >>>> dnszone-*. >>>> >>>> Any objections? AB? >>> Adding TXT record is probably harmless. >>> >>> I would actually add the TXT record creation only to realmdomains-* and >>> trigger it only in case we manage our DNS and DNS zone is there. >>> This way a hook from dnszone-add will trigger adding TXT record back (via >>> call to >>> realmdomains-mod --add and then TXT record addition from there). Also >>> the fact that admin added manually some domain to realmdomains mapping >>> means that it is implied to be used in obtaining TGTs, so TXT record is >>> helpful there as well. >> >> Okay, it makes sense. We will see how it will work in reality. > > One more thing to check is that we don't do this for our own domain. What do you mean? The TXT record? We create the TXT record in the 'first' IPA domain (or at least I see this records in my test domains). -- Petr Spacek From abokovoy at redhat.com Thu Apr 11 12:23:38 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Apr 2013 15:23:38 +0300 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <5166AA17.4050406@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AA17.4050406@redhat.com> Message-ID: <20130411122338.GG6823@redhat.com> On Thu, 11 Apr 2013, Petr Spacek wrote: >On 11.4.2013 13:43, Alexander Bokovoy wrote: >>On Thu, 11 Apr 2013, Petr Spacek wrote: >>>On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>Integrate realmdomains with IPA DNS >>>>>> >>>>>>Add an entry to realmdomains when a DNS zone is added to IPA. Delete the >>>>>>related entry from realmdomains when the DNS zone is deleted from IPA. >>>>>> >>>>>>https://fedorahosted.org/freeipa/ticket/3544 >>>>> >>>>>I would add a TXT record as I described in >>>>>https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>> >>>>>This integration probably should go to both commands, realmdomains-* >>>>>dnszone-*. >>>>> >>>>>Any objections? AB? >>>>Adding TXT record is probably harmless. >>>> >>>>I would actually add the TXT record creation only to realmdomains-* and >>>>trigger it only in case we manage our DNS and DNS zone is there. >>>>This way a hook from dnszone-add will trigger adding TXT record back (via >>>>call to >>>>realmdomains-mod --add and then TXT record addition from there). Also >>>>the fact that admin added manually some domain to realmdomains mapping >>>>means that it is implied to be used in obtaining TGTs, so TXT record is >>>>helpful there as well. >>> >>>Okay, it makes sense. We will see how it will work in reality. >> >>One more thing to check is that we don't do this for our own domain. > >What do you mean? The TXT record? We create the TXT record in the >'first' IPA domain (or at least I see this records in my test >domains). Creating realmdomains entry for our own domain is not needed since it is there by default and calling to create TXT entry for the same domain from realmdomains-mod is also not needed since we know that it is there. -- / Alexander Bokovoy From pviktori at redhat.com Thu Apr 11 12:24:55 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Apr 2013 14:24:55 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <51668AD1.5000600@redhat.com> References: <51668AD1.5000600@redhat.com> Message-ID: <5166AB97.9010705@redhat.com> On 04/11/2013 12:05 PM, Tomas Babej wrote: > Hi, > > Makes DNAME target validation less strict and allows underscore. > This is requirement for IPA sites. > > https://fedorahosted.org/freeipa/ticket/3550 > > Tomas I checked with Petr?, and he said it would make sense to also enable underscores for the other records types. For records other than TXT, SRV, DNAME, and NSEC we could warn if underscores are used, but that's probably not worth the trouble -- just allowing underscores everywhere is fine. -- Petr? From akrivoka at redhat.com Thu Apr 11 12:35:29 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 11 Apr 2013 14:35:29 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <20130411114304.GF6823@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> Message-ID: <5166AE11.6090300@redhat.com> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: > On Thu, 11 Apr 2013, Petr Spacek wrote: >> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>> Integrate realmdomains with IPA DNS >>>>> >>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>> Delete the >>>>> related entry from realmdomains when the DNS zone is deleted from >>>>> IPA. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>> >>>> I would add a TXT record as I described in >>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>> >>>> This integration probably should go to both commands, realmdomains-* >>>> dnszone-*. >>>> >>>> Any objections? AB? >>> Adding TXT record is probably harmless. >>> >>> I would actually add the TXT record creation only to realmdomains-* and >>> trigger it only in case we manage our DNS and DNS zone is there. >>> This way a hook from dnszone-add will trigger adding TXT record back >>> (via call to >>> realmdomains-mod --add and then TXT record addition from there). Also >>> the fact that admin added manually some domain to realmdomains mapping >>> means that it is implied to be used in obtaining TGTs, so TXT record is >>> helpful there as well. >> >> Okay, it makes sense. We will see how it will work in reality. > > One more thing to check is that we don't do this for our own domain. > Our own domain is already in realmdomains by default, and it cannot be removed from there. So I don't think any check related to our domain is necessary. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From simo at redhat.com Thu Apr 11 12:43:44 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Apr 2013 08:43:44 -0400 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <5166AB97.9010705@redhat.com> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> Message-ID: <1365684224.2845.0.camel@willson.li.ssimo.org> On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: > On 04/11/2013 12:05 PM, Tomas Babej wrote: > > Hi, > > > > Makes DNAME target validation less strict and allows underscore. > > This is requirement for IPA sites. > > > > https://fedorahosted.org/freeipa/ticket/3550 > > > > Tomas > > I checked with Petr?, and he said it would make sense to also enable > underscores for the other records types. > For records other than TXT, SRV, DNAME, and NSEC we could warn if > underscores are used, but that's probably not worth the trouble -- just > allowing underscores everywhere is fine. > Underscores are invalid DNS characters, they should not be allowed for A records, only for DNAME, and SRV records IMO. That said I am ok allowing them on other records provided we warn prominently. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Apr 11 12:52:52 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Apr 2013 14:52:52 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <1365684224.2845.0.camel@willson.li.ssimo.org> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> Message-ID: <5166B224.8070601@redhat.com> On 04/11/2013 02:43 PM, Simo Sorce wrote: > On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: >> On 04/11/2013 12:05 PM, Tomas Babej wrote: >>> Hi, >>> >>> Makes DNAME target validation less strict and allows underscore. >>> This is requirement for IPA sites. >>> >>> https://fedorahosted.org/freeipa/ticket/3550 >>> >>> Tomas >> >> I checked with Petr?, and he said it would make sense to also enable >> underscores for the other records types. >> For records other than TXT, SRV, DNAME, and NSEC we could warn if >> underscores are used, but that's probably not worth the trouble -- just >> allowing underscores everywhere is fine. >> > > Underscores are invalid DNS characters, they should not be allowed for A > records, only for DNAME, and SRV records IMO. Technically, they're invalid *hostname* characters; in DNS itself anything goes. Interestingly, we already allow them for A records: $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com _bogus --a-rec=1.2.3.4 Record name: _bogus A record: 1.2.3.4 But this ticket is not about the record name, it's about record data (i.e. the *target* of the DNAME). > That said I am ok allowing them on other records provided we warn > prominently. > > Simo. -- Petr? From pspacek at redhat.com Thu Apr 11 13:02:47 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Apr 2013 15:02:47 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <1365684224.2845.0.camel@willson.li.ssimo.org> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> Message-ID: <5166B477.3070307@redhat.com> On 11.4.2013 14:43, Simo Sorce wrote: > On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: >> On 04/11/2013 12:05 PM, Tomas Babej wrote: >>> Hi, >>> >>> Makes DNAME target validation less strict and allows underscore. >>> This is requirement for IPA sites. >>> >>> https://fedorahosted.org/freeipa/ticket/3550 >>> >>> Tomas >> >> I checked with Petr?, and he said it would make sense to also enable >> underscores for the other records types. >> For records other than TXT, SRV, DNAME, and NSEC we could warn if >> underscores are used, but that's probably not worth the trouble -- just >> allowing underscores everywhere is fine. >> > > Underscores are invalid DNS characters, they should not be allowed for A > records, only for DNAME, and SRV records IMO. AFAIK underscore is not allowed in 'host names' (= A/AAAA), but generally should be okay. (This limitation came from 1988 ...) > That said I am ok allowing them on other records provided we warn > prominently. We definitely need to allow underscore in DNAME, SRV, NSEC and TXT. Warning for these records is not meaningful. I'm okay with any check/warning/whatever for other records as long as --force can be used to disable the check. -- Petr^2 Spacek From abokovoy at redhat.com Thu Apr 11 13:03:02 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 11 Apr 2013 16:03:02 +0300 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <5166AE11.6090300@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> Message-ID: <20130411130302.GH6823@redhat.com> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >> On Thu, 11 Apr 2013, Petr Spacek wrote: >>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>> Integrate realmdomains with IPA DNS >>>>>> >>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>> Delete the >>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>> IPA. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>> >>>>> I would add a TXT record as I described in >>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>> >>>>> This integration probably should go to both commands, realmdomains-* >>>>> dnszone-*. >>>>> >>>>> Any objections? AB? >>>> Adding TXT record is probably harmless. >>>> >>>> I would actually add the TXT record creation only to realmdomains-* and >>>> trigger it only in case we manage our DNS and DNS zone is there. >>>> This way a hook from dnszone-add will trigger adding TXT record back >>>> (via call to >>>> realmdomains-mod --add and then TXT record addition from there). Also >>>> the fact that admin added manually some domain to realmdomains mapping >>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>> helpful there as well. >>> >>> Okay, it makes sense. We will see how it will work in reality. >> >> One more thing to check is that we don't do this for our own domain. >> > >Our own domain is already in realmdomains by default, and it cannot be >removed from there. So I don't think any check related to our domain is >necessary. We shouldn't start creating TXT records for our own domain, that's what I'm asking for here. Think about server install stage -- we start creating our own domain and the hook then causes to create realmdomains entry for the domain, causing realmdomains-mod code to raise ValidationError which is not handled in dnszone-add code with this patch. Same for TXT record creation starting from realmdomains-mod side -- it simply should avoid calling dnsrecord-add for the case we know wouldn't work. -- / Alexander Bokovoy From pspacek at redhat.com Thu Apr 11 13:05:46 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 11 Apr 2013 15:05:46 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <5166B224.8070601@redhat.com> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> <5166B224.8070601@redhat.com> Message-ID: <5166B52A.8050008@redhat.com> On 11.4.2013 14:52, Petr Viktorin wrote: > On 04/11/2013 02:43 PM, Simo Sorce wrote: >> On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: >>> On 04/11/2013 12:05 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> Makes DNAME target validation less strict and allows underscore. >>>> This is requirement for IPA sites. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3550 >>>> >>>> Tomas >>> >>> I checked with Petr?, and he said it would make sense to also enable >>> underscores for the other records types. >>> For records other than TXT, SRV, DNAME, and NSEC we could warn if >>> underscores are used, but that's probably not worth the trouble -- just >>> allowing underscores everywhere is fine. >>> >> >> Underscores are invalid DNS characters, they should not be allowed for A >> records, only for DNAME, and SRV records IMO. > > Technically, they're invalid *hostname* characters; in DNS itself anything goes. Exactly. > Interestingly, we already allow them for A records: > $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com _bogus --a-rec=1.2.3.4 > Record name: _bogus > A record: 1.2.3.4 AD sometimes create crazy A records in DNS tree, so I guess it is allowed for compatibility. (Imagine that - IPA DNS used for AD domain!) > But this ticket is not about the record name, it's about record data (i.e. the > *target* of the DNAME). This ticket *is* about names and targets at same time: Text from the ticket: > We need to allow underscore in record names and also DNAME targets. -- Petr^2 Spacek From rcritten at redhat.com Thu Apr 11 13:19:03 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 09:19:03 -0400 Subject: [Freeipa-devel] [PATCH] 1095 apply updates in order In-Reply-To: <5166A0CE.4080709@redhat.com> References: <5165A949.9090700@redhat.com> <5166A0CE.4080709@redhat.com> Message-ID: <5166B847.6060304@redhat.com> Petr Viktorin wrote: > On 04/10/2013 08:02 PM, Rob Crittenden wrote: >> The original design of the LDAP updater was to use numbered update files >> which would be applied in order in blocks of 10. We ended up just >> applying everything together, sorted by length of the DN. > > Why not just sort the files lexicographically, and _run_updates after > each one? That might work. I did this mostly for schema which can have interdependencies. I didn't want to force us to have humongous updates for schema. > I can kind of see the reasoning behind the blocks of ten, but it looks > pretty arbitrary and unnecessarily complex. > It will allow you to create/update parents and children anywhere in the > block of 10 and they'll be sorted properly, but outside of the blocks > you have to watch the ordering. This is pretty confusing; if it's really > needed it should at least be in the README. It is absolutely arbitrary. I'll beef up the README. In practice it probably isn't a big deal WHERE the updates get put, as long as schema is first. This is just an attempt to force us to be somewhat organized with things. >> This works ok except in the case of roles/privileges/permissions wehre >> it is possible that a role is added to a permission before the role is >> created. So the permission has no memberOf attribute and things don't >> work as expected. >> >> So this patch implements the by-10 rule and applies the files 10-19, >> 20-29, etc. I left the ability to run unstructured updates too by >> default. >> >> We also need to revert this commit which breaks a test case now that >> roles/permissions are created properly, >> f7e27b547547be06f511a3ddfaff8db7d0b7898f > > \o/ > > > In the README, 10 - 19 should be Schema & configuration. OK. > While you're at it you can update the FDS Server reference (FDS was > Fedora Directory Server, right?) > Yeah, shows how old this is. I'll fix it. rob From simo at redhat.com Thu Apr 11 13:59:26 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Apr 2013 09:59:26 -0400 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <5166B224.8070601@redhat.com> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> <5166B224.8070601@redhat.com> Message-ID: <1365688766.2845.13.camel@willson.li.ssimo.org> On Thu, 2013-04-11 at 14:52 +0200, Petr Viktorin wrote: > On 04/11/2013 02:43 PM, Simo Sorce wrote: > > On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: > >> On 04/11/2013 12:05 PM, Tomas Babej wrote: > >>> Hi, > >>> > >>> Makes DNAME target validation less strict and allows underscore. > >>> This is requirement for IPA sites. > >>> > >>> https://fedorahosted.org/freeipa/ticket/3550 > >>> > >>> Tomas > >> > >> I checked with Petr?, and he said it would make sense to also enable > >> underscores for the other records types. > >> For records other than TXT, SRV, DNAME, and NSEC we could warn if > >> underscores are used, but that's probably not worth the trouble -- just > >> allowing underscores everywhere is fine. > >> > > > > Underscores are invalid DNS characters, they should not be allowed for A > > records, only for DNAME, and SRV records IMO. > > Technically, they're invalid *hostname* characters; in DNS itself > anything goes. > > Interestingly, we already allow them for A records: > $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com _bogus --a-rec=1.2.3.4 > Record name: _bogus > A record: 1.2.3.4 > > But this ticket is not about the record name, it's about record data > (i.e. the *target* of the DNAME). So we are restricting record *data* but *not* record names ? That's ... odd. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Apr 11 13:59:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 11 Apr 2013 15:59:28 +0200 Subject: [Freeipa-devel] [PATCH] 0012 Fix output for some CLI commands In-Reply-To: <51657511.5030707@redhat.com> References: <5162ACBF.7040207@redhat.com> <5162C90A.9070301@redhat.com> <5162D537.6010800@redhat.com> <5162ED20.1050500@redhat.com> <51657511.5030707@redhat.com> Message-ID: <5166C1C0.1030200@redhat.com> On 04/10/2013 04:20 PM, Petr Viktorin wrote: > On 04/08/2013 06:15 PM, Ana Krivokapic wrote: >> On 04/08/2013 04:33 PM, Jan Cholasta wrote: >>> On 8.4.2013 15:41, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 8.4.2013 13:40, Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch addresses https://fedorahosted.org/freeipa/ticket/3503. See >>>>> the commit message for details. >>>>> >>>> >>>> the patch seems OK, I will just run the test suite to make sure you >>>> didn't miss anything. >>>> >>>> Honza >>>> >>> >>> Change dnszone_del summary to "Deleted DNS zone", as we use "DNS zone" >>> (not just "zone") in other commands. Also as Petr pointed out, we're >>> in string freeze now, so we have to wait until it's over before >>> pushing this patch, or split the patch in two. >>> >>> Besides that, ACK. >>> >> >> Thanks for the review. >> >> I have changed the summary message to "Deleted DNS zone", and split the >> patch into two patches that can be applied independently. >> > > We can break the string freeze with this small change, so ACK to both. > Pushed both patches to master. Martin From pviktori at redhat.com Thu Apr 11 14:35:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Apr 2013 16:35:54 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <1365688766.2845.13.camel@willson.li.ssimo.org> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> <5166B224.8070601@redhat.com> <1365688766.2845.13.camel@willson.li.ssimo.org> Message-ID: <5166CA4A.1080903@redhat.com> On 04/11/2013 03:59 PM, Simo Sorce wrote: > On Thu, 2013-04-11 at 14:52 +0200, Petr Viktorin wrote: >> On 04/11/2013 02:43 PM, Simo Sorce wrote: >>> On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: >>>> On 04/11/2013 12:05 PM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Makes DNAME target validation less strict and allows underscore. >>>>> This is requirement for IPA sites. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3550 >>>>> >>>>> Tomas >>>> >>>> I checked with Petr?, and he said it would make sense to also enable >>>> underscores for the other records types. >>>> For records other than TXT, SRV, DNAME, and NSEC we could warn if >>>> underscores are used, but that's probably not worth the trouble -- just >>>> allowing underscores everywhere is fine. >>>> >>> >>> Underscores are invalid DNS characters, they should not be allowed for A >>> records, only for DNAME, and SRV records IMO. >> >> Technically, they're invalid *hostname* characters; in DNS itself >> anything goes. >> >> Interestingly, we already allow them for A records: >> $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com _bogus --a-rec=1.2.3.4 >> Record name: _bogus >> A record: 1.2.3.4 >> >> But this ticket is not about the record name, it's about record data >> (i.e. the *target* of the DNAME). > > So we are restricting record *data* but *not* record names ? That's ... > odd. Yes. Apparently we relaxed the name validation because underscores are used in AD or other exotic/nonstandard setups, and now we need to relax the data validation as well. I filed a ticket to add warnings for underscores in A records: https://fedorahosted.org/freeipa/ticket/3557 -- Petr? From pviktori at redhat.com Thu Apr 11 15:17:37 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 11 Apr 2013 17:17:37 +0200 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts In-Reply-To: <5165E135.1090007@redhat.com> References: <5165B308.2020804@redhat.com> <5165E135.1090007@redhat.com> Message-ID: <5166D411.8030308@redhat.com> On 04/11/2013 12:01 AM, Rob Crittenden wrote: > Ana Krivokapic wrote: >> Hello, >> >> This patch set deprecates HBAC source hosts from IPA. >> >> See commit messages and the design page[1] for details. >> >> https://fedorahosted.org/freeipa/ticket/3528 >> >> [1] http://www.freeipa.org/page/V3/HBACSourceHosts > > Been a while since I've run the UI but I get an error in FF 18: > > Timestamp: 04/10/2013 05:43:31 PM > Error: TypeError: e.messages is undefined > Source File: https://rawhide2.greyoak.com/ipa/ui/js/freeipa/app.js > Line: 1 This probably means that you didn't rebuild the UI since 42300eb. Try git clean and a fresh rebuild, or use tools in install/ui/util/ (Petr Vobornik is the person to ask about those). > The other changes seem to operate fine. I tested with an older client > and got reasonable error messages back when I tried to do the various > sourcehost things. > > I got an unknown error message with --add-sourcehost but it did include > the text that the command is deprecated so I think this is acceptable. > There isn't a lot we can do, I'm sorry we didn't add this exception in > the beginning. > > I do wonder if we should leave the warning in hbactest if sourcehost is > set though, for those cases where there are already options set. > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Petr? From rcritten at redhat.com Thu Apr 11 15:57:35 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 11:57:35 -0400 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts In-Reply-To: <5166D411.8030308@redhat.com> References: <5165B308.2020804@redhat.com> <5165E135.1090007@redhat.com> <5166D411.8030308@redhat.com> Message-ID: <5166DD6F.20407@redhat.com> Petr Viktorin wrote: > On 04/11/2013 12:01 AM, Rob Crittenden wrote: >> Ana Krivokapic wrote: >>> Hello, >>> >>> This patch set deprecates HBAC source hosts from IPA. >>> >>> See commit messages and the design page[1] for details. >>> >>> https://fedorahosted.org/freeipa/ticket/3528 >>> >>> [1] http://www.freeipa.org/page/V3/HBACSourceHosts >> >> Been a while since I've run the UI but I get an error in FF 18: >> >> Timestamp: 04/10/2013 05:43:31 PM >> Error: TypeError: e.messages is undefined >> Source File: https://rawhide2.greyoak.com/ipa/ui/js/freeipa/app.js >> Line: 1 > > This probably means that you didn't rebuild the UI since 42300eb. > Try git clean and a fresh rebuild, or use tools in install/ui/util/ > (Petr Vobornik is the person to ask about those). Seems to have been a remnant of a previous build. I'm guessing that the UI build directories aren't covered by a clean/distclean. I manually removed some files from build and it works now. > >> The other changes seem to operate fine. I tested with an older client >> and got reasonable error messages back when I tried to do the various >> sourcehost things. >> >> I got an unknown error message with --add-sourcehost but it did include >> the text that the command is deprecated so I think this is acceptable. >> There isn't a lot we can do, I'm sorry we didn't add this exception in >> the beginning. >> >> I do wonder if we should leave the warning in hbactest if sourcehost is >> set though, for those cases where there are already options set. So this question still remains, should we leave the sourcehost warning in hbactest for another release or two? rob From npmccallum at redhat.com Thu Apr 11 18:12:53 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Apr 2013 14:12:53 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <5165BF14.40209@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> Message-ID: <1365703973.21323.8.camel@localhost.localdomain> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > I'm not sure how I'd test it if I got it built. I'm working on this. I hope to have a clear answer next week. Bear with me... > Overall looks really good. I've split up the patch into multiple commits. I've also added .update files and a patch for ipa-kdb to feed krb5 the right user string. https://github.com/npmccallum/freeipa/commits/otp Please take a look. I *think* I've got everything worked out so far with the exception of bug numbers / urls. Should every patch have a separate bug and a link to the design page? Nathaniel From simo at redhat.com Thu Apr 11 18:35:36 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Apr 2013 14:35:36 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365703973.21323.8.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> Message-ID: <1365705336.2845.108.camel@willson.li.ssimo.org> On Thu, 2013-04-11 at 14:12 -0400, Nathaniel McCallum wrote: > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > > I'm not sure how I'd test it if I got it built. > > I'm working on this. I hope to have a clear answer next week. Bear with > me... > > > Overall looks really good. > > I've split up the patch into multiple commits. I've also added .update > files and a patch for ipa-kdb to feed krb5 the right user string. > > https://github.com/npmccallum/freeipa/commits/otp > > Please take a look. I *think* I've got everything worked out so far with > the exception of bug numbers / urls. Should every patch have a separate > bug and a link to the design page? Please do not do a search of the global tree in ipadb_parse_otp(), it would cause an additional search at every lookup and this path is already too slow for the common case. Add the search for global data in ipa_get_global_configs() (ipa_kdb.c) and make the information available through the global context. Also I am correct that the last patch makes configure fail if systemd is not available ? It should be possible to build on systems that do not use systemd. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Apr 11 18:48:44 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 14:48:44 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365703973.21323.8.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> Message-ID: <5167058C.5070501@redhat.com> Nathaniel McCallum wrote: > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: >> I'm not sure how I'd test it if I got it built. > > I'm working on this. I hope to have a clear answer next week. Bear with > me... > >> Overall looks really good. > > I've split up the patch into multiple commits. I've also added .update > files and a patch for ipa-kdb to feed krb5 the right user string. > > https://github.com/npmccallum/freeipa/commits/otp > > Please take a look. I *think* I've got everything worked out so far with > the exception of bug numbers / urls. Should every patch have a separate > bug and a link to the design page? The ticket should go into every commit. I'd probably put the design link there too, just for completeness. Future bug fixes, et all aren't going to require the design page, but since these commits are all related to the initial feature it will be nice to have. You can have multiple patches on the same ticket/bug. rob From dpal at redhat.com Thu Apr 11 19:21:49 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 11 Apr 2013 15:21:49 -0400 Subject: [Freeipa-devel] FreeIPA Fedora 19 Test Day Announcement Message-ID: <51670D4D.50102@redhat.com> The FreeIPA team is happy to welcome you to a Fedora Test Day that will be held on Thursday, April 18th. We invite you to take part in testing of the new features that will become available in upcoming FreeIPA 3.2 upstream release and would be a part of Fedora 19. To read more about the test day and suggested tests use the following link http://fedoraproject.org/wiki/Test_Day:2013-04-18 The outline of the features of the upcoming release can be found in the following announcement: https://www.redhat.com/archives/freeipa-devel/2013-April/msg00028.html Thank you for your help and participation! FreeIPA team From rcritten at redhat.com Thu Apr 11 18:50:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 14:50:15 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365705336.2845.108.camel@willson.li.ssimo.org> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <1365705336.2845.108.camel@willson.li.ssimo.org> Message-ID: <516705E7.7040803@redhat.com> Simo Sorce wrote: > On Thu, 2013-04-11 at 14:12 -0400, Nathaniel McCallum wrote: >> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: >>> I'm not sure how I'd test it if I got it built. >> >> I'm working on this. I hope to have a clear answer next week. Bear with >> me... >> >>> Overall looks really good. >> >> I've split up the patch into multiple commits. I've also added .update >> files and a patch for ipa-kdb to feed krb5 the right user string. >> >> https://github.com/npmccallum/freeipa/commits/otp >> >> Please take a look. I *think* I've got everything worked out so far with >> the exception of bug numbers / urls. Should every patch have a separate >> bug and a link to the design page? > > Please do not do a search of the global tree in ipadb_parse_otp(), it > would cause an additional search at every lookup and this path is > already too slow for the common case. > > Add the search for global data in ipa_get_global_configs() (ipa_kdb.c) > and make the information available through the global context. > > > Also I am correct that the last patch makes configure fail if systemd is > not available ? > It should be possible to build on systems that do not use systemd. Really? The server target for this is F-19+ which doesn't have the option of SysV AFAIK. rob From rcritten at redhat.com Thu Apr 11 19:39:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 15:39:58 -0400 Subject: [Freeipa-devel] [PATCH] 1095 apply updates in order In-Reply-To: <5166B847.6060304@redhat.com> References: <5165A949.9090700@redhat.com> <5166A0CE.4080709@redhat.com> <5166B847.6060304@redhat.com> Message-ID: <5167118E.8030907@redhat.com> Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/10/2013 08:02 PM, Rob Crittenden wrote: >>> The original design of the LDAP updater was to use numbered update files >>> which would be applied in order in blocks of 10. We ended up just >>> applying everything together, sorted by length of the DN. >> >> Why not just sort the files lexicographically, and _run_updates after >> each one? > > That might work. I did this mostly for schema which can have > interdependencies. I didn't want to force us to have humongous updates > for schema. > >> I can kind of see the reasoning behind the blocks of ten, but it looks >> pretty arbitrary and unnecessarily complex. >> It will allow you to create/update parents and children anywhere in the >> block of 10 and they'll be sorted properly, but outside of the blocks >> you have to watch the ordering. This is pretty confusing; if it's really >> needed it should at least be in the README. > > It is absolutely arbitrary. > > I'll beef up the README. > > In practice it probably isn't a big deal WHERE the updates get put, as > long as schema is first. This is just an attempt to force us to be > somewhat organized with things. > >>> This works ok except in the case of roles/privileges/permissions wehre >>> it is possible that a role is added to a permission before the role is >>> created. So the permission has no memberOf attribute and things don't >>> work as expected. >>> >>> So this patch implements the by-10 rule and applies the files 10-19, >>> 20-29, etc. I left the ability to run unstructured updates too by >>> default. >>> >>> We also need to revert this commit which breaks a test case now that >>> roles/permissions are created properly, >>> f7e27b547547be06f511a3ddfaff8db7d0b7898f >> >> \o/ >> >> >> In the README, 10 - 19 should be Schema & configuration. > > OK. > >> While you're at it you can update the FDS Server reference (FDS was >> Fedora Directory Server, right?) >> > > Yeah, shows how old this is. I'll fix it. I updated the README with a bit more information. I dod not update the 10-19 range because it really should just be schema. It isn't that way in the updates currently, but it is what we should strive for. These are not hard and fast rules, with the exception of schema really, just a recommendation for organization. I can go ahead and move some files around if you really want, but I think it's just shuffling deck chairs. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1095-2-update.patch Type: text/x-patch Size: 6734 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 11 19:57:53 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 15:57:53 -0400 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <5164017C.1000101@redhat.com> References: <5164017C.1000101@redhat.com> Message-ID: <516715C1.9040607@redhat.com> Tomas Babej wrote: > Hi, > > In ipa-replica-manage commands, we enforce that hostnames we work > with are resolvable. However, this caused errors while deleting > or disconnecting a ipa / winsync replica, if that replica was down > and authoritative server for itself. > > https://fedorahosted.org/freeipa/ticket/3524 > > Tomas I'm not sure this is going to do the right thing either. A lot of these commands take the an argument as the remote master to run things on, so we'd really only be validating one of the names. Not sure how that helps us. What if we honor the --force flag for DNS lookup failures instead? Or, since that could override it and do other things, a --no-lookup flag perhaps? rob From rcritten at redhat.com Thu Apr 11 19:58:37 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 15:58:37 -0400 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <51657A73.9050006@redhat.com> References: <5164017C.1000101@redhat.com> <51657A73.9050006@redhat.com> Message-ID: <516715ED.7030906@redhat.com> Tomas Babej wrote: > On 04/09/2013 01:54 PM, Tomas Babej wrote: >> Hi, >> >> In ipa-replica-manage commands, we enforce that hostnames we work >> with are resolvable. However, this caused errors while deleting >> or disconnecting a ipa / winsync replica, if that replica was down >> and authoritative server for itself. >> >> https://fedorahosted.org/freeipa/ticket/3524 >> >> Tomas > > Attaching a fix for ipa-replica-manage which gracelly handles connection > timeout. > > Please apply on top of 0045. > > Tomas ACK on the concept. I'm assuming this is going to need to rebased eventually. rob From npmccallum at redhat.com Thu Apr 11 20:49:01 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 11 Apr 2013 16:49:01 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365705336.2845.108.camel@willson.li.ssimo.org> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <1365705336.2845.108.camel@willson.li.ssimo.org> Message-ID: <1365713341.21323.10.camel@localhost.localdomain> On Thu, 2013-04-11 at 14:35 -0400, Simo Sorce wrote: > On Thu, 2013-04-11 at 14:12 -0400, Nathaniel McCallum wrote: > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > > > I'm not sure how I'd test it if I got it built. > > > > I'm working on this. I hope to have a clear answer next week. Bear with > > me... > > > > > Overall looks really good. > > > > I've split up the patch into multiple commits. I've also added .update > > files and a patch for ipa-kdb to feed krb5 the right user string. > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > Please take a look. I *think* I've got everything worked out so far with > > the exception of bug numbers / urls. Should every patch have a separate > > bug and a link to the design page? > > Please do not do a search of the global tree in ipadb_parse_otp(), it > would cause an additional search at every lookup and this path is > already too slow for the common case. > > Add the search for global data in ipa_get_global_configs() (ipa_kdb.c) > and make the information available through the global context. Thanks, I forgot to ask about this. I pushed a fix. The only extra network/query cost now during getprinc is just a single (multi-value) attribute on the user entry. > Also I am correct that the last patch makes configure fail if systemd is > not available ? > It should be possible to build on systems that do not use systemd. I thought we depended on systemd now. Being buildable without systemd will take some more work (I'll have to implement all the daemonizing code or use something like xinetd). Nathaniel From rcritten at redhat.com Thu Apr 11 21:43:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Apr 2013 17:43:29 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <51668C38.8020607@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5163EBF2.8080004@redhat.com> <51648646.6070706@redhat.com> <51656EE9.3080108@redhat.com> <5165AF09.2030007@redhat.com> <51668C38.8020607@redhat.com> Message-ID: <51672E81.2090708@redhat.com> Petr Viktorin wrote: > On 04/10/2013 08:27 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/09/2013 11:21 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 04/05/2013 10:54 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>>>>>> Rob Crittenden wrote: >>>>>>>>> Petr Viktorin wrote: > [...] >>>>>>>>>> And for production, please have the commands log by default (set >>>>>>>>>> log_file_name). >>>>>>>>> >>>>>>>>> Yes, I plan on adding that in the future. > > One more comment here, shouldn't the log file be /var/log/iparestore.log > rather than /var/log/ipa_restore.log, to match all the other IPA logs? Sure. I did it because it kept conflicting with ipareplica-install.log and I like easy tabbing :-) > [...] >>>>>>> Could backup without --logs save which directories are there, and >>>>>>> restore create empty directories if they don't exist? To me >>>>>>> re-initializing a completely wiped machine looks like a big gain for >>>>>>> the >>>>>>> extra effort. >>>>>> >>>>>> I went ahead and made this change, it wasn't a lot of work. > > Another issue: if a CA was never installed on the host, pkiuser doesn't > exist, and ipa-restore will fail on pwd.getpwnam(PKI_USER). And since > /etc/passwd is restored, the obvious workaround of adding the user > doesn't work. We should only call this if CA is in one of the services to be restored. I went ahead and added a try/except around getting the name to make it more bullet-proof. > > We need to mention in the docs that ipa-restore overwrites files we > don't fully control (/etc/passwd, /ect/group, /etc/pki/nssdb/). > We also restore named configuration even if IPA DNS is not installed, > and smb.conf without AD trusts. Added. I suppose we could eventually add additional excludes based on the restored features. > [...] >>>>> I found a bug with the following topology: >>>>> >>>>> [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] >>>>> >>>>> Running ipa-restore on the 3.2 instance tries to disable the CA >>>>> replication agreement between the other two. >>>>> However, deep in ReplicationManager.agreement_dn it uses its own DS >>>>> instance name instead of the Dogtag-9-DS one, so the agreement isn't >>>>> found and the restore fails. >>>>> >>>>> >>>> >>>> Yeah, I'm not 100% sure how to address that either. Is it safe to >>>> assume >>>> that if the port is 7389 then the instance is pki-ca? >>> >>> The port was hardcoded so it is. >> >> Ok, just thanks for the other set of eyes. Updated patch attached. > > Yup, this is fixed, thanks. > >>>> Or should we test >>>> for the existence of the instance name like we do master/clone? >>>> >>>> I've also figured out why Update in Progress loops forever. It is >>>> because the older ipa-replica-manage do not re-enable the replication >>>> agreement, so replication can't continue. I'm not entirely sure how we >>>> will need to go about fixing this, except through documentation. > > Documentation works, but note that it'll affect anyone with a bunch of > upgraded (Dogtag-9 style) instances. It may be a pretty common case in > the wild. > Maybe we need to recommend reinstalling replicas entirely, rather than > re-initializing, just to be on the safe side. > Added. I also added a FILES section to both man pages to point out the log files and where the backups are saved. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1093-5-backup.patch Type: text/x-patch Size: 80332 bytes Desc: not available URL: From akrivoka at redhat.com Thu Apr 11 22:31:52 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 12 Apr 2013 00:31:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts In-Reply-To: <5166DD6F.20407@redhat.com> References: <5165B308.2020804@redhat.com> <5165E135.1090007@redhat.com> <5166D411.8030308@redhat.com> <5166DD6F.20407@redhat.com> Message-ID: <516739D8.5030702@redhat.com> On 04/11/2013 05:57 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/11/2013 12:01 AM, Rob Crittenden wrote: >>> Ana Krivokapic wrote: >>>> Hello, >>>> >>>> This patch set deprecates HBAC source hosts from IPA. >>>> >>>> See commit messages and the design page[1] for details. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3528 >>>> >>>> [1] http://www.freeipa.org/page/V3/HBACSourceHosts >>> >>> Been a while since I've run the UI but I get an error in FF 18: >>> >>> Timestamp: 04/10/2013 05:43:31 PM >>> Error: TypeError: e.messages is undefined >>> Source File: https://rawhide2.greyoak.com/ipa/ui/js/freeipa/app.js >>> Line: 1 >> >> This probably means that you didn't rebuild the UI since 42300eb. >> Try git clean and a fresh rebuild, or use tools in install/ui/util/ >> (Petr Vobornik is the person to ask about those). > > Seems to have been a remnant of a previous build. I'm guessing that > the UI build directories aren't covered by a clean/distclean. I > manually removed some files from build and it works now. > >> >>> The other changes seem to operate fine. I tested with an older client >>> and got reasonable error messages back when I tried to do the various >>> sourcehost things. >>> >>> I got an unknown error message with --add-sourcehost but it did include >>> the text that the command is deprecated so I think this is acceptable. >>> There isn't a lot we can do, I'm sorry we didn't add this exception in >>> the beginning. >>> >>> I do wonder if we should leave the warning in hbactest if sourcehost is >>> set though, for those cases where there are already options set. > > So this question still remains, should we leave the sourcehost warning > in hbactest for another release or two? > > rob > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Rob and I agreed on IRC to put the sourcehost warning back in hbactest for now. I updated the patch 0016 accordingly. (It also needed a slight rebase, due to API changes that happened in the meantime.) New version is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0016-02-Deprecate-HBAC-source-hosts-from-CLI.patch Type: text/x-patch Size: 32063 bytes Desc: not available URL: From simo at redhat.com Thu Apr 11 22:34:37 2013 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Apr 2013 18:34:37 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365713341.21323.10.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <1365705336.2845.108.camel@willson.li.ssimo.org> <1365713341.21323.10.camel@localhost.localdomain> Message-ID: <1365719677.2845.112.camel@willson.li.ssimo.org> On Thu, 2013-04-11 at 16:49 -0400, Nathaniel McCallum wrote: > On Thu, 2013-04-11 at 14:35 -0400, Simo Sorce wrote: > > On Thu, 2013-04-11 at 14:12 -0400, Nathaniel McCallum wrote: > > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > > > > I'm not sure how I'd test it if I got it built. > > > > > > I'm working on this. I hope to have a clear answer next week. Bear with > > > me... > > > > > > > Overall looks really good. > > > > > > I've split up the patch into multiple commits. I've also added .update > > > files and a patch for ipa-kdb to feed krb5 the right user string. > > > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > > > Please take a look. I *think* I've got everything worked out so far with > > > the exception of bug numbers / urls. Should every patch have a separate > > > bug and a link to the design page? > > > > Please do not do a search of the global tree in ipadb_parse_otp(), it > > would cause an additional search at every lookup and this path is > > already too slow for the common case. > > > > Add the search for global data in ipa_get_global_configs() (ipa_kdb.c) > > and make the information available through the global context. > > Thanks, I forgot to ask about this. I pushed a fix. The only extra > network/query cost now during getprinc is just a single (multi-value) > attribute on the user entry. > > > Also I am correct that the last patch makes configure fail if systemd is > > not available ? > > It should be possible to build on systems that do not use systemd. > > I thought we depended on systemd now. Being buildable without systemd > will take some more work (I'll have to implement all the daemonizing > code or use something like xinetd). There has been some (slow) work on allowing to build FreeIPA on other systems (debian based) and a systemd dependency would make it harder. We do not really have a dependency on systemd, but if it is a lot more work then I guess we can simply open a ticket about it being an issue and defer, maybe by the time we get around to doing something about it all other distribution will have fallen in line after all. Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Fri Apr 12 07:49:53 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Apr 2013 09:49:53 +0200 Subject: [Freeipa-devel] [PATCH 0143-0144] Preparation for 3.1 release Message-ID: <5167BCA1.6090304@redhat.com> Hello, I'm releasing version 3.1 which contains the fix from patch 140, nothing else. - Update NEWS file for upcoming 3.1 release. - Bump NVR to 3.1. Pushed to master: f3804cd6c3e56c7c7e87de3066bab97214a564a0 4b0dee082015b45a1ee9c6ddbce60158f5e72160 -- Petr^2 Spacek From pviktori at redhat.com Fri Apr 12 10:10:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Apr 2013 12:10:17 +0200 Subject: [Freeipa-devel] [PATCH] 1095 apply updates in order In-Reply-To: <5167118E.8030907@redhat.com> References: <5165A949.9090700@redhat.com> <5166A0CE.4080709@redhat.com> <5166B847.6060304@redhat.com> <5167118E.8030907@redhat.com> Message-ID: <5167DD89.2040107@redhat.com> On 04/11/2013 09:39 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Petr Viktorin wrote: [...] >>> In the README, 10 - 19 should be Schema & configuration. >> >> OK. >> >>> While you're at it you can update the FDS Server reference (FDS was >>> Fedora Directory Server, right?) >>> >> >> Yeah, shows how old this is. I'll fix it. > > I updated the README with a bit more information. I dod not update the > 10-19 range because it really should just be schema. It isn't that way > in the updates currently, but it is what we should strive for. > > These are not hard and fast rules, with the exception of schema really, > just a recommendation for organization. I can go ahead and move some > files around if you really want, but I think it's just shuffling deck > chairs. OK, I'm just curious what the design is more than anything. I'm still not a fan of the block of ten approach, but the patch works as designed. ACK. Please remember to also revert f7e27b5 when pushing. -- Petr? From akrivoka at redhat.com Fri Apr 12 10:20:02 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 12 Apr 2013 12:20:02 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <20130411130302.GH6823@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> Message-ID: <5167DFD2.2030402@redhat.com> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: > On Thu, 11 Apr 2013, Ana Krivokapic wrote: >> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>> Integrate realmdomains with IPA DNS >>>>>>> >>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>> Delete the >>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>> IPA. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>> >>>>>> I would add a TXT record as I described in >>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>> >>>>>> This integration probably should go to both commands, realmdomains-* >>>>>> dnszone-*. >>>>>> >>>>>> Any objections? AB? >>>>> Adding TXT record is probably harmless. >>>>> >>>>> I would actually add the TXT record creation only to >>>>> realmdomains-* and >>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>> (via call to >>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>> the fact that admin added manually some domain to realmdomains >>>>> mapping >>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>> record is >>>>> helpful there as well. >>>> >>>> Okay, it makes sense. We will see how it will work in reality. >>> >>> One more thing to check is that we don't do this for our own domain. >>> >> >> Our own domain is already in realmdomains by default, and it cannot be >> removed from there. So I don't think any check related to our domain is >> necessary. > We shouldn't start creating TXT records for our own domain, that's what > I'm asking for here. > > Think about server install stage -- we start creating our own domain and > the hook then causes to create realmdomains entry for the domain, > causing realmdomains-mod code to raise ValidationError which is not > handled in dnszone-add code with this patch. > > Same for TXT record creation starting from realmdomains-mod side -- it > simply should avoid calling dnsrecord-add for the case we know wouldn't > work. > I just realized that this ticket was not marked as RFE although it obviously is one. I fixed the ticket summary and wrote the design page for this enhancement: http://www.freeipa.org/page/V3/DNS_realmdomains_integration -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pviktori at redhat.com Fri Apr 12 10:25:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Apr 2013 12:25:56 +0200 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <51672E81.2090708@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5163EBF2.8080004@redhat.com> <51648646.6070706@redhat.com> <51656EE9.3080108@redhat.com> <5165AF09.2030007@redhat.com> <51668C38.8020607@redhat.com> <51672E81.2090708@redhat.com> Message-ID: <5167E134.2030705@redhat.com> On 04/11/2013 11:43 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/10/2013 08:27 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 04/09/2013 11:21 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> On 04/05/2013 10:54 PM, Rob Crittenden wrote: >>>>>>> Petr Viktorin wrote: >>>>>>>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>>>>>>> Rob Crittenden wrote: >>>>>>>>>> Petr Viktorin wrote: >> [...] >>>>>>>>>>> And for production, please have the commands log by default (set >>>>>>>>>>> log_file_name). >>>>>>>>>> >>>>>>>>>> Yes, I plan on adding that in the future. >> >> One more comment here, shouldn't the log file be /var/log/iparestore.log >> rather than /var/log/ipa_restore.log, to match all the other IPA logs? > > Sure. I did it because it kept conflicting with ipareplica-install.log > and I like easy tabbing :-) > >> [...] >>>>>>>> Could backup without --logs save which directories are there, and >>>>>>>> restore create empty directories if they don't exist? To me >>>>>>>> re-initializing a completely wiped machine looks like a big gain >>>>>>>> for >>>>>>>> the >>>>>>>> extra effort. >>>>>>> >>>>>>> I went ahead and made this change, it wasn't a lot of work. >> >> Another issue: if a CA was never installed on the host, pkiuser doesn't >> exist, and ipa-restore will fail on pwd.getpwnam(PKI_USER). And since >> /etc/passwd is restored, the obvious workaround of adding the user >> doesn't work. > > We should only call this if CA is in one of the services to be restored. > I went ahead and added a try/except around getting the name to make it > more bullet-proof. >> >> We need to mention in the docs that ipa-restore overwrites files we >> don't fully control (/etc/passwd, /ect/group, /etc/pki/nssdb/). >> We also restore named configuration even if IPA DNS is not installed, >> and smb.conf without AD trusts. > > Added. I suppose we could eventually add additional excludes based on > the restored features. > >> [...] >>>>>> I found a bug with the following topology: >>>>>> >>>>>> [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] >>>>>> >>>>>> Running ipa-restore on the 3.2 instance tries to disable the CA >>>>>> replication agreement between the other two. >>>>>> However, deep in ReplicationManager.agreement_dn it uses its own DS >>>>>> instance name instead of the Dogtag-9-DS one, so the agreement isn't >>>>>> found and the restore fails. >>>>>> >>>>>> >>>>> >>>>> Yeah, I'm not 100% sure how to address that either. Is it safe to >>>>> assume >>>>> that if the port is 7389 then the instance is pki-ca? >>>> >>>> The port was hardcoded so it is. >>> >>> Ok, just thanks for the other set of eyes. Updated patch attached. >> >> Yup, this is fixed, thanks. >> >>>>> Or should we test >>>>> for the existence of the instance name like we do master/clone? >>>>> >>>>> I've also figured out why Update in Progress loops forever. It is >>>>> because the older ipa-replica-manage do not re-enable the replication >>>>> agreement, so replication can't continue. I'm not entirely sure how we >>>>> will need to go about fixing this, except through documentation. >> >> Documentation works, but note that it'll affect anyone with a bunch of >> upgraded (Dogtag-9 style) instances. It may be a pretty common case in >> the wild. >> Maybe we need to recommend reinstalling replicas entirely, rather than >> re-initializing, just to be on the safe side. >> > > Added. > > I also added a FILES section to both man pages to point out the log > files and where the backups are saved. > > rob Thanks! And that's all the issues I found. Let's set the beast free, so it gets some wider testing. ACK -- Petr? From mkosek at redhat.com Fri Apr 12 10:44:40 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Apr 2013 12:44:40 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <5167DFD2.2030402@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> Message-ID: <5167E598.4000708@redhat.com> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: > On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>> >>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>> Delete the >>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>> IPA. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>> >>>>>>> I would add a TXT record as I described in >>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>> >>>>>>> This integration probably should go to both commands, realmdomains-* >>>>>>> dnszone-*. >>>>>>> >>>>>>> Any objections? AB? >>>>>> Adding TXT record is probably harmless. >>>>>> >>>>>> I would actually add the TXT record creation only to realmdomains-* and >>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>> (via call to >>>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>>> the fact that admin added manually some domain to realmdomains mapping >>>>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>>>> helpful there as well. >>>>> >>>>> Okay, it makes sense. We will see how it will work in reality. >>>> >>>> One more thing to check is that we don't do this for our own domain. >>>> >>> >>> Our own domain is already in realmdomains by default, and it cannot be >>> removed from there. So I don't think any check related to our domain is >>> necessary. >> We shouldn't start creating TXT records for our own domain, that's what >> I'm asking for here. >> >> Think about server install stage -- we start creating our own domain and >> the hook then causes to create realmdomains entry for the domain, >> causing realmdomains-mod code to raise ValidationError which is not >> handled in dnszone-add code with this patch. >> >> Same for TXT record creation starting from realmdomains-mod side -- it >> simply should avoid calling dnsrecord-add for the case we know wouldn't >> work. >> > > I just realized that this ticket was not marked as RFE although it obviously is > one. I fixed the ticket summary and wrote the design page for this enhancement: > > http://www.freeipa.org/page/V3/DNS_realmdomains_integration > Right, that was a good thing to do. I just have comment for the UPN enumeration image which you linked in the RFE - can you please process it, upload to the wiki and include in the overview? This will make the RFE page more appealing and it will also prevent us from having a broken link when Alexander removes the file from his temporary directory. Thanks, Martin From jcholast at redhat.com Fri Apr 12 11:24:03 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 12 Apr 2013 13:24:03 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca Message-ID: <5167EED3.10700@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-126-Use-A-AAAA-records-instead-of-CNAME-records-in-ipa-c.patch Type: text/x-patch Size: 14299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-127-Delete-DNS-records-in-ipa-ca-on-ipa-csreplica-manage.patch Type: text/x-patch Size: 1912 bytes Desc: not available URL: From akrivoka at redhat.com Fri Apr 12 11:26:42 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 12 Apr 2013 13:26:42 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <5167E598.4000708@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> Message-ID: <5167EF72.8090204@redhat.com> On 04/12/2013 12:44 PM, Martin Kosek wrote: > On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>> >>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>> Delete the >>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>> IPA. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>> I would add a TXT record as I described in >>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>> >>>>>>>> This integration probably should go to both commands, realmdomains-* >>>>>>>> dnszone-*. >>>>>>>> >>>>>>>> Any objections? AB? >>>>>>> Adding TXT record is probably harmless. >>>>>>> >>>>>>> I would actually add the TXT record creation only to realmdomains-* and >>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>> (via call to >>>>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>>>> the fact that admin added manually some domain to realmdomains mapping >>>>>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>>>>> helpful there as well. >>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>> One more thing to check is that we don't do this for our own domain. >>>>> >>>> Our own domain is already in realmdomains by default, and it cannot be >>>> removed from there. So I don't think any check related to our domain is >>>> necessary. >>> We shouldn't start creating TXT records for our own domain, that's what >>> I'm asking for here. >>> >>> Think about server install stage -- we start creating our own domain and >>> the hook then causes to create realmdomains entry for the domain, >>> causing realmdomains-mod code to raise ValidationError which is not >>> handled in dnszone-add code with this patch. >>> >>> Same for TXT record creation starting from realmdomains-mod side -- it >>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>> work. >>> >> I just realized that this ticket was not marked as RFE although it obviously is >> one. I fixed the ticket summary and wrote the design page for this enhancement: >> >> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >> > Right, that was a good thing to do. I just have comment for the UPN enumeration > image which you linked in the RFE - can you please process it, upload to the > wiki and include in the overview? This will make the RFE page more appealing > and it will also prevent us from having a broken link when Alexander removes > the file from his temporary directory. > > Thanks, > Martin Sure, done. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pviktori at redhat.com Fri Apr 12 12:19:34 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Apr 2013 14:19:34 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <5167EED3.10700@redhat.com> References: <5167EED3.10700@redhat.com> Message-ID: <5167FBD6.2070001@redhat.com> On 04/12/2013 01:24 PM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza We used short names in the CNAMEs: $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca Record name: ipa-ca CNAME record: vm-109 ---------------------------- Number of entries returned 1 ---------------------------- But it seems the patch assumes a FQDN with a dot at the end. When upgrading a 3.1 server I get: 2013-04-12T12:16:43Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 613, in run_script return_value = main_function() File "/usr/sbin/ipa-upgradeconfig", line 853, in main add_ca_dns_records() File "/usr/sbin/ipa-upgradeconfig", line 752, in add_ca_dns_records bind.convert_ipa_ca_cnames(api.env.domain) File "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", line 785, in convert_ipa_ca_cnames self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) File "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", line 772, in add_ipa_ca_dns_records host, zone = fqdn.split(".", 1) Unexpected error ValueError: need more than 1 value to unpack -- Petr? From jcholast at redhat.com Fri Apr 12 12:30:51 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 12 Apr 2013 14:30:51 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <5167FBD6.2070001@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> Message-ID: <5167FE7B.5040401@redhat.com> On 12.4.2013 14:19, Petr Viktorin wrote: > On 04/12/2013 01:24 PM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Honza > > We used short names in the CNAMEs: > > $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca > Record name: ipa-ca > CNAME record: vm-109 > ---------------------------- > Number of entries returned 1 > ---------------------------- > > > But it seems the patch assumes a FQDN with a dot at the end. When > upgrading a 3.1 server I get: > > 2013-04-12T12:16:43Z INFO File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 613, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-upgradeconfig", line 853, in main > add_ca_dns_records() > > File "/usr/sbin/ipa-upgradeconfig", line 752, in add_ca_dns_records > bind.convert_ipa_ca_cnames(api.env.domain) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", > line 785, in convert_ipa_ca_cnames > self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", > line 772, in add_ipa_ca_dns_records > host, zone = fqdn.split(".", 1) > > Unexpected error > ValueError: need more than 1 value to unpack > Hmm, in my test setup the CNAMEs contained FQDNs. Fixed. Updated patch attached. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-126.1-Use-A-AAAA-records-instead-of-CNAME-records-in-ipa-c.patch Type: text/x-patch Size: 14463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-127.1-Delete-DNS-records-in-ipa-ca-on-ipa-csreplica-manage.patch Type: text/x-patch Size: 1912 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 12 12:53:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Apr 2013 14:53:28 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <5167FE7B.5040401@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> Message-ID: <516803C8.5000403@redhat.com> On 04/12/2013 02:30 PM, Jan Cholasta wrote: > On 12.4.2013 14:19, Petr Viktorin wrote: >> On 04/12/2013 01:24 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix . >>> >>> Honza >> >> We used short names in the CNAMEs: >> >> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca >> Record name: ipa-ca >> CNAME record: vm-109 >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> >> But it seems the patch assumes a FQDN with a dot at the end. When >> upgrading a 3.1 server I get: >> >> 2013-04-12T12:16:43Z INFO File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 613, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-upgradeconfig", line 853, in main >> add_ca_dns_records() >> >> File "/usr/sbin/ipa-upgradeconfig", line 752, in add_ca_dns_records >> bind.convert_ipa_ca_cnames(api.env.domain) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >> line 785, in convert_ipa_ca_cnames >> self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >> line 772, in add_ipa_ca_dns_records >> host, zone = fqdn.split(".", 1) >> >> Unexpected error >> ValueError: need more than 1 value to unpack >> > > Hmm, in my test setup the CNAMEs contained FQDNs. Fixed. IIRC, ipa-ca will contain FQDNs if the server is from different domain in DNS. I.e. for example if managed domain is example.com, but one replica runs in domain testrelm.com. This is something that needs to be supported&tested too. Martin From pviktori at redhat.com Fri Apr 12 13:50:47 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Apr 2013 15:50:47 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <5167FE7B.5040401@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> Message-ID: <51681137.8060308@redhat.com> On 04/12/2013 02:30 PM, Jan Cholasta wrote: > On 12.4.2013 14:19, Petr Viktorin wrote: >> On 04/12/2013 01:24 PM, Jan Cholasta wrote: >>> Hi, >>> >>> the attached patches fix . >>> >>> Honza >> >> We used short names in the CNAMEs: >> >> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca >> Record name: ipa-ca >> CNAME record: vm-109 >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> >> But it seems the patch assumes a FQDN with a dot at the end. When >> upgrading a 3.1 server I get: >> >> 2013-04-12T12:16:43Z INFO File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 613, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-upgradeconfig", line 853, in main >> add_ca_dns_records() >> >> File "/usr/sbin/ipa-upgradeconfig", line 752, in add_ca_dns_records >> bind.convert_ipa_ca_cnames(api.env.domain) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >> line 785, in convert_ipa_ca_cnames >> self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >> line 772, in add_ipa_ca_dns_records >> host, zone = fqdn.split(".", 1) >> >> Unexpected error >> ValueError: need more than 1 value to unpack >> > > Hmm, in my test setup the CNAMEs contained FQDNs. Fixed. > > Updated patch attached. A question: do we support users that *want* a CNAME in ipa-ca? AFAIK that is the usual way to do load-balancing, which is the recommended setup for big installations. With this patch, if there is one, ca-install will fail as it tries to add the A record: $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca Record name: ipa-ca CNAME record: ca.load-balancer.example.com. $ ipa-ca-install [...] ValidationError: invalid 'cnamerecord': Gettext('CNAME record is not allowed to coexist with any other record (RFC 1034, section 3.6.2)', domain='ipa', localedir=None) Even if we don't supoport CNAMEs here, I think this we should print a big warning in this case rather than fail. Upgrade state is machine-local, so every time an old master is upgraded, any CNAME would get replaced: $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca Record name: ipa-ca CNAME record: ca.load-balancer.example.com. ---------------------------- Number of entries returned 1 ---------------------------- $ sudo ipa-upgradeconfig ... $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca Record name: ipa-ca A record: 10.34.47.109 ---------------------------- Number of entries returned 1 ---------------------------- We should at least highlight this in the release notes, as it deletes users' data. -- Petr? From mkosek at redhat.com Fri Apr 12 13:58:28 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 12 Apr 2013 15:58:28 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <51681137.8060308@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> Message-ID: <51681304.4030904@redhat.com> On 04/12/2013 03:50 PM, Petr Viktorin wrote: > On 04/12/2013 02:30 PM, Jan Cholasta wrote: >> On 12.4.2013 14:19, Petr Viktorin wrote: >>> On 04/12/2013 01:24 PM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> the attached patches fix . >>>> >>>> Honza >>> >>> We used short names in the CNAMEs: >>> >>> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca >>> Record name: ipa-ca >>> CNAME record: vm-109 >>> ---------------------------- >>> Number of entries returned 1 >>> ---------------------------- >>> >>> >>> But it seems the patch assumes a FQDN with a dot at the end. When >>> upgrading a 3.1 server I get: >>> >>> 2013-04-12T12:16:43Z INFO File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 613, in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-upgradeconfig", line 853, in main >>> add_ca_dns_records() >>> >>> File "/usr/sbin/ipa-upgradeconfig", line 752, in add_ca_dns_records >>> bind.convert_ipa_ca_cnames(api.env.domain) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>> line 785, in convert_ipa_ca_cnames >>> self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>> line 772, in add_ipa_ca_dns_records >>> host, zone = fqdn.split(".", 1) >>> >>> Unexpected error >>> ValueError: need more than 1 value to unpack >>> >> >> Hmm, in my test setup the CNAMEs contained FQDNs. Fixed. >> >> Updated patch attached. > > A question: do we support users that *want* a CNAME in ipa-ca? AFAIK that is > the usual way to do load-balancing, which is the recommended setup for big > installations. > Given that CNAME can only point to one host, I do not know how can it be used to load balance. The idea with ipa-ca was to contain a number of A records, which would create a load balancer to some extent as client software checking the OCSP/CRL would run the request against one random A record and thus distribute the load among all FreeIPA CAs. As A cannot coexist with CNAME, we need to delete it. But it is true that it may be good idea to produce upgrade warning about it. Martin From rcritten at redhat.com Fri Apr 12 14:01:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Apr 2013 10:01:13 -0400 Subject: [Freeipa-devel] [PATCH] WIP backup and restore In-Reply-To: <5167E134.2030705@redhat.com> References: <514D2A3A.4010909@redhat.com> <5150928F.2010602@redhat.com> <5151C859.6040208@redhat.com> <515D7A5F.3050703@redhat.com> <515ED83D.50107@redhat.com> <515F3A16.9050500@redhat.com> <5163EBF2.8080004@redhat.com> <51648646.6070706@redhat.com> <51656EE9.3080108@redhat.com> <5165AF09.2030007@redhat.com> <51668C38.8020607@redhat.com> <51672E81.2090708@redhat.com> <5167E134.2030705@redhat.com> Message-ID: <516813A9.4040404@redhat.com> Petr Viktorin wrote: > On 04/11/2013 11:43 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/10/2013 08:27 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 04/09/2013 11:21 PM, Rob Crittenden wrote: >>>>>> Petr Viktorin wrote: >>>>>>> On 04/05/2013 10:54 PM, Rob Crittenden wrote: >>>>>>>> Petr Viktorin wrote: >>>>>>>>> On 04/04/2013 03:04 PM, Rob Crittenden wrote: >>>>>>>>>> Rob Crittenden wrote: >>>>>>>>>>> Petr Viktorin wrote: >>> [...] >>>>>>>>>>>> And for production, please have the commands log by default >>>>>>>>>>>> (set >>>>>>>>>>>> log_file_name). >>>>>>>>>>> >>>>>>>>>>> Yes, I plan on adding that in the future. >>> >>> One more comment here, shouldn't the log file be /var/log/iparestore.log >>> rather than /var/log/ipa_restore.log, to match all the other IPA logs? >> >> Sure. I did it because it kept conflicting with ipareplica-install.log >> and I like easy tabbing :-) >> >>> [...] >>>>>>>>> Could backup without --logs save which directories are there, and >>>>>>>>> restore create empty directories if they don't exist? To me >>>>>>>>> re-initializing a completely wiped machine looks like a big gain >>>>>>>>> for >>>>>>>>> the >>>>>>>>> extra effort. >>>>>>>> >>>>>>>> I went ahead and made this change, it wasn't a lot of work. >>> >>> Another issue: if a CA was never installed on the host, pkiuser doesn't >>> exist, and ipa-restore will fail on pwd.getpwnam(PKI_USER). And since >>> /etc/passwd is restored, the obvious workaround of adding the user >>> doesn't work. >> >> We should only call this if CA is in one of the services to be restored. >> I went ahead and added a try/except around getting the name to make it >> more bullet-proof. >>> >>> We need to mention in the docs that ipa-restore overwrites files we >>> don't fully control (/etc/passwd, /ect/group, /etc/pki/nssdb/). >>> We also restore named configuration even if IPA DNS is not installed, >>> and smb.conf without AD trusts. >> >> Added. I suppose we could eventually add additional excludes based on >> the restored features. >> >>> [...] >>>>>>> I found a bug with the following topology: >>>>>>> >>>>>>> [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2] >>>>>>> >>>>>>> Running ipa-restore on the 3.2 instance tries to disable the CA >>>>>>> replication agreement between the other two. >>>>>>> However, deep in ReplicationManager.agreement_dn it uses its own DS >>>>>>> instance name instead of the Dogtag-9-DS one, so the agreement isn't >>>>>>> found and the restore fails. >>>>>>> >>>>>>> >>>>>> >>>>>> Yeah, I'm not 100% sure how to address that either. Is it safe to >>>>>> assume >>>>>> that if the port is 7389 then the instance is pki-ca? >>>>> >>>>> The port was hardcoded so it is. >>>> >>>> Ok, just thanks for the other set of eyes. Updated patch attached. >>> >>> Yup, this is fixed, thanks. >>> >>>>>> Or should we test >>>>>> for the existence of the instance name like we do master/clone? >>>>>> >>>>>> I've also figured out why Update in Progress loops forever. It is >>>>>> because the older ipa-replica-manage do not re-enable the replication >>>>>> agreement, so replication can't continue. I'm not entirely sure >>>>>> how we >>>>>> will need to go about fixing this, except through documentation. >>> >>> Documentation works, but note that it'll affect anyone with a bunch of >>> upgraded (Dogtag-9 style) instances. It may be a pretty common case in >>> the wild. >>> Maybe we need to recommend reinstalling replicas entirely, rather than >>> re-initializing, just to be on the safe side. >>> >> >> Added. >> >> I also added a FILES section to both man pages to point out the log >> files and where the backups are saved. >> >> rob > > Thanks! > And that's all the issues I found. Let's set the beast free, so it gets > some wider testing. > > ACK > pushed ot master From pviktori at redhat.com Fri Apr 12 14:09:16 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Apr 2013 16:09:16 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <51681304.4030904@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> Message-ID: <5168158C.5070806@redhat.com> On 04/12/2013 03:58 PM, Martin Kosek wrote: > On 04/12/2013 03:50 PM, Petr Viktorin wrote: >> On 04/12/2013 02:30 PM, Jan Cholasta wrote: >>> On 12.4.2013 14:19, Petr Viktorin wrote: >>>> On 04/12/2013 01:24 PM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> the attached patches fix . >>>>> >>>>> Honza >>>> >>>> We used short names in the CNAMEs: >>>> >>>> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca >>>> Record name: ipa-ca >>>> CNAME record: vm-109 >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> >>>> But it seems the patch assumes a FQDN with a dot at the end. When >>>> upgrading a 3.1 server I get: >>>> >>>> 2013-04-12T12:16:43Z INFO File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> line 613, in run_script >>>> return_value = main_function() >>>> >>>> File "/usr/sbin/ipa-upgradeconfig", line 853, in main >>>> add_ca_dns_records() >>>> >>>> File "/usr/sbin/ipa-upgradeconfig", line 752, in add_ca_dns_records >>>> bind.convert_ipa_ca_cnames(api.env.domain) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>> line 785, in convert_ipa_ca_cnames >>>> self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>> line 772, in add_ipa_ca_dns_records >>>> host, zone = fqdn.split(".", 1) >>>> >>>> Unexpected error >>>> ValueError: need more than 1 value to unpack >>>> >>> >>> Hmm, in my test setup the CNAMEs contained FQDNs. Fixed. >>> >>> Updated patch attached. >> >> A question: do we support users that *want* a CNAME in ipa-ca? AFAIK that is >> the usual way to do load-balancing, which is the recommended setup for big >> installations. >> > > Given that CNAME can only point to one host, I do not know how can it be used > to load balance. The host behind the CNAME can still have multiple A records, and/or the record(s) can point to "real" load balancers that distribute traffic to several servers, taking into account how busy each one is and excluding ones that are down. From the discussions I'm under the impression that this is the proper "big enterprise" solution, which we don't do only because we don't want to integrate a load balancer into IPA. That's why I'm asking if/how we want to support it. > The idea with ipa-ca was to contain a number of A records, which would create a > load balancer to some extent as client software checking the OCSP/CRL would run > the request against one random A record and thus distribute the load among all > FreeIPA CAs. > > As A cannot coexist with CNAME, we need to delete it. But it is true that it > may be good idea to produce upgrade warning about it. > > Martin > -- Petr? From tbabej at redhat.com Fri Apr 12 14:10:40 2013 From: tbabej at redhat.com (Tomas Babej) Date: Fri, 12 Apr 2013 16:10:40 +0200 Subject: [Freeipa-devel] [PATCH 0048] Add nfs:NONE to default PAC types only when needed Message-ID: <516815E0.6080802@redhat.com> Hi, We need to add nfs:NONE as a default PAC type only if there's no other default PAC type for nfs. Adds a update plugin which determines whether default PAC type for nfs is set and adds nfs:NONE PAC type accordingly. https://fedorahosted.org/freeipa/ticket/3555 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0048-Add-nfs-NONE-to-default-PAC-types-only-when-needed.patch Type: text/x-patch Size: 3961 bytes Desc: not available URL: From dpal at redhat.com Fri Apr 12 14:15:24 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Apr 2013 10:15:24 -0400 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <5168158C.5070806@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <5168158C.5070806@redhat.com> Message-ID: <516816FC.8030807@redhat.com> On 04/12/2013 10:09 AM, Petr Viktorin wrote: > On 04/12/2013 03:58 PM, Martin Kosek wrote: >> On 04/12/2013 03:50 PM, Petr Viktorin wrote: >>> On 04/12/2013 02:30 PM, Jan Cholasta wrote: >>>> On 12.4.2013 14:19, Petr Viktorin wrote: >>>>> On 04/12/2013 01:24 PM, Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> the attached patches fix >>>>>> . >>>>>> >>>>>> Honza >>>>> >>>>> We used short names in the CNAMEs: >>>>> >>>>> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca >>>>> Record name: ipa-ca >>>>> CNAME record: vm-109 >>>>> ---------------------------- >>>>> Number of entries returned 1 >>>>> ---------------------------- >>>>> >>>>> >>>>> But it seems the patch assumes a FQDN with a dot at the end. When >>>>> upgrading a 3.1 server I get: >>>>> >>>>> 2013-04-12T12:16:43Z INFO File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>>> line 613, in run_script >>>>> return_value = main_function() >>>>> >>>>> File "/usr/sbin/ipa-upgradeconfig", line 853, in main >>>>> add_ca_dns_records() >>>>> >>>>> File "/usr/sbin/ipa-upgradeconfig", line 752, in >>>>> add_ca_dns_records >>>>> bind.convert_ipa_ca_cnames(api.env.domain) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>> line 785, in convert_ipa_ca_cnames >>>>> self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) >>>>> >>>>> File >>>>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", >>>>> line 772, in add_ipa_ca_dns_records >>>>> host, zone = fqdn.split(".", 1) >>>>> >>>>> Unexpected error >>>>> ValueError: need more than 1 value to unpack >>>>> >>>> >>>> Hmm, in my test setup the CNAMEs contained FQDNs. Fixed. >>>> >>>> Updated patch attached. >>> >>> A question: do we support users that *want* a CNAME in ipa-ca? AFAIK >>> that is >>> the usual way to do load-balancing, which is the recommended setup >>> for big >>> installations. >>> >> >> Given that CNAME can only point to one host, I do not know how can it >> be used >> to load balance. > > The host behind the CNAME can still have multiple A records, and/or > the record(s) can point to "real" load balancers that distribute > traffic to several servers, taking into account how busy each one is > and excluding ones that are down. > > From the discussions I'm under the impression that this is the proper > "big enterprise" solution, which we don't do only because we don't > want to integrate a load balancer into IPA. That's why I'm asking > if/how we want to support it. It should work without load balancer with just DNS but if big customer wants to put a load balancer he should be able to. > >> The idea with ipa-ca was to contain a number of A records, which >> would create a >> load balancer to some extent as client software checking the OCSP/CRL >> would run >> the request against one random A record and thus distribute the load >> among all >> FreeIPA CAs. >> >> As A cannot coexist with CNAME, we need to delete it. But it is true >> that it >> may be good idea to produce upgrade warning about it. >> >> Martin >> > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Apr 12 14:25:24 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Apr 2013 10:25:24 -0400 Subject: [Freeipa-devel] [PATCH] 1095 apply updates in order In-Reply-To: <5167DD89.2040107@redhat.com> References: <5165A949.9090700@redhat.com> <5166A0CE.4080709@redhat.com> <5166B847.6060304@redhat.com> <5167118E.8030907@redhat.com> <5167DD89.2040107@redhat.com> Message-ID: <51681954.2050801@redhat.com> Petr Viktorin wrote: > On 04/11/2013 09:39 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Petr Viktorin wrote: > [...] >>>> In the README, 10 - 19 should be Schema & configuration. >>> >>> OK. >>> >>>> While you're at it you can update the FDS Server reference (FDS was >>>> Fedora Directory Server, right?) >>>> >>> >>> Yeah, shows how old this is. I'll fix it. >> >> I updated the README with a bit more information. I dod not update the >> 10-19 range because it really should just be schema. It isn't that way >> in the updates currently, but it is what we should strive for. >> >> These are not hard and fast rules, with the exception of schema really, >> just a recommendation for organization. I can go ahead and move some >> files around if you really want, but I think it's just shuffling deck >> chairs. > > OK, I'm just curious what the design is more than anything. > > > > > I'm still not a fan of the block of ten approach, but the patch works as > designed. > > ACK. Please remember to also revert f7e27b5 when pushing. > pushed to master, reverted. I opened a new ticket to apply each file independently after a discussion with Petr in IRC. rob From pviktori at redhat.com Fri Apr 12 14:52:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 12 Apr 2013 16:52:14 +0200 Subject: [Freeipa-devel] [PATCH 0048] Add nfs:NONE to default PAC types only when needed In-Reply-To: <516815E0.6080802@redhat.com> References: <516815E0.6080802@redhat.com> Message-ID: <51681F9E.6040202@redhat.com> On 04/12/2013 04:10 PM, Tomas Babej wrote: > Hi, > > We need to add nfs:NONE as a default PAC type only if there's no > other default PAC type for nfs. Adds a update plugin which > determines whether default PAC type for nfs is set and adds > nfs:NONE PAC type accordingly. > > https://fedorahosted.org/freeipa/ticket/3555 > > Tomas Looks good, works well, see a few nitpicks below. [...] > diff --git a/ipaserver/install/plugins/update_pacs.py b/ipaserver/install/plugins/update_pacs.py [...] > +from ipapython.ipa_log_manager import * Please don't use star imports in new code. Only import what you need (that is, remove this import entirely). > +class update_pacs(PostUpdate): > + """ > + Includes default nfs:None only if no nfs: entry present in ipakrbauthzdata. > + """ > + > + order = MIDDLE > + > + def execute(self, **options): > + ldap = self.obj.backend > + > + try: > + dn = DN('cn=ipaConfig', 'cn=etc', api.env.basedn) > + entry = ldap.get_entry(dn, ['ipakrbauthzdata']) > + pacs = entry.get('ipakrbauthzdata') > + > + if pacs is None: This shouldn't happen (ipaKrbAuthzData gets a default in previous updates). It's not necessary to complicate the code, `pacs = entry.get('ipakrbauthzdata', [])` would do. > + self.log.warning('No ipakrbauthzdata attribute found.') > + return (False, False, []) > > + except errors.NotFound: > + self.log.warning('Error retrieving: %s' % str(dn)) > + return (False, False, []) > + > + nfs_pac_set = any(pac.startswith('nfs:') for pac in pacs) > + > + if not nfs_pac_set: > + self.log.debug('Adding nfs:None to default PAC types') > + updated_pacs = pacs + [u'nfs:NONE'] > + update = dict(ipakrbauthzdata=updated_pacs) > + ldap.update_entry(dn, update) This will work, but the preferred form for updates is now: entry['ipakrbauthzdata'] = updated_pacs ldap.update_entry(entry) > + else: > + self.log.debug('PAC for nfs is already set, not adding nfs:NONE.') > + > + return (False, False, []) > + > +api.register(update_pacs) > -- 1.8.1.4 Please also add the new update file to Makefile.am. -- Petr? From ssorce at redhat.com Fri Apr 12 14:55:17 2013 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 12 Apr 2013 10:55:17 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <51681304.4030904@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> Message-ID: <1211642414.42013.1365778517178.JavaMail.root@redhat.com> ----- Original Message ----- > On 04/12/2013 03:50 PM, Petr Viktorin wrote: > > On 04/12/2013 02:30 PM, Jan Cholasta wrote: > >> On 12.4.2013 14:19, Petr Viktorin wrote: > >>> On 04/12/2013 01:24 PM, Jan Cholasta wrote: > >>>> Hi, > >>>> > >>>> the attached patches fix . > >>>> > >>>> Honza > >>> > >>> We used short names in the CNAMEs: > >>> > >>> $ ipa dnsrecord-find idm.lab.eng.brq.redhat.com ipa-ca > >>> Record name: ipa-ca > >>> CNAME record: vm-109 > >>> ---------------------------- > >>> Number of entries returned 1 > >>> ---------------------------- > >>> > >>> > >>> But it seems the patch assumes a FQDN with a dot at the end. When > >>> upgrading a 3.1 server I get: > >>> > >>> 2013-04-12T12:16:43Z INFO File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > >>> line 613, in run_script > >>> return_value = main_function() > >>> > >>> File "/usr/sbin/ipa-upgradeconfig", line 853, in main > >>> add_ca_dns_records() > >>> > >>> File "/usr/sbin/ipa-upgradeconfig", line 752, in add_ca_dns_records > >>> bind.convert_ipa_ca_cnames(api.env.domain) > >>> > >>> File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", > >>> line 785, in convert_ipa_ca_cnames > >>> self.add_ipa_ca_dns_records(cname[:-1], domain_name, None) > >>> > >>> File > >>> "/usr/lib/python2.7/site-packages/ipaserver/install/bindinstance.py", > >>> line 772, in add_ipa_ca_dns_records > >>> host, zone = fqdn.split(".", 1) > >>> > >>> Unexpected error > >>> ValueError: need more than 1 value to unpack > >>> > >> > >> Hmm, in my test setup the CNAMEs contained FQDNs. Fixed. > >> > >> Updated patch attached. > > > > A question: do we support users that *want* a CNAME in ipa-ca? AFAIK that > > is > > the usual way to do load-balancing, which is the recommended setup for big > > installations. > > > > Given that CNAME can only point to one host, I do not know how can it be used > to load balance. > > The idea with ipa-ca was to contain a number of A records, which would create > a > load balancer to some extent as client software checking the OCSP/CRL would > run > the request against one random A record and thus distribute the load among > all > FreeIPA CAs. > > As A cannot coexist with CNAME, we need to delete it. But it is true that it > may be good idea to produce upgrade warning about it. We should not delete it. If the admin consciously changed the A name to a CNAME we should respect that decision. The problem is on upgrade I guess. I think on upgrade from 3.1 we just need to document admins should manually fix the record. After the upgrade he'll remove the CNAME and instead add an A name pointing to all the CA replicas manually ? Simo. -- Simo Sorce * Red Hat, Inc. * New York From npmccallum at redhat.com Fri Apr 12 15:34:59 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 12 Apr 2013 11:34:59 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <5167058C.5070501@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <5167058C.5070501@redhat.com> Message-ID: <1365780899.21323.30.camel@localhost.localdomain> On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: > Nathaniel McCallum wrote: > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > >> I'm not sure how I'd test it if I got it built. > > > > I'm working on this. I hope to have a clear answer next week. Bear with > > me... > > > >> Overall looks really good. > > > > I've split up the patch into multiple commits. I've also added .update > > files and a patch for ipa-kdb to feed krb5 the right user string. > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > Please take a look. I *think* I've got everything worked out so far with > > the exception of bug numbers / urls. Should every patch have a separate > > bug and a link to the design page? > > The ticket should go into every commit. I'd probably put the design link > there too, just for completeness. Future bug fixes, et all aren't going > to require the design page, but since these commits are all related to > the initial feature it will be nice to have. > > You can have multiple patches on the same ticket/bug. https://github.com/npmccallum/freeipa/commits/otp All four commits now have bug numbers and design page links. I'm adding the design page link to the tickets as we speak. Remaining issues (AFAICS): 1. The daemon (ipa-otpd) runs as root and binds anonymously 2. ipatokenRadiusSecret is readable by an anonymous bind Outstanding pieces: 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 #1 and #2 are within the scope of F19 and should hopefully land shortly (in separate commits). #3 and #4 are probably $nextrelease. Nathaniel From akrivoka at redhat.com Fri Apr 12 15:43:34 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 12 Apr 2013 17:43:34 +0200 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts In-Reply-To: <516739D8.5030702@redhat.com> References: <5165B308.2020804@redhat.com> <5165E135.1090007@redhat.com> <5166D411.8030308@redhat.com> <5166DD6F.20407@redhat.com> <516739D8.5030702@redhat.com> Message-ID: <51682BA6.70309@redhat.com> On 04/12/2013 12:31 AM, Ana Krivokapic wrote: > On 04/11/2013 05:57 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/11/2013 12:01 AM, Rob Crittenden wrote: >>>> Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> This patch set deprecates HBAC source hosts from IPA. >>>>> >>>>> See commit messages and the design page[1] for details. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3528 >>>>> >>>>> [1] http://www.freeipa.org/page/V3/HBACSourceHosts >>>> >>>> Been a while since I've run the UI but I get an error in FF 18: >>>> >>>> Timestamp: 04/10/2013 05:43:31 PM >>>> Error: TypeError: e.messages is undefined >>>> Source File: https://rawhide2.greyoak.com/ipa/ui/js/freeipa/app.js >>>> Line: 1 >>> >>> This probably means that you didn't rebuild the UI since 42300eb. >>> Try git clean and a fresh rebuild, or use tools in install/ui/util/ >>> (Petr Vobornik is the person to ask about those). >> >> Seems to have been a remnant of a previous build. I'm guessing that >> the UI build directories aren't covered by a clean/distclean. I >> manually removed some files from build and it works now. >> >>> >>>> The other changes seem to operate fine. I tested with an older client >>>> and got reasonable error messages back when I tried to do the various >>>> sourcehost things. >>>> >>>> I got an unknown error message with --add-sourcehost but it did >>>> include >>>> the text that the command is deprecated so I think this is acceptable. >>>> There isn't a lot we can do, I'm sorry we didn't add this exception in >>>> the beginning. >>>> >>>> I do wonder if we should leave the warning in hbactest if >>>> sourcehost is >>>> set though, for those cases where there are already options set. >> >> So this question still remains, should we leave the sourcehost >> warning in hbactest for another release or two? >> >> rob >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Rob and I agreed on IRC to put the sourcehost warning back in hbactest > for now. I updated the patch 0016 accordingly. (It also needed a > slight rebase, due to API changes that happened in the meantime.) New > version is attached. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel After further discussion on IRC, we decided there is no reason to keep the warning after all. I am attaching a rebased version of the original patch 0016. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0016-03-Deprecate-HBAC-source-hosts-from-CLI.patch Type: text/x-patch Size: 33566 bytes Desc: not available URL: From npmccallum at redhat.com Fri Apr 12 15:53:40 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 12 Apr 2013 11:53:40 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365780899.21323.30.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> Message-ID: <1365782020.21323.33.camel@localhost.localdomain> On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: > On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: > > Nathaniel McCallum wrote: > > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > > >> I'm not sure how I'd test it if I got it built. > > > > > > I'm working on this. I hope to have a clear answer next week. Bear with > > > me... > > > > > >> Overall looks really good. > > > > > > I've split up the patch into multiple commits. I've also added .update > > > files and a patch for ipa-kdb to feed krb5 the right user string. > > > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > > > Please take a look. I *think* I've got everything worked out so far with > > > the exception of bug numbers / urls. Should every patch have a separate > > > bug and a link to the design page? > > > > The ticket should go into every commit. I'd probably put the design link > > there too, just for completeness. Future bug fixes, et all aren't going > > to require the design page, but since these commits are all related to > > the initial feature it will be nice to have. > > > > You can have multiple patches on the same ticket/bug. > > https://github.com/npmccallum/freeipa/commits/otp > > All four commits now have bug numbers and design page links. I'm adding > the design page link to the tickets as we speak. > > Remaining issues (AFAICS): > 1. The daemon (ipa-otpd) runs as root and binds anonymously > 2. ipatokenRadiusSecret is readable by an anonymous bind 3. ipatokenT?OTP.* are readable by an anonymous bind In the case of both #2 and #3, only admins should have RW. ipa-otpd needs read access to ipatokenRadiusSecret. The DS bind plugin below (#2) needs read access to ipatokenT?OTP.*. > Outstanding pieces: > 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 > 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 > 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 > 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 > > #1 and #2 are within the scope of F19 and should hopefully land shortly > (in separate commits). #3 and #4 are probably $nextrelease. > > Nathaniel > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Fri Apr 12 18:30:40 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Apr 2013 14:30:40 -0400 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts In-Reply-To: <51682BA6.70309@redhat.com> References: <5165B308.2020804@redhat.com> <5165E135.1090007@redhat.com> <5166D411.8030308@redhat.com> <5166DD6F.20407@redhat.com> <516739D8.5030702@redhat.com> <51682BA6.70309@redhat.com> Message-ID: <516852D0.9000807@redhat.com> Ana Krivokapic wrote: > On 04/12/2013 12:31 AM, Ana Krivokapic wrote: >> On 04/11/2013 05:57 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> On 04/11/2013 12:01 AM, Rob Crittenden wrote: >>>>> Ana Krivokapic wrote: >>>>>> Hello, >>>>>> >>>>>> This patch set deprecates HBAC source hosts from IPA. >>>>>> >>>>>> See commit messages and the design page[1] for details. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3528 >>>>>> >>>>>> [1] http://www.freeipa.org/page/V3/HBACSourceHosts >>>>> >>>>> Been a while since I've run the UI but I get an error in FF 18: >>>>> >>>>> Timestamp: 04/10/2013 05:43:31 PM >>>>> Error: TypeError: e.messages is undefined >>>>> Source File: https://rawhide2.greyoak.com/ipa/ui/js/freeipa/app.js >>>>> Line: 1 >>>> >>>> This probably means that you didn't rebuild the UI since 42300eb. >>>> Try git clean and a fresh rebuild, or use tools in install/ui/util/ >>>> (Petr Vobornik is the person to ask about those). >>> >>> Seems to have been a remnant of a previous build. I'm guessing that >>> the UI build directories aren't covered by a clean/distclean. I >>> manually removed some files from build and it works now. >>> >>>> >>>>> The other changes seem to operate fine. I tested with an older client >>>>> and got reasonable error messages back when I tried to do the various >>>>> sourcehost things. >>>>> >>>>> I got an unknown error message with --add-sourcehost but it did >>>>> include >>>>> the text that the command is deprecated so I think this is acceptable. >>>>> There isn't a lot we can do, I'm sorry we didn't add this exception in >>>>> the beginning. >>>>> >>>>> I do wonder if we should leave the warning in hbactest if >>>>> sourcehost is >>>>> set though, for those cases where there are already options set. >>> >>> So this question still remains, should we leave the sourcehost >>> warning in hbactest for another release or two? >>> >>> rob >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> Rob and I agreed on IRC to put the sourcehost warning back in hbactest >> for now. I updated the patch 0016 accordingly. (It also needed a >> slight rebase, due to API changes that happened in the meantime.) New >> version is attached. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > After further discussion on IRC, we decided there is no reason to keep > the warning after all. I am attaching a rebased version of the original > patch 0016. ACK. Pushed to master and rebased and pushed to ipa-3-1 rob From akrivoka at redhat.com Fri Apr 12 18:45:55 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 12 Apr 2013 20:45:55 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <5167EF72.8090204@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> Message-ID: <51685663.8090402@redhat.com> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: > On 04/12/2013 12:44 PM, Martin Kosek wrote: >> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>> >>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>> Delete the >>>>>>>>>> related entry from realmdomains when the DNS zone is deleted >>>>>>>>>> from >>>>>>>>>> IPA. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>> I would add a TXT record as I described in >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>> >>>>>>>>> This integration probably should go to both commands, >>>>>>>>> realmdomains-* >>>>>>>>> dnszone-*. >>>>>>>>> >>>>>>>>> Any objections? AB? >>>>>>>> Adding TXT record is probably harmless. >>>>>>>> >>>>>>>> I would actually add the TXT record creation only to >>>>>>>> realmdomains-* and >>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>> This way a hook from dnszone-add will trigger adding TXT record >>>>>>>> back >>>>>>>> (via call to >>>>>>>> realmdomains-mod --add and then TXT record addition from >>>>>>>> there). Also >>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>> mapping >>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>> record is >>>>>>>> helpful there as well. >>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>> One more thing to check is that we don't do this for our own domain. >>>>>> >>>>> Our own domain is already in realmdomains by default, and it >>>>> cannot be >>>>> removed from there. So I don't think any check related to our >>>>> domain is >>>>> necessary. >>>> We shouldn't start creating TXT records for our own domain, that's >>>> what >>>> I'm asking for here. >>>> >>>> Think about server install stage -- we start creating our own >>>> domain and >>>> the hook then causes to create realmdomains entry for the domain, >>>> causing realmdomains-mod code to raise ValidationError which is not >>>> handled in dnszone-add code with this patch. >>>> >>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>> simply should avoid calling dnsrecord-add for the case we know >>>> wouldn't >>>> work. >>>> >>> I just realized that this ticket was not marked as RFE although it >>> obviously is >>> one. I fixed the ticket summary and wrote the design page for this >>> enhancement: >>> >>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>> >> Right, that was a good thing to do. I just have comment for the UPN >> enumeration >> image which you linked in the RFE - can you please process it, upload >> to the >> wiki and include in the overview? This will make the RFE page more >> appealing >> and it will also prevent us from having a broken link when Alexander >> removes >> the file from his temporary directory. >> >> Thanks, >> Martin > > Sure, done. > I added the functionality to create TXT record to realmdomains-mod, and also made sure that the case of our own domain is handled properly. Unit tests have been added to cover the new functionality. One unit test of the dns plugin needed adjusting, but it still fails due to the bug in the testing framework[1]. It should pass after the bug is fixed. Updated patch is attached. [1] https://fedorahosted.org/freeipa/ticket/3562 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0017-02-Integrate-realmdomains-with-IPA-DNS.patch Type: text/x-patch Size: 13001 bytes Desc: not available URL: From akrivoka at redhat.com Fri Apr 12 18:58:52 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 12 Apr 2013 20:58:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0014-0016 Deprecate HBAC source hosts In-Reply-To: <516852D0.9000807@redhat.com> References: <5165B308.2020804@redhat.com> <5165E135.1090007@redhat.com> <5166D411.8030308@redhat.com> <5166DD6F.20407@redhat.com> <516739D8.5030702@redhat.com> <51682BA6.70309@redhat.com> <516852D0.9000807@redhat.com> Message-ID: <5168596C.4080705@redhat.com> On 04/12/2013 08:30 PM, Rob Crittenden wrote: > Ana Krivokapic wrote: >> On 04/12/2013 12:31 AM, Ana Krivokapic wrote: >>> On 04/11/2013 05:57 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> On 04/11/2013 12:01 AM, Rob Crittenden wrote: >>>>>> Ana Krivokapic wrote: >>>>>>> Hello, >>>>>>> >>>>>>> This patch set deprecates HBAC source hosts from IPA. >>>>>>> >>>>>>> See commit messages and the design page[1] for details. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3528 >>>>>>> >>>>>>> [1] http://www.freeipa.org/page/V3/HBACSourceHosts >>>>>> >>>>>> Been a while since I've run the UI but I get an error in FF 18: >>>>>> >>>>>> Timestamp: 04/10/2013 05:43:31 PM >>>>>> Error: TypeError: e.messages is undefined >>>>>> Source File: https://rawhide2.greyoak.com/ipa/ui/js/freeipa/app.js >>>>>> Line: 1 >>>>> >>>>> This probably means that you didn't rebuild the UI since 42300eb. >>>>> Try git clean and a fresh rebuild, or use tools in install/ui/util/ >>>>> (Petr Vobornik is the person to ask about those). >>>> >>>> Seems to have been a remnant of a previous build. I'm guessing that >>>> the UI build directories aren't covered by a clean/distclean. I >>>> manually removed some files from build and it works now. >>>> >>>>> >>>>>> The other changes seem to operate fine. I tested with an older >>>>>> client >>>>>> and got reasonable error messages back when I tried to do the >>>>>> various >>>>>> sourcehost things. >>>>>> >>>>>> I got an unknown error message with --add-sourcehost but it did >>>>>> include >>>>>> the text that the command is deprecated so I think this is >>>>>> acceptable. >>>>>> There isn't a lot we can do, I'm sorry we didn't add this >>>>>> exception in >>>>>> the beginning. >>>>>> >>>>>> I do wonder if we should leave the warning in hbactest if >>>>>> sourcehost is >>>>>> set though, for those cases where there are already options set. >>>> >>>> So this question still remains, should we leave the sourcehost >>>> warning in hbactest for another release or two? >>>> >>>> rob >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Rob and I agreed on IRC to put the sourcehost warning back in hbactest >>> for now. I updated the patch 0016 accordingly. (It also needed a >>> slight rebase, due to API changes that happened in the meantime.) New >>> version is attached. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> After further discussion on IRC, we decided there is no reason to keep >> the warning after all. I am attaching a rebased version of the original >> patch 0016. > > ACK. Pushed to master and rebased and pushed to ipa-3-1 > > rob > I've linked the design page in http://www.freeipa.org/page/V3_Designs -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From npmccallum at redhat.com Fri Apr 12 21:39:26 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 12 Apr 2013 17:39:26 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365782020.21323.33.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> Message-ID: <1365802766.21323.36.camel@localhost.localdomain> On Fri, 2013-04-12 at 11:53 -0400, Nathaniel McCallum wrote: > On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: > > On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: > > > Nathaniel McCallum wrote: > > > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > > > >> I'm not sure how I'd test it if I got it built. > > > > > > > > I'm working on this. I hope to have a clear answer next week. Bear with > > > > me... > > > > > > > >> Overall looks really good. > > > > > > > > I've split up the patch into multiple commits. I've also added .update > > > > files and a patch for ipa-kdb to feed krb5 the right user string. > > > > > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > > > > > Please take a look. I *think* I've got everything worked out so far with > > > > the exception of bug numbers / urls. Should every patch have a separate > > > > bug and a link to the design page? > > > > > > The ticket should go into every commit. I'd probably put the design link > > > there too, just for completeness. Future bug fixes, et all aren't going > > > to require the design page, but since these commits are all related to > > > the initial feature it will be nice to have. > > > > > > You can have multiple patches on the same ticket/bug. > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > All four commits now have bug numbers and design page links. I'm adding > > the design page link to the tickets as we speak. > > > > Remaining issues (AFAICS): > > 1. The daemon (ipa-otpd) runs as root and binds anonymously > > 2. ipatokenRadiusSecret is readable by an anonymous bind > 3. ipatokenT?OTP.* are readable by an anonymous bind > > In the case of both #2 and #3, only admins should have RW. ipa-otpd > needs read access to ipatokenRadiusSecret. The DS bind plugin below (#2) > needs read access to ipatokenT?OTP.*. > > > Outstanding pieces: > > 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 > > 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 > > 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 > > 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 > > > > #1 and #2 are within the scope of F19 and should hopefully land shortly > > (in separate commits). #3 and #4 are probably $nextrelease. > > FYI - Here is an RPM with all of the code so far: http://koji.fedoraproject.org/koji/taskinfo?taskID=5247029 Nathaniel From pviktori at redhat.com Mon Apr 15 08:20:22 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 10:20:22 +0200 Subject: [Freeipa-devel] [PATCH] 0215 ipa-server-install: correct help text for --external_{cert, ca}_file Message-ID: <516BB846.10704@redhat.com> Hello, this fixes incorrect descriptions of the --external_cert_file & --external_ca_file options. https://fedorahosted.org/freeipa/ticket/3523 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0215-ipa-server-install-correct-help-text-for-external_-c.patch Type: text/x-patch Size: 2517 bytes Desc: not available URL: From akrivoka at redhat.com Mon Apr 15 09:50:47 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 15 Apr 2013 11:50:47 +0200 Subject: [Freeipa-devel] [PATCH] 0215 ipa-server-install: correct help text for --external_{cert, ca}_file In-Reply-To: <516BB846.10704@redhat.com> References: <516BB846.10704@redhat.com> Message-ID: <516BCD77.9070504@redhat.com> On 04/15/2013 10:20 AM, Petr Viktorin wrote: > Hello, > this fixes incorrect descriptions of the --external_cert_file & > --external_ca_file options. > > > https://fedorahosted.org/freeipa/ticket/3523 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel There are also 3 error messages in install/tools/ipa-server-install, that refer to PKCS#10 certificates. Do we also need to fix these? [akrivoka at server freeipa]$ git grep 'PKCS#10' install/tools/ipa-server-install install/tools/ipa-server-install: print "Can't load the PKCS#10 certificate: %s." % str(e) install/tools/ipa-server-install: print "Subject of the PKCS#10 certificate is not correct (got %s, expected %s)." % (certsubject, wantsubject) install/tools/ipa-server-install: print "The PKCS#10 certificate is not signed by the external CA (unknown issuer %s)." % certissuer -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Apr 15 10:26:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 12:26:25 +0200 Subject: [Freeipa-devel] [PATCH] 0215 ipa-server-install: correct help text for --external_{cert, ca}_file In-Reply-To: <516BCD77.9070504@redhat.com> References: <516BB846.10704@redhat.com> <516BCD77.9070504@redhat.com> Message-ID: <516BD5D1.8010402@redhat.com> On 04/15/2013 11:50 AM, Ana Krivokapic wrote: > On 04/15/2013 10:20 AM, Petr Viktorin wrote: >> Hello, >> this fixes incorrect descriptions of the --external_cert_file & >> --external_ca_file options. >> >> >> https://fedorahosted.org/freeipa/ticket/3523 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > There are also 3 error messages in install/tools/ipa-server-install, > that refer to > PKCS#10 certificates. Do we also need to fix these? > > [akrivoka at server freeipa]$ git grep 'PKCS#10' > install/tools/ipa-server-install > install/tools/ipa-server-install: print "Can't load the > PKCS#10 certificate: %s." % str(e) > install/tools/ipa-server-install: print "Subject of the > PKCS#10 certificate is not correct (got %s, expected %s)." % > (certsubject, wantsubject) > install/tools/ipa-server-install: print "The PKCS#10 > certificate is not signed by the external CA (unknown issuer %s)." % > certissuer Good catch, thanks. I've changed those as well. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0215.2-ipa-server-install-correct-help-text-for-external_-c.patch Type: text/x-patch Size: 3921 bytes Desc: not available URL: From jcholast at redhat.com Mon Apr 15 10:31:32 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 15 Apr 2013 12:31:32 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <1211642414.42013.1365778517178.JavaMail.root@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <1211642414.42013.1365778517178.JavaMail.root@redhat.com> Message-ID: <516BD704.8030304@redhat.com> On 12.4.2013 16:55, Simo Sorce wrote: > > > ----- Original Message ----- >> On 04/12/2013 03:50 PM, Petr Viktorin wrote: >>> A question: do we support users that *want* a CNAME in ipa-ca? AFAIK that >>> is >>> the usual way to do load-balancing, which is the recommended setup for big >>> installations. >>> >> >> Given that CNAME can only point to one host, I do not know how can it be used >> to load balance. >> >> The idea with ipa-ca was to contain a number of A records, which would create >> a >> load balancer to some extent as client software checking the OCSP/CRL would >> run >> the request against one random A record and thus distribute the load among >> all >> FreeIPA CAs. >> >> As A cannot coexist with CNAME, we need to delete it. But it is true that it >> may be good idea to produce upgrade warning about it. > > We should not delete it. > If the admin consciously changed the A name to a CNAME we should respect that decision. > The problem is on upgrade I guess. > I think on upgrade from 3.1 we just need to document admins should manually fix the record. > After the upgrade he'll remove the CNAME and instead add an A name pointing to all the CA replicas manually ? > > Simo. > > I have changed the patch so that the CNAMEs are replaced with A/AAAA if and only if they all point to IPA masters, otherwise a warning is printed. Is that OK? Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-126.2-Use-A-AAAA-records-instead-of-CNAME-records-in-ipa-c.patch Type: text/x-patch Size: 15682 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-127.2-Delete-DNS-records-in-ipa-ca-on-ipa-csreplica-manage.patch Type: text/x-patch Size: 1913 bytes Desc: not available URL: From tbabej at redhat.com Mon Apr 15 10:32:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 15 Apr 2013 12:32:20 +0200 Subject: [Freeipa-devel] [PATCH 0048] Add nfs:NONE to default PAC types only when needed In-Reply-To: <51681F9E.6040202@redhat.com> References: <516815E0.6080802@redhat.com> <51681F9E.6040202@redhat.com> Message-ID: <516BD734.8080204@redhat.com> On 04/12/2013 04:52 PM, Petr Viktorin wrote: > On 04/12/2013 04:10 PM, Tomas Babej wrote: >> Hi, >> >> We need to add nfs:NONE as a default PAC type only if there's no >> other default PAC type for nfs. Adds a update plugin which >> determines whether default PAC type for nfs is set and adds >> nfs:NONE PAC type accordingly. >> >> https://fedorahosted.org/freeipa/ticket/3555 >> >> Tomas > > Looks good, works well, see a few nitpicks below. > > [...] >> diff --git a/ipaserver/install/plugins/update_pacs.py >> b/ipaserver/install/plugins/update_pacs.py > [...] >> +from ipapython.ipa_log_manager import * > > Please don't use star imports in new code. Only import what you need > (that is, remove this import entirely). > >> +class update_pacs(PostUpdate): >> + """ >> + Includes default nfs:None only if no nfs: entry present in >> ipakrbauthzdata. >> + """ >> + >> + order = MIDDLE >> + >> + def execute(self, **options): >> + ldap = self.obj.backend >> + >> + try: >> + dn = DN('cn=ipaConfig', 'cn=etc', api.env.basedn) >> + entry = ldap.get_entry(dn, ['ipakrbauthzdata']) >> + pacs = entry.get('ipakrbauthzdata') >> + >> + if pacs is None: > > This shouldn't happen (ipaKrbAuthzData gets a default in previous > updates). It's not necessary to complicate the code, `pacs = > entry.get('ipakrbauthzdata', [])` would do. Yes, this was probably overcautious. > >> + self.log.warning('No ipakrbauthzdata attribute found.') >> + return (False, False, []) >> >> + except errors.NotFound: >> + self.log.warning('Error retrieving: %s' % str(dn)) >> + return (False, False, []) >> + >> + nfs_pac_set = any(pac.startswith('nfs:') for pac in pacs) >> + >> + if not nfs_pac_set: >> + self.log.debug('Adding nfs:None to default PAC types') >> + updated_pacs = pacs + [u'nfs:NONE'] >> + update = dict(ipakrbauthzdata=updated_pacs) >> + ldap.update_entry(dn, update) > > This will work, but the preferred form for updates is now: > entry['ipakrbauthzdata'] = updated_pacs > ldap.update_entry(entry) > >> + else: >> + self.log.debug('PAC for nfs is already set, not adding >> nfs:NONE.') >> + >> + return (False, False, []) >> + >> +api.register(update_pacs) >> -- 1.8.1.4 > > Please also add the new update file to Makefile.am. > Thank you for the review. Updated patch attached. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0048-2-Add-nfs-NONE-to-default-PAC-types-only-when-needed.patch Type: text/x-patch Size: 4262 bytes Desc: not available URL: From tbabej at redhat.com Mon Apr 15 10:43:34 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 15 Apr 2013 12:43:34 +0200 Subject: [Freeipa-devel] [PATCH 0034] Deny LDAP binds for user accounts with expired principal In-Reply-To: <5162CC60.8040008@redhat.com> References: <511A72D9.6090506@redhat.com> <511A75F0.7070801@redhat.com> <1360689791.3838.56.camel@willson.li.ssimo.org> <511B8632.7000709@redhat.com> <5159E560.6030603@redhat.com> <5162CC60.8040008@redhat.com> Message-ID: <516BD9D6.6020800@redhat.com> On 04/08/2013 03:55 PM, Martin Kosek wrote: > On 04/01/2013 09:52 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 02/12/2013 06:23 PM, Simo Sorce wrote: >>>> On Tue, 2013-02-12 at 18:03 +0100, Tomas Babej wrote: >>>>> On 02/12/2013 05:50 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> This patch adds a check for krbprincipalexpiration attribute to >>>>>> pre_bind operation >>>>>> in ipa-pwd-extop dirsrv plugin. If the principal is expired, auth is >>>>>> denied and LDAP_INVALID_CREDENTIALS along with the error message is >>>>>> sent back to the client. Since krbprincipalexpiration attribute is >>>>> not >>>>>> mandatory, if there is no value set, the check is passed. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3305 >>>> Comments inline. >>>>> @@ -1166,6 +1173,29 @@ static int ipapwd_pre_bind(Slapi_PBlock *pb) >>>>> goto done; >>>>> } >>>>> + /* check the krbPrincipalExpiration attribute is present */ >>>>> + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", >>>>> &attr); >>>>> + if (!ret) { >>>> ret is not a boolean so probably better ti use (ret != 0) >>>> >>>>> + /* if it is, check whether the principal has not expired */ >>>>> + >>>>> + principal_expire = slapi_entry_attr_get_charptr(entry, >>>>> + "krbprincipalexpiration"); >>>>> + memset(&expire_tm, 0, sizeof (expire_tm)); >>>>> + >>>>> + if (strptime(principal_expire, "%Y%m%d%H%M%SZ", &expire_tm)){ >>>> style issue missing space between ) and { >>>> >>>>> + expire_time = mktime(&expire_tm); >>>>> + /* this might have overflown on 32-bit system */ >>>> This comment does not help to point out what you want to put in >>>> evidence. >>>> if there is an overflow what is the consequence ? Or does it mean the >>>> next condition is taking that into account ? >>> Yeah, this was rather ill-worded. Replaced by a rather verbose >>> comment that hopefully clears things out. >>>>> + if (current_time > expire_time && expire_time > 0){ >>>> style issue missing space between ) and { >>>> >>>>> + LOG_FATAL("kerberos principal has expired in user >>>>> entry: %s\n", >>>>> + dn); >>>> I think a better phrasing would be: "The kerberos principal on %s is >>>> expired\n" >>>> >>>>> + errMesg = "Kerberos principal has expired."; >>>> s/has/is/ >>>> >>>> The rest looks good to me. >>>> >>>> Simo. >>> Styling issues fixed and updated patch attached :) >> Small nit, the expiration error should probably use 'in' not 'on'. >> >> I'm not sure LDAP_INVALID_CREDENTIALS is the right return code. This implies >> that the password is wrong. I think that LDAP_UNWILLING_TO_PERFORM is probably >> more correct here. It is what we return on other policy failures. >> >> rob >> > Additional findings: > > 1) Lets not try to get current_time every time, but only when its needed (i.e. > krbPrincipalExpiration is set) - AFAIK, it is not so cheap operation: > > + /* get current time*/ > + current_time = time(NULL); > > 2) Why using slapi_entry_attr_get_charptr and thus let 389-ds find the > attribute again when we already have a pointer for the attribute? Would > slapi_attr_first_value following slapi_entry_attr_find be faster approach? > > + ret = slapi_entry_attr_find(entry, "krbPrincipalExpiration", &attr); > + if (ret != 0) { > + /* if it is, check whether the principal has not expired */ > + > + principal_expire = slapi_entry_attr_get_charptr(entry, > + "krbprincipalexpiration"); > > This way, we would not create a copy of this attribute value - we do not need a > copy, we just do check against it. > > > 3) Shouldn't we return -1 in the end when the auth fails? We do that in other > pre_callbacks. Otherwise we just return 0 (success): > > + if (auth_failed){ > + slapi_send_ldap_result(pb, LDAP_INVALID_CREDENTIALS, NULL, errMesg, > + 0, NULL); > + } > + > return 0; > > Martin Thank you both for the review. I updated and retested the patch, with your suggestions incorporated. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0034-4-Deny-LDAP-binds-for-user-accounts-with-expired-princ.patch Type: text/x-patch Size: 4245 bytes Desc: not available URL: From akrivoka at redhat.com Mon Apr 15 11:25:40 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 15 Apr 2013 13:25:40 +0200 Subject: [Freeipa-devel] [PATCH] 0215 ipa-server-install: correct help text for --external_{cert, ca}_file In-Reply-To: <516BD5D1.8010402@redhat.com> References: <516BB846.10704@redhat.com> <516BCD77.9070504@redhat.com> <516BD5D1.8010402@redhat.com> Message-ID: <516BE3B4.9050008@redhat.com> On 04/15/2013 12:26 PM, Petr Viktorin wrote: > On 04/15/2013 11:50 AM, Ana Krivokapic wrote: >> On 04/15/2013 10:20 AM, Petr Viktorin wrote: >>> Hello, >>> this fixes incorrect descriptions of the --external_cert_file & >>> --external_ca_file options. >>> >>> >>> https://fedorahosted.org/freeipa/ticket/3523 >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> >> There are also 3 error messages in install/tools/ipa-server-install, >> that refer to >> PKCS#10 certificates. Do we also need to fix these? >> >> [akrivoka at server freeipa]$ git grep 'PKCS#10' >> install/tools/ipa-server-install >> install/tools/ipa-server-install: print "Can't load the >> PKCS#10 certificate: %s." % str(e) >> install/tools/ipa-server-install: print "Subject of the >> PKCS#10 certificate is not correct (got %s, expected %s)." % >> (certsubject, wantsubject) >> install/tools/ipa-server-install: print "The PKCS#10 >> certificate is not signed by the external CA (unknown issuer %s)." % >> certissuer > > Good catch, thanks. I've changed those as well. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Apr 15 11:34:31 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 13:34:31 +0200 Subject: [Freeipa-devel] [PATCH] 0215 ipa-server-install: correct help text for --external_{cert, ca}_file In-Reply-To: <516BE3B4.9050008@redhat.com> References: <516BB846.10704@redhat.com> <516BCD77.9070504@redhat.com> <516BD5D1.8010402@redhat.com> <516BE3B4.9050008@redhat.com> Message-ID: <516BE5C7.1000706@redhat.com> On 04/15/2013 01:25 PM, Ana Krivokapic wrote: > On 04/15/2013 12:26 PM, Petr Viktorin wrote: >> On 04/15/2013 11:50 AM, Ana Krivokapic wrote: >>> On 04/15/2013 10:20 AM, Petr Viktorin wrote: >>>> Hello, >>>> this fixes incorrect descriptions of the --external_cert_file & >>>> --external_ca_file options. >>>> >>>> >>>> https://fedorahosted.org/freeipa/ticket/3523 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> There are also 3 error messages in install/tools/ipa-server-install, >>> that refer to >>> PKCS#10 certificates. Do we also need to fix these? >>> >>> [akrivoka at server freeipa]$ git grep 'PKCS#10' >>> install/tools/ipa-server-install >>> install/tools/ipa-server-install: print "Can't load the >>> PKCS#10 certificate: %s." % str(e) >>> install/tools/ipa-server-install: print "Subject of the >>> PKCS#10 certificate is not correct (got %s, expected %s)." % >>> (certsubject, wantsubject) >>> install/tools/ipa-server-install: print "The PKCS#10 >>> certificate is not signed by the external CA (unknown issuer %s)." % >>> certissuer >> >> Good catch, thanks. I've changed those as well. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > ACK > Pushed to master. Martin From pviktori at redhat.com Mon Apr 15 11:48:27 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 13:48:27 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <516BD704.8030304@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <1211642414.42013.1365778517178.JavaMail.root@redhat.com> <516BD704.8030304@redhat.com> Message-ID: <516BE90B.3010102@redhat.com> On 04/15/2013 12:31 PM, Jan Cholasta wrote: > On 12.4.2013 16:55, Simo Sorce wrote: >> >> >> ----- Original Message ----- >>> On 04/12/2013 03:50 PM, Petr Viktorin wrote: >>>> A question: do we support users that *want* a CNAME in ipa-ca? AFAIK >>>> that >>>> is >>>> the usual way to do load-balancing, which is the recommended setup >>>> for big >>>> installations. >>>> >>> >>> Given that CNAME can only point to one host, I do not know how can it >>> be used >>> to load balance. >>> >>> The idea with ipa-ca was to contain a number of A records, which >>> would create >>> a >>> load balancer to some extent as client software checking the OCSP/CRL >>> would >>> run >>> the request against one random A record and thus distribute the load >>> among >>> all >>> FreeIPA CAs. >>> >>> As A cannot coexist with CNAME, we need to delete it. But it is true >>> that it >>> may be good idea to produce upgrade warning about it. >> >> We should not delete it. >> If the admin consciously changed the A name to a CNAME we should >> respect that decision. >> The problem is on upgrade I guess. >> I think on upgrade from 3.1 we just need to document admins should >> manually fix the record. >> After the upgrade he'll remove the CNAME and instead add an A name >> pointing to all the CA replicas manually ? >> >> Simo. >> >> > > I have changed the patch so that the CNAMEs are replaced with A/AAAA if > and only if they all point to IPA masters, otherwise a warning is > printed. Is that OK? OK with me, patch works well. ACK unless Simo really wants to always skip the update. -- Petr? From pviktori at redhat.com Mon Apr 15 12:02:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 14:02:31 +0200 Subject: [Freeipa-devel] [PATCH 0048] Add nfs:NONE to default PAC types only when needed In-Reply-To: <516BD734.8080204@redhat.com> References: <516815E0.6080802@redhat.com> <51681F9E.6040202@redhat.com> <516BD734.8080204@redhat.com> Message-ID: <516BEC57.7080003@redhat.com> On 04/15/2013 12:32 PM, Tomas Babej wrote: > On 04/12/2013 04:52 PM, Petr Viktorin wrote: >> On 04/12/2013 04:10 PM, Tomas Babej wrote: >>> Hi, >>> >>> We need to add nfs:NONE as a default PAC type only if there's no >>> other default PAC type for nfs. Adds a update plugin which >>> determines whether default PAC type for nfs is set and adds >>> nfs:NONE PAC type accordingly. >>> >>> https://fedorahosted.org/freeipa/ticket/3555 >>> >>> Tomas >> >> Looks good, works well, see a few nitpicks below. >> >> [...] >>> diff --git a/ipaserver/install/plugins/update_pacs.py >>> b/ipaserver/install/plugins/update_pacs.py >> [...] >>> +from ipapython.ipa_log_manager import * >> >> Please don't use star imports in new code. Only import what you need >> (that is, remove this import entirely). >> >>> +class update_pacs(PostUpdate): >>> + """ >>> + Includes default nfs:None only if no nfs: entry present in >>> ipakrbauthzdata. >>> + """ >>> + >>> + order = MIDDLE >>> + >>> + def execute(self, **options): >>> + ldap = self.obj.backend >>> + >>> + try: >>> + dn = DN('cn=ipaConfig', 'cn=etc', api.env.basedn) >>> + entry = ldap.get_entry(dn, ['ipakrbauthzdata']) >>> + pacs = entry.get('ipakrbauthzdata') >>> + >>> + if pacs is None: >> >> This shouldn't happen (ipaKrbAuthzData gets a default in previous >> updates). It's not necessary to complicate the code, `pacs = >> entry.get('ipakrbauthzdata', [])` would do. > Yes, this was probably overcautious. >> >>> + self.log.warning('No ipakrbauthzdata attribute found.') >>> + return (False, False, []) >>> >>> + except errors.NotFound: >>> + self.log.warning('Error retrieving: %s' % str(dn)) >>> + return (False, False, []) >>> + >>> + nfs_pac_set = any(pac.startswith('nfs:') for pac in pacs) >>> + >>> + if not nfs_pac_set: >>> + self.log.debug('Adding nfs:None to default PAC types') >>> + updated_pacs = pacs + [u'nfs:NONE'] >>> + update = dict(ipakrbauthzdata=updated_pacs) >>> + ldap.update_entry(dn, update) >> >> This will work, but the preferred form for updates is now: >> entry['ipakrbauthzdata'] = updated_pacs >> ldap.update_entry(entry) >> >>> + else: >>> + self.log.debug('PAC for nfs is already set, not adding >>> nfs:NONE.') >>> + >>> + return (False, False, []) >>> + >>> +api.register(update_pacs) >>> -- 1.8.1.4 >> >> Please also add the new update file to Makefile.am. >> > > Thank you for the review. Updated patch attached. > > Tomas ACK -- Petr? From mkosek at redhat.com Mon Apr 15 12:48:18 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 14:48:18 +0200 Subject: [Freeipa-devel] [PATCH 0048] Add nfs:NONE to default PAC types only when needed In-Reply-To: <516BEC57.7080003@redhat.com> References: <516815E0.6080802@redhat.com> <51681F9E.6040202@redhat.com> <516BD734.8080204@redhat.com> <516BEC57.7080003@redhat.com> Message-ID: <516BF712.9080606@redhat.com> On 04/15/2013 02:02 PM, Petr Viktorin wrote: > On 04/15/2013 12:32 PM, Tomas Babej wrote: >> On 04/12/2013 04:52 PM, Petr Viktorin wrote: >>> On 04/12/2013 04:10 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> We need to add nfs:NONE as a default PAC type only if there's no >>>> other default PAC type for nfs. Adds a update plugin which >>>> determines whether default PAC type for nfs is set and adds >>>> nfs:NONE PAC type accordingly. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3555 >>>> >>>> Tomas >>> >>> Looks good, works well, see a few nitpicks below. >>> >>> [...] >>>> diff --git a/ipaserver/install/plugins/update_pacs.py >>>> b/ipaserver/install/plugins/update_pacs.py >>> [...] >>>> +from ipapython.ipa_log_manager import * >>> >>> Please don't use star imports in new code. Only import what you need >>> (that is, remove this import entirely). >>> >>>> +class update_pacs(PostUpdate): >>>> + """ >>>> + Includes default nfs:None only if no nfs: entry present in >>>> ipakrbauthzdata. >>>> + """ >>>> + >>>> + order = MIDDLE >>>> + >>>> + def execute(self, **options): >>>> + ldap = self.obj.backend >>>> + >>>> + try: >>>> + dn = DN('cn=ipaConfig', 'cn=etc', api.env.basedn) >>>> + entry = ldap.get_entry(dn, ['ipakrbauthzdata']) >>>> + pacs = entry.get('ipakrbauthzdata') >>>> + >>>> + if pacs is None: >>> >>> This shouldn't happen (ipaKrbAuthzData gets a default in previous >>> updates). It's not necessary to complicate the code, `pacs = >>> entry.get('ipakrbauthzdata', [])` would do. >> Yes, this was probably overcautious. >>> >>>> + self.log.warning('No ipakrbauthzdata attribute found.') >>>> + return (False, False, []) >>>> >>>> + except errors.NotFound: >>>> + self.log.warning('Error retrieving: %s' % str(dn)) >>>> + return (False, False, []) >>>> + >>>> + nfs_pac_set = any(pac.startswith('nfs:') for pac in pacs) >>>> + >>>> + if not nfs_pac_set: >>>> + self.log.debug('Adding nfs:None to default PAC types') >>>> + updated_pacs = pacs + [u'nfs:NONE'] >>>> + update = dict(ipakrbauthzdata=updated_pacs) >>>> + ldap.update_entry(dn, update) >>> >>> This will work, but the preferred form for updates is now: >>> entry['ipakrbauthzdata'] = updated_pacs >>> ldap.update_entry(entry) >>> >>>> + else: >>>> + self.log.debug('PAC for nfs is already set, not adding >>>> nfs:NONE.') >>>> + >>>> + return (False, False, []) >>>> + >>>> +api.register(update_pacs) >>>> -- 1.8.1.4 >>> >>> Please also add the new update file to Makefile.am. >>> >> >> Thank you for the review. Updated patch attached. >> >> Tomas > > ACK > Pushed to master. Martin From akrivoka at redhat.com Mon Apr 15 13:40:24 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 15 Apr 2013 15:40:24 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Do not sort dictionaries in assert_deepequal utility function Message-ID: <516C0348.9030004@redhat.com> Sorting lists of dictionaries in assert_deepequal was causing inconsistencies in unit test execution. To fix this, do not sort lists if their elements are dictionaries. See the ticket description and comments for more information and example how to reproduce the problem. https://fedorahosted.org/freeipa/ticket/3562 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0018-Do-not-sort-dictionaries-in-assert_deepequal-utility.patch Type: text/x-patch Size: 2848 bytes Desc: not available URL: From mkosek at redhat.com Mon Apr 15 13:39:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 15:39:01 +0200 Subject: [Freeipa-devel] [PATCHES] 0210-0213 Drop selfsign server functionality In-Reply-To: <515DD115.3030501@redhat.com> References: <515D9903.1080807@redhat.com> <515DD115.3030501@redhat.com> Message-ID: <516C02F5.8060700@redhat.com> On 04/04/2013 09:14 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> Hello, >> >> These patches convert selfsign masters to CA-less on upgrade, and remove >> all selfsign-related code >> >> The files the CA uses are left around for admins to pick up cert >> management manually. Instructions for that are provided in the design >> document. They pretty much just document what the selfsign CA did. >> Removing the automation may seem like a step backwards, but when the >> steps are just a wiki page, the admins can adjust for their needs (e.g. >> issue wildcart certs). For an automated solution we have Dogtag. >> >> Design: http://freeipa.org/page/V3/Drop_selfsign_functionality >> Ticket: https://fedorahosted.org/freeipa/ticket/3494 >> >> (Note that removing the --selfsign *option*, not functionality, has a >> separate ticket and design doc.) > > As I've been looking at this I'm having some reservations about this. It is > going to remove functionality from a running server. And once gone I don't > think one could easily get it back. > > I guess I'd be fine deprecating it and no longer providing any support, and > strongly recommending that people move away from it, but dropping it > mid-release seems rather strict. > > rob I am thinking that keeping the nonfunctional selfsign code would rather create mess, I would personally tend to removing that in 3.2. As this patch also converts selfsign installations to CA-less, current selfsign installation would still work - except creating replicas where people would need to generate certs for the replica. I also did not see much resistance or concerns when Petr sent a Heads-up mail to freeipa-users (but of course, not every our user reads that). https://www.redhat.com/archives/freeipa-users/2013-March/msg00235.html Martin From rcritten at redhat.com Mon Apr 15 13:42:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Apr 2013 09:42:11 -0400 Subject: [Freeipa-devel] [PATCHES] 0210-0213 Drop selfsign server functionality In-Reply-To: <516C02F5.8060700@redhat.com> References: <515D9903.1080807@redhat.com> <515DD115.3030501@redhat.com> <516C02F5.8060700@redhat.com> Message-ID: <516C03B3.5080605@redhat.com> Martin Kosek wrote: > On 04/04/2013 09:14 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> Hello, >>> >>> These patches convert selfsign masters to CA-less on upgrade, and remove >>> all selfsign-related code >>> >>> The files the CA uses are left around for admins to pick up cert >>> management manually. Instructions for that are provided in the design >>> document. They pretty much just document what the selfsign CA did. >>> Removing the automation may seem like a step backwards, but when the >>> steps are just a wiki page, the admins can adjust for their needs (e.g. >>> issue wildcart certs). For an automated solution we have Dogtag. >>> >>> Design: http://freeipa.org/page/V3/Drop_selfsign_functionality >>> Ticket: https://fedorahosted.org/freeipa/ticket/3494 >>> >>> (Note that removing the --selfsign *option*, not functionality, has a >>> separate ticket and design doc.) >> >> As I've been looking at this I'm having some reservations about this. It is >> going to remove functionality from a running server. And once gone I don't >> think one could easily get it back. >> >> I guess I'd be fine deprecating it and no longer providing any support, and >> strongly recommending that people move away from it, but dropping it >> mid-release seems rather strict. >> >> rob > > I am thinking that keeping the nonfunctional selfsign code would rather create > mess, I would personally tend to removing that in 3.2. As this patch also > converts selfsign installations to CA-less, current selfsign installation would > still work - except creating replicas where people would need to generate certs > for the replica. > > I also did not see much resistance or concerns when Petr sent a Heads-up mail > to freeipa-users (but of course, not every our user reads that). > https://www.redhat.com/archives/freeipa-users/2013-March/msg00235.html > > Martin > You can also more easily issue server certs for services, and enrolled clients get a server cert. rob From ssorce at redhat.com Mon Apr 15 14:47:51 2013 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 15 Apr 2013 10:47:51 -0400 (EDT) Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <516BE90B.3010102@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <1211642414.42013.1365778517178.JavaMail.root@redhat.com> <516BD704.8030304@redhat.com> <516BE90B.3010102@redhat.com> Message-ID: <1304869496.517311.1366037271196.JavaMail.root@redhat.com> > On 04/15/2013 12:31 PM, Jan Cholasta wrote: > > I have changed the patch so that the CNAMEs are replaced with A/AAAA if > > and only if they all point to IPA masters, otherwise a warning is > > printed. Is that OK? > > OK with me, patch works well. > ACK unless Simo really wants to always skip the update. Looks great to me. Simo. -- Simo Sorce * Red Hat, Inc. * New York From pviktori at redhat.com Mon Apr 15 15:33:07 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 17:33:07 +0200 Subject: [Freeipa-devel] FreeIPA string freeze In-Reply-To: <516592D2.5090207@gmail.com> References: <5162E61A.5060700@redhat.com> <516540D6.3040001@redhat.com> <516592D2.5090207@gmail.com> Message-ID: <516C1DB3.4090108@redhat.com> On 04/10/2013 06:26 PM, J?r?me Fenal wrote: > Le 10/04/2013 14:27, Yuri Chornoivan a ?crit : >> Wed, 10 Apr 2013 13:37:10 +0300 ???? ???????? Petr Viktorin >> : >> >>> On 04/08/2013 05:54 PM, Yuri Chornoivan wrote: >>>> ???????? Mon, 08 Apr 2013 18:45:30 +0300, Petr Viktorin >>>> : >>>> >>>>> Hello, FreeIPA translators! >>>>> >>>>> We wanted to give enough time for translations, so we made an upstream >>>>> string freeze last week, giving about two weeks of translation time >>>>> until the beta. >>>>> We didn't expect most of the translations to be done already -- >>>>> Ukrainian at 100% and French with 40 strings missing. Thank you!! >>>>> >>>>> Meanwhile we have some fixes upstream that add/change additional >>>>> strings that would have to be postponed for the next release. >>>>> How much would it inconvenience you if instead of postponing the >>>>> patches, we'd push each change to Transifex as it is pushed to master? >>>>> >>>>> In the past J?r?me said that updating continuously would be better >>>>> than the string freezes and mass updates we do now. We don't have >>>>> resources to automate that*, but for slipping a few strings past >>>>> string freeze it could work. >>>>> >>>> >>>> Hi, >>>> >>>> Surely, it would be good to have fixes now (as well as some announce in >>>> trans at lists.fedoraproject.org ). >>>> >>>> And I'm all of the J?r?me's proposal. It is enough to have updates >>>> every >>>> 3-4 months. That will make the translation process significantly >>>> easier. >>>> >>> >>> Okay. I've pushed the updates to Transifex (7 new strings, expect a >>> couple more), and I'll do some more frequent updates in the future. >> >> Thanks for your work. > > And you have my thank you as well. > As we tend to agree for at least two mostly/fully translated languages, > I'd say that yes, regular updates (could be every 2 or 3 or 4 weeks to > have strings to translate, but not too many in a row) would be easier > for everybody to catch up. > >>> I've lurked on trans at lists.fedoraproject.org for a while and haven't >>> seen many announcements from projects. Is it the right list to >>> communicate string freezes/deadlines/releases? >> >> Yes. This is the right list for Fedora translation announces. >> Personally, I do not know why other Fedora Upstream projects do not >> announce their translation dates in this list. It is easy to send a >> message there and target Fedora translation coordinators of many >> languages at once. >> >> Yes, it might happen that you will not obtain much translations at >> once, but I cannot imagine the other way to contact new translators. >> >> Such strategy (regular announces in translator's mailing lists) works >> fine in many projects (KDE, GNOME, Audacity etc.) It's a win-win >> situation. You cannot lose if you make even one-sentence announces and >> do it regularly. > What could be done here is to show some role model. > While it is good for translators, some projects may also rely on the > fact that their own translators catch up by subscribing to their own > project updates in Transifex, which gives them the go to translate > remaining strings. This is for instance how it works for a few ones in > the French team. Okay, I'll announce the next "string freeze" there. > But I also agree that broadly announced strings freezes, and broad and > regular calls to contributions will get further attention for languages > that do not have yet the level of contributions Ukrainian or French > currently have. > > Last item, I've been quite busy by day work these days, but I'm also > working on a way to automate splitting huge strings such as the plugins > help/usage pages in smaller chunks (a 15 min > draft of the script seems to work for those plugins, attached if you > want to have a look at it). I did not test it yet to see the final > result, and I also need to work on doing the same on the .po files in > order to avoid manually splitting the translations. Thanks! Unfortunately I don't know Perl, so the script is a complete mystery to me. I'm busy on day work as well but I can see that with more frequent updates, splitting the strings is even more important. > I will keep you posted here when I have something. > > Regards, > > J. -- Petr? From pviktori at redhat.com Mon Apr 15 15:34:37 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 17:34:37 +0200 Subject: [Freeipa-devel] [PATCH] 0216 Update translations from Transifex Message-ID: <516C1E0D.4050409@redhat.com> Hello, Since the beta will be released soon, we should pull in all the hard work our translators have contributed. Ukrainian and French are almost complete ("almost" only due to our extremely lax string freeze). New languages: Catalan and Basque* Thanks to all translators! Validation finds one problem in French; it's an interesting false positive: locations: ipalib/parameters.py:1490 The following substitutions are absent in msgid: %(char)s The following substitutions are absent in msgstr: %(char)r >>> msgid <<< The character %(char)r is not allowed. >>> msgstr <<< Le caract?re ? %(char)s ? n'est pas autoris?. The problem here is that the faux-English quotes (which %r gives) are not appropriate for French. I'm not sure yet how to best solve this. I haven't attached the patch due to its large size. Please download it from: https://github.com/encukou/freeipa/commit/1b1e4129f20b44bcb650d5ffe02370ba3fbedef2.patch -- Petr? * plus Czech, which doesn't really count -- I used it for testing From jfenal at gmail.com Mon Apr 15 15:38:18 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 15 Apr 2013 17:38:18 +0200 Subject: [Freeipa-devel] [PATCH] 0216 Update translations from Transifex In-Reply-To: <516C1E0D.4050409@redhat.com> References: <516C1E0D.4050409@redhat.com> Message-ID: No, the problem is real here : %s vs. %r... :) Will fix it. 2013/4/15 Petr Viktorin > Hello, > Since the beta will be released soon, we should pull in all the hard work > our translators have contributed. > > Ukrainian and French are almost complete ("almost" only due to our > extremely lax string freeze). > New languages: Catalan and Basque* > > Thanks to all translators! > > > Validation finds one problem in French; it's an interesting false positive: > locations: ipalib/parameters.py:1490 > The following substitutions are absent in msgid: %(char)s > The following substitutions are absent in msgstr: %(char)r > >>> msgid <<< > The character %(char)r is not allowed. > >>> msgstr <<< > Le caract?re ? %(char)s ? n'est pas autoris?. > > The problem here is that the faux-English quotes (which %r gives) are not > appropriate for French. I'm not sure yet how to best solve this. > > > I haven't attached the patch due to its large size. Please download it > from: https://github.com/encukou/**freeipa/commit/** > 1b1e4129f20b44bcb650d5ffe02370**ba3fbedef2.patch > > > -- > Petr? > > * plus Czech, which doesn't really count -- I used it for testing > > ______________________________**_________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-devel > -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfenal at gmail.com Mon Apr 15 15:39:28 2013 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 15 Apr 2013 17:39:28 +0200 Subject: [Freeipa-devel] [PATCH] 0216 Update translations from Transifex In-Reply-To: References: <516C1E0D.4050409@redhat.com> Message-ID: Fixed ;) 2013/4/15 J?r?me Fenal > No, the problem is real here : %s vs. %r... :) > Will fix it. > > > 2013/4/15 Petr Viktorin > >> Hello, >> Since the beta will be released soon, we should pull in all the hard work >> our translators have contributed. >> >> Ukrainian and French are almost complete ("almost" only due to our >> extremely lax string freeze). >> New languages: Catalan and Basque* >> >> Thanks to all translators! >> >> >> Validation finds one problem in French; it's an interesting false >> positive: >> locations: ipalib/parameters.py:1490 >> The following substitutions are absent in msgid: %(char)s >> The following substitutions are absent in msgstr: %(char)r >> >>> msgid <<< >> The character %(char)r is not allowed. >> >>> msgstr <<< >> Le caract?re ? %(char)s ? n'est pas autoris?. >> >> The problem here is that the faux-English quotes (which %r gives) are not >> appropriate for French. I'm not sure yet how to best solve this. >> >> >> I haven't attached the patch due to its large size. Please download it >> from: https://github.com/encukou/**freeipa/commit/** >> 1b1e4129f20b44bcb650d5ffe02370**ba3fbedef2.patch >> >> >> -- >> Petr? >> >> * plus Czech, which doesn't really count -- I used it for testing >> >> ______________________________**_________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-devel >> > > > > -- > J?r?me Fenal > -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Apr 15 15:56:21 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 17:56:21 +0200 Subject: [Freeipa-devel] [PATCH] 0216 Update translations from Transifex In-Reply-To: References: <516C1E0D.4050409@redhat.com> Message-ID: <516C2325.4070109@redhat.com> On 04/15/2013 05:39 PM, J?r?me Fenal wrote: > Fixed ;) Thanks! Updated patch is here: https://github.com/encukou/freeipa/commit/416b9a7ea69c2f8f1711c62a1c77430d31ac5292.patch > 2013/4/15 J?r?me Fenal > > > No, the problem is real here : %s vs. %r... :) > Will fix it. > > > 2013/4/15 Petr Viktorin > > > Hello, > Since the beta will be released soon, we should pull in all the > hard work our translators have contributed. > > Ukrainian and French are almost complete ("almost" only due to > our extremely lax string freeze). > New languages: Catalan and Basque* > > Thanks to all translators! > > > Validation finds one problem in French; it's an interesting > false positive: > locations: ipalib/parameters.py:1490 > The following substitutions are absent in msgid: %(char)s > The following substitutions are absent in msgstr: %(char)r > >>> msgid <<< > The character %(char)r is not allowed. > >>> msgstr <<< > Le caract?re ? %(char)s ? n'est pas autoris?. > > The problem here is that the faux-English quotes (which %r > gives) are not appropriate for French. I'm not sure yet how to > best solve this. > > > I haven't attached the patch due to its large size. Please > download it from: > https://github.com/encukou/__freeipa/commit/__1b1e4129f20b44bcb650d5ffe02370__ba3fbedef2.patch > > -- Petr? From mkosek at redhat.com Mon Apr 15 16:08:14 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 18:08:14 +0200 Subject: [Freeipa-devel] [PATCHES] 0210-0213 Drop selfsign server functionality In-Reply-To: <516C03B3.5080605@redhat.com> References: <515D9903.1080807@redhat.com> <515DD115.3030501@redhat.com> <516C02F5.8060700@redhat.com> <516C03B3.5080605@redhat.com> Message-ID: <516C25EE.3040707@redhat.com> On 04/15/2013 03:42 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 04/04/2013 09:14 PM, Rob Crittenden wrote: >>> Petr Viktorin wrote: >>>> Hello, >>>> >>>> These patches convert selfsign masters to CA-less on upgrade, and remove >>>> all selfsign-related code >>>> >>>> The files the CA uses are left around for admins to pick up cert >>>> management manually. Instructions for that are provided in the design >>>> document. They pretty much just document what the selfsign CA did. >>>> Removing the automation may seem like a step backwards, but when the >>>> steps are just a wiki page, the admins can adjust for their needs (e.g. >>>> issue wildcart certs). For an automated solution we have Dogtag. >>>> >>>> Design: http://freeipa.org/page/V3/Drop_selfsign_functionality >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3494 >>>> >>>> (Note that removing the --selfsign *option*, not functionality, has a >>>> separate ticket and design doc.) >>> >>> As I've been looking at this I'm having some reservations about this. It is >>> going to remove functionality from a running server. And once gone I don't >>> think one could easily get it back. >>> >>> I guess I'd be fine deprecating it and no longer providing any support, and >>> strongly recommending that people move away from it, but dropping it >>> mid-release seems rather strict. >>> >>> rob >> >> I am thinking that keeping the nonfunctional selfsign code would rather create >> mess, I would personally tend to removing that in 3.2. As this patch also >> converts selfsign installations to CA-less, current selfsign installation would >> still work - except creating replicas where people would need to generate certs >> for the replica. >> >> I also did not see much resistance or concerns when Petr sent a Heads-up mail >> to freeipa-users (but of course, not every our user reads that). >> https://www.redhat.com/archives/freeipa-users/2013-March/msg00235.html >> >> Martin >> > > You can also more easily issue server certs for services, and enrolled clients > get a server cert. > > rob We had a discussion about this topic on a meeting and we have agreed on removing the selfsign completely. This will still not be end of the world for users running selfsign servers (if there are any) as they could use the new CA-less feature to generate certs for replica or other certs. Moving to review of this patch. 1) Upgrade of the actual selfsigned server did not seem to work for me: selfsigned master broke after I upgraded from 3.1.3 selfsigned server. # ipa cert-show 1 ipa: ERROR: an internal error has occurred httpd's error_log: [Mon Apr 15 11:53:15.080995 2013] [:error] [pid 6020] ipa: ERROR: non-public: AttributeError: 'NameSpace' object has no attribute 'ra' [Mon Apr 15 11:53:15.081047 2013] [:error] [pid 6020] Traceback (most recent call last): [Mon Apr 15 11:53:15.081053 2013] [:error] [pid 6020] File "/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333, in wsgi_execute [Mon Apr 15 11:53:15.081058 2013] [:error] [pid 6020] result = self.Command[name](*args, **options) [Mon Apr 15 11:53:15.081062 2013] [:error] [pid 6020] File "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 436, in __call__ [Mon Apr 15 11:53:15.081067 2013] [:error] [pid 6020] ret = self.run(*args, **options) [Mon Apr 15 11:53:15.081071 2013] [:error] [pid 6020] File "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 729, in run [Mon Apr 15 11:53:15.081076 2013] [:error] [pid 6020] result = self.execute(*args, **options) [Mon Apr 15 11:53:15.081080 2013] [:error] [pid 6020] File "/usr/lib/python2.7/site-packages/ipalib/ plugins/cert.py", line 530, in execute [Mon Apr 15 11:53:15.081085 2013] [:error] [pid 6020] result=self.Backend.ra. get_certificate(serial_number) [Mon Apr 15 11:53:15.081089 2013] [:error] [pid 6020] AttributeError: 'NameSpace' object has no attribute 'ra' Maybe the reason is that the selfsign server's default.conf has still enable_ra set to "True"? # cat /etc/ipa/default.conf [global] host=vm-037.idm.lab.bos.redhat.com basedn=dc=idm,dc=lab,dc=bos,dc=redhat,dc=com realm=IDM.LAB.BOS.REDHAT.COM domain=idm.lab.bos.redhat.com xmlrpc_uri=https://vm-037.idm.lab.bos.redhat.com/ipa/xml ldap_uri=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket enable_ra=True mode=production 2) Upgrade of a selfsigned replica seemed OK, but I still see its httpd and dirsrv certificates being tracked by certmonger, when I list them with "ipa-getcert list"... Martin From mkosek at redhat.com Mon Apr 15 16:30:29 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 18:30:29 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <51685663.8090402@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> Message-ID: <516C2B25.9000307@redhat.com> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: > On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>> >>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>> Delete the >>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>> IPA. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>> >>>>>>>>>> This integration probably should go to both commands, realmdomains-* >>>>>>>>>> dnszone-*. >>>>>>>>>> >>>>>>>>>> Any objections? AB? >>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>> >>>>>>>>> I would actually add the TXT record creation only to realmdomains-* and >>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>> (via call to >>>>>>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>>>>>> the fact that admin added manually some domain to realmdomains mapping >>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>>>>>>> helpful there as well. >>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>> >>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>> removed from there. So I don't think any check related to our domain is >>>>>> necessary. >>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>> I'm asking for here. >>>>> >>>>> Think about server install stage -- we start creating our own domain and >>>>> the hook then causes to create realmdomains entry for the domain, >>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>> handled in dnszone-add code with this patch. >>>>> >>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>> work. >>>>> >>>> I just realized that this ticket was not marked as RFE although it >>>> obviously is >>>> one. I fixed the ticket summary and wrote the design page for this >>>> enhancement: >>>> >>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>> >>> Right, that was a good thing to do. I just have comment for the UPN enumeration >>> image which you linked in the RFE - can you please process it, upload to the >>> wiki and include in the overview? This will make the RFE page more appealing >>> and it will also prevent us from having a broken link when Alexander removes >>> the file from his temporary directory. >>> >>> Thanks, >>> Martin >> >> Sure, done. >> > > I added the functionality to create TXT record to realmdomains-mod, and also > made sure that the case of our own domain is handled properly. Unit tests have > been added to cover the new functionality. One unit test of the dns plugin > needed adjusting, but it still fails due to the bug in the testing > framework[1]. It should pass after the bug is fixed. > > Updated patch is attached. > > [1] https://fedorahosted.org/freeipa/ticket/3562 > This looks nice, thanks for the new test cases. I experienced an issue with dnsrecord-find test in tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open ticket to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a show-stopper. This is a nitpick, but could you update tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same domains for testing as tests/test_xmlrpc/test_dns_plugin.py does? I often use example*.com zones in my testing and we also advertise test commands with these zones in "ipa help dns" too, so I (and maybe others) could get surprised that these zones are deleted after running the test suite. I.e. I would prefer to have dnszone*.test used for test. Thanks, Martin From pviktori at redhat.com Mon Apr 15 16:41:20 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 18:41:20 +0200 Subject: [Freeipa-devel] [PATCHES] 0210-0213 Drop selfsign server functionality In-Reply-To: <516C25EE.3040707@redhat.com> References: <515D9903.1080807@redhat.com> <515DD115.3030501@redhat.com> <516C02F5.8060700@redhat.com> <516C03B3.5080605@redhat.com> <516C25EE.3040707@redhat.com> Message-ID: <516C2DB0.5040705@redhat.com> On 04/15/2013 06:08 PM, Martin Kosek wrote: > On 04/15/2013 03:42 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 04/04/2013 09:14 PM, Rob Crittenden wrote: >>>> Petr Viktorin wrote: >>>>> Hello, >>>>> >>>>> These patches convert selfsign masters to CA-less on upgrade, and remove >>>>> all selfsign-related code >>>>> >>>>> The files the CA uses are left around for admins to pick up cert >>>>> management manually. Instructions for that are provided in the design >>>>> document. They pretty much just document what the selfsign CA did. >>>>> Removing the automation may seem like a step backwards, but when the >>>>> steps are just a wiki page, the admins can adjust for their needs (e.g. >>>>> issue wildcart certs). For an automated solution we have Dogtag. >>>>> >>>>> Design: http://freeipa.org/page/V3/Drop_selfsign_functionality >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3494 >>>>> >>>>> (Note that removing the --selfsign *option*, not functionality, has a >>>>> separate ticket and design doc.) >>>> >>>> As I've been looking at this I'm having some reservations about this. It is >>>> going to remove functionality from a running server. And once gone I don't >>>> think one could easily get it back. >>>> >>>> I guess I'd be fine deprecating it and no longer providing any support, and >>>> strongly recommending that people move away from it, but dropping it >>>> mid-release seems rather strict. >>>> >>>> rob >>> >>> I am thinking that keeping the nonfunctional selfsign code would rather create >>> mess, I would personally tend to removing that in 3.2. As this patch also >>> converts selfsign installations to CA-less, current selfsign installation would >>> still work - except creating replicas where people would need to generate certs >>> for the replica. >>> >>> I also did not see much resistance or concerns when Petr sent a Heads-up mail >>> to freeipa-users (but of course, not every our user reads that). >>> https://www.redhat.com/archives/freeipa-users/2013-March/msg00235.html >>> >>> Martin >>> >> >> You can also more easily issue server certs for services, and enrolled clients >> get a server cert. >> >> rob > > We had a discussion about this topic on a meeting and we have agreed on > removing the selfsign completely. This will still not be end of the world for > users running selfsign servers (if there are any) as they could use the new > CA-less feature to generate certs for replica or other certs. > > Moving to review of this patch. > > 1) Upgrade of the actual selfsigned server did not seem to work for me: > > selfsigned master broke after I upgraded from 3.1.3 selfsigned server. > > # ipa cert-show 1 > ipa: ERROR: an internal error has occurred > > httpd's error_log: > [Mon Apr 15 11:53:15.080995 2013] [:error] [pid 6020] ipa: ERROR: non-public: > AttributeError: 'NameSpace' object has no attribute 'ra' > [Mon Apr 15 11:53:15.081047 2013] [:error] [pid 6020] Traceback (most recent > call last): > [Mon Apr 15 11:53:15.081053 2013] [:error] [pid 6020] File > "/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", line 333, > in wsgi_execute > [Mon Apr 15 11:53:15.081058 2013] [:error] [pid 6020] result = > self.Command[name](*args, **options) > [Mon Apr 15 11:53:15.081062 2013] [:error] [pid 6020] File > "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 436, in __call__ > [Mon Apr 15 11:53:15.081067 2013] [:error] [pid 6020] ret = self.run(*args, > **options) > [Mon Apr 15 11:53:15.081071 2013] [:error] [pid 6020] File > "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 729, in run > [Mon Apr 15 11:53:15.081076 2013] [:error] [pid 6020] result = > self.execute(*args, **options) > [Mon Apr 15 11:53:15.081080 2013] [:error] [pid 6020] File > "/usr/lib/python2.7/site-packages/ipalib/ plugins/cert.py", line 530, in execute > [Mon Apr 15 11:53:15.081085 2013] [:error] [pid 6020] > result=self.Backend.ra. get_certificate(serial_number) > [Mon Apr 15 11:53:15.081089 2013] [:error] [pid 6020] AttributeError: > 'NameSpace' object has no attribute 'ra' > > > Maybe the reason is that the selfsign server's default.conf has still enable_ra > set to "True"? > > # cat /etc/ipa/default.conf > [global] > host=vm-037.idm.lab.bos.redhat.com > basedn=dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > realm=IDM.LAB.BOS.REDHAT.COM > domain=idm.lab.bos.redhat.com > xmlrpc_uri=https://vm-037.idm.lab.bos.redhat.com/ipa/xml > ldap_uri=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket > enable_ra=True > mode=production > > > 2) Upgrade of a selfsigned replica seemed OK, but I still see its httpd and > dirsrv certificates being tracked by certmonger, when I list them with > "ipa-getcert list"... > > Martin > Thanks for the catch. Here's a fixed version of the patches. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0210.2-Uninstall-selfsign-CA-on-upgrade.patch Type: text/x-patch Size: 5782 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0211.2-Remove-obsolete-self-sign-references-from-man-pages-.patch Type: text/x-patch Size: 6039 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0212.2-Drop-selfsign-server-functionality.patch Type: text/x-patch Size: 54756 bytes Desc: not available URL: From mkosek at redhat.com Mon Apr 15 16:47:14 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 18:47:14 +0200 Subject: [Freeipa-devel] [PATCH] 0216 Update translations from Transifex In-Reply-To: <516C2325.4070109@redhat.com> References: <516C1E0D.4050409@redhat.com> <516C2325.4070109@redhat.com> Message-ID: <516C2F12.3020208@redhat.com> Thanks both to Petr and our translators! Pushed to master. Martin On 04/15/2013 05:56 PM, Petr Viktorin wrote: > On 04/15/2013 05:39 PM, J?r?me Fenal wrote: >> Fixed ;) > > Thanks! > Updated patch is here: > https://github.com/encukou/freeipa/commit/416b9a7ea69c2f8f1711c62a1c77430d31ac5292.patch > > >> 2013/4/15 J?r?me Fenal > >> >> No, the problem is real here : %s vs. %r... :) >> Will fix it. >> >> >> 2013/4/15 Petr Viktorin > > >> >> Hello, >> Since the beta will be released soon, we should pull in all the >> hard work our translators have contributed. >> >> Ukrainian and French are almost complete ("almost" only due to >> our extremely lax string freeze). >> New languages: Catalan and Basque* >> >> Thanks to all translators! >> >> >> Validation finds one problem in French; it's an interesting >> false positive: >> locations: ipalib/parameters.py:1490 >> The following substitutions are absent in msgid: %(char)s >> The following substitutions are absent in msgstr: %(char)r >> >>> msgid <<< >> The character %(char)r is not allowed. >> >>> msgstr <<< >> Le caract?re ? %(char)s ? n'est pas autoris?. >> >> The problem here is that the faux-English quotes (which %r >> gives) are not appropriate for French. I'm not sure yet how to >> best solve this. >> >> >> I haven't attached the patch due to its large size. Please >> download it from: >> >> https://github.com/encukou/__freeipa/commit/__1b1e4129f20b44bcb650d5ffe02370__ba3fbedef2.patch >> >> >> >> >> > From akrivoka at redhat.com Mon Apr 15 16:53:03 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 15 Apr 2013 18:53:03 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516C2B25.9000307@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> Message-ID: <516C306F.70609@redhat.com> On 04/15/2013 06:30 PM, Martin Kosek wrote: > On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>> >>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>> Delete the >>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>> IPA. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>> >>>>>>>>>>> This integration probably should go to both commands, realmdomains-* >>>>>>>>>>> dnszone-*. >>>>>>>>>>> >>>>>>>>>>> Any objections? AB? >>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>> >>>>>>>>>> I would actually add the TXT record creation only to realmdomains-* and >>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>> (via call to >>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>>>>>>> the fact that admin added manually some domain to realmdomains mapping >>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>>>>>>>> helpful there as well. >>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>> >>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>> necessary. >>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>> I'm asking for here. >>>>>> >>>>>> Think about server install stage -- we start creating our own domain and >>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>> handled in dnszone-add code with this patch. >>>>>> >>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>> work. >>>>>> >>>>> I just realized that this ticket was not marked as RFE although it >>>>> obviously is >>>>> one. I fixed the ticket summary and wrote the design page for this >>>>> enhancement: >>>>> >>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>> >>>> Right, that was a good thing to do. I just have comment for the UPN enumeration >>>> image which you linked in the RFE - can you please process it, upload to the >>>> wiki and include in the overview? This will make the RFE page more appealing >>>> and it will also prevent us from having a broken link when Alexander removes >>>> the file from his temporary directory. >>>> >>>> Thanks, >>>> Martin >>> Sure, done. >>> >> I added the functionality to create TXT record to realmdomains-mod, and also >> made sure that the case of our own domain is handled properly. Unit tests have >> been added to cover the new functionality. One unit test of the dns plugin >> needed adjusting, but it still fails due to the bug in the testing >> framework[1]. It should pass after the bug is fixed. >> >> Updated patch is attached. >> >> [1] https://fedorahosted.org/freeipa/ticket/3562 >> > This looks nice, thanks for the new test cases. > > I experienced an issue with dnsrecord-find test in > tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open ticket > to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a > show-stopper. > > This is a nitpick, but could you update > tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same domains > for testing as tests/test_xmlrpc/test_dns_plugin.py does? > > I often use example*.com zones in my testing and we also advertise test > commands with these zones in "ipa help dns" too, so I (and maybe others) could > get surprised that these zones are deleted after running the test suite. I.e. I > would prefer to have dnszone*.test used for test. > > Thanks, > Martin Sure. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0017-03-Integrate-realmdomains-with-IPA-DNS.patch Type: text/x-patch Size: 13002 bytes Desc: not available URL: From pviktori at redhat.com Mon Apr 15 16:51:37 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 15 Apr 2013 18:51:37 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <1304869496.517311.1366037271196.JavaMail.root@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <1211642414.42013.1365778517178.JavaMail.root@redhat.com> <516BD704.8030304@redhat.com> <516BE90B.3010102@redhat.com> <1304869496.517311.1366037271196.JavaMail.root@redhat.com> Message-ID: <516C3019.8070209@redhat.com> On 04/15/2013 04:47 PM, Simo Sorce wrote: >> On 04/15/2013 12:31 PM, Jan Cholasta wrote: >>> I have changed the patch so that the CNAMEs are replaced with A/AAAA if >>> and only if they all point to IPA masters, otherwise a warning is >>> printed. Is that OK? >> >> OK with me, patch works well. >> ACK unless Simo really wants to always skip the update. > > Looks great to me. > > Simo. > OK, full ACK -- Petr? From mkosek at redhat.com Mon Apr 15 17:06:34 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 19:06:34 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516C306F.70609@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> Message-ID: <516C339A.2070005@redhat.com> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: > On 04/15/2013 06:30 PM, Martin Kosek wrote: >> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>> >>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>> Delete the >>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>> IPA. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>> >>>>>>>>>>>> This integration probably should go to both commands, realmdomains-* >>>>>>>>>>>> dnszone-*. >>>>>>>>>>>> >>>>>>>>>>>> Any objections? AB? >>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>> >>>>>>>>>>> I would actually add the TXT record creation only to realmdomains-* and >>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>> (via call to >>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>>>>>>>> the fact that admin added manually some domain to realmdomains mapping >>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>>>>>>>>> helpful there as well. >>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>> >>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>> necessary. >>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>> I'm asking for here. >>>>>>> >>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>> handled in dnszone-add code with this patch. >>>>>>> >>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>> work. >>>>>>> >>>>>> I just realized that this ticket was not marked as RFE although it >>>>>> obviously is >>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>> enhancement: >>>>>> >>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>> >>>>> Right, that was a good thing to do. I just have comment for the UPN enumeration >>>>> image which you linked in the RFE - can you please process it, upload to the >>>>> wiki and include in the overview? This will make the RFE page more appealing >>>>> and it will also prevent us from having a broken link when Alexander removes >>>>> the file from his temporary directory. >>>>> >>>>> Thanks, >>>>> Martin >>>> Sure, done. >>>> >>> I added the functionality to create TXT record to realmdomains-mod, and also >>> made sure that the case of our own domain is handled properly. Unit tests have >>> been added to cover the new functionality. One unit test of the dns plugin >>> needed adjusting, but it still fails due to the bug in the testing >>> framework[1]. It should pass after the bug is fixed. >>> >>> Updated patch is attached. >>> >>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>> >> This looks nice, thanks for the new test cases. >> >> I experienced an issue with dnsrecord-find test in >> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open ticket >> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >> show-stopper. >> >> This is a nitpick, but could you update >> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same domains >> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >> >> I often use example*.com zones in my testing and we also advertise test >> commands with these zones in "ipa help dns" too, so I (and maybe others) could >> get surprised that these zones are deleted after running the test suite. I.e. I >> would prefer to have dnszone*.test used for test. >> >> Thanks, >> Martin > > Sure. Updated patch attached. > One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you do checks for zone/record before you do the dnsrecord-add/dnsrecord-del command. I think this will unnecessarily make the command slower. You can just try add/delete a record and catch also a NotFound error - these commands already check for zone/record existence, so we do not need to do the checks twice. Relevant sections: + try: + api.Command['dnszone_show'](unicode(d)) + except errors.NotFound: + pass + else: + try: + api.Command['dnsrecord_add']( + unicode(d), + u'_kerberos', + txtrecord=api.env.realm + ) + except errors.EmptyModlist: + pass ... + try: + api.Command['dnszone_show'](unicode(d)) + except errors.NotFound: + pass + else: + try: + api.Command['dnsrecord_del']( + unicode(d), + u'_kerberos', + txtrecord=api.env.realm + ) + except errors.AttrValueNotFound: + pass Martin From akrivoka at redhat.com Mon Apr 15 17:28:01 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 15 Apr 2013 19:28:01 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516C339A.2070005@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> Message-ID: <516C38A1.5030506@redhat.com> On 04/15/2013 07:06 PM, Martin Kosek wrote: > On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>> >>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>> >>>>>>>>>>>>> This integration probably should go to both commands, realmdomains-* >>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>> >>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>> >>>>>>>>>>>> I would actually add the TXT record creation only to realmdomains-* and >>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>> (via call to >>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>>>>>>>>> the fact that admin added manually some domain to realmdomains mapping >>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>>>>>>>>>> helpful there as well. >>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>> >>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>> necessary. >>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>> I'm asking for here. >>>>>>>> >>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>> handled in dnszone-add code with this patch. >>>>>>>> >>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>> work. >>>>>>>> >>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>> obviously is >>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>> enhancement: >>>>>>> >>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>> >>>>>> Right, that was a good thing to do. I just have comment for the UPN enumeration >>>>>> image which you linked in the RFE - can you please process it, upload to the >>>>>> wiki and include in the overview? This will make the RFE page more appealing >>>>>> and it will also prevent us from having a broken link when Alexander removes >>>>>> the file from his temporary directory. >>>>>> >>>>>> Thanks, >>>>>> Martin >>>>> Sure, done. >>>>> >>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>> made sure that the case of our own domain is handled properly. Unit tests have >>>> been added to cover the new functionality. One unit test of the dns plugin >>>> needed adjusting, but it still fails due to the bug in the testing >>>> framework[1]. It should pass after the bug is fixed. >>>> >>>> Updated patch is attached. >>>> >>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>> >>> This looks nice, thanks for the new test cases. >>> >>> I experienced an issue with dnsrecord-find test in >>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open ticket >>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>> show-stopper. >>> >>> This is a nitpick, but could you update >>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same domains >>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>> >>> I often use example*.com zones in my testing and we also advertise test >>> commands with these zones in "ipa help dns" too, so I (and maybe others) could >>> get surprised that these zones are deleted after running the test suite. I.e. I >>> would prefer to have dnszone*.test used for test. >>> >>> Thanks, >>> Martin >> Sure. Updated patch attached. >> > One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you > do checks for zone/record before you do the dnsrecord-add/dnsrecord-del command. > > I think this will unnecessarily make the command slower. You can just try > add/delete a record and catch also a NotFound error - these commands already > check for zone/record existence, so we do not need to do the checks twice. > > Relevant sections: > > + try: > + api.Command['dnszone_show'](unicode(d)) > + except errors.NotFound: > + pass > + else: > + try: > + api.Command['dnsrecord_add']( > + unicode(d), > + u'_kerberos', > + txtrecord=api.env.realm > + ) > + except errors.EmptyModlist: > + pass > > ... > > + try: > + api.Command['dnszone_show'](unicode(d)) > + except errors.NotFound: > + pass > + else: > + try: > + api.Command['dnsrecord_del']( > + unicode(d), > + u'_kerberos', > + txtrecord=api.env.realm > + ) > + except errors.AttrValueNotFound: > + pass > > Martin Nice catch, those checks were totally unnecessary. Thanks. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0017-04-Integrate-realmdomains-with-IPA-DNS.patch Type: text/x-patch Size: 12669 bytes Desc: not available URL: From mkosek at redhat.com Mon Apr 15 19:16:49 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Apr 2013 21:16:49 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <516C3019.8070209@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <1211642414.42013.1365778517178.JavaMail.root@redhat.com> <516BD704.8030304@redhat.com> <516BE90B.3010102@redhat.com> <1304869496.517311.1366037271196.JavaMail.root@redhat.com> <516C3019.8070209@redhat.com> Message-ID: <516C5221.3070205@redhat.com> On 04/15/2013 06:51 PM, Petr Viktorin wrote: > On 04/15/2013 04:47 PM, Simo Sorce wrote: >>> On 04/15/2013 12:31 PM, Jan Cholasta wrote: >>>> I have changed the patch so that the CNAMEs are replaced with A/AAAA if >>>> and only if they all point to IPA masters, otherwise a warning is >>>> printed. Is that OK? >>> >>> OK with me, patch works well. >>> ACK unless Simo really wants to always skip the update. >> >> Looks great to me. >> >> Simo. >> > > OK, full ACK > Pushed to master. Jan, can you please rebase the patch also for ipa-3-1? We will need to fix this issue also for 3.1. Martin From rcritten at redhat.com Mon Apr 15 20:57:14 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Apr 2013 16:57:14 -0400 Subject: [Freeipa-devel] [PATCHES] 0210-0213 Drop selfsign server functionality In-Reply-To: <516C2DB0.5040705@redhat.com> References: <515D9903.1080807@redhat.com> <515DD115.3030501@redhat.com> <516C02F5.8060700@redhat.com> <516C03B3.5080605@redhat.com> <516C25EE.3040707@redhat.com> <516C2DB0.5040705@redhat.com> Message-ID: <516C69AA.1030507@redhat.com> Petr Viktorin wrote: > On 04/15/2013 06:08 PM, Martin Kosek wrote: >> On 04/15/2013 03:42 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 04/04/2013 09:14 PM, Rob Crittenden wrote: >>>>> Petr Viktorin wrote: >>>>>> Hello, >>>>>> >>>>>> These patches convert selfsign masters to CA-less on upgrade, and >>>>>> remove >>>>>> all selfsign-related code >>>>>> >>>>>> The files the CA uses are left around for admins to pick up cert >>>>>> management manually. Instructions for that are provided in the design >>>>>> document. They pretty much just document what the selfsign CA did. >>>>>> Removing the automation may seem like a step backwards, but when the >>>>>> steps are just a wiki page, the admins can adjust for their needs >>>>>> (e.g. >>>>>> issue wildcart certs). For an automated solution we have Dogtag. >>>>>> >>>>>> Design: http://freeipa.org/page/V3/Drop_selfsign_functionality >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3494 >>>>>> >>>>>> (Note that removing the --selfsign *option*, not functionality, has a >>>>>> separate ticket and design doc.) >>>>> >>>>> As I've been looking at this I'm having some reservations about >>>>> this. It is >>>>> going to remove functionality from a running server. And once gone >>>>> I don't >>>>> think one could easily get it back. >>>>> >>>>> I guess I'd be fine deprecating it and no longer providing any >>>>> support, and >>>>> strongly recommending that people move away from it, but dropping it >>>>> mid-release seems rather strict. >>>>> >>>>> rob >>>> >>>> I am thinking that keeping the nonfunctional selfsign code would >>>> rather create >>>> mess, I would personally tend to removing that in 3.2. As this patch >>>> also >>>> converts selfsign installations to CA-less, current selfsign >>>> installation would >>>> still work - except creating replicas where people would need to >>>> generate certs >>>> for the replica. >>>> >>>> I also did not see much resistance or concerns when Petr sent a >>>> Heads-up mail >>>> to freeipa-users (but of course, not every our user reads that). >>>> https://www.redhat.com/archives/freeipa-users/2013-March/msg00235.html >>>> >>>> Martin >>>> >>> >>> You can also more easily issue server certs for services, and >>> enrolled clients >>> get a server cert. >>> >>> rob >> >> We had a discussion about this topic on a meeting and we have agreed on >> removing the selfsign completely. This will still not be end of the >> world for >> users running selfsign servers (if there are any) as they could use >> the new >> CA-less feature to generate certs for replica or other certs. >> >> Moving to review of this patch. >> >> 1) Upgrade of the actual selfsigned server did not seem to work for me: >> >> selfsigned master broke after I upgraded from 3.1.3 selfsigned server. >> >> # ipa cert-show 1 >> ipa: ERROR: an internal error has occurred >> >> httpd's error_log: >> [Mon Apr 15 11:53:15.080995 2013] [:error] [pid 6020] ipa: ERROR: >> non-public: >> AttributeError: 'NameSpace' object has no attribute 'ra' >> [Mon Apr 15 11:53:15.081047 2013] [:error] [pid 6020] Traceback (most >> recent >> call last): >> [Mon Apr 15 11:53:15.081053 2013] [:error] [pid 6020] File >> "/usr/lib/python2.7/site-packages/ ipaserver/rpcserver.py", >> line 333, >> in wsgi_execute >> [Mon Apr 15 11:53:15.081058 2013] [:error] [pid 6020] result = >> self.Command[name](*args, **options) >> [Mon Apr 15 11:53:15.081062 2013] [:error] [pid 6020] File >> "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 436, in >> __call__ >> [Mon Apr 15 11:53:15.081067 2013] [:error] [pid 6020] ret = >> self.run(*args, >> **options) >> [Mon Apr 15 11:53:15.081071 2013] [:error] [pid 6020] File >> "/usr/lib/python2.7/site-packages/ipalib/ frontend.py", line 729, in run >> [Mon Apr 15 11:53:15.081076 2013] [:error] [pid 6020] result = >> self.execute(*args, **options) >> [Mon Apr 15 11:53:15.081080 2013] [:error] [pid 6020] File >> "/usr/lib/python2.7/site-packages/ipalib/ plugins/cert.py", line 530, >> in execute >> [Mon Apr 15 11:53:15.081085 2013] [:error] [pid 6020] >> result=self.Backend.ra. >> get_certificate(serial_number) >> [Mon Apr 15 11:53:15.081089 2013] [:error] [pid 6020] AttributeError: >> 'NameSpace' object has no attribute 'ra' >> >> >> Maybe the reason is that the selfsign server's default.conf has still >> enable_ra >> set to "True"? >> >> # cat /etc/ipa/default.conf >> [global] >> host=vm-037.idm.lab.bos.redhat.com >> basedn=dc=idm,dc=lab,dc=bos,dc=redhat,dc=com >> realm=IDM.LAB.BOS.REDHAT.COM >> domain=idm.lab.bos.redhat.com >> xmlrpc_uri=https://vm-037.idm.lab.bos.redhat.com/ipa/xml >> ldap_uri=ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket >> enable_ra=True >> mode=production >> >> >> 2) Upgrade of a selfsigned replica seemed OK, but I still see its >> httpd and >> dirsrv certificates being tracked by certmonger, when I list them with >> "ipa-getcert list"... >> >> Martin >> > > Thanks for the catch. Here's a fixed version of the patches. ACK, pushed to master rob From rcritten at redhat.com Mon Apr 15 21:21:10 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Apr 2013 17:21:10 -0400 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516C38A1.5030506@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> Message-ID: <516C6F46.6060204@redhat.com> Ana Krivokapic wrote: > On 04/15/2013 07:06 PM, Martin Kosek wrote: >> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> This integration probably should go to both commands, realmdomains-* >>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>> >>>>>>>>>>>>> I would actually add the TXT record creation only to realmdomains-* and >>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>> (via call to >>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). Also >>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains mapping >>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT record is >>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>> >>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>> necessary. >>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>> I'm asking for here. >>>>>>>>> >>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>> >>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>> work. >>>>>>>>> >>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>> obviously is >>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>> enhancement: >>>>>>>> >>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>> >>>>>>> Right, that was a good thing to do. I just have comment for the UPN enumeration >>>>>>> image which you linked in the RFE - can you please process it, upload to the >>>>>>> wiki and include in the overview? This will make the RFE page more appealing >>>>>>> and it will also prevent us from having a broken link when Alexander removes >>>>>>> the file from his temporary directory. >>>>>>> >>>>>>> Thanks, >>>>>>> Martin >>>>>> Sure, done. >>>>>> >>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>> made sure that the case of our own domain is handled properly. Unit tests have >>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>> needed adjusting, but it still fails due to the bug in the testing >>>>> framework[1]. It should pass after the bug is fixed. >>>>> >>>>> Updated patch is attached. >>>>> >>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>> >>>> This looks nice, thanks for the new test cases. >>>> >>>> I experienced an issue with dnsrecord-find test in >>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open ticket >>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>> show-stopper. >>>> >>>> This is a nitpick, but could you update >>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same domains >>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>> >>>> I often use example*.com zones in my testing and we also advertise test >>>> commands with these zones in "ipa help dns" too, so I (and maybe others) could >>>> get surprised that these zones are deleted after running the test suite. I.e. I >>>> would prefer to have dnszone*.test used for test. >>>> >>>> Thanks, >>>> Martin >>> Sure. Updated patch attached. >>> >> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del command. >> >> I think this will unnecessarily make the command slower. You can just try >> add/delete a record and catch also a NotFound error - these commands already >> check for zone/record existence, so we do not need to do the checks twice. >> >> Relevant sections: >> >> + try: >> + api.Command['dnszone_show'](unicode(d)) >> + except errors.NotFound: >> + pass >> + else: >> + try: >> + api.Command['dnsrecord_add']( >> + unicode(d), >> + u'_kerberos', >> + txtrecord=api.env.realm >> + ) >> + except errors.EmptyModlist: >> + pass >> >> ... >> >> + try: >> + api.Command['dnszone_show'](unicode(d)) >> + except errors.NotFound: >> + pass >> + else: >> + try: >> + api.Command['dnsrecord_del']( >> + unicode(d), >> + u'_kerberos', >> + txtrecord=api.env.realm >> + ) >> + except errors.AttrValueNotFound: >> + pass >> >> Martin > > Nice catch, those checks were totally unnecessary. Thanks. I tried adding an upper-case version of my primary domain and got an odd error: $ ipa realmdomains-mod --add-domain EXAMPLE.COM ipa: ERROR: Type or value exists: Ok, I can sort of accept that, but there is no real detail. httpd logged this though: [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, force=False, all=False, raw=False, version=u'2.57'): DatabaseError I'm really a little confused about this discrepancy. The client side looks right, I don't understand why we logged a DB error on the server. LDAP has the right error: [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm Domains,cn=ipa,cn=etc,dc=example,dc=com" [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 What led me to try this was this code: + for d in domains_added: + # Skip our own domain + if d == api.env.domain: + continue This probably needs to be case insensitive. rob From rcritten at redhat.com Mon Apr 15 21:58:53 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Apr 2013 17:58:53 -0400 Subject: [Freeipa-devel] [PATCH 0044] Update only selected attributes for winsync agreement In-Reply-To: <51656589.30508@redhat.com> References: <5162CC78.6030208@redhat.com> <51648C66.3040102@redhat.com> <51656589.30508@redhat.com> Message-ID: <516C781D.7050707@redhat.com> Tomas Babej wrote: > On 04/09/2013 11:47 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> Hi, >>> >>> Trying to insert nsDS5ReplicatedAttributeListTotal and >>> nsds5ReplicaStripAttrs to winsync agreements caused upgrade errors. >>> With this patch, these attributes are skipped for winsync agreements. >>> >>> Made find_ipa_replication_agreements() in replication.py more >>> corresponding to find_replication_agreements. It returns list of >>> entries instead of unicode strings now. >>> >>> https://fedorahosted.org/freeipa/ticket/3522 >>> >>> Tomas >> >> This will still do some work against a winsync agreement. Do we need >> to do that at all? I'm not sure we do. >> >> rob >> > I removed the nsds5replicahost attribute update for winsync agreements > after discussion. > > Updated patch attached. > > Tomas This looks ok. The backup/restore patch added two more calls to find_ipa_replication_agreements so a rebase is needed. I think these are the required changes: diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py index 04d4210..760da0b 100644 --- a/ipaserver/install/ipa_restore.py +++ b/ipaserver/install/ipa_restore.py @@ -373,7 +373,10 @@ class Restore(admintool.AdminTool): services_cns = [s.single_value('cn') for s in services] - hosts = repl.find_ipa_replication_agreements() + host_entries = repl.find_ipa_replication_agreements() + hosts = [rep.single_value('nsds5replicahost', None) + for rep in host_entries] + for host in hosts: self.log.info('Disabling replication agreement on %s to %s' % ( master, host)) repl.disable_agreement(host) @@ -385,7 +388,9 @@ class Restore(admintool.AdminTool): except Exception, e: self.log.critical("Unable to disable agreement on %s: %s" % (master, e)) - hosts = repl.find_ipa_replication_agreements() + host_entries = repl.find_ipa_replication_agreements() + hosts = [rep.single_value('nsds5replicahost', None) + for rep in host_entries] for host in hosts: self.log.info('Disabling CA replication agreement on %s to %s' % (master, host)) repl.hostnames = [master, host] From mkosek at redhat.com Tue Apr 16 07:14:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Apr 2013 09:14:39 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516C6F46.6060204@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> Message-ID: <516CFA5F.9090409@redhat.com> On 04/15/2013 11:21 PM, Rob Crittenden wrote: > Ana Krivokapic wrote: >> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>> Also >>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>> mapping >>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>> record is >>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>>> >>>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>>> necessary. >>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>>> I'm asking for here. >>>>>>>>>> >>>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>> >>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>>> work. >>>>>>>>>> >>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>> obviously is >>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>> enhancement: >>>>>>>>> >>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>> >>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>> enumeration >>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>> to the >>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>> appealing >>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>> removes >>>>>>>> the file from his temporary directory. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Martin >>>>>>> Sure, done. >>>>>>> >>>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>> have >>>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>> framework[1]. It should pass after the bug is fixed. >>>>>> >>>>>> Updated patch is attached. >>>>>> >>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>> >>>>> This looks nice, thanks for the new test cases. >>>>> >>>>> I experienced an issue with dnsrecord-find test in >>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>> ticket >>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>> show-stopper. >>>>> >>>>> This is a nitpick, but could you update >>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>> domains >>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>> >>>>> I often use example*.com zones in my testing and we also advertise test >>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>> could >>>>> get surprised that these zones are deleted after running the test suite. >>>>> I.e. I >>>>> would prefer to have dnszone*.test used for test. >>>>> >>>>> Thanks, >>>>> Martin >>>> Sure. Updated patch attached. >>>> >>> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>> command. >>> >>> I think this will unnecessarily make the command slower. You can just try >>> add/delete a record and catch also a NotFound error - these commands already >>> check for zone/record existence, so we do not need to do the checks twice. >>> >>> Relevant sections: >>> >>> + try: >>> + api.Command['dnszone_show'](unicode(d)) >>> + except errors.NotFound: >>> + pass >>> + else: >>> + try: >>> + api.Command['dnsrecord_add']( >>> + unicode(d), >>> + u'_kerberos', >>> + txtrecord=api.env.realm >>> + ) >>> + except errors.EmptyModlist: >>> + pass >>> >>> ... >>> >>> + try: >>> + api.Command['dnszone_show'](unicode(d)) >>> + except errors.NotFound: >>> + pass >>> + else: >>> + try: >>> + api.Command['dnsrecord_del']( >>> + unicode(d), >>> + u'_kerberos', >>> + txtrecord=api.env.realm >>> + ) >>> + except errors.AttrValueNotFound: >>> + pass >>> >>> Martin >> >> Nice catch, those checks were totally unnecessary. Thanks. > > I tried adding an upper-case version of my primary domain and got an odd error: > > $ ipa realmdomains-mod --add-domain EXAMPLE.COM > ipa: ERROR: Type or value exists: > > Ok, I can sort of accept that, but there is no real detail. > > httpd logged this though: > > [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: > admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, > force=False, all=False, raw=False, version=u'2.57'): DatabaseError > > I'm really a little confused about this discrepancy. The client side looks > right, I don't understand why we logged a DB error on the server. > > LDAP has the right error: > > [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm > Domains,cn=ipa,cn=etc,dc=example,dc=com" > [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 > > What led me to try this was this code: > > + for d in domains_added: > + # Skip our own domain > + if d == api.env.domain: > + continue > > This probably needs to be case insensitive. > > rob We may also want to normalize zones to the non-fqdn DNS version before adding them to realmdomains - i.e. store "example.com" instead of "example.com.". Adding Alexander to CC list to verify this is a sound requirement. Otherwise, we would have duplicate zones in realmdomains object: # ipa dnszone-add example2.com --name-server=`hostname`. # ipa realmdomains-show Domain: idm.lab.bos.redhat.com, example2.com # ipa realmdomains-mod --add-domain=example2.com. Domain: idm.lab.bos.redhat.com, example2.com, example2.com. example2.com. should be normalized to example.com # ipa dnszone-add example3.com. --name-server=`hostname`. # ipa realmdomains-show Domain: idm.lab.bos.redhat.com, example2.com, example2.com., example3.com. I think example3.com. should be normalized to example3.com Martin From jcholast at redhat.com Tue Apr 16 07:40:37 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Apr 2013 09:40:37 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <516C5221.3070205@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <1211642414.42013.1365778517178.JavaMail.root@redhat.com> <516BD704.8030304@redhat.com> <516BE90B.3010102@redhat.com> <1304869496.517311.1366037271196.JavaMail.root@redhat.com> <516C3019.8070209@redhat.com> <516C5221.3070205@redhat.com> Message-ID: <516D0075.50202@redhat.com> On 15.4.2013 21:16, Martin Kosek wrote: > Jan, can you please rebase the patch also for ipa-3-1? We will need to > fix this issue also for 3.1. Yep. -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-126.2-ipa-3-1-Use-A-AAAA-records-instead-of-CNAME-records-in-ipa-c.patch Type: text/x-patch Size: 15704 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-127.2-ipa-3-1-Delete-DNS-records-in-ipa-ca-on-ipa-csreplica-manage.patch Type: text/x-patch Size: 1921 bytes Desc: not available URL: From jcholast at redhat.com Tue Apr 16 08:05:39 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 16 Apr 2013 10:05:39 +0200 Subject: [Freeipa-devel] [PATCH] 128 Do not use new LDAP API in old code Message-ID: <516D0653.807@redhat.com> Hi, while rebasing patches 126 & 127 on top of ipa-3-1, I have noticed that commit bceccbd6 uses new LDAP API, which is not available in 3.1. The attached patch fixes this. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-128-Do-not-use-new-LDAP-API-in-old-code.patch Type: text/x-patch Size: 1441 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 16 08:40:26 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Apr 2013 10:40:26 +0200 Subject: [Freeipa-devel] [PATCH 0146] Disallow all dynamic updates if update policy configuration failed Message-ID: <516D0E7A.50202@redhat.com> Hello, Disallow all dynamic updates if update policy configuration failed. Without this patch the old update policy stays in effect when re-configuration failed. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0146-Disallow-all-dynamic-updates-if-update-policy-config.patch Type: text/x-patch Size: 1727 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 16 09:16:26 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 16 Apr 2013 11:16:26 +0200 Subject: [Freeipa-devel] [PATCH 0044] Update only selected attributes for winsync agreement In-Reply-To: <516C781D.7050707@redhat.com> References: <5162CC78.6030208@redhat.com> <51648C66.3040102@redhat.com> <51656589.30508@redhat.com> <516C781D.7050707@redhat.com> Message-ID: <516D16EA.5070409@redhat.com> On 04/15/2013 11:58 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 04/09/2013 11:47 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> Hi, >>>> >>>> Trying to insert nsDS5ReplicatedAttributeListTotal and >>>> nsds5ReplicaStripAttrs to winsync agreements caused upgrade errors. >>>> With this patch, these attributes are skipped for winsync agreements. >>>> >>>> Made find_ipa_replication_agreements() in replication.py more >>>> corresponding to find_replication_agreements. It returns list of >>>> entries instead of unicode strings now. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3522 >>>> >>>> Tomas >>> >>> This will still do some work against a winsync agreement. Do we need >>> to do that at all? I'm not sure we do. >>> >>> rob >>> >> I removed the nsds5replicahost attribute update for winsync agreements >> after discussion. >> >> Updated patch attached. >> >> Tomas > > This looks ok. The backup/restore patch added two more calls to > find_ipa_replication_agreements so a rebase is needed. I think these > are the required changes: > > diff --git a/ipaserver/install/ipa_restore.py > b/ipaserver/install/ipa_restore.py > index 04d4210..760da0b 100644 > --- a/ipaserver/install/ipa_restore.py > +++ b/ipaserver/install/ipa_restore.py > @@ -373,7 +373,10 @@ class Restore(admintool.AdminTool): > > services_cns = [s.single_value('cn') for s in services] > > - hosts = repl.find_ipa_replication_agreements() > + host_entries = repl.find_ipa_replication_agreements() > + hosts = [rep.single_value('nsds5replicahost', None) > + for rep in host_entries] > + > for host in hosts: > self.log.info('Disabling replication agreement on %s > to %s' % ( > master, host)) > repl.disable_agreement(host) > @@ -385,7 +388,9 @@ class Restore(admintool.AdminTool): > except Exception, e: > self.log.critical("Unable to disable agreement on > %s: %s" % > (master, e)) > > - hosts = repl.find_ipa_replication_agreements() > + host_entries = repl.find_ipa_replication_agreements() > + hosts = [rep.single_value('nsds5replicahost', None) > + for rep in host_entries] > for host in hosts: > self.log.info('Disabling CA replication agreement > on %s to > %s' % (master, host)) > repl.hostnames = [master, host] > > I added the calls and rebased the patch. I also found one missed call in ipa-replica-csmanage. Updated patch attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0044-3-Update-only-selected-attributes-for-winsync-agreemen.patch Type: text/x-patch Size: 7280 bytes Desc: not available URL: From akrivoka at redhat.com Tue Apr 16 10:31:30 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 16 Apr 2013 12:31:30 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516CFA5F.9090409@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> <516CFA5F.9090409@redhat.com> Message-ID: <516D2882.8000206@redhat.com> On 04/16/2013 09:14 AM, Martin Kosek wrote: > On 04/15/2013 11:21 PM, Rob Crittenden wrote: >> Ana Krivokapic wrote: >>> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>>> mapping >>>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>>> record is >>>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>>>> >>>>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>>>> necessary. >>>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>>>> I'm asking for here. >>>>>>>>>>> >>>>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>>> >>>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>>>> work. >>>>>>>>>>> >>>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>>> obviously is >>>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>>> enhancement: >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>>> >>>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>>> enumeration >>>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>>> to the >>>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>>> appealing >>>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>>> removes >>>>>>>>> the file from his temporary directory. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Martin >>>>>>>> Sure, done. >>>>>>>> >>>>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>>> have >>>>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>>> framework[1]. It should pass after the bug is fixed. >>>>>>> >>>>>>> Updated patch is attached. >>>>>>> >>>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>>> >>>>>> This looks nice, thanks for the new test cases. >>>>>> >>>>>> I experienced an issue with dnsrecord-find test in >>>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>>> ticket >>>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>>> show-stopper. >>>>>> >>>>>> This is a nitpick, but could you update >>>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>>> domains >>>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>>> >>>>>> I often use example*.com zones in my testing and we also advertise test >>>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>>> could >>>>>> get surprised that these zones are deleted after running the test suite. >>>>>> I.e. I >>>>>> would prefer to have dnszone*.test used for test. >>>>>> >>>>>> Thanks, >>>>>> Martin >>>>> Sure. Updated patch attached. >>>>> >>>> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >>>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>>> command. >>>> >>>> I think this will unnecessarily make the command slower. You can just try >>>> add/delete a record and catch also a NotFound error - these commands already >>>> check for zone/record existence, so we do not need to do the checks twice. >>>> >>>> Relevant sections: >>>> >>>> + try: >>>> + api.Command['dnszone_show'](unicode(d)) >>>> + except errors.NotFound: >>>> + pass >>>> + else: >>>> + try: >>>> + api.Command['dnsrecord_add']( >>>> + unicode(d), >>>> + u'_kerberos', >>>> + txtrecord=api.env.realm >>>> + ) >>>> + except errors.EmptyModlist: >>>> + pass >>>> >>>> ... >>>> >>>> + try: >>>> + api.Command['dnszone_show'](unicode(d)) >>>> + except errors.NotFound: >>>> + pass >>>> + else: >>>> + try: >>>> + api.Command['dnsrecord_del']( >>>> + unicode(d), >>>> + u'_kerberos', >>>> + txtrecord=api.env.realm >>>> + ) >>>> + except errors.AttrValueNotFound: >>>> + pass >>>> >>>> Martin >>> Nice catch, those checks were totally unnecessary. Thanks. >> I tried adding an upper-case version of my primary domain and got an odd error: >> >> $ ipa realmdomains-mod --add-domain EXAMPLE.COM >> ipa: ERROR: Type or value exists: >> >> Ok, I can sort of accept that, but there is no real detail. >> >> httpd logged this though: >> >> [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: >> admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, >> force=False, all=False, raw=False, version=u'2.57'): DatabaseError >> >> I'm really a little confused about this discrepancy. The client side looks >> right, I don't understand why we logged a DB error on the server. >> >> LDAP has the right error: >> >> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm >> Domains,cn=ipa,cn=etc,dc=example,dc=com" >> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 >> >> What led me to try this was this code: >> >> + for d in domains_added: >> + # Skip our own domain >> + if d == api.env.domain: >> + continue >> >> This probably needs to be case insensitive. >> >> rob > We may also want to normalize zones to the non-fqdn DNS version before adding > them to realmdomains - i.e. store "example.com" instead of "example.com.". > Adding Alexander to CC list to verify this is a sound requirement. > > Otherwise, we would have duplicate zones in realmdomains object: > > # ipa dnszone-add example2.com --name-server=`hostname`. > > # ipa realmdomains-show > Domain: idm.lab.bos.redhat.com, example2.com > > # ipa realmdomains-mod --add-domain=example2.com. > Domain: idm.lab.bos.redhat.com, example2.com, example2.com. > > example2.com. should be normalized to example.com > > > # ipa dnszone-add example3.com. --name-server=`hostname`. > > # ipa realmdomains-show > Domain: idm.lab.bos.redhat.com, example2.com, example2.com., example3.com. > > I think example3.com. should be normalized to example3.com > > Martin I added normalizers for realmdomains-mod options, which should fix issues encountered by Rob and Martin. Updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0017-05-Integrate-realmdomains-with-IPA-DNS.patch Type: text/x-patch Size: 13362 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 16 10:44:25 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Apr 2013 12:44:25 +0200 Subject: [Freeipa-devel] [PATCH 0147] Improve error logging for zones with idnsAllowDynUpdate == FALSE. Message-ID: <516D2B89.1090506@redhat.com> Hello, Improve error logging for zones with idnsAllowDynUpdate == FALSE. Zones with dynamic updates disabled are re-configured with empty update policy string, so the update is refused by BIND and an error is logged. -- Petr Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0147-Improve-error-logging-for-zones-with-idnsAllowDynUpd.patch Type: text/x-patch Size: 4894 bytes Desc: not available URL: From pspacek at redhat.com Tue Apr 16 10:45:14 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 16 Apr 2013 12:45:14 +0200 Subject: [Freeipa-devel] [PATCH 0148] Explicitly return SERVFAIL if PTR synchronization is misconfigured. Message-ID: <516D2BBA.2040407@redhat.com> Hello, Explicitly return SERVFAIL if PTR synchronization is misconfigured. SERVFAIL will be returned if PTR synchronization is enabled in forward zone but reverse zone has dynamic updates disabled. -- Petr Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0148-Explicitly-return-SERVFAIL-if-PTR-synchronization-is.patch Type: text/x-patch Size: 1042 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 16 11:00:37 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Apr 2013 13:00:37 +0200 Subject: [Freeipa-devel] [PATCHES] 126-127 Use A/AAAA records instead of CNAME records in ipa-ca In-Reply-To: <516D0075.50202@redhat.com> References: <5167EED3.10700@redhat.com> <5167FBD6.2070001@redhat.com> <5167FE7B.5040401@redhat.com> <51681137.8060308@redhat.com> <51681304.4030904@redhat.com> <1211642414.42013.1365778517178.JavaMail.root@redhat.com> <516BD704.8030304@redhat.com> <516BE90B.3010102@redhat.com> <1304869496.517311.1366037271196.JavaMail.root@redhat.com> <516C3019.8070209@redhat.com> <516C5221.3070205@redhat.com> <516D0075.50202@redhat.com> Message-ID: <516D2F55.9070502@redhat.com> On 04/16/2013 09:40 AM, Jan Cholasta wrote: > On 15.4.2013 21:16, Martin Kosek wrote: >> Jan, can you please rebase the patch also for ipa-3-1? We will need to >> fix this issue also for 3.1. > > Yep. > Thanks. Pushed both to ipa-3-1. Martin From mkosek at redhat.com Tue Apr 16 11:01:50 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Apr 2013 13:01:50 +0200 Subject: [Freeipa-devel] [PATCH] 128 Do not use new LDAP API in old code In-Reply-To: <516D0653.807@redhat.com> References: <516D0653.807@redhat.com> Message-ID: <516D2F9E.4060706@redhat.com> On 04/16/2013 10:05 AM, Jan Cholasta wrote: > Hi, > > while rebasing patches 126 & 127 on top of ipa-3-1, I have noticed that commit > bceccbd6 uses new LDAP API, which is not available in 3.1. The attached patch > fixes this. > > Honza ACK, pushed to ipa-3-1. Martin From mkosek at redhat.com Tue Apr 16 11:16:55 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Apr 2013 13:16:55 +0200 Subject: [Freeipa-devel] [PATCH] 401 Require new samba and krb5 Message-ID: <516D3327.7060905@redhat.com> Require samba 4.0.5 (passdb API changed). Make sure that we use the right epoch number with samba so that the Requires is correctly enforced. Require krb5 1.11.2-1 to fix missing PAC issue. --- This patch makes sure we have the right dependencies in Fedora 19 (and Fedora 18 too for the samba one). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-401-require-new-samba-and-krb5.patch Type: text/x-patch Size: 1927 bytes Desc: not available URL: From abokovoy at redhat.com Tue Apr 16 11:32:43 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 16 Apr 2013 14:32:43 +0300 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516CFA5F.9090409@redhat.com> References: <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> <516CFA5F.9090409@redhat.com> Message-ID: <20130416113243.GS6823@redhat.com> On Tue, 16 Apr 2013, Martin Kosek wrote: >On 04/15/2013 11:21 PM, Rob Crittenden wrote: >> Ana Krivokapic wrote: >>> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>>> mapping >>>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>>> record is >>>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>>>> >>>>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>>>> necessary. >>>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>>>> I'm asking for here. >>>>>>>>>>> >>>>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>>> >>>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>>>> work. >>>>>>>>>>> >>>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>>> obviously is >>>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>>> enhancement: >>>>>>>>>> >>>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>>> >>>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>>> enumeration >>>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>>> to the >>>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>>> appealing >>>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>>> removes >>>>>>>>> the file from his temporary directory. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Martin >>>>>>>> Sure, done. >>>>>>>> >>>>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>>> have >>>>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>>> framework[1]. It should pass after the bug is fixed. >>>>>>> >>>>>>> Updated patch is attached. >>>>>>> >>>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>>> >>>>>> This looks nice, thanks for the new test cases. >>>>>> >>>>>> I experienced an issue with dnsrecord-find test in >>>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>>> ticket >>>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>>> show-stopper. >>>>>> >>>>>> This is a nitpick, but could you update >>>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>>> domains >>>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>>> >>>>>> I often use example*.com zones in my testing and we also advertise test >>>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>>> could >>>>>> get surprised that these zones are deleted after running the test suite. >>>>>> I.e. I >>>>>> would prefer to have dnszone*.test used for test. >>>>>> >>>>>> Thanks, >>>>>> Martin >>>>> Sure. Updated patch attached. >>>>> >>>> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >>>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>>> command. >>>> >>>> I think this will unnecessarily make the command slower. You can just try >>>> add/delete a record and catch also a NotFound error - these commands already >>>> check for zone/record existence, so we do not need to do the checks twice. >>>> >>>> Relevant sections: >>>> >>>> + try: >>>> + api.Command['dnszone_show'](unicode(d)) >>>> + except errors.NotFound: >>>> + pass >>>> + else: >>>> + try: >>>> + api.Command['dnsrecord_add']( >>>> + unicode(d), >>>> + u'_kerberos', >>>> + txtrecord=api.env.realm >>>> + ) >>>> + except errors.EmptyModlist: >>>> + pass >>>> >>>> ... >>>> >>>> + try: >>>> + api.Command['dnszone_show'](unicode(d)) >>>> + except errors.NotFound: >>>> + pass >>>> + else: >>>> + try: >>>> + api.Command['dnsrecord_del']( >>>> + unicode(d), >>>> + u'_kerberos', >>>> + txtrecord=api.env.realm >>>> + ) >>>> + except errors.AttrValueNotFound: >>>> + pass >>>> >>>> Martin >>> >>> Nice catch, those checks were totally unnecessary. Thanks. >> >> I tried adding an upper-case version of my primary domain and got an odd error: >> >> $ ipa realmdomains-mod --add-domain EXAMPLE.COM >> ipa: ERROR: Type or value exists: >> >> Ok, I can sort of accept that, but there is no real detail. >> >> httpd logged this though: >> >> [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: >> admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, >> force=False, all=False, raw=False, version=u'2.57'): DatabaseError >> >> I'm really a little confused about this discrepancy. The client side looks >> right, I don't understand why we logged a DB error on the server. >> >> LDAP has the right error: >> >> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm >> Domains,cn=ipa,cn=etc,dc=example,dc=com" >> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 >> >> What led me to try this was this code: >> >> + for d in domains_added: >> + # Skip our own domain >> + if d == api.env.domain: >> + continue >> >> This probably needs to be case insensitive. >> >> rob > >We may also want to normalize zones to the non-fqdn DNS version before adding >them to realmdomains - i.e. store "example.com" instead of "example.com.". >Adding Alexander to CC list to verify this is a sound requirement. Looking into DNS schema I see most records there use caseIgnoreIA5Match or similar caseless search. It means our comparison in the python code should follow caseless searches too. -- / Alexander Bokovoy From mkosek at redhat.com Tue Apr 16 11:55:17 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Apr 2013 13:55:17 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516D2882.8000206@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> <516CFA5F.9090409@redhat.com> <516D2882.8000206@redhat.com> Message-ID: <516D3C25.7070409@redhat.com> On 04/16/2013 12:31 PM, Ana Krivokapic wrote: > On 04/16/2013 09:14 AM, Martin Kosek wrote: >> On 04/15/2013 11:21 PM, Rob Crittenden wrote: >>> Ana Krivokapic wrote: >>>> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>>>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>>>> mapping >>>>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>>>> record is >>>>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>>>>> >>>>>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>>>>> necessary. >>>>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>>>>> I'm asking for here. >>>>>>>>>>>> >>>>>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>>>> >>>>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>>>>> work. >>>>>>>>>>>> >>>>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>>>> obviously is >>>>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>>>> enhancement: >>>>>>>>>>> >>>>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>>>> >>>>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>>>> enumeration >>>>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>>>> to the >>>>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>>>> appealing >>>>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>>>> removes >>>>>>>>>> the file from his temporary directory. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Martin >>>>>>>>> Sure, done. >>>>>>>>> >>>>>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>>>> have >>>>>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>>>> framework[1]. It should pass after the bug is fixed. >>>>>>>> >>>>>>>> Updated patch is attached. >>>>>>>> >>>>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>>>> >>>>>>> This looks nice, thanks for the new test cases. >>>>>>> >>>>>>> I experienced an issue with dnsrecord-find test in >>>>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>>>> ticket >>>>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>>>> show-stopper. >>>>>>> >>>>>>> This is a nitpick, but could you update >>>>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>>>> domains >>>>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>>>> >>>>>>> I often use example*.com zones in my testing and we also advertise test >>>>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>>>> could >>>>>>> get surprised that these zones are deleted after running the test suite. >>>>>>> I.e. I >>>>>>> would prefer to have dnszone*.test used for test. >>>>>>> >>>>>>> Thanks, >>>>>>> Martin >>>>>> Sure. Updated patch attached. >>>>>> >>>>> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >>>>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>>>> command. >>>>> >>>>> I think this will unnecessarily make the command slower. You can just try >>>>> add/delete a record and catch also a NotFound error - these commands already >>>>> check for zone/record existence, so we do not need to do the checks twice. >>>>> >>>>> Relevant sections: >>>>> >>>>> + try: >>>>> + api.Command['dnszone_show'](unicode(d)) >>>>> + except errors.NotFound: >>>>> + pass >>>>> + else: >>>>> + try: >>>>> + api.Command['dnsrecord_add']( >>>>> + unicode(d), >>>>> + u'_kerberos', >>>>> + txtrecord=api.env.realm >>>>> + ) >>>>> + except errors.EmptyModlist: >>>>> + pass >>>>> >>>>> ... >>>>> >>>>> + try: >>>>> + api.Command['dnszone_show'](unicode(d)) >>>>> + except errors.NotFound: >>>>> + pass >>>>> + else: >>>>> + try: >>>>> + api.Command['dnsrecord_del']( >>>>> + unicode(d), >>>>> + u'_kerberos', >>>>> + txtrecord=api.env.realm >>>>> + ) >>>>> + except errors.AttrValueNotFound: >>>>> + pass >>>>> >>>>> Martin >>>> Nice catch, those checks were totally unnecessary. Thanks. >>> I tried adding an upper-case version of my primary domain and got an odd error: >>> >>> $ ipa realmdomains-mod --add-domain EXAMPLE.COM >>> ipa: ERROR: Type or value exists: >>> >>> Ok, I can sort of accept that, but there is no real detail. >>> >>> httpd logged this though: >>> >>> [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: >>> admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, >>> force=False, all=False, raw=False, version=u'2.57'): DatabaseError >>> >>> I'm really a little confused about this discrepancy. The client side looks >>> right, I don't understand why we logged a DB error on the server. >>> >>> LDAP has the right error: >>> >>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm >>> Domains,cn=ipa,cn=etc,dc=example,dc=com" >>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 >>> >>> What led me to try this was this code: >>> >>> + for d in domains_added: >>> + # Skip our own domain >>> + if d == api.env.domain: >>> + continue >>> >>> This probably needs to be case insensitive. >>> >>> rob >> We may also want to normalize zones to the non-fqdn DNS version before adding >> them to realmdomains - i.e. store "example.com" instead of "example.com.". >> Adding Alexander to CC list to verify this is a sound requirement. >> >> Otherwise, we would have duplicate zones in realmdomains object: >> >> # ipa dnszone-add example2.com --name-server=`hostname`. >> >> # ipa realmdomains-show >> Domain: idm.lab.bos.redhat.com, example2.com >> >> # ipa realmdomains-mod --add-domain=example2.com. >> Domain: idm.lab.bos.redhat.com, example2.com, example2.com. >> >> example2.com. should be normalized to example.com >> >> >> # ipa dnszone-add example3.com. --name-server=`hostname`. >> >> # ipa realmdomains-show >> Domain: idm.lab.bos.redhat.com, example2.com, example2.com., example3.com. >> >> I think example3.com. should be normalized to example3.com >> >> Martin > > I added normalizers for realmdomains-mod options, which should fix > issues encountered by Rob and Martin. > > Updated patch is attached. > Good! I think this addresses all concerns and issues we found. I have one last minor issue and then we can push it. Please just add the normalizers to an own function as it is done in other plugins. It is then much easier to change such normalizer in one central location. Thanks, Martin From akrivoka at redhat.com Tue Apr 16 13:03:59 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 16 Apr 2013 15:03:59 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516D3C25.7070409@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> <516CFA5F.9090409@redhat.com> <516D2882.8000206@redhat.com> <516D3C25.7070409@redhat.com> Message-ID: <516D4C3F.9000105@redhat.com> On 04/16/2013 01:55 PM, Martin Kosek wrote: > On 04/16/2013 12:31 PM, Ana Krivokapic wrote: >> On 04/16/2013 09:14 AM, Martin Kosek wrote: >>> On 04/15/2013 11:21 PM, Rob Crittenden wrote: >>>> Ana Krivokapic wrote: >>>>> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>>>>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>>>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>>>>> mapping >>>>>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>>>>> record is >>>>>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>>>>>> necessary. >>>>>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>>>>>> I'm asking for here. >>>>>>>>>>>>> >>>>>>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>>>>> >>>>>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>>>>>> work. >>>>>>>>>>>>> >>>>>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>>>>> obviously is >>>>>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>>>>> enhancement: >>>>>>>>>>>> >>>>>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>>>>> >>>>>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>>>>> enumeration >>>>>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>>>>> to the >>>>>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>>>>> appealing >>>>>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>>>>> removes >>>>>>>>>>> the file from his temporary directory. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Martin >>>>>>>>>> Sure, done. >>>>>>>>>> >>>>>>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>>>>> have >>>>>>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>>>>> framework[1]. It should pass after the bug is fixed. >>>>>>>>> >>>>>>>>> Updated patch is attached. >>>>>>>>> >>>>>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>>>>> >>>>>>>> This looks nice, thanks for the new test cases. >>>>>>>> >>>>>>>> I experienced an issue with dnsrecord-find test in >>>>>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>>>>> ticket >>>>>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>>>>> show-stopper. >>>>>>>> >>>>>>>> This is a nitpick, but could you update >>>>>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>>>>> domains >>>>>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>>>>> >>>>>>>> I often use example*.com zones in my testing and we also advertise test >>>>>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>>>>> could >>>>>>>> get surprised that these zones are deleted after running the test suite. >>>>>>>> I.e. I >>>>>>>> would prefer to have dnszone*.test used for test. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Martin >>>>>>> Sure. Updated patch attached. >>>>>>> >>>>>> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >>>>>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>>>>> command. >>>>>> >>>>>> I think this will unnecessarily make the command slower. You can just try >>>>>> add/delete a record and catch also a NotFound error - these commands already >>>>>> check for zone/record existence, so we do not need to do the checks twice. >>>>>> >>>>>> Relevant sections: >>>>>> >>>>>> + try: >>>>>> + api.Command['dnszone_show'](unicode(d)) >>>>>> + except errors.NotFound: >>>>>> + pass >>>>>> + else: >>>>>> + try: >>>>>> + api.Command['dnsrecord_add']( >>>>>> + unicode(d), >>>>>> + u'_kerberos', >>>>>> + txtrecord=api.env.realm >>>>>> + ) >>>>>> + except errors.EmptyModlist: >>>>>> + pass >>>>>> >>>>>> ... >>>>>> >>>>>> + try: >>>>>> + api.Command['dnszone_show'](unicode(d)) >>>>>> + except errors.NotFound: >>>>>> + pass >>>>>> + else: >>>>>> + try: >>>>>> + api.Command['dnsrecord_del']( >>>>>> + unicode(d), >>>>>> + u'_kerberos', >>>>>> + txtrecord=api.env.realm >>>>>> + ) >>>>>> + except errors.AttrValueNotFound: >>>>>> + pass >>>>>> >>>>>> Martin >>>>> Nice catch, those checks were totally unnecessary. Thanks. >>>> I tried adding an upper-case version of my primary domain and got an odd error: >>>> >>>> $ ipa realmdomains-mod --add-domain EXAMPLE.COM >>>> ipa: ERROR: Type or value exists: >>>> >>>> Ok, I can sort of accept that, but there is no real detail. >>>> >>>> httpd logged this though: >>>> >>>> [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: >>>> admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, >>>> force=False, all=False, raw=False, version=u'2.57'): DatabaseError >>>> >>>> I'm really a little confused about this discrepancy. The client side looks >>>> right, I don't understand why we logged a DB error on the server. >>>> >>>> LDAP has the right error: >>>> >>>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm >>>> Domains,cn=ipa,cn=etc,dc=example,dc=com" >>>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 >>>> >>>> What led me to try this was this code: >>>> >>>> + for d in domains_added: >>>> + # Skip our own domain >>>> + if d == api.env.domain: >>>> + continue >>>> >>>> This probably needs to be case insensitive. >>>> >>>> rob >>> We may also want to normalize zones to the non-fqdn DNS version before adding >>> them to realmdomains - i.e. store "example.com" instead of "example.com.". >>> Adding Alexander to CC list to verify this is a sound requirement. >>> >>> Otherwise, we would have duplicate zones in realmdomains object: >>> >>> # ipa dnszone-add example2.com --name-server=`hostname`. >>> >>> # ipa realmdomains-show >>> Domain: idm.lab.bos.redhat.com, example2.com >>> >>> # ipa realmdomains-mod --add-domain=example2.com. >>> Domain: idm.lab.bos.redhat.com, example2.com, example2.com. >>> >>> example2.com. should be normalized to example.com >>> >>> >>> # ipa dnszone-add example3.com. --name-server=`hostname`. >>> >>> # ipa realmdomains-show >>> Domain: idm.lab.bos.redhat.com, example2.com, example2.com., example3.com. >>> >>> I think example3.com. should be normalized to example3.com >>> >>> Martin >> I added normalizers for realmdomains-mod options, which should fix >> issues encountered by Rob and Martin. >> >> Updated patch is attached. >> > Good! I think this addresses all concerns and issues we found. I have one last > minor issue and then we can push it. > > Please just add the normalizers to an own function as it is done in other > plugins. It is then much easier to change such normalizer in one central location. > > Thanks, > Martin As we agreed on IRC, I implemented the following two changes: 1) Create a separate normalizer function 2) Properly handle reverse zones (i.e. do not create realmdomains entries or TXT records for them) Updated patch is attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0017-06-Integrate-realmdomains-with-IPA-DNS.patch Type: text/x-patch Size: 13607 bytes Desc: not available URL: From mkosek at redhat.com Tue Apr 16 13:54:45 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Apr 2013 15:54:45 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516D4C3F.9000105@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> <516CFA5F.9090409@redhat.com> <516D2882.8000206@redhat.com> <516D3C25.7070409@redhat.com> <516D4C3F.9000105@redhat.com> Message-ID: <516D5825.3030308@redhat.com> On 04/16/2013 03:03 PM, Ana Krivokapic wrote: > On 04/16/2013 01:55 PM, Martin Kosek wrote: >> On 04/16/2013 12:31 PM, Ana Krivokapic wrote: >>> On 04/16/2013 09:14 AM, Martin Kosek wrote: >>>> On 04/15/2013 11:21 PM, Rob Crittenden wrote: >>>>> Ana Krivokapic wrote: >>>>>> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>>>>>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>>>>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>>>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>>>>>> mapping >>>>>>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>>>>>> record is >>>>>>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>>>>>>> necessary. >>>>>>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>>>>>>> I'm asking for here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>>>>>>> work. >>>>>>>>>>>>>> >>>>>>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>>>>>> obviously is >>>>>>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>>>>>> enhancement: >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>>>>>> >>>>>>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>>>>>> enumeration >>>>>>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>>>>>> to the >>>>>>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>>>>>> appealing >>>>>>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>>>>>> removes >>>>>>>>>>>> the file from his temporary directory. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Martin >>>>>>>>>>> Sure, done. >>>>>>>>>>> >>>>>>>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>>>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>>>>>> have >>>>>>>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>>>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>>>>>> framework[1]. It should pass after the bug is fixed. >>>>>>>>>> >>>>>>>>>> Updated patch is attached. >>>>>>>>>> >>>>>>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>>>>>> >>>>>>>>> This looks nice, thanks for the new test cases. >>>>>>>>> >>>>>>>>> I experienced an issue with dnsrecord-find test in >>>>>>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>>>>>> ticket >>>>>>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>>>>>> show-stopper. >>>>>>>>> >>>>>>>>> This is a nitpick, but could you update >>>>>>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>>>>>> domains >>>>>>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>>>>>> >>>>>>>>> I often use example*.com zones in my testing and we also advertise test >>>>>>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>>>>>> could >>>>>>>>> get surprised that these zones are deleted after running the test suite. >>>>>>>>> I.e. I >>>>>>>>> would prefer to have dnszone*.test used for test. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Martin >>>>>>>> Sure. Updated patch attached. >>>>>>>> >>>>>>> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >>>>>>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>>>>>> command. >>>>>>> >>>>>>> I think this will unnecessarily make the command slower. You can just try >>>>>>> add/delete a record and catch also a NotFound error - these commands already >>>>>>> check for zone/record existence, so we do not need to do the checks twice. >>>>>>> >>>>>>> Relevant sections: >>>>>>> >>>>>>> + try: >>>>>>> + api.Command['dnszone_show'](unicode(d)) >>>>>>> + except errors.NotFound: >>>>>>> + pass >>>>>>> + else: >>>>>>> + try: >>>>>>> + api.Command['dnsrecord_add']( >>>>>>> + unicode(d), >>>>>>> + u'_kerberos', >>>>>>> + txtrecord=api.env.realm >>>>>>> + ) >>>>>>> + except errors.EmptyModlist: >>>>>>> + pass >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> + try: >>>>>>> + api.Command['dnszone_show'](unicode(d)) >>>>>>> + except errors.NotFound: >>>>>>> + pass >>>>>>> + else: >>>>>>> + try: >>>>>>> + api.Command['dnsrecord_del']( >>>>>>> + unicode(d), >>>>>>> + u'_kerberos', >>>>>>> + txtrecord=api.env.realm >>>>>>> + ) >>>>>>> + except errors.AttrValueNotFound: >>>>>>> + pass >>>>>>> >>>>>>> Martin >>>>>> Nice catch, those checks were totally unnecessary. Thanks. >>>>> I tried adding an upper-case version of my primary domain and got an odd error: >>>>> >>>>> $ ipa realmdomains-mod --add-domain EXAMPLE.COM >>>>> ipa: ERROR: Type or value exists: >>>>> >>>>> Ok, I can sort of accept that, but there is no real detail. >>>>> >>>>> httpd logged this though: >>>>> >>>>> [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: >>>>> admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, >>>>> force=False, all=False, raw=False, version=u'2.57'): DatabaseError >>>>> >>>>> I'm really a little confused about this discrepancy. The client side looks >>>>> right, I don't understand why we logged a DB error on the server. >>>>> >>>>> LDAP has the right error: >>>>> >>>>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm >>>>> Domains,cn=ipa,cn=etc,dc=example,dc=com" >>>>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 >>>>> >>>>> What led me to try this was this code: >>>>> >>>>> + for d in domains_added: >>>>> + # Skip our own domain >>>>> + if d == api.env.domain: >>>>> + continue >>>>> >>>>> This probably needs to be case insensitive. >>>>> >>>>> rob >>>> We may also want to normalize zones to the non-fqdn DNS version before adding >>>> them to realmdomains - i.e. store "example.com" instead of "example.com.". >>>> Adding Alexander to CC list to verify this is a sound requirement. >>>> >>>> Otherwise, we would have duplicate zones in realmdomains object: >>>> >>>> # ipa dnszone-add example2.com --name-server=`hostname`. >>>> >>>> # ipa realmdomains-show >>>> Domain: idm.lab.bos.redhat.com, example2.com >>>> >>>> # ipa realmdomains-mod --add-domain=example2.com. >>>> Domain: idm.lab.bos.redhat.com, example2.com, example2.com. >>>> >>>> example2.com. should be normalized to example.com >>>> >>>> >>>> # ipa dnszone-add example3.com. --name-server=`hostname`. >>>> >>>> # ipa realmdomains-show >>>> Domain: idm.lab.bos.redhat.com, example2.com, example2.com., example3.com. >>>> >>>> I think example3.com. should be normalized to example3.com >>>> >>>> Martin >>> I added normalizers for realmdomains-mod options, which should fix >>> issues encountered by Rob and Martin. >>> >>> Updated patch is attached. >>> >> Good! I think this addresses all concerns and issues we found. I have one last >> minor issue and then we can push it. >> >> Please just add the normalizers to an own function as it is done in other >> plugins. It is then much easier to change such normalizer in one central location. >> >> Thanks, >> Martin > > As we agreed on IRC, I implemented the following two changes: > > 1) Create a separate normalizer function > 2) Properly handle reverse zones (i.e. do not create realmdomains > entries or TXT records for them) > > Updated patch is attached. > ACK. Pushed to master. Martin From mkosek at redhat.com Tue Apr 16 14:13:43 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 16 Apr 2013 16:13:43 +0200 Subject: [Freeipa-devel] [PATCH] 401 Require new samba and krb5 In-Reply-To: <516D3327.7060905@redhat.com> References: <516D3327.7060905@redhat.com> Message-ID: <516D5C97.10106@redhat.com> On 04/16/2013 01:16 PM, Martin Kosek wrote: > Require samba 4.0.5 (passdb API changed). Make sure that we use the > right epoch number with samba so that the Requires is correctly > enforced. > > Require krb5 1.11.2-1 to fix missing PAC issue. > > --- > > This patch makes sure we have the right dependencies in Fedora 19 (and Fedora > 18 too for the samba one). > > Martin > Squashing a fix for backup dir permissions. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-401-2-require-new-samba-and-krb5.patch Type: text/x-patch Size: 2478 bytes Desc: not available URL: From akrivoka at redhat.com Tue Apr 16 14:20:34 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 16 Apr 2013 16:20:34 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <516D5825.3030308@redhat.com> References: <516699ED.6060509@redhat.com> <51669B05.30709@redhat.com> <20130411112421.GE6823@redhat.com> <51669DE3.60904@redhat.com> <20130411114304.GF6823@redhat.com> <5166AE11.6090300@redhat.com> <20130411130302.GH6823@redhat.com> <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> <516CFA5F.9090409@redhat.com> <516D2882.8000206@redhat.com> <516D3C25.7070409@redhat.com> <516D4C3F.9000105@redhat.com> <516D5825.3030308@redhat.com> Message-ID: <516D5E32.1040005@redhat.com> On 04/16/2013 03:54 PM, Martin Kosek wrote: > On 04/16/2013 03:03 PM, Ana Krivokapic wrote: >> On 04/16/2013 01:55 PM, Martin Kosek wrote: >>> On 04/16/2013 12:31 PM, Ana Krivokapic wrote: >>>> On 04/16/2013 09:14 AM, Martin Kosek wrote: >>>>> On 04/15/2013 11:21 PM, Rob Crittenden wrote: >>>>>> Ana Krivokapic wrote: >>>>>>> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>>>>>>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>>>>>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>>>>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>>>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is deleted from >>>>>>>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT record back >>>>>>>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>>>>>>> mapping >>>>>>>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>>>>>>> record is >>>>>>>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>>>>>>> One more thing to check is that we don't do this for our own domain. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Our own domain is already in realmdomains by default, and it cannot be >>>>>>>>>>>>>>>> removed from there. So I don't think any check related to our domain is >>>>>>>>>>>>>>>> necessary. >>>>>>>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's what >>>>>>>>>>>>>>> I'm asking for here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Think about server install stage -- we start creating our own domain and >>>>>>>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side -- it >>>>>>>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know wouldn't >>>>>>>>>>>>>>> work. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>>>>>>> obviously is >>>>>>>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>>>>>>> enhancement: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>>>>>>> >>>>>>>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>>>>>>> enumeration >>>>>>>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>>>>>>> to the >>>>>>>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>>>>>>> appealing >>>>>>>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>>>>>>> removes >>>>>>>>>>>>> the file from his temporary directory. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Martin >>>>>>>>>>>> Sure, done. >>>>>>>>>>>> >>>>>>>>>>> I added the functionality to create TXT record to realmdomains-mod, and also >>>>>>>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>>>>>>> have >>>>>>>>>>> been added to cover the new functionality. One unit test of the dns plugin >>>>>>>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>>>>>>> framework[1]. It should pass after the bug is fixed. >>>>>>>>>>> >>>>>>>>>>> Updated patch is attached. >>>>>>>>>>> >>>>>>>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>>>>>>> >>>>>>>>>> This looks nice, thanks for the new test cases. >>>>>>>>>> >>>>>>>>>> I experienced an issue with dnsrecord-find test in >>>>>>>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>>>>>>> ticket >>>>>>>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>>>>>>> show-stopper. >>>>>>>>>> >>>>>>>>>> This is a nitpick, but could you update >>>>>>>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>>>>>>> domains >>>>>>>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>>>>>>> >>>>>>>>>> I often use example*.com zones in my testing and we also advertise test >>>>>>>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>>>>>>> could >>>>>>>>>> get surprised that these zones are deleted after running the test suite. >>>>>>>>>> I.e. I >>>>>>>>>> would prefer to have dnszone*.test used for test. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Martin >>>>>>>>> Sure. Updated patch attached. >>>>>>>>> >>>>>>>> One more nitpick (sorry for not spotting it earlier). In realmdomains-mod, you >>>>>>>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>>>>>>> command. >>>>>>>> >>>>>>>> I think this will unnecessarily make the command slower. You can just try >>>>>>>> add/delete a record and catch also a NotFound error - these commands already >>>>>>>> check for zone/record existence, so we do not need to do the checks twice. >>>>>>>> >>>>>>>> Relevant sections: >>>>>>>> >>>>>>>> + try: >>>>>>>> + api.Command['dnszone_show'](unicode(d)) >>>>>>>> + except errors.NotFound: >>>>>>>> + pass >>>>>>>> + else: >>>>>>>> + try: >>>>>>>> + api.Command['dnsrecord_add']( >>>>>>>> + unicode(d), >>>>>>>> + u'_kerberos', >>>>>>>> + txtrecord=api.env.realm >>>>>>>> + ) >>>>>>>> + except errors.EmptyModlist: >>>>>>>> + pass >>>>>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> + try: >>>>>>>> + api.Command['dnszone_show'](unicode(d)) >>>>>>>> + except errors.NotFound: >>>>>>>> + pass >>>>>>>> + else: >>>>>>>> + try: >>>>>>>> + api.Command['dnsrecord_del']( >>>>>>>> + unicode(d), >>>>>>>> + u'_kerberos', >>>>>>>> + txtrecord=api.env.realm >>>>>>>> + ) >>>>>>>> + except errors.AttrValueNotFound: >>>>>>>> + pass >>>>>>>> >>>>>>>> Martin >>>>>>> Nice catch, those checks were totally unnecessary. Thanks. >>>>>> I tried adding an upper-case version of my primary domain and got an odd error: >>>>>> >>>>>> $ ipa realmdomains-mod --add-domain EXAMPLE.COM >>>>>> ipa: ERROR: Type or value exists: >>>>>> >>>>>> Ok, I can sort of accept that, but there is no real detail. >>>>>> >>>>>> httpd logged this though: >>>>>> >>>>>> [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: >>>>>> admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, >>>>>> force=False, all=False, raw=False, version=u'2.57'): DatabaseError >>>>>> >>>>>> I'm really a little confused about this discrepancy. The client side looks >>>>>> right, I don't understand why we logged a DB error on the server. >>>>>> >>>>>> LDAP has the right error: >>>>>> >>>>>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm >>>>>> Domains,cn=ipa,cn=etc,dc=example,dc=com" >>>>>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 etime=0 >>>>>> >>>>>> What led me to try this was this code: >>>>>> >>>>>> + for d in domains_added: >>>>>> + # Skip our own domain >>>>>> + if d == api.env.domain: >>>>>> + continue >>>>>> >>>>>> This probably needs to be case insensitive. >>>>>> >>>>>> rob >>>>> We may also want to normalize zones to the non-fqdn DNS version before adding >>>>> them to realmdomains - i.e. store "example.com" instead of "example.com.". >>>>> Adding Alexander to CC list to verify this is a sound requirement. >>>>> >>>>> Otherwise, we would have duplicate zones in realmdomains object: >>>>> >>>>> # ipa dnszone-add example2.com --name-server=`hostname`. >>>>> >>>>> # ipa realmdomains-show >>>>> Domain: idm.lab.bos.redhat.com, example2.com >>>>> >>>>> # ipa realmdomains-mod --add-domain=example2.com. >>>>> Domain: idm.lab.bos.redhat.com, example2.com, example2.com. >>>>> >>>>> example2.com. should be normalized to example.com >>>>> >>>>> >>>>> # ipa dnszone-add example3.com. --name-server=`hostname`. >>>>> >>>>> # ipa realmdomains-show >>>>> Domain: idm.lab.bos.redhat.com, example2.com, example2.com., example3.com. >>>>> >>>>> I think example3.com. should be normalized to example3.com >>>>> >>>>> Martin >>>> I added normalizers for realmdomains-mod options, which should fix >>>> issues encountered by Rob and Martin. >>>> >>>> Updated patch is attached. >>>> >>> Good! I think this addresses all concerns and issues we found. I have one last >>> minor issue and then we can push it. >>> >>> Please just add the normalizers to an own function as it is done in other >>> plugins. It is then much easier to change such normalizer in one central location. >>> >>> Thanks, >>> Martin >> As we agreed on IRC, I implemented the following two changes: >> >> 1) Create a separate normalizer function >> 2) Properly handle reverse zones (i.e. do not create realmdomains >> entries or TXT records for them) >> >> Updated patch is attached. >> > ACK. Pushed to master. > > Martin I updated the design page and linked it in http://www.freeipa.org/page/V3_Designs -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From rcritten at redhat.com Tue Apr 16 14:18:44 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Apr 2013 10:18:44 -0400 Subject: [Freeipa-devel] [PATCH 0044] Update only selected attributes for winsync agreement In-Reply-To: <516D16EA.5070409@redhat.com> References: <5162CC78.6030208@redhat.com> <51648C66.3040102@redhat.com> <51656589.30508@redhat.com> <516C781D.7050707@redhat.com> <516D16EA.5070409@redhat.com> Message-ID: <516D5DC4.3020603@redhat.com> Tomas Babej wrote: > On 04/15/2013 11:58 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 04/09/2013 11:47 PM, Rob Crittenden wrote: >>>> Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> Trying to insert nsDS5ReplicatedAttributeListTotal and >>>>> nsds5ReplicaStripAttrs to winsync agreements caused upgrade errors. >>>>> With this patch, these attributes are skipped for winsync agreements. >>>>> >>>>> Made find_ipa_replication_agreements() in replication.py more >>>>> corresponding to find_replication_agreements. It returns list of >>>>> entries instead of unicode strings now. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3522 >>>>> >>>>> Tomas >>>> >>>> This will still do some work against a winsync agreement. Do we need >>>> to do that at all? I'm not sure we do. >>>> >>>> rob >>>> >>> I removed the nsds5replicahost attribute update for winsync agreements >>> after discussion. >>> >>> Updated patch attached. >>> >>> Tomas >> >> This looks ok. The backup/restore patch added two more calls to >> find_ipa_replication_agreements so a rebase is needed. I think these >> are the required changes: >> >> diff --git a/ipaserver/install/ipa_restore.py >> b/ipaserver/install/ipa_restore.py >> index 04d4210..760da0b 100644 >> --- a/ipaserver/install/ipa_restore.py >> +++ b/ipaserver/install/ipa_restore.py >> @@ -373,7 +373,10 @@ class Restore(admintool.AdminTool): >> >> services_cns = [s.single_value('cn') for s in services] >> >> - hosts = repl.find_ipa_replication_agreements() >> + host_entries = repl.find_ipa_replication_agreements() >> + hosts = [rep.single_value('nsds5replicahost', None) >> + for rep in host_entries] >> + >> for host in hosts: >> self.log.info('Disabling replication agreement on %s >> to %s' % ( >> master, host)) >> repl.disable_agreement(host) >> @@ -385,7 +388,9 @@ class Restore(admintool.AdminTool): >> except Exception, e: >> self.log.critical("Unable to disable agreement on >> %s: %s" % >> (master, e)) >> >> - hosts = repl.find_ipa_replication_agreements() >> + host_entries = repl.find_ipa_replication_agreements() >> + hosts = [rep.single_value('nsds5replicahost', None) >> + for rep in host_entries] >> for host in hosts: >> self.log.info('Disabling CA replication agreement >> on %s to >> %s' % (master, host)) >> repl.hostnames = [master, host] >> >> > I added the calls and rebased the patch. I also found one missed call in > ipa-replica-csmanage. > > Updated patch attached. ACK, pushed to master rob From pviktori at redhat.com Tue Apr 16 14:33:14 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 16 Apr 2013 16:33:14 +0200 Subject: [Freeipa-devel] [PATCH] 401 Require new samba and krb5 In-Reply-To: <516D3327.7060905@redhat.com> References: <516D3327.7060905@redhat.com> Message-ID: <516D612A.2090908@redhat.com> On 04/16/2013 01:16 PM, Martin Kosek wrote: > Require samba 4.0.5 (passdb API changed). Make sure that we use the > right epoch number with samba so that the Requires is correctly > enforced. > > Require krb5 1.11.2-1 to fix missing PAC issue. > > --- > > This patch makes sure we have the right dependencies in Fedora 19 (and Fedora > 18 too for the samba one). > > Martin I've tested on f19 with Kerberos from Koji, and got the following test failure in test_cmdline/test_ipagetkeytab.py, test_2_run: ====================================================================== FAIL: Create a keytab with `ipa-getkeytab` for an existing service. ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/home/pviktori/freeipa/tests/test_cmdline/test_ipagetkeytab.py", line 110, in test_2_run assert err == 'Keytab successfully retrieved and stored in: %s\n' % self.keytabname AssertionError The command works, the test fails because it doesn't expect warnings about Camellia on stderr. I assume they're benign? Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) Keytab successfully retrieved and stored in: /tmp/tmpvLHm7l On f18 my smoke testing is going fine. -- Petr? From rcritten at redhat.com Tue Apr 16 14:44:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Apr 2013 10:44:58 -0400 Subject: [Freeipa-devel] [PATCH] 401 Require new samba and krb5 In-Reply-To: <516D612A.2090908@redhat.com> References: <516D3327.7060905@redhat.com> <516D612A.2090908@redhat.com> Message-ID: <516D63EA.3050106@redhat.com> Petr Viktorin wrote: > On 04/16/2013 01:16 PM, Martin Kosek wrote: >> Require samba 4.0.5 (passdb API changed). Make sure that we use the >> right epoch number with samba so that the Requires is correctly >> enforced. >> >> Require krb5 1.11.2-1 to fix missing PAC issue. >> >> --- >> >> This patch makes sure we have the right dependencies in Fedora 19 (and >> Fedora >> 18 too for the samba one). >> >> Martin > > I've tested on f19 with Kerberos from Koji, and got the following test > failure in test_cmdline/test_ipagetkeytab.py, test_2_run: > > ====================================================================== > FAIL: Create a keytab with `ipa-getkeytab` for an existing service. > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in > runTest > self.test(*self.arg) > File > "/home/pviktori/freeipa/tests/test_cmdline/test_ipagetkeytab.py", line > 110, in test_2_run > assert err == 'Keytab successfully retrieved and stored in: %s\n' % > self.keytabname > AssertionError > > > The command works, the test fails because it doesn't expect warnings > about Camellia on stderr. I assume they're benign? > > Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) > Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) > Keytab successfully retrieved and stored in: /tmp/tmpvLHm7l > > > > On f18 my smoke testing is going fine. > Yes, looks like new ciphers were added that we don't have enabled by default in IPA. The patch looks ok to me, ACK. rob From rcritten at redhat.com Tue Apr 16 15:05:53 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Apr 2013 11:05:53 -0400 Subject: [Freeipa-devel] [PATCH] 401 Require new samba and krb5 In-Reply-To: <516D63EA.3050106@redhat.com> References: <516D3327.7060905@redhat.com> <516D612A.2090908@redhat.com> <516D63EA.3050106@redhat.com> Message-ID: <516D68D1.6090808@redhat.com> Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/16/2013 01:16 PM, Martin Kosek wrote: >>> Require samba 4.0.5 (passdb API changed). Make sure that we use the >>> right epoch number with samba so that the Requires is correctly >>> enforced. >>> >>> Require krb5 1.11.2-1 to fix missing PAC issue. >>> >>> --- >>> >>> This patch makes sure we have the right dependencies in Fedora 19 (and >>> Fedora >>> 18 too for the samba one). >>> >>> Martin >> >> I've tested on f19 with Kerberos from Koji, and got the following test >> failure in test_cmdline/test_ipagetkeytab.py, test_2_run: >> >> ====================================================================== >> FAIL: Create a keytab with `ipa-getkeytab` for an existing service. >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in >> runTest >> self.test(*self.arg) >> File >> "/home/pviktori/freeipa/tests/test_cmdline/test_ipagetkeytab.py", line >> 110, in test_2_run >> assert err == 'Keytab successfully retrieved and stored in: %s\n' % >> self.keytabname >> AssertionError >> >> >> The command works, the test fails because it doesn't expect warnings >> about Camellia on stderr. I assume they're benign? >> >> Failed to retrieve encryption type Camellia-128 CTS mode with CMAC (#25) >> Failed to retrieve encryption type Camellia-256 CTS mode with CMAC (#26) >> Keytab successfully retrieved and stored in: /tmp/tmpvLHm7l >> >> >> >> On f18 my smoke testing is going fine. >> > > Yes, looks like new ciphers were added that we don't have enabled by > default in IPA. > > The patch looks ok to me, ACK. pushed to master From pviktori at redhat.com Wed Apr 17 10:05:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 17 Apr 2013 12:05:46 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Do not sort dictionaries in assert_deepequal utility function In-Reply-To: <516C0348.9030004@redhat.com> References: <516C0348.9030004@redhat.com> Message-ID: <516E73FA.3040903@redhat.com> On 04/15/2013 03:40 PM, Ana Krivokapic wrote: > Sorting lists of dictionaries in assert_deepequal was causing > inconsistencies in unit test execution. To fix this, do not sort lists > if their elements are dictionaries. > > See the ticket description and comments for more information and example > how to reproduce the problem. > > https://fedorahosted.org/freeipa/ticket/3562 The problem here is that the order in which entries are returned from DS is also undefined. The patch swaps one undefined behavior for another. -- Petr? From pspacek at redhat.com Wed Apr 17 10:23:10 2013 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 17 Apr 2013 12:23:10 +0200 Subject: [Freeipa-devel] [PATCH] 0017 Integrate realmdomains with IPA DNS In-Reply-To: <20130416113243.GS6823@redhat.com> References: <5167DFD2.2030402@redhat.com> <5167E598.4000708@redhat.com> <5167EF72.8090204@redhat.com> <51685663.8090402@redhat.com> <516C2B25.9000307@redhat.com> <516C306F.70609@redhat.com> <516C339A.2070005@redhat.com> <516C38A1.5030506@redhat.com> <516C6F46.6060204@redhat.com> <516CFA5F.9090409@redhat.com> <20130416113243.GS6823@redhat.com> Message-ID: <516E780E.7090709@redhat.com> On 16.4.2013 13:32, Alexander Bokovoy wrote: > On Tue, 16 Apr 2013, Martin Kosek wrote: >> On 04/15/2013 11:21 PM, Rob Crittenden wrote: >>> Ana Krivokapic wrote: >>>> On 04/15/2013 07:06 PM, Martin Kosek wrote: >>>>> On 04/15/2013 06:53 PM, Ana Krivokapic wrote: >>>>>> On 04/15/2013 06:30 PM, Martin Kosek wrote: >>>>>>> On 04/12/2013 08:45 PM, Ana Krivokapic wrote: >>>>>>>> On 04/12/2013 01:26 PM, Ana Krivokapic wrote: >>>>>>>>> On 04/12/2013 12:44 PM, Martin Kosek wrote: >>>>>>>>>> On 04/12/2013 12:20 PM, Ana Krivokapic wrote: >>>>>>>>>>> On 04/11/2013 03:03 PM, Alexander Bokovoy wrote: >>>>>>>>>>>> On Thu, 11 Apr 2013, Ana Krivokapic wrote: >>>>>>>>>>>>> On 04/11/2013 01:43 PM, Alexander Bokovoy wrote: >>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>> On 11.4.2013 13:24, Alexander Bokovoy wrote: >>>>>>>>>>>>>>>> On Thu, 11 Apr 2013, Petr Spacek wrote: >>>>>>>>>>>>>>>>> On 11.4.2013 13:09, Ana Krivokapic wrote: >>>>>>>>>>>>>>>>>> Integrate realmdomains with IPA DNS >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Add an entry to realmdomains when a DNS zone is added to IPA. >>>>>>>>>>>>>>>>>> Delete the >>>>>>>>>>>>>>>>>> related entry from realmdomains when the DNS zone is >>>>>>>>>>>>>>>>>> deleted from >>>>>>>>>>>>>>>>>> IPA. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544 >>>>>>>>>>>>>>>>> I would add a TXT record as I described in >>>>>>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3544#comment:8 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This integration probably should go to both commands, >>>>>>>>>>>>>>>>> realmdomains-* >>>>>>>>>>>>>>>>> dnszone-*. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Any objections? AB? >>>>>>>>>>>>>>>> Adding TXT record is probably harmless. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would actually add the TXT record creation only to >>>>>>>>>>>>>>>> realmdomains-* and >>>>>>>>>>>>>>>> trigger it only in case we manage our DNS and DNS zone is there. >>>>>>>>>>>>>>>> This way a hook from dnszone-add will trigger adding TXT >>>>>>>>>>>>>>>> record back >>>>>>>>>>>>>>>> (via call to >>>>>>>>>>>>>>>> realmdomains-mod --add and then TXT record addition from there). >>>>>>>>>>>>>>>> Also >>>>>>>>>>>>>>>> the fact that admin added manually some domain to realmdomains >>>>>>>>>>>>>>>> mapping >>>>>>>>>>>>>>>> means that it is implied to be used in obtaining TGTs, so TXT >>>>>>>>>>>>>>>> record is >>>>>>>>>>>>>>>> helpful there as well. >>>>>>>>>>>>>>> Okay, it makes sense. We will see how it will work in reality. >>>>>>>>>>>>>> One more thing to check is that we don't do this for our own >>>>>>>>>>>>>> domain. >>>>>>>>>>>>>> >>>>>>>>>>>>> Our own domain is already in realmdomains by default, and it >>>>>>>>>>>>> cannot be >>>>>>>>>>>>> removed from there. So I don't think any check related to our >>>>>>>>>>>>> domain is >>>>>>>>>>>>> necessary. >>>>>>>>>>>> We shouldn't start creating TXT records for our own domain, that's >>>>>>>>>>>> what >>>>>>>>>>>> I'm asking for here. >>>>>>>>>>>> >>>>>>>>>>>> Think about server install stage -- we start creating our own >>>>>>>>>>>> domain and >>>>>>>>>>>> the hook then causes to create realmdomains entry for the domain, >>>>>>>>>>>> causing realmdomains-mod code to raise ValidationError which is not >>>>>>>>>>>> handled in dnszone-add code with this patch. >>>>>>>>>>>> >>>>>>>>>>>> Same for TXT record creation starting from realmdomains-mod side >>>>>>>>>>>> -- it >>>>>>>>>>>> simply should avoid calling dnsrecord-add for the case we know >>>>>>>>>>>> wouldn't >>>>>>>>>>>> work. >>>>>>>>>>>> >>>>>>>>>>> I just realized that this ticket was not marked as RFE although it >>>>>>>>>>> obviously is >>>>>>>>>>> one. I fixed the ticket summary and wrote the design page for this >>>>>>>>>>> enhancement: >>>>>>>>>>> >>>>>>>>>>> http://www.freeipa.org/page/V3/DNS_realmdomains_integration >>>>>>>>>>> >>>>>>>>>> Right, that was a good thing to do. I just have comment for the UPN >>>>>>>>>> enumeration >>>>>>>>>> image which you linked in the RFE - can you please process it, upload >>>>>>>>>> to the >>>>>>>>>> wiki and include in the overview? This will make the RFE page more >>>>>>>>>> appealing >>>>>>>>>> and it will also prevent us from having a broken link when Alexander >>>>>>>>>> removes >>>>>>>>>> the file from his temporary directory. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Martin >>>>>>>>> Sure, done. >>>>>>>>> >>>>>>>> I added the functionality to create TXT record to realmdomains-mod, >>>>>>>> and also >>>>>>>> made sure that the case of our own domain is handled properly. Unit tests >>>>>>>> have >>>>>>>> been added to cover the new functionality. One unit test of the dns >>>>>>>> plugin >>>>>>>> needed adjusting, but it still fails due to the bug in the testing >>>>>>>> framework[1]. It should pass after the bug is fixed. >>>>>>>> >>>>>>>> Updated patch is attached. >>>>>>>> >>>>>>>> [1] https://fedorahosted.org/freeipa/ticket/3562 >>>>>>>> >>>>>>> This looks nice, thanks for the new test cases. >>>>>>> >>>>>>> I experienced an issue with dnsrecord-find test in >>>>>>> tests/test_xmlrpc/test_dns_plugin.py, but I see you already have an open >>>>>>> ticket >>>>>>> to fix that (https://fedorahosted.org/freeipa/ticket/3562) so it is not a >>>>>>> show-stopper. >>>>>>> >>>>>>> This is a nitpick, but could you update >>>>>>> tests/test_xmlrpc/test_dns_realmdomains_integration.py to use the same >>>>>>> domains >>>>>>> for testing as tests/test_xmlrpc/test_dns_plugin.py does? >>>>>>> >>>>>>> I often use example*.com zones in my testing and we also advertise test >>>>>>> commands with these zones in "ipa help dns" too, so I (and maybe others) >>>>>>> could >>>>>>> get surprised that these zones are deleted after running the test suite. >>>>>>> I.e. I >>>>>>> would prefer to have dnszone*.test used for test. >>>>>>> >>>>>>> Thanks, >>>>>>> Martin >>>>>> Sure. Updated patch attached. >>>>>> >>>>> One more nitpick (sorry for not spotting it earlier). In >>>>> realmdomains-mod, you >>>>> do checks for zone/record before you do the dnsrecord-add/dnsrecord-del >>>>> command. >>>>> >>>>> I think this will unnecessarily make the command slower. You can just try >>>>> add/delete a record and catch also a NotFound error - these commands already >>>>> check for zone/record existence, so we do not need to do the checks twice. >>>>> >>>>> Relevant sections: >>>>> >>>>> + try: >>>>> + api.Command['dnszone_show'](unicode(d)) >>>>> + except errors.NotFound: >>>>> + pass >>>>> + else: >>>>> + try: >>>>> + api.Command['dnsrecord_add']( >>>>> + unicode(d), >>>>> + u'_kerberos', >>>>> + txtrecord=api.env.realm >>>>> + ) >>>>> + except errors.EmptyModlist: >>>>> + pass >>>>> >>>>> ... >>>>> >>>>> + try: >>>>> + api.Command['dnszone_show'](unicode(d)) >>>>> + except errors.NotFound: >>>>> + pass >>>>> + else: >>>>> + try: >>>>> + api.Command['dnsrecord_del']( >>>>> + unicode(d), >>>>> + u'_kerberos', >>>>> + txtrecord=api.env.realm >>>>> + ) >>>>> + except errors.AttrValueNotFound: >>>>> + pass >>>>> >>>>> Martin >>>> >>>> Nice catch, those checks were totally unnecessary. Thanks. >>> >>> I tried adding an upper-case version of my primary domain and got an odd >>> error: >>> >>> $ ipa realmdomains-mod --add-domain EXAMPLE.COM >>> ipa: ERROR: Type or value exists: >>> >>> Ok, I can sort of accept that, but there is no real detail. >>> >>> httpd logged this though: >>> >>> [Mon Apr 15 17:15:48.048169 2013] [:error] [pid 3515] ipa: INFO: >>> admin at EXAMPLE.COM: realmdomains_mod(add_domain=u'EXAMPLE.COM', rights=False, >>> force=False, all=False, raw=False, version=u'2.57'): DatabaseError >>> >>> I'm really a little confused about this discrepancy. The client side looks >>> right, I don't understand why we logged a DB error on the server. >>> >>> LDAP has the right error: >>> >>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 MOD dn="cn=Realm >>> Domains,cn=ipa,cn=etc,dc=example,dc=com" >>> [15/Apr/2013:17:15:47 -0400] conn=20 op=7 RESULT err=20 tag=103 nentries=0 >>> etime=0 >>> >>> What led me to try this was this code: >>> >>> + for d in domains_added: >>> + # Skip our own domain >>> + if d == api.env.domain: >>> + continue >>> >>> This probably needs to be case insensitive. >>> >>> rob >> >> We may also want to normalize zones to the non-fqdn DNS version before adding >> them to realmdomains - i.e. store "example.com" instead of "example.com.". >> Adding Alexander to CC list to verify this is a sound requirement. > Looking into DNS schema I see most records there use caseIgnoreIA5Match > or similar caseless search. It means our comparison in the python code > should follow caseless searches too. All DNS *names* are case-insensitive. The schema is a bit weird when it comes to *data* etc., but the idnsName attribute should ignore the case. -- Petr^2 Spacek From rcritten at redhat.com Wed Apr 17 13:00:19 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Apr 2013 09:00:19 -0400 Subject: [Freeipa-devel] [PATCH] 0018 Do not sort dictionaries in assert_deepequal utility function In-Reply-To: <516E73FA.3040903@redhat.com> References: <516C0348.9030004@redhat.com> <516E73FA.3040903@redhat.com> Message-ID: <516E9CE3.2090905@redhat.com> Petr Viktorin wrote: > On 04/15/2013 03:40 PM, Ana Krivokapic wrote: >> Sorting lists of dictionaries in assert_deepequal was causing >> inconsistencies in unit test execution. To fix this, do not sort lists >> if their elements are dictionaries. >> >> See the ticket description and comments for more information and example >> how to reproduce the problem. >> >> https://fedorahosted.org/freeipa/ticket/3562 > > The problem here is that the order in which entries are returned from DS > is also undefined. The patch swaps one undefined behavior for another. > > Undefined but somewhat predictable. Unless we see the test(s) randomly failing because of unpredictable behavior I think it is something we could live with. This is short-lived data after all. rob From jcholast at redhat.com Wed Apr 17 13:19:37 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 17 Apr 2013 15:19:37 +0200 Subject: [Freeipa-devel] [PATCH] 129 Use correct zone when removing DNS records of a master Message-ID: <516EA169.7040200@redhat.com> Hi, this patch fixes . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-129-Use-correct-zone-when-removing-DNS-records-of-a-mast.patch Type: text/x-patch Size: 1499 bytes Desc: not available URL: From pviktori at redhat.com Wed Apr 17 14:55:43 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 17 Apr 2013 16:55:43 +0200 Subject: [Freeipa-devel] [PATCH] 129 Use correct zone when removing DNS records of a master In-Reply-To: <516EA169.7040200@redhat.com> References: <516EA169.7040200@redhat.com> Message-ID: <516EB7EF.7030902@redhat.com> On 04/17/2013 03:19 PM, Jan Cholasta wrote: > Hi, > > this patch fixes . > > Honza > ACK -- Petr? From mkosek at redhat.com Thu Apr 18 06:06:03 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Apr 2013 08:06:03 +0200 Subject: [Freeipa-devel] [PATCH] 129 Use correct zone when removing DNS records of a master In-Reply-To: <516EB7EF.7030902@redhat.com> References: <516EA169.7040200@redhat.com> <516EB7EF.7030902@redhat.com> Message-ID: <516F8D4B.5020408@redhat.com> On 04/17/2013 04:55 PM, Petr Viktorin wrote: > On 04/17/2013 03:19 PM, Jan Cholasta wrote: >> Hi, >> >> this patch fixes . >> >> Honza >> > > ACK > Pushed to master, ipa-3-1. Martin From pspacek at redhat.com Thu Apr 18 09:04:23 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Apr 2013 11:04:23 +0200 Subject: [Freeipa-devel] [PATCH 0149] Clean up PTR record synchronization code and make it more robust Message-ID: <516FB717.9010203@redhat.com> Hello, Clean up PTR record synchronization code and make it more robust. PTR record synchronization was split to smaller functions. Input validation, error handling and logging was improved significantly. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0149-Clean-up-PTR-record-synchronization-code-and-make-it.patch Type: text/x-patch Size: 18967 bytes Desc: not available URL: From akrivoka at redhat.com Thu Apr 18 09:11:29 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 18 Apr 2013 11:11:29 +0200 Subject: [Freeipa-devel] [PATCH] 0019 Improve help text for HBAC service groups Message-ID: <516FB8C1.5040809@redhat.com> Hello, Remove the part of help text for HBAC service groups which contains an example suggesting that nested groups are supported. Nested groups are not supported in HBAC service groups. https://fedorahosted.org/freeipa/ticket/3548 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0019-Improve-help-text-for-HBAC-service-groups.patch Type: text/x-patch Size: 1114 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 18 13:12:56 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Apr 2013 09:12:56 -0400 Subject: [Freeipa-devel] Fedora 19 Test Day today, April 18 Message-ID: <516FF158.2040509@redhat.com> The FreeIPA team is happy to welcome you to a Fedora Test Day that is being held today, Thursday, April 18th. We invite you to take part in testing of the new features that will become available in upcoming FreeIPA 3.2 upstream release and will be a part of Fedora 19. To read more about the test day and suggested tests see the following link http://fedoraproject.org/wiki/Test_Day:2013-04-18 The outline of the features of the upcoming release can be found in the following announcement: https://www.redhat.com/archives/freeipa-devel/2013-April/msg00028.html Thank you for your help and participation! FreeIPA team From mkosek at redhat.com Thu Apr 18 13:21:14 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Apr 2013 15:21:14 +0200 Subject: [Freeipa-devel] Fedora 19 Test Day today, April 18 In-Reply-To: <516FF158.2040509@redhat.com> References: <516FF158.2040509@redhat.com> Message-ID: <516FF34A.2030407@redhat.com> On 04/18/2013 03:12 PM, Rob Crittenden wrote: > The FreeIPA team is happy to welcome you to a Fedora Test Day that is being > held today, Thursday, April 18th. > > We invite you to take part in testing of the new features that will become > available in upcoming FreeIPA 3.2 upstream release and will be a part of Fedora > 19. > > To read more about the test day and suggested tests see the following link > http://fedoraproject.org/wiki/Test_Day:2013-04-18 > > The outline of the features of the upcoming release can be found in the > following announcement: > https://www.redhat.com/archives/freeipa-devel/2013-April/msg00028.html > > Thank you for your help and participation! > > FreeIPA team > I would just like to add more information for new testers. To save your time when testing FreeIPA on Fedora 19, please make sure that you have java-atk-wrapper package installed before you install FreeIPA (relevant Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=953413). If you do not have the package installed, you can avoid the ipa-server-install crash by installing this package and rebooting or killing pki processes before running ipa-server-install. Other already known issues can be found at the test day page or our public test day etherpad: http://openetherpad.org/Fedora-19-IPA-Test-Day Happy testing! Martin From rcritten at redhat.com Thu Apr 18 13:38:14 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Apr 2013 09:38:14 -0400 Subject: [Freeipa-devel] Announcing FreeIPA 3.2.0 Beta 1 Message-ID: <516FF746.2090306@redhat.com> The FreeIPA team is proud to announce the first Beta of FreeIPA v3.2.0. We would like to welcome any early testers of this Beta to provide us feedback and help us stabilize this feature release which we plan to release as final in the beginning of May 2013. It can be downloaded from http://www.freeipa.org/page/Downloads. The new version has also been built for Fedora 19 Alpha. == Highlights in 3.2.0 Beta 1 == === New features for 3.2.0 === * Support installing FreeIPA without an embedded Certificate Authority, with user-provided SSL certificates for the HTTP and Directory servers. [1] * New cert-find command. Search certificates in the Dogtag database based on their serial number, validity or revocation details. This feature is available both as a CLI command and Web UI page. [2] * New trustconfig-show and trustconfig-mod command. Show or modify AD Trust settings generated during AD Trust installation (ipa-adtrust-install) [3] * Multiple FreeIPA servers can now be designated as Domain Controllers for trusts with Active Directory [12] * New realmdomains-show and realmdomains-mod command. Manage list of DNS domains associated with FreeIPA realm (realmdomains sommand). This list is primarily used by AD, which can pull all domains managed by FreeIPA and use that list for routing authentication requests for domains which do not match FreeIPA realm name. [4] * Support trusted domain users in HBAC test command (hbactest command). * Allow filtering incoming trusted domain SIDs per-trust (trust-mod command). [5] * Configurable PAC type for services. Service commands can now configure a set of PAC types (MS-PAC, PAD, no PAC) that are supported and handled for the service. * Faster UI loading. FreeIPA Web UI application is now packaged in minimalized format. FreeIPA web server is now also able to transmit data in compressed format. [6] [7] * UI now accepts confirmation of cancel of its dialogs via keyboard [11] * Client reenrollment. A host that has been recreated can now be reenrolled to FreeIPA server using a backed up host keytab or admin credentials [8] * Service and Host commands now provide options to add or remove selected Kerberos flags [9] * Full system backup and restore [13] * Source hosts have been completely removed from HBAC. They haven't been used by SSSD for quite some time and are being removed to avoid the suggestion that they might actually do something. * Updated French and Ukranian translations. === Beta 1 limitations === * List of DNS domains associated with FreeIPA realm currently only works with a special Samba build available for Fedora 18: http://koji.fedoraproject.org/koji/taskinfo?taskID=5184105. One needs to rebuild FreeIPA 3.2.0 beta 1 against this Samba version in order to get it working. * Test of trusted domain users in HBAC rules is accessible to only to members of 'Trust Admins' group due to privilege limitations * Same applies to any other trust-specific operations that require translation between user/group name and its security identifier (SID) === Bug fixes === * Fixed migration from OpenLDAP. FreeIPA is now able to migrate users and groups from OpenLDAP database instances. * Migration process is now also a lot faster and provides more debug output (to httpd error log). * SUDO rules disabled by sudorule-disable command are now removed from ou=sudoers compat tree without a need to restart 389 Directory Server instance. * Fixed LDAP schema upgrade when upgrading from a pre-2.2.0 release * Fixed server installation with external CA (--external-ca) * Consolidate on-line help system, show help without need of valid Kerberos credentials (ipa help) * New LDAP plugin (ipa_dns) has been added to add missing idnsSOASerial attribute for replicas which either do not have integrated DNS service enabled to which have disabled SOA serial autoincrement * LDAP lockout plugin has been fixed so that lockout policies are applied consistently both for LDAP binds and Kerberos authentication * ... and many others stabilization fixes, see Detailed changelog for full details == Changes in API or CLI == === Dropped --selfsign option === FreeIPA servers prior to 3.2.0 could be installed with --selfsign option. This configured the server with a NSS database based Certificate Authority with a selfsigned CA certificate and limited certificate operation support. This option was always intended for development or testing purposes only and was not intended for use in production. This release drops this option and deprecates the functionality. Current FreeIPA servers installed with --selfsigned option will still work, instructions on how to migrate to supported certificate options will be provided. FreeIPA servers version 3.2.0 and later supports the following 2 flavors of certificate management: * FreeIPA with pki-ca (dogtag) with either a self-signed certificate or with a certificate signed by external CA (--external-ca option) * FreeIPA with no pki-ca installed with certificates signed and provided by an external CA [1] === Dropped CSV support === FreeIPA client CLI supported CSV in some arguments so that multiple values could be added with just one convenient option: ipa permission-add some-perm --permissions=read,write --attrs=sn,cn ipa dnsrecord-add example.com --a-rec=10.0.0.1,10.0.0.2 CSV parsing however introduces great difficulty when trying to include a value with an embedded space in it. Escaping these values is not intuitive and made it very difficult to add such values. The level of effort in working around the CSV problems has come to the point where the benefits of it are outweighed by the problems which lead to decision to drop CSV support in CLI altogether [10]. There are several ways to workaround lack of CSV: Provide an argument multiple times on the command-line: ipa permission-add some-perm --permissions=read --permissions=write --attrs=sn --attrs=cn ipa dnsrecord-add example.com --a-rec=10.0.0.1 --a-rec=10.0.0.2 Let BASH do the expansion for you: ipa permission-add some-perm --permissions={read,write} --attrs={sn,cn} ipa dnsrecord-add example.com --a-rec={10.0.0.1,10.0.0.2} == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 and later versions is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa channel on Freenode. == Documentation == * [1] http://www.freeipa.org/page/V3/CA-less_install * [2] http://www.freeipa.org/page/V3/Cert_find * [3] http://www.freeipa.org/page/V3/Trust_config_command * [4] http://www.freeipa.org/page/V3/Realm_Domains * [5] http://www.freeipa.org/page/V3/Configurable_SID_Blacklists * [6] http://www.freeipa.org/page/V3/WebUI_gzip_compression * [7] http://www.freeipa.org/page/V3/WebUI_build * [8] http://www.freeipa.org/page/V3/Forced_client_re-enrollment * [9] http://www.freeipa.org/page/V3/Kerberos_Flags * [10] http://www.freeipa.org/page/V3/Drop_CSV * [11] http://www.freeipa.org/page/V3/WebUI_keyboard_confirmation * [12] http://www.freeipa.org/page/V3/MultipleTrustServers * [13] http://freeipa.org/page/V3/Backup_and_Restore == Detailed Changelog since 3.2.0.pre1 == Alexander Bokovoy (1): * spec: detect Kerberos DAL driver ABI change from installed krb5-devel Ana Krivokapic (7): * Remove CA cert on client uninstall * Fix output for some CLI commands * Add missing summary message to dnszone_del * Remove HBAC source hosts from web UI * Remove any reference to HBAC source hosts from help * Deprecate HBAC source hosts from CLI * Integrate realmdomains with IPA DNS Jan Cholasta (4): * Do actually stop pki_cad in stop_pkicad instead of starting it. * Use only one URL for OCSP and CRL in IPA certificate profile. * Use A/AAAA records instead of CNAME records in ipa-ca. * Delete DNS records in ipa-ca on ipa-csreplica-manage del. Martin Kosek (2): * Fix trustconfig-mod primary group error * Require new samba and krb5 Petr Viktorin (7): * Display full command documentation in online help * Remove 'cn' attribute from idnsRecord and idnsZone objectClasses * ipa-server-install: correct help text for --external_{cert,ca}_file * Update translations from Transifex * Uninstall selfsign CA on upgrade * Remove obsolete self-sign references from man pages, docstrings, comments * Drop --selfsign server functionality Petr Vobornik (6): * Add ipakrbokasdelegate option to service and host Web UI pages * Run permission target switch action only for visible widgets * Filter groups by type (POSIX, non-POSIX, external) * Global trust config page * Don't show trusts pages when trust is not configured * Fix regression in group type selection in group adder dialog Rob Crittenden (5): * Fix two failing tests due to missing krb ticket flags * Full system backup and restore * Apply LDAP update files in blocks of 10, as originally designed. * Revert "Fix permission_find test error" * Become 3.2.0 Beta 1 Tomas Babej (2): * Add nfs:NONE to default PAC types only when needed * Update only selected attributes for winsync agreement From npmccallum at redhat.com Thu Apr 18 13:48:56 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 18 Apr 2013 09:48:56 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1365802766.21323.36.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> Message-ID: <1366292936.17909.3.camel@localhost.localdomain> On Fri, 2013-04-12 at 17:39 -0400, Nathaniel McCallum wrote: > On Fri, 2013-04-12 at 11:53 -0400, Nathaniel McCallum wrote: > > On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: > > > On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: > > > > Nathaniel McCallum wrote: > > > > > On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > > > > >> I'm not sure how I'd test it if I got it built. > > > > > > > > > > I'm working on this. I hope to have a clear answer next week. Bear with > > > > > me... > > > > > > > > > >> Overall looks really good. > > > > > > > > > > I've split up the patch into multiple commits. I've also added .update > > > > > files and a patch for ipa-kdb to feed krb5 the right user string. > > > > > > > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > > > > > > > Please take a look. I *think* I've got everything worked out so far with > > > > > the exception of bug numbers / urls. Should every patch have a separate > > > > > bug and a link to the design page? > > > > > > > > The ticket should go into every commit. I'd probably put the design link > > > > there too, just for completeness. Future bug fixes, et all aren't going > > > > to require the design page, but since these commits are all related to > > > > the initial feature it will be nice to have. > > > > > > > > You can have multiple patches on the same ticket/bug. > > > > > > https://github.com/npmccallum/freeipa/commits/otp > > > > > > All four commits now have bug numbers and design page links. I'm adding > > > the design page link to the tickets as we speak. > > > > > > Remaining issues (AFAICS): > > > 1. The daemon (ipa-otpd) runs as root and binds anonymously > > > 2. ipatokenRadiusSecret is readable by an anonymous bind > > 3. ipatokenT?OTP.* are readable by an anonymous bind > > > > In the case of both #2 and #3, only admins should have RW. ipa-otpd > > needs read access to ipatokenRadiusSecret. The DS bind plugin below (#2) > > needs read access to ipatokenT?OTP.*. > > > > > Outstanding pieces: > > > 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 > > > 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 > > > 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 > > > 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 > > > > > > #1 and #2 are within the scope of F19 and should hopefully land shortly > > > (in separate commits). #3 and #4 are probably $nextrelease. > > > > > FYI - Here is an RPM with all of the code so far: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5247029 Updated RPMs, containing the new 389DS bind plugin and build for F19, are here: http://koji.fedoraproject.org/koji/taskinfo?taskID=5270926 Nathaniel From pspacek at redhat.com Thu Apr 18 14:58:12 2013 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 18 Apr 2013 16:58:12 +0200 Subject: [Freeipa-devel] [PATCH 0150] Do not delete whole node during PTR record synchronization. Message-ID: <51700A04.3070305@redhat.com> Hello, Do not delete whole node during PTR record synchronization. https://fedorahosted.org/bind-dyndb-ldap/ticket/115 -- Petr Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0150-Do-not-delete-whole-node-during-PTR-record-synchroni.patch Type: text/x-patch Size: 3915 bytes Desc: not available URL: From jcholast at redhat.com Thu Apr 18 17:25:01 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 18 Apr 2013 19:25:01 +0200 Subject: [Freeipa-devel] [PATCH] 130 Drop support for OpenSSH versions before 6.2 Message-ID: <51702C6D.70900@redhat.com> Hi, this patch fixes . OpenSSH 6.2 brings upstream support for AuthorizedKeysCommand, which is required for OpenSSH integration. Until now, we relied on downstream patches and enabled parts of OpenSSH integration conditionally. This patch includes a scriptlet which updates sshd_config on freeipa-client RPM update. Please note that the scriptlet will work only if IPA client was set up before openssh-server package was updated to 6.2p1. This is because unpatched ipa-client-install does not configure sshd_config when openssh-server 6.2p1 is already installed (see https://bugzilla.redhat.com/show_bug.cgi?id=953617). Specifically, it will not work for IPA installs done on recently updated Fedora 19. Also, this does not fix SSH integration not working on Fedora 18, as that is caused by backward incompatiblity in openssh-server-6.1p1-6 and later (see https://bugzilla.redhat.com/show_bug.cgi?id=953534). Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-130-Drop-support-for-OpenSSH-versions-before-6.2.patch Type: text/x-patch Size: 3826 bytes Desc: not available URL: From rcritten at redhat.com Thu Apr 18 21:30:33 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Apr 2013 17:30:33 -0400 Subject: [Freeipa-devel] [PATCH] 0019 Improve help text for HBAC service groups In-Reply-To: <516FB8C1.5040809@redhat.com> References: <516FB8C1.5040809@redhat.com> Message-ID: <517065F9.7060201@redhat.com> Ana Krivokapic wrote: > Hello, > > Remove the part of help text for HBAC service groups which contains an > example suggesting that nested groups are supported. Nested groups are > not supported in HBAC service groups. > > https://fedorahosted.org/freeipa/ticket/3548 > ACK, pushed to master rob From pviktori at redhat.com Fri Apr 19 10:26:36 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Apr 2013 12:26:36 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Do not sort dictionaries in assert_deepequal utility function In-Reply-To: <516E9CE3.2090905@redhat.com> References: <516C0348.9030004@redhat.com> <516E73FA.3040903@redhat.com> <516E9CE3.2090905@redhat.com> Message-ID: <51711BDC.1020508@redhat.com> On 04/17/2013 03:00 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> On 04/15/2013 03:40 PM, Ana Krivokapic wrote: >>> Sorting lists of dictionaries in assert_deepequal was causing >>> inconsistencies in unit test execution. To fix this, do not sort lists >>> if their elements are dictionaries. >>> >>> See the ticket description and comments for more information and example >>> how to reproduce the problem. >>> >>> https://fedorahosted.org/freeipa/ticket/3562 >> >> The problem here is that the order in which entries are returned from DS >> is also undefined. The patch swaps one undefined behavior for another. >> >> > > Undefined but somewhat predictable. Unless we see the test(s) randomly > failing because of unpredictable behavior I think it is something we > could live with. This is short-lived data after all. > > rob OK then. It's cutting corners but it makes the tests pass for now. ACK. -- Petr? From pspacek at redhat.com Fri Apr 19 10:44:46 2013 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 19 Apr 2013 12:44:46 +0200 Subject: [Freeipa-devel] [PATCH 0151] Disallow all zone transfers/queries if transfer/query policy configuration failed Message-ID: <5171201E.9030502@redhat.com> Hello, Disallow all zone transfers/queries if transfer/query policy configuration failed. Without this patch the old policy stays in effect if re-configuration with the new policy failed. https://fedorahosted.org/bind-dyndb-ldap/ticket/116 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0151-Disallow-all-zone-transfers-queries-if-transfer-quer.patch Type: text/x-patch Size: 4691 bytes Desc: not available URL: From mkosek at redhat.com Fri Apr 19 10:46:59 2013 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 19 Apr 2013 12:46:59 +0200 Subject: [Freeipa-devel] [PATCH] 0018 Do not sort dictionaries in assert_deepequal utility function In-Reply-To: <51711BDC.1020508@redhat.com> References: <516C0348.9030004@redhat.com> <516E73FA.3040903@redhat.com> <516E9CE3.2090905@redhat.com> <51711BDC.1020508@redhat.com> Message-ID: <517120A3.9090108@redhat.com> On 04/19/2013 12:26 PM, Petr Viktorin wrote: > On 04/17/2013 03:00 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> On 04/15/2013 03:40 PM, Ana Krivokapic wrote: >>>> Sorting lists of dictionaries in assert_deepequal was causing >>>> inconsistencies in unit test execution. To fix this, do not sort lists >>>> if their elements are dictionaries. >>>> >>>> See the ticket description and comments for more information and example >>>> how to reproduce the problem. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3562 >>> >>> The problem here is that the order in which entries are returned from DS >>> is also undefined. The patch swaps one undefined behavior for another. >>> >>> >> >> Undefined but somewhat predictable. Unless we see the test(s) randomly >> failing because of unpredictable behavior I think it is something we >> could live with. This is short-lived data after all. >> >> rob > > OK then. It's cutting corners but it makes the tests pass for now. ACK. > Pushed to master. Martin From pviktori at redhat.com Fri Apr 19 12:13:59 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 19 Apr 2013 14:13:59 +0200 Subject: [Freeipa-devel] [PATCH] 0217 Use two digits for each part of NUM_VERSION Message-ID: <51713507.9040406@redhat.com> Hello, This fixes https://fedorahosted.org/freeipa/ticket/3545 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0217-Use-two-digits-for-each-part-of-NUM_VERSION.patch Type: text/x-patch Size: 1693 bytes Desc: not available URL: From akrivoka at redhat.com Fri Apr 19 13:25:14 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 19 Apr 2013 15:25:14 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install Message-ID: <517145BA.30204@redhat.com> Hello, Make sure /etc/ipa is created and owned by freeipa-python package. Report correct error to user if /etc/ipa is missing during client installation. https://fedorahosted.org/freeipa/ticket/3551 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0020-Handle-missing-etc-ipa-in-ipa-client-install.patch Type: text/x-patch Size: 2752 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 19 13:48:36 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Apr 2013 09:48:36 -0400 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <517145BA.30204@redhat.com> References: <517145BA.30204@redhat.com> Message-ID: <51714B34.6060804@redhat.com> Ana Krivokapic wrote: > Hello, > > Make sure /etc/ipa is created and owned by freeipa-python package. > > Report correct error to user if /etc/ipa is missing during client > installation. > > https://fedorahosted.org/freeipa/ticket/3551 The server also owns this directory. It should only be owned by the python subpackage. %dir %{_sysconfdir}/ipa rob From rcritten at redhat.com Fri Apr 19 13:58:58 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Apr 2013 09:58:58 -0400 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <51714B34.6060804@redhat.com> References: <517145BA.30204@redhat.com> <51714B34.6060804@redhat.com> Message-ID: <51714DA2.5010408@redhat.com> Rob Crittenden wrote: > Ana Krivokapic wrote: >> Hello, >> >> Make sure /etc/ipa is created and owned by freeipa-python package. >> >> Report correct error to user if /etc/ipa is missing during client >> installation. >> >> https://fedorahosted.org/freeipa/ticket/3551 > > The server also owns this directory. It should only be owned by the > python subpackage. > > %dir %{_sysconfdir}/ipa > > rob The mode should probably be 0755. rob From akrivoka at redhat.com Fri Apr 19 14:14:30 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 19 Apr 2013 16:14:30 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <51714DA2.5010408@redhat.com> References: <517145BA.30204@redhat.com> <51714B34.6060804@redhat.com> <51714DA2.5010408@redhat.com> Message-ID: <51715146.3010705@redhat.com> On 04/19/2013 03:58 PM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Ana Krivokapic wrote: >>> Hello, >>> >>> Make sure /etc/ipa is created and owned by freeipa-python package. >>> >>> Report correct error to user if /etc/ipa is missing during client >>> installation. >>> >>> https://fedorahosted.org/freeipa/ticket/3551 >> >> The server also owns this directory. It should only be owned by the >> python subpackage. >> >> %dir %{_sysconfdir}/ipa >> >> rob > > The mode should probably be 0755. > > rob > Thanks, fixed. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0020-02-Handle-missing-etc-ipa-in-ipa-client-install.patch Type: text/x-patch Size: 3067 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 19 14:56:15 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Apr 2013 10:56:15 -0400 Subject: [Freeipa-devel] [PATCH] 0217 Use two digits for each part of NUM_VERSION In-Reply-To: <51713507.9040406@redhat.com> References: <51713507.9040406@redhat.com> Message-ID: <51715B0F.10308@redhat.com> Petr Viktorin wrote: > Hello, > This fixes https://fedorahosted.org/freeipa/ticket/3545 > ACK, pushed to master and ipa-3-1 rob From rcritten at redhat.com Fri Apr 19 14:58:29 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Apr 2013 10:58:29 -0400 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <51715146.3010705@redhat.com> References: <517145BA.30204@redhat.com> <51714B34.6060804@redhat.com> <51714DA2.5010408@redhat.com> <51715146.3010705@redhat.com> Message-ID: <51715B95.8070502@redhat.com> Ana Krivokapic wrote: > On 04/19/2013 03:58 PM, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Ana Krivokapic wrote: >>>> Hello, >>>> >>>> Make sure /etc/ipa is created and owned by freeipa-python package. >>>> >>>> Report correct error to user if /etc/ipa is missing during client >>>> installation. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3551 >>> >>> The server also owns this directory. It should only be owned by the >>> python subpackage. >>> >>> %dir %{_sysconfdir}/ipa >>> >>> rob >> >> The mode should probably be 0755. >> >> rob >> > > Thanks, fixed. > ACK. pushed to master and ipa-3-1 rob From rcritten at redhat.com Fri Apr 19 17:39:08 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Apr 2013 13:39:08 -0400 Subject: [Freeipa-devel] [PATCH] 130 Drop support for OpenSSH versions before 6.2 In-Reply-To: <51702C6D.70900@redhat.com> References: <51702C6D.70900@redhat.com> Message-ID: <5171813C.10502@redhat.com> Jan Cholasta wrote: > Hi, > > this patch fixes . > > OpenSSH 6.2 brings upstream support for AuthorizedKeysCommand, > which is required for OpenSSH integration. Until now, we relied on > downstream > patches and enabled parts of OpenSSH integration conditionally. > > This patch includes a scriptlet which updates sshd_config on > freeipa-client RPM update. Please note that the scriptlet will work only > if IPA client was set up before openssh-server package was updated to > 6.2p1. This is because unpatched ipa-client-install does not configure > sshd_config when openssh-server 6.2p1 is already installed (see > https://bugzilla.redhat.com/show_bug.cgi?id=953617). Specifically, it > will not work for IPA installs done on recently updated Fedora 19. > > Also, this does not fix SSH integration not working on Fedora 18, as > that is caused by backward incompatiblity in openssh-server-6.1p1-6 and > later (see https://bugzilla.redhat.com/show_bug.cgi?id=953534). This seems to work ok. Do we want to do this upgrade as an rpm scriptlet or is it better to handle this in ipa-upgradeconfig (it might be easier to maintain there)? In any case, a condrestart of sssd is required to have it pick up the new config. Do you know if F-18 will get 6.2? Do we need to consider backporting this to 3.1? rob From dpal at redhat.com Sun Apr 21 19:14:14 2013 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 21 Apr 2013 15:14:14 -0400 Subject: [Freeipa-devel] Integration with the provisioning systems Message-ID: <51743A86.7090206@redhat.com> Hello, Please review the design page for the following ticket: https://fedorahosted.org/freeipa/ticket/3583 http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Mon Apr 22 06:16:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Apr 2013 08:16:58 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <51715B95.8070502@redhat.com> References: <517145BA.30204@redhat.com> <51714B34.6060804@redhat.com> <51714DA2.5010408@redhat.com> <51715146.3010705@redhat.com> <51715B95.8070502@redhat.com> Message-ID: <5174D5DA.4060702@redhat.com> On 04/19/2013 04:58 PM, Rob Crittenden wrote: > Ana Krivokapic wrote: >> On 04/19/2013 03:58 PM, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Ana Krivokapic wrote: >>>>> Hello, >>>>> >>>>> Make sure /etc/ipa is created and owned by freeipa-python package. >>>>> >>>>> Report correct error to user if /etc/ipa is missing during client >>>>> installation. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3551 >>>> >>>> The server also owns this directory. It should only be owned by the >>>> python subpackage. >>>> >>>> %dir %{_sysconfdir}/ipa >>>> >>>> rob >>> >>> The mode should probably be 0755. >>> >>> rob >>> >> >> Thanks, fixed. >> > > ACK. pushed to master and ipa-3-1 > > rob > Hm, the spec change does not look right to me: +%dir %attr(0755,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ Why is the directory owned by group apache? Why does the directory have "%config(noreplace)" set? Isn't it a NOOP when set for a directory (just asking)? This is what we get when we install freeipa-python now: # rm -r /etc/ipa/ # rpm -Uvh --force /home/mkosek/dist-master/rpms/freeipa-client-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm /home/mkosek/dist-master/rpms/freeipa-python-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm # ll -d /etc/ipa/ drwxr-xr-x. 2 root apache 4096 Apr 22 02:05 /etc/ipa/ ^^^^^^ Thanks, Martin From mkosek at redhat.com Mon Apr 22 06:25:27 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Apr 2013 08:25:27 +0200 Subject: [Freeipa-devel] [PATCH] 130 Drop support for OpenSSH versions before 6.2 In-Reply-To: <5171813C.10502@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> Message-ID: <5174D7D7.8010204@redhat.com> On 04/19/2013 07:39 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> this patch fixes . >> >> OpenSSH 6.2 brings upstream support for AuthorizedKeysCommand, >> which is required for OpenSSH integration. Until now, we relied on >> downstream >> patches and enabled parts of OpenSSH integration conditionally. >> >> This patch includes a scriptlet which updates sshd_config on >> freeipa-client RPM update. Please note that the scriptlet will work only >> if IPA client was set up before openssh-server package was updated to >> 6.2p1. This is because unpatched ipa-client-install does not configure >> sshd_config when openssh-server 6.2p1 is already installed (see >> https://bugzilla.redhat.com/show_bug.cgi?id=953617). Specifically, it >> will not work for IPA installs done on recently updated Fedora 19. >> >> Also, this does not fix SSH integration not working on Fedora 18, as >> that is caused by backward incompatiblity in openssh-server-6.1p1-6 and >> later (see https://bugzilla.redhat.com/show_bug.cgi?id=953534). > > This seems to work ok. Do we want to do this upgrade as an rpm scriptlet or is > it better to handle this in ipa-upgradeconfig (it might be easier to maintain > there)? As we need to run this upgrade on all clients (not only FreeIPA servers), ipa-upgradeconfig is not a way to go. We would first need a client upgrade script to do that: https://fedorahosted.org/freeipa/ticket/3149 This is now scheduled for a next version, we may want to convert our current spec file upgrades to this ipa-client-upgrade script when it is ready. Martin From akrivoka at redhat.com Mon Apr 22 09:29:56 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Apr 2013 11:29:56 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <5174D5DA.4060702@redhat.com> References: <517145BA.30204@redhat.com> <51714B34.6060804@redhat.com> <51714DA2.5010408@redhat.com> <51715146.3010705@redhat.com> <51715B95.8070502@redhat.com> <5174D5DA.4060702@redhat.com> Message-ID: <51750314.1050907@redhat.com> On 04/22/2013 08:16 AM, Martin Kosek wrote: > On 04/19/2013 04:58 PM, Rob Crittenden wrote: >> Ana Krivokapic wrote: >>> On 04/19/2013 03:58 PM, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Ana Krivokapic wrote: >>>>>> Hello, >>>>>> >>>>>> Make sure /etc/ipa is created and owned by freeipa-python package. >>>>>> >>>>>> Report correct error to user if /etc/ipa is missing during client >>>>>> installation. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3551 >>>>> The server also owns this directory. It should only be owned by the >>>>> python subpackage. >>>>> >>>>> %dir %{_sysconfdir}/ipa >>>>> >>>>> rob >>>> The mode should probably be 0755. >>>> >>>> rob >>>> >>> Thanks, fixed. >>> >> ACK. pushed to master and ipa-3-1 >> >> rob >> > Hm, the spec change does not look right to me: > > +%dir %attr(0755,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ > > Why is the directory owned by group apache? Why does the directory have > "%config(noreplace)" set? Isn't it a NOOP when set for a directory (just asking)? > > This is what we get when we install freeipa-python now: > > # rm -r /etc/ipa/ > # rpm -Uvh --force > /home/mkosek/dist-master/rpms/freeipa-client-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm > /home/mkosek/dist-master/rpms/freeipa-python-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm > > # ll -d /etc/ipa/ > drwxr-xr-x. 2 root apache 4096 Apr 22 02:05 /etc/ipa/ > ^^^^^^ > Thanks, > Martin You are right, it was a mistake on my part. Attached is a oneliner fix. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0021-Fix-the-spec-file.patch Type: text/x-patch Size: 972 bytes Desc: not available URL: From akrivoka at redhat.com Mon Apr 22 09:53:58 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Apr 2013 11:53:58 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <51750314.1050907@redhat.com> References: <517145BA.30204@redhat.com> <51714B34.6060804@redhat.com> <51714DA2.5010408@redhat.com> <51715146.3010705@redhat.com> <51715B95.8070502@redhat.com> <5174D5DA.4060702@redhat.com> <51750314.1050907@redhat.com> Message-ID: <517508B6.4020209@redhat.com> On 04/22/2013 11:29 AM, Ana Krivokapic wrote: > On 04/22/2013 08:16 AM, Martin Kosek wrote: >> On 04/19/2013 04:58 PM, Rob Crittenden wrote: >>> Ana Krivokapic wrote: >>>> On 04/19/2013 03:58 PM, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Ana Krivokapic wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Make sure /etc/ipa is created and owned by freeipa-python package. >>>>>>> >>>>>>> Report correct error to user if /etc/ipa is missing during client >>>>>>> installation. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3551 >>>>>> The server also owns this directory. It should only be owned by the >>>>>> python subpackage. >>>>>> >>>>>> %dir %{_sysconfdir}/ipa >>>>>> >>>>>> rob >>>>> The mode should probably be 0755. >>>>> >>>>> rob >>>>> >>>> Thanks, fixed. >>>> >>> ACK. pushed to master and ipa-3-1 >>> >>> rob >>> >> Hm, the spec change does not look right to me: >> >> +%dir %attr(0755,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ >> >> Why is the directory owned by group apache? Why does the directory have >> "%config(noreplace)" set? Isn't it a NOOP when set for a directory (just asking)? >> >> This is what we get when we install freeipa-python now: >> >> # rm -r /etc/ipa/ >> # rpm -Uvh --force >> /home/mkosek/dist-master/rpms/freeipa-client-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm >> /home/mkosek/dist-master/rpms/freeipa-python-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm >> >> # ll -d /etc/ipa/ >> drwxr-xr-x. 2 root apache 4096 Apr 22 02:05 /etc/ipa/ >> ^^^^^^ >> Thanks, >> Martin > You are right, it was a mistake on my part. Attached is a oneliner fix. > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel I forgot to add link to the ticket to commit message. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0021-Fix-the-spec-file.patch Type: text/x-patch Size: 1018 bytes Desc: not available URL: From mkosek at redhat.com Mon Apr 22 09:54:01 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Apr 2013 11:54:01 +0200 Subject: [Freeipa-devel] [PATCH] 0020 Handle missing /etc/ipa in ipa-client-install In-Reply-To: <517508B6.4020209@redhat.com> References: <517145BA.30204@redhat.com> <51714B34.6060804@redhat.com> <51714DA2.5010408@redhat.com> <51715146.3010705@redhat.com> <51715B95.8070502@redhat.com> <5174D5DA.4060702@redhat.com> <51750314.1050907@redhat.com> <517508B6.4020209@redhat.com> Message-ID: <517508B9.4080208@redhat.com> On 04/22/2013 11:53 AM, Ana Krivokapic wrote: > On 04/22/2013 11:29 AM, Ana Krivokapic wrote: >> On 04/22/2013 08:16 AM, Martin Kosek wrote: >>> On 04/19/2013 04:58 PM, Rob Crittenden wrote: >>>> Ana Krivokapic wrote: >>>>> On 04/19/2013 03:58 PM, Rob Crittenden wrote: >>>>>> Rob Crittenden wrote: >>>>>>> Ana Krivokapic wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Make sure /etc/ipa is created and owned by freeipa-python package. >>>>>>>> >>>>>>>> Report correct error to user if /etc/ipa is missing during client >>>>>>>> installation. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3551 >>>>>>> The server also owns this directory. It should only be owned by the >>>>>>> python subpackage. >>>>>>> >>>>>>> %dir %{_sysconfdir}/ipa >>>>>>> >>>>>>> rob >>>>>> The mode should probably be 0755. >>>>>> >>>>>> rob >>>>>> >>>>> Thanks, fixed. >>>>> >>>> ACK. pushed to master and ipa-3-1 >>>> >>>> rob >>>> >>> Hm, the spec change does not look right to me: >>> >>> +%dir %attr(0755,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ >>> >>> Why is the directory owned by group apache? Why does the directory have >>> "%config(noreplace)" set? Isn't it a NOOP when set for a directory (just asking)? >>> >>> This is what we get when we install freeipa-python now: >>> >>> # rm -r /etc/ipa/ >>> # rpm -Uvh --force >>> /home/mkosek/dist-master/rpms/freeipa-client-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm >>> /home/mkosek/dist-master/rpms/freeipa-python-3.2.0GIT2a8f1b0-0.fc18.x86_64.rpm >>> >>> # ll -d /etc/ipa/ >>> drwxr-xr-x. 2 root apache 4096 Apr 22 02:05 /etc/ipa/ >>> ^^^^^^ >>> Thanks, >>> Martin >> You are right, it was a mistake on my part. Attached is a oneliner fix. >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > I forgot to add link to the ticket to commit message. > > -- > Regards, > > Ana Krivokapic > Associate Software Engineer > FreeIPA team > Red Hat Inc. > ACK. Pushed to master, ipa-3-1. Martin From mkosek at redhat.com Mon Apr 22 11:34:07 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Apr 2013 13:34:07 +0200 Subject: [Freeipa-devel] Integration with the provisioning systems In-Reply-To: <51743A86.7090206@redhat.com> References: <51743A86.7090206@redhat.com> Message-ID: <5175202F.3020704@redhat.com> On 04/21/2013 09:14 PM, Dmitri Pal wrote: > Hello, > > Please review the design page for the following ticket: > https://fedorahosted.org/freeipa/ticket/3583 > http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > Hello Dmitri, The design looks fine, I would just like to discuss the schema enhancements. I'd propose to not create our own artificial attributes, but rather use a standard existing userClass attributeType defined in RFC 4524 which is already present in 389-ds schemas and which semantics seems to match what we want: ... 2.25. userClass The 'userClass' attribute specifies categories of computer or application user. The semantics placed on this attribute are for local interpretation. Examples of current usage of this attribute in academia are "student", "staff", and "faculty". Note that the 'organizationalStatus' attribute type is now often preferred, as it makes no distinction between persons as opposed to users. ( 0.9.2342.19200300.100.1.8 NAME 'userClass' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described in [RFC4517]. ... What about simply adding this attributeType as a MAY attribute for ipaHost objectClass? As for user objects, what about adding new auxiliary objectClass called ipaUser storing miscellaneous attributes like this one? Or is there a benefit of having a specialized objectClass holding just this one MAY attribute? Thanks, Martin From dpal at redhat.com Mon Apr 22 12:48:24 2013 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 22 Apr 2013 08:48:24 -0400 Subject: [Freeipa-devel] Integration with the provisioning systems In-Reply-To: <5175202F.3020704@redhat.com> References: <51743A86.7090206@redhat.com> <5175202F.3020704@redhat.com> Message-ID: <51753198.8050903@redhat.com> On 04/22/2013 07:34 AM, Martin Kosek wrote: > On 04/21/2013 09:14 PM, Dmitri Pal wrote: >> Hello, >> >> Please review the design page for the following ticket: >> https://fedorahosted.org/freeipa/ticket/3583 >> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >> > Hello Dmitri, > > The design looks fine, I would just like to discuss the schema enhancements. > > I'd propose to not create our own artificial attributes, but rather use a > standard existing userClass attributeType defined in RFC 4524 which is already > present in 389-ds schemas and which semantics seems to match what we want: > > ... > 2.25. userClass > > The 'userClass' attribute specifies categories of computer or > application user. The semantics placed on this attribute are for > local interpretation. Examples of current usage of this attribute in > academia are "student", "staff", and "faculty". Note that the > 'organizationalStatus' attribute type is now often preferred, as it > makes no distinction between persons as opposed to users. > > ( 0.9.2342.19200300.100.1.8 NAME 'userClass' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) I tried to find something like this but I did not see this attribute as a part of the object classes used for user accounts ("person" and derivatives). This would perfectly match the need and would not require a creation of the new attribute. Ack! > > The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the > 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described > in [RFC4517]. This is fine to. And it is MV which is good. > ... > > What about simply adding this attributeType as a MAY attribute for ipaHost > objectClass? I was thinking about this too but then we would have it in a bit asymmetric way. I am fine with that too. > > As for user objects, what about adding new auxiliary objectClass called ipaUser > storing miscellaneous attributes like this one? This is fine except this is much more intrusive. I was looking for a very simple, low cost fix that can be added with very limited impact. While creation of the ipaUser is probably the correct step it sounds a bit bigger than I want it to be for now. > > Or is there a benefit of having a specialized objectClass holding just this one > MAY attribute? No. So here is what I suggest: Split the ticket into two steps (tickets): Step 1: add the userClass attribute to ipaHost - do it now. That should be a very low impact change. Step 2: sort out the right class hierarchy for user - this is a candidate for next round of refactoring. Step 1 is the only requirement at the moment so let us go just for it. > > Thanks, > Martin -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jcholast at redhat.com Mon Apr 22 13:26:42 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 22 Apr 2013 15:26:42 +0200 Subject: [Freeipa-devel] [PATCH] 130 Drop support for OpenSSH versions before 6.2 In-Reply-To: <5171813C.10502@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> Message-ID: <51753A92.5020208@redhat.com> On 19.4.2013 19:39, Rob Crittenden wrote: > Jan Cholasta wrote: >> Also, this does not fix SSH integration not working on Fedora 18, as >> that is caused by backward incompatiblity in openssh-server-6.1p1-6 and >> later (see https://bugzilla.redhat.com/show_bug.cgi?id=953534). FYI this bug was fixed. > > This seems to work ok. Do we want to do this upgrade as an rpm scriptlet > or is it better to handle this in ipa-upgradeconfig (it might be easier > to maintain there)? As Martin pointed out, this needs to be done on the client and we don't have client upgrade script yet, hence the scriptlet. > > In any case, a condrestart of sssd is required to have it pick up the > new config. Fixed. > > Do you know if F-18 will get 6.2? Do we need to consider backporting > this to 3.1? It won't, backport is not needed. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-130.1-Drop-support-for-OpenSSH-versions-before-6.2.patch Type: text/x-patch Size: 3897 bytes Desc: not available URL: From mkosek at redhat.com Mon Apr 22 12:56:02 2013 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 22 Apr 2013 14:56:02 +0200 Subject: [Freeipa-devel] Integration with the provisioning systems In-Reply-To: <51753198.8050903@redhat.com> References: <51743A86.7090206@redhat.com> <5175202F.3020704@redhat.com> <51753198.8050903@redhat.com> Message-ID: <51753362.6010103@redhat.com> On 04/22/2013 02:48 PM, Dmitri Pal wrote: > On 04/22/2013 07:34 AM, Martin Kosek wrote: >> On 04/21/2013 09:14 PM, Dmitri Pal wrote: ... > So here is what I suggest: > Split the ticket into two steps (tickets): > Step 1: add the userClass attribute to ipaHost - do it now. That should > be a very low impact change. Yes, it should be just updating MAY list of ipaHost objectClass + adding a new param to FreeIPA host plugin. > Step 2: sort out the right class hierarchy for user - this is a > candidate for next round of refactoring. > > Step 1 is the only requirement at the moment so let us go just for it. Ok, fine by me. Lets wait a bit to see if there are any more comments to this design - if not, I will do the ticket work tomorrow morning. Martin From simo at redhat.com Mon Apr 22 13:42:19 2013 From: simo at redhat.com (Simo Sorce) Date: Mon, 22 Apr 2013 09:42:19 -0400 Subject: [Freeipa-devel] Integration with the provisioning systems In-Reply-To: <51753198.8050903@redhat.com> References: <51743A86.7090206@redhat.com> <5175202F.3020704@redhat.com> <51753198.8050903@redhat.com> Message-ID: <1366638139.2815.919.camel@willson.li.ssimo.org> On Mon, 2013-04-22 at 08:48 -0400, Dmitri Pal wrote: > On 04/22/2013 07:34 AM, Martin Kosek wrote: > > On 04/21/2013 09:14 PM, Dmitri Pal wrote: > >> Hello, > >> > >> Please review the design page for the following ticket: > >> https://fedorahosted.org/freeipa/ticket/3583 > >> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > >> > > Hello Dmitri, > > > > The design looks fine, I would just like to discuss the schema enhancements. > > > > I'd propose to not create our own artificial attributes, but rather use a > > standard existing userClass attributeType defined in RFC 4524 which is already > > present in 389-ds schemas and which semantics seems to match what we want: > > > > ... > > 2.25. userClass > > > > The 'userClass' attribute specifies categories of computer or > > application user. The semantics placed on this attribute are for > > local interpretation. Examples of current usage of this attribute in > > academia are "student", "staff", and "faculty". Note that the > > 'organizationalStatus' attribute type is now often preferred, as it > > makes no distinction between persons as opposed to users. > > > > ( 0.9.2342.19200300.100.1.8 NAME 'userClass' > > EQUALITY caseIgnoreMatch > > SUBSTR caseIgnoreSubstringsMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > I tried to find something like this but I did not see this attribute as > a part of the object classes used for user accounts ("person" and > derivatives). > This would perfectly match the need and would not require a creation of > the new attribute. > Ack! > > > > > The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the > > 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described > > in [RFC4517]. > > This is fine to. And it is MV which is good. > > > ... > > > > What about simply adding this attributeType as a MAY attribute for ipaHost > > objectClass? > > > I was thinking about this too but then we would have it in a bit > asymmetric way. > I am fine with that too. > > > > > As for user objects, what about adding new auxiliary objectClass called ipaUser > > storing miscellaneous attributes like this one? > > This is fine except this is much more intrusive. > I was looking for a very simple, low cost fix that can be added with > very limited impact. > While creation of the ipaUser is probably the correct step it sounds a > bit bigger than I want it to be for now. > > > > > Or is there a benefit of having a specialized objectClass holding just this one > > MAY attribute? > > > No. > > So here is what I suggest: > Split the ticket into two steps (tickets): > Step 1: add the userClass attribute to ipaHost - do it now. That should > be a very low impact change. > Step 2: sort out the right class hierarchy for user - this is a > candidate for next round of refactoring. > > Step 1 is the only requirement at the moment so let us go just for it. +1, go for it! Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Apr 22 13:54:26 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Apr 2013 09:54:26 -0400 Subject: [Freeipa-devel] Integration with the provisioning systems In-Reply-To: <1366638139.2815.919.camel@willson.li.ssimo.org> References: <51743A86.7090206@redhat.com> <5175202F.3020704@redhat.com> <51753198.8050903@redhat.com> <1366638139.2815.919.camel@willson.li.ssimo.org> Message-ID: <51754112.6050408@redhat.com> Simo Sorce wrote: > On Mon, 2013-04-22 at 08:48 -0400, Dmitri Pal wrote: >> On 04/22/2013 07:34 AM, Martin Kosek wrote: >>> On 04/21/2013 09:14 PM, Dmitri Pal wrote: >>>> Hello, >>>> >>>> Please review the design page for the following ticket: >>>> https://fedorahosted.org/freeipa/ticket/3583 >>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>> >>> Hello Dmitri, >>> >>> The design looks fine, I would just like to discuss the schema enhancements. >>> >>> I'd propose to not create our own artificial attributes, but rather use a >>> standard existing userClass attributeType defined in RFC 4524 which is already >>> present in 389-ds schemas and which semantics seems to match what we want: >>> >>> ... >>> 2.25. userClass >>> >>> The 'userClass' attribute specifies categories of computer or >>> application user. The semantics placed on this attribute are for >>> local interpretation. Examples of current usage of this attribute in >>> academia are "student", "staff", and "faculty". Note that the >>> 'organizationalStatus' attribute type is now often preferred, as it >>> makes no distinction between persons as opposed to users. >>> >>> ( 0.9.2342.19200300.100.1.8 NAME 'userClass' >>> EQUALITY caseIgnoreMatch >>> SUBSTR caseIgnoreSubstringsMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) >> >> I tried to find something like this but I did not see this attribute as >> a part of the object classes used for user accounts ("person" and >> derivatives). >> This would perfectly match the need and would not require a creation of >> the new attribute. >> Ack! >> >>> >>> The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the >>> 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described >>> in [RFC4517]. >> >> This is fine to. And it is MV which is good. >> >>> ... >>> >>> What about simply adding this attributeType as a MAY attribute for ipaHost >>> objectClass? >> >> >> I was thinking about this too but then we would have it in a bit >> asymmetric way. >> I am fine with that too. >> >>> >>> As for user objects, what about adding new auxiliary objectClass called ipaUser >>> storing miscellaneous attributes like this one? >> >> This is fine except this is much more intrusive. >> I was looking for a very simple, low cost fix that can be added with >> very limited impact. >> While creation of the ipaUser is probably the correct step it sounds a >> bit bigger than I want it to be for now. >> >>> >>> Or is there a benefit of having a specialized objectClass holding just this one >>> MAY attribute? >> >> >> No. >> >> So here is what I suggest: >> Split the ticket into two steps (tickets): >> Step 1: add the userClass attribute to ipaHost - do it now. That should >> be a very low impact change. >> Step 2: sort out the right class hierarchy for user - this is a >> candidate for next round of refactoring. >> >> Step 1 is the only requirement at the moment so let us go just for it. > > +1, go for it! > > Simo. > /aol rob From akrivoka at redhat.com Mon Apr 22 14:51:07 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Apr 2013 16:51:07 +0200 Subject: [Freeipa-devel] [PATCH] 0022 Do not display an interactive mode message in unattended mode Message-ID: <51754E5B.1090402@redhat.com> Do not display an interactive mode message in unattended mode https://fedorahosted.org/freeipa/ticket/3576 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0022-Do-not-display-an-interactive-mode-message-in-unatte.patch Type: text/x-patch Size: 1050 bytes Desc: not available URL: From akrivoka at redhat.com Mon Apr 22 15:12:38 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Apr 2013 17:12:38 +0200 Subject: [Freeipa-devel] [PATCH 0023 Do not display ports to open when password is incorrect during ipa-client-install Message-ID: <51755366.6090104@redhat.com> Do not display ports to open when password is incorrect during ipa-client-install https://fedorahosted.org/freeipa/ticket/3573 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0023-Do-not-display-ports-to-open-when-password-is-incorr.patch Type: text/x-patch Size: 1568 bytes Desc: not available URL: From pvoborni at redhat.com Mon Apr 22 16:54:54 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 22 Apr 2013 18:54:54 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review Message-ID: <51756B5E.8030604@redhat.com> Hello, Web UI refactoring is ready for review. Code is available at usual location: git://fedorapeople.org/~pvoborni/freeipa.git branch menu I would like to ask Endi and Ana to comment the design of Builder/Registry/Global registry/Providers. I will work with Ana and Varun on testing the stuff to avoid regressions. There are some remaining minor parts to be implemented (described below). They shouldn't block the review. The whole effort has 124 commits. They reflect the way how it was developed. Many of them could be squashed (mainly the ones with 'Builder:' prefix. Some, mostly fixes of issues found later, might be quite hard to squash. We should decide on some reasonable compromise to avoid spending a lot of time on squashing. Later this week I'll create design page for #3235 and update the one for #3236. The doc on http://pvoborni.fedorapeople.org/doc/ should also be updated to reflect new builder capabilities. Following text describes the work which was done since the last review (starting with 1440996d9466921178598289579f5dad031e4e54 Metadata and text providers commit) Main refactoring themes ----------------------- 1. Menu + application controller refactoring Was described in previous mails. #3235 2. Plugins support Also discussed. #3236 3. Make definitions of specification objects (specs) of entities, facets, widgets modifiable by plugins. No ticket, but supports both #3535 and #3236. a) Main complication is specification of objects not yet retrieved - mostly metadata and messages. Data providers were created to solve the issue. Providers expect string as an input and return related data. Provider logic is implemented in ./_base/Provider. Providers can be nestable so one provider can serve as access point for multiple provider. One should use ./_base/metadata_provider for obtaining metadata and ./text for strings. ./text also searches in metadata by using metadata_provider. All instances of IPA.metadata and IPA.messages were replaced by provider definitions. b) Second big issue was build of objects. Entities and facets have complex build logic. It can be simplified into three steps: 1) modifications of spec 2) creation of object and class inheritance 3) init logic Most of the ideas were implemented in previous part but the builder alone got new features to meet all requirements. The main features are post_ops and pre_ops. Pre_ops are operations, defined as functions, objects or diff objects which are executed/applied before creation of instance (calling ctor/factory). Their purpose is to modify spec object. They are similar to pre callbacks in ipa framework. Post_ops are operations executed after executing factory/constructor. Their purpose is to contain object's initialization logic. New Builder features: * distinguishes between framework(built) object and spec. Returns input if its not a spec. Allows to specify spec or built object in spec. * mass build when supplied array of specs * specify global pre/post_ops * factory, ctor defaults * support of two modes when spec is a simple string: 'type', 'property'. Default is 'type'. 'type' means that spec is a name of object type and builder should search construct registry. 'property' serves for simplifying spec eg: '{ name: 'uid' } -> 'uid'. This means that it heavily rely on builders defaults to supply correct factory/ctor. * overrides: allow to override builder defaults (factory, ctor, post_ops, pre_ops) * context - object supplied by caller which is passed to pre_ops and post_ops. Allows to define containers. New Construct registry features: * post_ops and pre_ops for types c) Web UI has several object types: entities, facets, widgets, fields, actions, validators, entity policies, facet policies. Each object type requires its builder, construct registry and some also singleton registry. Two umbrella pseudo-registries were created to avoid creating twice as many modules and also to allow redefinition of the registries: ./reg and ./builder. ./reg is a registry of construct registries or singleton registries. Difference between normal registry is that one can access its registries directly. ./builder is a registry of builders. Each object type may have its own builder with different defaults, pre_ops, post_ops and construct registry. Construct registry is usually the one registered in ./reg. Builder also serves as general build interface so one don't have to obtain the builder first: builder.build(object_type, spec, context, overrides) Builder can also be used for building objects without registered builders: builder.build('', spec, context, overrides) All modules should register their objects at registration phase. It defines a structure so one can expect when objects are registered and also one can do some changes to the spec in module before it is registered. Plugins containing and entity should have the spec prepared in a module property. So modules don't have to specify the object statically but they have to make sure that it will be static when the module is requested by other module (plugin). d) Modification of spec by diff object. Implemented in ./_base/Spec_mod module. Applied by builder. Was not thoroughly tested. One variant of pre_op. I would like to improve the concept in a future. Know problems & remaining work ------------------------------ 1. Change generation of plugin index to dynamical instead of rpm-post 2. Incorrect behavior (enabled buttons) of rule table when 'rule applies to anyone' selected. 3. delete ./facets module Use ./reg an ./builder instead. Incorporate it into router to support standalone facets. Design Questions ---------------- 1. Move ./_base/metadata_provider to ./metadata? Might simplify stuff. 2. Move actions/buttons spec from factories to pre_ops associated with the factories. Example of stuff to be moved (search.js): spec.actions = spec.actions || []; spec.actions.unshift( 'refresh', 'batch_remove', 'add'); It may simplify/allow removal of those items in spec or pre_ops of child factories. Currently there is no way how to intercept them. --- I hope that I didn't forget anything important. Thank you, -- Petr Vobornik From pviktori at redhat.com Mon Apr 22 17:30:13 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 22 Apr 2013 19:30:13 +0200 Subject: [Freeipa-devel] [PATCHES] 0218-0219 https://fedorahosted.org/freeipa/ticket/3578 Message-ID: <517573A5.4000109@redhat.com> Hello, These patches fix errors in our schema files. The syntax errors would prevent future versions of 389 from starting. I haven't done functional testing with development 389 versions, I'll get in touch with mreynolds for that. So don't push these yet. https://fedorahosted.org/freeipa/ticket/3578 -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0218-Fix-syntax-of-the-dc-attributeType.patch Type: text/x-patch Size: 3959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0219-Fix-syntax-errors-in-schema-files.patch Type: text/x-patch Size: 11577 bytes Desc: not available URL: From rcritten at redhat.com Mon Apr 22 18:22:24 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Apr 2013 14:22:24 -0400 Subject: [Freeipa-devel] [PATCH] 1096 handle gethostbyaddr() exceptions Message-ID: <51757FE0.80504@redhat.com> This was seen during the Test Day where a user had an empty /etc/resolv.conf and /etc/hosts. He was trying to set up IPA as the DNS server. By just logging this error we still handle it properly later, even with --no-host-dns. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1096-socket.patch Type: text/x-diff Size: 1316 bytes Desc: not available URL: From akrivoka at redhat.com Mon Apr 22 20:26:22 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 22 Apr 2013 22:26:22 +0200 Subject: [Freeipa-devel] [PATCH] 0024 Add missing permissions to Host Administrators privilege Message-ID: <51759CEE.9090504@redhat.com> The 'Host Administrators' privilege was missing two permissions ('Retrieve Certificates from the CA' and 'Revoke Certificate'), causing the inability to remove a host with a certificate. https://fedorahosted.org/freeipa/ticket/3585 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0024-Add-missing-permissions-to-Host-Administrators-privi.patch Type: text/x-patch Size: 1794 bytes Desc: not available URL: From rcritten at redhat.com Mon Apr 22 21:44:34 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Apr 2013 17:44:34 -0400 Subject: [Freeipa-devel] [PATCH] 0022 Do not display an interactive mode message in unattended mode In-Reply-To: <51754E5B.1090402@redhat.com> References: <51754E5B.1090402@redhat.com> Message-ID: <5175AF42.8060103@redhat.com> Ana Krivokapic wrote: > Do not display an interactive mode message in unattended mode > > https://fedorahosted.org/freeipa/ticket/3576 ACK From rcritten at redhat.com Mon Apr 22 22:06:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Apr 2013 18:06:05 -0400 Subject: [Freeipa-devel] [PATCH 0023 Do not display ports to open when password is incorrect during ipa-client-install In-Reply-To: <51755366.6090104@redhat.com> References: <51755366.6090104@redhat.com> Message-ID: <5175B44D.8080705@redhat.com> Ana Krivokapic wrote: > Do not display ports to open when password is incorrect during > ipa-client-install > > https://fedorahosted.org/freeipa/ticket/3573 > What happens if port 88 is not open so it can't connect to the KDC? I'm not sure how the best way to determine one vs the other, I don't think there are distinct return values. We could use the fact that Kerberos isn't translated to look for specific strings maybe, but that is hackish and could break. rob From mkosek at redhat.com Tue Apr 23 07:17:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Apr 2013 09:17:39 +0200 Subject: [Freeipa-devel] Integration with the provisioning systems In-Reply-To: <1366638139.2815.919.camel@willson.li.ssimo.org> References: <51743A86.7090206@redhat.com> <5175202F.3020704@redhat.com> <51753198.8050903@redhat.com> <1366638139.2815.919.camel@willson.li.ssimo.org> Message-ID: <51763593.9010605@redhat.com> On 04/22/2013 03:42 PM, Simo Sorce wrote: > On Mon, 2013-04-22 at 08:48 -0400, Dmitri Pal wrote: >> On 04/22/2013 07:34 AM, Martin Kosek wrote: >>> On 04/21/2013 09:14 PM, Dmitri Pal wrote: >>>> Hello, >>>> >>>> Please review the design page for the following ticket: >>>> https://fedorahosted.org/freeipa/ticket/3583 >>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>> >>> Hello Dmitri, >>> >>> The design looks fine, I would just like to discuss the schema enhancements. >>> >>> I'd propose to not create our own artificial attributes, but rather use a >>> standard existing userClass attributeType defined in RFC 4524 which is already >>> present in 389-ds schemas and which semantics seems to match what we want: >>> >>> ... >>> 2.25. userClass >>> >>> The 'userClass' attribute specifies categories of computer or >>> application user. The semantics placed on this attribute are for >>> local interpretation. Examples of current usage of this attribute in >>> academia are "student", "staff", and "faculty". Note that the >>> 'organizationalStatus' attribute type is now often preferred, as it >>> makes no distinction between persons as opposed to users. >>> >>> ( 0.9.2342.19200300.100.1.8 NAME 'userClass' >>> EQUALITY caseIgnoreMatch >>> SUBSTR caseIgnoreSubstringsMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) >> >> I tried to find something like this but I did not see this attribute as >> a part of the object classes used for user accounts ("person" and >> derivatives). >> This would perfectly match the need and would not require a creation of >> the new attribute. >> Ack! >> >>> >>> The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the >>> 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described >>> in [RFC4517]. >> >> This is fine to. And it is MV which is good. >> >>> ... >>> >>> What about simply adding this attributeType as a MAY attribute for ipaHost >>> objectClass? >> >> >> I was thinking about this too but then we would have it in a bit >> asymmetric way. >> I am fine with that too. >> >>> >>> As for user objects, what about adding new auxiliary objectClass called ipaUser >>> storing miscellaneous attributes like this one? >> >> This is fine except this is much more intrusive. >> I was looking for a very simple, low cost fix that can be added with >> very limited impact. >> While creation of the ipaUser is probably the correct step it sounds a >> bit bigger than I want it to be for now. >> >>> >>> Or is there a benefit of having a specialized objectClass holding just this one >>> MAY attribute? >> >> >> No. >> >> So here is what I suggest: >> Split the ticket into two steps (tickets): >> Step 1: add the userClass attribute to ipaHost - do it now. That should >> be a very low impact change. >> Step 2: sort out the right class hierarchy for user - this is a >> candidate for next round of refactoring. >> >> Step 1 is the only requirement at the moment so let us go just for it. > > +1, go for it! > > Simo. > Cool! I did the ticket work: Step 1: https://fedorahosted.org/freeipa/ticket/3583 Step 2: https://fedorahosted.org/freeipa/ticket/3588 Martin From mkosek at redhat.com Tue Apr 23 08:10:09 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Apr 2013 10:10:09 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts Message-ID: <517641E1.8080409@redhat.com> This new freeform host attribute will allow provisioning systems to add custom tags for host objects which can be later used for in automember rules or for additional local interpretation. Design page: http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems Ticket: https://fedorahosted.org/freeipa/ticket/3583 ----- This is how it can be used: # ipa hostgroup-add webservers Description: web servers ---------------------------- Added hostgroup "webservers" ---------------------------- Host-group: webservers Description: web servers # ipa automember-add --type=hostgroup webservers ---------------------------------- Added automember rule "webservers" ---------------------------------- Automember Rule: webservers # ipa automember-add-condition --key=userclass --type=hostgroup --inclusive-regex=^webserver webservers ---------------------------------- Added condition(s) to "webservers" ---------------------------------- Automember Rule: webservers Inclusive Regex: userclass=^webserver ---------------------------- Number of conditions added 1 ---------------------------- # ipa host-add web.example.com --force --class=webserver --class=mailserver ---------------------------- Added host "web.example.com" ---------------------------- Host name: web.example.com Principal name: host/web.example.com at EXAMPLE.COM Class: webserver, mailserver <<<<<<<<<< Password: False Member of host-groups: webservers <<<<<<<<<< Indirect Member of netgroup: webservers Keytab: False Managed by: web.example.com Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-402-add-userclass-attribute-for-hosts.patch Type: text/x-patch Size: 8813 bytes Desc: not available URL: From jcholast at redhat.com Tue Apr 23 08:35:38 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 23 Apr 2013 10:35:38 +0200 Subject: [Freeipa-devel] [PATCHES] 131-132 Add DNS records for existing masters when installing DNS for the first time Message-ID: <517647DA.5090207@redhat.com> Hi, the attached patches fix . Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-131-Add-DNS-records-for-existing-masters-when-installing.patch Type: text/x-patch Size: 8221 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-132-Add-ipa-ca-records-for-existing-CA-masters-when-inst.patch Type: text/x-patch Size: 3267 bytes Desc: not available URL: From akrivoka at redhat.com Tue Apr 23 10:17:41 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 23 Apr 2013 12:17:41 +0200 Subject: [Freeipa-devel] [PATCH 0023 Do not display ports to open when password is incorrect during ipa-client-install In-Reply-To: <5175B44D.8080705@redhat.com> References: <51755366.6090104@redhat.com> <5175B44D.8080705@redhat.com> Message-ID: <51765FC5.6030105@redhat.com> On 04/23/2013 12:06 AM, Rob Crittenden wrote: > Ana Krivokapic wrote: >> Do not display ports to open when password is incorrect during >> ipa-client-install >> >> https://fedorahosted.org/freeipa/ticket/3573 >> > > What happens if port 88 is not open so it can't connect to the KDC? > I'm not sure how the best way to determine one vs the other, I don't > think there are distinct return values. > > We could use the fact that Kerberos isn't translated to look for > specific strings maybe, but that is hackish and could break. > > rob The return value from kinit is always 1 in case of failure. So the only way to determine the reason for failure would be to look into the message string. I agree this is hackish as Rob pointed out. Personally, I am for leaving everything as it is now. In the case of incorrect password, the user _does_ get the message that the password was incorrect (kinit: Password incorrect while getting initial credentials). So I don't think that displaying the message about ports, in addition to this message, is confusing/misleading. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From mkosek at redhat.com Tue Apr 23 10:22:13 2013 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Apr 2013 12:22:13 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517641E1.8080409@redhat.com> References: <517641E1.8080409@redhat.com> Message-ID: <517660D5.3030204@redhat.com> On 04/23/2013 10:10 AM, Martin Kosek wrote: > This new freeform host attribute will allow provisioning systems > to add custom tags for host objects which can be later used for > in automember rules or for additional local interpretation. > > Design page: http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > Ticket: https://fedorahosted.org/freeipa/ticket/3583 > > ----- > > This is how it can be used: > > # ipa hostgroup-add webservers > Description: web servers > ---------------------------- > Added hostgroup "webservers" > ---------------------------- > Host-group: webservers > Description: web servers > > # ipa automember-add --type=hostgroup webservers > ---------------------------------- > Added automember rule "webservers" > ---------------------------------- > Automember Rule: webservers > > # ipa automember-add-condition --key=userclass --type=hostgroup > --inclusive-regex=^webserver webservers > ---------------------------------- > Added condition(s) to "webservers" > ---------------------------------- > Automember Rule: webservers > Inclusive Regex: userclass=^webserver > ---------------------------- > Number of conditions added 1 > ---------------------------- > > > > # ipa host-add web.example.com --force --class=webserver --class=mailserver > ---------------------------- > Added host "web.example.com" > ---------------------------- > Host name: web.example.com > Principal name: host/web.example.com at EXAMPLE.COM > Class: webserver, mailserver <<<<<<<<<< > Password: False > Member of host-groups: webservers <<<<<<<<<< > Indirect Member of netgroup: webservers > Keytab: False > Managed by: web.example.com > > > Martin > I just noticed that despite what the design page says, I implemented the new attribute both for host-add and host-mod commands. My thinking was that the attribute may have a general use and not just for the automember. Thus, I would not limit it to host-add only. Admins may want to change the attribute after the host was created (and then maybe also run the manual automember task computing the groups again). Martin From tbabej at redhat.com Tue Apr 23 10:25:08 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Apr 2013 12:25:08 +0200 Subject: [Freeipa-devel] [PATCH 0049] Avoid removing sss from nssswitch.conf during client uninstall Message-ID: <51766184.2050009@redhat.com> Hi, This patch makes sure that sss is not removed from nsswitch.conf which causes probles with later uses of sssd. Makes sure that authconfig with --disablesssd option is not executed during ipa client uninstall. https://fedorahosted.org/freeipa/ticket/3577 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0049-Avoid-removing-sss-from-nssswitch.conf-during-client.patch Type: text/x-patch Size: 1893 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 23 10:25:59 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Apr 2013 12:25:59 +0200 Subject: [Freeipa-devel] [PATCH 0050] Add hint message about --force-join option when enrollment fails Message-ID: <517661B7.90107@redhat.com> Hi, When client enrollment fails due to the fact that host entry already exists on the server, display an message informing the user about the possibility of using --force-join option. https://fedorahosted.org/freeipa/ticket/3572 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0050-Add-hint-message-about-force-join-option-when-enroll.patch Type: text/x-patch Size: 1511 bytes Desc: not available URL: From pvoborni at redhat.com Tue Apr 23 10:28:51 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 23 Apr 2013 12:28:51 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517660D5.3030204@redhat.com> References: <517641E1.8080409@redhat.com> <517660D5.3030204@redhat.com> Message-ID: <51766263.1020508@redhat.com> On 04/23/2013 12:22 PM, Martin Kosek wrote: > On 04/23/2013 10:10 AM, Martin Kosek wrote: >> This new freeform host attribute will allow provisioning systems >> to add custom tags for host objects which can be later used for >> in automember rules or for additional local interpretation. >> >> Design page: http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >> >> ----- >> >> This is how it can be used: >> >> # ipa hostgroup-add webservers >> Description: web servers >> ---------------------------- >> Added hostgroup "webservers" >> ---------------------------- >> Host-group: webservers >> Description: web servers >> >> # ipa automember-add --type=hostgroup webservers >> ---------------------------------- >> Added automember rule "webservers" >> ---------------------------------- >> Automember Rule: webservers >> >> # ipa automember-add-condition --key=userclass --type=hostgroup >> --inclusive-regex=^webserver webservers >> ---------------------------------- >> Added condition(s) to "webservers" >> ---------------------------------- >> Automember Rule: webservers >> Inclusive Regex: userclass=^webserver >> ---------------------------- >> Number of conditions added 1 >> ---------------------------- >> >> >> >> # ipa host-add web.example.com --force --class=webserver --class=mailserver >> ---------------------------- >> Added host "web.example.com" >> ---------------------------- >> Host name: web.example.com >> Principal name: host/web.example.com at EXAMPLE.COM >> Class: webserver, mailserver <<<<<<<<<< >> Password: False >> Member of host-groups: webservers <<<<<<<<<< >> Indirect Member of netgroup: webservers >> Keytab: False >> Managed by: web.example.com >> >> >> Martin >> > > I just noticed that despite what the design page says, I implemented the new > attribute both for host-add and host-mod commands. > > My thinking was that the attribute may have a general use and not just for the > automember. Thus, I would not limit it to host-add only. Admins may want to > change the attribute after the host was created (and then maybe also run the > manual automember task computing the groups again). > > Martin Which raises UI questions: 1) Do we want to add the class attrs to user and host adder dialogs? (to allow automember to kick in) 2) Do we want to add the attrs to user and host details pages? (to keep CLI and UI in sync) -- Petr Vobornik From tbabej at redhat.com Tue Apr 23 10:28:55 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Apr 2013 12:28:55 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf Message-ID: <51766267.8040504@redhat.com> Hi, We should respect already configured options present in /etc/openldap/ldap.conf when generating our own configuration. With this patch, we only rewrite URI, BASE and TLS_CACERT options. https://fedorahosted.org/freeipa/ticket/3582 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0051-Perserve-already-configured-options-in-openldap-conf.patch Type: text/x-patch Size: 2157 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 23 10:51:18 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Apr 2013 12:51:18 +0200 Subject: [Freeipa-devel] [PATCHES] 0218-0219 https://fedorahosted.org/freeipa/ticket/3578 In-Reply-To: <517573A5.4000109@redhat.com> References: <517573A5.4000109@redhat.com> Message-ID: <517667A6.5040705@redhat.com> On 04/22/2013 07:30 PM, Petr Viktorin wrote: > Hello, > > These patches fix errors in our schema files. The syntax errors would > prevent future versions of 389 from starting. > > I haven't done functional testing with development 389 versions, I'll > get in touch with mreynolds for that. So don't push these yet. > > https://fedorahosted.org/freeipa/ticket/3578 > Another syntax issue was in the updates, attaching an additional fix. Testing RPMs are available at http://fedorapeople.org/~pviktori/rpms/freeipa-3fd3e61/ -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0220-Fix-schema-syntax-in-update-file.patch Type: text/x-patch Size: 2111 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 23 11:23:52 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Apr 2013 13:23:52 +0200 Subject: [Freeipa-devel] [PATCH 0049] Avoid removing sss from nssswitch.conf during client uninstall In-Reply-To: <51766184.2050009@redhat.com> References: <51766184.2050009@redhat.com> Message-ID: <51766F48.10207@redhat.com> On 04/23/2013 12:25 PM, Tomas Babej wrote: > Hi, > > This patch makes sure that sss is not removed from nsswitch.conf > which causes probles with later uses of sssd. Makes sure that > authconfig with --disablesssd option is not executed during > ipa client uninstall. > > https://fedorahosted.org/freeipa/ticket/3577 > > Tomas This works well, ACK. I would also link to the bug in a comment to help people reading the code in the future -- it's not immediately clear why 'sssd' is excluded. But that's probably nitpicking too much. -- Petr? From pviktori at redhat.com Tue Apr 23 11:35:03 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Apr 2013 13:35:03 +0200 Subject: [Freeipa-devel] [PATCH 0050] Add hint message about --force-join option when enrollment fails In-Reply-To: <517661B7.90107@redhat.com> References: <517661B7.90107@redhat.com> Message-ID: <517671E7.6040205@redhat.com> On 04/23/2013 12:25 PM, Tomas Babej wrote: > Hi, > > When client enrollment fails due to the fact that host entry > already exists on the server, display an message informing the > user about the possibility of using --force-join option. > > https://fedorahosted.org/freeipa/ticket/3572 > > Tomas ACK -- Petr? From tbabej at redhat.com Tue Apr 23 12:02:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Apr 2013 14:02:20 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <5166CA4A.1080903@redhat.com> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> <5166B224.8070601@redhat.com> <1365688766.2845.13.camel@willson.li.ssimo.org> <5166CA4A.1080903@redhat.com> Message-ID: <5176784C.1060707@redhat.com> On 04/11/2013 04:35 PM, Petr Viktorin wrote: > On 04/11/2013 03:59 PM, Simo Sorce wrote: >> On Thu, 2013-04-11 at 14:52 +0200, Petr Viktorin wrote: >>> On 04/11/2013 02:43 PM, Simo Sorce wrote: >>>> On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: >>>>> On 04/11/2013 12:05 PM, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> Makes DNAME target validation less strict and allows underscore. >>>>>> This is requirement for IPA sites. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3550 >>>>>> >>>>>> Tomas >>>>> >>>>> I checked with Petr?, and he said it would make sense to also enable >>>>> underscores for the other records types. >>>>> For records other than TXT, SRV, DNAME, and NSEC we could warn if >>>>> underscores are used, but that's probably not worth the trouble -- >>>>> just >>>>> allowing underscores everywhere is fine. >>>>> >>>> >>>> Underscores are invalid DNS characters, they should not be allowed >>>> for A >>>> records, only for DNAME, and SRV records IMO. >>> >>> Technically, they're invalid *hostname* characters; in DNS itself >>> anything goes. >>> >>> Interestingly, we already allow them for A records: >>> $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com _bogus --a-rec=1.2.3.4 >>> Record name: _bogus >>> A record: 1.2.3.4 >>> >>> But this ticket is not about the record name, it's about record data >>> (i.e. the *target* of the DNAME). >> >> So we are restricting record *data* but *not* record names ? That's ... >> odd. > > Yes. Apparently we relaxed the name validation because underscores are > used in AD or other exotic/nonstandard setups, and now we need to > relax the data validation as well. > > I filed a ticket to add warnings for underscores in A records: > https://fedorahosted.org/freeipa/ticket/3557 > > Sorry for letting this rot on the list, I thought I sent the patch already. Patchwork saved me this time. Here's the updated patch. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0047-2-Allow-underscore-in-record-targets.patch Type: text/x-patch Size: 3106 bytes Desc: not available URL: From tbabej at redhat.com Tue Apr 23 12:11:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 23 Apr 2013 14:11:52 +0200 Subject: [Freeipa-devel] [PATCH 0049] Avoid removing sss from nssswitch.conf during client uninstall In-Reply-To: <51766F48.10207@redhat.com> References: <51766184.2050009@redhat.com> <51766F48.10207@redhat.com> Message-ID: <51767A88.9090109@redhat.com> On 04/23/2013 01:23 PM, Petr Viktorin wrote: > On 04/23/2013 12:25 PM, Tomas Babej wrote: >> Hi, >> >> This patch makes sure that sss is not removed from nsswitch.conf >> which causes probles with later uses of sssd. Makes sure that >> authconfig with --disablesssd option is not executed during >> ipa client uninstall. >> >> https://fedorahosted.org/freeipa/ticket/3577 >> >> Tomas > > This works well, ACK. > > I would also link to the bug in a comment to help people reading the > code in the future -- it's not immediately clear why 'sssd' is > excluded. But that's probably nitpicking too much. > Not at all, I'm all for readability. Updated patch attached, no functional changes. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0049-2-Avoid-removing-sss-from-nssswitch.conf-during-client.patch Type: text/x-patch Size: 2320 bytes Desc: not available URL: From dpal at redhat.com Tue Apr 23 15:27:29 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 23 Apr 2013 11:27:29 -0400 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <51766263.1020508@redhat.com> References: <517641E1.8080409@redhat.com> <517660D5.3030204@redhat.com> <51766263.1020508@redhat.com> Message-ID: <5176A861.9080602@redhat.com> On 04/23/2013 06:28 AM, Petr Vobornik wrote: > On 04/23/2013 12:22 PM, Martin Kosek wrote: >> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>> This new freeform host attribute will allow provisioning systems >>> to add custom tags for host objects which can be later used for >>> in automember rules or for additional local interpretation. >>> >>> Design page: >>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>> >>> ----- >>> >>> This is how it can be used: >>> >>> # ipa hostgroup-add webservers >>> Description: web servers >>> ---------------------------- >>> Added hostgroup "webservers" >>> ---------------------------- >>> Host-group: webservers >>> Description: web servers >>> >>> # ipa automember-add --type=hostgroup webservers >>> ---------------------------------- >>> Added automember rule "webservers" >>> ---------------------------------- >>> Automember Rule: webservers >>> >>> # ipa automember-add-condition --key=userclass --type=hostgroup >>> --inclusive-regex=^webserver webservers >>> ---------------------------------- >>> Added condition(s) to "webservers" >>> ---------------------------------- >>> Automember Rule: webservers >>> Inclusive Regex: userclass=^webserver >>> ---------------------------- >>> Number of conditions added 1 >>> ---------------------------- >>> >>> >>> >>> # ipa host-add web.example.com --force --class=webserver >>> --class=mailserver >>> ---------------------------- >>> Added host "web.example.com" >>> ---------------------------- >>> Host name: web.example.com >>> Principal name: host/web.example.com at EXAMPLE.COM >>> Class: webserver, mailserver <<<<<<<<<< >>> Password: False >>> Member of host-groups: webservers <<<<<<<<<< >>> Indirect Member of netgroup: webservers >>> Keytab: False >>> Managed by: web.example.com >>> >>> >>> Martin >>> >> >> I just noticed that despite what the design page says, I implemented >> the new >> attribute both for host-add and host-mod commands. >> >> My thinking was that the attribute may have a general use and not >> just for the >> automember. Thus, I would not limit it to host-add only. Admins may >> want to >> change the attribute after the host was created (and then maybe also >> run the >> manual automember task computing the groups again). >> >> Martin > > Which raises UI questions: > > 1) Do we want to add the class attrs to user and host adder dialogs? > (to allow automember to kick in) > > 2) Do we want to add the attrs to user and host details pages? (to > keep CLI and UI in sync) > The minimal requirement was just to do it on the addition. I think we need two separate patches. It is probably OK to do it in schema and addition because this we will backport to earlier version while modify operation + UI can be left till later (I mean done now but not ported back). -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pviktori at redhat.com Tue Apr 23 15:50:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Apr 2013 17:50:42 +0200 Subject: [Freeipa-devel] [PATCHES] 131-132 Add DNS records for existing masters when installing DNS for the first time In-Reply-To: <517647DA.5090207@redhat.com> References: <517647DA.5090207@redhat.com> Message-ID: <5176ADD2.4050507@redhat.com> On 04/23/2013 10:35 AM, Jan Cholasta wrote: > Hi, > > the attached patches fix . > > Honza > Works well for me, ACK. -- Petr? From pviktori at redhat.com Tue Apr 23 16:47:25 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Apr 2013 18:47:25 +0200 Subject: [Freeipa-devel] [PATCH 0049] Avoid removing sss from nssswitch.conf during client uninstall In-Reply-To: <51767A88.9090109@redhat.com> References: <51766184.2050009@redhat.com> <51766F48.10207@redhat.com> <51767A88.9090109@redhat.com> Message-ID: <5176BB1D.3090408@redhat.com> On 04/23/2013 02:11 PM, Tomas Babej wrote: > On 04/23/2013 01:23 PM, Petr Viktorin wrote: >> On 04/23/2013 12:25 PM, Tomas Babej wrote: >>> Hi, >>> >>> This patch makes sure that sss is not removed from nsswitch.conf >>> which causes probles with later uses of sssd. Makes sure that >>> authconfig with --disablesssd option is not executed during >>> ipa client uninstall. >>> >>> https://fedorahosted.org/freeipa/ticket/3577 >>> >>> Tomas >> >> This works well, ACK. >> >> I would also link to the bug in a comment to help people reading the >> code in the future -- it's not immediately clear why 'sssd' is >> excluded. But that's probably nitpicking too much. >> > Not at all, I'm all for readability. Updated patch attached, no > functional changes. > > Tomas ACK, thanks. -- Petr? From pviktori at redhat.com Tue Apr 23 17:01:52 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 23 Apr 2013 19:01:52 +0200 Subject: [Freeipa-devel] [PATCHES] 0218-0219 Fix syntax errors in schema files In-Reply-To: <517667A6.5040705@redhat.com> References: <517573A5.4000109@redhat.com> <517667A6.5040705@redhat.com> Message-ID: <5176BE80.7060807@redhat.com> On 04/23/2013 12:51 PM, Petr Viktorin wrote: > On 04/22/2013 07:30 PM, Petr Viktorin wrote: >> Hello, >> >> These patches fix errors in our schema files. The syntax errors would >> prevent future versions of 389 from starting. >> >> I haven't done functional testing with development 389 versions, I'll >> get in touch with mreynolds for that. So don't push these yet. >> >> https://fedorahosted.org/freeipa/ticket/3578 >> > > > Another syntax issue was in the updates, attaching an additional fix. > > Testing RPMs are available at > http://fedorapeople.org/~pviktori/rpms/freeipa-3fd3e61/ The new DS finds no more syntax errors, so the patches are ready for review. I've squashed 0220 in, the full batch is attached. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0218.2-Fix-syntax-of-the-dc-attributeType.patch Type: text/x-patch Size: 3959 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0219.2-Fix-syntax-errors-in-schema-files.patch Type: text/x-patch Size: 13461 bytes Desc: not available URL: From rcritten at redhat.com Tue Apr 23 20:12:32 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Apr 2013 16:12:32 -0400 Subject: [Freeipa-devel] [PATCH 0050] Add hint message about --force-join option when enrollment fails In-Reply-To: <517671E7.6040205@redhat.com> References: <517661B7.90107@redhat.com> <517671E7.6040205@redhat.com> Message-ID: <5176EB30.6040703@redhat.com> Petr Viktorin wrote: > On 04/23/2013 12:25 PM, Tomas Babej wrote: >> Hi, >> >> When client enrollment fails due to the fact that host entry >> already exists on the server, display an message informing the >> user about the possibility of using --force-join option. >> >> https://fedorahosted.org/freeipa/ticket/3572 >> >> Tomas > > ACK > > pushed to master From rcritten at redhat.com Tue Apr 23 20:15:05 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Apr 2013 16:15:05 -0400 Subject: [Freeipa-devel] [PATCH 0049] Avoid removing sss from nssswitch.conf during client uninstall In-Reply-To: <5176BB1D.3090408@redhat.com> References: <51766184.2050009@redhat.com> <51766F48.10207@redhat.com> <51767A88.9090109@redhat.com> <5176BB1D.3090408@redhat.com> Message-ID: <5176EBC9.9080507@redhat.com> Petr Viktorin wrote: > On 04/23/2013 02:11 PM, Tomas Babej wrote: >> On 04/23/2013 01:23 PM, Petr Viktorin wrote: >>> On 04/23/2013 12:25 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> This patch makes sure that sss is not removed from nsswitch.conf >>>> which causes probles with later uses of sssd. Makes sure that >>>> authconfig with --disablesssd option is not executed during >>>> ipa client uninstall. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3577 >>>> >>>> Tomas >>> >>> This works well, ACK. >>> >>> I would also link to the bug in a comment to help people reading the >>> code in the future -- it's not immediately clear why 'sssd' is >>> excluded. But that's probably nitpicking too much. >>> >> Not at all, I'm all for readability. Updated patch attached, no >> functional changes. >> >> Tomas > > ACK, thanks. > pushed to master From mkosek at redhat.com Wed Apr 24 06:25:38 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Apr 2013 08:25:38 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <5176A861.9080602@redhat.com> References: <517641E1.8080409@redhat.com> <517660D5.3030204@redhat.com> <51766263.1020508@redhat.com> <5176A861.9080602@redhat.com> Message-ID: <51777AE2.4010002@redhat.com> On 04/23/2013 05:27 PM, Dmitri Pal wrote: > On 04/23/2013 06:28 AM, Petr Vobornik wrote: >> On 04/23/2013 12:22 PM, Martin Kosek wrote: >>> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>>> This new freeform host attribute will allow provisioning systems >>>> to add custom tags for host objects which can be later used for >>>> in automember rules or for additional local interpretation. >>>> >>>> Design page: >>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>>> >>>> ----- >>>> >>>> This is how it can be used: >>>> >>>> # ipa hostgroup-add webservers >>>> Description: web servers >>>> ---------------------------- >>>> Added hostgroup "webservers" >>>> ---------------------------- >>>> Host-group: webservers >>>> Description: web servers >>>> >>>> # ipa automember-add --type=hostgroup webservers >>>> ---------------------------------- >>>> Added automember rule "webservers" >>>> ---------------------------------- >>>> Automember Rule: webservers >>>> >>>> # ipa automember-add-condition --key=userclass --type=hostgroup >>>> --inclusive-regex=^webserver webservers >>>> ---------------------------------- >>>> Added condition(s) to "webservers" >>>> ---------------------------------- >>>> Automember Rule: webservers >>>> Inclusive Regex: userclass=^webserver >>>> ---------------------------- >>>> Number of conditions added 1 >>>> ---------------------------- >>>> >>>> >>>> >>>> # ipa host-add web.example.com --force --class=webserver >>>> --class=mailserver >>>> ---------------------------- >>>> Added host "web.example.com" >>>> ---------------------------- >>>> Host name: web.example.com >>>> Principal name: host/web.example.com at EXAMPLE.COM >>>> Class: webserver, mailserver <<<<<<<<<< >>>> Password: False >>>> Member of host-groups: webservers <<<<<<<<<< >>>> Indirect Member of netgroup: webservers >>>> Keytab: False >>>> Managed by: web.example.com >>>> >>>> >>>> Martin >>>> >>> >>> I just noticed that despite what the design page says, I implemented >>> the new >>> attribute both for host-add and host-mod commands. >>> >>> My thinking was that the attribute may have a general use and not >>> just for the >>> automember. Thus, I would not limit it to host-add only. Admins may >>> want to >>> change the attribute after the host was created (and then maybe also >>> run the >>> manual automember task computing the groups again). >>> >>> Martin >> >> Which raises UI questions: >> >> 1) Do we want to add the class attrs to user and host adder dialogs? >> (to allow automember to kick in) >> >> 2) Do we want to add the attrs to user and host details pages? (to >> keep CLI and UI in sync) >> > > The minimal requirement was just to do it on the addition. > I think we need two separate patches. As for CLI part, presence in host-mod comes for free (making it show just for host-add is actually harder, we need to add a special flag). I would leave it there to make this attribute more general unless there is a hard requirement for reverse. > It is probably OK to do it in schema and addition because this we will > backport to earlier version while modify operation + UI can be left till > later (I mean done now but not ported back). Ok, the UI does not have to be necessarily backported. Martin From jcholast at redhat.com Wed Apr 24 11:28:58 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Apr 2013 13:28:58 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <51766267.8040504@redhat.com> References: <51766267.8040504@redhat.com> Message-ID: <5177C1FA.4030005@redhat.com> Hi, On 23.4.2013 12:28, Tomas Babej wrote: > Hi, > > We should respect already configured options present in > /etc/openldap/ldap.conf when generating our own configuration. > With this patch, we only rewrite URI, BASE and TLS_CACERT options. > > https://fedorahosted.org/freeipa/ticket/3582 > the changeConf call will fail when the file does not exist, we might want to handle that gracefully. Honza -- Jan Cholasta From mkosek at redhat.com Wed Apr 24 12:39:20 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Apr 2013 14:39:20 +0200 Subject: [Freeipa-devel] [PATCHES] 131-132 Add DNS records for existing masters when installing DNS for the first time In-Reply-To: <5176ADD2.4050507@redhat.com> References: <517647DA.5090207@redhat.com> <5176ADD2.4050507@redhat.com> Message-ID: <5177D278.3020509@redhat.com> On 04/23/2013 05:50 PM, Petr Viktorin wrote: > On 04/23/2013 10:35 AM, Jan Cholasta wrote: >> Hi, >> >> the attached patches fix . >> >> Honza >> > > Works well for me, ACK. Pushed to master. Martin From rcritten at redhat.com Wed Apr 24 12:51:50 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Apr 2013 08:51:50 -0400 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <5177C1FA.4030005@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> Message-ID: <5177D566.1090005@redhat.com> Jan Cholasta wrote: > Hi, > > On 23.4.2013 12:28, Tomas Babej wrote: >> Hi, >> >> We should respect already configured options present in >> /etc/openldap/ldap.conf when generating our own configuration. >> With this patch, we only rewrite URI, BASE and TLS_CACERT options. >> >> https://fedorahosted.org/freeipa/ticket/3582 >> > > the changeConf call will fail when the file does not exist, we might > want to handle that gracefully. > > Honza > We also need to handle the case where these items are already defined. I'm honestly not sure what the behavior should be: overwrite, warn and overwrite, fail. rob From mkosek at redhat.com Wed Apr 24 12:54:52 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Apr 2013 14:54:52 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <5177D566.1090005@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> Message-ID: <5177D61C.2070407@redhat.com> On 04/24/2013 02:51 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> On 23.4.2013 12:28, Tomas Babej wrote: >>> Hi, >>> >>> We should respect already configured options present in >>> /etc/openldap/ldap.conf when generating our own configuration. >>> With this patch, we only rewrite URI, BASE and TLS_CACERT options. >>> >>> https://fedorahosted.org/freeipa/ticket/3582 >>> >> >> the changeConf call will fail when the file does not exist, we might >> want to handle that gracefully. >> >> Honza >> > > We also need to handle the case where these items are already defined. I'm > honestly not sure what the behavior should be: overwrite, warn and overwrite, > fail. > > rob > I am also thinking that we may want to be more cautious before updating this file. AFAIK, we do not need the updated file for our function, its only updated for user convenience so that he can run ldapsearches more easily. I see several options here that could help this goal: 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these options are not set. If the options are already set, we could just print a note that we skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has these options commented out, so it should be possible to implement this check. 2) Do ldap.conf changes only if a new special option is passe (e.g. --configure-ldap-cong) 3) Do not update ldap.conf when a new special option is not passed (e.g. --no-ldap-conf Martin From tbabej at redhat.com Wed Apr 24 13:07:03 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 24 Apr 2013 15:07:03 +0200 Subject: [Freeipa-devel] [PATCH 0052] Make gecos field editable in Web UI Message-ID: <5177D8F7.6050007@redhat.com> Hi, This patch exposes user entry gecos field in Web UI. https://fedorahosted.org/freeipa/ticket/3569 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0052-Make-gecos-field-editable-in-Web-UI.patch Type: text/x-patch Size: 977 bytes Desc: not available URL: From jcholast at redhat.com Wed Apr 24 13:11:11 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 24 Apr 2013 15:11:11 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <5177D61C.2070407@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> Message-ID: <5177D9EF.1080005@redhat.com> On 24.4.2013 14:54, Martin Kosek wrote: > On 04/24/2013 02:51 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> On 23.4.2013 12:28, Tomas Babej wrote: >>>> Hi, >>>> >>>> We should respect already configured options present in >>>> /etc/openldap/ldap.conf when generating our own configuration. >>>> With this patch, we only rewrite URI, BASE and TLS_CACERT options. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3582 >>>> >>> >>> the changeConf call will fail when the file does not exist, we might >>> want to handle that gracefully. >>> >>> Honza >>> >> >> We also need to handle the case where these items are already defined. I'm >> honestly not sure what the behavior should be: overwrite, warn and overwrite, >> fail. >> >> rob >> > > I am also thinking that we may want to be more cautious before updating this > file. AFAIK, we do not need the updated file for our function, its only updated > for user convenience so that he can run ldapsearches more easily. > > I see several options here that could help this goal: > 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these options are > not set. If the options are already set, we could just print a note that we > skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has these options > commented out, so it should be possible to implement this check. > > 2) Do ldap.conf changes only if a new special option is passe (e.g. > --configure-ldap-cong) > > 3) Do not update ldap.conf when a new special option is not passed (e.g. > --no-ldap-conf > > Martin > If we don't need the file for our function, we can just not configure it at all IMO. We can document how to configure it for users who want it. Honza -- Jan Cholasta From mkosek at redhat.com Wed Apr 24 13:30:42 2013 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 24 Apr 2013 15:30:42 +0200 Subject: [Freeipa-devel] [PATCH] 1096 handle gethostbyaddr() exceptions In-Reply-To: <51757FE0.80504@redhat.com> References: <51757FE0.80504@redhat.com> Message-ID: <5177DE82.2040605@redhat.com> On 04/22/2013 08:22 PM, Rob Crittenden wrote: > This was seen during the Test Day where a user had an empty /etc/resolv.conf > and /etc/hosts. He was trying to set up IPA as the DNS server. > > By just logging this error we still handle it properly later, even with > --no-host-dns. > > rob > ACK. Pushed to master, ipa-3-1. Martin From tbabej at redhat.com Wed Apr 24 12:58:44 2013 From: tbabej at redhat.com (Tomas Babej) Date: Wed, 24 Apr 2013 14:58:44 +0200 Subject: [Freeipa-devel] [PATCH] 0024 Add missing permissions to Host Administrators privilege In-Reply-To: <51759CEE.9090504@redhat.com> References: <51759CEE.9090504@redhat.com> Message-ID: <5177D704.6090402@redhat.com> On 04/22/2013 10:26 PM, Ana Krivokapic wrote: > The 'Host Administrators' privilege was missing two permissions > ('Retrieve Certificates from the CA' and 'Revoke Certificate'), causing > the inability to remove a host with a certificate. > > https://fedorahosted.org/freeipa/ticket/3585 > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Tomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From pvoborni at redhat.com Wed Apr 24 14:55:21 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Apr 2013 16:55:21 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <51756B5E.8030604@redhat.com> References: <51756B5E.8030604@redhat.com> Message-ID: <5177F259.4060100@redhat.com> I've implemented the remaining work. Pushed to the private repo. > Know problems & remaining work > ------------------------------ > 1. Change generation of plugin index to dynamical instead of rpm-post The plugin index (plugins.js) is generated by wsgi script. New dir was created: /usr/share/ipa/wsgi to store the script. It has the same attributes as migration dir. Plugins.js should be located in /usr/share/ipa/ui/js/freeipa/ dir. New rewrite rule was added in order to make it work. It has a nice side effect that one could not find out that the file is dynamically generated. Design page updated accordingly: http://www.freeipa.org/page/V3/WebUI_plugins > > 2. Incorrect behavior (enabled buttons) of rule table when 'rule applies > to anyone' selected. Fixed by creating updated event. Probably not caused by this refactoring but by refactoring of checkboxes and radios for PAC patch. > > 3. delete ./facets module > Use ./reg an ./builder instead. Incorporate it into router to support > standalone facets. Done, but not tested. I'll create plugin example to test it. -- Petr Vobornik From abokovoy at redhat.com Wed Apr 24 16:03:18 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 24 Apr 2013 19:03:18 +0300 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <5177F259.4060100@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> Message-ID: <20130424160318.GM6823@redhat.com> On Wed, 24 Apr 2013, Petr Vobornik wrote: >I've implemented the remaining work. Pushed to the private repo. > >>Know problems & remaining work >>------------------------------ >>1. Change generation of plugin index to dynamical instead of rpm-post > >The plugin index (plugins.js) is generated by wsgi script. New dir >was created: /usr/share/ipa/wsgi to store the script. It has the same >attributes as migration dir. >Plugins.js should be located in /usr/share/ipa/ui/js/freeipa/ dir. >New rewrite rule was added in order to make it work. It has a nice >side effect that one could not find out that the file is dynamically >generated. 1. We should not elevate privileges to wsgi script. Instead, one could do plugin list regeneration by running pre-start script in ipa systemd unit. Alternatively, we can add ipa-js-plugins.service unit that is run one-off and is required by ipa.service. 2. /usr/share/ipa/wsgi is wrong. In long term Fedora is moving to make /usr/share read-only. I'd rather moved it to /var/cache/ipa/wsgi. wsgi process already knows how to reach to /var/cache/ipa/sessions so we are good from SELinux perspective as well. -- / Alexander Bokovoy From pvoborni at redhat.com Wed Apr 24 16:28:50 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 24 Apr 2013 18:28:50 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <20130424160318.GM6823@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <20130424160318.GM6823@redhat.com> Message-ID: <51780842.7000206@redhat.com> On 04/24/2013 06:03 PM, Alexander Bokovoy wrote: > On Wed, 24 Apr 2013, Petr Vobornik wrote: >> I've implemented the remaining work. Pushed to the private repo. >> >>> Know problems & remaining work >>> ------------------------------ >>> 1. Change generation of plugin index to dynamical instead of rpm-post >> >> The plugin index (plugins.js) is generated by wsgi script. New dir was >> created: /usr/share/ipa/wsgi to store the script. It has the same >> attributes as migration dir. >> Plugins.js should be located in /usr/share/ipa/ui/js/freeipa/ dir. New >> rewrite rule was added in order to make it work. It has a nice side >> effect that one could not find out that the file is dynamically >> generated. > 1. We should not elevate privileges to wsgi script. Instead, one could > do plugin list regeneration by running pre-start script in ipa systemd > unit. Alternatively, we can add ipa-js-plugins.service unit that is run > one-off and is required by ipa.service. > > 2. /usr/share/ipa/wsgi is wrong. In long term Fedora is moving to make > /usr/share read-only. > > I'd rather moved it to /var/cache/ipa/wsgi. wsgi process already knows > how to reach to /var/cache/ipa/sessions so we are good from SELinux > perspective as well. > The wsgi script doesn't write anything. It just reads a content of /usr/share/ipa/ui/js/plugins directory, transforms it into JS AMD module with one array and returns it as an application/javascript http response. My inspiration was /ipa/migration/migration.py. The difference is that plugins.py reads dir and migration.py communicates with LDAP through ipalib. Is the reading of dir content also problematic? -- Petr Vobornik From abokovoy at redhat.com Wed Apr 24 16:45:23 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 24 Apr 2013 19:45:23 +0300 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <51780842.7000206@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <20130424160318.GM6823@redhat.com> <51780842.7000206@redhat.com> Message-ID: <20130424164523.GN6823@redhat.com> On Wed, 24 Apr 2013, Petr Vobornik wrote: >On 04/24/2013 06:03 PM, Alexander Bokovoy wrote: >>On Wed, 24 Apr 2013, Petr Vobornik wrote: >>>I've implemented the remaining work. Pushed to the private repo. >>> >>>>Know problems & remaining work >>>>------------------------------ >>>>1. Change generation of plugin index to dynamical instead of rpm-post >>> >>>The plugin index (plugins.js) is generated by wsgi script. New dir was >>>created: /usr/share/ipa/wsgi to store the script. It has the same >>>attributes as migration dir. >>>Plugins.js should be located in /usr/share/ipa/ui/js/freeipa/ dir. New >>>rewrite rule was added in order to make it work. It has a nice side >>>effect that one could not find out that the file is dynamically >>>generated. >>1. We should not elevate privileges to wsgi script. Instead, one could >>do plugin list regeneration by running pre-start script in ipa systemd >>unit. Alternatively, we can add ipa-js-plugins.service unit that is run >>one-off and is required by ipa.service. >> >>2. /usr/share/ipa/wsgi is wrong. In long term Fedora is moving to make >>/usr/share read-only. >> >>I'd rather moved it to /var/cache/ipa/wsgi. wsgi process already knows >>how to reach to /var/cache/ipa/sessions so we are good from SELinux >>perspective as well. >> > >The wsgi script doesn't write anything. It just reads a content of >/usr/share/ipa/ui/js/plugins directory, transforms it into JS AMD >module with one array and returns it as an application/javascript >http response. Sorry, I've missed this part when looking through the code. This approach is good then -- we don't modify anything on the file system, only read. > >My inspiration was /ipa/migration/migration.py. The difference is >that plugins.py reads dir and migration.py communicates with LDAP >through ipalib. > >Is the reading of dir content also problematic? That is completely fine -- after all serving those .js files implies httpd_context_t being able to read them. Sorry for false alarm! -- / Alexander Bokovoy From rcritten at redhat.com Wed Apr 24 17:37:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Apr 2013 13:37:13 -0400 Subject: [Freeipa-devel] [PATCH] 0022 Do not display an interactive mode message in unattended mode In-Reply-To: <5175AF42.8060103@redhat.com> References: <51754E5B.1090402@redhat.com> <5175AF42.8060103@redhat.com> Message-ID: <51781849.1030200@redhat.com> Rob Crittenden wrote: > Ana Krivokapic wrote: >> Do not display an interactive mode message in unattended mode >> >> https://fedorahosted.org/freeipa/ticket/3576 > > ACK pushed to master From rcritten at redhat.com Wed Apr 24 18:02:54 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Apr 2013 14:02:54 -0400 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <5177D9EF.1080005@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> Message-ID: <51781E4E.4020203@redhat.com> Jan Cholasta wrote: > On 24.4.2013 14:54, Martin Kosek wrote: >> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> We should respect already configured options present in >>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT options. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>> >>>> >>>> the changeConf call will fail when the file does not exist, we might >>>> want to handle that gracefully. >>>> >>>> Honza >>>> >>> >>> We also need to handle the case where these items are already >>> defined. I'm >>> honestly not sure what the behavior should be: overwrite, warn and >>> overwrite, >>> fail. >>> >>> rob >>> >> >> I am also thinking that we may want to be more cautious before >> updating this >> file. AFAIK, we do not need the updated file for our function, its >> only updated >> for user convenience so that he can run ldapsearches more easily. >> >> I see several options here that could help this goal: >> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >> options are >> not set. If the options are already set, we could just print a note >> that we >> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >> these options >> commented out, so it should be possible to implement this check. >> >> 2) Do ldap.conf changes only if a new special option is passe (e.g. >> --configure-ldap-cong) >> >> 3) Do not update ldap.conf when a new special option is not passed (e.g. >> --no-ldap-conf >> >> Martin >> > > If we don't need the file for our function, we can just not configure it > at all IMO. We can document how to configure it for users who want it. It was an RFE that we create this file. It is handy to have pre-configured, I like having it actually. We just need to try to have a gentler touch than my first crack at it, which overwrote it completely. I think #1 is probably enough for now. I'm not sure I want to add two new options this late in the game, and the client already has a lot of knobs. rob From rcritten at redhat.com Wed Apr 24 18:37:13 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Apr 2013 14:37:13 -0400 Subject: [Freeipa-devel] [PATCH] 0024 Add missing permissions to Host Administrators privilege In-Reply-To: <5177D704.6090402@redhat.com> References: <51759CEE.9090504@redhat.com> <5177D704.6090402@redhat.com> Message-ID: <51782659.5060809@redhat.com> Tomas Babej wrote: > On 04/22/2013 10:26 PM, Ana Krivokapic wrote: >> The 'Host Administrators' privilege was missing two permissions >> ('Retrieve Certificates from the CA' and 'Revoke Certificate'), causing >> the inability to remove a host with a certificate. >> >> https://fedorahosted.org/freeipa/ticket/3585 >> >> >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > ACK. > > Tomas Pushed to ipa-3-1 and master From mkosek at redhat.com Thu Apr 25 06:51:39 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Apr 2013 08:51:39 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <51781E4E.4020203@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> Message-ID: <5178D27B.6060402@redhat.com> On 04/24/2013 08:02 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 24.4.2013 14:54, Martin Kosek wrote: >>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>> Hi, >>>>>> >>>>>> We should respect already configured options present in >>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT options. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>> >>>>> >>>>> the changeConf call will fail when the file does not exist, we might >>>>> want to handle that gracefully. >>>>> >>>>> Honza >>>>> >>>> >>>> We also need to handle the case where these items are already >>>> defined. I'm >>>> honestly not sure what the behavior should be: overwrite, warn and >>>> overwrite, >>>> fail. >>>> >>>> rob >>>> >>> >>> I am also thinking that we may want to be more cautious before >>> updating this >>> file. AFAIK, we do not need the updated file for our function, its >>> only updated >>> for user convenience so that he can run ldapsearches more easily. >>> >>> I see several options here that could help this goal: >>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>> options are >>> not set. If the options are already set, we could just print a note >>> that we >>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>> these options >>> commented out, so it should be possible to implement this check. >>> >>> 2) Do ldap.conf changes only if a new special option is passe (e.g. >>> --configure-ldap-cong) >>> >>> 3) Do not update ldap.conf when a new special option is not passed (e.g. >>> --no-ldap-conf >>> >>> Martin >>> >> >> If we don't need the file for our function, we can just not configure it >> at all IMO. We can document how to configure it for users who want it. > > It was an RFE that we create this file. It is handy to have pre-configured, I > like having it actually. > > We just need to try to have a gentler touch than my first crack at it, which > overwrote it completely. I think #1 is probably enough for now. I'm not sure I > want to add two new options this late in the game, and the client already has a > lot of knobs. > > rob > Yeah, I also agree that 1) is enough. It will not add any more options and will let us be more gentle and respectful to already existent custom user settings in ldap.conf. So Tomas, this seems like the way to go :-) Martin From pviktori at redhat.com Thu Apr 25 10:03:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Apr 2013 12:03:17 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <5176784C.1060707@redhat.com> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> <5166B224.8070601@redhat.com> <1365688766.2845.13.camel@willson.li.ssimo.org> <5166CA4A.1080903@redhat.com> <5176784C.1060707@redhat.com> Message-ID: <5178FF65.1020302@redhat.com> On 04/23/2013 02:02 PM, Tomas Babej wrote: > On 04/11/2013 04:35 PM, Petr Viktorin wrote: >> On 04/11/2013 03:59 PM, Simo Sorce wrote: >>> On Thu, 2013-04-11 at 14:52 +0200, Petr Viktorin wrote: >>>> On 04/11/2013 02:43 PM, Simo Sorce wrote: >>>>> On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: >>>>>> On 04/11/2013 12:05 PM, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Makes DNAME target validation less strict and allows underscore. >>>>>>> This is requirement for IPA sites. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3550 >>>>>>> >>>>>>> Tomas >>>>>> >>>>>> I checked with Petr?, and he said it would make sense to also enable >>>>>> underscores for the other records types. >>>>>> For records other than TXT, SRV, DNAME, and NSEC we could warn if >>>>>> underscores are used, but that's probably not worth the trouble -- >>>>>> just >>>>>> allowing underscores everywhere is fine. >>>>>> >>>>> >>>>> Underscores are invalid DNS characters, they should not be allowed >>>>> for A >>>>> records, only for DNAME, and SRV records IMO. >>>> >>>> Technically, they're invalid *hostname* characters; in DNS itself >>>> anything goes. >>>> >>>> Interestingly, we already allow them for A records: >>>> $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com _bogus --a-rec=1.2.3.4 >>>> Record name: _bogus >>>> A record: 1.2.3.4 >>>> >>>> But this ticket is not about the record name, it's about record data >>>> (i.e. the *target* of the DNAME). >>> >>> So we are restricting record *data* but *not* record names ? That's ... >>> odd. >> >> Yes. Apparently we relaxed the name validation because underscores are >> used in AD or other exotic/nonstandard setups, and now we need to >> relax the data validation as well. >> >> I filed a ticket to add warnings for underscores in A records: >> https://fedorahosted.org/freeipa/ticket/3557 >> >> > Sorry for letting this rot on the list, I thought I sent the patch > already. Patchwork saved me this time. > > Here's the updated patch. > > Tomas ACK -- Petr? From jcholast at redhat.com Thu Apr 25 10:29:34 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 25 Apr 2013 12:29:34 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <5178D27B.6060402@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> Message-ID: <5179058E.7050306@redhat.com> On 25.4.2013 08:51, Martin Kosek wrote: > On 04/24/2013 08:02 PM, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> On 24.4.2013 14:54, Martin Kosek wrote: >>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> Hi, >>>>>> >>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>> Hi, >>>>>>> >>>>>>> We should respect already configured options present in >>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT options. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>> >>>>>> >>>>>> the changeConf call will fail when the file does not exist, we might >>>>>> want to handle that gracefully. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>>> We also need to handle the case where these items are already >>>>> defined. I'm >>>>> honestly not sure what the behavior should be: overwrite, warn and >>>>> overwrite, >>>>> fail. >>>>> >>>>> rob >>>>> >>>> >>>> I am also thinking that we may want to be more cautious before >>>> updating this >>>> file. AFAIK, we do not need the updated file for our function, its >>>> only updated >>>> for user convenience so that he can run ldapsearches more easily. >>>> >>>> I see several options here that could help this goal: >>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>> options are >>>> not set. If the options are already set, we could just print a note >>>> that we >>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>> these options >>>> commented out, so it should be possible to implement this check. >>>> >>>> 2) Do ldap.conf changes only if a new special option is passe (e.g. >>>> --configure-ldap-cong) >>>> >>>> 3) Do not update ldap.conf when a new special option is not passed (e.g. >>>> --no-ldap-conf >>>> >>>> Martin >>>> >>> >>> If we don't need the file for our function, we can just not configure it >>> at all IMO. We can document how to configure it for users who want it. >> >> It was an RFE that we create this file. It is handy to have pre-configured, I >> like having it actually. >> >> We just need to try to have a gentler touch than my first crack at it, which >> overwrote it completely. I think #1 is probably enough for now. I'm not sure I >> want to add two new options this late in the game, and the client already has a >> lot of knobs. >> >> rob >> > > Yeah, I also agree that 1) is enough. It will not add any more options and will > let us be more gentle and respectful to already existent custom user settings > in ldap.conf. So Tomas, this seems like the way to go :-) > > Martin > I don't see the point of updating only some of these values. What about 4) Update BASE and URI and TLS_CACERT, comment any old settings out. ? Honza -- Jan Cholasta From pviktori at redhat.com Thu Apr 25 10:37:17 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 25 Apr 2013 12:37:17 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517641E1.8080409@redhat.com> References: <517641E1.8080409@redhat.com> Message-ID: <5179075D.1050304@redhat.com> On 04/23/2013 10:10 AM, Martin Kosek wrote: > This new freeform host attribute will allow provisioning systems > to add custom tags for host objects which can be later used for > in automember rules or for additional local interpretation. > > Design page: http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems > Ticket: https://fedorahosted.org/freeipa/ticket/3583 > > ----- > > This is how it can be used: > > # ipa hostgroup-add webservers > Description: web servers > ---------------------------- > Added hostgroup "webservers" > ---------------------------- > Host-group: webservers > Description: web servers > > # ipa automember-add --type=hostgroup webservers > ---------------------------------- > Added automember rule "webservers" > ---------------------------------- > Automember Rule: webservers > > # ipa automember-add-condition --key=userclass --type=hostgroup > --inclusive-regex=^webserver webservers > ---------------------------------- > Added condition(s) to "webservers" > ---------------------------------- > Automember Rule: webservers > Inclusive Regex: userclass=^webserver > ---------------------------- > Number of conditions added 1 > ---------------------------- > > > > # ipa host-add web.example.com --force --class=webserver --class=mailserver > ---------------------------- > Added host "web.example.com" > ---------------------------- > Host name: web.example.com > Principal name: host/web.example.com at EXAMPLE.COM > Class: webserver, mailserver <<<<<<<<<< > Password: False > Member of host-groups: webservers <<<<<<<<<< > Indirect Member of netgroup: webservers > Keytab: False > Managed by: web.example.com > > > Martin > I was surprised to find that host-show doesn't show it by default. Is there a reason to not put userclass in default_attributes? Please add a test. -- Petr? From mkosek at redhat.com Thu Apr 25 10:42:58 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Apr 2013 12:42:58 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <5179058E.7050306@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> <5179058E.7050306@redhat.com> Message-ID: <517908B2.8000002@redhat.com> On 04/25/2013 12:29 PM, Jan Cholasta wrote: > On 25.4.2013 08:51, Martin Kosek wrote: >> On 04/24/2013 08:02 PM, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> On 24.4.2013 14:54, Martin Kosek wrote: >>>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> We should respect already configured options present in >>>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT options. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>>> >>>>>>> >>>>>>> the changeConf call will fail when the file does not exist, we might >>>>>>> want to handle that gracefully. >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> We also need to handle the case where these items are already >>>>>> defined. I'm >>>>>> honestly not sure what the behavior should be: overwrite, warn and >>>>>> overwrite, >>>>>> fail. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> I am also thinking that we may want to be more cautious before >>>>> updating this >>>>> file. AFAIK, we do not need the updated file for our function, its >>>>> only updated >>>>> for user convenience so that he can run ldapsearches more easily. >>>>> >>>>> I see several options here that could help this goal: >>>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>>> options are >>>>> not set. If the options are already set, we could just print a note >>>>> that we >>>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>>> these options >>>>> commented out, so it should be possible to implement this check. >>>>> >>>>> 2) Do ldap.conf changes only if a new special option is passe (e.g. >>>>> --configure-ldap-cong) >>>>> >>>>> 3) Do not update ldap.conf when a new special option is not passed (e.g. >>>>> --no-ldap-conf >>>>> >>>>> Martin >>>>> >>>> >>>> If we don't need the file for our function, we can just not configure it >>>> at all IMO. We can document how to configure it for users who want it. >>> >>> It was an RFE that we create this file. It is handy to have pre-configured, I >>> like having it actually. >>> >>> We just need to try to have a gentler touch than my first crack at it, which >>> overwrote it completely. I think #1 is probably enough for now. I'm not sure I >>> want to add two new options this late in the game, and the client already has a >>> lot of knobs. >>> >>> rob >>> >> >> Yeah, I also agree that 1) is enough. It will not add any more options and will >> let us be more gentle and respectful to already existent custom user settings >> in ldap.conf. So Tomas, this seems like the way to go :-) >> >> Martin >> > > I don't see the point of updating only some of these values. What about Not some of them - either all of them (BASE, URI, TLS_CACERT) when none of them is already configured or none at all. > > 4) Update BASE and URI and TLS_CACERT, comment any old settings out. > > ? This would still break an existing user configuration, we would just tell user what we broke :-) Martin > > Honza > From mkosek at redhat.com Thu Apr 25 10:54:24 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Apr 2013 12:54:24 +0200 Subject: [Freeipa-devel] [PATCH 0047] Allow underscore in DNAME targets In-Reply-To: <5178FF65.1020302@redhat.com> References: <51668AD1.5000600@redhat.com> <5166AB97.9010705@redhat.com> <1365684224.2845.0.camel@willson.li.ssimo.org> <5166B224.8070601@redhat.com> <1365688766.2845.13.camel@willson.li.ssimo.org> <5166CA4A.1080903@redhat.com> <5176784C.1060707@redhat.com> <5178FF65.1020302@redhat.com> Message-ID: <51790B60.7020007@redhat.com> On 04/25/2013 12:03 PM, Petr Viktorin wrote: > On 04/23/2013 02:02 PM, Tomas Babej wrote: >> On 04/11/2013 04:35 PM, Petr Viktorin wrote: >>> On 04/11/2013 03:59 PM, Simo Sorce wrote: >>>> On Thu, 2013-04-11 at 14:52 +0200, Petr Viktorin wrote: >>>>> On 04/11/2013 02:43 PM, Simo Sorce wrote: >>>>>> On Thu, 2013-04-11 at 14:24 +0200, Petr Viktorin wrote: >>>>>>> On 04/11/2013 12:05 PM, Tomas Babej wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Makes DNAME target validation less strict and allows underscore. >>>>>>>> This is requirement for IPA sites. >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3550 >>>>>>>> >>>>>>>> Tomas >>>>>>> >>>>>>> I checked with Petr?, and he said it would make sense to also enable >>>>>>> underscores for the other records types. >>>>>>> For records other than TXT, SRV, DNAME, and NSEC we could warn if >>>>>>> underscores are used, but that's probably not worth the trouble -- >>>>>>> just >>>>>>> allowing underscores everywhere is fine. >>>>>>> >>>>>> >>>>>> Underscores are invalid DNS characters, they should not be allowed >>>>>> for A >>>>>> records, only for DNAME, and SRV records IMO. >>>>> >>>>> Technically, they're invalid *hostname* characters; in DNS itself >>>>> anything goes. >>>>> >>>>> Interestingly, we already allow them for A records: >>>>> $ ipa dnsrecord-add idm.lab.eng.brq.redhat.com _bogus --a-rec=1.2.3.4 >>>>> Record name: _bogus >>>>> A record: 1.2.3.4 >>>>> >>>>> But this ticket is not about the record name, it's about record data >>>>> (i.e. the *target* of the DNAME). >>>> >>>> So we are restricting record *data* but *not* record names ? That's ... >>>> odd. >>> >>> Yes. Apparently we relaxed the name validation because underscores are >>> used in AD or other exotic/nonstandard setups, and now we need to >>> relax the data validation as well. >>> >>> I filed a ticket to add warnings for underscores in A records: >>> https://fedorahosted.org/freeipa/ticket/3557 >>> >>> >> Sorry for letting this rot on the list, I thought I sent the patch >> already. Patchwork saved me this time. >> >> Here's the updated patch. >> >> Tomas > > ACK > Pushed to master, ipa-3-1 (rebased). Martin From mkosek at redhat.com Thu Apr 25 13:54:44 2013 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 25 Apr 2013 15:54:44 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <5179075D.1050304@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> Message-ID: <517935A4.5070803@redhat.com> On 04/25/2013 12:37 PM, Petr Viktorin wrote: > On 04/23/2013 10:10 AM, Martin Kosek wrote: >> This new freeform host attribute will allow provisioning systems >> to add custom tags for host objects which can be later used for >> in automember rules or for additional local interpretation. >> >> Design page: >> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >> >> ----- >> >> This is how it can be used: >> >> # ipa hostgroup-add webservers >> Description: web servers >> ---------------------------- >> Added hostgroup "webservers" >> ---------------------------- >> Host-group: webservers >> Description: web servers >> >> # ipa automember-add --type=hostgroup webservers >> ---------------------------------- >> Added automember rule "webservers" >> ---------------------------------- >> Automember Rule: webservers >> >> # ipa automember-add-condition --key=userclass --type=hostgroup >> --inclusive-regex=^webserver webservers >> ---------------------------------- >> Added condition(s) to "webservers" >> ---------------------------------- >> Automember Rule: webservers >> Inclusive Regex: userclass=^webserver >> ---------------------------- >> Number of conditions added 1 >> ---------------------------- >> >> >> >> # ipa host-add web.example.com --force --class=webserver --class=mailserver >> ---------------------------- >> Added host "web.example.com" >> ---------------------------- >> Host name: web.example.com >> Principal name: host/web.example.com at EXAMPLE.COM >> Class: webserver, mailserver <<<<<<<<<< >> Password: False >> Member of host-groups: webservers <<<<<<<<<< >> Indirect Member of netgroup: webservers >> Keytab: False >> Managed by: web.example.com >> >> >> Martin >> > > I was surprised to find that host-show doesn't show it by default. Is there a > reason to not put userclass in default_attributes? > > Please add a test. > Fixed. Updated patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-402-2-add-userclass-attribute-for-hosts.patch Type: text/x-patch Size: 11104 bytes Desc: not available URL: From pvoborni at redhat.com Thu Apr 25 15:28:02 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 25 Apr 2013 17:28:02 +0200 Subject: [Freeipa-devel] [PATCH 0052] Make gecos field editable in Web UI In-Reply-To: <5177D8F7.6050007@redhat.com> References: <5177D8F7.6050007@redhat.com> Message-ID: <51794B82.8030406@redhat.com> On 04/24/2013 03:07 PM, Tomas Babej wrote: > Hi, > > This patch exposes user entry gecos field in Web UI. > > https://fedorahosted.org/freeipa/ticket/3569 > > Tomas > ACK, pushed to master. -- Petr Vobornik From dpal at redhat.com Thu Apr 25 16:59:23 2013 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 25 Apr 2013 12:59:23 -0400 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517935A4.5070803@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> Message-ID: <517960EB.8030201@redhat.com> On 04/25/2013 09:54 AM, Martin Kosek wrote: > On 04/25/2013 12:37 PM, Petr Viktorin wrote: >> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>> This new freeform host attribute will allow provisioning systems >>> to add custom tags for host objects which can be later used for >>> in automember rules or for additional local interpretation. >>> >>> Design page: >>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>> >>> ----- >>> >>> This is how it can be used: >>> >>> # ipa hostgroup-add webservers >>> Description: web servers >>> ---------------------------- >>> Added hostgroup "webservers" >>> ---------------------------- >>> Host-group: webservers >>> Description: web servers >>> >>> # ipa automember-add --type=hostgroup webservers >>> ---------------------------------- >>> Added automember rule "webservers" >>> ---------------------------------- >>> Automember Rule: webservers >>> >>> # ipa automember-add-condition --key=userclass --type=hostgroup >>> --inclusive-regex=^webserver webservers >>> ---------------------------------- >>> Added condition(s) to "webservers" >>> ---------------------------------- >>> Automember Rule: webservers >>> Inclusive Regex: userclass=^webserver >>> ---------------------------- >>> Number of conditions added 1 >>> ---------------------------- >>> >>> >>> >>> # ipa host-add web.example.com --force --class=webserver >>> --class=mailserver >>> ---------------------------- >>> Added host "web.example.com" >>> ---------------------------- >>> Host name: web.example.com >>> Principal name: host/web.example.com at EXAMPLE.COM >>> Class: webserver, mailserver <<<<<<<<<< >>> Password: False >>> Member of host-groups: webservers <<<<<<<<<< >>> Indirect Member of netgroup: webservers >>> Keytab: False >>> Managed by: web.example.com >>> >>> >>> Martin >>> >> >> I was surprised to find that host-show doesn't show it by default. Is >> there a >> reason to not put userclass in default_attributes? >> >> Please add a test. >> > > Fixed. Updated patch attached. > > Martin > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Can we use this patch to create a HOWTO on how to add and LDAP attribute to IPA? Also we have, I suspect a lot of metadata about attributes encoded in the framework, right? Why can't we use some kind of the data file(s) for it? This way one can add attributes dynamically and the framework would pick them up. It is clear that it would have to be done on all replicas but still it would not require people to change the code - only configuration. Have we ever thought about this? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From akrivoka at redhat.com Thu Apr 25 16:37:58 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Thu, 25 Apr 2013 18:37:58 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <5177F259.4060100@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> Message-ID: <51795BE6.9090405@redhat.com> On 04/24/2013 04:55 PM, Petr Vobornik wrote: > I've implemented the remaining work. Pushed to the private repo. > >> Know problems & remaining work >> ------------------------------ >> 1. Change generation of plugin index to dynamical instead of rpm-post > > The plugin index (plugins.js) is generated by wsgi script. New dir was > created: /usr/share/ipa/wsgi to store the script. It has the same > attributes as migration dir. > Plugins.js should be located in /usr/share/ipa/ui/js/freeipa/ dir. New > rewrite rule was added in order to make it work. It has a nice side > effect that one could not find out that the file is dynamically > generated. > > Design page updated accordingly: > http://www.freeipa.org/page/V3/WebUI_plugins > >> >> 2. Incorrect behavior (enabled buttons) of rule table when 'rule applies >> to anyone' selected. > > Fixed by creating updated event. Probably not caused by this > refactoring but by refactoring of checkboxes and radios for PAC patch. > >> >> 3. delete ./facets module >> Use ./reg an ./builder instead. Incorporate it into router to support >> standalone facets. > > Done, but not tested. I'll create plugin example to test it. Hi, While reviewing and testing the new UI changes, I have encountered the following issues. (Some of them may be unrelated to the webUI refactoring effort, but I will list them here just so we are aware of them.) 1) When in self service mode, you are now allowed to go to pages of related objects. If you go to e.g. User Groups for your user, there are Add/Delete buttons and they are enabled, but if you try to use them, you will be denied access. However, a message will appear, saying 'Items added' / 'Items removed' even though the operation had failed. Should we disable these options in self service mode? I think we should at least make sure that the misleading message which suggests that the actions was completed, does not appear. 2) This one was already discussed with Petr in person: Runtime error on invalid URL: https://ipahost/ipa/ui/#/e/doesnotexist will give an ugly runtime error and any further navigation does not get rid of this error - you have to reload the page. We should make sure that this is handled more gracefully. 3) Role Based Access Control, when trying to add a permission to a privilege: * Permissions which are already in that privilege appear in the list of available permissions. They should not appear there (it doesn't make sense to add something which is already there). (This behavior is correct in other parts of UI, e.g. when you want add a privilege to a role, the privileges which are already present for that role, do not appear in the list of available privileges.) * When you try to add such permission, first an Operations Error appears, but when you click OK, a message saying 'Items added' appears (similar issue is mentioned in 1) ). 4) Host Based Access Control: When modifying a HBAC rule, workflow can be a bit confusing. For example, if you have a rule with 'Anyone' selected in the 'WHO' section, then you decide to change it to Specified Users and Groups, and then click on Add to add users/groups, a dialog appears requiring you to save your selection first (you have to click on Update, or click Cancel, then Update the changes and then try to Add users again). Is it possible to call the Update when Add is clicked, so that this step is automatically performed, requiring no action from the user? I think it would feel more intuitive to the user. 5) For sections that have Expand All/Collapse All link (for example, when looking at a user's details page), I think that when you expand all sections manually, the Expand All link should change to Collapse all. And also the other way around: when you collapse all sections manually, the Collapse All link should change to Expand All. This is probably nitpicking too much, it is just a nice to have (does not make sense to 'expand all' if everything is already expanded). -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. From pviktori at redhat.com Fri Apr 26 10:15:46 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Apr 2013 12:15:46 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517935A4.5070803@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> Message-ID: <517A53D2.20009@redhat.com> On 04/25/2013 03:54 PM, Martin Kosek wrote: > On 04/25/2013 12:37 PM, Petr Viktorin wrote: >> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>> This new freeform host attribute will allow provisioning systems >>> to add custom tags for host objects which can be later used for >>> in automember rules or for additional local interpretation. >>> >>> Design page: >>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>> >>> ----- >>> >>> This is how it can be used: >>> >>> # ipa hostgroup-add webservers >>> Description: web servers >>> ---------------------------- >>> Added hostgroup "webservers" >>> ---------------------------- >>> Host-group: webservers >>> Description: web servers >>> >>> # ipa automember-add --type=hostgroup webservers >>> ---------------------------------- >>> Added automember rule "webservers" >>> ---------------------------------- >>> Automember Rule: webservers >>> >>> # ipa automember-add-condition --key=userclass --type=hostgroup >>> --inclusive-regex=^webserver webservers >>> ---------------------------------- >>> Added condition(s) to "webservers" >>> ---------------------------------- >>> Automember Rule: webservers >>> Inclusive Regex: userclass=^webserver >>> ---------------------------- >>> Number of conditions added 1 >>> ---------------------------- >>> >>> >>> >>> # ipa host-add web.example.com --force --class=webserver >>> --class=mailserver >>> ---------------------------- >>> Added host "web.example.com" >>> ---------------------------- >>> Host name: web.example.com >>> Principal name: host/web.example.com at EXAMPLE.COM >>> Class: webserver, mailserver <<<<<<<<<< >>> Password: False >>> Member of host-groups: webservers <<<<<<<<<< >>> Indirect Member of netgroup: webservers >>> Keytab: False >>> Managed by: web.example.com >>> >>> >>> Martin >>> >> >> I was surprised to find that host-show doesn't show it by default. Is >> there a >> reason to not put userclass in default_attributes? >> >> Please add a test. >> > > Fixed. Updated patch attached. > > Martin ACK -- Petr? From pviktori at redhat.com Fri Apr 26 10:47:36 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Apr 2013 12:47:36 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517960EB.8030201@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> <517960EB.8030201@redhat.com> Message-ID: <517A5B48.9080208@redhat.com> On 04/25/2013 06:59 PM, Dmitri Pal wrote: > On 04/25/2013 09:54 AM, Martin Kosek wrote: >> On 04/25/2013 12:37 PM, Petr Viktorin wrote: >>> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>>> This new freeform host attribute will allow provisioning systems >>>> to add custom tags for host objects which can be later used for >>>> in automember rules or for additional local interpretation. >>>> >>>> Design page: >>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>>> [...] > > Can we use this patch to create a HOWTO on how to add and LDAP attribute > to IPA? Yes, I can annotate the patch and put it on the wiki. I'll do it once it's pushed so I can link to it. I know we're trying to organize the wiki page names. What's the correct location for a developer-focused HOWTO? > Also we have, I suspect a lot of metadata about attributes encoded in > the framework, right? > Why can't we use some kind of the data file(s) for it? This way one can > add attributes dynamically and the framework would pick them up. > It is clear that it would have to be done on all replicas So we should store it in LDAP and have it replicated. > but still it > would not require people to change the code - only configuration. Have > we ever thought about this? If you're talking about parameters in the the framework commands, I think --setattr is fine. Or is this also about the schema? Web UI? -- Petr? From pvoborni at redhat.com Fri Apr 26 10:51:40 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Apr 2013 12:51:40 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <51795BE6.9090405@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <51795BE6.9090405@redhat.com> Message-ID: <517A5C3C.4010005@redhat.com> On 04/25/2013 06:37 PM, Ana Krivokapic wrote: > > Hi, > > While reviewing and testing the new UI changes, I have encountered the > following issues. (Some of them may be unrelated to the webUI > refactoring effort, but I will list them here just so we are aware of them.) Thanks for review, I will fix regressions today. We might open a ticket for the rest. > > 1) When in self service mode, you are now allowed to go to pages of > related objects. If you go to e.g. User Groups for your user, there are > Add/Delete buttons and they are enabled, but if you try to use them, you > will be denied access. However, a message will appear, saying 'Items > added' / 'Items removed' even though the operation had failed. Should we > disable these options in self service mode? I think we should at least > make sure that the misleading message which suggests that the actions > was completed, does not appear. Regression. Links should not be clickable and buttons should be hidden. > > 2) This one was already discussed with Petr in person: Runtime error on > invalid URL: https://ipahost/ipa/ui/#/e/doesnotexist will give an ugly > runtime error and any further navigation does not get rid of this error > - you have to reload the page. We should make sure that this is handled > more gracefully. > Kind of regression. I will fix it by redirecting to default facet (user search). > 3) Role Based Access Control, when trying to add a permission to a > privilege: > * Permissions which are already in that privilege appear in the list of > available permissions. They should not appear there (it doesn't make > sense to add something which is already there). (This behavior is > correct in other parts of UI, e.g. when you want add a privilege to a > role, the privileges which are already present for that role, do not > appear in the list of available privileges.) > * When you try to add such permission, first an Operations Error > appears, but when you click OK, a message saying 'Items added' appears > (similar issue is mentioned in 1) ). Not related to refactoring. a) permission-find doesn't have not-in-priviledge options so the not-offering of existing values is handled by association_adder_dialog dialog's `exclude` array. This array is filled with already added and then compared with the keys got from xx-find command. Problems is that memberships are lowercased and therefore the values have different casing -> don't match and therefore are still offered. We might do some normalization in association_adder_dialog. I don't mind fixing it along with the refactoring. b) the success message might be a more wide-spread problem I noticed similar behavior in group's external member. Because of the wider scope please open a ticket. > > 4) Host Based Access Control: > When modifying a HBAC rule, workflow can be a bit confusing. For > example, if you have a rule with 'Anyone' selected in the 'WHO' section, > then you decide to change it to Specified Users and Groups, and then > click on Add to add users/groups, a dialog appears requiring you to save > your selection first (you have to click on Update, or click Cancel, then > Update the changes and then try to Add users again). Is it possible to > call the Update when Add is clicked, so that this step is automatically > performed, requiring no action from the user? I think it would feel more > intuitive to the user. I see one problem with the proposal. User might have changed also a description field or other category rule radio. I'm not sure if he wants to apply these changes automatically as well. > > 5) For sections that have Expand All/Collapse All link (for example, > when looking at a user's details page), I think that when you expand all > sections manually, the Expand All link should change to Collapse all. > And also the other way around: when you collapse all sections manually, > the Collapse All link should change to Expand All. This is probably > nitpicking too much, it is just a nice to have (does not make sense to > 'expand all' if everything is already expanded). > Open a ticket. I wonder how many users is using this feature. Personally, I don't. -- Petr Vobornik From akrivoka at redhat.com Fri Apr 26 13:03:01 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 26 Apr 2013 15:03:01 +0200 Subject: [Freeipa-devel] [PATCH] 0025 Always stop dirsrv in 'ipactl stop' Message-ID: <517A7B05.3040805@redhat.com> Ensure that 'ipactl stop' stops the dirsrv instance, even when no other services are running. https://fedorahosted.org/freeipa/ticket/3574 -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0025-Always-stop-dirsrv-in-ipactl-stop.patch Type: text/x-patch Size: 1618 bytes Desc: not available URL: From pviktori at redhat.com Fri Apr 26 13:47:18 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Apr 2013 15:47:18 +0200 Subject: [Freeipa-devel] [TIP] Make patches from Git more informative Message-ID: <517A8566.2060309@redhat.com> Hello, I'm sure you're aware of hunk header lines in patches: @@ -24,5 +24,5 @@ class SomeClass(object): It's possible to configure which source line Git selects for the hunk header. By default it uses non-indented lines. A "python" regexp, which selects functions, classes and methods, is already included in Git; you just have to enable it. I also use custom regexps for ldifs and API.txt: $ cat ~/.gitattributes # (Or .git/info/attributes for project-specific config) *.py diff=python API.txt diff=apitxt *.ldif diff=ldif *.update diff=ldif $ git config -l # set with e.g. `git config --global key="value"` ... core.attributesfile=~/.gitattributes diff.apitxt.xfuncname=^command: .* diff.ldif.xfuncname=^dn:.* Enjoy your Friday! -- Petr? From pviktori at redhat.com Fri Apr 26 14:03:56 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 26 Apr 2013 16:03:56 +0200 Subject: [Freeipa-devel] [PATCH] 0025 Always stop dirsrv in 'ipactl stop' In-Reply-To: <517A7B05.3040805@redhat.com> References: <517A7B05.3040805@redhat.com> Message-ID: <517A894C.5090402@redhat.com> On 04/26/2013 03:03 PM, Ana Krivokapic wrote: > Ensure that 'ipactl stop' stops the dirsrv instance, even when no other > services are running. > > https://fedorahosted.org/freeipa/ticket/3574 Thanks for the patch. It solves the problem, but when I look at the `if len(svc_list) == 0:` block, I see it only protects the os.unlink at the bottom against the case where there file doesn't exist. I think the code would be more straightforward if you removed the `if` block entirely, and wrapped a try/except around the unlink call. -- Petr? From akrivoka at redhat.com Fri Apr 26 14:30:56 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Fri, 26 Apr 2013 16:30:56 +0200 Subject: [Freeipa-devel] [PATCH] 0025 Always stop dirsrv in 'ipactl stop' In-Reply-To: <517A894C.5090402@redhat.com> References: <517A7B05.3040805@redhat.com> <517A894C.5090402@redhat.com> Message-ID: <517A8FA0.3020307@redhat.com> On 04/26/2013 04:03 PM, Petr Viktorin wrote: > On 04/26/2013 03:03 PM, Ana Krivokapic wrote: >> Ensure that 'ipactl stop' stops the dirsrv instance, even when no other >> services are running. >> >> https://fedorahosted.org/freeipa/ticket/3574 > > Thanks for the patch. It solves the problem, but when I look at the > `if len(svc_list) == 0:` block, I see it only protects the os.unlink > at the bottom against the case where there file doesn't exist. > I think the code would be more straightforward if you removed the `if` > block entirely, and wrapped a try/except around the unlink call. > Agreed, updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0025-02-Always-stop-dirsrv-in-ipactl-stop.patch Type: text/x-patch Size: 1829 bytes Desc: not available URL: From pvoborni at redhat.com Fri Apr 26 14:32:18 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Apr 2013 16:32:18 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <517A5C3C.4010005@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <51795BE6.9090405@redhat.com> <517A5C3C.4010005@redhat.com> Message-ID: <517A8FF2.6090107@redhat.com> Hi, 1, 2 and 3a are fixed and pushed to the private repo. Rest won't be fixed during the refactoring. I changed SingletonRegistry behavior that it returns null when builder/construction spec is missing. It's more consistent with build of unsupported entities (also returns null). On 04/26/2013 12:51 PM, Petr Vobornik wrote: > On 04/25/2013 06:37 PM, Ana Krivokapic wrote: >> >> Hi, >> >> While reviewing and testing the new UI changes, I have encountered the >> following issues. (Some of them may be unrelated to the webUI >> refactoring effort, but I will list them here just so we are aware of >> them.) > > Thanks for review, I will fix regressions today. We might open a ticket > for the rest. > >> >> 1) When in self service mode, you are now allowed to go to pages of >> related objects. If you go to e.g. User Groups for your user, there are >> Add/Delete buttons and they are enabled, but if you try to use them, you >> will be denied access. However, a message will appear, saying 'Items >> added' / 'Items removed' even though the operation had failed. Should we >> disable these options in self service mode? I think we should at least >> make sure that the misleading message which suggests that the actions >> was completed, does not appear. > > Regression. Links should not be clickable and buttons should be hidden. > >> >> 2) This one was already discussed with Petr in person: Runtime error on >> invalid URL: https://ipahost/ipa/ui/#/e/doesnotexist will give an ugly >> runtime error and any further navigation does not get rid of this error >> - you have to reload the page. We should make sure that this is handled >> more gracefully. >> > > Kind of regression. I will fix it by redirecting to default facet (user > search). > >> 3) Role Based Access Control, when trying to add a permission to a >> privilege: >> * Permissions which are already in that privilege appear in the list of >> available permissions. They should not appear there (it doesn't make >> sense to add something which is already there). (This behavior is >> correct in other parts of UI, e.g. when you want add a privilege to a >> role, the privileges which are already present for that role, do not >> appear in the list of available privileges.) >> * When you try to add such permission, first an Operations Error >> appears, but when you click OK, a message saying 'Items added' appears >> (similar issue is mentioned in 1) ). > > Not related to refactoring. > > a) permission-find doesn't have not-in-priviledge options so the > not-offering of existing values is handled by association_adder_dialog > dialog's `exclude` array. This array is filled with already added and > then compared with the keys got from xx-find command. Problems is that > memberships are lowercased and therefore the values have different > casing -> don't match and therefore are still offered. We might do some > normalization in association_adder_dialog. > > I don't mind fixing it along with the refactoring. > > b) the success message might be a more wide-spread problem I noticed > similar behavior in group's external member. > > Because of the wider scope please open a ticket. > >> >> 4) Host Based Access Control: >> When modifying a HBAC rule, workflow can be a bit confusing. For >> example, if you have a rule with 'Anyone' selected in the 'WHO' section, >> then you decide to change it to Specified Users and Groups, and then >> click on Add to add users/groups, a dialog appears requiring you to save >> your selection first (you have to click on Update, or click Cancel, then >> Update the changes and then try to Add users again). Is it possible to >> call the Update when Add is clicked, so that this step is automatically >> performed, requiring no action from the user? I think it would feel more >> intuitive to the user. > > I see one problem with the proposal. User might have changed also a > description field or other category rule radio. I'm not sure if he wants > to apply these changes automatically as well. > >> >> 5) For sections that have Expand All/Collapse All link (for example, >> when looking at a user's details page), I think that when you expand all >> sections manually, the Expand All link should change to Collapse all. >> And also the other way around: when you collapse all sections manually, >> the Collapse All link should change to Expand All. This is probably >> nitpicking too much, it is just a nice to have (does not make sense to >> 'expand all' if everything is already expanded). >> > > Open a ticket. I wonder how many users is using this feature. > Personally, I don't. > -- Petr Vobornik From rcritten at redhat.com Fri Apr 26 15:09:11 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Apr 2013 11:09:11 -0400 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517A53D2.20009@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> <517A53D2.20009@redhat.com> Message-ID: <517A9897.7020607@redhat.com> Petr Viktorin wrote: > On 04/25/2013 03:54 PM, Martin Kosek wrote: >> On 04/25/2013 12:37 PM, Petr Viktorin wrote: >>> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>>> This new freeform host attribute will allow provisioning systems >>>> to add custom tags for host objects which can be later used for >>>> in automember rules or for additional local interpretation. >>>> >>>> Design page: >>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>>> >>>> ----- >>>> >>>> This is how it can be used: >>>> >>>> # ipa hostgroup-add webservers >>>> Description: web servers >>>> ---------------------------- >>>> Added hostgroup "webservers" >>>> ---------------------------- >>>> Host-group: webservers >>>> Description: web servers >>>> >>>> # ipa automember-add --type=hostgroup webservers >>>> ---------------------------------- >>>> Added automember rule "webservers" >>>> ---------------------------------- >>>> Automember Rule: webservers >>>> >>>> # ipa automember-add-condition --key=userclass --type=hostgroup >>>> --inclusive-regex=^webserver webservers >>>> ---------------------------------- >>>> Added condition(s) to "webservers" >>>> ---------------------------------- >>>> Automember Rule: webservers >>>> Inclusive Regex: userclass=^webserver >>>> ---------------------------- >>>> Number of conditions added 1 >>>> ---------------------------- >>>> >>>> >>>> >>>> # ipa host-add web.example.com --force --class=webserver >>>> --class=mailserver >>>> ---------------------------- >>>> Added host "web.example.com" >>>> ---------------------------- >>>> Host name: web.example.com >>>> Principal name: host/web.example.com at EXAMPLE.COM >>>> Class: webserver, mailserver <<<<<<<<<< >>>> Password: False >>>> Member of host-groups: webservers <<<<<<<<<< >>>> Indirect Member of netgroup: webservers >>>> Keytab: False >>>> Managed by: web.example.com >>>> >>>> >>>> Martin >>>> >>> >>> I was surprised to find that host-show doesn't show it by default. Is >>> there a >>> reason to not put userclass in default_attributes? >>> >>> Please add a test. >>> >> >> Fixed. Updated patch attached. >> >> Martin > > ACK > Pushed to master, rebased and pushed to ipa-3-1 rob From rcritten at redhat.com Fri Apr 26 15:25:30 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Apr 2013 11:25:30 -0400 Subject: [Freeipa-devel] [PATCHES] 0218-0219 Fix syntax errors in schema files In-Reply-To: <5176BE80.7060807@redhat.com> References: <517573A5.4000109@redhat.com> <517667A6.5040705@redhat.com> <5176BE80.7060807@redhat.com> Message-ID: <517A9C6A.6090309@redhat.com> Petr Viktorin wrote: > On 04/23/2013 12:51 PM, Petr Viktorin wrote: >> On 04/22/2013 07:30 PM, Petr Viktorin wrote: >>> Hello, >>> >>> These patches fix errors in our schema files. The syntax errors would >>> prevent future versions of 389 from starting. >>> >>> I haven't done functional testing with development 389 versions, I'll >>> get in touch with mreynolds for that. So don't push these yet. >>> >>> https://fedorahosted.org/freeipa/ticket/3578 >>> >> >> >> Another syntax issue was in the updates, attaching an additional fix. >> >> Testing RPMs are available at >> http://fedorapeople.org/~pviktori/rpms/freeipa-3fd3e61/ > > The new DS finds no more syntax errors, so the patches are ready for > review. > I've squashed 0220 in, the full batch is attached. > Ack, pushed both to master. I needed to do a minor rebase on 218. rob From pvoborni at redhat.com Fri Apr 26 16:15:19 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Apr 2013 18:15:19 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <517A8FF2.6090107@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <51795BE6.9090405@redhat.com> <517A5C3C.4010005@redhat.com> <517A8FF2.6090107@redhat.com> Message-ID: <517AA817.1080303@redhat.com> Another problem found: trustconfig had invalid spec which made the trust section quite unusable. Fixed and pushed to the private repo. I also took an opportunity and added missing parts of trust metadata for static testing. On 04/26/2013 04:32 PM, Petr Vobornik wrote: > Hi, > > 1, 2 and 3a are fixed and pushed to the private repo. Rest won't be > fixed during the refactoring. > > I changed SingletonRegistry behavior that it returns null when > builder/construction spec is missing. It's more consistent with build of > unsupported entities (also returns null). -- Petr Vobornik From rcritten at redhat.com Fri Apr 26 16:39:06 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Apr 2013 12:39:06 -0400 Subject: [Freeipa-devel] [PATCH] 1097 Bump nss Requires Message-ID: <517AADAA.8020107@redhat.com> Set minimum version of nss/nss-tools to pick up fix to certutil handling of base64-encoded certificates. We saw pretty reliable failures in F-19 without this. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1097-nss.patch Type: text/x-diff Size: 1588 bytes Desc: not available URL: From pvoborni at redhat.com Fri Apr 26 16:43:12 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 26 Apr 2013 18:43:12 +0200 Subject: [Freeipa-devel] [PATCH] 276 Fix: Certificate status is not visible in Service and Host page Message-ID: <517AAEA0.2040306@redhat.com> https://fedorahosted.org/freeipa/ticket/3593 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0276-Fix-Certificate-status-is-not-visible-in-Service-and.patch Type: text/x-patch Size: 1195 bytes Desc: not available URL: From dpal at redhat.com Fri Apr 26 17:02:24 2013 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 26 Apr 2013 13:02:24 -0400 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517A5B48.9080208@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> <517960EB.8030201@redhat.com> <517A5B48.9080208@redhat.com> Message-ID: <517AB320.50009@redhat.com> On 04/26/2013 06:47 AM, Petr Viktorin wrote: > On 04/25/2013 06:59 PM, Dmitri Pal wrote: >> On 04/25/2013 09:54 AM, Martin Kosek wrote: >>> On 04/25/2013 12:37 PM, Petr Viktorin wrote: >>>> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>>>> This new freeform host attribute will allow provisioning systems >>>>> to add custom tags for host objects which can be later used for >>>>> in automember rules or for additional local interpretation. >>>>> >>>>> Design page: >>>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>>>> > [...] >> >> Can we use this patch to create a HOWTO on how to add and LDAP attribute >> to IPA? > > Yes, I can annotate the patch and put it on the wiki. I'll do it once > it's pushed so I can link to it. > > I know we're trying to organize the wiki page names. What's the > correct location for a developer-focused HOWTO? I do not have a preference. Whatever makes sense. > >> Also we have, I suspect a lot of metadata about attributes encoded in >> the framework, right? >> Why can't we use some kind of the data file(s) for it? This way one can >> add attributes dynamically and the framework would pick them up. >> It is clear that it would have to be done on all replicas > > So we should store it in LDAP and have it replicated. I am not against it. Files might be an interim step before getting there. > >> but still it >> would not require people to change the code - only configuration. Have >> we ever thought about this? > > If you're talking about parameters in the the framework commands, I > think --setattr is fine. > Or is this also about the schema? Web UI? > There are three parts: a) Schema b) Code option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) ... option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) ... option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) + Str('userclass*', + cli_name='class', + label=_('Class'), + doc=_('Host category (semantics placed on this attribute are for ' + 'local interpretation)'), + ), ) + ticket_flags_params + test This code can be completely parametarized and values read from the LDAP or files c) UI metadata - should be similar to above Then adding a new field would be equivalent to changing the schema and adding an entry or two - it is not a a software update per say. We would need to keep the data version clear rather than in addition to the hardcoded version in the code -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Fri Apr 26 19:53:10 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Apr 2013 15:53:10 -0400 Subject: [Freeipa-devel] [PATCH] 1098 catch cert-find errors on upgraded servers Message-ID: <517ADB26.60402@redhat.com> A dogtag 9 -> 10 upgraded server doesn't provide the RESTful API so therefore the cert-find command doesn't work. Starting with dogtag 10.0.2 it is going to send back a 501 (HTTP Not implemented) in this case so we at least have something to catch. This patch catches a 501 and returns a more specific message. 10.0.2 builds should be available this weekend, or you can pull from their devel repo at: [dogtag-devel] name=Dogtag development $releasever - $basearch baseurl=http://nkinder.fedorapeople.org/dogtag-devel/fedora/$releasever/$basearch/os/ enabled=0 gpgcheck=0 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1098-certfind.patch Type: text/x-diff Size: 2288 bytes Desc: not available URL: From rcritten at redhat.com Fri Apr 26 20:40:37 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Apr 2013 16:40:37 -0400 Subject: [Freeipa-devel] [PATCH] 0025 Always stop dirsrv in 'ipactl stop' In-Reply-To: <517A8FA0.3020307@redhat.com> References: <517A7B05.3040805@redhat.com> <517A894C.5090402@redhat.com> <517A8FA0.3020307@redhat.com> Message-ID: <517AE645.2060401@redhat.com> Ana Krivokapic wrote: > On 04/26/2013 04:03 PM, Petr Viktorin wrote: >> On 04/26/2013 03:03 PM, Ana Krivokapic wrote: >>> Ensure that 'ipactl stop' stops the dirsrv instance, even when no other >>> services are running. >>> >>> https://fedorahosted.org/freeipa/ticket/3574 >> >> Thanks for the patch. It solves the problem, but when I look at the >> `if len(svc_list) == 0:` block, I see it only protects the os.unlink >> at the bottom against the case where there file doesn't exist. >> I think the code would be more straightforward if you removed the `if` >> block entirely, and wrapped a try/except around the unlink call. >> > > Agreed, updated patch attached. Works for me. Postponing push until Monday as some of the hosted services are down for maintenance. rob From rcritten at redhat.com Fri Apr 26 22:30:47 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 26 Apr 2013 18:30:47 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <1366292936.17909.3.camel@localhost.localdomain> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> <1366292936.17909.3.camel@localhost.localdomain> Message-ID: <517B0017.8070209@redhat.com> Nathaniel McCallum wrote: > On Fri, 2013-04-12 at 17:39 -0400, Nathaniel McCallum wrote: >> On Fri, 2013-04-12 at 11:53 -0400, Nathaniel McCallum wrote: >>> On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: >>>> On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: >>>>> Nathaniel McCallum wrote: >>>>>> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: >>>>>>> I'm not sure how I'd test it if I got it built. >>>>>> >>>>>> I'm working on this. I hope to have a clear answer next week. Bear with >>>>>> me... >>>>>> >>>>>>> Overall looks really good. >>>>>> >>>>>> I've split up the patch into multiple commits. I've also added .update >>>>>> files and a patch for ipa-kdb to feed krb5 the right user string. >>>>>> >>>>>> https://github.com/npmccallum/freeipa/commits/otp >>>>>> >>>>>> Please take a look. I *think* I've got everything worked out so far with >>>>>> the exception of bug numbers / urls. Should every patch have a separate >>>>>> bug and a link to the design page? >>>>> >>>>> The ticket should go into every commit. I'd probably put the design link >>>>> there too, just for completeness. Future bug fixes, et all aren't going >>>>> to require the design page, but since these commits are all related to >>>>> the initial feature it will be nice to have. >>>>> >>>>> You can have multiple patches on the same ticket/bug. >>>> >>>> https://github.com/npmccallum/freeipa/commits/otp >>>> >>>> All four commits now have bug numbers and design page links. I'm adding >>>> the design page link to the tickets as we speak. >>>> >>>> Remaining issues (AFAICS): >>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously >>>> 2. ipatokenRadiusSecret is readable by an anonymous bind >>> 3. ipatokenT?OTP.* are readable by an anonymous bind >>> >>> In the case of both #2 and #3, only admins should have RW. ipa-otpd >>> needs read access to ipatokenRadiusSecret. The DS bind plugin below (#2) >>> needs read access to ipatokenT?OTP.*. >>> >>>> Outstanding pieces: >>>> 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 >>>> 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 >>>> 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 >>>> 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 >>>> >>>> #1 and #2 are within the scope of F19 and should hopefully land shortly >>>> (in separate commits). #3 and #4 are probably $nextrelease. >>>> >> >> FYI - Here is an RPM with all of the code so far: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=5247029 > > Updated RPMs, containing the new 389DS bind plugin and build for F19, > are here: > http://koji.fedoraproject.org/koji/taskinfo?taskID=5270926 > > Nathaniel BuildRequires needed for whatever provides krad.h A bunch of the files declare functions in each other. Is it cleaner to put these into an include file? I'm gathering that this will always be self-contained, so maybe this is ok. In entry_attr_get_berval() is it worth pointing out that there is no need to free the value, or is that assumed because it uses slapi_value_get_berval()? If we detect that there is clock drift should we log it? Will we ever try to report to the client (e.g. future enhancement)? I wonder if the NSPR-version of some functions should be used since this is running inside 389-ds, like PL_strcasecmp for strcasecmp() ops.c: pedantic: lack of spacing between if and parens sha384 is an allowed type only in otp.c. Is that needed? rob From rmeggins at redhat.com Fri Apr 26 22:49:11 2013 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 26 Apr 2013 16:49:11 -0600 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <517B0017.8070209@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> <1366292936.17909.3.camel@localhost.localdomain> <517B0017.8070209@redhat.com> Message-ID: <517B0467.5070005@redhat.com> On 04/26/2013 04:30 PM, Rob Crittenden wrote: > Nathaniel McCallum wrote: >> On Fri, 2013-04-12 at 17:39 -0400, Nathaniel McCallum wrote: >>> On Fri, 2013-04-12 at 11:53 -0400, Nathaniel McCallum wrote: >>>> On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: >>>>> On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: >>>>>> Nathaniel McCallum wrote: >>>>>>> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: >>>>>>>> I'm not sure how I'd test it if I got it built. >>>>>>> >>>>>>> I'm working on this. I hope to have a clear answer next week. >>>>>>> Bear with >>>>>>> me... >>>>>>> >>>>>>>> Overall looks really good. >>>>>>> >>>>>>> I've split up the patch into multiple commits. I've also added >>>>>>> .update >>>>>>> files and a patch for ipa-kdb to feed krb5 the right user string. >>>>>>> >>>>>>> https://github.com/npmccallum/freeipa/commits/otp >>>>>>> >>>>>>> Please take a look. I *think* I've got everything worked out so >>>>>>> far with >>>>>>> the exception of bug numbers / urls. Should every patch have a >>>>>>> separate >>>>>>> bug and a link to the design page? >>>>>> >>>>>> The ticket should go into every commit. I'd probably put the >>>>>> design link >>>>>> there too, just for completeness. Future bug fixes, et all aren't >>>>>> going >>>>>> to require the design page, but since these commits are all >>>>>> related to >>>>>> the initial feature it will be nice to have. >>>>>> >>>>>> You can have multiple patches on the same ticket/bug. >>>>> >>>>> https://github.com/npmccallum/freeipa/commits/otp >>>>> >>>>> All four commits now have bug numbers and design page links. I'm >>>>> adding >>>>> the design page link to the tickets as we speak. >>>>> >>>>> Remaining issues (AFAICS): >>>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously >>>>> 2. ipatokenRadiusSecret is readable by an anonymous bind >>>> 3. ipatokenT?OTP.* are readable by an anonymous bind >>>> >>>> In the case of both #2 and #3, only admins should have RW. ipa-otpd >>>> needs read access to ipatokenRadiusSecret. The DS bind plugin below >>>> (#2) >>>> needs read access to ipatokenT?OTP.*. >>>> >>>>> Outstanding pieces: >>>>> 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 >>>>> 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 >>>>> 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 >>>>> 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 >>>>> >>>>> #1 and #2 are within the scope of F19 and should hopefully land >>>>> shortly >>>>> (in separate commits). #3 and #4 are probably $nextrelease. >>>>> >>> >>> FYI - Here is an RPM with all of the code so far: >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=5247029 >> >> Updated RPMs, containing the new 389DS bind plugin and build for F19, >> are here: >> http://koji.fedoraproject.org/koji/taskinfo?taskID=5270926 >> >> Nathaniel > > BuildRequires needed for whatever provides krad.h > > A bunch of the files declare functions in each other. Is it cleaner to > put these into an include file? I'm gathering that this will always be > self-contained, so maybe this is ok. > > In entry_attr_get_berval() is it worth pointing out that there is no > need to free the value, or is that assumed because it uses > slapi_value_get_berval()? > > If we detect that there is clock drift should we log it? Will we ever > try to report to the client (e.g. future enhancement)? > > I wonder if the NSPR-version of some functions should be used since > this is running inside 389-ds, like PL_strcasecmp for strcasecmp() Nah - at this point, strcasecmp is supported pretty much everywhere. However, there are some interesting NSPR functions that help with buffer overrun detection and string null terminating - see plstr.h for details - if you need to do something like that. > > ops.c: > > pedantic: lack of spacing between if and parens > > sha384 is an allowed type only in otp.c. Is that needed? > > rob > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From akrivoka at redhat.com Mon Apr 29 11:05:11 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Mon, 29 Apr 2013 13:05:11 +0200 Subject: [Freeipa-devel] [PATCH] 276 Fix: Certificate status is not visible in Service and Host page In-Reply-To: <517AAEA0.2040306@redhat.com> References: <517AAEA0.2040306@redhat.com> Message-ID: <517E53E7.1000904@redhat.com> On 04/26/2013 06:43 PM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/3593 > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel ACK -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Mon Apr 29 11:12:31 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Apr 2013 13:12:31 +0200 Subject: [Freeipa-devel] [PATCH] 1098 catch cert-find errors on upgraded servers In-Reply-To: <517ADB26.60402@redhat.com> References: <517ADB26.60402@redhat.com> Message-ID: <517E559F.60301@redhat.com> On 04/26/2013 09:53 PM, Rob Crittenden wrote: > A dogtag 9 -> 10 upgraded server doesn't provide the RESTful API so > therefore the cert-find command doesn't work. Starting with dogtag > 10.0.2 it is going to send back a 501 (HTTP Not implemented) in this > case so we at least have something to catch. > > This patch catches a 501 and returns a more specific message. > > 10.0.2 builds should be available this weekend, or you can pull from > their devel repo at: > > [dogtag-devel] > name=Dogtag development $releasever - $basearch > baseurl=http://nkinder.fedorapeople.org/dogtag-devel/fedora/$releasever/$basearch/os/ > > enabled=0 > gpgcheck=0 > With the new Dogtag, /root/.pki/pki-tomcat/ca_admin_cert.p12 is not created. Installation of a new server fails on copying that to /root/ca-agent.p12. Adding Ade to the thread, he should know more. On my instance upgraded from f17 to f18, I get 404 errors, not 501. $ rpm -q pki-base pki-base-10.0.2-1.fc18.noarch $ ./ipa cert-find ipa: ERROR: Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) $ curl -v http://`hostname`:9180/ca/rest/certs/search [...] < HTTP/1.1 404 Not Found < Server: Apache-Coyote/1.1 < Content-Type: text/html < Content-Length: 5723 < Date: Sun, 28 Apr 2013 23:08:44 GMT [...] -- Petr? From pviktori at redhat.com Mon Apr 29 12:52:38 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Apr 2013 14:52:38 +0200 Subject: [Freeipa-devel] [PATCH] 1097 Bump nss Requires In-Reply-To: <517AADAA.8020107@redhat.com> References: <517AADAA.8020107@redhat.com> Message-ID: <517E6D16.7040301@redhat.com> On 04/26/2013 06:39 PM, Rob Crittenden wrote: > Set minimum version of nss/nss-tools to pick up fix to certutil handling > of base64-encoded certificates. We saw pretty reliable failures in F-19 > without this. > > rob ACK -- Petr? From rcritten at redhat.com Mon Apr 29 13:47:00 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Apr 2013 09:47:00 -0400 Subject: [Freeipa-devel] [PATCH] 0025 Always stop dirsrv in 'ipactl stop' In-Reply-To: <517AE645.2060401@redhat.com> References: <517A7B05.3040805@redhat.com> <517A894C.5090402@redhat.com> <517A8FA0.3020307@redhat.com> <517AE645.2060401@redhat.com> Message-ID: <517E79D4.1050103@redhat.com> Rob Crittenden wrote: > Ana Krivokapic wrote: >> On 04/26/2013 04:03 PM, Petr Viktorin wrote: >>> On 04/26/2013 03:03 PM, Ana Krivokapic wrote: >>>> Ensure that 'ipactl stop' stops the dirsrv instance, even when no other >>>> services are running. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3574 >>> >>> Thanks for the patch. It solves the problem, but when I look at the >>> `if len(svc_list) == 0:` block, I see it only protects the os.unlink >>> at the bottom against the case where there file doesn't exist. >>> I think the code would be more straightforward if you removed the `if` >>> block entirely, and wrapped a try/except around the unlink call. >>> >> >> Agreed, updated patch attached. > > Works for me. Postponing push until Monday as some of the hosted > services are down for maintenance. > > rob pushed to master From rcritten at redhat.com Mon Apr 29 13:50:43 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Apr 2013 09:50:43 -0400 Subject: [Freeipa-devel] [PATCH] 1097 Bump nss Requires In-Reply-To: <517E6D16.7040301@redhat.com> References: <517AADAA.8020107@redhat.com> <517E6D16.7040301@redhat.com> Message-ID: <517E7AB3.4030003@redhat.com> Petr Viktorin wrote: > On 04/26/2013 06:39 PM, Rob Crittenden wrote: >> Set minimum version of nss/nss-tools to pick up fix to certutil handling >> of base64-encoded certificates. We saw pretty reliable failures in F-19 >> without this. >> >> rob > > ACK > Pushed to master From tbabej at redhat.com Mon Apr 29 13:54:52 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Apr 2013 15:54:52 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <517908B2.8000002@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> <5179058E.7050306@redhat.com> <517908B2.8000002@redhat.com> Message-ID: <517E7BAC.5000407@redhat.com> On 04/25/2013 12:42 PM, Martin Kosek wrote: > On 04/25/2013 12:29 PM, Jan Cholasta wrote: >> On 25.4.2013 08:51, Martin Kosek wrote: >>> On 04/24/2013 08:02 PM, Rob Crittenden wrote: >>>> Jan Cholasta wrote: >>>>> On 24.4.2013 14:54, Martin Kosek wrote: >>>>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>>>> Jan Cholasta wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We should respect already configured options present in >>>>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT >>>>>>>>> options. >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>>>> >>>>>>>> >>>>>>>> the changeConf call will fail when the file does not exist, we >>>>>>>> might >>>>>>>> want to handle that gracefully. >>>>>>>> >>>>>>>> Honza >>>>>>>> >>>>>>> >>>>>>> We also need to handle the case where these items are already >>>>>>> defined. I'm >>>>>>> honestly not sure what the behavior should be: overwrite, warn and >>>>>>> overwrite, >>>>>>> fail. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> I am also thinking that we may want to be more cautious before >>>>>> updating this >>>>>> file. AFAIK, we do not need the updated file for our function, its >>>>>> only updated >>>>>> for user convenience so that he can run ldapsearches more easily. >>>>>> >>>>>> I see several options here that could help this goal: >>>>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>>>> options are >>>>>> not set. If the options are already set, we could just print a note >>>>>> that we >>>>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>>>> these options >>>>>> commented out, so it should be possible to implement this check. >>>>>> >>>>>> 2) Do ldap.conf changes only if a new special option is passe (e.g. >>>>>> --configure-ldap-cong) >>>>>> >>>>>> 3) Do not update ldap.conf when a new special option is not >>>>>> passed (e.g. >>>>>> --no-ldap-conf >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> If we don't need the file for our function, we can just not >>>>> configure it >>>>> at all IMO. We can document how to configure it for users who want >>>>> it. >>>> >>>> It was an RFE that we create this file. It is handy to have >>>> pre-configured, I >>>> like having it actually. >>>> >>>> We just need to try to have a gentler touch than my first crack at >>>> it, which >>>> overwrote it completely. I think #1 is probably enough for now. I'm >>>> not sure I >>>> want to add two new options this late in the game, and the client >>>> already has a >>>> lot of knobs. >>>> >>>> rob >>>> >>> >>> Yeah, I also agree that 1) is enough. It will not add any more >>> options and will >>> let us be more gentle and respectful to already existent custom user >>> settings >>> in ldap.conf. So Tomas, this seems like the way to go :-) >>> >>> Martin >>> >> >> I don't see the point of updating only some of these values. What about > > Not some of them - either all of them (BASE, URI, TLS_CACERT) when > none of them is already configured or none at all. > >> >> 4) Update BASE and URI and TLS_CACERT, comment any old settings out. >> >> ? > > This would still break an existing user configuration, we would just > tell user what we broke :-) > > Martin > >> >> Honza >> > The following version of the patch configures (BASE, URI, TLS_CACERT) attributes if they are not set. However, to preserve user-friendliness, our suggested option is added as an comment. See commit message for details. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0051-2-Preserve-already-configured-options-in-openldap-conf.patch Type: text/x-patch Size: 5775 bytes Desc: not available URL: From pviktori at redhat.com Mon Apr 29 15:35:29 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 29 Apr 2013 17:35:29 +0200 Subject: [Freeipa-devel] [PATCH] 402 Add userClass attribute for hosts In-Reply-To: <517AB320.50009@redhat.com> References: <517641E1.8080409@redhat.com> <5179075D.1050304@redhat.com> <517935A4.5070803@redhat.com> <517960EB.8030201@redhat.com> <517A5B48.9080208@redhat.com> <517AB320.50009@redhat.com> Message-ID: <517E9341.2080103@redhat.com> On 04/26/2013 07:02 PM, Dmitri Pal wrote: > On 04/26/2013 06:47 AM, Petr Viktorin wrote: >> On 04/25/2013 06:59 PM, Dmitri Pal wrote: >>> On 04/25/2013 09:54 AM, Martin Kosek wrote: >>>> On 04/25/2013 12:37 PM, Petr Viktorin wrote: >>>>> On 04/23/2013 10:10 AM, Martin Kosek wrote: >>>>>> This new freeform host attribute will allow provisioning systems >>>>>> to add custom tags for host objects which can be later used for >>>>>> in automember rules or for additional local interpretation. >>>>>> >>>>>> Design page: >>>>>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3583 >>>>>> >> [...] >>> >>> Can we use this patch to create a HOWTO on how to add and LDAP attribute >>> to IPA? >> >> Yes, I can annotate the patch and put it on the wiki. I'll do it once >> it's pushed so I can link to it. >> >> I know we're trying to organize the wiki page names. What's the >> correct location for a developer-focused HOWTO? > > I do not have a preference. Whatever makes sense. http://www.freeipa.org/page/HowTo/Add_a_new_attribute >> >>> Also we have, I suspect a lot of metadata about attributes encoded in >>> the framework, right? >>> Why can't we use some kind of the data file(s) for it? This way one can >>> add attributes dynamically and the framework would pick them up. >>> It is clear that it would have to be done on all replicas >> >> So we should store it in LDAP and have it replicated. > > > I am not against it. Files might be an interim step before getting there. Keep in mind that clients would need the info too. >>> but still it >>> would not require people to change the code - only configuration. Have >>> we ever thought about this? >> >> If you're talking about parameters in the the framework commands, I >> think --setattr is fine. >> Or is this also about the schema? Web UI? >> > > There are three parts: > a) Schema > b) Code > > option: Str('userclass', attribute=True, cli_name='class', multivalue=True, required=False) > ... > option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, query=True, required=False) > ... > option: Str('userclass', attribute=True, autofill=False, cli_name='class', multivalue=True, required=False) > > + Str('userclass*', > + cli_name='class', > + label=_('Class'), > + doc=_('Host category (semantics placed on this attribute are for ' > + 'local interpretation)'), > + ), > ) + ticket_flags_params > > + test > > This code can be completely parametarized and values read from the LDAP > or files Having one definitive list for the framework, UI, and various flags like default_attributes is the better design, but sadly without much practical advantage except the configurability. And the configurability would be limited. Lots of IPA code depends on "our" attributes being there, so users would need to only add additional ones, or risk breaking something. For small things a schema change and --setattr is enough (except the Web UI needs a way to do setattr too). If they need to add something big (custom validators, interdependencies between attributes), they'll need to write code anyway. > c) UI metadata - should be similar to above > > Then adding a new field would be equivalent to changing the schema and > adding an entry or two - it is not a a software update per say. > > We would need to keep the data version clear rather than in addition to > the hardcoded version in the code It would be a pretty large change, and it would need to be designed carefully to deal with replication, clients, data/schema/API versioning, etc. Don't get me wrong, I'd love to implement this, but I don't think there's enough demand/value to justify it. I filed a RFE: https://fedorahosted.org/freeipa/ticket/3595 -- Petr? From rcritten at redhat.com Mon Apr 29 18:13:49 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Apr 2013 14:13:49 -0400 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <517E7BAC.5000407@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> <5179058E.7050306@redhat.com> <517908B2.8000002@redhat.com> <517E7BAC.5000407@redhat.com> Message-ID: <517EB85D.10006@redhat.com> Tomas Babej wrote: > On 04/25/2013 12:42 PM, Martin Kosek wrote: >> On 04/25/2013 12:29 PM, Jan Cholasta wrote: >>> On 25.4.2013 08:51, Martin Kosek wrote: >>>> On 04/24/2013 08:02 PM, Rob Crittenden wrote: >>>>> Jan Cholasta wrote: >>>>>> On 24.4.2013 14:54, Martin Kosek wrote: >>>>>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>>>>> Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> We should respect already configured options present in >>>>>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT >>>>>>>>>> options. >>>>>>>>>> >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>>>>> >>>>>>>>> >>>>>>>>> the changeConf call will fail when the file does not exist, we >>>>>>>>> might >>>>>>>>> want to handle that gracefully. >>>>>>>>> >>>>>>>>> Honza >>>>>>>>> >>>>>>>> >>>>>>>> We also need to handle the case where these items are already >>>>>>>> defined. I'm >>>>>>>> honestly not sure what the behavior should be: overwrite, warn and >>>>>>>> overwrite, >>>>>>>> fail. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> I am also thinking that we may want to be more cautious before >>>>>>> updating this >>>>>>> file. AFAIK, we do not need the updated file for our function, its >>>>>>> only updated >>>>>>> for user convenience so that he can run ldapsearches more easily. >>>>>>> >>>>>>> I see several options here that could help this goal: >>>>>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>>>>> options are >>>>>>> not set. If the options are already set, we could just print a note >>>>>>> that we >>>>>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>>>>> these options >>>>>>> commented out, so it should be possible to implement this check. >>>>>>> >>>>>>> 2) Do ldap.conf changes only if a new special option is passe (e.g. >>>>>>> --configure-ldap-cong) >>>>>>> >>>>>>> 3) Do not update ldap.conf when a new special option is not >>>>>>> passed (e.g. >>>>>>> --no-ldap-conf >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> If we don't need the file for our function, we can just not >>>>>> configure it >>>>>> at all IMO. We can document how to configure it for users who want >>>>>> it. >>>>> >>>>> It was an RFE that we create this file. It is handy to have >>>>> pre-configured, I >>>>> like having it actually. >>>>> >>>>> We just need to try to have a gentler touch than my first crack at >>>>> it, which >>>>> overwrote it completely. I think #1 is probably enough for now. I'm >>>>> not sure I >>>>> want to add two new options this late in the game, and the client >>>>> already has a >>>>> lot of knobs. >>>>> >>>>> rob >>>>> >>>> >>>> Yeah, I also agree that 1) is enough. It will not add any more >>>> options and will >>>> let us be more gentle and respectful to already existent custom user >>>> settings >>>> in ldap.conf. So Tomas, this seems like the way to go :-) >>>> >>>> Martin >>>> >>> >>> I don't see the point of updating only some of these values. What about >> >> Not some of them - either all of them (BASE, URI, TLS_CACERT) when >> none of them is already configured or none at all. >> >>> >>> 4) Update BASE and URI and TLS_CACERT, comment any old settings out. >>> >>> ? >> >> This would still break an existing user configuration, we would just >> tell user what we broke :-) >> >> Martin >> >>> >>> Honza >>> >> > The following version of the patch configures (BASE, URI, TLS_CACERT) > attributes if they are not set. > > However, to preserve user-friendliness, our suggested option is added as > an comment. See commit message for details. > > Tomas Ok, this works as advertised, I just have a general question. This could enable a mix of IPA and non-IPA settings. In my case I left BASE configured and only URI and TLS_CACERT got set. This could cause some unexpected results I think, depending on what got changed. Do we rather want to punt on all of them if any of them can't be updated? This would require a bit more code, and wouldn't be as generic. I just wonder if this would cause subtle failures. rob From rcritten at redhat.com Mon Apr 29 18:58:19 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Apr 2013 14:58:19 -0400 Subject: [Freeipa-devel] [PATCH] 130 Drop support for OpenSSH versions before 6.2 In-Reply-To: <51753A92.5020208@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> <51753A92.5020208@redhat.com> Message-ID: <517EC2CB.3010401@redhat.com> Jan Cholasta wrote: > On 19.4.2013 19:39, Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Also, this does not fix SSH integration not working on Fedora 18, as >>> that is caused by backward incompatiblity in openssh-server-6.1p1-6 and >>> later (see https://bugzilla.redhat.com/show_bug.cgi?id=953534). > > FYI this bug was fixed. > >> >> This seems to work ok. Do we want to do this upgrade as an rpm scriptlet >> or is it better to handle this in ipa-upgradeconfig (it might be easier >> to maintain there)? > > As Martin pointed out, this needs to be done on the client and we don't > have client upgrade script yet, hence the scriptlet. > >> >> In any case, a condrestart of sssd is required to have it pick up the >> new config. > > Fixed. > >> >> Do you know if F-18 will get 6.2? Do we need to consider backporting >> this to 3.1? > > It won't, backport is not needed. > > Updated patch attached. > > Honza > Alexander pointed out that we can use the user nobody to run these commands rather than running as the user who requested it, %u. For the purposes of development, this is going to commit everyone to moving to F-19 now. Is that acceptable or do we want to wrap this with a conditional for some period? rob From tbabej at redhat.com Mon Apr 29 20:28:20 2013 From: tbabej at redhat.com (Tomas Babej) Date: Mon, 29 Apr 2013 22:28:20 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <517EB85D.10006@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> <5179058E.7050306@redhat.com> <517908B2.8000002@redhat.com> <517E7BAC.5000407@redhat.com> <517EB85D.10006@redhat.com> Message-ID: <517ED7E4.9070204@redhat.com> On 04/29/2013 08:13 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> On 04/25/2013 12:42 PM, Martin Kosek wrote: >>> On 04/25/2013 12:29 PM, Jan Cholasta wrote: >>>> On 25.4.2013 08:51, Martin Kosek wrote: >>>>> On 04/24/2013 08:02 PM, Rob Crittenden wrote: >>>>>> Jan Cholasta wrote: >>>>>>> On 24.4.2013 14:54, Martin Kosek wrote: >>>>>>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>>>>>> Jan Cholasta wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> We should respect already configured options present in >>>>>>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT >>>>>>>>>>> options. >>>>>>>>>>> >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> the changeConf call will fail when the file does not exist, we >>>>>>>>>> might >>>>>>>>>> want to handle that gracefully. >>>>>>>>>> >>>>>>>>>> Honza >>>>>>>>>> >>>>>>>>> >>>>>>>>> We also need to handle the case where these items are already >>>>>>>>> defined. I'm >>>>>>>>> honestly not sure what the behavior should be: overwrite, warn >>>>>>>>> and >>>>>>>>> overwrite, >>>>>>>>> fail. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>> >>>>>>>> I am also thinking that we may want to be more cautious before >>>>>>>> updating this >>>>>>>> file. AFAIK, we do not need the updated file for our function, its >>>>>>>> only updated >>>>>>>> for user convenience so that he can run ldapsearches more easily. >>>>>>>> >>>>>>>> I see several options here that could help this goal: >>>>>>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>>>>>> options are >>>>>>>> not set. If the options are already set, we could just print a >>>>>>>> note >>>>>>>> that we >>>>>>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>>>>>> these options >>>>>>>> commented out, so it should be possible to implement this check. >>>>>>>> >>>>>>>> 2) Do ldap.conf changes only if a new special option is passe >>>>>>>> (e.g. >>>>>>>> --configure-ldap-cong) >>>>>>>> >>>>>>>> 3) Do not update ldap.conf when a new special option is not >>>>>>>> passed (e.g. >>>>>>>> --no-ldap-conf >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> If we don't need the file for our function, we can just not >>>>>>> configure it >>>>>>> at all IMO. We can document how to configure it for users who want >>>>>>> it. >>>>>> >>>>>> It was an RFE that we create this file. It is handy to have >>>>>> pre-configured, I >>>>>> like having it actually. >>>>>> >>>>>> We just need to try to have a gentler touch than my first crack at >>>>>> it, which >>>>>> overwrote it completely. I think #1 is probably enough for now. I'm >>>>>> not sure I >>>>>> want to add two new options this late in the game, and the client >>>>>> already has a >>>>>> lot of knobs. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> Yeah, I also agree that 1) is enough. It will not add any more >>>>> options and will >>>>> let us be more gentle and respectful to already existent custom user >>>>> settings >>>>> in ldap.conf. So Tomas, this seems like the way to go :-) >>>>> >>>>> Martin >>>>> >>>> >>>> I don't see the point of updating only some of these values. What >>>> about >>> >>> Not some of them - either all of them (BASE, URI, TLS_CACERT) when >>> none of them is already configured or none at all. >>> >>>> >>>> 4) Update BASE and URI and TLS_CACERT, comment any old settings out. >>>> >>>> ? >>> >>> This would still break an existing user configuration, we would just >>> tell user what we broke :-) >>> >>> Martin >>> >>>> >>>> Honza >>>> >>> >> The following version of the patch configures (BASE, URI, TLS_CACERT) >> attributes if they are not set. >> >> However, to preserve user-friendliness, our suggested option is added as >> an comment. See commit message for details. >> >> Tomas > > Ok, this works as advertised, I just have a general question. > > This could enable a mix of IPA and non-IPA settings. In my case I left > BASE configured and only URI and TLS_CACERT got set. > > This could cause some unexpected results I think, depending on what > got changed. > > Do we rather want to punt on all of them if any of them can't be > updated? This would require a bit more code, and wouldn't be as > generic. I just wonder if this would cause subtle failures. > > rob After IRC conversation with Rob, we decided to keep the behaviour, while having it explicitly mentioned in the ldap.conf file. For illustration, the ldap.conf file could look like this: [/etc/openldap/ldap.conf] # File modified by ipa-client-install # We do not want to break your existing configuration, hence: # URI, BASE and TLS_CACERT have been added if they were not set. # In case any of them were set, a comment with trailing note # "# modified by IPA" note has been inserted. # To use IPA server with openLDAP tools, please comment out your # existing configuration for these options and uncomment the # corresponding lines generated by IPA. # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=ipa,dc=example,dc=com # modified by IPA BASE dc=example,dc=com #URI ldaps://ipa.example.com # modified by IPA URI ldap://ldap.example.com #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts TLS_CACERT /etc/ipa/ca.crt Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0051-3-Preserve-already-configured-options-in-openldap-conf.patch Type: text/x-patch Size: 7172 bytes Desc: not available URL: From rcritten at redhat.com Mon Apr 29 20:52:17 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 29 Apr 2013 16:52:17 -0400 Subject: [Freeipa-devel] [PATCH] 1098 catch cert-find errors on upgraded servers In-Reply-To: <517E559F.60301@redhat.com> References: <517ADB26.60402@redhat.com> <517E559F.60301@redhat.com> Message-ID: <517EDD81.9020005@redhat.com> Petr Viktorin wrote: > On 04/26/2013 09:53 PM, Rob Crittenden wrote: >> A dogtag 9 -> 10 upgraded server doesn't provide the RESTful API so >> therefore the cert-find command doesn't work. Starting with dogtag >> 10.0.2 it is going to send back a 501 (HTTP Not implemented) in this >> case so we at least have something to catch. >> >> This patch catches a 501 and returns a more specific message. >> >> 10.0.2 builds should be available this weekend, or you can pull from >> their devel repo at: >> >> [dogtag-devel] >> name=Dogtag development $releasever - $basearch >> baseurl=http://nkinder.fedorapeople.org/dogtag-devel/fedora/$releasever/$basearch/os/ >> >> >> enabled=0 >> gpgcheck=0 >> > > With the new Dogtag, /root/.pki/pki-tomcat/ca_admin_cert.p12 is not > created. Installation of a new server fails on copying that to > /root/ca-agent.p12. Adding Ade to the thread, he should know more. > > > On my instance upgraded from f17 to f18, I get 404 errors, not 501. > > $ rpm -q pki-base > pki-base-10.0.2-1.fc18.noarch > $ ./ipa cert-find > ipa: ERROR: Certificate operation cannot be completed: Unable to > communicate with CMS (Not Found) > $ curl -v http://`hostname`:9180/ca/rest/certs/search > [...] > < HTTP/1.1 404 Not Found > < Server: Apache-Coyote/1.1 > < Content-Type: text/html > < Content-Length: 5723 > < Date: Sun, 28 Apr 2013 23:08:44 GMT > [...] This is caused by some syntax errors in the dogtag upgrade script. They are working on a respin. See /var/log/pki/pki-server-upgrade-*.log rob From pviktori at redhat.com Tue Apr 30 08:09:23 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Apr 2013 10:09:23 +0200 Subject: [Freeipa-devel] [PATCH] 130 Drop support for OpenSSH versions before 6.2 In-Reply-To: <517EC2CB.3010401@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> <51753A92.5020208@redhat.com> <517EC2CB.3010401@redhat.com> Message-ID: <517F7C33.3050303@redhat.com> On 04/29/2013 08:58 PM, Rob Crittenden wrote: > Jan Cholasta wrote: >> On 19.4.2013 19:39, Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Also, this does not fix SSH integration not working on Fedora 18, as >>>> that is caused by backward incompatiblity in openssh-server-6.1p1-6 and >>>> later (see https://bugzilla.redhat.com/show_bug.cgi?id=953534). >> >> FYI this bug was fixed. >> >>> >>> This seems to work ok. Do we want to do this upgrade as an rpm scriptlet >>> or is it better to handle this in ipa-upgradeconfig (it might be easier >>> to maintain there)? >> >> As Martin pointed out, this needs to be done on the client and we don't >> have client upgrade script yet, hence the scriptlet. >> >>> >>> In any case, a condrestart of sssd is required to have it pick up the >>> new config. >> >> Fixed. >> >>> >>> Do you know if F-18 will get 6.2? Do we need to consider backporting >>> this to 3.1? >> >> It won't, backport is not needed. >> >> Updated patch attached. >> >> Honza >> > > Alexander pointed out that we can use the user nobody to run these > commands rather than running as the user who requested it, %u. > > For the purposes of development, this is going to commit everyone to > moving to F-19 now. Is that acceptable or do we want to wrap this with a > conditional for some period? > > rob The upcoming upgrade testing would be easier if we can just do f17?f18 instead of f17?f18?f19 to look for issues with Dogtag-9 style instances. -- Petr? From pviktori at redhat.com Tue Apr 30 08:42:06 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Apr 2013 10:42:06 +0200 Subject: [Freeipa-devel] [PATCH 0023 Do not display ports to open when password is incorrect during ipa-client-install In-Reply-To: <51765FC5.6030105@redhat.com> References: <51755366.6090104@redhat.com> <5175B44D.8080705@redhat.com> <51765FC5.6030105@redhat.com> Message-ID: <517F83DE.9050604@redhat.com> On 04/23/2013 12:17 PM, Ana Krivokapic wrote: > On 04/23/2013 12:06 AM, Rob Crittenden wrote: >> Ana Krivokapic wrote: >>> Do not display ports to open when password is incorrect during >>> ipa-client-install >>> >>> https://fedorahosted.org/freeipa/ticket/3573 >>> >> >> What happens if port 88 is not open so it can't connect to the KDC? >> I'm not sure how the best way to determine one vs the other, I don't >> think there are distinct return values. >> >> We could use the fact that Kerberos isn't translated to look for >> specific strings maybe, but that is hackish and could break. >> >> rob > > The return value from kinit is always 1 in case of failure. So the only > way to determine the reason for failure would be to look into the > message string. I agree this is hackish as Rob pointed out. Personally, > I am for leaving everything as it is now. In the case of incorrect > password, the user _does_ get the message that the password was > incorrect (kinit: Password incorrect while getting initial credentials). > So I don't think that displaying the message about ports, in addition to > this message, is confusing/misleading. I think displaying the error messages after the port information would make it clearer that this is the reason for failed installation. -- Petr? From jcholast at redhat.com Tue Apr 30 09:08:01 2013 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 30 Apr 2013 11:08:01 +0200 Subject: [Freeipa-devel] [PATCH] 130 Add support for OpenSSH 6.2 (was Re: [PATCH] 130 Drop support for OpenSSH versions before 6.2) In-Reply-To: <517EC2CB.3010401@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> <51753A92.5020208@redhat.com> <517EC2CB.3010401@redhat.com> Message-ID: <517F89F1.7000604@redhat.com> On 29.4.2013 20:58, Rob Crittenden wrote: > Alexander pointed out that we can use the user nobody to run these > commands rather than running as the user who requested it, %u. Added. > > For the purposes of development, this is going to commit everyone to > moving to F-19 now. Is that acceptable or do we want to wrap this with a > conditional for some period? I have changed the patch to add support for openssh 6.2 without dropping support for older openssh versions. We can drop support for older openssh versions in IPA 3.3. See attachment. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-130.2-Add-support-for-OpenSSH-6.2.patch Type: text/x-patch Size: 7242 bytes Desc: not available URL: From sbose at redhat.com Tue Apr 30 10:04:54 2013 From: sbose at redhat.com (Sumit Bose) Date: Tue, 30 Apr 2013 12:04:54 +0200 Subject: [Freeipa-devel] [PATCHES] Fix minor issues in the extdom plugin Message-ID: <20130430100454.GA11687@localhost.localdomain> Hi, while adding the SID based lookups to SSSD I would some minor issues in the extdom plugin in code paths which were not used by the current requests. Fixes https://fedorahosted.org/freeipa/ticket/3596 bye, Sumit -------------- next part -------------- From 4db38535ba86a0249c4f11d4adde814eee6547e3 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 24 Apr 2013 14:44:54 +0200 Subject: [PATCH 111/113] Do not lookup up the domain too early if only the SID is know Request with a SID as input parameter do not contain the domain name, hence is must be tried to resolve the SID first before the corresponding domain can be looked up. --- .../ipa-extdom-extop/ipa_extdom_common.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index 660ed04c2ced547027f79b9da01ede21775ede19..e532807aa6f40191724eeb091c7bc22303960135 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -332,10 +332,13 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, enum idmap_error_code err; char *sid_str; - ret = get_domain_info(ctx, req->data.name.domain_name, &domain_info); - if (ret != 0) { - return LDAP_OPERATIONS_ERROR; + if (req->input_type != INP_SID) { + ret = get_domain_info(ctx, req->data.name.domain_name, &domain_info); + if (ret != 0) { + return LDAP_OPERATIONS_ERROR; + } } + if (req->input_type == INP_POSIX_UID || req->input_type == INP_POSIX_GID) { if (req->input_type == INP_POSIX_UID) { id = req->data.posix_uid.uid; @@ -374,6 +377,13 @@ int handle_request(struct ipa_extdom_ctx *ctx, struct extdom_req *req, goto done; } + if (req->input_type == INP_SID) { + ret = get_domain_info(ctx, domain_name, &domain_info); + if (ret != 0) { + return LDAP_OPERATIONS_ERROR; + } + } + ret = create_response(req, domain_info, domain_name, name, &sid, name_type, res); if (ret != 0) { -- 1.8.1.4 -------------- next part -------------- From 31526d967dbf3a0eaca141c8d400f5c29b22f511 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 26 Apr 2013 09:21:43 +0200 Subject: [PATCH 112/113] Do not store SID string in a local buffer --- .../ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index e532807aa6f40191724eeb091c7bc22303960135..ef474d3a175a256bfb4397fe6b21b5ca2cf35c90 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -432,7 +432,8 @@ int create_response(struct extdom_req *req, struct domain_info *domain_info, struct extdom_res *res; uint32_t id; enum idmap_error_code err; - char sid_str[WBC_SID_STRING_BUFLEN + 1]; + char *sid_str; + wbcErr werr; res = malloc(sizeof(struct extdom_res)); if (res == NULL) { @@ -450,9 +451,8 @@ int create_response(struct extdom_req *req, struct domain_info *domain_info, case INP_NAME: res->response_type = RESP_SID; - len = wbcSidToStringBuf(sid, sid_str, - WBC_SID_STRING_BUFLEN); - if (len + 1 > WBC_SID_STRING_BUFLEN) { + werr = wbcSidToString(sid, &sid_str); + if (!WBC_ERROR_IS_OK(werr)) { ret = EINVAL; goto done; } @@ -465,13 +465,14 @@ int create_response(struct extdom_req *req, struct domain_info *domain_info, } break; case REQ_FULL: - len = wbcSidToStringBuf(sid, sid_str, WBC_SID_STRING_BUFLEN); - if (len + 1 > WBC_SID_STRING_BUFLEN) { + len = wbcSidToString(sid, &sid_str); + if (!WBC_ERROR_IS_OK(werr)) { ret = EINVAL; goto done; } err = sss_idmap_sid_to_unix(domain_info->idmap_ctx, sid_str, &id); + wbcFreeMemory(sid_str); if (err != IDMAP_SUCCESS) { ret = EINVAL; goto done; @@ -566,6 +567,7 @@ int pack_response(struct extdom_res *res, struct berval **ret_val) switch (res->response_type) { case RESP_SID: ret = ber_printf(ber,"{es}", res->response_type, res->data.sid); + wbcFreeMemory(res->data.sid); break; case RESP_NAME: ret = ber_printf(ber,"{e{ss}}", res->response_type, -- 1.8.1.4 -------------- next part -------------- From faf8a7cd0361e07dbdad336bd0df73184afb05c7 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Fri, 26 Apr 2013 17:20:49 +0200 Subject: [PATCH 113/113] Allow ID-to-SID mappings in the extdom plugin --- daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c index ef474d3a175a256bfb4397fe6b21b5ca2cf35c90..b6136ee78cb75b37d2dcf16bd1b0e7871f5f1d84 100644 --- a/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c +++ b/daemons/ipa-slapi-plugins/ipa-extdom-extop/ipa_extdom_common.c @@ -449,6 +449,8 @@ int create_response(struct extdom_req *req, struct domain_info *domain_info, res->data.name.object_name = name; break; case INP_NAME: + case INP_POSIX_UID: + case INP_POSIX_GID: res->response_type = RESP_SID; werr = wbcSidToString(sid, &sid_str); -- 1.8.1.4 From pviktori at redhat.com Tue Apr 30 12:12:42 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Apr 2013 14:12:42 +0200 Subject: [Freeipa-devel] [PATCH] 130 Add support for OpenSSH 6.2 (was Re: [PATCH] 130 Drop support for OpenSSH versions before 6.2) In-Reply-To: <517F89F1.7000604@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> <51753A92.5020208@redhat.com> <517EC2CB.3010401@redhat.com> <517F89F1.7000604@redhat.com> Message-ID: <517FB53A.5070706@redhat.com> On 04/30/2013 11:08 AM, Jan Cholasta wrote: > On 29.4.2013 20:58, Rob Crittenden wrote: >> Alexander pointed out that we can use the user nobody to run these >> commands rather than running as the user who requested it, %u. > > Added. > >> >> For the purposes of development, this is going to commit everyone to >> moving to F-19 now. Is that acceptable or do we want to wrap this with a >> conditional for some period? > > I have changed the patch to add support for openssh 6.2 without dropping > support for older openssh versions. We can drop support for older > openssh versions in IPA 3.3. See attachment. > > Honza Works for me, so ACK unless someone more experienced with SSH wants to take a look. -- Petr? From tbabej at redhat.com Tue Apr 30 12:32:30 2013 From: tbabej at redhat.com (Tomas Babej) Date: Tue, 30 Apr 2013 14:32:30 +0200 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <516715C1.9040607@redhat.com> References: <5164017C.1000101@redhat.com> <516715C1.9040607@redhat.com> Message-ID: <517FB9DE.8000404@redhat.com> On 04/11/2013 09:57 PM, Rob Crittenden wrote: > Tomas Babej wrote: >> Hi, >> >> In ipa-replica-manage commands, we enforce that hostnames we work >> with are resolvable. However, this caused errors while deleting >> or disconnecting a ipa / winsync replica, if that replica was down >> and authoritative server for itself. >> >> https://fedorahosted.org/freeipa/ticket/3524 >> >> Tomas > > I'm not sure this is going to do the right thing either. A lot of > these commands take the an argument as the remote master to run things > on, so we'd really only be validating one of the names. Not sure how > that helps us. > Actually, the patch tried to adress that. I carefully reviewed the effort, now we should be consistent in validating all the names. > What if we honor the --force flag for DNS lookup failures instead? Or, > since that could override it and do other things, a --no-lookup flag > perhaps? > > rob I added a --no-lookup flag for ipa-replica-manage that disables host existence check. Sending both patches rebased. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0046-2-Handle-connection-timeout-in-ipa-replica-manage.patch Type: text/x-patch Size: 2037 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0045-2-Enforce-host-existence-only-where-needed-in-ipa-repl.patch Type: text/x-patch Size: 10114 bytes Desc: not available URL: From abokovoy at redhat.com Tue Apr 30 12:41:49 2013 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 30 Apr 2013 15:41:49 +0300 Subject: [Freeipa-devel] [PATCH] 130 Add support for OpenSSH 6.2 (was Re: [PATCH] 130 Drop support for OpenSSH versions before 6.2) In-Reply-To: <517FB53A.5070706@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> <51753A92.5020208@redhat.com> <517EC2CB.3010401@redhat.com> <517F89F1.7000604@redhat.com> <517FB53A.5070706@redhat.com> Message-ID: <20130430124149.GI7607@redhat.com> On Tue, 30 Apr 2013, Petr Viktorin wrote: >On 04/30/2013 11:08 AM, Jan Cholasta wrote: >>On 29.4.2013 20:58, Rob Crittenden wrote: >>>Alexander pointed out that we can use the user nobody to run these >>>commands rather than running as the user who requested it, %u. >> >>Added. >> >>> >>>For the purposes of development, this is going to commit everyone to >>>moving to F-19 now. Is that acceptable or do we want to wrap this with a >>>conditional for some period? >> >>I have changed the patch to add support for openssh 6.2 without dropping >>support for older openssh versions. We can drop support for older >>openssh versions in IPA 3.3. See attachment. >> >>Honza > >Works for me, so ACK unless someone more experienced with SSH wants >to take a look. Works for me too and looks OK. ACK. -- / Alexander Bokovoy From pspacek at redhat.com Tue Apr 30 13:45:25 2013 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 30 Apr 2013 15:45:25 +0200 Subject: [Freeipa-devel] [PATCH 0152] Replace TTL values > 2^31-1 with 0. Message-ID: <517FCAF5.70103@redhat.com> Hello, Replace TTL values > 2^31-1 with 0. The rule comes from RFC 2181 section 8. https://fedorahosted.org/bind-dyndb-ldap/ticket/117 -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0152-Replace-TTL-values-2-31-1-with-0.patch Type: text/x-patch Size: 940 bytes Desc: not available URL: From akrivoka at redhat.com Tue Apr 30 14:03:52 2013 From: akrivoka at redhat.com (Ana Krivokapic) Date: Tue, 30 Apr 2013 16:03:52 +0200 Subject: [Freeipa-devel] [PATCH 0023 Do not display ports to open when password is incorrect during ipa-client-install In-Reply-To: <517F83DE.9050604@redhat.com> References: <51755366.6090104@redhat.com> <5175B44D.8080705@redhat.com> <51765FC5.6030105@redhat.com> <517F83DE.9050604@redhat.com> Message-ID: <517FCF48.5040206@redhat.com> On 04/30/2013 10:42 AM, Petr Viktorin wrote: > On 04/23/2013 12:17 PM, Ana Krivokapic wrote: >> On 04/23/2013 12:06 AM, Rob Crittenden wrote: >>> Ana Krivokapic wrote: >>>> Do not display ports to open when password is incorrect during >>>> ipa-client-install >>>> >>>> https://fedorahosted.org/freeipa/ticket/3573 >>>> >>> >>> What happens if port 88 is not open so it can't connect to the KDC? >>> I'm not sure how the best way to determine one vs the other, I don't >>> think there are distinct return values. >>> >>> We could use the fact that Kerberos isn't translated to look for >>> specific strings maybe, but that is hackish and could break. >>> >>> rob >> >> The return value from kinit is always 1 in case of failure. So the only >> way to determine the reason for failure would be to look into the >> message string. I agree this is hackish as Rob pointed out. Personally, >> I am for leaving everything as it is now. In the case of incorrect >> password, the user _does_ get the message that the password was >> incorrect (kinit: Password incorrect while getting initial credentials). >> So I don't think that displaying the message about ports, in addition to >> this message, is confusing/misleading. > > I think displaying the error messages after the port information would > make it clearer that this is the reason for failed installation. > I think this is a good compromise. Updated patch attached. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-akrivoka-0023-02-Improve-error-message-on-failed-Kerberos-authenticat.patch Type: text/x-patch Size: 2103 bytes Desc: not available URL: From pviktori at redhat.com Tue Apr 30 14:33:54 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Apr 2013 16:33:54 +0200 Subject: [Freeipa-devel] [PATCH 0023 Do not display ports to open when password is incorrect during ipa-client-install In-Reply-To: <517FCF48.5040206@redhat.com> References: <51755366.6090104@redhat.com> <5175B44D.8080705@redhat.com> <51765FC5.6030105@redhat.com> <517F83DE.9050604@redhat.com> <517FCF48.5040206@redhat.com> Message-ID: <517FD652.3000703@redhat.com> On 04/30/2013 04:03 PM, Ana Krivokapic wrote: > On 04/30/2013 10:42 AM, Petr Viktorin wrote: >> On 04/23/2013 12:17 PM, Ana Krivokapic wrote: >>> On 04/23/2013 12:06 AM, Rob Crittenden wrote: >>>> Ana Krivokapic wrote: >>>>> Do not display ports to open when password is incorrect during >>>>> ipa-client-install >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3573 >>>>> >>>> >>>> What happens if port 88 is not open so it can't connect to the KDC? >>>> I'm not sure how the best way to determine one vs the other, I don't >>>> think there are distinct return values. >>>> >>>> We could use the fact that Kerberos isn't translated to look for >>>> specific strings maybe, but that is hackish and could break. >>>> >>>> rob >>> >>> The return value from kinit is always 1 in case of failure. So the only >>> way to determine the reason for failure would be to look into the >>> message string. I agree this is hackish as Rob pointed out. Personally, >>> I am for leaving everything as it is now. In the case of incorrect >>> password, the user _does_ get the message that the password was >>> incorrect (kinit: Password incorrect while getting initial credentials). >>> So I don't think that displaying the message about ports, in addition to >>> this message, is confusing/misleading. >> >> I think displaying the error messages after the port information would >> make it clearer that this is the reason for failed installation. >> > > I think this is a good compromise. Updated patch attached. So now we have, with bad password: $ sudo ipa-client-install -p admin -w bad-password Discovery was successful! Hostname: vm-050.idm.lab.eng.brq.redhat.com Realm: IDM.LAB.ENG.BRQ.REDHAT.COM DNS Domain: idm.lab.eng.brq.redhat.com IPA Server: vm-109.idm.lab.eng.brq.redhat.com BaseDN: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com Continue to configure the system with these values? [no]: y Synchronizing time with KDC... Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Kerberos authentication failed kinit: Password incorrect while getting initial credentials Installation failed. Rolling back changes. IPA client is not configured on this system. and with no connection: $ sudo ipa-client-install -p admin -w good-password Discovery was successful! Hostname: vm-050.idm.lab.eng.brq.redhat.com Realm: IDM.LAB.ENG.BRQ.REDHAT.COM DNS Domain: idm.lab.eng.brq.redhat.com IPA Server: vm-109.idm.lab.eng.brq.redhat.com BaseDN: dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com Continue to configure the system with these values? [no]: y Synchronizing time with KDC... Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) Kerberos authentication failed kinit: Cannot contact any KDC for realm 'IDM.LAB.ENG.BRQ.REDHAT.COM' while getting initial credentials Installation failed. Rolling back changes. IPA client is not configured on this system. Rob, is the behavior OK? ACK for the implementation. -- Petr? From dpal at redhat.com Tue Apr 30 14:42:18 2013 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 30 Apr 2013 10:42:18 -0400 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <517FB9DE.8000404@redhat.com> References: <5164017C.1000101@redhat.com> <516715C1.9040607@redhat.com> <517FB9DE.8000404@redhat.com> Message-ID: <517FD84A.3020504@redhat.com> On 04/30/2013 08:32 AM, Tomas Babej wrote: > On 04/11/2013 09:57 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> Hi, >>> >>> In ipa-replica-manage commands, we enforce that hostnames we work >>> with are resolvable. However, this caused errors while deleting >>> or disconnecting a ipa / winsync replica, if that replica was down >>> and authoritative server for itself. >>> >>> https://fedorahosted.org/freeipa/ticket/3524 >>> >>> Tomas >> >> I'm not sure this is going to do the right thing either. A lot of >> these commands take the an argument as the remote master to run >> things on, so we'd really only be validating one of the names. Not >> sure how that helps us. >> > Actually, the patch tried to adress that. I carefully reviewed the > effort, now we should be consistent in validating all the names. > >> What if we honor the --force flag for DNS lookup failures instead? >> Or, since that could override it and do other things, a --no-lookup >> flag perhaps? >> >> rob > > I added a --no-lookup flag for ipa-replica-manage that disables host > existence check. A new flag would need a design page. > > Sending both patches rebased. > > Tomas > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pviktori at redhat.com Tue Apr 30 14:54:41 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Apr 2013 16:54:41 +0200 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <517ED7E4.9070204@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> <5179058E.7050306@redhat.com> <517908B2.8000002@redhat.com> <517E7BAC.5000407@redhat.com> <517EB85D.10006@redhat.com> <517ED7E4.9070204@redhat.com> Message-ID: <517FDB31.7080308@redhat.com> On 04/29/2013 10:28 PM, Tomas Babej wrote: > On 04/29/2013 08:13 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 04/25/2013 12:42 PM, Martin Kosek wrote: >>>> On 04/25/2013 12:29 PM, Jan Cholasta wrote: >>>>> On 25.4.2013 08:51, Martin Kosek wrote: >>>>>> On 04/24/2013 08:02 PM, Rob Crittenden wrote: >>>>>>> Jan Cholasta wrote: >>>>>>>> On 24.4.2013 14:54, Martin Kosek wrote: >>>>>>>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> We should respect already configured options present in >>>>>>>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT >>>>>>>>>>>> options. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> the changeConf call will fail when the file does not exist, we >>>>>>>>>>> might >>>>>>>>>>> want to handle that gracefully. >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We also need to handle the case where these items are already >>>>>>>>>> defined. I'm >>>>>>>>>> honestly not sure what the behavior should be: overwrite, warn >>>>>>>>>> and >>>>>>>>>> overwrite, >>>>>>>>>> fail. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>> >>>>>>>>> I am also thinking that we may want to be more cautious before >>>>>>>>> updating this >>>>>>>>> file. AFAIK, we do not need the updated file for our function, its >>>>>>>>> only updated >>>>>>>>> for user convenience so that he can run ldapsearches more easily. >>>>>>>>> >>>>>>>>> I see several options here that could help this goal: >>>>>>>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>>>>>>> options are >>>>>>>>> not set. If the options are already set, we could just print a >>>>>>>>> note >>>>>>>>> that we >>>>>>>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>>>>>>> these options >>>>>>>>> commented out, so it should be possible to implement this check. >>>>>>>>> >>>>>>>>> 2) Do ldap.conf changes only if a new special option is passe >>>>>>>>> (e.g. >>>>>>>>> --configure-ldap-cong) >>>>>>>>> >>>>>>>>> 3) Do not update ldap.conf when a new special option is not >>>>>>>>> passed (e.g. >>>>>>>>> --no-ldap-conf >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> If we don't need the file for our function, we can just not >>>>>>>> configure it >>>>>>>> at all IMO. We can document how to configure it for users who want >>>>>>>> it. >>>>>>> >>>>>>> It was an RFE that we create this file. It is handy to have >>>>>>> pre-configured, I >>>>>>> like having it actually. >>>>>>> >>>>>>> We just need to try to have a gentler touch than my first crack at >>>>>>> it, which >>>>>>> overwrote it completely. I think #1 is probably enough for now. I'm >>>>>>> not sure I >>>>>>> want to add two new options this late in the game, and the client >>>>>>> already has a >>>>>>> lot of knobs. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Yeah, I also agree that 1) is enough. It will not add any more >>>>>> options and will >>>>>> let us be more gentle and respectful to already existent custom user >>>>>> settings >>>>>> in ldap.conf. So Tomas, this seems like the way to go :-) >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I don't see the point of updating only some of these values. What >>>>> about >>>> >>>> Not some of them - either all of them (BASE, URI, TLS_CACERT) when >>>> none of them is already configured or none at all. >>>> >>>>> >>>>> 4) Update BASE and URI and TLS_CACERT, comment any old settings out. >>>>> >>>>> ? >>>> >>>> This would still break an existing user configuration, we would just >>>> tell user what we broke :-) >>>> >>>> Martin >>>> >>>>> >>>>> Honza >>>>> >>>> >>> The following version of the patch configures (BASE, URI, TLS_CACERT) >>> attributes if they are not set. >>> >>> However, to preserve user-friendliness, our suggested option is added as >>> an comment. See commit message for details. >>> >>> Tomas >> >> Ok, this works as advertised, I just have a general question. >> >> This could enable a mix of IPA and non-IPA settings. In my case I left >> BASE configured and only URI and TLS_CACERT got set. >> >> This could cause some unexpected results I think, depending on what >> got changed. >> >> Do we rather want to punt on all of them if any of them can't be >> updated? This would require a bit more code, and wouldn't be as >> generic. I just wonder if this would cause subtle failures. >> >> rob > > After IRC conversation with Rob, we decided to keep the behaviour, while > having it explicitly mentioned in the ldap.conf file. > > For illustration, the ldap.conf file could look like this: > > [/etc/openldap/ldap.conf] > # File modified by ipa-client-install > > # We do not want to break your existing configuration, hence: > # URI, BASE and TLS_CACERT have been added if they were not set. > # In case any of them were set, a comment with trailing note > # "# modified by IPA" note has been inserted. > # To use IPA server with openLDAP tools, please comment out your > # existing configuration for these options and uncomment the > # corresponding lines generated by IPA. > > > # > # LDAP Defaults > # > > # See ldap.conf(5) for details > # This file should be world readable but not world writable. > > #BASE dc=ipa,dc=example,dc=com # modified by IPA > BASE dc=example,dc=com > #URI ldaps://ipa.example.com # modified by IPA > URI ldap://ldap.example.com > > #SIZELIMIT 12 > #TIMELIMIT 15 > #DEREF never > > TLS_CACERTDIR /etc/openldap/cacerts > TLS_CACERT /etc/ipa/ca.crt > > Tomas > [...] > + root_logger.info("Could not parse {path}".format(path=target_fname)) > + root_logger.debug(error_msg.format(path=target_fname, err=str(e))) To my (limited) knowledge, this would be the first Python 2.6+ feature used in the client code. Is it OK? Normally we use multiple arguments for logging: root_logger.info("Could not parse %s", target_fname) Patch works as designed (you get a mix of IPA and non-IPA settings if only some of the options are pre-existing). -- Petr? From rcritten at redhat.com Tue Apr 30 14:54:54 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Apr 2013 10:54:54 -0400 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <517ED7E4.9070204@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> <5179058E.7050306@redhat.com> <517908B2.8000002@redhat.com> <517E7BAC.5000407@redhat.com> <517EB85D.10006@redhat.com> <517ED7E4.9070204@redhat.com> Message-ID: <517FDB3E.5010504@redhat.com> Tomas Babej wrote: > On 04/29/2013 08:13 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> On 04/25/2013 12:42 PM, Martin Kosek wrote: >>>> On 04/25/2013 12:29 PM, Jan Cholasta wrote: >>>>> On 25.4.2013 08:51, Martin Kosek wrote: >>>>>> On 04/24/2013 08:02 PM, Rob Crittenden wrote: >>>>>>> Jan Cholasta wrote: >>>>>>>> On 24.4.2013 14:54, Martin Kosek wrote: >>>>>>>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> We should respect already configured options present in >>>>>>>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT >>>>>>>>>>>> options. >>>>>>>>>>>> >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> the changeConf call will fail when the file does not exist, we >>>>>>>>>>> might >>>>>>>>>>> want to handle that gracefully. >>>>>>>>>>> >>>>>>>>>>> Honza >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We also need to handle the case where these items are already >>>>>>>>>> defined. I'm >>>>>>>>>> honestly not sure what the behavior should be: overwrite, warn >>>>>>>>>> and >>>>>>>>>> overwrite, >>>>>>>>>> fail. >>>>>>>>>> >>>>>>>>>> rob >>>>>>>>>> >>>>>>>>> >>>>>>>>> I am also thinking that we may want to be more cautious before >>>>>>>>> updating this >>>>>>>>> file. AFAIK, we do not need the updated file for our function, its >>>>>>>>> only updated >>>>>>>>> for user convenience so that he can run ldapsearches more easily. >>>>>>>>> >>>>>>>>> I see several options here that could help this goal: >>>>>>>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>>>>>>> options are >>>>>>>>> not set. If the options are already set, we could just print a >>>>>>>>> note >>>>>>>>> that we >>>>>>>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>>>>>>> these options >>>>>>>>> commented out, so it should be possible to implement this check. >>>>>>>>> >>>>>>>>> 2) Do ldap.conf changes only if a new special option is passe >>>>>>>>> (e.g. >>>>>>>>> --configure-ldap-cong) >>>>>>>>> >>>>>>>>> 3) Do not update ldap.conf when a new special option is not >>>>>>>>> passed (e.g. >>>>>>>>> --no-ldap-conf >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> If we don't need the file for our function, we can just not >>>>>>>> configure it >>>>>>>> at all IMO. We can document how to configure it for users who want >>>>>>>> it. >>>>>>> >>>>>>> It was an RFE that we create this file. It is handy to have >>>>>>> pre-configured, I >>>>>>> like having it actually. >>>>>>> >>>>>>> We just need to try to have a gentler touch than my first crack at >>>>>>> it, which >>>>>>> overwrote it completely. I think #1 is probably enough for now. I'm >>>>>>> not sure I >>>>>>> want to add two new options this late in the game, and the client >>>>>>> already has a >>>>>>> lot of knobs. >>>>>>> >>>>>>> rob >>>>>>> >>>>>> >>>>>> Yeah, I also agree that 1) is enough. It will not add any more >>>>>> options and will >>>>>> let us be more gentle and respectful to already existent custom user >>>>>> settings >>>>>> in ldap.conf. So Tomas, this seems like the way to go :-) >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I don't see the point of updating only some of these values. What >>>>> about >>>> >>>> Not some of them - either all of them (BASE, URI, TLS_CACERT) when >>>> none of them is already configured or none at all. >>>> >>>>> >>>>> 4) Update BASE and URI and TLS_CACERT, comment any old settings out. >>>>> >>>>> ? >>>> >>>> This would still break an existing user configuration, we would just >>>> tell user what we broke :-) >>>> >>>> Martin >>>> >>>>> >>>>> Honza >>>>> >>>> >>> The following version of the patch configures (BASE, URI, TLS_CACERT) >>> attributes if they are not set. >>> >>> However, to preserve user-friendliness, our suggested option is added as >>> an comment. See commit message for details. >>> >>> Tomas >> >> Ok, this works as advertised, I just have a general question. >> >> This could enable a mix of IPA and non-IPA settings. In my case I left >> BASE configured and only URI and TLS_CACERT got set. >> >> This could cause some unexpected results I think, depending on what >> got changed. >> >> Do we rather want to punt on all of them if any of them can't be >> updated? This would require a bit more code, and wouldn't be as >> generic. I just wonder if this would cause subtle failures. >> >> rob > > After IRC conversation with Rob, we decided to keep the behaviour, while > having it explicitly mentioned in the ldap.conf file. > > For illustration, the ldap.conf file could look like this: > > [/etc/openldap/ldap.conf] > # File modified by ipa-client-install > > # We do not want to break your existing configuration, hence: > # URI, BASE and TLS_CACERT have been added if they were not set. > # In case any of them were set, a comment with trailing note > # "# modified by IPA" note has been inserted. > # To use IPA server with openLDAP tools, please comment out your > # existing configuration for these options and uncomment the > # corresponding lines generated by IPA. > > > # > # LDAP Defaults > # > > # See ldap.conf(5) for details > # This file should be world readable but not world writable. > > #BASE dc=ipa,dc=example,dc=com # modified by IPA > BASE dc=example,dc=com > #URI ldaps://ipa.example.com # modified by IPA > URI ldap://ldap.example.com > > #SIZELIMIT 12 > #TIMELIMIT 15 > #DEREF never > > TLS_CACERTDIR /etc/openldap/cacerts > TLS_CACERT /etc/ipa/ca.crt > > Tomas ACK, pushed to master rob From rcritten at redhat.com Tue Apr 30 14:58:31 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Apr 2013 10:58:31 -0400 Subject: [Freeipa-devel] [PATCH 0051] Preserve already configured options in openldap conf In-Reply-To: <517FDB31.7080308@redhat.com> References: <51766267.8040504@redhat.com> <5177C1FA.4030005@redhat.com> <5177D566.1090005@redhat.com> <5177D61C.2070407@redhat.com> <5177D9EF.1080005@redhat.com> <51781E4E.4020203@redhat.com> <5178D27B.6060402@redhat.com> <5179058E.7050306@redhat.com> <517908B2.8000002@redhat.com> <517E7BAC.5000407@redhat.com> <517EB85D.10006@redhat.com> <517ED7E4.9070204@redhat.com> <517FDB31.7080308@redhat.com> Message-ID: <517FDC17.1040001@redhat.com> Petr Viktorin wrote: > On 04/29/2013 10:28 PM, Tomas Babej wrote: >> On 04/29/2013 08:13 PM, Rob Crittenden wrote: >>> Tomas Babej wrote: >>>> On 04/25/2013 12:42 PM, Martin Kosek wrote: >>>>> On 04/25/2013 12:29 PM, Jan Cholasta wrote: >>>>>> On 25.4.2013 08:51, Martin Kosek wrote: >>>>>>> On 04/24/2013 08:02 PM, Rob Crittenden wrote: >>>>>>>> Jan Cholasta wrote: >>>>>>>>> On 24.4.2013 14:54, Martin Kosek wrote: >>>>>>>>>> On 04/24/2013 02:51 PM, Rob Crittenden wrote: >>>>>>>>>>> Jan Cholasta wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> On 23.4.2013 12:28, Tomas Babej wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> We should respect already configured options present in >>>>>>>>>>>>> /etc/openldap/ldap.conf when generating our own configuration. >>>>>>>>>>>>> With this patch, we only rewrite URI, BASE and TLS_CACERT >>>>>>>>>>>>> options. >>>>>>>>>>>>> >>>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3582 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> the changeConf call will fail when the file does not exist, we >>>>>>>>>>>> might >>>>>>>>>>>> want to handle that gracefully. >>>>>>>>>>>> >>>>>>>>>>>> Honza >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> We also need to handle the case where these items are already >>>>>>>>>>> defined. I'm >>>>>>>>>>> honestly not sure what the behavior should be: overwrite, warn >>>>>>>>>>> and >>>>>>>>>>> overwrite, >>>>>>>>>>> fail. >>>>>>>>>>> >>>>>>>>>>> rob >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am also thinking that we may want to be more cautious before >>>>>>>>>> updating this >>>>>>>>>> file. AFAIK, we do not need the updated file for our function, >>>>>>>>>> its >>>>>>>>>> only updated >>>>>>>>>> for user convenience so that he can run ldapsearches more easily. >>>>>>>>>> >>>>>>>>>> I see several options here that could help this goal: >>>>>>>>>> 1) Update ldap.conf if BASE and URI and TLS_CACERT only if these >>>>>>>>>> options are >>>>>>>>>> not set. If the options are already set, we could just print a >>>>>>>>>> note >>>>>>>>>> that we >>>>>>>>>> skipped it. When I see my vanilla /etc/openldap/ldap.conf, it has >>>>>>>>>> these options >>>>>>>>>> commented out, so it should be possible to implement this check. >>>>>>>>>> >>>>>>>>>> 2) Do ldap.conf changes only if a new special option is passe >>>>>>>>>> (e.g. >>>>>>>>>> --configure-ldap-cong) >>>>>>>>>> >>>>>>>>>> 3) Do not update ldap.conf when a new special option is not >>>>>>>>>> passed (e.g. >>>>>>>>>> --no-ldap-conf >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>> >>>>>>>>> If we don't need the file for our function, we can just not >>>>>>>>> configure it >>>>>>>>> at all IMO. We can document how to configure it for users who want >>>>>>>>> it. >>>>>>>> >>>>>>>> It was an RFE that we create this file. It is handy to have >>>>>>>> pre-configured, I >>>>>>>> like having it actually. >>>>>>>> >>>>>>>> We just need to try to have a gentler touch than my first crack at >>>>>>>> it, which >>>>>>>> overwrote it completely. I think #1 is probably enough for now. I'm >>>>>>>> not sure I >>>>>>>> want to add two new options this late in the game, and the client >>>>>>>> already has a >>>>>>>> lot of knobs. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> Yeah, I also agree that 1) is enough. It will not add any more >>>>>>> options and will >>>>>>> let us be more gentle and respectful to already existent custom user >>>>>>> settings >>>>>>> in ldap.conf. So Tomas, this seems like the way to go :-) >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> I don't see the point of updating only some of these values. What >>>>>> about >>>>> >>>>> Not some of them - either all of them (BASE, URI, TLS_CACERT) when >>>>> none of them is already configured or none at all. >>>>> >>>>>> >>>>>> 4) Update BASE and URI and TLS_CACERT, comment any old settings out. >>>>>> >>>>>> ? >>>>> >>>>> This would still break an existing user configuration, we would just >>>>> tell user what we broke :-) >>>>> >>>>> Martin >>>>> >>>>>> >>>>>> Honza >>>>>> >>>>> >>>> The following version of the patch configures (BASE, URI, TLS_CACERT) >>>> attributes if they are not set. >>>> >>>> However, to preserve user-friendliness, our suggested option is >>>> added as >>>> an comment. See commit message for details. >>>> >>>> Tomas >>> >>> Ok, this works as advertised, I just have a general question. >>> >>> This could enable a mix of IPA and non-IPA settings. In my case I left >>> BASE configured and only URI and TLS_CACERT got set. >>> >>> This could cause some unexpected results I think, depending on what >>> got changed. >>> >>> Do we rather want to punt on all of them if any of them can't be >>> updated? This would require a bit more code, and wouldn't be as >>> generic. I just wonder if this would cause subtle failures. >>> >>> rob >> >> After IRC conversation with Rob, we decided to keep the behaviour, while >> having it explicitly mentioned in the ldap.conf file. >> >> For illustration, the ldap.conf file could look like this: >> >> [/etc/openldap/ldap.conf] >> # File modified by ipa-client-install >> >> # We do not want to break your existing configuration, hence: >> # URI, BASE and TLS_CACERT have been added if they were not set. >> # In case any of them were set, a comment with trailing note >> # "# modified by IPA" note has been inserted. >> # To use IPA server with openLDAP tools, please comment out your >> # existing configuration for these options and uncomment the >> # corresponding lines generated by IPA. >> >> >> # >> # LDAP Defaults >> # >> >> # See ldap.conf(5) for details >> # This file should be world readable but not world writable. >> >> #BASE dc=ipa,dc=example,dc=com # modified by IPA >> BASE dc=example,dc=com >> #URI ldaps://ipa.example.com # modified by IPA >> URI ldap://ldap.example.com >> >> #SIZELIMIT 12 >> #TIMELIMIT 15 >> #DEREF never >> >> TLS_CACERTDIR /etc/openldap/cacerts >> TLS_CACERT /etc/ipa/ca.crt >> >> Tomas >> > [...] >> + root_logger.info("Could not parse >> {path}".format(path=target_fname)) >> + root_logger.debug(error_msg.format(path=target_fname, >> err=str(e))) > > To my (limited) knowledge, this would be the first Python 2.6+ feature > used in the client code. Is it OK? Yes, we have no plans to rebase 3.x back to an older distro. It may make backporting patches interesting at some point but we'll cross that bridge if we come to it. rob From rcritten at redhat.com Tue Apr 30 15:10:43 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Apr 2013 11:10:43 -0400 Subject: [Freeipa-devel] [PATCH] 130 Add support for OpenSSH 6.2 (was Re: [PATCH] 130 Drop support for OpenSSH versions before 6.2) In-Reply-To: <20130430124149.GI7607@redhat.com> References: <51702C6D.70900@redhat.com> <5171813C.10502@redhat.com> <51753A92.5020208@redhat.com> <517EC2CB.3010401@redhat.com> <517F89F1.7000604@redhat.com> <517FB53A.5070706@redhat.com> <20130430124149.GI7607@redhat.com> Message-ID: <517FDEF3.6000307@redhat.com> Alexander Bokovoy wrote: > On Tue, 30 Apr 2013, Petr Viktorin wrote: >> On 04/30/2013 11:08 AM, Jan Cholasta wrote: >>> On 29.4.2013 20:58, Rob Crittenden wrote: >>>> Alexander pointed out that we can use the user nobody to run these >>>> commands rather than running as the user who requested it, %u. >>> >>> Added. >>> >>>> >>>> For the purposes of development, this is going to commit everyone to >>>> moving to F-19 now. Is that acceptable or do we want to wrap this >>>> with a >>>> conditional for some period? >>> >>> I have changed the patch to add support for openssh 6.2 without dropping >>> support for older openssh versions. We can drop support for older >>> openssh versions in IPA 3.3. See attachment. >>> >>> Honza >> >> Works for me, so ACK unless someone more experienced with SSH wants to >> take a look. > Works for me too and looks OK. > > ACK. > pushed to master and ipa-3-1 rob From pviktori at redhat.com Tue Apr 30 15:24:28 2013 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 30 Apr 2013 17:24:28 +0200 Subject: [Freeipa-devel] [PATCH 0045] Enforce host existence only where needed in ipa-replica-manage In-Reply-To: <517FB9DE.8000404@redhat.com> References: <5164017C.1000101@redhat.com> <516715C1.9040607@redhat.com> <517FB9DE.8000404@redhat.com> Message-ID: <517FE22C.50607@redhat.com> On 04/30/2013 02:32 PM, Tomas Babej wrote: > On 04/11/2013 09:57 PM, Rob Crittenden wrote: >> Tomas Babej wrote: >>> Hi, >>> >>> In ipa-replica-manage commands, we enforce that hostnames we work >>> with are resolvable. However, this caused errors while deleting >>> or disconnecting a ipa / winsync replica, if that replica was down >>> and authoritative server for itself. >>> >>> https://fedorahosted.org/freeipa/ticket/3524 >>> >>> Tomas >> >> I'm not sure this is going to do the right thing either. A lot of >> these commands take the an argument as the remote master to run things >> on, so we'd really only be validating one of the names. Not sure how >> that helps us. >> > Actually, the patch tried to adress that. I carefully reviewed the > effort, now we should be consistent in validating all the names. > >> What if we honor the --force flag for DNS lookup failures instead? Or, >> since that could override it and do other things, a --no-lookup flag >> perhaps? >> >> rob > > I added a --no-lookup flag for ipa-replica-manage that disables host > existence check. > > Sending both patches rebased. > > Tomas The nolookup argument is never passed to get_ruv() when it is called by list_ruv, get_rid_by_host, clean_ruv, abort_clean_ruv. Some of these don't take the argument but are called with it. Lint error: install/tools/ipa-replica-manage:1188: [E1121, main] Too many positional arguments for function call nolookup is also not passed to list_clean_ruv(), re_initialize(), force_sync(), show_DNA_ranges() etc. Git complains about some extra whitespace: Applying: Enforce host existence only where needed in ipa-replica-manage /home/pviktori/freeipa/.git/rebase-apply/patch:234: new blank line at EOF. + warning: 1 line adds whitespace errors. -- Petr? From pvoborni at redhat.com Tue Apr 30 15:31:42 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 30 Apr 2013 17:31:42 +0200 Subject: [Freeipa-devel] [PATCH] 276 Fix: Certificate status is not visible in Service and Host page In-Reply-To: <517E53E7.1000904@redhat.com> References: <517AAEA0.2040306@redhat.com> <517E53E7.1000904@redhat.com> Message-ID: <517FE3DE.2070702@redhat.com> On 04/29/2013 01:05 PM, Ana Krivokapic wrote: > On 04/26/2013 06:43 PM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/3593 > > ACK > Pushed to master. -- Petr Vobornik From pvoborni at redhat.com Tue Apr 30 17:19:03 2013 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 30 Apr 2013 19:19:03 +0200 Subject: [Freeipa-devel] Web UI refactoring effort ready for review In-Reply-To: <517AA817.1080303@redhat.com> References: <51756B5E.8030604@redhat.com> <5177F259.4060100@redhat.com> <51795BE6.9090405@redhat.com> <517A5C3C.4010005@redhat.com> <517A8FF2.6090107@redhat.com> <517AA817.1080303@redhat.com> Message-ID: <517FFD07.3010607@redhat.com> Update: * rebased on current master an force-pushed to private repo * fixed crash when IPA installed without CA * fixed bugs found by automated tests ** crash on ssh key add ** crash on host deletion * added design page for #3236: http://www.freeipa.org/page/V3/WebUI_extensible_navigation * enabled adding facets without entity into menu (untested) Attaching two simple example plugins. * simpleuser: replaces selfservice page with simpler one * usermod: moves initials field in user page ** example of adding a field ** example of deleting a field ** tries Spec_mod utility which proved to not be much useful yet because it's search is limited only to one array, which is not enough To test the plugins put them into: /usr/share/ipa/ui/js/plugins/usermod /usr/share/ipa/ui/js/plugins/simpleuser On 04/26/2013 06:15 PM, Petr Vobornik wrote: > Another problem found: trustconfig had invalid spec which made the trust > section quite unusable. > > Fixed and pushed to the private repo. > > I also took an opportunity and added missing parts of trust metadata for > static testing. > > On 04/26/2013 04:32 PM, Petr Vobornik wrote: >> Hi, >> >> 1, 2 and 3a are fixed and pushed to the private repo. Rest won't be >> fixed during the refactoring. >> >> I changed SingletonRegistry behavior that it returns null when >> builder/construction spec is missing. It's more consistent with build of >> unsupported entities (also returns null). > -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: simpleuser.js Type: application/javascript Size: 2789 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: usermod.js Type: application/javascript Size: 1900 bytes Desc: not available URL: From rcritten at redhat.com Tue Apr 30 19:22:34 2013 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 30 Apr 2013 15:22:34 -0400 Subject: [Freeipa-devel] [PATCH] 1099 fix --no-sssd enrollment Message-ID: <518019FA.10307@redhat.com> Fix client enrollment when using --no-sssd and nss-pam-ldapd. At version 0.8.4 the default was changed to map uniqueMember to member so a mapping is no longer required, or possible. This causes the daemon to not load. Remove the option and add a Conflicts on older versions. This is more a problem in F-18. I propose we backport this patch to the ipa-3-1 branch. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1099-nslcd.patch Type: text/x-diff Size: 2626 bytes Desc: not available URL: From npmccallum at redhat.com Tue Apr 30 21:46:33 2013 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Tue, 30 Apr 2013 17:46:33 -0400 Subject: [Freeipa-devel] [PATCH] krb 1.12's OTP-Over-RADIUS In-Reply-To: <517B0017.8070209@redhat.com> References: <1362592570.12650.7.camel@localhost.localdomain> <1362593086.12650.8.camel@localhost.localdomain> <1362754217.2822.121.camel@willson.li.ssimo.org> <1362754629.9093.10.camel@localhost.localdomain> <515DA36E.7020003@redhat.com> <1365543559.2015.20.camel@localhost.localdomain> <5165BF14.40209@redhat.com> <1365703973.21323.8.camel@localhost.localdomain> <5167058C.5070501@redhat.com> <1365780899.21323.30.camel@localhost.localdomain> <1365782020.21323.33.camel@localhost.localdomain> <1365802766.21323.36.camel@localhost.localdomain> <1366292936.17909.3.camel@localhost.localdomain> <517B0017.8070209@redhat.com> Message-ID: <1367358393.29302.4.camel@localhost.localdomain> On Fri, 2013-04-26 at 18:30 -0400, Rob Crittenden wrote: > Nathaniel McCallum wrote: > > On Fri, 2013-04-12 at 17:39 -0400, Nathaniel McCallum wrote: > >> On Fri, 2013-04-12 at 11:53 -0400, Nathaniel McCallum wrote: > >>> On Fri, 2013-04-12 at 11:34 -0400, Nathaniel McCallum wrote: > >>>> On Thu, 2013-04-11 at 14:48 -0400, Rob Crittenden wrote: > >>>>> Nathaniel McCallum wrote: > >>>>>> On Wed, 2013-04-10 at 15:35 -0400, Rob Crittenden wrote: > >>>>>>> I'm not sure how I'd test it if I got it built. > >>>>>> > >>>>>> I'm working on this. I hope to have a clear answer next week. Bear with > >>>>>> me... > >>>>>> > >>>>>>> Overall looks really good. > >>>>>> > >>>>>> I've split up the patch into multiple commits. I've also added .update > >>>>>> files and a patch for ipa-kdb to feed krb5 the right user string. > >>>>>> > >>>>>> https://github.com/npmccallum/freeipa/commits/otp > >>>>>> > >>>>>> Please take a look. I *think* I've got everything worked out so far with > >>>>>> the exception of bug numbers / urls. Should every patch have a separate > >>>>>> bug and a link to the design page? > >>>>> > >>>>> The ticket should go into every commit. I'd probably put the design link > >>>>> there too, just for completeness. Future bug fixes, et all aren't going > >>>>> to require the design page, but since these commits are all related to > >>>>> the initial feature it will be nice to have. > >>>>> > >>>>> You can have multiple patches on the same ticket/bug. > >>>> > >>>> https://github.com/npmccallum/freeipa/commits/otp > >>>> > >>>> All four commits now have bug numbers and design page links. I'm adding > >>>> the design page link to the tickets as we speak. > >>>> > >>>> Remaining issues (AFAICS): > >>>> 1. The daemon (ipa-otpd) runs as root and binds anonymously > >>>> 2. ipatokenRadiusSecret is readable by an anonymous bind > >>> 3. ipatokenT?OTP.* are readable by an anonymous bind > >>> > >>> In the case of both #2 and #3, only admins should have RW. ipa-otpd > >>> needs read access to ipatokenRadiusSecret. The DS bind plugin below (#2) > >>> needs read access to ipatokenT?OTP.*. > >>> > >>>> Outstanding pieces: > >>>> 1. CLI tool -- https://fedorahosted.org/freeipa/ticket/3368 > >>>> 2. DS bind plugin -- https://fedorahosted.org/freeipa/ticket/3367 > >>>> 3. UI -- https://fedorahosted.org/freeipa/ticket/3369 > >>>> 4. Self Service UI -- https://fedorahosted.org/freeipa/ticket/3370 > >>>> > >>>> #1 and #2 are within the scope of F19 and should hopefully land shortly > >>>> (in separate commits). #3 and #4 are probably $nextrelease. > >>>> > >> > >> FYI - Here is an RPM with all of the code so far: > >> http://koji.fedoraproject.org/koji/taskinfo?taskID=5247029 > > > > Updated RPMs, containing the new 389DS bind plugin and build for F19, > > are here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=5270926 > > > > Nathaniel > > BuildRequires needed for whatever provides krad.h It is there already. I updated the spec file to have a hard dependency on krb5 >= 1.11. > A bunch of the files declare functions in each other. Is it cleaner to > put these into an include file? I'm gathering that this will always be > self-contained, so maybe this is ok. Most of the functions are only needed in one other file. I thought this was cleaner. I'm also open to suggestions on how to better split the files so there are less includes... > In entry_attr_get_berval() is it worth pointing out that there is no > need to free the value, or is that assumed because it uses > slapi_value_get_berval()? I would hope it is assumed by const. > If we detect that there is clock drift should we log it? Will we ever > try to report to the client (e.g. future enhancement)? There are lots of clock related enhancements that should be low-hanging fruit. > I wonder if the NSPR-version of some functions should be used since this > is running inside 389-ds, like PL_strcasecmp for strcasecmp() I did not fix this since strcasecmp() is available everywhere. > ops.c: > > pedantic: lack of spacing between if and parens Fixed. > sha384 is an allowed type only in otp.c. Is that needed? The RFC doesn't specify sha384 support. However, adding support for it is somewhat obvious. In the spirit of "being liberal in what you receive, strict in what you send" I added sha384 support in auth.c. Nathaniel