From jcholast at redhat.com Thu Nov 1 12:42:30 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Nov 2012 13:42:30 +0100 Subject: [Freeipa-devel] [PATCH] 1067 clear out certmonger requests In-Reply-To: <50914392.7060409@redhat.com> References: <50883FFC.8020005@redhat.com> <508E8893.9080007@redhat.com> <508ED4F6.1010605@redhat.com> <508FD6F1.3010605@redhat.com> <50914392.7060409@redhat.com> Message-ID: <50926E36.1000708@redhat.com> 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 From pvoborni at redhat.com Thu Nov 1 13:25:13 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 01 Nov 2012 14:25:13 +0100 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <5091A279.8060205@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> Message-ID: <50927839.30806@redhat.com> 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 builder isn't in the rpm. >> >> AFAIK the dojo rpm contains already built files. It has a core >> dojo.js file which contains basic modules to work but the rest of >> modules are separated. IDK if it can be used in a build process. I >> have to test it. >> >>> >>> There's also RequireJS (http://requirejs.org/). >> >> require.js is just AMD loader but it uses r.js as optimizer. r.js >> seems more lightweight than dojo builder. I would stick with dojo >> loader and builder if we use other dojo features. >> >>> >>>> ### 2) Object store/model >>>> At the beginning Web UI was quite simple - a command filled widgets, >>>> widgets got edited, update command was constructed from widgets, it was >>>> sent to server and at the end widgets were updated with new values. >>>> >>>> Now various parts of displayed page (action lists, panels, status >>>> widgets, facet header) needs to use loaded values too or influence >>>> others. This issue was often discussed in patch reviews. As a solution, >>>> some model object with bidirectional binding capabilities would be >>>> greatly beneficial. >>>> >>>> Dojo provides a extensible object store [1]. I would like to use >>>> 'memory >>>> store' and 'observable' and extend it with 'dirty-check' capabilities. >>>> >>>> [1] >>>> http://dojotoolkit.org/documentation/tutorials/1.8/intro_dojo_store/ >>> >>> Backbone also has similar mechanisms for events and sync. >>> >>>> ### 3) Class model >>>> Yes, in IPA Web UI we are using some class model, but it has flaws, >>>> mainly in initialization of a object (some initialization code of >>>> parent >>>> class may be called before inheritance is finished). >>>> >>>> Dojo has a class system [1] which is easy to use and support >>>> inheritance, mixins and overrided function calls. >>>> >>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/declare/ >>> >>> At first glance Backbone seems to be better in this area, but Dojo might >>> also be sufficient for our purposes. >> >> Backbone seems to have advantage in calling super class' constructor. >> It is not recommended in Dojo. >> >>> >>> There's going to be some challenges converting the current class >>> framework. Like you said, the current initialization isn't well >>> structured, so we might need to fix that first before converting the >>> class framework. And then we use 'that' instead of 'this', and sometimes >>> both, and they get confusing, so we'd have to be very careful when >>> converting them. Also, the current way to call a method in super class >>> needs to be fixed. >> >> We can come with some strategy to keep patch reviews simple. >> IE: >> * move initialization stuff to init method (or more fine-grained) and >> use builder to create and instance (in some parts its already done), >> this way we eliminate statements in class declaration (except method >> declaration and overriding) >> * change to the classes: change that to this/self(to keep context in >> closures) >> * eliminate method overrides with inherited() calls. >> * put init calls to constructor >> * change builder again >> >>> >>>> ### 4) Localization >>>> Web UI and pages in config, migrate and error folder are not localized >>>> until successful login. It's because Web UI gets localized strings by >>>> API call which needs prior authentication. We should use other >>>> method to >>>> provide localized config, error and login pages. >>>> >>>> Dojo has a easy to use localization solution [1]. Basically strings are >>>> defined in .js files as modules, translations in subfolders. Dojo >>>> loader >>>> and i18n framework take care of loading of proper string depending on >>>> user's local. It doesn't need communication with JSON-RPC so can be >>>> used >>>> in config and login pages. >>>> >>>> We would have to make a script to translate the format to a format >>>> usable by transifex. >>>> >>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/i18n/ >>> >>> A possible alternative is jquery-i18n-properties >>> (http://code.google.com/p/jquery-i18n-properties/). >>> >>>> ### 5) Navigation >>>> Our navigation code is limited to IPA entities. Introducing non-entity >>>> page like log (#3040) or help is problematic. Routing code should be >>>> improved. Separate entity initialization and menu definition. As the >>>> re-factoring will be at some point done, we might consider to use >>>> dojo.router and dojo.hash instead of $.bbq. This is really optional and >>>> not strictly related to Dojo, but I wanted to mention it. >>>> >>>> Better handling of pkeys may fix `#2741 [ipa webui] Intermittent errors >>>> - 'cn' is required; limits exceeded for this query` >>> >>> Backbone also has router and history. >>> >>>> ### 6) Easier unit tests >>>> By utilizing AMD modules, Localization, Model binding we might be able >>>> to write unit tests of widgets easier. Now we have to simulate entity, >>>> facets, fields, strings loaded from JSON-RPC... >>> >>> Yes, that would be great. >>> >>>> ### 7) Separation of framework and IPA >>>> We often talk about separating Web UI framework and IPA related stuff. >>>> We can do it along with this refactoring. >>>> https://fedorahosted.org/freeipa/ticket/3030 >>> >>> Yes, but it might need to be fixed separately. >> >> I don't want to this all stuff in one patch :). >>> >>>> What I don't want to do >>>> ----------------------- >>>> * rewrite whole UI, changes should be gradual >>>> * replace jQuery. Most of our widgets are using jquery, I don't want to >>>> change this code, so I don't want to replace it with Dojo widget system >>>> - too big effort. So in the result the HTML output should not be >>>> changed >>>> much - not to affect automated tests. >>>> >>>> ### Steps how could be Dojo incorporated >>>> It should be done gradually. >>>> 1) make the build system working. Without it a lot of .js files >>>> would be >>>> transmitted to browser which is really bad. >>> >>> This is probably the easiest part. The next steps could be difficult to >>> untangle. So be ready for a long haul. :) >> >> The harder part is not to populate git and rpm with a lot of >> third-party stuff. We need to convince dojo builder to use uglify.js >> under rhino to avoid using of closure compiler or shrink-safe which >> are not and probably will not be bundled in fedora and RHEL and >> definitely we don't want to bundle them. >> >> I'm thinking about making a script which would create WebUI-devoloper >> enviroment: >> * checkout dojo/dojo and dojo/util git repository to 1.8.1 tag >> * create a symbolic links to the tag >> * apply custom patches on dojo/util (there will definitely be one) >> * include in FreeIPA git only builded dojo.js (in the case we have >> separate files for dojo.js and freeipa.js (just a suggestion of name)) >> * will investigate if we can build the builder and include it in git >> for rpm builds. >> >> We can of course include into our git a whole 1.8.1 dojo/dojo and >> dojo/util but I would rather avoid it because it's a LOT of files. >> >>> >>>> 2) separate components to individual files and transform then into AMD >>>> modules. We might change namespaces and dependencies to separate Web UI >>>> framework and IPA related stuff. >>>> 3) change class system of entities and facets >>>> 4) implement a 'model' >>>> ? >>>> At this point it depends on priorities and new tickets with higher >>>> priority may appear. >>> >> >> > Still sounds scary... What is the general recommendation? Are the > arguments for or against Dojo convincing? > I proposed it, so the question is mainly for Endi or Adam, if he is interested (added Cc). Just to add: The question is whether we want to use third party code to solve some issues or we want to write everything ourselves. Everything I wrote above can be solved by us but it will probably take much more time. Dojo itself won't fix our problems it just provides means to fix them. As Enti wrote, for the problems we have, it can be replaced by multiple libraries combined(require.js, r.js, backbone.js, jquery-i18n-properties). I don't want to repeat myself much so adding just some dojo-related pros and cons: Cons: * third party code - we need to watch updates, sec issues * more complex build of UI which eventually needs more unit tests (basically I want some build with or without Dojo) Pros: * third party code - don't have to reinvent the wheel * establish library (good docs, some books were writen) * using good modular structure, we can pick the parts we actually want, when we want (loader, builder, class system, object store, localization, modular system) -- Petr Vobornik From loris at lgs.com.ve Thu Nov 1 14:00:31 2012 From: loris at lgs.com.ve (Loris Santamaria) Date: Thu, 01 Nov 2012 09:30:31 -0430 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin Message-ID: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> 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:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford From ayoung at redhat.com Thu Nov 1 14:01:22 2012 From: ayoung at redhat.com (Adam Young) Date: Thu, 01 Nov 2012 10:01:22 -0400 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <50927839.30806@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> Message-ID: <509280B2.2040607@redhat.com> 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 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). Just want to reiterate the power of being able to dop development withouth having to do a build. DO NOT MAKE A DELIBERATE BUILD STEP FOR JAVASCRIPT! >>>>> >>>>> [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 builder isn't in the rpm. >>> >>> AFAIK the dojo rpm contains already built files. It has a core >>> dojo.js file which contains basic modules to work but the rest of >>> modules are separated. IDK if it can be used in a build process. I >>> have to test it. >>> >>>> >>>> There's also RequireJS (http://requirejs.org/). >>> >>> require.js is just AMD loader but it uses r.js as optimizer. r.js >>> seems more lightweight than dojo builder. I would stick with dojo >>> loader and builder if we use other dojo features. >>> >>>> >>>>> ### 2) Object store/model >>>>> At the beginning Web UI was quite simple - a command filled widgets, >>>>> widgets got edited, update command was constructed from widgets, >>>>> it was >>>>> sent to server and at the end widgets were updated with new values. >>>>> >>>>> Now various parts of displayed page (action lists, panels, status >>>>> widgets, facet header) needs to use loaded values too or influence >>>>> others. This issue was often discussed in patch reviews. As a >>>>> solution, >>>>> some model object with bidirectional binding capabilities would be >>>>> greatly beneficial. >>>>> >>>>> Dojo provides a extensible object store [1]. I would like to use >>>>> 'memory >>>>> store' and 'observable' and extend it with 'dirty-check' >>>>> capabilities. >>>>> >>>>> [1] >>>>> http://dojotoolkit.org/documentation/tutorials/1.8/intro_dojo_store/ >>>> >>>> Backbone also has similar mechanisms for events and sync. >>>> >>>>> ### 3) Class model >>>>> Yes, in IPA Web UI we are using some class model, but it has flaws, >>>>> mainly in initialization of a object (some initialization code of >>>>> parent >>>>> class may be called before inheritance is finished). >>>>> >>>>> Dojo has a class system [1] which is easy to use and support >>>>> inheritance, mixins and overrided function calls. >>>>> >>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/declare/ >>>> >>>> At first glance Backbone seems to be better in this area, but Dojo >>>> might >>>> also be sufficient for our purposes. >>> >>> Backbone seems to have advantage in calling super class' constructor. >>> It is not recommended in Dojo. >>> >>>> >>>> There's going to be some challenges converting the current class >>>> framework. Like you said, the current initialization isn't well >>>> structured, so we might need to fix that first before converting the >>>> class framework. And then we use 'that' instead of 'this', and >>>> sometimes >>>> both, and they get confusing, so we'd have to be very careful when >>>> converting them. Also, the current way to call a method in super class >>>> needs to be fixed. >>> >>> We can come with some strategy to keep patch reviews simple. >>> IE: >>> * move initialization stuff to init method (or more fine-grained) and >>> use builder to create and instance (in some parts its already done), >>> this way we eliminate statements in class declaration (except method >>> declaration and overriding) >>> * change to the classes: change that to this/self(to keep context in >>> closures) >>> * eliminate method overrides with inherited() calls. >>> * put init calls to constructor >>> * change builder again >>> >>>> >>>>> ### 4) Localization >>>>> Web UI and pages in config, migrate and error folder are not >>>>> localized >>>>> until successful login. It's because Web UI gets localized strings by >>>>> API call which needs prior authentication. We should use other >>>>> method to >>>>> provide localized config, error and login pages. The localization information is not necessarily accessable to the browser. The only thing we can depend on is that the server gets it, and then sends back the strings. That was the rationale for the current mechanism. >>>>> >>>>> Dojo has a easy to use localization solution [1]. Basically >>>>> strings are >>>>> defined in .js files as modules, translations in subfolders. Dojo >>>>> loader >>>>> and i18n framework take care of loading of proper string depending on >>>>> user's local. It doesn't need communication with JSON-RPC so can be >>>>> used >>>>> in config and login pages. >>>>> >>>>> We would have to make a script to translate the format to a format >>>>> usable by transifex. >>>>> >>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/i18n/ >>>> >>>> A possible alternative is jquery-i18n-properties >>>> (http://code.google.com/p/jquery-i18n-properties/). >>>> >>>>> ### 5) Navigation >>>>> Our navigation code is limited to IPA entities. Introducing >>>>> non-entity >>>>> page like log (#3040) or help is problematic. Routing code should be >>>>> improved. Separate entity initialization and menu definition. As the >>>>> re-factoring will be at some point done, we might consider to use >>>>> dojo.router and dojo.hash instead of $.bbq. This is really >>>>> optional and >>>>> not strictly related to Dojo, but I wanted to mention it. >>>>> >>>>> Better handling of pkeys may fix `#2741 [ipa webui] Intermittent >>>>> errors >>>>> - 'cn' is required; limits exceeded for this query` >>>> >>>> Backbone also has router and history. >>>> >>>>> ### 6) Easier unit tests >>>>> By utilizing AMD modules, Localization, Model binding we might be >>>>> able >>>>> to write unit tests of widgets easier. Now we have to simulate >>>>> entity, >>>>> facets, fields, strings loaded from JSON-RPC... >>>> >>>> Yes, that would be great. I'd like better inversion of control in the JS code in general. But you don't need to move to Dojo to do that. As I recall, Dojo "wiring up" was about a 1/2 way solution (but it has been a long time since I looked) >>>> >>>>> ### 7) Separation of framework and IPA >>>>> We often talk about separating Web UI framework and IPA related >>>>> stuff. >>>>> We can do it along with this refactoring. >>>>> https://fedorahosted.org/freeipa/ticket/3030 >>>> >>>> Yes, but it might need to be fixed separately. >>> >>> I don't want to this all stuff in one patch :). >>>> >>>>> What I don't want to do >>>>> ----------------------- >>>>> * rewrite whole UI, changes should be gradual >>>>> * replace jQuery. Most of our widgets are using jquery, I don't >>>>> want to >>>>> change this code, so I don't want to replace it with Dojo widget >>>>> system >>>>> - too big effort. So in the result the HTML output should not be >>>>> changed >>>>> much - not to affect automated tests. >>>>> >>>>> ### Steps how could be Dojo incorporated >>>>> It should be done gradually. >>>>> 1) make the build system working. Without it a lot of .js files >>>>> would be >>>>> transmitted to browser which is really bad. >>>> >>>> This is probably the easiest part. The next steps could be >>>> difficult to >>>> untangle. So be ready for a long haul. :) >>> >>> The harder part is not to populate git and rpm with a lot of >>> third-party stuff. We need to convince dojo builder to use uglify.js >>> under rhino to avoid using of closure compiler or shrink-safe which >>> are not and probably will not be bundled in fedora and RHEL and >>> definitely we don't want to bundle them. >>> >>> I'm thinking about making a script which would create WebUI-devoloper >>> enviroment: >>> * checkout dojo/dojo and dojo/util git repository to 1.8.1 tag >>> * create a symbolic links to the tag >>> * apply custom patches on dojo/util (there will definitely be one) >>> * include in FreeIPA git only builded dojo.js (in the case we have >>> separate files for dojo.js and freeipa.js (just a suggestion of name)) >>> * will investigate if we can build the builder and include it in git >>> for rpm builds. >>> >>> We can of course include into our git a whole 1.8.1 dojo/dojo and >>> dojo/util but I would rather avoid it because it's a LOT of files. >>> >>>> >>>>> 2) separate components to individual files and transform then into >>>>> AMD >>>>> modules. We might change namespaces and dependencies to separate >>>>> Web UI >>>>> framework and IPA related stuff. >>>>> 3) change class system of entities and facets >>>>> 4) implement a 'model' >>>>> ? >>>>> At this point it depends on priorities and new tickets with higher >>>>> priority may appear. >>>> >>> >>> >> Still sounds scary... What is the general recommendation? Are the >> arguments for or against Dojo convincing? >> > I proposed it, so the question is mainly for Endi or Adam, if he is > interested (added Cc). > > Just to add: > The question is whether we want to use third party code to solve some > issues or we want to write everything ourselves. Everything I wrote > above can be solved by us but it will probably take much more time. > Dojo itself won't fix our problems it just provides means to fix > them. As Enti wrote, for the problems we have, it can be replaced by > multiple libraries combined(require.js, r.js, backbone.js, > jquery-i18n-properties). > > I don't want to repeat myself much so adding just some dojo-related > pros and cons: > > Cons: > * third party code - we need to watch updates, sec issues > * more complex build of UI which eventually needs more unit tests > (basically I want some build with or without Dojo) > > Pros: > * third party code - don't have to reinvent the wheel > * establish library (good docs, some books were writen) > * using good modular structure, we can pick the parts we actually > want, when we want (loader, builder, class system, object store, > localization, modular system) > My take away is the a Framework is the right direction, but Dojo is not the right Framework. I would look to see if someone has built the equivalent on top of JQuery. If not, pull in the various pieces from JQuery based projects and move forward with that. I think you are right to focus on unit tests and modularity. But I think at this point, you would be better off with an incremental approach. From rcritten at redhat.com Thu Nov 1 14:03:02 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 10:03:02 -0400 Subject: [Freeipa-devel] [PATCH] 1067 clear out certmonger requests In-Reply-To: <50926E36.1000708@redhat.com> References: <50883FFC.8020005@redhat.com> <508E8893.9080007@redhat.com> <508ED4F6.1010605@redhat.com> <508FD6F1.3010605@redhat.com> <50914392.7060409@redhat.com> <50926E36.1000708@redhat.com> Message-ID: <50928116.3010408@redhat.com> 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 From rcritten at redhat.com Thu Nov 1 14:34:36 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 10:34:36 -0400 Subject: [Freeipa-devel] [PATCH] 1070 change user_u context in list Message-ID: <5092887C.1040609@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1070-selinux.patch Type: text/x-diff Size: 1961 bytes Desc: not available URL: From rcritten at redhat.com Thu Nov 1 14:59:32 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 10:59:32 -0400 Subject: [Freeipa-devel] [PATCH] Get list of service from LDAP only at startup In-Reply-To: <50918E22.5050602@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> Message-ID: <50928E54.8070506@redhat.com> Rob Crittenden wrote: > Simo Sorce wrote: >> From: Simo Sorce >> >> 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 From jcholast at redhat.com Thu Nov 1 15:05:57 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Nov 2012 16:05:57 +0100 Subject: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA In-Reply-To: <50884082.70305@redhat.com> References: <50884082.70305@redhat.com> Message-ID: <50928FD5.4010506@redhat.com> 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 From simo at redhat.com Thu Nov 1 15:32:03 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 11:32:03 -0400 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> Message-ID: <1351783923.18469.108.camel@willson.li.ssimo.org> 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 ?ber-objectclass that allows to associate a lot of Asterisk attributes, but it is not clear why you need this class and why you extend AsteriskExtension with it but then add additional Ast attributes. At a quick glance it seem to defeat the purpose of the objectclass division done by the asterisk people. Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better not to use that prefix for custom objects to avoid potential accidental conflicts should they decide to add a class with that name, and in general it is better to avoid confusion, using a different prefix makes it clear that this is not an official digium object but a custom extension. Also you need an OID for this calss, do you have your own OID numberspace from which to assign from ? Otherwise we need to decide how to get you OIDs for your additional schema. I see also that you created some attributes that use the ipa prefix for their name. for these you will also need an OID, and we should probably agree on a subprefix you can use and that we mark as assigned to your plugin so we do not accidentally use a conflicting name for whatever reason. I see the actual prefix ends up being ipaAutoAst for the 2 attributes you defined. Perhaps if would be better to use ipaAstAuto as a prefix instead, and we mark the whole sub-namespace 'ipaAst' as a name space that you use in your plugin. (So maybe you want to use ipaAstSitesDefaults for your custom objectclass) To make things clearer I would suggest you to use 2 schema files; one with the official digium objects and an additional one that depends on it with the plugin custom objects. The basic DIT looks ok, but there isn't much detail on what you plan to put in each sub container (sorry if this should be obvious to Asterisk-versed people, I know the project only by name and never configured an Asterisk server myself). I see that there is a astAccountSecret attribute that seem to hold a clear text password ? I assume it is desired that the SIP password is actually *not* synchronized with the FreeIPA account password as it usually is transmitted in the clear by a lot of devices/SIP phones ? Can regular computers be 'endpoint' devices ? (I am thinking softphones) Or an endpoint is always a physical device ? As I said I am not really familiar with Asterisk configuration but all the plugin CLI command looks quite reasonable. What kind of UI do you have in mind for the Web part ? Something inspired by our DNS plugin ? Or something different ? Lots of questions, but you are on a good start! Have fun. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Nov 1 15:32:41 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 11:32:41 -0400 Subject: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA In-Reply-To: <50928FD5.4010506@redhat.com> References: <50884082.70305@redhat.com> <50928FD5.4010506@redhat.com> Message-ID: <50929619.4090800@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1068-2-renewal.patch Type: text/x-diff Size: 6625 bytes Desc: not available URL: From jcholast at redhat.com Thu Nov 1 15:38:39 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Nov 2012 16:38:39 +0100 Subject: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA In-Reply-To: <50929619.4090800@redhat.com> References: <50884082.70305@redhat.com> <50928FD5.4010506@redhat.com> <50929619.4090800@redhat.com> Message-ID: <5092977F.5020002@redhat.com> 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 From simo at redhat.com Thu Nov 1 15:43:23 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 11:43:23 -0400 Subject: [Freeipa-devel] [DHCP] tree layout options In-Reply-To: <5008027E.4070401@firstyear.id.au> References: <5008027E.4070401@firstyear.id.au> Message-ID: <1351784603.18469.113.camel@willson.li.ssimo.org> 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 From rmeggins at redhat.com Thu Nov 1 15:46:04 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 01 Nov 2012 09:46:04 -0600 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1351783923.18469.108.camel@willson.li.ssimo.org> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> Message-ID: <5092993C.6020009@redhat.com> 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 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. Right. That is planned for a future version of 389. > > Btw can you explain what is the use of the AsteriskSiteDefault > objectclass, it looks like an ?ber-objectclass that allows to associate > a lot of Asterisk attributes, but it is not clear why you need this > class and why you extend AsteriskExtension with it but then add > additional Ast attributes. > At a quick glance it seem to defeat the purpose of the objectclass > division done by the asterisk people. > Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better > not to use that prefix for custom objects to avoid potential accidental > conflicts should they decide to add a class with that name, and in > general it is better to avoid confusion, using a different prefix makes > it clear that this is not an official digium object but a custom > extension. > Also you need an OID for this calss, do you have your own OID > numberspace from which to assign from ? > Otherwise we need to decide how to get you OIDs for your additional > schema. > > I see also that you created some attributes that use the ipa prefix for > their name. for these you will also need an OID, and we should probably > agree on a subprefix you can use and that we mark as assigned to your > plugin so we do not accidentally use a conflicting name for whatever > reason. > I see the actual prefix ends up being ipaAutoAst for the 2 attributes > you defined. Perhaps if would be better to use ipaAstAuto as a prefix > instead, and we mark the whole sub-namespace 'ipaAst' as a name space > that you use in your plugin. (So maybe you want to use > ipaAstSitesDefaults for your custom objectclass) > > To make things clearer I would suggest you to use 2 schema files; one > with the official digium objects and an additional one that depends on > it with the plugin custom objects. > > The basic DIT looks ok, but there isn't much detail on what you plan to > put in each sub container (sorry if this should be obvious to > Asterisk-versed people, I know the project only by name and never > configured an Asterisk server myself). > > > I see that there is a astAccountSecret attribute that seem to hold a > clear text password ? I assume it is desired that the SIP password is > actually *not* synchronized with the FreeIPA account password as it > usually is transmitted in the clear by a lot of devices/SIP phones ? > > Can regular computers be 'endpoint' devices ? (I am thinking softphones) > Or an endpoint is always a physical device ? > > As I said I am not really familiar with Asterisk configuration but all > the plugin CLI command looks quite reasonable. > What kind of UI do you have in mind for the Web part ? > Something inspired by our DNS plugin ? Or something different ? > > Lots of questions, but you are on a good start! > Have fun. > > Simo. > From simo at redhat.com Thu Nov 1 15:48:16 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 11:48:16 -0400 Subject: [Freeipa-devel] [PATCH] 1070 change user_u context in list In-Reply-To: <5092887C.1040609@redhat.com> References: <5092887C.1040609@redhat.com> Message-ID: <1351784896.18469.115.camel@willson.li.ssimo.org> 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 From rcritten at redhat.com Thu Nov 1 15:54:10 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 11:54:10 -0400 Subject: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA In-Reply-To: <5092977F.5020002@redhat.com> References: <50884082.70305@redhat.com> <50928FD5.4010506@redhat.com> <50929619.4090800@redhat.com> <5092977F.5020002@redhat.com> Message-ID: <50929B22.3070909@redhat.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1068-3-renewal.patch Type: text/x-diff Size: 6661 bytes Desc: not available URL: From dpal at redhat.com Thu Nov 1 16:47:35 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 01 Nov 2012 12:47:35 -0400 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1351783923.18469.108.camel@willson.li.ssimo.org> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> Message-ID: <5092A7A7.9070802@redhat.com> 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 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 ?ber-objectclass that allows to associate > a lot of Asterisk attributes, but it is not clear why you need this > class and why you extend AsteriskExtension with it but then add > additional Ast attributes. > At a quick glance it seem to defeat the purpose of the objectclass > division done by the asterisk people. > Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better > not to use that prefix for custom objects to avoid potential accidental > conflicts should they decide to add a class with that name, and in > general it is better to avoid confusion, using a different prefix makes > it clear that this is not an official digium object but a custom > extension. > Also you need an OID for this calss, do you have your own OID > numberspace from which to assign from ? > Otherwise we need to decide how to get you OIDs for your additional > schema. > > I see also that you created some attributes that use the ipa prefix for > their name. for these you will also need an OID, and we should probably > agree on a subprefix you can use and that we mark as assigned to your > plugin so we do not accidentally use a conflicting name for whatever > reason. > I see the actual prefix ends up being ipaAutoAst for the 2 attributes > you defined. Perhaps if would be better to use ipaAstAuto as a prefix > instead, and we mark the whole sub-namespace 'ipaAst' as a name space > that you use in your plugin. (So maybe you want to use > ipaAstSitesDefaults for your custom objectclass) > > To make things clearer I would suggest you to use 2 schema files; one > with the official digium objects and an additional one that depends on > it with the plugin custom objects. > > The basic DIT looks ok, but there isn't much detail on what you plan to > put in each sub container (sorry if this should be obvious to > Asterisk-versed people, I know the project only by name and never > configured an Asterisk server myself). > > > I see that there is a astAccountSecret attribute that seem to hold a > clear text password ? I assume it is desired that the SIP password is > actually *not* synchronized with the FreeIPA account password as it > usually is transmitted in the clear by a lot of devices/SIP phones ? > > Can regular computers be 'endpoint' devices ? (I am thinking softphones) > Or an endpoint is always a physical device ? > > As I said I am not really familiar with Asterisk configuration but all > the plugin CLI command looks quite reasonable. > What kind of UI do you have in mind for the Web part ? > Something inspired by our DNS plugin ? Or something different ? > > Lots of questions, but you are on a good start! > Have fun. > > Simo. > -- 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 Thu Nov 1 17:33:37 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Nov 2012 18:33:37 +0100 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <508EA54C.9020700@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> Message-ID: <5092B271.3080905@redhat.com> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0096-Use-correct-Dogtag-configuration-in-get_pin-and-get_.patch Type: text/x-patch Size: 4935 bytes Desc: not available URL: From pviktori at redhat.com Thu Nov 1 17:34:28 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 01 Nov 2012 18:34:28 +0100 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <5092B271.3080905@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> Message-ID: <5092B2A4.6030306@redhat.com> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0097-Update-certmap.conf-on-IPA-upgrades.patch Type: text/x-patch Size: 4333 bytes Desc: not available URL: From rcritten at redhat.com Thu Nov 1 17:38:07 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 13:38:07 -0400 Subject: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA In-Reply-To: <5092A727.8030406@redhat.com> References: <50884082.70305@redhat.com> <50928FD5.4010506@redhat.com> <50929619.4090800@redhat.com> <5092977F.5020002@redhat.com> <50929B22.3070909@redhat.com> <5092A727.8030406@redhat.com> Message-ID: <5092B37F.9080507@redhat.com> 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 From jcholast at redhat.com Thu Nov 1 16:45:27 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 01 Nov 2012 17:45:27 +0100 Subject: [Freeipa-devel] [PATCH] 1068 wait for LDAP when renewing the RA In-Reply-To: <50929B22.3070909@redhat.com> References: <50884082.70305@redhat.com> <50928FD5.4010506@redhat.com> <50929619.4090800@redhat.com> <5092977F.5020002@redhat.com> <50929B22.3070909@redhat.com> Message-ID: <5092A727.8030406@redhat.com> 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 From rcritten at redhat.com Thu Nov 1 18:25:47 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 14:25:47 -0400 Subject: [Freeipa-devel] [PATCH] 88 Reword description of the --passsync option of ipa-replica-manage In-Reply-To: <508ED8F8.8030108@redhat.com> References: <508E4A89.8020507@redhat.com> <508ED8F8.8030108@redhat.com> Message-ID: <5092BEAB.1000006@redhat.com> Rob Crittenden wrote: > Jan Cholasta wrote: >> Hi, >> >> this patch fixes . > > 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 From simo at redhat.com Thu Nov 1 18:28:12 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 14:28:12 -0400 Subject: [Freeipa-devel] [PATCH] Get list of service from LDAP only at startup In-Reply-To: <50928E54.8070506@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> Message-ID: <1351794492.18469.122.camel@willson.li.ssimo.org> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: > Rob Crittenden wrote: > > Simo Sorce wrote: > >> From: Simo Sorce > >> > >> 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 From simo at redhat.com Thu Nov 1 18:33:09 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 14:33:09 -0400 Subject: [Freeipa-devel] [PATCH] 329 Use common encoding in modlist generation In-Reply-To: <508FE064.2020705@redhat.com> References: <508E4FF6.2070809@redhat.com> <508E81D9.5000409@redhat.com> <508EC20D.3060302@redhat.com> <508FE064.2020705@redhat.com> Message-ID: <1351794789.18469.123.camel@willson.li.ssimo.org> 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 From simo at redhat.com Thu Nov 1 19:48:17 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Nov 2012 15:48:17 -0400 Subject: [Freeipa-devel] [PATCH 1/1] Resolve external members from trusted domain via Global Catalog In-Reply-To: <1351716732-27551-2-git-send-email-abokovoy@redhat.com> References: <1351716732-27551-1-git-send-email-abokovoy@redhat.com> <1351716732-27551-2-git-send-email-abokovoy@redhat.com> Message-ID: <1351799297.18469.135.camel@willson.li.ssimo.org> 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_TD 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 From rcritten at redhat.com Thu Nov 1 20:01:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Nov 2012 16:01:26 -0400 Subject: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone In-Reply-To: <508F816C.2070809@redhat.com> References: <508F816C.2070809@redhat.com> Message-ID: <5092D516.4070207@redhat.com> 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 From loris at lgs.com.ve Fri Nov 2 03:36:53 2012 From: loris at lgs.com.ve (Loris Santamaria) Date: Thu, 01 Nov 2012 23:06:53 -0430 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1351783923.18469.108.camel@willson.li.ssimo.org> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> Message-ID: <1351827413.32488.62.camel@toron.pzo.lgs.com.ve> 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 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 ?ber-objectclass that allows to associate > a lot of Asterisk attributes, but it is not clear why you need this > class and why you extend AsteriskExtension with it but then add > additional Ast attributes. > At a quick glance it seem to defeat the purpose of the objectclass > division done by the asterisk people. You have a point here. The purpose was to have a global search on objectClass=AsteriskSIPUser not returning the site configuration/global configuration stuff, but since real SIP objects are in their own container this is not really needed. > Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better > not to use that prefix for custom objects to avoid potential accidental > conflicts should they decide to add a class with that name, and in > general it is better to avoid confusion, using a different prefix makes > it clear that this is not an official digium object but a custom > extension. > Also you need an OID for this calss, do you have your own OID > numberspace from which to assign from ? > Otherwise we need to decide how to get you OIDs for your additional > schema. > > I see also that you created some attributes that use the ipa prefix for > their name. for these you will also need an OID, and we should probably > agree on a subprefix you can use and that we mark as assigned to your > plugin so we do not accidentally use a conflicting name for whatever > reason. > I see the actual prefix ends up being ipaAutoAst for the 2 attributes > you defined. Perhaps if would be better to use ipaAstAuto as a prefix > instead, and we mark the whole sub-namespace 'ipaAst' as a name space > that you use in your plugin. (So maybe you want to use > ipaAstSitesDefaults for your custom objectclass) > > To make things clearer I would suggest you to use 2 schema files; one > with the official digium objects and an additional one that depends on > it with the plugin custom objects. Agreed, every new object will belong to the ipaAst sub-namespace. We will need an OID for that. Please note that this schema may grow in the future as Asterisk is very flexible in this respect. In fact the list of LDAP attributes used by Asterisk is configured at runtime, and it can retrieve from LDAP the configuration of other types of telephony features, like queues and conference rooms, even tough these are not defined in the standard schema. For now we will begin with SIP, IAX and Voicemail stuff > The basic DIT looks ok, but there isn't much detail on what you plan to > put in each sub container (sorry if this should be obvious to > Asterisk-versed people, I know the project only by name and never > configured an Asterisk server myself). > > > I see that there is a astAccountSecret attribute that seem to hold a > clear text password ? I assume it is desired that the SIP password is > actually *not* synchronized with the FreeIPA account password as it > usually is transmitted in the clear by a lot of devices/SIP phones ? The secret is used by the phone to authenticate itself against Asterisk, and the phone gets this password over a configuration file downloaded via TFTP or HTTP, a file which should be generated automatically by an "endpoint manager", so it would have to be kept in clear text. Only Asterisk and the endpoint manager would be able to read this password from the directory using a proper ACI and a bind user. It is not an ideal situation but for now it is the only authentication scheme that works with all brands of phones. Maybe in the future one will be able to use certificate authentication for phones. > Can regular computers be 'endpoint' devices ? (I am thinking softphones) > Or an endpoint is always a physical device ? Yes, the endpoint could be a computer. > As I said I am not really familiar with Asterisk configuration but all > the plugin CLI command looks quite reasonable. > What kind of UI do you have in mind for the Web part ? > Something inspired by our DNS plugin ? Or something different ? Nothing defined so far, it could be something like Asterisk =========================================================== Sites SIP IAX Voicemail Dialplan Global Config > Lots of questions, but you are on a good start! > Have fun. > > Simo. > Thanks for the feedback! -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford From loris at lgs.com.ve Fri Nov 2 04:25:44 2012 From: loris at lgs.com.ve (Loris Santamaria) Date: Thu, 01 Nov 2012 23:55:44 -0430 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <5092A7A7.9070802@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> Message-ID: <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> 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 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 ?ber-objectclass that allows to associate > > a lot of Asterisk attributes, but it is not clear why you need this > > class and why you extend AsteriskExtension with it but then add > > additional Ast attributes. > > At a quick glance it seem to defeat the purpose of the objectclass > > division done by the asterisk people. > > Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better > > not to use that prefix for custom objects to avoid potential accidental > > conflicts should they decide to add a class with that name, and in > > general it is better to avoid confusion, using a different prefix makes > > it clear that this is not an official digium object but a custom > > extension. > > Also you need an OID for this calss, do you have your own OID > > numberspace from which to assign from ? > > Otherwise we need to decide how to get you OIDs for your additional > > schema. > > > > I see also that you created some attributes that use the ipa prefix for > > their name. for these you will also need an OID, and we should probably > > agree on a subprefix you can use and that we mark as assigned to your > > plugin so we do not accidentally use a conflicting name for whatever > > reason. > > I see the actual prefix ends up being ipaAutoAst for the 2 attributes > > you defined. Perhaps if would be better to use ipaAstAuto as a prefix > > instead, and we mark the whole sub-namespace 'ipaAst' as a name space > > that you use in your plugin. (So maybe you want to use > > ipaAstSitesDefaults for your custom objectclass) > > > > To make things clearer I would suggest you to use 2 schema files; one > > with the official digium objects and an additional one that depends on > > it with the plugin custom objects. > > > > The basic DIT looks ok, but there isn't much detail on what you plan to > > put in each sub container (sorry if this should be obvious to > > Asterisk-versed people, I know the project only by name and never > > configured an Asterisk server myself). > > > > > > I see that there is a astAccountSecret attribute that seem to hold a > > clear text password ? I assume it is desired that the SIP password is > > actually *not* synchronized with the FreeIPA account password as it > > usually is transmitted in the clear by a lot of devices/SIP phones ? > > > > Can regular computers be 'endpoint' devices ? (I am thinking softphones) > > Or an endpoint is always a physical device ? > > > > As I said I am not really familiar with Asterisk configuration but all > > the plugin CLI command looks quite reasonable. > > What kind of UI do you have in mind for the Web part ? > > Something inspired by our DNS plugin ? Or something different ? > > > > Lots of questions, but you are on a good start! > > Have fun. > > > > Simo. > > > > -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford From mkosek at redhat.com Fri Nov 2 08:12:56 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Nov 2012 09:12:56 +0100 Subject: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone In-Reply-To: <5092D516.4070207@redhat.com> References: <508F816C.2070809@redhat.com> <5092D516.4070207@redhat.com> Message-ID: <50938088.703@redhat.com> On 11/01/2012 09:01 PM, Rob Crittenden wrote: > 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 > Fixed both. After a short discussion with Petr Spacek I also added a possibility to set global dnsconfig to NONE. On a different note, I discovered that global forwarders in bind-dyndb-ldap/bind are actually broken with referred bind-dyndb-ldap/bind version. Thus, we may want to bump bind-dyndb-ldap version in spec when this is resolved. (This should not affect diff in dns.py in any way). Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-330-2-disable-global-forwarding-per-zone.patch Type: text/x-patch Size: 8463 bytes Desc: not available URL: From mkosek at redhat.com Fri Nov 2 09:46:02 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Nov 2012 10:46:02 +0100 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <1351794492.18469.122.camel@willson.li.ssimo.org> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> Message-ID: <5093965A.1020603@redhat.com> On 11/01/2012 07:28 PM, Simo Sorce wrote: > On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Simo Sorce wrote: >>>> From: Simo Sorce >>>> >>>> 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. While trying to follow this thread, I must throw my 2 conservative cents in. This thread is a very good example why processing our patches via patchwork is IMHO rather fuzzy and can cause more confusion than clarity. These are my main points: I cannot see which patches are the recent ones. Each patch is sent separately in mail body and I cannot quickly see by looking in thread which mail contains a revised patch and which is just a comment. When patches are attached directly to mail as files, I can quickly distinguish which mail has new patch set as it has "the paperclip icon". It also enabled us to attach a whole set of valid patches to one mail and thus make it easier for reviewer to pull a whole set of valid patches in one click. Patchwork style patch sending also generates a lot of mails which may confuse not only me but other contributors... Comments welcome, Martin From jcholast at redhat.com Fri Nov 2 09:51:38 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Nov 2012 10:51:38 +0100 Subject: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone In-Reply-To: <50938088.703@redhat.com> References: <508F816C.2070809@redhat.com> <5092D516.4070207@redhat.com> <50938088.703@redhat.com> Message-ID: <509397AA.6030208@redhat.com> Hi, On 2.11.2012 09:12, Martin Kosek wrote: > On 11/01/2012 09:01 PM, Rob Crittenden wrote: >> 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 >> > > Fixed both. After a short discussion with Petr Spacek I also added a > possibility to set global dnsconfig to NONE. > > On a different note, I discovered that global forwarders in > bind-dyndb-ldap/bind are actually broken with referred bind-dyndb-ldap/bind > version. Thus, we may want to bump bind-dyndb-ldap version in spec when this is > resolved. (This should not affect diff in dns.py in any way). > > Martin > This might be a stupid question, but why is "NONE" in upper case and the rest of the values in lower case? Honza -- Jan Cholasta From mkosek at redhat.com Fri Nov 2 10:08:37 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Nov 2012 11:08:37 +0100 Subject: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone In-Reply-To: <509397AA.6030208@redhat.com> References: <508F816C.2070809@redhat.com> <5092D516.4070207@redhat.com> <50938088.703@redhat.com> <509397AA.6030208@redhat.com> Message-ID: <50939BA5.9050305@redhat.com> On 11/02/2012 10:51 AM, Jan Cholasta wrote: > Hi, > > On 2.11.2012 09:12, Martin Kosek wrote: >> On 11/01/2012 09:01 PM, Rob Crittenden wrote: >>> 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 >>> >> >> Fixed both. After a short discussion with Petr Spacek I also added a >> possibility to set global dnsconfig to NONE. >> >> On a different note, I discovered that global forwarders in >> bind-dyndb-ldap/bind are actually broken with referred bind-dyndb-ldap/bind >> version. Thus, we may want to bump bind-dyndb-ldap version in spec when this is >> resolved. (This should not affect diff in dns.py in any way). >> >> Martin >> > > This might be a stupid question, but why is "NONE" in upper case and the rest > of the values in lower case? > > Honza > This really doesn't matter function-wise, as bind-dydnb-ldap does the comparison in case insensitive way. My original intention was to be consistent with other NONE values we use across IPA and to distinguish the value from valid BIND values. But you are right that within dns plugin it makes more sense to have it all lowercase. Updated patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-330-3-disable-global-forwarding-per-zone.patch Type: text/x-patch Size: 8463 bytes Desc: not available URL: From pviktori at redhat.com Fri Nov 2 10:10:50 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Nov 2012 11:10:50 +0100 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <5093965A.1020603@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> Message-ID: <50939C2A.4080304@redhat.com> On 11/02/2012 10:46 AM, Martin Kosek wrote: > On 11/01/2012 07:28 PM, Simo Sorce wrote: >> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> From: Simo Sorce >>>>> >>>>> 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. > > While trying to follow this thread, I must throw my 2 conservative cents in. > This thread is a very good example why processing our patches via patchwork is > IMHO rather fuzzy and can cause more confusion than clarity. These are my main > points: > > I cannot see which patches are the recent ones. Each patch is sent separately > in mail body and I cannot quickly see by looking in thread which mail contains > a revised patch and which is just a comment. > > When patches are attached directly to mail as files, I can quickly distinguish > which mail has new patch set as it has "the paperclip icon". It also enabled us > to attach a whole set of valid patches to one mail and thus make it easier for > reviewer to pull a whole set of valid patches in one click. > > > Patchwork style patch sending also generates a lot of mails which may confuse > not only me but other contributors... +1 This particular thread is extremely confusing. Each individual patch generated its own subthread, and then the revised patches were sent as a reply the original, spawning new threads to continue the old ones. The discussion is broken up and impossible to navigate. You can't see where the patches are, let alone where to look for latest versions. Thanks to Rob for showing us that even a person following the thread is easily confused. Patchwork adds a view that is incomplete and not cross-linked. To make a comment on a patch, you need to do it by e-mail; finding a patch in Patchwork is useless for this. Same for assigning a reviewer: you need to find it "manually" in Patchwork even if you have the mail in front of you. I don't really see Patchwork's advantage. For a list of "active" patches, we have the "Patch submitted" bit in Trac; to claim a larger review we could have a policy to announce this on the list. And the claim that Patchwork doesn't change our current practices is simply false. -- Petr? From james.hogarth at gmail.com Fri Nov 2 10:16:47 2012 From: james.hogarth at gmail.com (James Hogarth) Date: Fri, 2 Nov 2012 10:16:47 +0000 Subject: [Freeipa-devel] [PATCH] Allow TTL to be configured during ipa-client-install Message-ID: Hi, Now that the mirror patch has been committed to SSSD 1.10 I thought it sensible to submit this patch to FreeIPA to allow ipa-client-install to configure this SSSD action... I was holding back for a full TTL rework but that's taking longer than I expected and would rather not miss this part now that the SSSD side is in place for 1.10 ... The patch adds a new option to ipa-client-install --dns-updates-ttl to configure the TTL for dynamic updates at registration time. I hope to be able to present a suitable patch that exposes TTL of DNS records in the UI for configuration in the next couple of weeks. Kind regards, James -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-TTL-to-be-configured-dring-ipa-client-install.patch Type: application/octet-stream Size: 5262 bytes Desc: not available URL: From jcholast at redhat.com Fri Nov 2 11:20:05 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Nov 2012 12:20:05 +0100 Subject: [Freeipa-devel] [PATCH] 88 Reword description of the --passsync option of ipa-replica-manage In-Reply-To: <5092BEAB.1000006@redhat.com> References: <508E4A89.8020507@redhat.com> <508ED8F8.8030108@redhat.com> <5092BEAB.1000006@redhat.com> Message-ID: <5093AC65.6030401@redhat.com> On 1.11.2012 19:25, Rob Crittenden wrote: > Rob Crittenden wrote: >> Jan Cholasta wrote: >>> Hi, >>> >>> this patch fixes . >> >> 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 > > Thanks, added. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-88.1-Reword-description-of-the-passsync-option-of-ipa-rep.patch Type: text/x-patch Size: 3209 bytes Desc: not available URL: From pspacek at redhat.com Fri Nov 2 11:22:40 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 02 Nov 2012 12:22:40 +0100 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <50939C2A.4080304@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> Message-ID: <5093AD00.5000907@redhat.com> On 11/02/2012 11:10 AM, Petr Viktorin wrote: > On 11/02/2012 10:46 AM, Martin Kosek wrote: >> On 11/01/2012 07:28 PM, Simo Sorce wrote: >>> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: >>>> Rob Crittenden wrote: >>>>> Simo Sorce wrote: >>>>>> From: Simo Sorce >>>>>> >>>>>> 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. >> >> While trying to follow this thread, I must throw my 2 conservative cents in. >> This thread is a very good example why processing our patches via patchwork is >> IMHO rather fuzzy and can cause more confusion than clarity. These are my main >> points: >> >> I cannot see which patches are the recent ones. Each patch is sent separately >> in mail body and I cannot quickly see by looking in thread which mail contains >> a revised patch and which is just a comment. >> >> When patches are attached directly to mail as files, I can quickly distinguish >> which mail has new patch set as it has "the paperclip icon". It also enabled us >> to attach a whole set of valid patches to one mail and thus make it easier for >> reviewer to pull a whole set of valid patches in one click. > > >> >> Patchwork style patch sending also generates a lot of mails which may confuse >> not only me but other contributors... > > +1 > > This particular thread is extremely confusing. Each individual patch generated > its own subthread, and then the revised patches were sent as a reply the > original, spawning new threads to continue the old ones. The discussion is > broken up and impossible to navigate. You can't see where the patches are, let > alone where to look for latest versions. > Thanks to Rob for showing us that even a person following the thread is easily > confused. > > Patchwork adds a view that is incomplete and not cross-linked. > To make a comment on a patch, you need to do it by e-mail; finding a patch in > Patchwork is useless for this. Same for assigning a reviewer: you need to find > it "manually" in Patchwork even if you have the mail in front of you. > > > I don't really see Patchwork's advantage. For a list of "active" patches, we > have the "Patch submitted" bit in Trac; to claim a larger review we could have > a policy to announce this on the list. And the claim that Patchwork doesn't > change our current practices is simply false. > As guys described above, Patchwork influenced our process a lot and, personally, I don't like these changes. +1 from me to more rational Trac usage. We can simply set bit and/or reviewer name in Trac through API and avoid all changes introduced with Patchwork. Simple script and appropriate Trac query can do better work for us. -- Petr^2 Spacek From sbose at redhat.com Fri Nov 2 11:54:15 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 2 Nov 2012 12:54:15 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <50913DB2.5040908@redhat.com> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> Message-ID: <20121102115415.GL10066@localhost.localdomain> On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: > On 10/30/2012 12:16 PM, Sumit Bose wrote: > > Hi, > > > > this patch allows ipa-adtrust-install to reset the NetBIOS domain name > > and fixes https://fedorahosted.org/freeipa/ticket/3192 . > > > > bye, > > Sumit > > > > > Hello Sumit, > > I found few issues with your patch: Thank you for the review. > > 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not > think this is necessary, ipa-adtrust-install already requires admin password to > be passed and it already connects to LDAP with these credentials: > > api.Backend.ldap2.connect(ccache.name) > > You could use ipa.Backend.ldap2 object to do entry retrieval > (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. fixed > > 2) When doing try..except statement, rule of thumb says that it should be as > short as possible, so that it does not hide other potential errors and makes > clear what function raises the catched exception. > > In your case: > > try: > entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), > api.env.container_cifsdomains, > self.api.env.basedn), > ['ipantflatname']) > except errors.NotFound: > reset_netbios_name = False > else: > # process entry > > Should be a pattern that you want. fixed I also move all the NetBIOS name related code into a separate function. > > 3) I think this line is redundant: > + print "Say 'yes' if the NetBIOS shall be changed and " \ > + "'no' if the old one shall be kept." > > IMO, the question: > > reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default > = False, allow_empty = False) > > and the information printed before is enough. I would prefer to keep it this way to make clear that ipa-adtrust-install will continue processing, but the old name if kept even if a new name was given with --netbios-name on the command line. New version attached. bye, Sumit > > Martin -------------- next part -------------- From d0c460d44414bd35703943cd94ea81b814092d51 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 29 Oct 2012 21:43:56 +0100 Subject: [PATCH] ipa-adtrust-install: allow to reset te NetBIOS domain name Fixes https://fedorahosted.org/freeipa/ticket/3192 --- install/tools/ipa-adtrust-install | 108 ++++++++++++++++++++++++++------ install/tools/man/ipa-adtrust-install.1 | 6 +- ipaserver/install/adtrustinstance.py | 24 ++++++- 3 Dateien ge?ndert, 116 Zeilen hinzugef?gt(+), 22 Zeilen entfernt(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 52179038e84a08ea6abb3ee26d8e668efe0a2b13..7bb9f2f25f8fb501557eacbf68c3ea8d7975128c 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -71,7 +71,7 @@ def parse_options(): return safe_options, options def netbios_name_error(name): - print "Illegal NetBIOS name [%s].\n" % name + print "\nIllegal NetBIOS name [%s].\n" % name print "Up to 15 characters and only uppercase ASCII letter and digits are allowed." def read_netbios_name(netbios_default): @@ -101,6 +101,89 @@ def read_admin_password(admin_name): admin_password = read_password(admin_name, confirm=False, validate=None) return admin_password +def set_and_check_netbios_name(netbios_name, unattended): + """ + Depending if trust in already configured or not a given NetBIOS domain + name must be handled differently. + + If trust is not configured the given NetBIOS is used or the NetBIOS is + generated if none was given on the command line. + + If trust is already configured the given NetBIOS name is used to reset + the stored NetBIOS name it it differs from the current one. + """ + + flat_name_attr = 'ipantflatname' + cur_netbios_name = None + reset_netbios_name = False + dom_dn = None + + try: + (dom_dn, entry) = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), + api.env.container_cifsdomains, + ipautil.realm_to_suffix(api.env.realm)), + [flat_name_attr]) + except errors.NotFound: + # trust not configured + pass + else: + cur_netbios_name = entry.get(flat_name_attr)[0] + + if cur_netbios_name and not netbios_name: + # keep the current NetBIOS name + netbios_name = cur_netbios_name + reset_netbios_name = False + elif cur_netbios_name and cur_netbios_name != netbios_name: + # change the NetBIOS name + print "Current NetBIOS domain name is %s new name is %s.\n" % \ + (cur_netbios_name, netbios_name) + print "Please note that changing the NetBIOS name might " \ + "break existing trust relationships." + if unattended: + reset_netbios_name = True + print "NetBIOS domain name will be changes to %s.\n" % \ + netbios_name + else: + print "Say 'yes' if the NetBIOS shall be changed and " \ + "'no' if the old one shall be kept." + reset_netbios_name = ipautil.user_input( + 'Do you want to reset the NetBIOS domain name?', + default = False, allow_empty = False) + if not reset_netbios_name: + netbios_name = cur_netbios_name + elif cur_netbios_name and cur_netbios_name == netbios_name: + # keep the current NetBIOS name + reset_netbios_name = False + elif not cur_netbios_name: + if not netbios_name: + netbios_name = adtrustinstance.make_netbios_name(api.env.domain) + + if dom_dn: + # Fix existing trust configuration + print "Trust is configured but no NetBIOS domain name found, " \ + "setting it now." + reset_netbios_name = True + else: + # initial trust configuration + reset_netbios_name = False + else: + # all possible cases should be covered above + raise Exception('Unexpected state while checking NetBIOS domain name') + + if not adtrustinstance.check_netbios_name(netbios_name): + if unattended: + netbios_name_error(netbios_name) + sys.exit("Aborting installation.") + else: + if netbios_name: + netbios_name_error(netbios_name) + netbios_name = None + + if not unattended and not netbios_name: + netbios_name = read_netbios_name(netbios_name) + + return (netbios_name, reset_netbios_name) + def ensure_admin_kinit(admin_name, admin_password): try: ipautil.run(['kinit', admin_name], stdin=admin_password+'\n') @@ -197,22 +280,6 @@ def main(): print "Please wait until the prompt is returned." print "" - netbios_name = options.netbios_name - if not netbios_name: - netbios_name = adtrustinstance.make_netbios_name(api.env.domain) - - if not adtrustinstance.check_netbios_name(netbios_name): - if options.unattended: - netbios_name_error(netbios_name) - sys.exit("Aborting installation.") - else: - netbios_name = None - if options.netbios_name: - netbios_name_error(options.netbios_name) - - if not options.unattended and ( not netbios_name or not options.netbios_name): - netbios_name = read_netbios_name(netbios_name) - admin_password = options.admin_password if not (options.unattended or admin_password): admin_password = read_admin_password(options.admin_name) @@ -248,11 +315,16 @@ def main(): except Exception, e: sys.exit("Unrecognized error during check of admin rights: %s" % (str(e))) + (netbios_name, reset_netbios_name) = \ + set_and_check_netbios_name(options.netbios_name, + options.unattended) + smb = adtrustinstance.ADTRUSTInstance(fstore) smb.realm = api.env.realm smb.autobind = service.ENABLED smb.setup(api.env.host, ip_address, api.env.realm, api.env.domain, - netbios_name, options.rid_base, options.secondary_rid_base, + netbios_name, reset_netbios_name, + options.rid_base, options.secondary_rid_base, options.no_msdcs, options.add_sids) smb.find_local_id_range() smb.create_instance() diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index 9204b7d5fde7493a4c268eb71693e86a63a1b4b7..38957f3a486ec4d3108e7ccdc955880dc65a3873 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -42,7 +42,11 @@ Enable debug logging when more verbose output is needed The IP address of the IPA server. If not provided then this is determined based on the hostname of the server. .TP \fB\-\-netbios\-name\fR=\fINETBIOS_NAME\fR -The NetBIOS name for the IPA domain. If not provided then this is determined based on the leading component of the DNS domain name. +The NetBIOS name for the IPA domain. If not provided then this is determined +based on the leading component of the DNS domain name. Running +ipa\-adtrust\-install for a second time with a different NetBIOS name will +change the name. Please note that changing the NetBIOS name might break +existing trust relationships to other domains. .TP \fB\-\-no\-msdcs\fR Do not create DNS service records for Windows in managed DNS server. Since those diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index c27fac99cf624ca6460ce84e76be52db38f11a5b..16f2136a6485e6915fd5de2000e6a378d03b44aa 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -115,6 +115,7 @@ class ADTRUSTInstance(service.Service): self.realm = None self.domain_name = None self.netbios_name = None + self.reset_netbios_name = None self.no_msdcs = None self.add_sids = None self.smbd_user = None @@ -295,11 +296,27 @@ class ADTRUSTInstance(service.Service): "define it and run again.") raise e + def __reset_netbios_name(self): + """ + Set the NetBIOS domain name to a new value. + """ + self.print_msg("Reset NetBIOS domain name") + + try: + self.admin_conn.modify_s(self.smb_dom_dn, + [(ldap.MOD_REPLACE, self.ATTR_FLAT_NAME, + self.netbios_name)]) + except ldap.LDAPError: + self.print_msg("Failed to reset the NetBIOS domain name") + def __create_samba_domain_object(self): try: self.admin_conn.getEntry(self.smb_dom_dn, ldap.SCOPE_BASE) - root_logger.info("Samba domain object already exists") + if self.reset_netbios_name: + self.__reset_netbios_name() + else : + self.print_msg("Samba domain object already exists") return except errors.NotFound: pass @@ -653,13 +670,14 @@ class ADTRUSTInstance(service.Service): FQDN = self.fqdn) def setup(self, fqdn, ip_address, realm_name, domain_name, netbios_name, - rid_base, secondary_rid_base, no_msdcs=False, add_sids=False, - smbd_user="samba"): + reset_netbios_name, rid_base, secondary_rid_base, + no_msdcs=False, add_sids=False, smbd_user="samba"): self.fqdn = fqdn self.ip_address = ip_address self.realm = realm_name self.domain_name = domain_name self.netbios_name = netbios_name + self.reset_netbios_name = reset_netbios_name self.rid_base = rid_base self.secondary_rid_base = secondary_rid_base self.no_msdcs = no_msdcs -- 1.7.11.4 From pviktori at redhat.com Fri Nov 2 12:08:47 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 02 Nov 2012 13:08:47 +0100 Subject: [Freeipa-devel] [TIP] Making sense of parallel Git branches Message-ID: <5093B7CF.4070806@redhat.com> Hi, We had some discussion about finding changes pushed to one Git branch but not another. This command might be also useful to other maintainers: git log --oneline --cherry-pick --left-right origin/master...origin/ipa-3-0 This will show patches that are only in one branch or the other. It also marks the branch with < or >. There are some false positives when the diffs don't match exactly, but still it should make some people's lives much easier. Enjoy your Friday! -- Petr? From abokovoy at redhat.com Fri Nov 2 12:19:40 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Nov 2012 14:19:40 +0200 Subject: [Freeipa-devel] [PATCH] 0089 Clarify trust-add help regarding multiple runs against the same domain In-Reply-To: <507E8F9F.4060606@redhat.com> References: <20121010150502.GY17454@redhat.com> <20121017105211.GT23959@localhost.localdomain> <507E8F9F.4060606@redhat.com> Message-ID: <20121102121940.GS4353@redhat.com> On Wed, 17 Oct 2012, Martin Kosek wrote: >On 10/17/2012 12:52 PM, Sumit Bose wrote: >> On Wed, Oct 10, 2012 at 06:05:02PM +0300, Alexander Bokovoy wrote: >>> Hi, >>> >>> this patch originated from off-list discussion regarding multiple runs >>> of ipa trust-add against the same domain. >>> >>> Since trust-add re-establishes the trust every time it is run and all >>> the other information fetched from the remote domain controller stays >>> the same, it can be run multiple times. The only change would occur is >>> update of trust relationship credentials -- they are supposed to be >>> updated periodically by underlying infrastructure anyway. >>> >>> So the patch adds some clarity to the help and changes summary message >>> when trust was re-established instead of created. >>> -- >>> / Alexander Bokovoy >> >> ACK >> >> Btw, another useful feature of allowing to run trust-add multiple times >> is to re-established the trust if it was deleted only on one side, AD or >> IPA. Having a separate command for this would make no sense because it >> would be basically be an alias to trust-add. >> >> bye, >> Sumit >> > >I am still a bit worried about our consistency with IPA command help >indentation. You have it indented with trust-add command: > ># ipa help trust-add >Purpose: Add new trust to use. > > This command establishes trust relationship to another domain > which becomes 'trusted'. As result, users of the trusted domain > may access resources of this domain. >... A fix is attached. -- / Alexander Bokovoy -------------- next part -------------- >From 44550cf83aac289363e3ca2acc789bc81cef351d Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 10 Oct 2012 15:33:50 +0300 Subject: [PATCH 5/5] Clarify trust-add help regarding multiple runs against the same domain Since trust-add re-establishes the trust every time it is run and all the other information fetched from the remote domain controller stays the same, it can be run multiple times. The only change would occur is update of trust relationship credentials -- they are supposed to be updated periodically by underlying infrastructure anyway. --- ipalib/plugins/trust.py | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/ipalib/plugins/trust.py b/ipalib/plugins/trust.py index 845f96e1fdd09d1e85f6f900d3f1c241445b9c6b..8632d42df578d81b6fdbcd9e5be8979994699206 100644 --- a/ipalib/plugins/trust.py +++ b/ipalib/plugins/trust.py @@ -179,7 +179,19 @@ def make_trust_dn(env, trust_type, dn): return dn class trust_add(LDAPCreate): - __doc__ = _('Add new trust to use') + __doc__ = _(''' +Add new trust to use. + +This command establishes trust relationship to another domain +which becomes 'trusted'. As result, users of the trusted domain +may access resources of this domain. + +Only trusts to Active Directory domains are supported right now. + +The command can be safely run multiple times against the same domain, +this will cause change to trust relationship credentials on both +sides. + ''') takes_options = LDAPCreate.takes_options + ( StrEnum('trust_type', @@ -309,6 +321,11 @@ class trust_add(LDAPCreate): reason=_('''Cannot perform join operation without own domain configured. Make sure you have run ipa-adtrust-install on the IPA server first''')) + try: + existing_trust = api.Command['trust_show'](keys[-1]) + summary = _('Re-established trust to domain "%(value)s"') + except errors.NotFound: + summary = self.msg_summary # 1. Full access to the remote domain. Use admin credentials and # generate random trustdom password to do work on both sides if 'realm_admin' in options: @@ -360,14 +377,19 @@ class trust_add(LDAPCreate): raise errors.ValidationError(name=_('AD Trust setup'), error=_('Unable to verify write permissions to the AD')) - return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret = dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret['summary'] = summary % ret + return ret + # 2. We don't have access to the remote domain and trustdom password # is provided. Do the work on our side and inform what to do on remote # side. if 'trust_secret' in options: result = trustinstance.join_ad_ipa_half(keys[-1], realm_server, options['trust_secret']) - return dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret = dict(value=trustinstance.remote_domain.info['dns_domain'], verified=result['verified']) + ret['summary'] = summary % ret + return ret raise errors.ValidationError(name=_('AD Trust setup'), error=_('Not enough arguments specified to perform trust setup')) -- 1.7.12 From dpal at redhat.com Fri Nov 2 13:09:08 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 09:09:08 -0400 Subject: [Freeipa-devel] [PATCH] Allow TTL to be configured during ipa-client-install In-Reply-To: References: Message-ID: <5093C5F4.8020307@redhat.com> On 11/02/2012 06:16 AM, James Hogarth wrote: > Hi, > > Now that the mirror patch has been committed to SSSD 1.10 I thought it > sensible to submit this patch to FreeIPA to allow ipa-client-install > to configure this SSSD action... > > I was holding back for a full TTL rework but that's taking longer than > I expected and would rather not miss this part now that the SSSD side > is in place for 1.10 ... > > The patch adds a new option to ipa-client-install --dns-updates-ttl to > configure the TTL for dynamic updates at registration time. > > I hope to be able to present a suitable patch that exposes TTL of DNS > records in the UI for configuration in the next couple of weeks. > > Kind regards, > > James Thank you for a patch James. Was there any specific ticket on the IPA side to connect this patch too? If not can you please open such ticket in the freeipa trac instance? https://fedorahosted.org/freeipa/ It would help us to make sure the work you have done is not lost. Also since it is an enhancement would you mind putting together a paragraph that would describe following about this feature: 1) Overview - what feature is about 2) Use case - why it is needed 3) How to test it 4) Anything that needs to be documented 5) Examples of use You can send this to the list or attache to the ticket. We are trying to be a bit more formal in tracking the new features so that we know what they are and how to test them. We will put it on the wiki and reference from the ticket. I hope you would find this request reasonable. And thank you again for the interest and contribution to the IPA project. We really appreciate it! 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: From pvoborni at redhat.com Fri Nov 2 13:10:39 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 02 Nov 2012 14:10:39 +0100 Subject: [Freeipa-devel] [PATCH] 225 Web UI: disable global forwarding per zone Message-ID: <5093C64F.6030607@redhat.com> Web UI part of 'disable global forwarding per zone' effort. Option "Forwarding disabled" was added to 'DNS global config' and 'DNS zone' forwarding policy. It corresponds to 'none' value of idnsforwardpolicy. https://fedorahosted.org/freeipa/ticket/3209 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0225-Web-UI-disable-global-forwarding-per-zone.patch Type: text/x-patch Size: 3080 bytes Desc: not available URL: From dpal at redhat.com Fri Nov 2 13:16:57 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 09:16:57 -0400 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <5093AD00.5000907@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> Message-ID: <5093C7C9.7090606@redhat.com> On 11/02/2012 07:22 AM, Petr Spacek wrote: > On 11/02/2012 11:10 AM, Petr Viktorin wrote: >> On 11/02/2012 10:46 AM, Martin Kosek wrote: >>> On 11/01/2012 07:28 PM, Simo Sorce wrote: >>>> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> Simo Sorce wrote: >>>>>>> From: Simo Sorce >>>>>>> >>>>>>> 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. >>> >>> While trying to follow this thread, I must throw my 2 conservative >>> cents in. >>> This thread is a very good example why processing our patches via >>> patchwork is >>> IMHO rather fuzzy and can cause more confusion than clarity. These >>> are my main >>> points: >>> >>> I cannot see which patches are the recent ones. Each patch is sent >>> separately >>> in mail body and I cannot quickly see by looking in thread which >>> mail contains >>> a revised patch and which is just a comment. >>> >>> When patches are attached directly to mail as files, I can quickly >>> distinguish >>> which mail has new patch set as it has "the paperclip icon". It also >>> enabled us >>> to attach a whole set of valid patches to one mail and thus make it >>> easier for >>> reviewer to pull a whole set of valid patches in one click. >> > >>> >>> Patchwork style patch sending also generates a lot of mails which >>> may confuse >>> not only me but other contributors... >> >> +1 >> >> This particular thread is extremely confusing. Each individual patch >> generated >> its own subthread, and then the revised patches were sent as a reply the >> original, spawning new threads to continue the old ones. The >> discussion is >> broken up and impossible to navigate. You can't see where the patches >> are, let >> alone where to look for latest versions. >> Thanks to Rob for showing us that even a person following the thread >> is easily >> confused. >> >> Patchwork adds a view that is incomplete and not cross-linked. >> To make a comment on a patch, you need to do it by e-mail; finding a >> patch in >> Patchwork is useless for this. Same for assigning a reviewer: you >> need to find >> it "manually" in Patchwork even if you have the mail in front of you. >> >> >> I don't really see Patchwork's advantage. For a list of "active" >> patches, we >> have the "Patch submitted" bit in Trac; to claim a larger review we >> could have >> a policy to announce this on the list. And the claim that Patchwork >> doesn't >> change our current practices is simply false. >> > > As guys described above, Patchwork influenced our process a lot and, > personally, I don't like these changes. > > +1 from me to more rational Trac usage. We can simply set bit and/or > reviewer name in Trac through API and avoid all changes introduced > with Patchwork. > > Simple script and appropriate Trac query can do better work for us. > OK. It looks like it brings more disruption than benefit. Simo, can we please get back to the original method at least for now? At this stage of development it see a lot of disruption that we can't afford. Patch tracking problem exists - I do not deny it but it seems that the change to patchwork does not bring the benefits you hoped. I have an action item to explore what we can do with other tools we considered like Gerrit. We might be not that far from it becoming an option. I will follow up and let you know. -- 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 Fri Nov 2 13:36:02 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 09:36:02 -0400 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> Message-ID: <5093CC42.3060003@redhat.com> On 11/02/2012 12:25 AM, Loris Santamaria wrote: > 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. IMO it can be eventually. It really depends on your goals. > 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. So you are potentially open to moving the project under the "IPA" optional area that currently does not exists but can be created because this project sets a precedent. Let us work out the details when the code is functional. > > You could set some guidelines for projects like this. Yes, but we do not have them yet, so it is a good opportunity to identify what these guidelines should include and start putting together a wiki page to provide a guidance. But this is so far uncharted territory so please bear with us and any help in this area would be appreciated. I will try to put together a wiki page to cover what we already learned from this thread. I also need to read more about Asterisk before I can proceed. > 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? Yes and no. IMO we need to differentiate the components even optional ones that are or will be developed within IPA project and are completely external and independent components developed independently. We need guidance for both but historically it is hard to plan in advance until someone starts actual work. So may be the guideline should state "figure out what the container name for the data you are going to add will be, here are XYZ constraints to consider". This is exactly what you are doing now. > How one should integrate optional components with the Web UI? Yeah this is a gray area to me to. I would love to see a clear doc on this too. Petr, is this doable? > > 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. Absolutely. We just have not has a chance to invest into making it easier. Looks like it is 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 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 ?ber-objectclass that allows to associate >>> a lot of Asterisk attributes, but it is not clear why you need this >>> class and why you extend AsteriskExtension with it but then add >>> additional Ast attributes. >>> At a quick glance it seem to defeat the purpose of the objectclass >>> division done by the asterisk people. >>> Also 'Asterisk/Ast' is a prefix used by Digium, so it would be better >>> not to use that prefix for custom objects to avoid potential accidental >>> conflicts should they decide to add a class with that name, and in >>> general it is better to avoid confusion, using a different prefix makes >>> it clear that this is not an official digium object but a custom >>> extension. >>> Also you need an OID for this calss, do you have your own OID >>> numberspace from which to assign from ? >>> Otherwise we need to decide how to get you OIDs for your additional >>> schema. >>> >>> I see also that you created some attributes that use the ipa prefix for >>> their name. for these you will also need an OID, and we should probably >>> agree on a subprefix you can use and that we mark as assigned to your >>> plugin so we do not accidentally use a conflicting name for whatever >>> reason. >>> I see the actual prefix ends up being ipaAutoAst for the 2 attributes >>> you defined. Perhaps if would be better to use ipaAstAuto as a prefix >>> instead, and we mark the whole sub-namespace 'ipaAst' as a name space >>> that you use in your plugin. (So maybe you want to use >>> ipaAstSitesDefaults for your custom objectclass) >>> >>> To make things clearer I would suggest you to use 2 schema files; one >>> with the official digium objects and an additional one that depends on >>> it with the plugin custom objects. >>> >>> The basic DIT looks ok, but there isn't much detail on what you plan to >>> put in each sub container (sorry if this should be obvious to >>> Asterisk-versed people, I know the project only by name and never >>> configured an Asterisk server myself). >>> >>> >>> I see that there is a astAccountSecret attribute that seem to hold a >>> clear text password ? I assume it is desired that the SIP password is >>> actually *not* synchronized with the FreeIPA account password as it >>> usually is transmitted in the clear by a lot of devices/SIP phones ? >>> >>> Can regular computers be 'endpoint' devices ? (I am thinking softphones) >>> Or an endpoint is always a physical device ? >>> >>> As I said I am not really familiar with Asterisk configuration but all >>> the plugin CLI command looks quite reasonable. >>> What kind of UI do you have in mind for the Web part ? >>> Something inspired by our DNS plugin ? Or something different ? >>> >>> Lots of questions, but you are on a good start! >>> Have fun. >>> >>> Simo. >>> >> -- 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 Nov 2 13:40:36 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2012 09:40:36 -0400 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <5093CC42.3060003@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> <5093CC42.3060003@redhat.com> Message-ID: <5093CD54.6020902@redhat.com> Dmitri Pal wrote: > On 11/02/2012 12:25 AM, Loris Santamaria wrote: >> 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. > > IMO it can be eventually. It really depends on your goals. > >> 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. > > So you are potentially open to moving the project under the "IPA" > optional area that currently does not exists but can be created because > this project sets a precedent. > Let us work out the details when the code is functional. > >> >> You could set some guidelines for projects like this. > > Yes, but we do not have them yet, so it is a good opportunity to > identify what these guidelines should include and start putting together > a wiki page to provide a guidance. But this is so far uncharted > territory so please bear with us and any help in this area would be > appreciated. > I will try to put together a wiki page to cover what we already learned > from this thread. I also need to read more about Asterisk before I can > proceed. > >> 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? > > Yes and no. IMO we need to differentiate the components even optional > ones that are or will be developed within IPA project and are completely > external and independent components developed independently. We need > guidance for both but historically it is hard to plan in advance until > someone starts actual work. So may be the guideline should state "figure > out what the container name for the data you are going to add will be, > here are XYZ constraints to consider". > This is exactly what you are doing now. > >> How one should integrate optional components with the Web UI? > > > Yeah this is a gray area to me to. I would love to see a clear doc on > this too. > Petr, is this doable? We have this guide, which has a UI component: http://abbra.fedorapeople.org/guide.html rob From dpal at redhat.com Fri Nov 2 13:43:37 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 09:43:37 -0400 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <5093CD54.6020902@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> <5093CC42.3060003@redhat.com> <5093CD54.6020902@redhat.com> Message-ID: <5093CE09.7070004@redhat.com> On 11/02/2012 09:40 AM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 11/02/2012 12:25 AM, Loris Santamaria wrote: >>> 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. >> >> IMO it can be eventually. It really depends on your goals. >> >>> 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. >> >> So you are potentially open to moving the project under the "IPA" >> optional area that currently does not exists but can be created because >> this project sets a precedent. >> Let us work out the details when the code is functional. >> >>> >>> You could set some guidelines for projects like this. >> >> Yes, but we do not have them yet, so it is a good opportunity to >> identify what these guidelines should include and start putting together >> a wiki page to provide a guidance. But this is so far uncharted >> territory so please bear with us and any help in this area would be >> appreciated. >> I will try to put together a wiki page to cover what we already learned >> from this thread. I also need to read more about Asterisk before I can >> proceed. >> >>> 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? >> >> Yes and no. IMO we need to differentiate the components even optional >> ones that are or will be developed within IPA project and are completely >> external and independent components developed independently. We need >> guidance for both but historically it is hard to plan in advance until >> someone starts actual work. So may be the guideline should state "figure >> out what the container name for the data you are going to add will be, >> here are XYZ constraints to consider". >> This is exactly what you are doing now. >> >>> How one should integrate optional components with the Web UI? >> >> >> Yeah this is a gray area to me to. I would love to see a clear doc on >> this too. >> Petr, is this doable? > > We have this guide, which has a UI component: > http://abbra.fedorapeople.org/guide.html > > rob > I did not realize that it covers the UI. Last time I read it I do not remember see a UI section. So is it up to date and sufficient? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From james.hogarth at gmail.com Fri Nov 2 13:49:32 2012 From: james.hogarth at gmail.com (James Hogarth) Date: Fri, 2 Nov 2012 13:49:32 +0000 Subject: [Freeipa-devel] [PATCH] Allow TTL to be configured during ipa-client-install In-Reply-To: <5093C5F4.8020307@redhat.com> References: <5093C5F4.8020307@redhat.com> Message-ID: Hi Dimitri, > > Was there any specific ticket on the IPA side to connect this patch too? > Don't think so... I'll give a quick check to see if this exists there yet > If not can you please open such ticket in the freeipa trac instance? > https://fedorahosted.org/freeipa/ > It would help us to make sure the work you have done is not lost. > Not a problem - I'll take care of that this afternoon > > We are trying to be a bit more formal in tracking the new features so that > we know what they are and how to test them. We will put it on the wiki and > reference from the ticket. > Makes a lot of sense to me > > I hope you would find this request reasonable. > And thank you again for the interest and contribution to the IPA project. > We really appreciate it! > I consider this a pretty key project for growing linux based infrastructure when compared to a Windows one linked with AD thus much keen interest ;) Regards, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Nov 2 13:53:27 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Nov 2012 15:53:27 +0200 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <5093CE09.7070004@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> <5093CC42.3060003@redhat.com> <5093CD54.6020902@redhat.com> <5093CE09.7070004@redhat.com> Message-ID: <20121102135327.GT4353@redhat.com> On Fri, 02 Nov 2012, Dmitri Pal wrote: >>>> How one should integrate optional components with the Web UI? >>> >>> >>> Yeah this is a gray area to me to. I would love to see a clear doc on >>> this too. >>> Petr, is this doable? >> >> We have this guide, which has a UI component: >> http://abbra.fedorapeople.org/guide.html >> >> rob >> >I did not realize that it covers the UI. Last time I read it I do not >remember see a UI section. So is it up to date and sufficient? We do have hooks for extensions in Web UI already so it is possible to add external modules, albeight it is being directed to support sysadmins with local tuning rather than full blown modes. That local tuning gives you chance to load additionally any JS modules on the server. As we found recently with AD trusts, there is also an issue of refreshing running server configuration once a new feature is added -- since WSGI process does load IPA plugins only at startup. This is sort of maintenance machinery that needs to be done for all additional IPA plugins. -- / Alexander Bokovoy From mkosek at redhat.com Fri Nov 2 13:54:32 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Nov 2012 14:54:32 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <20121102115415.GL10066@localhost.localdomain> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> Message-ID: <5093D098.2060109@redhat.com> On 11/02/2012 12:54 PM, Sumit Bose wrote: > On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: >> On 10/30/2012 12:16 PM, Sumit Bose wrote: >>> Hi, >>> >>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name >>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . >>> >>> bye, >>> Sumit >>> >> >> >> Hello Sumit, >> >> I found few issues with your patch: > > Thank you for the review. > >> >> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not >> think this is necessary, ipa-adtrust-install already requires admin password to >> be passed and it already connects to LDAP with these credentials: >> >> api.Backend.ldap2.connect(ccache.name) >> >> You could use ipa.Backend.ldap2 object to do entry retrieval >> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. > > fixed > >> >> 2) When doing try..except statement, rule of thumb says that it should be as >> short as possible, so that it does not hide other potential errors and makes >> clear what function raises the catched exception. >> >> In your case: >> >> try: >> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), >> api.env.container_cifsdomains, >> self.api.env.basedn), >> ['ipantflatname']) >> except errors.NotFound: >> reset_netbios_name = False >> else: >> # process entry >> >> Should be a pattern that you want. > > fixed > > I also move all the NetBIOS name related code into a separate function. >> >> 3) I think this line is redundant: >> + print "Say 'yes' if the NetBIOS shall be changed and " \ >> + "'no' if the old one shall be kept." >> >> IMO, the question: >> >> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default >> = False, allow_empty = False) >> >> and the information printed before is enough. > > I would prefer to keep it this way to make clear that > ipa-adtrust-install will continue processing, but the old name if kept > even if a new name was given with --netbios-name on the command line. > > New version attached. > > bye, > Sumit > >> >> Martin The new approach looks much better. Sending issues I found with the new patch: 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS name interactively. I can only change it via script option... 2) I saw few typos: + print "Current NetBIOS domain name is %s new name is %s.\n" % \ should be: + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ + print "NetBIOS domain name will be changes to %s.\n" % \ should be: + print "NetBIOS domain name will be changed to %s.\n" % \ Martin From dpal at redhat.com Fri Nov 2 13:58:57 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 09:58:57 -0400 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <20121102135327.GT4353@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> <5093CC42.3060003@redhat.com> <5093CD54.6020902@redhat.com> <5093CE09.7070004@redhat.com> <20121102135327.GT4353@redhat.com> Message-ID: <5093D1A1.2000707@redhat.com> On 11/02/2012 09:53 AM, Alexander Bokovoy wrote: > On Fri, 02 Nov 2012, Dmitri Pal wrote: >>>>> How one should integrate optional components with the Web UI? >>>> >>>> >>>> Yeah this is a gray area to me to. I would love to see a clear doc on >>>> this too. >>>> Petr, is this doable? >>> >>> We have this guide, which has a UI component: >>> http://abbra.fedorapeople.org/guide.html >>> >>> rob >>> >> I did not realize that it covers the UI. Last time I read it I do not >> remember see a UI section. So is it up to date and sufficient? > We do have hooks for extensions in Web UI already so it is possible to > add external modules, albeight it is being directed to support sysadmins > with local tuning rather than full blown modes. That local tuning gives > you chance to load additionally any JS modules on the server. > > As we found recently with AD trusts, there is also an issue of > refreshing running server configuration once a new feature is added -- > since WSGI process does load IPA plugins only at startup. This is sort > of maintenance machinery that needs to be done for all additional IPA > plugins. > Yes. I already came up with a list of 17 items that need to go into the guidelines. Plugin deployment is one of 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 james.hogarth at gmail.com Fri Nov 2 14:04:37 2012 From: james.hogarth at gmail.com (James Hogarth) Date: Fri, 2 Nov 2012 14:04:37 +0000 Subject: [Freeipa-devel] [PATCH] Allow TTL to be configured during ipa-client-install In-Reply-To: References: <5093C5F4.8020307@redhat.com> Message-ID: , > > >> >> Was there any specific ticket on the IPA side to connect this patch too? >> > > Don't think so... I'll give a quick check to see if this exists there yet > > >> >> Apparently I had a mental blank about submitting this two months ago... The relevant ticket is https://fedorahosted.org/freeipa/ticket/3031 ... Regards, James -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Fri Nov 2 14:13:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2012 10:13:53 -0400 Subject: [Freeipa-devel] [PATCH] 88 Reword description of the --passsync option of ipa-replica-manage In-Reply-To: <5093AC65.6030401@redhat.com> References: <508E4A89.8020507@redhat.com> <508ED8F8.8030108@redhat.com> <5092BEAB.1000006@redhat.com> <5093AC65.6030401@redhat.com> Message-ID: <5093D521.9030000@redhat.com> Jan Cholasta wrote: > On 1.11.2012 19:25, Rob Crittenden wrote: >> Rob Crittenden wrote: >>> Jan Cholasta wrote: >>>> Hi, >>>> >>>> this patch fixes . >>> >>> 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 >> >> > > Thanks, added. Updated patch attached. > > Honza > Fixed a typo, s/tne/the and pushed to master and ipa-3-0 rob From pvoborni at redhat.com Fri Nov 2 14:15:34 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 02 Nov 2012 15:15:34 +0100 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <5093CC42.3060003@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> <5093CC42.3060003@redhat.com> Message-ID: <5093D586.3080107@redhat.com> On 11/02/2012 02:36 PM, Dmitri Pal wrote: > On 11/02/2012 12:25 AM, Loris Santamaria wrote: >> 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. > >> How one should integrate optional components with the Web UI? > > > Yeah this is a gray area to me to. I would love to see a clear doc on > this too. > Petr, is this doable? > >> >>>> >>>>> 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. >>>> Do you target existing releases (up to 3.0) or some next? In versions 2.2 and 3.0 not-touching existing Web UI sources might not be doable. You will have to put some code into ext/extension.js which is blank file, marked as configuration file and is loaded with the rest of Web UI. You will face two problems: 1) Load extension code. Currently Web UI has all links to JS sources hard coded in index.html. You can put all your code into extension.js or you have to put there a code which will dynamically load your JS file. 2) Register entity and update navigation You need to update navigation to display a link for the new pages. It's not straightforward without touching webui.js. I doubt that anybody done it before. I can help you with it if needed. IMO we should eliminate both issues to allow extending Web UI just by adding files to some directory. HTH -- Petr Vobornik From rcritten at redhat.com Fri Nov 2 14:20:14 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2012 10:20:14 -0400 Subject: [Freeipa-devel] [PATCH] 1070 change user_u context in list In-Reply-To: <1351784896.18469.115.camel@willson.li.ssimo.org> References: <5092887C.1040609@redhat.com> <1351784896.18469.115.camel@willson.li.ssimo.org> Message-ID: <5093D69E.1070407@redhat.com> Simo Sorce wrote: > 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. > pushed to master and ipa-3-0 From dpal at redhat.com Fri Nov 2 14:35:18 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 10:35:18 -0400 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <5093D586.3080107@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> <5093CC42.3060003@redhat.com> <5093D586.3080107@redhat.com> Message-ID: <5093DA26.70207@redhat.com> On 11/02/2012 10:15 AM, Petr Vobornik wrote: > On 11/02/2012 02:36 PM, Dmitri Pal wrote: >> On 11/02/2012 12:25 AM, Loris Santamaria wrote: >>> 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. >> >>> How one should integrate optional components with the Web UI? >> >> >> Yeah this is a gray area to me to. I would love to see a clear doc on >> this too. >> Petr, is this doable? >> >>> >>>>> >>>>>> 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. >>>>> > > Do you target existing releases (up to 3.0) or some next? > > In versions 2.2 and 3.0 not-touching existing Web UI sources might not > be doable. You will have to put some code into ext/extension.js which > is blank file, marked as configuration file and is loaded with the > rest of Web UI. I do not think it is worth targeting existing versions. > > You will face two problems: > > 1) Load extension code. > Currently Web UI has all links to JS sources hard coded in index.html. > You can put all your code into extension.js or you have to put there a > code which will dynamically load your JS file. > > 2) Register entity and update navigation > You need to update navigation to display a link for the new pages. > It's not straightforward without touching webui.js. I doubt that > anybody done it before. > > I can help you with it if needed. > > IMO we should eliminate both issues to allow extending Web UI just by > adding files to some directory. Please file a ticket. I would argue it will be the goal for the Pilsner release to address it. > > HTH -- 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 Fri Nov 2 14:39:39 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 10:39:39 -0400 Subject: [Freeipa-devel] [PATCH] Allow TTL to be configured during ipa-client-install In-Reply-To: References: <5093C5F4.8020307@redhat.com> Message-ID: <5093DB2B.9060202@redhat.com> On 11/02/2012 10:04 AM, James Hogarth wrote: > > > , > > > > > Was there any specific ticket on the IPA side to connect this > patch too? > > > Don't think so... I'll give a quick check to see if this exists > there yet > > > > > Apparently I had a mental blank about submitting this two months ago... > > The relevant ticket is https://fedorahosted.org/freeipa/ticket/3031 ... > > Regards, > > James > Thanks! -- 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 simo at redhat.com Fri Nov 2 14:56:17 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2012 10:56:17 -0400 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <5093C7C9.7090606@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> Message-ID: <1351868177.18469.172.camel@willson.li.ssimo.org> On Fri, 2012-11-02 at 09:16 -0400, Dmitri Pal wrote: > On 11/02/2012 07:22 AM, Petr Spacek wrote: > > On 11/02/2012 11:10 AM, Petr Viktorin wrote: > >> On 11/02/2012 10:46 AM, Martin Kosek wrote: > >>> On 11/01/2012 07:28 PM, Simo Sorce wrote: > >>>> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: > >>>>> Rob Crittenden wrote: > >>>>>> Simo Sorce wrote: > >>>>>>> From: Simo Sorce > >>>>>>> > >>>>>>> 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. > >>> > >>> While trying to follow this thread, I must throw my 2 conservative > >>> cents in. > >>> This thread is a very good example why processing our patches via > >>> patchwork is > >>> IMHO rather fuzzy and can cause more confusion than clarity. These > >>> are my main > >>> points: > >>> > >>> I cannot see which patches are the recent ones. Each patch is sent > >>> separately > >>> in mail body and I cannot quickly see by looking in thread which > >>> mail contains > >>> a revised patch and which is just a comment. > >>> > >>> When patches are attached directly to mail as files, I can quickly > >>> distinguish > >>> which mail has new patch set as it has "the paperclip icon". It also > >>> enabled us > >>> to attach a whole set of valid patches to one mail and thus make it > >>> easier for > >>> reviewer to pull a whole set of valid patches in one click. > >> > > >>> > >>> Patchwork style patch sending also generates a lot of mails which > >>> may confuse > >>> not only me but other contributors... > >> > >> +1 > >> > >> This particular thread is extremely confusing. Each individual patch > >> generated > >> its own subthread, and then the revised patches were sent as a reply the > >> original, spawning new threads to continue the old ones. The > >> discussion is > >> broken up and impossible to navigate. You can't see where the patches > >> are, let > >> alone where to look for latest versions. > >> Thanks to Rob for showing us that even a person following the thread > >> is easily > >> confused. > >> > >> Patchwork adds a view that is incomplete and not cross-linked. > >> To make a comment on a patch, you need to do it by e-mail; finding a > >> patch in > >> Patchwork is useless for this. Same for assigning a reviewer: you > >> need to find > >> it "manually" in Patchwork even if you have the mail in front of you. > >> > >> > >> I don't really see Patchwork's advantage. For a list of "active" > >> patches, we > >> have the "Patch submitted" bit in Trac; to claim a larger review we > >> could have > >> a policy to announce this on the list. And the claim that Patchwork > >> doesn't > >> change our current practices is simply false. > >> > > > > As guys described above, Patchwork influenced our process a lot and, > > personally, I don't like these changes. > > > > +1 from me to more rational Trac usage. We can simply set bit and/or > > reviewer name in Trac through API and avoid all changes introduced > > with Patchwork. > > > > Simple script and appropriate Trac query can do better work for us. > > > OK. It looks like it brings more disruption than benefit. > Simo, can we please get back to the original method at least for now? > At this stage of development it see a lot of disruption that we can't > afford. > Patch tracking problem exists - I do not deny it but it seems that the > change to patchwork does not bring the benefits you hoped. > I have an action item to explore what we can do with other tools we > considered like Gerrit. We might be not that far from it becoming an > option. I will follow up and let you know. Personally after a lot of consideration I really do not like the Gerrit option. It seem that patchwork is not working as is, I wonder if some work on it to allow it to be able to track multiple patches per email would be enough to keep using it while not disrupting the traditional way ? I have to be honest, I do like the change patchwork introduced, it makes it a lot easier to me to review patches inline and allows me to easily download them in a separate machine with a simple wget. Maybe there is a way to compromise on the rough edges and please everyone ? I do not like the trac approach because it is not automatic, so it is completely inconsistent, and also because trac is extremely slow. The patchwork webui is fast, I get results alsmot instantaneously, my experience with trac is that it take several seconds for the simplest views. Also trac cannot 'trac' patches that are not associated to a bug, so it will always be incomplete. The big win I see in patchwork is the automation, which is not in full force yet and can be improved. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Nov 2 15:05:54 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 02 Nov 2012 11:05:54 -0400 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <1351868177.18469.172.camel@willson.li.ssimo.org> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> <1351868177.18469.172.camel@willson.li.ssimo.org> Message-ID: <5093E152.2010606@redhat.com> On 11/02/2012 10:56 AM, Simo Sorce wrote: > On Fri, 2012-11-02 at 09:16 -0400, Dmitri Pal wrote: >> On 11/02/2012 07:22 AM, Petr Spacek wrote: >>> On 11/02/2012 11:10 AM, Petr Viktorin wrote: >>>> On 11/02/2012 10:46 AM, Martin Kosek wrote: >>>>> On 11/01/2012 07:28 PM, Simo Sorce wrote: >>>>>> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Simo Sorce wrote: >>>>>>>>> From: Simo Sorce >>>>>>>>> >>>>>>>>> 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. >>>>> While trying to follow this thread, I must throw my 2 conservative >>>>> cents in. >>>>> This thread is a very good example why processing our patches via >>>>> patchwork is >>>>> IMHO rather fuzzy and can cause more confusion than clarity. These >>>>> are my main >>>>> points: >>>>> >>>>> I cannot see which patches are the recent ones. Each patch is sent >>>>> separately >>>>> in mail body and I cannot quickly see by looking in thread which >>>>> mail contains >>>>> a revised patch and which is just a comment. >>>>> >>>>> When patches are attached directly to mail as files, I can quickly >>>>> distinguish >>>>> which mail has new patch set as it has "the paperclip icon". It also >>>>> enabled us >>>>> to attach a whole set of valid patches to one mail and thus make it >>>>> easier for >>>>> reviewer to pull a whole set of valid patches in one click. >>>> > >>>>> Patchwork style patch sending also generates a lot of mails which >>>>> may confuse >>>>> not only me but other contributors... >>>> +1 >>>> >>>> This particular thread is extremely confusing. Each individual patch >>>> generated >>>> its own subthread, and then the revised patches were sent as a reply the >>>> original, spawning new threads to continue the old ones. The >>>> discussion is >>>> broken up and impossible to navigate. You can't see where the patches >>>> are, let >>>> alone where to look for latest versions. >>>> Thanks to Rob for showing us that even a person following the thread >>>> is easily >>>> confused. >>>> >>>> Patchwork adds a view that is incomplete and not cross-linked. >>>> To make a comment on a patch, you need to do it by e-mail; finding a >>>> patch in >>>> Patchwork is useless for this. Same for assigning a reviewer: you >>>> need to find >>>> it "manually" in Patchwork even if you have the mail in front of you. >>>> >>>> >>>> I don't really see Patchwork's advantage. For a list of "active" >>>> patches, we >>>> have the "Patch submitted" bit in Trac; to claim a larger review we >>>> could have >>>> a policy to announce this on the list. And the claim that Patchwork >>>> doesn't >>>> change our current practices is simply false. >>>> >>> As guys described above, Patchwork influenced our process a lot and, >>> personally, I don't like these changes. >>> >>> +1 from me to more rational Trac usage. We can simply set bit and/or >>> reviewer name in Trac through API and avoid all changes introduced >>> with Patchwork. >>> >>> Simple script and appropriate Trac query can do better work for us. >>> >> OK. It looks like it brings more disruption than benefit. >> Simo, can we please get back to the original method at least for now? >> At this stage of development it see a lot of disruption that we can't >> afford. >> Patch tracking problem exists - I do not deny it but it seems that the >> change to patchwork does not bring the benefits you hoped. >> I have an action item to explore what we can do with other tools we >> considered like Gerrit. We might be not that far from it becoming an >> option. I will follow up and let you know. > Personally after a lot of consideration I really do not like the Gerrit > option. > > It seem that patchwork is not working as is, I wonder if some work on it > to allow it to be able to track multiple patches per email would be > enough to keep using it while not disrupting the traditional way ? I do not think we have cycles for this. > > I have to be honest, I do like the change patchwork introduced, it makes > it a lot easier to me to review patches inline and allows me to easily > download them in a separate machine with a simple wget. May be but there are many others for whom it does not. Let us step back for now and see what else can be done. May be we should clearly define the mail threading and patch re-posting rules first to avoid the confusion? > > Maybe there is a way to compromise on the rough edges and please > everyone ? > > I do not like the trac approach because it is not automatic, so it is > completely inconsistent, and also because trac is extremely slow. > The patchwork webui is fast, I get results alsmot instantaneously, my > experience with trac is that it take several seconds for the simplest > views. Also trac cannot 'trac' patches that are not associated to a bug, > so it will always be incomplete. I would argue that any patch set should be associated with the ticket. It can be a task but having patches without a ticket should not be a norm. > > The big win I see in patchwork is the automation, which is not in full > force yet and can be improved. > > Simo. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Fri Nov 2 15:16:57 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 02 Nov 2012 11:16:57 -0400 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <1351868177.18469.172.camel@willson.li.ssimo.org> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> <1351868177.18469.172.camel@willson.li.ssimo.org> Message-ID: <5093E3E9.4040603@redhat.com> On 11/02/2012 10:56 AM, Simo Sorce wrote: > I do not like the trac approach because it is not automatic, so it is > completely inconsistent, and also because trac is extremely slow. Factoring out the whole patchwork issue I do have to agree with Simo that using trac is painful because it's so slow. I've learned to live with it but it is annoying. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Fri Nov 2 15:27:26 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2012 11:27:26 -0400 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <5093E3E9.4040603@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> <1351868177.18469.172.camel@willson.li.ssimo.org> <5093E3E9.4040603@redhat.com> Message-ID: <1351870046.18469.179.camel@willson.li.ssimo.org> On Fri, 2012-11-02 at 11:16 -0400, John Dennis wrote: > On 11/02/2012 10:56 AM, Simo Sorce wrote: > > I do not like the trac approach because it is not automatic, so it is > > completely inconsistent, and also because trac is extremely slow. > > Factoring out the whole patchwork issue I do have to agree with Simo > that using trac is painful because it's so slow. I've learned to live > with it but it is annoying. I do use it when I have to update a ticket, but I would never use it to quickly glance at patches. Before patchwork I was doing it painfully (but at least fast enough) in the MUA. However doing it in the mail client is not easy because you have to manually weed off all the non-patch traffic. And you can only do so much to represent status. Simo. -- Simo Sorce * Red Hat, Inc * New York From jcholast at redhat.com Fri Nov 2 15:35:44 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Nov 2012 16:35:44 +0100 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <1351868177.18469.172.camel@willson.li.ssimo.org> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> <1351868177.18469.172.camel@willson.li.ssimo.org> Message-ID: <5093E850.4060406@redhat.com> On 2.11.2012 15:56, Simo Sorce wrote: > On Fri, 2012-11-02 at 09:16 -0400, Dmitri Pal wrote: >> On 11/02/2012 07:22 AM, Petr Spacek wrote: >>> On 11/02/2012 11:10 AM, Petr Viktorin wrote: >>>> On 11/02/2012 10:46 AM, Martin Kosek wrote: >>>>> On 11/01/2012 07:28 PM, Simo Sorce wrote: >>>>>> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: >>>>>>> Rob Crittenden wrote: >>>>>>>> Simo Sorce wrote: >>>>>>>>> From: Simo Sorce >>>>>>>>> >>>>>>>>> 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. >>>>> >>>>> While trying to follow this thread, I must throw my 2 conservative >>>>> cents in. >>>>> This thread is a very good example why processing our patches via >>>>> patchwork is >>>>> IMHO rather fuzzy and can cause more confusion than clarity. These >>>>> are my main >>>>> points: >>>>> >>>>> I cannot see which patches are the recent ones. Each patch is sent >>>>> separately >>>>> in mail body and I cannot quickly see by looking in thread which >>>>> mail contains >>>>> a revised patch and which is just a comment. >>>>> >>>>> When patches are attached directly to mail as files, I can quickly >>>>> distinguish >>>>> which mail has new patch set as it has "the paperclip icon". It also >>>>> enabled us >>>>> to attach a whole set of valid patches to one mail and thus make it >>>>> easier for >>>>> reviewer to pull a whole set of valid patches in one click. >>>> > >>>>> >>>>> Patchwork style patch sending also generates a lot of mails which >>>>> may confuse >>>>> not only me but other contributors... >>>> >>>> +1 >>>> >>>> This particular thread is extremely confusing. Each individual patch >>>> generated >>>> its own subthread, and then the revised patches were sent as a reply the >>>> original, spawning new threads to continue the old ones. The >>>> discussion is >>>> broken up and impossible to navigate. You can't see where the patches >>>> are, let >>>> alone where to look for latest versions. >>>> Thanks to Rob for showing us that even a person following the thread >>>> is easily >>>> confused. >>>> >>>> Patchwork adds a view that is incomplete and not cross-linked. >>>> To make a comment on a patch, you need to do it by e-mail; finding a >>>> patch in >>>> Patchwork is useless for this. Same for assigning a reviewer: you >>>> need to find >>>> it "manually" in Patchwork even if you have the mail in front of you. >>>> >>>> >>>> I don't really see Patchwork's advantage. For a list of "active" >>>> patches, we >>>> have the "Patch submitted" bit in Trac; to claim a larger review we >>>> could have >>>> a policy to announce this on the list. And the claim that Patchwork >>>> doesn't >>>> change our current practices is simply false. >>>> >>> >>> As guys described above, Patchwork influenced our process a lot and, >>> personally, I don't like these changes. >>> >>> +1 from me to more rational Trac usage. We can simply set bit and/or >>> reviewer name in Trac through API and avoid all changes introduced >>> with Patchwork. >>> >>> Simple script and appropriate Trac query can do better work for us. >>> >> OK. It looks like it brings more disruption than benefit. >> Simo, can we please get back to the original method at least for now? >> At this stage of development it see a lot of disruption that we can't >> afford. >> Patch tracking problem exists - I do not deny it but it seems that the >> change to patchwork does not bring the benefits you hoped. >> I have an action item to explore what we can do with other tools we >> considered like Gerrit. We might be not that far from it becoming an >> option. I will follow up and let you know. > > Personally after a lot of consideration I really do not like the Gerrit > option. > > It seem that patchwork is not working as is, I wonder if some work on it > to allow it to be able to track multiple patches per email would be > enough to keep using it while not disrupting the traditional way ? > > I have to be honest, I do like the change patchwork introduced, it makes > it a lot easier to me to review patches inline and allows me to easily > download them in a separate machine with a simple wget. > > Maybe there is a way to compromise on the rough edges and please > everyone ? > > I do not like the trac approach because it is not automatic, so it is > completely inconsistent, and also because trac is extremely slow. > The patchwork webui is fast, I get results alsmot instantaneously, my > experience with trac is that it take several seconds for the simplest > views. Also trac cannot 'trac' patches that are not associated to a bug, > so it will always be incomplete. In Trac's defense, it is actually fedorahosted that is slow. See how fast it is on other sites, e.g. or . > > The big win I see in patchwork is the automation, which is not in full > force yet and can be improved. > > Simo. > Honza -- Jan Cholasta From rcritten at redhat.com Fri Nov 2 15:35:16 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Nov 2012 11:35:16 -0400 Subject: [Freeipa-devel] [PATCH] 328 Process relative nameserver DNS record correctly In-Reply-To: <508946D1.7000603@redhat.com> References: <50894647.9030408@redhat.com> <508946D1.7000603@redhat.com> Message-ID: <5093E834.3040209@redhat.com> Martin Kosek wrote: > On 10/25/2012 04:01 PM, Martin Kosek wrote: >> Nameserver hostname passed to dnszone_add command was always treated >> as FQDN even though it was a relative DNS name to the new zone. All >> relative names were being rejected as unresolvable. >> >> Modify --name-server option processing in dnszone_add and dnszone_mod >> to respect FQDN/relative DNS name and do the checks accordingly. With >> this change, user can add a new zone "example.com" and let dnszone_add >> to create NS record "ns" in it, when supplied with its IP address. IP >> address check is more strict so that it is not entered when no forward >> record is created. Places misusing the option were fixed. >> >> Nameserver option now also accepts zone name, which means that NS and A >> record is placed to DNS zone itself. Also "@" is accepted as a nameserver >> name, BIND understand it also as a zone name. As a side-effect of this >> change, other records with hostname part (MX, KX, NS, SRV) accept "@" >> as valid hostname. BIND replaces it with respective zone name as well. >> >> Unit tests were updated to test the new format. >> >> https://fedorahosted.org/freeipa/ticket/3204 >> >> --- >> >> With this change, use cases like the following should now work as expected: >> >> # ipa dnszone-add example.com --name-server ns --ip-address 10.0.0.1 >> >> # ipa dnszone-add example.com --name-server ns.example.com. --ip-address 10.0.0.1 >> >> # ipa dnszone-add example.com --name-server ns.other.zone. --ip-address 10.0.0.1 >> >> # ipa dnszone-add example.com --name-server example.com. --ip-address 10.0.0.1 >> >> # ipa dnszone-add example.com --name-server @ --ip-address 10.0.0.1 >> >> Martin >> >> > > Forgot to squash NS check fix. Updated patch attached. Overall it looks good. The API needs to be updated. We had no formal string freeze but do we need to change doc strings now or can these be deferred (except may be the examples)? rob From mkosek at redhat.com Fri Nov 2 15:39:42 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Nov 2012 16:39:42 +0100 Subject: [Freeipa-devel] [PATCH] 0089 Clarify trust-add help regarding multiple runs against the same domain In-Reply-To: <20121102121940.GS4353@redhat.com> References: <20121010150502.GY17454@redhat.com> <20121017105211.GT23959@localhost.localdomain> <507E8F9F.4060606@redhat.com> <20121102121940.GS4353@redhat.com> Message-ID: <5093E93E.8070707@redhat.com> On 11/02/2012 01:19 PM, Alexander Bokovoy wrote: > On Wed, 17 Oct 2012, Martin Kosek wrote: >> On 10/17/2012 12:52 PM, Sumit Bose wrote: >>> On Wed, Oct 10, 2012 at 06:05:02PM +0300, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> this patch originated from off-list discussion regarding multiple runs >>>> of ipa trust-add against the same domain. >>>> >>>> Since trust-add re-establishes the trust every time it is run and all >>>> the other information fetched from the remote domain controller stays >>>> the same, it can be run multiple times. The only change would occur is >>>> update of trust relationship credentials -- they are supposed to be >>>> updated periodically by underlying infrastructure anyway. >>>> >>>> So the patch adds some clarity to the help and changes summary message >>>> when trust was re-established instead of created. >>>> -- >>>> / Alexander Bokovoy >>> >>> ACK >>> >>> Btw, another useful feature of allowing to run trust-add multiple times >>> is to re-established the trust if it was deleted only on one side, AD or >>> IPA. Having a separate command for this would make no sense because it >>> would be basically be an alias to trust-add. >>> >>> bye, >>> Sumit >>> >> >> I am still a bit worried about our consistency with IPA command help >> indentation. You have it indented with trust-add command: >> >> # ipa help trust-add >> Purpose: Add new trust to use. >> >> This command establishes trust relationship to another domain >> which becomes 'trusted'. As result, users of the trusted domain >> may access resources of this domain. >> ... > A fix is attached. > ACK. Pushed to master, ipa-3-0. Btw. I did not see any ticket linked to this patch. If there is any, please feel free to close it. Martin From pvoborni at redhat.com Fri Nov 2 15:42:34 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 02 Nov 2012 16:42:34 +0100 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <5093DA26.70207@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <1351783923.18469.108.camel@willson.li.ssimo.org> <5092A7A7.9070802@redhat.com> <1351830344.32488.84.camel@toron.pzo.lgs.com.ve> <5093CC42.3060003@redhat.com> <5093D586.3080107@redhat.com> <5093DA26.70207@redhat.com> Message-ID: <5093E9EA.60608@redhat.com> On 11/02/2012 03:35 PM, Dmitri Pal wrote: > On 11/02/2012 10:15 AM, Petr Vobornik wrote: >> On 11/02/2012 02:36 PM, Dmitri Pal wrote: >>> On 11/02/2012 12:25 AM, Loris Santamaria wrote: >>>> 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. >>> >>>> How one should integrate optional components with the Web UI? >>> >>> >>> Yeah this is a gray area to me to. I would love to see a clear doc on >>> this too. >>> Petr, is this doable? >>> >>>> >>>>>> >>>>>>> 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. >>>>>> >> >> Do you target existing releases (up to 3.0) or some next? >> >> In versions 2.2 and 3.0 not-touching existing Web UI sources might not >> be doable. You will have to put some code into ext/extension.js which >> is blank file, marked as configuration file and is loaded with the >> rest of Web UI. > > I do not think it is worth targeting existing versions. > >> >> You will face two problems: >> >> 1) Load extension code. >> Currently Web UI has all links to JS sources hard coded in index.html. >> You can put all your code into extension.js or you have to put there a >> code which will dynamically load your JS file. >> >> 2) Register entity and update navigation >> You need to update navigation to display a link for the new pages. >> It's not straightforward without touching webui.js. I doubt that >> anybody done it before. >> >> I can help you with it if needed. >> >> IMO we should eliminate both issues to allow extending Web UI just by >> adding files to some directory. > > Please file a ticket. I would argue it will be the goal for the Pilsner > release to address it. Tickets for both issues filed: https://fedorahosted.org/freeipa/ticket/3235 https://fedorahosted.org/freeipa/ticket/3236 -- Petr Vobornik From simo at redhat.com Fri Nov 2 15:45:50 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2012 11:45:50 -0400 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <5093E850.4060406@redhat.com> References: <50915E45.5000509@redhat.com> <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> <1351868177.18469.172.camel@willson.li.ssimo.org> <5093E850.4060406@redhat.com> Message-ID: <1351871150.18469.187.camel@willson.li.ssimo.org> On Fri, 2012-11-02 at 16:35 +0100, Jan Cholasta wrote: > On 2.11.2012 15:56, Simo Sorce wrote: > > On Fri, 2012-11-02 at 09:16 -0400, Dmitri Pal wrote: > >> On 11/02/2012 07:22 AM, Petr Spacek wrote: > >>> On 11/02/2012 11:10 AM, Petr Viktorin wrote: > >>>> On 11/02/2012 10:46 AM, Martin Kosek wrote: > >>>>> On 11/01/2012 07:28 PM, Simo Sorce wrote: > >>>>>> On Thu, 2012-11-01 at 10:59 -0400, Rob Crittenden wrote: > >>>>>>> Rob Crittenden wrote: > >>>>>>>> Simo Sorce wrote: > >>>>>>>>> From: Simo Sorce > >>>>>>>>> > >>>>>>>>> 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. > >>>>> > >>>>> While trying to follow this thread, I must throw my 2 conservative > >>>>> cents in. > >>>>> This thread is a very good example why processing our patches via > >>>>> patchwork is > >>>>> IMHO rather fuzzy and can cause more confusion than clarity. These > >>>>> are my main > >>>>> points: > >>>>> > >>>>> I cannot see which patches are the recent ones. Each patch is sent > >>>>> separately > >>>>> in mail body and I cannot quickly see by looking in thread which > >>>>> mail contains > >>>>> a revised patch and which is just a comment. > >>>>> > >>>>> When patches are attached directly to mail as files, I can quickly > >>>>> distinguish > >>>>> which mail has new patch set as it has "the paperclip icon". It also > >>>>> enabled us > >>>>> to attach a whole set of valid patches to one mail and thus make it > >>>>> easier for > >>>>> reviewer to pull a whole set of valid patches in one click. > >>>> > > >>>>> > >>>>> Patchwork style patch sending also generates a lot of mails which > >>>>> may confuse > >>>>> not only me but other contributors... > >>>> > >>>> +1 > >>>> > >>>> This particular thread is extremely confusing. Each individual patch > >>>> generated > >>>> its own subthread, and then the revised patches were sent as a reply the > >>>> original, spawning new threads to continue the old ones. The > >>>> discussion is > >>>> broken up and impossible to navigate. You can't see where the patches > >>>> are, let > >>>> alone where to look for latest versions. > >>>> Thanks to Rob for showing us that even a person following the thread > >>>> is easily > >>>> confused. > >>>> > >>>> Patchwork adds a view that is incomplete and not cross-linked. > >>>> To make a comment on a patch, you need to do it by e-mail; finding a > >>>> patch in > >>>> Patchwork is useless for this. Same for assigning a reviewer: you > >>>> need to find > >>>> it "manually" in Patchwork even if you have the mail in front of you. > >>>> > >>>> > >>>> I don't really see Patchwork's advantage. For a list of "active" > >>>> patches, we > >>>> have the "Patch submitted" bit in Trac; to claim a larger review we > >>>> could have > >>>> a policy to announce this on the list. And the claim that Patchwork > >>>> doesn't > >>>> change our current practices is simply false. > >>>> > >>> > >>> As guys described above, Patchwork influenced our process a lot and, > >>> personally, I don't like these changes. > >>> > >>> +1 from me to more rational Trac usage. We can simply set bit and/or > >>> reviewer name in Trac through API and avoid all changes introduced > >>> with Patchwork. > >>> > >>> Simple script and appropriate Trac query can do better work for us. > >>> > >> OK. It looks like it brings more disruption than benefit. > >> Simo, can we please get back to the original method at least for now? > >> At this stage of development it see a lot of disruption that we can't > >> afford. > >> Patch tracking problem exists - I do not deny it but it seems that the > >> change to patchwork does not bring the benefits you hoped. > >> I have an action item to explore what we can do with other tools we > >> considered like Gerrit. We might be not that far from it becoming an > >> option. I will follow up and let you know. > > > > Personally after a lot of consideration I really do not like the Gerrit > > option. > > > > It seem that patchwork is not working as is, I wonder if some work on it > > to allow it to be able to track multiple patches per email would be > > enough to keep using it while not disrupting the traditional way ? > > > > I have to be honest, I do like the change patchwork introduced, it makes > > it a lot easier to me to review patches inline and allows me to easily > > download them in a separate machine with a simple wget. > > > > Maybe there is a way to compromise on the rough edges and please > > everyone ? > > > > I do not like the trac approach because it is not automatic, so it is > > completely inconsistent, and also because trac is extremely slow. > > The patchwork webui is fast, I get results alsmot instantaneously, my > > experience with trac is that it take several seconds for the simplest > > views. Also trac cannot 'trac' patches that are not associated to a bug, > > so it will always be incomplete. > > In Trac's defense, it is actually fedorahosted that is slow. See how > fast it is on other sites, e.g. or > . Yep but slowness is just one little annoyance, it's the fact it can't be automatic that it is annoying, how would trac know how to associate a patch to a ticket even assuming a ticket is available ? How does it shows multiple patches ? Would it have to unpack them from mail and ad them as attachments to the ticket ? To me they seem complementary tools, I would rather work some integration with trac and improve the way patchwork handles multiple patches in a mail. I will see if it is possible to easily change the parsing code in patchwork to 'duplicate' mails when multiple patches are found. That would allow us to send bundles of patches in the same email as before. Also replying on the threading issue to Martin I think that is laregely my fault because we were experimenting. I used the --no-cchain-reply-to option initially but that is wrong, because then all patches are replies to the same mail and things do get confusing. However if you use the --chain-reply-to option then each patch is in reply to the previous one in the patchset. So if you send a whole patchset in replay to the previous [0/x] message then you can clearly see series in threads because each series will be a chain of replies to the same cover letter. That should make things a lot less confusing. It will not resolve the 'paper clip' issue BUT, if you use git-send-email you have another simple indicator and taht is that the subject is [Patch X/N] for all patches So when you see that subject you know it is a patch, if you see 'RE: [Patch...' then you know it is just a reply. Does this help ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Nov 2 16:16:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Nov 2012 17:16:47 +0100 Subject: [Freeipa-devel] [PATCH] 328 Process relative nameserver DNS record correctly In-Reply-To: <5093E834.3040209@redhat.com> References: <50894647.9030408@redhat.com> <508946D1.7000603@redhat.com> <5093E834.3040209@redhat.com> Message-ID: <5093F1EF.2070701@redhat.com> On 11/02/2012 04:35 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/25/2012 04:01 PM, Martin Kosek wrote: >>> Nameserver hostname passed to dnszone_add command was always treated >>> as FQDN even though it was a relative DNS name to the new zone. All >>> relative names were being rejected as unresolvable. >>> >>> Modify --name-server option processing in dnszone_add and dnszone_mod >>> to respect FQDN/relative DNS name and do the checks accordingly. With >>> this change, user can add a new zone "example.com" and let dnszone_add >>> to create NS record "ns" in it, when supplied with its IP address. IP >>> address check is more strict so that it is not entered when no forward >>> record is created. Places misusing the option were fixed. >>> >>> Nameserver option now also accepts zone name, which means that NS and A >>> record is placed to DNS zone itself. Also "@" is accepted as a nameserver >>> name, BIND understand it also as a zone name. As a side-effect of this >>> change, other records with hostname part (MX, KX, NS, SRV) accept "@" >>> as valid hostname. BIND replaces it with respective zone name as well. >>> >>> Unit tests were updated to test the new format. >>> >>> https://fedorahosted.org/freeipa/ticket/3204 >>> >>> --- >>> >>> With this change, use cases like the following should now work as expected: >>> >>> # ipa dnszone-add example.com --name-server ns --ip-address 10.0.0.1 >>> >>> # ipa dnszone-add example.com --name-server ns.example.com. --ip-address >>> 10.0.0.1 >>> >>> # ipa dnszone-add example.com --name-server ns.other.zone. --ip-address >>> 10.0.0.1 >>> >>> # ipa dnszone-add example.com --name-server example.com. --ip-address 10.0.0.1 >>> >>> # ipa dnszone-add example.com --name-server @ --ip-address 10.0.0.1 >>> >>> Martin >>> >>> >> >> Forgot to squash NS check fix. Updated patch attached. > > Overall it looks good. > > The API needs to be updated. > > We had no formal string freeze but do we need to change doc strings now or can > these be deferred (except may be the examples)? > > > rob API updated. Relaxed check for root zone that Petr Spacek pointed out was removed. As for the string changes... I think that the only optional change is this one: @@ -1726,10 +1764,10 @@ class dnszone_add(LDAPCreate): takes_options = LDAPCreate.takes_options + ( Flag('force', label=_('Force'), - doc=_('Force DNS zone creation even if nameserver not in DNS.'), + doc=_('Force DNS zone creation even if nameserver is not resolvable.'), ), Str('ip_address?', _validate_ipaddr, - doc=_('Add the nameserver to DNS with this IP address'), + doc=_('Add forward record for nameserver located in the created zone'), ), ) Other changes are needed to make our processing of domain name clear, like - error=unicode(_("Nameserver address is not a fully qualified domain name"))) + error=_("Nameserver address is not a domain name")) Updated patch attached. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-328-3-process-relative-nameserver-dns-record-correctly.patch Type: text/x-patch Size: 21814 bytes Desc: not available URL: From abokovoy at redhat.com Fri Nov 2 17:24:19 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Nov 2012 19:24:19 +0200 Subject: [Freeipa-devel] [PATCH] 0089 Clarify trust-add help regarding multiple runs against the same domain In-Reply-To: <5093E93E.8070707@redhat.com> References: <20121010150502.GY17454@redhat.com> <20121017105211.GT23959@localhost.localdomain> <507E8F9F.4060606@redhat.com> <20121102121940.GS4353@redhat.com> <5093E93E.8070707@redhat.com> Message-ID: <20121102172419.GV4353@redhat.com> On Fri, 02 Nov 2012, Martin Kosek wrote: >On 11/02/2012 01:19 PM, Alexander Bokovoy wrote: >> On Wed, 17 Oct 2012, Martin Kosek wrote: >>> On 10/17/2012 12:52 PM, Sumit Bose wrote: >>>> On Wed, Oct 10, 2012 at 06:05:02PM +0300, Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> this patch originated from off-list discussion regarding multiple runs >>>>> of ipa trust-add against the same domain. >>>>> >>>>> Since trust-add re-establishes the trust every time it is run and all >>>>> the other information fetched from the remote domain controller stays >>>>> the same, it can be run multiple times. The only change would occur is >>>>> update of trust relationship credentials -- they are supposed to be >>>>> updated periodically by underlying infrastructure anyway. >>>>> >>>>> So the patch adds some clarity to the help and changes summary message >>>>> when trust was re-established instead of created. >>>>> -- >>>>> / Alexander Bokovoy >>>> >>>> ACK >>>> >>>> Btw, another useful feature of allowing to run trust-add multiple times >>>> is to re-established the trust if it was deleted only on one side, AD or >>>> IPA. Having a separate command for this would make no sense because it >>>> would be basically be an alias to trust-add. >>>> >>>> bye, >>>> Sumit >>>> >>> >>> I am still a bit worried about our consistency with IPA command help >>> indentation. You have it indented with trust-add command: >>> >>> # ipa help trust-add >>> Purpose: Add new trust to use. >>> >>> This command establishes trust relationship to another domain >>> which becomes 'trusted'. As result, users of the trusted domain >>> may access resources of this domain. >>> ... >> A fix is attached. >> > >ACK. Pushed to master, ipa-3-0. > >Btw. I did not see any ticket linked to this patch. If there is any, please >feel free to close it. Thanks! It was https://fedorahosted.org/freeipa/ticket/3172. -- / Alexander Bokovoy From pspacek at redhat.com Fri Nov 2 17:45:21 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 02 Nov 2012 18:45:21 +0100 Subject: [Freeipa-devel] [PATCH 0086] Respect global forwarders from named.conf if they are not overridden by LDAP configuration Message-ID: <509406B1.2080400@redhat.com> Hello, Respect global forwarders from named.conf if they are not overridden by LDAP configuration. Original configuration from named.conf is saved on load. Original configuration will be restored if configuration in LDAP is not present or is invalid. Another patch for cache flushing will follow. -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 2 17:52:52 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 02 Nov 2012 18:52:52 +0100 Subject: [Freeipa-devel] [PATCH 0086] Respect global forwarders from named.conf if they are not overridden by LDAP configuration In-Reply-To: <509406B1.2080400@redhat.com> References: <509406B1.2080400@redhat.com> Message-ID: <50940874.8080107@redhat.com> On 11/02/2012 06:45 PM, Petr Spacek wrote: > Hello, > > Respect global forwarders from named.conf if they are not overridden by LDAP > configuration. > > Original configuration from named.conf is saved on load. > Original configuration will be restored if configuration in LDAP is not > present or is invalid. > > > Another patch for cache flushing will follow. Well, another Friday - another forgotten patch. -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 2 18:02:29 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 02 Nov 2012 19:02:29 +0100 Subject: [Freeipa-devel] [PATCH 0086] Respect global forwarders from named.conf if they are not overridden by LDAP configuration In-Reply-To: <50940874.8080107@redhat.com> References: <509406B1.2080400@redhat.com> <50940874.8080107@redhat.com> Message-ID: <50940AB5.4010703@redhat.com> On 11/02/2012 06:52 PM, Petr Spacek wrote: > On 11/02/2012 06:45 PM, Petr Spacek wrote: >> Hello, >> >> Respect global forwarders from named.conf if they are not overridden by LDAP >> configuration. >> >> Original configuration from named.conf is saved on load. >> Original configuration will be restored if configuration in LDAP is not >> present or is invalid. >> >> >> Another patch for cache flushing will follow. > > Well, another Friday - another forgotten patch. > For my mail client: The patch is *attached*. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0086-2-Respect-global-forwarders-from-named.conf-if-they-ar.patch Type: text/x-patch Size: 12766 bytes Desc: not available URL: From jhrozek at redhat.com Fri Nov 2 18:02:54 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 2 Nov 2012 19:02:54 +0100 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <5093E152.2010606@redhat.com> References: <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> <1351868177.18469.172.camel@willson.li.ssimo.org> <5093E152.2010606@redhat.com> Message-ID: <20121102180254.GG4057@hendrix.redhat.com> On Fri, Nov 02, 2012 at 11:05:54AM -0400, Dmitri Pal wrote: > > I have to be honest, I do like the change patchwork introduced, it makes > > it a lot easier to me to review patches inline and allows me to easily > > download them in a separate machine with a simple wget. > > May be but there are many others for whom it does not. Let us step back > for now and see what else can be done. One thing I'd like to add is that I think we should postpone introducing process changes when we are done stabilizing the upcoming releases. I can hardly find the time to change my workflow right now when we're trying to fix all the SSSD 1.9.x bugs. Yesterday I learned that two things I thought did not work with patchwork (git am on maildir and assigning "admin" rights) were in fact misunderstandings on my part and lack of documentation respectively. But I would prefer to learn a new process when we're out from the bugfix crunch part. From simo at redhat.com Fri Nov 2 18:39:22 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Nov 2012 14:39:22 -0400 Subject: [Freeipa-devel] [RANT] Patchwork process In-Reply-To: <20121102180254.GG4057@hendrix.redhat.com> References: <1351707041-16593-1-git-send-email-simo@redhat.com> <50918E22.5050602@redhat.com> <50928E54.8070506@redhat.com> <1351794492.18469.122.camel@willson.li.ssimo.org> <5093965A.1020603@redhat.com> <50939C2A.4080304@redhat.com> <5093AD00.5000907@redhat.com> <5093C7C9.7090606@redhat.com> <1351868177.18469.172.camel@willson.li.ssimo.org> <5093E152.2010606@redhat.com> <20121102180254.GG4057@hendrix.redhat.com> Message-ID: <1351881562.18469.223.camel@willson.li.ssimo.org> On Fri, 2012-11-02 at 19:02 +0100, Jakub Hrozek wrote: > On Fri, Nov 02, 2012 at 11:05:54AM -0400, Dmitri Pal wrote: > > > I have to be honest, I do like the change patchwork introduced, it makes > > > it a lot easier to me to review patches inline and allows me to easily > > > download them in a separate machine with a simple wget. > > > > May be but there are many others for whom it does not. Let us step back > > for now and see what else can be done. > > One thing I'd like to add is that I think we should postpone introducing > process changes when we are done stabilizing the upcoming releases. I > can hardly find the time to change my workflow right now when we're > trying to fix all the SSSD 1.9.x bugs. > > Yesterday I learned that two things I thought did not work with > patchwork (git am on maildir and assigning "admin" rights) were in fact > misunderstandings on my part and lack of documentation respectively. But > I would prefer to learn a new process when we're out from the bugfix > crunch part. This is ok, I hoped the process would be less disruptive, but it appears no the case, please ignore patchwork for now if it disrupts your work. I'll keep it up to date and will see if I can make it grok also the current way the freeipa-devel list works (ie handling multiple patches per mail message). I will give a heads up later once we are less loaded to try to reintroduce it. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Fri Nov 2 20:50:00 2012 From: sbose at redhat.com (Sumit Bose) Date: Fri, 2 Nov 2012 21:50:00 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <5093D098.2060109@redhat.com> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> Message-ID: <20121102205000.GM10066@localhost.localdomain> On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: > On 11/02/2012 12:54 PM, Sumit Bose wrote: > > On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: > >> On 10/30/2012 12:16 PM, Sumit Bose wrote: > >>> Hi, > >>> > >>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name > >>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . > >>> > >>> bye, > >>> Sumit > >>> > >> > >> > >> Hello Sumit, > >> > >> I found few issues with your patch: > > > > Thank you for the review. > > > >> > >> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not > >> think this is necessary, ipa-adtrust-install already requires admin password to > >> be passed and it already connects to LDAP with these credentials: > >> > >> api.Backend.ldap2.connect(ccache.name) > >> > >> You could use ipa.Backend.ldap2 object to do entry retrieval > >> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. > > > > fixed > > > >> > >> 2) When doing try..except statement, rule of thumb says that it should be as > >> short as possible, so that it does not hide other potential errors and makes > >> clear what function raises the catched exception. > >> > >> In your case: > >> > >> try: > >> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), > >> api.env.container_cifsdomains, > >> self.api.env.basedn), > >> ['ipantflatname']) > >> except errors.NotFound: > >> reset_netbios_name = False > >> else: > >> # process entry > >> > >> Should be a pattern that you want. > > > > fixed > > > > I also move all the NetBIOS name related code into a separate function. > >> > >> 3) I think this line is redundant: > >> + print "Say 'yes' if the NetBIOS shall be changed and " \ > >> + "'no' if the old one shall be kept." > >> > >> IMO, the question: > >> > >> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default > >> = False, allow_empty = False) > >> > >> and the information printed before is enough. > > > > I would prefer to keep it this way to make clear that > > ipa-adtrust-install will continue processing, but the old name if kept > > even if a new name was given with --netbios-name on the command line. > > > > New version attached. > > > > bye, > > Sumit > > > >> > >> Martin > > > The new approach looks much better. Sending issues I found with the new patch: > > 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS > name interactively. I can only change it via script option... > fixed > > 2) I saw few typos: > > + print "Current NetBIOS domain name is %s new name is %s.\n" % \ > should be: > + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ > > + print "NetBIOS domain name will be changes to %s.\n" % \ > should be: > + print "NetBIOS domain name will be changed to %s.\n" % \ > > fixed new version attached. bye, Sumit > Martin -------------- next part -------------- From 4925b1871fef526ab8c1932a7541951f9980c055 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 29 Oct 2012 21:43:56 +0100 Subject: [PATCH] ipa-adtrust-install: allow to reset te NetBIOS domain name Fixes https://fedorahosted.org/freeipa/ticket/3192 --- install/tools/ipa-adtrust-install | 109 ++++++++++++++++++++++++++------ install/tools/man/ipa-adtrust-install.1 | 6 +- ipaserver/install/adtrustinstance.py | 24 ++++++- 3 Dateien ge?ndert, 117 Zeilen hinzugef?gt(+), 22 Zeilen entfernt(-) diff --git a/install/tools/ipa-adtrust-install b/install/tools/ipa-adtrust-install index 52179038e84a08ea6abb3ee26d8e668efe0a2b13..83c6b8f4f843e6e389a28b9b4527f89a5e7a118d 100755 --- a/install/tools/ipa-adtrust-install +++ b/install/tools/ipa-adtrust-install @@ -71,7 +71,7 @@ def parse_options(): return safe_options, options def netbios_name_error(name): - print "Illegal NetBIOS name [%s].\n" % name + print "\nIllegal NetBIOS name [%s].\n" % name print "Up to 15 characters and only uppercase ASCII letter and digits are allowed." def read_netbios_name(netbios_default): @@ -101,6 +101,90 @@ def read_admin_password(admin_name): admin_password = read_password(admin_name, confirm=False, validate=None) return admin_password +def set_and_check_netbios_name(netbios_name, unattended): + """ + Depending if trust in already configured or not a given NetBIOS domain + name must be handled differently. + + If trust is not configured the given NetBIOS is used or the NetBIOS is + generated if none was given on the command line. + + If trust is already configured the given NetBIOS name is used to reset + the stored NetBIOS name it it differs from the current one. + """ + + flat_name_attr = 'ipantflatname' + cur_netbios_name = None + gen_netbios_name = None + reset_netbios_name = False + dom_dn = None + + try: + (dom_dn, entry) = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), + api.env.container_cifsdomains, + ipautil.realm_to_suffix(api.env.realm)), + [flat_name_attr]) + except errors.NotFound: + # trust not configured + pass + else: + cur_netbios_name = entry.get(flat_name_attr)[0] + + if cur_netbios_name and not netbios_name: + # keep the current NetBIOS name + netbios_name = cur_netbios_name + reset_netbios_name = False + elif cur_netbios_name and cur_netbios_name != netbios_name: + # change the NetBIOS name + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ + (cur_netbios_name, netbios_name) + print "Please note that changing the NetBIOS name might " \ + "break existing trust relationships." + if unattended: + reset_netbios_name = True + print "NetBIOS domain name will be changed to %s.\n" % \ + netbios_name + else: + print "Say 'yes' if the NetBIOS shall be changed and " \ + "'no' if the old one shall be kept." + reset_netbios_name = ipautil.user_input( + 'Do you want to reset the NetBIOS domain name?', + default = False, allow_empty = False) + if not reset_netbios_name: + netbios_name = cur_netbios_name + elif cur_netbios_name and cur_netbios_name == netbios_name: + # keep the current NetBIOS name + reset_netbios_name = False + elif not cur_netbios_name: + if not netbios_name: + gen_netbios_name = adtrustinstance.make_netbios_name(api.env.domain) + + if dom_dn: + # Fix existing trust configuration + print "Trust is configured but no NetBIOS domain name found, " \ + "setting it now." + reset_netbios_name = True + else: + # initial trust configuration + reset_netbios_name = False + else: + # all possible cases should be covered above + raise Exception('Unexpected state while checking NetBIOS domain name') + + if not adtrustinstance.check_netbios_name(netbios_name): + if unattended: + netbios_name_error(netbios_name) + sys.exit("Aborting installation.") + else: + if netbios_name: + netbios_name_error(netbios_name) + netbios_name = None + + if not unattended and not netbios_name: + netbios_name = read_netbios_name(gen_netbios_name) + + return (netbios_name, reset_netbios_name) + def ensure_admin_kinit(admin_name, admin_password): try: ipautil.run(['kinit', admin_name], stdin=admin_password+'\n') @@ -197,22 +281,6 @@ def main(): print "Please wait until the prompt is returned." print "" - netbios_name = options.netbios_name - if not netbios_name: - netbios_name = adtrustinstance.make_netbios_name(api.env.domain) - - if not adtrustinstance.check_netbios_name(netbios_name): - if options.unattended: - netbios_name_error(netbios_name) - sys.exit("Aborting installation.") - else: - netbios_name = None - if options.netbios_name: - netbios_name_error(options.netbios_name) - - if not options.unattended and ( not netbios_name or not options.netbios_name): - netbios_name = read_netbios_name(netbios_name) - admin_password = options.admin_password if not (options.unattended or admin_password): admin_password = read_admin_password(options.admin_name) @@ -248,11 +316,16 @@ def main(): except Exception, e: sys.exit("Unrecognized error during check of admin rights: %s" % (str(e))) + (netbios_name, reset_netbios_name) = \ + set_and_check_netbios_name(options.netbios_name, + options.unattended) + smb = adtrustinstance.ADTRUSTInstance(fstore) smb.realm = api.env.realm smb.autobind = service.ENABLED smb.setup(api.env.host, ip_address, api.env.realm, api.env.domain, - netbios_name, options.rid_base, options.secondary_rid_base, + netbios_name, reset_netbios_name, + options.rid_base, options.secondary_rid_base, options.no_msdcs, options.add_sids) smb.find_local_id_range() smb.create_instance() diff --git a/install/tools/man/ipa-adtrust-install.1 b/install/tools/man/ipa-adtrust-install.1 index 9204b7d5fde7493a4c268eb71693e86a63a1b4b7..38957f3a486ec4d3108e7ccdc955880dc65a3873 100644 --- a/install/tools/man/ipa-adtrust-install.1 +++ b/install/tools/man/ipa-adtrust-install.1 @@ -42,7 +42,11 @@ Enable debug logging when more verbose output is needed The IP address of the IPA server. If not provided then this is determined based on the hostname of the server. .TP \fB\-\-netbios\-name\fR=\fINETBIOS_NAME\fR -The NetBIOS name for the IPA domain. If not provided then this is determined based on the leading component of the DNS domain name. +The NetBIOS name for the IPA domain. If not provided then this is determined +based on the leading component of the DNS domain name. Running +ipa\-adtrust\-install for a second time with a different NetBIOS name will +change the name. Please note that changing the NetBIOS name might break +existing trust relationships to other domains. .TP \fB\-\-no\-msdcs\fR Do not create DNS service records for Windows in managed DNS server. Since those diff --git a/ipaserver/install/adtrustinstance.py b/ipaserver/install/adtrustinstance.py index c27fac99cf624ca6460ce84e76be52db38f11a5b..16f2136a6485e6915fd5de2000e6a378d03b44aa 100644 --- a/ipaserver/install/adtrustinstance.py +++ b/ipaserver/install/adtrustinstance.py @@ -115,6 +115,7 @@ class ADTRUSTInstance(service.Service): self.realm = None self.domain_name = None self.netbios_name = None + self.reset_netbios_name = None self.no_msdcs = None self.add_sids = None self.smbd_user = None @@ -295,11 +296,27 @@ class ADTRUSTInstance(service.Service): "define it and run again.") raise e + def __reset_netbios_name(self): + """ + Set the NetBIOS domain name to a new value. + """ + self.print_msg("Reset NetBIOS domain name") + + try: + self.admin_conn.modify_s(self.smb_dom_dn, + [(ldap.MOD_REPLACE, self.ATTR_FLAT_NAME, + self.netbios_name)]) + except ldap.LDAPError: + self.print_msg("Failed to reset the NetBIOS domain name") + def __create_samba_domain_object(self): try: self.admin_conn.getEntry(self.smb_dom_dn, ldap.SCOPE_BASE) - root_logger.info("Samba domain object already exists") + if self.reset_netbios_name: + self.__reset_netbios_name() + else : + self.print_msg("Samba domain object already exists") return except errors.NotFound: pass @@ -653,13 +670,14 @@ class ADTRUSTInstance(service.Service): FQDN = self.fqdn) def setup(self, fqdn, ip_address, realm_name, domain_name, netbios_name, - rid_base, secondary_rid_base, no_msdcs=False, add_sids=False, - smbd_user="samba"): + reset_netbios_name, rid_base, secondary_rid_base, + no_msdcs=False, add_sids=False, smbd_user="samba"): self.fqdn = fqdn self.ip_address = ip_address self.realm = realm_name self.domain_name = domain_name self.netbios_name = netbios_name + self.reset_netbios_name = reset_netbios_name self.rid_base = rid_base self.secondary_rid_base = secondary_rid_base self.no_msdcs = no_msdcs -- 1.7.11.4 From lroot at redhat.com Mon Nov 5 08:43:32 2012 From: lroot at redhat.com (Lynn Root) Date: Mon, 5 Nov 2012 03:43:32 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <508F8B01.1090609@redhat.com> Message-ID: <625702657.4651970.1352105012674.JavaMail.root@redhat.com> Here's try #2! Adjusted patch attached. Let me know if there's anything else I've missed. Switched %r specifiers to '%s' in Public errors, and adjusted tests to expect no preceding 'u'. Tickets: https://fedorahosted.org/freeipa/ticket/3121 & https://fedorahosted.org/freeipa/ticket/2588 Lynn Root Associate Software Engineer Red Hat ----- Original Message ----- From: "Martin Kosek" To: "Jan Cholasta" Cc: "Lynn Root" , freeipa-devel at redhat.com Sent: Tuesday, October 30, 2012 9:08:33 AM Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors On 10/30/2012 09:04 AM, Jan Cholasta wrote: > Hi, > > On 29.10.2012 19:54, Lynn Root wrote: >> Hi all! >> >> This switch drops the preceding 'u' from strings in public error messages. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >> >> This patch also addresses the unfriendly 'u' from re-raising errors from the >> external call to netaddr.IPAddress by passing a bytestring to the function. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >> >> >> My first patch (and freeipa dev list email) ever! Let me know where there's >> room to improve. >> >> Lynn Root >> Associate Software Engineer >> Red Hat >> > > I think it would be nice if you kept the quotes around the values, as that is > probably the reason "%r" was used in the first place - i.e. use "'%s'" instead > of plain "%s". +1 With current patch, I assume that a lot of unit tests will fail as they check exact error message wording. I'd recommend running the whole test suite with your second patch revision. There is a short walkthrough how to set it up: http://freeipa.org/page/Testing Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Switch-r-specifiers-to-s-in-Public-errors-for-user-f.patch Type: text/x-patch Size: 15460 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 5 09:25:32 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 05 Nov 2012 10:25:32 +0100 Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <625702657.4651970.1352105012674.JavaMail.root@redhat.com> References: <625702657.4651970.1352105012674.JavaMail.root@redhat.com> Message-ID: <5097860C.9050109@redhat.com> On 5.11.2012 09:43, Lynn Root wrote: > Here's try #2! Adjusted patch attached. Let me know if there's anything else I've missed. > > Switched %r specifiers to '%s' in Public errors, and adjusted tests to expect no preceding 'u'. > > Tickets: https://fedorahosted.org/freeipa/ticket/3121 & https://fedorahosted.org/freeipa/ticket/2588 > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Martin Kosek" > To: "Jan Cholasta" > Cc: "Lynn Root" , freeipa-devel at redhat.com > Sent: Tuesday, October 30, 2012 9:08:33 AM > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors > > On 10/30/2012 09:04 AM, Jan Cholasta wrote: >> Hi, >> >> On 29.10.2012 19:54, Lynn Root wrote: >>> Hi all! >>> >>> This switch drops the preceding 'u' from strings in public error messages. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>> >>> This patch also addresses the unfriendly 'u' from re-raising errors from the >>> external call to netaddr.IPAddress by passing a bytestring to the function. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>> >>> >>> My first patch (and freeipa dev list email) ever! Let me know where there's >>> room to improve. >>> >>> Lynn Root >>> Associate Software Engineer >>> Red Hat >>> >> >> I think it would be nice if you kept the quotes around the values, as that is >> probably the reason "%r" was used in the first place - i.e. use "'%s'" instead >> of plain "%s". > > +1 > > With current patch, I assume that a lot of unit tests will fail as they check > exact error message wording. I'd recommend running the whole test suite with > your second patch revision. There is a short walkthrough how to set it up: > > http://freeipa.org/page/Testing > > Martin > You missed a few: $ git grep -En '%(\(.*?\))?r' Honza -- Jan Cholasta From mkosek at redhat.com Mon Nov 5 12:18:49 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 05 Nov 2012 13:18:49 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <20121102205000.GM10066@localhost.localdomain> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> <20121102205000.GM10066@localhost.localdomain> Message-ID: <5097AEA9.8000906@redhat.com> On 11/02/2012 09:50 PM, Sumit Bose wrote: > On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: >> On 11/02/2012 12:54 PM, Sumit Bose wrote: >>> On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: >>>> On 10/30/2012 12:16 PM, Sumit Bose wrote: >>>>> Hi, >>>>> >>>>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name >>>>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>> >>>> >>>> Hello Sumit, >>>> >>>> I found few issues with your patch: >>> >>> Thank you for the review. >>> >>>> >>>> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not >>>> think this is necessary, ipa-adtrust-install already requires admin password to >>>> be passed and it already connects to LDAP with these credentials: >>>> >>>> api.Backend.ldap2.connect(ccache.name) >>>> >>>> You could use ipa.Backend.ldap2 object to do entry retrieval >>>> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. >>> >>> fixed >>> >>>> >>>> 2) When doing try..except statement, rule of thumb says that it should be as >>>> short as possible, so that it does not hide other potential errors and makes >>>> clear what function raises the catched exception. >>>> >>>> In your case: >>>> >>>> try: >>>> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), >>>> api.env.container_cifsdomains, >>>> self.api.env.basedn), >>>> ['ipantflatname']) >>>> except errors.NotFound: >>>> reset_netbios_name = False >>>> else: >>>> # process entry >>>> >>>> Should be a pattern that you want. >>> >>> fixed >>> >>> I also move all the NetBIOS name related code into a separate function. >>>> >>>> 3) I think this line is redundant: >>>> + print "Say 'yes' if the NetBIOS shall be changed and " \ >>>> + "'no' if the old one shall be kept." >>>> >>>> IMO, the question: >>>> >>>> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default >>>> = False, allow_empty = False) >>>> >>>> and the information printed before is enough. >>> >>> I would prefer to keep it this way to make clear that >>> ipa-adtrust-install will continue processing, but the old name if kept >>> even if a new name was given with --netbios-name on the command line. >>> >>> New version attached. >>> >>> bye, >>> Sumit >>> >>>> >>>> Martin >> >> >> The new approach looks much better. Sending issues I found with the new patch: >> >> 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS >> name interactively. I can only change it via script option... >> > > fixed > >> >> 2) I saw few typos: >> >> + print "Current NetBIOS domain name is %s new name is %s.\n" % \ >> should be: >> + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ >> >> + print "NetBIOS domain name will be changes to %s.\n" % \ >> should be: >> + print "NetBIOS domain name will be changed to %s.\n" % \ >> >> > > fixed > > new version attached. > > bye, > Sumit >> Martin NetBIOS name is now asked when first installing ipa-adtrust-install. But I see that NetBIOS name is still not queried when I run re-install of ADTRUST, I can only change current name via option. Is this is an intended behavior so that people cannot mess it with by mistake? # ipa-adtrust-install The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will setup components needed to establish trust to AD domains for the FreeIPA Server. This includes: * Configure Samba * Add trust related objects to FreeIPA LDAP server To accept the default shown in brackets, press the Enter key. IPA generated smb.conf detected. Overwrite smb.conf? [no]: y The following operations may take some minutes to complete. Please wait until the prompt is returned. <<< no NetBIOS name asked interactively Configuring cross-realm trusts for IPA server requires password for user 'admin'. This user is a regular system account used for IPA server administration. admin password: Configuring CIFS [1/18]: stopping smbd ... Otherwise the patch looks OK. Martin From pspacek at redhat.com Mon Nov 5 14:26:36 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 05 Nov 2012 15:26:36 +0100 Subject: [Freeipa-devel] [PATCH 0087] Unload master zone if forwarders are specified Message-ID: <5097CC9C.3060000@redhat.com> Hello, Unload master zone if forwarders are specified. This patch should solve master => forward zone type change. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0087-Unload-master-zone-if-forwarders-are-specified.patch Type: text/x-patch Size: 4514 bytes Desc: not available URL: From rcritten at redhat.com Mon Nov 5 19:34:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2012 14:34:35 -0500 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <5091181C.5060807@redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> Message-ID: <509814CB.5020104@redhat.com> Martin Kosek wrote: > On 10/31/2012 11:00 AM, Jakub Hrozek wrote: >> On Mon, Oct 22, 2012 at 02:14:00PM -0400, Simo Sorce wrote: >>> On Mon, 2012-10-22 at 17:15 +0200, Martin Kosek wrote: >>>> On 10/08/2012 08:27 PM, Rob Crittenden wrote: >>>>> Jakub Hrozek wrote: >>>>>> On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> Hi, >>>>>>>> >>>>>>>> the attached patches add the directory the SSSD writes domain-realm >>>>>>>> mappings as includedir to krb5.conf when installing the client. >>>>>>>> >>>>>>>> [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for >>>>>>>> options >>>>>>>> ipachangeconf only allows one delimeter between keys and values. This >>>>>>>> patch adds the possibility of also specifying "delim" in the option >>>>>>>> dictionary to override the default delimeter. >>>>>>>> >>>>>>>> On a slightly-unrelated note, we really should think about adopting >>>>>>>> Augeas. Changing configuration with home-grown scripts is getting >>>>>>>> tricky. >>>>>>>> >>>>>>>> [PATCH 2/3] Specify includedir in krb5.conf on new installs >>>>>>>> This patch utilizes the new functionality from the previous patch to >>>>>>>> add >>>>>>>> the includedir on top of the krb5.conf file >>>>>>>> >>>>>>>> [PATCH 3/3] Add the includedir to krb5.conf on upgrades >>>>>>>> This patch is completely untested and I'm only posting it to get >>>>>>>> opinions. At first I was going to use an upgrade script in %post but >>>>>>>> then I thought it would be overengineering when all we want to do is >>>>>>>> prepend one line.. Would a simple munging like this be acceptable or >>>>>>>> shall I write a full script? >>>>>>> >>>>>>> NACK, using a scriptlet is fine, but not the way you did, as it has a huge >>>>>>> race condition where krb5.conf exists and has only one line in it (the >>>>>>> include line). >>>>>>> >>>>>>> You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew >>>>>>> Then cat the contents of the existing file in i:t cat /etc/krb.conf >> >>>>>>> /etc/krb.conf.ipanew >>>>>>> And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf >>>>>>> >>>>>>> This method is also safe wrt something killing the yum process ... >>>>>>> >>>>>>> Simo. >>>>>> >>>>>> I'm attaching a new revision of the patches not even two months after >>>>>> the original nack. >>>>>> >>>>>> I also think it might be nice to have a more general way of upgrading >>>>>> the client config so I filed >>>>>> https://fedorahosted.org/freeipa/ticket/3149 >>>>> >>>>> I don't think grepping for a string is an effective way to determine if the >>>>> client has been configured. Someone could have removed that line. >>>>> >>>>> I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it exists >>>>> and has more than 2 lines in it ([files] + one other file) then it is safe to >>>>> say the client is configured, or at least partially configured. >>>>> >>>>> rob >>>>> >>>> >>>> I just found one more issue. What if ipa-client-install is run with --no-sssd >>>> option? In that case I assume we should not include the SSSD's krb5.include.d, >>>> right? The same would also appy for upgrades, we would need to check if client >>>> was actually configured with SSSD before mangling their krb5.conf. >>> >>> Yeah that's right, we should have all sssd related changes under a >>> conditional that is true only when sssd is enabled. >>> >>> Simo. >> >> OK, new patches are attached. In new installs, the includedir is only >> added when options.sssd is true. During upgrades, I checked for >> sssd.conf's existence, I'm not sure if there's any other way to check if >> the client was configured with sssd? > > Hello Jakub, thanks for these patches. I think that checking if /etc/sssd.conf > exists as actually not so bad way to test if it was configured. Anyway, I did > few tests on server and client but I still see few issues: > > 1) SELinux context of krb5.conf is not as expected (but I am not sure what real > issue could that cause): > > # restorecon -FvvR /etc/krb5.conf > restorecon reset /etc/krb5.conf context > unconfined_u:object_r:etc_t:s0->system_u:object_r:krb5_conf_t:s0 > > 2) I can no longer kinit on IPA server after applying your patch > # rpm -q sssd > sssd-1.9.90-0.20121030T1436Zgitf46bf56.fc17.x86_64 > # rpm -Uvh --force freeipa-*.rpm > # head -n 5 /etc/krb5.conf > includedir /var/lib/sss/pubconf/krb5.include.d/ > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > # KRB5_TRACE=/dev/stdout kinit admin > [21059] 1351684052.658548: Getting initial credentials for > admin at IDM.LAB.BOS.REDHAT.COM > [21059] 1351684052.665269: Sending request (200 bytes) to IDM.LAB.BOS.REDHAT.COM > [21059] 1351684052.665989: Resolving hostname vm-044.idm.lab.bos.redhat.com > [21059] 1351684052.667511: Sending initial UDP request to dgram 10.16.78.44:88 > [21059] 1351684052.672514: Received answer from dgram 10.16.78.44:88 > [21059] 1351684052.672653: Response was from master KDC > [21059] 1351684052.672751: Received error from KDC: -1765328370/KDC has no > support for encryption type > kinit: KDC has no support for encryption type while getting initial credentials > > > Now when I comment includedir: > # head -n 5 /etc/krb5.conf > # kinit admin > Password for admin at IDM.LAB.BOS.REDHAT.COM: > # echo $? > 0 > > When I upgraded client machine (without krb5kdc), kinit worked fine. Does that > mean that krb5.conf can only be changed on client machines? > > 3) We should also add Requires on sssd >= 1.9.0 in FreeIPA spec file to pick up > the new feature. Otherwise I just get an error on client: > > # kinit admin > kinit: Included profile directory could not be read while initializing Kerberos > 5 library > > 4) (Optional) I think we can make the process of checking if IPA is configured > easier and follow a similar way that Sumit did: > https://fedorahosted.org/freeipa/changeset/fe66fbe637132ac5eb22eea388e2261f33497bf5/ > > This section: > > +restore=0 > +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l > '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') > + > +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > 2>/dev/null ; then > > could then be replaced by something like this: > > python -c "import sys; from ipapython import ipautil; sys.exit(0 if > ipapython.is_ipaclient_configured() else 1);" > /dev/null 2>&1 > if [ $? -eq 0 ]; then > > I am not saying you need to do this step, this can be done later by us. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > I'm not sure how you ran into problems on master because krb5.conf wasn't being set up by default on IPA masters (I had to update the krb5.conf.template to get that done). Once updated we get a slew of AVCs: type=SYSCALL msg=audit(1352143784.563:2184): arch=c000003e syscall=257 success=yes exit=4 a0=ffffffffffffff9c a1=7f485970dc0b a2=90800 a3=0 items=0 ppid=1 pid=5307 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="krb5kdc" exe="/usr/sbin/krb5kdc" subj=system_u:system_r:krb5kdc_t:s0 key=(null) type=AVC msg=audit(1352143784.563:2184): avc: denied { open } for pid=5307 comm="krb5kdc" path="/var/lib/sss/pubconf/krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143784.563:2184): avc: denied { read } for pid=5307 comm="krb5kdc" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143784.563:2184): avc: denied { search } for pid=5307 comm="krb5kdc" name="pubconf" dev="sda3" ino=129 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143784.781:2186): avc: denied { open } for pid=5320 comm="kadmind" path="/var/lib/sss/pubconf/krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143784.781:2186): avc: denied { read } for pid=5320 comm="kadmind" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:kadmind_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143816.001:2192): avc: denied { read } for pid=5428 comm="httpd" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143851.870:2200): avc: denied { read } for pid=5489 comm="ns-slapd" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=SYSCALL msg=audit(1352143852.271:2201): arch=c000003e syscall=233 success=yes exit=0 a0=5 a1=2 a2=6 a3=7fff416fea80 items=0 ppid=1 pid=5308 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="krb5kdc" exe="/usr/sbin/krb5kdc" subj=system_u:system_r:krb5kdc_t:s0 key=(null) type=AVC msg=audit(1352143852.271:2201): avc: denied { block_suspend } for pid=5308 comm="krb5kdc" capability=36 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:system_r:krb5kdc_t:s0 tclass=capability2 type=SYSCALL msg=audit(1352143852.294:2204): arch=c000003e syscall=257 success=yes exit=4 a0=ffffffffffffff9c a1=7ff22c96cc0b a2=90800 a3=0 items=0 ppid=1 pid=5573 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="krb5kdc" exe="/usr/sbin/krb5kdc" subj=system_u:system_r:krb5kdc_t:s0 key=(null) type=AVC msg=audit(1352143852.294:2204): avc: denied { open } for pid=5573 comm="krb5kdc" path="/var/lib/sss/pubconf/krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143852.294:2204): avc: denied { read } for pid=5573 comm="krb5kdc" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143852.294:2204): avc: denied { search } for pid=5573 comm="krb5kdc" name="pubconf" dev="sda3" ino=129 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143855.199:2210): avc: denied { read } for pid=5516 comm="ns-slapd" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143854.002:2208): avc: denied { read } for pid=5583 comm="httpd" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=SYSCALL msg=audit(1352143863.255:2218): arch=c000003e syscall=233 success=yes exit=0 a0=5 a1=2 a2=6 a3=7fff40924bf0 items=0 ppid=1 pid=5574 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="krb5kdc" exe="/usr/sbin/krb5kdc" subj=system_u:system_r:krb5kdc_t:s0 key=(null) type=AVC msg=audit(1352143863.255:2218): avc: denied { block_suspend } for pid=5574 comm="krb5kdc" capability=36 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:system_r:krb5kdc_t:s0 tclass=capability2 type=SYSCALL msg=audit(1352143866.074:2229): arch=c000003e syscall=257 success=yes exit=4 a0=ffffffffffffff9c a1=7f38ce963c0b a2=90800 a3=0 items=0 ppid=1 pid=5821 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="krb5kdc" exe="/usr/sbin/krb5kdc" subj=system_u:system_r:krb5kdc_t:s0 key=(null) type=AVC msg=audit(1352143866.074:2229): avc: denied { open } for pid=5821 comm="krb5kdc" path="/var/lib/sss/pubconf/krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143866.074:2229): avc: denied { read } for pid=5821 comm="krb5kdc" name="krb5.include.d" dev="sda3" ino=130 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir type=AVC msg=audit(1352143866.074:2229): avc: denied { search } for pid=5821 comm="krb5kdc" name="pubconf" dev="sda3" ino=129 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:sssd_public_t:s0 tclass=dir rob From rcritten at redhat.com Mon Nov 5 22:24:55 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Nov 2012 17:24:55 -0500 Subject: [Freeipa-devel] [PATCH] 328 Process relative nameserver DNS record correctly In-Reply-To: <5093F1EF.2070701@redhat.com> References: <50894647.9030408@redhat.com> <508946D1.7000603@redhat.com> <5093E834.3040209@redhat.com> <5093F1EF.2070701@redhat.com> Message-ID: <50983CB7.3070008@redhat.com> Martin Kosek wrote: > On 11/02/2012 04:35 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On 10/25/2012 04:01 PM, Martin Kosek wrote: >>>> Nameserver hostname passed to dnszone_add command was always treated >>>> as FQDN even though it was a relative DNS name to the new zone. All >>>> relative names were being rejected as unresolvable. >>>> >>>> Modify --name-server option processing in dnszone_add and dnszone_mod >>>> to respect FQDN/relative DNS name and do the checks accordingly. With >>>> this change, user can add a new zone "example.com" and let dnszone_add >>>> to create NS record "ns" in it, when supplied with its IP address. IP >>>> address check is more strict so that it is not entered when no forward >>>> record is created. Places misusing the option were fixed. >>>> >>>> Nameserver option now also accepts zone name, which means that NS and A >>>> record is placed to DNS zone itself. Also "@" is accepted as a nameserver >>>> name, BIND understand it also as a zone name. As a side-effect of this >>>> change, other records with hostname part (MX, KX, NS, SRV) accept "@" >>>> as valid hostname. BIND replaces it with respective zone name as well. >>>> >>>> Unit tests were updated to test the new format. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3204 >>>> >>>> --- >>>> >>>> With this change, use cases like the following should now work as expected: >>>> >>>> # ipa dnszone-add example.com --name-server ns --ip-address 10.0.0.1 >>>> >>>> # ipa dnszone-add example.com --name-server ns.example.com. --ip-address >>>> 10.0.0.1 >>>> >>>> # ipa dnszone-add example.com --name-server ns.other.zone. --ip-address >>>> 10.0.0.1 >>>> >>>> # ipa dnszone-add example.com --name-server example.com. --ip-address 10.0.0.1 >>>> >>>> # ipa dnszone-add example.com --name-server @ --ip-address 10.0.0.1 >>>> >>>> Martin >>>> >>>> >>> >>> Forgot to squash NS check fix. Updated patch attached. >> >> Overall it looks good. >> >> The API needs to be updated. >> >> We had no formal string freeze but do we need to change doc strings now or can >> these be deferred (except may be the examples)? >> >> >> rob > > API updated. > Relaxed check for root zone that Petr Spacek pointed out was removed. > > As for the string changes... I think that the only optional change is this one: > > @@ -1726,10 +1764,10 @@ class dnszone_add(LDAPCreate): > takes_options = LDAPCreate.takes_options + ( > Flag('force', > label=_('Force'), > - doc=_('Force DNS zone creation even if nameserver not in DNS.'), > + doc=_('Force DNS zone creation even if nameserver is not > resolvable.'), > ), > Str('ip_address?', _validate_ipaddr, > - doc=_('Add the nameserver to DNS with this IP address'), > + doc=_('Add forward record for nameserver located in the created > zone'), > ), > ) > > > Other changes are needed to make our processing of domain name clear, like > > - error=unicode(_("Nameserver address is not a fully > qualified domain name"))) > + error=_("Nameserver address is not a domain name")) > > Updated patch attached. > > Martin > Ok, yes, better correct in English than wrong in the native tongue! ACK rob From edewata at redhat.com Tue Nov 6 05:07:21 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Nov 2012 23:07:21 -0600 Subject: [Freeipa-devel] [PATCH] 225 Web UI: disable global forwarding per zone In-Reply-To: <5093C64F.6030607@redhat.com> References: <5093C64F.6030607@redhat.com> Message-ID: <50989B09.901@redhat.com> On 11/2/2012 8:10 AM, Petr Vobornik wrote: > Web UI part of 'disable global forwarding per zone' effort. > > Option "Forwarding disabled" was added to 'DNS global config' and 'DNS > zone' forwarding policy. It corresponds to 'none' value of > idnsforwardpolicy. > > https://fedorahosted.org/freeipa/ticket/3209 It works with Martin's patch #330-3. ACK. -- Endi S. Dewata From mkosek at redhat.com Tue Nov 6 07:47:04 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Nov 2012 08:47:04 +0100 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <509814CB.5020104@redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> <509814CB.5020104@redhat.com> Message-ID: <5098C078.7090705@redhat.com> On 11/05/2012 08:34 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 10/31/2012 11:00 AM, Jakub Hrozek wrote: >>> On Mon, Oct 22, 2012 at 02:14:00PM -0400, Simo Sorce wrote: >>>> On Mon, 2012-10-22 at 17:15 +0200, Martin Kosek wrote: >>>>> On 10/08/2012 08:27 PM, Rob Crittenden wrote: >>>>>> Jakub Hrozek wrote: >>>>>>> On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the attached patches add the directory the SSSD writes domain-realm >>>>>>>>> mappings as includedir to krb5.conf when installing the client. >>>>>>>>> >>>>>>>>> [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for >>>>>>>>> options >>>>>>>>> ipachangeconf only allows one delimeter between keys and values. This >>>>>>>>> patch adds the possibility of also specifying "delim" in the option >>>>>>>>> dictionary to override the default delimeter. >>>>>>>>> >>>>>>>>> On a slightly-unrelated note, we really should think about adopting >>>>>>>>> Augeas. Changing configuration with home-grown scripts is getting >>>>>>>>> tricky. >>>>>>>>> >>>>>>>>> [PATCH 2/3] Specify includedir in krb5.conf on new installs >>>>>>>>> This patch utilizes the new functionality from the previous patch to >>>>>>>>> add >>>>>>>>> the includedir on top of the krb5.conf file >>>>>>>>> >>>>>>>>> [PATCH 3/3] Add the includedir to krb5.conf on upgrades >>>>>>>>> This patch is completely untested and I'm only posting it to get >>>>>>>>> opinions. At first I was going to use an upgrade script in %post but >>>>>>>>> then I thought it would be overengineering when all we want to do is >>>>>>>>> prepend one line.. Would a simple munging like this be acceptable or >>>>>>>>> shall I write a full script? >>>>>>>> >>>>>>>> NACK, using a scriptlet is fine, but not the way you did, as it has a huge >>>>>>>> race condition where krb5.conf exists and has only one line in it (the >>>>>>>> include line). >>>>>>>> >>>>>>>> You should first create the new file: echo "include ..." > >>>>>>>> /etc/krb.conf.ipanew >>>>>>>> Then cat the contents of the existing file in i:t cat /etc/krb.conf >> >>>>>>>> /etc/krb.conf.ipanew >>>>>>>> And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf >>>>>>>> >>>>>>>> This method is also safe wrt something killing the yum process ... >>>>>>>> >>>>>>>> Simo. >>>>>>> >>>>>>> I'm attaching a new revision of the patches not even two months after >>>>>>> the original nack. >>>>>>> >>>>>>> I also think it might be nice to have a more general way of upgrading >>>>>>> the client config so I filed >>>>>>> https://fedorahosted.org/freeipa/ticket/3149 >>>>>> >>>>>> I don't think grepping for a string is an effective way to determine if the >>>>>> client has been configured. Someone could have removed that line. >>>>>> >>>>>> I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it >>>>>> exists >>>>>> and has more than 2 lines in it ([files] + one other file) then it is >>>>>> safe to >>>>>> say the client is configured, or at least partially configured. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> I just found one more issue. What if ipa-client-install is run with --no-sssd >>>>> option? In that case I assume we should not include the SSSD's >>>>> krb5.include.d, >>>>> right? The same would also appy for upgrades, we would need to check if >>>>> client >>>>> was actually configured with SSSD before mangling their krb5.conf. >>>> >>>> Yeah that's right, we should have all sssd related changes under a >>>> conditional that is true only when sssd is enabled. >>>> >>>> Simo. >>> >>> OK, new patches are attached. In new installs, the includedir is only >>> added when options.sssd is true. During upgrades, I checked for >>> sssd.conf's existence, I'm not sure if there's any other way to check if >>> the client was configured with sssd? >> >> Hello Jakub, thanks for these patches. I think that checking if /etc/sssd.conf >> exists as actually not so bad way to test if it was configured. Anyway, I did >> few tests on server and client but I still see few issues: >> >> 1) SELinux context of krb5.conf is not as expected (but I am not sure what real >> issue could that cause): >> >> # restorecon -FvvR /etc/krb5.conf >> restorecon reset /etc/krb5.conf context >> unconfined_u:object_r:etc_t:s0->system_u:object_r:krb5_conf_t:s0 >> >> 2) I can no longer kinit on IPA server after applying your patch >> # rpm -q sssd >> sssd-1.9.90-0.20121030T1436Zgitf46bf56.fc17.x86_64 >> # rpm -Uvh --force freeipa-*.rpm >> # head -n 5 /etc/krb5.conf >> includedir /var/lib/sss/pubconf/krb5.include.d/ >> [logging] >> default = FILE:/var/log/krb5libs.log >> kdc = FILE:/var/log/krb5kdc.log >> admin_server = FILE:/var/log/kadmind.log >> # KRB5_TRACE=/dev/stdout kinit admin >> [21059] 1351684052.658548: Getting initial credentials for >> admin at IDM.LAB.BOS.REDHAT.COM >> [21059] 1351684052.665269: Sending request (200 bytes) to IDM.LAB.BOS.REDHAT.COM >> [21059] 1351684052.665989: Resolving hostname vm-044.idm.lab.bos.redhat.com >> [21059] 1351684052.667511: Sending initial UDP request to dgram 10.16.78.44:88 >> [21059] 1351684052.672514: Received answer from dgram 10.16.78.44:88 >> [21059] 1351684052.672653: Response was from master KDC >> [21059] 1351684052.672751: Received error from KDC: -1765328370/KDC has no >> support for encryption type >> kinit: KDC has no support for encryption type while getting initial credentials >> >> >> Now when I comment includedir: >> # head -n 5 /etc/krb5.conf >> # kinit admin >> Password for admin at IDM.LAB.BOS.REDHAT.COM: >> # echo $? >> 0 >> >> When I upgraded client machine (without krb5kdc), kinit worked fine. Does that >> mean that krb5.conf can only be changed on client machines? >> >> 3) We should also add Requires on sssd >= 1.9.0 in FreeIPA spec file to pick up >> the new feature. Otherwise I just get an error on client: >> >> # kinit admin >> kinit: Included profile directory could not be read while initializing Kerberos >> 5 library >> >> 4) (Optional) I think we can make the process of checking if IPA is configured >> easier and follow a similar way that Sumit did: >> https://fedorahosted.org/freeipa/changeset/fe66fbe637132ac5eb22eea388e2261f33497bf5/ >> >> >> This section: >> >> +restore=0 >> +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l >> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') >> + >> +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >> + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >> 2>/dev/null ; then >> >> could then be replaced by something like this: >> >> python -c "import sys; from ipapython import ipautil; sys.exit(0 if >> ipapython.is_ipaclient_configured() else 1);" > /dev/null 2>&1 >> if [ $? -eq 0 ]; then >> >> I am not saying you need to do this step, this can be done later by us. >> >> Martin >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel >> > > I'm not sure how you ran into problems on master because krb5.conf wasn't being > set up by default on IPA masters (I had to update the krb5.conf.template to get > that done). krb5.conf will be changed during RPM update. Jakub added an upgrade section to %posttrans scriptlet for client package. > > Once updated we get a slew of AVCs: Yeah, we will need to have those fixed before inclusion in IPA... Did you file any bugzilla or should I do it? Martin From jhrozek at redhat.com Tue Nov 6 07:50:24 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 6 Nov 2012 08:50:24 +0100 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <5098C078.7090705@redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> <509814CB.5020104@redhat.com> <5098C078.7090705@redhat.com> Message-ID: <20121106075024.GE27268@hendrix.redhat.com> On Tue, Nov 06, 2012 at 08:47:04AM +0100, Martin Kosek wrote: > > Once updated we get a slew of AVCs: > > Yeah, we will need to have those fixed before inclusion in IPA... Did you file > any bugzilla or should I do it? Yes: https://bugzilla.redhat.com/show_bug.cgi?id=873429 From jcholast at redhat.com Tue Nov 6 07:57:06 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 06 Nov 2012 08:57:06 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <20121029162157.GM3900@hendrix.redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> Message-ID: <5098C2D2.9060309@redhat.com> On 29.10.2012 17:21, Jakub Hrozek wrote: > An improvement based on Honza's suggestion. > You might want to remove the try block around "sssdconfig.activate_service('autofs')". If it throws NoServiceError at this point, there is something really broken in SSSDConfig, in which case it is better to display a traceback rather than a nice error message IMO. Honza -- Jan Cholasta From mkosek at redhat.com Tue Nov 6 09:25:47 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Nov 2012 10:25:47 +0100 Subject: [Freeipa-devel] [PATCH] 331 Update SELinux policy for dogtag10 Message-ID: <5098D79B.2080301@redhat.com> Incorporate SELinux policy changes introduced in Dogtag 10 in IPA SELinux policy: - dogtag10 now runs with pki_tomcat_t context instead of pki_ca_t - certmonger related rule are now integrated in system policy and can be removed from IPA policy Also remove redundant SELinux rules for connection of httpd_t, krb5kdc_t or named_t to DS socket. The socket has different target type anyway (dirsrv_var_run_t) and the policy allowing this is already in system. https://fedorahosted.org/freeipa/ticket/3234 --- I tested an installation of IPA on F18 with SELinux enforcing mode and so far so good. Unit tests passed, CRL generation still works, certmonger was still able resubmit a cert. To verify that SELinux rules allowing access of httpd/krb5kdc/named to dirsrv socket, you ran run this SELinux search: sesearch -A -s httpd_t -t dirsrv_var_run_t -c sock_file -p write I saw few (benign?) AVCs not caused by this patch, I filed Bugzillas for those: krb5: https://bugzilla.redhat.com/show_bug.cgi?id=873564 pki-ca: https://bugzilla.redhat.com/show_bug.cgi?id=873585 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-331-update-selinux-policy-for-dogtag10.patch Type: text/x-patch Size: 3753 bytes Desc: not available URL: From mkosek at redhat.com Tue Nov 6 13:44:43 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Nov 2012 14:44:43 +0100 Subject: [Freeipa-devel] [PATCH] 331 Update SELinux policy for dogtag10 In-Reply-To: <5098D79B.2080301@redhat.com> References: <5098D79B.2080301@redhat.com> Message-ID: <5099144B.8040104@redhat.com> On 11/06/2012 10:25 AM, Martin Kosek wrote: > Incorporate SELinux policy changes introduced in Dogtag 10 in IPA > SELinux policy: > - dogtag10 now runs with pki_tomcat_t context instead of pki_ca_t > - certmonger related rule are now integrated in system policy and > can be removed from IPA policy > > Also remove redundant SELinux rules for connection of httpd_t, krb5kdc_t > or named_t to DS socket. The socket has different target type anyway > (dirsrv_var_run_t) and the policy allowing this is already in > system. > > https://fedorahosted.org/freeipa/ticket/3234 > > --- > > I tested an installation of IPA on F18 with SELinux enforcing mode and so far > so good. Unit tests passed, CRL generation still works, certmonger was still > able resubmit a cert. > > To verify that SELinux rules allowing access of httpd/krb5kdc/named to dirsrv > socket, you ran run this SELinux search: > > sesearch -A -s httpd_t -t dirsrv_var_run_t -c sock_file -p write > > > I saw few (benign?) AVCs not caused by this patch, I filed Bugzillas for those: > > krb5: https://bugzilla.redhat.com/show_bug.cgi?id=873564 > pki-ca: https://bugzilla.redhat.com/show_bug.cgi?id=873585 > > Martin > Important note: if/when this patch is accepted, it should be pushed to master branch only, i.e. to 3.1 release. This should never get to Fedora < 18 (and dogtag < 10) where using context pki_ca_t does not fly. Martin From pspacek at redhat.com Tue Nov 6 14:02:37 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 06 Nov 2012 15:02:37 +0100 Subject: [Freeipa-devel] [PATCH 0088] Flush BIND caches if forwarder configuration was changed Message-ID: <5099187D.2070509@redhat.com> Hello, Flush BIND caches if forwarder configuration was changed. Cache will not be flushed if old and new configurations are equal. Without this optimization cache would be flushed during each zone refresh. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0088-Flush-BIND-caches-if-forwarder-configuration-was-cha.patch Type: text/x-patch Size: 5205 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 6 14:06:21 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 06 Nov 2012 15:06:21 +0100 Subject: [Freeipa-devel] [PATCH 0089] Bump NVR to 2.3 Message-ID: <5099195D.9020904@redhat.com> Hello, Bump NVR to 2.3. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0089-Bump-NVR-to-2.3.patch Type: text/x-patch Size: 1196 bytes Desc: not available URL: From atkac at redhat.com Tue Nov 6 14:38:16 2012 From: atkac at redhat.com (Adam Tkac) Date: Tue, 6 Nov 2012 15:38:16 +0100 Subject: [Freeipa-devel] [PATCH 0086] Respect global forwarders from named.conf if they are not overridden by LDAP configuration In-Reply-To: <50940AB5.4010703@redhat.com> References: <509406B1.2080400@redhat.com> <50940874.8080107@redhat.com> <50940AB5.4010703@redhat.com> Message-ID: <20121106143816.GA7753@redhat.com> On Fri, Nov 02, 2012 at 07:02:29PM +0100, Petr Spacek wrote: > On 11/02/2012 06:52 PM, Petr Spacek wrote: > >On 11/02/2012 06:45 PM, Petr Spacek wrote: > >>Hello, > >> > >>Respect global forwarders from named.conf if they are not overridden by LDAP > >>configuration. > >> > >>Original configuration from named.conf is saved on load. > >>Original configuration will be restored if configuration in LDAP is not > >>present or is invalid. > >> > >> > >>Another patch for cache flushing will follow. > > > >Well, another Friday - another forgotten patch. > > > For my mail client: The patch is *attached*. Ack > From 6439769095d018f1487e53e7dc1a597e411cf33a Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 2 Nov 2012 17:48:04 +0100 > Subject: [PATCH] Respect global forwarders from named.conf if they are not > overridden by LDAP configuration. > > Original configuration from named.conf is saved on load. > Original configuration will be restored if configuration in LDAP > is not present or is invalid. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 173 ++++++++++++++++++++++++++++++++++++++++++------------ > src/settings.c | 19 ++++++ > src/settings.h | 4 ++ > src/types.h | 5 ++ > 4 files changed, 163 insertions(+), 38 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 5d7138b1861a85ad8f3d8027e94f4f807355f48a..2d52bfaf894de8a5591f966b0c9197d14a1e73f7 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -84,6 +84,13 @@ > #define MINTSIZ (65535 - 12 - 1 - 2 - 2 - 4 - 2) > #define TOKENSIZ (8*1024) > > +const enum_txt_assoc_t forwarder_policy_txts[] = { > + { dns_fwdpolicy_none, "none" }, > + { dns_fwdpolicy_first, "first" }, > + { dns_fwdpolicy_only, "only" }, > + { -1, NULL } /* end marker */ > +}; > + > #define LDAP_OPT_CHECK(r, ...) \ > do { \ > if ((r) != LDAP_OPT_SUCCESS) { \ > @@ -177,6 +184,7 @@ struct ldap_instance { > isc_boolean_t sync_ptr; > isc_boolean_t dyn_update; > isc_boolean_t serial_autoincrement; > + dns_forwarders_t orig_global_forwarders; /* from named.conf */ > }; > > struct ldap_pool { > @@ -335,6 +343,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > ldap_instance_t *ldap_inst; > dns_view_t *view = NULL; > ld_string_t *auth_method_str = NULL; > + dns_forwarders_t *orig_global_forwarders = NULL; > setting_t ldap_settings[] = { > { "uri", no_default_string }, > { "connections", default_uint(2) }, > @@ -373,6 +382,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > view = dns_dyndb_get_view(dyndb_args); > dns_view_attach(view, &ldap_inst->view); > ldap_inst->zmgr = dns_dyndb_get_zonemgr(dyndb_args); > + ISC_LIST_INIT(ldap_inst->orig_global_forwarders.addrs); > > CHECK(zr_create(mctx, &ldap_inst->zone_register)); > > @@ -490,6 +500,35 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > CHECK(ldap_pool_create(mctx, ldap_inst->connections, &ldap_inst->pool)); > CHECK(ldap_pool_connect(ldap_inst->pool, ldap_inst)); > > + /* copy global forwarders setting for configuration roll back in > + * configure_zone_forwarders() */ > + result = dns_fwdtable_find(ldap_inst->view->fwdtable, dns_rootname, > + &orig_global_forwarders); > + if (result == ISC_R_SUCCESS) { > + isc_sockaddr_t *addr; > + isc_sockaddr_t *new_addr; > + for (addr = ISC_LIST_HEAD(orig_global_forwarders->addrs); > + addr != NULL; > + addr = ISC_LIST_NEXT(addr, link)) { > + new_addr = isc_mem_get(mctx, sizeof(isc_sockaddr_t)); > + if (new_addr == NULL) > + CLEANUP_WITH(ISC_R_NOMEMORY); > + *new_addr = *addr; > + ISC_LINK_INIT(new_addr, link); > + ISC_LIST_APPEND(ldap_inst->orig_global_forwarders.addrs, > + new_addr, link); > + } > + ldap_inst->orig_global_forwarders.fwdpolicy = > + orig_global_forwarders->fwdpolicy; > + > + } else if (result == ISC_R_NOTFOUND) { > + /* global forwarders are not configured */ > + ldap_inst->orig_global_forwarders.fwdpolicy = dns_fwdpolicy_none; > + result = ISC_R_SUCCESS; > + } else { > + goto cleanup; > + } > + > if (ldap_inst->psearch) { > /* Start the watcher thread */ > result = isc_thread_create(ldap_psearch_watcher, ldap_inst, > @@ -519,6 +558,7 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > dns_rbt_t *rbt = NULL; > isc_result_t result = ISC_R_SUCCESS; > const char *db_name; > + isc_sockaddr_t *addr; > > REQUIRE(ldap_instp != NULL && *ldap_instp != NULL); > > @@ -628,6 +668,12 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > > 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); > + isc_mem_put(ldap_inst->mctx, addr, sizeof(isc_sockaddr_t)); > + } > + > isc_mem_putanddetach(&ldap_inst->mctx, ldap_inst, sizeof(ldap_instance_t)); > > *ldap_instp = NULL; > @@ -882,6 +928,22 @@ 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) > @@ -911,22 +973,33 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > ldap_valuelist_t values; > ldap_value_t *value; > isc_sockaddrlist_t addrs; > + isc_boolean_t is_global_config; > + isc_boolean_t fwdtbl_deletion_requested = ISC_TRUE; > + const char *msg_use_global_fwds; > + const char *msg_obj_type; > + const char *msg_forwarders_not_def; > + const char *msg_forward_policy = NULL; > /** > * BIND forward policies are "first" (default) or "only". > * We invented option "none" which disables forwarding for zone > * regardless idnsForwarders attribute and global forwarders. > */ > dns_fwdpolicy_t fwdpolicy = dns_fwdpolicy_first; > - const char msg_use_global_fwds[] = "global forwarders will be used " > - "(if they are configured)"; > > REQUIRE(entry != NULL && inst != NULL && name != NULL); > - > - /* Clean old fwdtable. */ > - result = dns_fwdtable_delete(inst->view->fwdtable, name); > - if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) { > - log_error("zone '%s': failed to delete forwarders", dn); > - return ISC_R_FAILURE; > + ISC_LIST_INIT(addrs); > + if (dns_name_equal(name, dns_rootname)) { > + is_global_config = ISC_TRUE; > + msg_obj_type = "global configuration"; > + msg_use_global_fwds = "; global forwarders will be disabled"; > + msg_forwarders_not_def = "; global forwarders from " > + "configuration file will be used"; > + } else { > + is_global_config = ISC_FALSE; > + msg_obj_type = "zone"; > + msg_use_global_fwds = "; global forwarders will be used " > + "(if they are configured)"; > + msg_forwarders_not_def = msg_use_global_fwds; > } > > /* > @@ -943,72 +1016,96 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > else if (strcasecmp(value->value, "none") == 0) > fwdpolicy = dns_fwdpolicy_none; > else { > - log_error("zone '%s': invalid value '%s' in " > + log_error("%s '%s': invalid value '%s' in " > "idnsForwardPolicy attribute; " > - "valid values: first, only, none; " > + "valid values: first, only, none" > "%s", > - dn, value->value, msg_use_global_fwds); > - return ISC_R_UNEXPECTEDTOKEN; > + msg_obj_type, dn, value->value, > + msg_use_global_fwds); > + CLEANUP_WITH(ISC_R_UNEXPECTEDTOKEN); > } > } > } > - log_debug(5, "zone '%s': forward policy is '%s'", dn, > - (fwdpolicy == dns_fwdpolicy_first) ? "first" : value->value); > > if (fwdpolicy == dns_fwdpolicy_none) { > ISC_LIST_INIT(values); /* ignore idnsForwarders in LDAP */ > } else { > result = ldap_entry_getvalues(entry, "idnsForwarders", &values); > if (result == ISC_R_NOTFOUND || EMPTY(values)) { > - log_debug(5, "zone '%s': idnsForwarders attribute is " > - "not present, %s", dn, msg_use_global_fwds); > - return ISC_R_DISABLED; > + log_debug(5, "%s '%s': idnsForwarders attribute is " > + "not present%s", msg_obj_type, dn, > + msg_forwarders_not_def); > + if (is_global_config) { > + ISC_LIST_INIT(values); > + addrs = inst->orig_global_forwarders.addrs; > + fwdpolicy = inst->orig_global_forwarders.fwdpolicy; > + } else { > + CLEANUP_WITH(ISC_R_DISABLED); > + } > } > } > > - ISC_LIST_INIT(addrs); > + CHECK(get_enum_description(forwarder_policy_txts, fwdpolicy, > + &msg_forward_policy)); > + log_debug(5, "%s '%s': forward policy is '%s'", msg_obj_type, dn, > + msg_forward_policy); > + > for (value = HEAD(values); value != NULL; value = NEXT(value, link)) { > isc_sockaddr_t *addr = NULL; > char forwarder_txt[ISC_SOCKADDR_FORMATSIZE]; > > if (acl_parse_forwarder(value->value, inst->mctx, &addr) > != ISC_R_SUCCESS) { > - log_error("zone '%s': could not parse forwarder '%s'", > - dn, value->value); > + log_error("%s '%s': could not parse forwarder '%s'", > + msg_obj_type, dn, value->value); > continue; > } > > ISC_LINK_INIT(addr, link); > ISC_LIST_APPEND(addrs, addr, link); > isc_sockaddr_format(addr, forwarder_txt, ISC_SOCKADDR_FORMATSIZE); > - log_debug(5, "zone '%s': adding forwarder '%s'", dn, forwarder_txt); > + log_debug(5, "%s '%s': adding forwarder '%s'", msg_obj_type, > + dn, forwarder_txt); > } > > if (fwdpolicy != dns_fwdpolicy_none && ISC_LIST_EMPTY(addrs)) { > - log_debug(5, "zone '%s': all idnsForwarders are invalid, %s", > - dn, msg_use_global_fwds); > - return ISC_R_UNEXPECTEDTOKEN; > + log_debug(5, "%s '%s': all idnsForwarders are invalid%s", > + msg_obj_type, dn, msg_use_global_fwds); > + CLEANUP_WITH(ISC_R_UNEXPECTEDTOKEN); > } else if (fwdpolicy == dns_fwdpolicy_none) { > - log_debug(5, "zone '%s': forwarding explicitly disabled " > - "(policy 'none', ignoring global forwarders)", dn); > + log_debug(5, "%s '%s': forwarding explicitly disabled " > + "(policy 'none', ignoring global forwarders)", > + msg_obj_type, dn); > } > > /* Set forward table up. */ > + CHECK(delete_forwarding_table(inst, name, msg_obj_type, dn)); > result = dns_fwdtable_add(inst->view->fwdtable, name, &addrs, fwdpolicy); > - > - while (!ISC_LIST_EMPTY(addrs)) { > - isc_sockaddr_t *addr = NULL; > - addr = ISC_LIST_HEAD(addrs); > - ISC_LIST_UNLINK(addrs, addr, link); > - isc_mem_put(inst->mctx, addr, sizeof(*addr)); > + if (result == ISC_R_SUCCESS) { > + fwdtbl_deletion_requested = ISC_FALSE; > + if (fwdpolicy == dns_fwdpolicy_none) > + result = ISC_R_DISABLED; > + } else { > + log_error_r("%s '%s': forwarding table update failed", > + msg_obj_type, dn); > } > > - if (result != ISC_R_SUCCESS) > - log_error_r("zone '%s': forwarding table update failed", dn); > - > - if (fwdpolicy == dns_fwdpolicy_none && result == ISC_R_SUCCESS) > - result = ISC_R_DISABLED; > - > +cleanup: > + if (ISC_LIST_HEAD(addrs) != > + ISC_LIST_HEAD(inst->orig_global_forwarders.addrs)) { > + while(!ISC_LIST_EMPTY(addrs)) { > + isc_sockaddr_t *addr = NULL; > + addr = ISC_LIST_HEAD(addrs); > + ISC_LIST_UNLINK(addrs, addr, link); > + isc_mem_put(inst->mctx, addr, sizeof(*addr)); > + } > + } > + if (fwdtbl_deletion_requested) { > + isc_result_t orig_result = result; > + result = delete_forwarding_table(inst, name, msg_obj_type, dn); > + if (result == ISC_R_SUCCESS) > + result = orig_result; > + } > return result; > } > > diff --git a/src/settings.c b/src/settings.c > index de9c7738d68954e9cb2f141d10963aa09da6a19f..25578ce2687bf12e3a2d387caf0b26ed1a3083b6 100644 > --- a/src/settings.c > +++ b/src/settings.c > @@ -30,6 +30,7 @@ > #include "settings.h" > #include "str.h" > #include "util.h" > +#include "types.h" > > > /* > @@ -195,3 +196,21 @@ get_value_str(const char *arg) > > return arg; > } > + > +isc_result_t > +get_enum_description(const enum_txt_assoc_t *map, int value, const char **desc) { > + const enum_txt_assoc_t *record; > + > + REQUIRE(map != NULL); > + REQUIRE(desc != NULL && *desc == NULL); > + > + for (record = map; > + record->description != NULL && record->value != -1; > + record++) { > + if (record->value == value) { > + *desc = record->description; > + return ISC_R_SUCCESS; > + } > + } > + return ISC_R_NOTFOUND; > +} > diff --git a/src/settings.h b/src/settings.h > index f1846695e1d1433cd310c6b9fba3076171fca2eb..53910ee11c2ac1f87db25fac8f24f5743f4312e4 100644 > --- a/src/settings.h > +++ b/src/settings.h > @@ -22,6 +22,7 @@ > #define _LD_SETTINGS_H_ > > #include > +#include "types.h" > > typedef struct setting setting_t; > > @@ -77,4 +78,7 @@ struct setting { > isc_result_t > set_settings(setting_t *settings, const char * const* argv); > > +isc_result_t > +get_enum_description(const enum_txt_assoc_t *map, int value, const char **desc); > + > #endif /* !_LD_SETTINGS_H_ */ > diff --git a/src/types.h b/src/types.h > index fe8dc62dda60a79ab753a7d32482f122c466c1bf..7d3bce4a26c99627bb1183dfd37814c4a7507d6e 100644 > --- a/src/types.h > +++ b/src/types.h > @@ -49,6 +49,11 @@ struct ldapdb_node { > ISC_LINK(ldapdb_node_t) link; > }; > > +typedef struct enum_txt_assoc { > + int value; > + const char *description; > +} enum_txt_assoc_t; > + > isc_result_t > ldapdbnode_create(isc_mem_t *mctx, dns_name_t *owner, ldapdb_node_t **nodep); > #endif /* !_LD_TYPES_H_ */ > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From mkosek at redhat.com Tue Nov 6 16:52:17 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 06 Nov 2012 17:52:17 +0100 Subject: [Freeipa-devel] [PATCH] 328 Process relative nameserver DNS record correctly In-Reply-To: <50983CB7.3070008@redhat.com> References: <50894647.9030408@redhat.com> <508946D1.7000603@redhat.com> <5093E834.3040209@redhat.com> <5093F1EF.2070701@redhat.com> <50983CB7.3070008@redhat.com> Message-ID: <50994041.9040604@redhat.com> On 11/05/2012 11:24 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 11/02/2012 04:35 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On 10/25/2012 04:01 PM, Martin Kosek wrote: >>>>> Nameserver hostname passed to dnszone_add command was always treated >>>>> as FQDN even though it was a relative DNS name to the new zone. All >>>>> relative names were being rejected as unresolvable. >>>>> >>>>> Modify --name-server option processing in dnszone_add and dnszone_mod >>>>> to respect FQDN/relative DNS name and do the checks accordingly. With >>>>> this change, user can add a new zone "example.com" and let dnszone_add >>>>> to create NS record "ns" in it, when supplied with its IP address. IP >>>>> address check is more strict so that it is not entered when no forward >>>>> record is created. Places misusing the option were fixed. >>>>> >>>>> Nameserver option now also accepts zone name, which means that NS and A >>>>> record is placed to DNS zone itself. Also "@" is accepted as a nameserver >>>>> name, BIND understand it also as a zone name. As a side-effect of this >>>>> change, other records with hostname part (MX, KX, NS, SRV) accept "@" >>>>> as valid hostname. BIND replaces it with respective zone name as well. >>>>> >>>>> Unit tests were updated to test the new format. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3204 >>>>> >>>>> --- >>>>> >>>>> With this change, use cases like the following should now work as expected: >>>>> >>>>> # ipa dnszone-add example.com --name-server ns --ip-address 10.0.0.1 >>>>> >>>>> # ipa dnszone-add example.com --name-server ns.example.com. --ip-address >>>>> 10.0.0.1 >>>>> >>>>> # ipa dnszone-add example.com --name-server ns.other.zone. --ip-address >>>>> 10.0.0.1 >>>>> >>>>> # ipa dnszone-add example.com --name-server example.com. --ip-address >>>>> 10.0.0.1 >>>>> >>>>> # ipa dnszone-add example.com --name-server @ --ip-address 10.0.0.1 >>>>> >>>>> Martin >>>>> >>>>> >>>> >>>> Forgot to squash NS check fix. Updated patch attached. >>> >>> Overall it looks good. >>> >>> The API needs to be updated. >>> >>> We had no formal string freeze but do we need to change doc strings now or can >>> these be deferred (except may be the examples)? >>> >>> >>> rob >> >> API updated. >> Relaxed check for root zone that Petr Spacek pointed out was removed. >> >> As for the string changes... I think that the only optional change is this one: >> >> @@ -1726,10 +1764,10 @@ class dnszone_add(LDAPCreate): >> takes_options = LDAPCreate.takes_options + ( >> Flag('force', >> label=_('Force'), >> - doc=_('Force DNS zone creation even if nameserver not in DNS.'), >> + doc=_('Force DNS zone creation even if nameserver is not >> resolvable.'), >> ), >> Str('ip_address?', _validate_ipaddr, >> - doc=_('Add the nameserver to DNS with this IP address'), >> + doc=_('Add forward record for nameserver located in the created >> zone'), >> ), >> ) >> >> >> Other changes are needed to make our processing of domain name clear, like >> >> - error=unicode(_("Nameserver address is not a fully >> qualified domain name"))) >> + error=_("Nameserver address is not a domain name")) >> >> Updated patch attached. >> >> Martin >> > > Ok, yes, better correct in English than wrong in the native tongue! > > ACK > > rob Pushed to master, ipa-3-0. Martin From rcritten at redhat.com Tue Nov 6 22:36:00 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Nov 2012 17:36:00 -0500 Subject: [Freeipa-devel] [PATCH] 1071 fix replica-manage Message-ID: <509990D0.7030907@redhat.com> A few of the new RUV commands would fail if no agreements had ever been set up. Simple things like this would fail: $ ipa-replica-manage list-ruv Remove the assumption that at least one entry is always returned. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1071-ruv.patch Type: text/x-diff Size: 1861 bytes Desc: not available URL: From jhrozek at redhat.com Tue Nov 6 23:53:21 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 7 Nov 2012 00:53:21 +0100 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <5091181C.5060807@redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> Message-ID: <20121106235321.GC2813@hendrix.redhat.com> On Wed, Oct 31, 2012 at 01:22:52PM +0100, Martin Kosek wrote: > On 10/31/2012 11:00 AM, Jakub Hrozek wrote: > > On Mon, Oct 22, 2012 at 02:14:00PM -0400, Simo Sorce wrote: > >> On Mon, 2012-10-22 at 17:15 +0200, Martin Kosek wrote: > >>> On 10/08/2012 08:27 PM, Rob Crittenden wrote: > >>>> Jakub Hrozek wrote: > >>>>> On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> Hi, > >>>>>>> > >>>>>>> the attached patches add the directory the SSSD writes domain-realm > >>>>>>> mappings as includedir to krb5.conf when installing the client. > >>>>>>> > >>>>>>> [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for > >>>>>>> options > >>>>>>> ipachangeconf only allows one delimeter between keys and values. This > >>>>>>> patch adds the possibility of also specifying "delim" in the option > >>>>>>> dictionary to override the default delimeter. > >>>>>>> > >>>>>>> On a slightly-unrelated note, we really should think about adopting > >>>>>>> Augeas. Changing configuration with home-grown scripts is getting > >>>>>>> tricky. > >>>>>>> > >>>>>>> [PATCH 2/3] Specify includedir in krb5.conf on new installs > >>>>>>> This patch utilizes the new functionality from the previous patch to > >>>>>>> add > >>>>>>> the includedir on top of the krb5.conf file > >>>>>>> > >>>>>>> [PATCH 3/3] Add the includedir to krb5.conf on upgrades > >>>>>>> This patch is completely untested and I'm only posting it to get > >>>>>>> opinions. At first I was going to use an upgrade script in %post but > >>>>>>> then I thought it would be overengineering when all we want to do is > >>>>>>> prepend one line.. Would a simple munging like this be acceptable or > >>>>>>> shall I write a full script? > >>>>>> > >>>>>> NACK, using a scriptlet is fine, but not the way you did, as it has a huge > >>>>>> race condition where krb5.conf exists and has only one line in it (the > >>>>>> include line). > >>>>>> > >>>>>> You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew > >>>>>> Then cat the contents of the existing file in i:t cat /etc/krb.conf >> > >>>>>> /etc/krb.conf.ipanew > >>>>>> And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf > >>>>>> > >>>>>> This method is also safe wrt something killing the yum process ... > >>>>>> > >>>>>> Simo. > >>>>> > >>>>> I'm attaching a new revision of the patches not even two months after > >>>>> the original nack. > >>>>> > >>>>> I also think it might be nice to have a more general way of upgrading > >>>>> the client config so I filed > >>>>> https://fedorahosted.org/freeipa/ticket/3149 > >>>> > >>>> I don't think grepping for a string is an effective way to determine if the > >>>> client has been configured. Someone could have removed that line. > >>>> > >>>> I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it exists > >>>> and has more than 2 lines in it ([files] + one other file) then it is safe to > >>>> say the client is configured, or at least partially configured. > >>>> > >>>> rob > >>>> > >>> > >>> I just found one more issue. What if ipa-client-install is run with --no-sssd > >>> option? In that case I assume we should not include the SSSD's krb5.include.d, > >>> right? The same would also appy for upgrades, we would need to check if client > >>> was actually configured with SSSD before mangling their krb5.conf. > >> > >> Yeah that's right, we should have all sssd related changes under a > >> conditional that is true only when sssd is enabled. > >> > >> Simo. > > > > OK, new patches are attached. In new installs, the includedir is only > > added when options.sssd is true. During upgrades, I checked for > > sssd.conf's existence, I'm not sure if there's any other way to check if > > the client was configured with sssd? > > Hello Jakub, thanks for these patches. I think that checking if /etc/sssd.conf > exists as actually not so bad way to test if it was configured. Anyway, I did > few tests on server and client but I still see few issues: > > 1) SELinux context of krb5.conf is not as expected (but I am not sure what real > issue could that cause): > > # restorecon -FvvR /etc/krb5.conf > restorecon reset /etc/krb5.conf context > unconfined_u:object_r:etc_t:s0->system_u:object_r:krb5_conf_t:s0 > Fixed. Thanks, I shouldn have noticed that doing mv would just replace the original context. > 2) I can no longer kinit on IPA server after applying your patch > # rpm -q sssd > sssd-1.9.90-0.20121030T1436Zgitf46bf56.fc17.x86_64 > # rpm -Uvh --force freeipa-*.rpm > # head -n 5 /etc/krb5.conf > includedir /var/lib/sss/pubconf/krb5.include.d/ > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > # KRB5_TRACE=/dev/stdout kinit admin > [21059] 1351684052.658548: Getting initial credentials for > admin at IDM.LAB.BOS.REDHAT.COM > [21059] 1351684052.665269: Sending request (200 bytes) to IDM.LAB.BOS.REDHAT.COM > [21059] 1351684052.665989: Resolving hostname vm-044.idm.lab.bos.redhat.com > [21059] 1351684052.667511: Sending initial UDP request to dgram 10.16.78.44:88 > [21059] 1351684052.672514: Received answer from dgram 10.16.78.44:88 > [21059] 1351684052.672653: Response was from master KDC > [21059] 1351684052.672751: Received error from KDC: -1765328370/KDC has no > support for encryption type > kinit: KDC has no support for encryption type while getting initial credentials > > > Now when I comment includedir: > # head -n 5 /etc/krb5.conf > # kinit admin > Password for admin at IDM.LAB.BOS.REDHAT.COM: > # echo $? > 0 > > When I upgraded client machine (without krb5kdc), kinit worked fine. Does that > mean that krb5.conf can only be changed on client machines? > I'm still looking into this. I'm not sure why kinit does that and why it does that on the IPA server only. Unfortunately the default krb5 package is so optimized that I need to rebuild one without optimizations. > 3) We should also add Requires on sssd >= 1.9.0 in FreeIPA spec file to pick up > the new feature. Otherwise I just get an error on client: > > # kinit admin > kinit: Included profile directory could not be read while initializing Kerberos > 5 library > Done > 4) (Optional) I think we can make the process of checking if IPA is configured > easier and follow a similar way that Sumit did: > https://fedorahosted.org/freeipa/changeset/fe66fbe637132ac5eb22eea388e2261f33497bf5/ > > This section: > > +restore=0 > +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l > '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') > + > +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > 2>/dev/null ; then > > could then be replaced by something like this: > > python -c "import sys; from ipapython import ipautil; sys.exit(0 if > ipapython.is_ipaclient_configured() else 1);" > /dev/null 2>&1 > if [ $? -eq 0 ]; then > > I am not saying you need to do this step, this can be done later by us. That code currently only exists for IPA server, right? At least judging by: from ipaserver.install import installutils; Then I would prefer to do it separately. It's a good idea, though, the postscript as it is now is ugly. -------------- next part -------------- >From b04f54dae49679633173d21139219743172bdeb4 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Fri, 17 Aug 2012 11:19:03 +0200 Subject: [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for options --- ipa-client/ipaclient/ipachangeconf.py | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/ipa-client/ipaclient/ipachangeconf.py b/ipa-client/ipaclient/ipachangeconf.py index 6cf47b807957c245fe03ff4259e35526c49175a9..bdc5579fccd82193e837b5e86cbc694c2619317c 100644 --- a/ipa-client/ipaclient/ipachangeconf.py +++ b/ipa-client/ipaclient/ipachangeconf.py @@ -174,9 +174,12 @@ class IPAChangeConf: self.subsectdel[1])) continue if o['type'] == "option": + delim = o.get('delim', self.dassign) + if delim not in self.assign: + raise ValueError('Unknown delim "%s" must be one of "%s"' % (delim, " ".join([d for d in self.assign]))) output.append(self._dump_line(self.indent[level], o['name'], - self.dassign, + delim, o['value'])) continue if o['type'] == "comment": @@ -200,13 +203,21 @@ class IPAChangeConf: 'type': 'comment', 'value': value.rstrip()} # pylint: disable=E1103 + o = dict() parts = line.split(self.dassign, 1) if len(parts) < 2: - raise SyntaxError('Syntax Error: Unknown line format') + # The default assign didn't match, try the non-default + for d in self.assign[1:]: + parts = line.split(d, 1) + if len(parts) >= 2: + o['delim'] = d + break - return {'name': parts[0].strip(), - 'type': 'option', - 'value': parts[1].rstrip()} + if 'delim' not in o: + raise SyntaxError, 'Syntax Error: Unknown line format' + + o.update({'name':parts[0].strip(), 'type':'option', 'value':parts[1].rstrip()}) + return o def findOpts(self, opts, type, name, exclude_sections=False): @@ -256,13 +267,13 @@ class IPAChangeConf: 'value': val}) continue if o['type'] == 'option': - val = self._dump_line(self.indent[level], - o['name'], - self.dassign, - o['value']) - opts.append({'name': 'comment', - 'type': 'comment', - 'value': val}) + delim = o.get('delim', self.dassign) + if delim not in self.assign: + val = self._dump_line(self.indent[level], + o['name'], + delim, + o['value']) + opts.append({'name':'comment', 'type':'comment', 'value':val}) continue if o['type'] == 'comment': opts.append(o) -- 1.7.12.1 -------------- next part -------------- >From 7cca38e2e0b1ffdb9ea8837872e43fe191ff7cbe Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 31 Oct 2012 10:59:04 +0100 Subject: [PATCH 2/3] Specify includedir in krb5.conf on new installs --- freeipa.spec.in | 2 +- ipa-client/ipa-install/ipa-client-install | 7 ++++++- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 90f78905a30ac3b0f0372a5a744d7669020a8df7..c7d43d2a1cddfe53cf6f9c6dbf75d74b3213d176 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -84,7 +84,7 @@ BuildRequires: pylint BuildRequires: python-polib BuildRequires: libipa_hbac-python BuildRequires: python-memcached -BuildRequires: sssd >= 1.8.0 +BuildRequires: sssd >= 1.9.2 BuildRequires: python-lxml BuildRequires: python-pyasn1 >= 0.0.9a BuildRequires: python-dns diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 190efb183d8c96e2c9665cf51d5346dc1111ae24..5bfaf3319e3f3f015059150b7cb9030495f3c7b8 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -729,7 +729,7 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, filename, client_domain): krbconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") - krbconf.setOptionAssignment(" = ") + krbconf.setOptionAssignment((" = ", " ")) krbconf.setSectionNameDelimiters(("[","]")) krbconf.setSubSectionDelimiters(("{","}")) krbconf.setIndent((""," "," ")) @@ -737,6 +737,11 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, opts = [{'name':'comment', 'type':'comment', 'value':'File modified by ipa-client-install'}, {'name':'empty', 'type':'empty'}] + # SSSD include dir + if options.sssd: + opts.append({'name':'includedir', 'type':'option', 'value':'/var/lib/sss/pubconf/krb5.include.d/', 'delim':' '}) + opts.append({'name':'empty', 'type':'empty'}) + #[libdefaults] libopts = [{'name':'default_realm', 'type':'option', 'value':cli_realm}] if not dnsok or not cli_kdc or options.force: -- 1.7.12.1 -------------- next part -------------- >From 475a089e8f68d710526df0167dd0c16c3b3bd18f Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 31 Oct 2012 10:15:28 +0100 Subject: [PATCH 3/3] Add the includedir to krb5.conf on upgrades --- freeipa.spec.in | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index c7d43d2a1cddfe53cf6f9c6dbf75d74b3213d176..26a174b9e9f92ad44ea07f731b7acb90565f60e4 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -176,6 +176,7 @@ Requires: python-dns Requires: keyutils Requires: zip Requires: policycoreutils >= %{POLICYCOREUTILSVER} +Requires(postttrans): policycoreutils # We have a soft-requires on bind. It is an optional part of # IPA but if it is configured we need a way to require versions @@ -611,6 +612,19 @@ if [ $1 -eq 0 ]; then fi %endif +%posttrans client +# Has the client been configured? +restore=0 +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') + +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf 2>/dev/null ; then + echo "includedir /var/lib/sss/pubconf/krb5.include.d/" > /etc/krb5.conf.ipanew + cat /etc/krb5.conf >> /etc/krb5.conf.ipanew + mv /etc/krb5.conf.ipanew /etc/krb5.conf + /sbin/restorecon /etc/krb5.conf + fi +fi %if ! %{ONLY_CLIENT} %files server -f server-python.list -- 1.7.12.1 From jhrozek at redhat.com Wed Nov 7 08:14:14 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 7 Nov 2012 09:14:14 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <5098C2D2.9060309@redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> <5098C2D2.9060309@redhat.com> Message-ID: <20121107081414.GF2813@hendrix.redhat.com> On Tue, Nov 06, 2012 at 08:57:06AM +0100, Jan Cholasta wrote: > On 29.10.2012 17:21, Jakub Hrozek wrote: > >An improvement based on Honza's suggestion. > > > > You might want to remove the try block around > "sssdconfig.activate_service('autofs')". If it throws NoServiceError > at this point, there is something really broken in SSSDConfig, in > which case it is better to display a traceback rather than a nice > error message IMO. > I guess this really depends on what the consistent behaviour of the installer tools is. My take would be to print an error message to the terminal and a traceback to a logfile. I can change the patch, technically that's not a problem, just let me know if printing a traceback is the preferred way. From mkosek at redhat.com Wed Nov 7 08:45:14 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Nov 2012 09:45:14 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <20121107081414.GF2813@hendrix.redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> <5098C2D2.9060309@redhat.com> <20121107081414.GF2813@hendrix.redhat.com> Message-ID: <509A1F9A.9090805@redhat.com> On 11/07/2012 09:14 AM, Jakub Hrozek wrote: > On Tue, Nov 06, 2012 at 08:57:06AM +0100, Jan Cholasta wrote: >> On 29.10.2012 17:21, Jakub Hrozek wrote: >>> An improvement based on Honza's suggestion. >>> >> >> You might want to remove the try block around >> "sssdconfig.activate_service('autofs')". If it throws NoServiceError >> at this point, there is something really broken in SSSDConfig, in >> which case it is better to display a traceback rather than a nice >> error message IMO. >> > > I guess this really depends on what the consistent behaviour of the > installer tools is. > > My take would be to print an error message to the terminal and a > traceback to a logfile. +1 for this approach. I do not think that tracebacks is a very user-friendly output. Martin > > I can change the patch, technically that's not a problem, just let me > know if printing a traceback is the preferred way. > From mkosek at redhat.com Wed Nov 7 09:02:45 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Nov 2012 10:02:45 +0100 Subject: [Freeipa-devel] [PATCH] 1071 fix replica-manage In-Reply-To: <509990D0.7030907@redhat.com> References: <509990D0.7030907@redhat.com> Message-ID: <509A23B5.1080706@redhat.com> On 11/06/2012 11:36 PM, Rob Crittenden wrote: > A few of the new RUV commands would fail if no agreements had ever been set up. > Simple things like this would fail: > > $ ipa-replica-manage list-ruv > > Remove the assumption that at least one entry is always returned. > > rob > ACK. Pushed to master, ipa-3-0. Martin From jcholast at redhat.com Wed Nov 7 10:51:15 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 07 Nov 2012 11:51:15 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <509A1F9A.9090805@redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> <5098C2D2.9060309@redhat.com> <20121107081414.GF2813@hendrix.redhat.com> <509A1F9A.9090805@redhat.com> Message-ID: <509A3D23.2010001@redhat.com> On 7.11.2012 09:45, Martin Kosek wrote: > On 11/07/2012 09:14 AM, Jakub Hrozek wrote: >> On Tue, Nov 06, 2012 at 08:57:06AM +0100, Jan Cholasta wrote: >>> On 29.10.2012 17:21, Jakub Hrozek wrote: >>>> An improvement based on Honza's suggestion. >>>> >>> >>> You might want to remove the try block around >>> "sssdconfig.activate_service('autofs')". If it throws NoServiceError >>> at this point, there is something really broken in SSSDConfig, in >>> which case it is better to display a traceback rather than a nice >>> error message IMO. >>> >> >> I guess this really depends on what the consistent behaviour of the >> installer tools is. >> >> My take would be to print an error message to the terminal and a >> traceback to a logfile. > > +1 for this approach. I do not think that tracebacks is a very user-friendly > output. It is not supposed to be user-friendly, as it is not supposed to happen, ever. If it does happen, it is a bug in SSSDConfig. AFAIK we don't do any other third-party API sanity checks with nice error messages anywhere in IPA, hence my suggestion. > > Martin > >> >> I can change the patch, technically that's not a problem, just let me >> know if printing a traceback is the preferred way. >> I'm fine with whatever approach, but if you go with the error message, please indicate in it that the world has collapsed and SSSDConfig is broken. Honza -- Jan Cholasta From sbose at redhat.com Wed Nov 7 12:54:58 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 7 Nov 2012 13:54:58 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <5097AEA9.8000906@redhat.com> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> <20121102205000.GM10066@localhost.localdomain> <5097AEA9.8000906@redhat.com> Message-ID: <20121107125458.GE2195@localhost.localdomain> On Mon, Nov 05, 2012 at 01:18:49PM +0100, Martin Kosek wrote: > On 11/02/2012 09:50 PM, Sumit Bose wrote: > > On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: > >> On 11/02/2012 12:54 PM, Sumit Bose wrote: > >>> On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: > >>>> On 10/30/2012 12:16 PM, Sumit Bose wrote: > >>>>> Hi, > >>>>> > >>>>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name > >>>>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . > >>>>> > >>>>> bye, > >>>>> Sumit > >>>>> > >>>> > >>>> > >>>> Hello Sumit, > >>>> > >>>> I found few issues with your patch: > >>> > >>> Thank you for the review. > >>> > >>>> > >>>> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not > >>>> think this is necessary, ipa-adtrust-install already requires admin password to > >>>> be passed and it already connects to LDAP with these credentials: > >>>> > >>>> api.Backend.ldap2.connect(ccache.name) > >>>> > >>>> You could use ipa.Backend.ldap2 object to do entry retrieval > >>>> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. > >>> > >>> fixed > >>> > >>>> > >>>> 2) When doing try..except statement, rule of thumb says that it should be as > >>>> short as possible, so that it does not hide other potential errors and makes > >>>> clear what function raises the catched exception. > >>>> > >>>> In your case: > >>>> > >>>> try: > >>>> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), > >>>> api.env.container_cifsdomains, > >>>> self.api.env.basedn), > >>>> ['ipantflatname']) > >>>> except errors.NotFound: > >>>> reset_netbios_name = False > >>>> else: > >>>> # process entry > >>>> > >>>> Should be a pattern that you want. > >>> > >>> fixed > >>> > >>> I also move all the NetBIOS name related code into a separate function. > >>>> > >>>> 3) I think this line is redundant: > >>>> + print "Say 'yes' if the NetBIOS shall be changed and " \ > >>>> + "'no' if the old one shall be kept." > >>>> > >>>> IMO, the question: > >>>> > >>>> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default > >>>> = False, allow_empty = False) > >>>> > >>>> and the information printed before is enough. > >>> > >>> I would prefer to keep it this way to make clear that > >>> ipa-adtrust-install will continue processing, but the old name if kept > >>> even if a new name was given with --netbios-name on the command line. > >>> > >>> New version attached. > >>> > >>> bye, > >>> Sumit > >>> > >>>> > >>>> Martin > >> > >> > >> The new approach looks much better. Sending issues I found with the new patch: > >> > >> 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS > >> name interactively. I can only change it via script option... > >> > > > > fixed > > > >> > >> 2) I saw few typos: > >> > >> + print "Current NetBIOS domain name is %s new name is %s.\n" % \ > >> should be: > >> + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ > >> > >> + print "NetBIOS domain name will be changes to %s.\n" % \ > >> should be: > >> + print "NetBIOS domain name will be changed to %s.\n" % \ > >> > >> > > > > fixed > > > > new version attached. > > > > bye, > > Sumit > >> Martin > > NetBIOS name is now asked when first installing ipa-adtrust-install. > > But I see that NetBIOS name is still not queried when I run re-install of > ADTRUST, I can only change current name via option. Is this is an intended > behavior so that people cannot mess it with by mistake? Yes. The old code didn't check if the NetBIOS name was already set in LDAP or not, hence it always asked the user if the generated NetBIOS name is the one the user expected. The new version looks up the NetBIOS name in the LDAP server and if set and no new name is given on the command line assumes that the admin does not want to change the NetBIOS name and skips the dialog. I'll add the QE team to hear what they prefer. Jenny, Scott, Steeve, assume ipa-adtrust-install is run after trust was already configured and no --netbios-name option is given on the command line. Shall the following dialog be shown: ..... Enter the NetBIOS name for the IPA domain. Only up to 15 uppercase ASCII letters and digits are allowed. Example: EXAMPLE. NetBIOS domain name [IPA17]: .... The admin then has to press enter to confirm the current NetBIOS name or can enter a new one. Or shall the dialog be skipped which means that the NetBIOS can only be resetted if a new one is given at the command line with the --netbios-name option? Thank you for your input. bye, Sumit > > # ipa-adtrust-install > > The log file for this installation can be found in /var/log/ipaserver-install.log > ============================================================================== > This program will setup components needed to establish trust to AD domains for > the FreeIPA Server. > > This includes: > * Configure Samba > * Add trust related objects to FreeIPA LDAP server > > To accept the default shown in brackets, press the Enter key. > > IPA generated smb.conf detected. > Overwrite smb.conf? [no]: y > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > <<< no NetBIOS name asked interactively > > Configuring cross-realm trusts for IPA server requires password for user 'admin'. > This user is a regular system account used for IPA server administration. > > admin password: > > Configuring CIFS > [1/18]: stopping smbd > ... > > > Otherwise the patch looks OK. > > Martin From mkosek at redhat.com Wed Nov 7 13:03:46 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Nov 2012 14:03:46 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <20121107125458.GE2195@localhost.localdomain> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> <20121102205000.GM10066@localhost.localdomain> <5097AEA9.8000906@redhat.com> <20121107125458.GE2195@localhost.localdomain> Message-ID: <509A5C32.9080207@redhat.com> On 11/07/2012 01:54 PM, Sumit Bose wrote: > On Mon, Nov 05, 2012 at 01:18:49PM +0100, Martin Kosek wrote: >> On 11/02/2012 09:50 PM, Sumit Bose wrote: >>> On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: >>>> On 11/02/2012 12:54 PM, Sumit Bose wrote: >>>>> On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: >>>>>> On 10/30/2012 12:16 PM, Sumit Bose wrote: >>>>>>> Hi, >>>>>>> >>>>>>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name >>>>>>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . >>>>>>> >>>>>>> bye, >>>>>>> Sumit >>>>>>> >>>>>> >>>>>> >>>>>> Hello Sumit, >>>>>> >>>>>> I found few issues with your patch: >>>>> >>>>> Thank you for the review. >>>>> >>>>>> >>>>>> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not >>>>>> think this is necessary, ipa-adtrust-install already requires admin password to >>>>>> be passed and it already connects to LDAP with these credentials: >>>>>> >>>>>> api.Backend.ldap2.connect(ccache.name) >>>>>> >>>>>> You could use ipa.Backend.ldap2 object to do entry retrieval >>>>>> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. >>>>> >>>>> fixed >>>>> >>>>>> >>>>>> 2) When doing try..except statement, rule of thumb says that it should be as >>>>>> short as possible, so that it does not hide other potential errors and makes >>>>>> clear what function raises the catched exception. >>>>>> >>>>>> In your case: >>>>>> >>>>>> try: >>>>>> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), >>>>>> api.env.container_cifsdomains, >>>>>> self.api.env.basedn), >>>>>> ['ipantflatname']) >>>>>> except errors.NotFound: >>>>>> reset_netbios_name = False >>>>>> else: >>>>>> # process entry >>>>>> >>>>>> Should be a pattern that you want. >>>>> >>>>> fixed >>>>> >>>>> I also move all the NetBIOS name related code into a separate function. >>>>>> >>>>>> 3) I think this line is redundant: >>>>>> + print "Say 'yes' if the NetBIOS shall be changed and " \ >>>>>> + "'no' if the old one shall be kept." >>>>>> >>>>>> IMO, the question: >>>>>> >>>>>> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default >>>>>> = False, allow_empty = False) >>>>>> >>>>>> and the information printed before is enough. >>>>> >>>>> I would prefer to keep it this way to make clear that >>>>> ipa-adtrust-install will continue processing, but the old name if kept >>>>> even if a new name was given with --netbios-name on the command line. >>>>> >>>>> New version attached. >>>>> >>>>> bye, >>>>> Sumit >>>>> >>>>>> >>>>>> Martin >>>> >>>> >>>> The new approach looks much better. Sending issues I found with the new patch: >>>> >>>> 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS >>>> name interactively. I can only change it via script option... >>>> >>> >>> fixed >>> >>>> >>>> 2) I saw few typos: >>>> >>>> + print "Current NetBIOS domain name is %s new name is %s.\n" % \ >>>> should be: >>>> + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ >>>> >>>> + print "NetBIOS domain name will be changes to %s.\n" % \ >>>> should be: >>>> + print "NetBIOS domain name will be changed to %s.\n" % \ >>>> >>>> >>> >>> fixed >>> >>> new version attached. >>> >>> bye, >>> Sumit >>>> Martin >> >> NetBIOS name is now asked when first installing ipa-adtrust-install. >> >> But I see that NetBIOS name is still not queried when I run re-install of >> ADTRUST, I can only change current name via option. Is this is an intended >> behavior so that people cannot mess it with by mistake? > > Yes. The old code didn't check if the NetBIOS name was already set in > LDAP or not, hence it always asked the user if the generated NetBIOS > name is the one the user expected. > > The new version looks up the NetBIOS name in the LDAP server and if set > and no new name is given on the command line assumes that the admin > does not want to change the NetBIOS name and skips the dialog. > > I'll add the QE team to hear what they prefer. > > Jenny, Scott, Steeve, assume ipa-adtrust-install is run after trust was > already configured and no --netbios-name option is given on the command > line. Shall the following dialog be shown: > > ..... > Enter the NetBIOS name for the IPA domain. > Only up to 15 uppercase ASCII letters and digits are allowed. > Example: EXAMPLE. > > > NetBIOS domain name [IPA17]: > .... > > The admin then has to press enter to confirm the current NetBIOS name or > can enter a new one. Or shall the dialog be skipped which means that the > NetBIOS can only be resetted if a new one is given at the command line > with the --netbios-name option? Ok, thanks from explanation. But from my devel perspective, since a change of NetBIOS domain name can break existing trusts I would rather not offer a change of NetBIOS name during interactive prompt. A mere stating of a current value with asking to user to change it should be enough. QE input is welcome, yes. Martin > > Thank you for your input. > > bye, > Sumit > >> >> # ipa-adtrust-install >> >> The log file for this installation can be found in /var/log/ipaserver-install.log >> ============================================================================== >> This program will setup components needed to establish trust to AD domains for >> the FreeIPA Server. >> >> This includes: >> * Configure Samba >> * Add trust related objects to FreeIPA LDAP server >> >> To accept the default shown in brackets, press the Enter key. >> >> IPA generated smb.conf detected. >> Overwrite smb.conf? [no]: y >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> <<< no NetBIOS name asked interactively >> >> Configuring cross-realm trusts for IPA server requires password for user 'admin'. >> This user is a regular system account used for IPA server administration. >> >> admin password: >> >> Configuring CIFS >> [1/18]: stopping smbd >> ... >> >> >> Otherwise the patch looks OK. >> >> Martin From pviktori at redhat.com Wed Nov 7 13:34:36 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 07 Nov 2012 14:34:36 +0100 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <5092B2A4.6030306@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> Message-ID: <509A636C.6090408@redhat.com> On 11/01/2012 06:34 PM, Petr Viktorin wrote: > 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. >>>>> >>>> Dogtag recently changed the defaults it uses for pkispawn: we need to set "pki_admin_name", "pki_admin_uid", "pki_security_domain_user" to "admin" to retain current behavior. Attaching updated patch that does this. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-alee-0001-03-Changes-to-use-a-single-database-for-dogtag-and-IPA.patch Type: text/x-patch Size: 36295 bytes Desc: not available URL: From steeve at redhat.com Wed Nov 7 13:53:52 2012 From: steeve at redhat.com (Steeve Goveas) Date: Wed, 07 Nov 2012 19:23:52 +0530 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <509A5C32.9080207@redhat.com> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> <20121102205000.GM10066@localhost.localdomain> <5097AEA9.8000906@redhat.com> <20121107125458.GE2195@localhost.localdomain> <509A5C32.9080207@redhat.com> Message-ID: <509A67F0.9030907@redhat.com> On 11/07/2012 06:33 PM, Martin Kosek wrote: > On 11/07/2012 01:54 PM, Sumit Bose wrote: >> On Mon, Nov 05, 2012 at 01:18:49PM +0100, Martin Kosek wrote: >>> On 11/02/2012 09:50 PM, Sumit Bose wrote: >>>> On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: >>>>> On 11/02/2012 12:54 PM, Sumit Bose wrote: >>>>>> On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: >>>>>>> On 10/30/2012 12:16 PM, Sumit Bose wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name >>>>>>>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . >>>>>>>> >>>>>>>> bye, >>>>>>>> Sumit >>>>>>>> >>>>>>> >>>>>>> Hello Sumit, >>>>>>> >>>>>>> I found few issues with your patch: >>>>>> Thank you for the review. >>>>>> >>>>>>> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not >>>>>>> think this is necessary, ipa-adtrust-install already requires admin password to >>>>>>> be passed and it already connects to LDAP with these credentials: >>>>>>> >>>>>>> api.Backend.ldap2.connect(ccache.name) >>>>>>> >>>>>>> You could use ipa.Backend.ldap2 object to do entry retrieval >>>>>>> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. >>>>>> fixed >>>>>> >>>>>>> 2) When doing try..except statement, rule of thumb says that it should be as >>>>>>> short as possible, so that it does not hide other potential errors and makes >>>>>>> clear what function raises the catched exception. >>>>>>> >>>>>>> In your case: >>>>>>> >>>>>>> try: >>>>>>> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), >>>>>>> api.env.container_cifsdomains, >>>>>>> self.api.env.basedn), >>>>>>> ['ipantflatname']) >>>>>>> except errors.NotFound: >>>>>>> reset_netbios_name = False >>>>>>> else: >>>>>>> # process entry >>>>>>> >>>>>>> Should be a pattern that you want. >>>>>> fixed >>>>>> >>>>>> I also move all the NetBIOS name related code into a separate function. >>>>>>> 3) I think this line is redundant: >>>>>>> + print "Say 'yes' if the NetBIOS shall be changed and " \ >>>>>>> + "'no' if the old one shall be kept." >>>>>>> >>>>>>> IMO, the question: >>>>>>> >>>>>>> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default >>>>>>> = False, allow_empty = False) >>>>>>> >>>>>>> and the information printed before is enough. >>>>>> I would prefer to keep it this way to make clear that >>>>>> ipa-adtrust-install will continue processing, but the old name if kept >>>>>> even if a new name was given with --netbios-name on the command line. >>>>>> >>>>>> New version attached. >>>>>> >>>>>> bye, >>>>>> Sumit >>>>>> >>>>>>> Martin >>>>> >>>>> The new approach looks much better. Sending issues I found with the new patch: >>>>> >>>>> 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS >>>>> name interactively. I can only change it via script option... >>>>> >>>> fixed >>>> >>>>> 2) I saw few typos: >>>>> >>>>> + print "Current NetBIOS domain name is %s new name is %s.\n" % \ >>>>> should be: >>>>> + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ >>>>> >>>>> + print "NetBIOS domain name will be changes to %s.\n" % \ >>>>> should be: >>>>> + print "NetBIOS domain name will be changed to %s.\n" % \ >>>>> >>>>> >>>> fixed >>>> >>>> new version attached. >>>> >>>> bye, >>>> Sumit >>>>> Martin >>> NetBIOS name is now asked when first installing ipa-adtrust-install. >>> >>> But I see that NetBIOS name is still not queried when I run re-install of >>> ADTRUST, I can only change current name via option. Is this is an intended >>> behavior so that people cannot mess it with by mistake? >> Yes. The old code didn't check if the NetBIOS name was already set in >> LDAP or not, hence it always asked the user if the generated NetBIOS >> name is the one the user expected. >> >> The new version looks up the NetBIOS name in the LDAP server and if set >> and no new name is given on the command line assumes that the admin >> does not want to change the NetBIOS name and skips the dialog. >> >> I'll add the QE team to hear what they prefer. >> >> Jenny, Scott, Steeve, assume ipa-adtrust-install is run after trust was >> already configured and no --netbios-name option is given on the command >> line. Shall the following dialog be shown: >> >> ..... >> Enter the NetBIOS name for the IPA domain. >> Only up to 15 uppercase ASCII letters and digits are allowed. >> Example: EXAMPLE. >> >> >> NetBIOS domain name [IPA17]: >> .... >> >> The admin then has to press enter to confirm the current NetBIOS name or >> can enter a new one. Or shall the dialog be skipped which means that the >> NetBIOS can only be resetted if a new one is given at the command line >> with the --netbios-name option? > Ok, thanks from explanation. But from my devel perspective, since a change of > NetBIOS domain name can break existing trusts I would rather not offer a change > of NetBIOS name during interactive prompt. A mere stating of a current value > with asking to user to change it should be enough. > > QE input is welcome, yes. > > Martin > If changing the netbios name post creating trust would break existing trust, then I dont think that changing the netbios named should be allowed. A clear message to drop the trust and re-add it would be better. -Steeve >> Thank you for your input. >> >> bye, >> Sumit >> >>> # ipa-adtrust-install >>> >>> The log file for this installation can be found in /var/log/ipaserver-install.log >>> ============================================================================== >>> This program will setup components needed to establish trust to AD domains for >>> the FreeIPA Server. >>> >>> This includes: >>> * Configure Samba >>> * Add trust related objects to FreeIPA LDAP server >>> >>> To accept the default shown in brackets, press the Enter key. >>> >>> IPA generated smb.conf detected. >>> Overwrite smb.conf? [no]: y >>> >>> The following operations may take some minutes to complete. >>> Please wait until the prompt is returned. >>> >>> <<< no NetBIOS name asked interactively >>> >>> Configuring cross-realm trusts for IPA server requires password for user 'admin'. >>> This user is a regular system account used for IPA server administration. >>> >>> admin password: >>> >>> Configuring CIFS >>> [1/18]: stopping smbd >>> ... >>> >>> >>> Otherwise the patch looks OK. >>> >>> Martin From lroot at redhat.com Wed Nov 7 15:08:41 2012 From: lroot at redhat.com (Lynn Root) Date: Wed, 7 Nov 2012 10:08:41 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <5097860C.9050109@redhat.com> Message-ID: <1347679228.6583986.1352300921252.JavaMail.root@redhat.com> Third time is a charm? Lynn Root Associate Software Engineer Red Hat ----- Original Message ----- From: "Jan Cholasta" To: "Lynn Root" Cc: freeipa-devel at redhat.com Sent: Monday, November 5, 2012 10:25:32 AM Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors On 5.11.2012 09:43, Lynn Root wrote: > Here's try #2! Adjusted patch attached. Let me know if there's anything else I've missed. > > Switched %r specifiers to '%s' in Public errors, and adjusted tests to expect no preceding 'u'. > > Tickets: https://fedorahosted.org/freeipa/ticket/3121 & https://fedorahosted.org/freeipa/ticket/2588 > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Martin Kosek" > To: "Jan Cholasta" > Cc: "Lynn Root" , freeipa-devel at redhat.com > Sent: Tuesday, October 30, 2012 9:08:33 AM > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors > > On 10/30/2012 09:04 AM, Jan Cholasta wrote: >> Hi, >> >> On 29.10.2012 19:54, Lynn Root wrote: >>> Hi all! >>> >>> This switch drops the preceding 'u' from strings in public error messages. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>> >>> This patch also addresses the unfriendly 'u' from re-raising errors from the >>> external call to netaddr.IPAddress by passing a bytestring to the function. >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>> >>> >>> My first patch (and freeipa dev list email) ever! Let me know where there's >>> room to improve. >>> >>> Lynn Root >>> Associate Software Engineer >>> Red Hat >>> >> >> I think it would be nice if you kept the quotes around the values, as that is >> probably the reason "%r" was used in the first place - i.e. use "'%s'" instead >> of plain "%s". > > +1 > > With current patch, I assume that a lot of unit tests will fail as they check > exact error message wording. I'd recommend running the whole test suite with > your second patch revision. There is a short walkthrough how to set it up: > > http://freeipa.org/page/Testing > > Martin > You missed a few: $ git grep -En '%(\(.*?\))?r' Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Switch-r-specifiers-to-s-in-Public-errors-for-user-f.patch Type: text/x-patch Size: 44687 bytes Desc: not available URL: From pvoborni at redhat.com Wed Nov 7 15:46:12 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Nov 2012 16:46:12 +0100 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509280B2.2040607@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> Message-ID: <509A8244.5000607@redhat.com> We discussed some things on IRC. I wrote some comments below to allow others to chime in. Adam also created a public etherpad where we wrote most of the issues and possible solutions in some frameworks. I also wrote there short reviews of various JavaScript frameworks. https://etherpad.openstack.org/webui-idm On 11/01/2012 03:01 PM, Adam Young wrote: > 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. I strongly disagree. First jquery is mostly DOM manipulation, AJAX and some effects library. Other libraries can use it but there is no need to be build upon it. None or soft dependency on jquery is much better. > > We also wanted to make the Entity definition as declarative as possible, I don't want to change it. I like this approach even thought it brings some problems. > and we didn't want to be driven by another developers view of M-V-C. I > still feel this is most important. Do we or don't we? Endi wrote that you agreed that we need a better framework? Should the framework fix only issues other than MVC or MVC too? Most of the framework which might help us (persistance, structure) has some view of MVC. My conclusion about them is at the end of the mail and in the etherpad. > > 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. IMO 'new' keyword usage is not bad if proper convention is used: all functions which are supposed to be used as constructors must start with capital letter. > > >>>>> >>>>>> 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 Agree. > 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. Please elaborate. IMO fast load times are one of the things which makes admins happy. I'm not convinced that admin needs to view the code. It's just nice to have. Most of people won't debug the code. Most (maybe all) Web UI bug reports contain just steps to reproduce, error message or screenshots. I don't remember stack-trace or similar code-related report. > >>>>>> >>>>>> 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). > > Just want to reiterate the power of being able to dop development > withouth having to do a build. DO NOT MAKE A DELIBERATE BUILD STEP FOR > JAVASCRIPT! Build is just for production. Development will remain build-less. Currently I'm the person which does the most UI debugging so it's natural that I don't want to make it harder for me :). >>>>>> >>>>>> [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 builder isn't in the rpm. >>>> >>>> AFAIK the dojo rpm contains already built files. It has a core >>>> dojo.js file which contains basic modules to work but the rest of >>>> modules are separated. IDK if it can be used in a build process. I >>>> have to test it. >>>> >>>>> >>>>> There's also RequireJS (http://requirejs.org/). >>>> >>>> require.js is just AMD loader but it uses r.js as optimizer. r.js >>>> seems more lightweight than dojo builder. I would stick with dojo >>>> loader and builder if we use other dojo features. >>>> >>>>> >>>>>> ### 2) Object store/model >>>>>> At the beginning Web UI was quite simple - a command filled widgets, >>>>>> widgets got edited, update command was constructed from widgets, >>>>>> it was >>>>>> sent to server and at the end widgets were updated with new values. >>>>>> >>>>>> Now various parts of displayed page (action lists, panels, status >>>>>> widgets, facet header) needs to use loaded values too or influence >>>>>> others. This issue was often discussed in patch reviews. As a >>>>>> solution, >>>>>> some model object with bidirectional binding capabilities would be >>>>>> greatly beneficial. >>>>>> >>>>>> Dojo provides a extensible object store [1]. I would like to use >>>>>> 'memory >>>>>> store' and 'observable' and extend it with 'dirty-check' >>>>>> capabilities. >>>>>> >>>>>> [1] >>>>>> http://dojotoolkit.org/documentation/tutorials/1.8/intro_dojo_store/ >>>>> >>>>> Backbone also has similar mechanisms for events and sync. >>>>> >>>>>> ### 3) Class model >>>>>> Yes, in IPA Web UI we are using some class model, but it has flaws, >>>>>> mainly in initialization of a object (some initialization code of >>>>>> parent >>>>>> class may be called before inheritance is finished). >>>>>> >>>>>> Dojo has a class system [1] which is easy to use and support >>>>>> inheritance, mixins and overrided function calls. >>>>>> >>>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/declare/ >>>>> >>>>> At first glance Backbone seems to be better in this area, but Dojo >>>>> might >>>>> also be sufficient for our purposes. >>>> >>>> Backbone seems to have advantage in calling super class' constructor. >>>> It is not recommended in Dojo. >>>> >>>>> >>>>> There's going to be some challenges converting the current class >>>>> framework. Like you said, the current initialization isn't well >>>>> structured, so we might need to fix that first before converting the >>>>> class framework. And then we use 'that' instead of 'this', and >>>>> sometimes >>>>> both, and they get confusing, so we'd have to be very careful when >>>>> converting them. Also, the current way to call a method in super class >>>>> needs to be fixed. >>>> >>>> We can come with some strategy to keep patch reviews simple. >>>> IE: >>>> * move initialization stuff to init method (or more fine-grained) and >>>> use builder to create and instance (in some parts its already done), >>>> this way we eliminate statements in class declaration (except method >>>> declaration and overriding) >>>> * change to the classes: change that to this/self(to keep context in >>>> closures) >>>> * eliminate method overrides with inherited() calls. >>>> * put init calls to constructor >>>> * change builder again >>>> >>>>> >>>>>> ### 4) Localization >>>>>> Web UI and pages in config, migrate and error folder are not >>>>>> localized >>>>>> until successful login. It's because Web UI gets localized strings by >>>>>> API call which needs prior authentication. We should use other >>>>>> method to >>>>>> provide localized config, error and login pages. > The localization information is not necessarily accessable to the > browser. The only thing we can depend on is that the server gets it, > and then sends back the strings. That was the rationale for the current > mechanism. >>>>>> >>>>>> Dojo has a easy to use localization solution [1]. Basically >>>>>> strings are >>>>>> defined in .js files as modules, translations in subfolders. Dojo >>>>>> loader >>>>>> and i18n framework take care of loading of proper string depending on >>>>>> user's local. It doesn't need communication with JSON-RPC so can be >>>>>> used >>>>>> in config and login pages. >>>>>> >>>>>> We would have to make a script to translate the format to a format >>>>>> usable by transifex. >>>>>> >>>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/i18n/ >>>>> >>>>> A possible alternative is jquery-i18n-properties >>>>> (http://code.google.com/p/jquery-i18n-properties/). >>>>> >>>>>> ### 5) Navigation >>>>>> Our navigation code is limited to IPA entities. Introducing >>>>>> non-entity >>>>>> page like log (#3040) or help is problematic. Routing code should be >>>>>> improved. Separate entity initialization and menu definition. As the >>>>>> re-factoring will be at some point done, we might consider to use >>>>>> dojo.router and dojo.hash instead of $.bbq. This is really >>>>>> optional and >>>>>> not strictly related to Dojo, but I wanted to mention it. >>>>>> >>>>>> Better handling of pkeys may fix `#2741 [ipa webui] Intermittent >>>>>> errors >>>>>> - 'cn' is required; limits exceeded for this query` >>>>> >>>>> Backbone also has router and history. >>>>> >>>>>> ### 6) Easier unit tests >>>>>> By utilizing AMD modules, Localization, Model binding we might be >>>>>> able >>>>>> to write unit tests of widgets easier. Now we have to simulate >>>>>> entity, >>>>>> facets, fields, strings loaded from JSON-RPC... >>>>> >>>>> Yes, that would be great. > I'd like better inversion of control in the JS code in general. But you > don't need to move to Dojo to do that. As I recall, Dojo "wiring up" > was about a 1/2 way solution (but it has been a long time since I looked) AMD is not IoC, but it share some ideas. The only framework with DI (of the reviewed) is Angular.js. >>>>> >>>>>> ### 7) Separation of framework and IPA >>>>>> We often talk about separating Web UI framework and IPA related >>>>>> stuff. >>>>>> We can do it along with this refactoring. >>>>>> https://fedorahosted.org/freeipa/ticket/3030 >>>>> >>>>> Yes, but it might need to be fixed separately. >>>> >>>> I don't want to this all stuff in one patch :). >>>>> >>>>>> What I don't want to do >>>>>> ----------------------- >>>>>> * rewrite whole UI, changes should be gradual >>>>>> * replace jQuery. Most of our widgets are using jquery, I don't >>>>>> want to >>>>>> change this code, so I don't want to replace it with Dojo widget >>>>>> system >>>>>> - too big effort. So in the result the HTML output should not be >>>>>> changed >>>>>> much - not to affect automated tests. >>>>>> >>>>>> ### Steps how could be Dojo incorporated >>>>>> It should be done gradually. >>>>>> 1) make the build system working. Without it a lot of .js files >>>>>> would be >>>>>> transmitted to browser which is really bad. >>>>> >>>>> This is probably the easiest part. The next steps could be >>>>> difficult to >>>>> untangle. So be ready for a long haul. :) >>>> >>>> The harder part is not to populate git and rpm with a lot of >>>> third-party stuff. We need to convince dojo builder to use uglify.js >>>> under rhino to avoid using of closure compiler or shrink-safe which >>>> are not and probably will not be bundled in fedora and RHEL and >>>> definitely we don't want to bundle them. >>>> >>>> I'm thinking about making a script which would create WebUI-devoloper >>>> enviroment: >>>> * checkout dojo/dojo and dojo/util git repository to 1.8.1 tag >>>> * create a symbolic links to the tag >>>> * apply custom patches on dojo/util (there will definitely be one) >>>> * include in FreeIPA git only builded dojo.js (in the case we have >>>> separate files for dojo.js and freeipa.js (just a suggestion of name)) >>>> * will investigate if we can build the builder and include it in git >>>> for rpm builds. >>>> >>>> We can of course include into our git a whole 1.8.1 dojo/dojo and >>>> dojo/util but I would rather avoid it because it's a LOT of files. >>>> >>>>> >>>>>> 2) separate components to individual files and transform then into >>>>>> AMD >>>>>> modules. We might change namespaces and dependencies to separate >>>>>> Web UI >>>>>> framework and IPA related stuff. >>>>>> 3) change class system of entities and facets >>>>>> 4) implement a 'model' >>>>>> ? >>>>>> At this point it depends on priorities and new tickets with higher >>>>>> priority may appear. >>>>> >>>> >>>> >>> Still sounds scary... What is the general recommendation? Are the >>> arguments for or against Dojo convincing? >>> >> I proposed it, so the question is mainly for Endi or Adam, if he is >> interested (added Cc). >> >> Just to add: >> The question is whether we want to use third party code to solve some >> issues or we want to write everything ourselves. Everything I wrote >> above can be solved by us but it will probably take much more time. >> Dojo itself won't fix our problems it just provides means to fix >> them. As Enti wrote, for the problems we have, it can be replaced by >> multiple libraries combined(require.js, r.js, backbone.js, >> jquery-i18n-properties). >> >> I don't want to repeat myself much so adding just some dojo-related >> pros and cons: >> >> Cons: >> * third party code - we need to watch updates, sec issues >> * more complex build of UI which eventually needs more unit tests >> (basically I want some build with or without Dojo) >> >> Pros: >> * third party code - don't have to reinvent the wheel >> * establish library (good docs, some books were writen) >> * using good modular structure, we can pick the parts we actually >> want, when we want (loader, builder, class system, object store, >> localization, modular system) >> > > > My take away is the a Framework is the right direction, but Dojo is not > the right Framework. Please elaborate. > I would look to see if someone has built the > equivalent on top of JQuery. If not, pull in the various pieces from > JQuery based projects and move forward with that. I disagree. As I said jquery is good at what it does. Problems we want to solve don't have anything to do with jquery. JQ is functional library which calls usually bind to some page element. That is not desired when dealing with architectural problems. Various plugins might also have problems with long-term support. > I think you are right > to focus on unit tests and modularity. But I think at this point, you > would be better off with an incremental approach. I still think Dojo is the best fit for us. Conclusion from comparing various frameworks (narrowed to Ember.js, AngularJS, backbone.js, JavaScriptMVC, Dojo): If we don't want to adopt other view of MVC we can ditch Ember.js, JavaScriptMVC and Angular JS, without their MVC there is no point to use them. If we would re-write the UI from scratch, which we don't want to, I would probably choose Ember.js because it uses nice structured way and has view composition, we would loose our declarative approach though. We are left with backbone and dojo. Backbone is very lightweight, it can't do anything more than classes, events, router, views and model (REST persistence). All of it and *more* can be done with Dojo. Its MVC approach is very similar to ours. Model implementation is not only REST which is good for us as we use JSON-RPC. Because it's completely AMD, we can build a custom dojo build with only the components we care about. Modularity: I think we agreed on that we want to change UI to AMD modules. It basically means we go with Dojo + uglify.js or we choose require.js, r.js, uglify.js and some other library to solve non-module stuff. -- Petr Vobornik From mkosek at redhat.com Wed Nov 7 16:20:30 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Nov 2012 17:20:30 +0100 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <20121106235321.GC2813@hendrix.redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> <20121106235321.GC2813@hendrix.redhat.com> Message-ID: <509A8A4E.2050807@redhat.com> On 11/07/2012 12:53 AM, Jakub Hrozek wrote: > On Wed, Oct 31, 2012 at 01:22:52PM +0100, Martin Kosek wrote: >> On 10/31/2012 11:00 AM, Jakub Hrozek wrote: >>> On Mon, Oct 22, 2012 at 02:14:00PM -0400, Simo Sorce wrote: >>>> On Mon, 2012-10-22 at 17:15 +0200, Martin Kosek wrote: >>>>> On 10/08/2012 08:27 PM, Rob Crittenden wrote: >>>>>> Jakub Hrozek wrote: >>>>>>> On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: >>>>>>>> >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> the attached patches add the directory the SSSD writes domain-realm >>>>>>>>> mappings as includedir to krb5.conf when installing the client. >>>>>>>>> >>>>>>>>> [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for >>>>>>>>> options >>>>>>>>> ipachangeconf only allows one delimeter between keys and values. This >>>>>>>>> patch adds the possibility of also specifying "delim" in the option >>>>>>>>> dictionary to override the default delimeter. >>>>>>>>> >>>>>>>>> On a slightly-unrelated note, we really should think about adopting >>>>>>>>> Augeas. Changing configuration with home-grown scripts is getting >>>>>>>>> tricky. >>>>>>>>> >>>>>>>>> [PATCH 2/3] Specify includedir in krb5.conf on new installs >>>>>>>>> This patch utilizes the new functionality from the previous patch to >>>>>>>>> add >>>>>>>>> the includedir on top of the krb5.conf file >>>>>>>>> >>>>>>>>> [PATCH 3/3] Add the includedir to krb5.conf on upgrades >>>>>>>>> This patch is completely untested and I'm only posting it to get >>>>>>>>> opinions. At first I was going to use an upgrade script in %post but >>>>>>>>> then I thought it would be overengineering when all we want to do is >>>>>>>>> prepend one line.. Would a simple munging like this be acceptable or >>>>>>>>> shall I write a full script? >>>>>>>> >>>>>>>> NACK, using a scriptlet is fine, but not the way you did, as it has a huge >>>>>>>> race condition where krb5.conf exists and has only one line in it (the >>>>>>>> include line). >>>>>>>> >>>>>>>> You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew >>>>>>>> Then cat the contents of the existing file in i:t cat /etc/krb.conf >> >>>>>>>> /etc/krb.conf.ipanew >>>>>>>> And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf >>>>>>>> >>>>>>>> This method is also safe wrt something killing the yum process ... >>>>>>>> >>>>>>>> Simo. >>>>>>> >>>>>>> I'm attaching a new revision of the patches not even two months after >>>>>>> the original nack. >>>>>>> >>>>>>> I also think it might be nice to have a more general way of upgrading >>>>>>> the client config so I filed >>>>>>> https://fedorahosted.org/freeipa/ticket/3149 >>>>>> >>>>>> I don't think grepping for a string is an effective way to determine if the >>>>>> client has been configured. Someone could have removed that line. >>>>>> >>>>>> I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it exists >>>>>> and has more than 2 lines in it ([files] + one other file) then it is safe to >>>>>> say the client is configured, or at least partially configured. >>>>>> >>>>>> rob >>>>>> >>>>> >>>>> I just found one more issue. What if ipa-client-install is run with --no-sssd >>>>> option? In that case I assume we should not include the SSSD's krb5.include.d, >>>>> right? The same would also appy for upgrades, we would need to check if client >>>>> was actually configured with SSSD before mangling their krb5.conf. >>>> >>>> Yeah that's right, we should have all sssd related changes under a >>>> conditional that is true only when sssd is enabled. >>>> >>>> Simo. >>> >>> OK, new patches are attached. In new installs, the includedir is only >>> added when options.sssd is true. During upgrades, I checked for >>> sssd.conf's existence, I'm not sure if there's any other way to check if >>> the client was configured with sssd? >> >> Hello Jakub, thanks for these patches. I think that checking if /etc/sssd.conf >> exists as actually not so bad way to test if it was configured. Anyway, I did >> few tests on server and client but I still see few issues: >> >> 1) SELinux context of krb5.conf is not as expected (but I am not sure what real >> issue could that cause): >> >> # restorecon -FvvR /etc/krb5.conf >> restorecon reset /etc/krb5.conf context >> unconfined_u:object_r:etc_t:s0->system_u:object_r:krb5_conf_t:s0 >> > > Fixed. Thanks, I shouldn have noticed that doing mv would just replace > the original context. > >> 2) I can no longer kinit on IPA server after applying your patch >> # rpm -q sssd >> sssd-1.9.90-0.20121030T1436Zgitf46bf56.fc17.x86_64 >> # rpm -Uvh --force freeipa-*.rpm >> # head -n 5 /etc/krb5.conf >> includedir /var/lib/sss/pubconf/krb5.include.d/ >> [logging] >> default = FILE:/var/log/krb5libs.log >> kdc = FILE:/var/log/krb5kdc.log >> admin_server = FILE:/var/log/kadmind.log >> # KRB5_TRACE=/dev/stdout kinit admin >> [21059] 1351684052.658548: Getting initial credentials for >> admin at IDM.LAB.BOS.REDHAT.COM >> [21059] 1351684052.665269: Sending request (200 bytes) to IDM.LAB.BOS.REDHAT.COM >> [21059] 1351684052.665989: Resolving hostname vm-044.idm.lab.bos.redhat.com >> [21059] 1351684052.667511: Sending initial UDP request to dgram 10.16.78.44:88 >> [21059] 1351684052.672514: Received answer from dgram 10.16.78.44:88 >> [21059] 1351684052.672653: Response was from master KDC >> [21059] 1351684052.672751: Received error from KDC: -1765328370/KDC has no >> support for encryption type >> kinit: KDC has no support for encryption type while getting initial credentials >> >> >> Now when I comment includedir: >> # head -n 5 /etc/krb5.conf >> # kinit admin >> Password for admin at IDM.LAB.BOS.REDHAT.COM: >> # echo $? >> 0 >> >> When I upgraded client machine (without krb5kdc), kinit worked fine. Does that >> mean that krb5.conf can only be changed on client machines? >> > > I'm still looking into this. I'm not sure why kinit does that and why it > does that on the IPA server only. Unfortunately the default krb5 package > is so optimized that I need to rebuild one without optimizations. > >> 3) We should also add Requires on sssd >= 1.9.0 in FreeIPA spec file to pick up >> the new feature. Otherwise I just get an error on client: >> >> # kinit admin >> kinit: Included profile directory could not be read while initializing Kerberos >> 5 library >> > > Done > >> 4) (Optional) I think we can make the process of checking if IPA is configured >> easier and follow a similar way that Sumit did: >> https://fedorahosted.org/freeipa/changeset/fe66fbe637132ac5eb22eea388e2261f33497bf5/ >> >> This section: >> >> +restore=0 >> +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l >> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') >> + >> +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >> + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >> 2>/dev/null ; then >> >> could then be replaced by something like this: >> >> python -c "import sys; from ipapython import ipautil; sys.exit(0 if >> ipapython.is_ipaclient_configured() else 1);" > /dev/null 2>&1 >> if [ $? -eq 0 ]; then >> >> I am not saying you need to do this step, this can be done later by us. > > That code currently only exists for IPA server, right? At least judging > by: > from ipaserver.install import installutils; > > Then I would prefer to do it separately. It's a good idea, though, the > postscript as it is now is ugly. > Thanks for updated patch, now when I updated to the most recent sssd, kinit worked for me even though IPA master krb5.conf was updated. Few more issues I found follows: 1) I see a build error: # make rpms ... rpmbuild --define "_topdir /root/freeipa-master/rpmbuild" -ba freeipa.spec error: line 179: Bad Requireflags: qualifiers: Requires(postttrans): policycoreutils make: *** [rpms] Error 1 This is the reason: +Requires(postttrans): policycoreutils should be: +Requires(posttrans): policycoreutils 2) IPA server krb5.conf is not updated for clean server/replica installation. The includedir can get there only with next package update. install/share/krb5.conf.template would also need to be updated. Besides these 2 issues (and the SELinux ones), the patch should be good to go. Martin From dpal at redhat.com Wed Nov 7 16:30:57 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 Nov 2012 11:30:57 -0500 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509A8244.5000607@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> <509A8244.5000607@redhat.com> Message-ID: <509A8CC1.7020507@redhat.com> On 11/07/2012 10:46 AM, Petr Vobornik wrote: > We discussed some things on IRC. I wrote some comments below to allow > others to chime in. > > Adam also created a public etherpad where we wrote most of the issues > and possible solutions in some frameworks. I also wrote there short > reviews of various JavaScript frameworks. > > https://etherpad.openstack.org/webui-idm Good analyzes. But unfortunately I do not understand it well enough to provide an opinion or guidance. Let us step back and think about the goals. The UI works. It is not that it is broken. We have several requirements for it though. 1) Do not redo it but refactor as needed 2) Do not grow technical debt for long. If something really ugly and prevents us from adding new capabilities or creates a bad user experience let us fix it. 3) We need to solve the problem of plugins/extensible UI so that optional UI components can be dropped in. Untangling IPA specific things from common code is a nice goal but not a priority. With those requirements on the table what do you see is the best focused approach? > > On 11/01/2012 03:01 PM, Adam Young wrote: >> 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. > > I strongly disagree. > > First jquery is mostly DOM manipulation, AJAX and some effects > library. Other libraries can use it but there is no need to be build > upon it. None or soft dependency on jquery is much better. > >> >> We also wanted to make the Entity definition as declarative as possible, > > I don't want to change it. I like this approach even thought it brings > some problems. > >> and we didn't want to be driven by another developers view of M-V-C. I >> still feel this is most important. > > Do we or don't we? Endi wrote that you agreed that we need a better > framework? Should the framework fix only issues other than MVC or MVC > too? > > Most of the framework which might help us (persistance, structure) has > some view of MVC. My conclusion about them is at the end of the mail > and in the etherpad. > >> >> 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. > > IMO 'new' keyword usage is not bad if proper convention is used: all > functions which are supposed to be used as constructors must start > with capital letter. > >> >> >>>>>> >>>>>>> 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 Agree. > >> 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. > > Please elaborate. > > IMO fast load times are one of the things which makes admins happy. > I'm not convinced that admin needs to view the code. It's just nice to > have. Most of people won't debug the code. Most (maybe all) Web UI bug > reports contain just steps to reproduce, error message or screenshots. > I don't remember stack-trace or similar code-related report. >> >>>>>>> >>>>>>> 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). >> >> Just want to reiterate the power of being able to dop development >> withouth having to do a build. DO NOT MAKE A DELIBERATE BUILD STEP FOR >> JAVASCRIPT! > > Build is just for production. Development will remain build-less. > Currently I'm the person which does the most UI debugging so it's > natural that I don't want to make it harder for me :). > >>>>>>> >>>>>>> [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 builder isn't in the rpm. >>>>> >>>>> AFAIK the dojo rpm contains already built files. It has a core >>>>> dojo.js file which contains basic modules to work but the rest of >>>>> modules are separated. IDK if it can be used in a build process. I >>>>> have to test it. >>>>> >>>>>> >>>>>> There's also RequireJS (http://requirejs.org/). >>>>> >>>>> require.js is just AMD loader but it uses r.js as optimizer. r.js >>>>> seems more lightweight than dojo builder. I would stick with dojo >>>>> loader and builder if we use other dojo features. >>>>> >>>>>> >>>>>>> ### 2) Object store/model >>>>>>> At the beginning Web UI was quite simple - a command filled >>>>>>> widgets, >>>>>>> widgets got edited, update command was constructed from widgets, >>>>>>> it was >>>>>>> sent to server and at the end widgets were updated with new >>>>>>> values. >>>>>>> >>>>>>> Now various parts of displayed page (action lists, panels, status >>>>>>> widgets, facet header) needs to use loaded values too or influence >>>>>>> others. This issue was often discussed in patch reviews. As a >>>>>>> solution, >>>>>>> some model object with bidirectional binding capabilities would be >>>>>>> greatly beneficial. >>>>>>> >>>>>>> Dojo provides a extensible object store [1]. I would like to use >>>>>>> 'memory >>>>>>> store' and 'observable' and extend it with 'dirty-check' >>>>>>> capabilities. >>>>>>> >>>>>>> [1] >>>>>>> http://dojotoolkit.org/documentation/tutorials/1.8/intro_dojo_store/ >>>>>>> >>>>>> >>>>>> Backbone also has similar mechanisms for events and sync. >>>>>> >>>>>>> ### 3) Class model >>>>>>> Yes, in IPA Web UI we are using some class model, but it has flaws, >>>>>>> mainly in initialization of a object (some initialization code of >>>>>>> parent >>>>>>> class may be called before inheritance is finished). >>>>>>> >>>>>>> Dojo has a class system [1] which is easy to use and support >>>>>>> inheritance, mixins and overrided function calls. >>>>>>> >>>>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/declare/ >>>>>> >>>>>> At first glance Backbone seems to be better in this area, but Dojo >>>>>> might >>>>>> also be sufficient for our purposes. >>>>> >>>>> Backbone seems to have advantage in calling super class' constructor. >>>>> It is not recommended in Dojo. >>>>> >>>>>> >>>>>> There's going to be some challenges converting the current class >>>>>> framework. Like you said, the current initialization isn't well >>>>>> structured, so we might need to fix that first before converting the >>>>>> class framework. And then we use 'that' instead of 'this', and >>>>>> sometimes >>>>>> both, and they get confusing, so we'd have to be very careful when >>>>>> converting them. Also, the current way to call a method in super >>>>>> class >>>>>> needs to be fixed. >>>>> >>>>> We can come with some strategy to keep patch reviews simple. >>>>> IE: >>>>> * move initialization stuff to init method (or more fine-grained) and >>>>> use builder to create and instance (in some parts its already done), >>>>> this way we eliminate statements in class declaration (except method >>>>> declaration and overriding) >>>>> * change to the classes: change that to this/self(to keep context in >>>>> closures) >>>>> * eliminate method overrides with inherited() calls. >>>>> * put init calls to constructor >>>>> * change builder again >>>>> >>>>>> >>>>>>> ### 4) Localization >>>>>>> Web UI and pages in config, migrate and error folder are not >>>>>>> localized >>>>>>> until successful login. It's because Web UI gets localized >>>>>>> strings by >>>>>>> API call which needs prior authentication. We should use other >>>>>>> method to >>>>>>> provide localized config, error and login pages. >> The localization information is not necessarily accessable to the >> browser. The only thing we can depend on is that the server gets it, >> and then sends back the strings. That was the rationale for the current >> mechanism. >>>>>>> >>>>>>> Dojo has a easy to use localization solution [1]. Basically >>>>>>> strings are >>>>>>> defined in .js files as modules, translations in subfolders. Dojo >>>>>>> loader >>>>>>> and i18n framework take care of loading of proper string >>>>>>> depending on >>>>>>> user's local. It doesn't need communication with JSON-RPC so can be >>>>>>> used >>>>>>> in config and login pages. >>>>>>> >>>>>>> We would have to make a script to translate the format to a format >>>>>>> usable by transifex. >>>>>>> >>>>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/i18n/ >>>>>> >>>>>> A possible alternative is jquery-i18n-properties >>>>>> (http://code.google.com/p/jquery-i18n-properties/). >>>>>> >>>>>>> ### 5) Navigation >>>>>>> Our navigation code is limited to IPA entities. Introducing >>>>>>> non-entity >>>>>>> page like log (#3040) or help is problematic. Routing code >>>>>>> should be >>>>>>> improved. Separate entity initialization and menu definition. As >>>>>>> the >>>>>>> re-factoring will be at some point done, we might consider to use >>>>>>> dojo.router and dojo.hash instead of $.bbq. This is really >>>>>>> optional and >>>>>>> not strictly related to Dojo, but I wanted to mention it. >>>>>>> >>>>>>> Better handling of pkeys may fix `#2741 [ipa webui] Intermittent >>>>>>> errors >>>>>>> - 'cn' is required; limits exceeded for this query` >>>>>> >>>>>> Backbone also has router and history. >>>>>> >>>>>>> ### 6) Easier unit tests >>>>>>> By utilizing AMD modules, Localization, Model binding we might be >>>>>>> able >>>>>>> to write unit tests of widgets easier. Now we have to simulate >>>>>>> entity, >>>>>>> facets, fields, strings loaded from JSON-RPC... >>>>>> >>>>>> Yes, that would be great. >> I'd like better inversion of control in the JS code in general. But you >> don't need to move to Dojo to do that. As I recall, Dojo "wiring up" >> was about a 1/2 way solution (but it has been a long time since I >> looked) > > AMD is not IoC, but it share some ideas. The only framework with DI > (of the reviewed) is Angular.js. > >>>>>> >>>>>>> ### 7) Separation of framework and IPA >>>>>>> We often talk about separating Web UI framework and IPA related >>>>>>> stuff. >>>>>>> We can do it along with this refactoring. >>>>>>> https://fedorahosted.org/freeipa/ticket/3030 >>>>>> >>>>>> Yes, but it might need to be fixed separately. >>>>> >>>>> I don't want to this all stuff in one patch :). >>>>>> >>>>>>> What I don't want to do >>>>>>> ----------------------- >>>>>>> * rewrite whole UI, changes should be gradual >>>>>>> * replace jQuery. Most of our widgets are using jquery, I don't >>>>>>> want to >>>>>>> change this code, so I don't want to replace it with Dojo widget >>>>>>> system >>>>>>> - too big effort. So in the result the HTML output should not be >>>>>>> changed >>>>>>> much - not to affect automated tests. >>>>>>> >>>>>>> ### Steps how could be Dojo incorporated >>>>>>> It should be done gradually. >>>>>>> 1) make the build system working. Without it a lot of .js files >>>>>>> would be >>>>>>> transmitted to browser which is really bad. >>>>>> >>>>>> This is probably the easiest part. The next steps could be >>>>>> difficult to >>>>>> untangle. So be ready for a long haul. :) >>>>> >>>>> The harder part is not to populate git and rpm with a lot of >>>>> third-party stuff. We need to convince dojo builder to use uglify.js >>>>> under rhino to avoid using of closure compiler or shrink-safe which >>>>> are not and probably will not be bundled in fedora and RHEL and >>>>> definitely we don't want to bundle them. >>>>> >>>>> I'm thinking about making a script which would create WebUI-devoloper >>>>> enviroment: >>>>> * checkout dojo/dojo and dojo/util git repository to 1.8.1 tag >>>>> * create a symbolic links to the tag >>>>> * apply custom patches on dojo/util (there will definitely be one) >>>>> * include in FreeIPA git only builded dojo.js (in the case we have >>>>> separate files for dojo.js and freeipa.js (just a suggestion of >>>>> name)) >>>>> * will investigate if we can build the builder and include it in >>>>> git >>>>> for rpm builds. >>>>> >>>>> We can of course include into our git a whole 1.8.1 dojo/dojo and >>>>> dojo/util but I would rather avoid it because it's a LOT of files. >>>>> >>>>>> >>>>>>> 2) separate components to individual files and transform then into >>>>>>> AMD >>>>>>> modules. We might change namespaces and dependencies to separate >>>>>>> Web UI >>>>>>> framework and IPA related stuff. >>>>>>> 3) change class system of entities and facets >>>>>>> 4) implement a 'model' >>>>>>> ? >>>>>>> At this point it depends on priorities and new tickets with higher >>>>>>> priority may appear. >>>>>> >>>>> >>>>> >>>> Still sounds scary... What is the general recommendation? Are the >>>> arguments for or against Dojo convincing? >>>> >>> I proposed it, so the question is mainly for Endi or Adam, if he is >>> interested (added Cc). >>> >>> Just to add: >>> The question is whether we want to use third party code to solve some >>> issues or we want to write everything ourselves. Everything I wrote >>> above can be solved by us but it will probably take much more time. >>> Dojo itself won't fix our problems it just provides means to fix >>> them. As Enti wrote, for the problems we have, it can be replaced by >>> multiple libraries combined(require.js, r.js, backbone.js, >>> jquery-i18n-properties). >>> >>> I don't want to repeat myself much so adding just some dojo-related >>> pros and cons: >>> >>> Cons: >>> * third party code - we need to watch updates, sec issues >>> * more complex build of UI which eventually needs more unit tests >>> (basically I want some build with or without Dojo) >>> >>> Pros: >>> * third party code - don't have to reinvent the wheel >>> * establish library (good docs, some books were writen) >>> * using good modular structure, we can pick the parts we actually >>> want, when we want (loader, builder, class system, object store, >>> localization, modular system) >>> >> >> >> My take away is the a Framework is the right direction, but Dojo is not >> the right Framework. > Please elaborate. > >> I would look to see if someone has built the >> equivalent on top of JQuery. If not, pull in the various pieces from >> JQuery based projects and move forward with that. > I disagree. As I said jquery is good at what it does. Problems we want > to solve don't have anything to do with jquery. JQ is functional > library which calls usually bind to some page element. That is not > desired when dealing with architectural problems. Various plugins > might also have problems with long-term support. > >> I think you are right >> to focus on unit tests and modularity. But I think at this point, you >> would be better off with an incremental approach. > > I still think Dojo is the best fit for us. > > Conclusion from comparing various frameworks (narrowed to Ember.js, > AngularJS, backbone.js, JavaScriptMVC, Dojo): > If we don't want to adopt other view of MVC we can ditch Ember.js, > JavaScriptMVC and Angular JS, without their MVC there is no point to > use them. If we would re-write the UI from scratch, which we don't > want to, I would probably choose Ember.js because it uses nice > structured way and has view composition, we would loose our > declarative approach though. > We are left with backbone and dojo. Backbone is very lightweight, it > can't do anything more than classes, events, router, views and model > (REST persistence). All of it and *more* can be done with Dojo. Its > MVC approach is very similar to ours. Model implementation is not only > REST which is good for us as we use JSON-RPC. Because it's completely > AMD, we can build a custom dojo build with only the components we care > about. > > Modularity: > I think we agreed on that we want to change UI to AMD modules. It > basically means we go with Dojo + uglify.js or we choose require.js, > r.js, uglify.js and some other library to solve non-module stuff. > -- 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 Nov 7 16:46:18 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Nov 2012 17:46:18 +0100 Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <1347679228.6583986.1352300921252.JavaMail.root@redhat.com> References: <1347679228.6583986.1352300921252.JavaMail.root@redhat.com> Message-ID: <509A905A.2000102@redhat.com> On 11/07/2012 04:08 PM, Lynn Root wrote: > Third time is a charm? > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Jan Cholasta" > To: "Lynn Root" > Cc: freeipa-devel at redhat.com > Sent: Monday, November 5, 2012 10:25:32 AM > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors > > On 5.11.2012 09:43, Lynn Root wrote: >> Here's try #2! Adjusted patch attached. Let me know if there's anything else I've missed. >> >> Switched %r specifiers to '%s' in Public errors, and adjusted tests to expect no preceding 'u'. >> >> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & https://fedorahosted.org/freeipa/ticket/2588 >> >> Lynn Root >> Associate Software Engineer >> Red Hat >> >> ----- Original Message ----- >> From: "Martin Kosek" >> To: "Jan Cholasta" >> Cc: "Lynn Root" , freeipa-devel at redhat.com >> Sent: Tuesday, October 30, 2012 9:08:33 AM >> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors >> >> On 10/30/2012 09:04 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 29.10.2012 19:54, Lynn Root wrote: >>>> Hi all! >>>> >>>> This switch drops the preceding 'u' from strings in public error messages. >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>>> >>>> This patch also addresses the unfriendly 'u' from re-raising errors from the >>>> external call to netaddr.IPAddress by passing a bytestring to the function. >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>>> >>>> >>>> My first patch (and freeipa dev list email) ever! Let me know where there's >>>> room to improve. >>>> >>>> Lynn Root >>>> Associate Software Engineer >>>> Red Hat >>>> >>> >>> I think it would be nice if you kept the quotes around the values, as that is >>> probably the reason "%r" was used in the first place - i.e. use "'%s'" instead >>> of plain "%s". >> >> +1 >> >> With current patch, I assume that a lot of unit tests will fail as they check >> exact error message wording. I'd recommend running the whole test suite with >> your second patch revision. There is a short walkthrough how to set it up: >> >> http://freeipa.org/page/Testing >> >> Martin >> > > You missed a few: > > $ git grep -En '%(\(.*?\))?r' > > Honza > I think this revised patch is pretty much ready. I will just wait if someone other see some issue. We will need to wait until a post 3.1 release cycle before we can push this one anyway. Martin From sbose at redhat.com Wed Nov 7 16:48:33 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 7 Nov 2012 17:48:33 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <509A67F0.9030907@redhat.com> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> <20121102205000.GM10066@localhost.localdomain> <5097AEA9.8000906@redhat.com> <20121107125458.GE2195@localhost.localdomain> <509A5C32.9080207@redhat.com> <509A67F0.9030907@redhat.com> Message-ID: <20121107164833.GG2195@localhost.localdomain> On Wed, Nov 07, 2012 at 07:23:52PM +0530, Steeve Goveas wrote: > On 11/07/2012 06:33 PM, Martin Kosek wrote: > >On 11/07/2012 01:54 PM, Sumit Bose wrote: > >>On Mon, Nov 05, 2012 at 01:18:49PM +0100, Martin Kosek wrote: > >>>On 11/02/2012 09:50 PM, Sumit Bose wrote: > >>>>On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: > >>>>>On 11/02/2012 12:54 PM, Sumit Bose wrote: > >>>>>>On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: > >>>>>>>On 10/30/2012 12:16 PM, Sumit Bose wrote: > >>>>>>>>Hi, > >>>>>>>> > >>>>>>>>this patch allows ipa-adtrust-install to reset the NetBIOS domain name > >>>>>>>>and fixes https://fedorahosted.org/freeipa/ticket/3192 . > >>>>>>>> > >>>>>>>>bye, > >>>>>>>>Sumit > >>>>>>>> > >>>>>>> > >>>>>>>Hello Sumit, > >>>>>>> > >>>>>>>I found few issues with your patch: > >>>>>>Thank you for the review. > >>>>>> > >>>>>>>1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not > >>>>>>>think this is necessary, ipa-adtrust-install already requires admin password to > >>>>>>>be passed and it already connects to LDAP with these credentials: > >>>>>>> > >>>>>>>api.Backend.ldap2.connect(ccache.name) > >>>>>>> > >>>>>>>You could use ipa.Backend.ldap2 object to do entry retrieval > >>>>>>>(ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. > >>>>>>fixed > >>>>>> > >>>>>>>2) When doing try..except statement, rule of thumb says that it should be as > >>>>>>>short as possible, so that it does not hide other potential errors and makes > >>>>>>>clear what function raises the catched exception. > >>>>>>> > >>>>>>>In your case: > >>>>>>> > >>>>>>>try: > >>>>>>> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), > >>>>>>> api.env.container_cifsdomains, > >>>>>>> self.api.env.basedn), > >>>>>>> ['ipantflatname']) > >>>>>>>except errors.NotFound: > >>>>>>> reset_netbios_name = False > >>>>>>>else: > >>>>>>> # process entry > >>>>>>> > >>>>>>>Should be a pattern that you want. > >>>>>>fixed > >>>>>> > >>>>>>I also move all the NetBIOS name related code into a separate function. > >>>>>>>3) I think this line is redundant: > >>>>>>>+ print "Say 'yes' if the NetBIOS shall be changed and " \ > >>>>>>>+ "'no' if the old one shall be kept." > >>>>>>> > >>>>>>>IMO, the question: > >>>>>>> > >>>>>>>reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default > >>>>>>>= False, allow_empty = False) > >>>>>>> > >>>>>>>and the information printed before is enough. > >>>>>>I would prefer to keep it this way to make clear that > >>>>>>ipa-adtrust-install will continue processing, but the old name if kept > >>>>>>even if a new name was given with --netbios-name on the command line. > >>>>>> > >>>>>>New version attached. > >>>>>> > >>>>>>bye, > >>>>>>Sumit > >>>>>> > >>>>>>>Martin > >>>>> > >>>>>The new approach looks much better. Sending issues I found with the new patch: > >>>>> > >>>>>1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS > >>>>>name interactively. I can only change it via script option... > >>>>> > >>>>fixed > >>>> > >>>>>2) I saw few typos: > >>>>> > >>>>>+ print "Current NetBIOS domain name is %s new name is %s.\n" % \ > >>>>>should be: > >>>>>+ print "Current NetBIOS domain name is %s, new name is %s.\n" % \ > >>>>> > >>>>>+ print "NetBIOS domain name will be changes to %s.\n" % \ > >>>>>should be: > >>>>>+ print "NetBIOS domain name will be changed to %s.\n" % \ > >>>>> > >>>>> > >>>>fixed > >>>> > >>>>new version attached. > >>>> > >>>>bye, > >>>>Sumit > >>>>>Martin > >>>NetBIOS name is now asked when first installing ipa-adtrust-install. > >>> > >>>But I see that NetBIOS name is still not queried when I run re-install of > >>>ADTRUST, I can only change current name via option. Is this is an intended > >>>behavior so that people cannot mess it with by mistake? > >>Yes. The old code didn't check if the NetBIOS name was already set in > >>LDAP or not, hence it always asked the user if the generated NetBIOS > >>name is the one the user expected. > >> > >>The new version looks up the NetBIOS name in the LDAP server and if set > >>and no new name is given on the command line assumes that the admin > >>does not want to change the NetBIOS name and skips the dialog. > >> > >>I'll add the QE team to hear what they prefer. > >> > >>Jenny, Scott, Steeve, assume ipa-adtrust-install is run after trust was > >>already configured and no --netbios-name option is given on the command > >>line. Shall the following dialog be shown: > >> > >>..... > >>Enter the NetBIOS name for the IPA domain. > >>Only up to 15 uppercase ASCII letters and digits are allowed. > >>Example: EXAMPLE. > >> > >> > >>NetBIOS domain name [IPA17]: > >>.... > >> > >>The admin then has to press enter to confirm the current NetBIOS name or > >>can enter a new one. Or shall the dialog be skipped which means that the > >>NetBIOS can only be resetted if a new one is given at the command line > >>with the --netbios-name option? > >Ok, thanks from explanation. But from my devel perspective, since a change of > >NetBIOS domain name can break existing trusts I would rather not offer a change > >of NetBIOS name during interactive prompt. A mere stating of a current value > >with asking to user to change it should be enough. > > > >QE input is welcome, yes. > > > >Martin > > > If changing the netbios name post creating trust would break > existing trust, then I dont think that changing the netbios named > should be allowed. A clear message to drop the trust and re-add it > would be better. With the current patch you already get a warning when your are about to change the NetBIOS name: .... Current NetBIOS domain name is IPA17, new name is ABC. Please note that changing the NetBIOS name might break existing trust relationships. Say 'yes' if the NetBIOS shall be changed and 'no' if the old one shall be kept. Do you want to reset the NetBIOS domain name? [no]: .... So the admin can still change his mind. I think a description of what you should considered when you really want to change the NetBIOS domain name should go into the docs and not printed by ipa-adtrust-install. As mentioned earlier changing the NetBIOS domain name should be seen as the last resort and should be done with great care. bye, Sumit > > -Steeve > >>Thank you for your input. > >> > >>bye, > >>Sumit > >> > >>># ipa-adtrust-install > >>> > >>>The log file for this installation can be found in /var/log/ipaserver-install.log > >>>============================================================================== > >>>This program will setup components needed to establish trust to AD domains for > >>>the FreeIPA Server. > >>> > >>>This includes: > >>> * Configure Samba > >>> * Add trust related objects to FreeIPA LDAP server > >>> > >>>To accept the default shown in brackets, press the Enter key. > >>> > >>>IPA generated smb.conf detected. > >>>Overwrite smb.conf? [no]: y > >>> > >>>The following operations may take some minutes to complete. > >>>Please wait until the prompt is returned. > >>> > >>><<< no NetBIOS name asked interactively > >>> > >>>Configuring cross-realm trusts for IPA server requires password for user 'admin'. > >>>This user is a regular system account used for IPA server administration. > >>> > >>>admin password: > >>> > >>>Configuring CIFS > >>> [1/18]: stopping smbd > >>>... > >>> > >>> > >>>Otherwise the patch looks OK. > >>> > >>>Martin > From ayoung at redhat.com Wed Nov 7 17:28:40 2012 From: ayoung at redhat.com (Adam Young) Date: Wed, 07 Nov 2012 12:28:40 -0500 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509A8244.5000607@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> <509A8244.5000607@redhat.com> Message-ID: <509A9A48.5090306@redhat.com> Looks like Dojo has a lot to recommend it. On 11/07/2012 10:46 AM, Petr Vobornik wrote: > We discussed some things on IRC. I wrote some comments below to allow > others to chime in. > > Adam also created a public etherpad where we wrote most of the issues > and possible solutions in some frameworks. I also wrote there short > reviews of various JavaScript frameworks. > > https://etherpad.openstack.org/webui-idm > > On 11/01/2012 03:01 PM, Adam Young wrote: >> 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. > > I strongly disagree. > > First jquery is mostly DOM manipulation, AJAX and some effects > library. Other libraries can use it but there is no need to be build > upon it. None or soft dependency on jquery is much better. I think you will find that all of the libraries need to do DOM manipulation. I think JQuery is now the standard, and I would not want to have to learn a different way to do that. But if the JQuery code can co-exist with the Dojo code cleanly, and not mess up new developers, I'll withdraw this objection. > >> >> We also wanted to make the Entity definition as declarative as possible, > > I don't want to change it. I like this approach even thought it brings > some problems. > >> and we didn't want to be driven by another developers view of M-V-C. I >> still feel this is most important. > > Do we or don't we? Endi wrote that you agreed that we need a better > framework? Should the framework fix only issues other than MVC or MVC > too? > > Most of the framework which might help us (persistance, structure) has > some view of MVC. My conclusion about them is at the end of the mail > and in the etherpad. i like your conclusions. I need to understand ember.js a little better to fully concur. > >> >> 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. > > IMO 'new' keyword usage is not bad if proper convention is used: all > functions which are supposed to be used as constructors must start > with capital letter. Yeah. I think that the mechanism we designed rules out using Prototype inheritance, and there was at least once while coding where I thought it would make sense to use Prototype and couldn't. You have to admit, it is kindof a weird way to make objects. > >> >> >>>>>> >>>>>>> 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 Agree. > >> 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. > > Please elaborate. > > IMO fast load times are one of the things which makes admins happy. > I'm not convinced that admin needs to view the code. It's just nice to > have. Most of people won't debug the code. Most (maybe all) Web UI bug > reports contain just steps to reproduce, error message or screenshots. > I don't remember stack-trace or similar code-related report. I think this will change once the project catches on, and someone decided to actually contribute to the UI code base, but so long as you can map one to the other, and build stage doesn't introduce a slew of new issues, it probably is fine to optimize. I just don;t consider it a priority. For a single page app, load time is a one time cost. >> >>>>>>> >>>>>>> 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). >> >> Just want to reiterate the power of being able to dop development >> withouth having to do a build. DO NOT MAKE A DELIBERATE BUILD STEP FOR >> JAVASCRIPT! > > Build is just for production. Development will remain build-less. > Currently I'm the person which does the most UI debugging so it's > natural that I don't want to make it harder for me :). Yep. I know that feeling. > >>>>>>> >>>>>>> [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 builder isn't in the rpm. >>>>> >>>>> AFAIK the dojo rpm contains already built files. It has a core >>>>> dojo.js file which contains basic modules to work but the rest of >>>>> modules are separated. IDK if it can be used in a build process. I >>>>> have to test it. >>>>> >>>>>> >>>>>> There's also RequireJS (http://requirejs.org/). >>>>> >>>>> require.js is just AMD loader but it uses r.js as optimizer. r.js >>>>> seems more lightweight than dojo builder. I would stick with dojo >>>>> loader and builder if we use other dojo features. >>>>> >>>>>> >>>>>>> ### 2) Object store/model >>>>>>> At the beginning Web UI was quite simple - a command filled >>>>>>> widgets, >>>>>>> widgets got edited, update command was constructed from widgets, >>>>>>> it was >>>>>>> sent to server and at the end widgets were updated with new >>>>>>> values. >>>>>>> >>>>>>> Now various parts of displayed page (action lists, panels, status >>>>>>> widgets, facet header) needs to use loaded values too or influence >>>>>>> others. This issue was often discussed in patch reviews. As a >>>>>>> solution, >>>>>>> some model object with bidirectional binding capabilities would be >>>>>>> greatly beneficial. >>>>>>> >>>>>>> Dojo provides a extensible object store [1]. I would like to use >>>>>>> 'memory >>>>>>> store' and 'observable' and extend it with 'dirty-check' >>>>>>> capabilities. >>>>>>> >>>>>>> [1] >>>>>>> http://dojotoolkit.org/documentation/tutorials/1.8/intro_dojo_store/ >>>>>>> >>>>>> >>>>>> Backbone also has similar mechanisms for events and sync. >>>>>> >>>>>>> ### 3) Class model >>>>>>> Yes, in IPA Web UI we are using some class model, but it has flaws, >>>>>>> mainly in initialization of a object (some initialization code of >>>>>>> parent >>>>>>> class may be called before inheritance is finished). >>>>>>> >>>>>>> Dojo has a class system [1] which is easy to use and support >>>>>>> inheritance, mixins and overrided function calls. >>>>>>> >>>>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/declare/ >>>>>> >>>>>> At first glance Backbone seems to be better in this area, but Dojo >>>>>> might >>>>>> also be sufficient for our purposes. >>>>> >>>>> Backbone seems to have advantage in calling super class' constructor. >>>>> It is not recommended in Dojo. >>>>> >>>>>> >>>>>> There's going to be some challenges converting the current class >>>>>> framework. Like you said, the current initialization isn't well >>>>>> structured, so we might need to fix that first before converting the >>>>>> class framework. And then we use 'that' instead of 'this', and >>>>>> sometimes >>>>>> both, and they get confusing, so we'd have to be very careful when >>>>>> converting them. Also, the current way to call a method in super >>>>>> class >>>>>> needs to be fixed. >>>>> >>>>> We can come with some strategy to keep patch reviews simple. >>>>> IE: >>>>> * move initialization stuff to init method (or more fine-grained) and >>>>> use builder to create and instance (in some parts its already done), >>>>> this way we eliminate statements in class declaration (except method >>>>> declaration and overriding) >>>>> * change to the classes: change that to this/self(to keep context in >>>>> closures) >>>>> * eliminate method overrides with inherited() calls. >>>>> * put init calls to constructor >>>>> * change builder again >>>>> >>>>>> >>>>>>> ### 4) Localization >>>>>>> Web UI and pages in config, migrate and error folder are not >>>>>>> localized >>>>>>> until successful login. It's because Web UI gets localized >>>>>>> strings by >>>>>>> API call which needs prior authentication. We should use other >>>>>>> method to >>>>>>> provide localized config, error and login pages. >> The localization information is not necessarily accessable to the >> browser. The only thing we can depend on is that the server gets it, >> and then sends back the strings. That was the rationale for the current >> mechanism. >>>>>>> >>>>>>> Dojo has a easy to use localization solution [1]. Basically >>>>>>> strings are >>>>>>> defined in .js files as modules, translations in subfolders. Dojo >>>>>>> loader >>>>>>> and i18n framework take care of loading of proper string >>>>>>> depending on >>>>>>> user's local. It doesn't need communication with JSON-RPC so can be >>>>>>> used >>>>>>> in config and login pages. >>>>>>> >>>>>>> We would have to make a script to translate the format to a format >>>>>>> usable by transifex. >>>>>>> >>>>>>> [1] http://dojotoolkit.org/documentation/tutorials/1.8/i18n/ >>>>>> >>>>>> A possible alternative is jquery-i18n-properties >>>>>> (http://code.google.com/p/jquery-i18n-properties/). >>>>>> >>>>>>> ### 5) Navigation >>>>>>> Our navigation code is limited to IPA entities. Introducing >>>>>>> non-entity >>>>>>> page like log (#3040) or help is problematic. Routing code >>>>>>> should be >>>>>>> improved. Separate entity initialization and menu definition. As >>>>>>> the >>>>>>> re-factoring will be at some point done, we might consider to use >>>>>>> dojo.router and dojo.hash instead of $.bbq. This is really >>>>>>> optional and >>>>>>> not strictly related to Dojo, but I wanted to mention it. >>>>>>> >>>>>>> Better handling of pkeys may fix `#2741 [ipa webui] Intermittent >>>>>>> errors >>>>>>> - 'cn' is required; limits exceeded for this query` >>>>>> >>>>>> Backbone also has router and history. >>>>>> >>>>>>> ### 6) Easier unit tests >>>>>>> By utilizing AMD modules, Localization, Model binding we might be >>>>>>> able >>>>>>> to write unit tests of widgets easier. Now we have to simulate >>>>>>> entity, >>>>>>> facets, fields, strings loaded from JSON-RPC... >>>>>> >>>>>> Yes, that would be great. >> I'd like better inversion of control in the JS code in general. But you >> don't need to move to Dojo to do that. As I recall, Dojo "wiring up" >> was about a 1/2 way solution (but it has been a long time since I >> looked) > > AMD is not IoC, but it share some ideas. The only framework with DI > (of the reviewed) is Angular.js. > >>>>>> >>>>>>> ### 7) Separation of framework and IPA >>>>>>> We often talk about separating Web UI framework and IPA related >>>>>>> stuff. >>>>>>> We can do it along with this refactoring. >>>>>>> https://fedorahosted.org/freeipa/ticket/3030 >>>>>> >>>>>> Yes, but it might need to be fixed separately. >>>>> >>>>> I don't want to this all stuff in one patch :). >>>>>> >>>>>>> What I don't want to do >>>>>>> ----------------------- >>>>>>> * rewrite whole UI, changes should be gradual >>>>>>> * replace jQuery. Most of our widgets are using jquery, I don't >>>>>>> want to >>>>>>> change this code, so I don't want to replace it with Dojo widget >>>>>>> system >>>>>>> - too big effort. So in the result the HTML output should not be >>>>>>> changed >>>>>>> much - not to affect automated tests. >>>>>>> >>>>>>> ### Steps how could be Dojo incorporated >>>>>>> It should be done gradually. >>>>>>> 1) make the build system working. Without it a lot of .js files >>>>>>> would be >>>>>>> transmitted to browser which is really bad. >>>>>> >>>>>> This is probably the easiest part. The next steps could be >>>>>> difficult to >>>>>> untangle. So be ready for a long haul. :) >>>>> >>>>> The harder part is not to populate git and rpm with a lot of >>>>> third-party stuff. We need to convince dojo builder to use uglify.js >>>>> under rhino to avoid using of closure compiler or shrink-safe which >>>>> are not and probably will not be bundled in fedora and RHEL and >>>>> definitely we don't want to bundle them. >>>>> >>>>> I'm thinking about making a script which would create WebUI-devoloper >>>>> enviroment: >>>>> * checkout dojo/dojo and dojo/util git repository to 1.8.1 tag >>>>> * create a symbolic links to the tag >>>>> * apply custom patches on dojo/util (there will definitely be one) >>>>> * include in FreeIPA git only builded dojo.js (in the case we have >>>>> separate files for dojo.js and freeipa.js (just a suggestion of >>>>> name)) >>>>> * will investigate if we can build the builder and include it in >>>>> git >>>>> for rpm builds. >>>>> >>>>> We can of course include into our git a whole 1.8.1 dojo/dojo and >>>>> dojo/util but I would rather avoid it because it's a LOT of files. >>>>> >>>>>> >>>>>>> 2) separate components to individual files and transform then into >>>>>>> AMD >>>>>>> modules. We might change namespaces and dependencies to separate >>>>>>> Web UI >>>>>>> framework and IPA related stuff. >>>>>>> 3) change class system of entities and facets >>>>>>> 4) implement a 'model' >>>>>>> ? >>>>>>> At this point it depends on priorities and new tickets with higher >>>>>>> priority may appear. >>>>>> >>>>> >>>>> >>>> Still sounds scary... What is the general recommendation? Are the >>>> arguments for or against Dojo convincing? >>>> >>> I proposed it, so the question is mainly for Endi or Adam, if he is >>> interested (added Cc). >>> >>> Just to add: >>> The question is whether we want to use third party code to solve some >>> issues or we want to write everything ourselves. Everything I wrote >>> above can be solved by us but it will probably take much more time. >>> Dojo itself won't fix our problems it just provides means to fix >>> them. As Enti wrote, for the problems we have, it can be replaced by >>> multiple libraries combined(require.js, r.js, backbone.js, >>> jquery-i18n-properties). >>> >>> I don't want to repeat myself much so adding just some dojo-related >>> pros and cons: >>> >>> Cons: >>> * third party code - we need to watch updates, sec issues >>> * more complex build of UI which eventually needs more unit tests >>> (basically I want some build with or without Dojo) >>> >>> Pros: >>> * third party code - don't have to reinvent the wheel >>> * establish library (good docs, some books were writen) >>> * using good modular structure, we can pick the parts we actually >>> want, when we want (loader, builder, class system, object store, >>> localization, modular system) >>> >> >> >> My take away is the a Framework is the right direction, but Dojo is not >> the right Framework. > Please elaborate. > >> I would look to see if someone has built the >> equivalent on top of JQuery. If not, pull in the various pieces from >> JQuery based projects and move forward with that. > I disagree. As I said jquery is good at what it does. Problems we want > to solve don't have anything to do with jquery. JQ is functional > library which calls usually bind to some page element. That is not > desired when dealing with architectural problems. Various plugins > might also have problems with long-term support. > >> I think you are right >> to focus on unit tests and modularity. But I think at this point, you >> would be better off with an incremental approach. > > I still think Dojo is the best fit for us. You've done your homeowork. I can't fault your conclusions. Just make sure you are prepared to deal with the RPM dependencies when you implement. > > Conclusion from comparing various frameworks (narrowed to Ember.js, > AngularJS, backbone.js, JavaScriptMVC, Dojo): > If we don't want to adopt other view of MVC we can ditch Ember.js, > JavaScriptMVC and Angular JS, without their MVC there is no point to > use them. If we would re-write the UI from scratch, which we don't > want to, I would probably choose Ember.js because it uses nice > structured way and has view composition, we would loose our > declarative approach though. > We are left with backbone and dojo. Backbone is very lightweight, it > can't do anything more than classes, events, router, views and model > (REST persistence). All of it and *more* can be done with Dojo. Its > MVC approach is very similar to ours. Model implementation is not only > REST which is good for us as we use JSON-RPC. Because it's completely > AMD, we can build a custom dojo build with only the components we care > about. > > Modularity: > I think we agreed on that we want to change UI to AMD modules. It > basically means we go with Dojo + uglify.js or we choose require.js, > r.js, uglify.js and some other library to solve non-module stuff. > From jcholast at redhat.com Wed Nov 7 17:46:05 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 07 Nov 2012 18:46:05 +0100 Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <1347679228.6583986.1352300921252.JavaMail.root@redhat.com> References: <1347679228.6583986.1352300921252.JavaMail.root@redhat.com> Message-ID: <509A9E5D.6070904@redhat.com> On 7.11.2012 16:08, Lynn Root wrote: > Third time is a charm? > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Jan Cholasta" > To: "Lynn Root" > Cc: freeipa-devel at redhat.com > Sent: Monday, November 5, 2012 10:25:32 AM > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors > > On 5.11.2012 09:43, Lynn Root wrote: >> Here's try #2! Adjusted patch attached. Let me know if there's anything else I've missed. >> >> Switched %r specifiers to '%s' in Public errors, and adjusted tests to expect no preceding 'u'. >> >> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & https://fedorahosted.org/freeipa/ticket/2588 >> >> Lynn Root >> Associate Software Engineer >> Red Hat >> >> ----- Original Message ----- >> From: "Martin Kosek" >> To: "Jan Cholasta" >> Cc: "Lynn Root" , freeipa-devel at redhat.com >> Sent: Tuesday, October 30, 2012 9:08:33 AM >> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors >> >> On 10/30/2012 09:04 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 29.10.2012 19:54, Lynn Root wrote: >>>> Hi all! >>>> >>>> This switch drops the preceding 'u' from strings in public error messages. >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>>> >>>> This patch also addresses the unfriendly 'u' from re-raising errors from the >>>> external call to netaddr.IPAddress by passing a bytestring to the function. >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>>> >>>> >>>> My first patch (and freeipa dev list email) ever! Let me know where there's >>>> room to improve. >>>> >>>> Lynn Root >>>> Associate Software Engineer >>>> Red Hat >>>> >>> >>> I think it would be nice if you kept the quotes around the values, as that is >>> probably the reason "%r" was used in the first place - i.e. use "'%s'" instead >>> of plain "%s". >> >> +1 >> >> With current patch, I assume that a lot of unit tests will fail as they check >> exact error message wording. I'd recommend running the whole test suite with >> your second patch revision. There is a short walkthrough how to set it up: >> >> http://freeipa.org/page/Testing >> >> Martin >> > > You missed a few: > > $ git grep -En '%(\(.*?\))?r' > > Honza > I think you have gone too far this time :-) It is not necessary (or wise) to get rid of %r *everywhere* in the code. A few rules to keep in mind: * If it is not an error message, do not touch it (log messages are not error messages BTW). * If it is an error message for an exception that does not inherit from errors.PublicError, do not touch it (there might be a few exceptions, though). * Use '%s' (%s with ticks) only for arguments whose value can be only str or unicode. Honza -- Jan Cholasta From pvoborni at redhat.com Wed Nov 7 18:16:40 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Nov 2012 19:16:40 +0100 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509A8CC1.7020507@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> <509A8244.5000607@redhat.com> <509A8CC1.7020507@redhat.com> Message-ID: <509AA588.1030006@redhat.com> On 11/07/2012 05:30 PM, Dmitri Pal wrote: > On 11/07/2012 10:46 AM, Petr Vobornik wrote: >> We discussed some things on IRC. I wrote some comments below to allow >> others to chime in. >> >> Adam also created a public etherpad where we wrote most of the issues >> and possible solutions in some frameworks. I also wrote there short >> reviews of various JavaScript frameworks. >> >> https://etherpad.openstack.org/webui-idm > > > Good analyzes. But unfortunately I do not understand it well enough to > provide an opinion or guidance. > Let us step back and think about the goals. > > The UI works. It is not that it is broken. > We have several requirements for it though. > > 1) Do not redo it but refactor as needed > 2) Do not grow technical debt for long. If something really ugly and > prevents us from adding new capabilities or creates a bad user > experience let us fix it. > 3) We need to solve the problem of plugins/extensible UI so that > optional UI components can be dropped in. > > Untangling IPA specific things from common code is a nice goal but not a > priority. > With those requirements on the table what do you see is the best focused > approach? Sorted by priority: 1) Improve navigation extensibility (#3236), introduce a loader (dojo/require.js/custom) and extension registration (to know what to load) (#3235). These should solve requirement #3. 2) Refactor/introduce better model(persistance). IMO biggest technical debt. For this task I want to borrow a component from Dojo. It will make developing of enhancements and additional refactoring easier. 3) Along with 1) and 2) we can do additional refactoring of navigation. which will fix some ugly intermittent errors (#2741). 4) Optimize startup. Not a big task, IMO possibly very appreciated enhancement by admins. Tickets: #2678, #2679, #112 5) I would really want to introduce AMD modules. Requires AMD loader (dojo/require.js) and a build tool (dojo/r.js) It should: * make dependencies more clear * easier development of third-party enhancements * the build helps with 4) * build will allow us to comment more so it might help new developers * it's side effect is partial untangling of IPA specific things from common code * better to do it sooner to avoid breaking of third party extensions. It's not a necessity but it should be worth the effort long-term. 6) Adopt different class system (from dojo or backbone.js) - fix issues in object initialization. * very time-consuming task * should be adopted gradually I've also considered to write a module with methods used by extension developers to extend existing pages easily - add one or two fields without studying the whole codebase. Something like add_field_after(new_field, entity, facet, section, after_field) or add_field(field, spec). Might be appreciated. -- Petr Vobornik From dpal at redhat.com Wed Nov 7 20:15:58 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 07 Nov 2012 15:15:58 -0500 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509AA588.1030006@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> <509A8244.5000607@redhat.com> <509A8CC1.7020507@redhat.com> <509AA588.1030006@redhat.com> Message-ID: <509AC17E.5090208@redhat.com> On 11/07/2012 01:16 PM, Petr Vobornik wrote: > On 11/07/2012 05:30 PM, Dmitri Pal wrote: >> On 11/07/2012 10:46 AM, Petr Vobornik wrote: >>> We discussed some things on IRC. I wrote some comments below to allow >>> others to chime in. >>> >>> Adam also created a public etherpad where we wrote most of the issues >>> and possible solutions in some frameworks. I also wrote there short >>> reviews of various JavaScript frameworks. >>> >>> https://etherpad.openstack.org/webui-idm >> >> >> Good analyzes. But unfortunately I do not understand it well enough to >> provide an opinion or guidance. >> Let us step back and think about the goals. >> >> The UI works. It is not that it is broken. >> We have several requirements for it though. >> >> 1) Do not redo it but refactor as needed >> 2) Do not grow technical debt for long. If something really ugly and >> prevents us from adding new capabilities or creates a bad user >> experience let us fix it. >> 3) We need to solve the problem of plugins/extensible UI so that >> optional UI components can be dropped in. >> >> Untangling IPA specific things from common code is a nice goal but not a >> priority. >> With those requirements on the table what do you see is the best focused >> approach? > > Sorted by priority: > 1) Improve navigation extensibility (#3236), introduce a loader > (dojo/require.js/custom) and extension registration (to know what to > load) (#3235). These should solve requirement #3. > > 2) Refactor/introduce better model(persistance). IMO biggest technical > debt. For this task I want to borrow a component from Dojo. It will > make developing of enhancements and additional refactoring easier. > > 3) Along with 1) and 2) we can do additional refactoring of > navigation. which will fix some ugly intermittent errors (#2741). > > 4) Optimize startup. Not a big task, IMO possibly very appreciated > enhancement by admins. Tickets: #2678, #2679, #112 > > 5) I would really want to introduce AMD modules. Requires AMD loader > (dojo/require.js) and a build tool (dojo/r.js) It should: > * make dependencies more clear > * easier development of third-party enhancements > * the build helps with 4) > * build will allow us to comment more so it might help new developers > * it's side effect is partial untangling of IPA specific things > from common code > * better to do it sooner to avoid breaking of third party extensions. > > It's not a necessity but it should be worth the effort long-term. > > 6) Adopt different class system (from dojo or backbone.js) - fix > issues in object initialization. > * very time-consuming task > * should be adopted gradually > > > I've also considered to write a module with methods used by extension > developers to extend existing pages easily - add one or two fields > without studying the whole codebase. Something like > add_field_after(new_field, entity, facet, section, after_field) or > add_field(field, spec). Might be appreciated. > Does it make sense to everybody else besides me? If yes let us agree with the plan. -- 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 Wed Nov 7 20:31:07 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 Nov 2012 15:31:07 -0500 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509AC17E.5090208@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> <509A8244.5000607@redhat.com> <509A8CC1.7020507@redhat.com> <509AA588.1030006@redhat.com> <509AC17E.5090208@redhat.com> Message-ID: <1352320267.10327.278.camel@willson.li.ssimo.org> On Wed, 2012-11-07 at 15:15 -0500, Dmitri Pal wrote: > On 11/07/2012 01:16 PM, Petr Vobornik wrote: > > On 11/07/2012 05:30 PM, Dmitri Pal wrote: > >> On 11/07/2012 10:46 AM, Petr Vobornik wrote: > >>> We discussed some things on IRC. I wrote some comments below to allow > >>> others to chime in. > >>> > >>> Adam also created a public etherpad where we wrote most of the issues > >>> and possible solutions in some frameworks. I also wrote there short > >>> reviews of various JavaScript frameworks. > >>> > >>> https://etherpad.openstack.org/webui-idm > >> > >> > >> Good analyzes. But unfortunately I do not understand it well enough to > >> provide an opinion or guidance. > >> Let us step back and think about the goals. > >> > >> The UI works. It is not that it is broken. > >> We have several requirements for it though. > >> > >> 1) Do not redo it but refactor as needed > >> 2) Do not grow technical debt for long. If something really ugly and > >> prevents us from adding new capabilities or creates a bad user > >> experience let us fix it. > >> 3) We need to solve the problem of plugins/extensible UI so that > >> optional UI components can be dropped in. > >> > >> Untangling IPA specific things from common code is a nice goal but not a > >> priority. > >> With those requirements on the table what do you see is the best focused > >> approach? > > > > Sorted by priority: > > 1) Improve navigation extensibility (#3236), introduce a loader > > (dojo/require.js/custom) and extension registration (to know what to > > load) (#3235). These should solve requirement #3. > > > > 2) Refactor/introduce better model(persistance). IMO biggest technical > > debt. For this task I want to borrow a component from Dojo. It will > > make developing of enhancements and additional refactoring easier. > > > > 3) Along with 1) and 2) we can do additional refactoring of > > navigation. which will fix some ugly intermittent errors (#2741). > > > > 4) Optimize startup. Not a big task, IMO possibly very appreciated > > enhancement by admins. Tickets: #2678, #2679, #112 > > > > 5) I would really want to introduce AMD modules. Requires AMD loader > > (dojo/require.js) and a build tool (dojo/r.js) It should: > > * make dependencies more clear > > * easier development of third-party enhancements > > * the build helps with 4) > > * build will allow us to comment more so it might help new developers > > * it's side effect is partial untangling of IPA specific things > > from common code > > * better to do it sooner to avoid breaking of third party extensions. > > > > It's not a necessity but it should be worth the effort long-term. > > > > 6) Adopt different class system (from dojo or backbone.js) - fix > > issues in object initialization. > > * very time-consuming task > > * should be adopted gradually > > > > > > I've also considered to write a module with methods used by extension > > developers to extend existing pages easily - add one or two fields > > without studying the whole codebase. Something like > > add_field_after(new_field, entity, facet, section, after_field) or > > add_field(field, spec). Might be appreciated. > > > > Does it make sense to everybody else besides me? > If yes let us agree with the plan. I do see a lot of research seem have one into this. I am not a webui expert so I'll defer to the current people working on it. As long as the changes to the web ui do not impact the framework and break compatibility of the xmlrpc api I think anything is on the table and acceptable if it moves us forward toward better code and better UI. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Nov 7 20:43:38 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Nov 2012 15:43:38 -0500 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509AC17E.5090208@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> <509A8244.5000607@redhat.com> <509A8CC1.7020507@redhat.com> <509AA588.1030006@redhat.com> <509AC17E.5090208@redhat.com> Message-ID: <509AC7FA.1090501@redhat.com> Dmitri Pal wrote: > On 11/07/2012 01:16 PM, Petr Vobornik wrote: >> On 11/07/2012 05:30 PM, Dmitri Pal wrote: >>> On 11/07/2012 10:46 AM, Petr Vobornik wrote: >>>> We discussed some things on IRC. I wrote some comments below to allow >>>> others to chime in. >>>> >>>> Adam also created a public etherpad where we wrote most of the issues >>>> and possible solutions in some frameworks. I also wrote there short >>>> reviews of various JavaScript frameworks. >>>> >>>> https://etherpad.openstack.org/webui-idm >>> >>> >>> Good analyzes. But unfortunately I do not understand it well enough to >>> provide an opinion or guidance. >>> Let us step back and think about the goals. >>> >>> The UI works. It is not that it is broken. >>> We have several requirements for it though. >>> >>> 1) Do not redo it but refactor as needed >>> 2) Do not grow technical debt for long. If something really ugly and >>> prevents us from adding new capabilities or creates a bad user >>> experience let us fix it. >>> 3) We need to solve the problem of plugins/extensible UI so that >>> optional UI components can be dropped in. >>> >>> Untangling IPA specific things from common code is a nice goal but not a >>> priority. >>> With those requirements on the table what do you see is the best focused >>> approach? >> >> Sorted by priority: >> 1) Improve navigation extensibility (#3236), introduce a loader >> (dojo/require.js/custom) and extension registration (to know what to >> load) (#3235). These should solve requirement #3. >> >> 2) Refactor/introduce better model(persistance). IMO biggest technical >> debt. For this task I want to borrow a component from Dojo. It will >> make developing of enhancements and additional refactoring easier. >> >> 3) Along with 1) and 2) we can do additional refactoring of >> navigation. which will fix some ugly intermittent errors (#2741). >> >> 4) Optimize startup. Not a big task, IMO possibly very appreciated >> enhancement by admins. Tickets: #2678, #2679, #112 >> >> 5) I would really want to introduce AMD modules. Requires AMD loader >> (dojo/require.js) and a build tool (dojo/r.js) It should: >> * make dependencies more clear >> * easier development of third-party enhancements >> * the build helps with 4) >> * build will allow us to comment more so it might help new developers >> * it's side effect is partial untangling of IPA specific things >> from common code >> * better to do it sooner to avoid breaking of third party extensions. >> >> It's not a necessity but it should be worth the effort long-term. >> >> 6) Adopt different class system (from dojo or backbone.js) - fix >> issues in object initialization. >> * very time-consuming task >> * should be adopted gradually >> >> >> I've also considered to write a module with methods used by extension >> developers to extend existing pages easily - add one or two fields >> without studying the whole codebase. Something like >> add_field_after(new_field, entity, facet, section, after_field) or >> add_field(field, spec). Might be appreciated. >> > > Does it make sense to everybody else besides me? > If yes let us agree with the plan. > I'm not really a UI guy so I'm willing to defer this to Petr and/or Endi (and Adam). As long as any changes doesn't fundamentally change usability or cause massive changes in the XML-RPC/json framework it's fine with me. Making it easier to extend is definitely desirable. rob From edewata at redhat.com Wed Nov 7 21:25:07 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 7 Nov 2012 16:25:07 -0500 (EST) Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509AC7FA.1090501@redhat.com> Message-ID: <221819353.7921293.1352323507618.JavaMail.root@redhat.com> ----- Original Message ----- > Dmitri Pal wrote: > > On 11/07/2012 01:16 PM, Petr Vobornik wrote: > >> On 11/07/2012 05:30 PM, Dmitri Pal wrote: > >>> On 11/07/2012 10:46 AM, Petr Vobornik wrote: > >>>> We discussed some things on IRC. I wrote some comments below to > >>>> allow > >>>> others to chime in. > >>>> > >>>> Adam also created a public etherpad where we wrote most of the > >>>> issues > >>>> and possible solutions in some frameworks. I also wrote there > >>>> short > >>>> reviews of various JavaScript frameworks. > >>>> > >>>> https://etherpad.openstack.org/webui-idm > >>> > >>> > >>> Good analyzes. But unfortunately I do not understand it well > >>> enough to > >>> provide an opinion or guidance. > >>> Let us step back and think about the goals. > >>> > >>> The UI works. It is not that it is broken. > >>> We have several requirements for it though. > >>> > >>> 1) Do not redo it but refactor as needed > >>> 2) Do not grow technical debt for long. If something really ugly > >>> and > >>> prevents us from adding new capabilities or creates a bad user > >>> experience let us fix it. > >>> 3) We need to solve the problem of plugins/extensible UI so that > >>> optional UI components can be dropped in. > >>> > >>> Untangling IPA specific things from common code is a nice goal > >>> but not a > >>> priority. > >>> With those requirements on the table what do you see is the best > >>> focused > >>> approach? > >> > >> Sorted by priority: > >> 1) Improve navigation extensibility (#3236), introduce a loader > >> (dojo/require.js/custom) and extension registration (to know what > >> to > >> load) (#3235). These should solve requirement #3. > >> > >> 2) Refactor/introduce better model(persistance). IMO biggest > >> technical > >> debt. For this task I want to borrow a component from Dojo. It > >> will > >> make developing of enhancements and additional refactoring easier. > >> > >> 3) Along with 1) and 2) we can do additional refactoring of > >> navigation. which will fix some ugly intermittent errors (#2741). > >> > >> 4) Optimize startup. Not a big task, IMO possibly very appreciated > >> enhancement by admins. Tickets: #2678, #2679, #112 > >> > >> 5) I would really want to introduce AMD modules. Requires AMD > >> loader > >> (dojo/require.js) and a build tool (dojo/r.js) It should: > >> * make dependencies more clear > >> * easier development of third-party enhancements > >> * the build helps with 4) > >> * build will allow us to comment more so it might help new > >> developers > >> * it's side effect is partial untangling of IPA specific > >> things > >> from common code > >> * better to do it sooner to avoid breaking of third party > >> extensions. > >> > >> It's not a necessity but it should be worth the effort long-term. > >> > >> 6) Adopt different class system (from dojo or backbone.js) - fix > >> issues in object initialization. > >> * very time-consuming task > >> * should be adopted gradually > >> > >> > >> I've also considered to write a module with methods used by > >> extension > >> developers to extend existing pages easily - add one or two fields > >> without studying the whole codebase. Something like > >> add_field_after(new_field, entity, facet, section, after_field) or > >> add_field(field, spec). Might be appreciated. > >> > > > > Does it make sense to everybody else besides me? > > If yes let us agree with the plan. > > > > I'm not really a UI guy so I'm willing to defer this to Petr and/or > Endi > (and Adam). As long as any changes doesn't fundamentally change > usability or cause massive changes in the XML-RPC/json framework it's > fine with me. Making it easier to extend is definitely desirable. > > rob I think Petr's plan is good. It shouldn't change the current XML-RPC/JSON because there's an abstraction layer, and if in the future we decide to support REST or other RPC mechanism it can be done without changing the server or majority of the UI. Any JS framework will help reduce the burden of maintaining the current custom framework. Some frameworks might be better than Dojo in certain aspects, but Dojo seems to offer the best overall solution which can be gradually implemented without adding too much burden. And since Petr is ultimately the one who will implement this I'll defer the ultimate decision to him. There might be other design issues that need to be discussed, but those are separate from the framework decision. -- Endi S. Dewata From jdennis at redhat.com Wed Nov 7 21:44:54 2012 From: jdennis at redhat.com (John Dennis) Date: Wed, 07 Nov 2012 16:44:54 -0500 Subject: [Freeipa-devel] Dojo and Web UI in 3.2 In-Reply-To: <509AC17E.5090208@redhat.com> References: <508E4C0E.5010807@redhat.com> <508F6A4B.7090109@redhat.com> <50900C40.2080801@redhat.com> <5091A279.8060205@redhat.com> <50927839.30806@redhat.com> <509280B2.2040607@redhat.com> <509A8244.5000607@redhat.com> <509A8CC1.7020507@redhat.com> <509AA588.1030006@redhat.com> <509AC17E.5090208@redhat.com> Message-ID: <509AD656.7060906@redhat.com> On 11/07/2012 03:15 PM, Dmitri Pal wrote: > Does it make sense to everybody else besides me? > If yes let us agree with the plan. I've been following the discussion but I'm not a web developer and many of the technical issues are outside my scope of knowledge. However the proposal does seem to be well researched and thought out so my instinct is to defer to the experts and proceed based on their advice. John -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Thu Nov 8 07:20:04 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Nov 2012 08:20:04 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <20121107164833.GG2195@localhost.localdomain> References: <20121030111644.GX10066@localhost.localdomain> <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> <20121102205000.GM10066@localhost.localdomain> <5097AEA9.8000906@redhat.com> <20121107125458.GE2195@localhost.localdomain> <509A5C32.9080207@redhat.com> <509A67F0.9030907@redhat.com> <20121107164833.GG2195@localhost.localdomain> Message-ID: <509B5D24.2050906@redhat.com> On 11/07/2012 05:48 PM, Sumit Bose wrote: > On Wed, Nov 07, 2012 at 07:23:52PM +0530, Steeve Goveas wrote: >> On 11/07/2012 06:33 PM, Martin Kosek wrote: >>> On 11/07/2012 01:54 PM, Sumit Bose wrote: >>>> On Mon, Nov 05, 2012 at 01:18:49PM +0100, Martin Kosek wrote: >>>>> On 11/02/2012 09:50 PM, Sumit Bose wrote: >>>>>> On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: >>>>>>> On 11/02/2012 12:54 PM, Sumit Bose wrote: >>>>>>>> On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: >>>>>>>>> On 10/30/2012 12:16 PM, Sumit Bose wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name >>>>>>>>>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . >>>>>>>>>> >>>>>>>>>> bye, >>>>>>>>>> Sumit >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hello Sumit, >>>>>>>>> >>>>>>>>> I found few issues with your patch: >>>>>>>> Thank you for the review. >>>>>>>> >>>>>>>>> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not >>>>>>>>> think this is necessary, ipa-adtrust-install already requires admin password to >>>>>>>>> be passed and it already connects to LDAP with these credentials: >>>>>>>>> >>>>>>>>> api.Backend.ldap2.connect(ccache.name) >>>>>>>>> >>>>>>>>> You could use ipa.Backend.ldap2 object to do entry retrieval >>>>>>>>> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. >>>>>>>> fixed >>>>>>>> >>>>>>>>> 2) When doing try..except statement, rule of thumb says that it should be as >>>>>>>>> short as possible, so that it does not hide other potential errors and makes >>>>>>>>> clear what function raises the catched exception. >>>>>>>>> >>>>>>>>> In your case: >>>>>>>>> >>>>>>>>> try: >>>>>>>>> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), >>>>>>>>> api.env.container_cifsdomains, >>>>>>>>> self.api.env.basedn), >>>>>>>>> ['ipantflatname']) >>>>>>>>> except errors.NotFound: >>>>>>>>> reset_netbios_name = False >>>>>>>>> else: >>>>>>>>> # process entry >>>>>>>>> >>>>>>>>> Should be a pattern that you want. >>>>>>>> fixed >>>>>>>> >>>>>>>> I also move all the NetBIOS name related code into a separate function. >>>>>>>>> 3) I think this line is redundant: >>>>>>>>> + print "Say 'yes' if the NetBIOS shall be changed and " \ >>>>>>>>> + "'no' if the old one shall be kept." >>>>>>>>> >>>>>>>>> IMO, the question: >>>>>>>>> >>>>>>>>> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default >>>>>>>>> = False, allow_empty = False) >>>>>>>>> >>>>>>>>> and the information printed before is enough. >>>>>>>> I would prefer to keep it this way to make clear that >>>>>>>> ipa-adtrust-install will continue processing, but the old name if kept >>>>>>>> even if a new name was given with --netbios-name on the command line. >>>>>>>> >>>>>>>> New version attached. >>>>>>>> >>>>>>>> bye, >>>>>>>> Sumit >>>>>>>> >>>>>>>>> Martin >>>>>>> >>>>>>> The new approach looks much better. Sending issues I found with the new patch: >>>>>>> >>>>>>> 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS >>>>>>> name interactively. I can only change it via script option... >>>>>>> >>>>>> fixed >>>>>> >>>>>>> 2) I saw few typos: >>>>>>> >>>>>>> + print "Current NetBIOS domain name is %s new name is %s.\n" % \ >>>>>>> should be: >>>>>>> + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ >>>>>>> >>>>>>> + print "NetBIOS domain name will be changes to %s.\n" % \ >>>>>>> should be: >>>>>>> + print "NetBIOS domain name will be changed to %s.\n" % \ >>>>>>> >>>>>>> >>>>>> fixed >>>>>> >>>>>> new version attached. >>>>>> >>>>>> bye, >>>>>> Sumit >>>>>>> Martin >>>>> NetBIOS name is now asked when first installing ipa-adtrust-install. >>>>> >>>>> But I see that NetBIOS name is still not queried when I run re-install of >>>>> ADTRUST, I can only change current name via option. Is this is an intended >>>>> behavior so that people cannot mess it with by mistake? >>>> Yes. The old code didn't check if the NetBIOS name was already set in >>>> LDAP or not, hence it always asked the user if the generated NetBIOS >>>> name is the one the user expected. >>>> >>>> The new version looks up the NetBIOS name in the LDAP server and if set >>>> and no new name is given on the command line assumes that the admin >>>> does not want to change the NetBIOS name and skips the dialog. >>>> >>>> I'll add the QE team to hear what they prefer. >>>> >>>> Jenny, Scott, Steeve, assume ipa-adtrust-install is run after trust was >>>> already configured and no --netbios-name option is given on the command >>>> line. Shall the following dialog be shown: >>>> >>>> ..... >>>> Enter the NetBIOS name for the IPA domain. >>>> Only up to 15 uppercase ASCII letters and digits are allowed. >>>> Example: EXAMPLE. >>>> >>>> >>>> NetBIOS domain name [IPA17]: >>>> .... >>>> >>>> The admin then has to press enter to confirm the current NetBIOS name or >>>> can enter a new one. Or shall the dialog be skipped which means that the >>>> NetBIOS can only be resetted if a new one is given at the command line >>>> with the --netbios-name option? >>> Ok, thanks from explanation. But from my devel perspective, since a change of >>> NetBIOS domain name can break existing trusts I would rather not offer a change >>> of NetBIOS name during interactive prompt. A mere stating of a current value >>> with asking to user to change it should be enough. >>> >>> QE input is welcome, yes. >>> >>> Martin >>> >> If changing the netbios name post creating trust would break >> existing trust, then I dont think that changing the netbios named >> should be allowed. A clear message to drop the trust and re-add it >> would be better. > > With the current patch you already get a warning when your are about to > change the NetBIOS name: > > .... > Current NetBIOS domain name is IPA17, new name is ABC. > > Please note that changing the NetBIOS name might break existing trust > relationships. > Say 'yes' if the NetBIOS shall be changed and 'no' if the old one shall > be kept. > Do you want to reset the NetBIOS domain name? [no]: > .... > > So the admin can still change his mind. I think a description of what > you should considered when you really want to change the NetBIOS domain > name should go into the docs and not printed by ipa-adtrust-install. As > mentioned earlier changing the NetBIOS domain name should be seen as the > last resort and should be done with great care. > > bye, > Sumit I think this is fine. ACK. Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Thu Nov 8 07:46:42 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Nov 2012 08:46:42 +0100 Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <509A9E5D.6070904@redhat.com> References: <1347679228.6583986.1352300921252.JavaMail.root@redhat.com> <509A9E5D.6070904@redhat.com> Message-ID: <509B6362.7020905@redhat.com> On 11/07/2012 06:46 PM, Jan Cholasta wrote: > On 7.11.2012 16:08, Lynn Root wrote: >> Third time is a charm? >> >> Lynn Root >> Associate Software Engineer >> Red Hat >> >> ----- Original Message ----- >> From: "Jan Cholasta" >> To: "Lynn Root" >> Cc: freeipa-devel at redhat.com >> Sent: Monday, November 5, 2012 10:25:32 AM >> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors >> >> On 5.11.2012 09:43, Lynn Root wrote: >>> Here's try #2! Adjusted patch attached. Let me know if there's anything >>> else I've missed. >>> >>> Switched %r specifiers to '%s' in Public errors, and adjusted tests to >>> expect no preceding 'u'. >>> >>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & >>> https://fedorahosted.org/freeipa/ticket/2588 >>> >>> Lynn Root >>> Associate Software Engineer >>> Red Hat >>> >>> ----- Original Message ----- >>> From: "Martin Kosek" >>> To: "Jan Cholasta" >>> Cc: "Lynn Root" , freeipa-devel at redhat.com >>> Sent: Tuesday, October 30, 2012 9:08:33 AM >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public >>> errors >>> >>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 29.10.2012 19:54, Lynn Root wrote: >>>>> Hi all! >>>>> >>>>> This switch drops the preceding 'u' from strings in public error messages. >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>>>> >>>>> This patch also addresses the unfriendly 'u' from re-raising errors from the >>>>> external call to netaddr.IPAddress by passing a bytestring to the function. >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>>>> >>>>> >>>>> My first patch (and freeipa dev list email) ever! Let me know where there's >>>>> room to improve. >>>>> >>>>> Lynn Root >>>>> Associate Software Engineer >>>>> Red Hat >>>>> >>>> >>>> I think it would be nice if you kept the quotes around the values, as that is >>>> probably the reason "%r" was used in the first place - i.e. use "'%s'" instead >>>> of plain "%s". >>> >>> +1 >>> >>> With current patch, I assume that a lot of unit tests will fail as they check >>> exact error message wording. I'd recommend running the whole test suite with >>> your second patch revision. There is a short walkthrough how to set it up: >>> >>> http://freeipa.org/page/Testing >>> >>> Martin >>> >> >> You missed a few: >> >> $ git grep -En '%(\(.*?\))?r' >> >> Honza >> > > I think you have gone too far this time :-) It is not necessary (or wise) to > get rid of %r *everywhere* in the code. Thanks Honza for pointing that out. It seems I missed that in yesterday's review. Now, when I look at it, it indeed is not right. > > A few rules to keep in mind: > > * If it is not an error message, do not touch it (log messages are not error > messages BTW). > > * If it is an error message for an exception that does not inherit from > errors.PublicError, do not touch it (there might be a few exceptions, though). Right. But for example, your netaddr str conversions should be fine since the netaddr error is propagated up to the ValidationError. Martin > > * Use '%s' (%s with ticks) only for arguments whose value can be only str or > unicode. > > Honza > From sbose at redhat.com Thu Nov 8 08:43:11 2012 From: sbose at redhat.com (Sumit Bose) Date: Thu, 8 Nov 2012 09:43:11 +0100 Subject: [Freeipa-devel] [PATCH] 89 ipa-adtrust-install: allow to reset te NetBIOS domain name In-Reply-To: <509B5D24.2050906@redhat.com> References: <50913DB2.5040908@redhat.com> <20121102115415.GL10066@localhost.localdomain> <5093D098.2060109@redhat.com> <20121102205000.GM10066@localhost.localdomain> <5097AEA9.8000906@redhat.com> <20121107125458.GE2195@localhost.localdomain> <509A5C32.9080207@redhat.com> <509A67F0.9030907@redhat.com> <20121107164833.GG2195@localhost.localdomain> <509B5D24.2050906@redhat.com> Message-ID: <20121108084310.GH2195@localhost.localdomain> On Thu, Nov 08, 2012 at 08:20:04AM +0100, Martin Kosek wrote: > On 11/07/2012 05:48 PM, Sumit Bose wrote: > > On Wed, Nov 07, 2012 at 07:23:52PM +0530, Steeve Goveas wrote: > >> On 11/07/2012 06:33 PM, Martin Kosek wrote: > >>> On 11/07/2012 01:54 PM, Sumit Bose wrote: > >>>> On Mon, Nov 05, 2012 at 01:18:49PM +0100, Martin Kosek wrote: > >>>>> On 11/02/2012 09:50 PM, Sumit Bose wrote: > >>>>>> On Fri, Nov 02, 2012 at 02:54:32PM +0100, Martin Kosek wrote: > >>>>>>> On 11/02/2012 12:54 PM, Sumit Bose wrote: > >>>>>>>> On Wed, Oct 31, 2012 at 04:03:14PM +0100, Martin Kosek wrote: > >>>>>>>>> On 10/30/2012 12:16 PM, Sumit Bose wrote: > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> this patch allows ipa-adtrust-install to reset the NetBIOS domain name > >>>>>>>>>> and fixes https://fedorahosted.org/freeipa/ticket/3192 . > >>>>>>>>>> > >>>>>>>>>> bye, > >>>>>>>>>> Sumit > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hello Sumit, > >>>>>>>>> > >>>>>>>>> I found few issues with your patch: > >>>>>>>> Thank you for the review. > >>>>>>>> > >>>>>>>>> 1) It requires admin to be kinited ("conn.do_sasl_gssapi_bind()") I do not > >>>>>>>>> think this is necessary, ipa-adtrust-install already requires admin password to > >>>>>>>>> be passed and it already connects to LDAP with these credentials: > >>>>>>>>> > >>>>>>>>> api.Backend.ldap2.connect(ccache.name) > >>>>>>>>> > >>>>>>>>> You could use ipa.Backend.ldap2 object to do entry retrieval > >>>>>>>>> (ipa.Backend.ldap2.get_entry) without a need to init IPAdmin at all. > >>>>>>>> fixed > >>>>>>>> > >>>>>>>>> 2) When doing try..except statement, rule of thumb says that it should be as > >>>>>>>>> short as possible, so that it does not hide other potential errors and makes > >>>>>>>>> clear what function raises the catched exception. > >>>>>>>>> > >>>>>>>>> In your case: > >>>>>>>>> > >>>>>>>>> try: > >>>>>>>>> entry = api.Backend.ldap2.get_entry(DN(('cn', api.env.domain), > >>>>>>>>> api.env.container_cifsdomains, > >>>>>>>>> self.api.env.basedn), > >>>>>>>>> ['ipantflatname']) > >>>>>>>>> except errors.NotFound: > >>>>>>>>> reset_netbios_name = False > >>>>>>>>> else: > >>>>>>>>> # process entry > >>>>>>>>> > >>>>>>>>> Should be a pattern that you want. > >>>>>>>> fixed > >>>>>>>> > >>>>>>>> I also move all the NetBIOS name related code into a separate function. > >>>>>>>>> 3) I think this line is redundant: > >>>>>>>>> + print "Say 'yes' if the NetBIOS shall be changed and " \ > >>>>>>>>> + "'no' if the old one shall be kept." > >>>>>>>>> > >>>>>>>>> IMO, the question: > >>>>>>>>> > >>>>>>>>> reset_netbios_name = ipautil.user_input( 'Reset NetBIOS domain name?', default > >>>>>>>>> = False, allow_empty = False) > >>>>>>>>> > >>>>>>>>> and the information printed before is enough. > >>>>>>>> I would prefer to keep it this way to make clear that > >>>>>>>> ipa-adtrust-install will continue processing, but the old name if kept > >>>>>>>> even if a new name was given with --netbios-name on the command line. > >>>>>>>> > >>>>>>>> New version attached. > >>>>>>>> > >>>>>>>> bye, > >>>>>>>> Sumit > >>>>>>>> > >>>>>>>>> Martin > >>>>>>> > >>>>>>> The new approach looks much better. Sending issues I found with the new patch: > >>>>>>> > >>>>>>> 1) When I run ipa-adtrust-install on a clean IPA, I can no longer enter NetBIOS > >>>>>>> name interactively. I can only change it via script option... > >>>>>>> > >>>>>> fixed > >>>>>> > >>>>>>> 2) I saw few typos: > >>>>>>> > >>>>>>> + print "Current NetBIOS domain name is %s new name is %s.\n" % \ > >>>>>>> should be: > >>>>>>> + print "Current NetBIOS domain name is %s, new name is %s.\n" % \ > >>>>>>> > >>>>>>> + print "NetBIOS domain name will be changes to %s.\n" % \ > >>>>>>> should be: > >>>>>>> + print "NetBIOS domain name will be changed to %s.\n" % \ > >>>>>>> > >>>>>>> > >>>>>> fixed > >>>>>> > >>>>>> new version attached. > >>>>>> > >>>>>> bye, > >>>>>> Sumit > >>>>>>> Martin > >>>>> NetBIOS name is now asked when first installing ipa-adtrust-install. > >>>>> > >>>>> But I see that NetBIOS name is still not queried when I run re-install of > >>>>> ADTRUST, I can only change current name via option. Is this is an intended > >>>>> behavior so that people cannot mess it with by mistake? > >>>> Yes. The old code didn't check if the NetBIOS name was already set in > >>>> LDAP or not, hence it always asked the user if the generated NetBIOS > >>>> name is the one the user expected. > >>>> > >>>> The new version looks up the NetBIOS name in the LDAP server and if set > >>>> and no new name is given on the command line assumes that the admin > >>>> does not want to change the NetBIOS name and skips the dialog. > >>>> > >>>> I'll add the QE team to hear what they prefer. > >>>> > >>>> Jenny, Scott, Steeve, assume ipa-adtrust-install is run after trust was > >>>> already configured and no --netbios-name option is given on the command > >>>> line. Shall the following dialog be shown: > >>>> > >>>> ..... > >>>> Enter the NetBIOS name for the IPA domain. > >>>> Only up to 15 uppercase ASCII letters and digits are allowed. > >>>> Example: EXAMPLE. > >>>> > >>>> > >>>> NetBIOS domain name [IPA17]: > >>>> .... > >>>> > >>>> The admin then has to press enter to confirm the current NetBIOS name or > >>>> can enter a new one. Or shall the dialog be skipped which means that the > >>>> NetBIOS can only be resetted if a new one is given at the command line > >>>> with the --netbios-name option? > >>> Ok, thanks from explanation. But from my devel perspective, since a change of > >>> NetBIOS domain name can break existing trusts I would rather not offer a change > >>> of NetBIOS name during interactive prompt. A mere stating of a current value > >>> with asking to user to change it should be enough. > >>> > >>> QE input is welcome, yes. > >>> > >>> Martin > >>> > >> If changing the netbios name post creating trust would break > >> existing trust, then I dont think that changing the netbios named > >> should be allowed. A clear message to drop the trust and re-add it > >> would be better. > > > > With the current patch you already get a warning when your are about to > > change the NetBIOS name: > > > > .... > > Current NetBIOS domain name is IPA17, new name is ABC. > > > > Please note that changing the NetBIOS name might break existing trust > > relationships. > > Say 'yes' if the NetBIOS shall be changed and 'no' if the old one shall > > be kept. > > Do you want to reset the NetBIOS domain name? [no]: > > .... > > > > So the admin can still change his mind. I think a description of what > > you should considered when you really want to change the NetBIOS domain > > name should go into the docs and not printed by ipa-adtrust-install. As > > mentioned earlier changing the NetBIOS domain name should be seen as the > > last resort and should be done with great care. > > > > bye, > > Sumit > > I think this is fine. > > ACK. Pushed to master, ipa-3-0. Thank you. bye, Sumit > > Martin > From atkac at redhat.com Thu Nov 8 15:13:48 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 8 Nov 2012 16:13:48 +0100 Subject: [Freeipa-devel] [PATCH 0087] Unload master zone if forwarders are specified In-Reply-To: <5097CC9C.3060000@redhat.com> References: <5097CC9C.3060000@redhat.com> Message-ID: <20121108151347.GA11301@redhat.com> On Mon, Nov 05, 2012 at 03:26:36PM +0100, Petr Spacek wrote: > Hello, > > Unload master zone if forwarders are specified. > > This patch should solve master => forward zone type change. Ack > From 96da10ab49612442fdf7b1c1805cddc4f46d511e Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Mon, 5 Nov 2012 15:12:50 +0100 > Subject: [PATCH] Unload master zone if forwarders are specified. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 36 ++++++++++++++++++++++++------------ > 1 file changed, 24 insertions(+), 12 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 2d52bfaf894de8a5591f966b0c9197d14a1e73f7..4f004515f513ecf6459b3bddfbc5474fe3cfabd2 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -308,7 +308,8 @@ 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); > +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, > @@ -620,7 +621,7 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > > result = ldap_delete_zone2(ldap_inst, > dns_fixedname_name(&concat), > - ISC_TRUE); > + ISC_TRUE, ISC_FALSE); > RUNTIME_CHECK(result == ISC_R_SUCCESS); > } > > @@ -841,7 +842,8 @@ configure_zone_ssutable(dns_zone_t *zone, const char *update_str) > > /* Delete zone by dns zone name */ > static isc_result_t > -ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock) > +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_boolean_t unlock = ISC_FALSE; > @@ -860,10 +862,12 @@ ldap_delete_zone2(ldap_instance_t *inst, dns_name_t *name, isc_boolean_t lock) > unlock = ISC_TRUE; > } > > - /* Disable 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); > + 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); > + } > > /* TODO: flush cache records belonging to deleted zone */ > CHECK(discard_from_cache(inst->cache, name)); > @@ -911,15 +915,16 @@ cleanup: > > /* Delete zone */ > static isc_result_t > -ldap_delete_zone(ldap_instance_t *inst, const char *dn, isc_boolean_t lock) > +ldap_delete_zone(ldap_instance_t *inst, const char *dn, isc_boolean_t lock, > + isc_boolean_t preserve_forwarding) > { > isc_result_t result; > dns_name_t name; > dns_name_init(&name, NULL); > > CHECK(dn_to_dnsname(inst->mctx, dn, &name, NULL)); > > - result = ldap_delete_zone2(inst, &name, lock); > + result = ldap_delete_zone2(inst, &name, lock, preserve_forwarding); > > cleanup: > if (dns_name_dynamic(&name)) > @@ -1218,6 +1223,11 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > result = configure_zone_forwarders(entry, inst, &name); > if (result != ISC_R_DISABLED) { > if (result == ISC_R_SUCCESS) { > + /* forwarding was enabled for the zone > + * => zone type was changed to "forward" > + * => delete "master" zone */ > + CHECK(ldap_delete_zone2(inst, &name, ISC_FALSE, > + ISC_TRUE)); > #if LIBDNS_VERSION_MAJOR < 90 > result = dns_view_flushcache(inst->view); > #else > @@ -1510,7 +1520,8 @@ next: > result = dns_rbtnodechain_next(&chain, NULL, NULL); > > if (delete == ISC_TRUE) > - ldap_delete_zone2(ldap_inst, &aname, ISC_FALSE); > + ldap_delete_zone2(ldap_inst, &aname, ISC_FALSE, > + ISC_FALSE); > } > > > @@ -3253,7 +3264,8 @@ update_zone(isc_task_t *task, isc_event_t *event) > 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)); > + 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); > @@ -3274,7 +3286,7 @@ update_zone(isc_task_t *task, isc_event_t *event) > > INSIST(NEXT(entry_zone, link) == NULL); /* no multiple zones with same DN */ > } else { > - CHECK(ldap_delete_zone(inst, pevent->dn, ISC_TRUE)); > + CHECK(ldap_delete_zone(inst, pevent->dn, ISC_TRUE, ISC_FALSE)); > } > > cleanup: > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 8 15:33:58 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 8 Nov 2012 16:33:58 +0100 Subject: [Freeipa-devel] [PATCH 0088] Flush BIND caches if forwarder configuration was changed In-Reply-To: <5099187D.2070509@redhat.com> References: <5099187D.2070509@redhat.com> Message-ID: <20121108153357.GA11587@redhat.com> On Tue, Nov 06, 2012 at 03:02:37PM +0100, Petr Spacek wrote: > Hello, > > Flush BIND caches if forwarder configuration was changed. > > Cache will not be flushed if old and new configurations are equal. > Without this optimization cache would be flushed during each zone refresh. Ack, just please check my comment below. Regards, Adam > From faed16b4861d4263ed942608d3767324fc2fae88 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 6 Nov 2012 14:53:02 +0100 > Subject: [PATCH] Flush BIND caches if forwarder configuration was changed. > > Cache will not be flushed if old and new configurations are equal. > Without this optimization cache would be flushed during each zone refresh. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 67 ++++++++++++++++++++++++++++++++++++++++++++----------- > 1 file changed, 54 insertions(+), 13 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 4f004515f513ecf6459b3bddfbc5474fe3cfabd2..b36892b4e8180fb2a5f335e3fa1b5589dae8bf14 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -975,11 +975,15 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > { > const char *dn = entry->dn; > isc_result_t result; > + isc_result_t orig_result; > ldap_valuelist_t values; > ldap_value_t *value; > isc_sockaddrlist_t addrs; > isc_boolean_t is_global_config; > isc_boolean_t fwdtbl_deletion_requested = ISC_TRUE; > + isc_boolean_t fwdtbl_update_requested = ISC_FALSE; > + dns_forwarders_t *old_setting = NULL; > + dns_fixedname_t foundname; > const char *msg_use_global_fwds; > const char *msg_obj_type; > const char *msg_forwarders_not_def; > @@ -993,6 +997,7 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > > REQUIRE(entry != NULL && inst != NULL && name != NULL); > ISC_LIST_INIT(addrs); > + dns_fixedname_init(&foundname); > if (dns_name_equal(name, dns_rootname)) { > is_global_config = ISC_TRUE; > msg_obj_type = "global configuration"; > @@ -1083,16 +1088,49 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, > msg_obj_type, dn); > } > > - /* Set forward table up. */ > - CHECK(delete_forwarding_table(inst, name, msg_obj_type, dn)); > - result = dns_fwdtable_add(inst->view->fwdtable, name, &addrs, fwdpolicy); > + /* Check for old and new forwarding settings equality. */ > + result = dns_fwdtable_find2(inst->view->fwdtable, name, > + dns_fixedname_name(&foundname), > + &old_setting); > + if (result == ISC_R_SUCCESS && > + (dns_name_equal(name, dns_fixedname_name(&foundname)) == ISC_TRUE)) { > + isc_sockaddr_t *s1, *s2; > + > + if (fwdpolicy != old_setting->fwdpolicy) > + fwdtbl_update_requested = ISC_TRUE; > + > + /* Check address lists item by item. */ > + for (s1 = ISC_LIST_HEAD(addrs), s2 = ISC_LIST_HEAD(old_setting->addrs); > + s1 != NULL && s2 != NULL && !fwdtbl_update_requested; > + s1 = ISC_LIST_NEXT(s1, link), s2 = ISC_LIST_NEXT(s2, link)) > + if (!isc_sockaddr_equal(s1, s2)) > + fwdtbl_update_requested = ISC_TRUE; > + > + if ((s1 == NULL) != (s2 == NULL)) Although this is correct, something like if ((s1 != NULL) || (s2 != NULL)) or even if (!fwdtbl_update_requested && ((s1 != NULL) || (s2 != NULL))) shouldn't affect functionality and is more readable than rare (==) != (==) construction. You don't have to pass the patch for review again, just directly push it. > + fwdtbl_update_requested = ISC_TRUE; > + } else { > + fwdtbl_update_requested = ISC_TRUE; > + if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) > + log_error_r("%s '%s': can't obtain old forwarding " > + "settings", msg_obj_type, dn); > + } > + > + if (fwdtbl_update_requested) { > + /* Something was changed - set forward table up. */ > + CHECK(delete_forwarding_table(inst, name, msg_obj_type, dn)); > + result = dns_fwdtable_add(inst->view->fwdtable, name, &addrs, fwdpolicy); > + if (result != ISC_R_SUCCESS) > + log_error_r("%s '%s': forwarding table update failed", > + msg_obj_type, dn); > + } else { > + result = ISC_R_SUCCESS; > + log_debug(5, "%s '%s': forwarding table unmodified", > + msg_obj_type, dn); > + } > if (result == ISC_R_SUCCESS) { > fwdtbl_deletion_requested = ISC_FALSE; > if (fwdpolicy == dns_fwdpolicy_none) > result = ISC_R_DISABLED; > - } else { > - log_error_r("%s '%s': forwarding table update failed", > - msg_obj_type, dn); > } > > cleanup: > @@ -1106,11 +1144,19 @@ cleanup: > } > } > if (fwdtbl_deletion_requested) { > - isc_result_t orig_result = result; > + orig_result = result; > result = delete_forwarding_table(inst, name, msg_obj_type, dn); > if (result == ISC_R_SUCCESS) > result = orig_result; > } > + if (fwdtbl_deletion_requested || fwdtbl_update_requested) { > + log_debug(5, "%s '%s': forwarder table was updated: %s", > + msg_obj_type, dn, dns_result_totext(result)); > + orig_result = result; > + result = dns_view_flushcache(inst->view); > + if (result == ISC_R_SUCCESS) > + result = orig_result; > + } > return result; > } > > @@ -1133,7 +1179,7 @@ ldap_parse_configentry(ldap_entry_t *entry, ldap_instance_t *inst) > /* idnsForwardPolicy change is handled by configure_zone_forwarders() */ > result = configure_zone_forwarders(entry, inst, dns_rootname); > if (result != ISC_R_SUCCESS && result != ISC_R_DISABLED) { > - log_error("Global forwarder could not be set up."); > + log_error_r("global forwarder could not be set up"); > } > > result = ldap_entry_getvalues(entry, "idnsAllowSyncPTR", &values); > @@ -1228,11 +1274,6 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > * => delete "master" zone */ > CHECK(ldap_delete_zone2(inst, &name, ISC_FALSE, > ISC_TRUE)); > -#if LIBDNS_VERSION_MAJOR < 90 > - result = dns_view_flushcache(inst->view); > -#else > - result = dns_view_flushnode(inst->view, &name, ISC_TRUE); > -#endif > } > /* DO NOT CHANGE ANYTHING ELSE after forwarders are set up! */ > goto cleanup; > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 8 15:34:14 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 8 Nov 2012 16:34:14 +0100 Subject: [Freeipa-devel] [PATCH 0089] Bump NVR to 2.3 In-Reply-To: <5099195D.9020904@redhat.com> References: <5099195D.9020904@redhat.com> Message-ID: <20121108153414.GB11587@redhat.com> On Tue, Nov 06, 2012 at 03:06:21PM +0100, Petr Spacek wrote: > Hello, > > Bump NVR to 2.3. Ack > From b311dfc43d1175af5d4c960b2e36925a02eb73e1 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 6 Nov 2012 15:05:33 +0100 > Subject: [PATCH] Bump NVR to 2.3. > > Signed-off-by: Petr Spacek > --- > configure.ac | 2 +- > contrib/bind-dyndb-ldap.spec | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 1706ae46aa3c0620bc8c5a7adf5463102f90edf5..0078f0a0533003b0935c1ffc935e9c67dfdcca79 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -1,5 +1,5 @@ > AC_PREREQ([2.59]) > -AC_INIT([bind-dyndb-ldap], [2.2], [freeipa-devel at redhat.com]) > +AC_INIT([bind-dyndb-ldap], [2.3], [freeipa-devel at redhat.com]) > > AM_INIT_AUTOMAKE([-Wall foreign dist-bzip2]) > > diff --git a/contrib/bind-dyndb-ldap.spec b/contrib/bind-dyndb-ldap.spec > index 8e9e6af029f99d056f4fe5e3d6afe0d365bf5c5f..f0fa17ccc4dae7113a0b4293c40aeae26b7c2ed8 100644 > --- a/contrib/bind-dyndb-ldap.spec > +++ b/contrib/bind-dyndb-ldap.spec > @@ -1,7 +1,7 @@ > %define VERSION %{version} > > Name: bind-dyndb-ldap > -Version: 2.2 > +Version: 2.3 > Release: 0%{?dist} > Summary: LDAP back-end plug-in for BIND > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Thu Nov 8 16:26:15 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Nov 2012 17:26:15 +0100 Subject: [Freeipa-devel] [PATCH 0086] Respect global forwarders from named.conf if they are not overridden by LDAP configuration In-Reply-To: <20121106143816.GA7753@redhat.com> References: <509406B1.2080400@redhat.com> <50940874.8080107@redhat.com> <50940AB5.4010703@redhat.com> <20121106143816.GA7753@redhat.com> Message-ID: <509BDD27.8030105@redhat.com> On 11/06/2012 03:38 PM, Adam Tkac wrote: > On Fri, Nov 02, 2012 at 07:02:29PM +0100, Petr Spacek wrote: >> >On 11/02/2012 06:52 PM, Petr Spacek wrote: >>> > >On 11/02/2012 06:45 PM, Petr Spacek wrote: >>>> > >>Hello, >>>> > >> >>>> > >>Respect global forwarders from named.conf if they are not overridden by LDAP >>>> > >>configuration. >>>> > >> >>>> > >>Original configuration from named.conf is saved on load. >>>> > >>Original configuration will be restored if configuration in LDAP is not >>>> > >>present or is invalid. >>>> > >> >>>> > >> >>>> > >>Another patch for cache flushing will follow. >>> > > >>> > >Well, another Friday - another forgotten patch. >>> > > >> >For my mail client: The patch is*attached*. > Ack > Pushed to master and v2: 6439769095d018f1487e53e7dc1a597e411cf33a -- Petr^2 Spacek From pspacek at redhat.com Thu Nov 8 16:26:50 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Nov 2012 17:26:50 +0100 Subject: [Freeipa-devel] [PATCH 0087] Unload master zone if forwarders are specified In-Reply-To: <20121108151347.GA11301@redhat.com> References: <5097CC9C.3060000@redhat.com> <20121108151347.GA11301@redhat.com> Message-ID: <509BDD4A.30206@redhat.com> On 11/08/2012 04:13 PM, Adam Tkac wrote: > On Mon, Nov 05, 2012 at 03:26:36PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Unload master zone if forwarders are specified. >> > >> >This patch should solve master => forward zone type change. > Ack > Pushed to master and v2: 96da10ab49612442fdf7b1c1805cddc4f46d511e -- Petr^2 Spacek From lroot at redhat.com Thu Nov 8 16:22:25 2012 From: lroot at redhat.com (Lynn Root) Date: Thu, 8 Nov 2012 11:22:25 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <509B6362.7020905@redhat.com> Message-ID: <543051636.7383138.1352391745075.JavaMail.root@redhat.com> Hmm I hope I understand well enough this time around. However, when I run the tests, there's this one error message I come across from `test_user[97]: user_add: Create u'tuser2'` - it throws `DatabaseError: Type or value exists`. I'm a bit lost on how to track this down. Once again - thanks for your help! Lynn Root Associate Software Engineer Red Hat ----- Original Message ----- From: "Martin Kosek" To: "Jan Cholasta" Cc: "Lynn Root" , freeipa-devel at redhat.com Sent: Thursday, November 8, 2012 8:46:42 AM Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors On 11/07/2012 06:46 PM, Jan Cholasta wrote: > On 7.11.2012 16:08, Lynn Root wrote: >> Third time is a charm? >> >> Lynn Root >> Associate Software Engineer >> Red Hat >> >> ----- Original Message ----- >> From: "Jan Cholasta" >> To: "Lynn Root" >> Cc: freeipa-devel at redhat.com >> Sent: Monday, November 5, 2012 10:25:32 AM >> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors >> >> On 5.11.2012 09:43, Lynn Root wrote: >>> Here's try #2! Adjusted patch attached. Let me know if there's anything >>> else I've missed. >>> >>> Switched %r specifiers to '%s' in Public errors, and adjusted tests to >>> expect no preceding 'u'. >>> >>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & >>> https://fedorahosted.org/freeipa/ticket/2588 >>> >>> Lynn Root >>> Associate Software Engineer >>> Red Hat >>> >>> ----- Original Message ----- >>> From: "Martin Kosek" >>> To: "Jan Cholasta" >>> Cc: "Lynn Root" , freeipa-devel at redhat.com >>> Sent: Tuesday, October 30, 2012 9:08:33 AM >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public >>> errors >>> >>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 29.10.2012 19:54, Lynn Root wrote: >>>>> Hi all! >>>>> >>>>> This switch drops the preceding 'u' from strings in public error messages. >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>>>> >>>>> This patch also addresses the unfriendly 'u' from re-raising errors from the >>>>> external call to netaddr.IPAddress by passing a bytestring to the function. >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>>>> >>>>> >>>>> My first patch (and freeipa dev list email) ever! Let me know where there's >>>>> room to improve. >>>>> >>>>> Lynn Root >>>>> Associate Software Engineer >>>>> Red Hat >>>>> >>>> >>>> I think it would be nice if you kept the quotes around the values, as that is >>>> probably the reason "%r" was used in the first place - i.e. use "'%s'" instead >>>> of plain "%s". >>> >>> +1 >>> >>> With current patch, I assume that a lot of unit tests will fail as they check >>> exact error message wording. I'd recommend running the whole test suite with >>> your second patch revision. There is a short walkthrough how to set it up: >>> >>> http://freeipa.org/page/Testing >>> >>> Martin >>> >> >> You missed a few: >> >> $ git grep -En '%(\(.*?\))?r' >> >> Honza >> > > I think you have gone too far this time :-) It is not necessary (or wise) to > get rid of %r *everywhere* in the code. Thanks Honza for pointing that out. It seems I missed that in yesterday's review. Now, when I look at it, it indeed is not right. > > A few rules to keep in mind: > > * If it is not an error message, do not touch it (log messages are not error > messages BTW). > > * If it is an error message for an exception that does not inherit from > errors.PublicError, do not touch it (there might be a few exceptions, though). Right. But for example, your netaddr str conversions should be fine since the netaddr error is propagated up to the ValidationError. Martin > > * Use '%s' (%s with ticks) only for arguments whose value can be only str or > unicode. > > Honza > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Switch-r-specifiers-to-s-in-Public-errors.patch Type: text/x-patch Size: 10191 bytes Desc: not available URL: From pspacek at redhat.com Thu Nov 8 16:27:28 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Nov 2012 17:27:28 +0100 Subject: [Freeipa-devel] [PATCH 0088] Flush BIND caches if forwarder configuration was changed In-Reply-To: <20121108153357.GA11587@redhat.com> References: <5099187D.2070509@redhat.com> <20121108153357.GA11587@redhat.com> Message-ID: <509BDD70.3050909@redhat.com> On 11/08/2012 04:33 PM, Adam Tkac wrote: > On Tue, Nov 06, 2012 at 03:02:37PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Flush BIND caches if forwarder configuration was changed. >> > >> > Cache will not be flushed if old and new configurations are equal. >> > Without this optimization cache would be flushed during each zone refresh. > Ack, just please check my comment below. > > Regards, Adam > >> > From faed16b4861d4263ed942608d3767324fc2fae88 Mon Sep 17 00:00:00 2001 >> >From: Petr Spacek >> >Date: Tue, 6 Nov 2012 14:53:02 +0100 >> >Subject: [PATCH] Flush BIND caches if forwarder configuration was changed. >> > >> >Cache will not be flushed if old and new configurations are equal. >> >Without this optimization cache would be flushed during each zone refresh. >> > >> >Signed-off-by: Petr Spacek >> >--- >> > src/ldap_helper.c | 67 ++++++++++++++++++++++++++++++++++++++++++++----------- >> > 1 file changed, 54 insertions(+), 13 deletions(-) >> > >> >diff --git a/src/ldap_helper.c b/src/ldap_helper.c >> >index 4f004515f513ecf6459b3bddfbc5474fe3cfabd2..b36892b4e8180fb2a5f335e3fa1b5589dae8bf14 100644 >> >--- a/src/ldap_helper.c >> >+++ b/src/ldap_helper.c >> >@@ -975,11 +975,15 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, >> > { >> > const char *dn = entry->dn; >> > isc_result_t result; >> >+ isc_result_t orig_result; >> > ldap_valuelist_t values; >> > ldap_value_t *value; >> > isc_sockaddrlist_t addrs; >> > isc_boolean_t is_global_config; >> > isc_boolean_t fwdtbl_deletion_requested = ISC_TRUE; >> >+ isc_boolean_t fwdtbl_update_requested = ISC_FALSE; >> >+ dns_forwarders_t *old_setting = NULL; >> >+ dns_fixedname_t foundname; >> > const char *msg_use_global_fwds; >> > const char *msg_obj_type; >> > const char *msg_forwarders_not_def; >> >@@ -993,6 +997,7 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, >> > >> > REQUIRE(entry != NULL && inst != NULL && name != NULL); >> > ISC_LIST_INIT(addrs); >> >+ dns_fixedname_init(&foundname); >> > if (dns_name_equal(name, dns_rootname)) { >> > is_global_config = ISC_TRUE; >> > msg_obj_type = "global configuration"; >> >@@ -1083,16 +1088,49 @@ configure_zone_forwarders(ldap_entry_t *entry, ldap_instance_t *inst, >> > msg_obj_type, dn); >> > } >> > >> >- /* Set forward table up. */ >> >- CHECK(delete_forwarding_table(inst, name, msg_obj_type, dn)); >> >- result = dns_fwdtable_add(inst->view->fwdtable, name, &addrs, fwdpolicy); >> >+ /* Check for old and new forwarding settings equality. */ >> >+ result = dns_fwdtable_find2(inst->view->fwdtable, name, >> >+ dns_fixedname_name(&foundname), >> >+ &old_setting); >> >+ if (result == ISC_R_SUCCESS && >> >+ (dns_name_equal(name, dns_fixedname_name(&foundname)) == ISC_TRUE)) { >> >+ isc_sockaddr_t *s1, *s2; >> >+ >> >+ if (fwdpolicy != old_setting->fwdpolicy) >> >+ fwdtbl_update_requested = ISC_TRUE; >> >+ >> >+ /* Check address lists item by item. */ >> >+ for (s1 = ISC_LIST_HEAD(addrs), s2 = ISC_LIST_HEAD(old_setting->addrs); >> >+ s1 != NULL && s2 != NULL && !fwdtbl_update_requested; >> >+ s1 = ISC_LIST_NEXT(s1, link), s2 = ISC_LIST_NEXT(s2, link)) >> >+ if (!isc_sockaddr_equal(s1, s2)) >> >+ fwdtbl_update_requested = ISC_TRUE; >> >+ >> >+ if ((s1 == NULL) != (s2 == NULL)) > Although this is correct, something like > > if ((s1 != NULL) || (s2 != NULL)) > > or even > > if (!fwdtbl_update_requested && ((s1 != NULL) || (s2 != NULL))) > > shouldn't affect functionality and is more readable than rare (==) != (==) > construction. > > You don't have to pass the patch for review again, just directly push it. > Corrected, pushed to master and v2: 25ca3ce13a28b6c856025e887891cff55165d648 -- Petr^2 Spacek From pspacek at redhat.com Thu Nov 8 16:27:56 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 08 Nov 2012 17:27:56 +0100 Subject: [Freeipa-devel] [PATCH 0089] Bump NVR to 2.3 In-Reply-To: <20121108153414.GB11587@redhat.com> References: <5099195D.9020904@redhat.com> <20121108153414.GB11587@redhat.com> Message-ID: <509BDD8C.8000508@redhat.com> On 11/08/2012 04:34 PM, Adam Tkac wrote: > On Tue, Nov 06, 2012 at 03:06:21PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Bump NVR to 2.3. > Ack > Pushed to master and v2: bbc79c6d8b3573aee3672a0686b185ac13eb3c41 -- Petr^2 Spacek From rcritten at redhat.com Thu Nov 8 22:10:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Nov 2012 17:10:18 -0500 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <509A636C.6090408@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> Message-ID: <509C2DCA.2010804@redhat.com> Petr Viktorin wrote: > On 11/01/2012 06:34 PM, Petr Viktorin wrote: >> 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. >>>>>> >>>>> > > Dogtag recently changed the defaults it uses for pkispawn: we need to > set "pki_admin_name", "pki_admin_uid", "pki_security_domain_user" to > "admin" to retain current behavior. Attaching updated patch that does this. This may not be a new problem specific to this, I'm not sure yet, but uninstall doesn't untrack all the certificates in the new tomcat directory. It also seems to miss the ipaCert alias in httpd (my post-install check caught only this one). It may also be helpful to combine all the required patches up to this point into a single post, sort of a "we're ready for broader testing checkpoint". Sifting through this long thread finding all the various patches was tedious. I sure wouldn't want to actually push what I culled because I'm not 100% sure I got them all. Otherwise a single master install went well and the CA renewal code works. Will continue upgrade and replication testing. rob From mkosek at redhat.com Fri Nov 9 08:30:19 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Nov 2012 09:30:19 +0100 Subject: [Freeipa-devel] [PATCH] 332 Do not require resolvable nameserver in DNS install Message-ID: <509CBF1B.3090107@redhat.com> As named.conf and bind-dyndb-plugin is not set up yet during DNS configuration phase, IPA hostname (i.e. the nameserver) should not be required be to resolvable in this phase. https://fedorahosted.org/freeipa/ticket/3248 -- Martin Kosek Senior Software Engineer - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-332-do-not-require-resolvable-nameserver-in-dns-install.patch Type: text/x-patch Size: 2682 bytes Desc: not available URL: From mkosek at redhat.com Fri Nov 9 09:10:40 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Nov 2012 10:10:40 +0100 Subject: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone In-Reply-To: <50939BA5.9050305@redhat.com> References: <508F816C.2070809@redhat.com> <5092D516.4070207@redhat.com> <50938088.703@redhat.com> <509397AA.6030208@redhat.com> <50939BA5.9050305@redhat.com> Message-ID: <509CC890.5070005@redhat.com> On 11/02/2012 11:08 AM, Martin Kosek wrote: > On 11/02/2012 10:51 AM, Jan Cholasta wrote: >> Hi, >> >> On 2.11.2012 09:12, Martin Kosek wrote: >>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: >>>> 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 >>>> >>> >>> Fixed both. After a short discussion with Petr Spacek I also added a >>> possibility to set global dnsconfig to NONE. >>> >>> On a different note, I discovered that global forwarders in >>> bind-dyndb-ldap/bind are actually broken with referred bind-dyndb-ldap/bind >>> version. Thus, we may want to bump bind-dyndb-ldap version in spec when this is >>> resolved. (This should not affect diff in dns.py in any way). >>> >>> Martin >>> >> >> This might be a stupid question, but why is "NONE" in upper case and the rest >> of the values in lower case? >> >> Honza >> > > This really doesn't matter function-wise, as bind-dydnb-ldap does the > comparison in case insensitive way. My original intention was to be consistent > with other NONE values we use across IPA and to distinguish the value from > valid BIND values. > > But you are right that within dns plugin it makes more sense to have it all > lowercase. > > Updated patch attached. > > Martin > bind-dyndb-ldap with fixed forwarding has been released. Sending an updated patch for both master and ipa-3-0 branches with its version in our spec file. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-330-4-disable-global-forwarding-per-zone.patch Type: text/x-patch Size: 8463 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-330-4-ipa-3-0.patch Type: text/x-patch Size: 8460 bytes Desc: not available URL: From lroot at redhat.com Fri Nov 9 12:43:31 2012 From: lroot at redhat.com (Lynn Root) Date: Fri, 9 Nov 2012 07:43:31 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <165192460.7792597.1352464400117.JavaMail.root@redhat.com> Message-ID: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> The VERSION file and Makefile now handles 'beta' release parameters when making s/rpms. Ticket: https://fedorahosted.org/freeipa/ticket/2893 Lynn Root Associate Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: Add-Beta-versioning.patch Type: text/x-patch Size: 2523 bytes Desc: not available URL: From pvoborni at redhat.com Fri Nov 9 12:58:17 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Nov 2012 13:58:17 +0100 Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> References: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> Message-ID: <509CFDE9.70002@redhat.com> On 11/09/2012 01:43 PM, Lynn Root wrote: > The VERSION file and Makefile now handles 'beta' release parameters when making s/rpms. > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > Lynn Root > Associate Software Engineer > Red Hat Thanks for the patch. In a next patch, I'd suggest to follow patch-naming conventions https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the patch number into a mail subject, it helps to keeping track of patches. -- Petr Vobornik From lroot at redhat.com Fri Nov 9 13:04:43 2012 From: lroot at redhat.com (Lynn Root) Date: Fri, 9 Nov 2012 08:04:43 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <509CFDE9.70002@redhat.com> Message-ID: <1940773203.7804090.1352466283311.JavaMail.root@redhat.com> Ah thank you - was going by the "Submit Changes" portion in http://freeipa.org/page/Contribute#Development_Process, which has less information (but clearly did not notice the Patch Format link right above). Lynn Root Associate Software Engineer Red Hat ----- Original Message ----- From: "Petr Vobornik" To: "Lynn Root" Cc: freeipa-devel at redhat.com Sent: Friday, November 9, 2012 1:58:17 PM Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning On 11/09/2012 01:43 PM, Lynn Root wrote: > The VERSION file and Makefile now handles 'beta' release parameters when making s/rpms. > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > Lynn Root > Associate Software Engineer > Red Hat Thanks for the patch. In a next patch, I'd suggest to follow patch-naming conventions https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the patch number into a mail subject, it helps to keeping track of patches. -- Petr Vobornik From mkosek at redhat.com Fri Nov 9 13:07:05 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Nov 2012 14:07:05 +0100 Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <1940773203.7804090.1352466283311.JavaMail.root@redhat.com> References: <1940773203.7804090.1352466283311.JavaMail.root@redhat.com> Message-ID: <509CFFF9.2070906@redhat.com> Actually, there is a link in the Contribute wiki page for the Patch format page: ... Patch Format - Guidance about the patch format ... We may want to make it more visible... Martin On 11/09/2012 02:04 PM, Lynn Root wrote: > Ah thank you - was going by the "Submit Changes" portion in http://freeipa.org/page/Contribute#Development_Process, which has less information (but clearly did not notice the Patch Format link right above). > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Petr Vobornik" > To: "Lynn Root" > Cc: freeipa-devel at redhat.com > Sent: Friday, November 9, 2012 1:58:17 PM > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > On 11/09/2012 01:43 PM, Lynn Root wrote: >> The VERSION file and Makefile now handles 'beta' release parameters when making s/rpms. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/2893 >> >> Lynn Root >> Associate Software Engineer >> Red Hat > > Thanks for the patch. > > In a next patch, I'd suggest to follow patch-naming conventions > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > patch number into a mail subject, it helps to keeping track of patches. > From abokovoy at redhat.com Fri Nov 9 13:15:09 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 Nov 2012 15:15:09 +0200 Subject: [Freeipa-devel] [PATCH] 332 Do not require resolvable nameserver in DNS install In-Reply-To: <509CBF1B.3090107@redhat.com> References: <509CBF1B.3090107@redhat.com> Message-ID: <20121109131509.GB14850@redhat.com> On Fri, 09 Nov 2012, Martin Kosek wrote: >As named.conf and bind-dyndb-plugin is not set up yet during DNS >configuration phase, IPA hostname (i.e. the nameserver) should not >be required be to resolvable in this phase. > >https://fedorahosted.org/freeipa/ticket/3248 ACK. -- / Alexander Bokovoy From mkosek at redhat.com Fri Nov 9 13:26:18 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Nov 2012 14:26:18 +0100 Subject: [Freeipa-devel] [PATCH] 332 Do not require resolvable nameserver in DNS install In-Reply-To: <20121109131509.GB14850@redhat.com> References: <509CBF1B.3090107@redhat.com> <20121109131509.GB14850@redhat.com> Message-ID: <509D047A.5030309@redhat.com> On 11/09/2012 02:15 PM, Alexander Bokovoy wrote: > On Fri, 09 Nov 2012, Martin Kosek wrote: >> As named.conf and bind-dyndb-plugin is not set up yet during DNS >> configuration phase, IPA hostname (i.e. the nameserver) should not >> be required be to resolvable in this phase. >> >> https://fedorahosted.org/freeipa/ticket/3248 > ACK. > Pushed to master, ipa-3-0. Martin From jcholast at redhat.com Fri Nov 9 14:25:20 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 09 Nov 2012 15:25:20 +0100 Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <543051636.7383138.1352391745075.JavaMail.root@redhat.com> References: <543051636.7383138.1352391745075.JavaMail.root@redhat.com> Message-ID: <509D1250.5060404@redhat.com> On 8.11.2012 17:22, Lynn Root wrote: > Hmm I hope I understand well enough this time around. > > However, when I run the tests, there's this one error message I come across from `test_user[97]: user_add: Create u'tuser2'` - it throws `DatabaseError: Type or value exists`. I'm a bit lost on how to track this down. > > Once again - thanks for your help! > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Martin Kosek" > To: "Jan Cholasta" > Cc: "Lynn Root" , freeipa-devel at redhat.com > Sent: Thursday, November 8, 2012 8:46:42 AM > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors > > On 11/07/2012 06:46 PM, Jan Cholasta wrote: >> On 7.11.2012 16:08, Lynn Root wrote: >>> Third time is a charm? >>> >>> Lynn Root >>> Associate Software Engineer >>> Red Hat >>> >>> ----- Original Message ----- >>> From: "Jan Cholasta" >>> To: "Lynn Root" >>> Cc: freeipa-devel at redhat.com >>> Sent: Monday, November 5, 2012 10:25:32 AM >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors >>> >>> On 5.11.2012 09:43, Lynn Root wrote: >>>> Here's try #2! Adjusted patch attached. Let me know if there's anything >>>> else I've missed. >>>> >>>> Switched %r specifiers to '%s' in Public errors, and adjusted tests to >>>> expect no preceding 'u'. >>>> >>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & >>>> https://fedorahosted.org/freeipa/ticket/2588 >>>> >>>> Lynn Root >>>> Associate Software Engineer >>>> Red Hat >>>> >>>> ----- Original Message ----- >>>> From: "Martin Kosek" >>>> To: "Jan Cholasta" >>>> Cc: "Lynn Root" , freeipa-devel at redhat.com >>>> Sent: Tuesday, October 30, 2012 9:08:33 AM >>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public >>>> errors >>>> >>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: >>>>> Hi, >>>>> >>>>> On 29.10.2012 19:54, Lynn Root wrote: >>>>>> Hi all! >>>>>> >>>>>> This switch drops the preceding 'u' from strings in public error messages. >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>>>>> >>>>>> This patch also addresses the unfriendly 'u' from re-raising errors from the >>>>>> external call to netaddr.IPAddress by passing a bytestring to the function. >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>>>>> >>>>>> >>>>>> My first patch (and freeipa dev list email) ever! Let me know where there's >>>>>> room to improve. >>>>>> >>>>>> Lynn Root >>>>>> Associate Software Engineer >>>>>> Red Hat >>>>>> >>>>> >>>>> I think it would be nice if you kept the quotes around the values, as that is >>>>> probably the reason "%r" was used in the first place - i.e. use "'%s'" instead >>>>> of plain "%s". >>>> >>>> +1 >>>> >>>> With current patch, I assume that a lot of unit tests will fail as they check >>>> exact error message wording. I'd recommend running the whole test suite with >>>> your second patch revision. There is a short walkthrough how to set it up: >>>> >>>> http://freeipa.org/page/Testing >>>> >>>> Martin >>>> >>> >>> You missed a few: >>> >>> $ git grep -En '%(\(.*?\))?r' >>> >>> Honza >>> >> >> I think you have gone too far this time :-) It is not necessary (or wise) to >> get rid of %r *everywhere* in the code. > > Thanks Honza for pointing that out. It seems I missed that in yesterday's > review. Now, when I look at it, it indeed is not right. > >> >> A few rules to keep in mind: >> >> * If it is not an error message, do not touch it (log messages are not error >> messages BTW). >> >> * If it is an error message for an exception that does not inherit from >> errors.PublicError, do not touch it (there might be a few exceptions, though). > > Right. But for example, your netaddr str conversions should be fine since the > netaddr error is propagated up to the ValidationError. > > Martin > >> >> * Use '%s' (%s with ticks) only for arguments whose value can be only str or >> unicode. >> >> Honza >> > This is better, thanks. In OverlapError.format, remove the ticks around %s, as we expect a list here (I think we could make it look prettier, similar to what Martin did in , but I'm not sure if we want to do it in this ticket/patch). I'm not sure what to do about the ValidationError at ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it should be "TypeError(TYPE_ERROR % (self.name, self.type, value, type(value)))" instead, as by the time parameters are validated they are the right type. Also there is one %r you missed in ipalib/parameters.py:1554. Honza -- Jan Cholasta From rcritten at redhat.com Fri Nov 9 14:36:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2012 09:36:20 -0500 Subject: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone In-Reply-To: <509CC890.5070005@redhat.com> References: <508F816C.2070809@redhat.com> <5092D516.4070207@redhat.com> <50938088.703@redhat.com> <509397AA.6030208@redhat.com> <50939BA5.9050305@redhat.com> <509CC890.5070005@redhat.com> Message-ID: <509D14E4.70209@redhat.com> Martin Kosek wrote: > On 11/02/2012 11:08 AM, Martin Kosek wrote: >> On 11/02/2012 10:51 AM, Jan Cholasta wrote: >>> Hi, >>> >>> On 2.11.2012 09:12, Martin Kosek wrote: >>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: >>>>> 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 >>>>> >>>> >>>> Fixed both. After a short discussion with Petr Spacek I also added a >>>> possibility to set global dnsconfig to NONE. >>>> >>>> On a different note, I discovered that global forwarders in >>>> bind-dyndb-ldap/bind are actually broken with referred bind-dyndb-ldap/bind >>>> version. Thus, we may want to bump bind-dyndb-ldap version in spec when this is >>>> resolved. (This should not affect diff in dns.py in any way). >>>> >>>> Martin >>>> >>> >>> This might be a stupid question, but why is "NONE" in upper case and the rest >>> of the values in lower case? >>> >>> Honza >>> >> >> This really doesn't matter function-wise, as bind-dydnb-ldap does the >> comparison in case insensitive way. My original intention was to be consistent >> with other NONE values we use across IPA and to distinguish the value from >> valid BIND values. >> >> But you are right that within dns plugin it makes more sense to have it all >> lowercase. >> >> Updated patch attached. >> >> Martin >> > > bind-dyndb-ldap with fixed forwarding has been released. Sending an updated > patch for both master and ipa-3-0 branches with its version in our spec file. > > Martin > ACK x2 From mkosek at redhat.com Fri Nov 9 14:40:06 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Nov 2012 15:40:06 +0100 Subject: [Freeipa-devel] [PATCH] 330 Disable global forwarding per-zone In-Reply-To: <509D14E4.70209@redhat.com> References: <508F816C.2070809@redhat.com> <5092D516.4070207@redhat.com> <50938088.703@redhat.com> <509397AA.6030208@redhat.com> <50939BA5.9050305@redhat.com> <509CC890.5070005@redhat.com> <509D14E4.70209@redhat.com> Message-ID: <509D15C6.7090806@redhat.com> On 11/09/2012 03:36 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 11/02/2012 11:08 AM, Martin Kosek wrote: >>> On 11/02/2012 10:51 AM, Jan Cholasta wrote: >>>> Hi, >>>> >>>> On 2.11.2012 09:12, Martin Kosek wrote: >>>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: >>>>>> 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 >>>>>> >>>>> >>>>> Fixed both. After a short discussion with Petr Spacek I also added a >>>>> possibility to set global dnsconfig to NONE. >>>>> >>>>> On a different note, I discovered that global forwarders in >>>>> bind-dyndb-ldap/bind are actually broken with referred bind-dyndb-ldap/bind >>>>> version. Thus, we may want to bump bind-dyndb-ldap version in spec when >>>>> this is >>>>> resolved. (This should not affect diff in dns.py in any way). >>>>> >>>>> Martin >>>>> >>>> >>>> This might be a stupid question, but why is "NONE" in upper case and the rest >>>> of the values in lower case? >>>> >>>> Honza >>>> >>> >>> This really doesn't matter function-wise, as bind-dydnb-ldap does the >>> comparison in case insensitive way. My original intention was to be consistent >>> with other NONE values we use across IPA and to distinguish the value from >>> valid BIND values. >>> >>> But you are right that within dns plugin it makes more sense to have it all >>> lowercase. >>> >>> Updated patch attached. >>> >>> Martin >>> >> >> bind-dyndb-ldap with fixed forwarding has been released. Sending an updated >> patch for both master and ipa-3-0 branches with its version in our spec file. >> >> Martin >> > > ACK x2 Pushed to master, ipa-3-0. Martin From jhrozek at redhat.com Fri Nov 9 15:06:29 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 9 Nov 2012 16:06:29 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <5098C2D2.9060309@redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> <5098C2D2.9060309@redhat.com> Message-ID: <20121109150629.GR31678@hendrix.brq.redhat.com> On Tue, Nov 06, 2012 at 08:57:06AM +0100, Jan Cholasta wrote: > On 29.10.2012 17:21, Jakub Hrozek wrote: > >An improvement based on Honza's suggestion. > > > > You might want to remove the try block around > "sssdconfig.activate_service('autofs')". If it throws NoServiceError > at this point, there is something really broken in SSSDConfig, in > which case it is better to display a traceback rather than a nice > error message IMO. > In retrospective, I agree. We can't try-except every line. -------------- next part -------------- >From 77869a71f758265f45d69bbebf158b0cf10e9079 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Mon, 29 Oct 2012 10:06:45 +0100 Subject: [PATCH] Make enabling the autofs service more robust --- ipa-client/ipa-install/ipa-client-automount | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount index 182f9f659dc3bfca198fc254f1a51047b3d9d31f..10512a72a278bc61ec1081f4c7d26bd4111deb31 100755 --- a/ipa-client/ipa-install/ipa-client-automount +++ b/ipa-client/ipa-install/ipa-client-automount @@ -154,14 +154,18 @@ def configure_autofs_sssd(fstore, statestore, autodiscover, options): except Exception, e: sys.exit(e) - if 'autofs' not in sssdconfig.list_services(): + try: sssdconfig.new_service('autofs') + except SSSDConfig.ServiceAlreadyExists: + pass + except SSSDConfig.ServiceNotRecognizedError: + root_logger.error("Unable to activate the Autofs service in SSSD config.") + root_logger.info( + "Please make sure you have SSSD built with autofs support installed.") + root_logger.info( + "Configure autofs support manually in /etc/sssd/sssd.conf.") - try: - sssdconfig.activate_service('autofs') - except SSSDConfig.NoServiceError: - print "Unable to activate the autofs service in SSSD config." - root_logger.debug("Unable to activate the autofs service in SSSD config.") + sssdconfig.activate_service('autofs') domain = None for name in domains: -- 1.7.12.1 From rcritten at redhat.com Fri Nov 9 16:43:53 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Nov 2012 11:43:53 -0500 Subject: [Freeipa-devel] Announcing FreeIPA v3.0.1 Release Message-ID: <509D32C9.3070305@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.0.1. It can be downloaded from http://www.freeipa.org/page/Downloads. A build will be submitted to updates-testing for Fedora 18 soon. == Highlights in 3.0.1 == * Change the way we calculate what services IPA is managing so that startup/shutdown with systemd works. * Resolve external members from trusted domain via Global Catalog. * Improvements to ipa-client-automount. * Man page and command help improvements. * Added option to configure DNS forwarding by zone. == 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 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-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 3.0.0 == Alexander Bokovoy (4): * Remove bogus check for smbpasswd * Warn about DNA plugin configuration when working with local ID ranges * Resolve external members from trusted domain via Global Catalog * Clarify trust-add help regarding multiple runs against the same domain Jakub Hrozek (1): * ipa-client-automount: Add the autofs service if it doesn't exist yet Jan Cholasta (1): * Reword description of the --passsync option of ipa-replica-manage. John Dennis (1): * log dogtag errors Martin Kosek (9): * Create reverse zone in unattended mode * Add fallback for httpd restarts on sysV platforms * Report ipa-upgradeconfig errors during RPM upgrade * Avoid uninstalling dependencies during package lifetime * Remove servertrls and clientctrls options from rename_s * Use common encoding in modlist generation * Process relative nameserver DNS record correctly * Do not require resolvable nameserver in DNS install * Disable global forwarding per-zone Nikolai Kondrashov (1): * Add uninstall command hints to ipa-*-install Petr Viktorin (3): * ipautil.run: Log the command line before running the command * ipa-replica-install: Use configured IPA DNS servers in forward/reverse resolution check * Make sure the CA is running when starting services Petr Vobornik (2): * Simpler instructions to generate certificate * Fixed incorrect link to browser config after session expiration Rob Crittenden (11): * Use TLS for CA replication * Don't configure a reverse zone if not desired in interactive installer. * Fix requesting certificates that contain subject altnames. * Improve error messages in ipa-replica-manage. * Close connection after each request, avoid NSS shutdown problem. * The SECURE_NFS value needs to be lower-case yes on SysV systems. * After unininstall see if certmonger is still tracking any of our certs. * Wait for the directory server to come up when updating the agent certificate. * Set MLS/MCS for user_u context to what will be on remote systems. * Handle the case where there are no replicas with list-ruv * Become IPA 3.0.1 Simo Sorce (6): * Add support for using AES fo cross-realm TGTs * Preserve original service_name in services * Save service name on service startup * Get list of service from LDAP only at startup * Revert "Save service name on service startup" * Save service name on service startup/shutdown Sumit Bose (4): * Fix various issues found by Coverity * extdom: handle INP_POSIX_UID and INP_POSIX_GID requests * Restart httpd if ipa-server-trust-ad is installed or updated * ipa-adtrust-install: allow to reset te NetBIOS domain name Tomas Babej (4): * Forbid overlapping primary and secondary rid ranges * Refactoring of default.conf man page * Make service naming in ipa-server-install consistent * IPA Server check in ipa-replica-manage From jhrozek at redhat.com Fri Nov 9 16:58:43 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 9 Nov 2012 17:58:43 +0100 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <509A8A4E.2050807@redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> <20121106235321.GC2813@hendrix.redhat.com> <509A8A4E.2050807@redhat.com> Message-ID: <20121109165843.GV31678@hendrix.brq.redhat.com> On Wed, Nov 07, 2012 at 05:20:30PM +0100, Martin Kosek wrote: > On 11/07/2012 12:53 AM, Jakub Hrozek wrote: > > On Wed, Oct 31, 2012 at 01:22:52PM +0100, Martin Kosek wrote: > >> On 10/31/2012 11:00 AM, Jakub Hrozek wrote: > >>> On Mon, Oct 22, 2012 at 02:14:00PM -0400, Simo Sorce wrote: > >>>> On Mon, 2012-10-22 at 17:15 +0200, Martin Kosek wrote: > >>>>> On 10/08/2012 08:27 PM, Rob Crittenden wrote: > >>>>>> Jakub Hrozek wrote: > >>>>>>> On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> the attached patches add the directory the SSSD writes domain-realm > >>>>>>>>> mappings as includedir to krb5.conf when installing the client. > >>>>>>>>> > >>>>>>>>> [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for > >>>>>>>>> options > >>>>>>>>> ipachangeconf only allows one delimeter between keys and values. This > >>>>>>>>> patch adds the possibility of also specifying "delim" in the option > >>>>>>>>> dictionary to override the default delimeter. > >>>>>>>>> > >>>>>>>>> On a slightly-unrelated note, we really should think about adopting > >>>>>>>>> Augeas. Changing configuration with home-grown scripts is getting > >>>>>>>>> tricky. > >>>>>>>>> > >>>>>>>>> [PATCH 2/3] Specify includedir in krb5.conf on new installs > >>>>>>>>> This patch utilizes the new functionality from the previous patch to > >>>>>>>>> add > >>>>>>>>> the includedir on top of the krb5.conf file > >>>>>>>>> > >>>>>>>>> [PATCH 3/3] Add the includedir to krb5.conf on upgrades > >>>>>>>>> This patch is completely untested and I'm only posting it to get > >>>>>>>>> opinions. At first I was going to use an upgrade script in %post but > >>>>>>>>> then I thought it would be overengineering when all we want to do is > >>>>>>>>> prepend one line.. Would a simple munging like this be acceptable or > >>>>>>>>> shall I write a full script? > >>>>>>>> > >>>>>>>> NACK, using a scriptlet is fine, but not the way you did, as it has a huge > >>>>>>>> race condition where krb5.conf exists and has only one line in it (the > >>>>>>>> include line). > >>>>>>>> > >>>>>>>> You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew > >>>>>>>> Then cat the contents of the existing file in i:t cat /etc/krb.conf >> > >>>>>>>> /etc/krb.conf.ipanew > >>>>>>>> And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf > >>>>>>>> > >>>>>>>> This method is also safe wrt something killing the yum process ... > >>>>>>>> > >>>>>>>> Simo. > >>>>>>> > >>>>>>> I'm attaching a new revision of the patches not even two months after > >>>>>>> the original nack. > >>>>>>> > >>>>>>> I also think it might be nice to have a more general way of upgrading > >>>>>>> the client config so I filed > >>>>>>> https://fedorahosted.org/freeipa/ticket/3149 > >>>>>> > >>>>>> I don't think grepping for a string is an effective way to determine if the > >>>>>> client has been configured. Someone could have removed that line. > >>>>>> > >>>>>> I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it exists > >>>>>> and has more than 2 lines in it ([files] + one other file) then it is safe to > >>>>>> say the client is configured, or at least partially configured. > >>>>>> > >>>>>> rob > >>>>>> > >>>>> > >>>>> I just found one more issue. What if ipa-client-install is run with --no-sssd > >>>>> option? In that case I assume we should not include the SSSD's krb5.include.d, > >>>>> right? The same would also appy for upgrades, we would need to check if client > >>>>> was actually configured with SSSD before mangling their krb5.conf. > >>>> > >>>> Yeah that's right, we should have all sssd related changes under a > >>>> conditional that is true only when sssd is enabled. > >>>> > >>>> Simo. > >>> > >>> OK, new patches are attached. In new installs, the includedir is only > >>> added when options.sssd is true. During upgrades, I checked for > >>> sssd.conf's existence, I'm not sure if there's any other way to check if > >>> the client was configured with sssd? > >> > >> Hello Jakub, thanks for these patches. I think that checking if /etc/sssd.conf > >> exists as actually not so bad way to test if it was configured. Anyway, I did > >> few tests on server and client but I still see few issues: > >> > >> 1) SELinux context of krb5.conf is not as expected (but I am not sure what real > >> issue could that cause): > >> > >> # restorecon -FvvR /etc/krb5.conf > >> restorecon reset /etc/krb5.conf context > >> unconfined_u:object_r:etc_t:s0->system_u:object_r:krb5_conf_t:s0 > >> > > > > Fixed. Thanks, I shouldn have noticed that doing mv would just replace > > the original context. > > > >> 2) I can no longer kinit on IPA server after applying your patch > >> # rpm -q sssd > >> sssd-1.9.90-0.20121030T1436Zgitf46bf56.fc17.x86_64 > >> # rpm -Uvh --force freeipa-*.rpm > >> # head -n 5 /etc/krb5.conf > >> includedir /var/lib/sss/pubconf/krb5.include.d/ > >> [logging] > >> default = FILE:/var/log/krb5libs.log > >> kdc = FILE:/var/log/krb5kdc.log > >> admin_server = FILE:/var/log/kadmind.log > >> # KRB5_TRACE=/dev/stdout kinit admin > >> [21059] 1351684052.658548: Getting initial credentials for > >> admin at IDM.LAB.BOS.REDHAT.COM > >> [21059] 1351684052.665269: Sending request (200 bytes) to IDM.LAB.BOS.REDHAT.COM > >> [21059] 1351684052.665989: Resolving hostname vm-044.idm.lab.bos.redhat.com > >> [21059] 1351684052.667511: Sending initial UDP request to dgram 10.16.78.44:88 > >> [21059] 1351684052.672514: Received answer from dgram 10.16.78.44:88 > >> [21059] 1351684052.672653: Response was from master KDC > >> [21059] 1351684052.672751: Received error from KDC: -1765328370/KDC has no > >> support for encryption type > >> kinit: KDC has no support for encryption type while getting initial credentials > >> > >> > >> Now when I comment includedir: > >> # head -n 5 /etc/krb5.conf > >> # kinit admin > >> Password for admin at IDM.LAB.BOS.REDHAT.COM: > >> # echo $? > >> 0 > >> > >> When I upgraded client machine (without krb5kdc), kinit worked fine. Does that > >> mean that krb5.conf can only be changed on client machines? > >> > > > > I'm still looking into this. I'm not sure why kinit does that and why it > > does that on the IPA server only. Unfortunately the default krb5 package > > is so optimized that I need to rebuild one without optimizations. > > > >> 3) We should also add Requires on sssd >= 1.9.0 in FreeIPA spec file to pick up > >> the new feature. Otherwise I just get an error on client: > >> > >> # kinit admin > >> kinit: Included profile directory could not be read while initializing Kerberos > >> 5 library > >> > > > > Done > > > >> 4) (Optional) I think we can make the process of checking if IPA is configured > >> easier and follow a similar way that Sumit did: > >> https://fedorahosted.org/freeipa/changeset/fe66fbe637132ac5eb22eea388e2261f33497bf5/ > >> > >> This section: > >> > >> +restore=0 > >> +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l > >> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') > >> + > >> +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > >> + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > >> 2>/dev/null ; then > >> > >> could then be replaced by something like this: > >> > >> python -c "import sys; from ipapython import ipautil; sys.exit(0 if > >> ipapython.is_ipaclient_configured() else 1);" > /dev/null 2>&1 > >> if [ $? -eq 0 ]; then > >> > >> I am not saying you need to do this step, this can be done later by us. > > > > That code currently only exists for IPA server, right? At least judging > > by: > > from ipaserver.install import installutils; > > > > Then I would prefer to do it separately. It's a good idea, though, the > > postscript as it is now is ugly. > > > > Thanks for updated patch, now when I updated to the most recent sssd, kinit > worked for me even though IPA master krb5.conf was updated. Few more issues I > found follows: > That must have been krb5 updated, sssd does not have much to do with bare kinit. > rpmbuild --define "_topdir /root/freeipa-master/rpmbuild" -ba freeipa.spec > error: line 179: Bad Requireflags: qualifiers: Requires(postttrans): > policycoreutils > make: *** [rpms] Error 1 > > This is the reason: > +Requires(postttrans): policycoreutils > should be: > +Requires(posttrans): policycoreutils > Thanks, the requires were misplaced, they were present in the server section and should have been in the client section..and because I only tested with make client-rpms (see below), I didn't notice the typo. > 2) IPA server krb5.conf is not updated for clean server/replica installation. > The includedir can get there only with next package update. > > install/share/krb5.conf.template would also need to be updated. > Done. I didn't realize the codepaths were different. > > Besides these 2 issues (and the SELinux ones), the patch should be good to go. > > Martin New patches are attached. -------------- next part -------------- >From 9a98459b258da23529a072b9d77568628d2486e6 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Fri, 17 Aug 2012 11:19:03 +0200 Subject: [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for options --- ipa-client/ipaclient/ipachangeconf.py | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/ipa-client/ipaclient/ipachangeconf.py b/ipa-client/ipaclient/ipachangeconf.py index 6cf47b807957c245fe03ff4259e35526c49175a9..bdc5579fccd82193e837b5e86cbc694c2619317c 100644 --- a/ipa-client/ipaclient/ipachangeconf.py +++ b/ipa-client/ipaclient/ipachangeconf.py @@ -174,9 +174,12 @@ class IPAChangeConf: self.subsectdel[1])) continue if o['type'] == "option": + delim = o.get('delim', self.dassign) + if delim not in self.assign: + raise ValueError('Unknown delim "%s" must be one of "%s"' % (delim, " ".join([d for d in self.assign]))) output.append(self._dump_line(self.indent[level], o['name'], - self.dassign, + delim, o['value'])) continue if o['type'] == "comment": @@ -200,13 +203,21 @@ class IPAChangeConf: 'type': 'comment', 'value': value.rstrip()} # pylint: disable=E1103 + o = dict() parts = line.split(self.dassign, 1) if len(parts) < 2: - raise SyntaxError('Syntax Error: Unknown line format') + # The default assign didn't match, try the non-default + for d in self.assign[1:]: + parts = line.split(d, 1) + if len(parts) >= 2: + o['delim'] = d + break - return {'name': parts[0].strip(), - 'type': 'option', - 'value': parts[1].rstrip()} + if 'delim' not in o: + raise SyntaxError, 'Syntax Error: Unknown line format' + + o.update({'name':parts[0].strip(), 'type':'option', 'value':parts[1].rstrip()}) + return o def findOpts(self, opts, type, name, exclude_sections=False): @@ -256,13 +267,13 @@ class IPAChangeConf: 'value': val}) continue if o['type'] == 'option': - val = self._dump_line(self.indent[level], - o['name'], - self.dassign, - o['value']) - opts.append({'name': 'comment', - 'type': 'comment', - 'value': val}) + delim = o.get('delim', self.dassign) + if delim not in self.assign: + val = self._dump_line(self.indent[level], + o['name'], + delim, + o['value']) + opts.append({'name':'comment', 'type':'comment', 'value':val}) continue if o['type'] == 'comment': opts.append(o) -- 1.7.12.1 -------------- next part -------------- >From 550e10db91f82db916ac12cc1559eb1dbf901703 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 31 Oct 2012 10:59:04 +0100 Subject: [PATCH 2/3] Specify includedir in krb5.conf on new installs --- freeipa.spec.in | 2 +- install/share/krb5.conf.template | 2 ++ ipa-client/ipa-install/ipa-client-install | 7 ++++++- 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 3f446032360a37d6aeb55c287eea2c0cd088bf31..6c631315506fc0d7dfc05bbb8e7e6cefe3146004 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -84,7 +84,7 @@ BuildRequires: pylint BuildRequires: python-polib BuildRequires: libipa_hbac-python BuildRequires: python-memcached -BuildRequires: sssd >= 1.8.0 +BuildRequires: sssd >= 1.9.2 BuildRequires: python-lxml BuildRequires: python-pyasn1 >= 0.0.9a BuildRequires: python-dns diff --git a/install/share/krb5.conf.template b/install/share/krb5.conf.template index f8b1a6f09868c55e47f21279b6d061fbd8251171..ed30b9e0fe37151c097d25e8b2e9fcf600a0a690 100644 --- a/install/share/krb5.conf.template +++ b/install/share/krb5.conf.template @@ -1,3 +1,5 @@ +includedir /var/lib/sss/pubconf/krb5.include.d + [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 190efb183d8c96e2c9665cf51d5346dc1111ae24..5bfaf3319e3f3f015059150b7cb9030495f3c7b8 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -729,7 +729,7 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, filename, client_domain): krbconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") - krbconf.setOptionAssignment(" = ") + krbconf.setOptionAssignment((" = ", " ")) krbconf.setSectionNameDelimiters(("[","]")) krbconf.setSubSectionDelimiters(("{","}")) krbconf.setIndent((""," "," ")) @@ -737,6 +737,11 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, opts = [{'name':'comment', 'type':'comment', 'value':'File modified by ipa-client-install'}, {'name':'empty', 'type':'empty'}] + # SSSD include dir + if options.sssd: + opts.append({'name':'includedir', 'type':'option', 'value':'/var/lib/sss/pubconf/krb5.include.d/', 'delim':' '}) + opts.append({'name':'empty', 'type':'empty'}) + #[libdefaults] libopts = [{'name':'default_realm', 'type':'option', 'value':cli_realm}] if not dnsok or not cli_kdc or options.force: -- 1.7.12.1 -------------- next part -------------- >From 52a92503efa0404f1a5dc4b29b295c5860b1ca85 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 31 Oct 2012 10:15:28 +0100 Subject: [PATCH 3/3] Add the includedir to krb5.conf on upgrades --- freeipa.spec.in | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6c631315506fc0d7dfc05bbb8e7e6cefe3146004..e2d07085dbf3baa990081323f32fa80eca238576 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -283,6 +283,7 @@ Requires: libsss_autofs Requires: autofs Requires: libnfsidmap Requires: nfs-utils +Requires(posttrans): policycoreutils Obsoletes: ipa-client >= 1.0 @@ -611,6 +612,19 @@ if [ $1 -eq 0 ]; then fi %endif +%posttrans client +# Has the client been configured? +restore=0 +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') + +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf 2>/dev/null ; then + echo "includedir /var/lib/sss/pubconf/krb5.include.d/" > /etc/krb5.conf.ipanew + cat /etc/krb5.conf >> /etc/krb5.conf.ipanew + mv /etc/krb5.conf.ipanew /etc/krb5.conf + /sbin/restorecon /etc/krb5.conf + fi +fi %if ! %{ONLY_CLIENT} %files server -f server-python.list -- 1.7.12.1 From jdennis at redhat.com Fri Nov 9 20:50:15 2012 From: jdennis at redhat.com (John Dennis) Date: Fri, 09 Nov 2012 15:50:15 -0500 Subject: [Freeipa-devel] apache segfaults Message-ID: <509D6C87.4040405@redhat.com> I'm wondering if anyone else has seen this. I've been running the server with debug=True to verify it's behaving properly which means I've been reading /var/log/httpd/error_log and what to my wondering eyes did appear? [core:notice] [pid 9089] AH00052: child pid 9092 exit signal Segmentation fault (11) The server seems to be running normally, except after the above segfault notice there are debug messages about loading our plugins which seems to imply it's restarting a wsgi process, but it's not clear that's what's actually happening. This is on a F18 vm. The only other information in the log is: *** glibc detected *** /usr/sbin/httpd: corrupted double-linked list: 0x00007f60952cddc0 *** So a few questions: * anybody seen something similar? * does apache respawn a child process that crashes? (the log seems to suggest so) * does systemd respawn a daemon that crashes? * how does one get a coredump? (Is that an apache config item?, a systemd flag?) * any reason to believe this has anything to do with us? * any suggestions for diagnosing this? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Fri Nov 9 20:59:17 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 09 Nov 2012 15:59:17 -0500 Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <509CFDE9.70002@redhat.com> References: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> <509CFDE9.70002@redhat.com> Message-ID: <509D6EA5.8040403@redhat.com> On 11/09/2012 07:58 AM, Petr Vobornik wrote: > On 11/09/2012 01:43 PM, Lynn Root wrote: >> The VERSION file and Makefile now handles 'beta' release parameters >> when making s/rpms. >> >> Ticket: https://fedorahosted.org/freeipa/ticket/2893 >> >> Lynn Root >> Associate Software Engineer >> Red Hat > > Thanks for the patch. > > In a next patch, I'd suggest to follow patch-naming conventions > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > patch number into a mail subject, it helps to keeping track of patches. > OK, finally. It is a good time to ask. Several years ago when we adopted this format I was wondering what is the exact sequence of operations one should do to make the resulting patch follow the format. I never figured it out so I never adopted the format for the patches I provide for ding-libs from time to time. So in the title of the commit message I put (for example): [INI] Remove code that allows dup sections the I do git format-patch with arguments this translates into a patch with name 0001-INI-Remove-code-that-allows-dup-sections.patch So am I supposed to the manually rename the patch to follow the format or have a script to do that or there is some other way that I do not know about that would allow me to provide patches following the format above right out of the git format-patch so that I do not need to do the renaming? Please advise. -- 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 Fri Nov 9 22:52:45 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 09 Nov 2012 17:52:45 -0500 Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <509D6EA5.8040403@redhat.com> References: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> <509CFDE9.70002@redhat.com> <509D6EA5.8040403@redhat.com> Message-ID: <1352501565.10327.385.camel@willson.li.ssimo.org> On Fri, 2012-11-09 at 15:59 -0500, Dmitri Pal wrote: > On 11/09/2012 07:58 AM, Petr Vobornik wrote: > > On 11/09/2012 01:43 PM, Lynn Root wrote: > >> The VERSION file and Makefile now handles 'beta' release parameters > >> when making s/rpms. > >> > >> Ticket: https://fedorahosted.org/freeipa/ticket/2893 > >> > >> Lynn Root > >> Associate Software Engineer > >> Red Hat > > > > Thanks for the patch. > > > > In a next patch, I'd suggest to follow patch-naming conventions > > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > > patch number into a mail subject, it helps to keeping track of patches. > > > OK, finally. It is a good time to ask. > > Several years ago when we adopted this format I was wondering what is > the exact sequence of operations one should do to make the resulting > patch follow the format. > I never figured it out so I never adopted the format for the patches I > provide for ding-libs from time to time. > > So in the title of the commit message I put (for example): > [INI] Remove code that allows dup sections > > the I do git format-patch with arguments > this translates into a patch with name > 0001-INI-Remove-code-that-allows-dup-sections.patch > > So am I supposed to the manually rename the patch to follow the format > or have a script to do that or there is some other way that I do not > know about that would allow me to provide patches following the format > above right out of the git format-patch so that I do not need to do the > renaming? This patch format rule is followed only on freeipa-devel for Freeipa patches. Some people have developed scripts to do the renaming automatically. ding libs stuff is tracked on sssd-devel which does not use this patch format rule, we enver felt it necessary in sssd development. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Nov 9 23:08:01 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 09 Nov 2012 18:08:01 -0500 Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <1352501565.10327.385.camel@willson.li.ssimo.org> References: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> <509CFDE9.70002@redhat.com> <509D6EA5.8040403@redhat.com> <1352501565.10327.385.camel@willson.li.ssimo.org> Message-ID: <509D8CD1.6090401@redhat.com> On 11/09/2012 05:52 PM, Simo Sorce wrote: > On Fri, 2012-11-09 at 15:59 -0500, Dmitri Pal wrote: >> On 11/09/2012 07:58 AM, Petr Vobornik wrote: >>> On 11/09/2012 01:43 PM, Lynn Root wrote: >>>> The VERSION file and Makefile now handles 'beta' release parameters >>>> when making s/rpms. >>>> >>>> Ticket: https://fedorahosted.org/freeipa/ticket/2893 >>>> >>>> Lynn Root >>>> Associate Software Engineer >>>> Red Hat >>> Thanks for the patch. >>> >>> In a next patch, I'd suggest to follow patch-naming conventions >>> https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the >>> patch number into a mail subject, it helps to keeping track of patches. >>> >> OK, finally. It is a good time to ask. >> >> Several years ago when we adopted this format I was wondering what is >> the exact sequence of operations one should do to make the resulting >> patch follow the format. >> I never figured it out so I never adopted the format for the patches I >> provide for ding-libs from time to time. >> >> So in the title of the commit message I put (for example): >> [INI] Remove code that allows dup sections >> >> the I do git format-patch with arguments >> this translates into a patch with name >> 0001-INI-Remove-code-that-allows-dup-sections.patch >> >> So am I supposed to the manually rename the patch to follow the format >> or have a script to do that or there is some other way that I do not >> know about that would allow me to provide patches following the format >> above right out of the git format-patch so that I do not need to do the >> renaming? > This patch format rule is followed only on freeipa-devel for Freeipa > patches. > > Some people have developed scripts to do the renaming automatically. > > ding libs stuff is tracked on sssd-devel which does not use this patch > format rule, we enver felt it necessary in sssd development. > > Simo. > I understand. It was more a conceptual question. It looks like the answer "there are scripts to do renaming that each developer has". Thanks. This is all I was looking for. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Sat Nov 10 11:13:31 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 10 Nov 2012 13:13:31 +0200 Subject: [Freeipa-devel] apache segfaults In-Reply-To: <509D6C87.4040405@redhat.com> References: <509D6C87.4040405@redhat.com> Message-ID: <20121110111331.GB3360@redhat.com> On Fri, 09 Nov 2012, John Dennis wrote: >I'm wondering if anyone else has seen this. I've been running the >server with debug=True to verify it's behaving properly which means >I've been reading /var/log/httpd/error_log and what to my wondering >eyes did appear? > >[core:notice] [pid 9089] AH00052: child pid 9092 exit signal >Segmentation fault (11) > >The server seems to be running normally, except after the above >segfault notice there are debug messages about loading our plugins >which seems to imply it's restarting a wsgi process, but it's not >clear that's what's actually happening. This is on a F18 vm. > >The only other information in the log is: > >*** glibc detected *** /usr/sbin/httpd: corrupted double-linked list: >0x00007f60952cddc0 *** > >So a few questions: > >* anybody seen something similar? I do see it, on F18 VMs. > >* does apache respawn a child process that crashes? (the log seems to >suggest so) yes. > >* does systemd respawn a daemon that crashes? Yes, if it is the main process for the service from systemd perspective. No for Apache since master process did not fail from perspective of systemd. > >* how does one get a coredump? (Is that an apache config item?, a >systemd flag?) Theoretically, systemd sends all coredumps it sees to journal. systemd-coredumpctl(1) is then used to list and extract coredumps. >* any reason to believe this has anything to do with us? I vaguely remember seeing some bugs in the Fedora Bugzilla about mod_wsgi failures in recent Apache updates on F18. Cannot find them now. >* any suggestions for diagnosing this? Try to set LimitCORE in httpd.service to non-zero value (as in RLIMIT_CORE from setrlimit(2)). Reload systemd configuration with 'systemctl daemon-reload' and hope to get core in the journal. -- / Alexander Bokovoy From abokovoy at redhat.com Sat Nov 10 11:41:35 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 10 Nov 2012 13:41:35 +0200 Subject: [Freeipa-devel] apache segfaults In-Reply-To: <20121110111331.GB3360@redhat.com> References: <509D6C87.4040405@redhat.com> <20121110111331.GB3360@redhat.com> Message-ID: <20121110114135.GC3360@redhat.com> On Sat, 10 Nov 2012, Alexander Bokovoy wrote: >On Fri, 09 Nov 2012, John Dennis wrote: >>I'm wondering if anyone else has seen this. I've been running the >>server with debug=True to verify it's behaving properly which means >>I've been reading /var/log/httpd/error_log and what to my wondering >>eyes did appear? >> >>[core:notice] [pid 9089] AH00052: child pid 9092 exit signal >>Segmentation fault (11) >> >>The server seems to be running normally, except after the above >>segfault notice there are debug messages about loading our plugins >>which seems to imply it's restarting a wsgi process, but it's not >>clear that's what's actually happening. This is on a F18 vm. >> >>The only other information in the log is: >> >>*** glibc detected *** /usr/sbin/httpd: corrupted double-linked >>list: 0x00007f60952cddc0 *** >> >>So a few questions: >> >>* anybody seen something similar? >I do see it, on F18 VMs. Actually, found it: https://bugzilla.redhat.com/show_bug.cgi?id=867276 -- / Alexander Bokovoy From jdennis at redhat.com Sat Nov 10 13:42:22 2012 From: jdennis at redhat.com (John Dennis) Date: Sat, 10 Nov 2012 08:42:22 -0500 Subject: [Freeipa-devel] apache segfaults In-Reply-To: <20121110114135.GC3360@redhat.com> References: <509D6C87.4040405@redhat.com> <20121110111331.GB3360@redhat.com> <20121110114135.GC3360@redhat.com> Message-ID: <509E59BE.5040408@redhat.com> On 11/10/2012 06:41 AM, Alexander Bokovoy wrote: >>> * anybody seen something similar? >> I do see it, on F18 VMs. > Actually, found it: > https://bugzilla.redhat.com/show_bug.cgi?id=867276 Ah thank you Alexander and Martin, this is exactly the problem I was seeing, good to know there is a fix. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From arta.moeini at gmail.com Sat Nov 10 14:14:43 2012 From: arta.moeini at gmail.com (mohammad moeini) Date: Sat, 10 Nov 2012 18:14:43 +0400 Subject: [Freeipa-devel] Freeipa-devel Digest, Vol 66, Issue 34 In-Reply-To: References: Message-ID: Dear Guyes i'm AAA Server administrator , I use freeipa for AAA server i Have a Centos server and 50 client debian i use the ipa v 3 and now have problem with join ipa clients becuse not exisixt upper 2.1.4 package in debian distru when i want compile ipa client on the folder ipa-client in cource get the error krb5.h not exist , please help me anout dependency on the freeipa v 3 o r say to me how can i config ipa v 3 for supporting ipa client v 2.1.4 Another my question is about sudoers i config sudoers seem of the all domcumention free ipa and testing many soulution from Ldap or freeipa or another way seem nscd.conf or sssd.conf or .... but not working and just say to me your user is not is sudoers ,,, i don't know i must doing any config in ldap schema or must create suoers group please help me ,,, i run freeipa for first time in middle ease and i want grow this at this point of world Regards Moeini On Fri, Nov 9, 2012 at 6:40 PM, wrote: > Send Freeipa-devel mailing list submissions to > freeipa-devel at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-devel > or, via email, send a message with subject or body 'help' to > freeipa-devel-request at redhat.com > > You can reach the person managing the list at > freeipa-devel-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-devel digest..." > > > Today's Topics: > > 1. [PATCH] Add Beta versioning (Lynn Root) > 2. Re: [PATCH] Add Beta versioning (Petr Vobornik) > 3. Re: [PATCH] Add Beta versioning (Lynn Root) > 4. Re: [PATCH] Add Beta versioning (Martin Kosek) > 5. Re: [PATCH] 332 Do not require resolvable nameserver in DNS > install (Alexander Bokovoy) > 6. Re: [PATCH] 332 Do not require resolvable nameserver in DNS > install (Martin Kosek) > 7. Re: [PATCH] Switch %r specifiers to %s in Public errors > (Jan Cholasta) > 8. Re: [PATCH] 330 Disable global forwarding per-zone > (Rob Crittenden) > 9. Re: [PATCH] 330 Disable global forwarding per-zone (Martin Kosek) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Nov 2012 07:43:31 -0500 (EST) > From: Lynn Root > To: freeipa-devel at redhat.com > Subject: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: <943042161.7794393.1352465011767.JavaMail.root at redhat.com> > Content-Type: text/plain; charset="utf-8" > > The VERSION file and Makefile now handles 'beta' release parameters when > making s/rpms. > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > Lynn Root > Associate Software Engineer > Red Hat > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Add-Beta-versioning.patch > Type: text/x-patch > Size: 2522 bytes > Desc: not available > URL: < > https://www.redhat.com/archives/freeipa-devel/attachments/20121109/17627fbd/attachment.bin > > > > ------------------------------ > > Message: 2 > Date: Fri, 09 Nov 2012 13:58:17 +0100 > From: Petr Vobornik > To: Lynn Root > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: <509CFDE9.70002 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/09/2012 01:43 PM, Lynn Root wrote: > > The VERSION file and Makefile now handles 'beta' release parameters when > making s/rpms. > > > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > Thanks for the patch. > > In a next patch, I'd suggest to follow patch-naming conventions > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > patch number into a mail subject, it helps to keeping track of patches. > > -- > Petr Vobornik > > > > ------------------------------ > > Message: 3 > Date: Fri, 9 Nov 2012 08:04:43 -0500 (EST) > From: Lynn Root > To: Petr Vobornik > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: > <1940773203.7804090.1352466283311.JavaMail.root at redhat.com> > Content-Type: text/plain; charset=utf-8 > > Ah thank you - was going by the "Submit Changes" portion in > http://freeipa.org/page/Contribute#Development_Process, which has less > information (but clearly did not notice the Patch Format link right above). > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Petr Vobornik" > To: "Lynn Root" > Cc: freeipa-devel at redhat.com > Sent: Friday, November 9, 2012 1:58:17 PM > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > On 11/09/2012 01:43 PM, Lynn Root wrote: > > The VERSION file and Makefile now handles 'beta' release parameters when > making s/rpms. > > > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > Thanks for the patch. > > In a next patch, I'd suggest to follow patch-naming conventions > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > patch number into a mail subject, it helps to keeping track of patches. > > -- > Petr Vobornik > > > > ------------------------------ > > Message: 4 > Date: Fri, 09 Nov 2012 14:07:05 +0100 > From: Martin Kosek > To: Lynn Root > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: <509CFFF9.2070906 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Actually, there is a link in the Contribute wiki page for the Patch format > page: > > ... > Patch Format - Guidance about the patch format > ... > > We may want to make it more visible... > > Martin > > On 11/09/2012 02:04 PM, Lynn Root wrote: > > Ah thank you - was going by the "Submit Changes" portion in > http://freeipa.org/page/Contribute#Development_Process, which has less > information (but clearly did not notice the Patch Format link right above). > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > ----- Original Message ----- > > From: "Petr Vobornik" > > To: "Lynn Root" > > Cc: freeipa-devel at redhat.com > > Sent: Friday, November 9, 2012 1:58:17 PM > > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > > > On 11/09/2012 01:43 PM, Lynn Root wrote: > >> The VERSION file and Makefile now handles 'beta' release parameters > when making s/rpms. > >> > >> Ticket: https://fedorahosted.org/freeipa/ticket/2893 > >> > >> Lynn Root > >> Associate Software Engineer > >> Red Hat > > > > Thanks for the patch. > > > > In a next patch, I'd suggest to follow patch-naming conventions > > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > > patch number into a mail subject, it helps to keeping track of patches. > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 9 Nov 2012 15:15:09 +0200 > From: Alexander Bokovoy > To: Martin Kosek > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 332 Do not require resolvable > nameserver in DNS install > Message-ID: <20121109131509.GB14850 at redhat.com> > Content-Type: text/plain; charset=us-ascii; format=flowed > > On Fri, 09 Nov 2012, Martin Kosek wrote: > >As named.conf and bind-dyndb-plugin is not set up yet during DNS > >configuration phase, IPA hostname (i.e. the nameserver) should not > >be required be to resolvable in this phase. > > > >https://fedorahosted.org/freeipa/ticket/3248 > ACK. > > -- > / Alexander Bokovoy > > > > ------------------------------ > > Message: 6 > Date: Fri, 09 Nov 2012 14:26:18 +0100 > From: Martin Kosek > To: Alexander Bokovoy > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 332 Do not require resolvable > nameserver in DNS install > Message-ID: <509D047A.5030309 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/09/2012 02:15 PM, Alexander Bokovoy wrote: > > On Fri, 09 Nov 2012, Martin Kosek wrote: > >> As named.conf and bind-dyndb-plugin is not set up yet during DNS > >> configuration phase, IPA hostname (i.e. the nameserver) should not > >> be required be to resolvable in this phase. > >> > >> https://fedorahosted.org/freeipa/ticket/3248 > > ACK. > > > > Pushed to master, ipa-3-0. > > Martin > > > > ------------------------------ > > Message: 7 > Date: Fri, 09 Nov 2012 15:25:20 +0100 > From: Jan Cholasta > To: Lynn Root > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > Public errors > Message-ID: <509D1250.5060404 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 8.11.2012 17:22, Lynn Root wrote: > > Hmm I hope I understand well enough this time around. > > > > However, when I run the tests, there's this one error message I come > across from `test_user[97]: user_add: Create u'tuser2'` - it throws > `DatabaseError: Type or value exists`. I'm a bit lost on how to track this > down. > > > > Once again - thanks for your help! > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > ----- Original Message ----- > > From: "Martin Kosek" > > To: "Jan Cholasta" > > Cc: "Lynn Root" , freeipa-devel at redhat.com > > Sent: Thursday, November 8, 2012 8:46:42 AM > > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > Public errors > > > > On 11/07/2012 06:46 PM, Jan Cholasta wrote: > >> On 7.11.2012 16:08, Lynn Root wrote: > >>> Third time is a charm? > >>> > >>> Lynn Root > >>> Associate Software Engineer > >>> Red Hat > >>> > >>> ----- Original Message ----- > >>> From: "Jan Cholasta" > >>> To: "Lynn Root" > >>> Cc: freeipa-devel at redhat.com > >>> Sent: Monday, November 5, 2012 10:25:32 AM > >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > Public errors > >>> > >>> On 5.11.2012 09:43, Lynn Root wrote: > >>>> Here's try #2! Adjusted patch attached. Let me know if there's > anything > >>>> else I've missed. > >>>> > >>>> Switched %r specifiers to '%s' in Public errors, and adjusted tests to > >>>> expect no preceding 'u'. > >>>> > >>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & > >>>> https://fedorahosted.org/freeipa/ticket/2588 > >>>> > >>>> Lynn Root > >>>> Associate Software Engineer > >>>> Red Hat > >>>> > >>>> ----- Original Message ----- > >>>> From: "Martin Kosek" > >>>> To: "Jan Cholasta" > >>>> Cc: "Lynn Root" , freeipa-devel at redhat.com > >>>> Sent: Tuesday, October 30, 2012 9:08:33 AM > >>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > Public > >>>> errors > >>>> > >>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: > >>>>> Hi, > >>>>> > >>>>> On 29.10.2012 19:54, Lynn Root wrote: > >>>>>> Hi all! > >>>>>> > >>>>>> This switch drops the preceding 'u' from strings in public error > messages. > >>>>>> > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 > >>>>>> > >>>>>> This patch also addresses the unfriendly 'u' from re-raising errors > from the > >>>>>> external call to netaddr.IPAddress by passing a bytestring to the > function. > >>>>>> > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 > >>>>>> > >>>>>> > >>>>>> My first patch (and freeipa dev list email) ever! Let me know where > there's > >>>>>> room to improve. > >>>>>> > >>>>>> Lynn Root > >>>>>> Associate Software Engineer > >>>>>> Red Hat > >>>>>> > >>>>> > >>>>> I think it would be nice if you kept the quotes around the values, > as that is > >>>>> probably the reason "%r" was used in the first place - i.e. use > "'%s'" instead > >>>>> of plain "%s". > >>>> > >>>> +1 > >>>> > >>>> With current patch, I assume that a lot of unit tests will fail as > they check > >>>> exact error message wording. I'd recommend running the whole test > suite with > >>>> your second patch revision. There is a short walkthrough how to set > it up: > >>>> > >>>> http://freeipa.org/page/Testing > >>>> > >>>> Martin > >>>> > >>> > >>> You missed a few: > >>> > >>> $ git grep -En '%(\(.*?\))?r' > >>> > >>> Honza > >>> > >> > >> I think you have gone too far this time :-) It is not necessary (or > wise) to > >> get rid of %r *everywhere* in the code. > > > > Thanks Honza for pointing that out. It seems I missed that in yesterday's > > review. Now, when I look at it, it indeed is not right. > > > >> > >> A few rules to keep in mind: > >> > >> * If it is not an error message, do not touch it (log messages are > not error > >> messages BTW). > >> > >> * If it is an error message for an exception that does not inherit > from > >> errors.PublicError, do not touch it (there might be a few exceptions, > though). > > > > Right. But for example, your netaddr str conversions should be fine > since the > > netaddr error is propagated up to the ValidationError. > > > > Martin > > > >> > >> * Use '%s' (%s with ticks) only for arguments whose value can be > only str or > >> unicode. > >> > >> Honza > >> > > > > This is better, thanks. > > In OverlapError.format, remove the ticks around %s, as we expect a list > here (I think we could make it look prettier, similar to what Martin did > in > < > https://fedorahosted.org/freeipa/changeset/988ea368272822f2153563ad34554240e3377d60/ > >, > but I'm not sure if we want to do it in this ticket/patch). > > I'm not sure what to do about the ValidationError at > ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it > should be "TypeError(TYPE_ERROR % (self.name, self.type, value, > type(value)))" instead, as by the time parameters are validated they are > the right type. > > Also there is one %r you missed in ipalib/parameters.py:1554. > > Honza > > -- > Jan Cholasta > > > > ------------------------------ > > Message: 8 > Date: Fri, 09 Nov 2012 09:36:20 -0500 > From: Rob Crittenden > To: Martin Kosek > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 330 Disable global forwarding > per-zone > Message-ID: <509D14E4.70209 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Martin Kosek wrote: > > On 11/02/2012 11:08 AM, Martin Kosek wrote: > >> On 11/02/2012 10:51 AM, Jan Cholasta wrote: > >>> Hi, > >>> > >>> On 2.11.2012 09:12, Martin Kosek wrote: > >>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: > >>>>> 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 > >>>>> > >>>> > >>>> Fixed both. After a short discussion with Petr Spacek I also added a > >>>> possibility to set global dnsconfig to NONE. > >>>> > >>>> On a different note, I discovered that global forwarders in > >>>> bind-dyndb-ldap/bind are actually broken with referred > bind-dyndb-ldap/bind > >>>> version. Thus, we may want to bump bind-dyndb-ldap version in spec > when this is > >>>> resolved. (This should not affect diff in dns.py in any way). > >>>> > >>>> Martin > >>>> > >>> > >>> This might be a stupid question, but why is "NONE" in upper case and > the rest > >>> of the values in lower case? > >>> > >>> Honza > >>> > >> > >> This really doesn't matter function-wise, as bind-dydnb-ldap does the > >> comparison in case insensitive way. My original intention was to be > consistent > >> with other NONE values we use across IPA and to distinguish the value > from > >> valid BIND values. > >> > >> But you are right that within dns plugin it makes more sense to have it > all > >> lowercase. > >> > >> Updated patch attached. > >> > >> Martin > >> > > > > bind-dyndb-ldap with fixed forwarding has been released. Sending an > updated > > patch for both master and ipa-3-0 branches with its version in our spec > file. > > > > Martin > > > > ACK x2 > > > > ------------------------------ > > Message: 9 > Date: Fri, 09 Nov 2012 15:40:06 +0100 > From: Martin Kosek > To: Rob Crittenden > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 330 Disable global forwarding > per-zone > Message-ID: <509D15C6.7090806 at redhat.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/09/2012 03:36 PM, Rob Crittenden wrote: > > Martin Kosek wrote: > >> On 11/02/2012 11:08 AM, Martin Kosek wrote: > >>> On 11/02/2012 10:51 AM, Jan Cholasta wrote: > >>>> Hi, > >>>> > >>>> On 2.11.2012 09:12, Martin Kosek wrote: > >>>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: > >>>>>> 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 > >>>>>> > >>>>> > >>>>> Fixed both. After a short discussion with Petr Spacek I also added a > >>>>> possibility to set global dnsconfig to NONE. > >>>>> > >>>>> On a different note, I discovered that global forwarders in > >>>>> bind-dyndb-ldap/bind are actually broken with referred > bind-dyndb-ldap/bind > >>>>> version. Thus, we may want to bump bind-dyndb-ldap version in spec > when > >>>>> this is > >>>>> resolved. (This should not affect diff in dns.py in any way). > >>>>> > >>>>> Martin > >>>>> > >>>> > >>>> This might be a stupid question, but why is "NONE" in upper case and > the rest > >>>> of the values in lower case? > >>>> > >>>> Honza > >>>> > >>> > >>> This really doesn't matter function-wise, as bind-dydnb-ldap does the > >>> comparison in case insensitive way. My original intention was to be > consistent > >>> with other NONE values we use across IPA and to distinguish the value > from > >>> valid BIND values. > >>> > >>> But you are right that within dns plugin it makes more sense to have > it all > >>> lowercase. > >>> > >>> Updated patch attached. > >>> > >>> Martin > >>> > >> > >> bind-dyndb-ldap with fixed forwarding has been released. Sending an > updated > >> patch for both master and ipa-3-0 branches with its version in our spec > file. > >> > >> Martin > >> > > > > ACK x2 > > Pushed to master, ipa-3-0. > > Martin > > > > ------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > End of Freeipa-devel Digest, Vol 66, Issue 34 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Sun Nov 11 22:18:32 2012 From: jdennis at redhat.com (John Dennis) Date: Sun, 11 Nov 2012 17:18:32 -0500 Subject: [Freeipa-devel] [PATCH 82] Compliant client side session cookie behavior Message-ID: <50A02438.50601@redhat.com> Note: This has been tested with both the command line api and the browser on both Fedora and RHEL-6. It has also been tested to make sure any cookies stored before an upgrade will work correctly. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0082-Compliant-client-side-session-cookie-behavior.patch Type: text/x-patch Size: 57895 bytes Desc: not available URL: From pspacek at redhat.com Mon Nov 12 11:10:53 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 12 Nov 2012 12:10:53 +0100 Subject: [Freeipa-devel] [PATCH 0080] Prevent false 'zone serial (2012060301) unchanged' error messages In-Reply-To: <20121029153120.GA26093@redhat.com> References: <508555AB.8030701@redhat.com> <20121029153120.GA26093@redhat.com> Message-ID: <50A0D93D.80202@redhat.com> On 10/29/2012 04:31 PM, Adam Tkac wrote: > On Mon, Oct 22, 2012 at 04:18:19PM +0200, Petr Spacek wrote: >> >Hello, >> > >> >this patch prevents false 'zone serial (2012060301) unchanged' error >> >messages coming from zone_postload(), which is called after each >> >zone change from dns_zone_load(). >> > >> >I found zone_postload() unnecessary for our plugin except initial >> >load. Adam, please, check that information, I'm not 100 % sure about >> >BIND internals. I examined only zone_load() and zone_postload() >> >functions and I'm not sure about consequences in other parts of >> >BIND. >> > >> >Attached patch creates empty SSU table which is enough to pass >> >dns_zone_isdynamic() check - as a result zone_postload() is not >> >called for our zones anymore. >> > >> > >> >This patch closes >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/79 > Ack > I forgot to push it... Pushed to master and v2: d2349fd132b821be93980e9a42cf8e52ed9bc0f9 -- Petr^2 Spacek From pviktori at redhat.com Mon Nov 12 11:21:37 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Nov 2012 12:21:37 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <509C2DCA.2010804@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> Message-ID: <50A0DBC1.1060409@redhat.com> On 11/08/2012 11:10 PM, Rob Crittenden wrote: > > This may not be a new problem specific to this, I'm not sure yet, but > uninstall doesn't untrack all the certificates in the new tomcat > directory. It also seems to miss the ipaCert alias in httpd (my > post-install check caught only this one). I'll look into this. > It may also be helpful to combine all the required patches up to this > point into a single post, sort of a "we're ready for broader testing > checkpoint". Sifting through this long thread finding all the various > patches was tedious. I sure wouldn't want to actually push what I culled > because I'm not 100% sure I got them all. Attached. > Otherwise a single master install went well and the CA renewal code > works. Will continue upgrade and replication testing. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-alee-0001-03-Changes-to-use-a-single-database-for-dogtag-and-IPA.patch Type: text/x-patch Size: 36295 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0095-02-Fix-schema-replication-from-old-masters.patch Type: text/x-patch Size: 9167 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0096-Use-correct-Dogtag-configuration-in-get_pin-and-get_.patch Type: text/x-patch Size: 4935 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0097-Update-certmap.conf-on-IPA-upgrades.patch Type: text/x-patch Size: 4333 bytes Desc: not available URL: From lroot at redhat.com Mon Nov 12 11:50:52 2012 From: lroot at redhat.com (Lynn Root) Date: Mon, 12 Nov 2012 06:50:52 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <509D1250.5060404@redhat.com> Message-ID: <97933906.8755095.1352721052338.JavaMail.root@redhat.com> Lynn Root Associate Software Engineer Red Hat ----- Original Message ----- > From: "Jan Cholasta" > To: "Lynn Root" > Cc: freeipa-devel at redhat.com > Sent: Friday, November 9, 2012 3:25:20 PM > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors > > On 8.11.2012 17:22, Lynn Root wrote: > > Hmm I hope I understand well enough this time around. > > > > However, when I run the tests, there's this one error message I > > come across from `test_user[97]: user_add: Create u'tuser2'` - it > > throws `DatabaseError: Type or value exists`. I'm a bit lost on > > how to track this down. > > > > Once again - thanks for your help! > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > ----- Original Message ----- > > From: "Martin Kosek" > > To: "Jan Cholasta" > > Cc: "Lynn Root" , freeipa-devel at redhat.com > > Sent: Thursday, November 8, 2012 8:46:42 AM > > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > > Public errors > > > > On 11/07/2012 06:46 PM, Jan Cholasta wrote: > >> On 7.11.2012 16:08, Lynn Root wrote: > >>> Third time is a charm? > >>> > >>> Lynn Root > >>> Associate Software Engineer > >>> Red Hat > >>> > >>> ----- Original Message ----- > >>> From: "Jan Cholasta" > >>> To: "Lynn Root" > >>> Cc: freeipa-devel at redhat.com > >>> Sent: Monday, November 5, 2012 10:25:32 AM > >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s > >>> in Public errors > >>> > >>> On 5.11.2012 09:43, Lynn Root wrote: > >>>> Here's try #2! Adjusted patch attached. Let me know if there's > >>>> anything > >>>> else I've missed. > >>>> > >>>> Switched %r specifiers to '%s' in Public errors, and adjusted > >>>> tests to > >>>> expect no preceding 'u'. > >>>> > >>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & > >>>> https://fedorahosted.org/freeipa/ticket/2588 > >>>> > >>>> Lynn Root > >>>> Associate Software Engineer > >>>> Red Hat > >>>> > >>>> ----- Original Message ----- > >>>> From: "Martin Kosek" > >>>> To: "Jan Cholasta" > >>>> Cc: "Lynn Root" , freeipa-devel at redhat.com > >>>> Sent: Tuesday, October 30, 2012 9:08:33 AM > >>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s > >>>> in Public > >>>> errors > >>>> > >>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: > >>>>> Hi, > >>>>> > >>>>> On 29.10.2012 19:54, Lynn Root wrote: > >>>>>> Hi all! > >>>>>> > >>>>>> This switch drops the preceding 'u' from strings in public > >>>>>> error messages. > >>>>>> > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 > >>>>>> > >>>>>> This patch also addresses the unfriendly 'u' from re-raising > >>>>>> errors from the > >>>>>> external call to netaddr.IPAddress by passing a bytestring to > >>>>>> the function. > >>>>>> > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 > >>>>>> > >>>>>> > >>>>>> My first patch (and freeipa dev list email) ever! Let me know > >>>>>> where there's > >>>>>> room to improve. > >>>>>> > >>>>>> Lynn Root > >>>>>> Associate Software Engineer > >>>>>> Red Hat > >>>>>> > >>>>> > >>>>> I think it would be nice if you kept the quotes around the > >>>>> values, as that is > >>>>> probably the reason "%r" was used in the first place - i.e. use > >>>>> "'%s'" instead > >>>>> of plain "%s". > >>>> > >>>> +1 > >>>> > >>>> With current patch, I assume that a lot of unit tests will fail > >>>> as they check > >>>> exact error message wording. I'd recommend running the whole > >>>> test suite with > >>>> your second patch revision. There is a short walkthrough how to > >>>> set it up: > >>>> > >>>> http://freeipa.org/page/Testing > >>>> > >>>> Martin > >>>> > >>> > >>> You missed a few: > >>> > >>> $ git grep -En '%(\(.*?\))?r' > >>> > >>> Honza > >>> > >> > >> I think you have gone too far this time :-) It is not necessary > >> (or wise) to > >> get rid of %r *everywhere* in the code. > > > > Thanks Honza for pointing that out. It seems I missed that in > > yesterday's > > review. Now, when I look at it, it indeed is not right. > > > >> > >> A few rules to keep in mind: > >> > >> * If it is not an error message, do not touch it (log messages > >> are not error > >> messages BTW). > >> > >> * If it is an error message for an exception that does not > >> inherit from > >> errors.PublicError, do not touch it (there might be a few > >> exceptions, though). > > > > Right. But for example, your netaddr str conversions should be fine > > since the > > netaddr error is propagated up to the ValidationError. > > > > Martin > > > >> > >> * Use '%s' (%s with ticks) only for arguments whose value can > >> be only str or > >> unicode. > >> > >> Honza > >> > > > > This is better, thanks. > > In OverlapError.format, remove the ticks around %s, as we expect a > list > here (I think we could make it look prettier, similar to what Martin > did > in > , > but I'm not sure if we want to do it in this ticket/patch). > Fixed, ty. > I'm not sure what to do about the ValidationError at > ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it > should be "TypeError(TYPE_ERROR % (self.name, self.type, value, > type(value)))" instead, as by the time parameters are validated they > are > the right type. Done - with adjusted tests. > > Also there is one %r you missed in ipalib/parameters.py:1554. The tests seem to be expecting a unicode character - are you sure this is right? If not - attached is the new patch (correctly formatted). Thanks again! > > Honza > > -- > Jan Cholasta > -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lroot-0001-5-Switch-r-specifiers-to-s-in-Public-errors.patch Type: text/x-patch Size: 13421 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 12 12:57:41 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Nov 2012 13:57:41 +0100 Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <97933906.8755095.1352721052338.JavaMail.root@redhat.com> References: <97933906.8755095.1352721052338.JavaMail.root@redhat.com> Message-ID: <50A0F245.1020505@redhat.com> On 12.11.2012 12:50, Lynn Root wrote: > > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- >> From: "Jan Cholasta" >> To: "Lynn Root" >> Cc: freeipa-devel at redhat.com >> Sent: Friday, November 9, 2012 3:25:20 PM >> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors >> >> On 8.11.2012 17:22, Lynn Root wrote: >>> Hmm I hope I understand well enough this time around. >>> >>> However, when I run the tests, there's this one error message I >>> come across from `test_user[97]: user_add: Create u'tuser2'` - it >>> throws `DatabaseError: Type or value exists`. I'm a bit lost on >>> how to track this down. >>> >>> Once again - thanks for your help! >>> >>> Lynn Root >>> Associate Software Engineer >>> Red Hat >>> >>> ----- Original Message ----- >>> From: "Martin Kosek" >>> To: "Jan Cholasta" >>> Cc: "Lynn Root" , freeipa-devel at redhat.com >>> Sent: Thursday, November 8, 2012 8:46:42 AM >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in >>> Public errors >>> >>> On 11/07/2012 06:46 PM, Jan Cholasta wrote: >>>> On 7.11.2012 16:08, Lynn Root wrote: >>>>> Third time is a charm? >>>>> >>>>> Lynn Root >>>>> Associate Software Engineer >>>>> Red Hat >>>>> >>>>> ----- Original Message ----- >>>>> From: "Jan Cholasta" >>>>> To: "Lynn Root" >>>>> Cc: freeipa-devel at redhat.com >>>>> Sent: Monday, November 5, 2012 10:25:32 AM >>>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s >>>>> in Public errors >>>>> >>>>> On 5.11.2012 09:43, Lynn Root wrote: >>>>>> Here's try #2! Adjusted patch attached. Let me know if there's >>>>>> anything >>>>>> else I've missed. >>>>>> >>>>>> Switched %r specifiers to '%s' in Public errors, and adjusted >>>>>> tests to >>>>>> expect no preceding 'u'. >>>>>> >>>>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & >>>>>> https://fedorahosted.org/freeipa/ticket/2588 >>>>>> >>>>>> Lynn Root >>>>>> Associate Software Engineer >>>>>> Red Hat >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Martin Kosek" >>>>>> To: "Jan Cholasta" >>>>>> Cc: "Lynn Root" , freeipa-devel at redhat.com >>>>>> Sent: Tuesday, October 30, 2012 9:08:33 AM >>>>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s >>>>>> in Public >>>>>> errors >>>>>> >>>>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 29.10.2012 19:54, Lynn Root wrote: >>>>>>>> Hi all! >>>>>>>> >>>>>>>> This switch drops the preceding 'u' from strings in public >>>>>>>> error messages. >>>>>>>> >>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>>>>>>> >>>>>>>> This patch also addresses the unfriendly 'u' from re-raising >>>>>>>> errors from the >>>>>>>> external call to netaddr.IPAddress by passing a bytestring to >>>>>>>> the function. >>>>>>>> >>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>>>>>>> >>>>>>>> >>>>>>>> My first patch (and freeipa dev list email) ever! Let me know >>>>>>>> where there's >>>>>>>> room to improve. >>>>>>>> >>>>>>>> Lynn Root >>>>>>>> Associate Software Engineer >>>>>>>> Red Hat >>>>>>>> >>>>>>> >>>>>>> I think it would be nice if you kept the quotes around the >>>>>>> values, as that is >>>>>>> probably the reason "%r" was used in the first place - i.e. use >>>>>>> "'%s'" instead >>>>>>> of plain "%s". >>>>>> >>>>>> +1 >>>>>> >>>>>> With current patch, I assume that a lot of unit tests will fail >>>>>> as they check >>>>>> exact error message wording. I'd recommend running the whole >>>>>> test suite with >>>>>> your second patch revision. There is a short walkthrough how to >>>>>> set it up: >>>>>> >>>>>> http://freeipa.org/page/Testing >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> You missed a few: >>>>> >>>>> $ git grep -En '%(\(.*?\))?r' >>>>> >>>>> Honza >>>>> >>>> >>>> I think you have gone too far this time :-) It is not necessary >>>> (or wise) to >>>> get rid of %r *everywhere* in the code. >>> >>> Thanks Honza for pointing that out. It seems I missed that in >>> yesterday's >>> review. Now, when I look at it, it indeed is not right. >>> >>>> >>>> A few rules to keep in mind: >>>> >>>> * If it is not an error message, do not touch it (log messages >>>> are not error >>>> messages BTW). >>>> >>>> * If it is an error message for an exception that does not >>>> inherit from >>>> errors.PublicError, do not touch it (there might be a few >>>> exceptions, though). >>> >>> Right. But for example, your netaddr str conversions should be fine >>> since the >>> netaddr error is propagated up to the ValidationError. >>> >>> Martin >>> >>>> >>>> * Use '%s' (%s with ticks) only for arguments whose value can >>>> be only str or >>>> unicode. >>>> >>>> Honza >>>> >>> >> >> This is better, thanks. >> >> In OverlapError.format, remove the ticks around %s, as we expect a >> list >> here (I think we could make it look prettier, similar to what Martin >> did >> in >> , >> but I'm not sure if we want to do it in this ticket/patch). >> > > Fixed, ty. > >> I'm not sure what to do about the ValidationError at >> ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it >> should be "TypeError(TYPE_ERROR % (self.name, self.type, value, >> type(value)))" instead, as by the time parameters are validated they >> are >> the right type. > > Done - with adjusted tests. Thanks, but please refer to me as jcholast at redhat.com in the commit message, so that people don't have to look me up. > >> >> Also there is one %r you missed in ipalib/parameters.py:1554. > > The tests seem to be expecting a unicode character - are you sure this is right? Currently the message the error produces has two ticks on each side of the value, which is ugly. So, replace the "\'%(char)r\'" with either "\'%(char)s\'" or "%(char)r". > > If not - attached is the new patch (correctly formatted). > > Thanks again! > >> >> Honza >> >> -- >> Jan Cholasta >> Honza -- Jan Cholasta From lroot at redhat.com Mon Nov 12 13:14:24 2012 From: lroot at redhat.com (Lynn Root) Date: Mon, 12 Nov 2012 08:14:24 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <50A0F245.1020505@redhat.com> Message-ID: <1476980763.8834780.1352726064763.JavaMail.root@redhat.com> ----- Original Message ----- > On 12.11.2012 12:50, Lynn Root wrote: > > > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > ----- Original Message ----- > >> From: "Jan Cholasta" > >> To: "Lynn Root" > >> Cc: freeipa-devel at redhat.com > >> Sent: Friday, November 9, 2012 3:25:20 PM > >> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > >> Public errors > >> > >> On 8.11.2012 17:22, Lynn Root wrote: > >>> Hmm I hope I understand well enough this time around. > >>> > >>> However, when I run the tests, there's this one error message I > >>> come across from `test_user[97]: user_add: Create u'tuser2'` - it > >>> throws `DatabaseError: Type or value exists`. I'm a bit lost on > >>> how to track this down. > >>> > >>> Once again - thanks for your help! > >>> > >>> Lynn Root > >>> Associate Software Engineer > >>> Red Hat > >>> > >>> ----- Original Message ----- > >>> From: "Martin Kosek" > >>> To: "Jan Cholasta" > >>> Cc: "Lynn Root" , freeipa-devel at redhat.com > >>> Sent: Thursday, November 8, 2012 8:46:42 AM > >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s > >>> in > >>> Public errors > >>> > >>> On 11/07/2012 06:46 PM, Jan Cholasta wrote: > >>>> On 7.11.2012 16:08, Lynn Root wrote: > >>>>> Third time is a charm? > >>>>> > >>>>> Lynn Root > >>>>> Associate Software Engineer > >>>>> Red Hat > >>>>> > >>>>> ----- Original Message ----- > >>>>> From: "Jan Cholasta" > >>>>> To: "Lynn Root" > >>>>> Cc: freeipa-devel at redhat.com > >>>>> Sent: Monday, November 5, 2012 10:25:32 AM > >>>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s > >>>>> in Public errors > >>>>> > >>>>> On 5.11.2012 09:43, Lynn Root wrote: > >>>>>> Here's try #2! Adjusted patch attached. Let me know if > >>>>>> there's > >>>>>> anything > >>>>>> else I've missed. > >>>>>> > >>>>>> Switched %r specifiers to '%s' in Public errors, and adjusted > >>>>>> tests to > >>>>>> expect no preceding 'u'. > >>>>>> > >>>>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & > >>>>>> https://fedorahosted.org/freeipa/ticket/2588 > >>>>>> > >>>>>> Lynn Root > >>>>>> Associate Software Engineer > >>>>>> Red Hat > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>> From: "Martin Kosek" > >>>>>> To: "Jan Cholasta" > >>>>>> Cc: "Lynn Root" , freeipa-devel at redhat.com > >>>>>> Sent: Tuesday, October 30, 2012 9:08:33 AM > >>>>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to > >>>>>> %s > >>>>>> in Public > >>>>>> errors > >>>>>> > >>>>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> On 29.10.2012 19:54, Lynn Root wrote: > >>>>>>>> Hi all! > >>>>>>>> > >>>>>>>> This switch drops the preceding 'u' from strings in public > >>>>>>>> error messages. > >>>>>>>> > >>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 > >>>>>>>> > >>>>>>>> This patch also addresses the unfriendly 'u' from re-raising > >>>>>>>> errors from the > >>>>>>>> external call to netaddr.IPAddress by passing a bytestring > >>>>>>>> to > >>>>>>>> the function. > >>>>>>>> > >>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 > >>>>>>>> > >>>>>>>> > >>>>>>>> My first patch (and freeipa dev list email) ever! Let me > >>>>>>>> know > >>>>>>>> where there's > >>>>>>>> room to improve. > >>>>>>>> > >>>>>>>> Lynn Root > >>>>>>>> Associate Software Engineer > >>>>>>>> Red Hat > >>>>>>>> > >>>>>>> > >>>>>>> I think it would be nice if you kept the quotes around the > >>>>>>> values, as that is > >>>>>>> probably the reason "%r" was used in the first place - i.e. > >>>>>>> use > >>>>>>> "'%s'" instead > >>>>>>> of plain "%s". > >>>>>> > >>>>>> +1 > >>>>>> > >>>>>> With current patch, I assume that a lot of unit tests will > >>>>>> fail > >>>>>> as they check > >>>>>> exact error message wording. I'd recommend running the whole > >>>>>> test suite with > >>>>>> your second patch revision. There is a short walkthrough how > >>>>>> to > >>>>>> set it up: > >>>>>> > >>>>>> http://freeipa.org/page/Testing > >>>>>> > >>>>>> Martin > >>>>>> > >>>>> > >>>>> You missed a few: > >>>>> > >>>>> $ git grep -En '%(\(.*?\))?r' > >>>>> > >>>>> Honza > >>>>> > >>>> > >>>> I think you have gone too far this time :-) It is not necessary > >>>> (or wise) to > >>>> get rid of %r *everywhere* in the code. > >>> > >>> Thanks Honza for pointing that out. It seems I missed that in > >>> yesterday's > >>> review. Now, when I look at it, it indeed is not right. > >>> > >>>> > >>>> A few rules to keep in mind: > >>>> > >>>> * If it is not an error message, do not touch it (log > >>>> messages > >>>> are not error > >>>> messages BTW). > >>>> > >>>> * If it is an error message for an exception that does not > >>>> inherit from > >>>> errors.PublicError, do not touch it (there might be a few > >>>> exceptions, though). > >>> > >>> Right. But for example, your netaddr str conversions should be > >>> fine > >>> since the > >>> netaddr error is propagated up to the ValidationError. > >>> > >>> Martin > >>> > >>>> > >>>> * Use '%s' (%s with ticks) only for arguments whose value > >>>> can > >>>> be only str or > >>>> unicode. > >>>> > >>>> Honza > >>>> > >>> > >> > >> This is better, thanks. > >> > >> In OverlapError.format, remove the ticks around %s, as we expect a > >> list > >> here (I think we could make it look prettier, similar to what > >> Martin > >> did > >> in > >> , > >> but I'm not sure if we want to do it in this ticket/patch). > >> > > > > Fixed, ty. > > > >> I'm not sure what to do about the ValidationError at > >> ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it > >> should be "TypeError(TYPE_ERROR % (self.name, self.type, value, > >> type(value)))" instead, as by the time parameters are validated > >> they > >> are > >> the right type. > > > > Done - with adjusted tests. > > Thanks, but please refer to me as jcholast at redhat.com in the commit > message, so that people don't have to look me up. > Fixed. > > > >> > >> Also there is one %r you missed in ipalib/parameters.py:1554. > > > > The tests seem to be expecting a unicode character - are you sure > > this is right? > > Currently the message the error produces has two ticks on each side > of > the value, which is ugly. So, replace the "\'%(char)r\'" with either > "\'%(char)s\'" or "%(char)r". Ah now I see - fixed. > > > > > If not - attached is the new patch (correctly formatted). > > > > Thanks again! > > > >> > >> Honza > >> > >> -- > >> Jan Cholasta > >> > > Honza > > -- > Jan Cholasta > Lynn Root Associate Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lroot-0001-6-Switch-r-specifiers-to-s-in-Public-errors.patch Type: text/x-patch Size: 14266 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 12 14:04:23 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Nov 2012 15:04:23 +0100 Subject: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in Public errors In-Reply-To: <1476980763.8834780.1352726064763.JavaMail.root@redhat.com> References: <1476980763.8834780.1352726064763.JavaMail.root@redhat.com> Message-ID: <50A101E7.9010003@redhat.com> On 12.11.2012 14:14, Lynn Root wrote: > > ----- Original Message ----- >> On 12.11.2012 12:50, Lynn Root wrote: >>> >>> >>> Lynn Root >>> Associate Software Engineer >>> Red Hat >>> >>> ----- Original Message ----- >>>> From: "Jan Cholasta" >>>> To: "Lynn Root" >>>> Cc: freeipa-devel at redhat.com >>>> Sent: Friday, November 9, 2012 3:25:20 PM >>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in >>>> Public errors >>>> >>>> On 8.11.2012 17:22, Lynn Root wrote: >>>>> Hmm I hope I understand well enough this time around. >>>>> >>>>> However, when I run the tests, there's this one error message I >>>>> come across from `test_user[97]: user_add: Create u'tuser2'` - it >>>>> throws `DatabaseError: Type or value exists`. I'm a bit lost on >>>>> how to track this down. >>>>> >>>>> Once again - thanks for your help! >>>>> >>>>> Lynn Root >>>>> Associate Software Engineer >>>>> Red Hat >>>>> >>>>> ----- Original Message ----- >>>>> From: "Martin Kosek" >>>>> To: "Jan Cholasta" >>>>> Cc: "Lynn Root" , freeipa-devel at redhat.com >>>>> Sent: Thursday, November 8, 2012 8:46:42 AM >>>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s >>>>> in >>>>> Public errors >>>>> >>>>> On 11/07/2012 06:46 PM, Jan Cholasta wrote: >>>>>> On 7.11.2012 16:08, Lynn Root wrote: >>>>>>> Third time is a charm? >>>>>>> >>>>>>> Lynn Root >>>>>>> Associate Software Engineer >>>>>>> Red Hat >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Jan Cholasta" >>>>>>> To: "Lynn Root" >>>>>>> Cc: freeipa-devel at redhat.com >>>>>>> Sent: Monday, November 5, 2012 10:25:32 AM >>>>>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s >>>>>>> in Public errors >>>>>>> >>>>>>> On 5.11.2012 09:43, Lynn Root wrote: >>>>>>>> Here's try #2! Adjusted patch attached. Let me know if >>>>>>>> there's >>>>>>>> anything >>>>>>>> else I've missed. >>>>>>>> >>>>>>>> Switched %r specifiers to '%s' in Public errors, and adjusted >>>>>>>> tests to >>>>>>>> expect no preceding 'u'. >>>>>>>> >>>>>>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & >>>>>>>> https://fedorahosted.org/freeipa/ticket/2588 >>>>>>>> >>>>>>>> Lynn Root >>>>>>>> Associate Software Engineer >>>>>>>> Red Hat >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Martin Kosek" >>>>>>>> To: "Jan Cholasta" >>>>>>>> Cc: "Lynn Root" , freeipa-devel at redhat.com >>>>>>>> Sent: Tuesday, October 30, 2012 9:08:33 AM >>>>>>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to >>>>>>>> %s >>>>>>>> in Public >>>>>>>> errors >>>>>>>> >>>>>>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 29.10.2012 19:54, Lynn Root wrote: >>>>>>>>>> Hi all! >>>>>>>>>> >>>>>>>>>> This switch drops the preceding 'u' from strings in public >>>>>>>>>> error messages. >>>>>>>>>> >>>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 >>>>>>>>>> >>>>>>>>>> This patch also addresses the unfriendly 'u' from re-raising >>>>>>>>>> errors from the >>>>>>>>>> external call to netaddr.IPAddress by passing a bytestring >>>>>>>>>> to >>>>>>>>>> the function. >>>>>>>>>> >>>>>>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> My first patch (and freeipa dev list email) ever! Let me >>>>>>>>>> know >>>>>>>>>> where there's >>>>>>>>>> room to improve. >>>>>>>>>> >>>>>>>>>> Lynn Root >>>>>>>>>> Associate Software Engineer >>>>>>>>>> Red Hat >>>>>>>>>> >>>>>>>>> >>>>>>>>> I think it would be nice if you kept the quotes around the >>>>>>>>> values, as that is >>>>>>>>> probably the reason "%r" was used in the first place - i.e. >>>>>>>>> use >>>>>>>>> "'%s'" instead >>>>>>>>> of plain "%s". >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> With current patch, I assume that a lot of unit tests will >>>>>>>> fail >>>>>>>> as they check >>>>>>>> exact error message wording. I'd recommend running the whole >>>>>>>> test suite with >>>>>>>> your second patch revision. There is a short walkthrough how >>>>>>>> to >>>>>>>> set it up: >>>>>>>> >>>>>>>> http://freeipa.org/page/Testing >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> You missed a few: >>>>>>> >>>>>>> $ git grep -En '%(\(.*?\))?r' >>>>>>> >>>>>>> Honza >>>>>>> >>>>>> >>>>>> I think you have gone too far this time :-) It is not necessary >>>>>> (or wise) to >>>>>> get rid of %r *everywhere* in the code. >>>>> >>>>> Thanks Honza for pointing that out. It seems I missed that in >>>>> yesterday's >>>>> review. Now, when I look at it, it indeed is not right. >>>>> >>>>>> >>>>>> A few rules to keep in mind: >>>>>> >>>>>> * If it is not an error message, do not touch it (log >>>>>> messages >>>>>> are not error >>>>>> messages BTW). >>>>>> >>>>>> * If it is an error message for an exception that does not >>>>>> inherit from >>>>>> errors.PublicError, do not touch it (there might be a few >>>>>> exceptions, though). >>>>> >>>>> Right. But for example, your netaddr str conversions should be >>>>> fine >>>>> since the >>>>> netaddr error is propagated up to the ValidationError. >>>>> >>>>> Martin >>>>> >>>>>> >>>>>> * Use '%s' (%s with ticks) only for arguments whose value >>>>>> can >>>>>> be only str or >>>>>> unicode. >>>>>> >>>>>> Honza >>>>>> >>>>> >>>> >>>> This is better, thanks. >>>> >>>> In OverlapError.format, remove the ticks around %s, as we expect a >>>> list >>>> here (I think we could make it look prettier, similar to what >>>> Martin >>>> did >>>> in >>>> , >>>> but I'm not sure if we want to do it in this ticket/patch). >>>> >>> >>> Fixed, ty. >>> >>>> I'm not sure what to do about the ValidationError at >>>> ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it >>>> should be "TypeError(TYPE_ERROR % (self.name, self.type, value, >>>> type(value)))" instead, as by the time parameters are validated >>>> they >>>> are >>>> the right type. >>> >>> Done - with adjusted tests. >> >> Thanks, but please refer to me as jcholast at redhat.com in the commit >> message, so that people don't have to look me up. >> > > Fixed. > >>> >>>> >>>> Also there is one %r you missed in ipalib/parameters.py:1554. >>> >>> The tests seem to be expecting a unicode character - are you sure >>> this is right? >> >> Currently the message the error produces has two ticks on each side >> of >> the value, which is ugly. So, replace the "\'%(char)r\'" with either >> "\'%(char)s\'" or "%(char)r". > > Ah now I see - fixed. > >> >>> >>> If not - attached is the new patch (correctly formatted). >>> >>> Thanks again! >>> >>>> >>>> Honza >>>> >>>> -- >>>> Jan Cholasta >>>> >> >> Honza >> >> -- >> Jan Cholasta >> > > > Lynn Root > Associate Software Engineer > Red Hat > Thanks, ACK. Honza -- Jan Cholasta From dpal at redhat.com Mon Nov 12 14:19:32 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Nov 2012 09:19:32 -0500 Subject: [Freeipa-devel] Freeipa-devel Digest, Vol 66, Issue 34 In-Reply-To: References: Message-ID: <50A10574.8050303@redhat.com> On 11/10/2012 09:14 AM, mohammad moeini wrote: > Dear Guyes > > i'm AAA Server administrator , I use freeipa for AAA server > i Have a Centos server and 50 client debian > i use the ipa v 3 and now have problem with join ipa clients becuse > not exisixt upper 2.1.4 package in debian distru > when i want compile ipa client on the folder ipa-client in cource get > the error krb5.h not exist , please help me anout dependency on the > freeipa v 3 o r say to me how can i config ipa v 3 for supporting ipa > client v 2.1.4 > > Another my question is about sudoers i config sudoers seem of the all > domcumention free ipa and testing many soulution from Ldap or freeipa > or another way seem nscd.conf or sssd.conf or .... but not working and > just say to me your user is not is sudoers ,,, i don't know i must > doing any config in ldap schema or must create suoers group > please help me ,,, i run freeipa for first time in middle ease and i > want grow this at this point of world > Have you seen couple threads on freeipa-users about SUDO this and last month? Just search the archives. They have a lot of hints on how to configure sudo and make sure it works. SUDO changed the name of its config file recently and that have be a source of confusion is some cases. Anyways please read those threads and try to follow the instructions there (posts from JR are very helpful). If you still have problems please let us know more details. > Regards Moeini > > > On Fri, Nov 9, 2012 at 6:40 PM, > wrote: > > Send Freeipa-devel mailing list submissions to > freeipa-devel at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-devel > or, via email, send a message with subject or body 'help' to > freeipa-devel-request at redhat.com > > > You can reach the person managing the list at > freeipa-devel-owner at redhat.com > > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-devel digest..." > > > Today's Topics: > > 1. [PATCH] Add Beta versioning (Lynn Root) > 2. Re: [PATCH] Add Beta versioning (Petr Vobornik) > 3. Re: [PATCH] Add Beta versioning (Lynn Root) > 4. Re: [PATCH] Add Beta versioning (Martin Kosek) > 5. Re: [PATCH] 332 Do not require resolvable nameserver in DNS > install (Alexander Bokovoy) > 6. Re: [PATCH] 332 Do not require resolvable nameserver in DNS > install (Martin Kosek) > 7. Re: [PATCH] Switch %r specifiers to %s in Public errors > (Jan Cholasta) > 8. Re: [PATCH] 330 Disable global forwarding per-zone > (Rob Crittenden) > 9. Re: [PATCH] 330 Disable global forwarding per-zone (Martin > Kosek) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 9 Nov 2012 07:43:31 -0500 (EST) > From: Lynn Root > > To: freeipa-devel at redhat.com > Subject: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: > <943042161.7794393.1352465011767.JavaMail.root at redhat.com > > > Content-Type: text/plain; charset="utf-8" > > The VERSION file and Makefile now handles 'beta' release > parameters when making s/rpms. > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > Lynn Root > Associate Software Engineer > Red Hat > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Add-Beta-versioning.patch > Type: text/x-patch > Size: 2522 bytes > Desc: not available > URL: > > > ------------------------------ > > Message: 2 > Date: Fri, 09 Nov 2012 13:58:17 +0100 > From: Petr Vobornik > > To: Lynn Root > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: <509CFDE9.70002 at redhat.com > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 11/09/2012 01:43 PM, Lynn Root wrote: > > The VERSION file and Makefile now handles 'beta' release > parameters when making s/rpms. > > > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > Thanks for the patch. > > In a next patch, I'd suggest to follow patch-naming conventions > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > patch number into a mail subject, it helps to keeping track of > patches. > > -- > Petr Vobornik > > > > ------------------------------ > > Message: 3 > Date: Fri, 9 Nov 2012 08:04:43 -0500 (EST) > From: Lynn Root > > To: Petr Vobornik > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: > <1940773203.7804090.1352466283311.JavaMail.root at redhat.com > > > Content-Type: text/plain; charset=utf-8 > > Ah thank you - was going by the "Submit Changes" portion in > http://freeipa.org/page/Contribute#Development_Process, which has > less information (but clearly did not notice the Patch Format link > right above). > > Lynn Root > Associate Software Engineer > Red Hat > > ----- Original Message ----- > From: "Petr Vobornik" > > To: "Lynn Root" > > Cc: freeipa-devel at redhat.com > Sent: Friday, November 9, 2012 1:58:17 PM > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > On 11/09/2012 01:43 PM, Lynn Root wrote: > > The VERSION file and Makefile now handles 'beta' release > parameters when making s/rpms. > > > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > Thanks for the patch. > > In a next patch, I'd suggest to follow patch-naming conventions > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > patch number into a mail subject, it helps to keeping track of > patches. > > -- > Petr Vobornik > > > > ------------------------------ > > Message: 4 > Date: Fri, 09 Nov 2012 14:07:05 +0100 > From: Martin Kosek > > To: Lynn Root > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > Message-ID: <509CFFF9.2070906 at redhat.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > Actually, there is a link in the Contribute wiki page for the > Patch format page: > > ... > Patch Format - Guidance about the patch format > ... > > We may want to make it more visible... > > Martin > > On 11/09/2012 02:04 PM, Lynn Root wrote: > > Ah thank you - was going by the "Submit Changes" portion in > http://freeipa.org/page/Contribute#Development_Process, which has > less information (but clearly did not notice the Patch Format link > right above). > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > ----- Original Message ----- > > From: "Petr Vobornik" > > > To: "Lynn Root" > > > Cc: freeipa-devel at redhat.com > > Sent: Friday, November 9, 2012 1:58:17 PM > > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > > > On 11/09/2012 01:43 PM, Lynn Root wrote: > >> The VERSION file and Makefile now handles 'beta' release > parameters when making s/rpms. > >> > >> Ticket: https://fedorahosted.org/freeipa/ticket/2893 > >> > >> Lynn Root > >> Associate Software Engineer > >> Red Hat > > > > Thanks for the patch. > > > > In a next patch, I'd suggest to follow patch-naming conventions > > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > > patch number into a mail subject, it helps to keeping track of > patches. > > > > > > ------------------------------ > > Message: 5 > Date: Fri, 9 Nov 2012 15:15:09 +0200 > From: Alexander Bokovoy > > To: Martin Kosek > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 332 Do not require resolvable > nameserver in DNS install > Message-ID: <20121109131509.GB14850 at redhat.com > > > Content-Type: text/plain; charset=us-ascii; format=flowed > > On Fri, 09 Nov 2012, Martin Kosek wrote: > >As named.conf and bind-dyndb-plugin is not set up yet during DNS > >configuration phase, IPA hostname (i.e. the nameserver) should not > >be required be to resolvable in this phase. > > > >https://fedorahosted.org/freeipa/ticket/3248 > ACK. > > -- > / Alexander Bokovoy > > > > ------------------------------ > > Message: 6 > Date: Fri, 09 Nov 2012 14:26:18 +0100 > From: Martin Kosek > > To: Alexander Bokovoy > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 332 Do not require resolvable > nameserver in DNS install > Message-ID: <509D047A.5030309 at redhat.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/09/2012 02:15 PM, Alexander Bokovoy wrote: > > On Fri, 09 Nov 2012, Martin Kosek wrote: > >> As named.conf and bind-dyndb-plugin is not set up yet during DNS > >> configuration phase, IPA hostname (i.e. the nameserver) should not > >> be required be to resolvable in this phase. > >> > >> https://fedorahosted.org/freeipa/ticket/3248 > > ACK. > > > > Pushed to master, ipa-3-0. > > Martin > > > > ------------------------------ > > Message: 7 > Date: Fri, 09 Nov 2012 15:25:20 +0100 > From: Jan Cholasta > > To: Lynn Root > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > Public errors > Message-ID: <509D1250.5060404 at redhat.com > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 8.11.2012 17:22, Lynn Root wrote: > > Hmm I hope I understand well enough this time around. > > > > However, when I run the tests, there's this one error message I > come across from `test_user[97]: user_add: Create u'tuser2'` - it > throws `DatabaseError: Type or value exists`. I'm a bit lost on > how to track this down. > > > > Once again - thanks for your help! > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > ----- Original Message ----- > > From: "Martin Kosek" > > > To: "Jan Cholasta" > > > Cc: "Lynn Root" >, > freeipa-devel at redhat.com > > Sent: Thursday, November 8, 2012 8:46:42 AM > > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s > in Public errors > > > > On 11/07/2012 06:46 PM, Jan Cholasta wrote: > >> On 7.11.2012 16:08, Lynn Root wrote: > >>> Third time is a charm? > >>> > >>> Lynn Root > >>> Associate Software Engineer > >>> Red Hat > >>> > >>> ----- Original Message ----- > >>> From: "Jan Cholasta" > > >>> To: "Lynn Root" > > >>> Cc: freeipa-devel at redhat.com > >>> Sent: Monday, November 5, 2012 10:25:32 AM > >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to > %s in Public errors > >>> > >>> On 5.11.2012 09:43, Lynn Root wrote: > >>>> Here's try #2! Adjusted patch attached. Let me know if > there's anything > >>>> else I've missed. > >>>> > >>>> Switched %r specifiers to '%s' in Public errors, and adjusted > tests to > >>>> expect no preceding 'u'. > >>>> > >>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & > >>>> https://fedorahosted.org/freeipa/ticket/2588 > >>>> > >>>> Lynn Root > >>>> Associate Software Engineer > >>>> Red Hat > >>>> > >>>> ----- Original Message ----- > >>>> From: "Martin Kosek" > > >>>> To: "Jan Cholasta" > > >>>> Cc: "Lynn Root" >, > freeipa-devel at redhat.com > >>>> Sent: Tuesday, October 30, 2012 9:08:33 AM > >>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to > %s in Public > >>>> errors > >>>> > >>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: > >>>>> Hi, > >>>>> > >>>>> On 29.10.2012 19:54, Lynn Root wrote: > >>>>>> Hi all! > >>>>>> > >>>>>> This switch drops the preceding 'u' from strings in public > error messages. > >>>>>> > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 > >>>>>> > >>>>>> This patch also addresses the unfriendly 'u' from > re-raising errors from the > >>>>>> external call to netaddr.IPAddress by passing a bytestring > to the function. > >>>>>> > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 > >>>>>> > >>>>>> > >>>>>> My first patch (and freeipa dev list email) ever! Let me > know where there's > >>>>>> room to improve. > >>>>>> > >>>>>> Lynn Root > >>>>>> Associate Software Engineer > >>>>>> Red Hat > >>>>>> > >>>>> > >>>>> I think it would be nice if you kept the quotes around the > values, as that is > >>>>> probably the reason "%r" was used in the first place - i.e. > use "'%s'" instead > >>>>> of plain "%s". > >>>> > >>>> +1 > >>>> > >>>> With current patch, I assume that a lot of unit tests will > fail as they check > >>>> exact error message wording. I'd recommend running the whole > test suite with > >>>> your second patch revision. There is a short walkthrough how > to set it up: > >>>> > >>>> http://freeipa.org/page/Testing > >>>> > >>>> Martin > >>>> > >>> > >>> You missed a few: > >>> > >>> $ git grep -En '%(\(.*?\))?r' > >>> > >>> Honza > >>> > >> > >> I think you have gone too far this time :-) It is not necessary > (or wise) to > >> get rid of %r *everywhere* in the code. > > > > Thanks Honza for pointing that out. It seems I missed that in > yesterday's > > review. Now, when I look at it, it indeed is not right. > > > >> > >> A few rules to keep in mind: > >> > >> * If it is not an error message, do not touch it (log > messages are not error > >> messages BTW). > >> > >> * If it is an error message for an exception that does not > inherit from > >> errors.PublicError, do not touch it (there might be a few > exceptions, though). > > > > Right. But for example, your netaddr str conversions should be > fine since the > > netaddr error is propagated up to the ValidationError. > > > > Martin > > > >> > >> * Use '%s' (%s with ticks) only for arguments whose value > can be only str or > >> unicode. > >> > >> Honza > >> > > > > This is better, thanks. > > In OverlapError.format, remove the ticks around %s, as we expect a > list > here (I think we could make it look prettier, similar to what > Martin did > in > , > but I'm not sure if we want to do it in this ticket/patch). > > I'm not sure what to do about the ValidationError at > ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it > should be "TypeError(TYPE_ERROR % (self.name , > self.type, value, > type(value)))" instead, as by the time parameters are validated > they are > the right type. > > Also there is one %r you missed in ipalib/parameters.py:1554. > > Honza > > -- > Jan Cholasta > > > > ------------------------------ > > Message: 8 > Date: Fri, 09 Nov 2012 09:36:20 -0500 > From: Rob Crittenden > > To: Martin Kosek > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 330 Disable global forwarding > per-zone > Message-ID: <509D14E4.70209 at redhat.com > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Martin Kosek wrote: > > On 11/02/2012 11:08 AM, Martin Kosek wrote: > >> On 11/02/2012 10:51 AM, Jan Cholasta wrote: > >>> Hi, > >>> > >>> On 2.11.2012 09:12, Martin Kosek wrote: > >>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: > >>>>> 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 > >>>>> > >>>> > >>>> Fixed both. After a short discussion with Petr Spacek I also > added a > >>>> possibility to set global dnsconfig to NONE. > >>>> > >>>> On a different note, I discovered that global forwarders in > >>>> bind-dyndb-ldap/bind are actually broken with referred > bind-dyndb-ldap/bind > >>>> version. Thus, we may want to bump bind-dyndb-ldap version in > spec when this is > >>>> resolved. (This should not affect diff in dns.py in any way). > >>>> > >>>> Martin > >>>> > >>> > >>> This might be a stupid question, but why is "NONE" in upper > case and the rest > >>> of the values in lower case? > >>> > >>> Honza > >>> > >> > >> This really doesn't matter function-wise, as bind-dydnb-ldap > does the > >> comparison in case insensitive way. My original intention was > to be consistent > >> with other NONE values we use across IPA and to distinguish the > value from > >> valid BIND values. > >> > >> But you are right that within dns plugin it makes more sense to > have it all > >> lowercase. > >> > >> Updated patch attached. > >> > >> Martin > >> > > > > bind-dyndb-ldap with fixed forwarding has been released. Sending > an updated > > patch for both master and ipa-3-0 branches with its version in > our spec file. > > > > Martin > > > > ACK x2 > > > > ------------------------------ > > Message: 9 > Date: Fri, 09 Nov 2012 15:40:06 +0100 > From: Martin Kosek > > To: Rob Crittenden > > Cc: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] [PATCH] 330 Disable global forwarding > per-zone > Message-ID: <509D15C6.7090806 at redhat.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/09/2012 03:36 PM, Rob Crittenden wrote: > > Martin Kosek wrote: > >> On 11/02/2012 11:08 AM, Martin Kosek wrote: > >>> On 11/02/2012 10:51 AM, Jan Cholasta wrote: > >>>> Hi, > >>>> > >>>> On 2.11.2012 09:12, Martin Kosek wrote: > >>>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: > >>>>>> 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 > >>>>>> > >>>>> > >>>>> Fixed both. After a short discussion with Petr Spacek I also > added a > >>>>> possibility to set global dnsconfig to NONE. > >>>>> > >>>>> On a different note, I discovered that global forwarders in > >>>>> bind-dyndb-ldap/bind are actually broken with referred > bind-dyndb-ldap/bind > >>>>> version. Thus, we may want to bump bind-dyndb-ldap version > in spec when > >>>>> this is > >>>>> resolved. (This should not affect diff in dns.py in any way). > >>>>> > >>>>> Martin > >>>>> > >>>> > >>>> This might be a stupid question, but why is "NONE" in upper > case and the rest > >>>> of the values in lower case? > >>>> > >>>> Honza > >>>> > >>> > >>> This really doesn't matter function-wise, as bind-dydnb-ldap > does the > >>> comparison in case insensitive way. My original intention was > to be consistent > >>> with other NONE values we use across IPA and to distinguish > the value from > >>> valid BIND values. > >>> > >>> But you are right that within dns plugin it makes more sense > to have it all > >>> lowercase. > >>> > >>> Updated patch attached. > >>> > >>> Martin > >>> > >> > >> bind-dyndb-ldap with fixed forwarding has been released. > Sending an updated > >> patch for both master and ipa-3-0 branches with its version in > our spec file. > >> > >> Martin > >> > > > > ACK x2 > > Pushed to master, ipa-3-0. > > Martin > > > > ------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > End of Freeipa-devel Digest, Vol 66, Issue 34 > ********************************************* > > > > > _______________________________________________ > 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 Mon Nov 12 15:31:18 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Nov 2012 16:31:18 +0100 Subject: [Freeipa-devel] [PATCH] 0098 Provide explicit user name for Dogtag installation scripts Message-ID: <50A11646.4050403@redhat.com> See commit message. Dogtag is changing its behavior soon (as in: tomorrow). This patch will be needed for IPA to install on Fedora 18. It would be nice if this went in our daily builds ASAP, so Dogtag people can test. Sorry for the short notice, I originally misunderstood Ade and included it in the merged database patches. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0098-Provide-explicit-user-name-for-Dogtag-installation-s.patch Type: text/x-patch Size: 1636 bytes Desc: not available URL: From jcholast at redhat.com Mon Nov 12 16:42:21 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Nov 2012 17:42:21 +0100 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <20121109165843.GV31678@hendrix.brq.redhat.com> References: <20120817114430.GC24190@zeppelin.brq.redhat.com> <223750653.6801841.1345220427417.JavaMail.root@redhat.com> <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> <20121106235321.GC2813@hendrix.redhat.com> <509A8A4E.2050807@redhat.com> <20121109165843.GV31678@hendrix.brq.redhat.com> Message-ID: <50A126ED.9090000@redhat.com> On 9.11.2012 17:58, Jakub Hrozek wrote: > On Wed, Nov 07, 2012 at 05:20:30PM +0100, Martin Kosek wrote: >> On 11/07/2012 12:53 AM, Jakub Hrozek wrote: >>> On Wed, Oct 31, 2012 at 01:22:52PM +0100, Martin Kosek wrote: >>>> On 10/31/2012 11:00 AM, Jakub Hrozek wrote: >>>>> On Mon, Oct 22, 2012 at 02:14:00PM -0400, Simo Sorce wrote: >>>>>> On Mon, 2012-10-22 at 17:15 +0200, Martin Kosek wrote: >>>>>>> On 10/08/2012 08:27 PM, Rob Crittenden wrote: >>>>>>>> Jakub Hrozek wrote: >>>>>>>>> On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> the attached patches add the directory the SSSD writes domain-realm >>>>>>>>>>> mappings as includedir to krb5.conf when installing the client. >>>>>>>>>>> >>>>>>>>>>> [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for >>>>>>>>>>> options >>>>>>>>>>> ipachangeconf only allows one delimeter between keys and values. This >>>>>>>>>>> patch adds the possibility of also specifying "delim" in the option >>>>>>>>>>> dictionary to override the default delimeter. >>>>>>>>>>> >>>>>>>>>>> On a slightly-unrelated note, we really should think about adopting >>>>>>>>>>> Augeas. Changing configuration with home-grown scripts is getting >>>>>>>>>>> tricky. >>>>>>>>>>> >>>>>>>>>>> [PATCH 2/3] Specify includedir in krb5.conf on new installs >>>>>>>>>>> This patch utilizes the new functionality from the previous patch to >>>>>>>>>>> add >>>>>>>>>>> the includedir on top of the krb5.conf file >>>>>>>>>>> >>>>>>>>>>> [PATCH 3/3] Add the includedir to krb5.conf on upgrades >>>>>>>>>>> This patch is completely untested and I'm only posting it to get >>>>>>>>>>> opinions. At first I was going to use an upgrade script in %post but >>>>>>>>>>> then I thought it would be overengineering when all we want to do is >>>>>>>>>>> prepend one line.. Would a simple munging like this be acceptable or >>>>>>>>>>> shall I write a full script? >>>>>>>>>> >>>>>>>>>> NACK, using a scriptlet is fine, but not the way you did, as it has a huge >>>>>>>>>> race condition where krb5.conf exists and has only one line in it (the >>>>>>>>>> include line). >>>>>>>>>> >>>>>>>>>> You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew >>>>>>>>>> Then cat the contents of the existing file in i:t cat /etc/krb.conf >> >>>>>>>>>> /etc/krb.conf.ipanew >>>>>>>>>> And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf >>>>>>>>>> >>>>>>>>>> This method is also safe wrt something killing the yum process ... >>>>>>>>>> >>>>>>>>>> Simo. >>>>>>>>> >>>>>>>>> I'm attaching a new revision of the patches not even two months after >>>>>>>>> the original nack. >>>>>>>>> >>>>>>>>> I also think it might be nice to have a more general way of upgrading >>>>>>>>> the client config so I filed >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3149 >>>>>>>> >>>>>>>> I don't think grepping for a string is an effective way to determine if the >>>>>>>> client has been configured. Someone could have removed that line. >>>>>>>> >>>>>>>> I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it exists >>>>>>>> and has more than 2 lines in it ([files] + one other file) then it is safe to >>>>>>>> say the client is configured, or at least partially configured. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>> >>>>>>> I just found one more issue. What if ipa-client-install is run with --no-sssd >>>>>>> option? In that case I assume we should not include the SSSD's krb5.include.d, >>>>>>> right? The same would also appy for upgrades, we would need to check if client >>>>>>> was actually configured with SSSD before mangling their krb5.conf. >>>>>> >>>>>> Yeah that's right, we should have all sssd related changes under a >>>>>> conditional that is true only when sssd is enabled. >>>>>> >>>>>> Simo. >>>>> >>>>> OK, new patches are attached. In new installs, the includedir is only >>>>> added when options.sssd is true. During upgrades, I checked for >>>>> sssd.conf's existence, I'm not sure if there's any other way to check if >>>>> the client was configured with sssd? >>>> >>>> Hello Jakub, thanks for these patches. I think that checking if /etc/sssd.conf >>>> exists as actually not so bad way to test if it was configured. Anyway, I did >>>> few tests on server and client but I still see few issues: >>>> >>>> 1) SELinux context of krb5.conf is not as expected (but I am not sure what real >>>> issue could that cause): >>>> >>>> # restorecon -FvvR /etc/krb5.conf >>>> restorecon reset /etc/krb5.conf context >>>> unconfined_u:object_r:etc_t:s0->system_u:object_r:krb5_conf_t:s0 >>>> >>> >>> Fixed. Thanks, I shouldn have noticed that doing mv would just replace >>> the original context. >>> >>>> 2) I can no longer kinit on IPA server after applying your patch >>>> # rpm -q sssd >>>> sssd-1.9.90-0.20121030T1436Zgitf46bf56.fc17.x86_64 >>>> # rpm -Uvh --force freeipa-*.rpm >>>> # head -n 5 /etc/krb5.conf >>>> includedir /var/lib/sss/pubconf/krb5.include.d/ >>>> [logging] >>>> default = FILE:/var/log/krb5libs.log >>>> kdc = FILE:/var/log/krb5kdc.log >>>> admin_server = FILE:/var/log/kadmind.log >>>> # KRB5_TRACE=/dev/stdout kinit admin >>>> [21059] 1351684052.658548: Getting initial credentials for >>>> admin at IDM.LAB.BOS.REDHAT.COM >>>> [21059] 1351684052.665269: Sending request (200 bytes) to IDM.LAB.BOS.REDHAT.COM >>>> [21059] 1351684052.665989: Resolving hostname vm-044.idm.lab.bos.redhat.com >>>> [21059] 1351684052.667511: Sending initial UDP request to dgram 10.16.78.44:88 >>>> [21059] 1351684052.672514: Received answer from dgram 10.16.78.44:88 >>>> [21059] 1351684052.672653: Response was from master KDC >>>> [21059] 1351684052.672751: Received error from KDC: -1765328370/KDC has no >>>> support for encryption type >>>> kinit: KDC has no support for encryption type while getting initial credentials >>>> >>>> >>>> Now when I comment includedir: >>>> # head -n 5 /etc/krb5.conf >>>> # kinit admin >>>> Password for admin at IDM.LAB.BOS.REDHAT.COM: >>>> # echo $? >>>> 0 >>>> >>>> When I upgraded client machine (without krb5kdc), kinit worked fine. Does that >>>> mean that krb5.conf can only be changed on client machines? >>>> >>> >>> I'm still looking into this. I'm not sure why kinit does that and why it >>> does that on the IPA server only. Unfortunately the default krb5 package >>> is so optimized that I need to rebuild one without optimizations. >>> >>>> 3) We should also add Requires on sssd >= 1.9.0 in FreeIPA spec file to pick up >>>> the new feature. Otherwise I just get an error on client: >>>> >>>> # kinit admin >>>> kinit: Included profile directory could not be read while initializing Kerberos >>>> 5 library >>>> >>> >>> Done >>> >>>> 4) (Optional) I think we can make the process of checking if IPA is configured >>>> easier and follow a similar way that Sumit did: >>>> https://fedorahosted.org/freeipa/changeset/fe66fbe637132ac5eb22eea388e2261f33497bf5/ >>>> >>>> This section: >>>> >>>> +restore=0 >>>> +test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') >>>> + >>>> +if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then >>>> + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf >>>> 2>/dev/null ; then >>>> >>>> could then be replaced by something like this: >>>> >>>> python -c "import sys; from ipapython import ipautil; sys.exit(0 if >>>> ipapython.is_ipaclient_configured() else 1);" > /dev/null 2>&1 >>>> if [ $? -eq 0 ]; then >>>> >>>> I am not saying you need to do this step, this can be done later by us. >>> >>> That code currently only exists for IPA server, right? At least judging >>> by: >>> from ipaserver.install import installutils; >>> >>> Then I would prefer to do it separately. It's a good idea, though, the >>> postscript as it is now is ugly. >>> >> >> Thanks for updated patch, now when I updated to the most recent sssd, kinit >> worked for me even though IPA master krb5.conf was updated. Few more issues I >> found follows: >> > > That must have been krb5 updated, sssd does not have much to do with > bare kinit. > >> rpmbuild --define "_topdir /root/freeipa-master/rpmbuild" -ba freeipa.spec >> error: line 179: Bad Requireflags: qualifiers: Requires(postttrans): >> policycoreutils >> make: *** [rpms] Error 1 >> >> This is the reason: >> +Requires(postttrans): policycoreutils >> should be: >> +Requires(posttrans): policycoreutils >> > > Thanks, the requires were misplaced, they were present in the server > section and should have been in the client section..and because I only > tested with make client-rpms (see below), I didn't notice the typo. > >> 2) IPA server krb5.conf is not updated for clean server/replica installation. >> The includedir can get there only with next package update. >> >> install/share/krb5.conf.template would also need to be updated. >> > > Done. I didn't realize the codepaths were different. > >> >> Besides these 2 issues (and the SELinux ones), the patch should be good to go. >> >> Martin > > New patches are attached. > We have discussed the patch with Jakub off-list and decided that the upgrade should be done in %post (with an appropriate $1 check) instead of %posttrans. Besides that, ACK. Honza -- Jan Cholasta From jcholast at redhat.com Mon Nov 12 16:54:22 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Mon, 12 Nov 2012 17:54:22 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <20121109150629.GR31678@hendrix.brq.redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> <5098C2D2.9060309@redhat.com> <20121109150629.GR31678@hendrix.brq.redhat.com> Message-ID: <50A129BE.8020702@redhat.com> On 9.11.2012 16:06, Jakub Hrozek wrote: > On Tue, Nov 06, 2012 at 08:57:06AM +0100, Jan Cholasta wrote: >> On 29.10.2012 17:21, Jakub Hrozek wrote: >>> An improvement based on Honza's suggestion. >>> >> >> You might want to remove the try block around >> "sssdconfig.activate_service('autofs')". If it throws NoServiceError >> at this point, there is something really broken in SSSDConfig, in >> which case it is better to display a traceback rather than a nice >> error message IMO. >> > > In retrospective, I agree. We can't try-except every line. > Add an appropriate sys.exit() at the end of the except SSSDConfig.ServiceNotRecognizedError block and it's an ACK. Honza -- Jan Cholasta From pviktori at redhat.com Mon Nov 12 17:39:48 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 12 Nov 2012 18:39:48 +0100 Subject: [Freeipa-devel] [PATCH 82] Compliant client side session cookie behavior In-Reply-To: <50A02438.50601@redhat.com> References: <50A02438.50601@redhat.com> Message-ID: <50A13464.6040908@redhat.com> On 11/11/2012 11:18 PM, John Dennis wrote: > Note: This has been tested with both the command line api and the > browser on both Fedora and RHEL-6. It has also been tested to make sure > any cookies stored before an upgrade will work correctly. > Since you asked for a quick review, I'll send what I have today. I haven't actually tested, and I probably missed a lot. > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > freeipa-jdennis-0082-Compliant-client-side-session-cookie-behavior.patch > > >>From 089d69a1e06636bbd2836fcb9072b5a2ffef7ae2 Mon Sep 17 00:00:00 2001 > From: John Dennis > Date: Sun, 11 Nov 2012 17:05:32 -0500 > Subject: [PATCH 82] Compliant client side session cookie behavior > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: 8bit > > In summary this patch does: > > * Follow the defined rules for cookies when: > > - receiving a cookie (process the attributes) > > - storing a cookie (store cookie + attributes) > > - sending a cookie > > + validate the cookie domain against the request URL > > + validate the cookie path against the request URL > > + validate the cookie expiration > > + if valid then send only the cookie, no attribtues > > * Modifies how a request URL is stored during a XMLRPC > request/response sequence. > > * Refactors a bit of the request/response logic to allow for making > the decision whether to send a session cookie instead of full > Kerberous auth easier. > > * The server now includes expiration information in the session cookie > it sends to the client. The server always had the information > available to prevent using an expired session cookie. Now that > expiration timestamp is returned to the client as well and now the > client will not send an expired session cookie back to the server. > > * Adds a new module and unit test for cookies (see below) > > Formerly we were always returning the session cookie no matter what > the domain or path was in the URL. We were also sending the cookie > attributes which are for the client only (used to determine if to > return a cookie). The attributes are not meant to be sent to the > server and the previous behavior was a protocol violation. We also > were not checking the cookie expiration. > > Cookie library issues: > > We need a library to create, parse, manipulate and format cookies both > in a client context and a server context. Core Python has two cookie > libraries, Cookie.py and cookielib.py. Why did we add a new cookie > module instead of using either of these two core Python libaries? > > Cookie.py is designed for server side generation but can be used to > parse cookies on the client. It's the library we were using in the > server. However when I tried to use it in the client I discovered it > has some serious bugs. There are 7 defined cookie elements, it fails > to correctly parse 3 of the 7 elements which makes it unusable because > we depend on those elements. Please include links to relevant bug reports in the docstring. > Since Cookie.py was designed for server > side cookie processing it's not hard to understand how fails to > correctly parse a cookie because that's a client side need. (Cookie.py > also has an awkward baroque API and is missing some useful > functionality we would have to build on top of it). > > cookielib.py is designed for client side. It's fully featured and obeys > all the RFC's. It would be great to use however it's tightly coupled > with another core library, urllib2.py. The http request and response > objects must be urllib2 objects. But we don't use urllib2, rather we use > httplib because xmlrpclib uses httplib. I don't see a reason why a > cookie library should be so tightly coupled to a protocol library, but > it is and that means we can't use it (I tried to just pick some isolated > entrypoints for our use but I kept hitting interaction/dependency problems). > > I decided to solve the cookie library problems by writing a minimal > cookie library that does what we need and no more than that. It is a > new module in ipapython shared by both client and server and comes > with a new unit test. The module has plenty of documentation, no need > to repeat it here. This sucks. Designing, implementing and maintaining our own version of general code is never good. I'd like to discuss with the other developers so everyone knows what's happening in this patch. Also, API design is a hard thing to do. I'd prefer if we made a subset of an existing API (especially if there's any hope of the standard library being fixed) rather than invented a new one. Please add the following paragraph to the cookie.py docstring, so people know our implementation is incomplete: > It doesn't have every bell and whistle nor can it > handle all the cookie scenarios found in the wild with random servers > and browsers, it does what we need in an RFC manner (but not all RFC > features). > > Request URL issues: > > We also had problems in rpc.py whereby information from the request > which is needed when we process the response is not available. Most > important was the requesting URL. It turns out that the way the class > and object relationships are structured it's impossible to get this > information. Someone else must have run into the same issue because > there was a routine called reconstruct_url() which attempted to > recreate the request URL from other available > information. Unfortunately reconstruct_url() was not callable from > inside the response handler. So I decided to store the information in > the thread context and when the request is received extract it from > the thread context. It's perhaps not an ideal solution but we do > similar things elsewhere so at least it's consistent. I removed the > reconstruct_url() function because the exact information is now in the > context and trying to apply heuristics to recreate the url is probably > not robust. I'm no fan of global state, but I guess there's no other way :( > Tickethttps://fedorahosted.org/freeipa/ticket/3022 > --- > ipalib/rpc.py | 224 +++++++++++++---- > ipalib/session.py | 39 +-- > ipapython/cookie.py | 486 ++++++++++++++++++++++++++++++++++++ > ipaserver/rpcserver.py | 6 +- > tests/test_ipapython/test_cookie.py | 332 ++++++++++++++++++++++++ > 5 files changed, 1017 insertions(+), 70 deletions(-) > create mode 100644 ipapython/cookie.py > create mode 100644 tests/test_ipapython/test_cookie.py > > diff --git a/ipalib/rpc.py b/ipalib/rpc.py > index c555105..b2021c1 100644 > --- a/ipalib/rpc.py > +++ b/ipalib/rpc.py > @@ -37,6 +37,7 @@ import sys > import os > import errno > import locale > +import datetime > from xmlrpclib import (Binary, Fault, dumps, loads, ServerProxy, Transport, > ProtocolError, MININT, MAXINT) > import kerberos > @@ -48,8 +49,10 @@ from ipalib.errors import public_errors, PublicError, UnknownError, NetworkError > from ipalib import errors > from ipalib.request import context, Connection > from ipalib.util import get_current_principal > +from ipapython.ipa_log_manager import * I understand star imports are current practice for ipa_log_manager, but I believe it is time to start changing it. Especially since you're just using one of the 8 names you're importing. But if you don't agree, keep it and let's save the argument for another day. > from ipapython import ipautil > from ipapython import kernel_keyring > +from ipapython.cookie import Cookie > from ipalib.text import _ > > import httplib > @@ -61,7 +64,8 @@ from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT > KRB5_FCC_PERM, KRB5_FCC_NOFILE, KRB5_CC_FORMAT, KRB5_REALM_CANT_RESOLVE > from ipapython.dn import DN > > -COOKIE_NAME = 'ipa_session_cookie:%s' > +COOKIE_NAME = 'ipa_session' > +KEYRING_COOKIE_NAME = '%s_cookie:%%s' % COOKIE_NAME > > def xml_wrap(value): > """ > @@ -310,9 +314,9 @@ class KerbTransport(SSLTransport): > if not isinstance(extra_headers, list): > extra_headers = [] > > - session_data = getattr(context, 'session_data', None) > - if session_data: > - extra_headers.append(('Cookie', session_data)) > + session_cookie = getattr(context, 'session_cookie', None) > + if session_cookie: > + extra_headers.append(('Cookie', session_cookie)) > return (host, extra_headers, x509) > > # Set the remote host principal > @@ -345,16 +349,64 @@ class KerbTransport(SSLTransport): > finally: > self.close() > > + def store_session_cookie(self, cookie_header): > + ''' > + Given the contents of a Set-Cookie header scan the header and > + extract each cookie contained within until the session cookie > + is located. Examine the session cookie if the domain and path > + are specified, if not update the cookie with those values from > + the request URL. Then write the session cookie into the key > + store for the principal. If the cookie header is None or the > + session cookie is not present in the header no action is > + taken. > + > + Context Dependencies: > + Here and in other places, Git complains about whitespace at end of line. > + The per thread context is expected to contain: > + principal > + The current pricipal the HTTP request was issued for. > + request_url > + The URL of the HTTP request. > + > + ''' > + > + if cookie_header is None: > + return > + > + principal = getattr(context, 'principal', None) > + root_logger.debug("received Set-Cookie '%s'", cookie_header) > + > + # Search for the session cookie > + try: > + session_cookie = Cookie.get_named_cookie_from_string(cookie_header, COOKIE_NAME) > + except Exception, e: > + root_logger.debug("unable to parse cookie header '%s': %s", cookie_header, e) > + return > + > + # If the domain or path is not specified it defaults the > + # values in the request URL > + request_url = getattr(context, 'request_url', None) > + scheme, netloc, path, params, query, fragment = urlparse.urlparse(request_url) > + > + if not session_cookie.domain: > + session_cookie.domain = netloc > + > + if not session_cookie.path: > + session_cookie.path = path > + > + # Normalize the expiration prior to storage > + session_cookie.normalize_expiration() > + > + cookie_string = str(session_cookie) > + root_logger.debug("storing cookie '%s' for principal %s", cookie_string, principal) > + try: > + kernel_keyring.update_key(KEYRING_COOKIE_NAME % principal, cookie_string) > + except ValueError, e: > + # Not fatal, we just can't use the session cookie we were sent. > + pass > + > def parse_response(self, response): > - session_cookie = response.getheader('Set-Cookie') > - if session_cookie: > - principal = getattr(context, 'principal', None) > - try: > - kernel_keyring.update_key(COOKIE_NAME % principal, session_cookie) > - except ValueError, e: > - # Not fatal, we just can't use the session cookie we were > - # sent. > - pass > + self.store_session_cookie(response.getheader('Set-Cookie')) > return SSLTransport.parse_response(self, response) > > > @@ -377,22 +429,6 @@ class xmlclient(Connectible): > super(xmlclient, self).__init__() > self.__errors = dict((e.errno, e) for e in public_errors) > > - def reconstruct_url(self): > - """ > - The URL directly isn't stored in the ServerProxy. We can't store > - it in the connection object itself but we can reconstruct it > - from the ServerProxy. > - """ > - if not hasattr(self.conn, '_ServerProxy__transport'): > - return None > - if (isinstance(self.conn._ServerProxy__transport, KerbTransport) or > - isinstance(self.conn._ServerProxy__transport, DelegatedKerbTransport)): > - scheme = "https" > - else: > - scheme = "http" > - server = '%s://%s%s' % (scheme, ipautil.format_netloc(self.conn._ServerProxy__host), self.conn._ServerProxy__handler) > - return server > - > def get_url_list(self, xmlrpc_uri): > """ > Create a list of urls consisting of the available IPA servers. > @@ -425,40 +461,124 @@ class xmlclient(Connectible): > > return servers > > + def apply_session_cookie(self, url): > + ''' > + Attempt to load a session cookie for the current principal > + from the key store. If the cookie is successfully loaded > + adjust the input url's to point to the session path and insert > + the session cookie into the per thread context for later > + insertion into the HTTP request. If the cookie is not > + successfully loaded then the original url is returned and the > + per thread context is not modified. > + > + Successful session cookie loading depends on the following: > + > + * A session cookie for the current principal must exist in the > + key store. > + > + * The request url's host must match the cookie's doman. > + > + * The path in the request url must contain the cookie's path. > + > + * If the cookie defines an expiration date then the current > + time must be less or equal to the cookie's expiration > + timestamp. > + > + Context Dependencies: > + > + The per thread context is expected to contain: > + principal > + The current pricipal the HTTP request was issued for. > + > + The per thread context will be updated with: > + session_cookie > + A cookie string to be inserted into the Cookie header > + of the HTPP request. > + > + ''' This method does too much. Can you split it into one that updates the global state (and possibly stores the URL there), and another that modifies the URL? > + original_url = url > + principal = getattr(context, 'principal', None) > + > + try: > + keyring_data = kernel_keyring.read_key(KEYRING_COOKIE_NAME % principal) > + except Exception, e: > + return original_url > + > + # Substitute the session path > + scheme, netloc, path, params, query, fragment = urlparse.urlparse(original_url) > + path = '/ipa/session/xml' > + session_url = urlparse.urlunparse((scheme, netloc, path, params, query, fragment)) > + > + # Decide if we should send the cookie to the server > + # It has to match the domain and path and not be expired > + > + # Search for the session cookie > + try: > + session_cookie = Cookie.get_named_cookie_from_string(keyring_data, COOKIE_NAME) > + except Exception, e: > + session_cookie = None > + > + if not session_cookie: > + self.log.debug("failed to find session_cookie in keyring data '%s'", keyring_data) > + return original_url > + > + self.debug("found session_cookie in keyring '%s'", session_cookie) > + > + cookie_expiration = session_cookie.get_expiration() > + if cookie_expiration is not None: > + now = datetime.datetime.utcnow() > + if cookie_expiration < now: > + self.log.debug("session_cookie expired at %s, not sending session_cookie", cookie_expiration) > + kernel_keyring.del_key(KEYRING_COOKIE_NAME % principal) > + return original_url > + > + if session_cookie.domain is not None and session_cookie.domain != netloc: > + self.log.debug("session_cookie domain '%s' does not match connection domain '%s', not sending session_cookie", > + session_cookie.domain, netloc) > + return original_url > + > + if session_cookie.path is not None and not path.startswith(session_cookie.path): > + self.log.debug("URL path '%s' does not start with session_cookie path '%s', not sending session_cookie", > + path, session_cookie.path) > + return original_url > + > + # O.K. session_cookie is valid to be returned, stash it away where it will will > + # get included in a HTTP Cookie headed sent to the server. > + self.log.debug("setting session_cookie into context '%s'", session_cookie) > + setattr(context, 'session_cookie', session_cookie.http_cookie()) I don't understand why setattr is needed here. Why would a simple context.session_cookie = session_cookie.http_cookie() not work? More of the same below. > + > + return session_url > + > def create_connection(self, ccache=None, verbose=False, fallback=True, > delegate=False): > try: > - session = False > - session_data = None > xmlrpc_uri = self.env.xmlrpc_uri > principal = get_current_principal() > setattr(context, 'principal', principal) > # We have a session cookie, try using the session URI to see if it > # is still valid > if not delegate: > - session_data = kernel_keyring.read_key(COOKIE_NAME % principal) > - setattr(context, 'session_data', session_data) > - (scheme, netloc, path, params, query, fragment) = urlparse.urlparse(self.env.xmlrpc_uri) > - xmlrpc_uri = urlparse.urlunparse((scheme, netloc, '/ipa/session/xml', params, query, fragment)) > - session = True > + xmlrpc_uri = self.apply_session_cookie(xmlrpc_uri) > except ValueError: > # No session key, do full Kerberos auth > pass > - servers = self.get_url_list(xmlrpc_uri) > + urls = self.get_url_list(xmlrpc_uri) > serverproxy = None > - for server in servers: > + for url in urls: > kw = dict(allow_none=True, encoding='UTF-8') > kw['verbose'] = verbose > - if server.startswith('https://'): > + if url.startswith('https://'): > if delegate: > kw['transport'] = DelegatedKerbTransport() > else: > kw['transport'] = KerbTransport() > else: > kw['transport'] = LanguageAwareTransport() > - self.log.info('trying %s' % server) > - serverproxy = ServerProxy(server, **kw) > - if len(servers) == 1: > + self.log.info('trying %s' % url) > + setattr(context, 'request_url', url) > + serverproxy = ServerProxy(url, **kw) > + if len(urls) == 1: > # if we have only 1 server and then let the > # main requester handle any errors. This also means it > # must handle a 401 but we save a ping. > @@ -476,7 +596,7 @@ class xmlclient(Connectible): > raise UnknownError( > code=e.faultCode, > error=e.faultString, > - server=server, > + server=url, > ) > # We don't care about the response, just that we got one > break > @@ -484,11 +604,11 @@ class xmlclient(Connectible): > # kerberos error on one server is likely on all > raise errors.KerberosError(major=str(krberr), minor='') > except ProtocolError, e: > - if session_data and e.errcode == 401: > + if context.has_key('session_cookie') and e.errcode == 401: What is has_key? Did you mean to use hasattr? > # Unauthorized. Remove the session and try again. > - delattr(context, 'session_data') > + delattr(context, 'session_cookie') Since you're touching the code, can you switch to `del context.session_cookie`? (again, ignore this comment if there's some deeper magic you're working around) More of the same below. > try: > - kernel_keyring.del_key(COOKIE_NAME % principal) > + kernel_keyring.del_key(KEYRING_COOKIE_NAME % principal) > except ValueError: > # This shouldn't happen if we have a session but > # it isn't fatal. > @@ -504,7 +624,7 @@ class xmlclient(Connectible): > > if serverproxy is None: > raise NetworkError(uri=_('any of the configured servers'), > - error=', '.join(servers)) > + error=', '.join(urls)) > return serverproxy > > def destroy_connection(self): > @@ -529,7 +649,7 @@ class xmlclient(Connectible): > raise ValueError( > '%s.forward(): %r not in api.Command' % (self.name, name) > ) > - server = self.reconstruct_url() > + server = getattr(context, 'request_url', None) > self.info('Forwarding %r to server %r', name, server) > command = getattr(self.conn, name) > params = [args, kw] > @@ -554,13 +674,13 @@ class xmlclient(Connectible): > # By catching a 401 here we can detect the case where we have > # a single IPA server and the session is invalid. Otherwise > # we always have to do a ping(). > - session_data = getattr(context, 'session_data', None) > - if session_data and e.errcode == 401: > + session_cookie = getattr(context, 'session_cookie', None) > + if session_cookie and e.errcode == 401: > # Unauthorized. Remove the session and try again. > - delattr(context, 'session_data') > + delattr(context, 'session_cookie') > try: > principal = getattr(context, 'principal', None) > - kernel_keyring.del_key(COOKIE_NAME % principal) > + kernel_keyring.del_key(KEYRING_COOKIE_NAME % principal) > except ValueError: > # This shouldn't happen if we have a session but > # it isn't fatal. > diff --git a/ipalib/session.py b/ipalib/session.py > index 36beece..900259a 100644 > --- a/ipalib/session.py > +++ b/ipalib/session.py > @@ -17,7 +17,6 @@ > # along with this program. If not, see. > > import memcache > -import Cookie > import random > import errors > import os > @@ -28,6 +27,7 @@ from ipapython.ipa_log_manager import * > from ipalib import api, errors > from ipalib import Command > from ipalib.krb_utils import * > +from ipapython.cookie import Cookie > > __doc__ = ''' > Session Support for IPA > @@ -955,13 +955,18 @@ class MemcacheSessionManager(SessionManager): > Session id as string or None if not found. > ''' > session_id = None > - if cookie_header is not None: > - cookie = Cookie.SimpleCookie() > - cookie.load(cookie_header) > - session_cookie = cookie.get(self.session_cookie_name) > - if session_cookie is not None: > - session_id = session_cookie.value > - self.debug('found session cookie_id = %s', session_id) > + try: > + session_cookie = Cookie.get_named_cookie_from_string(cookie_header, self.session_cookie_name) > + except Exception, e: > + session_cookie = None > + else: > + session_id = session_cookie.value > + > + if session_id is None: > + self.debug('no session cookie found') > + else: > + self.debug('found session cookie_id = %s', session_id) > + > return session_id > > > @@ -1050,7 +1055,7 @@ class MemcacheSessionManager(SessionManager): > self.mc.set(session_key, session_data, time=session_expiration_timestamp) > return session_id > > - def generate_cookie(self, url_path, session_id, add_header=False): > + def generate_cookie(self, url_path, session_id, expiration=None, add_header=False): > ''' > Return a session cookie containing the session id. The cookie > will be contrainted to the url path, defined for use > @@ -1068,15 +1073,17 @@ class MemcacheSessionManager(SessionManager): > :returns: > cookie string > ''' > - cookie = Cookie.SimpleCookie() > - cookie[self.session_cookie_name] = session_id > - cookie[self.session_cookie_name]['path'] = url_path > - cookie[self.session_cookie_name]['httponly'] = True > - cookie[self.session_cookie_name]['secure'] = True > + > + if not expiration: # Catch zero unix timestamps which are zero Too much redundancy in the comment > + expiration = None; > + > + cookie = Cookie(self.session_cookie_name, session_id, > + path=url_path, httponly= True, secure=True, > + expires=expiration) > if add_header: > - result = cookie.output().strip() > + result = 'Set-Cookie: %s' % cookie > else: > - result = cookie.output(header='').strip() > + result = str(cookie) > > return result > > diff --git a/ipapython/cookie.py b/ipapython/cookie.py > new file mode 100644 > index 0000000..0033aed > --- /dev/null > +++ b/ipapython/cookie.py > @@ -0,0 +1,486 @@ > +# Authors: > +# John Dennis > +# > +# Copyright (C) 2012 Red Hat > +# see file 'COPYING' for use and warranty information > +# > +# 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 Foundation, either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see. > + > +import re > +import time > +import datetime > +from calendar import timegm > + > +''' > +Core Python has two cookie libraries, Cookie.py targeted to server > +side and cookielib.py targeted to client side. So why this module and > +not use the standard libraries? > + > +Cookie.py has some serious bugs, it cannot correctly parse the > +HttpOnly, Secure, and Expires cookie attributes (more of a client side > +need and not what it was designed for). Since we utilize those > +attributes that makes Cookie.py a non-starter. Plus it's API awkard > +and limited (we would have to build more on top of it). > + > +cookielib.py has a lot of good featuress, a nice API and covers all > +the relevant RFC's as well as actual practice in the field. However > +cookielib.py is tighly integrated with urllib2 and it's not possible > +to use most of the features of cookielib without simultaneously using > +urllib2. Unfortunataely we only use httplib because of our dependency > +on xmlrpclib. Without urllib2 cookielib is a non-starter. > + > +This module is a minimal implementation of Netscape cookies which > +works equally well on either the client or server side. It's API is > +easy to use with cookie attributes as class properties which can be > +read or set easily. The Cookie object automatically converts Expires > +and Max-Age attributes into datetime objects for easy time > +comparision. Cookies in strings can easily be parsed, including > +multiple cookies in the HTTP_COOKIE envionment variable. > +''' > + > +#------------------------------------------------------------------------------- > +class Cookie(object): > + ''' > + A Cookie object has the following attributes: > + > + key > + The name of the cookie > + value > + The value of the cookie > + > + A Cookie also supports these predefined optional attributes. If an > + optional attribute is not set on the cookie it's value is None. > + > + domain > + Restrict cookie usage to this domain > + path > + Restrict cookie usage to this path or below > + expires > + Cookie is invalid after this UTC timestamp > + max_age > + Cookie is invalid this many seconds in the future. > + Has precedence over the expires attribute. > + secure > + Cookie should only be returned on secure (i.e. SSL/TLS) > + connections. > + httponly > + Cookie is intended only for HTTP communication, it can > + never be utilized in any other context (e.g. browser > + Javascript). > + > + See the documentation of get_expiration() for an explanation of > + how the expires and max-age attributes interact as well as the > + role of the timestamp attribute. Expiration values are stored as > + datetime objects for easy manipulation and comparision. > + > + There are two ways to instantiate a Cookie object. Either directly > + via the constructor or by calling the class function parse() which > + returns a list of Cookie objects found in a string. > + > + ''' > + > + # regexp to split fields at a semi-colon > + field_re = re.compile(r';\s*') > + > + # regexp to locate a key/value pair > + kv_pair_re = re.compile(r'^\s*([a-zA-Z0-9\!\#\$\%\&\'\*\+\-\.\^\_\`\|\~]+)\s*=\s*(.*?)\s*$', re.IGNORECASE) > + > + # Reserved attribute names, maps from lower case protocol name to > + # object attribute name > + attrs = {'domain' : 'domain', > + 'path' : 'path', > + 'max-age' : 'max_age', > + 'expires' : 'expires', > + 'secure' : 'secure', > + 'httponly' : 'httponly'} > + > + # Debug flag for class > + debug = False We have a fancy logging module that allows us to easily tune loggers for individual classes. Please use it instead of inventing a mechanism based on class-wide flags and print statements. > + > + @classmethod > + def datetime_to_time(cls, dt): As far as I can see, this method isn't used anywhere. Why add it? > + ''' > + Timestamps (timestamp & expires) are stored as datetime > + objects in UTC. It's non-obvious how to convert a naive UTC > + datetime into a unix time value (seconds since the epoch > + UTC). That functionality is oddly missing from the datetime > + and time modules. This utility provides that missing > + functionality. > + ''' > + # Use timegm from the calendar module > + return timegm(dt.utctimetuple()) > + > + @classmethod > + def datetime_to_string(cls, dt=None): Why is this a class method and not a normal function? It doesn't use cls at all, and there's no value in overriding it in subclasses. Same for the other classmethods. > + ''' > + Given a datetime object in UTC generate RFC 1123 date string. > + ''' > + > + # Try to verify dt is specified as UTC. If utcoffset is not > + # available we'll just have to assume the caller is using the > + # correct timezone. > + utcoffset = dt.utcoffset() > + if utcoffset is not None and utcoffset.total_seconds() != 0.0: > + raise ValueError("timezone is not UTC") > + > + # At this point we've validated as much as possible the timezone > + # is UTC or GMT but we can't use the %Z timezone format specifier > + # because the timezone in the string must be 'GMT', not something > + # equivalent to GMT, so we merely append the GMT timezone string. > + > + s = datetime.datetime.strftime(dt, '%a, %d %b %Y %H:%M:%S') > + return s + ' GMT' AFAIK `return datetime.datetime.strftime(dt, '%a, %d %b %Y %H:%M:%S GMT')` would work just as well. > + > + @classmethod > + def parse_datetime(cls, s): > + ''' > + Parse a RFC 822, RFC 1123 date string, return a datetime aware object in UTC. > + Accommodates some non-standard formats found in the wild. > + ''' > + > + formats = ['%a, %d %b %Y %H:%M:%S', > + '%a, %d-%b-%Y %H:%M:%S', > + '%a, %d-%b-%y %H:%M:%S', > + '%a, %d %b %y %H:%M:%S', > + ] > + s = s.strip() > + > + # strptime does not read the time zone and generate a tzinfo > + # object to insert in the datetime object so there is little point > + # in specifying a %Z format, instead verify GMT is specified and > + # generate the datetime object as if it were UTC. > + > + if not s.endswith(' GMT'): > + raise ValueError("http date string '%s' does not end with GMT time zone" % s) > + s = s[:-4] > + > + dt = None > + for format in formats: > + try: > + dt = datetime.datetime(*(time.strptime(s, format)[0:6])) > + break > + except Exception: > + continue > + > + if dt is None: > + raise ValueError("unable to parse expires datetime '%s'" % s) > + > + return dt > + > + > + @classmethod > + def parse(cls, cookie_string): > + ''' > + Given a string containing one or more cookies (the > + HTTP_COOKIES environment variable typically contains multiple > + cookies) parse the string and return a list of Cookie objects > + found in the string. > + ''' > + > + # Our list of returned cookies > + cookies = [] > + > + # Split the input string at semi-colon boundaries, we call this a > + # field. A field may either be a single keyword or a key=value > + # pair. > + fields = Cookie.field_re.split(cookie_string) > + if Cookie.debug: print "fields=%s" % (fields) > + > + # The input string may have multiple cookies inside it. This is > + # common when the string comes from a HTTP_COOKIE environment > + # variable. All the cookies will be contenated, separated by a > + # semi-colon. Semi-colons are also the separator between > + # attributes in a cookie. > + # > + # To distinguish between two adjacent cookies in a string we > + # have to locate the key=value pair at the start of a > + # cookie. Unfortunately cookies have attributes that also look > + # like key/value pairs, the only way to distinguish a cookie > + # attribute from a cookie is the fact the attribute names are > + # reserved. A cookie attribute may either be a key/value pair > + # or a single key (e.g. HttpOnly). As we scan the cookie we > + # first identify the key=value (cookie name, cookie > + # value). Then we continue scanning, if a bare key or > + # key/value pair follows and is a known reserved keyword than > + # that's an attribute belonging to the current cookie. As soon > + # as we see a key/value pair whose key is not reserved we know > + # we've found a new cookie. Bare keys (no value) can never > + # start a new cookie. > + > + # Iterate over all the fields and emit a new cookie whenever the > + # next field is not a known attribute. > + cookie = None > + for field in fields: > + match = Cookie.kv_pair_re.search(field) > + if match: > + key = match.group(1) > + value = match.group(2) > + # Double quoted value? > + if value[0] == '"': > + if value[-1] == '"': > + value = value[1:-1] > + else: > + raise ValueError("unterminated quote in '%s'" % value) > + kv_pair = True > + else: > + key = field > + value = True # True because bare keys are boolean flags > + kv_pair = False > + > + is_attribute = key.lower() in Cookie.attrs > + if Cookie.debug: print "is_attribute=%s '%s' '%s'" % (is_attribute, key, value) > + Use our logging mechanism, see above. If this stays for some reason, I'll ask you to not put multiple statements on one line, and use `self.debug` instead of `Cookie.debug`. > + # First cookie found, create new cookie object > + if cookie is None and kv_pair and not is_attribute: > + cookie = Cookie(key, value) > + > + # If start of new cookie then flush previous cookie and create > + # a new one (it's a new cookie because it's a key/value pair > + # whose key is not a reserved keyword). > + elif cookie and kv_pair and not is_attribute: > + if Cookie.debug: print "flushing: %s" % (cookie) > + cookies.append(cookie) > + cookie = Cookie(key, value) > + > + # If it's a reserved keyword add that as an attribute to the > + # current cookie being scanned. > + elif cookie and is_attribute: > + cookie.set_attr(key, value) > + # If we've found a non-empty single token that's not a > + # reserved keyword it's an error. An empty token can occur > + # when there are two adjacent semi-colons (i.e. "; ;"). > + # We don't consider empty tokens an error. > + elif key: > + raise ValueError("unknown cookie token '%s'" % key) > + > + # Flush out final cookie > + if cookie: > + cookies.append(cookie) > + > + return cookies > + > + @classmethod > + def get_named_cookie_from_string(cls, cookie_string, cookie_name): > + ''' > + A cookie string may contain multiple cookies, parse the cookie > + string and return the last cookie in the string matching the > + cookie name or None if not found. > + > + This is basically a utility wrapper around the parse() class > + method which iterates over what parse() returns looking for > + the specific cookie. > + > + When cookie_name appears more than once the last instance is > + returned rather than the first because the ordering sequence > + makes the last instance the current value. > + ''' > + > + target_cookie = None > + > + cookies = cls.parse(cookie_string) > + for cookie in cookies: > + if cookie.key == cookie_name: > + target_cookie = cookie > + > + return target_cookie > + > + > + def __init__(self, key, value, domain=None, path=None, max_age=None, expires=None, > + secure=None, httponly=None, timestamp=None): > + self.key = key > + self.value = value > + self.domain = domain > + self.path = path > + self.max_age = max_age > + self.expires = expires > + self.secure = secure > + self.httponly = httponly > + > + self.timestamp = timestamp > + > + @property > + def timestamp(self): > + ''' > + The UTC moment at which cookie was received for purposes of > + computing the expiration given a Max-Age offset. The > + expiration will be timestamp + max_age. The timestamp value > + will aways be a datetime object. > + > + By default the timestamp will be the moment the Cookie object > + is created as this often corresponds to the moment the cookie > + is received (the intent of the Max-Age attribute). But becuase > + it's sometimes desirable to force a specific moment for > + purposes of computing the expiration from the Max-Age the > + Cookie timestamp can be updated. > + > + Setting a value of None causes the timestamp to be set to the > + current UTC time (now). You may also assign with a numeric > + UNIX timestamp (seconds since the epoch UTC) or a formatted time > + sting, in all cases the value will be converted to a datetime > + object. > + ''' > + return self._timestamp > + > + @timestamp.setter > + def timestamp(self, value): > + if value is None: > + self._timestamp = None > + elif isinstance(value, datetime.datetime): > + self._timestamp = value > + elif isinstance(value, (int, long, float)): > + self._timestamp = datetime.datetime.utcfromtimestamp(value) > + elif isinstance(value, basestring): > + self._timestamp = Cookie.parse_datetime(value) > + else: > + raise TypeError('value must be datetime, int, long, float, basestring or None, not %s' % \ > + value.__class__.__name__) > + > + @property > + def expires(self): > + ''' > + The expiration timestamp (in UTC) as a datetime object for the > + cookie, or None if not set. > + > + You may assign a value of None, a datetime object, a numeric > + UNIX timestamp (seconds since the epoch UTC) or formatted time > + string (the latter two will be converted to a datetime object. > + ''' > + return self._expires > + > + @expires.setter > + def expires(self, value): > + if value is None: > + self._expires = None > + elif isinstance(value, datetime.datetime): > + self._expires = value > + elif isinstance(value, (int, long, float)): > + self._expires = datetime.datetime.utcfromtimestamp(value) > + elif isinstance(value, basestring): > + self._expires = Cookie.parse_datetime(value) > + else: > + raise TypeError('value must be datetime, int, long, float, basestring or None, not %s' % \ > + value.__class__.__name__) Are the automatic conversions necessary? I'd rather call an explicit set_expires_from_timestamp than have the attribute silently changed, with semantics depending on the type. This is the wrong kind of ?easy to use?. It should be ?easy to read and understand?, not ?less characters to type? (with magic to determine what you meant). > + > + @property > + def max_age(self): > + ''' > + The lifetime duration of the cookie. Computed as an offset > + from the cookie's timestamp. > + ''' > + return self._max_age > + > + @max_age.setter > + def max_age(self, value): > + if value is None: > + self._max_age = None > + else: > + try: > + self._max_age = int(value) > + except Exception: > + raise ValueError("Max-Age value '%s' not convertable to integer" % value) > + > + def set_attr(self, name, value): > + ''' > + Sets one of the predefined cookie attributes. > + ''' > + attr_name = Cookie.attrs.get(name.lower(), None) > + if attr_name is None: > + raise ValueError("unknown cookie attribute '%s'" % name) > + setattr(self, attr_name, value) Please don't include this in the public interface, there's no need for users to call it. It would be much better to inline the function in the only place that calls it. > + > + def __str__(self): > + result = "%s=%s;" % (self.key, self.value) > + > + if self.domain is not None: > + result += " Domain=%s;" % self.domain > + > + if self.path is not None: > + result += " Path=%s;" % self.path > + > + if self.max_age is not None: > + result += " Max-Age=%s;" % self.max_age > + > + if self.expires is not None: > + result += " Expires=%s;" % Cookie.datetime_to_string(self.expires) > + > + if self.secure: > + result += " Secure;" > + > + if self.httponly: > + result += " HttpOnly;" > + > + return result[:-1] # strip trainling semi-colon Concatenating strings is slow; please consider building a list and then `return '; '.join(result)`. > + > + def get_expiration(self): > + ''' > + Return the effective expiration of the cookie as a datetime > + object or None if no expiration is defined. Expiration may be > + defined either by the "Expires" timestamp attribute or the > + "Max-Age" duration attribute. If both are set "Max-Age" takes > + precedence. If neither is set the cookie has no expiration and > + None will be returned. > + > + "Max-Age" specifies the number of seconds in the future from when the > + cookie is received until it expires. Effectively it means > + adding "Max-Age" seconds to a timestamp to arrive at an > + expiration. By default the timestamp used to mark the arrival > + of the cookie is set to the moment the cookie object is > + created. However sometimes it is desirable to adjust the > + received timestamp to something other than the moment of > + object creation, therefore you can explicitly set the arrival > + timestamp used in the "Max-Age" calculation. > + > + "Expires" specifies an explicit timestamp. > + > + If "Max-Age" is set a datetime object is returned which is the > + sum of the arrival timestamp and "Max-Age". > + > + If "Expires" is set a datetime object is returned matching the > + timestamp specified as the "Expires" value. > + > + If neither is set None is returned. > + ''' > + > + if self.max_age is not None: > + return self.timestamp + datetime.timedelta(seconds=self.max_age) > + > + if self.expires is not None: > + return self.expires > + > + return None > + > + def normalize_expiration(self): > + ''' > + An expiration may be specified either with an explicit > + timestamp in the "Expires" attribute or via an offset > + specified witht the "Max-Age" attribute. The "Max-Age" > + attribute has precedence over "Expires" if both are > + specified. > + > + This method normalizes the expiration of the cookie such that > + only a "Expires" attribute remains after consideration of the > + "Max-Age" attribute. This is useful when storing the cookie > + for future reference. > + ''' > + > + self.expires = self.get_expiration() > + self.max_age = None > + return self.expires > + > + def http_cookie(self): > + ''' > + Return a string with just the key and value (no attributes). > + This is appropriate for including in a HTTP Cookie header. > + ''' > + return '%s=%s;' % (self.key, self.value) > diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py > index 0856c25..c4b5039 100644 > --- a/ipaserver/rpcserver.py > +++ b/ipaserver/rpcserver.py > @@ -384,7 +384,8 @@ class WSGIExecutioner(Executioner): > if session_data is not None: > # Send session cookie back and store session data > # FIXME: the URL path should be retreived from somewhere (but where?), not hardcoded > - session_cookie = session_mgr.generate_cookie('/ipa', session_data['session_id']) > + session_cookie = session_mgr.generate_cookie('/ipa', session_data['session_id'], > + session_data['session_expiration_timestamp']) > headers.append(('Set-Cookie', session_cookie)) > > start_response(status, headers) > @@ -666,7 +667,8 @@ class KerberosSession(object): > release_ipa_ccache(ccache_name) > > # Return success and set session cookie > - session_cookie = session_mgr.generate_cookie('/ipa', session_id) > + session_cookie = session_mgr.generate_cookie('/ipa', session_id, > + session_data['session_expiration_timestamp']) > headers.append(('Set-Cookie', session_cookie)) > > start_response(HTTP_STATUS_SUCCESS, headers) > diff --git a/tests/test_ipapython/test_cookie.py b/tests/test_ipapython/test_cookie.py > new file mode 100644 > index 0000000..4b3c317 > --- /dev/null > +++ b/tests/test_ipapython/test_cookie.py > @@ -0,0 +1,332 @@ > +# Authors: > +# John Dennis > +# > +# Copyright (C) 2012 Red Hat > +# see file 'COPYING' for use and warranty information > +# > +# 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 Foundation, either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see. > + > +import unittest > +import time > +import datetime > +import calendar > +from cookie import Cookie > + > +class TestParse(unittest.TestCase): > + > + def test_parse(self): > + # Empty string > + s = '' > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 0) > + > + # Invalid single token > + s = 'color' > + with self.assertRaises(ValueError): > + cookies = Cookie.parse(s) > + > + # Invalid single token that's keyword > + s = 'HttpOnly' > + with self.assertRaises(ValueError): > + cookies = Cookie.parse(s) > + > + # Invalid key/value pair whose key is a keyword > + s = 'domain=example.com' > + with self.assertRaises(ValueError): > + cookies = Cookie.parse(s) > + > + # 1 cookie with name/value > + s = 'color=blue' > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 1) > + cookie = cookies[0] > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue") > + self.assertEqual(cookie.http_cookie(), "color=blue;") > + > + # 1 cookie with whose value is quoted > + # Use "get by name" utility to extract specific cookie > + s = 'color="blue"' > + cookie = Cookie.get_named_cookie_from_string(s, 'color') > + self.assertIsNotNone(cookie) > + self.assertIsNotNone(cookie, Cookie) > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue") > + self.assertEqual(cookie.http_cookie(), "color=blue;") > + > + # 1 cookie with name/value and domain, path attributes. > + # Change up the whitespace a bit. > + s = 'color =blue; domain= example.com ; path = /toplevel ' > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 1) > + cookie = cookies[0] > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, 'example.com') > + self.assertEqual(cookie.path, '/toplevel') > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue; Domain=example.com; Path=/toplevel") > + self.assertEqual(cookie.http_cookie(), "color=blue;") > + > + # 2 cookies, various attributes > + s = 'color=blue; Max-Age=3600; temperature=hot; HttpOnly' > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 2) > + cookie = cookies[0] > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, 3600) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue; Max-Age=3600") > + self.assertEqual(cookie.http_cookie(), "color=blue;") > + cookie = cookies[1] > + self.assertEqual(cookie.key, 'temperature') > + self.assertEqual(cookie.value, 'hot') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, True) > + self.assertEqual(str(cookie), "temperature=hot; HttpOnly") > + self.assertEqual(cookie.http_cookie(), "temperature=hot;") > + > +class TestExpires(unittest.TestCase): > + > + def setUp(self): > + # Force microseconds to zero because cookie timestamps only have second resolution > + self.now = datetime.datetime.utcnow().replace(microsecond=0) > + self.now_timestamp = calendar.timegm(self.now.utctimetuple()) > + self.now_string = datetime.datetime.strftime(self.now, '%a, %d %b %Y %H:%M:%S GMT') > + > + self.max_age = 3600 # 1 hour > + self.age_expiration = self.now + datetime.timedelta(seconds=self.max_age) > + self.age_string = datetime.datetime.strftime(self.age_expiration, '%a, %d %b %Y %H:%M:%S GMT') > + > + self.expires = self.now + datetime.timedelta(days=1) # 1 day > + self.expires_timestamp = calendar.timegm(self.expires.utctimetuple()) > + self.expires_string = datetime.datetime.strftime(self.expires, '%a, %d %b %Y %H:%M:%S GMT') > + > + def test_expires(self): > + # 1 cookie with name/value and no Max-Age and no Expires > + s = 'color=blue;' > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 1) > + cookie = cookies[0] > + # Force timestamp to known value > + cookie.timestamp = self.now > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue") > + self.assertEqual(cookie.get_expiration(), None) > + # Normalize > + self.assertEqual(cookie.normalize_expiration(), None) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(str(cookie), "color=blue") > + > + # 1 cookie with name/value and Max-Age > + s = 'color=blue; max-age=%d' % (self.max_age) > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 1) > + cookie = cookies[0] > + # Force timestamp to known value > + cookie.timestamp = self.now > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, self.max_age) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue; Max-Age=%d" % (self.max_age)) > + self.assertEqual(cookie.get_expiration(), self.age_expiration) > + # Normalize > + self.assertEqual(cookie.normalize_expiration(), self.age_expiration) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, self.age_expiration) > + self.assertEqual(str(cookie), "color=blue; Expires=%s" % (self.age_string)) > + > + > + # 1 cookie with name/value and Expires > + s = 'color=blue; Expires=%s' % (self.expires_string) > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 1) > + cookie = cookies[0] > + # Force timestamp to known value > + cookie.timestamp = self.now > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, self.expires) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue; Expires=%s" % (self.expires_string)) > + self.assertEqual(cookie.get_expiration(), self.expires) > + # Normalize > + self.assertEqual(cookie.normalize_expiration(), self.expires) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, self.expires) > + self.assertEqual(str(cookie), "color=blue; Expires=%s" % (self.expires_string)) > + > + # 1 cookie with name/value witht both Max-Age and Expires, Max-Age takes precedence > + s = 'color=blue; Expires=%s; max-age=%d' % (self.expires_string, self.max_age) > + cookies = Cookie.parse(s) > + self.assertEqual(len(cookies), 1) > + cookie = cookies[0] > + # Force timestamp to known value > + cookie.timestamp = self.now > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, self.max_age) > + self.assertEqual(cookie.expires, self.expires) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue; Max-Age=%d; Expires=%s" % (self.max_age, self.expires_string)) > + self.assertEqual(cookie.get_expiration(), self.age_expiration) > + # Normalize > + self.assertEqual(cookie.normalize_expiration(), self.age_expiration) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, self.age_expiration) > + self.assertEqual(str(cookie), "color=blue; Expires=%s" % (self.age_string)) > + > + # Verify different types can be assigned to the timestamp and > + # expires attribute. > + > + cookie = Cookie('color', 'blue') > + cookie.timestamp = self.now > + self.assertEqual(cookie.timestamp, self.now) > + cookie.timestamp = self.now_timestamp > + self.assertEqual(cookie.timestamp, self.now) > + cookie.timestamp = self.now_string > + self.assertEqual(cookie.timestamp, self.now) > + > + self.assertEqual(cookie.expires, None) > + > + cookie.expires = self.expires > + self.assertEqual(cookie.expires, self.expires) > + cookie.expires = self.expires_timestamp > + self.assertEqual(cookie.expires, self.expires) > + cookie.expires = self.expires_string > + self.assertEqual(cookie.expires, self.expires) > + > +class TestInvalidAttributes(unittest.TestCase): > + def test_invalid(self): > + # Invalid Max-Age > + s = 'color=blue; Max-Age=over-the-hill' > + with self.assertRaises(ValueError): > + cookies = Cookie.parse(s) > + > + cookie = Cookie('color', 'blue') > + with self.assertRaises(ValueError): > + cookie.max_age = 'over-the-hill' > + > + # Invalid Expires > + s = 'color=blue; Expires=Sun, 06 Xxx 1994 08:49:37 GMT' > + with self.assertRaises(ValueError): > + cookies = Cookie.parse(s) > + > + cookie = Cookie('color', 'blue') > + with self.assertRaises(ValueError): > + cookie.expires = 'Sun, 06 Xxx 1994 08:49:37 GMT' > + > + > +class TestAttributes(unittest.TestCase): > + def test_attributes(self): > + cookie = Cookie('color', 'blue') > + self.assertEqual(cookie.key, 'color') > + self.assertEqual(cookie.value, 'blue') > + self.assertEqual(cookie.domain, None) > + self.assertEqual(cookie.path, None) > + self.assertEqual(cookie.max_age, None) > + self.assertEqual(cookie.expires, None) > + self.assertEqual(cookie.secure, None) > + self.assertEqual(cookie.httponly, None) > + > + cookie.domain = 'example.com' > + self.assertEqual(cookie.domain, 'example.com') > + cookie.domain = None > + self.assertEqual(cookie.domain, None) > + > + cookie.path = '/toplevel' > + self.assertEqual(cookie.path, '/toplevel') > + cookie.path = None > + self.assertEqual(cookie.path, None) > + > + cookie.max_age = 400 > + self.assertEqual(cookie.max_age, 400) > + cookie.max_age = None > + self.assertEqual(cookie.max_age, None) > + > + cookie.expires = 'Sun, 06 Nov 1994 08:49:37 GMT' > + self.assertEqual(cookie.expires, datetime.datetime(1994, 11, 6, 8, 49, 37)) > + cookie.expires = None > + self.assertEqual(cookie.expires, None) > + > + cookie.secure = True > + self.assertEqual(cookie.secure, True) > + self.assertEqual(str(cookie), "color=blue; Secure") > + cookie.secure = False > + self.assertEqual(cookie.secure, False) > + self.assertEqual(str(cookie), "color=blue") > + cookie.secure = None > + self.assertEqual(cookie.secure, None) > + self.assertEqual(str(cookie), "color=blue") > + > + cookie.httponly = True > + self.assertEqual(cookie.httponly, True) > + self.assertEqual(str(cookie), "color=blue; HttpOnly") > + cookie.httponly = False > + self.assertEqual(cookie.httponly, False) > + self.assertEqual(str(cookie), "color=blue") > + cookie.httponly = None > + self.assertEqual(cookie.httponly, None) > + self.assertEqual(str(cookie), "color=blue") > + > + > +#------------------------------------------------------------------------------- > +if __name__ == '__main__': > + unittest.main() > -- 1.7.11.7 Also, watch your line length, especially in new code. -- Petr? From mkosek at redhat.com Tue Nov 13 08:50:58 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Nov 2012 09:50:58 +0100 Subject: [Freeipa-devel] [PATCH] Add Beta versioning In-Reply-To: <509D8CD1.6090401@redhat.com> References: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> <509CFDE9.70002@redhat.com> <509D6EA5.8040403@redhat.com> <1352501565.10327.385.camel@willson.li.ssimo.org> <509D8CD1.6090401@redhat.com> Message-ID: <50A209F2.8020206@redhat.com> On 11/10/2012 12:08 AM, Dmitri Pal wrote: > On 11/09/2012 05:52 PM, Simo Sorce wrote: >> On Fri, 2012-11-09 at 15:59 -0500, Dmitri Pal wrote: >>> On 11/09/2012 07:58 AM, Petr Vobornik wrote: >>>> On 11/09/2012 01:43 PM, Lynn Root wrote: >>>>> The VERSION file and Makefile now handles 'beta' release parameters >>>>> when making s/rpms. >>>>> >>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2893 >>>>> >>>>> Lynn Root >>>>> Associate Software Engineer >>>>> Red Hat >>>> Thanks for the patch. >>>> >>>> In a next patch, I'd suggest to follow patch-naming conventions >>>> https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the >>>> patch number into a mail subject, it helps to keeping track of patches. >>>> >>> OK, finally. It is a good time to ask. >>> >>> Several years ago when we adopted this format I was wondering what is >>> the exact sequence of operations one should do to make the resulting >>> patch follow the format. >>> I never figured it out so I never adopted the format for the patches I >>> provide for ding-libs from time to time. >>> >>> So in the title of the commit message I put (for example): >>> [INI] Remove code that allows dup sections >>> >>> the I do git format-patch with arguments >>> this translates into a patch with name >>> 0001-INI-Remove-code-that-allows-dup-sections.patch >>> >>> So am I supposed to the manually rename the patch to follow the format >>> or have a script to do that or there is some other way that I do not >>> know about that would allow me to provide patches following the format >>> above right out of the git format-patch so that I do not need to do the >>> renaming? >> This patch format rule is followed only on freeipa-devel for Freeipa >> patches. >> >> Some people have developed scripts to do the renaming automatically. >> >> ding libs stuff is tracked on sssd-devel which does not use this patch >> format rule, we enver felt it necessary in sssd development. >> >> Simo. >> > I understand. It was more a conceptual question. It looks like the > answer "there are scripts to do renaming that each developer has". > Thanks. This is all I was looking for. > Right. I understand that it may be difficult to follow the patch naming rule for new people in the project. But I personally like both numbering and naming conventions as it helps me with locating patches when reviewing and with referencing patch numbers in IRC conversations. The script is the most straightforward approach to choose For example when I am submitting a patch, all I need to do is to run a script which will extract the patch from git, name and number it correctly and opens me a Compose Email window in my MUA with patch already attached and description taken from the patch description. It can even upload the patch to Trac Ticket and switch "patch sent for review" to 1. If people are interested in the script, I can upload it to some github repo and we can link it then from our freeipa.org Contribute page. Martin From arta.moeini at gmail.com Tue Nov 13 09:12:15 2012 From: arta.moeini at gmail.com (mohammad moeini) Date: Tue, 13 Nov 2012 12:42:15 +0330 Subject: [Freeipa-devel] Freeipa-devel Digest, Vol 66, Issue 41 In-Reply-To: References: Message-ID: Dear guys my Problem solved about sudoers config and i'm sorry about writer documention of ipa this section binddn uid=sudo,cn=sysaccounts,cn=etc,dc=nise,dc=ir bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me *in document write this section must configure in nsld.conf* *but at this config file it's not work but when i put this in * /etc/sudo.ldap sudo work please change your document ,,, many peopel same me mybe working 3 week at this problem and not found any solution for this document it's biggest bug in ipa regards moeini On Mon, Nov 12, 2012 at 5:49 PM, wrote: > Send Freeipa-devel mailing list submissions to > freeipa-devel at redhat.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.redhat.com/mailman/listinfo/freeipa-devel > or, via email, send a message with subject or body 'help' to > freeipa-devel-request at redhat.com > > You can reach the person managing the list at > freeipa-devel-owner at redhat.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeipa-devel digest..." > > > Today's Topics: > > 1. Re: Freeipa-devel Digest, Vol 66, Issue 34 (Dmitri Pal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 12 Nov 2012 09:19:32 -0500 > From: Dmitri Pal > To: freeipa-devel at redhat.com > Subject: Re: [Freeipa-devel] Freeipa-devel Digest, Vol 66, Issue 34 > Message-ID: <50A10574.8050303 at redhat.com> > Content-Type: text/plain; charset="iso-8859-1" > > On 11/10/2012 09:14 AM, mohammad moeini wrote: > > Dear Guyes > > > > i'm AAA Server administrator , I use freeipa for AAA server > > i Have a Centos server and 50 client debian > > i use the ipa v 3 and now have problem with join ipa clients becuse > > not exisixt upper 2.1.4 package in debian distru > > when i want compile ipa client on the folder ipa-client in cource get > > the error krb5.h not exist , please help me anout dependency on the > > freeipa v 3 o r say to me how can i config ipa v 3 for supporting ipa > > client v 2.1.4 > > > > Another my question is about sudoers i config sudoers seem of the all > > domcumention free ipa and testing many soulution from Ldap or freeipa > > or another way seem nscd.conf or sssd.conf or .... but not working and > > just say to me your user is not is sudoers ,,, i don't know i must > > doing any config in ldap schema or must create suoers group > > please help me ,,, i run freeipa for first time in middle ease and i > > want grow this at this point of world > > > > Have you seen couple threads on freeipa-users about SUDO this and last > month? Just search the archives. > They have a lot of hints on how to configure sudo and make sure it works. > SUDO changed the name of its config file recently and that have be a > source of confusion is some cases. > Anyways please read those threads and try to follow the instructions > there (posts from JR are very helpful). > If you still have problems please let us know more details. > > > > Regards Moeini > > > > > > On Fri, Nov 9, 2012 at 6:40 PM, > > wrote: > > > > Send Freeipa-devel mailing list submissions to > > freeipa-devel at redhat.com > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > or, via email, send a message with subject or body 'help' to > > freeipa-devel-request at redhat.com > > > > > > You can reach the person managing the list at > > freeipa-devel-owner at redhat.com > > > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Freeipa-devel digest..." > > > > > > Today's Topics: > > > > 1. [PATCH] Add Beta versioning (Lynn Root) > > 2. Re: [PATCH] Add Beta versioning (Petr Vobornik) > > 3. Re: [PATCH] Add Beta versioning (Lynn Root) > > 4. Re: [PATCH] Add Beta versioning (Martin Kosek) > > 5. Re: [PATCH] 332 Do not require resolvable nameserver in DNS > > install (Alexander Bokovoy) > > 6. Re: [PATCH] 332 Do not require resolvable nameserver in DNS > > install (Martin Kosek) > > 7. Re: [PATCH] Switch %r specifiers to %s in Public errors > > (Jan Cholasta) > > 8. Re: [PATCH] 330 Disable global forwarding per-zone > > (Rob Crittenden) > > 9. Re: [PATCH] 330 Disable global forwarding per-zone (Martin > > Kosek) > > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Fri, 9 Nov 2012 07:43:31 -0500 (EST) > > From: Lynn Root > > > To: freeipa-devel at redhat.com > > Subject: [Freeipa-devel] [PATCH] Add Beta versioning > > Message-ID: > > <943042161.7794393.1352465011767.JavaMail.root at redhat.com > > > > > Content-Type: text/plain; charset="utf-8" > > > > The VERSION file and Makefile now handles 'beta' release > > parameters when making s/rpms. > > > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: Add-Beta-versioning.patch > > Type: text/x-patch > > Size: 2522 bytes > > Desc: not available > > URL: > > < > https://www.redhat.com/archives/freeipa-devel/attachments/20121109/17627fbd/attachment.bin > > > > > > ------------------------------ > > > > Message: 2 > > Date: Fri, 09 Nov 2012 13:58:17 +0100 > > From: Petr Vobornik >> > > To: Lynn Root > > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > Message-ID: <509CFDE9.70002 at redhat.com > > > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 11/09/2012 01:43 PM, Lynn Root wrote: > > > The VERSION file and Makefile now handles 'beta' release > > parameters when making s/rpms. > > > > > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > > > > > Lynn Root > > > Associate Software Engineer > > > Red Hat > > > > Thanks for the patch. > > > > In a next patch, I'd suggest to follow patch-naming conventions > > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > > patch number into a mail subject, it helps to keeping track of > > patches. > > > > -- > > Petr Vobornik > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Fri, 9 Nov 2012 08:04:43 -0500 (EST) > > From: Lynn Root > > > To: Petr Vobornik > > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > Message-ID: > > <1940773203.7804090.1352466283311.JavaMail.root at redhat.com > > > > > Content-Type: text/plain; charset=utf-8 > > > > Ah thank you - was going by the "Submit Changes" portion in > > http://freeipa.org/page/Contribute#Development_Process, which has > > less information (but clearly did not notice the Patch Format link > > right above). > > > > Lynn Root > > Associate Software Engineer > > Red Hat > > > > ----- Original Message ----- > > From: "Petr Vobornik" > > > > To: "Lynn Root" > > > Cc: freeipa-devel at redhat.com > > Sent: Friday, November 9, 2012 1:58:17 PM > > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > > > On 11/09/2012 01:43 PM, Lynn Root wrote: > > > The VERSION file and Makefile now handles 'beta' release > > parameters when making s/rpms. > > > > > > Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > > > > > Lynn Root > > > Associate Software Engineer > > > Red Hat > > > > Thanks for the patch. > > > > In a next patch, I'd suggest to follow patch-naming conventions > > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the > > patch number into a mail subject, it helps to keeping track of > > patches. > > > > -- > > Petr Vobornik > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Fri, 09 Nov 2012 14:07:05 +0100 > > From: Martin Kosek > > > To: Lynn Root > > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > Message-ID: <509CFFF9.2070906 at redhat.com > > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Actually, there is a link in the Contribute wiki page for the > > Patch format page: > > > > ... > > Patch Format - Guidance about the patch format > > ... > > > > We may want to make it more visible... > > > > Martin > > > > On 11/09/2012 02:04 PM, Lynn Root wrote: > > > Ah thank you - was going by the "Submit Changes" portion in > > http://freeipa.org/page/Contribute#Development_Process, which has > > less information (but clearly did not notice the Patch Format link > > right above). > > > > > > Lynn Root > > > Associate Software Engineer > > > Red Hat > > > > > > ----- Original Message ----- > > > From: "Petr Vobornik" > > > > > To: "Lynn Root" > > > > Cc: freeipa-devel at redhat.com > > > Sent: Friday, November 9, 2012 1:58:17 PM > > > Subject: Re: [Freeipa-devel] [PATCH] Add Beta versioning > > > > > > On 11/09/2012 01:43 PM, Lynn Root wrote: > > >> The VERSION file and Makefile now handles 'beta' release > > parameters when making s/rpms. > > >> > > >> Ticket: https://fedorahosted.org/freeipa/ticket/2893 > > >> > > >> Lynn Root > > >> Associate Software Engineer > > >> Red Hat > > > > > > Thanks for the patch. > > > > > > In a next patch, I'd suggest to follow patch-naming conventions > > > https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include > the > > > patch number into a mail subject, it helps to keeping track of > > patches. > > > > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Fri, 9 Nov 2012 15:15:09 +0200 > > From: Alexander Bokovoy > > > > To: Martin Kosek > > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] 332 Do not require resolvable > > nameserver in DNS install > > Message-ID: <20121109131509.GB14850 at redhat.com > > > > > Content-Type: text/plain; charset=us-ascii; format=flowed > > > > On Fri, 09 Nov 2012, Martin Kosek wrote: > > >As named.conf and bind-dyndb-plugin is not set up yet during DNS > > >configuration phase, IPA hostname (i.e. the nameserver) should not > > >be required be to resolvable in this phase. > > > > > >https://fedorahosted.org/freeipa/ticket/3248 > > ACK. > > > > -- > > / Alexander Bokovoy > > > > > > > > ------------------------------ > > > > Message: 6 > > Date: Fri, 09 Nov 2012 14:26:18 +0100 > > From: Martin Kosek > > > To: Alexander Bokovoy > > > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] 332 Do not require resolvable > > nameserver in DNS install > > Message-ID: <509D047A.5030309 at redhat.com > > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 11/09/2012 02:15 PM, Alexander Bokovoy wrote: > > > On Fri, 09 Nov 2012, Martin Kosek wrote: > > >> As named.conf and bind-dyndb-plugin is not set up yet during DNS > > >> configuration phase, IPA hostname (i.e. the nameserver) should not > > >> be required be to resolvable in this phase. > > >> > > >> https://fedorahosted.org/freeipa/ticket/3248 > > > ACK. > > > > > > > Pushed to master, ipa-3-0. > > > > Martin > > > > > > > > ------------------------------ > > > > Message: 7 > > Date: Fri, 09 Nov 2012 15:25:20 +0100 > > From: Jan Cholasta >> > > To: Lynn Root > > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s in > > Public errors > > Message-ID: <509D1250.5060404 at redhat.com > > > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 8.11.2012 17:22, Lynn Root wrote: > > > Hmm I hope I understand well enough this time around. > > > > > > However, when I run the tests, there's this one error message I > > come across from `test_user[97]: user_add: Create u'tuser2'` - it > > throws `DatabaseError: Type or value exists`. I'm a bit lost on > > how to track this down. > > > > > > Once again - thanks for your help! > > > > > > Lynn Root > > > Associate Software Engineer > > > Red Hat > > > > > > ----- Original Message ----- > > > From: "Martin Kosek" >> > > > To: "Jan Cholasta" > > > > > Cc: "Lynn Root" >, > > freeipa-devel at redhat.com > > > Sent: Thursday, November 8, 2012 8:46:42 AM > > > Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to %s > > in Public errors > > > > > > On 11/07/2012 06:46 PM, Jan Cholasta wrote: > > >> On 7.11.2012 16:08, Lynn Root wrote: > > >>> Third time is a charm? > > >>> > > >>> Lynn Root > > >>> Associate Software Engineer > > >>> Red Hat > > >>> > > >>> ----- Original Message ----- > > >>> From: "Jan Cholasta" > > > > >>> To: "Lynn Root" > > > >>> Cc: freeipa-devel at redhat.com > > >>> Sent: Monday, November 5, 2012 10:25:32 AM > > >>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to > > %s in Public errors > > >>> > > >>> On 5.11.2012 09:43, Lynn Root wrote: > > >>>> Here's try #2! Adjusted patch attached. Let me know if > > there's anything > > >>>> else I've missed. > > >>>> > > >>>> Switched %r specifiers to '%s' in Public errors, and adjusted > > tests to > > >>>> expect no preceding 'u'. > > >>>> > > >>>> Tickets: https://fedorahosted.org/freeipa/ticket/3121 & > > >>>> https://fedorahosted.org/freeipa/ticket/2588 > > >>>> > > >>>> Lynn Root > > >>>> Associate Software Engineer > > >>>> Red Hat > > >>>> > > >>>> ----- Original Message ----- > > >>>> From: "Martin Kosek" > > > > >>>> To: "Jan Cholasta" > > > > >>>> Cc: "Lynn Root" >, > > freeipa-devel at redhat.com > > >>>> Sent: Tuesday, October 30, 2012 9:08:33 AM > > >>>> Subject: Re: [Freeipa-devel] [PATCH] Switch %r specifiers to > > %s in Public > > >>>> errors > > >>>> > > >>>> On 10/30/2012 09:04 AM, Jan Cholasta wrote: > > >>>>> Hi, > > >>>>> > > >>>>> On 29.10.2012 19:54, Lynn Root wrote: > > >>>>>> Hi all! > > >>>>>> > > >>>>>> This switch drops the preceding 'u' from strings in public > > error messages. > > >>>>>> > > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/3121 > > >>>>>> > > >>>>>> This patch also addresses the unfriendly 'u' from > > re-raising errors from the > > >>>>>> external call to netaddr.IPAddress by passing a bytestring > > to the function. > > >>>>>> > > >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2588 > > >>>>>> > > >>>>>> > > >>>>>> My first patch (and freeipa dev list email) ever! Let me > > know where there's > > >>>>>> room to improve. > > >>>>>> > > >>>>>> Lynn Root > > >>>>>> Associate Software Engineer > > >>>>>> Red Hat > > >>>>>> > > >>>>> > > >>>>> I think it would be nice if you kept the quotes around the > > values, as that is > > >>>>> probably the reason "%r" was used in the first place - i.e. > > use "'%s'" instead > > >>>>> of plain "%s". > > >>>> > > >>>> +1 > > >>>> > > >>>> With current patch, I assume that a lot of unit tests will > > fail as they check > > >>>> exact error message wording. I'd recommend running the whole > > test suite with > > >>>> your second patch revision. There is a short walkthrough how > > to set it up: > > >>>> > > >>>> http://freeipa.org/page/Testing > > >>>> > > >>>> Martin > > >>>> > > >>> > > >>> You missed a few: > > >>> > > >>> $ git grep -En '%(\(.*?\))?r' > > >>> > > >>> Honza > > >>> > > >> > > >> I think you have gone too far this time :-) It is not necessary > > (or wise) to > > >> get rid of %r *everywhere* in the code. > > > > > > Thanks Honza for pointing that out. It seems I missed that in > > yesterday's > > > review. Now, when I look at it, it indeed is not right. > > > > > >> > > >> A few rules to keep in mind: > > >> > > >> * If it is not an error message, do not touch it (log > > messages are not error > > >> messages BTW). > > >> > > >> * If it is an error message for an exception that does not > > inherit from > > >> errors.PublicError, do not touch it (there might be a few > > exceptions, though). > > > > > > Right. But for example, your netaddr str conversions should be > > fine since the > > > netaddr error is propagated up to the ValidationError. > > > > > > Martin > > > > > >> > > >> * Use '%s' (%s with ticks) only for arguments whose value > > can be only str or > > >> unicode. > > >> > > >> Honza > > >> > > > > > > > This is better, thanks. > > > > In OverlapError.format, remove the ticks around %s, as we expect a > > list > > here (I think we could make it look prettier, similar to what > > Martin did > > in > > < > https://fedorahosted.org/freeipa/changeset/988ea368272822f2153563ad34554240e3377d60/ > >, > > but I'm not sure if we want to do it in this ticket/patch). > > > > I'm not sure what to do about the ValidationError at > > ipalib/parameters.py:882 and ipalib/parameters.py:1171. I think it > > should be "TypeError(TYPE_ERROR % (self.name , > > self.type, value, > > type(value)))" instead, as by the time parameters are validated > > they are > > the right type. > > > > Also there is one %r you missed in ipalib/parameters.py:1554. > > > > Honza > > > > -- > > Jan Cholasta > > > > > > > > ------------------------------ > > > > Message: 8 > > Date: Fri, 09 Nov 2012 09:36:20 -0500 > > From: Rob Crittenden > > > > To: Martin Kosek > > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] 330 Disable global forwarding > > per-zone > > Message-ID: <509D14E4.70209 at redhat.com > > > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Martin Kosek wrote: > > > On 11/02/2012 11:08 AM, Martin Kosek wrote: > > >> On 11/02/2012 10:51 AM, Jan Cholasta wrote: > > >>> Hi, > > >>> > > >>> On 2.11.2012 09:12, Martin Kosek wrote: > > >>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: > > >>>>> 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 > > >>>>> > > >>>> > > >>>> Fixed both. After a short discussion with Petr Spacek I also > > added a > > >>>> possibility to set global dnsconfig to NONE. > > >>>> > > >>>> On a different note, I discovered that global forwarders in > > >>>> bind-dyndb-ldap/bind are actually broken with referred > > bind-dyndb-ldap/bind > > >>>> version. Thus, we may want to bump bind-dyndb-ldap version in > > spec when this is > > >>>> resolved. (This should not affect diff in dns.py in any way). > > >>>> > > >>>> Martin > > >>>> > > >>> > > >>> This might be a stupid question, but why is "NONE" in upper > > case and the rest > > >>> of the values in lower case? > > >>> > > >>> Honza > > >>> > > >> > > >> This really doesn't matter function-wise, as bind-dydnb-ldap > > does the > > >> comparison in case insensitive way. My original intention was > > to be consistent > > >> with other NONE values we use across IPA and to distinguish the > > value from > > >> valid BIND values. > > >> > > >> But you are right that within dns plugin it makes more sense to > > have it all > > >> lowercase. > > >> > > >> Updated patch attached. > > >> > > >> Martin > > >> > > > > > > bind-dyndb-ldap with fixed forwarding has been released. Sending > > an updated > > > patch for both master and ipa-3-0 branches with its version in > > our spec file. > > > > > > Martin > > > > > > > ACK x2 > > > > > > > > ------------------------------ > > > > Message: 9 > > Date: Fri, 09 Nov 2012 15:40:06 +0100 > > From: Martin Kosek > > > To: Rob Crittenden >> > > Cc: freeipa-devel at redhat.com > > Subject: Re: [Freeipa-devel] [PATCH] 330 Disable global forwarding > > per-zone > > Message-ID: <509D15C6.7090806 at redhat.com > > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On 11/09/2012 03:36 PM, Rob Crittenden wrote: > > > Martin Kosek wrote: > > >> On 11/02/2012 11:08 AM, Martin Kosek wrote: > > >>> On 11/02/2012 10:51 AM, Jan Cholasta wrote: > > >>>> Hi, > > >>>> > > >>>> On 2.11.2012 09:12, Martin Kosek wrote: > > >>>>> On 11/01/2012 09:01 PM, Rob Crittenden wrote: > > >>>>>> 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 > > >>>>>> > > >>>>> > > >>>>> Fixed both. After a short discussion with Petr Spacek I also > > added a > > >>>>> possibility to set global dnsconfig to NONE. > > >>>>> > > >>>>> On a different note, I discovered that global forwarders in > > >>>>> bind-dyndb-ldap/bind are actually broken with referred > > bind-dyndb-ldap/bind > > >>>>> version. Thus, we may want to bump bind-dyndb-ldap version > > in spec when > > >>>>> this is > > >>>>> resolved. (This should not affect diff in dns.py in any way). > > >>>>> > > >>>>> Martin > > >>>>> > > >>>> > > >>>> This might be a stupid question, but why is "NONE" in upper > > case and the rest > > >>>> of the values in lower case? > > >>>> > > >>>> Honza > > >>>> > > >>> > > >>> This really doesn't matter function-wise, as bind-dydnb-ldap > > does the > > >>> comparison in case insensitive way. My original intention was > > to be consistent > > >>> with other NONE values we use across IPA and to distinguish > > the value from > > >>> valid BIND values. > > >>> > > >>> But you are right that within dns plugin it makes more sense > > to have it all > > >>> lowercase. > > >>> > > >>> Updated patch attached. > > >>> > > >>> Martin > > >>> > > >> > > >> bind-dyndb-ldap with fixed forwarding has been released. > > Sending an updated > > >> patch for both master and ipa-3-0 branches with its version in > > our spec file. > > >> > > >> Martin > > >> > > > > > > ACK x2 > > > > Pushed to master, ipa-3-0. > > > > Martin > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Freeipa-devel mailing list > > Freeipa-devel at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-devel > > > > End of Freeipa-devel Digest, Vol 66, Issue 34 > > ********************************************* > > > > > > > > > > _______________________________________________ > > 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: < > https://www.redhat.com/archives/freeipa-devel/attachments/20121112/78f25fec/attachment.html > > > > ------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > End of Freeipa-devel Digest, Vol 66, Issue 41 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Nov 13 10:06:44 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 13 Nov 2012 11:06:44 +0100 Subject: [Freeipa-devel] [PATCH] client: include the directory with domain-realm mappings in krb5.conf In-Reply-To: <50A126ED.9090000@redhat.com> References: <20121008161726.GF685@hendrix.brq.redhat.com> <50731B03.2080604@redhat.com> <50856309.2050105@redhat.com> <1350929640.30610.167.camel@willson.li.ssimo.org> <20121031100010.GA13995@hendrix.brq.redhat.com> <5091181C.5060807@redhat.com> <20121106235321.GC2813@hendrix.redhat.com> <509A8A4E.2050807@redhat.com> <20121109165843.GV31678@hendrix.brq.redhat.com> <50A126ED.9090000@redhat.com> Message-ID: <20121113100644.GB8495@hendrix.brq.redhat.com> On Mon, Nov 12, 2012 at 05:42:21PM +0100, Jan Cholasta wrote: > On 9.11.2012 17:58, Jakub Hrozek wrote: > >On Wed, Nov 07, 2012 at 05:20:30PM +0100, Martin Kosek wrote: > >>On 11/07/2012 12:53 AM, Jakub Hrozek wrote: > >>>On Wed, Oct 31, 2012 at 01:22:52PM +0100, Martin Kosek wrote: > >>>>On 10/31/2012 11:00 AM, Jakub Hrozek wrote: > >>>>>On Mon, Oct 22, 2012 at 02:14:00PM -0400, Simo Sorce wrote: > >>>>>>On Mon, 2012-10-22 at 17:15 +0200, Martin Kosek wrote: > >>>>>>>On 10/08/2012 08:27 PM, Rob Crittenden wrote: > >>>>>>>>Jakub Hrozek wrote: > >>>>>>>>>On Fri, Aug 17, 2012 at 12:20:27PM -0400, Simo Sorce wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>----- Original Message ----- > >>>>>>>>>>>Hi, > >>>>>>>>>>> > >>>>>>>>>>>the attached patches add the directory the SSSD writes domain-realm > >>>>>>>>>>>mappings as includedir to krb5.conf when installing the client. > >>>>>>>>>>> > >>>>>>>>>>>[PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for > >>>>>>>>>>>options > >>>>>>>>>>>ipachangeconf only allows one delimeter between keys and values. This > >>>>>>>>>>>patch adds the possibility of also specifying "delim" in the option > >>>>>>>>>>>dictionary to override the default delimeter. > >>>>>>>>>>> > >>>>>>>>>>>On a slightly-unrelated note, we really should think about adopting > >>>>>>>>>>>Augeas. Changing configuration with home-grown scripts is getting > >>>>>>>>>>>tricky. > >>>>>>>>>>> > >>>>>>>>>>>[PATCH 2/3] Specify includedir in krb5.conf on new installs > >>>>>>>>>>>This patch utilizes the new functionality from the previous patch to > >>>>>>>>>>>add > >>>>>>>>>>>the includedir on top of the krb5.conf file > >>>>>>>>>>> > >>>>>>>>>>>[PATCH 3/3] Add the includedir to krb5.conf on upgrades > >>>>>>>>>>>This patch is completely untested and I'm only posting it to get > >>>>>>>>>>>opinions. At first I was going to use an upgrade script in %post but > >>>>>>>>>>>then I thought it would be overengineering when all we want to do is > >>>>>>>>>>>prepend one line.. Would a simple munging like this be acceptable or > >>>>>>>>>>>shall I write a full script? > >>>>>>>>>> > >>>>>>>>>>NACK, using a scriptlet is fine, but not the way you did, as it has a huge > >>>>>>>>>>race condition where krb5.conf exists and has only one line in it (the > >>>>>>>>>>include line). > >>>>>>>>>> > >>>>>>>>>>You should first create the new file: echo "include ..." > /etc/krb.conf.ipanew > >>>>>>>>>>Then cat the contents of the existing file in i:t cat /etc/krb.conf >> > >>>>>>>>>>/etc/krb.conf.ipanew > >>>>>>>>>>And finally atomically rename it: mv /etc/krb.conf.ipanew /etc/krb.conf > >>>>>>>>>> > >>>>>>>>>>This method is also safe wrt something killing the yum process ... > >>>>>>>>>> > >>>>>>>>>>Simo. > >>>>>>>>> > >>>>>>>>>I'm attaching a new revision of the patches not even two months after > >>>>>>>>>the original nack. > >>>>>>>>> > >>>>>>>>>I also think it might be nice to have a more general way of upgrading > >>>>>>>>>the client config so I filed > >>>>>>>>>https://fedorahosted.org/freeipa/ticket/3149 > >>>>>>>> > >>>>>>>>I don't think grepping for a string is an effective way to determine if the > >>>>>>>>client has been configured. Someone could have removed that line. > >>>>>>>> > >>>>>>>>I'd prefer using /var/lib/ipa-client/sysrestore/sysrestore.index. If it exists > >>>>>>>>and has more than 2 lines in it ([files] + one other file) then it is safe to > >>>>>>>>say the client is configured, or at least partially configured. > >>>>>>>> > >>>>>>>>rob > >>>>>>>> > >>>>>>> > >>>>>>>I just found one more issue. What if ipa-client-install is run with --no-sssd > >>>>>>>option? In that case I assume we should not include the SSSD's krb5.include.d, > >>>>>>>right? The same would also appy for upgrades, we would need to check if client > >>>>>>>was actually configured with SSSD before mangling their krb5.conf. > >>>>>> > >>>>>>Yeah that's right, we should have all sssd related changes under a > >>>>>>conditional that is true only when sssd is enabled. > >>>>>> > >>>>>>Simo. > >>>>> > >>>>>OK, new patches are attached. In new installs, the includedir is only > >>>>>added when options.sssd is true. During upgrades, I checked for > >>>>>sssd.conf's existence, I'm not sure if there's any other way to check if > >>>>>the client was configured with sssd? > >>>> > >>>>Hello Jakub, thanks for these patches. I think that checking if /etc/sssd.conf > >>>>exists as actually not so bad way to test if it was configured. Anyway, I did > >>>>few tests on server and client but I still see few issues: > >>>> > >>>>1) SELinux context of krb5.conf is not as expected (but I am not sure what real > >>>>issue could that cause): > >>>> > >>>># restorecon -FvvR /etc/krb5.conf > >>>>restorecon reset /etc/krb5.conf context > >>>>unconfined_u:object_r:etc_t:s0->system_u:object_r:krb5_conf_t:s0 > >>>> > >>> > >>>Fixed. Thanks, I shouldn have noticed that doing mv would just replace > >>>the original context. > >>> > >>>>2) I can no longer kinit on IPA server after applying your patch > >>>># rpm -q sssd > >>>>sssd-1.9.90-0.20121030T1436Zgitf46bf56.fc17.x86_64 > >>>># rpm -Uvh --force freeipa-*.rpm > >>>># head -n 5 /etc/krb5.conf > >>>>includedir /var/lib/sss/pubconf/krb5.include.d/ > >>>>[logging] > >>>> default = FILE:/var/log/krb5libs.log > >>>> kdc = FILE:/var/log/krb5kdc.log > >>>> admin_server = FILE:/var/log/kadmind.log > >>>># KRB5_TRACE=/dev/stdout kinit admin > >>>>[21059] 1351684052.658548: Getting initial credentials for > >>>>admin at IDM.LAB.BOS.REDHAT.COM > >>>>[21059] 1351684052.665269: Sending request (200 bytes) to IDM.LAB.BOS.REDHAT.COM > >>>>[21059] 1351684052.665989: Resolving hostname vm-044.idm.lab.bos.redhat.com > >>>>[21059] 1351684052.667511: Sending initial UDP request to dgram 10.16.78.44:88 > >>>>[21059] 1351684052.672514: Received answer from dgram 10.16.78.44:88 > >>>>[21059] 1351684052.672653: Response was from master KDC > >>>>[21059] 1351684052.672751: Received error from KDC: -1765328370/KDC has no > >>>>support for encryption type > >>>>kinit: KDC has no support for encryption type while getting initial credentials > >>>> > >>>> > >>>>Now when I comment includedir: > >>>># head -n 5 /etc/krb5.conf > >>>># kinit admin > >>>>Password for admin at IDM.LAB.BOS.REDHAT.COM: > >>>># echo $? > >>>>0 > >>>> > >>>>When I upgraded client machine (without krb5kdc), kinit worked fine. Does that > >>>>mean that krb5.conf can only be changed on client machines? > >>>> > >>> > >>>I'm still looking into this. I'm not sure why kinit does that and why it > >>>does that on the IPA server only. Unfortunately the default krb5 package > >>>is so optimized that I need to rebuild one without optimizations. > >>> > >>>>3) We should also add Requires on sssd >= 1.9.0 in FreeIPA spec file to pick up > >>>>the new feature. Otherwise I just get an error on client: > >>>> > >>>># kinit admin > >>>>kinit: Included profile directory could not be read while initializing Kerberos > >>>>5 library > >>>> > >>> > >>>Done > >>> > >>>>4) (Optional) I think we can make the process of checking if IPA is configured > >>>>easier and follow a similar way that Sumit did: > >>>>https://fedorahosted.org/freeipa/changeset/fe66fbe637132ac5eb22eea388e2261f33497bf5/ > >>>> > >>>>This section: > >>>> > >>>>+restore=0 > >>>>+test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l > >>>>'/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') > >>>>+ > >>>>+if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then > >>>>+ if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf > >>>>2>/dev/null ; then > >>>> > >>>>could then be replaced by something like this: > >>>> > >>>>python -c "import sys; from ipapython import ipautil; sys.exit(0 if > >>>>ipapython.is_ipaclient_configured() else 1);" > /dev/null 2>&1 > >>>>if [ $? -eq 0 ]; then > >>>> > >>>>I am not saying you need to do this step, this can be done later by us. > >>> > >>>That code currently only exists for IPA server, right? At least judging > >>>by: > >>>from ipaserver.install import installutils; > >>> > >>>Then I would prefer to do it separately. It's a good idea, though, the > >>>postscript as it is now is ugly. > >>> > >> > >>Thanks for updated patch, now when I updated to the most recent sssd, kinit > >>worked for me even though IPA master krb5.conf was updated. Few more issues I > >>found follows: > >> > > > >That must have been krb5 updated, sssd does not have much to do with > >bare kinit. > > > >>rpmbuild --define "_topdir /root/freeipa-master/rpmbuild" -ba freeipa.spec > >>error: line 179: Bad Requireflags: qualifiers: Requires(postttrans): > >>policycoreutils > >>make: *** [rpms] Error 1 > >> > >>This is the reason: > >>+Requires(postttrans): policycoreutils > >>should be: > >>+Requires(posttrans): policycoreutils > >> > > > >Thanks, the requires were misplaced, they were present in the server > >section and should have been in the client section..and because I only > >tested with make client-rpms (see below), I didn't notice the typo. > > > >>2) IPA server krb5.conf is not updated for clean server/replica installation. > >>The includedir can get there only with next package update. > >> > >>install/share/krb5.conf.template would also need to be updated. > >> > > > >Done. I didn't realize the codepaths were different. > > > >> > >>Besides these 2 issues (and the SELinux ones), the patch should be good to go. > >> > >>Martin > > > >New patches are attached. > > > > We have discussed the patch with Jakub off-list and decided that the > upgrade should be done in %post (with an appropriate $1 check) > instead of %posttrans. > With a little bit more context about why I chose %posttrans initially at all..I wasn't sure if yum/rpm guarantees it would install the dependencies (in this case sssd) before installing ipa-client-install, so I initially did the upgrade in %posttrans to make sure all packages were in place. > Besides that, ACK. Thank you, new patches are attached. -------------- next part -------------- >From 9a98459b258da23529a072b9d77568628d2486e6 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Fri, 17 Aug 2012 11:19:03 +0200 Subject: [PATCH 1/3] ipachangeconf: allow specifying non-default delimeter for options --- ipa-client/ipaclient/ipachangeconf.py | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/ipa-client/ipaclient/ipachangeconf.py b/ipa-client/ipaclient/ipachangeconf.py index 6cf47b807957c245fe03ff4259e35526c49175a9..bdc5579fccd82193e837b5e86cbc694c2619317c 100644 --- a/ipa-client/ipaclient/ipachangeconf.py +++ b/ipa-client/ipaclient/ipachangeconf.py @@ -174,9 +174,12 @@ class IPAChangeConf: self.subsectdel[1])) continue if o['type'] == "option": + delim = o.get('delim', self.dassign) + if delim not in self.assign: + raise ValueError('Unknown delim "%s" must be one of "%s"' % (delim, " ".join([d for d in self.assign]))) output.append(self._dump_line(self.indent[level], o['name'], - self.dassign, + delim, o['value'])) continue if o['type'] == "comment": @@ -200,13 +203,21 @@ class IPAChangeConf: 'type': 'comment', 'value': value.rstrip()} # pylint: disable=E1103 + o = dict() parts = line.split(self.dassign, 1) if len(parts) < 2: - raise SyntaxError('Syntax Error: Unknown line format') + # The default assign didn't match, try the non-default + for d in self.assign[1:]: + parts = line.split(d, 1) + if len(parts) >= 2: + o['delim'] = d + break - return {'name': parts[0].strip(), - 'type': 'option', - 'value': parts[1].rstrip()} + if 'delim' not in o: + raise SyntaxError, 'Syntax Error: Unknown line format' + + o.update({'name':parts[0].strip(), 'type':'option', 'value':parts[1].rstrip()}) + return o def findOpts(self, opts, type, name, exclude_sections=False): @@ -256,13 +267,13 @@ class IPAChangeConf: 'value': val}) continue if o['type'] == 'option': - val = self._dump_line(self.indent[level], - o['name'], - self.dassign, - o['value']) - opts.append({'name': 'comment', - 'type': 'comment', - 'value': val}) + delim = o.get('delim', self.dassign) + if delim not in self.assign: + val = self._dump_line(self.indent[level], + o['name'], + delim, + o['value']) + opts.append({'name':'comment', 'type':'comment', 'value':val}) continue if o['type'] == 'comment': opts.append(o) -- 1.8.0 -------------- next part -------------- >From 550e10db91f82db916ac12cc1559eb1dbf901703 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 31 Oct 2012 10:59:04 +0100 Subject: [PATCH 2/3] Specify includedir in krb5.conf on new installs --- freeipa.spec.in | 2 +- install/share/krb5.conf.template | 2 ++ ipa-client/ipa-install/ipa-client-install | 7 ++++++- 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 3f446032360a37d6aeb55c287eea2c0cd088bf31..6c631315506fc0d7dfc05bbb8e7e6cefe3146004 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -84,7 +84,7 @@ BuildRequires: pylint BuildRequires: python-polib BuildRequires: libipa_hbac-python BuildRequires: python-memcached -BuildRequires: sssd >= 1.8.0 +BuildRequires: sssd >= 1.9.2 BuildRequires: python-lxml BuildRequires: python-pyasn1 >= 0.0.9a BuildRequires: python-dns diff --git a/install/share/krb5.conf.template b/install/share/krb5.conf.template index f8b1a6f09868c55e47f21279b6d061fbd8251171..ed30b9e0fe37151c097d25e8b2e9fcf600a0a690 100644 --- a/install/share/krb5.conf.template +++ b/install/share/krb5.conf.template @@ -1,3 +1,5 @@ +includedir /var/lib/sss/pubconf/krb5.include.d + [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 190efb183d8c96e2c9665cf51d5346dc1111ae24..5bfaf3319e3f3f015059150b7cb9030495f3c7b8 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -729,7 +729,7 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, options, filename, client_domain): krbconf = ipaclient.ipachangeconf.IPAChangeConf("IPA Installer") - krbconf.setOptionAssignment(" = ") + krbconf.setOptionAssignment((" = ", " ")) krbconf.setSectionNameDelimiters(("[","]")) krbconf.setSubSectionDelimiters(("{","}")) krbconf.setIndent((""," "," ")) @@ -737,6 +737,11 @@ def configure_krb5_conf(cli_realm, cli_domain, cli_server, cli_kdc, dnsok, opts = [{'name':'comment', 'type':'comment', 'value':'File modified by ipa-client-install'}, {'name':'empty', 'type':'empty'}] + # SSSD include dir + if options.sssd: + opts.append({'name':'includedir', 'type':'option', 'value':'/var/lib/sss/pubconf/krb5.include.d/', 'delim':' '}) + opts.append({'name':'empty', 'type':'empty'}) + #[libdefaults] libopts = [{'name':'default_realm', 'type':'option', 'value':cli_realm}] if not dnsok or not cli_kdc or options.force: -- 1.8.0 -------------- next part -------------- >From f51e6c94f57bb0103b1251558c0b2f3d206dbfef Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Wed, 31 Oct 2012 10:15:28 +0100 Subject: [PATCH 3/3] Add the includedir to krb5.conf on upgrades --- freeipa.spec.in | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6c631315506fc0d7dfc05bbb8e7e6cefe3146004..9a918ddf7ae9799b78603ef5cc7ed99c8bbfe5cd 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -283,6 +283,7 @@ Requires: libsss_autofs Requires: autofs Requires: libnfsidmap Requires: nfs-utils +Requires(post): policycoreutils Obsoletes: ipa-client >= 1.0 @@ -611,6 +612,21 @@ if [ $1 -eq 0 ]; then fi %endif +%post client +if [ $1 -gt 1 ] ; then + # Has the client been configured? + restore=0 + test -f '/var/lib/ipa-client/sysrestore/sysrestore.index' && restore=$(wc -l '/var/lib/ipa-client/sysrestore/sysrestore.index' | awk '{print $1}') + + if [ -f '/etc/sssd/sssd.conf' -a $restore -ge 2 ]; then + if ! egrep -q '/var/lib/sss/pubconf/krb5.include.d/' /etc/krb5.conf 2>/dev/null ; then + echo "includedir /var/lib/sss/pubconf/krb5.include.d/" > /etc/krb5.conf.ipanew + cat /etc/krb5.conf >> /etc/krb5.conf.ipanew + mv /etc/krb5.conf.ipanew /etc/krb5.conf + /sbin/restorecon /etc/krb5.conf + fi + fi +fi %if ! %{ONLY_CLIENT} %files server -f server-python.list -- 1.8.0 From jhrozek at redhat.com Tue Nov 13 10:33:36 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 13 Nov 2012 11:33:36 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <50A129BE.8020702@redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> <5098C2D2.9060309@redhat.com> <20121109150629.GR31678@hendrix.brq.redhat.com> <50A129BE.8020702@redhat.com> Message-ID: <20121113103336.GD8495@hendrix.brq.redhat.com> On Mon, Nov 12, 2012 at 05:54:22PM +0100, Jan Cholasta wrote: > On 9.11.2012 16:06, Jakub Hrozek wrote: > >On Tue, Nov 06, 2012 at 08:57:06AM +0100, Jan Cholasta wrote: > >>On 29.10.2012 17:21, Jakub Hrozek wrote: > >>>An improvement based on Honza's suggestion. > >>> > >> > >>You might want to remove the try block around > >>"sssdconfig.activate_service('autofs')". If it throws NoServiceError > >>at this point, there is something really broken in SSSDConfig, in > >>which case it is better to display a traceback rather than a nice > >>error message IMO. > >> > > > >In retrospective, I agree. We can't try-except every line. > > > > Add an appropriate sys.exit() at the end of the except > SSSDConfig.ServiceNotRecognizedError block and it's an ACK. > > Honza Done, thank you for the review. -------------- next part -------------- >From 8fb1772843989969cdd839ac464915d741807fbf Mon Sep 17 00:00:00 2001 From: Jakub Hrozek Date: Mon, 29 Oct 2012 10:06:45 +0100 Subject: [PATCH] Make enabling the autofs service more robust --- ipa-client/ipa-install/ipa-client-automount | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/ipa-client/ipa-install/ipa-client-automount b/ipa-client/ipa-install/ipa-client-automount index 182f9f659dc3bfca198fc254f1a51047b3d9d31f..fd922b8a9e3fafbe1c740642752ff9258f1260bd 100755 --- a/ipa-client/ipa-install/ipa-client-automount +++ b/ipa-client/ipa-install/ipa-client-automount @@ -154,14 +154,19 @@ def configure_autofs_sssd(fstore, statestore, autodiscover, options): except Exception, e: sys.exit(e) - if 'autofs' not in sssdconfig.list_services(): + try: sssdconfig.new_service('autofs') + except SSSDConfig.ServiceAlreadyExists: + pass + except SSSDConfig.ServiceNotRecognizedError: + root_logger.error("Unable to activate the Autofs service in SSSD config.") + root_logger.info( + "Please make sure you have SSSD built with autofs support installed.") + root_logger.info( + "Configure autofs support manually in /etc/sssd/sssd.conf.") + sys.exit("Cannot create the autofs service in sssd.conf") - try: - sssdconfig.activate_service('autofs') - except SSSDConfig.NoServiceError: - print "Unable to activate the autofs service in SSSD config." - root_logger.debug("Unable to activate the autofs service in SSSD config.") + sssdconfig.activate_service('autofs') domain = None for name in domains: -- 1.8.0 From pviktori at redhat.com Tue Nov 13 12:39:00 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 Nov 2012 13:39:00 +0100 Subject: [Freeipa-devel] [PATCH 82] Compliant client side session cookie behavior In-Reply-To: <50A02438.50601@redhat.com> References: <50A02438.50601@redhat.com> Message-ID: <50A23F64.7020903@redhat.com> Continuing from yesterday. I tried building the RPMs, installing a server, running the tests, and checking the Web UI. Each of these steps failed. On 11/11/2012 11:18 PM, John Dennis wrote: > Note: This has been tested with both the command line api and the > browser on both Fedora and RHEL-6. It has also been tested to make sure > any cookies stored before an upgrade will work correctly. > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > freeipa-jdennis-0082-Compliant-client-side-session-cookie-behavior.patch > > >>From 089d69a1e06636bbd2836fcb9072b5a2ffef7ae2 Mon Sep 17 00:00:00 2001 > From: John Dennis > Date: Sun, 11 Nov 2012 17:05:32 -0500 > Subject: [PATCH 82] Compliant client side session cookie behavior > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: 8bit > [...] > > Ticket https://fedorahosted.org/freeipa/ticket/3022 > --- > ipalib/rpc.py | 224 +++++++++++++---- > ipalib/session.py | 39 +-- > ipapython/cookie.py | 486 ++++++++++++++++++++++++++++++++++++ > ipaserver/rpcserver.py | 6 +- > tests/test_ipapython/test_cookie.py | 332 ++++++++++++++++++++++++ > 5 files changed, 1017 insertions(+), 70 deletions(-) > create mode 100644 ipapython/cookie.py > create mode 100644 tests/test_ipapython/test_cookie.py > > diff --git a/ipalib/rpc.py b/ipalib/rpc.py > index c555105..b2021c1 100644 > --- a/ipalib/rpc.py > +++ b/ipalib/rpc.py > @@ -61,7 +64,8 @@ from ipalib.krb_utils import KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN, KRB5KRB_AP_ERR_TKT > KRB5_FCC_PERM, KRB5_FCC_NOFILE, KRB5_CC_FORMAT, KRB5_REALM_CANT_RESOLVE > from ipapython.dn import DN > > -COOKIE_NAME = 'ipa_session_cookie:%s' > +COOKIE_NAME = 'ipa_session' COOKIE_NAME is used in ipa-client-install, which promptly fails when it does `kernel_keyring.del_key(COOKIE_NAME % host_principal)`. (There should probably be a helper function to encapsulate this call.) > +KEYRING_COOKIE_NAME = '%s_cookie:%%s' % COOKIE_NAME > > def xml_wrap(value): > """ > diff --git a/ipalib/session.py b/ipalib/session.py > index 36beece..900259a 100644 > --- a/ipalib/session.py > +++ b/ipalib/session.py > @@ -955,13 +955,18 @@ class MemcacheSessionManager(SessionManager): > Session id as string or None if not found. > ''' > session_id = None > - if cookie_header is not None: > - cookie = Cookie.SimpleCookie() > - cookie.load(cookie_header) > - session_cookie = cookie.get(self.session_cookie_name) > - if session_cookie is not None: > - session_id = session_cookie.value > - self.debug('found session cookie_id = %s', session_id) > + try: > + session_cookie = Cookie.get_named_cookie_from_string(cookie_header, self.session_cookie_name) > + except Exception, e: > + session_cookie = None > + else: > + session_id = session_cookie.value When the user first accesses the Web UI, session_cookie will be None, resulting in an Internal Server Error. > diff --git a/ipapython/cookie.py b/ipapython/cookie.py > new file mode 100644 > index 0000000..0033aed > --- /dev/null > +++ b/ipapython/cookie.py [...] > + > + @property > + def timestamp(self): Pylint complains here and in similar places below: ipapython/cookie.py:313: [E0202, Cookie.timestamp] An attribute affected in ipapython.cookie line 310 hide this method > diff --git a/tests/test_ipapython/test_cookie.py b/tests/test_ipapython/test_cookie.py > new file mode 100644 > index 0000000..4b3c317 > --- /dev/null > +++ b/tests/test_ipapython/test_cookie.py > @@ -0,0 +1,332 @@ > +# Authors: > +# John Dennis > +# > +# Copyright (C) 2012 Red Hat > +# see file 'COPYING' for use and warranty information > +# > +# 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 Foundation, either version 3 of the License, or > +# (at your option) any later version. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program. If not, see. > + > +import unittest > +import time > +import datetime > +import calendar > +from cookie import Cookie Here I get ImportError: No module named cookie. -- Petr? From pviktori at redhat.com Tue Nov 13 14:57:42 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 13 Nov 2012 15:57:42 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A0DBC1.1060409@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> Message-ID: <50A25FE6.6000009@redhat.com> On 11/12/2012 12:21 PM, Petr Viktorin wrote: > On 11/08/2012 11:10 PM, Rob Crittenden wrote: >> >> This may not be a new problem specific to this, I'm not sure yet, but >> uninstall doesn't untrack all the certificates in the new tomcat >> directory. It also seems to miss the ipaCert alias in httpd (my >> post-install check caught only this one). > > I'll look into this. You're right. For some reason the cert untracking was part of the PKI DS uninstall step, so it didn't run on new installs. Also, the post-install check used configured_constants after the uninstallation unconfigured everything. Fix attached. >> It may also be helpful to combine all the required patches up to this >> point into a single post, sort of a "we're ready for broader testing >> checkpoint". Sifting through this long thread finding all the various >> patches was tedious. I sure wouldn't want to actually push what I culled >> because I'm not 100% sure I got them all. > > Attached. > For convenience, I've also pushed the changes to a personal repository. To fetch to branch "pviktori-dogtag-10" you can do: git fetch -f git://github.com/encukou/freeipa.git dogtag-10:pviktori-dogtag-10 (It's a WIP branch. I will be rebasing it. You might need --force when pulling. Let the Git gods have mercy on my soul.) -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0099-Properly-stop-tracking-certificates-on-uninstall.patch Type: text/x-patch Size: 4792 bytes Desc: not available URL: From mkosek at redhat.com Tue Nov 13 16:46:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Nov 2012 17:46:00 +0100 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes Message-ID: <50A27948.7040908@redhat.com> Index task need to be run for both index updates and new indexes, otherwise some current values may not be indexed and could cause issues when searching LDAP (like fqdn did). https://fedorahosted.org/freeipa/ticket/3253 --- This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix release (unless we want to backport more patches to 2.2 line). It should fix a severe issue when SSSD was no longer able to authenticate users against the update 2.2.1 FreeIPA server. I specifically updated all index updates (even when the index definition is already in LDAP) to make sure we fix any index that where the upgrade failed previously due to this bug. FreeIPA 3.0+ packages already contains a patch (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really new/updated indexes only, but I would not backport that patch due to messed fqdn index in 2.2.1. After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all required indexes, including fqdn index: # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* Preparing... ########################################### [100%] 1:freeipa-python ########################################### [ 17%] 2:freeipa-client ########################################### [ 33%] 3:freeipa-admintools ########################################### [ 50%] 4:freeipa-server ########################################### [ 67%] ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension 5:freeipa-server-selinux ########################################### [ 83%] 6:freeipa-debuginfo ########################################### [100%] # grep "Creating task to index" /var/log/ipaupgrade.log 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-333-run-index-task-for-new-indexes.patch Type: text/x-patch Size: 1622 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 13 16:46:20 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 13 Nov 2012 17:46:20 +0100 Subject: [Freeipa-devel] [PATCH 0090] Fix origin handling in dn_to_dnsname() for zone DNs Message-ID: <50A2795C.8070402@redhat.com> Hello, I found the bug in dn_to_dnsname() during my work on https://fedorahosted.org/bind-dyndb-ldap/ticket/91 "Cache is not flushed properly if renamed/deleted zone has superior zone in LDAP" Consider this change as part of solution for ticket #91: Fix origin handling in dn_to_dnsname() for zone DNs. This patch fixes case where DN is zone (i.e. DN with single idnsName component) and origin is non-NULL. Function str_to_isc_buffer() was fixed to not truncate last character. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0090-Fix-origin-handling-in-dn_to_dnsname-for-zone-DNs.patch Type: text/x-patch Size: 3600 bytes Desc: not available URL: From simo at redhat.com Tue Nov 13 17:05:22 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2012 12:05:22 -0500 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <50A27948.7040908@redhat.com> References: <50A27948.7040908@redhat.com> Message-ID: <1352826322.10327.554.camel@willson.li.ssimo.org> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: > Index task need to be run for both index updates and new indexes, > otherwise some current values may not be indexed and could cause > issues when searching LDAP (like fqdn did). > > https://fedorahosted.org/freeipa/ticket/3253 > > --- > > This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix > release (unless we want to backport more patches to 2.2 line). It should fix a > severe issue when SSSD was no longer able to authenticate users against the > update 2.2.1 FreeIPA server. > > I specifically updated all index updates (even when the index definition is > already in LDAP) to make sure we fix any index that where the upgrade failed > previously due to this bug. FreeIPA 3.0+ packages already contains a patch > (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really > new/updated indexes only, but I would not backport that patch due to messed > fqdn index in 2.2.1. > > After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all > required indexes, including fqdn index: > > # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* > Preparing... ########################################### [100%] > 1:freeipa-python ########################################### [ 17%] > 2:freeipa-client ########################################### [ 33%] > 3:freeipa-admintools ########################################### [ 50%] > 4:freeipa-server ########################################### [ 67%] > ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension > 5:freeipa-server-selinux ########################################### [ 83%] > 6:freeipa-debuginfo ########################################### [100%] > > # grep "Creating task to index" /var/log/ipaupgrade.log > 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid > 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf > 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost > 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser > 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< > 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId > 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId > Martin, does this means we run these task for every rpm upgrade regardless ? Or do we mark indexes as regenerated and do not repeat on the following rpm upgrade ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Tue Nov 13 17:20:30 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Nov 2012 18:20:30 +0100 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <1352826322.10327.554.camel@willson.li.ssimo.org> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> Message-ID: <50A2815E.50208@redhat.com> On 11/13/2012 06:05 PM, Simo Sorce wrote: > On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: >> Index task need to be run for both index updates and new indexes, >> otherwise some current values may not be indexed and could cause >> issues when searching LDAP (like fqdn did). >> >> https://fedorahosted.org/freeipa/ticket/3253 >> >> --- >> >> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix >> release (unless we want to backport more patches to 2.2 line). It should fix a >> severe issue when SSSD was no longer able to authenticate users against the >> update 2.2.1 FreeIPA server. >> >> I specifically updated all index updates (even when the index definition is >> already in LDAP) to make sure we fix any index that where the upgrade failed >> previously due to this bug. FreeIPA 3.0+ packages already contains a patch >> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really >> new/updated indexes only, but I would not backport that patch due to messed >> fqdn index in 2.2.1. >> >> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all >> required indexes, including fqdn index: >> >> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* >> Preparing... ########################################### [100%] >> 1:freeipa-python ########################################### [ 17%] >> 2:freeipa-client ########################################### [ 33%] >> 3:freeipa-admintools ########################################### [ 50%] >> 4:freeipa-server ########################################### [ 67%] >> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension >> 5:freeipa-server-selinux ########################################### [ 83%] >> 6:freeipa-debuginfo ########################################### [100%] >> >> # grep "Creating task to index" /var/log/ipaupgrade.log >> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid >> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf >> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost >> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser >> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< >> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId >> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId >> > > Martin, does this means we run these task for every rpm upgrade > regardless ? Or do we mark indexes as regenerated and do not repeat on > the following rpm upgrade ? > > Simo. > In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the update status. I fixed that behavior in FreeIPA 3.0 where we now only run the index task when the index is really updated or added (there is more reasoning above, but I am open to suggestions). Martin From lroot at redhat.com Tue Nov 13 17:32:57 2012 From: lroot at redhat.com (Lynn Root) Date: Tue, 13 Nov 2012 12:32:57 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Fixed the catch of the hostname option during ipa-server-install In-Reply-To: <2072839662.137611.1352827887620.JavaMail.root@redhat.com> Message-ID: <1376754491.138319.1352827977228.JavaMail.root@redhat.com> Hi all - Originally ipa-server-install would still prompt for the hostname even if it's supplied in the initial installation command. Ticket: https://fedorahosted.org/freeipa/ticket/2692 Lynn Root Associate Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lroot-0001-1-Fixed-the-catch-of-the-hostname-option-during-ipa-se.patch Type: text/x-patch Size: 982 bytes Desc: not available URL: From lroot at redhat.com Tue Nov 13 17:37:19 2012 From: lroot at redhat.com (Lynn Root) Date: Tue, 13 Nov 2012 12:37:19 -0500 (EST) Subject: [Freeipa-devel] [PATCH] Fixed the catch of the hostname option during ipa-server-install In-Reply-To: <1376754491.138319.1352827977228.JavaMail.root@redhat.com> Message-ID: <985567129.139743.1352828239094.JavaMail.root@redhat.com> Er, correctly formatted patch :D (I hope) Lynn Root Associate Software Engineer Red Hat ----- Original Message ----- > Hi all - > Originally ipa-server-install would still prompt for the hostname > even if it's supplied in the initial installation command. > Ticket: https://fedorahosted.org/freeipa/ticket/2692 > Lynn Root > Associate Software Engineer > Red Hat > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lroot-0003-1-Fixed-the-catch-of-the-hostname-option-during-ipa-se.patch Type: text/x-patch Size: 982 bytes Desc: not available URL: From simo at redhat.com Tue Nov 13 19:49:47 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2012 14:49:47 -0500 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <50A2815E.50208@redhat.com> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> Message-ID: <1352836187.10327.562.camel@willson.li.ssimo.org> On Tue, 2012-11-13 at 18:20 +0100, Martin Kosek wrote: > On 11/13/2012 06:05 PM, Simo Sorce wrote: > > On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: > >> Index task need to be run for both index updates and new indexes, > >> otherwise some current values may not be indexed and could cause > >> issues when searching LDAP (like fqdn did). > >> > >> https://fedorahosted.org/freeipa/ticket/3253 > >> > >> --- > >> > >> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix > >> release (unless we want to backport more patches to 2.2 line). It should fix a > >> severe issue when SSSD was no longer able to authenticate users against the > >> update 2.2.1 FreeIPA server. > >> > >> I specifically updated all index updates (even when the index definition is > >> already in LDAP) to make sure we fix any index that where the upgrade failed > >> previously due to this bug. FreeIPA 3.0+ packages already contains a patch > >> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really > >> new/updated indexes only, but I would not backport that patch due to messed > >> fqdn index in 2.2.1. > >> > >> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all > >> required indexes, including fqdn index: > >> > >> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* > >> Preparing... ########################################### [100%] > >> 1:freeipa-python ########################################### [ 17%] > >> 2:freeipa-client ########################################### [ 33%] > >> 3:freeipa-admintools ########################################### [ 50%] > >> 4:freeipa-server ########################################### [ 67%] > >> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension > >> 5:freeipa-server-selinux ########################################### [ 83%] > >> 6:freeipa-debuginfo ########################################### [100%] > >> > >> # grep "Creating task to index" /var/log/ipaupgrade.log > >> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid > >> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf > >> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost > >> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser > >> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< > >> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId > >> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId > >> > > > > Martin, does this means we run these task for every rpm upgrade > > regardless ? Or do we mark indexes as regenerated and do not repeat on > > the following rpm upgrade ? > > > > Simo. > > > > In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the > update status. I fixed that behavior in FreeIPA 3.0 where we now only run the > index task when the index is really updated or added (there is more reasoning > above, but I am open to suggestions). Ah as long as it works properly in 3.0 that good enough, I do not think we'll release too many updates to 2.x anymore so it is ok as is. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Nov 13 22:23:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Nov 2012 17:23:44 -0500 Subject: [Freeipa-devel] [PATCH] 0098 Provide explicit user name for Dogtag installation scripts In-Reply-To: <50A11646.4050403@redhat.com> References: <50A11646.4050403@redhat.com> Message-ID: <50A2C870.7000508@redhat.com> Petr Viktorin wrote: > See commit message. > > Dogtag is changing its behavior soon (as in: tomorrow). This patch will > be needed for IPA to install on Fedora 18. > > > It would be nice if this went in our daily builds ASAP, so Dogtag people > can test. Sorry for the short notice, I originally misunderstood Ade and > included it in the merged database patches. I tested this with 3.0.1 in F-18 and it works as expected. I accidentally tested a mish-mash of this and saw how it would fail, so the patch is definitely needed. I've included the patch in the F-18 spec file only for now. Unless there is a need for us to push this upstream sooner. Do we also need to set the n-v-r of pki-core to the latest? rob From mkosek at redhat.com Tue Nov 13 22:00:03 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Nov 2012 23:00:03 +0100 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <1352836187.10327.562.camel@willson.li.ssimo.org> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> <1352836187.10327.562.camel@willson.li.ssimo.org> Message-ID: <50A2C2E3.2080409@redhat.com> On 11/13/2012 08:49 PM, Simo Sorce wrote: > On Tue, 2012-11-13 at 18:20 +0100, Martin Kosek wrote: >> On 11/13/2012 06:05 PM, Simo Sorce wrote: >>> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: >>>> Index task need to be run for both index updates and new indexes, >>>> otherwise some current values may not be indexed and could cause >>>> issues when searching LDAP (like fqdn did). >>>> >>>> https://fedorahosted.org/freeipa/ticket/3253 >>>> >>>> --- >>>> >>>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix >>>> release (unless we want to backport more patches to 2.2 line). It should fix a >>>> severe issue when SSSD was no longer able to authenticate users against the >>>> update 2.2.1 FreeIPA server. >>>> >>>> I specifically updated all index updates (even when the index definition is >>>> already in LDAP) to make sure we fix any index that where the upgrade failed >>>> previously due to this bug. FreeIPA 3.0+ packages already contains a patch >>>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really >>>> new/updated indexes only, but I would not backport that patch due to messed >>>> fqdn index in 2.2.1. >>>> >>>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all >>>> required indexes, including fqdn index: >>>> >>>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* >>>> Preparing... ########################################### [100%] >>>> 1:freeipa-python ########################################### [ 17%] >>>> 2:freeipa-client ########################################### [ 33%] >>>> 3:freeipa-admintools ########################################### [ 50%] >>>> 4:freeipa-server ########################################### [ 67%] >>>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension >>>> 5:freeipa-server-selinux ########################################### [ 83%] >>>> 6:freeipa-debuginfo ########################################### [100%] >>>> >>>> # grep "Creating task to index" /var/log/ipaupgrade.log >>>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid >>>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf >>>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost >>>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser >>>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< >>>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId >>>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId >>>> >>> >>> Martin, does this means we run these task for every rpm upgrade >>> regardless ? Or do we mark indexes as regenerated and do not repeat on >>> the following rpm upgrade ? >>> >>> Simo. >>> >> >> In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the >> update status. I fixed that behavior in FreeIPA 3.0 where we now only run the >> index task when the index is really updated or added (there is more reasoning >> above, but I am open to suggestions). > > Ah as long as it works properly in 3.0 that good enough, I do not think > we'll release too many updates to 2.x anymore so it is ok as is. > > Simo. > Right. My target was to have a FreeIPA 2.x with valid indexes so that we can use the new index behavior in 3.x which runs indexes only when they are changed (which would otherwise fail in this case when index object in LDAP exists but index task was not run). Other option would be to backport this behavior to 2.2.2 but implement routine which would check that at least one index task was run for every index object in LDAP - and if not, it would fire the missing index task. But this may be an overkill for this case. Martin From simo at redhat.com Wed Nov 14 00:15:42 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2012 19:15:42 -0500 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <50A2C2E3.2080409@redhat.com> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> <1352836187.10327.562.camel@willson.li.ssimo.org> <50A2C2E3.2080409@redhat.com> Message-ID: <1352852142.10327.607.camel@willson.li.ssimo.org> On Tue, 2012-11-13 at 23:00 +0100, Martin Kosek wrote: > On 11/13/2012 08:49 PM, Simo Sorce wrote: > > On Tue, 2012-11-13 at 18:20 +0100, Martin Kosek wrote: > >> On 11/13/2012 06:05 PM, Simo Sorce wrote: > >>> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: > >>>> Index task need to be run for both index updates and new indexes, > >>>> otherwise some current values may not be indexed and could cause > >>>> issues when searching LDAP (like fqdn did). > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/3253 > >>>> > >>>> --- > >>>> > >>>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix > >>>> release (unless we want to backport more patches to 2.2 line). It should fix a > >>>> severe issue when SSSD was no longer able to authenticate users against the > >>>> update 2.2.1 FreeIPA server. > >>>> > >>>> I specifically updated all index updates (even when the index definition is > >>>> already in LDAP) to make sure we fix any index that where the upgrade failed > >>>> previously due to this bug. FreeIPA 3.0+ packages already contains a patch > >>>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really > >>>> new/updated indexes only, but I would not backport that patch due to messed > >>>> fqdn index in 2.2.1. > >>>> > >>>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all > >>>> required indexes, including fqdn index: > >>>> > >>>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* > >>>> Preparing... ########################################### [100%] > >>>> 1:freeipa-python ########################################### [ 17%] > >>>> 2:freeipa-client ########################################### [ 33%] > >>>> 3:freeipa-admintools ########################################### [ 50%] > >>>> 4:freeipa-server ########################################### [ 67%] > >>>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension > >>>> 5:freeipa-server-selinux ########################################### [ 83%] > >>>> 6:freeipa-debuginfo ########################################### [100%] > >>>> > >>>> # grep "Creating task to index" /var/log/ipaupgrade.log > >>>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid > >>>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf > >>>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost > >>>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser > >>>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< > >>>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId > >>>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId > >>>> > >>> > >>> Martin, does this means we run these task for every rpm upgrade > >>> regardless ? Or do we mark indexes as regenerated and do not repeat on > >>> the following rpm upgrade ? > >>> > >>> Simo. > >>> > >> > >> In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the > >> update status. I fixed that behavior in FreeIPA 3.0 where we now only run the > >> index task when the index is really updated or added (there is more reasoning > >> above, but I am open to suggestions). > > > > Ah as long as it works properly in 3.0 that good enough, I do not think > > we'll release too many updates to 2.x anymore so it is ok as is. > > > > Simo. > > > > Right. My target was to have a FreeIPA 2.x with valid indexes so that we can > use the new index behavior in 3.x which runs indexes only when they are changed > (which would otherwise fail in this case when index object in LDAP exists but > index task was not run). > > Other option would be to backport this behavior to 2.2.2 but implement routine > which would check that at least one index task was run for every index object > in LDAP - and if not, it would fire the missing index task. But this may be an > overkill for this case. I think it would be nice to have such a mechanism long term, as it would help in rare case where update may fail midway but can be restarted. however not needed right now, might be worth a nice to have ticket for a future version Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Wed Nov 14 00:59:21 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Nov 2012 19:59:21 -0500 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <50A2C2E3.2080409@redhat.com> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> <1352836187.10327.562.camel@willson.li.ssimo.org> <50A2C2E3.2080409@redhat.com> Message-ID: <1352854761.10327.637.camel@willson.li.ssimo.org> On Tue, 2012-11-13 at 23:00 +0100, Martin Kosek wrote: > On 11/13/2012 08:49 PM, Simo Sorce wrote: > > On Tue, 2012-11-13 at 18:20 +0100, Martin Kosek wrote: > >> On 11/13/2012 06:05 PM, Simo Sorce wrote: > >>> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: > >>>> Index task need to be run for both index updates and new indexes, > >>>> otherwise some current values may not be indexed and could cause > >>>> issues when searching LDAP (like fqdn did). > >>>> > >>>> https://fedorahosted.org/freeipa/ticket/3253 > >>>> > >>>> --- > >>>> > >>>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix > >>>> release (unless we want to backport more patches to 2.2 line). It should fix a > >>>> severe issue when SSSD was no longer able to authenticate users against the > >>>> update 2.2.1 FreeIPA server. > >>>> > >>>> I specifically updated all index updates (even when the index definition is > >>>> already in LDAP) to make sure we fix any index that where the upgrade failed > >>>> previously due to this bug. FreeIPA 3.0+ packages already contains a patch > >>>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really > >>>> new/updated indexes only, but I would not backport that patch due to messed > >>>> fqdn index in 2.2.1. > >>>> > >>>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all > >>>> required indexes, including fqdn index: > >>>> > >>>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* > >>>> Preparing... ########################################### [100%] > >>>> 1:freeipa-python ########################################### [ 17%] > >>>> 2:freeipa-client ########################################### [ 33%] > >>>> 3:freeipa-admintools ########################################### [ 50%] > >>>> 4:freeipa-server ########################################### [ 67%] > >>>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension > >>>> 5:freeipa-server-selinux ########################################### [ 83%] > >>>> 6:freeipa-debuginfo ########################################### [100%] > >>>> > >>>> # grep "Creating task to index" /var/log/ipaupgrade.log > >>>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid > >>>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf > >>>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost > >>>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser > >>>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< > >>>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId > >>>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId > >>>> > >>> > >>> Martin, does this means we run these task for every rpm upgrade > >>> regardless ? Or do we mark indexes as regenerated and do not repeat on > >>> the following rpm upgrade ? > >>> > >>> Simo. > >>> > >> > >> In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the > >> update status. I fixed that behavior in FreeIPA 3.0 where we now only run the > >> index task when the index is really updated or added (there is more reasoning > >> above, but I am open to suggestions). > > > > Ah as long as it works properly in 3.0 that good enough, I do not think > > we'll release too many updates to 2.x anymore so it is ok as is. > > > > Simo. > > > > Right. My target was to have a FreeIPA 2.x with valid indexes so that we can > use the new index behavior in 3.x which runs indexes only when they are changed > (which would otherwise fail in this case when index object in LDAP exists but > index task was not run). > > Other option would be to backport this behavior to 2.2.2 but implement routine > which would check that at least one index task was run for every index object > in LDAP - and if not, it would fire the missing index task. But this may be an > overkill for this case. > > Martin Oh, btw, ack! Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Nov 14 07:31:04 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 08:31:04 +0100 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <1352854761.10327.637.camel@willson.li.ssimo.org> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> <1352836187.10327.562.camel@willson.li.ssimo.org> <50A2C2E3.2080409@redhat.com> <1352854761.10327.637.camel@willson.li.ssimo.org> Message-ID: <50A348B8.5000902@redhat.com> On 11/14/2012 01:59 AM, Simo Sorce wrote: > On Tue, 2012-11-13 at 23:00 +0100, Martin Kosek wrote: >> On 11/13/2012 08:49 PM, Simo Sorce wrote: >>> On Tue, 2012-11-13 at 18:20 +0100, Martin Kosek wrote: >>>> On 11/13/2012 06:05 PM, Simo Sorce wrote: >>>>> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: >>>>>> Index task need to be run for both index updates and new indexes, >>>>>> otherwise some current values may not be indexed and could cause >>>>>> issues when searching LDAP (like fqdn did). >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3253 >>>>>> >>>>>> --- >>>>>> >>>>>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix >>>>>> release (unless we want to backport more patches to 2.2 line). It should fix a >>>>>> severe issue when SSSD was no longer able to authenticate users against the >>>>>> update 2.2.1 FreeIPA server. >>>>>> >>>>>> I specifically updated all index updates (even when the index definition is >>>>>> already in LDAP) to make sure we fix any index that where the upgrade failed >>>>>> previously due to this bug. FreeIPA 3.0+ packages already contains a patch >>>>>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really >>>>>> new/updated indexes only, but I would not backport that patch due to messed >>>>>> fqdn index in 2.2.1. >>>>>> >>>>>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all >>>>>> required indexes, including fqdn index: >>>>>> >>>>>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* >>>>>> Preparing... ########################################### [100%] >>>>>> 1:freeipa-python ########################################### [ 17%] >>>>>> 2:freeipa-client ########################################### [ 33%] >>>>>> 3:freeipa-admintools ########################################### [ 50%] >>>>>> 4:freeipa-server ########################################### [ 67%] >>>>>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension >>>>>> 5:freeipa-server-selinux ########################################### [ 83%] >>>>>> 6:freeipa-debuginfo ########################################### [100%] >>>>>> >>>>>> # grep "Creating task to index" /var/log/ipaupgrade.log >>>>>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid >>>>>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf >>>>>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost >>>>>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser >>>>>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< >>>>>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId >>>>>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId >>>>>> >>>>> >>>>> Martin, does this means we run these task for every rpm upgrade >>>>> regardless ? Or do we mark indexes as regenerated and do not repeat on >>>>> the following rpm upgrade ? >>>>> >>>>> Simo. >>>>> >>>> >>>> In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the >>>> update status. I fixed that behavior in FreeIPA 3.0 where we now only run the >>>> index task when the index is really updated or added (there is more reasoning >>>> above, but I am open to suggestions). >>> >>> Ah as long as it works properly in 3.0 that good enough, I do not think >>> we'll release too many updates to 2.x anymore so it is ok as is. >>> >>> Simo. >>> >> >> Right. My target was to have a FreeIPA 2.x with valid indexes so that we can >> use the new index behavior in 3.x which runs indexes only when they are changed >> (which would otherwise fail in this case when index object in LDAP exists but >> index task was not run). >> >> Other option would be to backport this behavior to 2.2.2 but implement routine >> which would check that at least one index task was run for every index object >> in LDAP - and if not, it would fire the missing index task. But this may be an >> overkill for this case. >> >> Martin > > Oh, btw, ack! > > Simo. > Thanks! Pushed to ipa-2-2. I will release a new Fedora build for Fedora 17 which would have this patch. Martin From mkosek at redhat.com Wed Nov 14 07:31:36 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 08:31:36 +0100 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <1352852142.10327.607.camel@willson.li.ssimo.org> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> <1352836187.10327.562.camel@willson.li.ssimo.org> <50A2C2E3.2080409@redhat.com> <1352852142.10327.607.camel@willson.li.ssimo.org> Message-ID: <50A348D8.8070002@redhat.com> On 11/14/2012 01:15 AM, Simo Sorce wrote: > On Tue, 2012-11-13 at 23:00 +0100, Martin Kosek wrote: >> On 11/13/2012 08:49 PM, Simo Sorce wrote: >>> On Tue, 2012-11-13 at 18:20 +0100, Martin Kosek wrote: >>>> On 11/13/2012 06:05 PM, Simo Sorce wrote: >>>>> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: >>>>>> Index task need to be run for both index updates and new indexes, >>>>>> otherwise some current values may not be indexed and could cause >>>>>> issues when searching LDAP (like fqdn did). >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3253 >>>>>> >>>>>> --- >>>>>> >>>>>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix >>>>>> release (unless we want to backport more patches to 2.2 line). It should fix a >>>>>> severe issue when SSSD was no longer able to authenticate users against the >>>>>> update 2.2.1 FreeIPA server. >>>>>> >>>>>> I specifically updated all index updates (even when the index definition is >>>>>> already in LDAP) to make sure we fix any index that where the upgrade failed >>>>>> previously due to this bug. FreeIPA 3.0+ packages already contains a patch >>>>>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really >>>>>> new/updated indexes only, but I would not backport that patch due to messed >>>>>> fqdn index in 2.2.1. >>>>>> >>>>>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all >>>>>> required indexes, including fqdn index: >>>>>> >>>>>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* >>>>>> Preparing... ########################################### [100%] >>>>>> 1:freeipa-python ########################################### [ 17%] >>>>>> 2:freeipa-client ########################################### [ 33%] >>>>>> 3:freeipa-admintools ########################################### [ 50%] >>>>>> 4:freeipa-server ########################################### [ 67%] >>>>>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension >>>>>> 5:freeipa-server-selinux ########################################### [ 83%] >>>>>> 6:freeipa-debuginfo ########################################### [100%] >>>>>> >>>>>> # grep "Creating task to index" /var/log/ipaupgrade.log >>>>>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid >>>>>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf >>>>>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost >>>>>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser >>>>>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< >>>>>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId >>>>>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId >>>>>> >>>>> >>>>> Martin, does this means we run these task for every rpm upgrade >>>>> regardless ? Or do we mark indexes as regenerated and do not repeat on >>>>> the following rpm upgrade ? >>>>> >>>>> Simo. >>>>> >>>> >>>> In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the >>>> update status. I fixed that behavior in FreeIPA 3.0 where we now only run the >>>> index task when the index is really updated or added (there is more reasoning >>>> above, but I am open to suggestions). >>> >>> Ah as long as it works properly in 3.0 that good enough, I do not think >>> we'll release too many updates to 2.x anymore so it is ok as is. >>> >>> Simo. >>> >> >> Right. My target was to have a FreeIPA 2.x with valid indexes so that we can >> use the new index behavior in 3.x which runs indexes only when they are changed >> (which would otherwise fail in this case when index object in LDAP exists but >> index task was not run). >> >> Other option would be to backport this behavior to 2.2.2 but implement routine >> which would check that at least one index task was run for every index object >> in LDAP - and if not, it would fire the missing index task. But this may be an >> overkill for this case. > > I think it would be nice to have such a mechanism long term, as it would > help in rare case where update may fail midway but can be restarted. > however not needed right now, might be worth a nice to have ticket for a > future version > > Simo. > Done! https://fedorahosted.org/freeipa/ticket/3255 Martin From mkosek at redhat.com Wed Nov 14 08:18:03 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 09:18:03 +0100 Subject: [Freeipa-devel] [PATCH] 0098 Provide explicit user name for Dogtag installation scripts In-Reply-To: <50A2C870.7000508@redhat.com> References: <50A11646.4050403@redhat.com> <50A2C870.7000508@redhat.com> Message-ID: <50A353BB.7060703@redhat.com> On 11/13/2012 11:23 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> See commit message. >> >> Dogtag is changing its behavior soon (as in: tomorrow). This patch will >> be needed for IPA to install on Fedora 18. >> >> >> It would be nice if this went in our daily builds ASAP, so Dogtag people >> can test. Sorry for the short notice, I originally misunderstood Ade and >> included it in the merged database patches. > > I tested this with 3.0.1 in F-18 and it works as expected. I accidentally > tested a mish-mash of this and saw how it would fail, so the patch is > definitely needed. > > I've included the patch in the F-18 spec file only for now. Unless there is a > need for us to push this upstream sooner. Do we also need to set the n-v-r of > pki-core to the latest? > > rob Thanks Rob, you were faster in reviewing the patch that me :-) There is just an issue with upgrading to the newest pki-ca and server theme package: # rpm -q pki-ca pki-ca-10.0.0-0.52.b3.fc18.noarch # rpm -qa "*pki-*-theme" dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* error: Failed dependencies: dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 I will send a patch fixing f18 spec file soon. Martin From mkosek at redhat.com Wed Nov 14 08:35:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 09:35:57 +0100 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme Message-ID: <50A357ED.7@redhat.com> Remove redundant pki-* package Requires and change PKI server theme Requires to correct package name. https://fedorahosted.org/freeipa/ticket/3213 --- The patch fixes broken Requires with the new server theme package name (thanks Ade for help): # rpm -q pki-ca pki-ca-10.0.0-0.52.b3.fc18.noarch # rpm -qa "*pki-*-theme" dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* error: Failed dependencies: dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 This patch is intended for Fedora 18 only, of course. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-334-add-requires-for-new-dogtag10-and-its-server-theme.patch Type: text/x-patch Size: 1473 bytes Desc: not available URL: From pviktori at redhat.com Wed Nov 14 08:43:42 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 Nov 2012 09:43:42 +0100 Subject: [Freeipa-devel] [PATCH] 0098 Provide explicit user name for Dogtag installation scripts In-Reply-To: <50A2C870.7000508@redhat.com> References: <50A11646.4050403@redhat.com> <50A2C870.7000508@redhat.com> Message-ID: <50A359BE.6090001@redhat.com> On 11/13/2012 11:23 PM, Rob Crittenden wrote: > Petr Viktorin wrote: >> See commit message. >> >> Dogtag is changing its behavior soon (as in: tomorrow). This patch will >> be needed for IPA to install on Fedora 18. >> >> >> It would be nice if this went in our daily builds ASAP, so Dogtag people >> can test. Sorry for the short notice, I originally misunderstood Ade and >> included it in the merged database patches. > > I tested this with 3.0.1 in F-18 and it works as expected. I > accidentally tested a mish-mash of this and saw how it would fail, so > the patch is definitely needed. > > I've included the patch in the F-18 spec file only for now. Unless there > is a need for us to push this upstream sooner. Do we also need to set > the n-v-r of pki-core to the latest? This way, RPMs built straight from master won't work on F18, right? In older DT versions these are the defaults so having the patch in won't hurt. There's no need to change the spec for this patch. The spec problem Martin found is serious but unrelated. -- Petr? From pviktori at redhat.com Wed Nov 14 08:49:04 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 14 Nov 2012 09:49:04 +0100 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <50A2815E.50208@redhat.com> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> Message-ID: <50A35B00.3090303@redhat.com> On 11/13/2012 06:20 PM, Martin Kosek wrote: > On 11/13/2012 06:05 PM, Simo Sorce wrote: >> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: >>> Index task need to be run for both index updates and new indexes, >>> otherwise some current values may not be indexed and could cause >>> issues when searching LDAP (like fqdn did). >>> >>> https://fedorahosted.org/freeipa/ticket/3253 >>> >>> --- >>> >>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix >>> release (unless we want to backport more patches to 2.2 line). It should fix a >>> severe issue when SSSD was no longer able to authenticate users against the >>> update 2.2.1 FreeIPA server. >>> >>> I specifically updated all index updates (even when the index definition is >>> already in LDAP) to make sure we fix any index that where the upgrade failed >>> previously due to this bug. FreeIPA 3.0+ packages already contains a patch >>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really >>> new/updated indexes only, but I would not backport that patch due to messed >>> fqdn index in 2.2.1. >>> >>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all >>> required indexes, including fqdn index: >>> >>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* >>> Preparing... ########################################### [100%] >>> 1:freeipa-python ########################################### [ 17%] >>> 2:freeipa-client ########################################### [ 33%] >>> 3:freeipa-admintools ########################################### [ 50%] >>> 4:freeipa-server ########################################### [ 67%] >>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox extension >>> 5:freeipa-server-selinux ########################################### [ 83%] >>> 6:freeipa-debuginfo ########################################### [100%] >>> >>> # grep "Creating task to index" /var/log/ipaupgrade.log >>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid >>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf >>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost >>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser >>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< >>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId >>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId >>> >> >> Martin, does this means we run these task for every rpm upgrade >> regardless ? Or do we mark indexes as regenerated and do not repeat on >> the following rpm upgrade ? >> >> Simo. >> > > In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the > update status. I fixed that behavior in FreeIPA 3.0 where we now only run the > index task when the index is really updated or added (there is more reasoning > above, but I am open to suggestions). > > Martin Does this mean that if someone upgrades from 2.2.1 straight to 3.x, the indexes will be broken? -- Petr? From mkosek at redhat.com Wed Nov 14 09:03:00 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 10:03:00 +0100 Subject: [Freeipa-devel] [PATCH] 333 Run index task for new indexes In-Reply-To: <50A35B00.3090303@redhat.com> References: <50A27948.7040908@redhat.com> <1352826322.10327.554.camel@willson.li.ssimo.org> <50A2815E.50208@redhat.com> <50A35B00.3090303@redhat.com> Message-ID: <50A35E44.8080004@redhat.com> On 11/14/2012 09:49 AM, Petr Viktorin wrote: > On 11/13/2012 06:20 PM, Martin Kosek wrote: >> On 11/13/2012 06:05 PM, Simo Sorce wrote: >>> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote: >>>> Index task need to be run for both index updates and new indexes, >>>> otherwise some current values may not be indexed and could cause >>>> issues when searching LDAP (like fqdn did). >>>> >>>> https://fedorahosted.org/freeipa/ticket/3253 >>>> >>>> --- >>>> >>>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix >>>> release (unless we want to backport more patches to 2.2 line). It should fix a >>>> severe issue when SSSD was no longer able to authenticate users against the >>>> update 2.2.1 FreeIPA server. >>>> >>>> I specifically updated all index updates (even when the index definition is >>>> already in LDAP) to make sure we fix any index that where the upgrade failed >>>> previously due to this bug. FreeIPA 3.0+ packages already contains a patch >>>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really >>>> new/updated indexes only, but I would not backport that patch due to messed >>>> fqdn index in 2.2.1. >>>> >>>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create all >>>> required indexes, including fqdn index: >>>> >>>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-* >>>> Preparing... ########################################### [100%] >>>> 1:freeipa-python ########################################### [ >>>> 17%] >>>> 2:freeipa-client ########################################### [ >>>> 33%] >>>> 3:freeipa-admintools ########################################### [ >>>> 50%] >>>> 4:freeipa-server ########################################### [ >>>> 67%] >>>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of Firefox >>>> extension >>>> 5:freeipa-server-selinux ########################################### [ >>>> 83%] >>>> 6:freeipa-debuginfo ########################################### >>>> [100%] >>>> >>>> # grep "Creating task to index" /var/log/ipaupgrade.log >>>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid >>>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf >>>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost >>>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser >>>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn <<<<<< >>>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId >>>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: ntUserDomainId >>>> >>> >>> Martin, does this means we run these task for every rpm upgrade >>> regardless ? Or do we mark indexes as regenerated and do not repeat on >>> the following rpm upgrade ? >>> >>> Simo. >>> >> >> In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the >> update status. I fixed that behavior in FreeIPA 3.0 where we now only run the >> index task when the index is really updated or added (there is more reasoning >> above, but I am open to suggestions). >> >> Martin > > Does this mean that if someone upgrades from 2.2.1 straight to 3.x, the indexes > will be broken? > > Correct. Although I doubt there would be people be running 2.2.1-1 without fixing the indexes at least with the workaround I provided and described on freeipa-users and freeipa.org as sssd does not work in that case. I have been already thinking about this issue previously, we may either add a note to FreeIPA 3.x upgrade procedure for 2.2.1-1 users or make sure that https://fedorahosted.org/freeipa/ticket/3255 is implemented before Fedora 18 GA. Martin From mkosek at redhat.com Wed Nov 14 10:02:48 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 11:02:48 +0100 Subject: [Freeipa-devel] [PATCH] Make enabling the autofs service more robust In-Reply-To: <20121113103336.GD8495@hendrix.brq.redhat.com> References: <20121029162157.GM3900@hendrix.redhat.com> <5098C2D2.9060309@redhat.com> <20121109150629.GR31678@hendrix.brq.redhat.com> <50A129BE.8020702@redhat.com> <20121113103336.GD8495@hendrix.brq.redhat.com> Message-ID: <50A36C48.9020509@redhat.com> On 11/13/2012 11:33 AM, Jakub Hrozek wrote: > On Mon, Nov 12, 2012 at 05:54:22PM +0100, Jan Cholasta wrote: >> On 9.11.2012 16:06, Jakub Hrozek wrote: >>> On Tue, Nov 06, 2012 at 08:57:06AM +0100, Jan Cholasta wrote: >>>> On 29.10.2012 17:21, Jakub Hrozek wrote: >>>>> An improvement based on Honza's suggestion. >>>>> >>>> >>>> You might want to remove the try block around >>>> "sssdconfig.activate_service('autofs')". If it throws NoServiceError >>>> at this point, there is something really broken in SSSDConfig, in >>>> which case it is better to display a traceback rather than a nice >>>> error message IMO. >>>> >>> >>> In retrospective, I agree. We can't try-except every line. >>> >> >> Add an appropriate sys.exit() at the end of the except >> SSSDConfig.ServiceNotRecognizedError block and it's an ACK. >> >> Honza > > Done, thank you for the review. > Second ACK. Pushed to master, ipa-3-0. Martin From mkosek at redhat.com Wed Nov 14 11:08:46 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 12:08:46 +0100 Subject: [Freeipa-devel] [PATCH 0022] Relax restriction for leading/trailing whitespaces in *-find commands In-Reply-To: <5091168F.10007@redhat.com> References: <508FDF4D.60800@redhat.com> <5090EC81.7090604@redhat.com> <50910847.5060203@redhat.com> <5091168F.10007@redhat.com> Message-ID: <50A37BBE.3060908@redhat.com> On 10/31/2012 01:16 PM, Tomas Babej wrote: > On 10/31/2012 12:15 PM, Martin Kosek wrote: >> On 10/31/2012 10:16 AM, Martin Kosek wrote: >>> On 10/30/2012 03:08 PM, Tomas Babej wrote: >>>> Hi, >>>> >>>> All *-find commands now enable leading/trailing whitespaces in the >>>> search phrase. Behaviour has been implemented directly into >>>> crud.Search class. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2981 >>>> >>>> Tomas >>>> >>> ACK, works fine. >>> >>> Martin >>> >> I take the ACK back, just found out you forgot to re-generate API.txt which >> makes the build fail: >> >> >> # make rpms >> ... >> Argument 'criteria?' in command 'aci_find' in API file not found >> Argument count in aci_find of 0 doesn't match expected: 1 >> Argument criteria? of command aci_find in ipalib, not in API file: >> Str('criteria?', noextrawhitespace=False) >> Argument 'criteria?' in command 'delegation_find' in API file not found >> Argument count in delegation_find of 0 doesn't match expected: 1 >> Argument criteria? of command delegation_find in ipalib, not in API file: >> Str('criteria?', noextrawhitespace=False) >> Argument 'criteria?' in command 'selfservice_find' in API file not found >> Argument count in selfservice_find of 0 doesn't match expected: 1 >> Argument criteria? of command selfservice_find in ipalib, not in API file: >> Str('criteria?', noextrawhitespace=False) >> >> There are one or more changes to the API. >> Either undo the API changes or update API.txt and increment the major version >> in VERSION. >> make: *** [version-update] Error 1 >> >> Martin > Update patch version attached. I regenerated API.txt and incremented > IPA_API_VERSION_MINOR to 45. > > Tomas ACK. We will just need to rebase it when the patch is about to be pushed (when work on 3.2 starts). Martin From mkosek at redhat.com Wed Nov 14 11:22:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 12:22:09 +0100 Subject: [Freeipa-devel] [PATCH] Fixed the catch of the hostname option during ipa-server-install In-Reply-To: <985567129.139743.1352828239094.JavaMail.root@redhat.com> References: <985567129.139743.1352828239094.JavaMail.root@redhat.com> Message-ID: <50A37EE1.4040605@redhat.com> On 11/13/2012 06:37 PM, Lynn Root wrote: > Er, correctly formatted patch :D (I hope) > > Lynn Root > Associate Software Engineer > Red Hat > > ------------------------------------------------------------------------------- > > Hi all - > > Originally ipa-server-install would still prompt for the hostname even if > it's supplied in the initial installation command. > > Ticket: https://fedorahosted.org/freeipa/ticket/2692 > > > Lynn Root > Associate Software Engineer > Red Hat > Yup, formatting is ok :-) ACK for the patch, works fine. Though we may wait with pushing it until we start 3.2. Martin From rcritten at redhat.com Wed Nov 14 13:41:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2012 08:41:57 -0500 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme In-Reply-To: <50A357ED.7@redhat.com> References: <50A357ED.7@redhat.com> Message-ID: <50A39FA5.2000907@redhat.com> Martin Kosek wrote: > Remove redundant pki-* package Requires and change PKI server theme > Requires to correct package name. > > https://fedorahosted.org/freeipa/ticket/3213 > > --- > > The patch fixes broken Requires with the new server theme package name (thanks > Ade for help): > > # rpm -q pki-ca > pki-ca-10.0.0-0.52.b3.fc18.noarch > # rpm -qa "*pki-*-theme" > dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch > > [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* > error: Failed dependencies: > dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 > > > This patch is intended for Fedora 18 only, of course. > > Martin > ACK From mkosek at redhat.com Wed Nov 14 16:05:35 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 17:05:35 +0100 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme In-Reply-To: <50A39FA5.2000907@redhat.com> References: <50A357ED.7@redhat.com> <50A39FA5.2000907@redhat.com> Message-ID: <50A3C14F.3010609@redhat.com> On 11/14/2012 02:41 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> Remove redundant pki-* package Requires and change PKI server theme >> Requires to correct package name. >> >> https://fedorahosted.org/freeipa/ticket/3213 >> >> --- >> >> The patch fixes broken Requires with the new server theme package name (thanks >> Ade for help): >> >> # rpm -q pki-ca >> pki-ca-10.0.0-0.52.b3.fc18.noarch >> # rpm -qa "*pki-*-theme" >> dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch >> >> [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* >> error: Failed dependencies: >> dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 >> >> >> This patch is intended for Fedora 18 only, of course. >> >> Martin >> > > ACK As discussed on IRC, I made the Requires conditional for Fedora 18 only so that we do not break environment for people still developing on Fedora 17 (like me). I also took the opportunity to do some clean ups of compatibility code for old Fedora 16 and older. Details are in the patch description. When/if this patch is accepted, Petr Viktorin's patch 0098 should go in too as we now require the affected pki-ca version on Fedora 18. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-334-2-prepare-spec-file-for-fedora-18.patch Type: text/x-patch Size: 14417 bytes Desc: not available URL: From mkosek at redhat.com Wed Nov 14 16:16:26 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Nov 2012 17:16:26 +0100 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme In-Reply-To: <50A3C14F.3010609@redhat.com> References: <50A357ED.7@redhat.com> <50A39FA5.2000907@redhat.com> <50A3C14F.3010609@redhat.com> Message-ID: <50A3C3DA.7040101@redhat.com> On 11/14/2012 05:05 PM, Martin Kosek wrote: > On 11/14/2012 02:41 PM, Rob Crittenden wrote: >> Martin Kosek wrote: >>> Remove redundant pki-* package Requires and change PKI server theme >>> Requires to correct package name. >>> >>> https://fedorahosted.org/freeipa/ticket/3213 >>> >>> --- >>> >>> The patch fixes broken Requires with the new server theme package name (thanks >>> Ade for help): >>> >>> # rpm -q pki-ca >>> pki-ca-10.0.0-0.52.b3.fc18.noarch >>> # rpm -qa "*pki-*-theme" >>> dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch >>> >>> [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* >>> error: Failed dependencies: >>> dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 >>> >>> >>> This patch is intended for Fedora 18 only, of course. >>> >>> Martin >>> >> >> ACK > > As discussed on IRC, I made the Requires conditional for Fedora 18 only so that > we do not break environment for people still developing on Fedora 17 (like me). > > I also took the opportunity to do some clean ups of compatibility code for old > Fedora 16 and older. Details are in the patch description. > > When/if this patch is accepted, Petr Viktorin's patch 0098 should go in too as > we now require the affected pki-ca version on Fedora 18. > > Martin > Since we are now touching tar, I also added it to BuildRequires. I think it bit me once when I built FreeIPA on some super-minimal Fedora compose. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-334-3-prepare-spec-file-for-fedora-18.patch Type: text/x-patch Size: 14517 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 14 17:02:43 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 14 Nov 2012 18:02:43 +0100 Subject: [Freeipa-devel] [PATCH 0091] Harden dn_to_text() conversion Message-ID: <50A3CEB3.7040905@redhat.com> Hello, Harden dn_to_text() conversion. All cases covered by new checks will silently cause errors in other parts of plugin. This code should catch problematic inputs and stop processing at the beginning. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0091-Harden-dn_to_text-conversion.patch Type: text/x-patch Size: 2482 bytes Desc: not available URL: From sbose at redhat.com Wed Nov 14 17:26:16 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 14 Nov 2012 18:26:16 +0100 Subject: [Freeipa-devel] [PATCH] Lookup the user SID in external group as well Message-ID: <20121114172616.GS24620@localhost.localdomain> Hi, Jakub found that currently only group SIDs are used to find group memberships of users from trusted domain. The attached patch adds the user SID as well. Fixes https://fedorahosted.org/freeipa/ticket/3257 . bye, Sumit -------------- next part -------------- From 9525242dc9912a62b89dc65633917ab660df1704 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 14 Nov 2012 14:22:15 +0100 Subject: [PATCH] Lookup the user SID in external group as well Currently only the group SIDs from a PAC are used to find out about the membership in local groups. This patch adds the user SID to the list. Fixes https://fedorahosted.org/freeipa/ticket/3257 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 19 ++++++++++++++----- 1 Datei ge?ndert, 14 Zeilen hinzugef?gt(+), 5 Zeilen entfernt(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 881a7a7124b3f6651c44bc393b6899d093f8dfc6..072dd0db8ee0a214ad062282e9459941022535e5 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -660,9 +660,9 @@ static char *gen_sid_string(TALLOC_CTX *memctx, struct dom_sid *dom_sid, return str; } -static int get_group_sids(TALLOC_CTX *memctx, - struct PAC_LOGON_INFO_CTR *logon_info, - char ***_group_sids) +static int get_user_and_group_sids(TALLOC_CTX *memctx, + struct PAC_LOGON_INFO_CTR *logon_info, + char ***_group_sids) { int ret; size_t c; @@ -678,7 +678,7 @@ static int get_group_sids(TALLOC_CTX *memctx, } group_sids = talloc_array(memctx, char *, - 2 + + 3 + logon_info->info->info3.base.groups.count + logon_info->info->info3.sidcount); if (group_sids == NULL) { @@ -688,6 +688,15 @@ static int get_group_sids(TALLOC_CTX *memctx, } group_sids[p] = gen_sid_string(memctx, domain_sid, + logon_info->info->info3.base.rid); + if (group_sids[p] == NULL) { + krb5_klog_syslog(LOG_ERR, "gen_sid_string failed"); + ret = EINVAL; + goto done; + } + p++; + + group_sids[p] = gen_sid_string(memctx, domain_sid, logon_info->info->info3.base.primary_gid); if (group_sids[p] == NULL) { krb5_klog_syslog(LOG_ERR, "gen_sid_string failed"); @@ -931,7 +940,7 @@ static krb5_error_code add_local_groups(krb5_context context, size_t ipa_group_sids_count = 0; struct dom_sid *ipa_group_sids = NULL; - ret = get_group_sids(memctx, info, &group_sids); + ret = get_user_and_group_sids(memctx, info, &group_sids); if (ret != 0) { return KRB5_KDB_INTERNAL_ERROR; } -- 1.7.11.4 From simo at redhat.com Wed Nov 14 17:40:39 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 12:40:39 -0500 Subject: [Freeipa-devel] [PATCH] Lookup the user SID in external group as well In-Reply-To: <20121114172616.GS24620@localhost.localdomain> References: <20121114172616.GS24620@localhost.localdomain> Message-ID: <1352914839.10327.667.camel@willson.li.ssimo.org> On Wed, 2012-11-14 at 18:26 +0100, Sumit Bose wrote: > Hi, > > Jakub found that currently only group SIDs are used to find group > memberships of users from trusted domain. The attached patch adds the > user SID as well. > > Fixes https://fedorahosted.org/freeipa/ticket/3257 . > ack Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Wed Nov 14 18:04:33 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 14 Nov 2012 19:04:33 +0100 Subject: [Freeipa-devel] [PATCH] 226 Better error message for login of users from other realms Message-ID: <50A3DD31.60007@redhat.com> This is Web UI part of #3252 which depends on tbabej's python part which will be send by tbabej later. When user from other realm than FreeIPA's tries to use Web UI (login via forms-based auth or with valid trusted realm ticket), he gets an unauthorized error with X-Ipa-Rejection-Reason=invalid-realm. Web UI responds with showing login dialog with following error message: 'Invalid realm: Login for users from other realms is not supported.'. Note: such users are not supported because they don't have a corresponding entry in LDAP which is needed for ACLs. https://fedorahosted.org/freeipa/ticket/3252 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0226-Better-error-message-for-login-of-users-from-other-r.patch Type: text/x-patch Size: 5458 bytes Desc: not available URL: From simo at redhat.com Wed Nov 14 18:15:57 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 13:15:57 -0500 Subject: [Freeipa-devel] [PATCH] 226 Better error message for login of users from other realms In-Reply-To: <50A3DD31.60007@redhat.com> References: <50A3DD31.60007@redhat.com> Message-ID: <1352916957.10327.670.camel@willson.li.ssimo.org> On Wed, 2012-11-14 at 19:04 +0100, Petr Vobornik wrote: > This is Web UI part of #3252 which depends on tbabej's python part which > will be send by tbabej later. > > When user from other realm than FreeIPA's tries to use Web UI (login via > forms-based auth or with valid trusted realm ticket), he gets an > unauthorized error with X-Ipa-Rejection-Reason=invalid-realm. Web UI > responds with showing login dialog with following error message: > 'Invalid realm: Login for users from other realms is not supported.'. > > Note: such users are not supported because they don't have a > corresponding entry in LDAP which is needed for ACLs. > > https://fedorahosted.org/freeipa/ticket/3252 I am not sure how you can tell the difference between invalid credentials being returned due to the realm being invalid or because later on we decided to allow only a subset of user from a realm and so the real m is valid but the user just do not have access. I would be more generic and return something like X-Ipa-Rehjection-Reason=denied and issue a generic message: "sorry you are not allowed to access this service" or similar. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Nov 14 22:36:55 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Nov 2012 17:36:55 -0500 Subject: [Freeipa-devel] cert-find design Message-ID: <50A41D07.2040303@redhat.com> There is currently no way to search for a certificate. You can only look it up if you already know the serial number. Dogtag 10 has a fresh API which makes searching very easy. I've started designing a search interface here: http://freeipa.org/page/Cert_find Comments welcome. I was able to create a proof-of-concept (minus date options) using this API in about 90 minutes. rob From simo at redhat.com Thu Nov 15 01:25:30 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Nov 2012 20:25:30 -0500 Subject: [Freeipa-devel] cert-find design In-Reply-To: <50A41D07.2040303@redhat.com> References: <50A41D07.2040303@redhat.com> Message-ID: <1352942730.10327.713.camel@willson.li.ssimo.org> On Wed, 2012-11-14 at 17:36 -0500, Rob Crittenden wrote: > There is currently no way to search for a certificate. You can only look > it up if you already know the serial number. > > Dogtag 10 has a fresh API which makes searching very easy. I've started > designing a search interface here: http://freeipa.org/page/Cert_find > > Comments welcome. CAn you move it under V3/ that's where we agreed to put new designs for the v3 series > I was able to create a proof-of-concept (minus date options) using this > API in about 90 minutes. Great! Question, how is authentication done ? Or is this all public information that can be freely obtained anonymously ? Or will we provide access control in the IPA API and let the dogtag REST interface be available only on localhost ? Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Thu Nov 15 10:01:49 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Nov 2012 11:01:49 +0100 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme In-Reply-To: <50A3C3DA.7040101@redhat.com> References: <50A357ED.7@redhat.com> <50A39FA5.2000907@redhat.com> <50A3C14F.3010609@redhat.com> <50A3C3DA.7040101@redhat.com> Message-ID: <50A4BD8D.7070609@redhat.com> On 11/14/2012 05:16 PM, Martin Kosek wrote: > On 11/14/2012 05:05 PM, Martin Kosek wrote: >> On 11/14/2012 02:41 PM, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> Remove redundant pki-* package Requires and change PKI server theme >>>> Requires to correct package name. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3213 >>>> >>>> --- >>>> >>>> The patch fixes broken Requires with the new server theme package name (thanks >>>> Ade for help): >>>> >>>> # rpm -q pki-ca >>>> pki-ca-10.0.0-0.52.b3.fc18.noarch >>>> # rpm -qa "*pki-*-theme" >>>> dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch >>>> >>>> [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* >>>> error: Failed dependencies: >>>> dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 >>>> >>>> >>>> This patch is intended for Fedora 18 only, of course. >>>> >>>> Martin >>>> >>> >>> ACK >> >> As discussed on IRC, I made the Requires conditional for Fedora 18 only so that >> we do not break environment for people still developing on Fedora 17 (like me). >> >> I also took the opportunity to do some clean ups of compatibility code for old >> Fedora 16 and older. Details are in the patch description. >> >> When/if this patch is accepted, Petr Viktorin's patch 0098 should go in too as >> we now require the affected pki-ca version on Fedora 18. >> >> Martin >> > > Since we are now touching tar, I also added it to BuildRequires. I think it bit > me once when I built FreeIPA on some super-minimal Fedora compose. That should not be necessary, see https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 I assume the thing that bit you was grepping the .spec.in for the BuildRequires, but that shouldn't be a reason to change our spec. -- Petr? From tbabej at redhat.com Thu Nov 15 10:54:17 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Nov 2012 11:54:17 +0100 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms Message-ID: <50A4C9D9.8020107@redhat.com> Hi, This is server part of #3252. When user from other realm than FreeIPA's tries to use Web UI (login via forms-based auth or with valid trusted realm ticket), the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied is returned. Also, the support for usernames of the form user at SERVER.REALM or user at server.realm was added. https://fedorahosted.org/freeipa/ticket/3252 Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0023-Add-detection-for-users-from-trusted-invalid-realms.patch Type: text/x-patch Size: 2764 bytes Desc: not available URL: From mkosek at redhat.com Thu Nov 15 11:04:58 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Nov 2012 12:04:58 +0100 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme In-Reply-To: <50A4BD8D.7070609@redhat.com> References: <50A357ED.7@redhat.com> <50A39FA5.2000907@redhat.com> <50A3C14F.3010609@redhat.com> <50A3C3DA.7040101@redhat.com> <50A4BD8D.7070609@redhat.com> Message-ID: <50A4CC5A.7050004@redhat.com> On 11/15/2012 11:01 AM, Petr Viktorin wrote: > On 11/14/2012 05:16 PM, Martin Kosek wrote: >> On 11/14/2012 05:05 PM, Martin Kosek wrote: >>> On 11/14/2012 02:41 PM, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> Remove redundant pki-* package Requires and change PKI server theme >>>>> Requires to correct package name. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3213 >>>>> >>>>> --- >>>>> >>>>> The patch fixes broken Requires with the new server theme package name >>>>> (thanks >>>>> Ade for help): >>>>> >>>>> # rpm -q pki-ca >>>>> pki-ca-10.0.0-0.52.b3.fc18.noarch >>>>> # rpm -qa "*pki-*-theme" >>>>> dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch >>>>> >>>>> [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* >>>>> error: Failed dependencies: >>>>> dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 >>>>> >>>>> >>>>> This patch is intended for Fedora 18 only, of course. >>>>> >>>>> Martin >>>>> >>>> >>>> ACK >>> >>> As discussed on IRC, I made the Requires conditional for Fedora 18 only so that >>> we do not break environment for people still developing on Fedora 17 (like me). >>> >>> I also took the opportunity to do some clean ups of compatibility code for old >>> Fedora 16 and older. Details are in the patch description. >>> >>> When/if this patch is accepted, Petr Viktorin's patch 0098 should go in too as >>> we now require the affected pki-ca version on Fedora 18. >>> >>> Martin >>> >> >> Since we are now touching tar, I also added it to BuildRequires. I think it bit >> me once when I built FreeIPA on some super-minimal Fedora compose. > > That should not be necessary, see > https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 > > I assume the thing that bit you was grepping the .spec.in for the > BuildRequires, but that shouldn't be a reason to change our spec. > You are right, this is exactly what I did. Attaching a previous version of the patch, without BuildRequires tar. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-334-4-prepare-spec-file-for-fedora-18.patch Type: text/x-patch Size: 14417 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 15 11:28:23 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Nov 2012 12:28:23 +0100 Subject: [Freeipa-devel] [PATCH] 226 Better error message for login of users from other realms In-Reply-To: <1352916957.10327.670.camel@willson.li.ssimo.org> References: <50A3DD31.60007@redhat.com> <1352916957.10327.670.camel@willson.li.ssimo.org> Message-ID: <50A4D1D7.7040101@redhat.com> On 11/14/2012 07:15 PM, Simo Sorce wrote: > On Wed, 2012-11-14 at 19:04 +0100, Petr Vobornik wrote: >> This is Web UI part of #3252 which depends on tbabej's python part which >> will be send by tbabej later. >> >> When user from other realm than FreeIPA's tries to use Web UI (login via >> forms-based auth or with valid trusted realm ticket), he gets an >> unauthorized error with X-Ipa-Rejection-Reason=invalid-realm. Web UI >> responds with showing login dialog with following error message: >> 'Invalid realm: Login for users from other realms is not supported.'. >> >> Note: such users are not supported because they don't have a >> corresponding entry in LDAP which is needed for ACLs. >> >> https://fedorahosted.org/freeipa/ticket/3252 > > I am not sure how you can tell the difference between invalid > credentials being returned due to the realm being invalid or because > later on we decided to allow only a subset of user from a realm and so > the real m is valid but the user just do not have access. > > I would be more generic and return something like > X-Ipa-Rehjection-Reason=denied and issue a generic message: "sorry you > are not allowed to access this service" or similar. > > Simo. > Changed. Updated patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0226-1-Better-error-message-for-login-of-users-from-other-r.patch Type: text/x-patch Size: 5271 bytes Desc: not available URL: From mkosek at redhat.com Thu Nov 15 11:34:53 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Nov 2012 12:34:53 +0100 Subject: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting time&date services Message-ID: <50A4D35D.6070304@redhat.com> Fedora 16 introduced chrony as default client time&date synchronization service: http://fedoraproject.org/wiki/Features/ChronyDefaultNTP Thus, there may be people already using chrony as their time and date synchronization service before installing IPA. However, installing IPA server or client on such machine may lead to unexpected behavior, as the IPA installer would configure ntpd and leave the machine with both ntpd and chronyd enabled. However, since the OS does not allow both chronyd and ntpd to be running concurrently and chronyd has the precedence, ntpd would not be run on that system at all. Make sure, that user is warned when trying to install IPA on such system and is given a possibility to either not to let IPA configure ntpd at all or to let the installer stop and disable chronyd. https://fedorahosted.org/freeipa/ticket/2974 -- Martin Kosek Senior Software Engineer - Identity Management Team Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-335-stop-and-disable-conflicting-time-date-services.patch Type: text/x-patch Size: 15763 bytes Desc: not available URL: From pvoborni at redhat.com Thu Nov 15 11:41:40 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Nov 2012 12:41:40 +0100 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms In-Reply-To: <50A4C9D9.8020107@redhat.com> References: <50A4C9D9.8020107@redhat.com> Message-ID: <50A4D4F4.8020806@redhat.com> On 11/15/2012 11:54 AM, Tomas Babej wrote: > Hi, > > This is server part of #3252. > > When user from other realm than FreeIPA's tries to use Web UI > (login via forms-based auth or with valid trusted realm ticket), > the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied > is returned. > > Also, the support for usernames of the form user at SERVER.REALM > or user at server.realm was added. > > https://fedorahosted.org/freeipa/ticket/3252 > > Tomas > > + # allows login in the form user at SERVER_REALM or FIXME:user at server_realm The comment may not be clear for other people. I would be more verbose about the FIXME. > + parts = user.split("@") > + if len(parts) > 1: > + if parts[1].upper()==self.api.env.realm: I don't think we wanted to do this hard-check of realm. Personally I'am not against it because it's better to fail at login than at subsequent command (which will happen). Anyway it should be commented. > + user=parts[0] > + else: > + return self.unauthorized(environ, start_response, '', 'denied') -- Petr Vobornik From pviktori at redhat.com Thu Nov 15 12:09:16 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Nov 2012 13:09:16 +0100 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme In-Reply-To: <50A4CC5A.7050004@redhat.com> References: <50A357ED.7@redhat.com> <50A39FA5.2000907@redhat.com> <50A3C14F.3010609@redhat.com> <50A3C3DA.7040101@redhat.com> <50A4BD8D.7070609@redhat.com> <50A4CC5A.7050004@redhat.com> Message-ID: <50A4DB6C.7040701@redhat.com> On 11/15/2012 12:04 PM, Martin Kosek wrote: > On 11/15/2012 11:01 AM, Petr Viktorin wrote: >> On 11/14/2012 05:16 PM, Martin Kosek wrote: >>> On 11/14/2012 05:05 PM, Martin Kosek wrote: >>>> On 11/14/2012 02:41 PM, Rob Crittenden wrote: >>>>> Martin Kosek wrote: >>>>>> Remove redundant pki-* package Requires and change PKI server theme >>>>>> Requires to correct package name. >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3213 >>>>>> >>>>>> --- >>>>>> >>>>>> The patch fixes broken Requires with the new server theme package name >>>>>> (thanks >>>>>> Ade for help): >>>>>> >>>>>> # rpm -q pki-ca >>>>>> pki-ca-10.0.0-0.52.b3.fc18.noarch >>>>>> # rpm -qa "*pki-*-theme" >>>>>> dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch >>>>>> >>>>>> [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* >>>>>> error: Failed dependencies: >>>>>> dogtag-pki-common-theme is needed by freeipa-server-3.0.1-1.fc18.x86_64 >>>>>> >>>>>> >>>>>> This patch is intended for Fedora 18 only, of course. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> ACK >>>> >>>> As discussed on IRC, I made the Requires conditional for Fedora 18 only so that >>>> we do not break environment for people still developing on Fedora 17 (like me). >>>> >>>> I also took the opportunity to do some clean ups of compatibility code for old >>>> Fedora 16 and older. Details are in the patch description. >>>> >>>> When/if this patch is accepted, Petr Viktorin's patch 0098 should go in too as >>>> we now require the affected pki-ca version on Fedora 18. >>>> >>>> Martin >>>> >>> >>> Since we are now touching tar, I also added it to BuildRequires. I think it bit >>> me once when I built FreeIPA on some super-minimal Fedora compose. >> >> That should not be necessary, see >> https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 >> >> I assume the thing that bit you was grepping the .spec.in for the >> BuildRequires, but that shouldn't be a reason to change our spec. >> > > You are right, this is exactly what I did. Attaching a previous version of the > patch, without BuildRequires tar. > > Martin > Please also mention removing tomcat6 for F18+ in the %changelog and commit message. Then, it's an ACK. -- Petr? From tbabej at redhat.com Thu Nov 15 12:24:26 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Nov 2012 13:24:26 +0100 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms In-Reply-To: <50A4D4F4.8020806@redhat.com> References: <50A4C9D9.8020107@redhat.com> <50A4D4F4.8020806@redhat.com> Message-ID: <50A4DEFA.2000805@redhat.com> On 11/15/2012 12:41 PM, Petr Vobornik wrote: > On 11/15/2012 11:54 AM, Tomas Babej wrote: >> Hi, >> >> This is server part of #3252. >> >> When user from other realm than FreeIPA's tries to use Web UI >> (login via forms-based auth or with valid trusted realm ticket), >> the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied >> is returned. >> >> Also, the support for usernames of the form user at SERVER.REALM >> or user at server.realm was added. >> >> https://fedorahosted.org/freeipa/ticket/3252 >> >> Tomas >> > >> + # allows login in the form user at SERVER_REALM or >> FIXME:user at server_realm > > The comment may not be clear for other people. I would be more verbose > about the FIXME. > >> + parts = user.split("@") >> + if len(parts) > 1: >> + if parts[1].upper()==self.api.env.realm: > > I don't think we wanted to do this hard-check of realm. Personally > I'am not against it because it's better to fail at login than at > subsequent command (which will happen). Anyway it should be commented. > >> + user=parts[0] >> + else: >> + return self.unauthorized(environ, start_response, >> '', 'denied') > I expanded the comments, please check if you find them appropriate now. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0023-2-Add-detection-for-users-from-trusted-invalid-realms.patch Type: text/x-patch Size: 3085 bytes Desc: not available URL: From mkosek at redhat.com Thu Nov 15 12:44:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Nov 2012 13:44:11 +0100 Subject: [Freeipa-devel] [PATCH] 334 Add requires for new dogtag10 and its server theme In-Reply-To: <50A4DB6C.7040701@redhat.com> References: <50A357ED.7@redhat.com> <50A39FA5.2000907@redhat.com> <50A3C14F.3010609@redhat.com> <50A3C3DA.7040101@redhat.com> <50A4BD8D.7070609@redhat.com> <50A4CC5A.7050004@redhat.com> <50A4DB6C.7040701@redhat.com> Message-ID: <50A4E39B.1020008@redhat.com> On 11/15/2012 01:09 PM, Petr Viktorin wrote: > On 11/15/2012 12:04 PM, Martin Kosek wrote: >> On 11/15/2012 11:01 AM, Petr Viktorin wrote: >>> On 11/14/2012 05:16 PM, Martin Kosek wrote: >>>> On 11/14/2012 05:05 PM, Martin Kosek wrote: >>>>> On 11/14/2012 02:41 PM, Rob Crittenden wrote: >>>>>> Martin Kosek wrote: >>>>>>> Remove redundant pki-* package Requires and change PKI server theme >>>>>>> Requires to correct package name. >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3213 >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> The patch fixes broken Requires with the new server theme package name >>>>>>> (thanks >>>>>>> Ade for help): >>>>>>> >>>>>>> # rpm -q pki-ca >>>>>>> pki-ca-10.0.0-0.52.b3.fc18.noarch >>>>>>> # rpm -qa "*pki-*-theme" >>>>>>> dogtag-pki-server-theme-10.0.0-0.7.b3.fc18.noarch >>>>>>> >>>>>>> [root at vm-104 freeipa-3.0.1-1.fc18]# rpm -Uvh --force freeipa-* >>>>>>> error: Failed dependencies: >>>>>>> dogtag-pki-common-theme is needed by >>>>>>> freeipa-server-3.0.1-1.fc18.x86_64 >>>>>>> >>>>>>> >>>>>>> This patch is intended for Fedora 18 only, of course. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> ACK >>>>> >>>>> As discussed on IRC, I made the Requires conditional for Fedora 18 only so >>>>> that >>>>> we do not break environment for people still developing on Fedora 17 (like >>>>> me). >>>>> >>>>> I also took the opportunity to do some clean ups of compatibility code for >>>>> old >>>>> Fedora 16 and older. Details are in the patch description. >>>>> >>>>> When/if this patch is accepted, Petr Viktorin's patch 0098 should go in >>>>> too as >>>>> we now require the affected pki-ca version on Fedora 18. >>>>> >>>>> Martin >>>>> >>>> >>>> Since we are now touching tar, I also added it to BuildRequires. I think it >>>> bit >>>> me once when I built FreeIPA on some super-minimal Fedora compose. >>> >>> That should not be necessary, see >>> https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions_2 >>> >>> I assume the thing that bit you was grepping the .spec.in for the >>> BuildRequires, but that shouldn't be a reason to change our spec. >>> >> >> You are right, this is exactly what I did. Attaching a previous version of the >> patch, without BuildRequires tar. >> >> Martin >> > > Please also mention removing tomcat6 for F18+ in the %changelog and commit > message. Then, it's an ACK. > Fixed. Pushed to master, ipa-3-0 (with a small rebase). Martin From mkosek at redhat.com Thu Nov 15 12:45:09 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Nov 2012 13:45:09 +0100 Subject: [Freeipa-devel] [PATCH] 0098 Provide explicit user name for Dogtag installation scripts In-Reply-To: <50A359BE.6090001@redhat.com> References: <50A11646.4050403@redhat.com> <50A2C870.7000508@redhat.com> <50A359BE.6090001@redhat.com> Message-ID: <50A4E3D5.1090302@redhat.com> On 11/14/2012 09:43 AM, Petr Viktorin wrote: > On 11/13/2012 11:23 PM, Rob Crittenden wrote: >> Petr Viktorin wrote: >>> See commit message. >>> >>> Dogtag is changing its behavior soon (as in: tomorrow). This patch will >>> be needed for IPA to install on Fedora 18. >>> >>> >>> It would be nice if this went in our daily builds ASAP, so Dogtag people >>> can test. Sorry for the short notice, I originally misunderstood Ade and >>> included it in the merged database patches. >> >> I tested this with 3.0.1 in F-18 and it works as expected. I >> accidentally tested a mish-mash of this and saw how it would fail, so >> the patch is definitely needed. >> >> I've included the patch in the F-18 spec file only for now. Unless there >> is a need for us to push this upstream sooner. Do we also need to set >> the n-v-r of pki-core to the latest? > > This way, RPMs built straight from master won't work on F18, right? > In older DT versions these are the defaults so having the patch in won't hurt. > There's no need to change the spec for this patch. > > The spec problem Martin found is serious but unrelated. > Pushed to master, ipa-3-0. Martin From abokovoy at redhat.com Thu Nov 15 13:13:38 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 15 Nov 2012 15:13:38 +0200 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms In-Reply-To: <50A4DEFA.2000805@redhat.com> References: <50A4C9D9.8020107@redhat.com> <50A4D4F4.8020806@redhat.com> <50A4DEFA.2000805@redhat.com> Message-ID: <20121115131338.GC3321@redhat.com> On Thu, 15 Nov 2012, Tomas Babej wrote: >>From e08691492241399bbe41802b945df0b714e16c00 Mon Sep 17 00:00:00 2001 >From: Tomas Babej >Date: Thu, 15 Nov 2012 05:21:16 -0500 >Subject: [PATCH] Add detection for users from trusted/invalid realms > >When user from other realm than FreeIPA's tries to use Web UI >(login via forms-based auth or with valid trusted realm ticket), >the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied >is returned. > >Also, the support for usernames of the form user at SERVER.REALM >or user at server.realm was added. > >https://fedorahosted.org/freeipa/ticket/3252 >--- > ipaserver/plugins/ldap2.py | 2 ++ > ipaserver/rpcserver.py | 20 +++++++++++++++++++- > 2 files changed, 21 insertions(+), 1 deletion(-) > >diff --git a/ipaserver/plugins/ldap2.py b/ipaserver/plugins/ldap2.py >index bf1a0d3761b90cfa0784363aeaf40686e72c5d49..8e8e1604ff0a3d36fe3501ec6f54abdb717d78ae 100644 >--- a/ipaserver/plugins/ldap2.py >+++ b/ipaserver/plugins/ldap2.py >@@ -727,6 +727,8 @@ class ldap2(CrudBackend): > except _ldap.SERVER_DOWN: > raise NetworkError(uri=self.ldap_uri, > error=u'LDAP Server Down') >+ except _ldap.LOCAL_ERROR: >+ raise errors.ACIError(info=info) > except _ldap.SUCCESS: > pass > except _ldap.LDAPError, e: >diff --git a/ipaserver/rpcserver.py b/ipaserver/rpcserver.py >index 0856c25cef7904b3913b1666ddcf4965368f368a..d64e6514699c8679aa9e396c7b6b6256977a821f 100644 >--- a/ipaserver/rpcserver.py >+++ b/ipaserver/rpcserver.py >@@ -809,7 +809,11 @@ class jsonserver_session(jsonserver, KerberosSession): > # Store the session data in the per-thread context > setattr(context, 'session_data', session_data) > >- self.create_context(ccache=ipa_ccache_name) >+ # This may fail if a ticket from wrong realm was handled via browser >+ try: >+ self.create_context(ccache=ipa_ccache_name) >+ except ACIError, e: >+ return self.unauthorized(environ, start_response, str(e), 'denied') > > try: > response = super(jsonserver_session, self).__call__(environ, start_response) >@@ -927,6 +931,20 @@ class login_password(Backend, KerberosSession, HTTP_Status): > else: > return self.bad_request(environ, start_response, "no user specified") > >+ # allows login in the form user at SERVER_REALM or user at server_realm >+ # FIXME: uppercasing may be removed when better handling of UPN >+ # is introduced >+ parts = user.split("@") >+ if len(parts) > 1: >+ # check whether the realm is server's realm >+ # Users from other realms are not supported >+ # (because they do not have necessary LDAP entry, >+ # LDAP connect will fail) >+ if parts[1].upper()==self.api.env.realm: >+ user=parts[0] >+ else: >+ return self.unauthorized(environ, start_response, '', 'denied') >+ Can we also block NetBIOS\user logins? See ipaserver.dcerpc.DomainValidator's normalize_name() method, it handles both variants and returns a dict. You cannot use it unconditionally, though, since it is only available if freeipa-server-trust-ad package is installed. We can move this method to some common place since it does not require trusts per se and then re-use it in several places. -- / Alexander Bokovoy From simo at redhat.com Thu Nov 15 14:10:43 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2012 09:10:43 -0500 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms In-Reply-To: <50A4D4F4.8020806@redhat.com> References: <50A4C9D9.8020107@redhat.com> <50A4D4F4.8020806@redhat.com> Message-ID: <1352988643.10327.748.camel@willson.li.ssimo.org> On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote: > On 11/15/2012 11:54 AM, Tomas Babej wrote: > > Hi, > > > > This is server part of #3252. > > > > When user from other realm than FreeIPA's tries to use Web UI > > (login via forms-based auth or with valid trusted realm ticket), > > the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied > > is returned. > > > > Also, the support for usernames of the form user at SERVER.REALM > > or user at server.realm was added. > > > > https://fedorahosted.org/freeipa/ticket/3252 > > > > Tomas > > > > > + # allows login in the form user at SERVER_REALM or FIXME:user at server_realm > > The comment may not be clear for other people. I would be more verbose > about the FIXME. > > > + parts = user.split("@") > > + if len(parts) > 1: > > + if parts[1].upper()==self.api.env.realm: > > I don't think we wanted to do this hard-check of realm. Personally I'am > not against it because it's better to fail at login than at subsequent > command (which will happen). Anyway it should be commented. > > > + user=parts[0] > > + else: > > + return self.unauthorized(environ, start_response, '', 'denied') I think you should really fail only if you get failure connecting to LDAP. Because we can easily allow logins by providing a mapping object as part of SASL rules, we simply do not do it yet. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Nov 15 14:14:44 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Nov 2012 15:14:44 +0100 Subject: [Freeipa-devel] [PATCH] IPA tool scripts In-Reply-To: <50A209F2.8020206@redhat.com> References: <943042161.7794393.1352465011767.JavaMail.root@redhat.com> <509CFDE9.70002@redhat.com> <509D6EA5.8040403@redhat.com> <1352501565.10327.385.camel@willson.li.ssimo.org> <509D8CD1.6090401@redhat.com> <50A209F2.8020206@redhat.com> Message-ID: <50A4F8D4.9000004@redhat.com> On 11/13/2012 09:50 AM, Martin Kosek wrote: > On 11/10/2012 12:08 AM, Dmitri Pal wrote: >> On 11/09/2012 05:52 PM, Simo Sorce wrote: >>> On Fri, 2012-11-09 at 15:59 -0500, Dmitri Pal wrote: >>>> On 11/09/2012 07:58 AM, Petr Vobornik wrote: >>>>> On 11/09/2012 01:43 PM, Lynn Root wrote: >>>>>> The VERSION file and Makefile now handles 'beta' release parameters >>>>>> when making s/rpms. >>>>>> >>>>>> Ticket: https://fedorahosted.org/freeipa/ticket/2893 >>>>>> >>>>>> Lynn Root >>>>>> Associate Software Engineer >>>>>> Red Hat >>>>> Thanks for the patch. >>>>> >>>>> In a next patch, I'd suggest to follow patch-naming conventions >>>>> https://fedorahosted.org/freeipa/wiki/PatchFormat . Also include the >>>>> patch number into a mail subject, it helps to keeping track of patches. >>>>> >>>> OK, finally. It is a good time to ask. >>>> >>>> Several years ago when we adopted this format I was wondering what is >>>> the exact sequence of operations one should do to make the resulting >>>> patch follow the format. >>>> I never figured it out so I never adopted the format for the patches I >>>> provide for ding-libs from time to time. >>>> >>>> So in the title of the commit message I put (for example): >>>> [INI] Remove code that allows dup sections >>>> >>>> the I do git format-patch with arguments >>>> this translates into a patch with name >>>> 0001-INI-Remove-code-that-allows-dup-sections.patch >>>> >>>> So am I supposed to the manually rename the patch to follow the format >>>> or have a script to do that or there is some other way that I do not >>>> know about that would allow me to provide patches following the format >>>> above right out of the git format-patch so that I do not need to do the >>>> renaming? >>> This patch format rule is followed only on freeipa-devel for Freeipa >>> patches. >>> >>> Some people have developed scripts to do the renaming automatically. >>> >>> ding libs stuff is tracked on sssd-devel which does not use this patch >>> format rule, we enver felt it necessary in sssd development. >>> >>> Simo. >>> >> I understand. It was more a conceptual question. It looks like the >> answer "there are scripts to do renaming that each developer has". >> Thanks. This is all I was looking for. >> > > Right. I understand that it may be difficult to follow the patch naming rule > for new people in the project. But I personally like both numbering and naming > conventions as it helps me with locating patches when reviewing and with > referencing patch numbers in IRC conversations. > > The script is the most straightforward approach to choose For example when I am > submitting a patch, all I need to do is to run a script which will extract the > patch from git, name and number it correctly and opens me a Compose Email > window in my MUA with patch already attached and description taken from the > patch description. It can even upload the patch to Trac Ticket and switch > "patch sent for review" to 1. > > If people are interested in the script, I can upload it to some github repo and > we can link it then from our freeipa.org Contribute page. > > Martin > I managed to upload few scripts relevant to submitting patches to FreeIPA to github: https://github.com/mkosek/ipa-tools ... and added a link to this git tree also to relevant section in Contribute page on freeipa.org in case that anybody finds it useful. I plan to polish it a bit when I have some free time as it still has many rough edges. But so far, the script(s) served me well for almost 2 years now :-) Martin From pviktori at redhat.com Thu Nov 15 14:19:08 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Nov 2012 15:19:08 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A25FE6.6000009@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> Message-ID: <50A4F9DC.2000001@redhat.com> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag defaults made it to master independently (91e477b). Attaching rebased patch. Note that to continue development on f17, you will need to use the dogtag-devel repo: sudo yum-config-manager --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo On 11/13/2012 03:57 PM, Petr Viktorin wrote: [...] > > For convenience, I've also pushed the changes to a personal repository. > To fetch to branch "pviktori-dogtag-10" you can do: > > git fetch -f git://github.com/encukou/freeipa.git > dogtag-10:pviktori-dogtag-10 > -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-alee-0001-04-Changes-to-use-a-single-database-for-dogtag-and-IPA.patch Type: text/x-patch Size: 35738 bytes Desc: not available URL: From simo at redhat.com Thu Nov 15 14:22:23 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2012 09:22:23 -0500 Subject: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting time&date services In-Reply-To: <50A4D35D.6070304@redhat.com> References: <50A4D35D.6070304@redhat.com> Message-ID: <1352989343.10327.752.camel@willson.li.ssimo.org> On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: > Fedora 16 introduced chrony as default client time&date synchronization > service: > http://fedoraproject.org/wiki/Features/ChronyDefaultNTP > Thus, there may be people already using chrony as their time and date > synchronization service before installing IPA. > > However, installing IPA server or client on such machine may lead to > unexpected behavior, as the IPA installer would configure ntpd and leave > the machine with both ntpd and chronyd enabled. However, since the OS > does not allow both chronyd and ntpd to be running concurrently and chronyd > has the precedence, ntpd would not be run on that system at all. > > Make sure, that user is warned when trying to install IPA on such > system and is given a possibility to either not to let IPA configure > ntpd at all or to let the installer stop and disable chronyd. > > https://fedorahosted.org/freeipa/ticket/2974 This looks a bit backwards to me. The IPA server can only configure ntpd because it configures it to serve time to the clients. So on a server force_ntpd should be the default and the install should automatically shutdown crony. On clients we may give a choice, but then we should not stop, we should instead configure the one tool the admin wants to use and point it to the server, because time synchronization is critical. Not syncing time is basically not an option so our default behavior must be to make sure one of the time tool is properly configured and require a force flag if the admin wants to 'not' configure a time sync tool. Simo. -- Simo Sorce * Red Hat, Inc * New York From tbabej at redhat.com Thu Nov 15 14:51:21 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Nov 2012 15:51:21 +0100 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms In-Reply-To: <1352988643.10327.748.camel@willson.li.ssimo.org> References: <50A4C9D9.8020107@redhat.com> <50A4D4F4.8020806@redhat.com> <1352988643.10327.748.camel@willson.li.ssimo.org> Message-ID: <50A50169.9010908@redhat.com> On 11/15/2012 03:10 PM, Simo Sorce wrote: > On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote: >> On 11/15/2012 11:54 AM, Tomas Babej wrote: >>> Hi, >>> >>> This is server part of #3252. >>> >>> When user from other realm than FreeIPA's tries to use Web UI >>> (login via forms-based auth or with valid trusted realm ticket), >>> the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied >>> is returned. >>> >>> Also, the support for usernames of the form user at SERVER.REALM >>> or user at server.realm was added. >>> >>> https://fedorahosted.org/freeipa/ticket/3252 >>> >>> Tomas >>> >>> + # allows login in the form user at SERVER_REALM or FIXME:user at server_realm >> The comment may not be clear for other people. I would be more verbose >> about the FIXME. >> >>> + parts = user.split("@") >>> + if len(parts) > 1: >>> + if parts[1].upper()==self.api.env.realm: >> I don't think we wanted to do this hard-check of realm. Personally I'am >> not against it because it's better to fail at login than at subsequent >> command (which will happen). Anyway it should be commented. >> >>> + user=parts[0] >>> + else: >>> + return self.unauthorized(environ, start_response, '', 'denied') > I think you should really fail only if you get failure connecting to > LDAP. Because we can easily allow logins by providing a mapping object > as part of SASL rules, we simply do not do it yet. > > Simo. > Turns out if user from trusted realm logs in using WebUI form, he sucessfully obtaines ticket, however, a ccache is created with negative expiration time, because KRB5_CCache classes uses server's realm in its methods. Tomas realm From rcritten at redhat.com Thu Nov 15 14:54:25 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2012 09:54:25 -0500 Subject: [Freeipa-devel] cert-find design In-Reply-To: <1352942730.10327.713.camel@willson.li.ssimo.org> References: <50A41D07.2040303@redhat.com> <1352942730.10327.713.camel@willson.li.ssimo.org> Message-ID: <50A50221.2050502@redhat.com> Simo Sorce wrote: > On Wed, 2012-11-14 at 17:36 -0500, Rob Crittenden wrote: >> There is currently no way to search for a certificate. You can only look >> it up if you already know the serial number. >> >> Dogtag 10 has a fresh API which makes searching very easy. I've started >> designing a search interface here: http://freeipa.org/page/Cert_find >> >> Comments welcome. > > CAn you move it under V3/ that's where we agreed to put new designs for > the v3 series Fixed. > >> I was able to create a proof-of-concept (minus date options) using this >> API in about 90 minutes. > > Great! > > Question, how is authentication done ? > Or is this all public information that can be freely obtained > anonymously ? > Or will we provide access control in the IPA API and let the dogtag REST > interface be available only on localhost ? IMHO issued certificates are public, no point in adding a role/permissions to protect the search of them. The dogtag port is 8080 for this which I believe one doesn't need to open in the firewall, so only authenticated IPA users would have access. rob From simo at redhat.com Thu Nov 15 15:14:43 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2012 10:14:43 -0500 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms In-Reply-To: <50A50169.9010908@redhat.com> References: <50A4C9D9.8020107@redhat.com> <50A4D4F4.8020806@redhat.com> <1352988643.10327.748.camel@willson.li.ssimo.org> <50A50169.9010908@redhat.com> Message-ID: <1352992483.10327.756.camel@willson.li.ssimo.org> On Thu, 2012-11-15 at 15:51 +0100, Tomas Babej wrote: > On 11/15/2012 03:10 PM, Simo Sorce wrote: > > On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote: > >> On 11/15/2012 11:54 AM, Tomas Babej wrote: > >>> Hi, > >>> > >>> This is server part of #3252. > >>> > >>> When user from other realm than FreeIPA's tries to use Web UI > >>> (login via forms-based auth or with valid trusted realm ticket), > >>> the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied > >>> is returned. > >>> > >>> Also, the support for usernames of the form user at SERVER.REALM > >>> or user at server.realm was added. > >>> > >>> https://fedorahosted.org/freeipa/ticket/3252 > >>> > >>> Tomas > >>> > >>> + # allows login in the form user at SERVER_REALM or FIXME:user at server_realm > >> The comment may not be clear for other people. I would be more verbose > >> about the FIXME. > >> > >>> + parts = user.split("@") > >>> + if len(parts) > 1: > >>> + if parts[1].upper()==self.api.env.realm: > >> I don't think we wanted to do this hard-check of realm. Personally I'am > >> not against it because it's better to fail at login than at subsequent > >> command (which will happen). Anyway it should be commented. > >> > >>> + user=parts[0] > >>> + else: > >>> + return self.unauthorized(environ, start_response, '', 'denied') > > I think you should really fail only if you get failure connecting to > > LDAP. Because we can easily allow logins by providing a mapping object > > as part of SASL rules, we simply do not do it yet. > > > > Simo. > > > Turns out if user from trusted realm logs in using WebUI form, > he sucessfully obtaines ticket, however, a ccache is created with > negative expiration time, because KRB5_CCache classes > uses server's realm in its methods. Uh odd. Well if the problem is deep there, then please open a ticket to fix that probelm and let's move on with your current solution. But we need either a ticket or a note somewhere (or maybe even just FIXMEs in your code comments) to make sure we improve this code later to check via LDAP so we do not hit a wall if/when we decide to allow trusted users to log into the ui. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Nov 15 15:16:38 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2012 10:16:38 -0500 Subject: [Freeipa-devel] cert-find design In-Reply-To: <50A50221.2050502@redhat.com> References: <50A41D07.2040303@redhat.com> <1352942730.10327.713.camel@willson.li.ssimo.org> <50A50221.2050502@redhat.com> Message-ID: <1352992598.10327.758.camel@willson.li.ssimo.org> On Thu, 2012-11-15 at 09:54 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2012-11-14 at 17:36 -0500, Rob Crittenden wrote: > >> There is currently no way to search for a certificate. You can only look > >> it up if you already know the serial number. > >> > >> Dogtag 10 has a fresh API which makes searching very easy. I've started > >> designing a search interface here: http://freeipa.org/page/Cert_find > >> > >> Comments welcome. > > > > CAn you move it under V3/ that's where we agreed to put new designs for > > the v3 series > > Fixed. > > > > >> I was able to create a proof-of-concept (minus date options) using this > >> API in about 90 minutes. > > > > Great! > > > > Question, how is authentication done ? > > Or is this all public information that can be freely obtained > > anonymously ? > > Or will we provide access control in the IPA API and let the dogtag REST > > interface be available only on localhost ? > > IMHO issued certificates are public, no point in adding a > role/permissions to protect the search of them. Well I bet some people will want that anyway :-) But we can defer closing down till we get RFEs for that. > The dogtag port is 8080 for this which I believe one doesn't need to > open in the firewall, so only authenticated IPA users would have access. ok, good to know Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Thu Nov 15 15:53:16 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2012 10:53:16 -0500 Subject: [Freeipa-devel] cert-find design In-Reply-To: <50A50221.2050502@redhat.com> References: <50A41D07.2040303@redhat.com> <1352942730.10327.713.camel@willson.li.ssimo.org> <50A50221.2050502@redhat.com> Message-ID: <1352994796.10327.760.camel@willson.li.ssimo.org> On Thu, 2012-11-15 at 09:54 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2012-11-14 at 17:36 -0500, Rob Crittenden wrote: > >> There is currently no way to search for a certificate. You can only look > >> it up if you already know the serial number. > >> > >> Dogtag 10 has a fresh API which makes searching very easy. I've started > >> designing a search interface here: http://freeipa.org/page/Cert_find > >> > >> Comments welcome. > > > > CAn you move it under V3/ that's where we agreed to put new designs for > > the v3 series > > Fixed. Thanks I removed the redirect too. The new link is: http://freeipa.org/page/V3/Cert_find Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Nov 15 16:09:25 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Nov 2012 17:09:25 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A4F9DC.2000001@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> Message-ID: <50A513B5.1040605@redhat.com> On 11/15/2012 03:19 PM, Petr Viktorin wrote: > Recently, the specfile changed (dce53e4) and the patch for changed Dogtag > defaults made it to master independently (91e477b). Attaching rebased patch. > > Note that to continue development on f17, you will need to use the dogtag-devel > repo: > sudo yum-config-manager > --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo > > > On 11/13/2012 03:57 PM, Petr Viktorin wrote: > [...] >> >> For convenience, I've also pushed the changes to a personal repository. >> To fetch to branch "pviktori-dogtag-10" you can do: >> >> git fetch -f git://github.com/encukou/freeipa.git >> dogtag-10:pviktori-dogtag-10 >> > I started reviewing the patches, and found the first thing that looks suspicious. I had IPA with 2 databases, then upgraded it to single-database IPA, the upgrade was OK. But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed because when I installed single-db IPA afterwards, I had 2 dirsrv instances running. Martin From mkosek at redhat.com Thu Nov 15 16:33:18 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Nov 2012 17:33:18 +0100 Subject: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting time&date services In-Reply-To: <1352989343.10327.752.camel@willson.li.ssimo.org> References: <50A4D35D.6070304@redhat.com> <1352989343.10327.752.camel@willson.li.ssimo.org> Message-ID: <50A5194E.80908@redhat.com> On 11/15/2012 03:22 PM, Simo Sorce wrote: > On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: >> Fedora 16 introduced chrony as default client time&date synchronization >> service: >> http://fedoraproject.org/wiki/Features/ChronyDefaultNTP >> Thus, there may be people already using chrony as their time and date >> synchronization service before installing IPA. >> >> However, installing IPA server or client on such machine may lead to >> unexpected behavior, as the IPA installer would configure ntpd and leave >> the machine with both ntpd and chronyd enabled. However, since the OS >> does not allow both chronyd and ntpd to be running concurrently and chronyd >> has the precedence, ntpd would not be run on that system at all. >> >> Make sure, that user is warned when trying to install IPA on such >> system and is given a possibility to either not to let IPA configure >> ntpd at all or to let the installer stop and disable chronyd. >> >> https://fedorahosted.org/freeipa/ticket/2974 > > This looks a bit backwards to me. > > The IPA server can only configure ntpd because it configures it to serve > time to the clients. So on a server force_ntpd should be the default and > the install should automatically shutdown crony. I considered that option too, but it simply just did not seem very "polite" to silently stop and disable chrony with some custom user time&date synchronization configuration that user may rely on. Telling user what's the problem and providing him with options what to do seemed more user friendly to me... > > On clients we may give a choice, but then we should not stop, we should > instead configure the one tool the admin wants to use and point it to > the server, because time synchronization is critical. Not syncing time > is basically not an option so our default behavior must be to make sure > one of the time tool is properly configured and require a force flag if > the admin wants to 'not' configure a time sync tool. > > Simo. > The force flag to not configure time sync tool is already there as --no-ntp. I already discussed this with Rob before, I was advised to rather stick with the ntpd only for the time being. Adding Rob to CC to comment on this one. Martin From pspacek at redhat.com Thu Nov 15 16:47:22 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 15 Nov 2012 17:47:22 +0100 Subject: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting time&date services In-Reply-To: <50A5194E.80908@redhat.com> References: <50A4D35D.6070304@redhat.com> <1352989343.10327.752.camel@willson.li.ssimo.org> <50A5194E.80908@redhat.com> Message-ID: <50A51C9A.6090709@redhat.com> On 11/15/2012 05:33 PM, Martin Kosek wrote: > On 11/15/2012 03:22 PM, Simo Sorce wrote: >> >On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: >>> >>Fedora 16 introduced chrony as default client time&date synchronization >>> >>service: >>> >>http://fedoraproject.org/wiki/Features/ChronyDefaultNTP >>> >>Thus, there may be people already using chrony as their time and date >>> >>synchronization service before installing IPA. >>> >> >>> >>However, installing IPA server or client on such machine may lead to >>> >>unexpected behavior, as the IPA installer would configure ntpd and leave >>> >>the machine with both ntpd and chronyd enabled. However, since the OS >>> >>does not allow both chronyd and ntpd to be running concurrently and chronyd >>> >>has the precedence, ntpd would not be run on that system at all. >>> >> >>> >>Make sure, that user is warned when trying to install IPA on such >>> >>system and is given a possibility to either not to let IPA configure >>> >>ntpd at all or to let the installer stop and disable chronyd. >>> >> >>> >>https://fedorahosted.org/freeipa/ticket/2974 >> > >> >This looks a bit backwards to me. >> > >> >The IPA server can only configure ntpd because it configures it to serve >> >time to the clients. So on a server force_ntpd should be the default and >> >the install should automatically shutdown crony. > I considered that option too, but it simply just did not seem very "polite" to > silently stop and disable chrony with some custom user time&date > synchronization configuration that user may rely on. > > Telling user what's the problem and providing him with options what to do > seemed more user friendly to me... +1 -- Petr^2 Spacek From pspacek at redhat.com Thu Nov 15 18:06:37 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 15 Nov 2012 19:06:37 +0100 Subject: [Freeipa-devel] [PATCH 92 WIP] Flush whole zone from cache during zone renaming/removal. Message-ID: <50A52F2D.3070402@redhat.com> Hello, attached patch is preliminary implementation of selective zone flush. Implementation is not so straight-forward as I want to see. Before discussing the patch itself - can we consider per-zone caches? In that case, we can simply deallocate whole per-zone RBT and we are done. Pros: * Potentially better concurrency, simpler code, much less corner cases. Cons: * We have to look into Zone register before searching the cache. * It can limit concurrency ... with many extra small zones? I'm not sure. ------------ Now we can dive into all the gory details of single-tree-cache implementation: Function discard_zone_from_cache() contains a long comment about potential problems, please send me your opinions. Functions dbg_* can be simply deleted after end of testing. I encountered some questions about locking: How I should lock these two locks properly? RWLOCK(&zr->rwlock, isc_rwlocktype_read); LOCK(&cache->mutex); AFAIK without some more intelligent algorithm or locking protocol it can simply deadlock if two threads attempt to get both locks in different order. For now I chosen isc_task_beginexclusive() way. Hopefully, zone flush should be rare operation so it can be enough. It raises another question: Is it possible for a thread to hold some lock during isc_task_beginexclusive()? I mean this situation: thread 1: lock(&cache->mutex) thread 1: store a pointer to the middle of the cache thread 2: isc_task_beginexclusive() thread 2: do something with cache thread 2: isc_task_endexclusive() thread 1: dereference stored pointer -> CRASH - thread 2 changed the data and pointer is invalid ... but thread 1 held the lock! I'm not really sure about this part of BIND. My guess: During "exclusive mode" all threads except single one (= thread which called isc_task_beginexclusive()) are blocked somewhere near dispatch() ... so they do nothing and thus they should not hold any lock. Is my guess correct? I looked into task.c and related code but I can't say "I understood!" :-( Now the funny part - RBT tree before and after per-zone flush. Expected behaviour when removing zone 'test.' ============================================= // cache tree before "test." zone removal . (empty node) 4.34.10.in-addr.arpa 89.4.34.10.in-addr.arpa brq.redhat.com pspacek.brq.redhat.com test.brq.redhat.com test e.test _kerberos.e.test _tcp.e.test (empty node) _kerberos._tcp.e.test _kerberos-master._tcp.e.test _kpasswd._tcp.e.test _ldap._tcp.e.test _udp.e.test (empty node) _kerberos._udp.e.test _kerberos-master._udp.e.test _kpasswd._udp.e.test _ntp._udp.e.test c182.e.test pspacek.e.test test.e.test rec.test sec.test sub.test ns.sub.test rec.sub.test // cache tree after 'test.' zone removal // zones 'e.test.', 'sub.test.' and 'sec.test.' are still present // record 'rec.test.' disappeared . (empty node) 4.34.10.in-addr.arpa 89.4.34.10.in-addr.arpa brq.redhat.com pspacek.brq.redhat.com test.brq.redhat.com test (empty node) e.test _kerberos.e.test _tcp.e.test (empty node) _kerberos._tcp.e.test _kerberos-master._tcp.e.test _kpasswd._tcp.e.test _ldap._tcp.e.test _udp.e.test (empty node) _kerberos._udp.e.test _kerberos-master._udp.e.test _kpasswd._udp.e.test _ntp._udp.e.test c182.e.test pspacek.e.test test.e.test sec.test sub.test ns.sub.test rec.sub.test -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0092-WIP-Flush-whole-zone-from-cache-during-zone-renaming.patch Type: text/x-patch Size: 10490 bytes Desc: not available URL: From pviktori at redhat.com Thu Nov 15 18:17:48 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 15 Nov 2012 19:17:48 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A513B5.1040605@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> Message-ID: <50A531CC.4080605@redhat.com> On 11/15/2012 05:09 PM, Martin Kosek wrote: > On 11/15/2012 03:19 PM, Petr Viktorin wrote: >> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >> defaults made it to master independently (91e477b). Attaching rebased patch. >> >> Note that to continue development on f17, you will need to use the dogtag-devel >> repo: >> sudo yum-config-manager >> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >> >> >> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >> [...] >>> >>> For convenience, I've also pushed the changes to a personal repository. >>> To fetch to branch "pviktori-dogtag-10" you can do: >>> >>> git fetch -f git://github.com/encukou/freeipa.git >>> dogtag-10:pviktori-dogtag-10 >>> >> > > I started reviewing the patches, and found the first thing that looks > suspicious. I had IPA with 2 databases, then upgraded it to single-database > IPA, the upgrade was OK. > > But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed because > when I installed single-db IPA afterwards, I had 2 dirsrv instances running. You're right. This is an uninstaller error already present in 2.2: https://fedorahosted.org/freeipa/ticket/3258 I'll start looking into it tomorrow, if nothing more important shows up. -- Petr? From tbabej at redhat.com Thu Nov 15 19:50:00 2012 From: tbabej at redhat.com (Tomas Babej) Date: Thu, 15 Nov 2012 20:50:00 +0100 Subject: [Freeipa-devel] [PATCH 0023] Add detection for users from trusted/invalid realms In-Reply-To: <1352992483.10327.756.camel@willson.li.ssimo.org> References: <50A4C9D9.8020107@redhat.com> <50A4D4F4.8020806@redhat.com> <1352988643.10327.748.camel@willson.li.ssimo.org> <50A50169.9010908@redhat.com> <1352992483.10327.756.camel@willson.li.ssimo.org> Message-ID: <50A54768.8020307@redhat.com> On 11/15/2012 04:14 PM, Simo Sorce wrote: > On Thu, 2012-11-15 at 15:51 +0100, Tomas Babej wrote: >> On 11/15/2012 03:10 PM, Simo Sorce wrote: >>> On Thu, 2012-11-15 at 12:41 +0100, Petr Vobornik wrote: >>>> On 11/15/2012 11:54 AM, Tomas Babej wrote: >>>>> Hi, >>>>> >>>>> This is server part of #3252. >>>>> >>>>> When user from other realm than FreeIPA's tries to use Web UI >>>>> (login via forms-based auth or with valid trusted realm ticket), >>>>> the 401 Unauthorized error with X-Ipa-Rejection-Reason=denied >>>>> is returned. >>>>> >>>>> Also, the support for usernames of the form user at SERVER.REALM >>>>> or user at server.realm was added. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3252 >>>>> >>>>> Tomas >>>>> >>>>> + # allows login in the form user at SERVER_REALM or FIXME:user at server_realm >>>> The comment may not be clear for other people. I would be more verbose >>>> about the FIXME. >>>> >>>>> + parts = user.split("@") >>>>> + if len(parts) > 1: >>>>> + if parts[1].upper()==self.api.env.realm: >>>> I don't think we wanted to do this hard-check of realm. Personally I'am >>>> not against it because it's better to fail at login than at subsequent >>>> command (which will happen). Anyway it should be commented. >>>> >>>>> + user=parts[0] >>>>> + else: >>>>> + return self.unauthorized(environ, start_response, '', 'denied') >>> I think you should really fail only if you get failure connecting to >>> LDAP. Because we can easily allow logins by providing a mapping object >>> as part of SASL rules, we simply do not do it yet. >>> >>> Simo. >>> >> Turns out if user from trusted realm logs in using WebUI form, >> he sucessfully obtaines ticket, however, a ccache is created with >> negative expiration time, because KRB5_CCache classes >> uses server's realm in its methods. > Uh odd. > Well if the problem is deep there, then please open a ticket to fix that > probelm and let's move on with your current solution. > > But we need either a ticket or a note somewhere (or maybe even just > FIXMEs in your code comments) to make sure we improve this code later to > check via LDAP so we do not hit a wall if/when we decide to allow > trusted users to log into the ui. > > Simo. The updated patch is attached. Please check if there are any other issues. I will open the tickets after further investigation. Tomas -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-tbabej-0023-3-Add-detection-for-users-from-trusted-invalid-realms.patch Type: text/x-patch Size: 6973 bytes Desc: not available URL: From simo at redhat.com Thu Nov 15 21:49:05 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 15 Nov 2012 16:49:05 -0500 Subject: [Freeipa-devel] [PATCH] 335 Stop and disable conflicting time&date services In-Reply-To: <50A5194E.80908@redhat.com> References: <50A4D35D.6070304@redhat.com> <1352989343.10327.752.camel@willson.li.ssimo.org> <50A5194E.80908@redhat.com> Message-ID: <1353016145.10327.766.camel@willson.li.ssimo.org> On Thu, 2012-11-15 at 17:33 +0100, Martin Kosek wrote: > On 11/15/2012 03:22 PM, Simo Sorce wrote: > > On Thu, 2012-11-15 at 12:34 +0100, Martin Kosek wrote: > >> Fedora 16 introduced chrony as default client time&date synchronization > >> service: > >> http://fedoraproject.org/wiki/Features/ChronyDefaultNTP > >> Thus, there may be people already using chrony as their time and date > >> synchronization service before installing IPA. > >> > >> However, installing IPA server or client on such machine may lead to > >> unexpected behavior, as the IPA installer would configure ntpd and leave > >> the machine with both ntpd and chronyd enabled. However, since the OS > >> does not allow both chronyd and ntpd to be running concurrently and chronyd > >> has the precedence, ntpd would not be run on that system at all. > >> > >> Make sure, that user is warned when trying to install IPA on such > >> system and is given a possibility to either not to let IPA configure > >> ntpd at all or to let the installer stop and disable chronyd. > >> > >> https://fedorahosted.org/freeipa/ticket/2974 > > > > This looks a bit backwards to me. > > > > The IPA server can only configure ntpd because it configures it to serve > > time to the clients. So on a server force_ntpd should be the default and > > the install should automatically shutdown crony. > > I considered that option too, but it simply just did not seem very "polite" to > silently stop and disable chrony with some custom user time&date > synchronization configuration that user may rely on. > > Telling user what's the problem and providing him with options what to do > seemed more user friendly to me... not on the server, no you don;t get to choose there, unless you call install script with --no-ntp > > > > On clients we may give a choice, but then we should not stop, we should > > instead configure the one tool the admin wants to use and point it to > > the server, because time synchronization is critical. Not syncing time > > is basically not an option so our default behavior must be to make sure > > one of the time tool is properly configured and require a force flag if > > the admin wants to 'not' configure a time sync tool. > > > > Simo. > > > > The force flag to not configure time sync tool is already there as --no-ntp. I > already discussed this with Rob before, I was advised to rather stick with the > ntpd only for the time being. Adding Rob to CC to comment on this one. Not sure I grok what this entails, support only ntpd ? In this case we can error out if crony is there on the client, but not on the server. On the server we just roll over crony, as crony is not an ntp server at all so it should go if the admin *really*insist in using crony then they'll have to explicitly install the server with --no-ntp note that we are not going to change crony;s configuration just turn it off and start ntpd instead. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Nov 16 04:53:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Nov 2012 23:53:44 -0500 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support Message-ID: <50A5C6D8.8030509@redhat.com> This patch enables transaction support in 389-ds-base and fixes a few transaction issues within IPA. This converts parts of the password and modrnd plugins to support transactions. The password plugin still largely runs as non-transactional because extop plugins aren't supported in transactions yet. I've left the wait_for_attr code in place for now but on reflection we should probably remove it. I'll leave that up to the reviewer, but I can't see the need for it any more. In order for this to work you'll need to apply the last two patches (both 0001) to slapi-nis and spin it up yourself, otherwise you'll have serious deadlock issues. I know this is extra work but this patch is potentially disruptive so I figure the earlier it is out the better. Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may have been too aggressive in my cleanup. Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? Once we have an official slapi-nis build with these patches we'll need to set the minimum n-v-r in our spec file. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1072-transaction.patch Type: text/x-patch Size: 28443 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-make-NIS-Plugin-and-Schema-Compatibility-Plugin-betx.patch Type: text/x-patch Size: 18934 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Code-cleanup.patch Type: text/x-patch Size: 4520 bytes Desc: not available URL: From mkosek at redhat.com Fri Nov 16 10:23:44 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Nov 2012 11:23:44 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A531CC.4080605@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> Message-ID: <50A61430.4030007@redhat.com> On 11/15/2012 07:17 PM, Petr Viktorin wrote: > On 11/15/2012 05:09 PM, Martin Kosek wrote: >> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>> defaults made it to master independently (91e477b). Attaching rebased patch. >>> >>> Note that to continue development on f17, you will need to use the dogtag-devel >>> repo: >>> sudo yum-config-manager >>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>> >>> >>> >>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>> [...] >>>> >>>> For convenience, I've also pushed the changes to a personal repository. >>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>> >>>> git fetch -f git://github.com/encukou/freeipa.git >>>> dogtag-10:pviktori-dogtag-10 >>>> >>> >> >> I started reviewing the patches, and found the first thing that looks >> suspicious. I had IPA with 2 databases, then upgraded it to single-database >> IPA, the upgrade was OK. >> >> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed because >> when I installed single-db IPA afterwards, I had 2 dirsrv instances running. > > You're right. This is an uninstaller error already present in 2.2: > https://fedorahosted.org/freeipa/ticket/3258 > > I'll start looking into it tomorrow, if nothing more important shows up. > Thanks for the pointer. But this is definitely not a show stopper, running additional DS instance seems more or less benign and as you pointed out, it is rather an old bug. There are bigger issues. Now I focused on ipa-replica-manage and ipa-csreplica-manage tools. ipa-replica-manage gets confused with the additional replication agreements in IPA dirsrv instance (although targeted to nsDS5ReplicaRoot: o=ipaca). First scenario: 3 IPA servers with CA in this topology: B - A - C On A: # ipa-replica-manage list `hostname` vm-055.idm.lab.bos.redhat.com: replica vm-070.idm.lab.bos.redhat.com: replica vm-055.idm.lab.bos.redhat.com: replica vm-070.idm.lab.bos.redhat.com: replica it should not display agreements that are for IPA only, not IPA CA ones. Now, when I try to connect B to C, ipa-replica-manage succeeded: [B] # ipa-replica-manage connect C Connected 'B' to 'C' This changed the topology to: A / \ B - C But ipa-csreplica-manage connect did not succeed then: [B] # ipa-csreplica-manage connect C Directory Manager password: This replication agreement already exists. Del command also failed for me: [A] ipa-replica-manage del [C] Still trying to investigate why. If I manage to get some workable fix during my investigations, I will attach it later. Martin From pspacek at redhat.com Fri Nov 16 12:31:11 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 16 Nov 2012 13:31:11 +0100 Subject: [Freeipa-devel] [PATCH 0093] Log memory allocation failures Message-ID: <50A6320F.8010102@redhat.com> Hello, this patch adds logging to error handling code around memory allocation. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0093-Log-memory-allocation-failures.patch Type: text/x-patch Size: 1711 bytes Desc: not available URL: From simo at redhat.com Fri Nov 16 13:24:34 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 16 Nov 2012 08:24:34 -0500 Subject: [Freeipa-devel] [PATCH 0093] Log memory allocation failures In-Reply-To: <50A6320F.8010102@redhat.com> References: <50A6320F.8010102@redhat.com> Message-ID: <1353072274.10327.785.camel@willson.li.ssimo.org> On Fri, 2012-11-16 at 13:31 +0100, Petr Spacek wrote: > +#define FILE_LINE_FUNC_MSG "%-15s: %4d: %-20s" > +#define FILE_LINE_FUNC_ARG __FILE__, __LINE__, __func__ Wouldn't it be more compact and less error prone to do something like: #define LOG_POSITION_MSG(str, ...) \ do { \ log_error("[%-15s: %4d: %-20s] " str, \ __FILE__, __LINE__, __func__, __VA_ARGS__); \ } while(0); > #define CLEANUP_WITH(result_code) \ > do { \ > result = (result_code); \ > @@ -46,15 +52,21 @@ > (target_ptr) = isc_mem_allocate((m), (s)); \ > if ((target_ptr) == NULL) { \ > result = ISC_R_NOMEMORY; \ > + log_error("MEMORY ALLOCATION FAILURE at > " \ > + FILE_LINE_FUNC_MSG, \ > + FILE_LINE_FUNC_ARG); \ and here simply: LOG_POSITION_MSG("MEMORY ALLOCATION FAILURE"); The _MSG seem misleading doesn't make you think it is a format string (maybe calling it _FMT would be better if you want to keep this split in pieces). The single form above let you write less and still do things like: LOG_POSITION_MSG("This failed with %d (%s)", ret, strerror(ret)); Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Nov 16 13:25:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Nov 2012 14:25:22 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A61430.4030007@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> Message-ID: <50A63EC2.3020006@redhat.com> On 11/16/2012 11:23 AM, Martin Kosek wrote: > On 11/15/2012 07:17 PM, Petr Viktorin wrote: >> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>>> defaults made it to master independently (91e477b). Attaching rebased patch. >>>> >>>> Note that to continue development on f17, you will need to use the >>>> dogtag-devel >>>> repo: >>>> sudo yum-config-manager >>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>> >>>> >>>> >>>> >>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>> [...] >>>>> >>>>> For convenience, I've also pushed the changes to a personal repository. >>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>> >>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>> dogtag-10:pviktori-dogtag-10 >>>>> >>>> >>> >>> I started reviewing the patches, and found the first thing that looks >>> suspicious. I had IPA with 2 databases, then upgraded it to single-database >>> IPA, the upgrade was OK. >>> >>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed because >>> when I installed single-db IPA afterwards, I had 2 dirsrv instances running. >> >> You're right. This is an uninstaller error already present in 2.2: >> https://fedorahosted.org/freeipa/ticket/3258 >> >> I'll start looking into it tomorrow, if nothing more important shows up. >> > > Thanks for the pointer. But this is definitely not a show stopper, running > additional DS instance seems more or less benign and as you pointed out, it is > rather an old bug. > > There are bigger issues. Now I focused on ipa-replica-manage and > ipa-csreplica-manage tools. ipa-replica-manage gets confused with the > additional replication agreements in IPA dirsrv instance (although targeted to > nsDS5ReplicaRoot: o=ipaca). > > First scenario: 3 IPA servers with CA in this topology: > > B - A - C > > On A: > # ipa-replica-manage list `hostname` > vm-055.idm.lab.bos.redhat.com: replica > vm-070.idm.lab.bos.redhat.com: replica > vm-055.idm.lab.bos.redhat.com: replica > vm-070.idm.lab.bos.redhat.com: replica > > it should not display agreements that are for IPA only, not IPA CA ones. > > Now, when I try to connect B to C, ipa-replica-manage succeeded: > [B] # ipa-replica-manage connect C > Connected 'B' to 'C' > > This changed the topology to: > A > / \ > B - C > > But ipa-csreplica-manage connect did not succeed then: > [B] # ipa-csreplica-manage connect C > Directory Manager password: > > This replication agreement already exists. > > Del command also failed for me: > [A] ipa-replica-manage del [C] > > Still trying to investigate why. If I manage to get some workable fix during my > investigations, I will attach it later. > > Martin The fix for that for easier than expected. Attached patch restored the previous functionality for ipa-(cs)replica-manage. I tried that with all basic commands - add, del, connect, disconnect and it worked fine so far. But this was a case with all D10 masters, I will need to try if that flies with D9->D10 replicas or upgraded D9 masters. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-336-filter-suffix-in-replication-management-tools.patch Type: text/x-patch Size: 4878 bytes Desc: not available URL: From pspacek at redhat.com Fri Nov 16 14:15:44 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 16 Nov 2012 15:15:44 +0100 Subject: [Freeipa-devel] [PATCH 0093] Log memory allocation failures In-Reply-To: <1353072274.10327.785.camel@willson.li.ssimo.org> References: <50A6320F.8010102@redhat.com> <1353072274.10327.785.camel@willson.li.ssimo.org> Message-ID: <50A64A90.7030100@redhat.com> On 11/16/2012 02:24 PM, Simo Sorce wrote: > On Fri, 2012-11-16 at 13:31 +0100, Petr Spacek wrote: >> +#define FILE_LINE_FUNC_MSG "%-15s: %4d: %-20s" >> +#define FILE_LINE_FUNC_ARG __FILE__, __LINE__, __func__ > > Wouldn't it be more compact and less error prone to do something like: > > #define LOG_POSITION_MSG(str, ...) \ > do { \ > log_error("[%-15s: %4d: %-20s] " str, \ > __FILE__, __LINE__, __func__, __VA_ARGS__); \ > } while(0); > >> #define CLEANUP_WITH(result_code) \ >> do { \ >> result = (result_code); \ >> @@ -46,15 +52,21 @@ >> (target_ptr) = isc_mem_allocate((m), (s)); \ >> if ((target_ptr) == NULL) { \ >> result = ISC_R_NOMEMORY; \ >> + log_error("MEMORY ALLOCATION FAILURE at >> " \ >> + FILE_LINE_FUNC_MSG, \ >> + FILE_LINE_FUNC_ARG); \ > > and here simply: > LOG_POSITION_MSG("MEMORY ALLOCATION FAILURE"); > > The _MSG seem misleading doesn't make you think it is a format string > (maybe calling it _FMT would be better if you want to keep this split in > pieces). > > The single form above let you write less and still do things like: > LOG_POSITION_MSG("This failed with %d (%s)", ret, strerror(ret)); Yes, it would. I split it to avoid dns_result_totext() duplication in my next patch ... I see this approach as better now. Amended patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0093-2-Log-memory-allocation-failures.patch Type: text/x-patch Size: 2426 bytes Desc: not available URL: From nalin at redhat.com Fri Nov 16 14:57:36 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Fri, 16 Nov 2012 09:57:36 -0500 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50A5C6D8.8030509@redhat.com> References: <50A5C6D8.8030509@redhat.com> Message-ID: <20121116145736.GA30716@redhat.com> On Thu, Nov 15, 2012 at 11:53:44PM -0500, Rob Crittenden wrote: > In order for this to work you'll need to apply the last two patches > (both 0001) to slapi-nis and spin it up yourself, otherwise you'll > have serious deadlock issues. I know this is extra work but this > patch is potentially disruptive so I figure the earlier it is out > the better. > > Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may > have been too aggressive in my cleanup. > > Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? > > Once we have an official slapi-nis build with these patches we'll > need to set the minimum n-v-r in our spec file. Rob, the original patch was already applied. I since reworked large parts of how it was organized to make it easier for me to read, and tagged the result as 0.43. Have you tested the IPA changes in combination with the 0.44 builds from either ipa-devel or Fedora 18's updates-testing repository? Nalin From mkosek at redhat.com Fri Nov 16 16:17:27 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Nov 2012 17:17:27 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A63EC2.3020006@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> Message-ID: <50A66717.1020701@redhat.com> On 11/16/2012 02:25 PM, Martin Kosek wrote: > On 11/16/2012 11:23 AM, Martin Kosek wrote: >> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>>>> defaults made it to master independently (91e477b). Attaching rebased patch. >>>>> >>>>> Note that to continue development on f17, you will need to use the >>>>> dogtag-devel >>>>> repo: >>>>> sudo yum-config-manager >>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>> [...] >>>>>> >>>>>> For convenience, I've also pushed the changes to a personal repository. >>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>> >>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>> dogtag-10:pviktori-dogtag-10 >>>>>> >>>>> >>>> >>>> I started reviewing the patches, and found the first thing that looks >>>> suspicious. I had IPA with 2 databases, then upgraded it to single-database >>>> IPA, the upgrade was OK. >>>> >>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed >>>> because >>>> when I installed single-db IPA afterwards, I had 2 dirsrv instances running. >>> >>> You're right. This is an uninstaller error already present in 2.2: >>> https://fedorahosted.org/freeipa/ticket/3258 >>> >>> I'll start looking into it tomorrow, if nothing more important shows up. >>> >> >> Thanks for the pointer. But this is definitely not a show stopper, running >> additional DS instance seems more or less benign and as you pointed out, it is >> rather an old bug. >> >> There are bigger issues. Now I focused on ipa-replica-manage and >> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >> additional replication agreements in IPA dirsrv instance (although targeted to >> nsDS5ReplicaRoot: o=ipaca). >> >> First scenario: 3 IPA servers with CA in this topology: >> >> B - A - C >> >> On A: >> # ipa-replica-manage list `hostname` >> vm-055.idm.lab.bos.redhat.com: replica >> vm-070.idm.lab.bos.redhat.com: replica >> vm-055.idm.lab.bos.redhat.com: replica >> vm-070.idm.lab.bos.redhat.com: replica >> >> it should not display agreements that are for IPA only, not IPA CA ones. >> >> Now, when I try to connect B to C, ipa-replica-manage succeeded: >> [B] # ipa-replica-manage connect C >> Connected 'B' to 'C' >> >> This changed the topology to: >> A >> / \ >> B - C >> >> But ipa-csreplica-manage connect did not succeed then: >> [B] # ipa-csreplica-manage connect C >> Directory Manager password: >> >> This replication agreement already exists. >> >> Del command also failed for me: >> [A] ipa-replica-manage del [C] >> >> Still trying to investigate why. If I manage to get some workable fix during my >> investigations, I will attach it later. >> >> Martin > > The fix for that for easier than expected. Attached patch restored the previous > functionality for ipa-(cs)replica-manage. I tried that with all basic commands > - add, del, connect, disconnect and it worked fine so far. > > But this was a case with all D10 masters, I will need to try if that flies with > D9->D10 replicas or upgraded D9 masters. > > Martin > I have issues creating a 3.1 replica for 3.0 master (D10) with split databases. I run the script, but now I always end with error during CA installation: # ipa-ca-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg Directory Manager (existing master) password: ... Execute check on remote master Check connection from master to remote replica 'vm-055.idm.lab.bos.redhat.com': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): WARNING Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): WARNING HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following UDP ports could not be verified as open: 88, 464 This can happen if they are already bound to an application and ipa-replica-conncheck cannot attach own UDP responder. Connection from master to replica is OK. Connection check OK Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/15]: creating certificate server user [2/15]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' Attaching relevant logs, this one looks suspicious: # tail /var/log/pki/pki-tomcat/ca/system 2016.localhost-startStop-1 - [16/Nov/2012:10:53:11 EST] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate 2016.localhost-startStop-1 - [16/Nov/2012:10:53:12 EST] [13] [3] authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value 2016.http-bio-8443-exec-1 - [16/Nov/2012:10:53:20 EST] [8] [3] In Ldap (bound) connection pool to host vm-104.idm.lab.bos.redhat.com port 7389, Cannot connect to LDAP server. Error: netscape.ldap.LDAPException: failed to connect to server ldap://vm-104.idm.lab.bos.redhat.com:7389 (91) But I am not sure what that means yet, that Directory Server instance is up, firewall is down. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: logs.tgz Type: application/x-compressed-tar Size: 45465 bytes Desc: not available URL: From rcritten at redhat.com Fri Nov 16 16:18:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 16 Nov 2012 11:18:18 -0500 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <20121116145736.GA30716@redhat.com> References: <50A5C6D8.8030509@redhat.com> <20121116145736.GA30716@redhat.com> Message-ID: <50A6674A.9020606@redhat.com> Nalin Dahyabhai wrote: > On Thu, Nov 15, 2012 at 11:53:44PM -0500, Rob Crittenden wrote: >> In order for this to work you'll need to apply the last two patches >> (both 0001) to slapi-nis and spin it up yourself, otherwise you'll >> have serious deadlock issues. I know this is extra work but this >> patch is potentially disruptive so I figure the earlier it is out >> the better. >> >> Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may >> have been too aggressive in my cleanup. >> >> Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? >> >> Once we have an official slapi-nis build with these patches we'll >> need to set the minimum n-v-r in our spec file. > > Rob, the original patch was already applied. I since reworked large > parts of how it was organized to make it easier for me to read, and > tagged the result as 0.43. Have you tested the IPA changes in > combination with the 0.44 builds from either ipa-devel or Fedora 18's > updates-testing repository? > > Nalin > I tested the 0.44 build and things are looking good. I'm not deadlocking, so I guess that's the desired out come :-) I bulk loaded a few thousand users and groups and tested the compat and NIS plugins and the data appears correct. Updated patch with minimum n-v-r in spec attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1072-2-transaction.patch Type: text/x-patch Size: 29469 bytes Desc: not available URL: From pviktori at redhat.com Fri Nov 16 17:46:44 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 16 Nov 2012 18:46:44 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A66717.1020701@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50A66717.1020701@redhat.com> Message-ID: <50A67C04.2050408@redhat.com> On 11/16/2012 05:17 PM, Martin Kosek wrote: > On 11/16/2012 02:25 PM, Martin Kosek wrote: >> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>> Recently, the specfile changed (dce53e4) and the patch for changed >>>>>> Dogtag >>>>>> defaults made it to master independently (91e477b). Attaching >>>>>> rebased patch. >>>>>> >>>>>> Note that to continue development on f17, you will need to use the >>>>>> dogtag-devel >>>>>> repo: >>>>>> sudo yum-config-manager >>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>> [...] >>>>>>> >>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>> repository. >>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>> >>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>> >>>>>> >>>>> >>>>> I started reviewing the patches, and found the first thing that looks >>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>> single-database >>>>> IPA, the upgrade was OK. >>>>> >>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>> removed >>>>> because >>>>> when I installed single-db IPA afterwards, I had 2 dirsrv instances >>>>> running. >>>> >>>> You're right. This is an uninstaller error already present in 2.2: >>>> https://fedorahosted.org/freeipa/ticket/3258 >>>> >>>> I'll start looking into it tomorrow, if nothing more important shows >>>> up. >>>> >>> >>> Thanks for the pointer. But this is definitely not a show stopper, >>> running >>> additional DS instance seems more or less benign and as you pointed >>> out, it is >>> rather an old bug. >>> >>> There are bigger issues. Now I focused on ipa-replica-manage and >>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>> additional replication agreements in IPA dirsrv instance (although >>> targeted to >>> nsDS5ReplicaRoot: o=ipaca). >>> >>> First scenario: 3 IPA servers with CA in this topology: >>> >>> B - A - C >>> >>> On A: >>> # ipa-replica-manage list `hostname` >>> vm-055.idm.lab.bos.redhat.com: replica >>> vm-070.idm.lab.bos.redhat.com: replica >>> vm-055.idm.lab.bos.redhat.com: replica >>> vm-070.idm.lab.bos.redhat.com: replica >>> >>> it should not display agreements that are for IPA only, not IPA CA ones. >>> >>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>> [B] # ipa-replica-manage connect C >>> Connected 'B' to 'C' >>> >>> This changed the topology to: >>> A >>> / \ >>> B - C >>> >>> But ipa-csreplica-manage connect did not succeed then: >>> [B] # ipa-csreplica-manage connect C >>> Directory Manager password: >>> >>> This replication agreement already exists. >>> >>> Del command also failed for me: >>> [A] ipa-replica-manage del [C] >>> >>> Still trying to investigate why. If I manage to get some workable fix >>> during my >>> investigations, I will attach it later. >>> >>> Martin >> >> The fix for that for easier than expected. Attached patch restored the >> previous >> functionality for ipa-(cs)replica-manage. I tried that with all basic >> commands >> - add, del, connect, disconnect and it worked fine so far. >> >> But this was a case with all D10 masters, I will need to try if that >> flies with >> D9->D10 replicas or upgraded D9 masters. >> >> Martin >> > > I have issues creating a 3.1 replica for 3.0 master (D10) with split > databases. I run the script, but now I always end with error during CA > installation: > [...] I couldn't reproduce this. Perhaps you installed the master or replica in a different way? What are the commands you used? -- Petr? From mkosek at redhat.com Fri Nov 16 17:54:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 16 Nov 2012 18:54:29 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A67C04.2050408@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50A66717.1020701@redhat.com> <50A67C04.2050408@redhat.com> Message-ID: <50A67DD5.1040702@redhat.com> On 11/16/2012 06:46 PM, Petr Viktorin wrote: > On 11/16/2012 05:17 PM, Martin Kosek wrote: >> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>> Recently, the specfile changed (dce53e4) and the patch for changed >>>>>>> Dogtag >>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>> rebased patch. >>>>>>> >>>>>>> Note that to continue development on f17, you will need to use the >>>>>>> dogtag-devel >>>>>>> repo: >>>>>>> sudo yum-config-manager >>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>> [...] >>>>>>>> >>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>> repository. >>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>> >>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>> >>>>>>> >>>>>> >>>>>> I started reviewing the patches, and found the first thing that looks >>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>> single-database >>>>>> IPA, the upgrade was OK. >>>>>> >>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>> removed >>>>>> because >>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv instances >>>>>> running. >>>>> >>>>> You're right. This is an uninstaller error already present in 2.2: >>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>> >>>>> I'll start looking into it tomorrow, if nothing more important shows >>>>> up. >>>>> >>>> >>>> Thanks for the pointer. But this is definitely not a show stopper, >>>> running >>>> additional DS instance seems more or less benign and as you pointed >>>> out, it is >>>> rather an old bug. >>>> >>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>> additional replication agreements in IPA dirsrv instance (although >>>> targeted to >>>> nsDS5ReplicaRoot: o=ipaca). >>>> >>>> First scenario: 3 IPA servers with CA in this topology: >>>> >>>> B - A - C >>>> >>>> On A: >>>> # ipa-replica-manage list `hostname` >>>> vm-055.idm.lab.bos.redhat.com: replica >>>> vm-070.idm.lab.bos.redhat.com: replica >>>> vm-055.idm.lab.bos.redhat.com: replica >>>> vm-070.idm.lab.bos.redhat.com: replica >>>> >>>> it should not display agreements that are for IPA only, not IPA CA ones. >>>> >>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>> [B] # ipa-replica-manage connect C >>>> Connected 'B' to 'C' >>>> >>>> This changed the topology to: >>>> A >>>> / \ >>>> B - C >>>> >>>> But ipa-csreplica-manage connect did not succeed then: >>>> [B] # ipa-csreplica-manage connect C >>>> Directory Manager password: >>>> >>>> This replication agreement already exists. >>>> >>>> Del command also failed for me: >>>> [A] ipa-replica-manage del [C] >>>> >>>> Still trying to investigate why. If I manage to get some workable fix >>>> during my >>>> investigations, I will attach it later. >>>> >>>> Martin >>> >>> The fix for that for easier than expected. Attached patch restored the >>> previous >>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>> commands >>> - add, del, connect, disconnect and it worked fine so far. >>> >>> But this was a case with all D10 masters, I will need to try if that >>> flies with >>> D9->D10 replicas or upgraded D9 masters. >>> >>> Martin >>> >> >> I have issues creating a 3.1 replica for 3.0 master (D10) with split >> databases. I run the script, but now I always end with error during CA >> installation: >> > [...] > > I couldn't reproduce this. Perhaps you installed the master or replica in a > different way? What are the commands you used? > > I am not sure what the different way means. I installed the 3.0 master with DNS support, on Fedora 18, with pki-ca-10.0.0-0.52.b3.fc18.noarch. Then created a replica info file, and run the script. On replica, I used standard # ipa-replica-install INFO_FILE # ipa-ca-install INFO_FILE The second command crashed. But I got the same result with: # ipa-replica-install INFO_FILE --setup-ca I can investigate it more on Monday if you do not find anything suspicious. It may have been my fault. Martin From dpal at redhat.com Fri Nov 16 19:35:56 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 16 Nov 2012 14:35:56 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> Message-ID: <50A6959C.9050802@redhat.com> On 11/01/2012 10:00 AM, 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. > > 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! > Hello Loris, Sorry for the delay. I finally got a moment to read about Asterisk and looked into your plans. Based on what you are proposing there is no real tight integration between IPA identities and services provided by IPA and Asterisk. What I see is IPA's DS would just be used as a data store for Asterisk configuration data and it would be managed via CLI leveraging the plugin framework we put together. If such approach is interesting for a customer I do not see a reason why it should not be done. I also do not see a value of having such plugin as a part of the integrated IPA supported offering. It is too independent and far from the core for us. But it is definitely a starting point. It might change over time. In future it might make sense to consider a different plugin that would add schema to IPA users only and would allow users to have additional Asterisk related attributes. I do not see a problem with user going into IPA web UI self service to manage his personal voice mail box settings. This seems like a logical operation. However it should be possible to split Asterisk configuration information between IPA and some other LDAP server or database. It might not make sense to pollute IPA with objects and entries that do not have a good relation to what IPA is for. So the best would be if Asterisk servers would be able to store user related info in the identity management system like IPA while having the rest of data about the infrastructure elsewhere. I do not know whether such approach is possible or feasible from the Asterisk project point of view. But if such extension for IPA users is in fact developed it has a much better chance to become over time a part of optional but supported portfolio of IPA plugins. No guarantees but at least such approach would be much closer to the core of what IPA is. We also took as stab at recommendations about writing such plugins. The list of things to consider turned to be long and scary. It is definitely a candidate for the external plugin development guide or alike but we do not have time to spend cycles to create such a guide now. We are still discussing how to better deliver this information to FreeIPA community and potential plugin developers like you. Please stay tuned. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Sat Nov 17 00:09:08 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 16 Nov 2012 17:09:08 -0700 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50A5C6D8.8030509@redhat.com> References: <50A5C6D8.8030509@redhat.com> Message-ID: <50A6D5A4.8000504@redhat.com> On 11/15/2012 09:53 PM, Rob Crittenden wrote: > This patch enables transaction support in 389-ds-base and fixes a few > transaction issues within IPA. > > This converts parts of the password and modrnd plugins to support > transactions. The password plugin still largely runs as > non-transactional because extop plugins aren't supported in > transactions yet. > > I've left the wait_for_attr code in place for now but on reflection we > should probably remove it. I'll leave that up to the reviewer, but I > can't see the need for it any more. > > In order for this to work you'll need to apply the last two patches > (both 0001) to slapi-nis and spin it up yourself, otherwise you'll > have serious deadlock issues. I know this is extra work but this patch > is potentially disruptive so I figure the earlier it is out the better. > > Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may > have been too aggressive in my cleanup. > > Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? ack > > Once we have an official slapi-nis build with these patches we'll need > to set the minimum n-v-r in our spec file. > > rob From nhosoi at redhat.com Sat Nov 17 00:43:01 2012 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 16 Nov 2012 16:43:01 -0800 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50A6D5A4.8000504@redhat.com> References: <50A5C6D8.8030509@redhat.com> <50A6D5A4.8000504@redhat.com> Message-ID: <50A6DD95.3010207@redhat.com> (2012/11/16 16:09), Rich Megginson wrote: > On 11/15/2012 09:53 PM, Rob Crittenden wrote: >> This patch enables transaction support in 389-ds-base and fixes a few >> transaction issues within IPA. >> >> This converts parts of the password and modrnd plugins to support >> transactions. The password plugin still largely runs as >> non-transactional because extop plugins aren't supported in >> transactions yet. >> >> I've left the wait_for_attr code in place for now but on reflection >> we should probably remove it. I'll leave that up to the reviewer, but >> I can't see the need for it any more. >> >> In order for this to work you'll need to apply the last two patches >> (both 0001) to slapi-nis and spin it up yourself, otherwise you'll >> have serious deadlock issues. I know this is extra work but this >> patch is potentially disruptive so I figure the earlier it is out the >> better. >> >> Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may >> have been too aggressive in my cleanup. >> >> Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? > ack Your patch looks good to me, too. Thank you so much! --noriko >> >> Once we have an official slapi-nis build with these patches we'll >> need to set the minimum n-v-r in our spec file. >> >> rob > From pvoborni at redhat.com Mon Nov 19 12:38:36 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 Nov 2012 13:38:36 +0100 Subject: [Freeipa-devel] [PATCH] 227 Editable sshkey field after upgrade Message-ID: <50AA284C.3060001@redhat.com> After upgrade, sshkeys of existing users and hosts are not editable because attribute level rights are not send to Web UI due to lack of ipasshuser object class. 'w_if_no_aci' attribute flag was introduced to bypass this issue. It makes attribute writable when AttributeLevelRights are not present. It was set for sshkeys_field. https://fedorahosted.org/freeipa/ticket/3260 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0227-Editable-sshkey-field-after-upgrade.patch Type: text/x-patch Size: 2052 bytes Desc: not available URL: From mkosek at redhat.com Mon Nov 19 13:09:35 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Nov 2012 14:09:35 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A63EC2.3020006@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> Message-ID: <50AA2F8F.50301@redhat.com> On 11/16/2012 02:25 PM, Martin Kosek wrote: > On 11/16/2012 11:23 AM, Martin Kosek wrote: >> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>>>> defaults made it to master independently (91e477b). Attaching rebased patch. >>>>> >>>>> Note that to continue development on f17, you will need to use the >>>>> dogtag-devel >>>>> repo: >>>>> sudo yum-config-manager >>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>> [...] >>>>>> >>>>>> For convenience, I've also pushed the changes to a personal repository. >>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>> >>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>> dogtag-10:pviktori-dogtag-10 >>>>>> >>>>> >>>> >>>> I started reviewing the patches, and found the first thing that looks >>>> suspicious. I had IPA with 2 databases, then upgraded it to single-database >>>> IPA, the upgrade was OK. >>>> >>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed >>>> because >>>> when I installed single-db IPA afterwards, I had 2 dirsrv instances running. >>> >>> You're right. This is an uninstaller error already present in 2.2: >>> https://fedorahosted.org/freeipa/ticket/3258 >>> >>> I'll start looking into it tomorrow, if nothing more important shows up. >>> >> >> Thanks for the pointer. But this is definitely not a show stopper, running >> additional DS instance seems more or less benign and as you pointed out, it is >> rather an old bug. >> >> There are bigger issues. Now I focused on ipa-replica-manage and >> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >> additional replication agreements in IPA dirsrv instance (although targeted to >> nsDS5ReplicaRoot: o=ipaca). >> >> First scenario: 3 IPA servers with CA in this topology: >> >> B - A - C >> >> On A: >> # ipa-replica-manage list `hostname` >> vm-055.idm.lab.bos.redhat.com: replica >> vm-070.idm.lab.bos.redhat.com: replica >> vm-055.idm.lab.bos.redhat.com: replica >> vm-070.idm.lab.bos.redhat.com: replica >> >> it should not display agreements that are for IPA only, not IPA CA ones. >> >> Now, when I try to connect B to C, ipa-replica-manage succeeded: >> [B] # ipa-replica-manage connect C >> Connected 'B' to 'C' >> >> This changed the topology to: >> A >> / \ >> B - C >> >> But ipa-csreplica-manage connect did not succeed then: >> [B] # ipa-csreplica-manage connect C >> Directory Manager password: >> >> This replication agreement already exists. >> >> Del command also failed for me: >> [A] ipa-replica-manage del [C] >> >> Still trying to investigate why. If I manage to get some workable fix during my >> investigations, I will attach it later. >> >> Martin > > The fix for that for easier than expected. Attached patch restored the previous > functionality for ipa-(cs)replica-manage. I tried that with all basic commands > - add, del, connect, disconnect and it worked fine so far. > > But this was a case with all D10 masters, I will need to try if that flies with > D9->D10 replicas or upgraded D9 masters. > > Martin > I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem to work well. I just think we will need to also backport the previous patch at least to 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication management tool. I created a ticket for this purpose: https://fedorahosted.org/freeipa/ticket/3262 Attaching a patch for IPA 2.2 branch in case somebody is also testing it. With this patch, I was able to list, force-sync, re-initialize, connect, disconnect from 2.2 to 3.1 replica without any errors. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-336-ipa-2-2-filter-suffix-in-replication-management-tools.patch Type: text/x-patch Size: 4863 bytes Desc: not available URL: From pviktori at redhat.com Mon Nov 19 14:14:36 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Mon, 19 Nov 2012 15:14:36 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50AA2F8F.50301@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> Message-ID: <50AA3ECC.9010601@redhat.com> On 11/19/2012 02:09 PM, Martin Kosek wrote: > On 11/16/2012 02:25 PM, Martin Kosek wrote: >> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>>>>> defaults made it to master independently (91e477b). Attaching rebased patch. >>>>>> >>>>>> Note that to continue development on f17, you will need to use the >>>>>> dogtag-devel >>>>>> repo: >>>>>> sudo yum-config-manager >>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>> [...] >>>>>>> >>>>>>> For convenience, I've also pushed the changes to a personal repository. >>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>> >>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>> >>>>>> >>>>> >>>>> I started reviewing the patches, and found the first thing that looks >>>>> suspicious. I had IPA with 2 databases, then upgraded it to single-database >>>>> IPA, the upgrade was OK. >>>>> >>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not removed >>>>> because >>>>> when I installed single-db IPA afterwards, I had 2 dirsrv instances running. >>>> >>>> You're right. This is an uninstaller error already present in 2.2: >>>> https://fedorahosted.org/freeipa/ticket/3258 >>>> >>>> I'll start looking into it tomorrow, if nothing more important shows up. >>>> >>> >>> Thanks for the pointer. But this is definitely not a show stopper, running >>> additional DS instance seems more or less benign and as you pointed out, it is >>> rather an old bug. >>> >>> There are bigger issues. Now I focused on ipa-replica-manage and >>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>> additional replication agreements in IPA dirsrv instance (although targeted to >>> nsDS5ReplicaRoot: o=ipaca). >>> >>> First scenario: 3 IPA servers with CA in this topology: >>> >>> B - A - C >>> >>> On A: >>> # ipa-replica-manage list `hostname` >>> vm-055.idm.lab.bos.redhat.com: replica >>> vm-070.idm.lab.bos.redhat.com: replica >>> vm-055.idm.lab.bos.redhat.com: replica >>> vm-070.idm.lab.bos.redhat.com: replica >>> >>> it should not display agreements that are for IPA only, not IPA CA ones. >>> >>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>> [B] # ipa-replica-manage connect C >>> Connected 'B' to 'C' >>> >>> This changed the topology to: >>> A >>> / \ >>> B - C >>> >>> But ipa-csreplica-manage connect did not succeed then: >>> [B] # ipa-csreplica-manage connect C >>> Directory Manager password: >>> >>> This replication agreement already exists. >>> >>> Del command also failed for me: >>> [A] ipa-replica-manage del [C] >>> >>> Still trying to investigate why. If I manage to get some workable fix during my >>> investigations, I will attach it later. >>> >>> Martin >> >> The fix for that for easier than expected. Attached patch restored the previous >> functionality for ipa-(cs)replica-manage. I tried that with all basic commands >> - add, del, connect, disconnect and it worked fine so far. >> >> But this was a case with all D10 masters, I will need to try if that flies with >> D9->D10 replicas or upgraded D9 masters. >> >> Martin >> > > I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem to work > well. I just think we will need to also backport the previous patch at least to > 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication > management tool. I created a ticket for this purpose: > > https://fedorahosted.org/freeipa/ticket/3262 > > Attaching a patch for IPA 2.2 branch in case somebody is also testing it. With > this patch, I was able to list, force-sync, re-initialize, connect, disconnect > from 2.2 to 3.1 replica without any errors. > > Martin > I checked ipa-csreplica-install, and found some more problems. In the "connect" and "disconnect" subcommands we now assume both masters use port 389 for the PKI DS. While the number is relatively easily parametrized, the assumption that both sides use the same port seems to run pretty deep. I'm working on a patch to detect if the remote server has merged DBs and use the appropriate port. -- Petr? From mkosek at redhat.com Mon Nov 19 16:35:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 19 Nov 2012 17:35:24 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50A4F9DC.2000001@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> Message-ID: <50AA5FCC.5090605@redhat.com> On 11/15/2012 03:19 PM, Petr Viktorin wrote: > Recently, the specfile changed (dce53e4) and the patch for changed Dogtag > defaults made it to master independently (91e477b). Attaching rebased patch. > > Note that to continue development on f17, you will need to use the dogtag-devel > repo: > sudo yum-config-manager > --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo > > > On 11/13/2012 03:57 PM, Petr Viktorin wrote: > [...] >> >> For convenience, I've also pushed the changes to a personal repository. >> To fetch to branch "pviktori-dogtag-10" you can do: >> >> git fetch -f git://github.com/encukou/freeipa.git >> dogtag-10:pviktori-dogtag-10 >> > I went through all the patches again, I found one more issue with the schema check. As it binds to Directory Server anonymously when retrieving the schema and tests if "ipaObject" objectclass is present, it can fail and crash when anonymous binds are not allowed for the Dogtag DS instance. This is what I get when I disabled anonymous binds and run ipa-replica-install --setup-ca (a script to turn anonymous binds off attached): [root at vm-104 ~]# ipa-replica-install replica-info-vm-104.idm.lab.bos.redhat.com.gpg --setup-ca Directory Manager (existing master) password: Run connection check to master [...] Connection from master to replica is OK. Connection check OK Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. LDAP error: INAPPROPRIATE_AUTH Anonymous access is not allowed If possible, it would be good authenticate first. This should be doable, we have a Directory Manager password available, after all. Some schema retrieval code that we already have in IPA can be found in SchemaCache class in ldap2.py. We may also want to have some flag similar to --skip-conncheck which would allow admin with an issue like this one skip the check when he is certain that he copied the schema files. Adding Ade to check that this scenario is actually sane and Dogtag is supposed to work with anonymous access disabled for its DS instance. When reading the patches, I also saw few places with magic constant "7389" (your "Fix schema replication from old masters" patch and Ade's patch). I wonder, would "dogtag.Dogtag9Constants.DS_PORT" be more readable? Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: ldap-non-anonymous.sh Type: application/x-shellscript Size: 473 bytes Desc: not available URL: From pvoborni at redhat.com Mon Nov 19 17:01:27 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 Nov 2012 18:01:27 +0100 Subject: [Freeipa-devel] [PATCHES] 228-237 Confirmation of dialogs by keyboard, better password dialogs Message-ID: <50AA65E7.4070301@redhat.com> This bunch of patches is 3.2 stuff. Patches 216 and 217 have higher priority. These patches are rebased upon my patch #216. I'm sending them now only to give more time for review. These patches make Web UI's dialogs more consistent and enhances keyboard support for most of them. They solve following tickets: * https://fedorahosted.org/freeipa/ticket/3035 (confirmation by enter of other confirm dialogs) * https://fedorahosted.org/freeipa/ticket/3200 [RFE] Confirmation by 'Enter' is not supported in all confirmation dialogs * https://fedorahosted.org/freeipa/ticket/2884 Improve notification and validation in password reset dialogs. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0228-Make-confirm_dialog-a-base-class-of-revoke-and-resto.patch Type: text/x-patch Size: 8944 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0229-Make-confirm_dialog-a-base-class-for-deleter-dialog.patch Type: text/x-patch Size: 6966 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0230-Make-confirm_dialog-a-base-class-for-message_dialog.patch Type: text/x-patch Size: 3664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0231-Confirm-mixin.patch Type: text/x-patch Size: 4521 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0232-Confirm-adder-dialog-by-enter.patch Type: text/x-patch Size: 2297 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0233-Confirm-error-dialog-by-enter.patch Type: text/x-patch Size: 5299 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0234-Focus-last-dialog-when-some-is-closed.patch Type: text/x-patch Size: 2718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0235-Confirm-association-dialogs-by-enter.patch Type: text/x-patch Size: 1653 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0236-Standardize-login-password-reset-user-reset-password.patch Type: text/x-patch Size: 7989 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0237-Focus-first-input-element-after-Add-and-Add-another.patch Type: text/x-patch Size: 1846 bytes Desc: not available URL: From dpal at redhat.com Mon Nov 19 17:15:18 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Nov 2012 12:15:18 -0500 Subject: [Freeipa-devel] [PATCHES] 228-237 Confirmation of dialogs by keyboard, better password dialogs In-Reply-To: <50AA65E7.4070301@redhat.com> References: <50AA65E7.4070301@redhat.com> Message-ID: <50AA6926.6000804@redhat.com> On 11/19/2012 12:01 PM, Petr Vobornik wrote: > This bunch of patches is 3.2 stuff. Patches 216 and 217 have higher > priority. These patches are rebased upon my patch #216. I'm sending > them now only to give more time for review. > > These patches make Web UI's dialogs more consistent and enhances > keyboard support for most of them. > > They solve following tickets: > * https://fedorahosted.org/freeipa/ticket/3035 (confirmation by > enter of other confirm dialogs) > * https://fedorahosted.org/freeipa/ticket/3200 [RFE] Confirmation by > 'Enter' is not supported in all confirmation dialogs > * https://fedorahosted.org/freeipa/ticket/2884 Improve notification > and validation in password reset dialogs. > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Any RFE needs to have a design page. -- 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 atkac at redhat.com Mon Nov 19 17:33:30 2012 From: atkac at redhat.com (Adam Tkac) Date: Mon, 19 Nov 2012 18:33:30 +0100 Subject: [Freeipa-devel] [PATCH 0093] Log memory allocation failures In-Reply-To: <50A64A90.7030100@redhat.com> References: <50A6320F.8010102@redhat.com> <1353072274.10327.785.camel@willson.li.ssimo.org> <50A64A90.7030100@redhat.com> Message-ID: <20121119173330.GA11848@redhat.com> On Fri, Nov 16, 2012 at 03:15:44PM +0100, Petr Spacek wrote: > On 11/16/2012 02:24 PM, Simo Sorce wrote: > >On Fri, 2012-11-16 at 13:31 +0100, Petr Spacek wrote: > >>+#define FILE_LINE_FUNC_MSG "%-15s: %4d: %-20s" > >>+#define FILE_LINE_FUNC_ARG __FILE__, __LINE__, __func__ > > > >Wouldn't it be more compact and less error prone to do something like: > > > >#define LOG_POSITION_MSG(str, ...) \ > >do { \ > >log_error("[%-15s: %4d: %-20s] " str, \ > > __FILE__, __LINE__, __func__, __VA_ARGS__); \ > >} while(0); > > > >> #define CLEANUP_WITH(result_code) \ > >> do { \ > >> result = (result_code); \ > >>@@ -46,15 +52,21 @@ > >> (target_ptr) = isc_mem_allocate((m), (s)); \ > >> if ((target_ptr) == NULL) { \ > >> result = ISC_R_NOMEMORY; \ > >>+ log_error("MEMORY ALLOCATION FAILURE at > >>" \ > >>+ FILE_LINE_FUNC_MSG, \ > >>+ FILE_LINE_FUNC_ARG); \ > > > >and here simply: > > LOG_POSITION_MSG("MEMORY ALLOCATION FAILURE"); > > > >The _MSG seem misleading doesn't make you think it is a format string > >(maybe calling it _FMT would be better if you want to keep this split in > >pieces). > > > >The single form above let you write less and still do things like: > >LOG_POSITION_MSG("This failed with %d (%s)", ret, strerror(ret)); > > Yes, it would. I split it to avoid dns_result_totext() duplication > in my next patch ... I see this approach as better now. Amended > patch is attached. Thanks for the patch, please read my comments below. Regards, Adam > From ef61c2e6db88b39c8b2642b14c23fd62a3eff472 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 16 Nov 2012 13:17:44 +0100 > Subject: [PATCH] Log memory allocation failures. > > Signed-off-by: Petr Spacek > --- > src/log.h | 7 ++++++- > src/util.h | 5 +++++ > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/src/log.h b/src/log.h > index 9062a4e80786b5bab806d6c9ceba1d1a9917a3e2..d6a40151d25b6f67cf6735ec955d45e4ebe4106c 100644 > --- a/src/log.h > +++ b/src/log.h > @@ -23,22 +23,27 @@ > > #include > #include > +#include > > #ifdef LOG_AS_ERROR > #define GET_LOG_LEVEL(level) ISC_LOG_ERROR > #else > #define GET_LOG_LEVEL(level) (level) > #endif > > #define fatal_error(...) \ > - isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__) > + isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__) > > #define log_bug(fmt, ...) \ > log_error("bug in %s(): " fmt, __func__,##__VA_ARGS__) > > #define log_error_r(fmt, ...) \ > log_error(fmt ": %s", ##__VA_ARGS__, dns_result_totext(result)) > > +#define log_error_position(format, ...) \ > + log_error("[%-15s: %4d: %-21s] " format, \ Do we really need to format the format string? I would prefer to drop the "[...]" stuff at all. > + __FILE__, __LINE__, __func__, ##__VA_ARGS__) > + > /* Basic logging functions */ > #define log_error(format, ...) \ > log_write(GET_LOG_LEVEL(ISC_LOG_ERROR), format, ##__VA_ARGS__) > diff --git a/src/util.h b/src/util.h > index 2b8f10e59ddacdb1d0e49cf0de3e9ab8a3786090..56fd5d80b55b8f8033718afbc31e9ff598f7e257 100644 > --- a/src/util.h > +++ b/src/util.h > @@ -21,6 +21,8 @@ > #ifndef _LD_UTIL_H_ > #define _LD_UTIL_H_ > > +#include "log.h" > + > #define CLEANUP_WITH(result_code) \ > do { \ > result = (result_code); \ > @@ -46,15 +48,17 @@ > (target_ptr) = isc_mem_allocate((m), (s)); \ > if ((target_ptr) == NULL) { \ > result = ISC_R_NOMEMORY; \ > + log_error_position("MEMORY ALLOCATION FAILURE"); \ Such huge msg is not needed, I think. What about more conservative log_error_position("Memory allocation failed") > goto cleanup; \ > } \ > } while (0) > > #define CHECKED_MEM_GET(m, target_ptr, s) \ > do { \ > (target_ptr) = isc_mem_get((m), (s)); \ > if ((target_ptr) == NULL) { \ > result = ISC_R_NOMEMORY; \ > + log_error_position("MEMORY ALLOCATION FAILURE"); \ > goto cleanup; \ > } \ > } while (0) > @@ -67,6 +71,7 @@ > (target) = isc_mem_strdup((m), (source)); \ > if ((target) == NULL) { \ > result = ISC_R_NOMEMORY; \ > + log_error_position("MEMORY ALLOCATION FAILURE"); \ > goto cleanup; \ > } \ > } while (0) > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From edewata at redhat.com Tue Nov 20 06:11:50 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Nov 2012 00:11:50 -0600 Subject: [Freeipa-devel] [PATCH] 226 Better error message for login of users from other realms In-Reply-To: <50A4D1D7.7040101@redhat.com> References: <50A3DD31.60007@redhat.com> <1352916957.10327.670.camel@willson.li.ssimo.org> <50A4D1D7.7040101@redhat.com> Message-ID: <50AB1F26.9090702@redhat.com> On 11/15/2012 5:28 AM, Petr Vobornik wrote: > Changed. Updated patch attached. ACK. Just a minor thing, the errors object probably can be created outside of show_login_error_message() since it contains only fixed messages. -- Endi S. Dewata From edewata at redhat.com Tue Nov 20 06:12:00 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Nov 2012 00:12:00 -0600 Subject: [Freeipa-devel] [PATCH] 227 Editable sshkey field after upgrade In-Reply-To: <50AA284C.3060001@redhat.com> References: <50AA284C.3060001@redhat.com> Message-ID: <50AB1F30.5040508@redhat.com> On 11/19/2012 6:38 AM, Petr Vobornik wrote: > After upgrade, sshkeys of existing users and hosts are not editable > because attribute level rights are not send to Web UI due to lack of > ipasshuser object class. > > 'w_if_no_aci' attribute flag was introduced to bypass this issue. It > makes attribute writable when AttributeLevelRights are not present. It > was set for sshkeys_field. > > https://fedorahosted.org/freeipa/ticket/3260 ACK. -- Endi S. Dewata From pspacek at redhat.com Tue Nov 20 09:11:42 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Nov 2012 10:11:42 +0100 Subject: [Freeipa-devel] [PATCH 0093] Log memory allocation failures In-Reply-To: <20121119173330.GA11848@redhat.com> References: <50A6320F.8010102@redhat.com> <1353072274.10327.785.camel@willson.li.ssimo.org> <50A64A90.7030100@redhat.com> <20121119173330.GA11848@redhat.com> Message-ID: <50AB494E.6090606@redhat.com> On 11/19/2012 06:33 PM, Adam Tkac wrote: > On Fri, Nov 16, 2012 at 03:15:44PM +0100, Petr Spacek wrote: >> On 11/16/2012 02:24 PM, Simo Sorce wrote: >>> On Fri, 2012-11-16 at 13:31 +0100, Petr Spacek wrote: >>>> +#define FILE_LINE_FUNC_MSG "%-15s: %4d: %-20s" >>>> +#define FILE_LINE_FUNC_ARG __FILE__, __LINE__, __func__ > Thanks for the patch, please read my comments below. >> diff --git a/src/log.h b/src/log.h >> index 9062a4e80786b5bab806d6c9ceba1d1a9917a3e2..d6a40151d25b6f67cf6735ec955d45e4ebe4106c 100644 >> --- a/src/log.h >> +++ b/src/log.h >> +#define log_error_position(format, ...) \ >> + log_error("[%-15s: %4d: %-21s] " format, \ > > Do we really need to format the format string? I would prefer to drop the > "[...]" stuff at all. This format will align file names, line numbers and most of function names in columns. It can be handy if some error propagates through call stack, but I can drop it if you want. Real world example: [ldap_entry.c : 370: ldap_entry_getfakesoa] FAILURE: not found [ldap_helper.c : 1869: add_soa_record ] FAILURE: not found My intention is to extend logging to failures detected inside CHECK() macros. Currently, any failure inside CHECK() will jump to "cleanup" label, so information about source of the failure is lost. As a result it produces error message like: update_record (psearch) failed, dn 'idnsName=q.sub,idnsname=test,cn=dns,dc=e,dc=test' change type 0x1. Records can be outdated, run `rndc reload`: not found Huh? What was not found? Those error messages are not useful for post mortem analysis. With logging inside CHECK() it produces: [ldap_helper.c : 3467: update_record ] FAILURE: not found update_record (psearch) failed, dn 'idnsName=q.sub,idnsname=test,cn=dns,dc=e,dc=test' change type 0x1. Records can be outdated, run `rndc reload`: not found File ldap_helper.c, line 3467, return code ISC_R_NOTFOUND is much better information. >> @@ -46,15 +48,17 @@ >> (target_ptr) = isc_mem_allocate((m), (s)); \ >> if ((target_ptr) == NULL) { \ >> result = ISC_R_NOMEMORY; \ >> + log_error_position("MEMORY ALLOCATION FAILURE"); \ > > Such huge msg is not needed, I think. What about more conservative > > log_error_position("Memory allocation failed") You are right, I shouldn't scream too much. Amended patch is attached. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0093-3-Log-memory-allocation-failures.patch Type: text/x-patch Size: 2423 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 20 09:18:09 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Nov 2012 10:18:09 +0100 Subject: [Freeipa-devel] [PATCH 0094] Use memory allocation macros more extensively - part 1 Message-ID: <50AB4AD1.8050108@redhat.com> Hello, Use memory allocation macros more extensively. Some scattered occurences of isc_mem_* functions was replaced by macros. Destroy_ldap_instance() now accepts NULL LDAP instance. String functions from str.c are still calling isc_mem_directly. This patch contain small subset of changes which affect new_ldap_instance() and destroy_ldap_instance() calls. Remaining changes do not require changes in new_*/destroy_* logic and will follow in separate patch. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0094-Use-memory-allocation-macros-more-extensively.patch Type: text/x-patch Size: 2488 bytes Desc: not available URL: From jcholast at redhat.com Tue Nov 20 09:48:24 2012 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 20 Nov 2012 10:48:24 +0100 Subject: [Freeipa-devel] [PATCH] 227 Editable sshkey field after upgrade In-Reply-To: <50AA284C.3060001@redhat.com> References: <50AA284C.3060001@redhat.com> Message-ID: <50AB51E8.9040607@redhat.com> Hi, On 19.11.2012 13:38, Petr Vobornik wrote: > After upgrade, sshkeys of existing users and hosts are not editable > because attribute level rights are not send to Web UI due to lack of > ipasshuser object class. > > 'w_if_no_aci' attribute flag was introduced to bypass this issue. It > makes attribute writable when AttributeLevelRights are not present. It > was set for sshkeys_field. > > https://fedorahosted.org/freeipa/ticket/3260 > I think that ipaexternalmember, gidnumber and macaddress attributes might cause trouble as well. They are all in objectclasses that are added to objects on-demand (like ipasshuser/ipasshhost is). Honza -- Jan Cholasta From pspacek at redhat.com Tue Nov 20 11:50:12 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Nov 2012 12:50:12 +0100 Subject: [Freeipa-devel] [PATCH 0095] Use memory allocation macros more extensively - part 2 Message-ID: <50AB6E74.5020803@redhat.com> Hello, this patch replaces all remaining occurrences of direct isc_mem_* calls with macros. The only exception is destroy_ldap_connection() which will be handled in separate patch - current deallocation code is probably not safe. Commit message: Use memory allocation macros more extensively - part 2. Some scattered occurences of isc_mem_* functions was replaced by macros. String functions from str.c are still calling isc_mem_directly. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0095-Use-memory-allocation-macros-more-extensively-part-2.patch Type: text/x-patch Size: 6703 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 20 11:57:13 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Nov 2012 12:57:13 +0100 Subject: [Freeipa-devel] [PATCH 0096] Remove unused str_*split*() functions Message-ID: <50AB7019.4070708@redhat.com> Hello, this patch removes never called str_*split*() functions and related ld_split structure. We can pull it from history when necessary. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0096-Remove-unused-str_-split-functions-and-ld_split-stru.patch Type: text/x-patch Size: 4533 bytes Desc: not available URL: From pspacek at redhat.com Tue Nov 20 12:06:59 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Nov 2012 13:06:59 +0100 Subject: [Freeipa-devel] [PATCH 0097] Deallocate LDAP connections in safe way Message-ID: <50AB7263.9040201@redhat.com> Hello, Deallocate LDAP connections in safe way. Current code does isc_mem_detach() before isc_mem_put() so memory context reference counter is wrong for a small time frame. Macro MEM_PUT_AND_DETACH will handle it properly including pointer zeroing. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0097-Deallocate-LDAP-connections-in-safe-way.patch Type: text/x-patch Size: 2543 bytes Desc: not available URL: From pvoborni at redhat.com Tue Nov 20 12:54:14 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Nov 2012 13:54:14 +0100 Subject: [Freeipa-devel] [PATCHES] 228-237 Confirmation of dialogs by keyboard, better password dialogs In-Reply-To: <50AA6926.6000804@redhat.com> References: <50AA65E7.4070301@redhat.com> <50AA6926.6000804@redhat.com> Message-ID: <50AB7D76.6010809@redhat.com> On 11/19/2012 06:15 PM, Dmitri Pal wrote: > On 11/19/2012 12:01 PM, Petr Vobornik wrote: >> This bunch of patches is 3.2 stuff. Patches 216 and 217 have higher >> priority. These patches are rebased upon my patch #216. I'm sending >> them now only to give more time for review. >> >> These patches make Web UI's dialogs more consistent and enhances >> keyboard support for most of them. >> >> They solve following tickets: >> * https://fedorahosted.org/freeipa/ticket/3035 (confirmation by >> enter of other confirm dialogs) >> * https://fedorahosted.org/freeipa/ticket/3200 [RFE] Confirmation by >> 'Enter' is not supported in all confirmation dialogs >> * https://fedorahosted.org/freeipa/ticket/2884 Improve notification >> and validation in password reset dialogs. >> > Any RFE needs to have a design page. > New design page: http://www.freeipa.org/page/V3/WebUI_keyboard_confirmation Link to design page was added to tickets #3200 and #2910. In the ticket list of previous mail is a mistake. This effort is related to tickets #3200, #2910 and #2884. Probably commit messages should be amended. -- Petr Vobornik From mkosek at redhat.com Tue Nov 20 13:08:04 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Nov 2012 14:08:04 +0100 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50A6674A.9020606@redhat.com> References: <50A5C6D8.8030509@redhat.com> <20121116145736.GA30716@redhat.com> <50A6674A.9020606@redhat.com> Message-ID: <50AB80B4.1060703@redhat.com> On 11/16/2012 05:18 PM, Rob Crittenden wrote: > Nalin Dahyabhai wrote: >> On Thu, Nov 15, 2012 at 11:53:44PM -0500, Rob Crittenden wrote: >>> In order for this to work you'll need to apply the last two patches >>> (both 0001) to slapi-nis and spin it up yourself, otherwise you'll >>> have serious deadlock issues. I know this is extra work but this >>> patch is potentially disruptive so I figure the earlier it is out >>> the better. >>> >>> Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may >>> have been too aggressive in my cleanup. >>> >>> Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? >>> >>> Once we have an official slapi-nis build with these patches we'll >>> need to set the minimum n-v-r in our spec file. >> >> Rob, the original patch was already applied. I since reworked large >> parts of how it was organized to make it easier for me to read, and >> tagged the result as 0.43. Have you tested the IPA changes in >> combination with the 0.44 builds from either ipa-devel or Fedora 18's >> updates-testing repository? >> >> Nalin >> > > I tested the 0.44 build and things are looking good. I'm not deadlocking, so I > guess that's the desired out come :-) > > I bulk loaded a few thousand users and groups and tested the compat and NIS > plugins and the data appears correct. > > Updated patch with minimum n-v-r in spec attached. > > rob > Good job, this closes a lot of tickets! I am now also able to run tests without having to set wait_for_attr env config first! The patch generally seems to work OK, I tried it even with a replica without transactions enabled and so far so good. I have found just few issues: 1) Patch needs a mild rebase (spec file conflict) 2) One Unit test failure slipped: ====================================================================== FAIL: test_permission[22]: permission_find: Search for permissions by attr with a limit of 1 (truncated) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 249, in func = lambda: self.check(nice, **test) File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 266, in check self.check_output(nice, cmd, args, options, expected, extra_check) File "/root/freeipa-master/tests/test_xmlrpc/xmlrpc_test.py", line 304, in check_output assert_deepequal(expected, got, nice) File "/root/freeipa-master/tests/util.py", line 335, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (key,)) File "/root/freeipa-master/tests/util.py", line 323, in assert_deepequal assert_deepequal(e_sub, g_sub, doc, stack + (i,)) File "/root/freeipa-master/tests/util.py", line 329, in assert_deepequal doc, sorted(missing), sorted(extra), expected, got, stack AssertionError: assert_deepequal: dict keys mismatch. test_permission[22]: permission_find: Search for permissions by attr with a limit of 1 (truncated) missing keys = [] extra keys = ['memberindirect'] expected = {'dn': ipapython.dn.DN('cn=Modify HBAC rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com'), 'cn': [u'Modify HBAC rule'], 'member_privilege': [u'HBAC Administrator'], 'subtree': u'ldap:///ipauniqueid=*,cn=hbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com', 'attrs': [u'servicecategory', u'sourcehostcategory', u'cn', u'description', u'ipaenabledflag', u'accesstime', u'usercategory', u'hostcategory', u'accessruletype', u'sourcehost'], 'permissions': [u'write']} got = {'dn': u'cn=Modify HBAC rule,cn=permissions,cn=pbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com', 'cn': (u'Modify HBAC rule',), 'member_privilege': (u'HBAC Administrator',), 'subtree': u'ldap:///ipauniqueid=*,cn=hbac,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com', 'memberindirect': (u'cn=IT Security Specialist,cn=roles,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com',), 'attrs': (u'servicecategory', u'sourcehostcategory', u'cn', u'description', u'ipaenabledflag', u'accesstime', u'usercategory', u'hostcategory', u'accessruletype', u'sourcehost'), 'permissions': (u'write',)} path = ('result', 0) 3) Question - what is the reason of keeping wait_for_attr sections in our code? I may miss something, but I see no difference with api.env.wait_for_attr enabled... AFAIU, there should not even be any difference as all attributes should be filled in one transaction, so I would rather remove this flag from both code and man page. 4) nsslapd-pluginbetxn is not set for schema compatibility plugin after upgrade: # Schema Compatibility, plugins, config dn: cn=Schema Compatibility,cn=plugins,cn=config nsslapd-pluginId: schema-compat-plugin cn: Schema Compatibility objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject nsslapd-pluginDescription: Schema Compatibility Plugin nsslapd-pluginEnabled: on nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/schemacompat-plugin.so nsslapd-pluginVersion: 0.44 (betxn support available and enabled by default) nsslapd-pluginVendor: redhat.com nsslapd-pluginType: object nsslapd-pluginInitfunc: schema_compat_plugin_init This is supposed to be enabled by default, judging by nsslapd-pluginVersion description, but this may create an inconsistency between new installs and upgraded IPA servers. The same issue applies to IPA server with NIS plugin enabled. Martin From pspacek at redhat.com Tue Nov 20 13:44:49 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Nov 2012 14:44:49 +0100 Subject: [Freeipa-devel] [PATCH 0098] Log failures detected in CHECK() macro Message-ID: <50AB8951.5000604@redhat.com> Hello, Log failures detected in CHECK() macro. Function ldap_query() can return ISC_R_NOTFOUND legitimately. For this and similar cases CHECK_CONDLOG macro was introduced. It will not log if result != ISC_R_SUCCESS but == ignored_code. Nested condition will be eliminated by optimizing compiler in cases where ignored_code == ISC_R_SUCCESS. Function add_soa_record() is now called only for zones to prevent false error messages. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0098-Log-failures-detected-in-CHECK-macro.patch Type: text/x-patch Size: 2950 bytes Desc: not available URL: From pviktori at redhat.com Tue Nov 20 13:59:39 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Tue, 20 Nov 2012 14:59:39 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50AA3ECC.9010601@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> Message-ID: <50AB8CCB.7020302@redhat.com> On 11/19/2012 03:14 PM, Petr Viktorin wrote: > On 11/19/2012 02:09 PM, Martin Kosek wrote: >> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>> changed Dogtag >>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>> rebased patch. >>>>>>> >>>>>>> Note that to continue development on f17, you will need to use the >>>>>>> dogtag-devel >>>>>>> repo: >>>>>>> sudo yum-config-manager >>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>> [...] >>>>>>>> >>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>> repository. >>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>> >>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>> >>>>>>> >>>>>> >>>>>> I started reviewing the patches, and found the first thing that looks >>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>> single-database >>>>>> IPA, the upgrade was OK. >>>>>> >>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>> removed >>>>>> because >>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>> instances running. >>>>> >>>>> You're right. This is an uninstaller error already present in 2.2: >>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>> >>>>> I'll start looking into it tomorrow, if nothing more important >>>>> shows up. >>>>> >>>> >>>> Thanks for the pointer. But this is definitely not a show stopper, >>>> running >>>> additional DS instance seems more or less benign and as you pointed >>>> out, it is >>>> rather an old bug. >>>> >>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>> additional replication agreements in IPA dirsrv instance (although >>>> targeted to >>>> nsDS5ReplicaRoot: o=ipaca). >>>> >>>> First scenario: 3 IPA servers with CA in this topology: >>>> >>>> B - A - C >>>> >>>> On A: >>>> # ipa-replica-manage list `hostname` >>>> vm-055.idm.lab.bos.redhat.com: replica >>>> vm-070.idm.lab.bos.redhat.com: replica >>>> vm-055.idm.lab.bos.redhat.com: replica >>>> vm-070.idm.lab.bos.redhat.com: replica >>>> >>>> it should not display agreements that are for IPA only, not IPA CA >>>> ones. >>>> >>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>> [B] # ipa-replica-manage connect C >>>> Connected 'B' to 'C' >>>> >>>> This changed the topology to: >>>> A >>>> / \ >>>> B - C >>>> >>>> But ipa-csreplica-manage connect did not succeed then: >>>> [B] # ipa-csreplica-manage connect C >>>> Directory Manager password: >>>> >>>> This replication agreement already exists. >>>> >>>> Del command also failed for me: >>>> [A] ipa-replica-manage del [C] >>>> >>>> Still trying to investigate why. If I manage to get some workable >>>> fix during my >>>> investigations, I will attach it later. >>>> >>>> Martin >>> >>> The fix for that for easier than expected. Attached patch restored >>> the previous >>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>> commands >>> - add, del, connect, disconnect and it worked fine so far. >>> >>> But this was a case with all D10 masters, I will need to try if that >>> flies with >>> D9->D10 replicas or upgraded D9 masters. >>> >>> Martin >>> >> >> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >> to work >> well. I just think we will need to also backport the previous patch at >> least to >> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >> management tool. I created a ticket for this purpose: >> >> https://fedorahosted.org/freeipa/ticket/3262 >> >> Attaching a patch for IPA 2.2 branch in case somebody is also testing >> it. With >> this patch, I was able to list, force-sync, re-initialize, connect, >> disconnect >> from 2.2 to 3.1 replica without any errors. >> >> Martin >> > > I checked ipa-csreplica-install, and found some more problems. > > In the "connect" and "disconnect" subcommands we now assume both masters > use port 389 for the PKI DS. While the number is relatively easily > parametrized, the assumption that both sides use the same port seems to > run pretty deep. > I'm working on a patch to detect if the remote server has merged DBs and > use the appropriate port. Attaching patches to do this. Patch 0100 adds an argument to IPAdmin to overrides guessing of the protocol to use. Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs involved and use those. Note that this touches code shared with ipa-replica-manage, please re-test that as well. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0100-Provide-protocol-argument-to-IPAdmin.patch Type: text/x-patch Size: 3756 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0101-Make-ipa-csreplica-manage-work-with-both-merged-and-.patch Type: text/x-patch Size: 14002 bytes Desc: not available URL: From abokovoy at redhat.com Tue Nov 20 14:09:47 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 20 Nov 2012 16:09:47 +0200 Subject: [Freeipa-devel] [PATCH] 0094 better Kerberos error handling in ipasam Message-ID: <20121120140947.GA3357@redhat.com> Hi, attached patch expands error checks when obtaining Kerberos ticket in ipasam module. The change should cover observed corner cases which caused ipasam to fail obtaining the ticket. Without the patch one will get something similar to what I get below when manually moving time back on the server (with additional debug statements to show error codes): Nov 20 14:01:29 signfinity winbindd[15759]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid) Nov 20 14:01:29 signfinity winbindd[15759]: [2012/11/20 14:01:29.616951, 0] ipa_sam.c:3829(bind_callback) Nov 20 14:01:29 signfinity winbindd[15759]: bind_callback: ldap_sasl_interactive_bind_s() call returned -2, kerberos code is 0 Nov 20 14:01:29 signfinity winbindd[15759]: [2012/11/20 14:01:29.618787, 0] ../source3/lib/smbldap.c:998(smbldap_connect_system) Nov 20 14:01:29 signfinity winbindd[15759]: failed to bind to server ldapi://%2fvar%2frun%2fslapd-IPA-TEAM.socket with dn="[Anonymous bind]" Error: Local error Nov 20 14:01:29 signfinity winbindd[15759]: #011SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid After patching it now looks like this: Nov 20 15:00:04 signfinity winbindd[18693]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid) Nov 20 15:00:04 signfinity winbindd[18693]: [2012/11/20 15:00:04.403051, 0] ipa_sam.c:3829(bind_callback) Nov 20 15:00:04 signfinity winbindd[18693]: bind_callback: ldap_sasl_interactive_bind_s() call returned -2, kerberos code is 0 Nov 20 15:00:20 signfinity winbindd[18693]: [2012/11/20 15:00:20.090270, 0] ipa_sam.c:3829(bind_callback) Nov 20 15:00:20 signfinity winbindd[18693]: bind_callback: ldap_sasl_interactive_bind_s() call returned 0, kerberos code is 0 as you can see, winbindd has recovered automatically. -- / Alexander Bokovoy -------------- next part -------------- >From a6159484e0c3f1533df2b222e66b7418ee55f309 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 20 Nov 2012 15:18:50 +0200 Subject: [PATCH] ipasam: better Kerberos error handling in ipasam If time is moved back on the IPA server, ipasam does not invalidate the existing ticket. https://fedorahosted.org/freeipa/ticket/3183 --- daemons/ipa-sam/ipa_sam.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index b1592b71f40d26775b5add9ce9846082d0112af7..3c4c97cd19a9937756013eab69b047d0df80ecad 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -3809,9 +3809,9 @@ static int bind_callback(LDAP *ldap_struct, struct smbldap_state *ldap_state, vo ldap_sasl_interact, &data); /* By now we have 'ret' for LDAP result and 'rc' for Kerberos result - * if ret is LDAP_INVALID_CREDENTIALS, LDAP server rejected our ccache. There may be several issues: + * if LDAP_API_ERROR(ret) is true, LDAP server rejected our ccache. There may be several issues: * - * 1. Credentials are invalid due to outdated ccache leftover from previous install + * 1. Credentials are invalid due to outdated ccache leftover from previous install or ticket is from future * Wipe out old ccache and start again * * 2. Key in the keytab is not enough to obtain ticket for cifs/FQDN at REALM service @@ -3825,7 +3825,9 @@ static int bind_callback(LDAP *ldap_struct, struct smbldap_state *ldap_state, vo * a new ccache file by the above call of bind_callback_obtain_creds(). This is expected and correct behavior. * */ - if ((ret == LDAP_INVALID_CREDENTIALS) && (rc == 0)) { + + if (LDAP_API_ERROR(ret) && + ((rc == 0) || (rc == KRB5KRB_AP_ERR_TKT_NYV) || (rc == KRB5KRB_AP_ERR_TKT_EXPIRED))) { bind_callback_cleanup_creds(&data); rc = bind_callback_obtain_creds(&data); if (rc) { -- 1.8.0 From simo at redhat.com Tue Nov 20 14:11:59 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Nov 2012 09:11:59 -0500 Subject: [Freeipa-devel] [PATCH 0094] Use memory allocation macros more extensively - part 1 In-Reply-To: <50AB4AD1.8050108@redhat.com> References: <50AB4AD1.8050108@redhat.com> Message-ID: <1353420719.25375.90.camel@willson.li.ssimo.org> On Tue, 2012-11-20 at 10:18 +0100, Petr Spacek wrote: > Hello, > > Use memory allocation macros more extensively. > > Some scattered occurences of isc_mem_* functions was replaced by macros. > Destroy_ldap_instance() now accepts NULL LDAP instance. > > String functions from str.c are still calling isc_mem_directly. > > This patch contain small subset of changes which affect new_ldap_instance() > and destroy_ldap_instance() calls. Remaining changes do not require changes in > new_*/destroy_* logic and will follow in separate patch. Hi Petr, I am not sure what are ISC conventions, but in general Macros that change program flow are quite dangerous *unless* you prominently make clear that that's what they are doing. So if you return or goto in a macro I suggest you make RETURN and GOTO part of the name, otherwise inspection of the code will easily make someone not notice that. This can easily lead to memory leaks where you do not notice a return/goto macro and the condition happen, as well as more serious issues, like not seeing a return/goto after you obtained a lock or a mutex and so on. In general I would really avoid 'return' in a macro and at most do gotos to some explicit label you can pass as argument of the macro. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Nov 20 14:14:01 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Nov 2012 09:14:01 -0500 Subject: [Freeipa-devel] [PATCH] 0094 better Kerberos error handling in ipasam In-Reply-To: <20121120140947.GA3357@redhat.com> References: <20121120140947.GA3357@redhat.com> Message-ID: <1353420841.25375.91.camel@willson.li.ssimo.org> On Tue, 2012-11-20 at 16:09 +0200, Alexander Bokovoy wrote: > Hi, > > attached patch expands error checks when obtaining Kerberos ticket in > ipasam module. The change should cover observed corner cases which > caused ipasam to fail obtaining the ticket. > > Without the patch one will get something similar to what I get below > when manually moving time back on the server (with additional debug > statements to show error codes): > Nov 20 14:01:29 signfinity winbindd[15759]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid) > Nov 20 14:01:29 signfinity winbindd[15759]: [2012/11/20 14:01:29.616951, 0] ipa_sam.c:3829(bind_callback) > Nov 20 14:01:29 signfinity winbindd[15759]: bind_callback: ldap_sasl_interactive_bind_s() call returned -2, kerberos code is 0 > Nov 20 14:01:29 signfinity winbindd[15759]: [2012/11/20 14:01:29.618787, 0] ../source3/lib/smbldap.c:998(smbldap_connect_system) > Nov 20 14:01:29 signfinity winbindd[15759]: failed to bind to server ldapi://%2fvar%2frun%2fslapd-IPA-TEAM.socket with dn="[Anonymous bind]" Error: Local error > Nov 20 14:01:29 signfinity winbindd[15759]: #011SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid > > After patching it now looks like this: > Nov 20 15:00:04 signfinity winbindd[18693]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid) > Nov 20 15:00:04 signfinity winbindd[18693]: [2012/11/20 15:00:04.403051, 0] ipa_sam.c:3829(bind_callback) > Nov 20 15:00:04 signfinity winbindd[18693]: bind_callback: ldap_sasl_interactive_bind_s() call returned -2, kerberos code is 0 > Nov 20 15:00:20 signfinity winbindd[18693]: [2012/11/20 15:00:20.090270, 0] ipa_sam.c:3829(bind_callback) > Nov 20 15:00:20 signfinity winbindd[18693]: bind_callback: ldap_sasl_interactive_bind_s() call returned 0, kerberos code is 0 > > as you can see, winbindd has recovered automatically. ACK Simo. -- Simo Sorce * Red Hat, Inc * New York From pspacek at redhat.com Tue Nov 20 14:38:02 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 20 Nov 2012 15:38:02 +0100 Subject: [Freeipa-devel] [PATCH 0094] Use memory allocation macros more extensively - part 1 In-Reply-To: <1353420719.25375.90.camel@willson.li.ssimo.org> References: <50AB4AD1.8050108@redhat.com> <1353420719.25375.90.camel@willson.li.ssimo.org> Message-ID: <50AB95CA.1040609@redhat.com> On 11/20/2012 03:11 PM, Simo Sorce wrote: > On Tue, 2012-11-20 at 10:18 +0100, Petr Spacek wrote: >> Hello, >> >> Use memory allocation macros more extensively. >> >> Some scattered occurences of isc_mem_* functions was replaced by macros. >> Destroy_ldap_instance() now accepts NULL LDAP instance. >> >> String functions from str.c are still calling isc_mem_directly. >> >> This patch contain small subset of changes which affect new_ldap_instance() >> and destroy_ldap_instance() calls. Remaining changes do not require changes in >> new_*/destroy_* logic and will follow in separate patch. > > Hi Petr, > I am not sure what are ISC conventions, but in general Macros that > change program flow are quite dangerous *unless* you prominently make > clear that that's what they are doing. > > So if you return or goto in a macro I suggest you make RETURN and GOTO > part of the name, otherwise inspection of the code will easily make > someone not notice that. > > This can easily lead to memory leaks where you do not notice a > return/goto macro and the condition happen, as well as more serious > issues, like not seeing a return/goto after you obtained a lock or a > mutex and so on. > > In general I would really avoid 'return' in a macro and at most do gotos > to some explicit label you can pass as argument of the macro. > > Simo. Hello, regarding the danger you described - I agree. We have following convention: CHECK* macros will jump to hardcoded label "cleanup" if something went wrong. Idea of cleanup section for "exception handling" came from ISC code (I guess). Bind-dyndb-ldap plugin has CHECK* macros since 2009-07-31 at least and it is used on approximately 300 places. I just reused it on several new places. The final result - more failures will be logged when my next patches will be applied. -- Petr^2 Spacek From nalin at redhat.com Tue Nov 20 15:27:30 2012 From: nalin at redhat.com (Nalin Dahyabhai) Date: Tue, 20 Nov 2012 10:27:30 -0500 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50AB80B4.1060703@redhat.com> References: <50A5C6D8.8030509@redhat.com> <20121116145736.GA30716@redhat.com> <50A6674A.9020606@redhat.com> <50AB80B4.1060703@redhat.com> Message-ID: <20121120152730.GA5966@redhat.com> On Tue, Nov 20, 2012 at 02:08:04PM +0100, Martin Kosek wrote: > 4) nsslapd-pluginbetxn is not set for schema compatibility plugin after upgrade: > > # Schema Compatibility, plugins, config > dn: cn=Schema Compatibility,cn=plugins,cn=config > nsslapd-pluginId: schema-compat-plugin > cn: Schema Compatibility > objectClass: top > objectClass: nsSlapdPlugin > objectClass: extensibleObject > nsslapd-pluginDescription: Schema Compatibility Plugin > nsslapd-pluginEnabled: on > nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > nsslapd-pluginVersion: 0.44 (betxn support available and enabled by default) > nsslapd-pluginVendor: redhat.com > nsslapd-pluginType: object > nsslapd-pluginInitfunc: schema_compat_plugin_init > > This is supposed to be enabled by default, judging by nsslapd-pluginVersion > description, but this may create an inconsistency between new installs and > upgraded IPA servers. > > The same issue applies to IPA server with NIS plugin enabled. Which version of IPA is it that starts explicitly configuring "nsslapd-pluginbetxn" values for plugins? For Fedora, at least, are there cases where we're going from a version that didn't configure that setting to a version that does configure it, as an update within a single release? If not, I can make the default change depending on which release we're building for, and we'll be fine. If that sort of upgrade is expected, though, the package will probably need to start conflicting with versions of IPA that don't configure "nsslapd-pluginbetxn" one way or the other, because there's no default value that's guaranteed to be safe. Nalin From mkosek at redhat.com Tue Nov 20 15:37:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 20 Nov 2012 16:37:24 +0100 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <20121120152730.GA5966@redhat.com> References: <50A5C6D8.8030509@redhat.com> <20121116145736.GA30716@redhat.com> <50A6674A.9020606@redhat.com> <50AB80B4.1060703@redhat.com> <20121120152730.GA5966@redhat.com> Message-ID: <50ABA3B4.2050405@redhat.com> On 11/20/2012 04:27 PM, Nalin Dahyabhai wrote: > On Tue, Nov 20, 2012 at 02:08:04PM +0100, Martin Kosek wrote: >> 4) nsslapd-pluginbetxn is not set for schema compatibility plugin after upgrade: >> >> # Schema Compatibility, plugins, config >> dn: cn=Schema Compatibility,cn=plugins,cn=config >> nsslapd-pluginId: schema-compat-plugin >> cn: Schema Compatibility >> objectClass: top >> objectClass: nsSlapdPlugin >> objectClass: extensibleObject >> nsslapd-pluginDescription: Schema Compatibility Plugin >> nsslapd-pluginEnabled: on >> nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/schemacompat-plugin.so >> nsslapd-pluginVersion: 0.44 (betxn support available and enabled by default) >> nsslapd-pluginVendor: redhat.com >> nsslapd-pluginType: object >> nsslapd-pluginInitfunc: schema_compat_plugin_init >> >> This is supposed to be enabled by default, judging by nsslapd-pluginVersion >> description, but this may create an inconsistency between new installs and >> upgraded IPA servers. >> >> The same issue applies to IPA server with NIS plugin enabled. > > Which version of IPA is it that starts explicitly configuring > "nsslapd-pluginbetxn" values for plugins? We explicitly started to set it to off in ea4f60b15a2743eb61f27ccd33d7bed17552eade, i.e. FreeIPA 3.0.x in F18. The plan is to set it to on with Rob's patch 1072 in FreeIPA 3.1. > > For Fedora, at least, are there cases where we're going from a version > that didn't configure that setting to a version that does configure it, > as an update within a single release? If not, I can make the default > change depending on which release we're building for, and we'll be fine. > If that sort of upgrade is expected, though, the package will probably > need to start conflicting with versions of IPA that don't configure > "nsslapd-pluginbetxn" one way or the other, because there's no default > value that's guaranteed to be safe. > > Nalin > Such update may make it more bulletproof. Bug I think that we should be OK as long as the default betxn support is enabled in Fedora 18 or later (which it is) because there should be no FreeIPA 2.x release (nsslapd-pluginbetxn not set) there. Martin From rcritten at redhat.com Tue Nov 20 15:47:58 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Nov 2012 10:47:58 -0500 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50ABA3B4.2050405@redhat.com> References: <50A5C6D8.8030509@redhat.com> <20121116145736.GA30716@redhat.com> <50A6674A.9020606@redhat.com> <50AB80B4.1060703@redhat.com> <20121120152730.GA5966@redhat.com> <50ABA3B4.2050405@redhat.com> Message-ID: <50ABA62E.5060108@redhat.com> Martin Kosek wrote: > On 11/20/2012 04:27 PM, Nalin Dahyabhai wrote: >> On Tue, Nov 20, 2012 at 02:08:04PM +0100, Martin Kosek wrote: >>> 4) nsslapd-pluginbetxn is not set for schema compatibility plugin after upgrade: >>> >>> # Schema Compatibility, plugins, config >>> dn: cn=Schema Compatibility,cn=plugins,cn=config >>> nsslapd-pluginId: schema-compat-plugin >>> cn: Schema Compatibility >>> objectClass: top >>> objectClass: nsSlapdPlugin >>> objectClass: extensibleObject >>> nsslapd-pluginDescription: Schema Compatibility Plugin >>> nsslapd-pluginEnabled: on >>> nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/schemacompat-plugin.so >>> nsslapd-pluginVersion: 0.44 (betxn support available and enabled by default) >>> nsslapd-pluginVendor: redhat.com >>> nsslapd-pluginType: object >>> nsslapd-pluginInitfunc: schema_compat_plugin_init >>> >>> This is supposed to be enabled by default, judging by nsslapd-pluginVersion >>> description, but this may create an inconsistency between new installs and >>> upgraded IPA servers. >>> >>> The same issue applies to IPA server with NIS plugin enabled. >> >> Which version of IPA is it that starts explicitly configuring >> "nsslapd-pluginbetxn" values for plugins? > > We explicitly started to set it to off in > ea4f60b15a2743eb61f27ccd33d7bed17552eade, i.e. FreeIPA 3.0.x in F18. The plan > is to set it to on with Rob's patch 1072 in FreeIPA 3.1. > >> >> For Fedora, at least, are there cases where we're going from a version >> that didn't configure that setting to a version that does configure it, >> as an update within a single release? If not, I can make the default >> change depending on which release we're building for, and we'll be fine. >> If that sort of upgrade is expected, though, the package will probably >> need to start conflicting with versions of IPA that don't configure >> "nsslapd-pluginbetxn" one way or the other, because there's no default >> value that's guaranteed to be safe. >> >> Nalin >> > > Such update may make it more bulletproof. Bug I think that we should be OK as > long as the default betxn support is enabled in Fedora 18 or later (which it > is) because there should be no FreeIPA 2.x release (nsslapd-pluginbetxn not > set) there. > > Martin > I had intended to always enable it with this patch (but I screwed it up somehow). I'm fine having this as an IPA responsibility. If you want to make it the default in slapi-nis too that would be fine, and is probably a good idea since transactions are enabled by default in 1.3, but I want to be explicit in IPA. rob From pvoborni at redhat.com Tue Nov 20 16:46:24 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Nov 2012 17:46:24 +0100 Subject: [Freeipa-devel] [PATCH] 227 Editable sshkey field after upgrade In-Reply-To: <50AB51E8.9040607@redhat.com> References: <50AA284C.3060001@redhat.com> <50AB51E8.9040607@redhat.com> Message-ID: <50ABB3E0.4050602@redhat.com> On 11/20/2012 10:48 AM, Jan Cholasta wrote: > Hi, > > On 19.11.2012 13:38, Petr Vobornik wrote: >> After upgrade, sshkeys of existing users and hosts are not editable >> because attribute level rights are not send to Web UI due to lack of >> ipasshuser object class. >> >> 'w_if_no_aci' attribute flag was introduced to bypass this issue. It >> makes attribute writable when AttributeLevelRights are not present. It >> was set for sshkeys_field. >> >> https://fedorahosted.org/freeipa/ticket/3260 >> > > I think that ipaexternalmember, gidnumber and macaddress attributes > might cause trouble as well. They are all in objectclasses that are > added to objects on-demand (like ipasshuser/ipasshhost is). > > Honza > Thanks for the catch. There is a problem with macaddress. Ipaexternalmember and gid number aren't affected because group is converted by actions, not by editing a field. I additionally conditioned the write exception on having write rights for objectclass. Update will fail without it. Updated patch attached. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0227-1-Editable-sshkey-field-after-upgrade.patch Type: text/x-patch Size: 3046 bytes Desc: not available URL: From pvoborni at redhat.com Tue Nov 20 17:14:00 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Nov 2012 18:14:00 +0100 Subject: [Freeipa-devel] [PATCH] 238 WebUI: Change of default value of type of new group back to POSIX Message-ID: <50ABBA58.9070809@redhat.com> In FreeIPA 2.2, the default for group type was 'POSIX', in 3.0 it's 'normal' (non-posix). CLI's default is 'POSIX', Web UI should use 'POSIX' as well. https://fedorahosted.org/freeipa/ticket/3270 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0238-WebUI-Change-of-default-value-of-type-of-new-group-b.patch Type: text/x-patch Size: 1122 bytes Desc: not available URL: From simo at redhat.com Tue Nov 20 18:35:11 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Nov 2012 13:35:11 -0500 Subject: [Freeipa-devel] [PATCH] 238 WebUI: Change of default value of type of new group back to POSIX In-Reply-To: <50ABBA58.9070809@redhat.com> References: <50ABBA58.9070809@redhat.com> Message-ID: <1353436511.25995.7.camel@willson.li.ssimo.org> On Tue, 2012-11-20 at 18:14 +0100, Petr Vobornik wrote: > In FreeIPA 2.2, the default for group type was 'POSIX', in 3.0 it's > 'normal' (non-posix). CLI's default is 'POSIX', Web UI should use > 'POSIX' as well. > > https://fedorahosted.org/freeipa/ticket/3270 I see you just opened this, but IIRC the change was somewhat intentional because you can go non-posix -> posix but you can't do the reverse. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Nov 20 20:24:42 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Nov 2012 15:24:42 -0500 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50AB80B4.1060703@redhat.com> References: <50A5C6D8.8030509@redhat.com> <20121116145736.GA30716@redhat.com> <50A6674A.9020606@redhat.com> <50AB80B4.1060703@redhat.com> Message-ID: <50ABE70A.9060200@redhat.com> Martin Kosek wrote: > On 11/16/2012 05:18 PM, Rob Crittenden wrote: >> Nalin Dahyabhai wrote: >>> On Thu, Nov 15, 2012 at 11:53:44PM -0500, Rob Crittenden wrote: >>>> In order for this to work you'll need to apply the last two patches >>>> (both 0001) to slapi-nis and spin it up yourself, otherwise you'll >>>> have serious deadlock issues. I know this is extra work but this >>>> patch is potentially disruptive so I figure the earlier it is out >>>> the better. >>>> >>>> Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may >>>> have been too aggressive in my cleanup. >>>> >>>> Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? >>>> >>>> Once we have an official slapi-nis build with these patches we'll >>>> need to set the minimum n-v-r in our spec file. >>> >>> Rob, the original patch was already applied. I since reworked large >>> parts of how it was organized to make it easier for me to read, and >>> tagged the result as 0.43. Have you tested the IPA changes in >>> combination with the 0.44 builds from either ipa-devel or Fedora 18's >>> updates-testing repository? >>> >>> Nalin >>> >> >> I tested the 0.44 build and things are looking good. I'm not deadlocking, so I >> guess that's the desired out come :-) >> >> I bulk loaded a few thousand users and groups and tested the compat and NIS >> plugins and the data appears correct. >> >> Updated patch with minimum n-v-r in spec attached. >> >> rob >> > > Good job, this closes a lot of tickets! I am now also able to run tests without > having to set wait_for_attr env config first! > > The patch generally seems to work OK, I tried it even with a replica without > transactions enabled and so far so good. I have found just few issues: > > 1) Patch needs a mild rebase (spec file conflict) Done. > > 2) One Unit test failure slipped: > > ====================================================================== > FAIL: test_permission[22]: permission_find: Search for permissions by attr with > a limit of 1 (truncated) I hadn't noticed this one because the memberof for the role wasn't being updated. I added a task that runs in the updates and that fixed it. > 3) Question - what is the reason of keeping wait_for_attr sections in our code? > I may miss something, but I see no difference with api.env.wait_for_attr > enabled... AFAIU, there should not even be any difference as all attributes > should be filled in one transaction, so I would rather remove this flag from > both code and man page. Was just hedging my bets. You're right though, it makes no sense when we have transactions. I've removed it. > 4) nsslapd-pluginbetxn is not set for schema compatibility plugin after upgrade: > > # Schema Compatibility, plugins, config > dn: cn=Schema Compatibility,cn=plugins,cn=config > nsslapd-pluginId: schema-compat-plugin > cn: Schema Compatibility > objectClass: top > objectClass: nsSlapdPlugin > objectClass: extensibleObject > nsslapd-pluginDescription: Schema Compatibility Plugin > nsslapd-pluginEnabled: on > nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/schemacompat-plugin.so > nsslapd-pluginVersion: 0.44 (betxn support available and enabled by default) > nsslapd-pluginVendor: redhat.com > nsslapd-pluginType: object > nsslapd-pluginInitfunc: schema_compat_plugin_init > > This is supposed to be enabled by default, judging by nsslapd-pluginVersion > description, but this may create an inconsistency between new installs and > upgraded IPA servers. > > The same issue applies to IPA server with NIS plugin enabled. Yeah, I fixed the ldif but had not added an update for these. I had to declare a new option for the updater, onlyifexist, which will force a value in an attribute only if the entry already exists. I need this to be sure that the only value for betxn is on. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-1072-3-transaction.patch Type: text/x-patch Size: 36723 bytes Desc: not available URL: From rcritten at redhat.com Tue Nov 20 20:26:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 20 Nov 2012 15:26:54 -0500 Subject: [Freeipa-devel] [PATCH] 238 WebUI: Change of default value of type of new group back to POSIX In-Reply-To: <1353436511.25995.7.camel@willson.li.ssimo.org> References: <50ABBA58.9070809@redhat.com> <1353436511.25995.7.camel@willson.li.ssimo.org> Message-ID: <50ABE78E.2060404@redhat.com> Simo Sorce wrote: > On Tue, 2012-11-20 at 18:14 +0100, Petr Vobornik wrote: >> In FreeIPA 2.2, the default for group type was 'POSIX', in 3.0 it's >> 'normal' (non-posix). CLI's default is 'POSIX', Web UI should use >> 'POSIX' as well. >> >> https://fedorahosted.org/freeipa/ticket/3270 > > I see you just opened this, but IIRC the change was somewhat intentional > because you can go non-posix -> posix but you can't do the reverse. > > Simo. > We either need this or do it for the cli as well. It currently creates posix groups by default. Reversing the cli would have to deprecate the --nonposix option. rob From simo at redhat.com Tue Nov 20 20:59:05 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Nov 2012 15:59:05 -0500 Subject: [Freeipa-devel] [PATCH] 238 WebUI: Change of default value of type of new group back to POSIX In-Reply-To: <50ABE78E.2060404@redhat.com> References: <50ABBA58.9070809@redhat.com> <1353436511.25995.7.camel@willson.li.ssimo.org> <50ABE78E.2060404@redhat.com> Message-ID: <1353445145.25995.16.camel@willson.li.ssimo.org> On Tue, 2012-11-20 at 15:26 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 2012-11-20 at 18:14 +0100, Petr Vobornik wrote: > >> In FreeIPA 2.2, the default for group type was 'POSIX', in 3.0 it's > >> 'normal' (non-posix). CLI's default is 'POSIX', Web UI should use > >> 'POSIX' as well. > >> > >> https://fedorahosted.org/freeipa/ticket/3270 > > > > I see you just opened this, but IIRC the change was somewhat intentional > > because you can go non-posix -> posix but you can't do the reverse. > > > > Simo. > > > > We either need this or do it for the cli as well. It currently creates > posix groups by default. Reversing the cli would have to deprecate the > --nonposix option. I do not want to force one way or another, but I saw this characterized as regression and wanted to make sure we are on the same page. Simo. -- Simo Sorce * Red Hat, Inc * New York From pvoborni at redhat.com Wed Nov 21 09:09:19 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 21 Nov 2012 10:09:19 +0100 Subject: [Freeipa-devel] [PATCH] 238 WebUI: Change of default value of type of new group back to POSIX In-Reply-To: <1353436511.25995.7.camel@willson.li.ssimo.org> References: <50ABBA58.9070809@redhat.com> <1353436511.25995.7.camel@willson.li.ssimo.org> Message-ID: <50AC9A3F.90302@redhat.com> On 11/20/2012 07:35 PM, Simo Sorce wrote: > On Tue, 2012-11-20 at 18:14 +0100, Petr Vobornik wrote: >> In FreeIPA 2.2, the default for group type was 'POSIX', in 3.0 it's >> 'normal' (non-posix). CLI's default is 'POSIX', Web UI should use >> 'POSIX' as well. >> >> https://fedorahosted.org/freeipa/ticket/3270 > > I see you just opened this, but IIRC the change was somewhat intentional > because you can go non-posix -> posix but you can't do the reverse. > > Simo. > It wasn't strictly intentional, but it was a contributing factor. Anyway the default, both in CLI and Web UI, should be the most used group type. AFAIK it's posix. -- Petr Vobornik From mkosek at redhat.com Wed Nov 21 09:46:48 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Nov 2012 10:46:48 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50AB8CCB.7020302@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> Message-ID: <50ACA308.4020207@redhat.com> On 11/20/2012 02:59 PM, Petr Viktorin wrote: > On 11/19/2012 03:14 PM, Petr Viktorin wrote: >> On 11/19/2012 02:09 PM, Martin Kosek wrote: >>> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>>> changed Dogtag >>>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>>> rebased patch. >>>>>>>> >>>>>>>> Note that to continue development on f17, you will need to use the >>>>>>>> dogtag-devel >>>>>>>> repo: >>>>>>>> sudo yum-config-manager >>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>>> [...] >>>>>>>>> >>>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>>> repository. >>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>>> >>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I started reviewing the patches, and found the first thing that looks >>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>>> single-database >>>>>>> IPA, the upgrade was OK. >>>>>>> >>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>>> removed >>>>>>> because >>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>>> instances running. >>>>>> >>>>>> You're right. This is an uninstaller error already present in 2.2: >>>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>>> >>>>>> I'll start looking into it tomorrow, if nothing more important >>>>>> shows up. >>>>>> >>>>> >>>>> Thanks for the pointer. But this is definitely not a show stopper, >>>>> running >>>>> additional DS instance seems more or less benign and as you pointed >>>>> out, it is >>>>> rather an old bug. >>>>> >>>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>>> additional replication agreements in IPA dirsrv instance (although >>>>> targeted to >>>>> nsDS5ReplicaRoot: o=ipaca). >>>>> >>>>> First scenario: 3 IPA servers with CA in this topology: >>>>> >>>>> B - A - C >>>>> >>>>> On A: >>>>> # ipa-replica-manage list `hostname` >>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>> >>>>> it should not display agreements that are for IPA only, not IPA CA >>>>> ones. >>>>> >>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>>> [B] # ipa-replica-manage connect C >>>>> Connected 'B' to 'C' >>>>> >>>>> This changed the topology to: >>>>> A >>>>> / \ >>>>> B - C >>>>> >>>>> But ipa-csreplica-manage connect did not succeed then: >>>>> [B] # ipa-csreplica-manage connect C >>>>> Directory Manager password: >>>>> >>>>> This replication agreement already exists. >>>>> >>>>> Del command also failed for me: >>>>> [A] ipa-replica-manage del [C] >>>>> >>>>> Still trying to investigate why. If I manage to get some workable >>>>> fix during my >>>>> investigations, I will attach it later. >>>>> >>>>> Martin >>>> >>>> The fix for that for easier than expected. Attached patch restored >>>> the previous >>>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>>> commands >>>> - add, del, connect, disconnect and it worked fine so far. >>>> >>>> But this was a case with all D10 masters, I will need to try if that >>>> flies with >>>> D9->D10 replicas or upgraded D9 masters. >>>> >>>> Martin >>>> >>> >>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >>> to work >>> well. I just think we will need to also backport the previous patch at >>> least to >>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >>> management tool. I created a ticket for this purpose: >>> >>> https://fedorahosted.org/freeipa/ticket/3262 >>> >>> Attaching a patch for IPA 2.2 branch in case somebody is also testing >>> it. With >>> this patch, I was able to list, force-sync, re-initialize, connect, >>> disconnect >>> from 2.2 to 3.1 replica without any errors. >>> >>> Martin >>> >> >> I checked ipa-csreplica-install, and found some more problems. >> >> In the "connect" and "disconnect" subcommands we now assume both masters >> use port 389 for the PKI DS. While the number is relatively easily >> parametrized, the assumption that both sides use the same port seems to >> run pretty deep. >> I'm working on a patch to detect if the remote server has merged DBs and >> use the appropriate port. > > Attaching patches to do this. > Patch 0100 adds an argument to IPAdmin to overrides guessing of the protocol to > use. > Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs > involved and use those. > > Note that this touches code shared with ipa-replica-manage, please re-test that > as well. > Works fine, I was able to create a network of few IPA 2.2 replicas and IPA 3.1 replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the agreements. No regression discovered so far. I just see that in patch 101 you touch setup_replication and force TLS as a default. But in this case, r_sslport parameter is never used and we can remove it. In 101, you also set LDAP+TLS as default connection protocol with + super(CSReplicationManager, self).__init__( + realm, hostname, dirman_passwd, port, starttls=True) ^^^^^^^^^^^^^ Wouldn't we want to make LDAP+TLS as a default also in a bunch of ReplicationManager initializations in ipa-replica-manage? Otherwise, we use ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would be a good step to do. Adding Rob and Simo to CC to correct me if I miss anything and we want to keep using ldaps/SSL by default. Martin From mkosek at redhat.com Wed Nov 21 09:48:32 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Nov 2012 10:48:32 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ACA308.4020207@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> Message-ID: <50ACA370.5060903@redhat.com> On 11/21/2012 10:46 AM, Martin Kosek wrote: > On 11/20/2012 02:59 PM, Petr Viktorin wrote: >> On 11/19/2012 03:14 PM, Petr Viktorin wrote: >>> On 11/19/2012 02:09 PM, Martin Kosek wrote: >>>> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>>>> changed Dogtag >>>>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>>>> rebased patch. >>>>>>>>> >>>>>>>>> Note that to continue development on f17, you will need to use the >>>>>>>>> dogtag-devel >>>>>>>>> repo: >>>>>>>>> sudo yum-config-manager >>>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>>>> repository. >>>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>>>> >>>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I started reviewing the patches, and found the first thing that looks >>>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>>>> single-database >>>>>>>> IPA, the upgrade was OK. >>>>>>>> >>>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>>>> removed >>>>>>>> because >>>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>>>> instances running. >>>>>>> >>>>>>> You're right. This is an uninstaller error already present in 2.2: >>>>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>>>> >>>>>>> I'll start looking into it tomorrow, if nothing more important >>>>>>> shows up. >>>>>>> >>>>>> >>>>>> Thanks for the pointer. But this is definitely not a show stopper, >>>>>> running >>>>>> additional DS instance seems more or less benign and as you pointed >>>>>> out, it is >>>>>> rather an old bug. >>>>>> >>>>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>>>> additional replication agreements in IPA dirsrv instance (although >>>>>> targeted to >>>>>> nsDS5ReplicaRoot: o=ipaca). >>>>>> >>>>>> First scenario: 3 IPA servers with CA in this topology: >>>>>> >>>>>> B - A - C >>>>>> >>>>>> On A: >>>>>> # ipa-replica-manage list `hostname` >>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>> >>>>>> it should not display agreements that are for IPA only, not IPA CA >>>>>> ones. >>>>>> >>>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>>>> [B] # ipa-replica-manage connect C >>>>>> Connected 'B' to 'C' >>>>>> >>>>>> This changed the topology to: >>>>>> A >>>>>> / \ >>>>>> B - C >>>>>> >>>>>> But ipa-csreplica-manage connect did not succeed then: >>>>>> [B] # ipa-csreplica-manage connect C >>>>>> Directory Manager password: >>>>>> >>>>>> This replication agreement already exists. >>>>>> >>>>>> Del command also failed for me: >>>>>> [A] ipa-replica-manage del [C] >>>>>> >>>>>> Still trying to investigate why. If I manage to get some workable >>>>>> fix during my >>>>>> investigations, I will attach it later. >>>>>> >>>>>> Martin >>>>> >>>>> The fix for that for easier than expected. Attached patch restored >>>>> the previous >>>>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>>>> commands >>>>> - add, del, connect, disconnect and it worked fine so far. >>>>> >>>>> But this was a case with all D10 masters, I will need to try if that >>>>> flies with >>>>> D9->D10 replicas or upgraded D9 masters. >>>>> >>>>> Martin >>>>> >>>> >>>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >>>> to work >>>> well. I just think we will need to also backport the previous patch at >>>> least to >>>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >>>> management tool. I created a ticket for this purpose: >>>> >>>> https://fedorahosted.org/freeipa/ticket/3262 >>>> >>>> Attaching a patch for IPA 2.2 branch in case somebody is also testing >>>> it. With >>>> this patch, I was able to list, force-sync, re-initialize, connect, >>>> disconnect >>>> from 2.2 to 3.1 replica without any errors. >>>> >>>> Martin >>>> >>> >>> I checked ipa-csreplica-install, and found some more problems. >>> >>> In the "connect" and "disconnect" subcommands we now assume both masters >>> use port 389 for the PKI DS. While the number is relatively easily >>> parametrized, the assumption that both sides use the same port seems to >>> run pretty deep. >>> I'm working on a patch to detect if the remote server has merged DBs and >>> use the appropriate port. >> >> Attaching patches to do this. >> Patch 0100 adds an argument to IPAdmin to overrides guessing of the protocol to >> use. >> Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs >> involved and use those. >> >> Note that this touches code shared with ipa-replica-manage, please re-test that >> as well. >> > > Works fine, I was able to create a network of few IPA 2.2 replicas and IPA 3.1 > replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the > agreements. No regression discovered so far. > > I just see that in patch 101 you touch setup_replication and force TLS as a > default. But in this case, r_sslport parameter is never used and we can remove it. > > In 101, you also set LDAP+TLS as default connection protocol with > + super(CSReplicationManager, self).__init__( > + realm, hostname, dirman_passwd, port, starttls=True) > ^^^^^^^^^^^^^ > > Wouldn't we want to make LDAP+TLS as a default also in a bunch of > ReplicationManager initializations in ipa-replica-manage? Otherwise, we use > ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would > be a good step to do. Adding Rob and Simo to CC to correct me if I miss > anything and we want to keep using ldaps/SSL by default. ... adding to CC now! Martin From pviktori at redhat.com Wed Nov 21 09:54:03 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 21 Nov 2012 10:54:03 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ACA370.5060903@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> <50ACA370.5060903@redhat.com> Message-ID: <50ACA4BB.1070107@redhat.com> On 11/21/2012 10:48 AM, Martin Kosek wrote: > On 11/21/2012 10:46 AM, Martin Kosek wrote: >> On 11/20/2012 02:59 PM, Petr Viktorin wrote: >>> On 11/19/2012 03:14 PM, Petr Viktorin wrote: >>>> On 11/19/2012 02:09 PM, Martin Kosek wrote: >>>>> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>>>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>>>>> changed Dogtag >>>>>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>>>>> rebased patch. >>>>>>>>>> >>>>>>>>>> Note that to continue development on f17, you will need to use the >>>>>>>>>> dogtag-devel >>>>>>>>>> repo: >>>>>>>>>> sudo yum-config-manager >>>>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>>>>> [...] >>>>>>>>>>> >>>>>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>>>>> repository. >>>>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>>>>> >>>>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> I started reviewing the patches, and found the first thing that looks >>>>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>>>>> single-database >>>>>>>>> IPA, the upgrade was OK. >>>>>>>>> >>>>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>>>>> removed >>>>>>>>> because >>>>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>>>>> instances running. >>>>>>>> >>>>>>>> You're right. This is an uninstaller error already present in 2.2: >>>>>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>>>>> >>>>>>>> I'll start looking into it tomorrow, if nothing more important >>>>>>>> shows up. >>>>>>>> >>>>>>> >>>>>>> Thanks for the pointer. But this is definitely not a show stopper, >>>>>>> running >>>>>>> additional DS instance seems more or less benign and as you pointed >>>>>>> out, it is >>>>>>> rather an old bug. >>>>>>> >>>>>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>>>>> additional replication agreements in IPA dirsrv instance (although >>>>>>> targeted to >>>>>>> nsDS5ReplicaRoot: o=ipaca). >>>>>>> >>>>>>> First scenario: 3 IPA servers with CA in this topology: >>>>>>> >>>>>>> B - A - C >>>>>>> >>>>>>> On A: >>>>>>> # ipa-replica-manage list `hostname` >>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>> >>>>>>> it should not display agreements that are for IPA only, not IPA CA >>>>>>> ones. >>>>>>> >>>>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>>>>> [B] # ipa-replica-manage connect C >>>>>>> Connected 'B' to 'C' >>>>>>> >>>>>>> This changed the topology to: >>>>>>> A >>>>>>> / \ >>>>>>> B - C >>>>>>> >>>>>>> But ipa-csreplica-manage connect did not succeed then: >>>>>>> [B] # ipa-csreplica-manage connect C >>>>>>> Directory Manager password: >>>>>>> >>>>>>> This replication agreement already exists. >>>>>>> >>>>>>> Del command also failed for me: >>>>>>> [A] ipa-replica-manage del [C] >>>>>>> >>>>>>> Still trying to investigate why. If I manage to get some workable >>>>>>> fix during my >>>>>>> investigations, I will attach it later. >>>>>>> >>>>>>> Martin >>>>>> >>>>>> The fix for that for easier than expected. Attached patch restored >>>>>> the previous >>>>>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>>>>> commands >>>>>> - add, del, connect, disconnect and it worked fine so far. >>>>>> >>>>>> But this was a case with all D10 masters, I will need to try if that >>>>>> flies with >>>>>> D9->D10 replicas or upgraded D9 masters. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >>>>> to work >>>>> well. I just think we will need to also backport the previous patch at >>>>> least to >>>>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >>>>> management tool. I created a ticket for this purpose: >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/3262 >>>>> >>>>> Attaching a patch for IPA 2.2 branch in case somebody is also testing >>>>> it. With >>>>> this patch, I was able to list, force-sync, re-initialize, connect, >>>>> disconnect >>>>> from 2.2 to 3.1 replica without any errors. >>>>> >>>>> Martin >>>>> >>>> >>>> I checked ipa-csreplica-install, and found some more problems. >>>> >>>> In the "connect" and "disconnect" subcommands we now assume both masters >>>> use port 389 for the PKI DS. While the number is relatively easily >>>> parametrized, the assumption that both sides use the same port seems to >>>> run pretty deep. >>>> I'm working on a patch to detect if the remote server has merged DBs and >>>> use the appropriate port. >>> >>> Attaching patches to do this. >>> Patch 0100 adds an argument to IPAdmin to overrides guessing of the protocol to >>> use. >>> Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs >>> involved and use those. >>> >>> Note that this touches code shared with ipa-replica-manage, please re-test that >>> as well. >>> >> >> Works fine, I was able to create a network of few IPA 2.2 replicas and IPA 3.1 >> replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the >> agreements. No regression discovered so far. >> >> I just see that in patch 101 you touch setup_replication and force TLS as a >> default. But in this case, r_sslport parameter is never used and we can remove it. >> >> In 101, you also set LDAP+TLS as default connection protocol with >> + super(CSReplicationManager, self).__init__( >> + realm, hostname, dirman_passwd, port, starttls=True) >> ^^^^^^^^^^^^^ >> >> Wouldn't we want to make LDAP+TLS as a default also in a bunch of >> ReplicationManager initializations in ipa-replica-manage? Otherwise, we use >> ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would >> be a good step to do. Adding Rob and Simo to CC to correct me if I miss >> anything and we want to keep using ldaps/SSL by default. > ... adding to CC now! > Yes, that would be good. I think it's out of scope for this patchset, though. Do we have a bug for this already? I think John or I can include it in the https://fedorahosted.org/freeipa/ticket/2660 or https://fedorahosted.org/freeipa/ticket/2652 efforts. -- Petr? From mkosek at redhat.com Wed Nov 21 12:20:42 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Nov 2012 13:20:42 +0100 Subject: [Freeipa-devel] [PATCH] 0094 better Kerberos error handling in ipasam In-Reply-To: <1353420841.25375.91.camel@willson.li.ssimo.org> References: <20121120140947.GA3357@redhat.com> <1353420841.25375.91.camel@willson.li.ssimo.org> Message-ID: <50ACC71A.6090901@redhat.com> On 11/20/2012 03:14 PM, Simo Sorce wrote: > On Tue, 2012-11-20 at 16:09 +0200, Alexander Bokovoy wrote: >> Hi, >> >> attached patch expands error checks when obtaining Kerberos ticket in >> ipasam module. The change should cover observed corner cases which >> caused ipasam to fail obtaining the ticket. >> >> Without the patch one will get something similar to what I get below >> when manually moving time back on the server (with additional debug >> statements to show error codes): >> Nov 20 14:01:29 signfinity winbindd[15759]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid) >> Nov 20 14:01:29 signfinity winbindd[15759]: [2012/11/20 14:01:29.616951, 0] ipa_sam.c:3829(bind_callback) >> Nov 20 14:01:29 signfinity winbindd[15759]: bind_callback: ldap_sasl_interactive_bind_s() call returned -2, kerberos code is 0 >> Nov 20 14:01:29 signfinity winbindd[15759]: [2012/11/20 14:01:29.618787, 0] ../source3/lib/smbldap.c:998(smbldap_connect_system) >> Nov 20 14:01:29 signfinity winbindd[15759]: failed to bind to server ldapi://%2fvar%2frun%2fslapd-IPA-TEAM.socket with dn="[Anonymous bind]" Error: Local error >> Nov 20 14:01:29 signfinity winbindd[15759]: #011SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid >> >> After patching it now looks like this: >> Nov 20 15:00:04 signfinity winbindd[18693]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid) >> Nov 20 15:00:04 signfinity winbindd[18693]: [2012/11/20 15:00:04.403051, 0] ipa_sam.c:3829(bind_callback) >> Nov 20 15:00:04 signfinity winbindd[18693]: bind_callback: ldap_sasl_interactive_bind_s() call returned -2, kerberos code is 0 >> Nov 20 15:00:20 signfinity winbindd[18693]: [2012/11/20 15:00:20.090270, 0] ipa_sam.c:3829(bind_callback) >> Nov 20 15:00:20 signfinity winbindd[18693]: bind_callback: ldap_sasl_interactive_bind_s() call returned 0, kerberos code is 0 >> >> as you can see, winbindd has recovered automatically. > > ACK > > Simo. > Pushed to master, ipa-3-0. Martin From pviktori at redhat.com Wed Nov 21 12:29:35 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 21 Nov 2012 13:29:35 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50AA5FCC.5090605@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50AA5FCC.5090605@redhat.com> Message-ID: <50ACC92F.1010507@redhat.com> On 11/19/2012 05:35 PM, Martin Kosek wrote: > On 11/15/2012 03:19 PM, Petr Viktorin wrote: >> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >> defaults made it to master independently (91e477b). Attaching rebased patch. >> >> Note that to continue development on f17, you will need to use the dogtag-devel >> repo: >> sudo yum-config-manager >> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >> >> >> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >> [...] >>> >>> For convenience, I've also pushed the changes to a personal repository. >>> To fetch to branch "pviktori-dogtag-10" you can do: >>> >>> git fetch -f git://github.com/encukou/freeipa.git >>> dogtag-10:pviktori-dogtag-10 >>> >> > > I went through all the patches again, I found one more issue with the schema > check. As it binds to Directory Server anonymously when retrieving the schema > and tests if "ipaObject" objectclass is present, it can fail and crash when > anonymous binds are not allowed for the Dogtag DS instance. This is what I get > when I disabled anonymous binds and run ipa-replica-install --setup-ca (a > script to turn anonymous binds off attached): > > [root at vm-104 ~]# ipa-replica-install > replica-info-vm-104.idm.lab.bos.redhat.com.gpg --setup-ca > Directory Manager (existing master) password: > > Run connection check to master > [...] > Connection from master to replica is OK. > > Connection check OK > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > LDAP error: INAPPROPRIATE_AUTH > Anonymous access is not allowed > > If possible, it would be good authenticate first. This should be doable, we > have a Directory Manager password available, after all. Some schema retrieval > code that we already have in IPA can be found in SchemaCache class in ldap2.py. Good point. Attaching updated patch. > We may also want to have some flag similar to --skip-conncheck which would > allow admin with an issue like this one skip the check when he is certain that > he copied the schema files. I named it --skip-schema-check. > Adding Ade to check that this scenario is actually sane and Dogtag is supposed > to work with anonymous access disabled for its DS instance. > > When reading the patches, I also saw few places with magic constant "7389" > (your "Fix schema replication from old masters" patch and Ade's patch). I > wonder, would "dogtag.Dogtag9Constants.DS_PORT" be more readable? Fixed in this patch, I'll look at the other one soon. For anyone who wants to test: I keep my Github branch updated. Re-running the fetch command will overwrite your branch with the latest changes. When the current issues are solved I'll repost all patches again in a single mail. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0095-03-Fix-schema-replication-from-old-masters.patch Type: text/x-patch Size: 12792 bytes Desc: not available URL: From mkosek at redhat.com Wed Nov 21 12:46:22 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Nov 2012 13:46:22 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ACA4BB.1070107@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> <50ACA370.5060903@redhat.com> <50ACA4BB.1070107@redhat.com> Message-ID: <50ACCD1E.7040509@redhat.com> On 11/21/2012 10:54 AM, Petr Viktorin wrote: > On 11/21/2012 10:48 AM, Martin Kosek wrote: >> On 11/21/2012 10:46 AM, Martin Kosek wrote: >>> On 11/20/2012 02:59 PM, Petr Viktorin wrote: >>>> On 11/19/2012 03:14 PM, Petr Viktorin wrote: >>>>> On 11/19/2012 02:09 PM, Martin Kosek wrote: >>>>>> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>>>>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>>>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>>>>>> changed Dogtag >>>>>>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>>>>>> rebased patch. >>>>>>>>>>> >>>>>>>>>>> Note that to continue development on f17, you will need to use the >>>>>>>>>>> dogtag-devel >>>>>>>>>>> repo: >>>>>>>>>>> sudo yum-config-manager >>>>>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>>>>>> [...] >>>>>>>>>>>> >>>>>>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>>>>>> repository. >>>>>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>>>>>> >>>>>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I started reviewing the patches, and found the first thing that looks >>>>>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>>>>>> single-database >>>>>>>>>> IPA, the upgrade was OK. >>>>>>>>>> >>>>>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>>>>>> removed >>>>>>>>>> because >>>>>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>>>>>> instances running. >>>>>>>>> >>>>>>>>> You're right. This is an uninstaller error already present in 2.2: >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>>>>>> >>>>>>>>> I'll start looking into it tomorrow, if nothing more important >>>>>>>>> shows up. >>>>>>>>> >>>>>>>> >>>>>>>> Thanks for the pointer. But this is definitely not a show stopper, >>>>>>>> running >>>>>>>> additional DS instance seems more or less benign and as you pointed >>>>>>>> out, it is >>>>>>>> rather an old bug. >>>>>>>> >>>>>>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>>>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>>>>>> additional replication agreements in IPA dirsrv instance (although >>>>>>>> targeted to >>>>>>>> nsDS5ReplicaRoot: o=ipaca). >>>>>>>> >>>>>>>> First scenario: 3 IPA servers with CA in this topology: >>>>>>>> >>>>>>>> B - A - C >>>>>>>> >>>>>>>> On A: >>>>>>>> # ipa-replica-manage list `hostname` >>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>> >>>>>>>> it should not display agreements that are for IPA only, not IPA CA >>>>>>>> ones. >>>>>>>> >>>>>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>>>>>> [B] # ipa-replica-manage connect C >>>>>>>> Connected 'B' to 'C' >>>>>>>> >>>>>>>> This changed the topology to: >>>>>>>> A >>>>>>>> / \ >>>>>>>> B - C >>>>>>>> >>>>>>>> But ipa-csreplica-manage connect did not succeed then: >>>>>>>> [B] # ipa-csreplica-manage connect C >>>>>>>> Directory Manager password: >>>>>>>> >>>>>>>> This replication agreement already exists. >>>>>>>> >>>>>>>> Del command also failed for me: >>>>>>>> [A] ipa-replica-manage del [C] >>>>>>>> >>>>>>>> Still trying to investigate why. If I manage to get some workable >>>>>>>> fix during my >>>>>>>> investigations, I will attach it later. >>>>>>>> >>>>>>>> Martin >>>>>>> >>>>>>> The fix for that for easier than expected. Attached patch restored >>>>>>> the previous >>>>>>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>>>>>> commands >>>>>>> - add, del, connect, disconnect and it worked fine so far. >>>>>>> >>>>>>> But this was a case with all D10 masters, I will need to try if that >>>>>>> flies with >>>>>>> D9->D10 replicas or upgraded D9 masters. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >>>>>> to work >>>>>> well. I just think we will need to also backport the previous patch at >>>>>> least to >>>>>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >>>>>> management tool. I created a ticket for this purpose: >>>>>> >>>>>> https://fedorahosted.org/freeipa/ticket/3262 >>>>>> >>>>>> Attaching a patch for IPA 2.2 branch in case somebody is also testing >>>>>> it. With >>>>>> this patch, I was able to list, force-sync, re-initialize, connect, >>>>>> disconnect >>>>>> from 2.2 to 3.1 replica without any errors. >>>>>> >>>>>> Martin >>>>>> >>>>> >>>>> I checked ipa-csreplica-install, and found some more problems. >>>>> >>>>> In the "connect" and "disconnect" subcommands we now assume both masters >>>>> use port 389 for the PKI DS. While the number is relatively easily >>>>> parametrized, the assumption that both sides use the same port seems to >>>>> run pretty deep. >>>>> I'm working on a patch to detect if the remote server has merged DBs and >>>>> use the appropriate port. >>>> >>>> Attaching patches to do this. >>>> Patch 0100 adds an argument to IPAdmin to overrides guessing of the >>>> protocol to >>>> use. >>>> Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs >>>> involved and use those. >>>> >>>> Note that this touches code shared with ipa-replica-manage, please re-test >>>> that >>>> as well. >>>> >>> >>> Works fine, I was able to create a network of few IPA 2.2 replicas and IPA 3.1 >>> replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the >>> agreements. No regression discovered so far. >>> >>> I just see that in patch 101 you touch setup_replication and force TLS as a >>> default. But in this case, r_sslport parameter is never used and we can >>> remove it. >>> >>> In 101, you also set LDAP+TLS as default connection protocol with >>> + super(CSReplicationManager, self).__init__( >>> + realm, hostname, dirman_passwd, port, starttls=True) >>> ^^^^^^^^^^^^^ >>> >>> Wouldn't we want to make LDAP+TLS as a default also in a bunch of >>> ReplicationManager initializations in ipa-replica-manage? Otherwise, we use >>> ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would >>> be a good step to do. Adding Rob and Simo to CC to correct me if I miss >>> anything and we want to keep using ldaps/SSL by default. >> ... adding to CC now! >> > > Yes, that would be good. I think it's out of scope for this patchset, though. > Do we have a bug for this already? > I think John or I can include it in the > https://fedorahosted.org/freeipa/ticket/2660 or > https://fedorahosted.org/freeipa/ticket/2652 efforts. > Right, I think we do not have to do this now. I would not include it in 2652, it is too general. I would prefer a separate ticket (if we agree with this change) or inclusion in 2660. On a different note, I tried a scenario of 3.0 split instance IPA master and 3.1 single instance replica and I got an error again: # ipa-replica-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg --setup-ca Directory Manager (existing master) password: ... [28/30]: enabling compatibility plugin [29/30]: tuning directory server [30/30]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/16]: creating certificate server user [2/16]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' # ipa-ca-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg ... Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/15]: creating certificate server user [2/15]: configuring certificate server instance Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-ca-install.log for details: IOError: [Errno 2] No such file or directory: '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' # rpm -q pki-ca pki-ca-10.0.0-0.52.b3.fc18.noarch # tail -1 /var/log/pki/pki-tomcat/ca/system 3357.http-bio-8443-exec-1 - [21/Nov/2012:07:16:02 EST] [8] [3] In Ldap (bound) connection pool to host vm-104.idm.lab.bos.redhat.com port 7389, Cannot connect to LDAP server. Error: netscape.ldap.LDAPException: failed to connect to server ldap://vm-104.idm.lab.bos.redhat.com:7389 (91) But when I try an ldapsearch to this address, it works: # ldapsearch -H "ldap://vm-104.idm.lab.bos.redhat.com:7389" -s base -b "o=ipaca" -D "cn=Directory Manager" -x -w kokos123 # extended LDIF # ipaca dn: o=ipaca objectClass: top objectClass: organization o: ipaca Attaching relevant logs and CC-ing Ade, I think we will need his help on this one. IMO it is important to have this scenario working too, F17 IPA users who'd upgrade to F18 and try to setup a replica may hit the same issue. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: logs.tgz Type: application/x-compressed-tar Size: 39184 bytes Desc: not available URL: From simo at redhat.com Wed Nov 21 13:43:46 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 21 Nov 2012 08:43:46 -0500 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ACA308.4020207@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> Message-ID: <1353505426.25995.24.camel@willson.li.ssimo.org> On Wed, 2012-11-21 at 10:46 +0100, Martin Kosek wrote: > On 11/20/2012 02:59 PM, Petr Viktorin wrote: > > On 11/19/2012 03:14 PM, Petr Viktorin wrote: > >> On 11/19/2012 02:09 PM, Martin Kosek wrote: > >>> On 11/16/2012 02:25 PM, Martin Kosek wrote: > >>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: > >>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: > >>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: > >>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: > >>>>>>>> Recently, the specfile changed (dce53e4) and the patch for > >>>>>>>> changed Dogtag > >>>>>>>> defaults made it to master independently (91e477b). Attaching > >>>>>>>> rebased patch. > >>>>>>>> > >>>>>>>> Note that to continue development on f17, you will need to use the > >>>>>>>> dogtag-devel > >>>>>>>> repo: > >>>>>>>> sudo yum-config-manager > >>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: > >>>>>>>> [...] > >>>>>>>>> > >>>>>>>>> For convenience, I've also pushed the changes to a personal > >>>>>>>>> repository. > >>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: > >>>>>>>>> > >>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git > >>>>>>>>> dogtag-10:pviktori-dogtag-10 > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> I started reviewing the patches, and found the first thing that looks > >>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to > >>>>>>> single-database > >>>>>>> IPA, the upgrade was OK. > >>>>>>> > >>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not > >>>>>>> removed > >>>>>>> because > >>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv > >>>>>>> instances running. > >>>>>> > >>>>>> You're right. This is an uninstaller error already present in 2.2: > >>>>>> https://fedorahosted.org/freeipa/ticket/3258 > >>>>>> > >>>>>> I'll start looking into it tomorrow, if nothing more important > >>>>>> shows up. > >>>>>> > >>>>> > >>>>> Thanks for the pointer. But this is definitely not a show stopper, > >>>>> running > >>>>> additional DS instance seems more or less benign and as you pointed > >>>>> out, it is > >>>>> rather an old bug. > >>>>> > >>>>> There are bigger issues. Now I focused on ipa-replica-manage and > >>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the > >>>>> additional replication agreements in IPA dirsrv instance (although > >>>>> targeted to > >>>>> nsDS5ReplicaRoot: o=ipaca). > >>>>> > >>>>> First scenario: 3 IPA servers with CA in this topology: > >>>>> > >>>>> B - A - C > >>>>> > >>>>> On A: > >>>>> # ipa-replica-manage list `hostname` > >>>>> vm-055.idm.lab.bos.redhat.com: replica > >>>>> vm-070.idm.lab.bos.redhat.com: replica > >>>>> vm-055.idm.lab.bos.redhat.com: replica > >>>>> vm-070.idm.lab.bos.redhat.com: replica > >>>>> > >>>>> it should not display agreements that are for IPA only, not IPA CA > >>>>> ones. > >>>>> > >>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: > >>>>> [B] # ipa-replica-manage connect C > >>>>> Connected 'B' to 'C' > >>>>> > >>>>> This changed the topology to: > >>>>> A > >>>>> / \ > >>>>> B - C > >>>>> > >>>>> But ipa-csreplica-manage connect did not succeed then: > >>>>> [B] # ipa-csreplica-manage connect C > >>>>> Directory Manager password: > >>>>> > >>>>> This replication agreement already exists. > >>>>> > >>>>> Del command also failed for me: > >>>>> [A] ipa-replica-manage del [C] > >>>>> > >>>>> Still trying to investigate why. If I manage to get some workable > >>>>> fix during my > >>>>> investigations, I will attach it later. > >>>>> > >>>>> Martin > >>>> > >>>> The fix for that for easier than expected. Attached patch restored > >>>> the previous > >>>> functionality for ipa-(cs)replica-manage. I tried that with all basic > >>>> commands > >>>> - add, del, connect, disconnect and it worked fine so far. > >>>> > >>>> But this was a case with all D10 masters, I will need to try if that > >>>> flies with > >>>> D9->D10 replicas or upgraded D9 masters. > >>>> > >>>> Martin > >>>> > >>> > >>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem > >>> to work > >>> well. I just think we will need to also backport the previous patch at > >>> least to > >>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication > >>> management tool. I created a ticket for this purpose: > >>> > >>> https://fedorahosted.org/freeipa/ticket/3262 > >>> > >>> Attaching a patch for IPA 2.2 branch in case somebody is also testing > >>> it. With > >>> this patch, I was able to list, force-sync, re-initialize, connect, > >>> disconnect > >>> from 2.2 to 3.1 replica without any errors. > >>> > >>> Martin > >>> > >> > >> I checked ipa-csreplica-install, and found some more problems. > >> > >> In the "connect" and "disconnect" subcommands we now assume both masters > >> use port 389 for the PKI DS. While the number is relatively easily > >> parametrized, the assumption that both sides use the same port seems to > >> run pretty deep. > >> I'm working on a patch to detect if the remote server has merged DBs and > >> use the appropriate port. > > > > Attaching patches to do this. > > Patch 0100 adds an argument to IPAdmin to overrides guessing of the protocol to > > use. > > Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs > > involved and use those. > > > > Note that this touches code shared with ipa-replica-manage, please re-test that > > as well. > > > > Works fine, I was able to create a network of few IPA 2.2 replicas and IPA 3.1 > replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the > agreements. No regression discovered so far. > > I just see that in patch 101 you touch setup_replication and force TLS as a > default. But in this case, r_sslport parameter is never used and we can remove it. > > In 101, you also set LDAP+TLS as default connection protocol with > + super(CSReplicationManager, self).__init__( > + realm, hostname, dirman_passwd, port, starttls=True) > ^^^^^^^^^^^^^ > > Wouldn't we want to make LDAP+TLS as a default also in a bunch of > ReplicationManager initializations in ipa-replica-manage? Otherwise, we use > ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would > be a good step to do. Adding Rob and Simo to CC to correct me if I miss > anything and we want to keep using ldaps/SSL by default. In order of preference: LDAP/GSSAPI LDAP/TLS/ LDAPS but using ldaps is not the end of the world, so don't tie yourself up due to this. Simo. -- Simo Sorce * Red Hat, Inc * New York From pviktori at redhat.com Wed Nov 21 13:59:28 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Wed, 21 Nov 2012 14:59:28 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ACC92F.1010507@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50AA5FCC.5090605@redhat.com> <50ACC92F.1010507@redhat.com> Message-ID: <50ACDE40.5020608@redhat.com> On 11/21/2012 01:29 PM, Petr Viktorin wrote: > On 11/19/2012 05:35 PM, Martin Kosek wrote: [...] >> >> When reading the patches, I also saw few places with magic constant >> "7389" >> (your "Fix schema replication from old masters" patch and Ade's patch). I >> wonder, would "dogtag.Dogtag9Constants.DS_PORT" be more readable? > > Fixed in this patch, I'll look at the other one soon. > Here is Ade's patch with the magic constants removed. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-alee-0001-05-Changes-to-use-a-single-database-for-dogtag-and-IPA.patch Type: text/x-patch Size: 36145 bytes Desc: not available URL: From mkosek at redhat.com Wed Nov 21 14:05:57 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Nov 2012 15:05:57 +0100 Subject: [Freeipa-devel] [PATCH] 1072 enable transaction support In-Reply-To: <50ABE70A.9060200@redhat.com> References: <50A5C6D8.8030509@redhat.com> <20121116145736.GA30716@redhat.com> <50A6674A.9020606@redhat.com> <50AB80B4.1060703@redhat.com> <50ABE70A.9060200@redhat.com> Message-ID: <50ACDFC5.2000206@redhat.com> On 11/20/2012 09:24 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On 11/16/2012 05:18 PM, Rob Crittenden wrote: >>> Nalin Dahyabhai wrote: >>>> On Thu, Nov 15, 2012 at 11:53:44PM -0500, Rob Crittenden wrote: >>>>> In order for this to work you'll need to apply the last two patches >>>>> (both 0001) to slapi-nis and spin it up yourself, otherwise you'll >>>>> have serious deadlock issues. I know this is extra work but this >>>>> patch is potentially disruptive so I figure the earlier it is out >>>>> the better. >>>>> >>>>> Noriko/Rich/Nalin, can you guys review the slapi-nis pieces? I may >>>>> have been too aggressive in my cleanup. >>>>> >>>>> Noriko/Rich, can you review the 389-ds plugin parts of my 1072 patch? >>>>> >>>>> Once we have an official slapi-nis build with these patches we'll >>>>> need to set the minimum n-v-r in our spec file. >>>> >>>> Rob, the original patch was already applied. I since reworked large >>>> parts of how it was organized to make it easier for me to read, and >>>> tagged the result as 0.43. Have you tested the IPA changes in >>>> combination with the 0.44 builds from either ipa-devel or Fedora 18's >>>> updates-testing repository? >>>> >>>> Nalin >>>> >>> >>> I tested the 0.44 build and things are looking good. I'm not deadlocking, so I >>> guess that's the desired out come :-) >>> >>> I bulk loaded a few thousand users and groups and tested the compat and NIS >>> plugins and the data appears correct. >>> >>> Updated patch with minimum n-v-r in spec attached. >>> >>> rob >>> >> >> Good job, this closes a lot of tickets! I am now also able to run tests without >> having to set wait_for_attr env config first! >> >> The patch generally seems to work OK, I tried it even with a replica without >> transactions enabled and so far so good. I have found just few issues: >> >> 1) Patch needs a mild rebase (spec file conflict) > > Done. > >> >> 2) One Unit test failure slipped: >> >> ====================================================================== >> FAIL: test_permission[22]: permission_find: Search for permissions by attr with >> a limit of 1 (truncated) > > I hadn't noticed this one because the memberof for the role wasn't being > updated. I added a task that runs in the updates and that fixed it. > >> 3) Question - what is the reason of keeping wait_for_attr sections in our code? >> I may miss something, but I see no difference with api.env.wait_for_attr >> enabled... AFAIU, there should not even be any difference as all attributes >> should be filled in one transaction, so I would rather remove this flag from >> both code and man page. > > Was just hedging my bets. You're right though, it makes no sense when we have > transactions. I've removed it. > >> 4) nsslapd-pluginbetxn is not set for schema compatibility plugin after upgrade: >> >> # Schema Compatibility, plugins, config >> dn: cn=Schema Compatibility,cn=plugins,cn=config >> nsslapd-pluginId: schema-compat-plugin >> cn: Schema Compatibility >> objectClass: top >> objectClass: nsSlapdPlugin >> objectClass: extensibleObject >> nsslapd-pluginDescription: Schema Compatibility Plugin >> nsslapd-pluginEnabled: on >> nsslapd-pluginPath: /usr/lib64/dirsrv/plugins/schemacompat-plugin.so >> nsslapd-pluginVersion: 0.44 (betxn support available and enabled by default) >> nsslapd-pluginVendor: redhat.com >> nsslapd-pluginType: object >> nsslapd-pluginInitfunc: schema_compat_plugin_init >> >> This is supposed to be enabled by default, judging by nsslapd-pluginVersion >> description, but this may create an inconsistency between new installs and >> upgraded IPA servers. >> >> The same issue applies to IPA server with NIS plugin enabled. > > Yeah, I fixed the ldif but had not added an update for these. > > I had to declare a new option for the updater, onlyifexist, which will force a > value in an attribute only if the entry already exists. I need this to be sure > that the only value for betxn is on. > > rob > Thanks. I think the patch works fine now. ACK, pushed to master. Martin From pspacek at redhat.com Wed Nov 21 14:59:21 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Nov 2012 15:59:21 +0100 Subject: [Freeipa-devel] [PATCH 0099] Remove dead code detected by clang static analyzer Message-ID: <50ACEC49.2020706@redhat.com> Hello, Remove dead code detected by clang static analyzer. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0099-Remove-dead-code-detected-by-clang-static-analyzer.patch Type: text/x-patch Size: 2112 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 21 15:04:09 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Nov 2012 16:04:09 +0100 Subject: [Freeipa-devel] [PATCH 101] Fix error handling in ldap_entry_create() Message-ID: <50ACED69.7030702@redhat.com> Hello, I noticed this problem during investigation of dead code found by Clang. Fix error handling in ldap_entry_create(). Jump to cleanup section after first memory allocation created memory leak which crashed BIND on reload. Missing return value check after ldap_get_dn() call can lead to crash. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0101-Fix-error-handling-in-ldap_entry_create.patch Type: text/x-patch Size: 2452 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 21 15:00:24 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Nov 2012 16:00:24 +0100 Subject: [Freeipa-devel] [PATCH 100] Add macro for LDAP error logging Message-ID: <50ACEC88.2030104@redhat.com> Hello, Add macro for LDAP error logging. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0100-Add-macro-for-LDAP-error-logging.patch Type: text/x-patch Size: 1033 bytes Desc: not available URL: From pspacek at redhat.com Wed Nov 21 16:04:00 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 21 Nov 2012 17:04:00 +0100 Subject: [Freeipa-devel] [PATCH 101] Fix error handling in ldap_entry_create() In-Reply-To: <50ACED69.7030702@redhat.com> References: <50ACED69.7030702@redhat.com> Message-ID: <50ACFB70.7070009@redhat.com> Hello, fixed fix is attached. Clang found bug in the fix but I didn't notice that because of other warnings ... On 11/21/2012 04:04 PM, Petr Spacek wrote: > Hello, > > I noticed this problem during investigation of dead code found by Clang. > > Fix error handling in ldap_entry_create(). > > Jump to cleanup section after first memory allocation created memory leak > which crashed BIND on reload. > > Missing return value check after ldap_get_dn() call can lead to crash. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0101-2-Fix-error-handling-in-ldap_entry_create.patch Type: text/x-patch Size: 2792 bytes Desc: not available URL: From abokovoy at redhat.com Wed Nov 21 16:40:38 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 21 Nov 2012 18:40:38 +0200 Subject: [Freeipa-devel] [PATCH] 0095 Trusts: replace use of python-crypto by m2crypto Message-ID: <20121121164038.GF3357@redhat.com> Hi, attached patch replaces use of python-crypto by m2crypto. We only need either one for RC4 encryption implementation and python-crypto is not available everywhere. Originally we thought to extend python-krbV to provide access to krb5_c_encrypt() but m2crypto is a simpler replacement. Using this patch I was able to re-establish trusts with Windows 2008R2 without any trouble and verified that it worked afterwards for resolving remote users since the code that searches Global Catalog is using the trust auth blob for obtaining Kerberos ticket against AD KDC. -- / Alexander Bokovoy -------------- next part -------------- >From 41bf34a4d6e32a3ae26206a8fe0d088c8b0b95d9 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 21 Nov 2012 18:33:49 +0200 Subject: [PATCH] trusts: replace use of python-crypto by m2crypto python-crypto package is not available everywhere, use m2crypto instead. Originally we thought to extend python-krbV to provide krb5_c_encrypt() wrapper but m2crypto is readily available. https://fedorahosted.org/freeipa/ticket/3271 --- freeipa.spec.in | 7 +++++-- ipaserver/dcerpc.py | 6 +++--- 2 files changed, 8 insertions(+), 5 deletions(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 50e743d809c8e499738c7fe67f853c4c9cea195c..43f4a3af2cb7e00aa19f57da1319a77018bee5e0 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -67,7 +67,7 @@ BuildRequires: sssd >= 1.8.0 BuildRequires: python-lxml BuildRequires: python-pyasn1 >= 0.0.9a BuildRequires: python-dns -BuildRequires: python-crypto +BuildRequires: m2crypto BuildRequires: check BuildRequires: libsss_idmap-devel @@ -181,7 +181,7 @@ daemons included in freeipa-server Summary: Virtual package to install packages required for Active Directory trusts Group: System Environment/Base Requires: %{name}-server = %version-%release -Requires: python-crypto +Requires: m2crypto %if 0%{?fedora} >= 18 Requires: samba-python Requires: samba @@ -733,6 +733,9 @@ fi %ghost %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/ipa/ca.crt %changelog +* Wed Nov 21 2012 Alexander Bokovoy - 3.0.99-6 +- Replace python-crypto by m2crypto dependency + * Fri Nov 16 2012 Rob Crittenden - 3.0.99-5 - Bump minimum version of slapi-nis to 0.44 diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 4eddbcdc304de9e50c5ccb9a71808fb71cf5b844..68b5ad52873753b6c78840c558636c16ea2dd803 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -41,7 +41,7 @@ from samba.ndr import ndr_pack from samba import net import samba import random -from Crypto.Cipher import ARC4 +from M2Crypto import RC4 try: from ldap.controls import RequestControl as LDAPControl #pylint: disable=F0401 except ImportError: @@ -526,8 +526,8 @@ class TrustDomainInstance(object): def generate_auth(self, trustdom_secret): def arcfour_encrypt(key, data): - c = ARC4.new(key) - return c.encrypt(data) + c = RC4.RC4(key) + return c.update(data) def string_to_array(what): blob = [0] * len(what) -- 1.8.0 From rcritten at redhat.com Wed Nov 21 17:01:27 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 21 Nov 2012 12:01:27 -0500 Subject: [Freeipa-devel] [PATCH] 0095 Trusts: replace use of python-crypto by m2crypto In-Reply-To: <20121121164038.GF3357@redhat.com> References: <20121121164038.GF3357@redhat.com> Message-ID: <50AD08E7.3030901@redhat.com> Alexander Bokovoy wrote: > Hi, > > attached patch replaces use of python-crypto by m2crypto. We only need > either one for RC4 encryption implementation and python-crypto is not > available everywhere. > > Originally we thought to extend python-krbV to provide access to > krb5_c_encrypt() but m2crypto is a simpler replacement. > > Using this patch I was able to re-establish trusts with Windows 2008R2 > without any trouble and verified that it worked afterwards for resolving > remote users since the code that searches Global Catalog is using the trust > auth blob for obtaining Kerberos ticket against AD KDC. ACK, pushed to master and ipa-3-0. rob From pspacek at redhat.com Thu Nov 22 08:36:34 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Nov 2012 09:36:34 +0100 Subject: [Freeipa-devel] [PATCH 0102] Fix error reporting for different TTLs in findrdatatype_or_create() Message-ID: <50ADE412.2080200@redhat.com> Hello, Fix error reporting for different TTLs in findrdatatype_or_create(). Old code returned ISC_R_SUCCESS even in unsupported case. Bug found by Clang static code analysis. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0102-Fix-error-reporting-for-different-TTLs-in-findrdatat.patch Type: text/x-patch Size: 1191 bytes Desc: not available URL: From pspacek at redhat.com Thu Nov 22 08:56:12 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Nov 2012 09:56:12 +0100 Subject: [Freeipa-devel] [PATCH 101] Fix error handling in ldap_entry_create() In-Reply-To: <50ACFB70.7070009@redhat.com> References: <50ACED69.7030702@redhat.com> <50ACFB70.7070009@redhat.com> Message-ID: <50ADE8AC.2090006@redhat.com> Hello, apparently I was very tired yesterday ... Cleaned version of the patch is attached. Petr^2 Spacek On 11/21/2012 05:04 PM, Petr Spacek wrote: > Hello, > > fixed fix is attached. Clang found bug in the fix but I didn't notice that > because of other warnings ... > > On 11/21/2012 04:04 PM, Petr Spacek wrote: >> Hello, >> >> I noticed this problem during investigation of dead code found by Clang. >> >> Fix error handling in ldap_entry_create(). >> >> Jump to cleanup section after first memory allocation created memory leak >> which crashed BIND on reload. >> >> Missing return value check after ldap_get_dn() call can lead to crash. -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0101-3-Fix-error-handling-in-ldap_entry_create.patch Type: text/x-patch Size: 1768 bytes Desc: not available URL: From pspacek at redhat.com Thu Nov 22 09:28:27 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Nov 2012 10:28:27 +0100 Subject: [Freeipa-devel] [PATCH 0103] Remove dead assignments in manager_create_db_instance() and make log messages verbose Message-ID: <50ADF03B.6040104@redhat.com> Hello, Remove dead assignments in manager_create_db_instance() and make log messages verbose. Dead assignments were reported by Clang static code analysis. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0103-Remove-dead-assignments-in-manager_create_db_instanc.patch Type: text/x-patch Size: 1579 bytes Desc: not available URL: From pspacek at redhat.com Thu Nov 22 09:57:38 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Nov 2012 10:57:38 +0100 Subject: [Freeipa-devel] [PATCH 0104] Remove dead assignment and add logging to ldap_pool_connect() Message-ID: <50ADF712.80004@redhat.com> Hello, Remove dead assignment and add logging to ldap_pool_connect(). Dead assignment was reported by Clang static code analysis. -- Petr^2 Spacek From mkosek at redhat.com Thu Nov 22 10:01:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 22 Nov 2012 11:01:11 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ACC92F.1010507@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50AA5FCC.5090605@redhat.com> <50ACC92F.1010507@redhat.com> Message-ID: <50ADF7E7.8070300@redhat.com> On 11/21/2012 01:29 PM, Petr Viktorin wrote: > On 11/19/2012 05:35 PM, Martin Kosek wrote: >> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>> defaults made it to master independently (91e477b). Attaching rebased patch. >>> >>> Note that to continue development on f17, you will need to use the dogtag-devel >>> repo: >>> sudo yum-config-manager >>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>> >>> >>> >>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>> [...] >>>> >>>> For convenience, I've also pushed the changes to a personal repository. >>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>> >>>> git fetch -f git://github.com/encukou/freeipa.git >>>> dogtag-10:pviktori-dogtag-10 >>>> >>> >> >> I went through all the patches again, I found one more issue with the schema >> check. As it binds to Directory Server anonymously when retrieving the schema >> and tests if "ipaObject" objectclass is present, it can fail and crash when >> anonymous binds are not allowed for the Dogtag DS instance. This is what I get >> when I disabled anonymous binds and run ipa-replica-install --setup-ca (a >> script to turn anonymous binds off attached): >> >> [root at vm-104 ~]# ipa-replica-install >> replica-info-vm-104.idm.lab.bos.redhat.com.gpg --setup-ca >> Directory Manager (existing master) password: >> >> Run connection check to master >> [...] >> Connection from master to replica is OK. >> >> Connection check OK >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> LDAP error: INAPPROPRIATE_AUTH >> Anonymous access is not allowed >> >> If possible, it would be good authenticate first. This should be doable, we >> have a Directory Manager password available, after all. Some schema retrieval >> code that we already have in IPA can be found in SchemaCache class in ldap2.py. > > Good point. Attaching updated patch. > >> We may also want to have some flag similar to --skip-conncheck which would >> allow admin with an issue like this one skip the check when he is certain that >> he copied the schema files. > > I named it --skip-schema-check. > >> Adding Ade to check that this scenario is actually sane and Dogtag is supposed >> to work with anonymous access disabled for its DS instance. >> >> When reading the patches, I also saw few places with magic constant "7389" >> (your "Fix schema replication from old masters" patch and Ade's patch). I >> wonder, would "dogtag.Dogtag9Constants.DS_PORT" be more readable? > > Fixed in this patch, I'll look at the other one soon. > > > > For anyone who wants to test: I keep my Github branch updated. Re-running the > fetch command will overwrite your branch with the latest changes. > When the current issues are solved I'll repost all patches again in a single mail. > This works fine. I just think that it may be useful to print some info like 'Schema check failed, you can use --skip-schema-check to....' in case when the following lines thrown an exception: + connection = ldap2.IPASimpleLDAPObject(ca_ldap_url) + connection.start_tls_s() + connection.simple_bind_s(DN(('cn', 'Directory Manager')), + config.dirman_password) This is an output I received when dirsrv at PKI-IPA on my IPA 2.2 master was down, the error was not very descriptive: # ipa-ca-install replica-info-vm-104.idm.lab.bos.redhat.com.gpg Directory Manager (existing master) password: ... Connection from master to replica is OK. Connection check OK Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Can't contact LDAP server # Something like: try: connection stuff... except Exception: print the info raise Martin From pspacek at redhat.com Thu Nov 22 10:01:47 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Nov 2012 11:01:47 +0100 Subject: [Freeipa-devel] [PATCH 0104] Remove dead assignment and add logging to ldap_pool_connect() In-Reply-To: <50ADF712.80004@redhat.com> References: <50ADF712.80004@redhat.com> Message-ID: <50ADF80B.4080500@redhat.com> One day I will forgot my head somewhere ... the patch is attached. On 11/22/2012 10:57 AM, Petr Spacek wrote: > Hello, > > Remove dead assignment and add logging to ldap_pool_connect(). > > Dead assignment was reported by Clang static code analysis. > -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0104-Remove-dead-assignment-and-add-logging-to-ldap_pool_.patch Type: text/x-patch Size: 1453 bytes Desc: not available URL: From pspacek at redhat.com Thu Nov 22 11:30:00 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Nov 2012 12:30:00 +0100 Subject: [Freeipa-devel] [PATCH 0105] Remove dead assignment in ldap_parse_zoneentry() Message-ID: <50AE0CB8.5050303@redhat.com> Hello, this patch fixes the last warning from Clang. Any new warning should attract our attention. Commit message: Remove dead assignment in ldap_parse_zoneentry(). Assigned result value was never read because it is overwritten by following CHECK()s in any case. Dead assignment was reported by Clang static code analysis. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0105-Remove-dead-assignment-in-ldap_parse_zoneentry.patch Type: text/x-patch Size: 989 bytes Desc: not available URL: From atkac at redhat.com Thu Nov 22 11:45:43 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 12:45:43 +0100 Subject: [Freeipa-devel] [PATCH 0093] Log memory allocation failures In-Reply-To: <50AB494E.6090606@redhat.com> References: <50A6320F.8010102@redhat.com> <1353072274.10327.785.camel@willson.li.ssimo.org> <50A64A90.7030100@redhat.com> <20121119173330.GA11848@redhat.com> <50AB494E.6090606@redhat.com> Message-ID: <20121122114542.GA1536@redhat.com> On Tue, Nov 20, 2012 at 10:11:42AM +0100, Petr Spacek wrote: > On 11/19/2012 06:33 PM, Adam Tkac wrote: > >On Fri, Nov 16, 2012 at 03:15:44PM +0100, Petr Spacek wrote: > >>On 11/16/2012 02:24 PM, Simo Sorce wrote: > >>>On Fri, 2012-11-16 at 13:31 +0100, Petr Spacek wrote: > >>>>+#define FILE_LINE_FUNC_MSG "%-15s: %4d: %-20s" > >>>>+#define FILE_LINE_FUNC_ARG __FILE__, __LINE__, __func__ > > > >Thanks for the patch, please read my comments below. > > > >>diff --git a/src/log.h b/src/log.h > >>index 9062a4e80786b5bab806d6c9ceba1d1a9917a3e2..d6a40151d25b6f67cf6735ec955d45e4ebe4106c 100644 > >>--- a/src/log.h > >>+++ b/src/log.h > > > >>+#define log_error_position(format, ...) \ > >>+ log_error("[%-15s: %4d: %-21s] " format, \ > > > >Do we really need to format the format string? I would prefer to drop the > >"[...]" stuff at all. > > This format will align file names, line numbers and most of function > names in columns. It can be handy if some error propagates through > call stack, but I can drop it if you want. > > Real world example: > [ldap_entry.c : 370: ldap_entry_getfakesoa] FAILURE: not found > [ldap_helper.c : 1869: add_soa_record ] FAILURE: not found > > > My intention is to extend logging to failures detected inside CHECK() macros. > > Currently, any failure inside CHECK() will jump to "cleanup" label, > so information about source of the failure is lost. > > As a result it produces error message like: > update_record (psearch) failed, dn > 'idnsName=q.sub,idnsname=test,cn=dns,dc=e,dc=test' change type 0x1. > Records can be outdated, run `rndc reload`: not found > > Huh? What was not found? Those error messages are not useful for > post mortem analysis. > > With logging inside CHECK() it produces: > [ldap_helper.c : 3467: update_record ] FAILURE: not found > update_record (psearch) failed, dn > 'idnsName=q.sub,idnsname=test,cn=dns,dc=e,dc=test' change type 0x1. > Records can be outdated, run `rndc reload`: not found > > File ldap_helper.c, line 3467, return code ISC_R_NOTFOUND is much > better information. Ok, you convinced me. Ack. > > >>@@ -46,15 +48,17 @@ > >> (target_ptr) = isc_mem_allocate((m), (s)); \ > >> if ((target_ptr) == NULL) { \ > >> result = ISC_R_NOMEMORY; \ > >>+ log_error_position("MEMORY ALLOCATION FAILURE"); \ > > > >Such huge msg is not needed, I think. What about more conservative > > > >log_error_position("Memory allocation failed") > You are right, I shouldn't scream too much. Amended patch is attached. > From e9e4b8aa38cb612cf39a1e917c74fd0022de6fd4 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 16 Nov 2012 13:17:44 +0100 > Subject: [PATCH] Log memory allocation failures. > > Signed-off-by: Petr Spacek > --- > src/log.h | 7 ++++++- > src/util.h | 5 +++++ > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/src/log.h b/src/log.h > index 9062a4e80786b5bab806d6c9ceba1d1a9917a3e2..d6a40151d25b6f67cf6735ec955d45e4ebe4106c 100644 > --- a/src/log.h > +++ b/src/log.h > @@ -23,22 +23,27 @@ > > #include > #include > +#include > > #ifdef LOG_AS_ERROR > #define GET_LOG_LEVEL(level) ISC_LOG_ERROR > #else > #define GET_LOG_LEVEL(level) (level) > #endif > > #define fatal_error(...) \ > - isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__) > + isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__) > > #define log_bug(fmt, ...) \ > log_error("bug in %s(): " fmt, __func__,##__VA_ARGS__) > > #define log_error_r(fmt, ...) \ > log_error(fmt ": %s", ##__VA_ARGS__, dns_result_totext(result)) > > +#define log_error_position(format, ...) \ > + log_error("[%-15s: %4d: %-21s] " format, \ > + __FILE__, __LINE__, __func__, ##__VA_ARGS__) > + > /* Basic logging functions */ > #define log_error(format, ...) \ > log_write(GET_LOG_LEVEL(ISC_LOG_ERROR), format, ##__VA_ARGS__) > diff --git a/src/util.h b/src/util.h > index 2b8f10e59ddacdb1d0e49cf0de3e9ab8a3786090..c61f4e7a4930717cfd7729caa2c2f36854d1903f 100644 > --- a/src/util.h > +++ b/src/util.h > @@ -21,6 +21,8 @@ > #ifndef _LD_UTIL_H_ > #define _LD_UTIL_H_ > > +#include "log.h" > + > #define CLEANUP_WITH(result_code) \ > do { \ > result = (result_code); \ > @@ -46,15 +48,17 @@ > (target_ptr) = isc_mem_allocate((m), (s)); \ > if ((target_ptr) == NULL) { \ > result = ISC_R_NOMEMORY; \ > + log_error_position("Memory allocation failed"); \ > goto cleanup; \ > } \ > } while (0) > > #define CHECKED_MEM_GET(m, target_ptr, s) \ > do { \ > (target_ptr) = isc_mem_get((m), (s)); \ > if ((target_ptr) == NULL) { \ > result = ISC_R_NOMEMORY; \ > + log_error_position("Memory allocation failed"); \ > goto cleanup; \ > } \ > } while (0) > @@ -67,6 +71,7 @@ > (target) = isc_mem_strdup((m), (source)); \ > if ((target) == NULL) { \ > result = ISC_R_NOMEMORY; \ > + log_error_position("Memory allocation failed"); \ > goto cleanup; \ > } \ > } while (0) > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 12:18:33 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 13:18:33 +0100 Subject: [Freeipa-devel] [PATCH 0090] Fix origin handling in dn_to_dnsname() for zone DNs In-Reply-To: <50A2795C.8070402@redhat.com> References: <50A2795C.8070402@redhat.com> Message-ID: <20121122121832.GA2159@redhat.com> On Tue, Nov 13, 2012 at 05:46:20PM +0100, Petr Spacek wrote: > Hello, > > I found the bug in dn_to_dnsname() during my work on > https://fedorahosted.org/bind-dyndb-ldap/ticket/91 > "Cache is not flushed properly if renamed/deleted zone has superior zone in LDAP" > > Consider this change as part of solution for ticket #91: > > Fix origin handling in dn_to_dnsname() for zone DNs. > > This patch fixes case where DN is zone (i.e. DN with single idnsName > component) and origin is non-NULL. > > Function str_to_isc_buffer() was fixed to not truncate last character. Ack > From 840dd9d6ee6eefde0baf00930590bb279e73db75 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 13 Nov 2012 17:29:05 +0100 > Subject: [PATCH] Fix origin handling in dn_to_dnsname() for zone DNs. > > This patch fixes case where DN is zone (i.e. DN with single idnsName > component) and origin is non-NULL. > > Function str_to_isc_buffer() was fixed to not truncate last character. > > Signed-off-by: Petr Spacek > --- > src/ldap_convert.c | 39 +++++++++++++++++++++++++-------------- > src/str.c | 2 +- > 2 files changed, 26 insertions(+), 15 deletions(-) > > diff --git a/src/ldap_convert.c b/src/ldap_convert.c > index 3352c573cafc54421c77b0b770657841b90ebd71..394d8d036c1d4e0f8a82499282d1acef7d442bcd 100644 > --- a/src/ldap_convert.c > +++ b/src/ldap_convert.c > @@ -91,12 +91,11 @@ dn_to_dnsname(isc_mem_t *mctx, const char *dn, dns_name_t *target, > > CHECK(dn_to_text(dn, str, ostr)); > str_to_isc_buffer(str, &buffer); > - CHECK(dns_name_fromtext(&name, &buffer, dns_rootname, 0, NULL)); > + CHECK(dns_name_fromtext(&name, &buffer, NULL, 0, NULL)); > > if (otarget != NULL) { > str_to_isc_buffer(ostr, &buffer); > - CHECK(dns_name_fromtext(&origin, &buffer, dns_rootname, 0, > - NULL)); > + CHECK(dns_name_fromtext(&origin, &buffer, NULL, 0, NULL)); > } > > cleanup: > @@ -124,14 +123,26 @@ cleanup: > return result; > } > > -/* > - * Convert LDAP dn to DNS name. > +/** > + * Convert LDAP DN to absolute DNS name. > * > - * Example: > - * dn = "idnsName=foo, idnsName=bar, idnsName=example.org, cn=dns," > - * "dc=example, dc=org" > + * @param[out] target Absolute DNS name derived from the all idnsNames. > + * @param[out] origin Absolute DNS name derived from the last idnsName > + * component of DN, i.e. zone. Can be NULL. > * > - * The resulting string will be "foo.bar.example.org." > + * @code > + * Examples: > + * dn = "idnsName=foo, idnsName=bar, idnsName=example.org," > + * "cn=dns, dc=example, dc=org" > + * target = "foo.bar.example.org." > + * origin = "example.org." > + * > + * dn = "idnsname=89, idnsname=4.34.10.in-addr.arpa.", > + * " cn=dns, dc=example, dc=org" > + * target = "89.4.34.10.in-addr.arpa." > + * origin = "4.34.10.in-addr.arpa." > + * (The dot at the end is not doubled when it's already present.) > + * @endcode > */ > isc_result_t > dn_to_text(const char *dn, ld_string_t *target, ld_string_t *origin) > @@ -159,24 +170,24 @@ dn_to_text(const char *dn, ld_string_t *target, ld_string_t *origin) > > CHECK(explode_rdn(exploded_dn[i], &exploded_rdn, 1)); > CHECK(str_cat_char(target, exploded_rdn[0])); > - CHECK(str_cat_char(target, ".")); > + if (str_buf(target)[str_len(target)-1] != '.') > + CHECK(str_cat_char(target, ".")); > } > > if (origin != NULL) { > str_clear(origin); > > /* > * If we have DNs with only one idnsName part, > - * treat them as absolute. > + * treat them as absolute zone name. > */ > - > if (i < 2) > CHECK(str_init_char(origin, ".")); > else { > CHECK(str_cat_char(origin, exploded_rdn[0])); > - CHECK(str_cat_char(origin, ".")); > + if (str_buf(origin)[str_len(origin)-1] != '.') > + CHECK(str_cat_char(origin, ".")); > } > - > } > > if (str_len(target) == 0) > diff --git a/src/str.c b/src/str.c > index 83645365ee6eff7bda5fbeda6837f30d4dec41ae..1be3f5b61250cb6900820dd4bf1375a3ed77359c 100644 > --- a/src/str.c > +++ b/src/str.c > @@ -465,7 +465,7 @@ str_to_isc_buffer(const ld_string_t *src, isc_buffer_t *dest) > REQUIRE(src != NULL); > REQUIRE(dest != NULL); > > - len = str_len_internal(src) - 1; > + len = str_len_internal(src); > > isc_buffer_init(dest, src->data, len); > isc_buffer_add(dest, len); > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 12:28:49 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 13:28:49 +0100 Subject: [Freeipa-devel] [PATCH 0091] Harden dn_to_text() conversion In-Reply-To: <50A3CEB3.7040905@redhat.com> References: <50A3CEB3.7040905@redhat.com> Message-ID: <20121122122848.GB2159@redhat.com> On Wed, Nov 14, 2012 at 06:02:43PM +0100, Petr Spacek wrote: > Hello, > > Harden dn_to_text() conversion. > > All cases covered by new checks will silently cause errors > in other parts of plugin. This code should catch problematic > inputs and stop processing at the beginning. Ack > From 71feac726d814469291eeb413fa8c90aca02cd2d Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Wed, 14 Nov 2012 17:57:13 +0100 > Subject: [PATCH] Harden dn_to_text() conversion. > > All cases covered by new checks will silently cause errors > in other parts of plugin. This code should catch problematic > inputs and stop processing at the beginning. > > Signed-off-by: Petr Spacek > --- > src/ldap_convert.c | 27 ++++++++++++++++++++++++++- > 1 file changed, 26 insertions(+), 1 deletion(-) > > diff --git a/src/ldap_convert.c b/src/ldap_convert.c > index 394d8d036c1d4e0f8a82499282d1acef7d442bcd..360c7f2df976bc992213a01d652ce264202ce89e 100644 > --- a/src/ldap_convert.c > +++ b/src/ldap_convert.c > @@ -126,6 +126,8 @@ cleanup: > /** > * Convert LDAP DN to absolute DNS name. > * > + * @param[in] dn LDAP DN with one or two idnsName components at the > + * beginning. > * @param[out] target Absolute DNS name derived from the all idnsNames. > * @param[out] origin Absolute DNS name derived from the last idnsName > * component of DN, i.e. zone. Can be NULL. > @@ -169,17 +171,40 @@ dn_to_text(const char *dn, ld_string_t *target, ld_string_t *origin) > } > > CHECK(explode_rdn(exploded_dn[i], &exploded_rdn, 1)); > + if (exploded_rdn[0] == NULL || exploded_rdn[1] != NULL) { > + log_error("idnsName component of DN has to have " > + "exactly one value: DN '%s'", dn); > + CLEANUP_WITH(ISC_R_NOTIMPLEMENTED); > + } > CHECK(str_cat_char(target, exploded_rdn[0])); > if (str_buf(target)[str_len(target)-1] != '.') > CHECK(str_cat_char(target, ".")); > } > > + /* filter out unsupported cases */ > + if (i <= 0) { > + log_error("no idnsName component found in DN '%s'", dn); > + CLEANUP_WITH(ISC_R_UNEXPECTEDEND); > + } else if (i == 1) { /* zone only - nothing to check */ > + ; > + } else if (i == 2) { > + if (exploded_dn[0][strlen(exploded_dn[0])-1] == '.') { > + log_error("absolute record name in DN " > + "is not supported: DN '%s'", dn); > + CLEANUP_WITH(ISC_R_NOTIMPLEMENTED); > + } > + } else { > + log_error("unsupported number of idnsName components in DN " > + "'%s': %u components found", dn, i); > + CLEANUP_WITH(ISC_R_NOTIMPLEMENTED); > + } > + > if (origin != NULL) { > str_clear(origin); > > /* > * If we have DNs with only one idnsName part, > - * treat them as absolute zone name. > + * treat them as absolute zone name, i.e. origin is root. > */ > if (i < 2) > CHECK(str_init_char(origin, ".")); > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 12:30:31 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 13:30:31 +0100 Subject: [Freeipa-devel] [PATCH 0095] Use memory allocation macros more extensively - part 2 In-Reply-To: <50AB6E74.5020803@redhat.com> References: <50AB6E74.5020803@redhat.com> Message-ID: <20121122123031.GC2159@redhat.com> On Tue, Nov 20, 2012 at 12:50:12PM +0100, Petr Spacek wrote: > Hello, > > this patch replaces all remaining occurrences of direct isc_mem_* > calls with macros. > The only exception is destroy_ldap_connection() which will be > handled in separate patch - current deallocation code is probably > not safe. > > Commit message: > Use memory allocation macros more extensively - part 2. > > Some scattered occurences of isc_mem_* functions was replaced by macros. > > String functions from str.c are still calling isc_mem_directly. Ack > From 9f44b8a965373f26c74100c84f7580d224355c3e Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 20 Nov 2012 12:39:49 +0100 > Subject: [PATCH] Use memory allocation macros more extensively - part 2. > > Some scattered occurrences of isc_mem_* functions was replaced by macros. > > String functions from str.c are still calling isc_mem_directly. > > Signed-off-by: Petr Spacek > --- > src/acl.c | 6 +----- > src/ldap_driver.c | 2 +- > src/ldap_entry.c | 6 +++--- > src/ldap_helper.c | 33 ++++++++++----------------------- > src/zone_manager.c | 2 +- > src/zone_register.c | 2 +- > 6 files changed, 17 insertions(+), 34 deletions(-) > > diff --git a/src/acl.c b/src/acl.c > index a490affaded51b48f0406a5d5a7d0fa51f625d80..c62a8cb9e867b658b65ce05a07fc31377b2356c2 100644 > --- a/src/acl.c > +++ b/src/acl.c > @@ -553,11 +553,7 @@ acl_parse_forwarder(const char *forwarder_str, isc_mem_t *mctx, isc_sockaddr_t * > } > > const cfg_obj_t *forwarder = cfg_listelt_value(element); > - *sa = isc_mem_get(mctx, sizeof(isc_sockaddr_t)); > - if (*sa == NULL) { > - result = ISC_R_NOMEMORY; > - goto cleanup; > - } > + CHECKED_MEM_GET_PTR(mctx, *sa); > **sa = *cfg_obj_assockaddr(forwarder); > if (isc_sockaddr_getport(*sa) == 0) > isc_sockaddr_setport(*sa, port); > diff --git a/src/ldap_driver.c b/src/ldap_driver.c > index 99a8421105f91a6c98d0e15d2c5962701974e380..cde09ee8aa3c9332f3766a031030a95b0cff3229 100644 > --- a/src/ldap_driver.c > +++ b/src/ldap_driver.c > @@ -221,7 +221,7 @@ clone_rdatalist_to_rdataset(isc_mem_t *mctx, dns_rdatalist_t *rdlist, > cleanup: > if (new_rdlist != NULL) { > free_rdatalist(mctx, rdlist); > - isc_mem_put(mctx, new_rdlist, sizeof(*new_rdlist)); > + SAFE_MEM_PUT_PTR(mctx, new_rdlist); > } > > return result; > diff --git a/src/ldap_entry.c b/src/ldap_entry.c > index 1e165ca696ccafa177f17b97bda08ed9cc344c7d..9436b895913b2eb1a711d9343e43e695ea7e6ae4 100644 > --- a/src/ldap_entry.c > +++ b/src/ldap_entry.c > @@ -120,7 +120,7 @@ ldap_valuelist_destroy(isc_mem_t *mctx, ldap_valuelist_t *values) > while (value != NULL) { > next = NEXT(value, link); > UNLINK(*values, value, link); > - isc_mem_put(mctx, value, sizeof(*value)); > + SAFE_MEM_PUT_PTR(mctx, value); > value = next; > } > } > @@ -137,7 +137,7 @@ ldap_attributelist_destroy(isc_mem_t *mctx, ldap_attributelist_t *attrlist) > ldap_valuelist_destroy(mctx, &attr->values); > ldap_value_free(attr->ldap_values); > ldap_memfree(attr->name); > - isc_mem_put(mctx, attr, sizeof(*attr)); > + SAFE_MEM_PUT_PTR(mctx, attr); > attr = next; > } > } > @@ -242,7 +242,7 @@ ldap_entry_destroy(isc_mem_t *mctx, ldap_entry_t **entryp) > ldap_attributelist_destroy(mctx, &entry->attrs); > if (entry->dn != NULL) > ldap_memfree(entry->dn); > - isc_mem_put(mctx, entry, sizeof(*entry)); > + SAFE_MEM_PUT_PTR(mctx, entry); > > *entryp = NULL; > } > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 904bae5259cccd9ce5cfd27deead3a0d23864f84..84ac06be7c7d4451e59844dd7c447f0f3d557f61 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -670,10 +670,10 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > 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); > - isc_mem_put(ldap_inst->mctx, addr, sizeof(isc_sockaddr_t)); > + SAFE_MEM_PUT_PTR(ldap_inst->mctx, addr); > } > > - isc_mem_putanddetach(&ldap_inst->mctx, ldap_inst, sizeof(ldap_instance_t)); > + MEM_PUT_AND_DETACH(ldap_inst); > > *ldap_instp = NULL; > log_debug(1, "LDAP instance '%s' destroyed", db_name); > @@ -693,7 +693,7 @@ new_ldap_connection(ldap_pool_t *pool, ldap_connection_t **ldap_connp) > > result = isc_mutex_init(&ldap_conn->lock); > if (result != ISC_R_SUCCESS) { > - isc_mem_put(pool->mctx, ldap_conn, sizeof(ldap_connection_t)); > + SAFE_MEM_PUT_PTR(pool->mctx, ldap_conn); > return result; > } > > @@ -1135,7 +1135,7 @@ cleanup: > isc_sockaddr_t *addr = NULL; > addr = ISC_LIST_HEAD(addrs); > ISC_LIST_UNLINK(addrs, addr, link); > - isc_mem_put(inst->mctx, addr, sizeof(*addr)); > + SAFE_MEM_PUT_PTR(inst->mctx, addr); > } > } > if (fwdtbl_deletion_requested) { > @@ -1654,7 +1654,7 @@ ldapdb_rdatalist_destroy(isc_mem_t *mctx, ldapdb_rdatalist_t *rdatalist) > rdlist = HEAD(*rdatalist); > free_rdatalist(mctx, rdlist); > UNLINK(*rdatalist, rdlist, link); > - isc_mem_put(mctx, rdlist, sizeof(*rdlist)); > + SAFE_MEM_PUT_PTR(mctx, rdlist); > } > } > > @@ -1671,7 +1671,7 @@ free_rdatalist(isc_mem_t *mctx, dns_rdatalist_t *rdlist) > UNLINK(rdlist->rdata, rdata, link); > dns_rdata_toregion(rdata, &r); > isc_mem_put(mctx, r.base, r.length); > - isc_mem_put(mctx, rdata, sizeof(*rdata)); > + SAFE_MEM_PUT_PTR(mctx, rdata); > } > } > > @@ -1931,8 +1931,7 @@ parse_rdata(isc_mem_t *mctx, ldap_qresult_t *qresult, > > cleanup: > isc_lex_close(qresult->lex); > - if (rdata != NULL) > - isc_mem_put(mctx, rdata, sizeof(*rdata)); > + SAFE_MEM_PUT_PTR(mctx, rdata); > if (rdatamem.base != NULL) > isc_mem_put(mctx, rdatamem.base, rdatamem.length); > > @@ -3589,23 +3588,11 @@ psearch_update(ldap_instance_t *inst, ldap_entry_t *entry, LDAPControl **ctrls) > > isc_mem_attach(inst->mctx, &mctx); > > - dn = isc_mem_strdup(mctx, entry->dn); > - if (dn == NULL) { > - result = ISC_R_NOMEMORY; > - goto cleanup; > - } > - dbname = isc_mem_strdup(mctx, inst->db_name); > - if (dbname == NULL) { > - result = ISC_R_NOMEMORY; > - goto cleanup; > - } > + CHECKED_MEM_STRDUP(mctx, entry->dn, dn); > + CHECKED_MEM_STRDUP(mctx, inst->db_name, dbname); > > if (PSEARCH_MODDN(chgtype)) { > - prevdn = isc_mem_strdup(mctx, prevdn_ldap); > - if (prevdn == NULL) { > - result = ISC_R_NOMEMORY; > - goto cleanup; > - } > + CHECKED_MEM_STRDUP(mctx, prevdn_ldap, prevdn); > } > > /* > diff --git a/src/zone_manager.c b/src/zone_manager.c > index ca3edd010e5f6ea94adb57e5ae5e915a834e52a0..2988cfd0598de57efbc4f7a42447ad1dadce6d65 100644 > --- a/src/zone_manager.c > +++ b/src/zone_manager.c > @@ -98,7 +98,7 @@ destroy_db_instance(db_instance_t **db_instp) > if (db_inst->name != NULL) > isc_mem_free(db_inst->mctx, db_inst->name); > > - isc_mem_putanddetach(&db_inst->mctx, db_inst, sizeof(*db_inst)); > + MEM_PUT_AND_DETACH(db_inst); > > *db_instp = NULL; > } > diff --git a/src/zone_register.c b/src/zone_register.c > index 76305730b2e19686568f8a1bc6ac703ed3898fcc..18438bf937a6482ddf058adbecdc21e7cf2e7f26 100644 > --- a/src/zone_register.c > +++ b/src/zone_register.c > @@ -167,7 +167,7 @@ delete_zone_info(void *arg1, void *arg2) > > isc_mem_free(mctx, zinfo->dn); > dns_zone_detach(&zinfo->zone); > - isc_mem_put(mctx, zinfo, sizeof(*zinfo)); > + SAFE_MEM_PUT_PTR(mctx, zinfo); > } > > /* > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 12:31:16 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 13:31:16 +0100 Subject: [Freeipa-devel] [PATCH 0096] Remove unused str_*split*() functions In-Reply-To: <50AB7019.4070708@redhat.com> References: <50AB7019.4070708@redhat.com> Message-ID: <20121122123115.GD2159@redhat.com> On Tue, Nov 20, 2012 at 12:57:13PM +0100, Petr Spacek wrote: > Hello, > > this patch removes never called str_*split*() functions and related > ld_split structure. > > We can pull it from history when necessary. Ack > From dfc3e0009e0b4ba091929d4171e407495f42f72a Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 20 Nov 2012 12:51:38 +0100 > Subject: [PATCH] Remove unused str_*split*() functions and ld_split > structure. > > Signed-off-by: Petr Spacek > --- > src/str.c | 133 -------------------------------------------------------------- > src/str.h | 7 ---- > 2 files changed, 140 deletions(-) > > diff --git a/src/str.c b/src/str.c > index 83645365ee6eff7bda5fbeda6837f30d4dec41ae..3c5cbbd03a998a539d41ddb51f167eebdc7bdd20 100644 > --- a/src/str.c > +++ b/src/str.c > @@ -57,14 +57,6 @@ struct ld_string { > #endif > }; > > -struct ld_split { > - isc_mem_t *mctx; /* Memory context. */ > - char *data; /* Splits. */ > - size_t allocated; /* Number of bytes allocated. */ > - char *splits[LD_MAX_SPLITS]; > - size_t split_count; /* Number of splits. */ > -}; > - > /* > * Private functions. > */ > @@ -479,128 +471,3 @@ str_casecmp_char(const ld_string_t *s1, const char *s2) > > return strcasecmp(s1->data, s2); > } > - > -/* > - * TODO: Review. > - */ > -isc_result_t > -str_new_split(isc_mem_t *mctx, ld_split_t **splitp) > -{ > - isc_result_t result; > - ld_split_t *split; > - > - REQUIRE(splitp != NULL && *splitp == NULL); > - > - CHECKED_MEM_GET_PTR(mctx, split); > - ZERO_PTR(split); > - isc_mem_attach(mctx, &split->mctx); > - > - *splitp = split; > - return ISC_R_SUCCESS; > - > -cleanup: > - return result; > -} > - > -void > -str_destroy_split(ld_split_t **splitp) > -{ > - ld_split_t *split; > - > - if (splitp == NULL || *splitp == NULL) > - return; > - > - split = *splitp; > - > - if (split->allocated) > - isc_mem_free(split->mctx, split->data); > - > - isc_mem_putanddetach(&split->mctx, split, sizeof(*split)); > - > - *splitp = NULL; > -} > - > -static isc_result_t > -str_split_initialize(ld_split_t *split, const char *str) > -{ > - size_t size; > - > - REQUIRE(split != NULL); > - REQUIRE(split->mctx != NULL); > - REQUIRE(str != NULL && *str != '\0'); > - > - if (split->allocated != 0) { > - isc_mem_put(split->mctx, split->data, split->allocated); > - split->allocated = 0; > - } > - split->splits[0] = NULL; > - split->split_count = 0; > - > - size = strlen(str) + 1; > - split->data = isc_mem_strdup(split->mctx, str); > - if (split->data == NULL) > - return ISC_R_NOMEMORY; > - > - split->allocated = size; > - > - return ISC_R_SUCCESS; > -} > - > -isc_result_t > -str_split(const ld_string_t *src, const char delimiter, ld_split_t *split) > -{ > - isc_result_t result; > - unsigned int current_pos; > - int save; > - > - REQUIRE(src != NULL); > - REQUIRE(delimiter != '\0'); > - REQUIRE(split != NULL); > - > - CHECK(str_split_initialize(split, src->data)); > - > - /* Replace all delimiters with '\0'. */ > - for (unsigned int i = 0; i < split->allocated; i++) { > - if (split->data[i] == delimiter) > - split->data[i] = '\0'; > - } > - > - /* Now save the right positions. */ > - current_pos = 0; > - save = 1; > - for (unsigned int i = 0; > - i < split->allocated && current_pos < LD_MAX_SPLITS - 1; > - i++) { > - if (save && split->data[i] != '\0') { > - split->splits[current_pos] = split->data + i; > - current_pos++; > - save = 0; > - } else if (split->data[i] == '\0') { > - save = 1; > - } > - } > - split->splits[current_pos] = NULL; > - split->split_count = current_pos; > - > - return ISC_R_SUCCESS; > - > -cleanup: > - return result; > -} > - > -size_t > -str_split_count(const ld_split_t *split) > -{ > - REQUIRE(split != NULL); > - > - return split->split_count; > -} > - > -const char * > -str_split_get(const ld_split_t *split, unsigned int split_number) > -{ > - REQUIRE(split != NULL); > - REQUIRE(split->split_count >= split_number); > - > - return split->splits[split_number]; > -} > diff --git a/src/str.h b/src/str.h > index b3dc48fb6156394e5099f6e2d9488093decd8d28..25f6682e78f643eeec02db2e0d0f127c09840691 100644 > --- a/src/str.h > +++ b/src/str.h > @@ -37,7 +37,6 @@ > #endif > > typedef struct ld_string ld_string_t; > -typedef struct ld_split ld_split_t; > > /* > * Public functions. > @@ -65,12 +64,6 @@ void str_to_isc_buffer(const ld_string_t *src, isc_buffer_t *dest); > > int str_casecmp_char(const ld_string_t *s1, const char *s2); > > -isc_result_t str_new_split(isc_mem_t *mctx, ld_split_t **splitp); > -void str_destroy_split(ld_split_t **splitp); > -isc_result_t str_split(const ld_string_t *src, const char delimiter, ld_split_t *split); > -size_t str_split_count(const ld_split_t *split); > -const char * str_split_get(const ld_split_t *split, unsigned int split_number); > - > /* These are pseudo-private functions and shouldn't be called directly. */ > isc_result_t str__new(isc_mem_t *mctx, ld_string_t **new_str _STR_MEM_FLARG); > void str__destroy(ld_string_t **str _STR_MEM_FLARG); > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 12:33:50 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 13:33:50 +0100 Subject: [Freeipa-devel] [PATCH 0097] Deallocate LDAP connections in safe way In-Reply-To: <50AB7263.9040201@redhat.com> References: <50AB7263.9040201@redhat.com> Message-ID: <20121122123349.GE2159@redhat.com> On Tue, Nov 20, 2012 at 01:06:59PM +0100, Petr Spacek wrote: > Hello, > > Deallocate LDAP connections in safe way. > > Current code does isc_mem_detach() before isc_mem_put() so > memory context reference counter is wrong for a small time frame. > > Macro MEM_PUT_AND_DETACH will handle it properly including > pointer zeroing. Ack > From 15bc2ce1c854dab3ddf0a0521f59390aa8871fae Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 20 Nov 2012 13:02:26 +0100 > Subject: [PATCH] Deallocate LDAP connections in safe way. > > Current code does isc_mem_detach() before isc_mem_put() so > memory context reference counter is wrong for a small time frame. > > Macro MEM_PUT_AND_DETACH will handle it properly including > pointer zeroing. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 16 ++++++---------- > 1 file changed, 6 insertions(+), 10 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 84ac06be7c7d4451e59844dd7c447f0f3d557f61..ef0fb69413d0febe8334bb5156d879fa1f0b9f16 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -258,8 +258,7 @@ struct ldap_psearchevent { > /* TODO: reorganize this stuff & clean it up. */ > static isc_result_t new_ldap_connection(ldap_pool_t *pool, > ldap_connection_t **ldap_connp); > -static void destroy_ldap_connection(ldap_pool_t *pool, > - ldap_connection_t **ldap_connp); > +static void destroy_ldap_connection(ldap_connection_t **ldap_connp); > > static isc_result_t findrdatatype_or_create(isc_mem_t *mctx, > ldapdb_rdatalist_t *rdatalist, dns_rdataclass_t rdclass, > @@ -706,13 +705,13 @@ new_ldap_connection(ldap_pool_t *pool, ldap_connection_t **ldap_connp) > return ISC_R_SUCCESS; > > cleanup: > - destroy_ldap_connection(pool, &ldap_conn); > + destroy_ldap_connection(&ldap_conn); > > return result; > } > > static void > -destroy_ldap_connection(ldap_pool_t *pool, ldap_connection_t **ldap_connp) > +destroy_ldap_connection(ldap_connection_t **ldap_connp) > { > ldap_connection_t *ldap_conn; > > @@ -730,10 +729,7 @@ destroy_ldap_connection(ldap_pool_t *pool, ldap_connection_t **ldap_connp) > ldap_control_free(ldap_conn->serverctrls[0]); > } > > - isc_mem_detach(&ldap_conn->mctx); > - > - isc_mem_put(pool->mctx, *ldap_connp, sizeof(ldap_connection_t)); > - *ldap_connp = NULL; > + MEM_PUT_AND_DETACH(*ldap_connp); > } > > /* > @@ -3028,7 +3024,7 @@ ldap_pool_destroy(ldap_pool_t **poolp) > for (i = 0; i < pool->connections; i++) { > ldap_conn = pool->conns[i]; > if (ldap_conn != NULL) > - destroy_ldap_connection(pool, &ldap_conn); > + destroy_ldap_connection(&ldap_conn); > } > > SAFE_MEM_PUT(pool->mctx, pool->conns, > @@ -3109,7 +3105,7 @@ ldap_pool_connect(ldap_pool_t *pool, ldap_instance_t *ldap_inst) > > cleanup: > for (i = 0; i < pool->connections; i++) { > - destroy_ldap_connection(pool, &pool->conns[i]); > + destroy_ldap_connection(&pool->conns[i]); > } > return result; > } > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:05:42 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:05:42 +0100 Subject: [Freeipa-devel] [PATCH 0098] Log failures detected in CHECK() macro In-Reply-To: <50AB8951.5000604@redhat.com> References: <50AB8951.5000604@redhat.com> Message-ID: <20121122130541.GF2159@redhat.com> On Tue, Nov 20, 2012 at 02:44:49PM +0100, Petr Spacek wrote: > Hello, > > Log failures detected in CHECK() macro. > > Function ldap_query() can return ISC_R_NOTFOUND legitimately. > For this and similar cases CHECK_CONDLOG macro was introduced. > It will not log if result != ISC_R_SUCCESS but == ignored_code. > Nested condition will be eliminated by optimizing compiler > in cases where ignored_code == ISC_R_SUCCESS. > > Function add_soa_record() is now called only for zones to prevent > false error messages. Nack. I don't like second part of the patch much, it adds huge amount of logging and now we will log every error twice because we already log errors explicitly. In my opinion better will be to add new configuration option, for example "debug", and with this option we can emit log messages from CHECK macros (I haven't though about implementation details, yet). Otherwise we should avoid logging because it's useless to log all errors, they are expected in production environment. I also don't like CHECK_CONDLOG macro, it's not intuitive and with it we can end with so called spaghetti code... As I wrote above I would log every CHECK failure with debugging on. However the first patch of the patch is fine (the add_soa_record part). Regards, Adam > From 2d17a81506c8851d5aa6e6f17a9cf72146b4b9c9 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Tue, 20 Nov 2012 13:58:32 +0100 > Subject: [PATCH] Log failures detected in CHECK() macro. > > Function ldap_query() can return ISC_R_NOTFOUND legitimately. > For this and similar cases CHECK_CONDLOG macro was introduced. > It will not log if result != ISC_R_SUCCESS but == ignored_code. > Nested condition will be eliminated by optimizing compiler > in cases where ignored_code == ISC_R_SUCCESS. > > Function add_soa_record() is now called only for zones to prevent > false error messages. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 12 ++++++------ > src/util.h | 17 ++++++++--------- > 2 files changed, 14 insertions(+), 15 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index ef0fb69413d0febe8334bb5156d879fa1f0b9f16..7da07eabd5c712006276021d56e5972b4de9a3e1 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1687,10 +1687,9 @@ ldap_parse_rrentry(isc_mem_t *mctx, ldap_entry_t *entry, > const char *dn = ""; > const char *data = ""; > > - result = add_soa_record(mctx, qresult, origin, entry, > - rdatalist, fake_mname); > - if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) > - goto cleanup; > + if ((ldap_entry_getclass(entry) & LDAP_ENTRYCLASS_ZONE) != 0) > + CHECK(add_soa_record(mctx, qresult, origin, entry, > + rdatalist, fake_mname)); > > rdclass = ldap_entry_getrdclass(entry); > ttl = ldap_entry_getttl(entry); > @@ -1814,8 +1813,9 @@ ldapdb_rdatalist_get(isc_mem_t *mctx, ldap_instance_t *ldap_inst, dns_name_t *na > CHECK(str_new(mctx, &string)); > CHECK(dnsname_to_dn(ldap_inst->zone_register, name, string)); > > - CHECK(ldap_query(ldap_inst, NULL, &ldap_qresult, str_buf(string), > - LDAP_SCOPE_BASE, NULL, 0, "(objectClass=idnsRecord)")); > + CHECK_CONDLOG(ldap_query(ldap_inst, NULL, &ldap_qresult, str_buf(string), > + LDAP_SCOPE_BASE, NULL, 0, "(objectClass=idnsRecord)"), > + ISC_R_NOTFOUND); > > if (EMPTY(ldap_qresult->ldap_entries)) { > result = ISC_R_NOTFOUND; > diff --git a/src/util.h b/src/util.h > index c61f4e7a4930717cfd7729caa2c2f36854d1903f..12d77df68d96556b9c8e42b3cd176a1cd3386c91 100644 > --- a/src/util.h > +++ b/src/util.h > @@ -29,18 +29,17 @@ > goto cleanup; \ > } while(0) > > -#define CHECK(op) \ > - do { \ > - result = (op); \ > - if (result != ISC_R_SUCCESS) \ > - goto cleanup; \ > - } while (0) > +#define CHECK(op) CHECK_CONDLOG(op, ISC_R_SUCCESS) > > -#define CHECK_NEXT(op) \ > +#define CHECK_CONDLOG(op, ignored_code) \ > do { \ > result = (op); \ > - if (result != ISC_R_SUCCESS) \ > - goto next; \ > + if (result != ISC_R_SUCCESS) { \ > + if (result != ignored_code) \ > + log_error_position("check failed: %s", \ > + dns_result_totext(result)); \ > + goto cleanup; \ > + } \ > } while (0) > > #define CHECKED_MEM_ALLOCATE(m, target_ptr, s) \ > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:07:05 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:07:05 +0100 Subject: [Freeipa-devel] [PATCH 0094] Use memory allocation macros more extensively - part 1 In-Reply-To: <50AB4AD1.8050108@redhat.com> References: <50AB4AD1.8050108@redhat.com> Message-ID: <20121122130705.GG2159@redhat.com> On Tue, Nov 20, 2012 at 10:18:09AM +0100, Petr Spacek wrote: > Hello, > > Use memory allocation macros more extensively. > > Some scattered occurences of isc_mem_* functions was replaced by macros. > Destroy_ldap_instance() now accepts NULL LDAP instance. > > String functions from str.c are still calling isc_mem_directly. > > This patch contain small subset of changes which affect > new_ldap_instance() and destroy_ldap_instance() calls. Remaining > changes do not require changes in new_*/destroy_* logic and will > follow in separate patch. Ack > From 47605bb5c605729224f43a01fcef94c93b7166d3 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Fri, 16 Nov 2012 15:34:39 +0100 > Subject: [PATCH] Use memory allocation macros more extensively. > > Some scattered occurences of isc_mem_* functions was replaced by macros. > Destroy_ldap_instance() now accepts NULL LDAP instance. > > String functions from str.c are still calling isc_mem_directly. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 21 ++++++++------------- > 1 file changed, 8 insertions(+), 13 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index b36892b4e8180fb2a5f335e3fa1b5589dae8bf14..904bae5259cccd9ce5cfd27deead3a0d23864f84 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -372,13 +372,10 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > > REQUIRE(ldap_instp != NULL && *ldap_instp == NULL); > > - ldap_inst = isc_mem_get(mctx, sizeof(ldap_instance_t)); > - if (ldap_inst == NULL) > - return ISC_R_NOMEMORY; > - > + CHECKED_MEM_GET_PTR(mctx, ldap_inst); > ZERO_PTR(ldap_inst); > - > isc_mem_attach(mctx, &ldap_inst->mctx); > + > ldap_inst->db_name = db_name; > view = dns_dyndb_get_view(dyndb_args); > dns_view_attach(view, &ldap_inst->view); > @@ -511,9 +508,7 @@ new_ldap_instance(isc_mem_t *mctx, const char *db_name, > for (addr = ISC_LIST_HEAD(orig_global_forwarders->addrs); > addr != NULL; > addr = ISC_LIST_NEXT(addr, link)) { > - new_addr = isc_mem_get(mctx, sizeof(isc_sockaddr_t)); > - if (new_addr == NULL) > - CLEANUP_WITH(ISC_R_NOMEMORY); > + CHECKED_MEM_GET_PTR(mctx, new_addr); > *new_addr = *addr; > ISC_LINK_INIT(new_addr, link); > ISC_LIST_APPEND(ldap_inst->orig_global_forwarders.addrs, > @@ -561,9 +556,12 @@ destroy_ldap_instance(ldap_instance_t **ldap_instp) > const char *db_name; > isc_sockaddr_t *addr; > > - REQUIRE(ldap_instp != NULL && *ldap_instp != NULL); > + REQUIRE(ldap_instp != NULL); > > ldap_inst = *ldap_instp; > + if (ldap_inst == NULL) > + return; > + > db_name = ldap_inst->db_name; /* points to DB instance: outside ldap_inst */ > > /* > @@ -690,10 +688,7 @@ new_ldap_connection(ldap_pool_t *pool, ldap_connection_t **ldap_connp) > REQUIRE(pool != NULL); > REQUIRE(ldap_connp != NULL && *ldap_connp == NULL); > > - ldap_conn = isc_mem_get(pool->mctx, sizeof(ldap_connection_t)); > - if (ldap_conn == NULL) > - return ISC_R_NOMEMORY; > - > + CHECKED_MEM_GET_PTR(pool->mctx, ldap_conn); > ZERO_PTR(ldap_conn); > > result = isc_mutex_init(&ldap_conn->lock); > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:12:02 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:12:02 +0100 Subject: [Freeipa-devel] [PATCH 0099] Remove dead code detected by clang static analyzer In-Reply-To: <50ACEC49.2020706@redhat.com> References: <50ACEC49.2020706@redhat.com> Message-ID: <20121122131201.GH2159@redhat.com> On Wed, Nov 21, 2012 at 03:59:21PM +0100, Petr Spacek wrote: > Hello, > > Remove dead code detected by clang static analyzer. > Ack > From 8bdab9e7d7d71a11f363873ebfbd979662474bfc Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Wed, 21 Nov 2012 12:59:00 +0100 > Subject: [PATCH] Remove dead code detected by clang static analyzer. > > Signed-off-by: Petr Spacek > --- > src/ldap_convert.c | 3 --- > src/ldap_helper.c | 4 ++-- > 2 files changed, 2 insertions(+), 5 deletions(-) > > diff --git a/src/ldap_convert.c b/src/ldap_convert.c > index 3352c573cafc54421c77b0b770657841b90ebd71..9589add4428cbac3ed467e5ae738c3f7a48e7474 100644 > --- a/src/ldap_convert.c > +++ b/src/ldap_convert.c > @@ -144,8 +144,6 @@ dn_to_text(const char *dn, ld_string_t *target, ld_string_t *origin) > REQUIRE(dn != NULL); > REQUIRE(target != NULL); > > - result = ISC_R_SUCCESS; > - > CHECK(explode_dn(dn, &exploded_dn, 0)); > str_clear(target); > for (i = 0; exploded_dn[i] != NULL; i++) { > @@ -283,7 +281,6 @@ dns_to_ldap_dn_escape(isc_mem_t *mctx, const char const * dns_str, char ** ldap_ > int length_ok = dns_idx - idx_symb_first; > memcpy(esc_name + esc_idx, dns_str + idx_symb_first, dns_idx - idx_symb_first); > esc_idx += length_ok; > - idx_symb_first = -1; > } > esc_name[esc_idx] = '\0'; > return ISC_R_SUCCESS; > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 7da07eabd5c712006276021d56e5972b4de9a3e1..c85fd7feca348bdd63bba33409fc740b399e61dd 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1280,7 +1280,7 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > publish = ISC_TRUE; > log_debug(2, "created zone %p: %s", zone, dn); > } else if (result != ISC_R_SUCCESS) > - CLEANUP_WITH(result); > + goto cleanup; > > log_debug(2, "Setting SSU table for %p: %s", zone, dn); > /* Get the update policy and update the zone with it. */ > @@ -3285,7 +3285,7 @@ update_zone(isc_task_t *task, isc_event_t *event) > LDAP_SCOPE_BASE, attrs_zone, 0, > "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))"); > if (result != ISC_R_SUCCESS && result != ISC_R_NOTFOUND) > - CLEANUP_WITH(result); > + goto cleanup; > > if (result == ISC_R_SUCCESS && > HEAD(ldap_qresult_zone->ldap_entries) != NULL) { > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:27:00 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:27:00 +0100 Subject: [Freeipa-devel] [PATCH 0103] Remove dead assignments in manager_create_db_instance() and make log messages verbose In-Reply-To: <50ADF03B.6040104@redhat.com> References: <50ADF03B.6040104@redhat.com> Message-ID: <20121122132659.GA12802@redhat.com> On Thu, Nov 22, 2012 at 10:28:27AM +0100, Petr Spacek wrote: > Hello, > > Remove dead assignments in manager_create_db_instance() and make > log messages verbose. > > Dead assignments were reported by Clang static code analysis. Ack > From 20b87c908c3ae2c05c10f0ee72fe17f34ff2b35b Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 22 Nov 2012 10:03:21 +0100 > Subject: [PATCH] Remove dead assignments in manager_create_db_instance() and > make log messages verbose. > > Dead assignments were reported by Clang static code analysis. > > Signed-off-by: Petr Spacek > --- > src/zone_manager.c | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/src/zone_manager.c b/src/zone_manager.c > index 2988cfd0598de57efbc4f7a42447ad1dadce6d65..08ef91907a35564520b8ccb8d9993b49fc88a391 100644 > --- a/src/zone_manager.c > +++ b/src/zone_manager.c > @@ -132,11 +132,8 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > result = find_db_instance(name, &db_inst); > if (result == ISC_R_SUCCESS) { > db_inst = NULL; > - result = ISC_R_FAILURE; > - log_error("'%s' already exists", name); > - goto cleanup; > - } else { > - result = ISC_R_SUCCESS; > + log_error("LDAP instance '%s' already exists", name); > + CLEANUP_WITH(ISC_R_EXISTS); > } > > /* Parse settings. */ > @@ -184,8 +181,7 @@ manager_create_db_instance(isc_mem_t *mctx, const char *name, > if (result != ISC_R_SUCCESS) { > /* In case we don't find any zones, we at least return > * ISC_R_SUCCESS so BIND won't exit because of this. */ > - result = ISC_R_SUCCESS; > - log_error("no valid zones found"); > + log_error_r("no valid zones found in LDAP"); > /* > * Do not jump to cleanup. Rather start timer for zone refresh. > * This is just a workaround when the LDAP server is not available > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:32:31 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:32:31 +0100 Subject: [Freeipa-devel] [PATCH 0104] Remove dead assignment and add logging to ldap_pool_connect() In-Reply-To: <50ADF80B.4080500@redhat.com> References: <50ADF712.80004@redhat.com> <50ADF80B.4080500@redhat.com> Message-ID: <20121122133230.GB12802@redhat.com> On Thu, Nov 22, 2012 at 11:01:47AM +0100, Petr Spacek wrote: > One day I will forgot my head somewhere ... the patch is attached. > > On 11/22/2012 10:57 AM, Petr Spacek wrote: > >Hello, > > > > Remove dead assignment and add logging to ldap_pool_connect(). > > > > Dead assignment was reported by Clang static code analysis. > > > > -- > Petr^2 Spacek Ack > From 0a10518a20e5ef0f0a8767d47d3306644cf2c636 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 22 Nov 2012 10:48:45 +0100 > Subject: [PATCH] Remove dead assignment and add logging to > ldap_pool_connect(). > > Dead assignment was reported by Clang static code analysis. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 407875a4f7e5952272e496ed70b18b772172bfb3..e537d9b3b76c6a7144ee7df1ddda26ed95b4ab0d 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -3094,18 +3094,18 @@ ldap_pool_connect(ldap_pool_t *pool, ldap_instance_t *ldap_inst) > ldap_conn = NULL; > CHECK(new_ldap_connection(pool, &ldap_conn)); > result = ldap_connect(ldap_inst, ldap_conn, ISC_FALSE); > - if (result == ISC_R_NOTCONNECTED || result == ISC_R_TIMEDOUT) { > - /* LDAP server is down which can happen, continue */ > - result = ISC_R_SUCCESS; > - } else if (result != ISC_R_SUCCESS) { > + /* Continue even if LDAP server is down */ > + if (result != ISC_R_NOTCONNECTED && result != ISC_R_TIMEDOUT && > + result != ISC_R_SUCCESS) { > goto cleanup; > } > pool->conns[i] = ldap_conn; > } > > return ISC_R_SUCCESS; > > cleanup: > + log_error_r("couldn't establish connection in LDAP connection pool"); > for (i = 0; i < pool->connections; i++) { > destroy_ldap_connection(&pool->conns[i]); > } > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:33:13 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:33:13 +0100 Subject: [Freeipa-devel] [PATCH 0105] Remove dead assignment in ldap_parse_zoneentry() In-Reply-To: <50AE0CB8.5050303@redhat.com> References: <50AE0CB8.5050303@redhat.com> Message-ID: <20121122133312.GC12802@redhat.com> On Thu, Nov 22, 2012 at 12:30:00PM +0100, Petr Spacek wrote: > Hello, > > this patch fixes the last warning from Clang. Any new warning should > attract our attention. > > Commit message: > Remove dead assignment in ldap_parse_zoneentry(). > > Assigned result value was never read because it is overwritten > by following CHECK()s in any case. > > Dead assignment was reported by Clang static code analysis. > > -- > Petr^2 Spacek Ack > From 850efaf7a1fce473216d5c0e07d5738c9819b01d Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 22 Nov 2012 12:23:15 +0100 > Subject: [PATCH] Remove dead assignment in ldap_parse_zoneentry(). > > Assigned result value was never read because it is overwritten > by following CHECK()s in any case. > > Dead assignment was reported by Clang static code analysis. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index e537d9b3b76c6a7144ee7df1ddda26ed95b4ab0d..57235de7da158b7a05de9e35fff2cdaaff74276c 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1334,7 +1334,6 @@ ldap_parse_zoneentry(ldap_entry_t *entry, ldap_instance_t *inst) > goto cleanup; > > zone_dynamic = (result == DNS_R_DYNAMIC); > - result = ISC_R_SUCCESS; > > /* initialize serial in zone register and always increment serial > * for a new zone (typically after BIND start) > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:38:48 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:38:48 +0100 Subject: [Freeipa-devel] [PATCH 0102] Fix error reporting for different TTLs in findrdatatype_or_create() In-Reply-To: <50ADE412.2080200@redhat.com> References: <50ADE412.2080200@redhat.com> Message-ID: <20121122133847.GA13081@redhat.com> On Thu, Nov 22, 2012 at 09:36:34AM +0100, Petr Spacek wrote: > Hello, > > Fix error reporting for different TTLs in findrdatatype_or_create(). > > Old code returned ISC_R_SUCCESS even in unsupported case. > > Bug found by Clang static code analysis. > > -- > Petr^2 Spacek Ack > From db7de384c4f047555275c164fc9dbe0a5d9269c6 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Thu, 22 Nov 2012 09:23:45 +0100 > Subject: [PATCH] Fix error reporting for different TTLs in > findrdatatype_or_create(). > > Old code returned ISC_R_SUCCESS even in unsupported case. > > Bug found by Clang static code analysis. > > Signed-off-by: Petr Spacek > --- > src/ldap_helper.c | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index 8a7765d5a650279db0417f6fb5be01a3dd2b82d4..8d23b6251b77a63cb22c484663a1169c0b1a31e3 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1600,13 +1600,15 @@ findrdatatype_or_create(isc_mem_t *mctx, ldapdb_rdatalist_t *rdatalist, > rdlist->type = rdtype; > rdlist->ttl = ttl; > APPEND(*rdatalist, rdlist, link); > - result = ISC_R_SUCCESS; > } else { > /* > * No support for different TTLs yet. > */ > - if (rdlist->ttl != ttl) > - result = ISC_R_FAILURE; > + if (rdlist->ttl != ttl) { > + log_error("different TTLs in single rdata list " > + "are not supported"); > + CLEANUP_WITH(ISC_R_NOTIMPLEMENTED); > + } > } > > *rdlistp = rdlist; > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Thu Nov 22 13:42:26 2012 From: atkac at redhat.com (Adam Tkac) Date: Thu, 22 Nov 2012 14:42:26 +0100 Subject: [Freeipa-devel] [PATCH 100] Add macro for LDAP error logging In-Reply-To: <50ACEC88.2030104@redhat.com> References: <50ACEC88.2030104@redhat.com> Message-ID: <20121122134225.GB13081@redhat.com> On Wed, Nov 21, 2012 at 04:00:24PM +0100, Petr Spacek wrote: > Hello, > > Add macro for LDAP error logging. > > -- > Petr^2 Spacek Ack > From 1d2c1d3b5024beca92417c0dc65cbfc0f4ddff25 Mon Sep 17 00:00:00 2001 > From: Petr Spacek > Date: Wed, 21 Nov 2012 15:52:39 +0100 > Subject: [PATCH] Add macro for LDAP error logging. > > Signed-off-by: Petr Spacek > --- > src/log.h | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/src/log.h b/src/log.h > index d6a40151d25b6f67cf6735ec955d45e4ebe4106c..312f24322fd0c6f9943c6beb810ac0bcd8f3896c 100644 > --- a/src/log.h > +++ b/src/log.h > @@ -54,6 +54,17 @@ > #define log_debug(level, format, ...) \ > log_write(GET_LOG_LEVEL(level), format, ##__VA_ARGS__) > > +/* LDAP logging functions */ > +#define log_ldap_error(ld) \ > + do { \ > + int err; \ > + char *errmsg = ""; \ > + if (ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err) \ > + == LDAP_OPT_SUCCESS) \ > + errmsg = ldap_err2string(err); \ > + log_error_position("LDAP error: %s", errmsg); \ > + } while (0); \ > + > void > log_write(int level, const char *format, ...) ISC_FORMAT_PRINTF(2, 3); > > -- > 1.7.11.7 > -- Adam Tkac, Red Hat, Inc. From pspacek at redhat.com Thu Nov 22 13:55:51 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 22 Nov 2012 14:55:51 +0100 Subject: [Freeipa-devel] [PATCH 0106] Fix error handling for initial zone refresh in persistent search Message-ID: <50AE2EE7.8030206@redhat.com> Hello, Fix error handling for initial zone refresh in persistent search. Old code terminates watcher thread in case of error. Now initial lookup is restarted after reconnect_interval seconds. -- Petr^2 Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-pspacek-0106-Fix-error-handling-for-initial-zone-refresh-in-persi.patch Type: text/x-patch Size: 2074 bytes Desc: not available URL: From pviktori at redhat.com Thu Nov 22 14:30:34 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Nov 2012 15:30:34 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ADF7E7.8070300@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50AA5FCC.5090605@redhat.com> <50ACC92F.1010507@redhat.com> <50ADF7E7.8070300@redhat.com> Message-ID: <50AE370A.2030802@redhat.com> On 11/22/2012 11:01 AM, Martin Kosek wrote: > On 11/21/2012 01:29 PM, Petr Viktorin wrote: >> On 11/19/2012 05:35 PM, Martin Kosek wrote: >>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>>> defaults made it to master independently (91e477b). Attaching rebased patch. >>>> >>>> Note that to continue development on f17, you will need to use the dogtag-devel >>>> repo: >>>> sudo yum-config-manager >>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>> >>>> >>>> >>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>> [...] >>>>> >>>>> For convenience, I've also pushed the changes to a personal repository. >>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>> >>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>> dogtag-10:pviktori-dogtag-10 >>>>> >>>> >>> >>> I went through all the patches again, I found one more issue with the schema >>> check. As it binds to Directory Server anonymously when retrieving the schema >>> and tests if "ipaObject" objectclass is present, it can fail and crash when >>> anonymous binds are not allowed for the Dogtag DS instance. This is what I get >>> when I disabled anonymous binds and run ipa-replica-install --setup-ca (a >>> script to turn anonymous binds off attached): >>> >>> [root at vm-104 ~]# ipa-replica-install >>> replica-info-vm-104.idm.lab.bos.redhat.com.gpg --setup-ca >>> Directory Manager (existing master) password: >>> >>> Run connection check to master >>> [...] >>> Connection from master to replica is OK. >>> >>> Connection check OK >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> LDAP error: INAPPROPRIATE_AUTH >>> Anonymous access is not allowed >>> >>> If possible, it would be good authenticate first. This should be doable, we >>> have a Directory Manager password available, after all. Some schema retrieval >>> code that we already have in IPA can be found in SchemaCache class in ldap2.py. >> >> Good point. Attaching updated patch. >> >>> We may also want to have some flag similar to --skip-conncheck which would >>> allow admin with an issue like this one skip the check when he is certain that >>> he copied the schema files. >> >> I named it --skip-schema-check. >> >>> Adding Ade to check that this scenario is actually sane and Dogtag is supposed >>> to work with anonymous access disabled for its DS instance. >>> >>> When reading the patches, I also saw few places with magic constant "7389" >>> (your "Fix schema replication from old masters" patch and Ade's patch). I >>> wonder, would "dogtag.Dogtag9Constants.DS_PORT" be more readable? >> >> Fixed in this patch, I'll look at the other one soon. >> >> >> >> For anyone who wants to test: I keep my Github branch updated. Re-running the >> fetch command will overwrite your branch with the latest changes. >> When the current issues are solved I'll repost all patches again in a single mail. >> > > This works fine. I just think that it may be useful to print some info like > 'Schema check failed, you can use --skip-schema-check to....' in case when the > following lines thrown an exception: > > + connection = ldap2.IPASimpleLDAPObject(ca_ldap_url) > + connection.start_tls_s() > + connection.simple_bind_s(DN(('cn', 'Directory Manager')), > + config.dirman_password) > > This is an output I received when dirsrv at PKI-IPA on my IPA 2.2 master was down, > the error was not very descriptive: > > # ipa-ca-install replica-info-vm-104.idm.lab.bos.redhat.com.gpg > Directory Manager (existing master) password: > ... > Connection from master to replica is OK. > > Connection check OK > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Can't contact LDAP server > # > > > Something like: > > try: > connection stuff... > except Exception: > print the info > raise > > Martin > Thanks. Attaching patch with such a message added. I've not included the suggestion to use --skip-schema-check, we want the user to fix the problem rather than skip the check. I've also included Ade's patch rebased to current master. -- Petr? -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-alee-0001-06-Changes-to-use-a-single-database-for-dogtag-and-IPA.patch Type: text/x-patch Size: 36145 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pviktori-0095-04-Fix-schema-replication-from-old-masters.patch Type: text/x-patch Size: 13040 bytes Desc: not available URL: From abokovoy at redhat.com Thu Nov 22 15:59:42 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Nov 2012 17:59:42 +0200 Subject: [Freeipa-devel] [PATCH] 0096 support Windows Server 2012 Message-ID: <20121122155942.GA9142@redhat.com> Hi, attached patch attempts to bring us up to MS-KILE version 25.0 support by verifying that if number of additional SIDs in KERB_VALIDATION_INFO structure is equal to one then this SID must be AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY, S-1-18-1 This SID means the client's identity is asserted by an authentication authority based on proof of possession of client credentials. During AD interop event at Microsoft earlier this year Simo found out that this is the case for Windows Server 2012 and we need to relax our check to allow this case. https://fedorahosted.org/freeipa/ticket/3231 I haven't tested it against Windows Server 2012 yet but sending the patch out for early check and verification. -- / Alexander Bokovoy -------------- next part -------------- >From 5c95c684722e3418352aa7ab971b2e7234e58769 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Thu, 22 Nov 2012 17:45:40 +0200 Subject: [PATCH] ipa-kdb: Support Windows 2012 Server Windows 2012 Server changed procedure how KERB_VALIDATION_INFO ([MS-PAC] section 2.5) is populated. Detailed description is available in [MS-KILE] version 25.0 and above. In particular, SidCount should be set to one and list of sids should contain the AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY SID (S-1-18-1). Refactor KERB_VALIDATION_INFO verification and add support for the case when SidCount is equal to one. https://fedorahosted.org/freeipa/ticket/3231 --- daemons/ipa-kdb/ipa_kdb_mspac.c | 30 +++++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c index 881a7a7124b3f6651c44bc393b6899d093f8dfc6..4a0d974d628fd3794054ba200b76e0530e20cef7 100644 --- a/daemons/ipa-kdb/ipa_kdb_mspac.c +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c @@ -87,6 +87,7 @@ static char *memberof_pac_attrs[] = { #define SID_ID_AUTHS 6 #define SID_SUB_AUTHS 15 #define MAX(a,b) (((a)>(b))?(a):(b)) +#define SID_AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY "S-1-18-1" static int string_to_sid(char *str, struct dom_sid *sid) { @@ -1079,10 +1080,33 @@ static krb5_error_code filter_logon_info(krb5_context context, } talloc_free(domsid); - /* According to MS-KILE, info->info->info3.sids must be zero, so check - * that it is the case here */ + /* According to MS-KILE 25.0, info->info->info3.sids may be non zero, so check + * should include different possibilities into account + * */ if (info->info->info3.sidcount != 0) { - return EINVAL; + switch (info->info->info3.sidcount) { + case 1: + /* sidcount is 1, info3.sids must contain SID_AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY */ + domsid = dom_sid_string(NULL, info->info->info3.sids[0].sid); + if (!domsid) { + return EINVAL; + } + + if (strcmp(domsid, SID_AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY) != 0) { + krb5_klog_syslog(LOG_ERR, "PAC Info mismatch: domain = %s, " + "expected extra sid to be %s, received %s ", + domain->domain_name, SID_AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY, + domsid); + talloc_free(domsid); + return EINVAL; + } + + talloc_free(domsid); + break; + default: + return EINVAL; + break; + } } /* According to MS-KILE, ResourceGroups must be zero, so check -- 1.8.0 From pviktori at redhat.com Thu Nov 22 16:54:49 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Nov 2012 17:54:49 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ACCD1E.7040509@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> <50ACA370.5060903@redhat.com> <50ACA4BB.1070107@redhat.com> <50ACCD1E.7040509@redhat.com> Message-ID: <50AE58D9.90001@redhat.com> On 11/21/2012 01:46 PM, Martin Kosek wrote: > On 11/21/2012 10:54 AM, Petr Viktorin wrote: >> On 11/21/2012 10:48 AM, Martin Kosek wrote: >>> On 11/21/2012 10:46 AM, Martin Kosek wrote: >>>> On 11/20/2012 02:59 PM, Petr Viktorin wrote: >>>>> On 11/19/2012 03:14 PM, Petr Viktorin wrote: >>>>>> On 11/19/2012 02:09 PM, Martin Kosek wrote: >>>>>>> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>>>>>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>>>>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>>>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>>>>>>> changed Dogtag >>>>>>>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>>>>>>> rebased patch. >>>>>>>>>>>> >>>>>>>>>>>> Note that to continue development on f17, you will need to use the >>>>>>>>>>>> dogtag-devel >>>>>>>>>>>> repo: >>>>>>>>>>>> sudo yum-config-manager >>>>>>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>>>>>>> [...] >>>>>>>>>>>>> >>>>>>>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>>>>>>> repository. >>>>>>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>>>>>>> >>>>>>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I started reviewing the patches, and found the first thing that looks >>>>>>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>>>>>>> single-database >>>>>>>>>>> IPA, the upgrade was OK. >>>>>>>>>>> >>>>>>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>>>>>>> removed >>>>>>>>>>> because >>>>>>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>>>>>>> instances running. >>>>>>>>>> >>>>>>>>>> You're right. This is an uninstaller error already present in 2.2: >>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>>>>>>> >>>>>>>>>> I'll start looking into it tomorrow, if nothing more important >>>>>>>>>> shows up. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for the pointer. But this is definitely not a show stopper, >>>>>>>>> running >>>>>>>>> additional DS instance seems more or less benign and as you pointed >>>>>>>>> out, it is >>>>>>>>> rather an old bug. >>>>>>>>> >>>>>>>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>>>>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>>>>>>> additional replication agreements in IPA dirsrv instance (although >>>>>>>>> targeted to >>>>>>>>> nsDS5ReplicaRoot: o=ipaca). >>>>>>>>> >>>>>>>>> First scenario: 3 IPA servers with CA in this topology: >>>>>>>>> >>>>>>>>> B - A - C >>>>>>>>> >>>>>>>>> On A: >>>>>>>>> # ipa-replica-manage list `hostname` >>>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>>> >>>>>>>>> it should not display agreements that are for IPA only, not IPA CA >>>>>>>>> ones. >>>>>>>>> >>>>>>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>>>>>>> [B] # ipa-replica-manage connect C >>>>>>>>> Connected 'B' to 'C' >>>>>>>>> >>>>>>>>> This changed the topology to: >>>>>>>>> A >>>>>>>>> / \ >>>>>>>>> B - C >>>>>>>>> >>>>>>>>> But ipa-csreplica-manage connect did not succeed then: >>>>>>>>> [B] # ipa-csreplica-manage connect C >>>>>>>>> Directory Manager password: >>>>>>>>> >>>>>>>>> This replication agreement already exists. >>>>>>>>> >>>>>>>>> Del command also failed for me: >>>>>>>>> [A] ipa-replica-manage del [C] >>>>>>>>> >>>>>>>>> Still trying to investigate why. If I manage to get some workable >>>>>>>>> fix during my >>>>>>>>> investigations, I will attach it later. >>>>>>>>> >>>>>>>>> Martin >>>>>>>> >>>>>>>> The fix for that for easier than expected. Attached patch restored >>>>>>>> the previous >>>>>>>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>>>>>>> commands >>>>>>>> - add, del, connect, disconnect and it worked fine so far. >>>>>>>> >>>>>>>> But this was a case with all D10 masters, I will need to try if that >>>>>>>> flies with >>>>>>>> D9->D10 replicas or upgraded D9 masters. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >>>>>>> to work >>>>>>> well. I just think we will need to also backport the previous patch at >>>>>>> least to >>>>>>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >>>>>>> management tool. I created a ticket for this purpose: >>>>>>> >>>>>>> https://fedorahosted.org/freeipa/ticket/3262 >>>>>>> >>>>>>> Attaching a patch for IPA 2.2 branch in case somebody is also testing >>>>>>> it. With >>>>>>> this patch, I was able to list, force-sync, re-initialize, connect, >>>>>>> disconnect >>>>>>> from 2.2 to 3.1 replica without any errors. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>> >>>>>> I checked ipa-csreplica-install, and found some more problems. >>>>>> >>>>>> In the "connect" and "disconnect" subcommands we now assume both masters >>>>>> use port 389 for the PKI DS. While the number is relatively easily >>>>>> parametrized, the assumption that both sides use the same port seems to >>>>>> run pretty deep. >>>>>> I'm working on a patch to detect if the remote server has merged DBs and >>>>>> use the appropriate port. >>>>> >>>>> Attaching patches to do this. >>>>> Patch 0100 adds an argument to IPAdmin to overrides guessing of the >>>>> protocol to >>>>> use. >>>>> Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs >>>>> involved and use those. >>>>> >>>>> Note that this touches code shared with ipa-replica-manage, please re-test >>>>> that >>>>> as well. >>>>> >>>> >>>> Works fine, I was able to create a network of few IPA 2.2 replicas and IPA 3.1 >>>> replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the >>>> agreements. No regression discovered so far. >>>> >>>> I just see that in patch 101 you touch setup_replication and force TLS as a >>>> default. But in this case, r_sslport parameter is never used and we can >>>> remove it. >>>> >>>> In 101, you also set LDAP+TLS as default connection protocol with >>>> + super(CSReplicationManager, self).__init__( >>>> + realm, hostname, dirman_passwd, port, starttls=True) >>>> ^^^^^^^^^^^^^ >>>> >>>> Wouldn't we want to make LDAP+TLS as a default also in a bunch of >>>> ReplicationManager initializations in ipa-replica-manage? Otherwise, we use >>>> ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would >>>> be a good step to do. Adding Rob and Simo to CC to correct me if I miss >>>> anything and we want to keep using ldaps/SSL by default. >>> ... adding to CC now! >>> >> >> Yes, that would be good. I think it's out of scope for this patchset, though. >> Do we have a bug for this already? >> I think John or I can include it in the >> https://fedorahosted.org/freeipa/ticket/2660 or >> https://fedorahosted.org/freeipa/ticket/2652 efforts. >> > > Right, I think we do not have to do this now. I would not include it in 2652, > it is too general. I would prefer a separate ticket (if we agree with this > change) or inclusion in 2660. > > On a different note, I tried a scenario of 3.0 split instance IPA master and > 3.1 single instance replica and I got an error again: > > # ipa-replica-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg --setup-ca > Directory Manager (existing master) password: > ... > [28/30]: enabling compatibility plugin > [29/30]: tuning directory server > [30/30]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/16]: creating certificate server user > [2/16]: configuring certificate server instance > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Unexpected error - see /var/log/ipareplica-install.log for details: > IOError: [Errno 2] No such file or directory: > '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' > > # ipa-ca-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg > ... > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds > [1/15]: creating certificate server user > [2/15]: configuring certificate server instance > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Unexpected error - see /var/log/ipareplica-ca-install.log for details: > IOError: [Errno 2] No such file or directory: > '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' > > # rpm -q pki-ca > pki-ca-10.0.0-0.52.b3.fc18.noarch > > # tail -1 /var/log/pki/pki-tomcat/ca/system > 3357.http-bio-8443-exec-1 - [21/Nov/2012:07:16:02 EST] [8] [3] In Ldap (bound) > connection pool to host vm-104.idm.lab.bos.redhat.com port 7389, Cannot connect > to LDAP server. Error: netscape.ldap.LDAPException: failed to connect to server > ldap://vm-104.idm.lab.bos.redhat.com:7389 (91) > > But when I try an ldapsearch to this address, it works: > # ldapsearch -H "ldap://vm-104.idm.lab.bos.redhat.com:7389" -s base -b > "o=ipaca" -D "cn=Directory Manager" -x -w kokos123 > # extended LDIF > > # ipaca > dn: o=ipaca > objectClass: top > objectClass: organization > o: ipaca > > Attaching relevant logs and CC-ing Ade, I think we will need his help on this one. > > IMO it is important to have this scenario working too, F17 IPA users who'd > upgrade to F18 and try to setup a replica may hit the same issue. > > Martin > I have successfully installed a 3.1 replica of a 3.0 master on my VMs. I believe the crash is due to broken setup, but I'll leave it to Ade to look at the Java exceptions. -- Petr? From pviktori at redhat.com Thu Nov 22 17:12:18 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Thu, 22 Nov 2012 18:12:18 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <1353505426.25995.24.camel@willson.li.ssimo.org> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> <1353505426.25995.24.camel@willson.li.ssimo.org> Message-ID: <50AE5CF2.9060300@redhat.com> On 11/21/2012 02:43 PM, Simo Sorce wrote: > On Wed, 2012-11-21 at 10:46 +0100, Martin Kosek wrote: >> On 11/20/2012 02:59 PM, Petr Viktorin wrote: [...] >> >> I just see that in patch 101 you touch setup_replication and force TLS as a >> default. But in this case, r_sslport parameter is never used and we can remove it. >> >> In 101, you also set LDAP+TLS as default connection protocol with >> + super(CSReplicationManager, self).__init__( >> + realm, hostname, dirman_passwd, port, starttls=True) >> ^^^^^^^^^^^^^ >> >> Wouldn't we want to make LDAP+TLS as a default also in a bunch of >> ReplicationManager initializations in ipa-replica-manage? Otherwise, we use >> ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this would >> be a good step to do. Adding Rob and Simo to CC to correct me if I miss >> anything and we want to keep using ldaps/SSL by default. > > In order of preference: > LDAP/GSSAPI > LDAP/TLS/ > LDAPS > > but using ldaps is not the end of the world, so don't tie yourself up > due to this. > > Simo. > https://fedorahosted.org/freeipa/ticket/3272 -- Petr? From simo at redhat.com Thu Nov 22 19:04:39 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Nov 2012 14:04:39 -0500 Subject: [Freeipa-devel] [PATCH] 0096 support Windows Server 2012 In-Reply-To: <20121122155942.GA9142@redhat.com> References: <20121122155942.GA9142@redhat.com> Message-ID: <1353611080.25995.42.camel@willson.li.ssimo.org> On Thu, 2012-11-22 at 17:59 +0200, Alexander Bokovoy wrote: > Hi, > > attached patch attempts to bring us up to MS-KILE version 25.0 support > by > verifying that if number of additional SIDs in KERB_VALIDATION_INFO > structure is equal to one then this SID must be > > AUTHENTICATION_AUTHORITY_ASSERTED_IDENTITY, S-1-18-1 > > This SID means the client's identity is asserted by an authentication > authority based on proof of possession of client credentials. > > During AD interop event at Microsoft earlier this year Simo found out > that this is the case for Windows Server 2012 and we need to relax our > check to allow this case. > > https://fedorahosted.org/freeipa/ticket/3231 > > I haven't tested it against Windows Server 2012 yet but sending the > patch out for early check and verification. > > NACK, there are 2 SID Windows 2012 may put there, not just S-1-2-18-1 (also -2 IIRC) and after I checked the docs I really think (As I suggested before) that we shouldn't expect a specific SID here, or in a next release a Windows server may break us again. The spec doesn't say they will never add other SIDs like these with new meanings. What we need to do is to check that NONE of these SIDs is from our own domain, or is a builtin SID. I think the best option for now, is to filter out any SID in there that we do not explicitly recognize, but not fail if there is any we do not support, just skip. So if you find S-1-18-1/S-1-18-2 you may decide to leave them in the PAC, they are useful indications to services and they can decide whether to use them or not. We need to filter out any SID that is not a regular domain SID (like wellknown SIDs and Builtin Domain SIDs) and any SID that belong to our own domain. Beyond that we should retain other SIDs (for example this structure might list an HistrorySID for the incoming user and we should give a chance to applications to make use of that information. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Fri Nov 23 08:02:28 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Nov 2012 09:02:28 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50AE58D9.90001@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> <50ACA370.5060903@redhat.com> <50ACA4BB.1070107@redhat.com> <50ACCD1E.7040509@redhat.com> <50AE58D9.90001@redh! at.com> Message-ID: <50AF2D94.50402@redhat.com> On 11/22/2012 05:54 PM, Petr Viktorin wrote: > On 11/21/2012 01:46 PM, Martin Kosek wrote: >> On 11/21/2012 10:54 AM, Petr Viktorin wrote: >>> On 11/21/2012 10:48 AM, Martin Kosek wrote: >>>> On 11/21/2012 10:46 AM, Martin Kosek wrote: >>>>> On 11/20/2012 02:59 PM, Petr Viktorin wrote: >>>>>> On 11/19/2012 03:14 PM, Petr Viktorin wrote: >>>>>>> On 11/19/2012 02:09 PM, Martin Kosek wrote: >>>>>>>> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>>>>>>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>>>>>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>>>>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>>>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>>>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>>>>>>>> changed Dogtag >>>>>>>>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>>>>>>>> rebased patch. >>>>>>>>>>>>> >>>>>>>>>>>>> Note that to continue development on f17, you will need to use the >>>>>>>>>>>>> dogtag-devel >>>>>>>>>>>>> repo: >>>>>>>>>>>>> sudo yum-config-manager >>>>>>>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>>>>>>>> [...] >>>>>>>>>>>>>> >>>>>>>>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>>>>>>>> repository. >>>>>>>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>>>>>>>> >>>>>>>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I started reviewing the patches, and found the first thing that looks >>>>>>>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>>>>>>>> single-database >>>>>>>>>>>> IPA, the upgrade was OK. >>>>>>>>>>>> >>>>>>>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>>>>>>>> removed >>>>>>>>>>>> because >>>>>>>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>>>>>>>> instances running. >>>>>>>>>>> >>>>>>>>>>> You're right. This is an uninstaller error already present in 2.2: >>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>>>>>>>> >>>>>>>>>>> I'll start looking into it tomorrow, if nothing more important >>>>>>>>>>> shows up. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks for the pointer. But this is definitely not a show stopper, >>>>>>>>>> running >>>>>>>>>> additional DS instance seems more or less benign and as you pointed >>>>>>>>>> out, it is >>>>>>>>>> rather an old bug. >>>>>>>>>> >>>>>>>>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>>>>>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>>>>>>>> additional replication agreements in IPA dirsrv instance (although >>>>>>>>>> targeted to >>>>>>>>>> nsDS5ReplicaRoot: o=ipaca). >>>>>>>>>> >>>>>>>>>> First scenario: 3 IPA servers with CA in this topology: >>>>>>>>>> >>>>>>>>>> B - A - C >>>>>>>>>> >>>>>>>>>> On A: >>>>>>>>>> # ipa-replica-manage list `hostname` >>>>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>>>> >>>>>>>>>> it should not display agreements that are for IPA only, not IPA CA >>>>>>>>>> ones. >>>>>>>>>> >>>>>>>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>>>>>>>> [B] # ipa-replica-manage connect C >>>>>>>>>> Connected 'B' to 'C' >>>>>>>>>> >>>>>>>>>> This changed the topology to: >>>>>>>>>> A >>>>>>>>>> / \ >>>>>>>>>> B - C >>>>>>>>>> >>>>>>>>>> But ipa-csreplica-manage connect did not succeed then: >>>>>>>>>> [B] # ipa-csreplica-manage connect C >>>>>>>>>> Directory Manager password: >>>>>>>>>> >>>>>>>>>> This replication agreement already exists. >>>>>>>>>> >>>>>>>>>> Del command also failed for me: >>>>>>>>>> [A] ipa-replica-manage del [C] >>>>>>>>>> >>>>>>>>>> Still trying to investigate why. If I manage to get some workable >>>>>>>>>> fix during my >>>>>>>>>> investigations, I will attach it later. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>> >>>>>>>>> The fix for that for easier than expected. Attached patch restored >>>>>>>>> the previous >>>>>>>>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>>>>>>>> commands >>>>>>>>> - add, del, connect, disconnect and it worked fine so far. >>>>>>>>> >>>>>>>>> But this was a case with all D10 masters, I will need to try if that >>>>>>>>> flies with >>>>>>>>> D9->D10 replicas or upgraded D9 masters. >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >>>>>>>> to work >>>>>>>> well. I just think we will need to also backport the previous patch at >>>>>>>> least to >>>>>>>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >>>>>>>> management tool. I created a ticket for this purpose: >>>>>>>> >>>>>>>> https://fedorahosted.org/freeipa/ticket/3262 >>>>>>>> >>>>>>>> Attaching a patch for IPA 2.2 branch in case somebody is also testing >>>>>>>> it. With >>>>>>>> this patch, I was able to list, force-sync, re-initialize, connect, >>>>>>>> disconnect >>>>>>>> from 2.2 to 3.1 replica without any errors. >>>>>>>> >>>>>>>> Martin >>>>>>>> >>>>>>> >>>>>>> I checked ipa-csreplica-install, and found some more problems. >>>>>>> >>>>>>> In the "connect" and "disconnect" subcommands we now assume both masters >>>>>>> use port 389 for the PKI DS. While the number is relatively easily >>>>>>> parametrized, the assumption that both sides use the same port seems to >>>>>>> run pretty deep. >>>>>>> I'm working on a patch to detect if the remote server has merged DBs and >>>>>>> use the appropriate port. >>>>>> >>>>>> Attaching patches to do this. >>>>>> Patch 0100 adds an argument to IPAdmin to overrides guessing of the >>>>>> protocol to >>>>>> use. >>>>>> Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs >>>>>> involved and use those. >>>>>> >>>>>> Note that this touches code shared with ipa-replica-manage, please re-test >>>>>> that >>>>>> as well. >>>>>> >>>>> >>>>> Works fine, I was able to create a network of few IPA 2.2 replicas and IPA >>>>> 3.1 >>>>> replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the >>>>> agreements. No regression discovered so far. >>>>> >>>>> I just see that in patch 101 you touch setup_replication and force TLS as a >>>>> default. But in this case, r_sslport parameter is never used and we can >>>>> remove it. >>>>> >>>>> In 101, you also set LDAP+TLS as default connection protocol with >>>>> + super(CSReplicationManager, self).__init__( >>>>> + realm, hostname, dirman_passwd, port, starttls=True) >>>>> ^^^^^^^^^^^^^ >>>>> >>>>> Wouldn't we want to make LDAP+TLS as a default also in a bunch of >>>>> ReplicationManager initializations in ipa-replica-manage? Otherwise, we use >>>>> ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this >>>>> would >>>>> be a good step to do. Adding Rob and Simo to CC to correct me if I miss >>>>> anything and we want to keep using ldaps/SSL by default. >>>> ... adding to CC now! >>>> >>> >>> Yes, that would be good. I think it's out of scope for this patchset, though. >>> Do we have a bug for this already? >>> I think John or I can include it in the >>> https://fedorahosted.org/freeipa/ticket/2660 or >>> https://fedorahosted.org/freeipa/ticket/2652 efforts. >>> >> >> Right, I think we do not have to do this now. I would not include it in 2652, >> it is too general. I would prefer a separate ticket (if we agree with this >> change) or inclusion in 2660. >> >> On a different note, I tried a scenario of 3.0 split instance IPA master and >> 3.1 single instance replica and I got an error again: >> >> # ipa-replica-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg --setup-ca >> Directory Manager (existing master) password: >> ... >> [28/30]: enabling compatibility plugin >> [29/30]: tuning directory server >> [30/30]: configuring directory to start on boot >> Done configuring directory server (dirsrv). >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >> seconds >> [1/16]: creating certificate server user >> [2/16]: configuring certificate server instance >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Unexpected error - see /var/log/ipareplica-install.log for details: >> IOError: [Errno 2] No such file or directory: >> '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' >> >> # ipa-ca-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg >> ... >> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >> seconds >> [1/15]: creating certificate server user >> [2/15]: configuring certificate server instance >> >> Your system may be partly configured. >> Run /usr/sbin/ipa-server-install --uninstall to clean up. >> >> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >> IOError: [Errno 2] No such file or directory: >> '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' >> >> # rpm -q pki-ca >> pki-ca-10.0.0-0.52.b3.fc18.noarch >> >> # tail -1 /var/log/pki/pki-tomcat/ca/system >> 3357.http-bio-8443-exec-1 - [21/Nov/2012:07:16:02 EST] [8] [3] In Ldap (bound) >> connection pool to host vm-104.idm.lab.bos.redhat.com port 7389, Cannot connect >> to LDAP server. Error: netscape.ldap.LDAPException: failed to connect to server >> ldap://vm-104.idm.lab.bos.redhat.com:7389 (91) >> >> But when I try an ldapsearch to this address, it works: >> # ldapsearch -H "ldap://vm-104.idm.lab.bos.redhat.com:7389" -s base -b >> "o=ipaca" -D "cn=Directory Manager" -x -w kokos123 >> # extended LDIF >> >> # ipaca >> dn: o=ipaca >> objectClass: top >> objectClass: organization >> o: ipaca >> >> Attaching relevant logs and CC-ing Ade, I think we will need his help on this >> one. >> >> IMO it is important to have this scenario working too, F17 IPA users who'd >> upgrade to F18 and try to setup a replica may hit the same issue. >> >> Martin >> > > I have successfully installed a 3.1 replica of a 3.0 master on my VMs. > > I believe the crash is due to broken setup, but I'll leave it to Ade to look at > the Java exceptions. > Hrm, I finally found the root cause. Its a good old SELinux AVC preventing pki-ca connecting to unreserved port 7389. I assume you have simply SELinux turned off in your setup. I have opened a SELinux policy Bug to fix that, Ade is CCed: https://bugzilla.redhat.com/show_bug.cgi?id=879516 With this in mind, and an easy workaround allowing me to create 3.0->3.1 replica (setenforce 0), I think we can wrap up and polish all patches in this thread and push this beast to master. Martin From pspacek at redhat.com Fri Nov 23 11:10:59 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:10:59 +0100 Subject: [Freeipa-devel] [PATCH 0090] Fix origin handling in dn_to_dnsname() for zone DNs In-Reply-To: <20121122121832.GA2159@redhat.com> References: <50A2795C.8070402@redhat.com> <20121122121832.GA2159@redhat.com> Message-ID: <50AF59C3.6080403@redhat.com> On 11/22/2012 01:18 PM, Adam Tkac wrote: > On Tue, Nov 13, 2012 at 05:46:20PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >I found the bug in dn_to_dnsname() during my work on >> >https://fedorahosted.org/bind-dyndb-ldap/ticket/91 >> >"Cache is not flushed properly if renamed/deleted zone has superior zone in LDAP" >> > >> >Consider this change as part of solution for ticket #91: >> > >> > Fix origin handling in dn_to_dnsname() for zone DNs. >> > >> > This patch fixes case where DN is zone (i.e. DN with single idnsName >> > component) and origin is non-NULL. >> > >> > Function str_to_isc_buffer() was fixed to not truncate last character. > Ack > Pushed to master and v2: 13ee1ec20b0e88a8e1d0dfd1f3a9fefc4089a9d9 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:13 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:13 +0100 Subject: [Freeipa-devel] [PATCH 0094] Use memory allocation macros more extensively - part 1 In-Reply-To: <20121122130705.GG2159@redhat.com> References: <50AB4AD1.8050108@redhat.com> <20121122130705.GG2159@redhat.com> Message-ID: <50AF59D1.2080502@redhat.com> On 11/22/2012 02:07 PM, Adam Tkac wrote: > On Tue, Nov 20, 2012 at 10:18:09AM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Use memory allocation macros more extensively. >> > >> > Some scattered occurences of isc_mem_* functions was replaced by macros. >> > Destroy_ldap_instance() now accepts NULL LDAP instance. >> > >> > String functions from str.c are still calling isc_mem_directly. >> > >> >This patch contain small subset of changes which affect >> >new_ldap_instance() and destroy_ldap_instance() calls. Remaining >> >changes do not require changes in new_*/destroy_* logic and will >> >follow in separate patch. > Ack > Pushed to master and v2: 0aabbf9f792984aae13a7b0e4f0713f8ce01e648 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:17 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:17 +0100 Subject: [Freeipa-devel] [PATCH 0095] Use memory allocation macros more extensively - part 2 In-Reply-To: <20121122123031.GC2159@redhat.com> References: <50AB6E74.5020803@redhat.com> <20121122123031.GC2159@redhat.com> Message-ID: <50AF59D5.9090001@redhat.com> On 11/22/2012 01:30 PM, Adam Tkac wrote: > On Tue, Nov 20, 2012 at 12:50:12PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch replaces all remaining occurrences of direct isc_mem_* >> >calls with macros. >> >The only exception is destroy_ldap_connection() which will be >> >handled in separate patch - current deallocation code is probably >> >not safe. >> > >> >Commit message: >> > Use memory allocation macros more extensively - part 2. >> > >> > Some scattered occurences of isc_mem_* functions was replaced by macros. >> > >> > String functions from str.c are still calling isc_mem_directly. > Ack > Pushed to master and v2: 0bf576474106f08065727dfa397eb8500573849e -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:22 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:22 +0100 Subject: [Freeipa-devel] [PATCH 0096] Remove unused str_*split*() functions In-Reply-To: <20121122123115.GD2159@redhat.com> References: <50AB7019.4070708@redhat.com> <20121122123115.GD2159@redhat.com> Message-ID: <50AF59DA.8030205@redhat.com> On 11/22/2012 01:31 PM, Adam Tkac wrote: > On Tue, Nov 20, 2012 at 12:57:13PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch removes never called str_*split*() functions and related >> >ld_split structure. >> > >> >We can pull it from history when necessary. > Ack > Pushed to master and v2: 014e36dcceaa1c6e6140e68fb884c806764fb2e6 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:26 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:26 +0100 Subject: [Freeipa-devel] [PATCH 0097] Deallocate LDAP connections in safe way In-Reply-To: <20121122123349.GE2159@redhat.com> References: <50AB7263.9040201@redhat.com> <20121122123349.GE2159@redhat.com> Message-ID: <50AF59DE.4050306@redhat.com> On 11/22/2012 01:33 PM, Adam Tkac wrote: > On Tue, Nov 20, 2012 at 01:06:59PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Deallocate LDAP connections in safe way. >> > >> > Current code does isc_mem_detach() before isc_mem_put() so >> > memory context reference counter is wrong for a small time frame. >> > >> > Macro MEM_PUT_AND_DETACH will handle it properly including >> > pointer zeroing. > Ack > Pushed to master and v2: bfa66088b3b4cee5037182bf30bfd0ed13663e6e -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:31 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:31 +0100 Subject: [Freeipa-devel] [PATCH 0099] Remove dead code detected by clang static analyzer In-Reply-To: <20121122131201.GH2159@redhat.com> References: <50ACEC49.2020706@redhat.com> <20121122131201.GH2159@redhat.com> Message-ID: <50AF59E3.1040607@redhat.com> On 11/22/2012 02:12 PM, Adam Tkac wrote: > On Wed, Nov 21, 2012 at 03:59:21PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Remove dead code detected by clang static analyzer. >> > > Ack > Pushed to master and v2: 10b694d5c3c495a9fede2f714cdce9191c3eab82 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:37 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:37 +0100 Subject: [Freeipa-devel] [PATCH 0102] Fix error reporting for different TTLs in findrdatatype_or_create() In-Reply-To: <20121122133847.GA13081@redhat.com> References: <50ADE412.2080200@redhat.com> <20121122133847.GA13081@redhat.com> Message-ID: <50AF59E9.3080303@redhat.com> On 11/22/2012 02:38 PM, Adam Tkac wrote: > On Thu, Nov 22, 2012 at 09:36:34AM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Fix error reporting for different TTLs in findrdatatype_or_create(). >> > >> > Old code returned ISC_R_SUCCESS even in unsupported case. >> > >> > Bug found by Clang static code analysis. >> > >> >-- >> >Petr^2 Spacek > Ack > Pushed to master and v2: a36034d54917d6f05056a3f1616441af50155be2 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:47 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:47 +0100 Subject: [Freeipa-devel] [PATCH 0091] Harden dn_to_text() conversion In-Reply-To: <20121122122848.GB2159@redhat.com> References: <50A3CEB3.7040905@redhat.com> <20121122122848.GB2159@redhat.com> Message-ID: <50AF59F3.1060607@redhat.com> On 11/22/2012 01:28 PM, Adam Tkac wrote: > On Wed, Nov 14, 2012 at 06:02:43PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Harden dn_to_text() conversion. >> > >> > All cases covered by new checks will silently cause errors >> > in other parts of plugin. This code should catch problematic >> > inputs and stop processing at the beginning. > Ack > Pushed to master and v2: 7d2645c9b9f740fec31cb88a2c094377fbcee094 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:53 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:53 +0100 Subject: [Freeipa-devel] [PATCH 0103] Remove dead assignments in manager_create_db_instance() and make log messages verbose In-Reply-To: <20121122132659.GA12802@redhat.com> References: <50ADF03B.6040104@redhat.com> <20121122132659.GA12802@redhat.com> Message-ID: <50AF59F9.4050003@redhat.com> On 11/22/2012 02:27 PM, Adam Tkac wrote: > On Thu, Nov 22, 2012 at 10:28:27AM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Remove dead assignments in manager_create_db_instance() and make >> > log messages verbose. >> > >> > Dead assignments were reported by Clang static code analysis. > Ack > Pushed to master and v2: 2af8c09574fc600c4c55311b9e8be92568c27eb7 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:11:58 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:11:58 +0100 Subject: [Freeipa-devel] [PATCH 0105] Remove dead assignment in ldap_parse_zoneentry() In-Reply-To: <20121122133312.GC12802@redhat.com> References: <50AE0CB8.5050303@redhat.com> <20121122133312.GC12802@redhat.com> Message-ID: <50AF59FE.6000600@redhat.com> On 11/22/2012 02:33 PM, Adam Tkac wrote: > On Thu, Nov 22, 2012 at 12:30:00PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch fixes the last warning from Clang. Any new warning should >> >attract our attention. >> > >> >Commit message: >> > Remove dead assignment in ldap_parse_zoneentry(). >> > >> > Assigned result value was never read because it is overwritten >> > by following CHECK()s in any case. >> > >> > Dead assignment was reported by Clang static code analysis. >> > >> >-- >> >Petr^2 Spacek > Ack > Pushed to master and v2: 7e939a9f3bb4dd541dd851321c7a454e0dca6d3c -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:12:03 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:12:03 +0100 Subject: [Freeipa-devel] [PATCH 0104] Remove dead assignment and add logging to ldap_pool_connect() In-Reply-To: <20121122133230.GB12802@redhat.com> References: <50ADF712.80004@redhat.com> <50ADF80B.4080500@redhat.com> <20121122133230.GB12802@redhat.com> Message-ID: <50AF5A03.8050905@redhat.com> On 11/22/2012 02:32 PM, Adam Tkac wrote: > On Thu, Nov 22, 2012 at 11:01:47AM +0100, Petr Spacek wrote: >> >One day I will forgot my head somewhere ... the patch is attached. >> > >> >On 11/22/2012 10:57 AM, Petr Spacek wrote: >>> > >Hello, >>> > > >>> > > Remove dead assignment and add logging to ldap_pool_connect(). >>> > > >>> > > Dead assignment was reported by Clang static code analysis. >>> > > >> > >> >-- >> >Petr^2 Spacek > Ack > Pushed to master and v2: 9cbd712d4a275e219ded1c5b7eb6edbdcba8de19 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:12:08 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:12:08 +0100 Subject: [Freeipa-devel] [PATCH 100] Add macro for LDAP error logging In-Reply-To: <20121122134225.GB13081@redhat.com> References: <50ACEC88.2030104@redhat.com> <20121122134225.GB13081@redhat.com> Message-ID: <50AF5A08.7020404@redhat.com> On 11/22/2012 02:42 PM, Adam Tkac wrote: > On Wed, Nov 21, 2012 at 04:00:24PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Add macro for LDAP error logging. >> > >> >-- >> >Petr^2 Spacek > Ack > Pushed to master and v2: 963d6c356db3ed331c946f3870c5788f9b803dc6 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:12:14 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:12:14 +0100 Subject: [Freeipa-devel] [PATCH 0093] Log memory allocation failures In-Reply-To: <20121122114542.GA1536@redhat.com> References: <50A6320F.8010102@redhat.com> <1353072274.10327.785.camel@willson.li.ssimo.org> <50A64A90.7030100@redhat.com> <20121119173330.GA11848@redhat.com> <50AB494E.6090606@redhat.com> <20121122114542.GA1536@redhat.com> Message-ID: <50AF5A0E.4030905@redhat.com> On 11/22/2012 12:45 PM, Adam Tkac wrote: > On Tue, Nov 20, 2012 at 10:11:42AM +0100, Petr Spacek wrote: >> >On 11/19/2012 06:33 PM, Adam Tkac wrote: >>> > >On Fri, Nov 16, 2012 at 03:15:44PM +0100, Petr Spacek wrote: >>>> > >>On 11/16/2012 02:24 PM, Simo Sorce wrote: >>>>> > >>>On Fri, 2012-11-16 at 13:31 +0100, Petr Spacek wrote: >>>>>> > >>>>+#define FILE_LINE_FUNC_MSG "%-15s: %4d: %-20s" >>>>>> > >>>>+#define FILE_LINE_FUNC_ARG __FILE__, __LINE__, __func__ >> > >> > >>> > >Thanks for the patch, please read my comments below. >> > >> > >>>> > >>diff --git a/src/log.h b/src/log.h >>>> > >>index 9062a4e80786b5bab806d6c9ceba1d1a9917a3e2..d6a40151d25b6f67cf6735ec955d45e4ebe4106c 100644 >>>> > >>--- a/src/log.h >>>> > >>+++ b/src/log.h >> > >> > >>>> > >>+#define log_error_position(format, ...) \ >>>> > >>+ log_error("[%-15s: %4d: %-21s] " format, \ >>> > > >>> > >Do we really need to format the format string? I would prefer to drop the >>> > >"[...]" stuff at all. >> > >> >This format will align file names, line numbers and most of function >> >names in columns. It can be handy if some error propagates through >> >call stack, but I can drop it if you want. >> > >> >Real world example: >> >[ldap_entry.c : 370: ldap_entry_getfakesoa] FAILURE: not found >> >[ldap_helper.c : 1869: add_soa_record ] FAILURE: not found >> > >> > >> >My intention is to extend logging to failures detected inside CHECK() macros. >> > >> >Currently, any failure inside CHECK() will jump to "cleanup" label, >> >so information about source of the failure is lost. >> > >> >As a result it produces error message like: >> >update_record (psearch) failed, dn >> >'idnsName=q.sub,idnsname=test,cn=dns,dc=e,dc=test' change type 0x1. >> >Records can be outdated, run `rndc reload`: not found >> > >> >Huh? What was not found? Those error messages are not useful for >> >post mortem analysis. >> > >> >With logging inside CHECK() it produces: >> >[ldap_helper.c : 3467: update_record ] FAILURE: not found >> >update_record (psearch) failed, dn >> >'idnsName=q.sub,idnsname=test,cn=dns,dc=e,dc=test' change type 0x1. >> >Records can be outdated, run `rndc reload`: not found >> > >> >File ldap_helper.c, line 3467, return code ISC_R_NOTFOUND is much >> >better information. > Ok, you convinced me. > > Ack. > Pushed to master and v2: 3aaf4e0c892590c3b46d0a99bb00607ddac2c37a -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:13:35 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:13:35 +0100 Subject: [Freeipa-devel] [PATCH 0091] Harden dn_to_text() conversion In-Reply-To: <20121122122848.GB2159@redhat.com> References: <50A3CEB3.7040905@redhat.com> <20121122122848.GB2159@redhat.com> Message-ID: <50AF5A5F.1010805@redhat.com> On 11/22/2012 01:28 PM, Adam Tkac wrote: > On Wed, Nov 14, 2012 at 06:02:43PM +0100, Petr Spacek wrote: >> >Hello, >> > >> > Harden dn_to_text() conversion. >> > >> > All cases covered by new checks will silently cause errors >> > in other parts of plugin. This code should catch problematic >> > inputs and stop processing at the beginning. > Ack > Pushed to master and v2: 7d2645c9b9f740fec31cb88a2c094377fbcee094 -- Petr^2 Spacek From pspacek at redhat.com Fri Nov 23 11:13:40 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 23 Nov 2012 12:13:40 +0100 Subject: [Freeipa-devel] [PATCH 0096] Remove unused str_*split*() functions In-Reply-To: <20121122123115.GD2159@redhat.com> References: <50AB7019.4070708@redhat.com> <20121122123115.GD2159@redhat.com> Message-ID: <50AF5A64.3040900@redhat.com> On 11/22/2012 01:31 PM, Adam Tkac wrote: > On Tue, Nov 20, 2012 at 12:57:13PM +0100, Petr Spacek wrote: >> >Hello, >> > >> >this patch removes never called str_*split*() functions and related >> >ld_split structure. >> > >> >We can pull it from history when necessary. > Ack > Pushed to master and v2: 014e36dcceaa1c6e6140e68fb884c806764fb2e6 -- Petr^2 Spacek From mkosek at redhat.com Fri Nov 23 11:58:55 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Nov 2012 12:58:55 +0100 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50AF2D94.50402@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50A513B5.1040605@redhat.com> <50A531CC.4080605@redhat.com> <50A61430.4030007@redhat.com> <50A63EC2.3020006@redhat.com> <50AA2F8F.50301@redhat.com> <50AA3ECC.9010601@redhat.com> <50AB8CCB.7020302@redhat.com> <50ACA308.4020207@redhat.com> <50ACA370.5060903@redhat.com> <50ACA4BB.1070107@redhat.com> <50ACCD1E.7040509@redhat.com> <50AE58D9.90001@redh! at.com> <50AF2D94.50402@redhat.com> Message-ID: <50AF64FF.9010208@redhat.com> On 11/23/2012 09:02 AM, Martin Kosek wrote: > On 11/22/2012 05:54 PM, Petr Viktorin wrote: >> On 11/21/2012 01:46 PM, Martin Kosek wrote: >>> On 11/21/2012 10:54 AM, Petr Viktorin wrote: >>>> On 11/21/2012 10:48 AM, Martin Kosek wrote: >>>>> On 11/21/2012 10:46 AM, Martin Kosek wrote: >>>>>> On 11/20/2012 02:59 PM, Petr Viktorin wrote: >>>>>>> On 11/19/2012 03:14 PM, Petr Viktorin wrote: >>>>>>>> On 11/19/2012 02:09 PM, Martin Kosek wrote: >>>>>>>>> On 11/16/2012 02:25 PM, Martin Kosek wrote: >>>>>>>>>> On 11/16/2012 11:23 AM, Martin Kosek wrote: >>>>>>>>>>> On 11/15/2012 07:17 PM, Petr Viktorin wrote: >>>>>>>>>>>> On 11/15/2012 05:09 PM, Martin Kosek wrote: >>>>>>>>>>>>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>>>>>>>>>>>> Recently, the specfile changed (dce53e4) and the patch for >>>>>>>>>>>>>> changed Dogtag >>>>>>>>>>>>>> defaults made it to master independently (91e477b). Attaching >>>>>>>>>>>>>> rebased patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note that to continue development on f17, you will need to use the >>>>>>>>>>>>>> dogtag-devel >>>>>>>>>>>>>> repo: >>>>>>>>>>>>>> sudo yum-config-manager >>>>>>>>>>>>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For convenience, I've also pushed the changes to a personal >>>>>>>>>>>>>>> repository. >>>>>>>>>>>>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>>>>>>>>>>>> dogtag-10:pviktori-dogtag-10 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I started reviewing the patches, and found the first thing that looks >>>>>>>>>>>>> suspicious. I had IPA with 2 databases, then upgraded it to >>>>>>>>>>>>> single-database >>>>>>>>>>>>> IPA, the upgrade was OK. >>>>>>>>>>>>> >>>>>>>>>>>>> But when I uninstalled the IPA, PKI-IPA dirsrv instance was not >>>>>>>>>>>>> removed >>>>>>>>>>>>> because >>>>>>>>>>>>> when I installed single-db IPA afterwards, I had 2 dirsrv >>>>>>>>>>>>> instances running. >>>>>>>>>>>> >>>>>>>>>>>> You're right. This is an uninstaller error already present in 2.2: >>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3258 >>>>>>>>>>>> >>>>>>>>>>>> I'll start looking into it tomorrow, if nothing more important >>>>>>>>>>>> shows up. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for the pointer. But this is definitely not a show stopper, >>>>>>>>>>> running >>>>>>>>>>> additional DS instance seems more or less benign and as you pointed >>>>>>>>>>> out, it is >>>>>>>>>>> rather an old bug. >>>>>>>>>>> >>>>>>>>>>> There are bigger issues. Now I focused on ipa-replica-manage and >>>>>>>>>>> ipa-csreplica-manage tools. ipa-replica-manage gets confused with the >>>>>>>>>>> additional replication agreements in IPA dirsrv instance (although >>>>>>>>>>> targeted to >>>>>>>>>>> nsDS5ReplicaRoot: o=ipaca). >>>>>>>>>>> >>>>>>>>>>> First scenario: 3 IPA servers with CA in this topology: >>>>>>>>>>> >>>>>>>>>>> B - A - C >>>>>>>>>>> >>>>>>>>>>> On A: >>>>>>>>>>> # ipa-replica-manage list `hostname` >>>>>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>>>>> vm-055.idm.lab.bos.redhat.com: replica >>>>>>>>>>> vm-070.idm.lab.bos.redhat.com: replica >>>>>>>>>>> >>>>>>>>>>> it should not display agreements that are for IPA only, not IPA CA >>>>>>>>>>> ones. >>>>>>>>>>> >>>>>>>>>>> Now, when I try to connect B to C, ipa-replica-manage succeeded: >>>>>>>>>>> [B] # ipa-replica-manage connect C >>>>>>>>>>> Connected 'B' to 'C' >>>>>>>>>>> >>>>>>>>>>> This changed the topology to: >>>>>>>>>>> A >>>>>>>>>>> / \ >>>>>>>>>>> B - C >>>>>>>>>>> >>>>>>>>>>> But ipa-csreplica-manage connect did not succeed then: >>>>>>>>>>> [B] # ipa-csreplica-manage connect C >>>>>>>>>>> Directory Manager password: >>>>>>>>>>> >>>>>>>>>>> This replication agreement already exists. >>>>>>>>>>> >>>>>>>>>>> Del command also failed for me: >>>>>>>>>>> [A] ipa-replica-manage del [C] >>>>>>>>>>> >>>>>>>>>>> Still trying to investigate why. If I manage to get some workable >>>>>>>>>>> fix during my >>>>>>>>>>> investigations, I will attach it later. >>>>>>>>>>> >>>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> The fix for that for easier than expected. Attached patch restored >>>>>>>>>> the previous >>>>>>>>>> functionality for ipa-(cs)replica-manage. I tried that with all basic >>>>>>>>>> commands >>>>>>>>>> - add, del, connect, disconnect and it worked fine so far. >>>>>>>>>> >>>>>>>>>> But this was a case with all D10 masters, I will need to try if that >>>>>>>>>> flies with >>>>>>>>>> D9->D10 replicas or upgraded D9 masters. >>>>>>>>>> >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>> >>>>>>>>> I managed to create a 2.2 (F17) -> 3.1 (F18) replica, everything seem >>>>>>>>> to work >>>>>>>>> well. I just think we will need to also backport the previous patch at >>>>>>>>> least to >>>>>>>>> 3.0 and 2.2 versions to fix errors with ipa-replica-manage replication >>>>>>>>> management tool. I created a ticket for this purpose: >>>>>>>>> >>>>>>>>> https://fedorahosted.org/freeipa/ticket/3262 >>>>>>>>> >>>>>>>>> Attaching a patch for IPA 2.2 branch in case somebody is also testing >>>>>>>>> it. With >>>>>>>>> this patch, I was able to list, force-sync, re-initialize, connect, >>>>>>>>> disconnect >>>>>>>>> from 2.2 to 3.1 replica without any errors. >>>>>>>>> >>>>>>>>> Martin >>>>>>>>> >>>>>>>> >>>>>>>> I checked ipa-csreplica-install, and found some more problems. >>>>>>>> >>>>>>>> In the "connect" and "disconnect" subcommands we now assume both masters >>>>>>>> use port 389 for the PKI DS. While the number is relatively easily >>>>>>>> parametrized, the assumption that both sides use the same port seems to >>>>>>>> run pretty deep. >>>>>>>> I'm working on a patch to detect if the remote server has merged DBs and >>>>>>>> use the appropriate port. >>>>>>> >>>>>>> Attaching patches to do this. >>>>>>> Patch 0100 adds an argument to IPAdmin to overrides guessing of the >>>>>>> protocol to >>>>>>> use. >>>>>>> Patch 0101 modifies ipa-csreplica-manage to figure out the ports of the DSs >>>>>>> involved and use those. >>>>>>> >>>>>>> Note that this touches code shared with ipa-replica-manage, please re-test >>>>>>> that >>>>>>> as well. >>>>>>> >>>>>> >>>>>> Works fine, I was able to create a network of few IPA 2.2 replicas and IPA >>>>>> 3.1 >>>>>> replicas and use ipa-replica-manage and ipa-csreplica-manage to play with the >>>>>> agreements. No regression discovered so far. >>>>>> >>>>>> I just see that in patch 101 you touch setup_replication and force TLS as a >>>>>> default. But in this case, r_sslport parameter is never used and we can >>>>>> remove it. >>>>>> >>>>>> In 101, you also set LDAP+TLS as default connection protocol with >>>>>> + super(CSReplicationManager, self).__init__( >>>>>> + realm, hostname, dirman_passwd, port, starttls=True) >>>>>> ^^^^^^^^^^^^^ >>>>>> >>>>>> Wouldn't we want to make LDAP+TLS as a default also in a bunch of >>>>>> ReplicationManager initializations in ipa-replica-manage? Otherwise, we use >>>>>> ldaps/SSL by default. AFAIU, LDAP+TLS is preferred over ldaps/SSL so this >>>>>> would >>>>>> be a good step to do. Adding Rob and Simo to CC to correct me if I miss >>>>>> anything and we want to keep using ldaps/SSL by default. >>>>> ... adding to CC now! >>>>> >>>> >>>> Yes, that would be good. I think it's out of scope for this patchset, though. >>>> Do we have a bug for this already? >>>> I think John or I can include it in the >>>> https://fedorahosted.org/freeipa/ticket/2660 or >>>> https://fedorahosted.org/freeipa/ticket/2652 efforts. >>>> >>> >>> Right, I think we do not have to do this now. I would not include it in 2652, >>> it is too general. I would prefer a separate ticket (if we agree with this >>> change) or inclusion in 2660. >>> >>> On a different note, I tried a scenario of 3.0 split instance IPA master and >>> 3.1 single instance replica and I got an error again: >>> >>> # ipa-replica-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg --setup-ca >>> Directory Manager (existing master) password: >>> ... >>> [28/30]: enabling compatibility plugin >>> [29/30]: tuning directory server >>> [30/30]: configuring directory to start on boot >>> Done configuring directory server (dirsrv). >>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >>> seconds >>> [1/16]: creating certificate server user >>> [2/16]: configuring certificate server instance >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Unexpected error - see /var/log/ipareplica-install.log for details: >>> IOError: [Errno 2] No such file or directory: >>> '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' >>> >>> # ipa-ca-install replica-info-vm-055.idm.lab.bos.redhat.com.gpg >>> ... >>> Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 >>> seconds >>> [1/15]: creating certificate server user >>> [2/15]: configuring certificate server instance >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> Unexpected error - see /var/log/ipareplica-ca-install.log for details: >>> IOError: [Errno 2] No such file or directory: >>> '/var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12' >>> >>> # rpm -q pki-ca >>> pki-ca-10.0.0-0.52.b3.fc18.noarch >>> >>> # tail -1 /var/log/pki/pki-tomcat/ca/system >>> 3357.http-bio-8443-exec-1 - [21/Nov/2012:07:16:02 EST] [8] [3] In Ldap (bound) >>> connection pool to host vm-104.idm.lab.bos.redhat.com port 7389, Cannot connect >>> to LDAP server. Error: netscape.ldap.LDAPException: failed to connect to server >>> ldap://vm-104.idm.lab.bos.redhat.com:7389 (91) >>> >>> But when I try an ldapsearch to this address, it works: >>> # ldapsearch -H "ldap://vm-104.idm.lab.bos.redhat.com:7389" -s base -b >>> "o=ipaca" -D "cn=Directory Manager" -x -w kokos123 >>> # extended LDIF >>> >>> # ipaca >>> dn: o=ipaca >>> objectClass: top >>> objectClass: organization >>> o: ipaca >>> >>> Attaching relevant logs and CC-ing Ade, I think we will need his help on this >>> one. >>> >>> IMO it is important to have this scenario working too, F17 IPA users who'd >>> upgrade to F18 and try to setup a replica may hit the same issue. >>> >>> Martin >>> >> >> I have successfully installed a 3.1 replica of a 3.0 master on my VMs. >> >> I believe the crash is due to broken setup, but I'll leave it to Ade to look at >> the Java exceptions. >> > > Hrm, I finally found the root cause. Its a good old SELinux AVC preventing > pki-ca connecting to unreserved port 7389. I assume you have simply SELinux > turned off in your setup. I have opened a SELinux policy Bug to fix that, Ade > is CCed: > > https://bugzilla.redhat.com/show_bug.cgi?id=879516 > > With this in mind, and an easy workaround allowing me to create 3.0->3.1 > replica (setenforce 0), I think we can wrap up and polish all patches in this > thread and push this beast to master. > > Martin > The SELinux Bug resolution is in progress, but this is not an obstacle for this patch set. We will just have to turn off the SELinux when creating a CA replica with FreeIPA with separated LDAP instance until the SELinux policy is fixed. ACK for all patches (grabbed from github branch). Pushed to master. With this patch set pushed, we should have the Dogtag10 integration pretty much complete. Thanks to everyone participating in this effort, especially to Petr and Ade! Martin From mkosek at redhat.com Fri Nov 23 12:37:44 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Nov 2012 13:37:44 +0100 Subject: [Freeipa-devel] [PATCH] 337 Filter suffix in replication management tools Message-ID: <50AF6E18.5040703@redhat.com> These 2 patches are just a backports of the patch ACKed and pushed to master in a scope of Dogtag 10 single instance patch set. Pushed to ipa-3-0, ipa-2-2. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-337-filter-suffix-in-replication-management-tools.patch Type: text/x-patch Size: 4933 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-337-ipa-2-2.patch Type: text/x-patch Size: 4863 bytes Desc: not available URL: From pviktori at redhat.com Fri Nov 23 12:44:04 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Nov 2012 13:44:04 +0100 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <1348113533.2575.14.camel@aleeredhat.laptop> References: <1348113533.2575.14.camel@aleeredhat.laptop> Message-ID: <50AF6F94.6000404@redhat.com> Since this branch became somewhat unwieldy, here's a quick summary. Patches are pushed to master (1d3ddef~..bef251a). Martin's patch was also pushed to 3.0 (83d2822) and 2.2 (18b873c). This fixes ipa-replica-manage to only manage the IPA agreements, not the PKI ones. There is an outstanding issue: SELinux prevents connecting to the old PKI DS port (7389), preventing CA replicas to old masters. https://bugzilla.redhat.com/show_bug.cgi?id=879516 Please test in permissive mode until it's fixed. -- Petr? From mkosek at redhat.com Fri Nov 23 12:49:08 2012 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 23 Nov 2012 13:49:08 +0100 Subject: [Freeipa-devel] [PATCH] Changes to use a single database for dogtag and IPA In-Reply-To: <50AF6F94.6000404@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50AF6F94.6000404@redhat.com> Message-ID: <50AF70C4.8000000@redhat.com> On 11/23/2012 01:44 PM, Petr Viktorin wrote: > Since this branch became somewhat unwieldy, here's a quick summary. > > Patches are pushed to master (1d3ddef~..bef251a). > Martin's patch was also pushed to 3.0 (83d2822) and 2.2 (18b873c). > This fixes ipa-replica-manage to only manage the IPA agreements, not the PKI ones. > > There is an outstanding issue: SELinux prevents connecting to the old PKI DS > port (7389), preventing CA replicas to old masters. > https://bugzilla.redhat.com/show_bug.cgi?id=879516 > Please test in permissive mode until it's fixed. Small addendum: permissive mode is needed only for replicas with CA, where the remote master has separate LDAP instance for Dogtag. A network of IPA 3.1 replicas should work SELinux enforced. Martin From pviktori at redhat.com Fri Nov 23 15:09:18 2012 From: pviktori at redhat.com (Petr Viktorin) Date: Fri, 23 Nov 2012 16:09:18 +0100 Subject: [Freeipa-devel] [RFE] Warnings and client capabilities (Was: [PATCH] 0062 Don't crash when server returns extra output) In-Reply-To: <508E3CAA.50506@redhat.com> References: <4FD7240A.5040400@redhat.com> <1339504707.8230.577.camel@willson.li.ssimo.org> <4FD73869.6020503@redhat.com> <4FE19398.2040401@redhat.com> <1340189270.3072.29.camel@balmora.brq.redhat.com> <1340200668.32038.150.camel@willson.li.ssimo.org> <5086BE75.6080408@redhat.com> <508952F1.5080707@redhat.com> <508A9FBA.3000605@redhat.com> <508E3CAA.50506@redhat.com> Message-ID: <50AF919E.3040009@redhat.com> On 10/29/2012 09:22 AM, Jan Cholasta wrote: > On 26.10.2012 16:35, Petr Viktorin wrote: >> On 10/25/2012 04:55 PM, Jan Cholasta wrote: >>> Hi, >>> >>> On 23.10.2012 17:57, Petr Viktorin wrote: >>>> Here is a draft design document for ticket 2732. >>>> Please comment on both the feature itself, and on how to write design >>>> documents. >>>> Petr?, please add how the UI should handle this. >>>> >>>> == Ticket summary ([https://fedorahosted.org/freeipa/ticket/2732 >>>> #2732]) == >>>> >>>> Currently the only way to display a warning on client is to raise >>>> NonFatalError. This is not particularly good, as it mutes normal >>>> command >>>> output and only one warning can be displayed at a time. >>>> >>>> Provide a mechanism for displaying arbitrary number of warnings and >>>> other messages on clients along with the normal command output. >>>> >>>> == Additional problem == >>>> >>>> The client validates the response it receives from the server. If it >>>> gets any extra items, the validation fails. Relaxing our validation is >>>> not an option. To support older clients, we need a mechanism for >>>> backwards-incompatible extensions to the API. >>>> >>>> == Solution == >>>> >>>> === Backend === >>>> >>>> Introduce a "capability" mechanism for backwards-incompatible API >>>> changes. The first capability will be "warnings": a client with this >>>> capability can get an extra key in the response dictionary, "warnings", >>>> which contains a list of non-fatal error messages. >>>> >>>> Capabilities are determined by API version. The version is linear; >>>> it is >>>> not possible for a client to support any custom subset of capabilities. >>>> >>>> If a client does not send an API version number, we will assume this is >>>> a testing client (such as a curl from the command line). Such a client >>>> is assumed to have all capabilities, but it will always receive a >>>> warning saying that forward compatibility is not guaranteed if the >>>> version number is not sent. >>> >>> I think this has potential to break stuff. An old client unaware of >>> capabilities might not send version and as a result receive unexpected >>> data, which might trigger some error. >> >> Our client always sends the version. We already use it to detect clients >> that are too old or too new. Clients that do not send it are not >> protected from breakage. They are not using the API correctly. >> >> Also, if any other clients currently exist, they're unlikely to validate >> the results as strictly as we do, so an extra "warnings" entry shouldn't >> hurt them. > > It's better to be safe than sorry, IMHO. What I'm proposing is just adding a warning when the client doesn't call the API correctly (it did happen to work before if you were lucky -- there was just no protection from incompatible server versions). I really don't see how this could cause any major trouble. And I like easy RPC calls too much :) >>>> Capabilities will be recorded in API.txt. When a new one is added, the >>>> API version must be incremented. >>>> >>>> All Commands will be updated to explicitly list 'version?' as one of >>>> their options in API.txt (most already do, and all take it). >>>> >>>> A missing version option will be set as part of validation/filling in >>>> defaults, so execute() will always get it. >>>> >>>> Helper methods will be available for checking a capability and for >>>> adding a warning to the result: >>>> >>>> add_warning(version, result, _("What you're doing is a bad idea")) >>>> >>>> will be equivalent to: >>>> >>>> if client_has_capability(version, 'warnings'): >>>> result.setdefault('warnings', []).append(_("What you're doing >>>> is a bad idea")) >>>> >>> >>> Here's a couple of things to consider: >>> >>> * There should be an API that doesn't require the version and result >>> arguments, because they might not be at hand when a warning needs to be >>> issued (e.g. in pre/post command callbacks or utility functions). >> >> I don't see how this can be done without introducing global/per-thread >> state or reworking the system. > > We already use per-thread state frequently, we can use it here as well. I'm not sold. Anyway, I think this this is outside the scope of this RFE. It can be implemented separately when it's needed, on top of the proposed API. Since it doesn't change the external API we can easily break it into a separate effort. >> >> Not having access to the output is a limitation of the callbacks. IMO >> it's a symptom of a deeper problem: they don't have access to any state >> other than what the current callbacks need, and we can't easily make >> more stuff available to them. >> I think this problem is orthogonal to this RFE and should be solved >> separately. >> >> (Note: the version is part of options, so callbacks do have acccess to >> it.) >> >>> * There should be more message levels than just "warning". I think it >>> should be at least "error", "warning", "info". >>> >>> I have included "error" here, because currently we can't send more >>> than one error back to the client, but it might be handy: >>> >>> # ipa command --opt1 ugly --opt2 uglier >>> ipa: ERROR: invalid 'opt1': must be an integer >>> ipa: ERROR: invalid 'opt2': must be at least 10 characters >> >> Unfortunately, XML-RPC doesn't allow any extra data in error messages, >> it's just errno and text. So we can't give multiple errors to the client. > > XML-RPC is not the only transport mechanism we have, so I don't think > this XML-RPC-centric thinking is appropriate. If XML-RPC does not have > native support for this, we certainly can do it some other way. > >> >> Regarding the "info" level, I don't see a use for it. Information is >> what the result dictionary already contains. > > Debugging comes to mind. My point is that this thing should be > extensible, so should we require a new message category in future, it > can be added easily. OK, then. In this case I should rename "warning" to "message" in the whole RFE. Does "warning", "info", and "debug", the latter displayed only the "-v", resp. "-d" options, sound good? Plus we'd have "error" and "critical" (unused for now because XML-RPC doesn't allow extra error data). Unfortunately, new categories can't be added too easily. Clients would have to be taught what to do with the new message types. -- Petr? From lroot at redhat.com Mon Nov 26 09:51:59 2012 From: lroot at redhat.com (Lynn Root) Date: Mon, 26 Nov 2012 04:51:59 -0500 (EST) Subject: [Freeipa-devel] [PATCH 0005] Clarified error message with ipa-client-automount In-Reply-To: <1289786929.5627402.1353923035333.JavaMail.root@redhat.com> Message-ID: <1129149924.5633962.1353923519895.JavaMail.root@redhat.com> Returns a clearer hint when user is running ipa-client-automount with possible firewall up and blocking need ports. Not sure if this patch is worded correctly in order to address the potential firewall block when running ipa-client-automount. Perhaps a different error should be thrown, rather than NOT_IPA_SERVER. Ticket: https://fedorahosted.org/freeipa/ticket/3080 Lynn Root Associate Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-lroot-0005-1-Clarified-error-message-with-ipa-client-automount.patch Type: text/x-patch Size: 1282 bytes Desc: not available URL: From loris at lgs.com.ve Mon Nov 26 19:15:15 2012 From: loris at lgs.com.ve (Loris Santamaria) Date: Mon, 26 Nov 2012 14:45:15 -0430 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <50A6959C.9050802@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> Message-ID: <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: > On 11/01/2012 10:00 AM, 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. > > > > 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! > > > Hello Loris, > > Sorry for the delay. > I finally got a moment to read about Asterisk and looked into your plans. > Based on what you are proposing there is no real tight integration > between IPA identities and services provided by IPA and Asterisk. What I > see is IPA's DS would just be used as a data store for Asterisk > configuration data and it would be managed via CLI leveraging the plugin > framework we put together. If such approach is interesting for a > customer I do not see a reason why it should not be done. I also do not > see a value of having such plugin as a part of the integrated IPA > supported offering. It is too independent and far from the core for us. > But it is definitely a starting point. It might change over time. Hi Dmitri, sorry for my late response, I was on vacation and just now resuming work on this plugin. I agree with you, this plugin while it could be useful to a number of sysadmins it is not really part of an identity management solution. > In future it might make sense to consider a different plugin that would > add schema to IPA users only and would allow users to have additional > Asterisk related attributes. I do not see a problem with user going into > IPA web UI self service to manage his personal voice mail box settings. > This seems like a logical operation. However it should be possible to > split Asterisk configuration information between IPA and some other LDAP > server or database. It might not make sense to pollute IPA with objects > and entries that do not have a good relation to what IPA is for. So the > best would be if Asterisk servers would be able to store user related > info in the identity management system like IPA while having the rest of > data about the infrastructure elsewhere. I do not know whether such > approach is possible or feasible from the Asterisk project point of > view. But if such extension for IPA users is in fact developed it has a > much better chance to become over time a part of optional but supported > portfolio of IPA plugins. No guarantees but at least such approach would > be much closer to the core of what IPA is. Ok this can be done, asterisk is very flexible in this respect, so the voice mail box information could be stored alongside the users' information. > We also took as stab at recommendations about writing such plugins. > The list of things to consider turned to be long and scary. > It is definitely a candidate for the external plugin development guide > or alike but we do not have time to spend cycles to create such a guide > now. We are still discussing how to better deliver this information to > FreeIPA community and potential plugin developers like you. Please stay > tuned. Thank you for your feedback! -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford From jfenal at gmail.com Mon Nov 26 20:04:56 2012 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Mon, 26 Nov 2012 21:04:56 +0100 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> Message-ID: 2012/11/26 Loris Santamaria > El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: > > On 11/01/2012 10:00 AM, 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. > > > > > > 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! > > > > > Hello Loris, > > > > Sorry for the delay. > > I finally got a moment to read about Asterisk and looked into your plans. > > Based on what you are proposing there is no real tight integration > > between IPA identities and services provided by IPA and Asterisk. What I > > see is IPA's DS would just be used as a data store for Asterisk > > configuration data and it would be managed via CLI leveraging the plugin > > framework we put together. If such approach is interesting for a > > customer I do not see a reason why it should not be done. I also do not > > see a value of having such plugin as a part of the integrated IPA > > supported offering. It is too independent and far from the core for us. > > But it is definitely a starting point. It might change over time. > > Hi Dmitri, sorry for my late response, I was on vacation and just now > resuming work on this plugin. > > I agree with you, this plugin while it could be useful to a number of > sysadmins it is not really part of an identity management solution. > Hi all, Wild question related to this one: would it be possible to add a plugin deployment/activation mechanism to allow admins to easily add such plugins maintained outside the IPA main tree? And a centralized repository (or at least directory) for those community plugins? Regards, J. -- J?r?me Fenal -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Mon Nov 26 20:56:17 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 26 Nov 2012 15:56:17 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> Message-ID: <1353963377.18536.24.camel@willson.li.ssimo.org> On Mon, 2012-11-26 at 21:04 +0100, J?r?me Fenal wrote: > 2012/11/26 Loris Santamaria > El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: > > On 11/01/2012 10:00 AM, 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. > > > > > > 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! > > > > > Hello Loris, > > > > Sorry for the delay. > > I finally got a moment to read about Asterisk and looked > into your plans. > > Based on what you are proposing there is no real tight > integration > > between IPA identities and services provided by IPA and > Asterisk. What I > > see is IPA's DS would just be used as a data store for > Asterisk > > configuration data and it would be managed via CLI > leveraging the plugin > > framework we put together. If such approach is interesting > for a > > customer I do not see a reason why it should not be done. I > also do not > > see a value of having such plugin as a part of the > integrated IPA > > supported offering. It is too independent and far from the > core for us. > > But it is definitely a starting point. It might change over > time. > > > Hi Dmitri, sorry for my late response, I was on vacation and > just now > resuming work on this plugin. > > I agree with you, this plugin while it could be useful to a > number of > sysadmins it is not really part of an identity management > solution. > > Hi all, > > Wild question related to this one: would it be possible to add a > plugin deployment/activation mechanism to allow admins to easily add > such plugins maintained outside the IPA main tree? Yes we want to work alongside Loris to make this happen. > And a centralized repository (or at least directory) for those > community plugins? This is a neat idea, once we'll have our first external plugin we will have to do something like this. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Nov 26 21:44:48 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 26 Nov 2012 16:44:48 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1353963377.18536.24.camel@willson.li.ssimo.org> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> <1353963377.18536.24.camel@willson.li.ssimo.org> Message-ID: <50B3E2D0.4060600@redhat.com> Simo Sorce wrote: > On Mon, 2012-11-26 at 21:04 +0100, J?r?me Fenal wrote: >> 2012/11/26 Loris Santamaria >> El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: >> > On 11/01/2012 10:00 AM, 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. >> > > >> > > 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! >> > > >> > Hello Loris, >> > >> > Sorry for the delay. >> > I finally got a moment to read about Asterisk and looked >> into your plans. >> > Based on what you are proposing there is no real tight >> integration >> > between IPA identities and services provided by IPA and >> Asterisk. What I >> > see is IPA's DS would just be used as a data store for >> Asterisk >> > configuration data and it would be managed via CLI >> leveraging the plugin >> > framework we put together. If such approach is interesting >> for a >> > customer I do not see a reason why it should not be done. I >> also do not >> > see a value of having such plugin as a part of the >> integrated IPA >> > supported offering. It is too independent and far from the >> core for us. >> > But it is definitely a starting point. It might change over >> time. >> >> >> Hi Dmitri, sorry for my late response, I was on vacation and >> just now >> resuming work on this plugin. >> >> I agree with you, this plugin while it could be useful to a >> number of >> sysadmins it is not really part of an identity management >> solution. >> >> Hi all, >> >> Wild question related to this one: would it be possible to add a >> plugin deployment/activation mechanism to allow admins to easily add >> such plugins maintained outside the IPA main tree? > > Yes we want to work alongside Loris to make this happen. > >> And a centralized repository (or at least directory) for those >> community plugins? > > This is a neat idea, once we'll have our first external plugin we will > have to do something like this. It is likely to take the form of a wiki page pointing to various plugins. I'm not sure we'd get much interest if we tried to host the repository ourselves. We'd also have to deal with all sorts of other issues like commit privileges, releases, etc. It would be a major headache on both sides. rob From dpal at redhat.com Mon Nov 26 22:30:22 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 26 Nov 2012 17:30:22 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> Message-ID: <50B3ED7E.8020209@redhat.com> On 11/26/2012 02:15 PM, Loris Santamaria wrote: > El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: >> On 11/01/2012 10:00 AM, 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. >>> >>> 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! >>> >> Hello Loris, >> >> Sorry for the delay. >> I finally got a moment to read about Asterisk and looked into your plans. >> Based on what you are proposing there is no real tight integration >> between IPA identities and services provided by IPA and Asterisk. What I >> see is IPA's DS would just be used as a data store for Asterisk >> configuration data and it would be managed via CLI leveraging the plugin >> framework we put together. If such approach is interesting for a >> customer I do not see a reason why it should not be done. I also do not >> see a value of having such plugin as a part of the integrated IPA >> supported offering. It is too independent and far from the core for us. >> But it is definitely a starting point. It might change over time. > Hi Dmitri, sorry for my late response, I was on vacation and just now > resuming work on this plugin. > > I agree with you, this plugin while it could be useful to a number of > sysadmins it is not really part of an identity management solution. > >> In future it might make sense to consider a different plugin that would >> add schema to IPA users only and would allow users to have additional >> Asterisk related attributes. I do not see a problem with user going into >> IPA web UI self service to manage his personal voice mail box settings. >> This seems like a logical operation. However it should be possible to >> split Asterisk configuration information between IPA and some other LDAP >> server or database. It might not make sense to pollute IPA with objects >> and entries that do not have a good relation to what IPA is for. So the >> best would be if Asterisk servers would be able to store user related >> info in the identity management system like IPA while having the rest of >> data about the infrastructure elsewhere. I do not know whether such >> approach is possible or feasible from the Asterisk project point of >> view. But if such extension for IPA users is in fact developed it has a >> much better chance to become over time a part of optional but supported >> portfolio of IPA plugins. No guarantees but at least such approach would >> be much closer to the core of what IPA is. > Ok this can be done, asterisk is very flexible in this respect, so the > voice mail box information could be stored alongside the users' > information. I am not sure we are on the same page. I suggested that *only* user related information will be in IPA and all other objects not related to identities will be stored elsewhere. Do you agree with such approach? It is not clear from your reply above. > >> We also took as stab at recommendations about writing such plugins. >> The list of things to consider turned to be long and scary. >> It is definitely a candidate for the external plugin development guide >> or alike but we do not have time to spend cycles to create such a guide >> now. We are still discussing how to better deliver this information to >> FreeIPA community and potential plugin developers like you. Please stay >> tuned. > Thank you for your feedback! > -- 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 Mon Nov 26 22:55:47 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 26 Nov 2012 17:55:47 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <50B3ED7E.8020209@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> <50B3ED7E.8020209@redhat.com> Message-ID: <1353970547.18536.28.camel@willson.li.ssimo.org> On Mon, 2012-11-26 at 17:30 -0500, Dmitri Pal wrote: > On 11/26/2012 02:15 PM, Loris Santamaria wrote: > > El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: > >> On 11/01/2012 10:00 AM, 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. > >>> > >>> 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! > >>> > >> Hello Loris, > >> > >> Sorry for the delay. > >> I finally got a moment to read about Asterisk and looked into your plans. > >> Based on what you are proposing there is no real tight integration > >> between IPA identities and services provided by IPA and Asterisk. What I > >> see is IPA's DS would just be used as a data store for Asterisk > >> configuration data and it would be managed via CLI leveraging the plugin > >> framework we put together. If such approach is interesting for a > >> customer I do not see a reason why it should not be done. I also do not > >> see a value of having such plugin as a part of the integrated IPA > >> supported offering. It is too independent and far from the core for us. > >> But it is definitely a starting point. It might change over time. > > Hi Dmitri, sorry for my late response, I was on vacation and just now > > resuming work on this plugin. > > > > I agree with you, this plugin while it could be useful to a number of > > sysadmins it is not really part of an identity management solution. > > > >> In future it might make sense to consider a different plugin that would > >> add schema to IPA users only and would allow users to have additional > >> Asterisk related attributes. I do not see a problem with user going into > >> IPA web UI self service to manage his personal voice mail box settings. > >> This seems like a logical operation. However it should be possible to > >> split Asterisk configuration information between IPA and some other LDAP > >> server or database. It might not make sense to pollute IPA with objects > >> and entries that do not have a good relation to what IPA is for. So the > >> best would be if Asterisk servers would be able to store user related > >> info in the identity management system like IPA while having the rest of > >> data about the infrastructure elsewhere. I do not know whether such > >> approach is possible or feasible from the Asterisk project point of > >> view. But if such extension for IPA users is in fact developed it has a > >> much better chance to become over time a part of optional but supported > >> portfolio of IPA plugins. No guarantees but at least such approach would > >> be much closer to the core of what IPA is. > > Ok this can be done, asterisk is very flexible in this respect, so the > > voice mail box information could be stored alongside the users' > > information. > > I am not sure we are on the same page. > I suggested that *only* user related information will be in IPA and all > other objects not related to identities will be stored elsewhere. > Do you agree with such approach? It is not clear from your reply above. Sorry Dmitri, why would we want that ? I do not see an issue with a subtree being used by the asterisk plugin. However I would prefer Loris to use their own OID space for the schema extensions so that we are not a bottleneck there. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Mon Nov 26 23:23:28 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 26 Nov 2012 18:23:28 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <50B3E2D0.4060600@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> <1353963377.18536.24.camel@willson.li.ssimo.org> <50B3E2D0.4060600@redhat.com> Message-ID: <1353972208.18536.33.camel@willson.li.ssimo.org> On Mon, 2012-11-26 at 16:44 -0500, Rob Crittenden wrote: > It is likely to take the form of a wiki page pointing to various > plugins. I'm not sure we'd get much interest if we tried to host the > repository ourselves. We'd also have to deal with all sorts of other > issues like commit privileges, releases, etc. It would be a major > headache on both sides. Well I guess we could have a yum repo that has pointers elsewhere, but I agree a yum repo may not be that interesting, for Fedora/RHEL it would probably be more interesting to make the plugin part of Fedora and EPEL repos. That way people gets the right bits aligned by version in the distro of choice. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Nov 26 23:41:51 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 26 Nov 2012 18:41:51 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1353970547.18536.28.camel@willson.li.ssimo.org> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> <50B3ED7E.8020209@redhat.com> <1353970547.18536.28.camel@willson.li.ssimo.org> Message-ID: <50B3FE3F.9070009@redhat.com> On 11/26/2012 05:55 PM, Simo Sorce wrote: > On Mon, 2012-11-26 at 17:30 -0500, Dmitri Pal wrote: >> On 11/26/2012 02:15 PM, Loris Santamaria wrote: >>> El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: >>>> On 11/01/2012 10:00 AM, 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. >>>>> >>>>> 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! >>>>> >>>> Hello Loris, >>>> >>>> Sorry for the delay. >>>> I finally got a moment to read about Asterisk and looked into your plans. >>>> Based on what you are proposing there is no real tight integration >>>> between IPA identities and services provided by IPA and Asterisk. What I >>>> see is IPA's DS would just be used as a data store for Asterisk >>>> configuration data and it would be managed via CLI leveraging the plugin >>>> framework we put together. If such approach is interesting for a >>>> customer I do not see a reason why it should not be done. I also do not >>>> see a value of having such plugin as a part of the integrated IPA >>>> supported offering. It is too independent and far from the core for us. >>>> But it is definitely a starting point. It might change over time. >>> Hi Dmitri, sorry for my late response, I was on vacation and just now >>> resuming work on this plugin. >>> >>> I agree with you, this plugin while it could be useful to a number of >>> sysadmins it is not really part of an identity management solution. >>> >>>> In future it might make sense to consider a different plugin that would >>>> add schema to IPA users only and would allow users to have additional >>>> Asterisk related attributes. I do not see a problem with user going into >>>> IPA web UI self service to manage his personal voice mail box settings. >>>> This seems like a logical operation. However it should be possible to >>>> split Asterisk configuration information between IPA and some other LDAP >>>> server or database. It might not make sense to pollute IPA with objects >>>> and entries that do not have a good relation to what IPA is for. So the >>>> best would be if Asterisk servers would be able to store user related >>>> info in the identity management system like IPA while having the rest of >>>> data about the infrastructure elsewhere. I do not know whether such >>>> approach is possible or feasible from the Asterisk project point of >>>> view. But if such extension for IPA users is in fact developed it has a >>>> much better chance to become over time a part of optional but supported >>>> portfolio of IPA plugins. No guarantees but at least such approach would >>>> be much closer to the core of what IPA is. >>> Ok this can be done, asterisk is very flexible in this respect, so the >>> voice mail box information could be stored alongside the users' >>> information. >> I am not sure we are on the same page. >> I suggested that *only* user related information will be in IPA and all >> other objects not related to identities will be stored elsewhere. >> Do you agree with such approach? It is not clear from your reply above. > Sorry Dmitri, > why would we want that ? > > I do not see an issue with a subtree being used by the asterisk plugin. > > However I would prefer Loris to use their own OID space for the schema > extensions so that we are not a bottleneck there. > > Simo. > OK it looks like there is some mis communication. I do no see an issue with storing all information in IPA: the data related to the users and the data that is absolutely unrelated to what IPA is about. We will do our best to help with the development of such solution regardless of the approach taken. However of it is possible to split the work into two completely unrelated plugins one for user related data and one for the rest so that these two chunks of data can come from two different sources i.e. the user related info from IPA and all the rest from some other back end it being DB, LDAP or something else then there is a higher chance that the user management plugin would be integrated over time into the core of IPA (no guarantee but there is a chance). This can be a mute point becuase it might be that Asterisk does not support ability to get data from two completely different data sources (I mean data servers not just parts of the same tree). If this is the case then only a single plugin is possible. If so there is a much lower chance that any part of this solution would be integrated into the core of IPA code. It still can be offered independently. We will have it listed on our wiki and have pointers to it but we will not be integrated. And as I said we will help regardless. On the contrary if such split is possible I would think that it would make sense to try to develop the user portion as part of the IPA tree and use IPA OIDs while the complementing part can be implemented in the external repository. I hope it is more clear now. I agree that single plugin is simpler and faster to implement but the second option also has its long term merits. I just want to make sure that these implications are factored in at the beginning of the design and development. -- 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 Tue Nov 27 00:01:27 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 26 Nov 2012 19:01:27 -0500 Subject: [Freeipa-devel] [PATCHES] Re: Changes to use a single database for dogtag and IPA In-Reply-To: <50ADF7E7.8070300@redhat.com> References: <1348113533.2575.14.camel@aleeredhat.laptop> <50640DCB.2060901@redhat.com> <50699C3B.4050200@redhat.com> <5069A430.20207@redhat.com> <1349103729.2575.109.camel@aleeredhat.laptop> <506AE5DB.9020605@redhat.com> <506B096A.1070406@redhat.com> <1349381056.2357.8.camel@aleeredhat.laptop> <506EAF01.4070002@redhat.com> <1349465098.19017.22.camel@aleeredhat.laptop> <5072F326.4040500@redhat.com> <508A8016.2050900@redhat.com> <508A814F.5090200@redhat.com> <508EA54C.9020700@redhat.com> <5092B271.3080905@redhat.com> <5092B2A4.6030306@redhat.com> <509A636C.6090408@redhat.com> <509C2DCA.2010804@redhat.com> <50A0DBC1.1060409@redhat.com> <50A25FE6.6000009@redhat.com> <50A4F9DC.2000001@redhat.com> <50AA5FCC.5090605@redhat.com> <50ACC92F.1010507@redhat.com> <50ADF7E7.8070300@redhat.com> Message-ID: <50B402D7.1080901@redhat.com> On 11/22/2012 05:01 AM, Martin Kosek wrote: > On 11/21/2012 01:29 PM, Petr Viktorin wrote: >> On 11/19/2012 05:35 PM, Martin Kosek wrote: >>> On 11/15/2012 03:19 PM, Petr Viktorin wrote: >>>> Recently, the specfile changed (dce53e4) and the patch for changed Dogtag >>>> defaults made it to master independently (91e477b). Attaching rebased patch. >>>> >>>> Note that to continue development on f17, you will need to use the dogtag-devel >>>> repo: >>>> sudo yum-config-manager >>>> --add-repo=http://nkinder.fedorapeople.org/dogtag-devel/dogtag-devel-fedora.repo >>>> >>>> >>>> >>>> On 11/13/2012 03:57 PM, Petr Viktorin wrote: >>>> [...] >>>>> For convenience, I've also pushed the changes to a personal repository. >>>>> To fetch to branch "pviktori-dogtag-10" you can do: >>>>> >>>>> git fetch -f git://github.com/encukou/freeipa.git >>>>> dogtag-10:pviktori-dogtag-10 >>>>> >>> I went through all the patches again, I found one more issue with the schema >>> check. As it binds to Directory Server anonymously when retrieving the schema >>> and tests if "ipaObject" objectclass is present, it can fail and crash when >>> anonymous binds are not allowed for the Dogtag DS instance. This is what I get >>> when I disabled anonymous binds and run ipa-replica-install --setup-ca (a >>> script to turn anonymous binds off attached): >>> >>> [root at vm-104 ~]# ipa-replica-install >>> replica-info-vm-104.idm.lab.bos.redhat.com.gpg --setup-ca >>> Directory Manager (existing master) password: >>> >>> Run connection check to master >>> [...] >>> Connection from master to replica is OK. >>> >>> Connection check OK >>> >>> Your system may be partly configured. >>> Run /usr/sbin/ipa-server-install --uninstall to clean up. >>> >>> LDAP error: INAPPROPRIATE_AUTH >>> Anonymous access is not allowed >>> >>> If possible, it would be good authenticate first. This should be doable, we >>> have a Directory Manager password available, after all. Some schema retrieval >>> code that we already have in IPA can be found in SchemaCache class in ldap2.py. >> Good point. Attaching updated patch. >> >>> We may also want to have some flag similar to --skip-conncheck which would >>> allow admin with an issue like this one skip the check when he is certain that >>> he copied the schema files. >> I named it --skip-schema-check. If we have any new command line switches we need a wiki page for this feature. The thread here also suggests that it is really worth capturing and not only for this. So please create a wiki. Later it will be possible to use in preparation to the test days. Also please link the the wiki to the ticket. >>> Adding Ade to check that this scenario is actually sane and Dogtag is supposed >>> to work with anonymous access disabled for its DS instance. >>> >>> When reading the patches, I also saw few places with magic constant "7389" >>> (your "Fix schema replication from old masters" patch and Ade's patch). I >>> wonder, would "dogtag.Dogtag9Constants.DS_PORT" be more readable? >> Fixed in this patch, I'll look at the other one soon. >> >> >> >> For anyone who wants to test: I keep my Github branch updated. Re-running the >> fetch command will overwrite your branch with the latest changes. >> When the current issues are solved I'll repost all patches again in a single mail. >> > This works fine. I just think that it may be useful to print some info like > 'Schema check failed, you can use --skip-schema-check to....' in case when the > following lines thrown an exception: > > + connection = ldap2.IPASimpleLDAPObject(ca_ldap_url) > + connection.start_tls_s() > + connection.simple_bind_s(DN(('cn', 'Directory Manager')), > + config.dirman_password) > > This is an output I received when dirsrv at PKI-IPA on my IPA 2.2 master was down, > the error was not very descriptive: > > # ipa-ca-install replica-info-vm-104.idm.lab.bos.redhat.com.gpg > Directory Manager (existing master) password: > ... > Connection from master to replica is OK. > > Connection check OK > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Can't contact LDAP server > # > > > Something like: > > try: > connection stuff... > except Exception: > print the info > raise > > 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 loris at lgs.com.ve Tue Nov 27 13:34:38 2012 From: loris at lgs.com.ve (Loris Santamaria) Date: Tue, 27 Nov 2012 09:04:38 -0430 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <50B3FE3F.9070009@redhat.com> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> <50B3ED7E.8020209@redhat.com> <1353970547.18536.28.camel@willson.li.ssimo.org> <50B3FE3F.9070009@redhat.com> Message-ID: <1354023278.9140.68.camel@toron.pzo.lgs.com.ve> El lun, 26-11-2012 a las 18:41 -0500, Dmitri Pal escribi?: > On 11/26/2012 05:55 PM, Simo Sorce wrote: > > On Mon, 2012-11-26 at 17:30 -0500, Dmitri Pal wrote: > >> On 11/26/2012 02:15 PM, Loris Santamaria wrote: > >>> El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: > >>>> On 11/01/2012 10:00 AM, 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. > >>>>> > >>>>> 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! > >>>>> > >>>> Hello Loris, > >>>> > >>>> Sorry for the delay. > >>>> I finally got a moment to read about Asterisk and looked into your plans. > >>>> Based on what you are proposing there is no real tight integration > >>>> between IPA identities and services provided by IPA and Asterisk. What I > >>>> see is IPA's DS would just be used as a data store for Asterisk > >>>> configuration data and it would be managed via CLI leveraging the plugin > >>>> framework we put together. If such approach is interesting for a > >>>> customer I do not see a reason why it should not be done. I also do not > >>>> see a value of having such plugin as a part of the integrated IPA > >>>> supported offering. It is too independent and far from the core for us. > >>>> But it is definitely a starting point. It might change over time. > >>> Hi Dmitri, sorry for my late response, I was on vacation and just now > >>> resuming work on this plugin. > >>> > >>> I agree with you, this plugin while it could be useful to a number of > >>> sysadmins it is not really part of an identity management solution. > >>> > >>>> In future it might make sense to consider a different plugin that would > >>>> add schema to IPA users only and would allow users to have additional > >>>> Asterisk related attributes. I do not see a problem with user going into > >>>> IPA web UI self service to manage his personal voice mail box settings. > >>>> This seems like a logical operation. However it should be possible to > >>>> split Asterisk configuration information between IPA and some other LDAP > >>>> server or database. It might not make sense to pollute IPA with objects > >>>> and entries that do not have a good relation to what IPA is for. So the > >>>> best would be if Asterisk servers would be able to store user related > >>>> info in the identity management system like IPA while having the rest of > >>>> data about the infrastructure elsewhere. I do not know whether such > >>>> approach is possible or feasible from the Asterisk project point of > >>>> view. But if such extension for IPA users is in fact developed it has a > >>>> much better chance to become over time a part of optional but supported > >>>> portfolio of IPA plugins. No guarantees but at least such approach would > >>>> be much closer to the core of what IPA is. > >>> Ok this can be done, asterisk is very flexible in this respect, so the > >>> voice mail box information could be stored alongside the users' > >>> information. > >> I am not sure we are on the same page. > >> I suggested that *only* user related information will be in IPA and all > >> other objects not related to identities will be stored elsewhere. > >> Do you agree with such approach? It is not clear from your reply above. > > Sorry Dmitri, > > why would we want that ? > > > > I do not see an issue with a subtree being used by the asterisk plugin. > > > > However I would prefer Loris to use their own OID space for the schema > > extensions so that we are not a bottleneck there. > > > > Simo. > > > OK it looks like there is some mis communication. > I do no see an issue with storing all information in IPA: the data > related to the users and the data that is absolutely unrelated to what > IPA is about. > We will do our best to help with the development of such solution > regardless of the approach taken. > > However of it is possible to split the work into two completely > unrelated plugins one for user related data and one for the rest so that > these two chunks of data can come from two different sources i.e. the > user related info from IPA and all the rest from some other back end it > being DB, LDAP or something else then there is a higher chance that the > user management plugin would be integrated over time into the core of > IPA (no guarantee but there is a chance). This can be a mute point > becuase it might be that Asterisk does not support ability to get data > from two completely different data sources (I mean data servers not just > parts of the same tree). If this is the case then only a single plugin > is possible. If so there is a much lower chance that any part of this > solution would be integrated into the core of IPA code. > It still can be offered independently. We will have it listed on our > wiki and have pointers to it but we will not be integrated. And as I > said we will help regardless. > On the contrary if such split is possible I would think that it would > make sense to try to develop the user portion as part of the IPA tree > and use IPA OIDs while the complementing part can be implemented in the > external repository. I hope it is more clear now. > I agree that single plugin is simpler and faster to implement but the > second option also has its long term merits. > I just want to make sure that these implications are factored in at the > beginning of the design and development. Hi all, it is indeed possible to have asterisk configuration information come from different and unrelated sources, but doing it that way we would lose all of the advantages that IPA offers. First of all, asterisk configuration information is a kind of data that is not often modified but it gets a lot of queries and this is the kind of workload where a LDAP server performs the best. Also it is much easier to replicate an LDAP server than, say, Postgres or MySQL. But then, why not use OpenLDAP or 389 Directory Server directly, using a frontend like phpLdapAdmin for data entry? Well just the thought of it brings back sad memories of hard to configure replication, missing indexes, editing spaghetti php code for extending templates. The advantages we see with IPA are: - Easy installation, easy replication management - Installs a great LDAP server, 389, reasonably well tuned for general use - A nice, easy to use python framework for managing schema, ACIs and data entry While I understand that resources are limited and the IPA team focus is on the IDM aspects of the platform, I see that this platform has the potential to become a configuration store for many applications, like bind, isc dhcp, postfix, asterisk, freeswitch, etc. So far, considering all the opinions, I think the best approach is for the plugin to keep all asterisk data under a single container (cn=asterisk) so it can be developed and distributed separately from the core of IPA, and just aim for EPEL inclusion. The user serviceable parts of the asterisk configuration (just a few voice mail settings) could be managed by extending the selfservice plugin. Thank you -- Loris Santamaria linux user #70506 xmpp:loris at lgs.com.ve Links Global Services, C.A. http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:103 at lgs.com.ve ------------------------------------------------------------ "If I'd asked my customers what they wanted, they'd have said a faster horse" - Henry Ford From edewata at redhat.com Tue Nov 27 15:48:23 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Nov 2012 09:48:23 -0600 Subject: [Freeipa-devel] [PATCH] 227 Editable sshkey field after upgrade In-Reply-To: <50ABB3E0.4050602@redhat.com> References: <50AA284C.3060001@redhat.com> <50AB51E8.9040607@redhat.com> <50ABB3E0.4050602@redhat.com> Message-ID: <50B4E0C7.7080202@redhat.com> On 11/20/2012 10:46 AM, Petr Vobornik wrote: >> I think that ipaexternalmember, gidnumber and macaddress attributes >> might cause trouble as well. They are all in objectclasses that are >> added to objects on-demand (like ipasshuser/ipasshhost is). >> >> Honza >> > > Thanks for the catch. There is a problem with macaddress. > Ipaexternalmember and gid number aren't affected because group is > converted by actions, not by editing a field. > > I additionally conditioned the write exception on having write rights > for objectclass. Update will fail without it. > > Updated patch attached. ACK. -- Endi S. Dewata From edewata at redhat.com Tue Nov 27 15:50:59 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Nov 2012 09:50:59 -0600 Subject: [Freeipa-devel] [PATCHES] 228-237 Confirmation of dialogs by keyboard, better password dialogs In-Reply-To: <50AB7D76.6010809@redhat.com> References: <50AA65E7.4070301@redhat.com> <50AA6926.6000804@redhat.com> <50AB7D76.6010809@redhat.com> Message-ID: <50B4E163.5080707@redhat.com> On 11/20/2012 6:54 AM, Petr Vobornik wrote: > New design page: http://www.freeipa.org/page/V3/WebUI_keyboard_confirmation > > Link to design page was added to tickets #3200 and #2910. > > In the ticket list of previous mail is a mistake. This effort is related > to tickets #3200, #2910 and #2884. Probably commit messages should be > amended. ACK. I had to do some reading on mixin, but the patches look good. Just some comments and related issues: 1. In patch #230 the inheritance is inverted. Previously the confirmation dialog inherits from message dialog. Now it's the other way around. Usually the higher the class in the hierarchy it will become more abstract and simpler. In this patch the confirmation dialog has an OK and a Cancel buttons, but then the message dialog simplifies it by removing the Cancel button. The code itself works just fine, but if it were me I'd try to keep the original hierarchy. On the other hand, OO discussion often times comes down to preference, so this is not really an issue. 2. It might be useful to show which button is the default button. On some OS's the default button is shown with bolder text or thicker border. How about highlighting the default button as if it were in focus (i.e. shown with black background)? If you change focus to another button then the default button will go back to normal (grey), but the point is there's always a highlighted button which will be activated if you hit Enter anywhere in the dialog. 3. The drop-down list cannot be operated with a keyboard. This is a separate issue. 4. The focus area (surrounded by dotted lines) of the down arrow in the drop-down list is incorrect. Try clicking inside a drop-down list, then hit Tab. Right now the focus area appears on the right side of the arrow and very tiny. Ideally the focus area should be a box around the arrow. This is also a separate issue. -- Endi S. Dewata From edewata at redhat.com Tue Nov 27 15:51:11 2012 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 27 Nov 2012 09:51:11 -0600 Subject: [Freeipa-devel] [PATCH] 238 WebUI: Change of default value of type of new group back to POSIX In-Reply-To: <50AC9A3F.90302@redhat.com> References: <50ABBA58.9070809@redhat.com> <1353436511.25995.7.camel@willson.li.ssimo.org> <50AC9A3F.90302@redhat.com> Message-ID: <50B4E16F.8040707@redhat.com> On 11/21/2012 3:09 AM, Petr Vobornik wrote: > On 11/20/2012 07:35 PM, Simo Sorce wrote: >> On Tue, 2012-11-20 at 18:14 +0100, Petr Vobornik wrote: >>> In FreeIPA 2.2, the default for group type was 'POSIX', in 3.0 it's >>> 'normal' (non-posix). CLI's default is 'POSIX', Web UI should use >>> 'POSIX' as well. >>> >>> https://fedorahosted.org/freeipa/ticket/3270 >> >> I see you just opened this, but IIRC the change was somewhat intentional >> because you can go non-posix -> posix but you can't do the reverse. >> >> Simo. >> > It wasn't strictly intentional, but it was a contributing factor. > > Anyway the default, both in CLI and Web UI, should be the most used > group type. AFAIK it's posix. ACK. -- Endi S. Dewata From abokovoy at redhat.com Tue Nov 27 18:37:40 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 27 Nov 2012 20:37:40 +0200 Subject: [Freeipa-devel] [PATCH] 0097 Propagate kinit errors when using trust account Message-ID: <20121127183740.GE4437@redhat.com> Hi, attached patch makes possible to see why using trust account to kinit may have failed against Active Directory DC. One common error might be time skew and there will be no chance to know about that without actually propagating the error message. https://fedorahosted.org/freeipa/ticket/3265 With the patch following message will be shown: $ ipa group-add-member adadmins_ext --external=ADX\\Domain\ Admins [member user]: [member group]: ipa: ERROR: Insufficient access: ad.lan KDC denied trust account for IPA domain with a message 'kinit: Clock skew too great while getting initial credentials' -- / Alexander Bokovoy -------------- next part -------------- >From bc2c4e9cb2595e02b1fd92e64d822459f40bd417 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Tue, 27 Nov 2012 20:31:02 +0200 Subject: [PATCH 2/2] Propagate kinit errors with trust account When using Global Catalog for resolving users and groups, one needs to authenticate against Active Directory DC using GSSAPI. Obtaining Kerberos ticket might fail. Make sure the failure message is actually returned to the user so that decision can be made about the source of issue. https://fedorahosted.org/freeipa/ticket/3265 --- ipaserver/dcerpc.py | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ipaserver/dcerpc.py b/ipaserver/dcerpc.py index 68b5ad52873753b6c78840c558636c16ea2dd803..8190bf6acd4ac3429ff2d06d2c4592bc46067ab5 100644 --- a/ipaserver/dcerpc.py +++ b/ipaserver/dcerpc.py @@ -279,6 +279,10 @@ class DomainValidator(object): if returncode == 0: return (ccache_name, principal) else: + if returncode == 1: + raise errors.ACIError( + info=_("KDC for %(domain)s denied trust account for IPA domain with a message '%(message)s'") % + dict(domain=info['dns_domain'],message=stderr.strip())) return (None, None) def resolve_against_gc(self, domain, name): -- 1.8.0 From rcritten at redhat.com Tue Nov 27 21:19:25 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 27 Nov 2012 16:19:25 -0500 Subject: [Freeipa-devel] [PATCH] 0097 Propagate kinit errors when using trust account In-Reply-To: <20121127183740.GE4437@redhat.com> References: <20121127183740.GE4437@redhat.com> Message-ID: <50B52E5D.1070807@redhat.com> Alexander Bokovoy wrote: > Hi, > > attached patch makes possible to see why using trust account to kinit > may have failed against Active Directory DC. One common error might be > time skew and there will be no chance to know about that without > actually propagating the error message. > > https://fedorahosted.org/freeipa/ticket/3265 > > With the patch following message will be shown: > > $ ipa group-add-member adadmins_ext --external=ADX\\Domain\ Admins > [member user]: [member group]: ipa: ERROR: Insufficient access: ad.lan > KDC denied trust account for IPA > domain with a message 'kinit: Clock skew too great while getting initial > credentials' ACK, pushed to master and ipa-3-0 From pspacek at redhat.com Wed Nov 28 08:23:07 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 28 Nov 2012 09:23:07 +0100 Subject: [Freeipa-devel] FreeIPA 3 installation is broken in Fedora 18 Message-ID: <50B5C9EB.8060306@redhat.com> Hello, at the moment it is not possible to install FreeIPA 3.0 to Fedora 18. With Fedora 18 + updates repos active it dies during dependency solving. I used clean F18 template on vm-077. # yum clean all Cleaning repos: fedora updates Cleaning up Everything # yum install freeipa-server Resolving Dependencies --> Running transaction check ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed --> Processing Dependency: freeipa-server-selinux = 3.0.0-3.fc18 for package: freeipa-server-3.0.0-3.fc18.x86_64 --> Processing Dependency: freeipa-python = 3.0.0-3.fc18 for package: freeipa-server-3.0.0-3.fc18.x86_64 --> Processing Dependency: freeipa-client = 3.0.0-3.fc18 for package: freeipa-server-3.0.0-3.fc18.x86_64 --> Processing Dependency: freeipa-admintools = 3.0.0-3.fc18 for package: freeipa-server-3.0.0-3.fc18.x86_64 --> Processing Dependency: dogtag-pki-common-theme for package: freeipa-server-3.0.0-3.fc18.x86_64 --> Running transaction check ---> Package freeipa-admintools.x86_64 0:3.0.0-3.fc18 will be installed ---> Package freeipa-client.x86_64 0:3.0.0-3.fc18 will be installed ---> Package freeipa-python.x86_64 0:3.0.0-3.fc18 will be installed ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed --> Processing Dependency: dogtag-pki-common-theme for package: freeipa-server-3.0.0-3.fc18.x86_64 ---> Package freeipa-server-selinux.x86_64 0:3.0.0-3.fc18 will be installed --> Finished Dependency Resolution Error: Package: freeipa-server-3.0.0-3.fc18.x86_64 (fedora) Requires: dogtag-pki-common-theme You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Dependencies are satisfied when updates-testing repo is enabled, but it fails during the ipa-server-install: # rpm -q freeipa-server freeipa-server-3.0.1-3.fc18.x86_64 # ipa-server-install -p aaaaaaaa -a aaaaaaaa The log file for this installation can be found in /var/log/ipaserver-install.log ============================================================================== This program will set up the FreeIPA Server. This includes: * Configure a stand-alone CA (dogtag) for certificate management * Configure the Network Time Daemon (ntpd) * Create and configure an instance of Directory Server * Create and configure a Kerberos Key Distribution Center (KDC) * Configure Apache (httpd) To accept the default shown in brackets, press the Enter key. Enter the fully qualified domain name of the computer on which you're setting up server software. Using the form . Example: master.example.com. Server host name [vm-077.idm.lab.test]: The domain name has been determined based on the host name. Please confirm the domain name [idm.lab.test]: The kerberos protocol requires a Realm name to be defined. This is typically the domain name converted to uppercase. Please provide a realm name [IDM.LAB.TEST]: The IPA Master Server will be configured with: Hostname: vm-077.idm.lab.test IP address: 1.2.3.77 Domain name: idm.lab.test Realm name: IDM.LAB.TEST Continue to configure the system with these values? [no]: yes The following operations may take some minutes to complete. Please wait until the prompt is returned. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd Unexpected error - see /var/log/ipaserver-install.log for details: IOError: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Last lines from /var/log/ipaserver-install.log: 2012-11-28T07:47:06Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2012-11-28T07:47:06Z DEBUG Configuring NTP daemon (ntpd) 2012-11-28T07:47:06Z DEBUG [1/4]: stopping ntpd 2012-11-28T07:47:06Z DEBUG Starting external process 2012-11-28T07:47:06Z DEBUG args=/bin/systemctl is-active ntpd.service 2012-11-28T07:47:07Z DEBUG Process finished, return code=1 2012-11-28T07:47:07Z DEBUG stdout=unknown 2012-11-28T07:47:07Z DEBUG stderr=Failed to issue method call: Unit ntpd.service is not loaded. 2012-11-28T07:47:07Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2012-11-28T07:47:07Z DEBUG Starting external process 2012-11-28T07:47:07Z DEBUG args=/bin/systemctl stop ntpd.service 2012-11-28T07:47:07Z DEBUG Process finished, return code=0 2012-11-28T07:47:07Z DEBUG stdout= 2012-11-28T07:47:07Z DEBUG stderr= 2012-11-28T07:47:07Z INFO File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 614, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 914, in main ntp.create_instance() File "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", line 158, in create_instance self.start_creation() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 358, in start_creation method() File "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", line 139, in __stop self.stop() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 262, in stop self.service.stop(instance_name, capture_output=capture_output) File "/usr/lib/python2.7/site-packages/ipapython/platform/systemd.py", line 94, in stop super(SystemdService, self).stop(instance_name) File "/usr/lib/python2.7/site-packages/ipapython/platform/base.py", line 177, in stop f = open(SVC_LIST_FILE, 'w') 2012-11-28T07:47:07Z INFO The ipa-server-install command failed, exception: IOError: [Errno 2] No such file or directory: '/var/run/ipa/services.list' This problem is apparently same as https://fedorahosted.org/freeipa/ticket/3240 Why the ticket was closed as invalid? Directory /var/run/ipa is missing in freeipa-server-3.0.1-3.fc18.x86_64.rpm . -- Petr^2 Spacek From sbose at redhat.com Wed Nov 28 08:58:21 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 28 Nov 2012 09:58:21 +0100 Subject: [Freeipa-devel] FreeIPA 3 installation is broken in Fedora 18 In-Reply-To: <50B5C9EB.8060306@redhat.com> References: <50B5C9EB.8060306@redhat.com> Message-ID: <20121128085821.GA24620@localhost.localdomain> On Wed, Nov 28, 2012 at 09:23:07AM +0100, Petr Spacek wrote: > Hello, > > at the moment it is not possible to install FreeIPA 3.0 to Fedora 18. > > With Fedora 18 + updates repos active it dies during dependency > solving. I used clean F18 template on vm-077. > > # yum clean all > Cleaning repos: fedora updates > Cleaning up Everything > > # yum install freeipa-server > > Resolving Dependencies > --> Running transaction check > ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed > --> Processing Dependency: freeipa-server-selinux = 3.0.0-3.fc18 for > package: freeipa-server-3.0.0-3.fc18.x86_64 > --> Processing Dependency: freeipa-python = 3.0.0-3.fc18 for > package: freeipa-server-3.0.0-3.fc18.x86_64 > --> Processing Dependency: freeipa-client = 3.0.0-3.fc18 for > package: freeipa-server-3.0.0-3.fc18.x86_64 > --> Processing Dependency: freeipa-admintools = 3.0.0-3.fc18 for > package: freeipa-server-3.0.0-3.fc18.x86_64 > --> Processing Dependency: dogtag-pki-common-theme for package: > freeipa-server-3.0.0-3.fc18.x86_64 > --> Running transaction check > ---> Package freeipa-admintools.x86_64 0:3.0.0-3.fc18 will be installed > ---> Package freeipa-client.x86_64 0:3.0.0-3.fc18 will be installed > ---> Package freeipa-python.x86_64 0:3.0.0-3.fc18 will be installed > ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed > --> Processing Dependency: dogtag-pki-common-theme for package: > freeipa-server-3.0.0-3.fc18.x86_64 > ---> Package freeipa-server-selinux.x86_64 0:3.0.0-3.fc18 will be installed > --> Finished Dependency Resolution > Error: Package: freeipa-server-3.0.0-3.fc18.x86_64 (fedora) > Requires: dogtag-pki-common-theme > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > > > > > Dependencies are satisfied when updates-testing repo is enabled, but > it fails during the ipa-server-install: > > # rpm -q freeipa-server > freeipa-server-3.0.1-3.fc18.x86_64 > > # ipa-server-install -p aaaaaaaa -a aaaaaaaa > > The log file for this installation can be found in /var/log/ipaserver-install.log > ============================================================================== > This program will set up the FreeIPA Server. > > This includes: > * Configure a stand-alone CA (dogtag) for certificate management > * Configure the Network Time Daemon (ntpd) > * Create and configure an instance of Directory Server > * Create and configure a Kerberos Key Distribution Center (KDC) > * Configure Apache (httpd) > > To accept the default shown in brackets, press the Enter key. > > Enter the fully qualified domain name of the computer > on which you're setting up server software. Using the form > . > Example: master.example.com. > > > Server host name [vm-077.idm.lab.test]: > > The domain name has been determined based on the host name. > > Please confirm the domain name [idm.lab.test]: > > The kerberos protocol requires a Realm name to be defined. > This is typically the domain name converted to uppercase. > > Please provide a realm name [IDM.LAB.TEST]: > > The IPA Master Server will be configured with: > Hostname: vm-077.idm.lab.test > IP address: 1.2.3.77 > Domain name: idm.lab.test > Realm name: IDM.LAB.TEST > > Continue to configure the system with these values? [no]: yes > > The following operations may take some minutes to complete. > Please wait until the prompt is returned. > > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > Unexpected error - see /var/log/ipaserver-install.log for details: > IOError: [Errno 2] No such file or directory: '/var/run/ipa/services.list' > > > Last lines from /var/log/ipaserver-install.log: > > 2012-11-28T07:47:06Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2012-11-28T07:47:06Z DEBUG Configuring NTP daemon (ntpd) > 2012-11-28T07:47:06Z DEBUG [1/4]: stopping ntpd > 2012-11-28T07:47:06Z DEBUG Starting external process > 2012-11-28T07:47:06Z DEBUG args=/bin/systemctl is-active ntpd.service > 2012-11-28T07:47:07Z DEBUG Process finished, return code=1 > 2012-11-28T07:47:07Z DEBUG stdout=unknown > > 2012-11-28T07:47:07Z DEBUG stderr=Failed to issue method call: Unit > ntpd.service is not loaded. > > 2012-11-28T07:47:07Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2012-11-28T07:47:07Z DEBUG Starting external process > 2012-11-28T07:47:07Z DEBUG args=/bin/systemctl stop ntpd.service > 2012-11-28T07:47:07Z DEBUG Process finished, return code=0 > 2012-11-28T07:47:07Z DEBUG stdout= > 2012-11-28T07:47:07Z DEBUG stderr= > 2012-11-28T07:47:07Z INFO File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 614, in run_script > return_value = main_function() > > File "/sbin/ipa-server-install", line 914, in main > ntp.create_instance() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", > line 158, in create_instance > self.start_creation() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 358, in start_creation > method() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", > line 139, in __stop > self.stop() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 262, in stop > self.service.stop(instance_name, capture_output=capture_output) > > File > "/usr/lib/python2.7/site-packages/ipapython/platform/systemd.py", > line 94, in stop > super(SystemdService, self).stop(instance_name) > > File > "/usr/lib/python2.7/site-packages/ipapython/platform/base.py", line > 177, in stop > f = open(SVC_LIST_FILE, 'w') > > 2012-11-28T07:47:07Z INFO The ipa-server-install command failed, > exception: IOError: [Errno 2] No such file or directory: > '/var/run/ipa/services.list' > > > This problem is apparently same as > https://fedorahosted.org/freeipa/ticket/3240 > > Why the ticket was closed as invalid? Directory /var/run/ipa is > missing in freeipa-server-3.0.1-3.fc18.x86_64.rpm . I think the ticket was closed because the upstream spec file already adds %{_localstatedir}/run/ipa/ to freeipa-server, but in the case of #3240<->bz873673 the RHEL6 spec file does not. I would suggest to clone https://bugzilla.redhat.com/show_bug.cgi?id=873673 for F18 so that the Fedora spec file gets fixed as well. HTH bye, Sumit > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From pspacek at redhat.com Wed Nov 28 11:14:14 2012 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 28 Nov 2012 12:14:14 +0100 Subject: [Freeipa-devel] FreeIPA 3 installation is broken in Fedora 18 In-Reply-To: <20121128085821.GA24620@localhost.localdomain> References: <50B5C9EB.8060306@redhat.com> <20121128085821.GA24620@localhost.localdomain> Message-ID: <50B5F206.7040401@redhat.com> On 11/28/2012 09:58 AM, Sumit Bose wrote: > On Wed, Nov 28, 2012 at 09:23:07AM +0100, Petr Spacek wrote: >> Hello, >> >> at the moment it is not possible to install FreeIPA 3.0 to Fedora 18. >> >> With Fedora 18 + updates repos active it dies during dependency >> solving. I used clean F18 template on vm-077. >> >> # yum clean all >> Cleaning repos: fedora updates >> Cleaning up Everything >> >> # yum install freeipa-server >> >> Resolving Dependencies >> --> Running transaction check >> ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed >> --> Processing Dependency: freeipa-server-selinux = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: freeipa-python = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: freeipa-client = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: freeipa-admintools = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: dogtag-pki-common-theme for package: >> freeipa-server-3.0.0-3.fc18.x86_64 >> --> Running transaction check >> ---> Package freeipa-admintools.x86_64 0:3.0.0-3.fc18 will be installed >> ---> Package freeipa-client.x86_64 0:3.0.0-3.fc18 will be installed >> ---> Package freeipa-python.x86_64 0:3.0.0-3.fc18 will be installed >> ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed >> --> Processing Dependency: dogtag-pki-common-theme for package: >> freeipa-server-3.0.0-3.fc18.x86_64 >> ---> Package freeipa-server-selinux.x86_64 0:3.0.0-3.fc18 will be installed >> --> Finished Dependency Resolution >> Error: Package: freeipa-server-3.0.0-3.fc18.x86_64 (fedora) >> Requires: dogtag-pki-common-theme >> You could try using --skip-broken to work around the problem >> You could try running: rpm -Va --nofiles --nodigest >> >> >> >> >> Dependencies are satisfied when updates-testing repo is enabled, but >> it fails during the ipa-server-install: >> >> # rpm -q freeipa-server >> freeipa-server-3.0.1-3.fc18.x86_64 >> >> # ipa-server-install -p aaaaaaaa -a aaaaaaaa >> >> The log file for this installation can be found in /var/log/ipaserver-install.log >> ============================================================================== >> This program will set up the FreeIPA Server. >> >> This includes: >> * Configure a stand-alone CA (dogtag) for certificate management >> * Configure the Network Time Daemon (ntpd) >> * Create and configure an instance of Directory Server >> * Create and configure a Kerberos Key Distribution Center (KDC) >> * Configure Apache (httpd) >> >> To accept the default shown in brackets, press the Enter key. >> >> Enter the fully qualified domain name of the computer >> on which you're setting up server software. Using the form >> . >> Example: master.example.com. >> >> >> Server host name [vm-077.idm.lab.test]: >> >> The domain name has been determined based on the host name. >> >> Please confirm the domain name [idm.lab.test]: >> >> The kerberos protocol requires a Realm name to be defined. >> This is typically the domain name converted to uppercase. >> >> Please provide a realm name [IDM.LAB.TEST]: >> >> The IPA Master Server will be configured with: >> Hostname: vm-077.idm.lab.test >> IP address: 1.2.3.77 >> Domain name: idm.lab.test >> Realm name: IDM.LAB.TEST >> >> Continue to configure the system with these values? [no]: yes >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> Unexpected error - see /var/log/ipaserver-install.log for details: >> IOError: [Errno 2] No such file or directory: '/var/run/ipa/services.list' >> >> >> Last lines from /var/log/ipaserver-install.log: >> >> 2012-11-28T07:47:06Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2012-11-28T07:47:06Z DEBUG Configuring NTP daemon (ntpd) >> 2012-11-28T07:47:06Z DEBUG [1/4]: stopping ntpd >> 2012-11-28T07:47:06Z DEBUG Starting external process >> 2012-11-28T07:47:06Z DEBUG args=/bin/systemctl is-active ntpd.service >> 2012-11-28T07:47:07Z DEBUG Process finished, return code=1 >> 2012-11-28T07:47:07Z DEBUG stdout=unknown >> >> 2012-11-28T07:47:07Z DEBUG stderr=Failed to issue method call: Unit >> ntpd.service is not loaded. >> >> 2012-11-28T07:47:07Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2012-11-28T07:47:07Z DEBUG Starting external process >> 2012-11-28T07:47:07Z DEBUG args=/bin/systemctl stop ntpd.service >> 2012-11-28T07:47:07Z DEBUG Process finished, return code=0 >> 2012-11-28T07:47:07Z DEBUG stdout= >> 2012-11-28T07:47:07Z DEBUG stderr= >> 2012-11-28T07:47:07Z INFO File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 614, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-server-install", line 914, in main >> ntp.create_instance() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", >> line 158, in create_instance >> self.start_creation() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 358, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", >> line 139, in __stop >> self.stop() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 262, in stop >> self.service.stop(instance_name, capture_output=capture_output) >> >> File >> "/usr/lib/python2.7/site-packages/ipapython/platform/systemd.py", >> line 94, in stop >> super(SystemdService, self).stop(instance_name) >> >> File >> "/usr/lib/python2.7/site-packages/ipapython/platform/base.py", line >> 177, in stop >> f = open(SVC_LIST_FILE, 'w') >> >> 2012-11-28T07:47:07Z INFO The ipa-server-install command failed, >> exception: IOError: [Errno 2] No such file or directory: >> '/var/run/ipa/services.list' >> >> >> This problem is apparently same as >> https://fedorahosted.org/freeipa/ticket/3240 >> >> Why the ticket was closed as invalid? Directory /var/run/ipa is >> missing in freeipa-server-3.0.1-3.fc18.x86_64.rpm . > > I think the ticket was closed because the upstream spec file already > adds %{_localstatedir}/run/ipa/ to freeipa-server, but in the case of > #3240<->bz873673 the RHEL6 spec file does not. I would suggest to clone > https://bugzilla.redhat.com/show_bug.cgi?id=873673 for F18 so that the > Fedora spec file gets fixed as well. https://bugzilla.redhat.com/show_bug.cgi?id=880995 -- Petr^2 Spacek From rcritten at redhat.com Wed Nov 28 13:44:55 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 28 Nov 2012 08:44:55 -0500 Subject: [Freeipa-devel] FreeIPA 3 installation is broken in Fedora 18 In-Reply-To: <20121128085821.GA24620@localhost.localdomain> References: <50B5C9EB.8060306@redhat.com> <20121128085821.GA24620@localhost.localdomain> Message-ID: <50B61557.8020307@redhat.com> Sumit Bose wrote: > On Wed, Nov 28, 2012 at 09:23:07AM +0100, Petr Spacek wrote: >> Hello, >> >> at the moment it is not possible to install FreeIPA 3.0 to Fedora 18. >> >> With Fedora 18 + updates repos active it dies during dependency >> solving. I used clean F18 template on vm-077. >> >> # yum clean all >> Cleaning repos: fedora updates >> Cleaning up Everything >> >> # yum install freeipa-server >> >> Resolving Dependencies >> --> Running transaction check >> ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed >> --> Processing Dependency: freeipa-server-selinux = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: freeipa-python = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: freeipa-client = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: freeipa-admintools = 3.0.0-3.fc18 for >> package: freeipa-server-3.0.0-3.fc18.x86_64 >> --> Processing Dependency: dogtag-pki-common-theme for package: >> freeipa-server-3.0.0-3.fc18.x86_64 >> --> Running transaction check >> ---> Package freeipa-admintools.x86_64 0:3.0.0-3.fc18 will be installed >> ---> Package freeipa-client.x86_64 0:3.0.0-3.fc18 will be installed >> ---> Package freeipa-python.x86_64 0:3.0.0-3.fc18 will be installed >> ---> Package freeipa-server.x86_64 0:3.0.0-3.fc18 will be installed >> --> Processing Dependency: dogtag-pki-common-theme for package: >> freeipa-server-3.0.0-3.fc18.x86_64 >> ---> Package freeipa-server-selinux.x86_64 0:3.0.0-3.fc18 will be installed >> --> Finished Dependency Resolution >> Error: Package: freeipa-server-3.0.0-3.fc18.x86_64 (fedora) >> Requires: dogtag-pki-common-theme >> You could try using --skip-broken to work around the problem >> You could try running: rpm -Va --nofiles --nodigest >> >> >> >> >> Dependencies are satisfied when updates-testing repo is enabled, but >> it fails during the ipa-server-install: >> >> # rpm -q freeipa-server >> freeipa-server-3.0.1-3.fc18.x86_64 >> >> # ipa-server-install -p aaaaaaaa -a aaaaaaaa >> >> The log file for this installation can be found in /var/log/ipaserver-install.log >> ============================================================================== >> This program will set up the FreeIPA Server. >> >> This includes: >> * Configure a stand-alone CA (dogtag) for certificate management >> * Configure the Network Time Daemon (ntpd) >> * Create and configure an instance of Directory Server >> * Create and configure a Kerberos Key Distribution Center (KDC) >> * Configure Apache (httpd) >> >> To accept the default shown in brackets, press the Enter key. >> >> Enter the fully qualified domain name of the computer >> on which you're setting up server software. Using the form >> . >> Example: master.example.com. >> >> >> Server host name [vm-077.idm.lab.test]: >> >> The domain name has been determined based on the host name. >> >> Please confirm the domain name [idm.lab.test]: >> >> The kerberos protocol requires a Realm name to be defined. >> This is typically the domain name converted to uppercase. >> >> Please provide a realm name [IDM.LAB.TEST]: >> >> The IPA Master Server will be configured with: >> Hostname: vm-077.idm.lab.test >> IP address: 1.2.3.77 >> Domain name: idm.lab.test >> Realm name: IDM.LAB.TEST >> >> Continue to configure the system with these values? [no]: yes >> >> The following operations may take some minutes to complete. >> Please wait until the prompt is returned. >> >> Configuring NTP daemon (ntpd) >> [1/4]: stopping ntpd >> Unexpected error - see /var/log/ipaserver-install.log for details: >> IOError: [Errno 2] No such file or directory: '/var/run/ipa/services.list' >> >> >> Last lines from /var/log/ipaserver-install.log: >> >> 2012-11-28T07:47:06Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2012-11-28T07:47:06Z DEBUG Configuring NTP daemon (ntpd) >> 2012-11-28T07:47:06Z DEBUG [1/4]: stopping ntpd >> 2012-11-28T07:47:06Z DEBUG Starting external process >> 2012-11-28T07:47:06Z DEBUG args=/bin/systemctl is-active ntpd.service >> 2012-11-28T07:47:07Z DEBUG Process finished, return code=1 >> 2012-11-28T07:47:07Z DEBUG stdout=unknown >> >> 2012-11-28T07:47:07Z DEBUG stderr=Failed to issue method call: Unit >> ntpd.service is not loaded. >> >> 2012-11-28T07:47:07Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2012-11-28T07:47:07Z DEBUG Starting external process >> 2012-11-28T07:47:07Z DEBUG args=/bin/systemctl stop ntpd.service >> 2012-11-28T07:47:07Z DEBUG Process finished, return code=0 >> 2012-11-28T07:47:07Z DEBUG stdout= >> 2012-11-28T07:47:07Z DEBUG stderr= >> 2012-11-28T07:47:07Z INFO File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 614, in run_script >> return_value = main_function() >> >> File "/sbin/ipa-server-install", line 914, in main >> ntp.create_instance() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", >> line 158, in create_instance >> self.start_creation() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 358, in start_creation >> method() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/ntpinstance.py", >> line 139, in __stop >> self.stop() >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 262, in stop >> self.service.stop(instance_name, capture_output=capture_output) >> >> File >> "/usr/lib/python2.7/site-packages/ipapython/platform/systemd.py", >> line 94, in stop >> super(SystemdService, self).stop(instance_name) >> >> File >> "/usr/lib/python2.7/site-packages/ipapython/platform/base.py", line >> 177, in stop >> f = open(SVC_LIST_FILE, 'w') >> >> 2012-11-28T07:47:07Z INFO The ipa-server-install command failed, >> exception: IOError: [Errno 2] No such file or directory: >> '/var/run/ipa/services.list' >> >> >> This problem is apparently same as >> https://fedorahosted.org/freeipa/ticket/3240 >> >> Why the ticket was closed as invalid? Directory /var/run/ipa is >> missing in freeipa-server-3.0.1-3.fc18.x86_64.rpm . > > I think the ticket was closed because the upstream spec file already > adds %{_localstatedir}/run/ipa/ to freeipa-server, but in the case of > #3240<->bz873673 the RHEL6 spec file does not. I would suggest to clone > https://bugzilla.redhat.com/show_bug.cgi?id=873673 for F18 so that the > Fedora spec file gets fixed as well. The RHEL-6 bug was closed because RHEL-6 doesn't use systemd so this file doesn't apply. rob From simo at redhat.com Wed Nov 28 17:44:27 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Nov 2012 12:44:27 -0500 Subject: [Freeipa-devel] [PATCH] Special case NFS related ticket to avoid attaching MS-PACs Message-ID: <1354124667.12309.18.camel@willson.li.ssimo.org> Fixes: https://fedorahosted.org/freeipa/ticket/3263 Details in the commit. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-MS-PAC-Special-case-NFS-services.patch Type: text/x-patch Size: 3083 bytes Desc: not available URL: From sbose at redhat.com Wed Nov 28 20:29:25 2012 From: sbose at redhat.com (Sumit Bose) Date: Wed, 28 Nov 2012 21:29:25 +0100 Subject: [Freeipa-devel] [PATCH] Special case NFS related ticket to avoid attaching MS-PACs In-Reply-To: <1354124667.12309.18.camel@willson.li.ssimo.org> References: <1354124667.12309.18.camel@willson.li.ssimo.org> Message-ID: <20121128202925.GB25275@localhost.localdomain> On Wed, Nov 28, 2012 at 12:44:27PM -0500, Simo Sorce wrote: > Fixes: https://fedorahosted.org/freeipa/ticket/3263 > > Details in the commit. ACK bye, Sumit > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Nov 29 00:40:29 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 28 Nov 2012 19:40:29 -0500 Subject: [Freeipa-devel] RFC: freeipa-asterisk plugin In-Reply-To: <1354023278.9140.68.camel@toron.pzo.lgs.com.ve> References: <1351778431.32488.26.camel@toron.pzo.lgs.com.ve> <50A6959C.9050802@redhat.com> <1353957315.9140.41.camel@toron.pzo.lgs.com.ve> <50B3ED7E.8020209@redhat.com> <1353970547.18536.28.camel@willson.li.ssimo.org> <50B3FE3F.9070009@redhat.com> <1354023278.9140.68.camel@toron.pzo.lgs.com.ve> Message-ID: <50B6AEFD.9020701@redhat.com> On 11/27/2012 08:34 AM, Loris Santamaria wrote: > El lun, 26-11-2012 a las 18:41 -0500, Dmitri Pal escribi?: >> On 11/26/2012 05:55 PM, Simo Sorce wrote: >>> On Mon, 2012-11-26 at 17:30 -0500, Dmitri Pal wrote: >>>> On 11/26/2012 02:15 PM, Loris Santamaria wrote: >>>>> El vie, 16-11-2012 a las 14:35 -0500, Dmitri Pal escribi?: >>>>>> On 11/01/2012 10:00 AM, 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. >>>>>>> >>>>>>> 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! >>>>>>> >>>>>> Hello Loris, >>>>>> >>>>>> Sorry for the delay. >>>>>> I finally got a moment to read about Asterisk and looked into your plans. >>>>>> Based on what you are proposing there is no real tight integration >>>>>> between IPA identities and services provided by IPA and Asterisk. What I >>>>>> see is IPA's DS would just be used as a data store for Asterisk >>>>>> configuration data and it would be managed via CLI leveraging the plugin >>>>>> framework we put together. If such approach is interesting for a >>>>>> customer I do not see a reason why it should not be done. I also do not >>>>>> see a value of having such plugin as a part of the integrated IPA >>>>>> supported offering. It is too independent and far from the core for us. >>>>>> But it is definitely a starting point. It might change over time. >>>>> Hi Dmitri, sorry for my late response, I was on vacation and just now >>>>> resuming work on this plugin. >>>>> >>>>> I agree with you, this plugin while it could be useful to a number of >>>>> sysadmins it is not really part of an identity management solution. >>>>> >>>>>> In future it might make sense to consider a different plugin that would >>>>>> add schema to IPA users only and would allow users to have additional >>>>>> Asterisk related attributes. I do not see a problem with user going into >>>>>> IPA web UI self service to manage his personal voice mail box settings. >>>>>> This seems like a logical operation. However it should be possible to >>>>>> split Asterisk configuration information between IPA and some other LDAP >>>>>> server or database. It might not make sense to pollute IPA with objects >>>>>> and entries that do not have a good relation to what IPA is for. So the >>>>>> best would be if Asterisk servers would be able to store user related >>>>>> info in the identity management system like IPA while having the rest of >>>>>> data about the infrastructure elsewhere. I do not know whether such >>>>>> approach is possible or feasible from the Asterisk project point of >>>>>> view. But if such extension for IPA users is in fact developed it has a >>>>>> much better chance to become over time a part of optional but supported >>>>>> portfolio of IPA plugins. No guarantees but at least such approach would >>>>>> be much closer to the core of what IPA is. >>>>> Ok this can be done, asterisk is very flexible in this respect, so the >>>>> voice mail box information could be stored alongside the users' >>>>> information. >>>> I am not sure we are on the same page. >>>> I suggested that *only* user related information will be in IPA and all >>>> other objects not related to identities will be stored elsewhere. >>>> Do you agree with such approach? It is not clear from your reply above. >>> Sorry Dmitri, >>> why would we want that ? >>> >>> I do not see an issue with a subtree being used by the asterisk plugin. >>> >>> However I would prefer Loris to use their own OID space for the schema >>> extensions so that we are not a bottleneck there. >>> >>> Simo. >>> >> OK it looks like there is some mis communication. >> I do no see an issue with storing all information in IPA: the data >> related to the users and the data that is absolutely unrelated to what >> IPA is about. >> We will do our best to help with the development of such solution >> regardless of the approach taken. >> >> However of it is possible to split the work into two completely >> unrelated plugins one for user related data and one for the rest so that >> these two chunks of data can come from two different sources i.e. the >> user related info from IPA and all the rest from some other back end it >> being DB, LDAP or something else then there is a higher chance that the >> user management plugin would be integrated over time into the core of >> IPA (no guarantee but there is a chance). This can be a mute point >> becuase it might be that Asterisk does not support ability to get data >> from two completely different data sources (I mean data servers not just >> parts of the same tree). If this is the case then only a single plugin >> is possible. If so there is a much lower chance that any part of this >> solution would be integrated into the core of IPA code. >> It still can be offered independently. We will have it listed on our >> wiki and have pointers to it but we will not be integrated. And as I >> said we will help regardless. >> On the contrary if such split is possible I would think that it would >> make sense to try to develop the user portion as part of the IPA tree >> and use IPA OIDs while the complementing part can be implemented in the >> external repository. I hope it is more clear now. >> I agree that single plugin is simpler and faster to implement but the >> second option also has its long term merits. >> I just want to make sure that these implications are factored in at the >> beginning of the design and development. > Hi all, > > it is indeed possible to have asterisk configuration information come > from different and unrelated sources, but doing it that way we would > lose all of the advantages that IPA offers. > > First of all, asterisk configuration information is a kind of data that > is not often modified but it gets a lot of queries and this is the kind > of workload where a LDAP server performs the best. Also it is much > easier to replicate an LDAP server than, say, Postgres or MySQL. > > But then, why not use OpenLDAP or 389 Directory Server directly, using a > frontend like phpLdapAdmin for data entry? Well just the thought of it > brings back sad memories of hard to configure replication, missing > indexes, editing spaghetti php code for extending templates. > > The advantages we see with IPA are: > > - Easy installation, easy replication management > - Installs a great LDAP server, 389, reasonably well tuned for general > use > - A nice, easy to use python framework for managing schema, ACIs and > data entry > > While I understand that resources are limited and the IPA team focus is > on the IDM aspects of the platform, I see that this platform has the > potential to become a configuration store for many applications, like > bind, isc dhcp, postfix, asterisk, freeswitch, etc. > > So far, considering all the opinions, I think the best approach is for > the plugin to keep all asterisk data under a single container > (cn=asterisk) so it can be developed and distributed separately from the > core of IPA, and just aim for EPEL inclusion. The user serviceable parts > of the asterisk configuration (just a few voice mail settings) could be > managed by extending the selfservice plugin. > > Thank you Fair enough. Time will show how it should evolve. I finally found time to groom and publish the questions to consider while implementing a plugin: http://www.freeipa.org/page/General_considerations HTH. Any comments and suggestions welcome. Good luck! -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pvoborni at redhat.com Thu Nov 29 08:42:15 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 Nov 2012 09:42:15 +0100 Subject: [Freeipa-devel] [PATCH] 227 Editable sshkey field after upgrade In-Reply-To: <50B4E0C7.7080202@redhat.com> References: <50AA284C.3060001@redhat.com> <50AB51E8.9040607@redhat.com> <50ABB3E0.4050602@redhat.com> <50B4E0C7.7080202@redhat.com> Message-ID: <50B71FE7.4000401@redhat.com> On 11/27/2012 04:48 PM, Endi Sukma Dewata wrote: > On 11/20/2012 10:46 AM, Petr Vobornik wrote: >>> I think that ipaexternalmember, gidnumber and macaddress attributes >>> might cause trouble as well. They are all in objectclasses that are >>> added to objects on-demand (like ipasshuser/ipasshhost is). >>> >>> Honza >>> >> >> Thanks for the catch. There is a problem with macaddress. >> Ipaexternalmember and gid number aren't affected because group is >> converted by actions, not by editing a field. >> >> I additionally conditioned the write exception on having write rights >> for objectclass. Update will fail without it. >> >> Updated patch attached. > > ACK. > Pushed to master, ipa-3-0. -- Petr Vobornik From pvoborni at redhat.com Thu Nov 29 08:42:43 2012 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 29 Nov 2012 09:42:43 +0100 Subject: [Freeipa-devel] [PATCH] 238 WebUI: Change of default value of type of new group back to POSIX In-Reply-To: <50B4E16F.8040707@redhat.com> References: <50ABBA58.9070809@redhat.com> <1353436511.25995.7.camel@willson.li.ssimo.org> <50AC9A3F.90302@redhat.com> <50B4E16F.8040707@redhat.com> Message-ID: <50B72003.9050105@redhat.com> On 11/27/2012 04:51 PM, Endi Sukma Dewata wrote: > On 11/21/2012 3:09 AM, Petr Vobornik wrote: >> On 11/20/2012 07:35 PM, Simo Sorce wrote: >>> On Tue, 2012-11-20 at 18:14 +0100, Petr Vobornik wrote: >>>> In FreeIPA 2.2, the default for group type was 'POSIX', in 3.0 it's >>>> 'normal' (non-posix). CLI's default is 'POSIX', Web UI should use >>>> 'POSIX' as well. >>>> >>>> https://fedorahosted.org/freeipa/ticket/3270 >>> >>> I see you just opened this, but IIRC the change was somewhat intentional >>> because you can go non-posix -> posix but you can't do the reverse. >>> >>> Simo. >>> >> It wasn't strictly intentional, but it was a contributing factor. >> >> Anyway the default, both in CLI and Web UI, should be the most used >> group type. AFAIK it's posix. > > ACK. > Pushed to master, ipa-3-0. -- Petr Vobornik From rcritten at redhat.com Fri Nov 30 16:13:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Nov 2012 11:13:43 -0500 Subject: [Freeipa-devel] [PATCH] 331 Update SELinux policy for dogtag10 In-Reply-To: <5099144B.8040104@redhat.com> References: <5098D79B.2080301@redhat.com> <5099144B.8040104@redhat.com> Message-ID: <50B8DB37.2060703@redhat.com> Martin Kosek wrote: > On 11/06/2012 10:25 AM, Martin Kosek wrote: >> Incorporate SELinux policy changes introduced in Dogtag 10 in IPA >> SELinux policy: >> - dogtag10 now runs with pki_tomcat_t context instead of pki_ca_t >> - certmonger related rule are now integrated in system policy and >> can be removed from IPA policy >> >> Also remove redundant SELinux rules for connection of httpd_t, krb5kdc_t >> or named_t to DS socket. The socket has different target type anyway >> (dirsrv_var_run_t) and the policy allowing this is already in >> system. >> >> https://fedorahosted.org/freeipa/ticket/3234 >> >> --- >> >> I tested an installation of IPA on F18 with SELinux enforcing mode and so far >> so good. Unit tests passed, CRL generation still works, certmonger was still >> able resubmit a cert. >> >> To verify that SELinux rules allowing access of httpd/krb5kdc/named to dirsrv >> socket, you ran run this SELinux search: >> >> sesearch -A -s httpd_t -t dirsrv_var_run_t -c sock_file -p write >> >> >> I saw few (benign?) AVCs not caused by this patch, I filed Bugzillas for those: >> >> krb5: https://bugzilla.redhat.com/show_bug.cgi?id=873564 >> pki-ca: https://bugzilla.redhat.com/show_bug.cgi?id=873585 >> >> Martin >> > > Important note: if/when this patch is accepted, it should be pushed to master > branch only, i.e. to 3.1 release. This should never get to Fedora < 18 (and > dogtag < 10) where using context pki_ca_t does not fly. ACK, pushed to master rob From rcritten at redhat.com Fri Nov 30 21:31:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Nov 2012 16:31:29 -0500 Subject: [Freeipa-devel] [PATCH] Special case NFS related ticket to avoid attaching MS-PACs In-Reply-To: <20121128202925.GB25275@localhost.localdomain> References: <1354124667.12309.18.camel@willson.li.ssimo.org> <20121128202925.GB25275@localhost.localdomain> Message-ID: <50B925B1.6060607@redhat.com> Sumit Bose wrote: > On Wed, Nov 28, 2012 at 12:44:27PM -0500, Simo Sorce wrote: >> Fixes: https://fedorahosted.org/freeipa/ticket/3263 >> >> Details in the commit. > > ACK pushed to master and ipa-3-0 From rcritten at redhat.com Fri Nov 30 21:35:37 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Nov 2012 16:35:37 -0500 Subject: [Freeipa-devel] [PATCH 0005] Clarified error message with ipa-client-automount In-Reply-To: <1129149924.5633962.1353923519895.JavaMail.root@redhat.com> References: <1129149924.5633962.1353923519895.JavaMail.root@redhat.com> Message-ID: <50B926A9.5030107@redhat.com> Lynn Root wrote: > Returns a clearer hint when user is running ipa-client-automount with > possible firewall up and blocking need ports. > > Not sure if this patch is worded correctly in order to address the > potential firewall block when running ipa-client-automount. Perhaps a > different error should be thrown, rather than NOT_IPA_SERVER. > > Ticket: https://fedorahosted.org/freeipa/ticket/3080 Tomas made a similar change recently in ipa-client-install which includes more information on the ports we need. You may want to take a look at that. It was for ticket https://fedorahosted.org/freeipa/ticket/2816 rob From rcritten at redhat.com Fri Nov 30 21:40:07 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 30 Nov 2012 16:40:07 -0500 Subject: [Freeipa-devel] [PATCH] Lookup the user SID in external group as well In-Reply-To: <1352914839.10327.667.camel@willson.li.ssimo.org> References: <20121114172616.GS24620@localhost.localdomain> <1352914839.10327.667.camel@willson.li.ssimo.org> Message-ID: <50B927B7.6080103@redhat.com> Simo Sorce wrote: > On Wed, 2012-11-14 at 18:26 +0100, Sumit Bose wrote: >> Hi, >> >> Jakub found that currently only group SIDs are used to find group >> memberships of users from trusted domain. The attached patch adds the >> user SID as well. >> >> Fixes https://fedorahosted.org/freeipa/ticket/3257 . >> > ack > > Simo. > Pushed to master and ipa-3-0 rob