Re: [Freeipa-devel] [PATCH] 1067 clear out certmonger requests
On 31.10.2012 16:28, Rob Crittenden wrote: Jan Cholasta wrote: On 29.10.2012 20:11, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 24.10.2012 21:22, Rob Crittenden wrote: If uninstall fails in certain ways it is possible that some certificates could still be tracked by certmonger (even if the NSS database is now gone). This will loop through the directories we care about and warn the user if there is anything left over. I added some basic test instructions to the ticket. rob You should check the return value of find_request_value, it can be None in case of error. I would prefer if you used os.path.join(REQUEST_DIR, file) instead of '%s/%s' % (REQUEST_DIR, file). There is a trailing whitespace in the patch on line 75. Honza fixed. rob This will still break if find_request_value returns None: +for file in fileList: +rv = find_request_value(os.path.join(REQUEST_DIR, file), +'cert_storage_location') +if rv: +rv = os.path.abspath(rv) +if rv.rstrip() == dir: +id = find_request_value(os.path.join(REQUEST_DIR, file), 'id').rstrip() +if id is not None: +reqid.append(id) I would suggest to do it like this instead: +for file in fileList: +rv = find_request_value(os.path.join(REQUEST_DIR, file), +'cert_storage_location') +if rv is None: +continue +rv = os.path.abspath(rv).rstrip() +if rv != dir: +continue +id = find_request_value(os.path.join(REQUEST_DIR, file), 'id') +if id is not None: +reqid.append(id.rstrip()) Honza OK, great suggestion, sorry I didn't grok it sooner. Updated patch attached. rob You missed one spot: +id = find_request_value(os.path.join(REQUEST_DIR, file), 'id') +if id is not None: +reqid.append(id.rstrip()) Also there is a trailing whitespace on line 73 of the patch. Once you fix this, ACK. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Dojo and Web UI in 3.2
On 10/31/2012 11:13 PM, Dmitri Pal wrote: On 10/30/2012 01:20 PM, Petr Vobornik wrote: On 10/30/2012 06:48 AM, Endi Sukma Dewata wrote: On 10/29/2012 4:27 AM, Petr Vobornik wrote: Hi, I would like to make a bigger change in Web UI. Basically I think Web UI would benefit from using a Dojo toolkit, a JS framework. I would like to know if I can proceed with incorporating it. I think this is the best time (end of 3.0/3.1 and a beginning of 3.2) to do such change. I don't know about the timing, but I agree we need a better framework. This was also discussed some time ago with Adam. Why Dojo? - It may solve several existing issues in Web UI architecture/code structure. TLDR version: * incorporates a lot of functionality we don't have to write * is considered to be a framework for enterprise class web applications * reuse an establish library which may be known to more developers then custom build in-house solution * makes code more maintainable * opportunity to separate Web UI framework and IPA specific parts Some functionality of Dojo overlaps with jquery which is not good, but the reason to use Dojo are the features jquery lacks. I also look on other frameworks or independent libraries: AngularJS, backbone.js, closure js framework and several single-purpose libraries (crossroads, hasher, underscore, amd-utils,. IMO Dojo is the best fit for us. I have not used Dojo or any of the above frameworks so I can't really say anything good/bad about them, but backbone.js also seems to be a popular lightweight alternative if we aren't planning to use the Dijit. We should consider whether a framework will work nicely with others or whether it will require us to use it for everything. I fear that with backbone.js we would have to rewrite the whole UI to not bend the framework much. From looking at examples IDK how would we incorporate it. I think it would be a nice candidate if we would rewrite UI from scratch. I like Dojo because we can make the changes gradual. In theory we can just utilize the things from dojo which we want and leave the rest untouched. If possible, we should try to address the issues below independently from each other (even if we end up using Dojo for everything) while we're still learning about it. Some of the issues are actually general design issues, so it won't be solved simply by converting the framework. Try to avoid refactoring the code and converting the framework at the same time because the patch could become very big and hard to review. I agree. Originally I was just looking if there is some small library which has a reasonable implementation for bindable object store. To keep with saying: best code is the one you don't have to write. I ended with Dojo because it can do a lot of stuff we might need in time. Of course all of dojo functionality can be replaced with other libraries but I think it's better to use one (and because of AMD modules, we can create small custom build) and not to worry about making them all work together. From Dojo I would like to use: ### 1) Build system and AMD modules Web UI doesn't use any JavaScript optimizer therefore we need to keep low file count and minimum size of files. We share one file for multiple components to keep the file count low. It leads to very long files. It's harder to maintain than separate files for each component. AMD modules and a builder can solve it. AMD modules [1] encourages to use one file per component. Then a dojo builder can be used to modify the declaration of a module for file concatenation then it can be sent to JavaScript minifier/compiler. Dojo builder [2] is quite powerfull, it can define 'layers' which serves as a part of application - basically a sets of component so an application with ie. 150 files can be compile to one or more (if needed) .js. Dojo loader takes care of the loading. AFAIU build system can be run at rpm build time using rhino (version 1.7R3-4 needed). Uglify.js can be used as a compiler, it's JS library and can be run in rhino too. The builder and uglify.js would be needed to budle in our source tarball but they won't be in output rpms so they shouldn't break Fedora packaging rules. Both are BSD licensed. Builder would need a patch to support Uglify (it's commited in dojo upstream trac but I want to incorporated it in latest stable version). [1] http://dojotoolkit.org/documentation/tutorials/1.8/modules/ [2] http://dojotoolkit.org/documentation/tutorials/1.8/build/ I suppose now if we want to test the static page without web server we will need to build the pages first? It's not necessary. For developing purposes it is better to use uncompiled files. Loader can load each separate file (if it's AMD module) if it isn't in bundle. If we use Dojo do we need to include Dojo js files into IPA source, or can we use the ones from Dojo rpm and only include it at build time? I'm for including it because we can create a build with the parts we actually use. Dojo
[Freeipa-devel] RFC: freeipa-asterisk plugin
Hi all, we plan to write a freeIPA configuration plugin for Asterisk, aiming to be general and useful enough to be included in Fedora and EPEL, so we would like to have your input on some issues before we write any code. I wrote down the plans so far on this wiki page: https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk Basically we would like to know if: * It is ok to use cn=asterisk as the base object * The planned DIT, separating object per type and not per site, is ok * The whole stuff of using CoS as a mechanism to apply default values to every new object seems right Another issue is that Asterisk SIP objects in real life are generally associated with real people and with physical devices. The physical devices are configured with a piece of software called the endpoint manager, which could pull from the directory the data required to generate the IP phones configuration. We have to choices here. Store the IP phone extra data _with_ the Asterisk SIP object, adding a ieee802device objectClass to the asteriskSIPuser object. The other option is to store the ieee802device object separately in a more appropriate part of the IPA tree and have it reference the SIP object vía a seeAlso or managedBy attribute. As for linking SIP users to real people, it would be great to link the asteriskSIPuser object to an IPA user, but probably not all organizations interested in this kind of functionality for Asterisk would manage all of their users with IPA. What if the real user belongs to a trusted directory, for example? So it seems that for simplicity's sake we will have to store the name of the person using the phone in the asteriskSIPuser description attribute. Speaking of packaging, reading http://abbra.fedorapeople.org/guide.html it doesn't seems clear to me how to have an extra category of configuration pages added to the Web UI without modifying the main IPA page. What is the proper way to add extra pages to the web UI ? Thanks in advance for your input! -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve If I'd asked my customers what they wanted, they'd have said a faster horse - Henry Ford ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Dojo and Web UI in 3.2
On 11/01/2012 09:25 AM, Petr Vobornik wrote: On 10/31/2012 11:13 PM, Dmitri Pal wrote: On 10/30/2012 01:20 PM, Petr Vobornik wrote: On 10/30/2012 06:48 AM, Endi Sukma Dewata wrote: On 10/29/2012 4:27 AM, Petr Vobornik wrote: Hi, I would like to make a bigger change in Web UI. Basically I think Web UI would benefit from using a Dojo toolkit, a JS framework. I would like to know if I can proceed with incorporating it. I think this is the best time (end of 3.0/3.1 and a beginning of 3.2) to do such change. I don't know about the timing, but I agree we need a better framework. This was also discussed some time ago with Adam. Looked into Dojo. My take was that the support of JQuery was more important than what Dojo provided. I still feel that is the case.If you are going to adopt a framework, choose one that is built on JQuery. We also wanted to make the Entity definition as declarative as possible, and we didn't want to be driven by another developers view of M-V-C. I still feel this is most important. There are certainly things I would want to tighten up in the IPA UI. I am not sure that the construction policy (no new keywords) was the absolute best choice. Why Dojo? - It may solve several existing issues in Web UI architecture/code structure. TLDR version: * incorporates a lot of functionality we don't have to write * is considered to be a framework for enterprise class web applications * reuse an establish library which may be known to more developers then custom build in-house solution * makes code more maintainable * opportunity to separate Web UI framework and IPA specific parts Some functionality of Dojo overlaps with jquery which is not good, but the reason to use Dojo are the features jquery lacks. I also look on other frameworks or independent libraries: AngularJS, backbone.js, closure js framework and several single-purpose libraries (crossroads, hasher, underscore, amd-utils,. IMO Dojo is the best fit for us. I have not used Dojo or any of the above frameworks so I can't really say anything good/bad about them, but backbone.js also seems to be a popular lightweight alternative if we aren't planning to use the Dijit. We should consider whether a framework will work nicely with others or whether it will require us to use it for everything. I fear that with backbone.js we would have to rewrite the whole UI to not bend the framework much. From looking at examples IDK how would we incorporate it. I think it would be a nice candidate if we would rewrite UI from scratch. I like Dojo because we can make the changes gradual. In theory we can just utilize the things from dojo which we want and leave the rest untouched. If possible, we should try to address the issues below independently from each other (even if we end up using Dojo for everything) while we're still learning about it. Some of the issues are actually general design issues, so it won't be solved simply by converting the framework. Try to avoid refactoring the code and converting the framework at the same time because the patch could become very big and hard to review. I agree. Originally I was just looking if there is some small library which has a reasonable implementation for bindable object store. To keep with saying: best code is the one you don't have to write. I ended with Dojo because it can do a lot of stuff we might need in time. Of course all of dojo functionality can be replaced with other libraries but I think it's better to use one (and because of AMD modules, we can create small custom build) and not to worry about making them all work together. From Dojo I would like to use: ### 1) Build system and AMD modules Web UI doesn't use any JavaScript optimizer therefore we need to keep low file count and minimum size of files. We share one file for multiple components to keep the file count low. It leads to very long files. It's harder to maintain than separate files for each component. AMD modules and a builder can solve it. AMD modules [1] encourages to use one file per component. Then a dojo builder can be used to modify the declaration of a module for file concatenation then it can be sent to JavaScript minifier/compiler. I like the concept of modules, but make sure whatever you use works well with the debugger. Keep development as straightforward as possible. I would take a performance hit at application load time if it means that the user sees the same thing as the developer: it will pay off in the long haul. Dojo builder [2] is quite powerfull, it can define 'layers' which serves as a part of application - basically a sets of component so an application with ie. 150 files can be compile to one or more (if needed) .js. Dojo loader takes care of the loading. AFAIU build system can be run at rpm build time using rhino (version 1.7R3-4 needed). Uglify.js can be used as a compiler, it's JS library and can be run in rhino too. The builder and
Re: [Freeipa-devel] [PATCH] 1067 clear out certmonger requests
Jan Cholasta wrote: On 31.10.2012 16:28, Rob Crittenden wrote: Jan Cholasta wrote: On 29.10.2012 20:11, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 24.10.2012 21:22, Rob Crittenden wrote: If uninstall fails in certain ways it is possible that some certificates could still be tracked by certmonger (even if the NSS database is now gone). This will loop through the directories we care about and warn the user if there is anything left over. I added some basic test instructions to the ticket. rob You should check the return value of find_request_value, it can be None in case of error. I would prefer if you used os.path.join(REQUEST_DIR, file) instead of '%s/%s' % (REQUEST_DIR, file). There is a trailing whitespace in the patch on line 75. Honza fixed. rob This will still break if find_request_value returns None: +for file in fileList: +rv = find_request_value(os.path.join(REQUEST_DIR, file), +'cert_storage_location') +if rv: +rv = os.path.abspath(rv) +if rv.rstrip() == dir: +id = find_request_value(os.path.join(REQUEST_DIR, file), 'id').rstrip() +if id is not None: +reqid.append(id) I would suggest to do it like this instead: +for file in fileList: +rv = find_request_value(os.path.join(REQUEST_DIR, file), +'cert_storage_location') +if rv is None: +continue +rv = os.path.abspath(rv).rstrip() +if rv != dir: +continue +id = find_request_value(os.path.join(REQUEST_DIR, file), 'id') +if id is not None: +reqid.append(id.rstrip()) Honza OK, great suggestion, sorry I didn't grok it sooner. Updated patch attached. rob You missed one spot: +id = find_request_value(os.path.join(REQUEST_DIR, file), 'id') +if id is not None: +reqid.append(id.rstrip()) Also there is a trailing whitespace on line 73 of the patch. Once you fix this, ACK. Honza Done, pushed to master and ipa-3-0 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 1070 change user_u context in list
The default user_u context in the selnux user map list didn't match what is actually the selinux default context. This could be confusing, so change it to match what systems will have. rob From ccfabc84a08020917b2c744661e64a51cb1bca53 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Thu, 1 Nov 2012 10:13:01 -0400 Subject: [PATCH] Set MLS/MCS for user_u context to what will be on remote systems. The user_u context in the default list was broader than is actually configured by default on systems. https://fedorahosted.org/freeipa/ticket/3224 --- install/share/bootstrap-template.ldif | 2 +- install/updates/50-ipaconfig.update | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/install/share/bootstrap-template.ldif b/install/share/bootstrap-template.ldif index a17f2518fce89232e6339fa1fdce508dd2c8f45c..bf7de348933433c82617f4acf33b7093e76ac959 100644 --- a/install/share/bootstrap-template.ldif +++ b/install/share/bootstrap-template.ldif @@ -381,7 +381,7 @@ ipaUserObjectClasses: ipasshuser ipaDefaultEmailDomain: $DOMAIN ipaMigrationEnabled: FALSE ipaConfigString: AllowNThash -ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0-s0:c0.c1023$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023 +ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023 ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023 dn: cn=cosTemplates,cn=accounts,$SUFFIX diff --git a/install/updates/50-ipaconfig.update b/install/updates/50-ipaconfig.update index 0992db4ec92c3cc254bf8d05892dd4abd9988d8c..69783f13261cfd969d37fdd0e00f2adf8bd66355 100644 --- a/install/updates/50-ipaconfig.update +++ b/install/updates/50-ipaconfig.update @@ -1,5 +1,5 @@ dn: cn=ipaConfig,cn=etc,$SUFFIX -add:ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0-s0:c0.c1023$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023 +add:ipaSELinuxUserMapOrder: guest_u:s0$$xguest_u:s0$$user_u:s0$$staff_u:s0-s0:c0.c1023$$unconfined_u:s0-s0:c0.c1023 add:ipaSELinuxUserMapDefault: unconfined_u:s0-s0:c0.c1023 add:ipaUserObjectClasses: ipasshuser -- 1.7.11.4 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Get list of service from LDAP only at startup
Rob Crittenden wrote: Simo Sorce wrote: From: Simo Sorce sso...@redhat.com We check (possibly different) data from LDAP only at (re)start. This way we always shutdown exactly the services we started even if the list changed in the meanwhile (we avoid leaving a service running even if it was removed from LDAP as the admin decided it should not be started in future). This should also fix a problematic deadlock with systemd when we try to read the list of service from LDAP at shutdown. This fixes things for me but ipactl start isn't working reliably and I've yet to determine if it is related or not (I'm thinking not). What I see is that it considers pki-tomcatd to not have started. What is happening is the request to the getStatus URI is timing out and that exception is being considered a didn't start. I modified the code to treat a timeout as a 503 and it is still failing because the timeout is so longer that it eats up all our normal timeout for waiting for the service at all. I don't see a way to pass a timeout to the http request method, I'll keep looking. I'm testing in F-18 btw. I can't reproduce the startup issues this morning, I still don't think they are related to this patch, so ACK. pushed all 3 to master and ipa-3-0 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA
Hi, On 24.10.2012 21:24, Rob Crittenden wrote: All the certs are pretty critical in certificate renewal but the agent cert has the distinction of having to be updated in multiple places. It needs to exist in both LDAP servers. It is possible that one or both of these servers may be down briefly during renewal so we need to be a bit more robust in our handling. This will wait up to 5 minutes per server to try to update things, and syslog when failures occur. It is now also safe to re-run this in case something catastrophic happens. One would just need to manually run this to load the required data into LDAP. rob I believe that there should be a break statement after the updated = True line: +updated = True +except errors.NetworkError: It would be nice if this message said 30 s instead of just 30: +syslog.syslog(syslog.LOG_ERR, 'Connection to %s failed, sleeping 30' % dogtag_uri) The continue statement is redundant: +attempts += 1 +continue except errors.EmptyModlist: The variables you access in both of the finally blocks (conn and tmpdir) may be unbound. This can be fixed like this: while attempts 10: conn = None tmpdir = None try: ... finally: if conn is not None and conn.isconnected(): conn.disconnect() if tmpdir is not None: shutil.rmtree(tmpdir) It would be nice if this message (both instances of it) included sys.argv[0], so that it is obvious to the user what script is this script: +syslog.syslog(syslog.LOG_ERR, 'Giving up. This script may be safely re-executed.') No spaces in kwarg assignment please: +tmpdir = tempfile.mkdtemp(prefix = tmp-) You might want to include sleeping 30 s in this message as well: +except Exception, e: +syslog.syslog(syslog.LOG_ERR, 'Updating renewal certificate failed: %s' % e) +time.sleep(30) Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On Thu, 2012-11-01 at 09:30 -0430, Loris Santamaria wrote: Hi all, we plan to write a freeIPA configuration plugin for Asterisk, aiming to be general and useful enough to be included in Fedora and EPEL, so we would like to have your input on some issues before we write any code. Hi Loris, this is really exciting! I wrote down the plans so far on this wiki page: https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk Basically we would like to know if: * It is ok to use cn=asterisk as the base object This looks like a good choice, maybe check with the asterisk people if they are ok with using the name that way ? Anyway any product specific name would work here, as it makes it extremely unlikely to clash with any future work in upstream FreeIPA or for any custom data in users' sites. * The planned DIT, separating object per type and not per site, is ok * The whole stuff of using CoS as a mechanism to apply default values to every new object seems right CoS may have some performance implications, and some usage implication, you need to evaluate if you are ok with those, but in general setting defaults is its job so it may be a good fit. I am CCing Nathan and Rich to ask them about the CoS definitions and whether using that many attributes would be problematic, so far I've only seen CoS used for overriding a single attribute so I am not sure what are the implications with that many. (Nathan, Rich, can you take a quick look at the paragraph named 'CoS definition entries' around the middle of the github wiki page pointed by Loris ?) Another issue is that Asterisk SIP objects in real life are generally associated with real people and with physical devices. The physical devices are configured with a piece of software called the endpoint manager, which could pull from the directory the data required to generate the IP phones configuration. We have to choices here. Store the IP phone extra data _with_ the Asterisk SIP object, adding a ieee802device objectClass to the asteriskSIPuser object. The other option is to store the ieee802device object separately in a more appropriate part of the IPA tree and have it reference the SIP object vía a seeAlso or managedBy attribute. I am not sure that there is an actual 'more appropriate' part of the tree. Although we do manage 'devices' (computer objects) that is for machines that are joined to the IPA domain so it would not be applicable in cases where the device can't actually 'join' an ipa domain. However I would stay flexible here and allow both cases. Ie allow to have objects both within the cn=asterisk subtree or in some other subtree. The ieee802device is an auxiliary class so it can be associated with any object in the schema at any time. The AsteriskSIPUser is also an auxiliray class, so as long as you allow searches that span the whole tree you can allow people to choose whether to associate these classes to external objects or to create device objects under cn=asterisk. Of course you need to decide if allowing that will make your plugin more complex and how you will manage those objects then. As for linking SIP users to real people, it would be great to link the asteriskSIPuser object to an IPA user, but probably not all organizations interested in this kind of functionality for Asterisk would manage all of their users with IPA. What if the real user belongs to a trusted directory, for example? So it seems that for simplicity's sake we will have to store the name of the person using the phone in the asteriskSIPuser description attribute. As for devices I think it would be nice if you could allow both options. Some deployments may choose to provision new user accounts from the get go with all the data including asterisk data. Also putting the data on the user entry make it simpler to allow the user to change some of the fields in a self service fashion (assuming there is any attribute that users should be able to change in a self service way). Other deployments that may want to handle additional users may need to be able to add additional unrelated users though, so being able to do that is also nice. Speaking of packaging, reading http://abbra.fedorapeople.org/guide.html it doesn't seems clear to me how to have an extra category of configuration pages added to the Web UI without modifying the main IPA page. What is the proper way to add extra pages to the web UI ? I will let the UI expert reply on this point. More questions follow :-) I am reading the project page description and I see your schema files needs to be converted in a format that is ok for 389 DS, that requires you to add the attributes and objectclasses full OIDs to the specific attribute/object definition, IIRC 389 does not allow for macro expansion of OIDs like is done in the official Digium schema files. Btw can you explain what is the use of the AsteriskSiteDefault objectclass, it looks like an
Re: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA
Jan Cholasta wrote:
Hi,
On 24.10.2012 21:24, Rob Crittenden wrote:
All the certs are pretty critical in certificate renewal but the agent
cert has the distinction of having to be updated in multiple places. It
needs to exist in both LDAP servers.
It is possible that one or both of these servers may be down briefly
during renewal so we need to be a bit more robust in our handling. This
will wait up to 5 minutes per server to try to update things, and syslog
when failures occur.
It is now also safe to re-run this in case something catastrophic
happens. One would just need to manually run this to load the required
data into LDAP.
rob
I believe that there should be a break statement after the updated =
True line:
+updated = True
+except errors.NetworkError:
Sure is, added.
It would be nice if this message said 30 s instead of just 30:
+syslog.syslog(syslog.LOG_ERR, 'Connection to %s failed,
sleeping 30' % dogtag_uri)
Sure.
The continue statement is redundant:
+attempts += 1
+continue
except errors.EmptyModlist:
Yup. I used to have code executed after the try/except/finally. Removed.
The variables you access in both of the finally blocks (conn and tmpdir)
may be unbound. This can be fixed like this:
while attempts 10:
conn = None
tmpdir = None
try:
...
finally:
if conn is not None and conn.isconnected():
conn.disconnect()
if tmpdir is not None:
shutil.rmtree(tmpdir)
Good catch, added.
It would be nice if this message (both instances of it) included
sys.argv[0], so that it is obvious to the user what script is this
script:
+syslog.syslog(syslog.LOG_ERR, 'Giving up. This script may be safely
re-executed.')
It is included by syslog:
Nov 1 11:13:24 edsel renew_ra_cert: Connection to ldap://localhost:7389
failed, sleeping 30
No spaces in kwarg assignment please:
+tmpdir = tempfile.mkdtemp(prefix = tmp-)
OK.
You might want to include sleeping 30 s in this message as well:
+except Exception, e:
+syslog.syslog(syslog.LOG_ERR, 'Updating renewal certificate
failed: %s' % e)
+time.sleep(30)
Sure, added that.
I also added a missing update. I added handling for ldap.SERVER_DOWN as
a NetworkError instead of a DatabaseError.
rob
From 8e31742686f5b261e6f6a82f9d49882a0a2750a6 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Tue, 23 Oct 2012 14:07:13 -0400
Subject: [PATCH] Wait for the directory server to come up when updating the
agent certificate.
It is possible that either or both of the LDAP instances are being restarted
during the renewal process. Make the script retry if this is the case.
It is also safe to re-run this script if it fails. It will take the current
ipaCert certificate and attempt to update the agent information in LDAP.
https://fedorahosted.org/freeipa/ticket/3179
---
install/restart_scripts/renew_ra_cert | 100 +++---
ipaserver/plugins/ldap2.py| 3 +
2 files changed, 72 insertions(+), 31 deletions(-)
diff --git a/install/restart_scripts/renew_ra_cert b/install/restart_scripts/renew_ra_cert
index 14cbc114ca9d38697cdb2a24b41ccf2ac2c66389..9d4a5e9c431c5445d4bc361630303015c83e53db 100644
--- a/install/restart_scripts/renew_ra_cert
+++ b/install/restart_scripts/renew_ra_cert
@@ -23,6 +23,7 @@ import sys
import shutil
import tempfile
import syslog
+import time
from ipapython import services as ipaservices
from ipapython.certmonger import get_pin
from ipapython import ipautil
@@ -33,6 +34,7 @@ from ipapython.dn import DN
from ipalib import x509
from ipalib import errors
from ipaserver.plugins.ldap2 import ldap2
+import ldap as _ldap
api.bootstrap(context='restart')
api.finalize()
@@ -53,41 +55,77 @@ except IOError, e:
syslog.syslog(syslog.LOG_ERR, 'Unable to determine PIN for CA instance: %s' % e)
sys.exit(1)
-try:
-conn = ldap2(shared_instance=False, ldap_uri='ldap://localhost:%d' % DEFAULT_DSPORT)
-conn.connect(bind_dn=DN(('cn', 'directory manager')), bind_pw=dm_password)
-(entry_dn, entry_attrs) = conn.get_entry(dn, ['usercertificate'], normalize=False)
-entry_attrs['usercertificate'].append(cert)
-entry_attrs['description'] = '2;%d;%s;%s' % (serial_number, issuer, subject)
-conn.update_entry(dn, entry_attrs, normalize=False)
-conn.disconnect()
-except Exception, e:
-syslog.syslog(syslog.LOG_ERR, 'Updating agent entry failed: %s' % e)
-sys.exit(1)
+attempts = 0
+dogtag_uri='ldap://localhost:%d' % DEFAULT_DSPORT
+updated = False
-# Store it in the IPA LDAP server
-tmpdir = tempfile.mkdtemp(prefix = tmp-)
-try:
-dn = DN(('cn','ipaCert'), ('cn', 'ca_renewal'), ('cn', 'ipa'), ('cn', 'etc'), api.env.basedn)
-principal = str('host/%s@%s' % (api.env.host, api.env.realm))
-ccache = ipautil.kinit_hostprincipal('/etc/krb5.keytab', tmpdir, principal)
-conn =
Re: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA
On 1.11.2012 16:32, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 24.10.2012 21:24, Rob Crittenden wrote: All the certs are pretty critical in certificate renewal but the agent cert has the distinction of having to be updated in multiple places. It needs to exist in both LDAP servers. It is possible that one or both of these servers may be down briefly during renewal so we need to be a bit more robust in our handling. This will wait up to 5 minutes per server to try to update things, and syslog when failures occur. It is now also safe to re-run this in case something catastrophic happens. One would just need to manually run this to load the required data into LDAP. rob I believe that there should be a break statement after the updated = True line: +updated = True +except errors.NetworkError: Sure is, added. It would be nice if this message said 30 s instead of just 30: +syslog.syslog(syslog.LOG_ERR, 'Connection to %s failed, sleeping 30' % dogtag_uri) Sure. The continue statement is redundant: +attempts += 1 +continue except errors.EmptyModlist: Yup. I used to have code executed after the try/except/finally. Removed. The variables you access in both of the finally blocks (conn and tmpdir) may be unbound. This can be fixed like this: while attempts 10: conn = None tmpdir = None try: ... finally: if conn is not None and conn.isconnected(): conn.disconnect() if tmpdir is not None: shutil.rmtree(tmpdir) Good catch, added. It would be nice if this message (both instances of it) included sys.argv[0], so that it is obvious to the user what script is this script: +syslog.syslog(syslog.LOG_ERR, 'Giving up. This script may be safely re-executed.') It is included by syslog: Nov 1 11:13:24 edsel renew_ra_cert: Connection to ldap://localhost:7389 failed, sleeping 30 Yep, but it might be nice to show the full path to the script, since it is not in $PATH. No spaces in kwarg assignment please: +tmpdir = tempfile.mkdtemp(prefix = tmp-) OK. You might want to include sleeping 30 s in this message as well: +except Exception, e: +syslog.syslog(syslog.LOG_ERR, 'Updating renewal certificate failed: %s' % e) +time.sleep(30) Sure, added that. I also added a missing update. I added handling for ldap.SERVER_DOWN as a NetworkError instead of a DatabaseError. rob Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [DHCP] tree layout options
On Thu, 2012-07-19 at 22:20 +0930, William Brown wrote: Find attached two different ldifs showing how the tree for DHCP services could be layed out. I personally prefer 2 due to the way that sharedNetwork segments can be named uniquely in a location without clashing with another location. The way that ISC-DHCP generates the config is through essentially a depth-first subtree search of the objects below the dhcpService object (In this case, cn=pultney). Due to this, I think the best way to split ipv4 and ipv6 due to the conflicting DHCP options, would be to make cn=locations,cn=v4,cn=isc,cn=dhcp and cn=locations,cn=v6,isc,cn=dhcp OR cn=locations4,cn=isc,cn=dhcp and cn=locations6,cn=isc,cn=dhcp Additionally, the option1 config does not at this time work with the ISC-DHCP server. It seems there is a bug in that it can parse the dhcpSharedNetworkDN attributes, and push them to a stack to follow them, but never parses the contents of them. Option 2 works, and generates a configuration for the networks and subnets correctly, but does not add any dhcpHost objects not the dhcpFailOverPeer information. I am investigating both. Hi William, sorry for the long delay, I finally found some time to look more in deep at the 2 options, and I think I agree with you that 2 looks a better option. It also seem it would allow to have the same numerical newtork in two separate locations (say a natted 192.168.1.0/24 network used for guests) so that 2 different groups of dhcp servers would be able to serve that data without conflict. Am I reading this right ? It's a bit of a pity that ipv4/ipv6 would need to be split so deep down. At a first glance it would seem that keeping them under the same location would make management easy, however after deeper consideration I can see how ipv6 and ipv4 location may also not overlap at all due the the big difference in routing and address schemes employed by the two ip versions, so having them separate at the root is not bad, and UI/CLI sugar coating can be used to show both if they happen to have same location subtrees underneath, if necessary. So 2 seem to be the most promising option including your recommendations for ipv4/ipv6 subtree splits. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On 11/01/2012 09:32 AM, Simo Sorce wrote: On Thu, 2012-11-01 at 09:30 -0430, Loris Santamaria wrote: Hi all, we plan to write a freeIPA configuration plugin for Asterisk, aiming to be general and useful enough to be included in Fedora and EPEL, so we would like to have your input on some issues before we write any code. Hi Loris, this is really exciting! I wrote down the plans so far on this wiki page: https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk Basically we would like to know if: * It is ok to use cn=asterisk as the base object This looks like a good choice, maybe check with the asterisk people if they are ok with using the name that way ? Anyway any product specific name would work here, as it makes it extremely unlikely to clash with any future work in upstream FreeIPA or for any custom data in users' sites. * The planned DIT, separating object per type and not per site, is ok * The whole stuff of using CoS as a mechanism to apply default values to every new object seems right CoS may have some performance implications, and some usage implication, you need to evaluate if you are ok with those, but in general setting defaults is its job so it may be a good fit. I am CCing Nathan and Rich to ask them about the CoS definitions and whether using that many attributes would be problematic, so far I've only seen CoS used for overriding a single attribute so I am not sure what are the implications with that many. (Nathan, Rich, can you take a quick look at the paragraph named 'CoS definition entries' around the middle of the github wiki page pointed by Loris ?) The one major drawback of CoS attributes is that they cannot currently be indexed, but you could write a virtual attribute indexing plugin. That is, you cannot do a search like (astAccountNAT=somevalue) and have it be indexed. You would have to write a virtual attribute indexing plugin (similar to what Roles does to allow searches like (nsRole=some role dn)). Another issue is that Asterisk SIP objects in real life are generally associated with real people and with physical devices. The physical devices are configured with a piece of software called the endpoint manager, which could pull from the directory the data required to generate the IP phones configuration. We have to choices here. Store the IP phone extra data _with_ the Asterisk SIP object, adding a ieee802device objectClass to the asteriskSIPuser object. The other option is to store the ieee802device object separately in a more appropriate part of the IPA tree and have it reference the SIP object vía a seeAlso or managedBy attribute. I am not sure that there is an actual 'more appropriate' part of the tree. Although we do manage 'devices' (computer objects) that is for machines that are joined to the IPA domain so it would not be applicable in cases where the device can't actually 'join' an ipa domain. However I would stay flexible here and allow both cases. Ie allow to have objects both within the cn=asterisk subtree or in some other subtree. The ieee802device is an auxiliary class so it can be associated with any object in the schema at any time. The AsteriskSIPUser is also an auxiliray class, so as long as you allow searches that span the whole tree you can allow people to choose whether to associate these classes to external objects or to create device objects under cn=asterisk. Of course you need to decide if allowing that will make your plugin more complex and how you will manage those objects then. As for linking SIP users to real people, it would be great to link the asteriskSIPuser object to an IPA user, but probably not all organizations interested in this kind of functionality for Asterisk would manage all of their users with IPA. What if the real user belongs to a trusted directory, for example? So it seems that for simplicity's sake we will have to store the name of the person using the phone in the asteriskSIPuser description attribute. As for devices I think it would be nice if you could allow both options. Some deployments may choose to provision new user accounts from the get go with all the data including asterisk data. Also putting the data on the user entry make it simpler to allow the user to change some of the fields in a self service fashion (assuming there is any attribute that users should be able to change in a self service way). Other deployments that may want to handle additional users may need to be able to add additional unrelated users though, so being able to do that is also nice. Speaking of packaging, reading http://abbra.fedorapeople.org/guide.html it doesn't seems clear to me how to have an extra category of configuration pages added to the Web UI without modifying the main IPA page. What is the proper way to add extra pages to the web UI ? I will let the UI expert reply on this point. More questions follow :-) I am reading the project page description and I see your
Re: [Freeipa-devel] [PATCH] 1070 change user_u context in list
On Thu, 2012-11-01 at 10:34 -0400, Rob Crittenden wrote: The default user_u context in the selnux user map list didn't match what is actually the selinux default context. This could be confusing, so change it to match what systems will have. ACK. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA
Jan Cholasta wrote:
On 1.11.2012 16:32, Rob Crittenden wrote:
Jan Cholasta wrote:
Hi,
On 24.10.2012 21:24, Rob Crittenden wrote:
All the certs are pretty critical in certificate renewal but the agent
cert has the distinction of having to be updated in multiple places. It
needs to exist in both LDAP servers.
It is possible that one or both of these servers may be down briefly
during renewal so we need to be a bit more robust in our handling. This
will wait up to 5 minutes per server to try to update things, and
syslog
when failures occur.
It is now also safe to re-run this in case something catastrophic
happens. One would just need to manually run this to load the required
data into LDAP.
rob
I believe that there should be a break statement after the updated =
True line:
+updated = True
+except errors.NetworkError:
Sure is, added.
It would be nice if this message said 30 s instead of just 30:
+syslog.syslog(syslog.LOG_ERR, 'Connection to %s failed,
sleeping 30' % dogtag_uri)
Sure.
The continue statement is redundant:
+attempts += 1
+continue
except errors.EmptyModlist:
Yup. I used to have code executed after the try/except/finally. Removed.
The variables you access in both of the finally blocks (conn and tmpdir)
may be unbound. This can be fixed like this:
while attempts 10:
conn = None
tmpdir = None
try:
...
finally:
if conn is not None and conn.isconnected():
conn.disconnect()
if tmpdir is not None:
shutil.rmtree(tmpdir)
Good catch, added.
It would be nice if this message (both instances of it) included
sys.argv[0], so that it is obvious to the user what script is this
script:
+syslog.syslog(syslog.LOG_ERR, 'Giving up. This script may be safely
re-executed.')
It is included by syslog:
Nov 1 11:13:24 edsel renew_ra_cert: Connection to ldap://localhost:7389
failed, sleeping 30
Yep, but it might be nice to show the full path to the script, since it
is not in $PATH.
Ok, added.
rob
From 9071e4b5c6ffb04929c1a68c6cd21359134660ad Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Tue, 23 Oct 2012 14:07:13 -0400
Subject: [PATCH] Wait for the directory server to come up when updating the
agent certificate.
It is possible that either or both of the LDAP instances are being restarted
during the renewal process. Make the script retry if this is the case.
It is also safe to re-run this script if it fails. It will take the current
ipaCert certificate and attempt to update the agent information in LDAP.
https://fedorahosted.org/freeipa/ticket/3179
---
install/restart_scripts/renew_ra_cert | 100 +++---
ipaserver/plugins/ldap2.py| 3 +
2 files changed, 72 insertions(+), 31 deletions(-)
diff --git a/install/restart_scripts/renew_ra_cert b/install/restart_scripts/renew_ra_cert
index 14cbc114ca9d38697cdb2a24b41ccf2ac2c66389..048a1ab18825c29d16d62e2a68e4b54dc79f032d 100644
--- a/install/restart_scripts/renew_ra_cert
+++ b/install/restart_scripts/renew_ra_cert
@@ -23,6 +23,7 @@ import sys
import shutil
import tempfile
import syslog
+import time
from ipapython import services as ipaservices
from ipapython.certmonger import get_pin
from ipapython import ipautil
@@ -33,6 +34,7 @@ from ipapython.dn import DN
from ipalib import x509
from ipalib import errors
from ipaserver.plugins.ldap2 import ldap2
+import ldap as _ldap
api.bootstrap(context='restart')
api.finalize()
@@ -53,41 +55,77 @@ except IOError, e:
syslog.syslog(syslog.LOG_ERR, 'Unable to determine PIN for CA instance: %s' % e)
sys.exit(1)
-try:
-conn = ldap2(shared_instance=False, ldap_uri='ldap://localhost:%d' % DEFAULT_DSPORT)
-conn.connect(bind_dn=DN(('cn', 'directory manager')), bind_pw=dm_password)
-(entry_dn, entry_attrs) = conn.get_entry(dn, ['usercertificate'], normalize=False)
-entry_attrs['usercertificate'].append(cert)
-entry_attrs['description'] = '2;%d;%s;%s' % (serial_number, issuer, subject)
-conn.update_entry(dn, entry_attrs, normalize=False)
-conn.disconnect()
-except Exception, e:
-syslog.syslog(syslog.LOG_ERR, 'Updating agent entry failed: %s' % e)
-sys.exit(1)
+attempts = 0
+dogtag_uri='ldap://localhost:%d' % DEFAULT_DSPORT
+updated = False
-# Store it in the IPA LDAP server
-tmpdir = tempfile.mkdtemp(prefix = tmp-)
-try:
-dn = DN(('cn','ipaCert'), ('cn', 'ca_renewal'), ('cn', 'ipa'), ('cn', 'etc'), api.env.basedn)
-principal = str('host/%s@%s' % (api.env.host, api.env.realm))
-ccache = ipautil.kinit_hostprincipal('/etc/krb5.keytab', tmpdir, principal)
-conn = ldap2(shared_instance=False, ldap_uri=api.env.ldap_uri)
-conn.connect(ccache=ccache)
+while attempts 10:
try:
-(entry_dn, entry_attrs) = conn.get_entry(dn, ['usercertificate'])
-entry_attrs['usercertificate'] = cert
+conn = ldap2(shared_instance=False,
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
On 11/01/2012 11:32 AM, Simo Sorce wrote: On Thu, 2012-11-01 at 09:30 -0430, Loris Santamaria wrote: Hi all, we plan to write a freeIPA configuration plugin for Asterisk, aiming to be general and useful enough to be included in Fedora and EPEL, so we would like to have your input on some issues before we write any code. Hi Loris, this is really exciting! Indeed! Several procedural questions to the list: 1) The design is on the github, Simo, should we have a proxy page on our wiki that will point to the github project? 2) Do we need to track it in some way via our ticketing system to make sure that it is aligned with our release cycle? 3) Loris, will it be a completely external effort or you want the code to land in the IPA repository or IPA tools/plugins/satellite repository that currently does not exist but we probably should have? 4) Loris, in a long run how you foresee this functionality being delivered? IPA + EPEL and support from your organization or you want it completely blend into the project and be supported as a part of the core IPA over time? I wrote down the plans so far on this wiki page: https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk Basically we would like to know if: * It is ok to use cn=asterisk as the base object This looks like a good choice, maybe check with the asterisk people if they are ok with using the name that way ? Anyway any product specific name would work here, as it makes it extremely unlikely to clash with any future work in upstream FreeIPA or for any custom data in users' sites. The only concern I have is potential future multitenancy work. We probably need to think about guidelines that integration projects like this should follow to avoid being completely broken in the future multitenant case. * The planned DIT, separating object per type and not per site, is ok * The whole stuff of using CoS as a mechanism to apply default values to every new object seems right CoS may have some performance implications, and some usage implication, you need to evaluate if you are ok with those, but in general setting defaults is its job so it may be a good fit. I am CCing Nathan and Rich to ask them about the CoS definitions and whether using that many attributes would be problematic, so far I've only seen CoS used for overriding a single attribute so I am not sure what are the implications with that many. (Nathan, Rich, can you take a quick look at the paragraph named 'CoS definition entries' around the middle of the github wiki page pointed by Loris ?) Another issue is that Asterisk SIP objects in real life are generally associated with real people and with physical devices. The physical devices are configured with a piece of software called the endpoint manager, which could pull from the directory the data required to generate the IP phones configuration. We have to choices here. Store the IP phone extra data _with_ the Asterisk SIP object, adding a ieee802device objectClass to the asteriskSIPuser object. The other option is to store the ieee802device object separately in a more appropriate part of the IPA tree and have it reference the SIP object vía a seeAlso or managedBy attribute. I am not sure that there is an actual 'more appropriate' part of the tree. Although we do manage 'devices' (computer objects) that is for machines that are joined to the IPA domain so it would not be applicable in cases where the device can't actually 'join' an ipa domain. However I would stay flexible here and allow both cases. Ie allow to have objects both within the cn=asterisk subtree or in some other subtree. The ieee802device is an auxiliary class so it can be associated with any object in the schema at any time. The AsteriskSIPUser is also an auxiliray class, so as long as you allow searches that span the whole tree you can allow people to choose whether to associate these classes to external objects or to create device objects under cn=asterisk. Of course you need to decide if allowing that will make your plugin more complex and how you will manage those objects then. As for linking SIP users to real people, it would be great to link the asteriskSIPuser object to an IPA user, but probably not all organizations interested in this kind of functionality for Asterisk would manage all of their users with IPA. What if the real user belongs to a trusted directory, for example? So it seems that for simplicity's sake we will have to store the name of the person using the phone in the asteriskSIPuser description attribute. As for devices I think it would be nice if you could allow both options. Some deployments may choose to provision new user accounts from the get go with all the data including asterisk data. Also putting the data on the user entry make it simpler to allow the user to change some of the fields in a self service fashion (assuming there is any attribute that users
Re: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA
On 10/29/2012 04:48 PM, Petr Viktorin wrote:
On 10/26/2012 02:25 PM, Petr Viktorin wrote:
On 10/26/2012 02:20 PM, Petr Viktorin wrote:
Attached are this thread's patches rebased and squashed into one.
... and here is a patch to address replication problems related to
merging the schemata of the IPA and CA databases. See the commit message
for details.
https://fedorahosted.org/freeipa/ticket/3213
With the previous patch, if an old split-database DT9 CA was inatalled,
ipa-ca-install didn't detect this, started installing another CA, and
then failed a bit later in the process.
I've added a check for this to the patch.
Two more modifications are needed to support installing a CA on an old
replica. See commit messages for details. Here is the first one.
--
Petr³
From f9afe21a6389a97bc642522f2217a995e1a2ecec Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Wed, 31 Oct 2012 10:37:33 -0400
Subject: [PATCH] Use correct Dogtag configuration in get_pin and
get_ca_certchain
Some install utilities used Dogtag configuration before Dogtag
was configured. Fix by passing the relevant dogtag_constants
where they're needed.
---
ipapython/certmonger.py |6 --
ipapython/dogtag.py |6 --
ipaserver/install/cainstance.py | 26 +-
3 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/ipapython/certmonger.py b/ipapython/certmonger.py
index 9cc4466c61108a863eb76b1ff67bef559a9228d0..445165dfb9498e7f3ffe682a7489158246bf1514 100644
--- a/ipapython/certmonger.py
+++ b/ipapython/certmonger.py
@@ -332,13 +332,15 @@ def remove_principal_from_cas():
fp.close()
# Routines specific to renewing dogtag CA certificates
-def get_pin(token):
+def get_pin(token, dogtag_constants=None):
Dogtag stores its NSS pin in a file formatted as token:PIN.
The caller is expected to handle any exceptions raised.
-with open(dogtag.configured_constants().PASSWORD_CONF_PATH, 'r') as f:
+if dogtag_constants is None:
+dogtag_constants = dogtag.configured_constants()
+with open(dogtag_constants.PASSWORD_CONF_PATH, 'r') as f:
for line in f:
(tok, pin) = line.split('=', 1)
if token == tok:
diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py
index 067a66afbcca805c1a967bc85d2da89f317d4f50..1b428d20e7eb80225470449eece88c6d6fc01989 100644
--- a/ipapython/dogtag.py
+++ b/ipapython/dogtag.py
@@ -149,15 +149,17 @@ def error_from_xml(doc, message_template):
return errors.RemoteRetrieveError(reason=message_template % e)
-def get_ca_certchain(ca_host=None):
+def get_ca_certchain(ca_host=None, dogtag_constants=None):
Retrieve the CA Certificate chain from the configured Dogtag server.
if ca_host is None:
ca_host = api.env.ca_host
+if dogtag_constants is None:
+dogtag_constants = configured_constants()
chain = None
conn = httplib.HTTPConnection(ca_host,
-api.env.ca_install_port or configured_constants().UNSECURE_PORT)
+api.env.ca_install_port or dogtag_constants.UNSECURE_PORT)
conn.request(GET, /ca/ee/ca/getCertChain)
res = conn.getresponse()
doc = None
diff --git a/ipaserver/install/cainstance.py b/ipaserver/install/cainstance.py
index 83752579dab0ad9075b93047b8b9a7699f967405..10c68fb754e7521da3d5632a13f51140c81f510c 100644
--- a/ipaserver/install/cainstance.py
+++ b/ipaserver/install/cainstance.py
@@ -1087,7 +1087,8 @@ class CAInstance(service.Service):
def __get_ca_chain(self):
try:
-return dogtag.get_ca_certchain(ca_host=self.fqdn)
+return dogtag.get_ca_certchain(ca_host=self.fqdn,
+dogtag_constants=self.dogtag_constants)
except Exception, e:
raise RuntimeError(Unable to retrieve CA chain: %s % str(e))
@@ -1383,11 +1384,16 @@ class CAInstance(service.Service):
with open(HTTPD_CONFD + ipa-pki-proxy.conf, w) as fd:
fd.write(template)
+def __get_ca_pin(self):
+try:
+return certmonger.get_pin('internal',
+dogtag_constants=self.dogtag_constants)
+except IOError, e:
+raise RuntimeError(
+'Unable to determine PIN for CA instance: %s' % str(e))
+
def track_servercert(self):
-try:
-pin = certmonger.get_pin('internal')
-except IOError, e:
-raise RuntimeError('Unable to determine PIN for CA instance: %s' % str(e))
+pin = self.__get_ca_pin()
certmonger.dogtag_start_tracking(
'dogtag-ipa-renew-agent', 'Server-Cert cert-pki-ca', pin, None,
self.dogtag_constants.ALIAS_DIR,
@@ -1399,10 +1405,7 @@ class CAInstance(service.Service):
ipaservices.knownservices.messagebus.start()
cmonger.start()
-try:
-pin = certmonger.get_pin('internal')
-except IOError, e:
-raise
Re: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA
On 11/01/2012 06:33 PM, Petr Viktorin wrote: On 10/29/2012 04:48 PM, Petr Viktorin wrote: On 10/26/2012 02:25 PM, Petr Viktorin wrote: On 10/26/2012 02:20 PM, Petr Viktorin wrote: Attached are this thread's patches rebased and squashed into one. ... and here is a patch to address replication problems related to merging the schemata of the IPA and CA databases. See the commit message for details. https://fedorahosted.org/freeipa/ticket/3213 With the previous patch, if an old split-database DT9 CA was inatalled, ipa-ca-install didn't detect this, started installing another CA, and then failed a bit later in the process. I've added a check for this to the patch. Two more modifications are needed to support installing a CA on an old replica. See commit messages for details. Here is the first one. ...and the second. -- Petr³ From 97957f8a958b3e7cb311f1e915cbf4b41d260faf Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Thu, 1 Nov 2012 12:16:25 -0400 Subject: [PATCH] Update certmap.conf on IPA upgrades This brings /etc/dirsrv/slapd-REALM/certmap.conf under IPA control. The file is overwritten on upgrades. This ensures that the cert for the ipaca user is recognized when ipa-ca-install is run on older masters. --- install/share/certmap.conf.template |6 +- install/tools/ipa-upgradeconfig | 17 - ipaserver/install/dsinstance.py |2 +- 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/install/share/certmap.conf.template b/install/share/certmap.conf.template index 40b4e6cb1513bed586248e0c214730861b9715cf..cff3a669b8946223b62e4fda00dbfa21d98245cd 100644 --- a/install/share/certmap.conf.template +++ b/install/share/certmap.conf.template @@ -1,4 +1,8 @@ +# VERSION 1 - DO NOT REMOVE THIS LINE # +# This file is managed by IPA and will be overwritten on upgrades. + + # BEGIN COPYRIGHT BLOCK # This Program is free software; you can redistribute it and/or modify it under # the terms of the GNU General Public License as published by the Free Software @@ -80,6 +84,6 @@ certmap default default #default:InitFn Init function's name default:DNComps default:FilterComps uid -certmap ipaca CN=Certificate Authority,O=domain_name +certmap ipaca CN=Certificate Authority,O=$REALM ipaca:CmapLdapAttr seeAlso ipaca:verifycerton diff --git a/install/tools/ipa-upgradeconfig b/install/tools/ipa-upgradeconfig index 14d4e0829162ab78665f794c582e704b5901ea41..12e96cfb77786a5ff503975d05876f56c8876111 100644 --- a/install/tools/ipa-upgradeconfig +++ b/install/tools/ipa-upgradeconfig @@ -153,7 +153,11 @@ def find_autoredirect(fqdn): return True def find_version(filename): -Find the version of a configuration file +Find the version of a configuration file + +If no VERSION entry exists in the file, returns 0. +If the file does not exist, returns -1. + if os.path.exists(filename): pattern = ^[\s#]*VERSION\s+([0-9]+)\s+.* p = re.compile(pattern) @@ -185,6 +189,12 @@ def upgrade(sub_dict, filename, template, add=False): if new 0: root_logger.error(%s not found. % template) +if old == 0: +# The original file does not have a VERSION entry. This means it's now +# managed by IPA, but previously was not. +root_logger.warning(%s is now managed by IPA. It will be +overwritten. A backup of the original will be made., filename) + if old new or (add and old == 0): backup_file(filename, new) update_conf(sub_dict, filename, template) @@ -626,9 +636,14 @@ def main(): '=') sub_dict['CLONE']='#' if crl.lower() == 'true' else '' +certmap_dir = dsinstance.config_dirname( +dsinstance.realm_to_serverid(api.env.realm)) + upgrade(sub_dict, /etc/httpd/conf.d/ipa.conf, ipautil.SHARE_DIR + ipa.conf) upgrade(sub_dict, /etc/httpd/conf.d/ipa-rewrite.conf, ipautil.SHARE_DIR + ipa-rewrite.conf) upgrade(sub_dict, /etc/httpd/conf.d/ipa-pki-proxy.conf, ipautil.SHARE_DIR + ipa-pki-proxy.conf, add=True) +upgrade(sub_dict, os.path.join(certmap_dir, certmap.conf), +os.path.join(ipautil.SHARE_DIR, certmap.conf.template)) upgrade_pki(ca, fstore) update_dbmodules(api.env.realm) uninstall_ipa_kpasswd() diff --git a/ipaserver/install/dsinstance.py b/ipaserver/install/dsinstance.py index 060490d59c90d62fcdd3d0da89b4f6eb1d0fbf97..3b4db1e7a26a8c9c143be487f93738648ec76813 100644 --- a/ipaserver/install/dsinstance.py +++ b/ipaserver/install/dsinstance.py @@ -610,7 +610,7 @@ class DsInstance(service.Service): shutil.copyfile(ipautil.SHARE_DIR + certmap.conf.template, config_dirname(self.serverid) + certmap.conf) installutils.update_file(config_dirname(self.serverid) + certmap.conf, - 'domain_name', self.realm_name) +
Re: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA
Jan Cholasta wrote: On 1.11.2012 16:54, Rob Crittenden wrote: Jan Cholasta wrote: On 1.11.2012 16:32, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 24.10.2012 21:24, Rob Crittenden wrote: All the certs are pretty critical in certificate renewal but the agent cert has the distinction of having to be updated in multiple places. It needs to exist in both LDAP servers. It is possible that one or both of these servers may be down briefly during renewal so we need to be a bit more robust in our handling. This will wait up to 5 minutes per server to try to update things, and syslog when failures occur. It is now also safe to re-run this in case something catastrophic happens. One would just need to manually run this to load the required data into LDAP. rob I believe that there should be a break statement after the updated = True line: +updated = True +except errors.NetworkError: Sure is, added. It would be nice if this message said 30 s instead of just 30: +syslog.syslog(syslog.LOG_ERR, 'Connection to %s failed, sleeping 30' % dogtag_uri) Sure. The continue statement is redundant: +attempts += 1 +continue except errors.EmptyModlist: Yup. I used to have code executed after the try/except/finally. Removed. The variables you access in both of the finally blocks (conn and tmpdir) may be unbound. This can be fixed like this: while attempts 10: conn = None tmpdir = None try: ... finally: if conn is not None and conn.isconnected(): conn.disconnect() if tmpdir is not None: shutil.rmtree(tmpdir) Good catch, added. It would be nice if this message (both instances of it) included sys.argv[0], so that it is obvious to the user what script is this script: +syslog.syslog(syslog.LOG_ERR, 'Giving up. This script may be safely re-executed.') It is included by syslog: Nov 1 11:13:24 edsel renew_ra_cert: Connection to ldap://localhost:7389 failed, sleeping 30 Yep, but it might be nice to show the full path to the script, since it is not in $PATH. Ok, added. rob Thanks. Please also add the conn = None bit to the first loop: while attempts 10: conn = None try: ... finally: if conn is not None and conn.isconnected(): conn.disconnect() and it's ACK. Honza Done, pushed to master and ipa-3-0 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA
On 1.11.2012 16:54, Rob Crittenden wrote: Jan Cholasta wrote: On 1.11.2012 16:32, Rob Crittenden wrote: Jan Cholasta wrote: Hi, On 24.10.2012 21:24, Rob Crittenden wrote: All the certs are pretty critical in certificate renewal but the agent cert has the distinction of having to be updated in multiple places. It needs to exist in both LDAP servers. It is possible that one or both of these servers may be down briefly during renewal so we need to be a bit more robust in our handling. This will wait up to 5 minutes per server to try to update things, and syslog when failures occur. It is now also safe to re-run this in case something catastrophic happens. One would just need to manually run this to load the required data into LDAP. rob I believe that there should be a break statement after the updated = True line: +updated = True +except errors.NetworkError: Sure is, added. It would be nice if this message said 30 s instead of just 30: +syslog.syslog(syslog.LOG_ERR, 'Connection to %s failed, sleeping 30' % dogtag_uri) Sure. The continue statement is redundant: +attempts += 1 +continue except errors.EmptyModlist: Yup. I used to have code executed after the try/except/finally. Removed. The variables you access in both of the finally blocks (conn and tmpdir) may be unbound. This can be fixed like this: while attempts 10: conn = None tmpdir = None try: ... finally: if conn is not None and conn.isconnected(): conn.disconnect() if tmpdir is not None: shutil.rmtree(tmpdir) Good catch, added. It would be nice if this message (both instances of it) included sys.argv[0], so that it is obvious to the user what script is this script: +syslog.syslog(syslog.LOG_ERR, 'Giving up. This script may be safely re-executed.') It is included by syslog: Nov 1 11:13:24 edsel renew_ra_cert: Connection to ldap://localhost:7389 failed, sleeping 30 Yep, but it might be nice to show the full path to the script, since it is not in $PATH. Ok, added. rob Thanks. Please also add the conn = None bit to the first loop: while attempts 10: conn = None try: ... finally: if conn is not None and conn.isconnected(): conn.disconnect() and it's ACK. Honza -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 88 Reword description of the --passsync option of ipa-replica-manage
Rob Crittenden wrote: Jan Cholasta wrote: Hi, this patch fixes https://fedorahosted.org/freeipa/ticket/3208. There are two typos, PasSync with only 2 s's. I think there should be a separate section on PassSync explaining what the service is and passwords are modified. There is some information on this in the ticket. It doesn't need to be very long. rob I had something like this in mind: diff --git a/install/tools/man/ipa-replica-manage.1 b/install/tools/man/ipa-repl ica-manage.1 index b1704c0..4e4bfa9 100644 --- a/install/tools/man/ipa-replica-manage.1 +++ b/install/tools/man/ipa-replica-manage.1 @@ -176,6 +176,10 @@ Create a winsync replication agreement: .TP Remove a winsync replication agreement: # ipa\-replica\-manage disconnect windows.ad.example.com +.SH PASSSYNC +PassSync is a Windows service that runs on AD Domain Controllers to intercept password changes. It sends these password changes to the IPA LDAP server over TLS. These password changes bypass normal IPA password policy settings and the password is not set to immediately expire. This is because by the time IPA receives the password change it has already been accepted by AD so it is too late to reject it. +.TP +IPA maintains a list of DNs that are excempt from password policy. A special us er is added automatically when a winsync replication agreement is created. The DN of this user is added to the excemption list stored in passSyncManagersDNs in tne entry cn=ipa_pwd_extop,cn=plugins,cn=config. .SH EXIT STATUS 0 if the command was successful ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Get list of service from LDAP only at startup
On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: Rob Crittenden wrote: Simo Sorce wrote: From: Simo Sorce sso...@redhat.com We check (possibly different) data from LDAP only at (re)start. This way we always shutdown exactly the services we started even if the list changed in the meanwhile (we avoid leaving a service running even if it was removed from LDAP as the admin decided it should not be started in future). This should also fix a problematic deadlock with systemd when we try to read the list of service from LDAP at shutdown. This fixes things for me but ipactl start isn't working reliably and I've yet to determine if it is related or not (I'm thinking not). What I see is that it considers pki-tomcatd to not have started. What is happening is the request to the getStatus URI is timing out and that exception is being considered a didn't start. I modified the code to treat a timeout as a 503 and it is still failing because the timeout is so longer that it eats up all our normal timeout for waiting for the service at all. I don't see a way to pass a timeout to the http request method, I'll keep looking. I'm testing in F-18 btw. I can't reproduce the startup issues this morning, I still don't think they are related to this patch, so ACK. pushed all 3 to master and ipa-3-0 You pushed an older revision for patch 2, I reverted it on both trees and pushed the right one. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 329 Use common encoding in modlist generation
On Tue, 2012-10-30 at 15:12 +0100, Jan Cholasta wrote: Thanks for the catch Honza! I missed these errors in false positives I got in my unit tests... Attaching a fixed patch, unit are clean this time. Martin ACK. This patch was pushed a while ago. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 1/1] Resolve external members from trusted domain via Global Catalog
On Wed, 2012-10-31 at 22:52 +0200, Alexander Bokovoy wrote: A sequence is following: 1. Match external member against existing trusted domain 2. Find trusted domain's domain controller and preferred GC hosts 3. Fetch trusted domain account auth info 4. Set up ccache in /var/run/ipa_memcached/krb5cc_TDdomain with principal ourdomain$@trusted.domain 5. Do LDAP SASL interactive bind using the ccache 6. Search for the member's SID 7. Decode SID 8. Replace external member name by SID --- ipalib/plugins/group.py | 32 --- ipalib/plugins/trust.py | 17 ++-- ipaserver/dcerpc.py | 233 +++- 3 files changed, 257 insertions(+), 25 deletions(-) Ack! Pushed to master and ipa-3-0 Thanks a lot! Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone
Martin Kosek wrote: bind-dyndb-ldap allows disabling global forwarder per-zone. This may be useful in a scenario when we do not want requests to delegated sub-zones (like sub.example.com. in zone example.com.) to be routed through global forwarder. Few lines to help added to explain the feature to users too. https://fedorahosted.org/freeipa/ticket/3209 Fix two minor problems and you have an ACK. 1. It needs a minor rebase 2. The API needs to be updated rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
El jue, 01-11-2012 a las 11:32 -0400, Simo Sorce escribió: On Thu, 2012-11-01 at 09:30 -0430, Loris Santamaria wrote: Hi all, we plan to write a freeIPA configuration plugin for Asterisk, aiming to be general and useful enough to be included in Fedora and EPEL, so we would like to have your input on some issues before we write any code. Hi Loris, this is really exciting! I wrote down the plans so far on this wiki page: https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk Basically we would like to know if: * It is ok to use cn=asterisk as the base object This looks like a good choice, maybe check with the asterisk people if they are ok with using the name that way ? Yes we will have to introduce the project to the asterisk-devel mailing list as well. Anyway any product specific name would work here, as it makes it extremely unlikely to clash with any future work in upstream FreeIPA or for any custom data in users' sites. * The planned DIT, separating object per type and not per site, is ok * The whole stuff of using CoS as a mechanism to apply default values to every new object seems right CoS may have some performance implications, and some usage implication, you need to evaluate if you are ok with those, but in general setting defaults is its job so it may be a good fit. I am CCing Nathan and Rich to ask them about the CoS definitions and whether using that many attributes would be problematic, so far I've only seen CoS used for overriding a single attribute so I am not sure what are the implications with that many. (Nathan, Rich, can you take a quick look at the paragraph named 'CoS definition entries' around the middle of the github wiki page pointed by Loris ?) Another issue is that Asterisk SIP objects in real life are generally associated with real people and with physical devices. The physical devices are configured with a piece of software called the endpoint manager, which could pull from the directory the data required to generate the IP phones configuration. We have to choices here. Store the IP phone extra data _with_ the Asterisk SIP object, adding a ieee802device objectClass to the asteriskSIPuser object. The other option is to store the ieee802device object separately in a more appropriate part of the IPA tree and have it reference the SIP object vía a seeAlso or managedBy attribute. I am not sure that there is an actual 'more appropriate' part of the tree. Although we do manage 'devices' (computer objects) that is for machines that are joined to the IPA domain so it would not be applicable in cases where the device can't actually 'join' an ipa domain. However I would stay flexible here and allow both cases. Ie allow to have objects both within the cn=asterisk subtree or in some other subtree. The ieee802device is an auxiliary class so it can be associated with any object in the schema at any time. The AsteriskSIPUser is also an auxiliray class, so as long as you allow searches that span the whole tree you can allow people to choose whether to associate these classes to external objects or to create device objects under cn=asterisk. Of course you need to decide if allowing that will make your plugin more complex and how you will manage those objects then. As for linking SIP users to real people, it would be great to link the asteriskSIPuser object to an IPA user, but probably not all organizations interested in this kind of functionality for Asterisk would manage all of their users with IPA. What if the real user belongs to a trusted directory, for example? So it seems that for simplicity's sake we will have to store the name of the person using the phone in the asteriskSIPuser description attribute. As for devices I think it would be nice if you could allow both options. Some deployments may choose to provision new user accounts from the get go with all the data including asterisk data. Also putting the data on the user entry make it simpler to allow the user to change some of the fields in a self service fashion (assuming there is any attribute that users should be able to change in a self service way). Other deployments that may want to handle additional users may need to be able to add additional unrelated users though, so being able to do that is also nice. Speaking of packaging, reading http://abbra.fedorapeople.org/guide.html it doesn't seems clear to me how to have an extra category of configuration pages added to the Web UI without modifying the main IPA page. What is the proper way to add extra pages to the web UI ? I will let the UI expert reply on this point. More questions follow :-) I am reading the project page description and I see your schema files needs to be converted in a format that is ok for 389 DS, that requires you to add the attributes and objectclasses full OIDs
Re: [Freeipa-devel] RFC: freeipa-asterisk plugin
El jue, 01-11-2012 a las 12:47 -0400, Dmitri Pal escribió: On 11/01/2012 11:32 AM, Simo Sorce wrote: On Thu, 2012-11-01 at 09:30 -0430, Loris Santamaria wrote: Hi all, we plan to write a freeIPA configuration plugin for Asterisk, aiming to be general and useful enough to be included in Fedora and EPEL, so we would like to have your input on some issues before we write any code. Hi Loris, this is really exciting! Indeed! Several procedural questions to the list: 1) The design is on the github, Simo, should we have a proxy page on our wiki that will point to the github project? 2) Do we need to track it in some way via our ticketing system to make sure that it is aligned with our release cycle? 3) Loris, will it be a completely external effort or you want the code to land in the IPA repository or IPA tools/plugins/satellite repository that currently does not exist but we probably should have? 4) Loris, in a long run how you foresee this functionality being delivered? IPA + EPEL and support from your organization or you want it completely blend into the project and be supported as a part of the core IPA over time? Of course it would be great if this plugin could be distributed as an optional but official IPA component. If you see it possible we will submit the code for review as soon as it is in a working state, else we will at least submit it for inclusion in Fedora with a dependency on freeipa-server. You could set some guidelines for projects like this. I see that a dhcp plugin is in the works, maybe both this plugin and the dhcp plugin should get assigned containers under a generic cn=apps container? Ip phones and maybe printers should be listed under a cn=devices container? How one should integrate optional components with the Web UI? IPA is a great framework to write LDAP configuration templates, very complete and easy to use, so some guidelines for satellite work could really get more contributions which you could then pull in the official distribution when they are ready and useful enough. I wrote down the plans so far on this wiki page: https://github.com/sorbouc/sorbo/wiki/freeipa-asterisk Basically we would like to know if: * It is ok to use cn=asterisk as the base object This looks like a good choice, maybe check with the asterisk people if they are ok with using the name that way ? Anyway any product specific name would work here, as it makes it extremely unlikely to clash with any future work in upstream FreeIPA or for any custom data in users' sites. The only concern I have is potential future multitenancy work. We probably need to think about guidelines that integration projects like this should follow to avoid being completely broken in the future multitenant case. * The planned DIT, separating object per type and not per site, is ok * The whole stuff of using CoS as a mechanism to apply default values to every new object seems right CoS may have some performance implications, and some usage implication, you need to evaluate if you are ok with those, but in general setting defaults is its job so it may be a good fit. I am CCing Nathan and Rich to ask them about the CoS definitions and whether using that many attributes would be problematic, so far I've only seen CoS used for overriding a single attribute so I am not sure what are the implications with that many. (Nathan, Rich, can you take a quick look at the paragraph named 'CoS definition entries' around the middle of the github wiki page pointed by Loris ?) Another issue is that Asterisk SIP objects in real life are generally associated with real people and with physical devices. The physical devices are configured with a piece of software called the endpoint manager, which could pull from the directory the data required to generate the IP phones configuration. We have to choices here. Store the IP phone extra data _with_ the Asterisk SIP object, adding a ieee802device objectClass to the asteriskSIPuser object. The other option is to store the ieee802device object separately in a more appropriate part of the IPA tree and have it reference the SIP object vía a seeAlso or managedBy attribute. I am not sure that there is an actual 'more appropriate' part of the tree. Although we do manage 'devices' (computer objects) that is for machines that are joined to the IPA domain so it would not be applicable in cases where the device can't actually 'join' an ipa domain. However I would stay flexible here and allow both cases. Ie allow to have objects both within the cn=asterisk subtree or in some other subtree. The ieee802device is an auxiliary class so it can be associated with any object in the schema at any time. The AsteriskSIPUser is also an auxiliray class, so as long as you allow searches that span the whole tree you can allow people to choose whether to
