From mkosek at redhat.com Thu Dec 1 07:35:46 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 01 Dec 2011 08:35:46 +0100 Subject: [Freeipa-devel] [PATCH 55/55] Restore default log level in server to INFO In-Reply-To: <4ED6652A.5060109@redhat.com> References: <201111301631.pAUGVx1H025114@int-mx01.intmail.prod.int.phx2.redhat.com> <4ED6652A.5060109@redhat.com> Message-ID: <1322724946.20143.0.camel@balmora.brq.redhat.com> On Wed, 2011-11-30 at 12:17 -0500, John Dennis wrote: > Found & fixed minor issue with doc on default_level property, please use > this version of the patch instead. > ACK. Pushed to master. Martin From mkosek at redhat.com Thu Dec 1 08:30:54 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 01 Dec 2011 09:30:54 +0100 Subject: [Freeipa-devel] [PATCH] 174 Fix config migration option Message-ID: <1322728254.20143.1.camel@balmora.brq.redhat.com> Make sure that --enable-migration in config plugin works correctly and user can use to both enable and disable migration. https://fedorahosted.org/freeipa/ticket/2150 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-174-fix-config-migration-option.patch Type: text/x-patch Size: 1249 bytes Desc: not available URL: From pvoborni at redhat.com Thu Dec 1 09:58:55 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 01 Dec 2011 10:58:55 +0100 Subject: [Freeipa-devel] [PATCH] 048 Added cross browser support of Array.indexOf method Message-ID: <4ED74FDF.3040502@redhat.com> https://fedorahosted.org/freeipa/ticket/2151 Note: I didn't add browser.js to jsl.conf because there is a jsl error - shortcut for checking NaN and I'm not sure if modifying it into standard isNaN call would be OK. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0048-Added-cross-browser-support-of-Array.indexOf-method.patch Type: text/x-patch Size: 3816 bytes Desc: not available URL: From mkosek at redhat.com Thu Dec 1 10:05:35 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 01 Dec 2011 11:05:35 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <1322498136.12794.22.camel@balmora.brq.redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> Message-ID: <1322733935.20143.5.camel@balmora.brq.redhat.com> On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: > I have prepared a working prototype of the new structured DNS API. It > may still have rough edges (and unit tests are not ready), but it will > provide a base for discussion and for WebUI folks - so that they can > start development of the new DNS WebUI API. > > The patch takes advantage of the DNS refactor I did in 172. For all > supported non-DNSSEC RR types, the following commands are available: > > dnsrecord-show ZONE NAME > dnsrecord-add ZONE NAME > dnsrecord-mod ZONE NAME VALUE > > This is an example of the new API in action: > > # ipa dnsrecord-show example.com foo > Record name: foo > A record: 10.0.0.1 > > # ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com." > MX record: 0 foo.example.com. > Preference: 0 > Exchanger: foo.example.com. > ---------------------------- > Number of entries returned 1 > ---------------------------- > > # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger="foo.example.com." > MX record: 0 foo.example.com. > Preference: 0 > Exchanger: foo.example.com. > > MX record: 1 foo.example.com. > Preference: 1 > Exchanger: foo.example.com. > ---------------------------- > Number of entries returned 2 > ---------------------------- > > # ipa dnsrecordmx-show example.com foo > MX record: 0 foo.example.com. > Preference: 0 > Exchanger: foo.example.com. > > MX record: 1 foo.example.com. > Preference: 1 > Exchanger: foo.example.com. > ---------------------------- > Number of entries returned 2 > ---------------------------- > > > There is an interactive wizard to help user modify a record without > specifying an updated value first. If there is just one (MX) record, no > wizard would be run. > > # ipa dnsrecordmx-mod example.com foo --preference=2 > Which MX record would you like to modify? > > [1]: 0 foo.example.com. > [2]: 1 foo.example.com. > > DNS record number: 2 > MX record: 0 foo.example.com. > Preference: 0 > Exchanger: foo.example.com. > > MX record: 2 foo.example.com. > Preference: 2 > Exchanger: foo.example.com. > ---------------------------- > Number of entries returned 2 > ---------------------------- > > # ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3 > MX record: 0 foo.example.com. > Preference: 0 > Exchanger: foo.example.com. > > MX record: 3 foo.example.com. > Preference: 3 > Exchanger: foo.example.com. > ---------------------------- > Number of entries returned 2 > ---------------------------- > > > There are few open questions I am still thinking about: > > 1) The commands return a list of structured records (just like *-find > commands) instead of returning just one record. I thought that it may be > more usable this way and consistent with dnsrecord-add/mod/show commands > behavior which returns all records too. Otherwise, we would have to > change the show command API and add VALUE argument, which would specify > a value to be displayed: > dnsrecord-show ZONE NAME VALUE > > 2) Raw DNS record value is in the output too. I though it would be > useful to see the raw DNS record value + its parts at one place. > > 3) The commands are in format dnsrecord-cmd, for example > dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we > want to go this way, I would have to bend the server framework a little > which parses an LDAP object from the command name (LDAP object name is > dnsrecordmx in this case). This is doable, although I am not sure if > this does not have some implications in WebUI side. > > Martin I rebased both patches to the most recent master. Adding CSVs now works ok again (with the fix in 175): # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 Record name: foo A record: 10.0.0.1, 10.0.0.2 Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-172-3-rework-dnsrecord-processing.patch Type: text/x-patch Size: 96210 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-173-2-create-per-type-dns-api.patch Type: text/x-patch Size: 61661 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-175-fix-parameter-csv-parsing.patch Type: text/x-patch Size: 1319 bytes Desc: not available URL: From ohamada at redhat.com Thu Dec 1 13:58:32 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Thu, 01 Dec 2011 14:58:32 +0100 Subject: [Freeipa-devel] [PATCH] ipa-client-install with --no-sssd option should check for nss_ldap In-Reply-To: <4ED54F98.4070700@redhat.com> References: <4EBD294A.20200@redhat.com> <4EC13FD2.9000203@redhat.com> <4ED54F98.4070700@redhat.com> Message-ID: <4ED78808.1000801@redhat.com> On 11/29/2011 10:33 PM, Rob Crittenden wrote: > Ondrej Hamada wrote: >> On 11/11/2011 02:55 PM, Ondrej Hamada wrote: >>> https://fedorahosted.org/freeipa/ticket/2063 >>> >>> In order to check presence of nss_ldap when installing client with >>> '--no-sssd' option there was added code into ipa-client-install. Check >>> is base on existence of nss_ldap configuration files. This >>> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>> '/etc/libnss_ldap.conf'. Presence of any of these files is considered >>> as success otherwise failure. >>> >>> >>> >>> _______________________________________________ >>> Freeipa-devel mailing list >>> Freeipa-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-devel >> I've rewritten it. Additionally it checks for existence of nss-pam-ldapd >> and makes the results reusable by configure_{ldap|nslcd}_conf() >> functions. >> >> https://fedorahosted.org/freeipa/ticket/2063 >> >> In order to check presence of nss_ldap or nss-pam-ldapd when installing >> client >> with '--no-sssd' option there was added code into ipa-client-install. >> Checking is based on existence of nss_ldap configuration files. This >> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >> '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could cooperate with >> pam_ldap >> module and hence the presence of it is checked by looking for >> 'pam_ldap.conf' file. >> Existence of nss-pam-ldapd is checked against existence of 'nslcd.conf' >> file. >> All this checking is done by function nssldap_exists(). >> Because both main modules are maintained by two different functions, the >> function >> returns tuple containing return code and dictionary structure - its key >> is name >> of target function and value is list of existing configuration files. >> Files to check are specified inside the nssldap_exists() function. >> >> In order to fit the returned values, the functions >> configure_{ldap|nslcd}_conf() >> were slightly modified. They accept one more parameter which is list of >> existing files. >> They are not checking existence of above mentioned files anymore. > > The patch looks good, just a couple of issues. > > 1. In the nslcd configurator you add ''.join(files). Did you mean > ','.join(files)? > > 2. The commit message lines wrap making it difficult to read. Can you > limit the lines to ~70 chars per line? > > 3. I think the message printed when neither package is available can > be simplified to: > > One of these packages must be installed: nss_ldap or nss-pam-ldapd > > It needs a rebase too. > > rob corrected, corrected, changed, rebased In order to check presence of nss_ldap or nss-pam-ldapd when installing client with '--no-sssd' option there was added code intoipa-client-install. Checking is based on existence of one of nss_ldap configuration files. This configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could cooperate with pam_ldap module and hence the presence of it is checked by looking for 'pam_ldap.conf' file. Existence of nss-pam-ldapd is checked against existence of 'nslcd.conf' file. All this checking is done by function nssldap_exists(). Because both modules are maintained by two different functions, the function returns tuple containing return code and dictionary structure - its key is name of target function and value is list of existing configuration files. Files to check are specified inside the nssldap_exists() function. In order to fit the returned values, the functions configure_{ldap|nslcd}_conf() were slightly modified. They accept one more parameter which is list of existing files. They are not checking existence of above mentioned files anymore. https://fedorahosted.org/freeipa/ticket/2063 -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-3-3-Client-install-checks-for-nss_ldap.patch Type: text/x-patch Size: 6303 bytes Desc: not available URL: From jkuncar at redhat.com Thu Dec 1 14:00:18 2011 From: jkuncar at redhat.com (Jiri Kuncar) Date: Thu, 01 Dec 2011 09:00:18 -0500 (EST) Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: enable/disable PTR synchronization per zone In-Reply-To: Message-ID: <06e44f93-1796-4409-8b8b-f9ffff7c6621@zmail13.collab.prod.int.phx2.redhat.com> I've added an attribute "idnsAllowSyncPTR" to "idnsZone" to enable or disable synchronization of PTR records. However the bind-dyndb-ldap plugin option "sync_ptr" has to be included in /etc/named.conf to run synchronization feature. My quick fix of LDAP schema in /usr/share/ipa/60basev2.ldif: ----- attributeTypes: (2.16.840.1.113730.3.8.5.11 NAME 'idnsAllowSyncPTR' DESC 'permit synchronization of PTR records' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v2' ) ... objectClasses: (2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowSyncPTR ) ) ----- https://fedorahosted.org/bind-dyndb-ldap/ticket/39 Jiri -------------- next part -------------- A non-text attachment was scrubbed... Name: jkuncar-ticket39-Enable-disable-PTR-synchronization-per-zone.patch Type: text/x-patch Size: 1842 bytes Desc: not available URL: From simo at redhat.com Thu Dec 1 14:27:08 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 09:27:08 -0500 Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: enable/disable PTR synchronization per zone In-Reply-To: <06e44f93-1796-4409-8b8b-f9ffff7c6621@zmail13.collab.prod.int.phx2.redhat.com> References: <06e44f93-1796-4409-8b8b-f9ffff7c6621@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <1322749628.22044.38.camel@willson.li.ssimo.org> On Thu, 2011-12-01 at 09:00 -0500, Jiri Kuncar wrote: > I've added an attribute "idnsAllowSyncPTR" to "idnsZone" to enable or > disable synchronization of PTR records. However the bind-dyndb-ldap > plugin option "sync_ptr" has to be included in /etc/named.conf to run > synchronization feature. We need an update script to run on ipa server at upgrade time then. > My quick fix of LDAP schema in /usr/share/ipa/60basev2.ldif: The DNS schema objects are in 60ipadns.ldif > ----- > attributeTypes: (2.16.840.1.113730.3.8.5.11 NAME 'idnsAllowSyncPTR' > DESC 'permit synchronization of PTR records' EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v2' ) NACK. 5.11 is reserved by idnsAllowQuery and 5.12 by idnsAllowTransfer. The first available OID is 5.13 > objectClasses: (2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone > class' SUP idnsRecord STRUCTURAL MUST ( idnsName $ idnsZoneActive $ > idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ > idnsSOAretry $ idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy > $ idnsAllowSyncPTR ) ) These changes need to be committed to the right file and a .update is also needed. > https://fedorahosted.org/bind-dyndb-ldap/ticket/39 > Need some more work but looks promising. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Thu Dec 1 14:39:46 2011 From: jdennis at redhat.com (John Dennis) Date: Thu, 01 Dec 2011 09:39:46 -0500 Subject: [Freeipa-devel] Logging changes in master Message-ID: <4ED791B2.1000705@redhat.com> A few days ago changes were checked into the master branch to improve the way logging works. The modules ipapython.ipa_log_manager and ipapython.log_manager were added and contain extensive documentation (links to their HTML version appear below). But you don't need to read through it all, you just need to know a few basic facts for all code going forward, items 1-3 are mandatory to know, the rest are helpful. 1) Never import the Python logging module, instead: from ipapython.log_manager import * 2) Use of the global root logger has been replaced, instead of logging.debug() use root_logger.debug(), etc. 3) Stand-alone programs should set up logging via this common utility, standard_logging_setup() 4) You can now control which classes (e.g. loggers) emit debug messages, it's no longer an all or nothing proposition, you can turn on debugging for just the code you're working on (or other level messages). Just edit one of the config files read by Env() and add a line like this: log_logger_debug = comma separated list of regular expressions where each regular expression matches a class (logger) name(s) See IPALogManger.configure_from_env for details 5) The Env() config files now support the verbose flag to turn on info level messages. 6) Avoid use of the global root logger if possible, instead use a logger belonging to the logical code location. If you have a class it's as simple as: log_mgr.get_logger(self, True) Now you're class will have .debug(), .info() etc. methods bound to it and when you log your class name (or other name) will be visible (this happens automatically for all plugins). If you don't have a class to hang your logger on use a meaningful name and create one, e.g.: logger = log_mgr.get_logger('client_installer') -or- logger = log_mgr.get_logger(os.path.basename(sys.argv[0])) HTML versions of the documentation can be found here: http://jdennis.fedorapeople.org/log_manager_doc/ -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jdennis at redhat.com Thu Dec 1 14:49:01 2011 From: jdennis at redhat.com (John Dennis) Date: Thu, 01 Dec 2011 09:49:01 -0500 Subject: [Freeipa-devel] Logging changes in master In-Reply-To: <4ED791B2.1000705@redhat.com> References: <4ED791B2.1000705@redhat.com> Message-ID: <4ED793DD.3020206@redhat.com> On 12/01/2011 09:39 AM, John Dennis wrote: > 1) Never import the Python logging module, instead: > > from ipapython.log_manager import * Opps, mea culpa, that should be ipa_log_manager, not log_manager from ipapython.ipa_log_manager import * -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From pvoborni at redhat.com Thu Dec 1 15:02:59 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 01 Dec 2011 16:02:59 +0100 Subject: [Freeipa-devel] [PATCH] 32-47 #2040, #1515 Refactor UI widgets In-Reply-To: <4ED65BE2.8050307@redhat.com> References: <4ED4E2B7.2020403@redhat.com> <4ED5C96E.4000707@redhat.com> <4ED65BE2.8050307@redhat.com> Message-ID: <4ED79723.2040809@redhat.com> Attaching patch for unit tests. Couple of widget tests still fail. They raise couple questions: 1) Should widget expect that array of values like ['value'] will be always passed to update(values) method or the update method should also work with simple values like 'value'? 2) Should widget load its own metadata - based on entity and its name or it is responsibility of field (current implementation)? 3) Should custom dirty checks, or other boolean checks (validate) always return pure boolean value, or is integer also acceptable. Usage of &= or |= operators is producing integer values because it actually means 'foo = foo & bar' not 'foo = foo && bar' Also all jsl warnings are fixed and jsl.conf for tests is added. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0049-Fixed-unit-tests-after-widget-refactoring.patch Type: text/x-patch Size: 49723 bytes Desc: not available URL: From ayoung at redhat.com Thu Dec 1 16:45:35 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 01 Dec 2011 11:45:35 -0500 Subject: [Freeipa-devel] [PATCH] 32-47 #2040, #1515 Refactor UI widgets In-Reply-To: <4ED79723.2040809@redhat.com> References: <4ED4E2B7.2020403@redhat.com> <4ED5C96E.4000707@redhat.com> <4ED65BE2.8050307@redhat.com> <4ED79723.2040809@redhat.com> Message-ID: <4ED7AF2F.1080303@redhat.com> On 12/01/2011 10:02 AM, Petr Vobornik wrote: > Attaching patch for unit tests. > > Couple of widget tests still fail. > > They raise couple questions: > > 1) Should widget expect that array of values like ['value'] will be > always passed to update(values) method or the update method should > also work with simple values like 'value'? The widget tests are higly subjective. Do not be afraid to change them, especially if the assumptions they are written against have changed. They were written more as a way to exercise the widgets than a codification of behavior. > > 2) Should widget load its own metadata - based on entity and its name > or it is responsibility of field (current implementation)? Personally, I'd prefer if the Metadata was passed to the constructor, as that allows us to compose it in multiple ways. That will be useful in the future. INfact, I would prefer it if, instead of the Metatdata as a chunk, we passed the indivual pieces that are required (pattern specifically) so that how to build the object can differ, but I wanted to hold off on doing anything like this until we had at least one more specific project to integrate with. GO with the most striaght forward solution for now. > > 3) Should custom dirty checks, or other boolean checks (validate) > always return pure boolean value, or is integer also acceptable. Usage > of &= or |= operators is producing integer values because it actually > means 'foo = foo & bar' not 'foo = foo && bar' Is there really a difference in Javascript? I so long as they evaluate to true/false, it is probably fine, but is there the possibility for confusion? > > Also all jsl warnings are fixed and jsl.conf for tests is added. > > > > _______________________________________________ > 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: From nkinder at redhat.com Thu Dec 1 18:50:47 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 01 Dec 2011 10:50:47 -0800 Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: enable/disable PTR synchronization per zone In-Reply-To: <1322749628.22044.38.camel@willson.li.ssimo.org> References: <06e44f93-1796-4409-8b8b-f9ffff7c6621@zmail13.collab.prod.int.phx2.redhat.com> <1322749628.22044.38.camel@willson.li.ssimo.org> Message-ID: <4ED7CC87.1030207@redhat.com> On 12/01/2011 06:27 AM, Simo Sorce wrote: > On Thu, 2011-12-01 at 09:00 -0500, Jiri Kuncar wrote: >> I've added an attribute "idnsAllowSyncPTR" to "idnsZone" to enable or >> disable synchronization of PTR records. However the bind-dyndb-ldap >> plugin option "sync_ptr" has to be included in /etc/named.conf to run >> synchronization feature. > We need an update script to run on ipa server at upgrade time then. > >> My quick fix of LDAP schema in /usr/share/ipa/60basev2.ldif: > The DNS schema objects are in 60ipadns.ldif > >> ----- >> attributeTypes: (2.16.840.1.113730.3.8.5.11 NAME 'idnsAllowSyncPTR' >> DESC 'permit synchronization of PTR records' EQUALITY booleanMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v2' ) > NACK. > 5.11 is reserved by idnsAllowQuery and 5.12 by idnsAllowTransfer. The > first available OID is 5.13 Do you have a page for tracking OID allocation within the FreeIPA namespace? If so, we should be sure to consult it to choose the next available OID and to update it once we have the final patch for this issue. > >> objectClasses: (2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone >> class' SUP idnsRecord STRUCTURAL MUST ( idnsName $ idnsZoneActive $ >> idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ >> idnsSOAretry $ idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy >> $ idnsAllowSyncPTR ) ) > These changes need to be committed to the right file and a .update is > also needed. > >> https://fedorahosted.org/bind-dyndb-ldap/ticket/39 >> > Need some more work but looks promising. > Simo. > From rcritten at redhat.com Thu Dec 1 21:50:19 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Dec 2011 16:50:19 -0500 Subject: [Freeipa-devel] [PATCH] 174 Fix config migration option In-Reply-To: <1322728254.20143.1.camel@balmora.brq.redhat.com> References: <1322728254.20143.1.camel@balmora.brq.redhat.com> Message-ID: <4ED7F69B.7040501@redhat.com> Martin Kosek wrote: > Make sure that --enable-migration in config plugin works correctly > and user can use to both enable and disable migration. > > https://fedorahosted.org/freeipa/ticket/2150 > ack pushed to master From rcritten at redhat.com Thu Dec 1 22:18:35 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 01 Dec 2011 17:18:35 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <1322733935.20143.5.camel@balmora.brq.redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> Message-ID: <4ED7FD3B.3030006@redhat.com> Martin Kosek wrote: > On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: >> I have prepared a working prototype of the new structured DNS API. It >> may still have rough edges (and unit tests are not ready), but it will >> provide a base for discussion and for WebUI folks - so that they can >> start development of the new DNS WebUI API. >> >> The patch takes advantage of the DNS refactor I did in 172. For all >> supported non-DNSSEC RR types, the following commands are available: >> >> dnsrecord-show ZONE NAME >> dnsrecord-add ZONE NAME >> dnsrecord-mod ZONE NAME VALUE >> >> This is an example of the new API in action: >> >> # ipa dnsrecord-show example.com foo >> Record name: foo >> A record: 10.0.0.1 >> >> # ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com." >> MX record: 0 foo.example.com. >> Preference: 0 >> Exchanger: foo.example.com. >> ---------------------------- >> Number of entries returned 1 >> ---------------------------- >> >> # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger="foo.example.com." >> MX record: 0 foo.example.com. >> Preference: 0 >> Exchanger: foo.example.com. >> >> MX record: 1 foo.example.com. >> Preference: 1 >> Exchanger: foo.example.com. >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> # ipa dnsrecordmx-show example.com foo >> MX record: 0 foo.example.com. >> Preference: 0 >> Exchanger: foo.example.com. >> >> MX record: 1 foo.example.com. >> Preference: 1 >> Exchanger: foo.example.com. >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> >> There is an interactive wizard to help user modify a record without >> specifying an updated value first. If there is just one (MX) record, no >> wizard would be run. >> >> # ipa dnsrecordmx-mod example.com foo --preference=2 >> Which MX record would you like to modify? >> >> [1]: 0 foo.example.com. >> [2]: 1 foo.example.com. >> >> DNS record number: 2 >> MX record: 0 foo.example.com. >> Preference: 0 >> Exchanger: foo.example.com. >> >> MX record: 2 foo.example.com. >> Preference: 2 >> Exchanger: foo.example.com. >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> # ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3 >> MX record: 0 foo.example.com. >> Preference: 0 >> Exchanger: foo.example.com. >> >> MX record: 3 foo.example.com. >> Preference: 3 >> Exchanger: foo.example.com. >> ---------------------------- >> Number of entries returned 2 >> ---------------------------- >> >> >> There are few open questions I am still thinking about: >> >> 1) The commands return a list of structured records (just like *-find >> commands) instead of returning just one record. I thought that it may be >> more usable this way and consistent with dnsrecord-add/mod/show commands >> behavior which returns all records too. Otherwise, we would have to >> change the show command API and add VALUE argument, which would specify >> a value to be displayed: >> dnsrecord-show ZONE NAME VALUE >> >> 2) Raw DNS record value is in the output too. I though it would be >> useful to see the raw DNS record value + its parts at one place. >> >> 3) The commands are in format dnsrecord-cmd, for example >> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we >> want to go this way, I would have to bend the server framework a little >> which parses an LDAP object from the command name (LDAP object name is >> dnsrecordmx in this case). This is doable, although I am not sure if >> this does not have some implications in WebUI side. >> >> Martin > > I rebased both patches to the most recent master. Adding CSVs now works > ok again (with the fix in 175): > > # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 > Record name: foo > A record: 10.0.0.1, 10.0.0.2 > > Martin I think some abbreviations can be eliminated: siz -> size alt -> altitude For MX record (and probably KX) you can make preference required. It should fill in without prompting since it has a default. This way it will show as required in the UI. PTRRecord doc I think would read better as "The hostname this reverse record points to" I'm not sure I follow the makeapi change. I see the new entry types in API.txt but this makeapi seems to suggest the DNS api is not checked. Otherwise generally looks good. rob From dpal at redhat.com Thu Dec 1 23:54:55 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 01 Dec 2011 18:54:55 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4ED6AF32.6000607@redhat.com> References: <4ED6AF32.6000607@redhat.com> Message-ID: <4ED813CF.8040403@redhat.com> On 11/30/2011 05:33 PM, John Dennis wrote: > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Seems reasonable. I agree with pros and cons and suggestions but I am not the person to make the final approval. Simo? Question for John: Is there any benefit for CLI or it is for UI only? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Fri Dec 2 00:31:24 2011 From: jdennis at redhat.com (John Dennis) Date: Thu, 01 Dec 2011 19:31:24 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4ED813CF.8040403@redhat.com> References: <4ED6AF32.6000607@redhat.com> <4ED813CF.8040403@redhat.com> Message-ID: <4ED81C5C.9010307@redhat.com> On 12/01/2011 06:54 PM, Dmitri Pal wrote: > Seems reasonable. I agree with pros and cons and suggestions but I am > not the person to make the final approval. Simo? > > Question for John: Is there any benefit for CLI or it is for UI only? Currently it would benefit the UI only. That's mostly because there is no mechanism in the cli to cache the session ID. Adding that wouldn't be too difficult except for the issue of how to store the session ID securely, it would have to be written to a file (unlike with a browser which is supposed to hold session cookies in memory). Is there an ability to add a data item like this to the user's kerberos credential cache? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Fri Dec 2 01:28:07 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 20:28:07 -0500 Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: enable/disable PTR synchronization per zone In-Reply-To: <4ED7CC87.1030207@redhat.com> References: <06e44f93-1796-4409-8b8b-f9ffff7c6621@zmail13.collab.prod.int.phx2.redhat.com> <1322749628.22044.38.camel@willson.li.ssimo.org> <4ED7CC87.1030207@redhat.com> Message-ID: <1322789287.22044.52.camel@willson.li.ssimo.org> On Thu, 2011-12-01 at 10:50 -0800, Nathan Kinder wrote: > On 12/01/2011 06:27 AM, Simo Sorce wrote: > > On Thu, 2011-12-01 at 09:00 -0500, Jiri Kuncar wrote: > >> I've added an attribute "idnsAllowSyncPTR" to "idnsZone" to enable or > >> disable synchronization of PTR records. However the bind-dyndb-ldap > >> plugin option "sync_ptr" has to be included in /etc/named.conf to run > >> synchronization feature. > > We need an update script to run on ipa server at upgrade time then. > > > >> My quick fix of LDAP schema in /usr/share/ipa/60basev2.ldif: > > The DNS schema objects are in 60ipadns.ldif > > > >> ----- > >> attributeTypes: (2.16.840.1.113730.3.8.5.11 NAME 'idnsAllowSyncPTR' > >> DESC 'permit synchronization of PTR records' EQUALITY booleanMatch > >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v2' ) > > NACK. > > 5.11 is reserved by idnsAllowQuery and 5.12 by idnsAllowTransfer. The > > first available OID is 5.13 > Do you have a page for tracking OID allocation within the FreeIPA > namespace? If so, we should be sure to consult it to choose the next > available OID and to update it once we have the final patch for this issue. We have one place within Red Hat where we also keep track of all 389ds OIDs that's how I know there is a conflict here. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 2 01:48:54 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 20:48:54 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4ED81C5C.9010307@redhat.com> References: <4ED6AF32.6000607@redhat.com> <4ED813CF.8040403@redhat.com> <4ED81C5C.9010307@redhat.com> Message-ID: <1322790534.22044.54.camel@willson.li.ssimo.org> On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: > On 12/01/2011 06:54 PM, Dmitri Pal wrote: > > Seems reasonable. I agree with pros and cons and suggestions but I am > > not the person to make the final approval. Simo? > > > > Question for John: Is there any benefit for CLI or it is for UI only? > > Currently it would benefit the UI only. That's mostly because there is > no mechanism in the cli to cache the session ID. Adding that wouldn't be > too difficult except for the issue of how to store the session ID > securely, it would have to be written to a file (unlike with a browser > which is supposed to hold session cookies in memory). Is there an > ability to add a data item like this to the user's kerberos credential > cache? Yes we could create a fake key and stick the session id in it. That was the trick we proposed using when this question was raised a few months ago during a conference call on the matter. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 2 02:55:37 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 21:55:37 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4ED6AF32.6000607@redhat.com> References: <4ED6AF32.6000607@redhat.com> Message-ID: <1322794537.22044.63.camel@willson.li.ssimo.org> On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: > Comments? Suggestions? > Sorry for the late reply. First of all, excellent write-up John, it is very comprehensive and lays down things very clearly. I agree that using ipa:ipa for memcached and wsgi would be a better proposition for us. Although we need to explore how this would affect credential caches created by mod_auth_kerb and our ability to use them, which is crucial*. You say that object sized for the stuff we will store in memcached should be limited. What is a reasonable size for those objects ? I was thinking we may want to store the krb ccaches in memcached in order to be able to keep them around. The reason I ask is that Krb ccaches can become quite big if PACs are attached to tickets although they are normally quite small. Aside for these minor details I totally agree with the direction you are proposing and I can't wait to see it implemented :) Simo. *In the long term we may even decide to stop using mod_auth_kerb and do our own handling if this simplifies things, but I guess we will need an interim transition period in any case, because we can't depend on too many changes to be done at once as a dependency to introduce sessions. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 2 03:04:36 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 22:04:36 -0500 Subject: [Freeipa-devel] Tomcat Realms and Directory Server In-Reply-To: <4EB970AB.9080807@redhat.com> References: <4EB970AB.9080807@redhat.com> Message-ID: <1322795076.22044.68.camel@willson.li.ssimo.org> Hi Adam, I haven't replied to this summary so far for 2 reasons. I had little time to ponder it (and Java is not my forte) and it is still a bit up in the air. I am a bit concerned about the relatively unstable/young support for some of the tech that would have to be involved, but on the other hand I tend to like the approach of better in depth security, auth forwarding, and isolation of instances and credentials used. I think you should keep exploring this area and see what works and what not. I wonder if the session work we are doing for the main IPA framework can be used in some way to simplify part of the work you are doing. Unfortunately working in Java may be an obstacle in this sense as we plan to use python native marchalling/unmarshalling of objects in the session cache, but keep in mind this may be an avenue to offload most of the auth/session management work to the IPA framework and simplify your credential management at least when dogtag is integrated with IPA. Simo. On Tue, 2011-11-08 at 13:10 -0500, Adam Young wrote: > One issue I have been looking at recently is how to integrate PKI and > IPA at the auth level while keeping a clean separation. > > We can extract the authentication from the servlet code, so it is > purely a matter of configuring the Tomcat instance Realm. > > I wrote up a Proof of concept for just doing pure LDAP using simple > bind, which is not a bad starting point. > > http://adam.younglogic.com/2011/11/tomcat-simple-ipa/ > > > We want to continue this approach, but use a more secure authentication > method. We won't be using basic auth, and we won't be using simple bind. > > There are two forms of authentication we want to support: Client > Certificates and Kerberos. Certificates will work as they do now, and > Kerberos will be for passing through user credentials from IPA, through > HTTP to CS. In both cases, the data that backs it will be stored in > the DS instance. > > Tomcat has a class classed a CombinedRealm: > http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm > > That might support stacking Certificate and Kerberos auth on top of > each other. The Realm will then delegate to LDAP for extracting the Roles. > > http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm > > Kerberos is typically done using a JAAS Realm. I have to admit I don't > really like the fact that we have to modify the JVM startup to do so, it > is not really that big of a deal. I was also not a fan of setting the > Realm up as a single service ticket until Simo informed me that the > Browser NEGOTIATE mechanism assumes that the Service ticket is going to > be Named HTTP. This means that for Proxied implementations, to include > IPA, we will have to share the Service Principal Identity with the > Apache HTTPD server. > > http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm > > However, once you start digging in, you will find that the solutions > are suboptimal. It turns out that the Negotiate auth-method has only > very recently been supported, and that is only on Tomcat7. > > The best resource I have found on the options for a custom realm is here: > http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos > and the most likely option > http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule > > We really want a mix of the KRB5Login Module and the JNDIRealm. That > seems to be what is described here: > http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html > > We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with > Tomcat-7. > > I suspect that the CombinedRealm approach will not support falling back > from one auth-method to another: I've been looking and have not see it > specified that you can put multiple auth-method entries inside a > login-config in the web.xml. Ideally, we would attempt a Certificate > based authentication first, and then fall back to Negotiate. However, > we can say that a given deployment is going to be either Kerberos or > Client Certificate, and swap out the configuration at the Tomcat > level. I don't like that nearly as much. > > The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback > talks about how to do Client Cert with a fallback to Form based > authentication. We'd want to do Client Cert with a fallback to Krb5. > This is using what is called a Valve. In Tomcat 6 and 7 valves have > been deprecated in favor of Filters. The general approach is the same. > > I'd like to keep the idea of the Realm as the primary approach. If we > do have to build a custom Realm, and I suspect that we will, we might > want to spin it off into its own package, or submit it for Inclusion in > Tomcat 7 upstream. > > It seems that the PKI approach has been to Bind as Directory Manager. > What I would like to target moving forward is that the Bind is done as > the user making the web request. For managed operations that require a > higher level of authentication, we use the concept of queues like we do > now. The threads that manage those queue will use a Principal with a > higher level of authorization: not "Directory Manger", but perhaps "CA > Manager" which is a user we create that manages the CA subtree in the > Directory server. For a Dogtag deployment without IPA, the CA Manger > would have write privileged on the Identity subtree. For integrated > deployments, IPA would have its own principal "IPA Manager" that > would not have read or write capabilities in the CA Subtree. DRM, > TKS and other subsytems would in turn also get their own Manager users, > and they would only have permissions to manage their own trees: we will > need to clear up which gets read and write permissions on which other > subtrees. > > Directory Manager would be limited to performing operations that effect > the entire DS instance: Setup and Replication. > > The Directory Manager, CA Manager, IPA manager users should be binding > with a certificate or a keytab, not with a cleartext password. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 2 03:17:44 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 22:17:44 -0500 Subject: [Freeipa-devel] [PATCH] Remove unused make flags Message-ID: <1322795864.22044.73.camel@willson.li.ssimo.org> Very simple patch to remove unused stuff, could have been a onelliner I guess, but here we go :) Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ipa-kdb-Remove-unused-CFLAGS-LIBS-from-Makefiles.patch Type: text/x-patch Size: 888 bytes Desc: not available URL: From simo at redhat.com Fri Dec 2 03:51:57 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 01 Dec 2011 22:51:57 -0500 Subject: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA Message-ID: <1322797917.22044.108.camel@willson.li.ssimo.org> Hello all, with this set of patches it is possible to allow constrained delegation of credentials so that a service can impersonate a user when communicating with another service w/o requiring the user to actually forward their TGT. This makes for a much better method of delegating credentials as it prevents exposure of the short term secret of the user. Plus, I added a relatively simple access control method that allow the KDC to decide exactly which services are allowed to impersonate which users against other services. A simple grouping mechanism is used so that large environments clusters and otherwise classes of services can be much more easily managed. The grouping mechanism has been built so that lookup is highly optimized and is basically reduced to a single search that uses the derefernce control. Speed is very important in this case because KDC operations time out very quickly and unless we add a caching layer in ipa-kdb we must keep the number of searches down to avoid client timeouts. The grouping mechanism is very simple a groupOfPrincipals object is introduced, this Auxiliary class have a single optional attribute called memberPrincipal which is a string containing a principal name. A separate objectclass is also introduced called ipaKrb5DelegationACL, it is a subclass of groupOfPrincipals and is a Structural class. It has 2 additional optional attributes: ipaAllowedTarget and ipaAllowToImpersonate. They are both DNs The memberPrincipal attribute in this class contains the list of principals that are being considered as 'proxies', that is the principals of the services that want to impersonate users against other services. The ipaAllowedToImpersonate must point to a groupOfPrincipal based object that contains the list of users that can be impersonated by this service. If the attribute is missing than the service is allowed to impersonate *any* user. The ipaAllowedTarget DN must point to a groupOfPrincipal based object that contains the list of services that the proxy service is allowed taret when impersonating users. A target must be specified in order to allow a service to access it impersonating another principal. At the moment no wildcarding is implemented so services have to be explicitly listed in their respective groups. I have some idea of adding wildcard support at least for the ipaAllowedToImpersonate group in order to separate user principals by REALM. So you can say all users of REALM1 can be impersonated by this service but no users of REALM2. It is unclear how this wildcarding may be implemented, but it must be simple to avoid potentially very expensive computations every time a ticket for the target services is requested. I have briefly tested this patch by manually creating a few objects then using the kvno command to test that I could get a ldap ticket just using the HTTP credentials (in order to do this I had to allow also s4u2self operations for the HTTP service, but this is *not* generally required and it is *not* desired in the IPA framework implementation). This patchset does not contain any CLI or UI nor installation changes to create ipaKrb5DelegationACL obujects. It is indeed yet unclear where we want to store them (suggestions are welcome) and how/when we may want to expose this mechanism through UI/CLI for general usage. The initial intended usage is to allow us to move away from using forwarded TGTs in the IPA framework and instead use S4U2Proxy in order to access the ldap service. In order to do this some changes will need to be made in installation scripts and replica management scripts later. How to test: Create 2 objects like these: dn: cn=ipa-http-delegation,... objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals cn: ipa-http-delegation memberPrincipal: HTTP/ipaserver.example.com at EXAMPLE.COM ipaAllowedTarget: cn=ipa-ldap-delegation-targets,... dn: cn=ipa-ldap-delegation-targets,... objectClass: groupOfPrincipals cn: ipa-ldap-delegation-targets memberPrincipal: ldap/ipaserver.example.com at EXAMPLE.COM In order to test with kvno which pretend to do s4u2self too you will need to allow the HTTP service to impersonate arbitrary users. This is done with: kdamin.local modprinc +ok_to_auth_as_delegate HTTP/ipaserver.example.com Then run kvno as follows: # Init credntials as HTTP kinit -kt /etc/httpd/conf/ipa.keytab HTTP/ipaserver.example.com # Perform S4U2Self kvno -U admin HTTP/ipaserver.example.com # Perform S4U2Proxy kvno -k /etc/httpd/conf/ipa.keytab -U admin -P HTTP/ipaserver.example.com ldap/ipaserver.example.com If this works it means you successfully impersonated the admin user with the HTTP service against the ldap service. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ipa-kdb-Delegation-ACL-schema.patch Type: text/x-patch Size: 3083 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-ipa-kdb-enhance-deref-searches.patch Type: text/x-patch Size: 5699 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-ipa-kdb-Add-delgation-access-control-support.patch Type: text/x-patch Size: 8251 bytes Desc: not available URL: From abokovoy at redhat.com Fri Dec 2 06:17:25 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2011 08:17:25 +0200 Subject: [Freeipa-devel] [PATCH] Remove unused make flags In-Reply-To: <1322795864.22044.73.camel@willson.li.ssimo.org> References: <1322795864.22044.73.camel@willson.li.ssimo.org> Message-ID: <20111202061725.GA426@redhat.com> On Thu, 01 Dec 2011, Simo Sorce wrote: > Very simple patch to remove unused stuff, could have been a onelliner I > guess, but here we go :) ACK. -- / Alexander Bokovoy From mkosek at redhat.com Fri Dec 2 08:17:00 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 02 Dec 2011 09:17:00 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <4ED7FD3B.3030006@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> Message-ID: <1322813820.9851.10.camel@balmora.brq.redhat.com> On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: > >> I have prepared a working prototype of the new structured DNS API. It > >> may still have rough edges (and unit tests are not ready), but it will > >> provide a base for discussion and for WebUI folks - so that they can > >> start development of the new DNS WebUI API. > >> > >> The patch takes advantage of the DNS refactor I did in 172. For all > >> supported non-DNSSEC RR types, the following commands are available: > >> > >> dnsrecord-show ZONE NAME > >> dnsrecord-add ZONE NAME > >> dnsrecord-mod ZONE NAME VALUE > >> > >> This is an example of the new API in action: > >> > >> # ipa dnsrecord-show example.com foo > >> Record name: foo > >> A record: 10.0.0.1 > >> > >> # ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com." > >> MX record: 0 foo.example.com. > >> Preference: 0 > >> Exchanger: foo.example.com. > >> ---------------------------- > >> Number of entries returned 1 > >> ---------------------------- > >> > >> # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger="foo.example.com." > >> MX record: 0 foo.example.com. > >> Preference: 0 > >> Exchanger: foo.example.com. > >> > >> MX record: 1 foo.example.com. > >> Preference: 1 > >> Exchanger: foo.example.com. > >> ---------------------------- > >> Number of entries returned 2 > >> ---------------------------- > >> > >> # ipa dnsrecordmx-show example.com foo > >> MX record: 0 foo.example.com. > >> Preference: 0 > >> Exchanger: foo.example.com. > >> > >> MX record: 1 foo.example.com. > >> Preference: 1 > >> Exchanger: foo.example.com. > >> ---------------------------- > >> Number of entries returned 2 > >> ---------------------------- > >> > >> > >> There is an interactive wizard to help user modify a record without > >> specifying an updated value first. If there is just one (MX) record, no > >> wizard would be run. > >> > >> # ipa dnsrecordmx-mod example.com foo --preference=2 > >> Which MX record would you like to modify? > >> > >> [1]: 0 foo.example.com. > >> [2]: 1 foo.example.com. > >> > >> DNS record number: 2 > >> MX record: 0 foo.example.com. > >> Preference: 0 > >> Exchanger: foo.example.com. > >> > >> MX record: 2 foo.example.com. > >> Preference: 2 > >> Exchanger: foo.example.com. > >> ---------------------------- > >> Number of entries returned 2 > >> ---------------------------- > >> > >> # ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3 > >> MX record: 0 foo.example.com. > >> Preference: 0 > >> Exchanger: foo.example.com. > >> > >> MX record: 3 foo.example.com. > >> Preference: 3 > >> Exchanger: foo.example.com. > >> ---------------------------- > >> Number of entries returned 2 > >> ---------------------------- > >> > >> > >> There are few open questions I am still thinking about: > >> > >> 1) The commands return a list of structured records (just like *-find > >> commands) instead of returning just one record. I thought that it may be > >> more usable this way and consistent with dnsrecord-add/mod/show commands > >> behavior which returns all records too. Otherwise, we would have to > >> change the show command API and add VALUE argument, which would specify > >> a value to be displayed: > >> dnsrecord-show ZONE NAME VALUE > >> > >> 2) Raw DNS record value is in the output too. I though it would be > >> useful to see the raw DNS record value + its parts at one place. > >> > >> 3) The commands are in format dnsrecord-cmd, for example > >> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we > >> want to go this way, I would have to bend the server framework a little > >> which parses an LDAP object from the command name (LDAP object name is > >> dnsrecordmx in this case). This is doable, although I am not sure if > >> this does not have some implications in WebUI side. > >> > >> Martin > > > > I rebased both patches to the most recent master. Adding CSVs now works > > ok again (with the fix in 175): > > > > # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 > > Record name: foo > > A record: 10.0.0.1, 10.0.0.2 > > > > Martin > Rob, thank you for the review! What do you think about the 3 open questions I posted above? > I think some abbreviations can be eliminated: > > siz -> size > alt -> altitude Sure, this can be fixed. > > For MX record (and probably KX) you can make preference required. It > should fill in without prompting since it has a default. This way it > will show as required in the UI. Right, we don't want to run into issues we had with user fields. > > PTRRecord doc I think would read better as "The hostname this reverse > record points to" Ok. Btw do you think it would be good to document this way all these new DNSRecord part parameters? As I checked with Petr, these would be shown in the UI - so the UI user would benefit from it. But it will require a lot of writing and RFC study :-) > > I'm not sure I follow the makeapi change. I see the new entry types in > API.txt but this makeapi seems to suggest the DNS api is not checked. This fix is in validate_doc(), which tries to check that all our commands have proper __doc__ string. It fails with the new DNS API commands (dnsrecordmx-add etc.) because it cannot find class definitions in dns.py. This is expected as I generate all these LDAP command classes on the fly from new DNSRecord parameters. Martin > > Otherwise generally looks good. > > rob From abokovoy at redhat.com Fri Dec 2 12:58:37 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2011 14:58:37 +0200 Subject: [Freeipa-devel] Q: dnsclient portability Message-ID: <20111202125837.GC426@redhat.com> Hi, I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 which concerns portability of ipapython.dnsclient module. ipapython.dnsclient module uses acutil module to perform 'res_send(3)' call provided by libresolv. acutil implements bindings to two system calls (res_send() and getusershell()) and belongs to authconfig package. The total size of acutil module source code is ~100 lines of C code. Now, authconfig package is not available beyond Fedora/RHEL distributions and, in particular, it is not available in Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on those platforms and a way of getting around the issue needs to be found. So far, there are two options: 1. Extract acutil module from authconfig and supply it with freeipa-python in a manner similar to default_encoding module. This is 'cheapest' solution in a sense we only interested in bindings to res_send(3). FreeIPA client code then will be self-contained and would not depend on authconfig availability (platform portability code already allows to re-implement authconfig implementation). 2. Port ipapython.dnsclient to use dnspython module if acutil is not available. This module, available from http://www.dnspython.org/, can be found in Fedora, GNU/Debian Linux, Ubuntu and many other distributions. It is python-only resolver providing a super-set of ipapython.dnsclient features. The downside of the first approach is a need to distribute and maintain another CPython extension. Though the code is straight forward and simple enough, it is still a separate maintenance burden. The downside of the second approach is to write a bridge code between ipapython.dnsclient API and dnspython API. They are different enough so that remapping of fields in objects resulting from a query is needed. I've started to implement the bridge code myself but it is quickly getting to the level of effort original ipapython.dnsclient has (due to API differences in attributes names) and that means it is probably not worth it. What do you think? -- / Alexander Bokovoy From rcritten at redhat.com Fri Dec 2 13:22:51 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 08:22:51 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <1322794537.22044.63.camel@willson.li.ssimo.org> References: <4ED6AF32.6000607@redhat.com> <1322794537.22044.63.camel@willson.li.ssimo.org> Message-ID: <4ED8D12B.3030703@redhat.com> Simo Sorce wrote: > On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: >> Comments? Suggestions? >> > Sorry for the late reply. > > First of all, excellent write-up John, it is very comprehensive and lays > down things very clearly. > > I agree that using ipa:ipa for memcached and wsgi would be a better > proposition for us. Although we need to explore how this would affect > credential caches created by mod_auth_kerb and our ability to use them, > which is crucial*. The krb ccache will not be readable by ipa:ipa. > You say that object sized for the stuff we will store in memcached > should be limited. What is a reasonable size for those objects ? > I was thinking we may want to store the krb ccaches in memcached in > order to be able to keep them around. The reason I ask is that Krb > ccaches can become quite big if PACs are attached to tickets although > they are normally quite small. > > Aside for these minor details I totally agree with the direction you are > proposing and I can't wait to see it implemented :) Yes, seems fine to me too. rob From ohamada at redhat.com Fri Dec 2 13:25:30 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 02 Dec 2011 14:25:30 +0100 Subject: [Freeipa-devel] [PATCH] 6 Sort password policy by priority In-Reply-To: <4ED535CD.2090709@redhat.com> References: <4ED4F031.9030408@redhat.com> <4ED4F4C1.90806@redhat.com> <4ED535CD.2090709@redhat.com> Message-ID: <4ED8D1CA.5000806@redhat.com> On 11/29/2011 08:43 PM, Rob Crittenden wrote: > Ondrej Hamada wrote: >> On 11/29/2011 03:46 PM, Ondrej Hamada wrote: >>> https://fedorahosted.org/freeipa/ticket/2045 >>> >>> 'ipa pwpolicy-find' output is now sorted by priority of the policies. >>> Lower position means lower priority. Global policy is then at the >>> bottom. >>> >>> The changes has also affected LDAPSearch class in baseldap.py: >>> LDAPSearch class sorts the search results by primary key be default >>> (which is usually 'cn'). Therefor a function pointer entries_sortfn >>> was added. If no sorting function exists, default sorting by primary >>> key >>> is used. >>> >>> Sorting function had to be introduced due to the fact that pwpolicy's >>> primary >>> key is also it's 'cn' and global policy is not allowed to have any >>> priority. >>> >> forget to attach the patch, sorry :-[ >> > > > Doesn't work with the lite-server due to changing a ReadOnly value. I > think you have the right idea you just need to assign the sorting > statically instead of dynamically (it won't change after finalization). > > $ ./ipa pwpolicy-add editors --minlife=2 --priority=9 > > ipa: DEBUG: Created connection context.ldap2 > ipa: DEBUG: raw: pwpolicy_add(u'editors', krbminpwdlife=2, > cospriority=9, all=False, raw=False, version=u'2.15') > ipa: DEBUG: pwpolicy_add(u'editors', krbminpwdlife=2, cospriority=9, > all=False, raw=False, version=u'2.15') > ipa: DEBUG: raw: cosentry_add(u'editors', > krbpwdpolicyreference=u'cn=editors,cn=GREYOAK.COM,cn=kerberos,dc=greyoak,dc=com', > cospriority=9) > ipa: DEBUG: cosentry_add(u'editors', > krbpwdpolicyreference=u'cn=editors,cn=GREYOAK.COM,cn=kerberos,dc=greyoak,dc=com', > cospriority=9, all=False, raw=False) > ipa: DEBUG: raw: group_show(u'editors', all=True) > ipa: DEBUG: group_show(u'editors', rights=False, all=True, raw=False) > ipa: DEBUG: raw: cosentry_find(None, cospriority=9) > ipa: DEBUG: cosentry_find(None, cospriority=9, all=False, raw=False, > pkey_only=False) > ipa: ERROR: non-public: AttributeError: locked: cannot set > cosentry_find.entries_sortfn to at 0x7f7abc33ec80> > Traceback (most recent call last): > File "/home/rcrit/redhat/freeipa-review/ipaserver/rpcserver.py", > line 223, in wsgi_execute > result = self.Command[name](*args, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line > 438, in __call__ > ret = self.run(*args, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line > 756, in run > return self.execute(*args, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/baseldap.py", > line 700, in execute > ldap, dn, entry_attrs, attrs_list, *keys, **options > File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/pwpolicy.py", > line 346, in pre_callback > cospriority=options.get('cospriority') > File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line > 438, in __call__ > ret = self.run(*args, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line > 756, in run > return self.execute(*args, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/baseldap.py", > line 700, in execute > ldap, dn, entry_attrs, attrs_list, *keys, **options > File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/pwpolicy.py", > line 127, in pre_callback > self.obj.check_priority_uniqueness(*keys, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/pwpolicy.py", > line 101, in check_priority_uniqueness > cospriority=options['cospriority'] > File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line > 438, in __call__ > ret = self.run(*args, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line > 756, in run > return self.execute(*args, **options) > File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/baseldap.py", > line 1620, in execute > self.entries_sortfn=lambda x,y: > cmp(x[1][self.obj.primary_key.name][0].lower(), > y[1][self.obj.primary_key.name][0].lower()) > File "/home/rcrit/redhat/freeipa-review/ipalib/base.py", line 131, > in __setattr__ > SET_ERROR % (self.__class__.__name__, name, value) > AttributeError: locked: cannot set cosentry_find.entries_sortfn to > at 0x7f7abc33ec80> > ipa: INFO: admin at GREYOAK.COM: pwpolicy_add(u'editors', > krbminpwdlife=2, cospriority=9, all=False, raw=False, > version=u'2.15'): AttributeError > ipa: DEBUG: response: InternalError: an internal error has occurred > ipa: DEBUG: Destroyed connection context.ldap2 > corrected, patch attached -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-6-2-Sort-password-policy-by-priority.patch Type: text/x-patch Size: 3391 bytes Desc: not available URL: From simo at redhat.com Fri Dec 2 13:30:43 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 08:30:43 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4ED8D12B.3030703@redhat.com> References: <4ED6AF32.6000607@redhat.com> <1322794537.22044.63.camel@willson.li.ssimo.org> <4ED8D12B.3030703@redhat.com> Message-ID: <1322832643.6745.8.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 08:22 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: > >> Comments? Suggestions? > >> > > Sorry for the late reply. > > > > First of all, excellent write-up John, it is very comprehensive and lays > > down things very clearly. > > > > I agree that using ipa:ipa for memcached and wsgi would be a better > > proposition for us. Although we need to explore how this would affect > > credential caches created by mod_auth_kerb and our ability to use them, > > which is crucial*. > > The krb ccache will not be readable by ipa:ipa. I feared that, although maybe we can do some trick with default ACLs to make them readable to the 'ipa' user. Do we have the option to re-implement SPNEGO in python and stop using mod_auth_kerb ? Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Fri Dec 2 14:04:31 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2011 16:04:31 +0200 Subject: [Freeipa-devel] [PATCH] fix memleaks In-Reply-To: <1322601248.2613.78.camel@willson.li.ssimo.org> References: <1322601248.2613.78.camel@willson.li.ssimo.org> Message-ID: <20111202140431.GA3787@redhat.com> On Tue, 29 Nov 2011, Simo Sorce wrote: > Found a couple of memleaks while reviewing code. > > Attached. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > >From 70840691e48e1ac89002499c08a9dd4fdcae7c50 Mon Sep 17 00:00:00 2001 > From: Simo Sorce > Date: Sun, 20 Nov 2011 20:50:11 -0500 > Subject: [PATCH] ipa-kdb: fix memleaks in ipa_kdb_mspac.c > > --- > daemons/ipa-kdb/ipa_kdb_mspac.c | 13 +++++++------ > 1 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c > index cce1ca9060f0e03d525bb87d843bdd5811e9d20b..0c0da75ca8dbedf12e39e8ec5d87bfd4cd485d4a 100644 > --- a/daemons/ipa-kdb/ipa_kdb_mspac.c > +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c > @@ -466,7 +466,7 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > TALLOC_CTX *tmpctx; > struct ipadb_e_data *ied; > struct ipadb_context *ipactx; > - LDAPMessage *results; > + LDAPMessage *results = NULL; > LDAPMessage *lentry; > DATA_BLOB pac_data; > krb5_data data; > @@ -479,11 +479,6 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > return KRB5_KDB_DBNOTINITED; > } > > - tmpctx = talloc_new(NULL); > - if (!tmpctx) { > - return ENOMEM; > - } > - > ied = (struct ipadb_e_data *)client->e_data; > if (ied->magic != IPA_E_DATA_MAGIC) { > return EINVAL; > @@ -493,6 +488,11 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > return 0; > } > > + tmpctx = talloc_new(NULL); > + if (!tmpctx) { > + return ENOMEM; > + } > + > memset(&pac_info, 0, sizeof(pac_info)); > pac_info.logon_info.info = talloc_zero(tmpctx, struct PAC_LOGON_INFO); > if (!tmpctx) { Here is an issue -- you are allocating off tmpctx which is not empty here (we checked it right above) but then you are checking tmpctx rather than pac_info.logon_info.info. It is an older error but needs to be fixed as well. Also please name the patch file according to https://fedorahosted.org/freeipa/wiki/PatchFormat :) -- / Alexander Bokovoy From simo at redhat.com Fri Dec 2 14:21:42 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 09:21:42 -0500 Subject: [Freeipa-devel] [PATCH] fix memleaks In-Reply-To: <20111202140431.GA3787@redhat.com> References: <1322601248.2613.78.camel@willson.li.ssimo.org> <20111202140431.GA3787@redhat.com> Message-ID: <1322835702.6745.12.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 16:04 +0200, Alexander Bokovoy wrote: > On Tue, 29 Nov 2011, Simo Sorce wrote: > > Found a couple of memleaks while reviewing code. > > > > Attached. > > > > Simo. > > > > -- > > Simo Sorce * Red Hat, Inc * New York > > > >From 70840691e48e1ac89002499c08a9dd4fdcae7c50 Mon Sep 17 00:00:00 2001 > > From: Simo Sorce > > Date: Sun, 20 Nov 2011 20:50:11 -0500 > > Subject: [PATCH] ipa-kdb: fix memleaks in ipa_kdb_mspac.c > > > > --- > > daemons/ipa-kdb/ipa_kdb_mspac.c | 13 +++++++------ > > 1 files changed, 7 insertions(+), 6 deletions(-) > > > > diff --git a/daemons/ipa-kdb/ipa_kdb_mspac.c b/daemons/ipa-kdb/ipa_kdb_mspac.c > > index cce1ca9060f0e03d525bb87d843bdd5811e9d20b..0c0da75ca8dbedf12e39e8ec5d87bfd4cd485d4a 100644 > > --- a/daemons/ipa-kdb/ipa_kdb_mspac.c > > +++ b/daemons/ipa-kdb/ipa_kdb_mspac.c > > @@ -466,7 +466,7 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > > TALLOC_CTX *tmpctx; > > struct ipadb_e_data *ied; > > struct ipadb_context *ipactx; > > - LDAPMessage *results; > > + LDAPMessage *results = NULL; > > LDAPMessage *lentry; > > DATA_BLOB pac_data; > > krb5_data data; > > @@ -479,11 +479,6 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > > return KRB5_KDB_DBNOTINITED; > > } > > > > - tmpctx = talloc_new(NULL); > > - if (!tmpctx) { > > - return ENOMEM; > > - } > > - > > ied = (struct ipadb_e_data *)client->e_data; > > if (ied->magic != IPA_E_DATA_MAGIC) { > > return EINVAL; > > @@ -493,6 +488,11 @@ static krb5_error_code ipadb_get_pac(krb5_context kcontext, > > return 0; > > } > > > > + tmpctx = talloc_new(NULL); > > + if (!tmpctx) { > > + return ENOMEM; > > + } > > + > > memset(&pac_info, 0, sizeof(pac_info)); > > pac_info.logon_info.info = talloc_zero(tmpctx, struct PAC_LOGON_INFO); > > if (!tmpctx) { > Here is an issue -- you are allocating off tmpctx which is not empty > here (we checked it right above) but then you are checking tmpctx > rather than pac_info.logon_info.info. > > It is an older error but needs to be fixed as well. Ok added this fix. > Also please name the patch file according to > https://fedorahosted.org/freeipa/wiki/PatchFormat :) I lost count of how many patches I handled, and to be honest I think this naming convention sucks a bit. I would be ok changing the number to match a ticket number perhaps, when there is a ticket attached to it, but for patches like this one all you really-need it to append a -2 at the end if a new revision is necessary. Putting arbitrary numbers and names, doesn't make it any easier to handle to me. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-31e0-2-ipa-kdb-fix-memleaks-in-ipa_kdb_mspac.c.patch Type: text/x-patch Size: 1880 bytes Desc: not available URL: From rcritten at redhat.com Fri Dec 2 14:27:18 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 09:27:18 -0500 Subject: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA In-Reply-To: <1322797917.22044.108.camel@willson.li.ssimo.org> References: <1322797917.22044.108.camel@willson.li.ssimo.org> Message-ID: <4ED8E046.2020603@redhat.com> Simo Sorce wrote: > Hello all, > > with this set of patches it is possible to allow constrained delegation > of credentials so that a service can impersonate a user when > communicating with another service w/o requiring the user to actually > forward their TGT. This makes for a much better method of delegating > credentials as it prevents exposure of the short term secret of the > user. > > Plus, I added a relatively simple access control method that allow the > KDC to decide exactly which services are allowed to impersonate which > users against other services. A simple grouping mechanism is used so > that large environments clusters and otherwise classes of services can > be much more easily managed. > > The grouping mechanism has been built so that lookup is highly optimized > and is basically reduced to a single search that uses the derefernce > control. Speed is very important in this case because KDC operations > time out very quickly and unless we add a caching layer in ipa-kdb we > must keep the number of searches down to avoid client timeouts. > > The grouping mechanism is very simple a groupOfPrincipals object is > introduced, this Auxiliary class have a single optional attribute called > memberPrincipal which is a string containing a principal name. > > A separate objectclass is also introduced called ipaKrb5DelegationACL, > it is a subclass of groupOfPrincipals and is a Structural class. > > It has 2 additional optional attributes: ipaAllowedTarget and > ipaAllowToImpersonate. They are both DNs > > The memberPrincipal attribute in this class contains the list of > principals that are being considered as 'proxies', that is the > principals of the services that want to impersonate users against other > services. > > The ipaAllowedToImpersonate must point to a groupOfPrincipal based > object that contains the list of users that can be impersonated by this > service. If the attribute is missing than the service is allowed to > impersonate *any* user. > > The ipaAllowedTarget DN must point to a groupOfPrincipal based object > that contains the list of services that the proxy service is allowed > taret when impersonating users. A target must be specified in order to > allow a service to access it impersonating another principal. > > > At the moment no wildcarding is implemented so services have to be > explicitly listed in their respective groups. > I have some idea of adding wildcard support at least for the > ipaAllowedToImpersonate group in order to separate user principals by > REALM. So you can say all users of REALM1 can be impersonated by this > service but no users of REALM2. > > It is unclear how this wildcarding may be implemented, but it must be > simple to avoid potentially very expensive computations every time a > ticket for the target services is requested. > > I have briefly tested this patch by manually creating a few objects then > using the kvno command to test that I could get a ldap ticket just using > the HTTP credentials (in order to do this I had to allow also s4u2self > operations for the HTTP service, but this is *not* generally required > and it is *not* desired in the IPA framework implementation). > > This patchset does not contain any CLI or UI nor installation changes to > create ipaKrb5DelegationACL obujects. It is indeed yet unclear where we > want to store them (suggestions are welcome) and how/when we may want to > expose this mechanism through UI/CLI for general usage. > > The initial intended usage is to allow us to move away from using > forwarded TGTs in the IPA framework and instead use S4U2Proxy in order > to access the ldap service. In order to do this some changes will need > to be made in installation scripts and replica management scripts later. > > How to test: > > Create 2 objects like these: > > dn: cn=ipa-http-delegation,... > objectClass: ipaKrb5DelegationACL > objectClass: groupOfPrincipals > cn: ipa-http-delegation > memberPrincipal: HTTP/ipaserver.example.com at EXAMPLE.COM > ipaAllowedTarget: cn=ipa-ldap-delegation-targets,... > > dn: cn=ipa-ldap-delegation-targets,... > objectClass: groupOfPrincipals > cn: ipa-ldap-delegation-targets > memberPrincipal: ldap/ipaserver.example.com at EXAMPLE.COM > > > In order to test with kvno which pretend to do s4u2self too you will > need to allow the HTTP service to impersonate arbitrary users. > > This is done with: > kdamin.local > modprinc +ok_to_auth_as_delegate HTTP/ipaserver.example.com > > Then run kvno as follows: > > # Init credntials as HTTP > kinit -kt /etc/httpd/conf/ipa.keytab HTTP/ipaserver.example.com > > # Perform S4U2Self > kvno -U admin HTTP/ipaserver.example.com > > # Perform S4U2Proxy > kvno -k /etc/httpd/conf/ipa.keytab -U admin -P HTTP/ipaserver.example.com ldap/ipaserver.example.com > > > If this works it means you successfully impersonated the admin user with > the HTTP service against the ldap service. > > Simo. > In the third patch in ipadb_get_delegation_acl() you can just fall through to the return. I think the content of this e-mail should be added as a README to the source tree. rob From rcritten at redhat.com Fri Dec 2 14:33:43 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 09:33:43 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <1322813820.9851.10.camel@balmora.brq.redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> Message-ID: <4ED8E1C7.4010504@redhat.com> Martin Kosek wrote: > On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: >>>> I have prepared a working prototype of the new structured DNS API. It >>>> may still have rough edges (and unit tests are not ready), but it will >>>> provide a base for discussion and for WebUI folks - so that they can >>>> start development of the new DNS WebUI API. >>>> >>>> The patch takes advantage of the DNS refactor I did in 172. For all >>>> supported non-DNSSEC RR types, the following commands are available: >>>> >>>> dnsrecord-show ZONE NAME >>>> dnsrecord-add ZONE NAME >>>> dnsrecord-mod ZONE NAME VALUE >>>> >>>> This is an example of the new API in action: >>>> >>>> # ipa dnsrecord-show example.com foo >>>> Record name: foo >>>> A record: 10.0.0.1 >>>> >>>> # ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com." >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger="foo.example.com." >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 1 foo.example.com. >>>> Preference: 1 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> # ipa dnsrecordmx-show example.com foo >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 1 foo.example.com. >>>> Preference: 1 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> >>>> There is an interactive wizard to help user modify a record without >>>> specifying an updated value first. If there is just one (MX) record, no >>>> wizard would be run. >>>> >>>> # ipa dnsrecordmx-mod example.com foo --preference=2 >>>> Which MX record would you like to modify? >>>> >>>> [1]: 0 foo.example.com. >>>> [2]: 1 foo.example.com. >>>> >>>> DNS record number: 2 >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 2 foo.example.com. >>>> Preference: 2 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> # ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3 >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 3 foo.example.com. >>>> Preference: 3 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> >>>> There are few open questions I am still thinking about: >>>> >>>> 1) The commands return a list of structured records (just like *-find >>>> commands) instead of returning just one record. I thought that it may be >>>> more usable this way and consistent with dnsrecord-add/mod/show commands >>>> behavior which returns all records too. Otherwise, we would have to >>>> change the show command API and add VALUE argument, which would specify >>>> a value to be displayed: >>>> dnsrecord-show ZONE NAME VALUE >>>> >>>> 2) Raw DNS record value is in the output too. I though it would be >>>> useful to see the raw DNS record value + its parts at one place. >>>> >>>> 3) The commands are in format dnsrecord-cmd, for example >>>> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we >>>> want to go this way, I would have to bend the server framework a little >>>> which parses an LDAP object from the command name (LDAP object name is >>>> dnsrecordmx in this case). This is doable, although I am not sure if >>>> this does not have some implications in WebUI side. >>>> >>>> Martin >>> >>> I rebased both patches to the most recent master. Adding CSVs now works >>> ok again (with the fix in 175): >>> >>> # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 >>> Record name: foo >>> A record: 10.0.0.1, 10.0.0.2 >>> >>> Martin >> > > Rob, thank you for the review! What do you think about the 3 open > questions I posted above? I haven't applied the patches to see what the output looks like yet so can't really comment on the first two. I think the extra dash would make the command line easier to grok, or at least read, but it isn't a show stopper for me. I'd be interested in feedback from the UI guys but they may have to start poking at it to really know for sure how much of an issue it would be. > >> I think some abbreviations can be eliminated: >> >> siz -> size >> alt -> altitude > > Sure, this can be fixed. > >> >> For MX record (and probably KX) you can make preference required. It >> should fill in without prompting since it has a default. This way it >> will show as required in the UI. > > Right, we don't want to run into issues we had with user fields. > >> >> PTRRecord doc I think would read better as "The hostname this reverse >> record points to" > > Ok. Btw do you think it would be good to document this way all these new > DNSRecord part parameters? As I checked with Petr, these would be shown > in the UI - so the UI user would benefit from it. But it will require a > lot of writing and RFC study :-) I was wondering that myself. The labels can be rather terse, I wasn't sure how much more a _doc() would add. I was also wondering if we should include some of the limits within the doc, esp the 0-64k ones since those are smaller. It would make it somewhat inconsistent which is why I didn't raise it. >> >> I'm not sure I follow the makeapi change. I see the new entry types in >> API.txt but this makeapi seems to suggest the DNS api is not checked. > > This fix is in validate_doc(), which tries to check that all our > commands have proper __doc__ string. It fails with the new DNS API > commands (dnsrecordmx-add etc.) because it cannot find class definitions > in dns.py. This is expected as I generate all these LDAP command classes > on the fly from new DNSRecord parameters. Ok, that's fine then. > > Martin > >> >> Otherwise generally looks good. >> >> rob > > From abokovoy at redhat.com Fri Dec 2 14:39:31 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2011 16:39:31 +0200 Subject: [Freeipa-devel] [PATCH] fix memleaks In-Reply-To: <1322835702.6745.12.camel@willson.li.ssimo.org> References: <1322601248.2613.78.camel@willson.li.ssimo.org> <20111202140431.GA3787@redhat.com> <1322835702.6745.12.camel@willson.li.ssimo.org> Message-ID: <20111202143931.GA6781@redhat.com> On Fri, 02 Dec 2011, Simo Sorce wrote: > > > memset(&pac_info, 0, sizeof(pac_info)); > > > pac_info.logon_info.info = talloc_zero(tmpctx, struct PAC_LOGON_INFO); > > > if (!tmpctx) { > > Here is an issue -- you are allocating off tmpctx which is not empty > > here (we checked it right above) but then you are checking tmpctx > > rather than pac_info.logon_info.info. > > > > It is an older error but needs to be fixed as well. > > Ok added this fix. ACK. > > Also please name the patch file according to > > https://fedorahosted.org/freeipa/wiki/PatchFormat :) > > I lost count of how many patches I handled, and to be honest I think > this naming convention sucks a bit. > > I would be ok changing the number to match a ticket number perhaps, when > there is a ticket attached to it, but for patches like this one all you > really-need it to append a -2 at the end if a new revision is necessary. > Putting arbitrary numbers and names, doesn't make it any easier to > handle to me. I'm fine with any way that does not introduce file names conflicts. We can even write a simple script that takes information from the patch itself and renames the files in a directory according to the established practice. But I think better solution would be to use Gerrit to handle patch reviews. Then the issue of patch names will go away as you'll be dealing with git pull/push mostly. -- / Alexander Bokovoy From rcritten at redhat.com Fri Dec 2 14:46:10 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 09:46:10 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <1322832643.6745.8.camel@willson.li.ssimo.org> References: <4ED6AF32.6000607@redhat.com> <1322794537.22044.63.camel@willson.li.ssimo.org> <4ED8D12B.3030703@redhat.com> <1322832643.6745.8.camel@willson.li.ssimo.org> Message-ID: <4ED8E4B2.8020905@redhat.com> Simo Sorce wrote: > On Fri, 2011-12-02 at 08:22 -0500, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: >>>> Comments? Suggestions? >>>> >>> Sorry for the late reply. >>> >>> First of all, excellent write-up John, it is very comprehensive and lays >>> down things very clearly. >>> >>> I agree that using ipa:ipa for memcached and wsgi would be a better >>> proposition for us. Although we need to explore how this would affect >>> credential caches created by mod_auth_kerb and our ability to use them, >>> which is crucial*. >> >> The krb ccache will not be readable by ipa:ipa. > > I feared that, although maybe we can do some trick with default ACLs to > make them readable to the 'ipa' user. > Do we have the option to re-implement SPNEGO in python and stop using > mod_auth_kerb ? > > Simo. > We last looked at this way back in early v1 so it may be possible now, it wasn't then. This would be a long-term effort. Whatever we do we definitely don't want 389-ds to be running as the same user as the ipa framework. Breaking into the web server via our app would mean filesystem access to the raw LDAP database. rob From rcritten at redhat.com Fri Dec 2 14:49:00 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 09:49:00 -0500 Subject: [Freeipa-devel] [PATCH] fix memleaks In-Reply-To: <1322835702.6745.12.camel@willson.li.ssimo.org> References: <1322601248.2613.78.camel@willson.li.ssimo.org> <20111202140431.GA3787@redhat.com> <1322835702.6745.12.camel@willson.li.ssimo.org> Message-ID: <4ED8E55C.2080602@redhat.com> Simo Sorce wrote: > I lost count of how many patches I handled, and to be honest I think > this naming convention sucks a bit. > > I would be ok changing the number to match a ticket number perhaps, when > there is a ticket attached to it, but for patches like this one all you > really-need it to append a -2 at the end if a new revision is necessary. > Putting arbitrary numbers and names, doesn't make it any easier to > handle to me. The numbers can help at commit time when ordering matters. Most of the time they are just decorators. Being able to identify the owner of a patch in the file name is quite handy IMHO. rob From jcholast at redhat.com Fri Dec 2 14:50:44 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Dec 2011 15:50:44 +0100 Subject: [Freeipa-devel] Hashbang line in IPA scripts Message-ID: <4ED8E5C4.3090403@redhat.com> Hi, We currently use this hashbang line in IPA scripts: #! /usr/bin/python -E IMHO this should be changed to point to Python 2 binary specifically: #! /usr/bin/python2 -E for the sake of distros, which symlink /usr/bin/python to Python 3 binary by default (Fedora 17?). Honza -- Jan Cholasta From simo at redhat.com Fri Dec 2 14:50:03 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 09:50:03 -0500 Subject: [Freeipa-devel] [PATCH] fix memleaks In-Reply-To: <20111202143931.GA6781@redhat.com> References: <1322601248.2613.78.camel@willson.li.ssimo.org> <20111202140431.GA3787@redhat.com> <1322835702.6745.12.camel@willson.li.ssimo.org> <20111202143931.GA6781@redhat.com> Message-ID: <1322837403.6745.16.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 16:39 +0200, Alexander Bokovoy wrote: > On Fri, 02 Dec 2011, Simo Sorce wrote: > > > > memset(&pac_info, 0, sizeof(pac_info)); > > > > pac_info.logon_info.info = talloc_zero(tmpctx, struct PAC_LOGON_INFO); > > > > if (!tmpctx) { > > > Here is an issue -- you are allocating off tmpctx which is not empty > > > here (we checked it right above) but then you are checking tmpctx > > > rather than pac_info.logon_info.info. > > > > > > It is an older error but needs to be fixed as well. > > > > Ok added this fix. > ACK. Ok pushed to master. > > > Also please name the patch file according to > > > https://fedorahosted.org/freeipa/wiki/PatchFormat :) > > > > I lost count of how many patches I handled, and to be honest I think > > this naming convention sucks a bit. > > > > I would be ok changing the number to match a ticket number perhaps, when > > there is a ticket attached to it, but for patches like this one all you > > really-need it to append a -2 at the end if a new revision is necessary. > > Putting arbitrary numbers and names, doesn't make it any easier to > > handle to me. > I'm fine with any way that does not introduce file names conflicts. > We can even write a simple script that takes information from the > patch itself and renames the files in a directory according to the > established practice. > > But I think better solution would be to use Gerrit to handle patch > reviews. Then the issue of patch names will go away as you'll be > dealing with git pull/push mostly. Yes we are working on that with SSSD, if experimentation goes well we will propose using gerrit for freeIPA too. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Dec 2 14:56:23 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 09:56:23 -0500 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <4EAFE5D2.4010607@redhat.com> References: <4E96B5AB.4030800@redhat.com> <4E970565.6040009@redhat.com> <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> Message-ID: <4ED8E717.7050302@redhat.com> Jan Cholasta wrote: > Dne 14.10.2011 10:19, Alexander Bokovoy napsal(a): >> On Fri, 14 Oct 2011, Jan Cholasta wrote: >>> Perform an HTTP request. >>> """ >>> - if self.ca_host == None: >>> - self.ca_host = self._select_ca() >>> + if self.ca_host is None: >>> + object.__setattr__(self, 'ca_host', self._select_ca()) >>> return dogtag.http_request(self.ca_host, port, url, **kw) >> I don't like this approach as well. A better way would be to have a >> class CaCache that is mutable and allow changing its properties. Then >> you would create an instance of CaCache in ca.__init__() and ask for >> its properties later. > > I don't like the idea of introducing a new class every time we need a > ReadOnly attribute to be writable. There's quite a few places in the > code where we do object.__setattr__ on ReadOnly objects. IMO the right > thing to do would be to add means of whitelisting ReadOnly attributes > that need to stay writable after locking. > >> >> You can move those _select_ca(), _select_any_master(), >> _host_has_service() to CaCache as they seem to not depend on anything >> in class ca but rather use global api.env. >> >> This way you will get is a fairly simple CaCache class reusable both >> in ca and ra classes. > > Honza > What is the status of this patch? rob From jcholast at redhat.com Fri Dec 2 15:01:45 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Fri, 02 Dec 2011 16:01:45 +0100 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <4ED8E717.7050302@redhat.com> References: <4E96B5AB.4030800@redhat.com> <4E970565.6040009@redhat.com> <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> <4ED8E717.7050302@redhat.com> Message-ID: <4ED8E859.1050407@redhat.com> Dne 2.12.2011 15:56, Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 14.10.2011 10:19, Alexander Bokovoy napsal(a): >>> On Fri, 14 Oct 2011, Jan Cholasta wrote: >>>> Perform an HTTP request. >>>> """ >>>> - if self.ca_host == None: >>>> - self.ca_host = self._select_ca() >>>> + if self.ca_host is None: >>>> + object.__setattr__(self, 'ca_host', self._select_ca()) >>>> return dogtag.http_request(self.ca_host, port, url, **kw) >>> I don't like this approach as well. A better way would be to have a >>> class CaCache that is mutable and allow changing its properties. Then >>> you would create an instance of CaCache in ca.__init__() and ask for >>> its properties later. >> >> I don't like the idea of introducing a new class every time we need a >> ReadOnly attribute to be writable. There's quite a few places in the >> code where we do object.__setattr__ on ReadOnly objects. IMO the right >> thing to do would be to add means of whitelisting ReadOnly attributes >> that need to stay writable after locking. >> >>> >>> You can move those _select_ca(), _select_any_master(), >>> _host_has_service() to CaCache as they seem to not depend on anything >>> in class ca but rather use global api.env. >>> >>> This way you will get is a fairly simple CaCache class reusable both >>> in ca and ra classes. >> >> Honza >> > > What is the status of this patch? > > rob It fixes the issue and I wouldn't mind leaving it as it is. Alexander? Honza -- Jan Cholasta From simo at redhat.com Fri Dec 2 15:10:24 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 10:10:24 -0500 Subject: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA In-Reply-To: <4ED8E046.2020603@redhat.com> References: <1322797917.22044.108.camel@willson.li.ssimo.org> <4ED8E046.2020603@redhat.com> Message-ID: <1322838624.6745.21.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 09:27 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > Hello all, > > > > with this set of patches it is possible to allow constrained delegation > > of credentials so that a service can impersonate a user when [..] > In the third patch in ipadb_get_delegation_acl() you can just fall > through to the return. Removed useless check. I also noticed I had added the prototype declaration for the new vtable function in the 2nd patch instead of the 3rd where it belongs by mistake. So I fixed that too. > I think the content of this e-mail should be added as a README to the > source tree. Ok, I dumped and adapted the email content into a README file and added it to the third patch. I also fixed the patch names as per policy. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-468-1-ipa-kdb-Delegation-ACL-schema.patch Type: text/x-patch Size: 3083 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-469-2-ipa-kdb-enhance-deref-searches.patch Type: text/x-patch Size: 5136 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-470-2-ipa-kdb-Add-delgation-access-control-support.patch Type: text/x-patch Size: 14666 bytes Desc: not available URL: From simo at redhat.com Fri Dec 2 15:11:48 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 10:11:48 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4ED8E4B2.8020905@redhat.com> References: <4ED6AF32.6000607@redhat.com> <1322794537.22044.63.camel@willson.li.ssimo.org> <4ED8D12B.3030703@redhat.com> <1322832643.6745.8.camel@willson.li.ssimo.org> <4ED8E4B2.8020905@redhat.com> Message-ID: <1322838708.6745.23.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 09:46 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 2011-12-02 at 08:22 -0500, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: > >>>> Comments? Suggestions? > >>>> > >>> Sorry for the late reply. > >>> > >>> First of all, excellent write-up John, it is very comprehensive and lays > >>> down things very clearly. > >>> > >>> I agree that using ipa:ipa for memcached and wsgi would be a better > >>> proposition for us. Although we need to explore how this would affect > >>> credential caches created by mod_auth_kerb and our ability to use them, > >>> which is crucial*. > >> > >> The krb ccache will not be readable by ipa:ipa. > > > > I feared that, although maybe we can do some trick with default ACLs to > > make them readable to the 'ipa' user. > > Do we have the option to re-implement SPNEGO in python and stop using > > mod_auth_kerb ? > > > > Simo. > > > > We last looked at this way back in early v1 so it may be possible now, > it wasn't then. This would be a long-term effort. Yep, medium/long term. > Whatever we do we definitely don't want 389-ds to be running as the same > user as the ipa framework. Breaking into the web server via our app > would mean filesystem access to the raw LDAP database. Totally agree, ipa:ipa should only be used for wsgi/memcached at most. Certainly not other services we currently have. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Dec 2 15:16:27 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 10:16:27 -0500 Subject: [Freeipa-devel] [PATCH] ipa-client-install with --no-sssd option should check for nss_ldap In-Reply-To: <4ED78808.1000801@redhat.com> References: <4EBD294A.20200@redhat.com> <4EC13FD2.9000203@redhat.com> <4ED54F98.4070700@redhat.com> <4ED78808.1000801@redhat.com> Message-ID: <4ED8EBCB.6030801@redhat.com> Ondrej Hamada wrote: > On 11/29/2011 10:33 PM, Rob Crittenden wrote: >> Ondrej Hamada wrote: >>> On 11/11/2011 02:55 PM, Ondrej Hamada wrote: >>>> https://fedorahosted.org/freeipa/ticket/2063 >>>> >>>> In order to check presence of nss_ldap when installing client with >>>> '--no-sssd' option there was added code into ipa-client-install. Check >>>> is base on existence of nss_ldap configuration files. This >>>> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>>> '/etc/libnss_ldap.conf'. Presence of any of these files is considered >>>> as success otherwise failure. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Freeipa-devel mailing list >>>> Freeipa-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> I've rewritten it. Additionally it checks for existence of nss-pam-ldapd >>> and makes the results reusable by configure_{ldap|nslcd}_conf() >>> functions. >>> >>> https://fedorahosted.org/freeipa/ticket/2063 >>> >>> In order to check presence of nss_ldap or nss-pam-ldapd when installing >>> client >>> with '--no-sssd' option there was added code into ipa-client-install. >>> Checking is based on existence of nss_ldap configuration files. This >>> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>> '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could cooperate with >>> pam_ldap >>> module and hence the presence of it is checked by looking for >>> 'pam_ldap.conf' file. >>> Existence of nss-pam-ldapd is checked against existence of 'nslcd.conf' >>> file. >>> All this checking is done by function nssldap_exists(). >>> Because both main modules are maintained by two different functions, the >>> function >>> returns tuple containing return code and dictionary structure - its key >>> is name >>> of target function and value is list of existing configuration files. >>> Files to check are specified inside the nssldap_exists() function. >>> >>> In order to fit the returned values, the functions >>> configure_{ldap|nslcd}_conf() >>> were slightly modified. They accept one more parameter which is list of >>> existing files. >>> They are not checking existence of above mentioned files anymore. >> >> The patch looks good, just a couple of issues. >> >> 1. In the nslcd configurator you add ''.join(files). Did you mean >> ','.join(files)? >> >> 2. The commit message lines wrap making it difficult to read. Can you >> limit the lines to ~70 chars per line? >> >> 3. I think the message printed when neither package is available can >> be simplified to: >> >> One of these packages must be installed: nss_ldap or nss-pam-ldapd >> >> It needs a rebase too. >> >> rob > corrected, corrected, changed, rebased > > > > In order to check presence of nss_ldap or nss-pam-ldapd when > installing client with '--no-sssd' option there was added > code intoipa-client-install. Checking is based on existence > of one of nss_ldap configuration files. This configuration > could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or > '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could > cooperate with pam_ldap module and hence the presence of it > is checked by looking for 'pam_ldap.conf' file. Existence > of nss-pam-ldapd is checked against existence of > 'nslcd.conf' file. All this checking is done by function > nssldap_exists(). Because both modules are maintained by > two different functions, the function returns tuple > containing return code and dictionary structure - its > key is name of target function and value is list of > existing configuration files. Files to check are specified > inside the nssldap_exists() function. > > In order to fit the returned values, the functions > configure_{ldap|nslcd}_conf() were slightly modified. They > accept one more parameter which is list of existing files. > They are not checking existence of above mentioned > files anymore. > > https://fedorahosted.org/freeipa/ticket/2063 > Can you add a block header to nssldap_exists()? I think in particular you need explain that it returns 1 and 0 because that value can eventually be the return value of the installer itself (normally an exists would return True/False). Seeing a traceback: # ipa-client-install --no-sssd [ snip ] Enrolled in IPA realm EXAMPLE.COM Created /etc/ipa/default.conf Configured /etc/krb5.conf for IPA realm EXAMPLE.COM LDAP enabled Kerberos 5 enabled Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 1294, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 1281, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 1211, in install (retcode, conf, filename) = configurer(fstore, cli_basedn, cli_realm, cli_domain, cli_server, dnsok, options) TypeError: configure_ldap_conf() takes exactly 8 arguments (7 given) rob From jdennis at redhat.com Fri Dec 2 15:20:58 2011 From: jdennis at redhat.com (John Dennis) Date: Fri, 02 Dec 2011 10:20:58 -0500 Subject: [Freeipa-devel] Q: dnsclient portability In-Reply-To: <20111202125837.GC426@redhat.com> References: <20111202125837.GC426@redhat.com> Message-ID: <4ED8ECDA.10107@redhat.com> On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: > Hi, > > I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 > which concerns portability of ipapython.dnsclient module. > > ipapython.dnsclient module uses acutil module to perform 'res_send(3)' > call provided by libresolv. acutil implements bindings to two system > calls (res_send() and getusershell()) and belongs to authconfig > package. The total size of acutil module source code is ~100 lines of > C code. > > Now, authconfig package is not available beyond Fedora/RHEL > distributions and, in particular, it is not available in > Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on > those platforms and a way of getting around the issue needs to be > found. > > So far, there are two options: > > 1. Extract acutil module from authconfig and supply it with > freeipa-python in a manner similar to default_encoding module. This is > 'cheapest' solution in a sense we only interested in bindings to > res_send(3). FreeIPA client code then will be self-contained and would > not depend on authconfig availability (platform portability code > already allows to re-implement authconfig implementation). > > 2. Port ipapython.dnsclient to use dnspython module if acutil is not > available. This module, available from http://www.dnspython.org/, can > be found in Fedora, GNU/Debian Linux, Ubuntu and many other > distributions. It is python-only resolver providing a super-set of > ipapython.dnsclient features. > > The downside of the first approach is a need to distribute and > maintain another CPython extension. Though the code is straight > forward and simple enough, it is still a separate maintenance burden. > > The downside of the second approach is to write a bridge code between > ipapython.dnsclient API and dnspython API. They are different enough > so that remapping of fields in objects resulting from a query is > needed. > > I've started to implement the bridge code myself but it is quickly > getting to the level of effort original ipapython.dnsclient has > (due to API differences in attributes names) and that means it is > probably not worth it. I think the second approach is better, here is my reasoning: * If we rebuilt acutil it would make more sense to package it an actual package, not just another IPA CPython module, this would be more flexible and other could use it, but ... * acutil seems incomplete and an odd mix of just 2 functions, probably the minimum needed but not general (I don't know the API's so I might be wrong on that score) * We really don't want to maintain YAP (Yet Another Package) * dnspython seems more complete, widely used, has other maintainers and support we can leverage. (Should we have used it in the first place) * Since dnspython is a superset and once we get ipapython.dnsclient ported to it maybe we'll discover we can then easily user other features dnspython provides. Anyway, tough call, the right answer is not entirely obvious, just my 2 cents. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From ayoung at redhat.com Fri Dec 2 15:39:07 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 02 Dec 2011 10:39:07 -0500 Subject: [Freeipa-devel] Tomcat Realms and Directory Server In-Reply-To: <1322795076.22044.68.camel@willson.li.ssimo.org> References: <4EB970AB.9080807@redhat.com> <1322795076.22044.68.camel@willson.li.ssimo.org> Message-ID: <4ED8F11B.1040003@redhat.com> On 12/01/2011 10:04 PM, Simo Sorce wrote: > Hi Adam, > I haven't replied to this summary so far for 2 reasons. > I had little time to ponder it (and Java is not my forte) and it is > still a bit up in the air. > > I am a bit concerned about the relatively unstable/young support for > some of the tech that would have to be involved, but on the other hand I > tend to like the approach of better in depth security, auth forwarding, > and isolation of instances and credentials used. > > I think you should keep exploring this area and see what works and what > not. > > I wonder if the session work we are doing for the main IPA framework can > be used in some way to simplify part of the work you are doing. > Unfortunately working in Java may be an obstacle in this sense as we > plan to use python native marchalling/unmarshalling of objects in the > session cache, but keep in mind this may be an avenue to offload most of > the auth/session management work to the IPA framework and simplify your > credential management at least when dogtag is integrated with IPA. > > Simo. So I've learned a litle bit more since I wrote this. The Proxy code should forward over the Principal, to the Java side. So we can rely on AJP to do the authentication, and just treat as unauthenticated any that come through without a Principal. There is a little risk here if a system is misconfigured that someone could talk directly to AJP, so we should look into securing the connection between Apache and Tomcat. If we need to keep session information around in the Java side, we can either add our own Session cookie, or store it in the Apache session. Right now, the only need for that I've seen is CRSF Nonces, which are currently disabled due to how IPA talks to Dogtag. We should probably re-enable them incase if anyone wants to talk to the PKI server directly, and provide an exception for IPA to do the work it needs for requesting certificates On the Tomcat side, we would still do JNDI LDAP for getting the Subjects,just using the principal forwarded from AJP. > > On Tue, 2011-11-08 at 13:10 -0500, Adam Young wrote: >> One issue I have been looking at recently is how to integrate PKI and >> IPA at the auth level while keeping a clean separation. >> >> We can extract the authentication from the servlet code, so it is >> purely a matter of configuring the Tomcat instance Realm. >> >> I wrote up a Proof of concept for just doing pure LDAP using simple >> bind, which is not a bad starting point. >> >> http://adam.younglogic.com/2011/11/tomcat-simple-ipa/ >> >> >> We want to continue this approach, but use a more secure authentication >> method. We won't be using basic auth, and we won't be using simple bind. >> >> There are two forms of authentication we want to support: Client >> Certificates and Kerberos. Certificates will work as they do now, and >> Kerberos will be for passing through user credentials from IPA, through >> HTTP to CS. In both cases, the data that backs it will be stored in >> the DS instance. >> >> Tomcat has a class classed a CombinedRealm: >> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm >> >> That might support stacking Certificate and Kerberos auth on top of >> each other. The Realm will then delegate to LDAP for extracting the Roles. >> >> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm >> >> Kerberos is typically done using a JAAS Realm. I have to admit I don't >> really like the fact that we have to modify the JVM startup to do so, it >> is not really that big of a deal. I was also not a fan of setting the >> Realm up as a single service ticket until Simo informed me that the >> Browser NEGOTIATE mechanism assumes that the Service ticket is going to >> be Named HTTP. This means that for Proxied implementations, to include >> IPA, we will have to share the Service Principal Identity with the >> Apache HTTPD server. >> >> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm >> >> However, once you start digging in, you will find that the solutions >> are suboptimal. It turns out that the Negotiate auth-method has only >> very recently been supported, and that is only on Tomcat7. >> >> The best resource I have found on the options for a custom realm is here: >> http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos >> and the most likely option >> http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule >> >> We really want a mix of the KRB5Login Module and the JNDIRealm. That >> seems to be what is described here: >> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html >> >> We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with >> Tomcat-7. >> >> I suspect that the CombinedRealm approach will not support falling back >> from one auth-method to another: I've been looking and have not see it >> specified that you can put multiple auth-method entries inside a >> login-config in the web.xml. Ideally, we would attempt a Certificate >> based authentication first, and then fall back to Negotiate. However, >> we can say that a given deployment is going to be either Kerberos or >> Client Certificate, and swap out the configuration at the Tomcat >> level. I don't like that nearly as much. >> >> The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback >> talks about how to do Client Cert with a fallback to Form based >> authentication. We'd want to do Client Cert with a fallback to Krb5. >> This is using what is called a Valve. In Tomcat 6 and 7 valves have >> been deprecated in favor of Filters. The general approach is the same. >> >> I'd like to keep the idea of the Realm as the primary approach. If we >> do have to build a custom Realm, and I suspect that we will, we might >> want to spin it off into its own package, or submit it for Inclusion in >> Tomcat 7 upstream. >> >> It seems that the PKI approach has been to Bind as Directory Manager. >> What I would like to target moving forward is that the Bind is done as >> the user making the web request. For managed operations that require a >> higher level of authentication, we use the concept of queues like we do >> now. The threads that manage those queue will use a Principal with a >> higher level of authorization: not "Directory Manger", but perhaps "CA >> Manager" which is a user we create that manages the CA subtree in the >> Directory server. For a Dogtag deployment without IPA, the CA Manger >> would have write privileged on the Identity subtree. For integrated >> deployments, IPA would have its own principal "IPA Manager" that >> would not have read or write capabilities in the CA Subtree. DRM, >> TKS and other subsytems would in turn also get their own Manager users, >> and they would only have permissions to manage their own trees: we will >> need to clear up which gets read and write permissions on which other >> subtrees. >> >> Directory Manager would be limited to performing operations that effect >> the entire DS instance: Setup and Replication. >> >> The Directory Manager, CA Manager, IPA manager users should be binding >> with a certificate or a keytab, not with a cleartext password. >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel From rcritten at redhat.com Fri Dec 2 15:40:11 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 10:40:11 -0500 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <20111114093243.GA312@redhat.com> References: <20111114093243.GA312@redhat.com> Message-ID: <4ED8F15B.7060602@redhat.com> Alexander Bokovoy wrote: > Hi, > > FreeIPA SUDO rules use --usercat/--groupcat to specify that rule > applies to all users or groups. Thus, sudorule-add-runasuser and > sudorule-add-runasgroup accept specific groups and users and do not > accept ALL reserved word. > > The patch validates user and group passed to these commands and > reports appropriate errors when these are ALL or all arguments > are empty. > > Ticket #1496 > https://fedorahosted.org/freeipa/ticket/1496 > > One thing I'm not sure about is blocking all variants of the reserved > word 'ALL'. The patch blocks them all due to the fact that most likely > any of 'all', 'All', 'ALL', 'aLL', and so on are mistyping but there > are might be valid cases when group or user is called 'all'. Then runasuser check reports runas-group as the attribute name, I think it should still be runas-user even though it is a group of users. Other member commands don't consider it an error to provide any actual members, it treats it as a no-op. We should probably be consistent. It would probably be better to return the value as passed in by the user rather than user[0].value. rob From rcritten at redhat.com Fri Dec 2 15:53:33 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 10:53:33 -0500 Subject: [Freeipa-devel] [PATCH] 0033 Check all LDAP servers during IPA discovery In-Reply-To: <20111114104800.GA3927@redhat.com> References: <20111114104800.GA3927@redhat.com> Message-ID: <4ED8F47D.7060905@redhat.com> Alexander Bokovoy wrote: > Hi, > > This is patch proposal, I haven't checked it with multiple servers > setup yet. > > When discovering IPA LDAP servers through DNS records, look through all > servers found until first success. A master might be not available or > denied access due to anonymous binds disabled, for example, but > replica may succeed. > > Ticket #1827 > https://fedorahosted.org/freeipa/ticket/1827 Needs a rebase. This works fine but I wonder if someone specifies --server on the command-line if we should try only that server and fail if we can't connect. I can see someone using that so they can specify which server the client uses. rob From pvoborni at redhat.com Fri Dec 2 15:53:46 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 02 Dec 2011 16:53:46 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <4ED8E1C7.4010504@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> <4ED8E1C7.4010504@redhat.com> Message-ID: <4ED8F48A.6030900@redhat.com> On 12/02/2011 03:33 PM, Rob Crittenden wrote: > Martin Kosek wrote: >> On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: >>> Martin Kosek wrote: >>>> On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: >>>>> >>>>> 3) The commands are in format dnsrecord-cmd, for example >>>>> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we >>>>> want to go this way, I would have to bend the server framework a >>>>> little >>>>> which parses an LDAP object from the command name (LDAP object name is >>>>> dnsrecordmx in this case). This is doable, although I am not sure if >>>>> this does not have some implications in WebUI side. >>>>> >>>>> Martin >> >> Rob, thank you for the review! What do you think about the 3 open >> questions I posted above? > > I haven't applied the patches to see what the output looks like yet so > can't really comment on the first two. > > I think the extra dash would make the command line easier to grok, or at > least read, but it isn't a show stopper for me. I'd be interested in > feedback from the UI guys but they may have to start poking at it to > really know for sure how much of an issue it would be. For UI it is better without the dash. With dash it breaks the entity-method naming, which is default behavior for creating commands to the server. But it is quite easy to implement it with the dash too. If it makes the CLI more usable we should add the dash - it may save users more time. >>> PTRRecord doc I think would read better as "The hostname this reverse >>> record points to" >> >> Ok. Btw do you think it would be good to document this way all these new >> DNSRecord part parameters? As I checked with Petr, these would be shown >> in the UI - so the UI user would benefit from it. But it will require a >> lot of writing and RFC study :-) > > I was wondering that myself. The labels can be rather terse, I wasn't > sure how much more a _doc() would add. I was also wondering if we should > include some of the limits within the doc, esp the 0-64k ones since > those are smaller. It would make it somewhat inconsistent which is why I > didn't raise it. The label for attributes is very useful, without it we would have to add the label into internal.py which would only complicate things. The doc can be the same as the label as it is now for many attributes. Anyway special doc is useful if something is not clear. >> Martin >>> rob -- Petr Vobornik From simo at redhat.com Fri Dec 2 16:00:34 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 11:00:34 -0500 Subject: [Freeipa-devel] Hashbang line in IPA scripts In-Reply-To: <4ED8E5C4.3090403@redhat.com> References: <4ED8E5C4.3090403@redhat.com> Message-ID: <1322841634.6745.34.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 15:50 +0100, Jan Cholasta wrote: > Hi, > > We currently use this hashbang line in IPA scripts: > > #! /usr/bin/python -E > > IMHO this should be changed to point to Python 2 binary specifically: > > #! /usr/bin/python2 -E > > for the sake of distros, which symlink /usr/bin/python to Python 3 > binary by default (Fedora 17?). > > Honza Send a patch, but is python2 guaranteed to be always available (thinking RHEL for example) ? Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 2 16:04:20 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 02 Dec 2011 11:04:20 -0500 Subject: [Freeipa-devel] [PATCH] Remove unused make flags In-Reply-To: <20111202061725.GA426@redhat.com> References: <1322795864.22044.73.camel@willson.li.ssimo.org> <20111202061725.GA426@redhat.com> Message-ID: <1322841860.6745.35.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 08:17 +0200, Alexander Bokovoy wrote: > On Thu, 01 Dec 2011, Simo Sorce wrote: > > > Very simple patch to remove unused stuff, could have been a onelliner I > > guess, but here we go :) > ACK. Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Dec 2 16:07:51 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 11:07:51 -0500 Subject: [Freeipa-devel] [PATCH 54/54] ticet 2135 - enhance make-test for debugging In-Reply-To: <201111221916.pAMJGWjr004962@int-mx01.intmail.prod.int.phx2.redhat.com> References: <201111221916.pAMJGWjr004962@int-mx01.intmail.prod.int.phx2.redhat.com> Message-ID: <4ED8F7D7.7050607@redhat.com> John Dennis wrote: > Add option to run the unit tests under PDB, but enter > PDB before anything executes so you can set breakpoints etc. > > Add option to disable nosetest from capturing stdout, handy for > adding print statements when debugging. > > Note: the old --pdb arg behavior is now --pdb-errors, --pdb is now > used to enter pdb upon test execution. This minor change in command > line behavior much more accurately reflects the arg name and the > behavior. This runs the tests over and over and over again until I forcibly break out of pdb: ./make-test --pdb tests/test_xmlrpc/test_user_plugin.py Also, just a nit, but it makes releases easier, don't include the ticket number in the first line of the commit, just include it somewhere in the body. I have to strip those out when I create the release notes. rob From rcritten at redhat.com Fri Dec 2 16:15:35 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 11:15:35 -0500 Subject: [Freeipa-devel] [PATCH] 6 Sort password policy by priority In-Reply-To: <4ED8D1CA.5000806@redhat.com> References: <4ED4F031.9030408@redhat.com> <4ED4F4C1.90806@redhat.com> <4ED535CD.2090709@redhat.com> <4ED8D1CA.5000806@redhat.com> Message-ID: <4ED8F9A7.8030000@redhat.com> Ondrej Hamada wrote: > On 11/29/2011 08:43 PM, Rob Crittenden wrote: >> Ondrej Hamada wrote: >>> On 11/29/2011 03:46 PM, Ondrej Hamada wrote: >>>> https://fedorahosted.org/freeipa/ticket/2045 >>>> >>>> 'ipa pwpolicy-find' output is now sorted by priority of the policies. >>>> Lower position means lower priority. Global policy is then at the >>>> bottom. >>>> >>>> The changes has also affected LDAPSearch class in baseldap.py: >>>> LDAPSearch class sorts the search results by primary key be default >>>> (which is usually 'cn'). Therefor a function pointer entries_sortfn >>>> was added. If no sorting function exists, default sorting by primary >>>> key >>>> is used. >>>> >>>> Sorting function had to be introduced due to the fact that pwpolicy's >>>> primary >>>> key is also it's 'cn' and global policy is not allowed to have any >>>> priority. >>>> >>> forget to attach the patch, sorry :-[ >>> >> >> >> Doesn't work with the lite-server due to changing a ReadOnly value. I >> think you have the right idea you just need to assign the sorting >> statically instead of dynamically (it won't change after finalization). >> >> $ ./ipa pwpolicy-add editors --minlife=2 --priority=9 >> >> ipa: DEBUG: Created connection context.ldap2 >> ipa: DEBUG: raw: pwpolicy_add(u'editors', krbminpwdlife=2, >> cospriority=9, all=False, raw=False, version=u'2.15') >> ipa: DEBUG: pwpolicy_add(u'editors', krbminpwdlife=2, cospriority=9, >> all=False, raw=False, version=u'2.15') >> ipa: DEBUG: raw: cosentry_add(u'editors', >> krbpwdpolicyreference=u'cn=editors,cn=GREYOAK.COM,cn=kerberos,dc=greyoak,dc=com', >> cospriority=9) >> ipa: DEBUG: cosentry_add(u'editors', >> krbpwdpolicyreference=u'cn=editors,cn=GREYOAK.COM,cn=kerberos,dc=greyoak,dc=com', >> cospriority=9, all=False, raw=False) >> ipa: DEBUG: raw: group_show(u'editors', all=True) >> ipa: DEBUG: group_show(u'editors', rights=False, all=True, raw=False) >> ipa: DEBUG: raw: cosentry_find(None, cospriority=9) >> ipa: DEBUG: cosentry_find(None, cospriority=9, all=False, raw=False, >> pkey_only=False) >> ipa: ERROR: non-public: AttributeError: locked: cannot set >> cosentry_find.entries_sortfn to at 0x7f7abc33ec80> >> Traceback (most recent call last): >> File "/home/rcrit/redhat/freeipa-review/ipaserver/rpcserver.py", line >> 223, in wsgi_execute >> result = self.Command[name](*args, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line 438, >> in __call__ >> ret = self.run(*args, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line 756, >> in run >> return self.execute(*args, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/baseldap.py", >> line 700, in execute >> ldap, dn, entry_attrs, attrs_list, *keys, **options >> File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/pwpolicy.py", >> line 346, in pre_callback >> cospriority=options.get('cospriority') >> File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line 438, >> in __call__ >> ret = self.run(*args, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line 756, >> in run >> return self.execute(*args, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/baseldap.py", >> line 700, in execute >> ldap, dn, entry_attrs, attrs_list, *keys, **options >> File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/pwpolicy.py", >> line 127, in pre_callback >> self.obj.check_priority_uniqueness(*keys, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/pwpolicy.py", >> line 101, in check_priority_uniqueness >> cospriority=options['cospriority'] >> File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line 438, >> in __call__ >> ret = self.run(*args, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/frontend.py", line 756, >> in run >> return self.execute(*args, **options) >> File "/home/rcrit/redhat/freeipa-review/ipalib/plugins/baseldap.py", >> line 1620, in execute >> self.entries_sortfn=lambda x,y: >> cmp(x[1][self.obj.primary_key.name][0].lower(), >> y[1][self.obj.primary_key.name][0].lower()) >> File "/home/rcrit/redhat/freeipa-review/ipalib/base.py", line 131, in >> __setattr__ >> SET_ERROR % (self.__class__.__name__, name, value) >> AttributeError: locked: cannot set cosentry_find.entries_sortfn to >> at 0x7f7abc33ec80> >> ipa: INFO: admin at GREYOAK.COM: pwpolicy_add(u'editors', >> krbminpwdlife=2, cospriority=9, all=False, raw=False, >> version=u'2.15'): AttributeError >> ipa: DEBUG: response: InternalError: an internal error has occurred >> ipa: DEBUG: Destroyed connection context.ldap2 >> > corrected, patch attached > ACK, pushed to master. I slightly modified one comment and limited the commit message to 75 chars per line. Nice work. rob From atkac at redhat.com Fri Dec 2 16:49:44 2011 From: atkac at redhat.com (Adam Tkac) Date: Fri, 2 Dec 2011 17:49:44 +0100 Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: enable/disable PTR synchronization per zone In-Reply-To: <06e44f93-1796-4409-8b8b-f9ffff7c6621@zmail13.collab.prod.int.phx2.redhat.com> References: <06e44f93-1796-4409-8b8b-f9ffff7c6621@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <20111202164939.GA12728@redhat.com> On Thu, Dec 01, 2011 at 09:00:18AM -0500, Jiri Kuncar wrote: > I've added an attribute "idnsAllowSyncPTR" to "idnsZone" to enable or disable synchronization of PTR records. However the bind-dyndb-ldap plugin option "sync_ptr" has to be included in /etc/named.conf to run synchronization feature. Hello, This doesn't seem too user-friendly for me. In my opinion better is to allow PTR synchronization when sync_ptr is "no" and idnsAllowSyncPTR is set to "TRUE". So admin can either set sync_ptr to allow updates for all zones or set per-zone idnsAllowSyncPTR attr. Please check my comments inside the patch. > My quick fix of LDAP schema in /usr/share/ipa/60basev2.ldif: > ----- > attributeTypes: (2.16.840.1.113730.3.8.5.11 NAME 'idnsAllowSyncPTR' DESC 'permit synchronization of PTR records' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE X-ORIGIN 'IPA v2' ) > ... > objectClasses: (2.16.840.1.113730.3.8.6.1 NAME 'idnsZone' DESC 'Zone class' SUP idnsRecord STRUCTURAL MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $ idnsSOArName $ idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $ idnsSOAminimum ) MAY ( idnsUpdatePolicy $ idnsAllowSyncPTR ) ) > ----- > > https://fedorahosted.org/bind-dyndb-ldap/ticket/39 > > Jiri > From b1aaef1c05be1a16115eb30bb76a0d1795806bc7 Mon Sep 17 00:00:00 2001 > From: Jiri Kuncar > Date: Thu, 1 Dec 2011 08:32:34 -0500 > Subject: [PATCH] Enable/disable PTR synchronization per zone. Class > idnsRecord has new attribute idnsAllowSyncPTR (BOOLEAN). > > Signed-off-by: Jiri Kuncar > --- > src/ldap_helper.c | 32 ++++++++++++++++++++++++++++++++ > 1 files changed, 32 insertions(+), 0 deletions(-) > > diff --git a/src/ldap_helper.c b/src/ldap_helper.c > index b60cf11..4530155 100644 > --- a/src/ldap_helper.c > +++ b/src/ldap_helper.c > @@ -1801,6 +1801,38 @@ modify_ldap_common(dns_name_t *owner, ldap_instance_t *ldap_inst, > if (ldap_inst->sync_ptr == ISC_TRUE && > (rdlist->type == dns_rdatatype_a || rdlist->type == dns_rdatatype_aaaa)) { > > + /* > + * Find parent zone entry. > + * @todo Try the cache first and improve split. > + */ > + char *zone_dn = strstr(str_buf(owner_dn),", ") + 1; Since this strstr() rule depends on current src/ldap_convert.c:dnsname_to_dn() behavior, please add note to dnsname_to_dn() that modification of the CHECK(str_cat_char(target, ", ")); line could affect this part of code. > + ldap_entry_t *entry; > + ldap_valuelist_t values; > + char *attrs[] = {"idnsAllowSyncPTR", NULL}; > + > + CHECK(ldap_query(ldap_inst, ldap_conn, zone_dn, > + LDAP_SCOPE_BASE, attrs, 0, > + "(&(objectClass=idnsZone)(idnsZoneActive=TRUE))")); > + > + /* Search for zone entry with 'idnsAllowSyncPTR == "TRUE"'. */ > + for (entry = HEAD(ldap_conn->ldap_entries); > + entry != NULL; > + entry = NEXT(entry, link)) { > + result = ldap_entry_getvalues(entry, "idnsAllowSyncPTR", &values); > + if (result != ISC_R_SUCCESS) > + continue; > + > + if (strcmp(HEAD(values)->value, "TRUE") != 0) { > + entry = NULL; > + } > + break; > + } > + /* Any valid zone was found. */ > + if (entry == NULL) { > + log_error("Sync PTR is not allowed in zone %s", zone_dn); idnsAllowSyncPTR set to "FALSE" (or missing idnsAllowSyncPTR attr) shouldn't be treated as error. Please degrade this msg to log_debug(3, "...") for example. > + goto cleanup; > + } It would be nice to receive debug msg when idnsAllowSyncPTR is allowed. What about log_debug(3, "Sync PTR is allowed for zone %s", zone_dn); Regards, Adam -- Adam Tkac, Red Hat, Inc. From edewata at redhat.com Fri Dec 2 17:54:56 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 02 Dec 2011 11:54:56 -0600 Subject: [Freeipa-devel] [PATCH] 32-47 #2040, #1515 Refactor UI widgets In-Reply-To: <4ED65BE2.8050307@redhat.com> References: <4ED4E2B7.2020403@redhat.com> <4ED5C96E.4000707@redhat.com> <4ED65BE2.8050307@redhat.com> Message-ID: <4ED910F0.7050601@redhat.com> The UI seems to be working like before, so patches #32-47 are ACKed. But I'd rather wait until the unit tests are completely fixed before pushing. I'm going to rebase the HBAC Test patches on top of these. I have some comments below, but they can be addressed separately. On 11/30/2011 10:37 AM, Petr Vobornik wrote: >> 6. Open a self service permission, click 'select all' checkbox. The >> update should have become enabled. > Fixed [aci patch #43] When resetting the page the 'select all' remains checked. This is an existing problem. >> 10. In sudo.js you use apply() to call push() like this: >> >> spec.fields.push.apply(spec.fields, [...]); >> >> Why not call spec.fields.push(...) directly? >> > Fixed. My mindset was: i want to push an array. It would be probably OK > if the array was already defined somewhere else. [sudo, hbac patch #45] There are 2 more in line 242 & 249. 11. Create a permission with target 'type'. Edit it, change the type, the attributes will change accordingly. Then click undo/reset, the attributes do not revert back. This is an existing problem. 12. In IPA.checkboxes_field the 'checkbox_load' should have been 'checkboxes_load'. The commented code is not necessary, checkboxes field is different because it can be empty whereas checkbox field always has a value (on/off). 13. The IPA.field.test_dirty() can call widget.save() directly instead of field.save(). It will make more sense because we're comparing the widget's current value with the field's original value. Also this way we don't have to support 2 modes in field.save(): with param and no param. 14. The IPA.rule_details_widget probably can be removed or converted into a field. The category radio widget and the tables probably can be defined directly under the section. 15. The IPA.column still depends on entity to get the column labels. If the table is used by a field that contains pkey of another entity, the field should get the entity's metadata and set the column labels when creating the table. If the table is used by search facet, the facet should supply the labels. 16. The IPA.entity_select_widget should be converted into a subclass of IPA.combobox_field which uses the IPA.combobox_widget. The existing class only contains data handling logic, it doesn't change the UI. 17. The IPA.attributes_widget probably can be converted into a subclass of IPA.checkboxes_field which uses the IPA.table_widget. 18. Similarly, the IPA.rights_widget can be converted into a subclass of IPA.checkboxes_field which uses the IPA.checkboxes_widget. In general if the UI doesn't change we should reuse existing widgets and we should do the behavior customization in the field. 19. The IPA.permission_target_widget can switch inheritance from different super classes (ie. collapsible or non-collapsible section) depending on the parameter. While this is possible in JS, the concept is difficult to translate to other OO framework (in case someday we want to change). Here's the current class hierarchy: section (composite widget) + collapsible section (details section) + details table section + permission target section <-- + non-collapsible details table section + permission target section <-- I think the decision whether to use a collapsible or non-collapsible section should be separate from the permission target section. One solution is to use the following class hierarchy: section (composite widget) + table section + permission target section + collapsible table section <-- + collapsible section + collapsible table section <-- In the details facet definition the permission target section should be specified as a member widget (not a subclass) of collapsible section. In the dialog box the permission target section should be used directly. For other widgets in the details facet, they can be put under a collapsible table section. The class can be implemented either as a subclass of table section or collapsible section, whichever is easier, but it doesn't mean it can switch inheritance. -- Endi S. Dewata From edewata at redhat.com Fri Dec 2 18:42:22 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 02 Dec 2011 12:42:22 -0600 Subject: [Freeipa-devel] [PATCH] 048 Added cross browser support of Array.indexOf method In-Reply-To: <4ED74FDF.3040502@redhat.com> References: <4ED74FDF.3040502@redhat.com> Message-ID: <4ED91C0E.1020004@redhat.com> On 12/1/2011 3:58 AM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/2151 > > Note: I didn't add browser.js to jsl.conf because there is a jsl error - > shortcut for checking NaN and I'm not sure if modifying it into standard > isNaN call would be OK. I don't have an environment to test this properly or to find a solution about the NaN issue, but it doesn't break anything. ACK and pushed to master after fixing whitespace warning. -- Endi S. Dewata From edewata at redhat.com Fri Dec 2 18:49:38 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 02 Dec 2011 12:49:38 -0600 Subject: [Freeipa-devel] [PATCH] 32-47 #2040, #1515 Refactor UI widgets In-Reply-To: <4ED7AF2F.1080303@redhat.com> References: <4ED4E2B7.2020403@redhat.com> <4ED5C96E.4000707@redhat.com> <4ED65BE2.8050307@redhat.com> <4ED79723.2040809@redhat.com> <4ED7AF2F.1080303@redhat.com> Message-ID: <4ED91DC2.5070103@redhat.com> On 12/1/2011 10:45 AM, Adam Young wrote: > On 12/01/2011 10:02 AM, Petr Vobornik wrote: >> 1) Should widget expect that array of values like ['value'] will be >> always passed to update(values) method or the update method should >> also work with simple values like 'value'? > > The widget tests are higly subjective. Do not be afraid to change them, > especially if the assumptions they are written against have changed. > They were written more as a way to exercise the widgets than a > codification of behavior. The best probably would be to support both, but the code would have to check the param type, which would make it more complex. If we're just going accept 1 type we should take the array because it can accommodate single value too. Some single-valued attributes are returned as arrays too. >> 2) Should widget load its own metadata - based on entity and its name >> or it is responsibility of field (current implementation)? > > Personally, I'd prefer if the Metadata was passed to the constructor, as > that allows us to compose it in multiple ways. That will be useful in > the future. INfact, I would prefer it if, instead of the Metatdata as a > chunk, we passed the indivual pieces that are required (pattern > specifically) so that how to build the object can differ, but I wanted > to hold off on doing anything like this until we had at least one more > specific project to integrate with. GO with the most striaght forward > solution for now. Yeah, the metadata should be supplied by the field builder into the field's constructor. Then the field can use it to set the labels in the widget. >> 3) Should custom dirty checks, or other boolean checks (validate) >> always return pure boolean value, or is integer also acceptable. Usage >> of &= or |= operators is producing integer values because it actually >> means 'foo = foo & bar' not 'foo = foo && bar' > > Is there really a difference in Javascript? I so long as they evaluate > to true/false, it is probably fine, but is there the possibility for > confusion? I think we should make sure we use boolean operator instead of bitwise. I'm not sure if we're actually affected, but there's a difference: 1 && 2 => true 1 & 2 => 0 >> Also all jsl warnings are fixed and jsl.conf for tests is added. There's a whitespace warning in patch #49. -- Endi S. Dewata From rcritten at redhat.com Fri Dec 2 20:13:55 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 15:13:55 -0500 Subject: [Freeipa-devel] [PATCH] 909 show HBAC and Sudo rule membership Message-ID: <4ED93183.2040105@redhat.com> The CLI wasn't showing HBAC and Sudo rule membership because it lacked a label. These already show in the UI. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-909-label.patch Type: text/x-patch Size: 3283 bytes Desc: not available URL: From abokovoy at redhat.com Fri Dec 2 20:26:32 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 2 Dec 2011 22:26:32 +0200 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <4ED8E859.1050407@redhat.com> References: <4E96B5AB.4030800@redhat.com> <4E970565.6040009@redhat.com> <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> <4ED8E717.7050302@redhat.com> <4ED8E859.1050407@redhat.com> Message-ID: <20111202202631.GA29560@redhat.com> On Fri, 02 Dec 2011, Jan Cholasta wrote: > >>I don't like the idea of introducing a new class every time we need a > >>ReadOnly attribute to be writable. There's quite a few places in the > >>code where we do object.__setattr__ on ReadOnly objects. IMO the right > >>thing to do would be to add means of whitelisting ReadOnly attributes > >>that need to stay writable after locking. > >> > >>> > >>>You can move those _select_ca(), _select_any_master(), > >>>_host_has_service() to CaCache as they seem to not depend on anything > >>>in class ca but rather use global api.env. > >>> > >>>This way you will get is a fairly simple CaCache class reusable both > >>>in ca and ra classes. > >> > >>Honza > >> > > > >What is the status of this patch? > > > >rob > > It fixes the issue and I wouldn't mind leaving it as it is. > > Alexander? I still don't like it. There is nothing in CA that really requires enabling writting to ReadOnly after locking. ReadOnly is a fundamental promise of our API and breaking it should be possible only for cases where any other approach will be ineffective. This particular case is rather poor implementation of CA/RA classes that could be solved in a simpler way. Sometimes you need to hold promises. ;) -- / Alexander Bokovoy From rcritten at redhat.com Fri Dec 2 22:46:04 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 02 Dec 2011 17:46:04 -0500 Subject: [Freeipa-devel] [PATCH] 908 make some fields required In-Reply-To: <4ED410C2.7000905@redhat.com> References: <4ED3CE6A.9000804@redhat.com> <4ED410C2.7000905@redhat.com> Message-ID: <4ED9552C.6050508@redhat.com> Endi Sukma Dewata wrote: > On 11/28/2011 12:09 PM, Rob Crittenden wrote: >> Some attributes in the framework were not marked as required even though >> they are in the schema. These are typically computed values and I think >> the intention was to not prompt for them. This has the side-effect of >> them showing as not required in the UI even though they are. >> >> Since they all have default values set they won't be prompted for on the >> CLI so there won't be any practical changes. > > This patch fixes the problem with required attributes in DNS Zones and > cn, uidNumber, and gidNumber in Users. The UI now shows the required > indicators for these attributes. So this patch is ACKed. > > Some problems mentioned in ticket #2015 are still present: > > 1. Removing the homeDirectory from a user fails because it's required by > posixAccount. > > 2. Removing the gidNumber from a group fails because it's required by > posixGroup. > > 3. Removing config attributes listed in the ticket generates internal > error. I think at least the server should return a proper error message. > The required indicator can be hard-coded in the UI if necessary. > I know you acked this already but I went ahead and addressed #1 and #2 and updated the patch. For #3 I filed a new ticket, https://fedorahosted.org/freeipa/ticket/2159 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-908-2-required.patch Type: text/x-patch Size: 9537 bytes Desc: not available URL: From jdennis at redhat.com Fri Dec 2 23:15:32 2011 From: jdennis at redhat.com (John Dennis) Date: Fri, 02 Dec 2011 18:15:32 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <1322794537.22044.63.camel@willson.li.ssimo.org> References: <4ED6AF32.6000607@redhat.com> <1322794537.22044.63.camel@willson.li.ssimo.org> Message-ID: <4ED95C14.7020601@redhat.com> On 12/01/2011 09:55 PM, Simo Sorce wrote: > On Wed, 2011-11-30 at 17:33 -0500, John Dennis wrote: >> Comments? Suggestions? >> > Sorry for the late reply. > > First of all, excellent write-up John, it is very comprehensive and lays > down things very clearly. Thank you. > I agree that using ipa:ipa for memcached and wsgi would be a better > proposition for us. Although we need to explore how this would affect > credential caches created by mod_auth_kerb and our ability to use them, > which is crucial*. > > You say that object sized for the stuff we will store in memcached > should be limited. What is a reasonable size for those objects ? > I was thinking we may want to store the krb ccaches in memcached in > order to be able to keep them around. The reason I ask is that Krb > ccaches can become quite big if PACs are attached to tickets although > they are normally quite small. I had to do a little digging to get the answer. The maximum size of a single entry is 1 MB. That includes some metadata bound to the item for internal use, but it isn't a lot, so technically a single item's max size is just under one megabyte. This limit can be increased but the memcached developers do not recommend it (I believe because it reduces memory usage efficiency due to page hits). By default the memcached daemon initializes with 64 MB of total memory the vast majority of which is allocated to item storage and a minor amount allocated to bookkeeping. The total memory size is easily adjusted by a command line parameter when the daemon initializes. In addition the Python library supports compression using zlib. You specify a minimum compression length. The value is converted into it's storage form (python objects other than integers and strings are "pickled") and if the length of the value in it's final storage form is greater than the minimum compression length zib is invoked to compress it. This way zlib compression is avoided for small items (or compression can be completely disabled). Thus we have the option to play around with compressing our entries if we discover we have some need to. I think initially we would disable compression sacrificing memory consumption in favor of performance. My guess is we're not likely to be bumping up against the 1 MB per item threshold (nor would it be smart to anywhere be close to that). I think I recalled you mentioning that PAC data would max out around 16 KB. So I don't see the limit as being something we realistically need to worry about (or at least I hope not :-) One nice feature of memcached is you can query the statistics from a live daemon at any time. While we're tuning we might need to do this. > Aside for these minor details I totally agree with the direction you are > proposing and I can't wait to see it implemented :) > > > Simo. > > > *In the long term we may even decide to stop using mod_auth_kerb and do > our own handling if this simplifies things, but I guess we will need an > interim transition period in any case, because we can't depend on too > many changes to be done at once as a dependency to introduce sessions. > -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Sat Dec 3 15:55:31 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 3 Dec 2011 17:55:31 +0200 Subject: [Freeipa-devel] Session design document In-Reply-To: <4ED95C14.7020601@redhat.com> References: <4ED6AF32.6000607@redhat.com> <1322794537.22044.63.camel@willson.li.ssimo.org> <4ED95C14.7020601@redhat.com> Message-ID: <20111203155530.GA14350@redhat.com> On Fri, 02 Dec 2011, John Dennis wrote: > My guess is we're not likely to be bumping up against the 1 MB per > item threshold (nor would it be smart to anywhere be close to that). > I think I recalled you mentioning that PAC data would max out around > 16 KB. So I don't see the limit as being something we realistically > need to worry about (or at least I hope not :-) According to http://support.microsoft.com/kb/327825: ---------------------------------------------------------------------- TokenSize = 1200 + 40d + 8s This formula uses the following values: d: The number of domain local groups a user is a member of plus the number of universal groups outside the user's account domain plus the number of groups represented in security ID (SID) history. s: The number of security global groups that a user is a member of plus the number of universal groups in a user's account domain. 1200: The estimated value for ticket overhead. This value can vary depending on factors such as DNS domain name length, client name, and other factors. ----------------------------------------------------------------------- The KB article goes on to say that the recommended maximum value is 65535 bytes. It is 'a fixed Kerberos ticket receive buffer that contains the SIDs that represent the groups in which the account is a member'. Thus, in large environments realistic limit is still 64Kb per PAC. -- / Alexander Bokovoy From dpal at redhat.com Sat Dec 3 19:06:48 2011 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 03 Dec 2011 14:06:48 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <1322790534.22044.54.camel@willson.li.ssimo.org> References: <4ED6AF32.6000607@redhat.com> <4ED813CF.8040403@redhat.com> <4ED81C5C.9010307@redhat.com> <1322790534.22044.54.camel@willson.li.ssimo.org> Message-ID: <4EDA7348.1030500@redhat.com> On 12/01/2011 08:48 PM, Simo Sorce wrote: > On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: >> On 12/01/2011 06:54 PM, Dmitri Pal wrote: >>> Seems reasonable. I agree with pros and cons and suggestions but I am >>> not the person to make the final approval. Simo? >>> >>> Question for John: Is there any benefit for CLI or it is for UI only? >> Currently it would benefit the UI only. That's mostly because there is >> no mechanism in the cli to cache the session ID. Adding that wouldn't be >> too difficult except for the issue of how to store the session ID >> securely, it would have to be written to a file (unlike with a browser >> which is supposed to hold session cookies in memory). Is there an >> ability to add a data item like this to the user's kerberos credential >> cache? > Yes we could create a fake key and stick the session id in it. > That was the trick we proposed using when this question was raised a few > months ago during a conference call on the matter. > > Simo. > Can we please then extend the design to include this? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sin at altlinux.ru Mon Dec 5 00:37:07 2011 From: sin at altlinux.ru (Evgeny Sinelnikov) Date: Mon, 5 Dec 2011 03:37:07 +0300 Subject: [Freeipa-devel] [PATCH] #2160 ipa_kpasswd: Update selinux policies Message-ID: The ipa_kpasswd daemon can't listen ldap on tcp and access to /dev/urandom due to an error in the selinux policies on Fedora 16. Attached patch fixed it instead of "setsebool authlogin_nsswitch_use_ldap on" using. -- Sin (Sinelnikov Evgeny) Etersoft -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ipa_kpasswd-Update-selinux-policies.patch Type: text/x-patch Size: 1103 bytes Desc: not available URL: From abokovoy at redhat.com Mon Dec 5 09:40:12 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Dec 2011 11:40:12 +0200 Subject: [Freeipa-devel] [PATCH] Make pwd-extop aware of new ipaNTHash attribute In-Reply-To: <20111128172840.GF2246@localhost.localdomain> References: <20111128172840.GF2246@localhost.localdomain> Message-ID: <20111205094011.GA27139@redhat.com> On Mon, 28 Nov 2011, Sumit Bose wrote: > Hi, > > in IPAv3 we introduce a new attribute 'ipaNTHash' to store the NT hash. > Currently the plugin handling the change password extended operation > only sets and updates 'sambaNTPassword'. This patch add support for the > new attribute without removing the support for the old one. ACK One possible enhancement I would make is to get attribute names as constant defines and re-use them across the code. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Dec 5 09:42:30 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Dec 2011 11:42:30 +0200 Subject: [Freeipa-devel] [PATCH] Add ipasam samba passdb backend In-Reply-To: <1322648533.2924.1.camel@balmora.brq.redhat.com> References: <20111123154802.GI2205@localhost.localdomain> <20111128172227.GE2246@localhost.localdomain> <20111129210926.GK2246@localhost.localdomain> <20111129212541.GA24514@redhat.com> <20111130091134.GA2348@localhost.localdomain> <1322648533.2924.1.camel@balmora.brq.redhat.com> Message-ID: <20111205094229.GA27978@redhat.com> On Wed, 30 Nov 2011, Martin Kosek wrote: > On Wed, 2011-11-30 at 10:11 +0100, Sumit Bose wrote: > > On Tue, Nov 29, 2011 at 11:25:41PM +0200, Alexander Bokovoy wrote: > > > On Tue, 29 Nov 2011, Sumit Bose wrote: > > > > @@ -199,10 +216,11 @@ class ADTRUSTInstance(service.Service): > > > > self.admin_conn.addEntry(entry) > > > > > > > > entry = ipaldap.Entry(self.smb_dom_dn) > > > > - entry.setValues("objectclass", ["sambaDomain", "nsContainer"]) > > > > + entry.setValues("objectclass", [self.OBJC_DOMAIN, "nsContainer"]) > > > > entry.setValues("cn", self.domain_name) > > > > - entry.setValues("sambaDomainName", self.netbios_name) > > > > - entry.setValues("sambaSID", self.__gen_sid_string()) > > > > + entry.setValues(self.ATTR_FLAT_NAME, self.netbios_name) > > > > + entry.setValues(self.ATTR_SID, self.__gen_sid_string()) > > > > + entry.setValues(self.ATTR_GUID, str(uuid.uuid4())) > > > > #TODO: which MAY attributes do we want to set ? > > > > self.admin_conn.add_s(entry) > > > Could you please also convert this one to .addEntry(entry)? > > > I think it is the last one left... > > > > This is fixed in freeipa-sbose-0012-3-Fix-some-pylint-warnings.patch. > > > > Martin, shall I extract the add_s->addEntry changes into a separate > > patch so the they can reviewed indepently of the 6 ipasam patches? > > > > bye, > > Sumit > > > > I think it is OK to review (and push) them in a scope of your patch > 0012-3, we don't have to divide them. Yes. ACK then. -- / Alexander Bokovoy From ohamada at redhat.com Mon Dec 5 11:34:50 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Mon, 05 Dec 2011 12:34:50 +0100 Subject: [Freeipa-devel] [PATCH] ipa-client-install with --no-sssd option should check for nss_ldap In-Reply-To: <4ED8EBCB.6030801@redhat.com> References: <4EBD294A.20200@redhat.com> <4EC13FD2.9000203@redhat.com> <4ED54F98.4070700@redhat.com> <4ED78808.1000801@redhat.com> <4ED8EBCB.6030801@redhat.com> Message-ID: <4EDCAC5A.1090703@redhat.com> On 12/02/2011 04:16 PM, Rob Crittenden wrote: > Ondrej Hamada wrote: >> On 11/29/2011 10:33 PM, Rob Crittenden wrote: >>> Ondrej Hamada wrote: >>>> On 11/11/2011 02:55 PM, Ondrej Hamada wrote: >>>>> https://fedorahosted.org/freeipa/ticket/2063 >>>>> >>>>> In order to check presence of nss_ldap when installing client with >>>>> '--no-sssd' option there was added code into ipa-client-install. >>>>> Check >>>>> is base on existence of nss_ldap configuration files. This >>>>> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>>>> '/etc/libnss_ldap.conf'. Presence of any of these files is considered >>>>> as success otherwise failure. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Freeipa-devel mailing list >>>>> Freeipa-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>> I've rewritten it. Additionally it checks for existence of >>>> nss-pam-ldapd >>>> and makes the results reusable by configure_{ldap|nslcd}_conf() >>>> functions. >>>> >>>> https://fedorahosted.org/freeipa/ticket/2063 >>>> >>>> In order to check presence of nss_ldap or nss-pam-ldapd when >>>> installing >>>> client >>>> with '--no-sssd' option there was added code into ipa-client-install. >>>> Checking is based on existence of nss_ldap configuration files. This >>>> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>>> '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could cooperate with >>>> pam_ldap >>>> module and hence the presence of it is checked by looking for >>>> 'pam_ldap.conf' file. >>>> Existence of nss-pam-ldapd is checked against existence of >>>> 'nslcd.conf' >>>> file. >>>> All this checking is done by function nssldap_exists(). >>>> Because both main modules are maintained by two different >>>> functions, the >>>> function >>>> returns tuple containing return code and dictionary structure - its >>>> key >>>> is name >>>> of target function and value is list of existing configuration files. >>>> Files to check are specified inside the nssldap_exists() function. >>>> >>>> In order to fit the returned values, the functions >>>> configure_{ldap|nslcd}_conf() >>>> were slightly modified. They accept one more parameter which is >>>> list of >>>> existing files. >>>> They are not checking existence of above mentioned files anymore. >>> >>> The patch looks good, just a couple of issues. >>> >>> 1. In the nslcd configurator you add ''.join(files). Did you mean >>> ','.join(files)? >>> >>> 2. The commit message lines wrap making it difficult to read. Can you >>> limit the lines to ~70 chars per line? >>> >>> 3. I think the message printed when neither package is available can >>> be simplified to: >>> >>> One of these packages must be installed: nss_ldap or nss-pam-ldapd >>> >>> It needs a rebase too. >>> >>> rob >> corrected, corrected, changed, rebased >> >> >> >> In order to check presence of nss_ldap or nss-pam-ldapd when >> installing client with '--no-sssd' option there was added >> code intoipa-client-install. Checking is based on existence >> of one of nss_ldap configuration files. This configuration >> could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >> '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could >> cooperate with pam_ldap module and hence the presence of it >> is checked by looking for 'pam_ldap.conf' file. Existence >> of nss-pam-ldapd is checked against existence of >> 'nslcd.conf' file. All this checking is done by function >> nssldap_exists(). Because both modules are maintained by >> two different functions, the function returns tuple >> containing return code and dictionary structure - its >> key is name of target function and value is list of >> existing configuration files. Files to check are specified >> inside the nssldap_exists() function. >> >> In order to fit the returned values, the functions >> configure_{ldap|nslcd}_conf() were slightly modified. They >> accept one more parameter which is list of existing files. >> They are not checking existence of above mentioned >> files anymore. >> >> https://fedorahosted.org/freeipa/ticket/2063 >> > > Can you add a block header to nssldap_exists()? I think in particular > you need explain that it returns 1 and 0 because that value can > eventually be the return value of the installer itself (normally an > exists would return True/False). I've changed it to return True/False and added comment > > Seeing a traceback: > > # ipa-client-install --no-sssd > > [ snip ] > > Enrolled in IPA realm EXAMPLE.COM > Created /etc/ipa/default.conf > Configured /etc/krb5.conf for IPA realm EXAMPLE.COM > LDAP enabled > Kerberos 5 enabled > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 1294, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 1281, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 1211, in install > (retcode, conf, filename) = configurer(fstore, cli_basedn, > cli_realm, cli_domain, cli_server, dnsok, options) > TypeError: configure_ldap_conf() takes exactly 8 arguments (7 given) > > rob corrected -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-3-4-Client-install-checks-for-nss_ldap.patch Type: text/x-patch Size: 7157 bytes Desc: not available URL: From sgallagh at redhat.com Mon Dec 5 14:33:52 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 05 Dec 2011 09:33:52 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4EDA7348.1030500@redhat.com> References: <4ED6AF32.6000607@redhat.com> <4ED813CF.8040403@redhat.com> <4ED81C5C.9010307@redhat.com> <1322790534.22044.54.camel@willson.li.ssimo.org> <4EDA7348.1030500@redhat.com> Message-ID: <1323095632.2194.41.camel@sgallagh520.sgallagh.bos.redhat.com> On Sat, 2011-12-03 at 14:06 -0500, Dmitri Pal wrote: > On 12/01/2011 08:48 PM, Simo Sorce wrote: > > On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: > >> On 12/01/2011 06:54 PM, Dmitri Pal wrote: > >>> Seems reasonable. I agree with pros and cons and suggestions but I am > >>> not the person to make the final approval. Simo? > >>> > >>> Question for John: Is there any benefit for CLI or it is for UI only? > >> Currently it would benefit the UI only. That's mostly because there is > >> no mechanism in the cli to cache the session ID. Adding that wouldn't be > >> too difficult except for the issue of how to store the session ID > >> securely, it would have to be written to a file (unlike with a browser > >> which is supposed to hold session cookies in memory). Is there an > >> ability to add a data item like this to the user's kerberos credential > >> cache? > > Yes we could create a fake key and stick the session id in it. > > That was the trick we proposed using when this question was raised a few > > months ago during a conference call on the matter. > > > > Simo. > > > Can we please then extend the design to include this? > Another approach (on Linux only) would be to have the CLI stuff the session key into the kernel keyring. It would be secure and would be capable of outliving the TGT life (if the session expiration is longer than the TGT expiration). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Mon Dec 5 14:42:03 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Dec 2011 09:42:03 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <1323095632.2194.41.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4ED6AF32.6000607@redhat.com> <4ED813CF.8040403@redhat.com> <4ED81C5C.9010307@redhat.com> <1322790534.22044.54.camel@willson.li.ssimo.org> <4EDA7348.1030500@redhat.com> <1323095632.2194.41.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <4EDCD83B.9010308@redhat.com> On 12/05/2011 09:33 AM, Stephen Gallagher wrote: > On Sat, 2011-12-03 at 14:06 -0500, Dmitri Pal wrote: >> On 12/01/2011 08:48 PM, Simo Sorce wrote: >>> On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: >>>> On 12/01/2011 06:54 PM, Dmitri Pal wrote: >>>>> Seems reasonable. I agree with pros and cons and suggestions but I am >>>>> not the person to make the final approval. Simo? >>>>> >>>>> Question for John: Is there any benefit for CLI or it is for UI only? >>>> Currently it would benefit the UI only. That's mostly because there is >>>> no mechanism in the cli to cache the session ID. Adding that wouldn't be >>>> too difficult except for the issue of how to store the session ID >>>> securely, it would have to be written to a file (unlike with a browser >>>> which is supposed to hold session cookies in memory). Is there an >>>> ability to add a data item like this to the user's kerberos credential >>>> cache? >>> Yes we could create a fake key and stick the session id in it. >>> That was the trick we proposed using when this question was raised a few >>> months ago during a conference call on the matter. >>> >>> Simo. >>> >> Can we please then extend the design to include this? >> > Another approach (on Linux only) would be to have the CLI stuff the > session key into the kernel keyring. It would be secure and would be > capable of outliving the TGT life (if the session expiration is longer > than the TGT expiration). We support CLI only on Linux so this is not an issue. But it would not work cross multiple CLI commands as they are different processes and AFAIU only the process that put the data into the keyring would be able to fetch it unless we provide a special IPA shell that keeps one process and executes batch inside it. Am I wrong? > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Mon Dec 5 14:44:32 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Mon, 05 Dec 2011 09:44:32 -0500 Subject: [Freeipa-devel] Session design document In-Reply-To: <4EDCD83B.9010308@redhat.com> References: <4ED6AF32.6000607@redhat.com> <4ED813CF.8040403@redhat.com> <4ED81C5C.9010307@redhat.com> <1322790534.22044.54.camel@willson.li.ssimo.org> <4EDA7348.1030500@redhat.com> <1323095632.2194.41.camel@sgallagh520.sgallagh.bos.redhat.com> <4EDCD83B.9010308@redhat.com> Message-ID: <1323096272.2194.42.camel@sgallagh520.sgallagh.bos.redhat.com> On Mon, 2011-12-05 at 09:42 -0500, Dmitri Pal wrote: > On 12/05/2011 09:33 AM, Stephen Gallagher wrote: > > On Sat, 2011-12-03 at 14:06 -0500, Dmitri Pal wrote: > > > On 12/01/2011 08:48 PM, Simo Sorce wrote: > > > > On Thu, 2011-12-01 at 19:31 -0500, John Dennis wrote: > > > > > On 12/01/2011 06:54 PM, Dmitri Pal wrote: > > > > > > Seems reasonable. I agree with pros and cons and suggestions but I am > > > > > > not the person to make the final approval. Simo? > > > > > > > > > > > > Question for John: Is there any benefit for CLI or it is for UI only? > > > > > Currently it would benefit the UI only. That's mostly because there is > > > > > no mechanism in the cli to cache the session ID. Adding that wouldn't be > > > > > too difficult except for the issue of how to store the session ID > > > > > securely, it would have to be written to a file (unlike with a browser > > > > > which is supposed to hold session cookies in memory). Is there an > > > > > ability to add a data item like this to the user's kerberos credential > > > > > cache? > > > > Yes we could create a fake key and stick the session id in it. > > > > That was the trick we proposed using when this question was raised a few > > > > months ago during a conference call on the matter. > > > > > > > > Simo. > > > > > > > Can we please then extend the design to include this? > > > > > Another approach (on Linux only) would be to have the CLI stuff the > > session key into the kernel keyring. It would be secure and would be > > capable of outliving the TGT life (if the session expiration is longer > > than the TGT expiration). > > > We support CLI only on Linux so this is not an issue. > But it would not work cross multiple CLI commands as they are > different processes and AFAIU only the process that put the data into > the keyring would be able to fetch it unless we provide a special IPA > shell that keeps one process and executes batch inside it. > Am I wrong? Yes, you are wrong :) The keyring can be configured to be limited to either "user" or "user and a specific process ID". We do the latter in SSSD, but that's a recent change. Previously we were restricting it only by user. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From pvoborni at redhat.com Mon Dec 5 15:37:09 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 05 Dec 2011 16:37:09 +0100 Subject: [Freeipa-devel] [PATCH] 051 Search facets show translated boolean values Message-ID: <4EDCE525.3030502@redhat.com> Created format method for getting translated messages for boolean values - IPA.boolean_column_format. Used in hosts, sudo rules, hbac rules. https://fedorahosted.org/freeipa/ticket/2027 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0051-Search-facets-show-translated-boolean-values.patch Type: text/x-patch Size: 3091 bytes Desc: not available URL: From mkosek at redhat.com Mon Dec 5 15:39:43 2011 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 05 Dec 2011 16:39:43 +0100 Subject: [Freeipa-devel] Q: dnsclient portability In-Reply-To: <4ED8ECDA.10107@redhat.com> References: <20111202125837.GC426@redhat.com> <4ED8ECDA.10107@redhat.com> Message-ID: <1323099583.7702.32.camel@balmora.brq.redhat.com> On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: > On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: > > Hi, > > > > I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 > > which concerns portability of ipapython.dnsclient module. > > > > ipapython.dnsclient module uses acutil module to perform 'res_send(3)' > > call provided by libresolv. acutil implements bindings to two system > > calls (res_send() and getusershell()) and belongs to authconfig > > package. The total size of acutil module source code is ~100 lines of > > C code. > > > > Now, authconfig package is not available beyond Fedora/RHEL > > distributions and, in particular, it is not available in > > Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on > > those platforms and a way of getting around the issue needs to be > > found. > > > > So far, there are two options: > > > > 1. Extract acutil module from authconfig and supply it with > > freeipa-python in a manner similar to default_encoding module. This is > > 'cheapest' solution in a sense we only interested in bindings to > > res_send(3). FreeIPA client code then will be self-contained and would > > not depend on authconfig availability (platform portability code > > already allows to re-implement authconfig implementation). > > > > 2. Port ipapython.dnsclient to use dnspython module if acutil is not > > available. This module, available from http://www.dnspython.org/, can > > be found in Fedora, GNU/Debian Linux, Ubuntu and many other > > distributions. It is python-only resolver providing a super-set of > > ipapython.dnsclient features. > > > > The downside of the first approach is a need to distribute and > > maintain another CPython extension. Though the code is straight > > forward and simple enough, it is still a separate maintenance burden. > > > > The downside of the second approach is to write a bridge code between > > ipapython.dnsclient API and dnspython API. They are different enough > > so that remapping of fields in objects resulting from a query is > > needed. > > > > I've started to implement the bridge code myself but it is quickly > > getting to the level of effort original ipapython.dnsclient has > > (due to API differences in attributes names) and that means it is > > probably not worth it. > > I think the second approach is better, here is my reasoning: > > * If we rebuilt acutil it would make more sense to package it an actual > package, not just another IPA CPython module, this would be more > flexible and other could use it, but ... > > * acutil seems incomplete and an odd mix of just 2 functions, probably > the minimum needed but not general (I don't know the API's so I might be > wrong on that score) > > * We really don't want to maintain YAP (Yet Another Package) > > * dnspython seems more complete, widely used, has other maintainers and > support we can leverage. (Should we have used it in the first place) > > * Since dnspython is a superset and once we get ipapython.dnsclient > ported to it maybe we'll discover we can then easily user other features > dnspython provides. > > Anyway, tough call, the right answer is not entirely obvious, just my 2 > cents. > > I like second approach more too. Although I think the best solution here would be to discard ipapython.dnsclient as is and use dnspython directly in our code. ipapython.dnsclient is not used on that many places in our code anyway. This way, we wouldn't have use our artificial dnsclient API in the proposed bridge but rather use (more standard) dnspython API and have access to all its native functionality. Martin From rcritten at redhat.com Mon Dec 5 15:43:33 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Dec 2011 10:43:33 -0500 Subject: [Freeipa-devel] [PATCH] #2160 ipa_kpasswd: Update selinux policies In-Reply-To: References: Message-ID: <4EDCE6A5.1030706@redhat.com> Evgeny Sinelnikov wrote: > The ipa_kpasswd daemon can't listen ldap on tcp and access to > /dev/urandom due to an error in the selinux policies on Fedora 16. > > Attached patch fixed it instead of "setsebool > authlogin_nsswitch_use_ldap on" using. ACK, pushed to master. I'll work on adding this to the Fedora 16 package. thanks for the patch rob From abokovoy at redhat.com Mon Dec 5 16:09:36 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Dec 2011 18:09:36 +0200 Subject: [Freeipa-devel] Q: dnsclient portability In-Reply-To: <1323099583.7702.32.camel@balmora.brq.redhat.com> References: <20111202125837.GC426@redhat.com> <4ED8ECDA.10107@redhat.com> <1323099583.7702.32.camel@balmora.brq.redhat.com> Message-ID: <20111205160935.GA24120@redhat.com> On Mon, 05 Dec 2011, Martin Kosek wrote: > On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: > > On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: > > > Hi, > > > > > > I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 > > > which concerns portability of ipapython.dnsclient module. > > > > > > ipapython.dnsclient module uses acutil module to perform 'res_send(3)' > > > call provided by libresolv. acutil implements bindings to two system > > > calls (res_send() and getusershell()) and belongs to authconfig > > > package. The total size of acutil module source code is ~100 lines of > > > C code. > > > > > > Now, authconfig package is not available beyond Fedora/RHEL > > > distributions and, in particular, it is not available in > > > Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on > > > those platforms and a way of getting around the issue needs to be > > > found. > > > > > > So far, there are two options: > > > > > > 1. Extract acutil module from authconfig and supply it with > > > freeipa-python in a manner similar to default_encoding module. This is > > > 'cheapest' solution in a sense we only interested in bindings to > > > res_send(3). FreeIPA client code then will be self-contained and would > > > not depend on authconfig availability (platform portability code > > > already allows to re-implement authconfig implementation). > > > > > > 2. Port ipapython.dnsclient to use dnspython module if acutil is not > > > available. This module, available from http://www.dnspython.org/, can > > > be found in Fedora, GNU/Debian Linux, Ubuntu and many other > > > distributions. It is python-only resolver providing a super-set of > > > ipapython.dnsclient features. > > > > > > The downside of the first approach is a need to distribute and > > > maintain another CPython extension. Though the code is straight > > > forward and simple enough, it is still a separate maintenance burden. > > > > > > The downside of the second approach is to write a bridge code between > > > ipapython.dnsclient API and dnspython API. They are different enough > > > so that remapping of fields in objects resulting from a query is > > > needed. > > > > > > I've started to implement the bridge code myself but it is quickly > > > getting to the level of effort original ipapython.dnsclient has > > > (due to API differences in attributes names) and that means it is > > > probably not worth it. > > > > I think the second approach is better, here is my reasoning: > > > > * If we rebuilt acutil it would make more sense to package it an actual > > package, not just another IPA CPython module, this would be more > > flexible and other could use it, but ... > > > > * acutil seems incomplete and an odd mix of just 2 functions, probably > > the minimum needed but not general (I don't know the API's so I might be > > wrong on that score) > > > > * We really don't want to maintain YAP (Yet Another Package) > > > > * dnspython seems more complete, widely used, has other maintainers and > > support we can leverage. (Should we have used it in the first place) > > > > * Since dnspython is a superset and once we get ipapython.dnsclient > > ported to it maybe we'll discover we can then easily user other features > > dnspython provides. > > > > Anyway, tough call, the right answer is not entirely obvious, just my 2 > > cents. > > > > > > I like second approach more too. Although I think the best solution here > would be to discard ipapython.dnsclient as is and use dnspython directly > in our code. ipapython.dnsclient is not used on that many places in our > code anyway. > > This way, we wouldn't have use our artificial dnsclient API in the > proposed bridge but rather use (more standard) dnspython API and have > access to all its native functionality. Hm. Good idea. This though will have a toll for platforms where dnspython is not yet available like various Red Hat Enterprise Linux versions... -- / Alexander Bokovoy From simo at redhat.com Mon Dec 5 16:11:57 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 Dec 2011 11:11:57 -0500 Subject: [Freeipa-devel] Q: dnsclient portability In-Reply-To: <20111205160935.GA24120@redhat.com> References: <20111202125837.GC426@redhat.com> <4ED8ECDA.10107@redhat.com> <1323099583.7702.32.camel@balmora.brq.redhat.com> <20111205160935.GA24120@redhat.com> Message-ID: <1323101517.16141.7.camel@willson.li.ssimo.org> On Mon, 2011-12-05 at 18:09 +0200, Alexander Bokovoy wrote: > On Mon, 05 Dec 2011, Martin Kosek wrote: > > On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: > > > On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: > > > > Hi, > > > > > > > > I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 > > > > which concerns portability of ipapython.dnsclient module. > > > > > > > > ipapython.dnsclient module uses acutil module to perform 'res_send(3)' > > > > call provided by libresolv. acutil implements bindings to two system > > > > calls (res_send() and getusershell()) and belongs to authconfig > > > > package. The total size of acutil module source code is ~100 lines of > > > > C code. > > > > > > > > Now, authconfig package is not available beyond Fedora/RHEL > > > > distributions and, in particular, it is not available in > > > > Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on > > > > those platforms and a way of getting around the issue needs to be > > > > found. > > > > > > > > So far, there are two options: > > > > > > > > 1. Extract acutil module from authconfig and supply it with > > > > freeipa-python in a manner similar to default_encoding module. This is > > > > 'cheapest' solution in a sense we only interested in bindings to > > > > res_send(3). FreeIPA client code then will be self-contained and would > > > > not depend on authconfig availability (platform portability code > > > > already allows to re-implement authconfig implementation). > > > > > > > > 2. Port ipapython.dnsclient to use dnspython module if acutil is not > > > > available. This module, available from http://www.dnspython.org/, can > > > > be found in Fedora, GNU/Debian Linux, Ubuntu and many other > > > > distributions. It is python-only resolver providing a super-set of > > > > ipapython.dnsclient features. > > > > > > > > The downside of the first approach is a need to distribute and > > > > maintain another CPython extension. Though the code is straight > > > > forward and simple enough, it is still a separate maintenance burden. > > > > > > > > The downside of the second approach is to write a bridge code between > > > > ipapython.dnsclient API and dnspython API. They are different enough > > > > so that remapping of fields in objects resulting from a query is > > > > needed. > > > > > > > > I've started to implement the bridge code myself but it is quickly > > > > getting to the level of effort original ipapython.dnsclient has > > > > (due to API differences in attributes names) and that means it is > > > > probably not worth it. > > > > > > I think the second approach is better, here is my reasoning: > > > > > > * If we rebuilt acutil it would make more sense to package it an actual > > > package, not just another IPA CPython module, this would be more > > > flexible and other could use it, but ... > > > > > > * acutil seems incomplete and an odd mix of just 2 functions, probably > > > the minimum needed but not general (I don't know the API's so I might be > > > wrong on that score) > > > > > > * We really don't want to maintain YAP (Yet Another Package) > > > > > > * dnspython seems more complete, widely used, has other maintainers and > > > support we can leverage. (Should we have used it in the first place) > > > > > > * Since dnspython is a superset and once we get ipapython.dnsclient > > > ported to it maybe we'll discover we can then easily user other features > > > dnspython provides. > > > > > > Anyway, tough call, the right answer is not entirely obvious, just my 2 > > > cents. > > > > > > > > > > I like second approach more too. Although I think the best solution here > > would be to discard ipapython.dnsclient as is and use dnspython directly > > in our code. ipapython.dnsclient is not used on that many places in our > > code anyway. > > > > This way, we wouldn't have use our artificial dnsclient API in the > > proposed bridge but rather use (more standard) dnspython API and have > > access to all its native functionality. > Hm. Good idea. This though will have a toll for platforms where > dnspython is not yet available like various Red Hat Enterprise Linux > versions... RHEL can ship a version that bundles dnspython, we just need a conditional on import so that we import from ipasomething.dnspython if regular dnspython is not available. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Mon Dec 5 16:14:27 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 5 Dec 2011 18:14:27 +0200 Subject: [Freeipa-devel] Q: dnsclient portability In-Reply-To: <1323101517.16141.7.camel@willson.li.ssimo.org> References: <20111202125837.GC426@redhat.com> <4ED8ECDA.10107@redhat.com> <1323099583.7702.32.camel@balmora.brq.redhat.com> <20111205160935.GA24120@redhat.com> <1323101517.16141.7.camel@willson.li.ssimo.org> Message-ID: <20111205161426.GA24343@redhat.com> On Mon, 05 Dec 2011, Simo Sorce wrote: > > > I like second approach more too. Although I think the best solution here > > > would be to discard ipapython.dnsclient as is and use dnspython directly > > > in our code. ipapython.dnsclient is not used on that many places in our > > > code anyway. > > > > > > This way, we wouldn't have use our artificial dnsclient API in the > > > proposed bridge but rather use (more standard) dnspython API and have > > > access to all its native functionality. > > Hm. Good idea. This though will have a toll for platforms where > > dnspython is not yet available like various Red Hat Enterprise Linux > > versions... > > RHEL can ship a version that bundles dnspython, we just need a > conditional on import so that we import from ipasomething.dnspython if > regular dnspython is not available. Ok. From my perspective it is also much simpler to turn around and fix usage of ipapython.dnsclient rather than mimic it on top of dnspython. -- / Alexander Bokovoy From edewata at redhat.com Mon Dec 5 16:21:57 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 10:21:57 -0600 Subject: [Freeipa-devel] [PATCH] 32-47 #2040, #1515 Refactor UI widgets In-Reply-To: <4ED91DC2.5070103@redhat.com> References: <4ED4E2B7.2020403@redhat.com> <4ED5C96E.4000707@redhat.com> <4ED65BE2.8050307@redhat.com> <4ED79723.2040809@redhat.com> <4ED7AF2F.1080303@redhat.com> <4ED91DC2.5070103@redhat.com> Message-ID: <4EDCEFA5.9040202@redhat.com> On 12/5/2011 7:41 AM, Petr Vobornik wrote: > All tests passed. ACK 32-47, 49-1, 50. Pushed to master. YAY! -- Endi S. Dewata From edewata at redhat.com Mon Dec 5 17:27:33 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 11:27:33 -0600 Subject: [Freeipa-devel] [PATCH] 051 Search facets show translated boolean values In-Reply-To: <4EDCE525.3030502@redhat.com> References: <4EDCE525.3030502@redhat.com> Message-ID: <4EDCFF05.60109@redhat.com> On 12/5/2011 9:37 AM, Petr Vobornik wrote: > Created format method for getting translated messages for boolean values > - IPA.boolean_column_format. > > Used in hosts, sudo rules, hbac rules. > > https://fedorahosted.org/freeipa/ticket/2027 The patch works, so it's ACKed. There are a few suggestions but they can be done later: 1. It might be better to name the function IPA.boolean_format because we can use it for other things too, not just inside a column. 2. The value can be normalized using toLowerCase() before comparison. 3. If the value doesn't match true/false it can return the original value instead of empty string. -- Endi S. Dewata From ayoung at redhat.com Mon Dec 5 18:25:21 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 05 Dec 2011 13:25:21 -0500 Subject: [Freeipa-devel] [PATCH] 051 Search facets show translated boolean values In-Reply-To: <4EDCFF05.60109@redhat.com> References: <4EDCE525.3030502@redhat.com> <4EDCFF05.60109@redhat.com> Message-ID: <4EDD0C91.7030909@redhat.com> On 12/05/2011 12:27 PM, Endi Sukma Dewata wrote: > On 12/5/2011 9:37 AM, Petr Vobornik wrote: >> Created format method for getting translated messages for boolean values >> - IPA.boolean_column_format. >> >> Used in hosts, sudo rules, hbac rules. >> >> https://fedorahosted.org/freeipa/ticket/2027 > > The patch works, so it's ACKed. There are a few suggestions but they > can be done later: > > 1. It might be better to name the function IPA.boolean_format because > we can use it for other things too, not just inside a column. > > 2. The value can be normalized using toLowerCase() before comparison. > > 3. If the value doesn't match true/false it can return the original > value instead of empty string. > Can we make this the default handling for boolean columns? From rcritten at redhat.com Mon Dec 5 19:49:35 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Dec 2011 14:49:35 -0500 Subject: [Freeipa-devel] Q: dnsclient portability In-Reply-To: <20111205160935.GA24120@redhat.com> References: <20111202125837.GC426@redhat.com> <4ED8ECDA.10107@redhat.com> <1323099583.7702.32.camel@balmora.brq.redhat.com> <20111205160935.GA24120@redhat.com> Message-ID: <4EDD204F.8020704@redhat.com> Alexander Bokovoy wrote: > On Mon, 05 Dec 2011, Martin Kosek wrote: >> On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote: >>> On 12/02/2011 07:58 AM, Alexander Bokovoy wrote: >>>> Hi, >>>> >>>> I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837 >>>> which concerns portability of ipapython.dnsclient module. >>>> >>>> ipapython.dnsclient module uses acutil module to perform 'res_send(3)' >>>> call provided by libresolv. acutil implements bindings to two system >>>> calls (res_send() and getusershell()) and belongs to authconfig >>>> package. The total size of acutil module source code is ~100 lines of >>>> C code. >>>> >>>> Now, authconfig package is not available beyond Fedora/RHEL >>>> distributions and, in particular, it is not available in >>>> Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on >>>> those platforms and a way of getting around the issue needs to be >>>> found. >>>> >>>> So far, there are two options: >>>> >>>> 1. Extract acutil module from authconfig and supply it with >>>> freeipa-python in a manner similar to default_encoding module. This is >>>> 'cheapest' solution in a sense we only interested in bindings to >>>> res_send(3). FreeIPA client code then will be self-contained and would >>>> not depend on authconfig availability (platform portability code >>>> already allows to re-implement authconfig implementation). >>>> >>>> 2. Port ipapython.dnsclient to use dnspython module if acutil is not >>>> available. This module, available from http://www.dnspython.org/, can >>>> be found in Fedora, GNU/Debian Linux, Ubuntu and many other >>>> distributions. It is python-only resolver providing a super-set of >>>> ipapython.dnsclient features. >>>> >>>> The downside of the first approach is a need to distribute and >>>> maintain another CPython extension. Though the code is straight >>>> forward and simple enough, it is still a separate maintenance burden. >>>> >>>> The downside of the second approach is to write a bridge code between >>>> ipapython.dnsclient API and dnspython API. They are different enough >>>> so that remapping of fields in objects resulting from a query is >>>> needed. >>>> >>>> I've started to implement the bridge code myself but it is quickly >>>> getting to the level of effort original ipapython.dnsclient has >>>> (due to API differences in attributes names) and that means it is >>>> probably not worth it. >>> >>> I think the second approach is better, here is my reasoning: >>> >>> * If we rebuilt acutil it would make more sense to package it an actual >>> package, not just another IPA CPython module, this would be more >>> flexible and other could use it, but ... >>> >>> * acutil seems incomplete and an odd mix of just 2 functions, probably >>> the minimum needed but not general (I don't know the API's so I might be >>> wrong on that score) >>> >>> * We really don't want to maintain YAP (Yet Another Package) >>> >>> * dnspython seems more complete, widely used, has other maintainers and >>> support we can leverage. (Should we have used it in the first place) >>> >>> * Since dnspython is a superset and once we get ipapython.dnsclient >>> ported to it maybe we'll discover we can then easily user other features >>> dnspython provides. >>> >>> Anyway, tough call, the right answer is not entirely obvious, just my 2 >>> cents. >>> >>> >> >> I like second approach more too. Although I think the best solution here >> would be to discard ipapython.dnsclient as is and use dnspython directly >> in our code. ipapython.dnsclient is not used on that many places in our >> code anyway. >> >> This way, we wouldn't have use our artificial dnsclient API in the >> proposed bridge but rather use (more standard) dnspython API and have >> access to all its native functionality. > Hm. Good idea. This though will have a toll for platforms where > dnspython is not yet available like various Red Hat Enterprise Linux > versions... > I think this is why we stuck with acutil. rob From dpal at redhat.com Mon Dec 5 23:01:17 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 05 Dec 2011 18:01:17 -0500 Subject: [Freeipa-devel] What is the status of the patches/tickets? Message-ID: <4EDD4D3D.8080907@redhat.com> Hi These have patches on the list: https://fedorahosted.org/freeipa/ticket/1496 https://fedorahosted.org/freeipa/ticket/1827 These tickets depend on external work: https://fedorahosted.org/freeipa/ticket/2103 https://fedorahosted.org/freeipa/ticket/2117 -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Mon Dec 5 23:09:26 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 05 Dec 2011 18:09:26 -0500 Subject: [Freeipa-devel] What is the status of the patches/tickets? In-Reply-To: <4EDD4D3D.8080907@redhat.com> References: <4EDD4D3D.8080907@redhat.com> Message-ID: <4EDD4F26.2030200@redhat.com> Dmitri Pal wrote: > Hi > > These have patches on the list: > https://fedorahosted.org/freeipa/ticket/1496 NACKd on 12/2 > https://fedorahosted.org/freeipa/ticket/1827 Needs a rebase and I had a question/suggestion. I did the reviews Friday afternoon after Alexander's day had ended. He'll take a look when he gets back on Wed. > These tickets depend on external work: > https://fedorahosted.org/freeipa/ticket/2103 In updates-testing now awaiting feedback and karma. > https://fedorahosted.org/freeipa/ticket/2117 This handles some of the dogtag upgrade issues but not specifically the profile problem I outlined. rob From simo at redhat.com Mon Dec 5 23:20:39 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 Dec 2011 18:20:39 -0500 Subject: [Freeipa-devel] [PATCH] minor cleanup Message-ID: <1323127239.16141.28.camel@willson.li.ssimo.org> Straightforward cleanup. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-471-ipa-kdb-return-properly-when-no-PAC-is-available.patch Type: text/x-patch Size: 1123 bytes Desc: not available URL: From simo at redhat.com Mon Dec 5 23:37:53 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 05 Dec 2011 18:37:53 -0500 Subject: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA In-Reply-To: <1322838624.6745.21.camel@willson.li.ssimo.org> References: <1322797917.22044.108.camel@willson.li.ssimo.org> <4ED8E046.2020603@redhat.com> <1322838624.6745.21.camel@willson.li.ssimo.org> Message-ID: <1323128273.16141.32.camel@willson.li.ssimo.org> On Fri, 2011-12-02 at 10:10 -0500, Simo Sorce wrote: > On Fri, 2011-12-02 at 09:27 -0500, Rob Crittenden wrote: > > Simo Sorce wrote: > > > Hello all, > > > > > > with this set of patches it is possible to allow constrained delegation > > > of credentials so that a service can impersonate a user when > > [..] > > > In the third patch in ipadb_get_delegation_acl() you can just fall > > through to the return. > > Removed useless check. > I also noticed I had added the prototype declaration for the new vtable > function in the 2nd patch instead of the 3rd where it belongs by > mistake. > > So I fixed that too. > > > I think the content of this e-mail should be added as a README to the > > source tree. > > Ok, I dumped and adapted the email content into a README file and added > it to the third patch. > > I also fixed the patch names as per policy. > > Simo. We have discovered a few issues w/ MIT 1.9 and s4u2proxy used outside of the 'artificial' test done by kvno. I pushed a patch to handle part of the problem as a new krb5 package in ipa-devel. Soon we will have a patch for mod_auth_kerb that handles an issue there. But we still have an unresolved issue when using the adtrust functionality and our KDC releases PACs. The attached patch can be used to deal with that case. As you can see this is not intended for production, but can be used until we have a better fix on the KDC side. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ipa-kdb-temporary-workaround-for-s4u2proxy-ops.patch Type: text/x-patch Size: 1142 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:38:39 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:38:39 -0600 Subject: [Freeipa-devel] [PATCH] 315 Added commands into metadata. In-Reply-To: <4EC6A385.4050605@redhat.com> References: <4EC5602E.3030004@redhat.com> <4EC63A3E.5080200@redhat.com> <4EC67B6E.2070409@redhat.com> <4EC6A385.4050605@redhat.com> Message-ID: <4EDDAA5F.4060903@redhat.com> On 11/18/2011 12:27 PM, Endi Sukma Dewata wrote: >> Now the methods metadata seem to be a subset of commands metadata, so we >> probably can change the UI to use commands metadata and not pull the >> methods metadata. > > I did this change in the updated patch. It seems to be working fine. > >> In the JSON API itself the parameters are specified as options, so the >> order shouldn't matter to the UI. Is there a way to define the execute() >> using unordered keywords? I'm trying to avoid changing the method >> signature again in the future. > > I replaced takes_args with takes_options which takes care the ordering > problem. I verified the old UI way of calling json_metadata still works. Updated patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0315-3-Added-commands-into-metadata.patch Type: text/x-patch Size: 465218 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:39:21 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:39:21 -0600 Subject: [Freeipa-devel] [PATCH] 316 Added support for radio buttons in table widget. In-Reply-To: <4ECA95EE.7080205@redhat.com> References: <4ECA95EE.7080205@redhat.com> Message-ID: <4EDDAA89.5010509@redhat.com> On 11/21/2011 12:18 PM, Endi Sukma Dewata wrote: > The table widget has been modified to support single-valued attribute > using radio buttons needed by some facets in HBAC Test. The widget now > uses 'pagination' flag to determine whether to show the pagination > control. The test data has also been updated. > > Ticket #388 Updated patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0316-2-Added-support-for-radio-buttons-in-table-widget.patch Type: text/x-patch Size: 28340 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:39:51 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:39:51 -0600 Subject: [Freeipa-devel] [PATCH] 317 Fixed entity metadata resolution. In-Reply-To: <4ECA972D.7030904@redhat.com> References: <4ECA972D.7030904@redhat.com> Message-ID: <4EDDAAA7.3070605@redhat.com> On 11/21/2011 12:23 PM, Endi Sukma Dewata wrote: > The current code assumes that an entity will always have a corresponding > LDAPObject on the server, so it looks for the metadata in a fixed > location. This assumption doesn't work for HBAC Test since it is a > Command, not an LDAPObject, so the metadata has to be obtained from a > different location. A new method get_default_metadata() has been added > to allow each entity to find the metadata from the correct location. > > Ticket #388 Updated patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0317-2-Fixed-entity-metadata-resolution.patch Type: text/x-patch Size: 22166 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:40:21 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:40:21 -0600 Subject: [Freeipa-devel] [PATCH] 318 Refactored facet.load(). In-Reply-To: <4ECA989E.8050300@redhat.com> References: <4ECA989E.8050300@redhat.com> Message-ID: <4EDDAAC5.7090700@redhat.com> On 11/21/2011 12:29 PM, Endi Sukma Dewata wrote: > The load() in IPA.facet has been modified to accept the complete > data returned by the server instead of just the result. This is > needed by HBAC Test to access other attributes returned in the > test result. > > Ticket #388 Updated patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0318-2-Refactored-facet.load.patch Type: text/x-patch Size: 54666 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:41:02 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:41:02 -0600 Subject: [Freeipa-devel] [PATCH] 319 Added HBAC Test page. In-Reply-To: <4ECA9AAD.6070502@redhat.com> References: <4ECA9AAD.6070502@redhat.com> Message-ID: <4EDDAAEE.7070809@redhat.com> On 11/21/2011 12:38 PM, Endi Sukma Dewata wrote: > This is the initial implementation of HBAC Test page. Currently it > can select user, source/target group, service, rules, and execute > the test. Other functionalities to be implemented include the search > filter, external users/hosts, back/next buttons, validation, styling, > and internalization. > > Ticket #388 Updated patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0319-2-Added-HBAC-Test-page.patch Type: text/x-patch Size: 35384 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:41:49 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:41:49 -0600 Subject: [Freeipa-devel] [PATCH] 320 Fixed navigation buttons for HBAC Test. In-Reply-To: <4ECAFB7E.1090805@redhat.com> References: <4ECAFB7E.1090805@redhat.com> Message-ID: <4EDDAB1D.7060703@redhat.com> On 11/21/2011 7:31 PM, Endi Sukma Dewata wrote: > The Back, Next, and New Test buttons in HBAC Test have been fixed > to work properly. > > Ticket #388 Updated patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0320-2-Fixed-navigation-buttons-for-HBAC-Test.patch Type: text/x-patch Size: 9331 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:42:32 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:42:32 -0600 Subject: [Freeipa-devel] [PATCH] 321 Fixed search filter in HBAC Test. In-Reply-To: <4ECAFBFF.1000305@redhat.com> References: <4ECAFBFF.1000305@redhat.com> Message-ID: <4EDDAB48.3090403@redhat.com> On 11/21/2011 7:33 PM, Endi Sukma Dewata wrote: > The search filter in HBAC Test has been fixed to work properly. > > Ticket #388 Updated patch attached. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0321-2-Fixed-search-filter-in-HBAC-Test.patch Type: text/x-patch Size: 1422 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 6 05:47:47 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 05 Dec 2011 23:47:47 -0600 Subject: [Freeipa-devel] [PATCH] 322 Added external fields for HBAC Test. Message-ID: <4EDDAC83.9050301@redhat.com> A text field has been added for specifying external user, host, and service for HBAC testing. Ticket #388 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0322-Added-external-fields-for-HBAC-Test.patch Type: text/x-patch Size: 4154 bytes Desc: not available URL: From simo at redhat.com Tue Dec 6 13:31:27 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 06 Dec 2011 08:31:27 -0500 Subject: [Freeipa-devel] [PATCH] Make pwd-extop aware of new ipaNTHash attribute In-Reply-To: <20111205094011.GA27139@redhat.com> References: <20111128172840.GF2246@localhost.localdomain> <20111205094011.GA27139@redhat.com> Message-ID: <1323178287.16141.38.camel@willson.li.ssimo.org> On Mon, 2011-12-05 at 11:40 +0200, Alexander Bokovoy wrote: > On Mon, 28 Nov 2011, Sumit Bose wrote: > > Hi, > > > > in IPAv3 we introduce a new attribute 'ipaNTHash' to store the NT hash. > > Currently the plugin handling the change password extended operation > > only sets and updates 'sambaNTPassword'. This patch add support for the > > new attribute without removing the support for the old one. > ACK > > One possible enhancement I would make is to get attribute names as > constant defines and re-use them across the code. Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Dec 6 13:32:19 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 06 Dec 2011 08:32:19 -0500 Subject: [Freeipa-devel] [PATCH] Add ipasam samba passdb backend In-Reply-To: <20111205094229.GA27978@redhat.com> References: <20111123154802.GI2205@localhost.localdomain> <20111128172227.GE2246@localhost.localdomain> <20111129210926.GK2246@localhost.localdomain> <20111129212541.GA24514@redhat.com> <20111130091134.GA2348@localhost.localdomain> <1322648533.2924.1.camel@balmora.brq.redhat.com> <20111205094229.GA27978@redhat.com> Message-ID: <1323178339.16141.39.camel@willson.li.ssimo.org> On Mon, 2011-12-05 at 11:42 +0200, Alexander Bokovoy wrote: > On Wed, 30 Nov 2011, Martin Kosek wrote: > > On Wed, 2011-11-30 at 10:11 +0100, Sumit Bose wrote: > > > On Tue, Nov 29, 2011 at 11:25:41PM +0200, Alexander Bokovoy wrote: > > > > On Tue, 29 Nov 2011, Sumit Bose wrote: > > > > > @@ -199,10 +216,11 @@ class ADTRUSTInstance(service.Service): > > > > > self.admin_conn.addEntry(entry) > > > > > > > > > > entry = ipaldap.Entry(self.smb_dom_dn) > > > > > - entry.setValues("objectclass", ["sambaDomain", "nsContainer"]) > > > > > + entry.setValues("objectclass", [self.OBJC_DOMAIN, "nsContainer"]) > > > > > entry.setValues("cn", self.domain_name) > > > > > - entry.setValues("sambaDomainName", self.netbios_name) > > > > > - entry.setValues("sambaSID", self.__gen_sid_string()) > > > > > + entry.setValues(self.ATTR_FLAT_NAME, self.netbios_name) > > > > > + entry.setValues(self.ATTR_SID, self.__gen_sid_string()) > > > > > + entry.setValues(self.ATTR_GUID, str(uuid.uuid4())) > > > > > #TODO: which MAY attributes do we want to set ? > > > > > self.admin_conn.add_s(entry) > > > > Could you please also convert this one to .addEntry(entry)? > > > > I think it is the last one left... > > > > > > This is fixed in freeipa-sbose-0012-3-Fix-some-pylint-warnings.patch. > > > > > > Martin, shall I extract the add_s->addEntry changes into a separate > > > patch so the they can reviewed indepently of the 6 ipasam patches? > > > > > > bye, > > > Sumit > > > > > > > I think it is OK to review (and push) them in a scope of your patch > > 0012-3, we don't have to divide them. > Yes. ACK then. Pushed all to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Dec 6 13:54:28 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 06 Dec 2011 08:54:28 -0500 Subject: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA In-Reply-To: <1323128273.16141.32.camel@willson.li.ssimo.org> References: <1322797917.22044.108.camel@willson.li.ssimo.org> <4ED8E046.2020603@redhat.com> <1322838624.6745.21.camel@willson.li.ssimo.org> <1323128273.16141.32.camel@willson.li.ssimo.org> Message-ID: <1323179668.16141.42.camel@willson.li.ssimo.org> On Mon, 2011-12-05 at 18:37 -0500, Simo Sorce wrote: > On Fri, 2011-12-02 at 10:10 -0500, Simo Sorce wrote: > > On Fri, 2011-12-02 at 09:27 -0500, Rob Crittenden wrote: > > > Simo Sorce wrote: > > > > Hello all, > > > > > > > > with this set of patches it is possible to allow constrained delegation > > > > of credentials so that a service can impersonate a user when > > > > [..] > > > > > In the third patch in ipadb_get_delegation_acl() you can just fall > > > through to the return. > > > > Removed useless check. > > I also noticed I had added the prototype declaration for the new vtable > > function in the 2nd patch instead of the 3rd where it belongs by > > mistake. > > > > So I fixed that too. > > > > > I think the content of this e-mail should be added as a README to the > > > source tree. > > > > Ok, I dumped and adapted the email content into a README file and added > > it to the third patch. > > > > I also fixed the patch names as per policy. > > > > Simo. > > > We have discovered a few issues w/ MIT 1.9 and s4u2proxy used outside of > the 'artificial' test done by kvno. > > I pushed a patch to handle part of the problem as a new krb5 package in > ipa-devel. > > Soon we will have a patch for mod_auth_kerb that handles an issue there. > > But we still have an unresolved issue when using the adtrust > functionality and our KDC releases PACs. > > The attached patch can be used to deal with that case. As you can see > this is not intended for production, but can be used until we have a > better fix on the KDC side. > > Simo. Rebased patch 468 to apply to current master. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-468-2-ipa-kdb-Delegation-ACL-schema.patch Type: text/x-patch Size: 3271 bytes Desc: not available URL: From pvoborni at redhat.com Tue Dec 6 14:27:23 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 15:27:23 +0100 Subject: [Freeipa-devel] [PATCH] 315 Added commands into metadata. In-Reply-To: <4EDDAA5F.4060903@redhat.com> References: <4EC5602E.3030004@redhat.com> <4EC63A3E.5080200@redhat.com> <4EC67B6E.2070409@redhat.com> <4EC6A385.4050605@redhat.com> <4EDDAA5F.4060903@redhat.com> Message-ID: <4EDE264B.8080809@redhat.com> On 12/06/2011 06:38 AM, Endi Sukma Dewata wrote: > On 11/18/2011 12:27 PM, Endi Sukma Dewata wrote: >>> Now the methods metadata seem to be a subset of commands metadata, so we >>> probably can change the UI to use commands metadata and not pull the >>> methods metadata. >> >> I did this change in the updated patch. It seems to be working fine. >> >>> In the JSON API itself the parameters are specified as options, so the >>> order shouldn't matter to the UI. Is there a way to define the execute() >>> using unordered keywords? I'm trying to avoid changing the method >>> signature again in the future. >> >> I replaced takes_args with takes_options which takes care the ordering >> problem. I verified the old UI way of calling json_metadata still works. > > Updated patch attached. Web UI - ACK. Server side - seems fine - I would give it an ACK, but I'm not sure if I'm the right person for it. -- Petr Vobornik From pvoborni at redhat.com Tue Dec 6 14:28:32 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 15:28:32 +0100 Subject: [Freeipa-devel] [PATCH] 316 Added support for radio buttons in table widget. In-Reply-To: <4EDDAA89.5010509@redhat.com> References: <4ECA95EE.7080205@redhat.com> <4EDDAA89.5010509@redhat.com> Message-ID: <4EDE2690.2090009@redhat.com> On 12/06/2011 06:39 AM, Endi Sukma Dewata wrote: > On 11/21/2011 12:18 PM, Endi Sukma Dewata wrote: >> The table widget has been modified to support single-valued attribute >> using radio buttons needed by some facets in HBAC Test. The widget now >> uses 'pagination' flag to determine whether to show the pagination >> control. The test data has also been updated. >> >> Ticket #388 > > Updated patch attached. > ACK -- Petr Vobornik From pvoborni at redhat.com Tue Dec 6 14:29:15 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 15:29:15 +0100 Subject: [Freeipa-devel] [PATCH] 317 Fixed entity metadata resolution. In-Reply-To: <4EDDAAA7.3070605@redhat.com> References: <4ECA972D.7030904@redhat.com> <4EDDAAA7.3070605@redhat.com> Message-ID: <4EDE26BB.6010100@redhat.com> On 12/06/2011 06:39 AM, Endi Sukma Dewata wrote: > On 11/21/2011 12:23 PM, Endi Sukma Dewata wrote: >> The current code assumes that an entity will always have a corresponding >> LDAPObject on the server, so it looks for the metadata in a fixed >> location. This assumption doesn't work for HBAC Test since it is a >> Command, not an LDAPObject, so the metadata has to be obtained from a >> different location. A new method get_default_metadata() has been added >> to allow each entity to find the metadata from the correct location. >> >> Ticket #388 > > Updated patch attached. ACK -- Petr Vobornik From pvoborni at redhat.com Tue Dec 6 14:52:40 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 15:52:40 +0100 Subject: [Freeipa-devel] [PATCH] 318 Refactored facet.load(). In-Reply-To: <4EDDAAC5.7090700@redhat.com> References: <4ECA989E.8050300@redhat.com> <4EDDAAC5.7090700@redhat.com> Message-ID: <4EDE2C38.9010700@redhat.com> On 12/06/2011 06:40 AM, Endi Sukma Dewata wrote: > On 11/21/2011 12:29 PM, Endi Sukma Dewata wrote: >> The load() in IPA.facet has been modified to accept the complete >> data returned by the server instead of just the result. This is >> needed by HBAC Test to access other attributes returned in the >> test result. >> >> Ticket #388 > > Updated patch attached. > ACK -- Petr Vobornik From pvoborni at redhat.com Tue Dec 6 15:06:39 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 16:06:39 +0100 Subject: [Freeipa-devel] [PATCH] 319 Added HBAC Test page. In-Reply-To: <4EDDAAEE.7070809@redhat.com> References: <4ECA9AAD.6070502@redhat.com> <4EDDAAEE.7070809@redhat.com> Message-ID: <4EDE2F7F.4040502@redhat.com> On 12/06/2011 06:41 AM, Endi Sukma Dewata wrote: > On 11/21/2011 12:38 PM, Endi Sukma Dewata wrote: >> This is the initial implementation of HBAC Test page. Currently it >> can select user, source/target group, service, rules, and execute >> the test. Other functionalities to be implemented include the search >> filter, external users/hosts, back/next buttons, validation, styling, >> and internalization. >> >> Ticket #388 > > Updated patch attached. > ACK In tables are 3 boolean columns which are not translated. I'll wait with pushing my patch #51 and I'll add them there along with some issues you mentioned in that patch' review. -- Petr Vobornik From pvoborni at redhat.com Tue Dec 6 15:16:08 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 16:16:08 +0100 Subject: [Freeipa-devel] [PATCH] 320 Fixed navigation buttons for HBAC Test. In-Reply-To: <4EDDAB1D.7060703@redhat.com> References: <4ECAFB7E.1090805@redhat.com> <4EDDAB1D.7060703@redhat.com> Message-ID: <4EDE31B8.8000809@redhat.com> On 12/06/2011 06:41 AM, Endi Sukma Dewata wrote: > On 11/21/2011 7:31 PM, Endi Sukma Dewata wrote: >> The Back, Next, and New Test buttons in HBAC Test have been fixed >> to work properly. >> >> Ticket #388 > > Updated patch attached. > NACK CSS issues: 1) 'Collapse all' link in details facet is no longer aligned right. 2) Find button in association adder dialog has wrong size. 3) '>>' and '<<' buttons in association adder dialog cannot be clicked - in Chrome. In Firefox they work. Other: 4) get_key_index method is defined twice in jQuery.ordered_map. -- Petr Vobornik From pvoborni at redhat.com Tue Dec 6 15:19:23 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 16:19:23 +0100 Subject: [Freeipa-devel] [PATCH] 321 Fixed search filter in HBAC Test. In-Reply-To: <4EDDAB48.3090403@redhat.com> References: <4ECAFBFF.1000305@redhat.com> <4EDDAB48.3090403@redhat.com> Message-ID: <4EDE327B.9010705@redhat.com> On 12/06/2011 06:42 AM, Endi Sukma Dewata wrote: > On 11/21/2011 7:33 PM, Endi Sukma Dewata wrote: >> The search filter in HBAC Test has been fixed to work properly. >> >> Ticket #388 > > Updated patch attached. > ACK -- Petr Vobornik From rcritten at redhat.com Tue Dec 6 16:30:20 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 11:30:20 -0500 Subject: [Freeipa-devel] [PATCH] 315 Added commands into metadata. In-Reply-To: <4EDE264B.8080809@redhat.com> References: <4EC5602E.3030004@redhat.com> <4EC63A3E.5080200@redhat.com> <4EC67B6E.2070409@redhat.com> <4EC6A385.4050605@redhat.com> <4EDDAA5F.4060903@redhat.com> <4EDE264B.8080809@redhat.com> Message-ID: <4EDE431C.7090000@redhat.com> Petr Vobornik wrote: > On 12/06/2011 06:38 AM, Endi Sukma Dewata wrote: >> On 11/18/2011 12:27 PM, Endi Sukma Dewata wrote: >>>> Now the methods metadata seem to be a subset of commands metadata, >>>> so we >>>> probably can change the UI to use commands metadata and not pull the >>>> methods metadata. >>> >>> I did this change in the updated patch. It seems to be working fine. >>> >>>> In the JSON API itself the parameters are specified as options, so the >>>> order shouldn't matter to the UI. Is there a way to define the >>>> execute() >>>> using unordered keywords? I'm trying to avoid changing the method >>>> signature again in the future. >>> >>> I replaced takes_args with takes_options which takes care the ordering >>> problem. I verified the old UI way of calling json_metadata still works. >> >> Updated patch attached. > > Web UI - ACK. > Server side - seems fine - I would give it an ACK, but I'm not sure if > I'm the right person for it. > > I think this is too radical a change. We can only bump the minor version in this release so while the api can be modified it still needs to be backwards compatible. rob From pvoborni at redhat.com Tue Dec 6 17:24:30 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 06 Dec 2011 18:24:30 +0100 Subject: [Freeipa-devel] [PATCH] 322 Added external fields for HBAC Test. In-Reply-To: <4EDDAC83.9050301@redhat.com> References: <4EDDAC83.9050301@redhat.com> Message-ID: <4EDE4FCE.9040509@redhat.com> On 12/06/2011 06:47 AM, Endi Sukma Dewata wrote: > A text field has been added for specifying external user, host, and > service for HBAC testing. > > Ticket #388 > 1) An exception occurs right after showing HBAC test page - user facet: hbactest.js:364: if (that.selected_values[0] === '__external__') { that.selected_values is undefined. 2) An exception occurs when you freshly open UI, go right for hbac test, from user facet you skip to run test and click on "new test". It's because other facets are not created, so when calling reset that.external_radio is undefined. -- Petr Vobornik From rcritten at redhat.com Tue Dec 6 19:03:55 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 14:03:55 -0500 Subject: [Freeipa-devel] [PATCH] 910 fix memberof for privileges Message-ID: <4EDE671B.90708@redhat.com> Some privileges were being created after the permissions that were pointing to it causing the memberof to not be generated. This patch reorders things for new installs and creates a PBAC memberof task that will correct an upgrade. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-910-memberof.patch Type: text/x-patch Size: 6844 bytes Desc: not available URL: From rcritten at redhat.com Tue Dec 6 19:26:19 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 14:26:19 -0500 Subject: [Freeipa-devel] Announcing FreeIPA 2.1.4 Message-ID: <4EDE6C5B.6070808@redhat.com> The FreeIPA team is proud to announce version 2.1.4. It can be downloaded from http://www.freeipa.org/Downloads and should appear in the Fedora 15 and 16 updates-testing soon (still waiting for bohdi to push the builds). A rawhide (F-17) build is also available. == Highlights in 2.1.4 == This is a security release, users are strongly advised to upgrade. Specifically, it addresses CVE-2011-3636. A Cross-Site Request Forgery (CSRF) flaw was found in FreeIPA due to a lack of checking the Referer Header in the server (it is not set in the CLI utilities). If a remote attacker could trick a user, who was logged into the FreeIPA management interface, into visiting a specially-crafted URL, the attacker could perform FreeIPA configuration changes with the privileges of the logged in user. Some bugs have been addressed too, the highlights are: * Certificates in the UI are now displayed in PEM format * systemd support in Fedora 16 * Change the way the Kerberos random salt is calculated to improve interoperability with Windows * Fix nis netgroups, users and groups were not appearing * Better handling of Kerberos realm to domain mapping == Upgrading == === Server === To upgrade a 2.0.0, 2.0.1 or 2.1.0 server do the following: # yum update freeipa-server --enablerepo=updates-testing This will pull in updated freeIPA, 389-ds, dogtag, libcurl and xmlrpc-c packages (and perhaps some others). A script will be executed in the rpm postinstall phase to update the IPA LDAP server with any required changes. There is a bug reported against 389-ds, https://bugzilla.redhat.com/show_bug.cgi?id=730387, related to read-write locks. The NSPR RW lock implementation does not safely allow re-entrant use of reader locks. This is a timing issue so it is difficult to predict. During testing one user experienced this and the upgrade hung. To break the hang kill the ns-slapd process for your realm, wait for the yum transaction to complete, then restart 389-ds and manually run the update process: # service dirsrv start # ipa-ldap-updater --update === Client === The ipa-client-install tool in the ipa-client package is just a configuration tool. There should be no need to re-run this on every client already enrolled. == Detailed Changelog for 2.1.3 == Alexander Bokovoy (4): * hbactest fails while you have svcgroup in hbacrule * Add support for systemd environments and use it to support Fedora 16 * Spin for connection success also when socket is not (yet) available * Quote multiple workers option Endi S. Dewata (1): * Added current password field. Evgeny Sinelnikov (1): * ipa_kpasswd: Update selinux policies for ldap and urandom John Dennis (1): * Unable to Download Certificate with Browser Martin Kosek (8): * Fix client krb5 domain mapping and DNS * Fix ipa-managed-entries password option long form * Fix ipa-server-install answer cache * Fix ipa-replica-conncheck port labels * Fix ipa-managed-entries bind procedure * Let PublicError accept Gettext objects * Enable automember for upgraded servers * Make ipa-server-install clean after itself Ondrej Hamada (1): * Client install root privileges check Rob Crittenden (4): * Fix problems in help system * Fix nis netgroup config entry so users appear in netgroup triple. * Don't allow default objectclass list to be empty. * Require an HTTP Referer header in the server. Send one in ipa tools. (CVE-2011-3636) Simo Sorce (1): * Modify random salt creation for interoperability From rcritten at redhat.com Tue Dec 6 20:36:46 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 15:36:46 -0500 Subject: [Freeipa-devel] [PATCH] pushed one-liner Message-ID: <4EDE7CDE.7050609@redhat.com> I noticed an extraneous trailing quote on nis.uldif, I pushed the fix as a one-liner. diff --git a/install/share/nis.uldif b/install/share/nis.uldif index 7567b5a..6ff575f 100644 --- a/install/share/nis.uldif +++ b/install/share/nis.uldif @@ -68,5 +68,5 @@ default:nis-map: netgroup default:nis-base: cn=ng, cn=alt, $SUFFIX default:nis-filter: (objectClass=ipanisNetgroup) default:nis-key-format: %{cn} -default:nis-value-format:%merge(" ","%{memberNisNetgroup}","(%link(\"%ifeq(\\\"hostCategory\\\",\\\"all\\\",\\\"\\\",\\\"%collect(\\\\\\\"%{externalHost}\\\\\\\",\\\\\\\"%deref(\\\\\\\\\\\\\\\"memberHost\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"memberHost\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\\")\\\\\\\")\\\")\",\"-\",\",\",\"%ifeq(\\\"userCategory\\\",\\\"all\\\",\\\"\\\",\\\"%collect(\\\\\\\"%deref(\\\\\\\\\\\\\\\"memberUser\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"memberUser\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\\")\\\\\\\")\\\")\",\"-\"),%{nisDomainName:-})")' +default:nis-value-format:%merge(" ","%{memberNisNetgroup}","(%link(\"%ifeq(\\\"hostCategory\\\",\\\"all\\\",\\\"\\\",\\\"%collect(\\\\\\\"%{externalHost}\\\\\\\",\\\\\\\"%deref(\\\\\\\\\\\\\\\"memberHost\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"memberHost\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"fqdn\\\\\\\\\\\\\\\")\\\\\\\")\\\")\",\"-\",\",\",\"%ifeq(\\\"userCategory\\\",\\\"all\\\",\\\"\\\",\\\"%collect(\\\\\\\"%deref(\\\\\\\\\\\\\\\"memberUser\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\\")\\\\\\\",\\\\\\\"%deref_r(\\\\\\\\\\\\\\\"memberUser\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"member\\\\\\\\\\\\\\\",\\\\\\\\\\\\\\\"uid\\\\\\\\\\\\\\\")\\\\\\\")\\\")\",\"-\"),%{nisDomainName:-})") default:nis-secure: no -- From rcritten at redhat.com Tue Dec 6 20:37:40 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 15:37:40 -0500 Subject: [Freeipa-devel] [PATCH] 908 make some fields required In-Reply-To: <4ED9552C.6050508@redhat.com> References: <4ED3CE6A.9000804@redhat.com> <4ED410C2.7000905@redhat.com> <4ED9552C.6050508@redhat.com> Message-ID: <4EDE7D14.6090101@redhat.com> Rob Crittenden wrote: > Endi Sukma Dewata wrote: >> On 11/28/2011 12:09 PM, Rob Crittenden wrote: >>> Some attributes in the framework were not marked as required even though >>> they are in the schema. These are typically computed values and I think >>> the intention was to not prompt for them. This has the side-effect of >>> them showing as not required in the UI even though they are. >>> >>> Since they all have default values set they won't be prompted for on the >>> CLI so there won't be any practical changes. >> >> This patch fixes the problem with required attributes in DNS Zones and >> cn, uidNumber, and gidNumber in Users. The UI now shows the required >> indicators for these attributes. So this patch is ACKed. >> >> Some problems mentioned in ticket #2015 are still present: >> >> 1. Removing the homeDirectory from a user fails because it's required by >> posixAccount. >> >> 2. Removing the gidNumber from a group fails because it's required by >> posixGroup. >> >> 3. Removing config attributes listed in the ticket generates internal >> error. I think at least the server should return a proper error message. >> The required indicator can be hard-coded in the UI if necessary. >> > > I know you acked this already but I went ahead and addressed #1 and #2 > and updated the patch. > > For #3 I filed a new ticket, https://fedorahosted.org/freeipa/ticket/2159 > > rob ACKed by Endi in IRC, pushed to master. rob From rcritten at redhat.com Tue Dec 6 21:01:42 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 16:01:42 -0500 Subject: [Freeipa-devel] [PATCH] ipa-client-install with --no-sssd option should check for nss_ldap In-Reply-To: <4EDCAC5A.1090703@redhat.com> References: <4EBD294A.20200@redhat.com> <4EC13FD2.9000203@redhat.com> <4ED54F98.4070700@redhat.com> <4ED78808.1000801@redhat.com> <4ED8EBCB.6030801@redhat.com> <4EDCAC5A.1090703@redhat.com> Message-ID: <4EDE82B6.508@redhat.com> Ondrej Hamada wrote: > On 12/02/2011 04:16 PM, Rob Crittenden wrote: >> Ondrej Hamada wrote: >>> On 11/29/2011 10:33 PM, Rob Crittenden wrote: >>>> Ondrej Hamada wrote: >>>>> On 11/11/2011 02:55 PM, Ondrej Hamada wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/2063 >>>>>> >>>>>> In order to check presence of nss_ldap when installing client with >>>>>> '--no-sssd' option there was added code into ipa-client-install. >>>>>> Check >>>>>> is base on existence of nss_ldap configuration files. This >>>>>> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>>>>> '/etc/libnss_ldap.conf'. Presence of any of these files is considered >>>>>> as success otherwise failure. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Freeipa-devel mailing list >>>>>> Freeipa-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>>>> I've rewritten it. Additionally it checks for existence of >>>>> nss-pam-ldapd >>>>> and makes the results reusable by configure_{ldap|nslcd}_conf() >>>>> functions. >>>>> >>>>> https://fedorahosted.org/freeipa/ticket/2063 >>>>> >>>>> In order to check presence of nss_ldap or nss-pam-ldapd when >>>>> installing >>>>> client >>>>> with '--no-sssd' option there was added code into ipa-client-install. >>>>> Checking is based on existence of nss_ldap configuration files. This >>>>> configuration could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>>>> '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could cooperate with >>>>> pam_ldap >>>>> module and hence the presence of it is checked by looking for >>>>> 'pam_ldap.conf' file. >>>>> Existence of nss-pam-ldapd is checked against existence of >>>>> 'nslcd.conf' >>>>> file. >>>>> All this checking is done by function nssldap_exists(). >>>>> Because both main modules are maintained by two different >>>>> functions, the >>>>> function >>>>> returns tuple containing return code and dictionary structure - its >>>>> key >>>>> is name >>>>> of target function and value is list of existing configuration files. >>>>> Files to check are specified inside the nssldap_exists() function. >>>>> >>>>> In order to fit the returned values, the functions >>>>> configure_{ldap|nslcd}_conf() >>>>> were slightly modified. They accept one more parameter which is >>>>> list of >>>>> existing files. >>>>> They are not checking existence of above mentioned files anymore. >>>> >>>> The patch looks good, just a couple of issues. >>>> >>>> 1. In the nslcd configurator you add ''.join(files). Did you mean >>>> ','.join(files)? >>>> >>>> 2. The commit message lines wrap making it difficult to read. Can you >>>> limit the lines to ~70 chars per line? >>>> >>>> 3. I think the message printed when neither package is available can >>>> be simplified to: >>>> >>>> One of these packages must be installed: nss_ldap or nss-pam-ldapd >>>> >>>> It needs a rebase too. >>>> >>>> rob >>> corrected, corrected, changed, rebased >>> >>> >>> >>> In order to check presence of nss_ldap or nss-pam-ldapd when >>> installing client with '--no-sssd' option there was added >>> code intoipa-client-install. Checking is based on existence >>> of one of nss_ldap configuration files. This configuration >>> could be in 'etc/ldap.conf', '/etc/nss_ldap.conf' or >>> '/etc/libnss_ldap.conf'. Optionaly the nss_ldap could >>> cooperate with pam_ldap module and hence the presence of it >>> is checked by looking for 'pam_ldap.conf' file. Existence >>> of nss-pam-ldapd is checked against existence of >>> 'nslcd.conf' file. All this checking is done by function >>> nssldap_exists(). Because both modules are maintained by >>> two different functions, the function returns tuple >>> containing return code and dictionary structure - its >>> key is name of target function and value is list of >>> existing configuration files. Files to check are specified >>> inside the nssldap_exists() function. >>> >>> In order to fit the returned values, the functions >>> configure_{ldap|nslcd}_conf() were slightly modified. They >>> accept one more parameter which is list of existing files. >>> They are not checking existence of above mentioned >>> files anymore. >>> >>> https://fedorahosted.org/freeipa/ticket/2063 >>> >> >> Can you add a block header to nssldap_exists()? I think in particular >> you need explain that it returns 1 and 0 because that value can >> eventually be the return value of the installer itself (normally an >> exists would return True/False). > I've changed it to return True/False and added comment >> >> Seeing a traceback: >> >> # ipa-client-install --no-sssd >> >> [ snip ] >> >> Enrolled in IPA realm EXAMPLE.COM >> Created /etc/ipa/default.conf >> Configured /etc/krb5.conf for IPA realm EXAMPLE.COM >> LDAP enabled >> Kerberos 5 enabled >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install", line 1294, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install", line 1281, in main >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install", line 1211, in install >> (retcode, conf, filename) = configurer(fstore, cli_basedn, cli_realm, >> cli_domain, cli_server, dnsok, options) >> TypeError: configure_ldap_conf() takes exactly 8 arguments (7 given) >> >> rob > corrected > ack, pushed to master From simo at redhat.com Tue Dec 6 21:09:46 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 06 Dec 2011 16:09:46 -0500 Subject: [Freeipa-devel] [Freeipa-users] Announcing FreeIPA 2.1.4 In-Reply-To: <4EDE6C5B.6070808@redhat.com> References: <4EDE6C5B.6070808@redhat.com> Message-ID: <1323205786.16141.100.camel@willson.li.ssimo.org> Thanks Rob for all the great work! I want to add just one warning that may escape users attention. Due to the need to address the CSRF attack, our command line tools (including ipa-client-install) will not work on newer servers until you upgrade those clients. The reason is that the old tools never sent the Referer header. The newer tools should work w/o any issue against an old server. Unfortunately although CSRF attacks are a concern only when using the Web UI, we had to break compatibility because a browser could be subverted to use the xml-rpc interface used by the CLI tools, and we couldn't leave that hole open even though this means we are breaking backwards compatibility. So if you need to have a gradual upgrade you should start from clients (and install images) before upgrading the server. Keep in mind though that the flaw will not be fixed until you upgrade the server. So, although the flaw is not really critical (IMO), you should not delay upgrades too long in production environments and be careful on administrative clients where you use admin credentials. HTH, Simo. On Tue, 2011-12-06 at 14:26 -0500, Rob Crittenden wrote: > The FreeIPA team is proud to announce version 2.1.4. > > It can be downloaded from http://www.freeipa.org/Downloads and should > appear in the Fedora 15 and 16 updates-testing soon (still waiting for > bohdi to push the builds). A rawhide (F-17) build is also available. > > == Highlights in 2.1.4 == > > This is a security release, users are strongly advised to upgrade. > > Specifically, it addresses CVE-2011-3636. A Cross-Site Request Forgery > (CSRF) flaw was found in FreeIPA due to a lack of checking the Referer > Header in the server (it is not set in the CLI utilities). If a remote > attacker could trick a user, who was logged into the FreeIPA management > interface, into visiting a specially-crafted URL, the attacker could > perform FreeIPA configuration changes with the privileges of the logged > in user. > > Some bugs have been addressed too, the highlights are: > > * Certificates in the UI are now displayed in PEM format > * systemd support in Fedora 16 > * Change the way the Kerberos random salt is calculated to improve > interoperability with Windows > * Fix nis netgroups, users and groups were not appearing > * Better handling of Kerberos realm to domain mapping > > == Upgrading == > > === Server === > > To upgrade a 2.0.0, 2.0.1 or 2.1.0 server do the following: > # yum update freeipa-server --enablerepo=updates-testing > > This will pull in updated freeIPA, 389-ds, dogtag, libcurl and xmlrpc-c > packages (and perhaps some others). A script will be executed in the rpm > postinstall phase to update the IPA LDAP server with any required changes. > > There is a bug reported against 389-ds, > https://bugzilla.redhat.com/show_bug.cgi?id=730387, related to > read-write locks. The NSPR RW lock implementation does not safely allow > re-entrant use of reader > locks. This is a timing issue so it is difficult to predict. During > testing one user experienced this and the upgrade hung. To break the > hang kill the ns-slapd process for your realm, wait for the yum > transaction to complete, then restart 389-ds and manually run the update > process: > > # service dirsrv start > # ipa-ldap-updater --update > > === Client === > > The ipa-client-install tool in the ipa-client package is just a > configuration tool. There should be no need to re-run this on every > client already enrolled. > > == Detailed Changelog for 2.1.3 == > > Alexander Bokovoy (4): > * hbactest fails while you have svcgroup in hbacrule > * Add support for systemd environments and use it to support Fedora 16 > * Spin for connection success also when socket is not (yet) available > * Quote multiple workers option > > Endi S. Dewata (1): > * Added current password field. > > Evgeny Sinelnikov (1): > * ipa_kpasswd: Update selinux policies for ldap and urandom > > John Dennis (1): > * Unable to Download Certificate with Browser > > Martin Kosek (8): > * Fix client krb5 domain mapping and DNS > * Fix ipa-managed-entries password option long form > * Fix ipa-server-install answer cache > * Fix ipa-replica-conncheck port labels > * Fix ipa-managed-entries bind procedure > * Let PublicError accept Gettext objects > * Enable automember for upgraded servers > * Make ipa-server-install clean after itself > > Ondrej Hamada (1): > * Client install root privileges check > > Rob Crittenden (4): > * Fix problems in help system > * Fix nis netgroup config entry so users appear in netgroup triple. > * Don't allow default objectclass list to be empty. > * Require an HTTP Referer header in the server. Send one in ipa tools. > (CVE-2011-3636) > > Simo Sorce (1): > * Modify random salt creation for interoperability > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From JR.Aquino at citrix.com Tue Dec 6 21:17:57 2011 From: JR.Aquino at citrix.com (JR Aquino) Date: Tue, 6 Dec 2011 21:17:57 +0000 Subject: [Freeipa-devel] [Freeipa-users] Announcing FreeIPA 2.1.4 In-Reply-To: <1323205786.16141.100.camel@willson.li.ssimo.org> References: <4EDE6C5B.6070808@redhat.com> <1323205786.16141.100.camel@willson.li.ssimo.org> Message-ID: On Dec 6, 2011, at 1:09 PM, Simo Sorce wrote: > Thanks Rob for all the great work! > > > I want to add just one warning that may escape users attention. > > Due to the need to address the CSRF attack, our command line tools > (including ipa-client-install) will not work on newer servers until you > upgrade those clients. The reason is that the old tools never sent the > Referer header. How do you upgrade your clients if they are RHEL and the Server is Fedora? > > The newer tools should work w/o any issue against an old server. > > Unfortunately although CSRF attacks are a concern only when using the > Web UI, we had to break compatibility because a browser could be > subverted to use the xml-rpc interface used by the CLI tools, and we > couldn't leave that hole open even though this means we are breaking > backwards compatibility. > > So if you need to have a gradual upgrade you should start from clients > (and install images) before upgrading the server. > > Keep in mind though that the flaw will not be fixed until you upgrade > the server. So, although the flaw is not really critical (IMO), you > should not delay upgrades too long in production environments and be > careful on administrative clients where you use admin credentials. > > HTH, > Simo. From edewata at redhat.com Tue Dec 6 21:56:20 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 06 Dec 2011 15:56:20 -0600 Subject: [Freeipa-devel] [PATCH] 315 Added commands into metadata. In-Reply-To: <4EDE431C.7090000@redhat.com> References: <4EC5602E.3030004@redhat.com> <4EC63A3E.5080200@redhat.com> <4EC67B6E.2070409@redhat.com> <4EC6A385.4050605@redhat.com> <4EDDAA5F.4060903@redhat.com> <4EDE264B.8080809@redhat.com> <4EDE431C.7090000@redhat.com> Message-ID: <4EDE8F84.4020009@redhat.com> On 12/6/2011 10:30 AM, Rob Crittenden wrote: >>> Updated patch attached. >> >> Web UI - ACK. >> Server side - seems fine - I would give it an ACK, but I'm not sure if >> I'm the right person for it. > > I think this is too radical a change. We can only bump the minor version > in this release so while the api can be modified it still needs to be > backwards compatible. New patch attached. The existing arguments are retained, new options are added. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0315-4-Added-commands-into-metadata.patch Type: text/x-patch Size: 465233 bytes Desc: not available URL: From rcritten at redhat.com Tue Dec 6 22:02:08 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 17:02:08 -0500 Subject: [Freeipa-devel] [PATCH] 315 Added commands into metadata. In-Reply-To: <4EDE8F84.4020009@redhat.com> References: <4EC5602E.3030004@redhat.com> <4EC63A3E.5080200@redhat.com> <4EC67B6E.2070409@redhat.com> <4EC6A385.4050605@redhat.com> <4EDDAA5F.4060903@redhat.com> <4EDE264B.8080809@redhat.com> <4EDE431C.7090000@redhat.com> <4EDE8F84.4020009@redhat.com> Message-ID: <4EDE90E0.1030205@redhat.com> Endi Sukma Dewata wrote: > On 12/6/2011 10:30 AM, Rob Crittenden wrote: >>>> Updated patch attached. >>> >>> Web UI - ACK. >>> Server side - seems fine - I would give it an ACK, but I'm not sure if >>> I'm the right person for it. >> >> I think this is too radical a change. We can only bump the minor version >> in this release so while the api can be modified it still needs to be >> backwards compatible. > > New patch attached. The existing arguments are retained, new options are > added. > ACK on framework changes. rob From edewata at redhat.com Tue Dec 6 22:10:17 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 06 Dec 2011 16:10:17 -0600 Subject: [Freeipa-devel] [PATCH] 315 Added commands into metadata. In-Reply-To: <4EDE90E0.1030205@redhat.com> References: <4EC5602E.3030004@redhat.com> <4EC63A3E.5080200@redhat.com> <4EC67B6E.2070409@redhat.com> <4EC6A385.4050605@redhat.com> <4EDDAA5F.4060903@redhat.com> <4EDE264B.8080809@redhat.com> <4EDE431C.7090000@redhat.com> <4EDE8F84.4020009@redhat.com> <4EDE90E0.1030205@redhat.com> Message-ID: <4EDE92C9.1060300@redhat.com> On 12/6/2011 4:02 PM, Rob Crittenden wrote: >>>> Web UI - ACK. >>>> Server side - seems fine - I would give it an ACK, but I'm not sure if >>>> I'm the right person for it. >>> >>> I think this is too radical a change. We can only bump the minor version >>> in this release so while the api can be modified it still needs to be >>> backwards compatible. >> >> New patch attached. The existing arguments are retained, new options are >> added. > > ACK on framework changes. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Dec 6 22:10:59 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 06 Dec 2011 16:10:59 -0600 Subject: [Freeipa-devel] [PATCH] 316 Added support for radio buttons in table widget. In-Reply-To: <4EDE2690.2090009@redhat.com> References: <4ECA95EE.7080205@redhat.com> <4EDDAA89.5010509@redhat.com> <4EDE2690.2090009@redhat.com> Message-ID: <4EDE92F3.1000202@redhat.com> On 12/6/2011 8:28 AM, Petr Vobornik wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Dec 6 22:11:21 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 06 Dec 2011 16:11:21 -0600 Subject: [Freeipa-devel] [PATCH] 317 Fixed entity metadata resolution. In-Reply-To: <4EDE26BB.6010100@redhat.com> References: <4ECA972D.7030904@redhat.com> <4EDDAAA7.3070605@redhat.com> <4EDE26BB.6010100@redhat.com> Message-ID: <4EDE9309.90400@redhat.com> On 12/6/2011 8:29 AM, Petr Vobornik wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Dec 6 22:11:39 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 06 Dec 2011 16:11:39 -0600 Subject: [Freeipa-devel] [PATCH] 318 Refactored facet.load(). In-Reply-To: <4EDE2C38.9010700@redhat.com> References: <4ECA989E.8050300@redhat.com> <4EDDAAC5.7090700@redhat.com> <4EDE2C38.9010700@redhat.com> Message-ID: <4EDE931B.7090908@redhat.com> On 12/6/2011 8:52 AM, Petr Vobornik wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Dec 6 22:12:49 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 06 Dec 2011 16:12:49 -0600 Subject: [Freeipa-devel] [PATCH] 319 Added HBAC Test page. In-Reply-To: <4EDE2F7F.4040502@redhat.com> References: <4ECA9AAD.6070502@redhat.com> <4EDDAAEE.7070809@redhat.com> <4EDE2F7F.4040502@redhat.com> Message-ID: <4EDE9361.3070809@redhat.com> On 12/6/2011 9:06 AM, Petr Vobornik wrote: > ACK > > In tables are 3 boolean columns which are not translated. I'll wait with > pushing my patch #51 and I'll add them there along with some issues you > mentioned in that patch' review. Thanks. Pushed to master. -- Endi S. Dewata From rcritten at redhat.com Tue Dec 6 22:56:06 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 17:56:06 -0500 Subject: [Freeipa-devel] [PATCH] 911 ensure confidential minssf Message-ID: <4EDE9D86.6050301@redhat.com> Ensure that we always use at least 56 for minssf when communicating with 389-ds. This will prevent someone from modifying /etc/openldap/ldap.conf in a way to put all communication in the clear. See the ticket for testing information. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-911-minssf.patch Type: text/x-patch Size: 1653 bytes Desc: not available URL: From rcritten at redhat.com Tue Dec 6 23:18:25 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 18:18:25 -0500 Subject: [Freeipa-devel] [PATCH] 911 ensure confidential minssf In-Reply-To: <4EDE9D86.6050301@redhat.com> References: <4EDE9D86.6050301@redhat.com> Message-ID: <4EDEA2C1.1040308@redhat.com> Rob Crittenden wrote: > Ensure that we always use at least 56 for minssf when communicating with > 389-ds. This will prevent someone from modifying /etc/openldap/ldap.conf > in a way to put all communication in the clear. > > See the ticket for testing information. > > rob Note that it should be setting minssf to 56 and not 1 here. I hadn't committed that change yet, I'll fix before pushing if acked. rob From rcritten at redhat.com Tue Dec 6 23:21:06 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 18:21:06 -0500 Subject: [Freeipa-devel] Display the value of memberOf ACIs in permission plugin. Message-ID: <4EDEA362.2070209@redhat.com> There were two problems: 1. memberof wasn't in the list of things we looked for in the return value from aci_show() 2. The value wasn't being translated into a group name. Use the DN class to retrieve the group name from the memberof URI. Note that I changed the parsing for targetgroup as well. We now save a lookup and potentially returning a NotFound if an aci points to a group that no longer exists. https://fedorahosted.org/freeipa/ticket/2100 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-912-permission.patch Type: text/x-patch Size: 5240 bytes Desc: not available URL: From rcritten at redhat.com Tue Dec 6 23:22:04 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 06 Dec 2011 18:22:04 -0500 Subject: [Freeipa-devel] Fwd: [PATCH] 912 Display the value of memberOf ACIs in permission plugin. In-Reply-To: <4EDEA362.2070209@redhat.com> References: <4EDEA362.2070209@redhat.com> Message-ID: <4EDEA39C.5010206@redhat.com> Resending as a [PATCH] -------------- next part -------------- An embedded message was scrubbed... From: Rob Crittenden Subject: [Freeipa-devel] Display the value of memberOf ACIs in permission plugin. Date: Tue, 06 Dec 2011 18:21:06 -0500 Size: 9631 URL: From jcholast at redhat.com Wed Dec 7 07:13:13 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 07 Dec 2011 08:13:13 +0100 Subject: [Freeipa-devel] [PATCH] 56 Add new Param method for marshalling values from complex data types In-Reply-To: <4EA949CB.40804@redhat.com> References: <4EA949CB.40804@redhat.com> Message-ID: <4EDF1209.9060300@redhat.com> Dne 27.10.2011 14:08, Jan Cholasta napsal(a): > Add new Param method for marshalling values from complex data types to > primitive data types suitable for transmission over RPC. > > This change makes it possible to use complex data types (like > python-netaddr IPAddress) in parameters. > > https://fedorahosted.org/freeipa/ticket/2033 > > This will help implementing IP address parameter types properly in > https://fedorahosted.org/freeipa/ticket/1487 . > Self-NACK, I need to redo this on top of Martin's patch 163. Honza -- Jan Cholasta From jcholast at redhat.com Wed Dec 7 07:21:24 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 07 Dec 2011 08:21:24 +0100 Subject: [Freeipa-devel] Hashbang line in IPA scripts In-Reply-To: <1322841634.6745.34.camel@willson.li.ssimo.org> References: <4ED8E5C4.3090403@redhat.com> <1322841634.6745.34.camel@willson.li.ssimo.org> Message-ID: <4EDF13F4.6090201@redhat.com> Dne 2.12.2011 17:00, Simo Sorce napsal(a): > On Fri, 2011-12-02 at 15:50 +0100, Jan Cholasta wrote: >> Hi, >> >> We currently use this hashbang line in IPA scripts: >> >> #! /usr/bin/python -E >> >> IMHO this should be changed to point to Python 2 binary specifically: >> >> #! /usr/bin/python2 -E >> >> for the sake of distros, which symlink /usr/bin/python to Python 3 >> binary by default (Fedora 17?). >> >> Honza > > Send a patch, but is python2 guaranteed to be always available (thinking > RHEL for example) ? > > Simo. > An option is to use distutils (setup.py) on all the scripts, as it automatically changes the hashbang line to point to the correct interpreter. Honza -- Jan Cholasta From edewata at redhat.com Wed Dec 7 08:13:41 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 02:13:41 -0600 Subject: [Freeipa-devel] [PATCH] 320 Fixed navigation buttons for HBAC Test. In-Reply-To: <4EDE31B8.8000809@redhat.com> References: <4ECAFB7E.1090805@redhat.com> <4EDDAB1D.7060703@redhat.com> <4EDE31B8.8000809@redhat.com> Message-ID: <4EDF2035.40207@redhat.com> On 12/6/2011 9:16 AM, Petr Vobornik wrote: > 1) 'Collapse all' link in details facet is no longer aligned right. > 2) Find button in association adder dialog has wrong size. > 3) '>>' and '<<' buttons in association adder dialog cannot be clicked - > in Chrome. In Firefox they work. > 4) get_key_index method is defined twice in jQuery.ordered_map. All fixed in the new patch. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0320-3-Fixed-navigation-buttons-for-HBAC-Test.patch Type: text/x-patch Size: 11062 bytes Desc: not available URL: From edewata at redhat.com Wed Dec 7 08:13:51 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 02:13:51 -0600 Subject: [Freeipa-devel] [PATCH] 322 Added external fields for HBAC Test. In-Reply-To: <4EDE4FCE.9040509@redhat.com> References: <4EDDAC83.9050301@redhat.com> <4EDE4FCE.9040509@redhat.com> Message-ID: <4EDF203F.5020600@redhat.com> On 12/6/2011 11:24 AM, Petr Vobornik wrote: > 1) An exception occurs right after showing HBAC test page - user facet: > hbactest.js:364: if (that.selected_values[0] === '__external__') { > that.selected_values is undefined. > > 2) An exception occurs when you freshly open UI, go right for hbac test, > from user facet you skip to run test and click on "new test". It's > because other facets are not created, so when calling reset > that.external_radio is undefined. All fixed in the new patch. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0322-2-Added-external-fields-for-HBAC-Test.patch Type: text/x-patch Size: 9146 bytes Desc: not available URL: From edewata at redhat.com Wed Dec 7 08:14:02 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 02:14:02 -0600 Subject: [Freeipa-devel] [PATCH] 323 Fixed CSS for HBAC Test Message-ID: <4EDF204A.2010703@redhat.com> The tables in HBAC Test have been modified to expand according to window size. Hard-coded CSS codes have been moved into ipa.css. Ticket #388 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0323-Fixed-CSS-for-HBAC-Test.patch Type: text/x-patch Size: 10295 bytes Desc: not available URL: From mkosek at redhat.com Wed Dec 7 08:56:41 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Dec 2011 09:56:41 +0100 Subject: [Freeipa-devel] [PATCH] 899 more context with attribute in error message In-Reply-To: <4EA1C7EB.8010003@redhat.com> References: <4EA1C7EB.8010003@redhat.com> Message-ID: <1323248201.28014.8.camel@balmora.brq.redhat.com> On Fri, 2011-10-21 at 15:28 -0400, Rob Crittenden wrote: > Depending on the context and how you are using input (-- options or > set/addattr) you might get a different attribute name in the error > message. This patch tries to clear that up a bit. > > See the ticket for some test cases. > > rob I found few issues with this patch: 1) This patch cannot be applied. First chunk (frontend.py) was already pushed in other patch 2) Actually, this patch did not work for me: # ipa pwpolicy-mod --setattr=krbpwdmaxfailure=-1 ipa: ERROR: invalid 'krbpwdmaxfailure': must be at least 0 cli_name still did not show up. I also see that you did the change for Int onlu. I guess we should fix all parameters, for example StrEnum, etc.: # ipa sudorule-add foo --usercat=bar ipa: ERROR: invalid 'usercat': must be one of (u'all',) # ipa sudorule-add foo --setattr=usercategory=bar ipa: ERROR: invalid 'usercategory': must be one of (u'all',) Martin From jkuncar at redhat.com Wed Dec 7 08:59:12 2011 From: jkuncar at redhat.com (Jiri Kuncar) Date: Wed, 07 Dec 2011 03:59:12 -0500 (EST) Subject: [Freeipa-devel] [PATCH] bind-dyndb-ldap: enable/disable PTR synchronization per zone In-Reply-To: <20111202164939.GA12728@redhat.com> Message-ID: <893852f3-79b2-424f-a212-9b3eacafcec3@zmail13.collab.prod.int.phx2.redhat.com> > On Thu, Dec 01, 2011 at 09:00:18AM -0500, Jiri Kuncar wrote: > > I've added an attribute "idnsAllowSyncPTR" to "idnsZone" to enable > > or disable synchronization of PTR records. However the > > bind-dyndb-ldap plugin option "sync_ptr" has to be included in > > /etc/named.conf to run synchronization feature. > > Hello, > > This doesn't seem too user-friendly for me. In my opinion better is > to allow PTR > synchronization when sync_ptr is "no" and idnsAllowSyncPTR is set to > "TRUE". So > admin can either set sync_ptr to allow updates for all zones or set > per-zone > idnsAllowSyncPTR attr. I agree. Please check my corrections and comments inside the patch. Regards, Jiri -------------- next part -------------- A non-text attachment was scrubbed... Name: jkuncar-ticket39-Enable-disable-PTR-synchronization-per-zone-v2.patch Type: text/x-patch Size: 5259 bytes Desc: not available URL: From edewata at redhat.com Wed Dec 7 09:06:47 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 03:06:47 -0600 Subject: [Freeipa-devel] [PATCH] 324 Fixed I18n labels for HBAC Test Message-ID: <4EDF2CA7.9090500@redhat.com> Hard-coded labels in HBAC Test have been moved into internal.py to allow translation. Ticket #388 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0324-Fixed-I18n-labels-for-HBAC-Test.patch Type: text/x-patch Size: 12076 bytes Desc: not available URL: From mkosek at redhat.com Wed Dec 7 09:22:18 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Dec 2011 10:22:18 +0100 Subject: [Freeipa-devel] [PATCH] 910 fix memberof for privileges In-Reply-To: <4EDE671B.90708@redhat.com> References: <4EDE671B.90708@redhat.com> Message-ID: <1323249738.28014.14.camel@balmora.brq.redhat.com> On Tue, 2011-12-06 at 14:03 -0500, Rob Crittenden wrote: > Some privileges were being created after the permissions that were > pointing to it causing the memberof to not be generated. > > This patch reorders things for new installs and creates a PBAC memberof > task that will correct an upgrade. > > rob I found few issues with this patch: 1) It needs a rebase, Makefile.am chunk does not apply. 2) The patch won't fix "Modify Group membership" privilege issue. The problem here is that this privilege does not have any permissions assigned at all. 3) The update has failed in my case (on F16): # ipa-ldap-updater --upgrade Upgrading IPA: [1/8]: stopping directory server [2/8]: saving configuration [3/8]: disabling listeners [4/8]: starting directory server [5/8]: upgrading server ipa : ERROR Upgrade failed with Unable to connect to LDAP server ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket [6/8]: stopping directory server [7/8]: restoring configuration [8/8]: starting directory server done configuring dirsrv. ipa : INFO IPA upgrade failed. IPA upgrade failed. The socker is there though, no AVC in audit.log either. # ls /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket Did the update work for you? Martin From mkosek at redhat.com Wed Dec 7 10:24:09 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Dec 2011 11:24:09 +0100 Subject: [Freeipa-devel] [PATCH] 903 normalize paths in certmonger In-Reply-To: <4EB9BC55.1010706@redhat.com> References: <4EB9BC55.1010706@redhat.com> Message-ID: <1323253449.28014.27.camel@balmora.brq.redhat.com> On Tue, 2011-11-08 at 18:33 -0500, Rob Crittenden wrote: > There are times we need to hunt through the certmonger request files > trying (such as trying to stop tracking a cert). One criteria is the > cert database and they need to match exactly. We weren't normalizing > this so something as simple as a trailing slash would cause a match to fail. > > Normalize both values to address this. > > rob Looks good. I just found few nitpicks that may be fixed before push: 1) I didn't like constructs like this one: '%s' % os.path.abspath(secdir) Simple "os.path.abspath(secdir)" would be enough 2) I think get_request_id() function documentation should contain recognized value types: None: Any type 1: File path 3) We may want also to normalize path to PW file. This is what we use now in ipa-server-install: 2011-12-07T10:11:25Z DEBUG args=/usr/bin/ipa-getcert start-tracking -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert -p /etc/dirsrv/slapd-PKI-IPA//pwdfile.txt This shoud be enough: - args.append(passwd_fname) + args.append(os.path.abspath(passwd_fname)) Martin From abokovoy at redhat.com Wed Dec 7 11:49:49 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 7 Dec 2011 13:49:49 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <4ED8F15B.7060602@redhat.com> References: <20111114093243.GA312@redhat.com> <4ED8F15B.7060602@redhat.com> Message-ID: <20111207114948.GA32281@redhat.com> On Fri, 02 Dec 2011, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >Hi, > > > >FreeIPA SUDO rules use --usercat/--groupcat to specify that rule > >applies to all users or groups. Thus, sudorule-add-runasuser and > >sudorule-add-runasgroup accept specific groups and users and do not > >accept ALL reserved word. > > > >The patch validates user and group passed to these commands and > >reports appropriate errors when these are ALL or all arguments > >are empty. > > > >Ticket #1496 > >https://fedorahosted.org/freeipa/ticket/1496 > > > >One thing I'm not sure about is blocking all variants of the reserved > >word 'ALL'. The patch blocks them all due to the fact that most likely > >any of 'all', 'All', 'ALL', 'aLL', and so on are mistyping but there > >are might be valid cases when group or user is called 'all'. > > Then runasuser check reports runas-group as the attribute name, I > think it should still be runas-user even though it is a group of > users. Ok. Changed. > Other member commands don't consider it an error to provide any > actual members, it treats it as a no-op. We should probably be > consistent. Don't understand. Did you mean 'to not provide any actual members'? In case you did, attached patch removes remaining checks for runas_{user,group) to be False. > It would probably be better to return the value as passed in by the > user rather than user[0].value. The issue here is that names come to the callback already as DNs from LDAPAddMember's execute() method. Strictly speaking it is already different to what user has entered as we do expansion by default to add $SUFFIX and appropriate container. In the updated patch I tried to reduce DN to something reasonable by relying on known containers and only showing full DN for cases when these are not users/groups containers. -- / Alexander Bokovoy -------------- next part -------------- >From 4bf337aad4ab228efb34b6b553c2856de63cb245 Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Mon, 14 Nov 2011 11:23:19 +0200 Subject: [PATCH] Validate sudo RunAsUser/RunAsGroup arguments FreeIPA SUDO rules use --usercat/--groupcat to specify that rule applies to all users or groups. Thus, sudorule-add-runasuser and sudorule-add-runasgroup accept specific groups and users and do not accept ALL reserved word. The patch validates user and group passed to these commands and reports appropriate errors when these are ALL. Ticket #1496 https://fedorahosted.org/freeipa/ticket/1496 --- ipalib/plugins/sudorule.py | 60 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 60 insertions(+), 0 deletions(-) diff --git a/ipalib/plugins/sudorule.py b/ipalib/plugins/sudorule.py index 93ca03f0170d922b91eff45ec2f42871336973f1..31b72d860f0dafc34e00432edaa4da69a809e2f8 100644 --- a/ipalib/plugins/sudorule.py +++ b/ipalib/plugins/sudorule.py @@ -472,6 +472,18 @@ class sudorule_remove_host(LDAPRemoveMember): api.register(sudorule_remove_host) +def relative_to_container(env, cn_name, dn): + try: + cn_ = 'container_%s' % (cn_name) + if cn_ in env: + cn = DN(env[cn_])+DN(env.basedn) + else: + return dn + except: + return dn + if dn.endswith(cn): + return dn[0].value + return dn class sudorule_add_runasuser(LDAPAddMember): __doc__ = _('Add users and groups for Sudo to execute as.') @@ -479,6 +491,33 @@ class sudorule_add_runasuser(LDAPAddMember): member_attributes = ['ipasudorunas'] member_count_out = ('%i object added.', '%i objects added.') + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + def check_validity(runas): + v = unicode(runas[0].value) + if v.upper() == u'ALL': + return False + return True + + if 'ipasudorunas' in entry_attrs: + # Map group and user options. If option value is missing, runas_* will + # be set to False. The ordering is group, user and values are + # DNs already so we'll use DN class for extracting actual CN. + (runas_group, runas_user) = map(lambda x: len(x)>0 and x[0], entry_attrs['ipasudorunas'].values()) + if runas_group: + group = DN(runas_group) + if not check_validity(group): + raise errors.ValidationError(name='runas-user', + error=unicode(_("RunAsUser does not accept '%s' as a group name")) % + (relative_to_container(self.api.env, 'group', group))) + if runas_user: + user = DN(runas_user) + if not check_validity(user): + raise errors.ValidationError(name='runas-user', + error=unicode(_("RunAsUser does not accept '%s' as a user name")) % + (relative_to_container(self.api.env, 'user', user))) + + return dn + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): completed_external = 0 # Sift through the user failures. We assume that these are all @@ -547,6 +586,27 @@ class sudorule_add_runasgroup(LDAPAddMember): member_attributes = ['ipasudorunasgroup'] member_count_out = ('%i object added.', '%i objects added.') + def pre_callback(self, ldap, dn, entry_attrs, attrs_list, *keys, **options): + def check_validity(runas): + v = unicode(runas[0].value) + if v.upper() == u'ALL': + return False + return True + + if 'ipasudorunasgroup' in entry_attrs: + # Extract group DN. If it is empty, runas_group will be set to False. + # We'll use DN class to extract actual CN we are interested in. + runas_group = entry_attrs['ipasudorunasgroup']['group'] + runas_group = len(runas_group)>0 and runas_group[0] + if runas_group: + group = DN(runas_group) + if not check_validity(group): + raise errors.ValidationError(name='runas-group', + error=unicode(_("RunAsGroup does not accept '%s' as a group name")) % + (relative_to_container(self.api.env, 'group', group))) + + return dn + def post_callback(self, ldap, completed, failed, dn, entry_attrs, *keys, **options): completed_external = 0 # Sift through the group failures. We assume that these are all -- 1.7.7.3 From abokovoy at redhat.com Wed Dec 7 12:42:25 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 7 Dec 2011 14:42:25 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Check all LDAP servers during IPA discovery In-Reply-To: <4ED8F47D.7060905@redhat.com> References: <20111114104800.GA3927@redhat.com> <4ED8F47D.7060905@redhat.com> Message-ID: <20111207124224.GB32281@redhat.com> On Fri, 02 Dec 2011, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >Hi, > > > >This is patch proposal, I haven't checked it with multiple servers > >setup yet. > > > >When discovering IPA LDAP servers through DNS records, look through all > >servers found until first success. A master might be not available or > >denied access due to anonymous binds disabled, for example, but > >replica may succeed. > > > >Ticket #1827 > >https://fedorahosted.org/freeipa/ticket/1827 > > Needs a rebase. > > This works fine but I wonder if someone specifies --server on the > command-line if we should try only that server and fail if we can't > connect. I can see someone using that so they can specify which > server the client uses. Rebase attached. If --server is specified, DNS discovery is bypassed in search() and self.server will have the value of --server. That means the code I changed will still work as parse_items() accepts a single item as well. -- / Alexander Bokovoy -------------- next part -------------- >From bc441d8e6bc1e0007c4a6395f0a382980b8de36f Mon Sep 17 00:00:00 2001 From: Alexander Bokovoy Date: Wed, 7 Dec 2011 14:40:46 +0200 Subject: [PATCH] Check through all LDAP servers in the domain during IPA discovery When discovering IPA LDAP servers through DNS records, look through all servers found until first success. A master might be not available or denied access but replica may succeed. Ticket #1827 https://fedorahosted.org/freeipa/ticket/1827 --- ipa-client/ipaclient/ipadiscovery.py | 34 +++++++++++++++++++++++++--------- 1 files changed, 25 insertions(+), 9 deletions(-) diff --git a/ipa-client/ipaclient/ipadiscovery.py b/ipa-client/ipaclient/ipadiscovery.py index 94a04f39e70f6edf3874c036462c457f85f56c12..40fafbabfeccf1f90adb36a86dc5cfd0ae297329 100644 --- a/ipa-client/ipaclient/ipadiscovery.py +++ b/ipa-client/ipaclient/ipadiscovery.py @@ -25,7 +25,7 @@ import tempfile import ldap from ldap import LDAPError from ipapython.ipautil import run, CalledProcessError, valid_ip, get_ipa_basedn, \ - realm_to_suffix, format_netloc + realm_to_suffix, format_netloc, parse_items NOT_FQDN = -1 @@ -170,19 +170,35 @@ class IPADiscovery: self.kdc = krbret[1] root_logger.debug("[ipacheckldap]") - # check ldap now - ldapret = self.ipacheckldap(self.server, self.realm) + # We may have received multiple servers corresponding to the domain + # Iterate through all of those to check if it is IPA LDAP server + servers = parse_items(self.server) + ldapret = [NOT_IPA_SERVER] + ldapaccess = True + for server in servers: + # check ldap now + ldapret = self.ipacheckldap(server, self.realm) - if ldapret[0] == 0: - self.server = ldapret[1] - self.realm = ldapret[2] + if ldapret[0] == 0: + self.server = ldapret[1] + self.realm = ldapret[2] + break - if ldapret[0] == NO_ACCESS_TO_LDAP and self.realm is None: + if ldapret[0] == NO_ACCESS_TO_LDAP: + ldapaccess = False + + # If one of LDAP servers checked rejects access (may be anonymous + # bind is disabled), assume realm and basedn generated off domain. + # Note that in case ldapret[0] == 0 and ldapaccess == False (one of + # servers didn't provide access but another one succeeded), self.realm + # will be set already to a proper value above, self.basdn will be + # initialized during the LDAP check itself and we'll skip these two checks. + if not ldapaccess and self.realm is None: # Assume realm is the same as domain.upper() self.realm = self.domain.upper() root_logger.debug("Assuming realm is the same as domain: %s" % self.realm) - if ldapret[0] == NO_ACCESS_TO_LDAP and self.basedn is None: + if not ldapaccess and self.basedn is None: # Generate suffix from realm self.basedn = realm_to_suffix(self.realm) root_logger.debug("Generate basedn from realm: %s" % self.basedn) @@ -200,7 +216,7 @@ class IPADiscovery: Errno is an error number: 0 means all ok 1 means we could not check the info in LDAP (may happend when - anonymous binds are siabled) + anonymous binds are disabled) 2 means the server is certainly not an IPA server """ -- 1.7.7.3 From mkosek at redhat.com Wed Dec 7 13:22:18 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Dec 2011 14:22:18 +0100 Subject: [Freeipa-devel] [PATCH] 176 Ask for user confirmation in ipa-server-install Message-ID: <1323264138.28014.28.camel@balmora.brq.redhat.com> Summarize entered IPA server configuration so that user can examine it and stop the installation process in case of error. Before this patch, user had to know which question is the last one and check the values he entered in various places during the interactive wizard. https://fedorahosted.org/freeipa/ticket/1083 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-176-ask-for-user-confirmation-in-ipa-server-install.patch Type: text/x-patch Size: 2547 bytes Desc: not available URL: From abokovoy at redhat.com Wed Dec 7 13:42:48 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 7 Dec 2011 15:42:48 +0200 Subject: [Freeipa-devel] [PATCH] 176 Ask for user confirmation in ipa-server-install In-Reply-To: <1323264138.28014.28.camel@balmora.brq.redhat.com> References: <1323264138.28014.28.camel@balmora.brq.redhat.com> Message-ID: <20111207134248.GA16334@redhat.com> On Wed, 07 Dec 2011, Martin Kosek wrote: > Summarize entered IPA server configuration so that user can examine > it and stop the installation process in case of error. Before this > patch, user had to know which question is the last one and check > the values he entered in various places during the interactive > wizard. > > https://fedorahosted.org/freeipa/ticket/1083 ACK. -- / Alexander Bokovoy From mkosek at redhat.com Wed Dec 7 13:45:55 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 07 Dec 2011 14:45:55 +0100 Subject: [Freeipa-devel] [PATCH] 176 Ask for user confirmation in ipa-server-install In-Reply-To: <20111207134248.GA16334@redhat.com> References: <1323264138.28014.28.camel@balmora.brq.redhat.com> <20111207134248.GA16334@redhat.com> Message-ID: <1323265555.28014.29.camel@balmora.brq.redhat.com> On Wed, 2011-12-07 at 15:42 +0200, Alexander Bokovoy wrote: > On Wed, 07 Dec 2011, Martin Kosek wrote: > > Summarize entered IPA server configuration so that user can examine > > it and stop the installation process in case of error. Before this > > patch, user had to know which question is the last one and check > > the values he entered in various places during the interactive > > wizard. > > > > https://fedorahosted.org/freeipa/ticket/1083 > ACK. > Pushed to master. Martin From pvoborni at redhat.com Wed Dec 7 14:08:04 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Dec 2011 15:08:04 +0100 Subject: [Freeipa-devel] [PATCH] 320 Fixed navigation buttons for HBAC Test. In-Reply-To: <4EDF2035.40207@redhat.com> References: <4ECAFB7E.1090805@redhat.com> <4EDDAB1D.7060703@redhat.com> <4EDE31B8.8000809@redhat.com> <4EDF2035.40207@redhat.com> Message-ID: <4EDF7344.8070605@redhat.com> On 12/07/2011 09:13 AM, Endi Sukma Dewata wrote: > > All fixed in the new patch. > ACK -- Petr Vobornik From pvoborni at redhat.com Wed Dec 7 14:08:18 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Dec 2011 15:08:18 +0100 Subject: [Freeipa-devel] [PATCH] 322 Added external fields for HBAC Test. In-Reply-To: <4EDF203F.5020600@redhat.com> References: <4EDDAC83.9050301@redhat.com> <4EDE4FCE.9040509@redhat.com> <4EDF203F.5020600@redhat.com> Message-ID: <4EDF7352.1000803@redhat.com> On 12/07/2011 09:13 AM, Endi Sukma Dewata wrote: > On 12/6/2011 11:24 AM, Petr Vobornik wrote: >> 1) An exception occurs right after showing HBAC test page - user facet: >> hbactest.js:364: if (that.selected_values[0] === '__external__') { >> that.selected_values is undefined. >> >> 2) An exception occurs when you freshly open UI, go right for hbac test, >> from user facet you skip to run test and click on "new test". It's >> because other facets are not created, so when calling reset >> that.external_radio is undefined. > > All fixed in the new patch. > ACK -- Petr Vobornik From pvoborni at redhat.com Wed Dec 7 14:16:07 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Dec 2011 15:16:07 +0100 Subject: [Freeipa-devel] [PATCH] 323 Fixed CSS for HBAC Test In-Reply-To: <4EDF204A.2010703@redhat.com> References: <4EDF204A.2010703@redhat.com> Message-ID: <4EDF7527.8080502@redhat.com> On 12/07/2011 09:14 AM, Endi Sukma Dewata wrote: > The tables in HBAC Test have been modified to expand according to > window size. Hard-coded CSS codes have been moved into ipa.css. > > Ticket #388 > ACK Assuming that some following patch would add functionality to 'matched' and 'unmatched' checkboxes which were added to test_run_facet. -- Petr Vobornik From pvoborni at redhat.com Wed Dec 7 14:18:00 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Dec 2011 15:18:00 +0100 Subject: [Freeipa-devel] [PATCH] 324 Fixed I18n labels for HBAC Test In-Reply-To: <4EDF2CA7.9090500@redhat.com> References: <4EDF2CA7.9090500@redhat.com> Message-ID: <4EDF7598.6000800@redhat.com> On 12/07/2011 10:06 AM, Endi Sukma Dewata wrote: > Hard-coded labels in HBAC Test have been moved into internal.py to > allow translation. > > Ticket #388 > ACK -- Petr Vobornik From edewata at redhat.com Wed Dec 7 15:34:44 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 09:34:44 -0600 Subject: [Freeipa-devel] [PATCH] 320 Fixed navigation buttons for HBAC Test. In-Reply-To: <4EDF7344.8070605@redhat.com> References: <4ECAFB7E.1090805@redhat.com> <4EDDAB1D.7060703@redhat.com> <4EDE31B8.8000809@redhat.com> <4EDF2035.40207@redhat.com> <4EDF7344.8070605@redhat.com> Message-ID: <4EDF8794.8070206@redhat.com> On 12/7/2011 8:08 AM, Petr Vobornik wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Dec 7 15:35:06 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 09:35:06 -0600 Subject: [Freeipa-devel] [PATCH] 321 Fixed search filter in HBAC Test. In-Reply-To: <4EDE327B.9010705@redhat.com> References: <4ECAFBFF.1000305@redhat.com> <4EDDAB48.3090403@redhat.com> <4EDE327B.9010705@redhat.com> Message-ID: <4EDF87AA.60203@redhat.com> On 12/6/2011 9:19 AM, Petr Vobornik wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Dec 7 15:35:22 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 09:35:22 -0600 Subject: [Freeipa-devel] [PATCH] 322 Added external fields for HBAC Test. In-Reply-To: <4EDF7352.1000803@redhat.com> References: <4EDDAC83.9050301@redhat.com> <4EDE4FCE.9040509@redhat.com> <4EDF203F.5020600@redhat.com> <4EDF7352.1000803@redhat.com> Message-ID: <4EDF87BA.2020500@redhat.com> On 12/7/2011 8:08 AM, Petr Vobornik wrote: > ACK Pushed to master. -- Endi S. Dewata From edewata at redhat.com Wed Dec 7 15:36:08 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 09:36:08 -0600 Subject: [Freeipa-devel] [PATCH] 323 Fixed CSS for HBAC Test In-Reply-To: <4EDF7527.8080502@redhat.com> References: <4EDF204A.2010703@redhat.com> <4EDF7527.8080502@redhat.com> Message-ID: <4EDF87E8.5030704@redhat.com> On 12/7/2011 8:16 AM, Petr Vobornik wrote: > ACK Pushed to master. > Assuming that some following patch would add functionality to 'matched' > and 'unmatched' checkboxes which were added to test_run_facet. Yes, coming up next. -- Endi S. Dewata From edewata at redhat.com Wed Dec 7 15:36:33 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 09:36:33 -0600 Subject: [Freeipa-devel] [PATCH] 324 Fixed I18n labels for HBAC Test In-Reply-To: <4EDF7598.6000800@redhat.com> References: <4EDF2CA7.9090500@redhat.com> <4EDF7598.6000800@redhat.com> Message-ID: <4EDF8801.5010304@redhat.com> On 12/7/2011 8:18 AM, Petr Vobornik wrote: > ACK Pushed to master. -- Endi S. Dewata From pvoborni at redhat.com Wed Dec 7 16:00:52 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Dec 2011 17:00:52 +0100 Subject: [Freeipa-devel] [PATCH] 051 Search facets show translated boolean values In-Reply-To: <4EDCFF05.60109@redhat.com> References: <4EDCE525.3030502@redhat.com> <4EDCFF05.60109@redhat.com> Message-ID: <4EDF8DB4.2060901@redhat.com> On 12/05/2011 06:27 PM, Endi Sukma Dewata wrote: > On 12/5/2011 9:37 AM, Petr Vobornik wrote: >> Created format method for getting translated messages for boolean values >> - IPA.boolean_column_format. >> >> Used in hosts, sudo rules, hbac rules. >> >> https://fedorahosted.org/freeipa/ticket/2027 > > The patch works, so it's ACKed. New version attached. > There are a few suggestions but they can > be done later: > > 1. It might be better to name the function IPA.boolean_format because we > can use it for other things too, not just inside a column. Renamed > > 2. The value can be normalized using toLowerCase() before comparison. Done, but using normalized value only for comparison because of #3. > > 3. If the value doesn't match true/false it can return the original > value instead of empty string Done. Returning empty string if null or undefined. Newly used in HBAC test page. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0051-1-Search-facets-show-translated-boolean-values.patch Type: text/x-patch Size: 5158 bytes Desc: not available URL: From jcholast at redhat.com Wed Dec 7 16:28:52 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 07 Dec 2011 17:28:52 +0100 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management Message-ID: <4EDF9444.20209@redhat.com> Hi, this patchset fixes the following tickets: https://fedorahosted.org/freeipa/ticket/754 https://fedorahosted.org/freeipa/ticket/1634 https://fedorahosted.org/freeipa/ticket/1978 [PATCH] 59 Add LDAP schema for SSH public keys. [PATCH] 60 Add LDAP ACIs for SSH public key schema. [PATCH] 61 Add support for SSH public keys to user and host objects. This patch adds a new multivalue param "sshpubkey" for specifying SSH public keys to both user and host objects. The accepted value is base64-encoded public key blob as specified in RFC4253, section 6.6. Additionaly, host commands automatically update DNS SSHFP records when requested by user. [PATCH] 62 Add API initialization to ipa-client-install. This change makes it possible to call IPA commands from ipa-client-install. [PATCH] 63 Move the nsupdate functionality to separate function in ipa-client-install. [PATCH] 64 Update host SSH public keys on the server during client install. This is done by calling host-mod to update the keys on IPA server and nsupdate to update DNS SSHFP records. DNS update can be disabled using --no-dns-sshfp ipa-client-install option. [PATCH] 65 Configure ssh and sshd during ipa-client-install. For ssh, VerifyHostKeyDNS option is enabled. For sshd, KerberosAuthentication, GSSAPIAuthentication and UsePAM options are enabled (this can be disabled using --no-sshd ipa-client-install option). Note that user impersonation is not part of this patchset, I'm still working on it. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-59-ssh-ldap-schema.patch Type: text/x-patch Size: 3637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-60-ssh-ldap-aci.patch Type: text/x-patch Size: 5811 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-61-ssh-host-user-plugins.patch Type: text/x-patch Size: 19507 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-62-ipa-client-install-api.patch Type: text/x-patch Size: 4108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-63-ipa-client-install-nsupdate.patch Type: text/x-patch Size: 2213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-64-ssh-install-update-keys.patch Type: text/x-patch Size: 5249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-65-ssh-install-config-sshd.patch Type: text/x-patch Size: 6774 bytes Desc: not available URL: From pvoborni at redhat.com Wed Dec 7 16:32:07 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 07 Dec 2011 17:32:07 +0100 Subject: [Freeipa-devel] [PATCH] 028 Code cleanup of HBAC, Sudo rules In-Reply-To: <4EAB5AC1.6030005@redhat.com> References: <4EA521FF.7020405@redhat.com> <4EA59250.8040506@redhat.com> <4EA6B041.5090204@redhat.com> <4EA6F86D.4070706@redhat.com> <4EA95F0A.5060903@redhat.com> <4EA9D27C.8060207@redhat.com> <4EA9EB9B.6050909@redhat.com> <4EA9FD89.2080206@redhat.com> <4EAB5AC1.6030005@redhat.com> Message-ID: <4EDF9507.2040503@redhat.com> Summary to maintain order in the list: This effort was split into patches: freeipa-pvoborni-0030-Extending-facet-s-mechanism-of-gathering-changes freeipa-pvoborni-0045-Code-cleanup-of-HBAC-Sudo-rules.patch - a part of greater UI refactoring effort ticket #2040 (patches 32-49). Patches mentioned above were ACKed and pushed to master. On 10/29/2011 03:45 AM, Adam Young wrote: > On 10/27/2011 08:55 PM, Endi Sukma Dewata wrote: >> On 10/27/2011 6:39 PM, Adam Young wrote: >>>> We might need to distinguish 2 different usages of 'entity'. The first >>>> one represents a collection of entries: >>> >>> Call that an instance. Entity is the term that is the analogue of Class >> >> Not sure I understand correctly. You mean entity is a class which is a >> collection, similar to a table in database? And instance is an object >> or individual entry or row in a table? > Yes, that is a pretty good analogy. >>> So we want to distinguish getting the primary key field for the entity, >>> as opposed to the primary key of the instance. >> >> From the URL we want to get the primary key for a particular >> instance/object to show in the detail page. > Yes. In a RESTful scheme it would be /IPA/entities/users/ayoung to get > my user object >> >>>> The IPA.client will represent a connection to the IPA server. In a >>>> browser IPA.client can only connect to the server it's loaded from: >>>> >>>> var client = IPA.client(); >>>> >>>> but in a JS engine like Rhino the IPA.client can connect to any IPA >>>> server: >>>> >>>> var client = IPA.client('ipa.example.com'); >>> >>> This will work now, but you will not be able to see the results of the >>> command. Integrations like this are how the Like buttons from Facebook >>> work. Cross site posting is tricky, but permitted, and might be useful >>> in some cases. Possibly we should call it connection. >> >> The second code is not supposed to be used inside a browser. This is >> suppose you're writing a JS script running in Rhino, you need to >> specify the IPA server you're connecting to. I haven't tried this, but >> I suppose in Rhino we will be able to set the Referer to match the >> server name. >> >> I'd rather call it IPA.client because it will do other things too, not >> just connection. >> > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Petr Vobornik From rcritten at redhat.com Wed Dec 7 18:50:26 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Dec 2011 13:50:26 -0500 Subject: [Freeipa-devel] [PATCH] 910 fix memberof for privileges In-Reply-To: <1323249738.28014.14.camel@balmora.brq.redhat.com> References: <4EDE671B.90708@redhat.com> <1323249738.28014.14.camel@balmora.brq.redhat.com> Message-ID: <4EDFB572.3090009@redhat.com> Martin Kosek wrote: > On Tue, 2011-12-06 at 14:03 -0500, Rob Crittenden wrote: >> Some privileges were being created after the permissions that were >> pointing to it causing the memberof to not be generated. >> >> This patch reorders things for new installs and creates a PBAC memberof >> task that will correct an upgrade. >> >> rob > > I found few issues with this patch: > > 1) It needs a rebase, Makefile.am chunk does not apply. Done. > > 2) The patch won't fix "Modify Group membership" privilege issue. The > problem here is that this privilege does not have any permissions > assigned at all. Right, I started looking at the wrong privilege. Fixed. > > 3) The update has failed in my case (on F16): > > # ipa-ldap-updater --upgrade > Upgrading IPA: > [1/8]: stopping directory server > [2/8]: saving configuration > [3/8]: disabling listeners > [4/8]: starting directory server > [5/8]: upgrading server > ipa : ERROR Upgrade failed with Unable to connect to LDAP server ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket > [6/8]: stopping directory server > [7/8]: restoring configuration > [8/8]: starting directory server > done configuring dirsrv. > ipa : INFO IPA upgrade failed. > IPA upgrade failed. > > The socker is there though, no AVC in audit.log either. > # ls /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket > /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket > > Did the update work for you? Yes, it works for me. I think this problem is unrelated to my patch. Might be worth it to check the 389-ds logs to see if it started properly. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-910-2-memberof.patch Type: text/x-patch Size: 7501 bytes Desc: not available URL: From rcritten at redhat.com Wed Dec 7 20:04:53 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 07 Dec 2011 15:04:53 -0500 Subject: [Freeipa-devel] [PATCH] 903 normalize paths in certmonger In-Reply-To: <1323253449.28014.27.camel@balmora.brq.redhat.com> References: <4EB9BC55.1010706@redhat.com> <1323253449.28014.27.camel@balmora.brq.redhat.com> Message-ID: <4EDFC6E5.3050904@redhat.com> Martin Kosek wrote: > On Tue, 2011-11-08 at 18:33 -0500, Rob Crittenden wrote: >> There are times we need to hunt through the certmonger request files >> trying (such as trying to stop tracking a cert). One criteria is the >> cert database and they need to match exactly. We weren't normalizing >> this so something as simple as a trailing slash would cause a match to fail. >> >> Normalize both values to address this. >> >> rob > > Looks good. > > I just found few nitpicks that may be fixed before push: > > 1) I didn't like constructs like this one: > '%s' % os.path.abspath(secdir) OK > > Simple "os.path.abspath(secdir)" would be enough > > 2) I think get_request_id() function documentation should contain > recognized value types: > None: Any type > 1: File path Not sure what you mean. The function takes a tuple and seems fairly well documented to me. > 3) We may want also to normalize path to PW file. This is what we use > now in ipa-server-install: > > 2011-12-07T10:11:25Z DEBUG args=/usr/bin/ipa-getcert start-tracking > -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert > -p /etc/dirsrv/slapd-PKI-IPA//pwdfile.txt > This shoud be enough: > - args.append(passwd_fname) > + args.append(os.path.abspath(passwd_fname)) done rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-903-2-certmonger.patch Type: text/x-patch Size: 2012 bytes Desc: not available URL: From jdennis at redhat.com Thu Dec 8 01:39:20 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 7 Dec 2011 20:39:20 -0500 Subject: [Freeipa-devel] [PATCH 56] ticket 2172 - If "make rpms" fails so will the next make Message-ID: <201112080139.pB81dKQg021782@int-mx12.intmail.prod.int.phx2.redhat.com> If "make rpms" fails it doesn't clean up the rpmbuild directory it created. The next make-lint will also fail because it finds files under rpmbuild. make-lint is invoked by "make rpms", a vicous cycle. The patch contains two sets of changes Include "rpmbuild" in the IGNORE_PATHS list of make-lint. Fix the Makefile to use $(RPMBUILD) consistently, there were a number of hardcoded uses of "rpmbuild" as a direcotry. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0056-ticket-2172-If-make-rpms-fails-so-will-the-next-make.patch Type: text/x-patch Size: 3405 bytes Desc: not available URL: From edewata at redhat.com Thu Dec 8 02:13:38 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 20:13:38 -0600 Subject: [Freeipa-devel] [PATCH] 051 Search facets show translated boolean values In-Reply-To: <4EDF8DB4.2060901@redhat.com> References: <4EDCE525.3030502@redhat.com> <4EDCFF05.60109@redhat.com> <4EDF8DB4.2060901@redhat.com> Message-ID: <4EE01D52.4090904@redhat.com> On 12/7/2011 10:00 AM, Petr Vobornik wrote: > New version attached. ACK and pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Dec 8 02:15:27 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 20:15:27 -0600 Subject: [Freeipa-devel] [PATCH] 325 Fixed matched/unmatched checkboxes in HBAC Test Message-ID: <4EE01DBF.5040002@redhat.com> The checkboxes in HBAC Test run page have been fixed to show/hide matched or unmatched rules. The New Test button has been fixed to deselect the inputs in all facets. The test data has been updated as well. Ticket #388 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0325-Fixed-matched-unmatched-checkboxes-in-HBAC-Test.patch Type: text/x-patch Size: 61558 bytes Desc: not available URL: From simo at redhat.com Thu Dec 8 02:28:24 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 Dec 2011 21:28:24 -0500 Subject: [Freeipa-devel] [Fwd: daemons/ipa-kdb] One liner fix Message-ID: <1323311304.16138.53.camel@willson.li.ssimo.org> I fixed this copy&paste typo as a one-liner ... Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- An embedded message was scrubbed... From: Simo Sorce Subject: daemons/ipa-kdb Date: Thu, 8 Dec 2011 02:27:28 +0000 (UTC) Size: 3207 URL: From simo at redhat.com Thu Dec 8 02:44:22 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 Dec 2011 21:44:22 -0500 Subject: [Freeipa-devel] [PATCH] #2169 Fix PAC Validation Message-ID: <1323312262.16138.55.camel@willson.li.ssimo.org> PAC Validation was not correct for all cases. In order to test this patch you must use the krb5 packages in the ipa-devel repo as they contains some patches that were necessary to fix various issues with s4u2proxy cases including PAC verification. Fixes 2169 Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-472-1-ipa-kdb-Verify-the-correct-checksum-in-PAC-validatio.patch Type: text/x-patch Size: 4642 bytes Desc: not available URL: From edewata at redhat.com Thu Dec 8 02:44:32 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 07 Dec 2011 20:44:32 -0600 Subject: [Freeipa-devel] [PATCH] 326 Added HBAC Test input validation. Message-ID: <4EE02490.20101@redhat.com> The HBAC Test pages have been modified to validate required input before executing the test. Ticket #388 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0326-Added-HBAC-Test-input-validation.patch Type: text/x-patch Size: 5943 bytes Desc: not available URL: From simo at redhat.com Thu Dec 8 02:46:23 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 07 Dec 2011 21:46:23 -0500 Subject: [Freeipa-devel] [PATCH] #2170 Properly sign PACs Message-ID: <1323312383.16138.57.camel@willson.li.ssimo.org> The PAC signing code would fail to add the correct KDC checksum in the cross-realm TGT case. This was discovered while investigating s4u2proxy issues. This patch is dependent on patch 472 for ticket #2169 Fixes #2170 Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-473-1-ipa-kdb-Create-PAC-s-KDC-checksum-with-right-key.patch Type: text/x-patch Size: 4389 bytes Desc: not available URL: From mkosek at redhat.com Thu Dec 8 07:34:43 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Dec 2011 08:34:43 +0100 Subject: [Freeipa-devel] [PATCH 56] ticket 2172 - If "make rpms" fails so will the next make In-Reply-To: <201112080139.pB81dKQg021782@int-mx12.intmail.prod.int.phx2.redhat.com> References: <201112080139.pB81dKQg021782@int-mx12.intmail.prod.int.phx2.redhat.com> Message-ID: <1323329683.16789.0.camel@balmora.brq.redhat.com> On Wed, 2011-12-07 at 20:39 -0500, John Dennis wrote: > If "make rpms" fails it doesn't clean up the rpmbuild directory it created. > The next make-lint will also fail because it finds files under rpmbuild. > make-lint is invoked by "make rpms", a vicous cycle. > > The patch contains two sets of changes > > Include "rpmbuild" in the IGNORE_PATHS list of make-lint. > > Fix the Makefile to use $(RPMBUILD) consistently, there were a number > of hardcoded uses of "rpmbuild" as a direcotry. ACK. Pushed to master, ipa-2-1. Martin From jcholast at redhat.com Thu Dec 8 07:42:47 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 08 Dec 2011 08:42:47 +0100 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4EDF9444.20209@redhat.com> References: <4EDF9444.20209@redhat.com> Message-ID: <4EE06A77.2080700@redhat.com> Dne 7.12.2011 17:28, Jan Cholasta napsal(a): > [PATCH] 65 Configure ssh and sshd during ipa-client-install. > > For ssh, VerifyHostKeyDNS option is enabled. > > For sshd, KerberosAuthentication, GSSAPIAuthentication and UsePAM > options are enabled (this can be disabled using --no-sshd > ipa-client-install option). > Changed this not to implicitly trust DNS, as discussed on yesterday's meeting. You can make SSH trust DNS explicitly using --ssh-trust-dns ipa-client-install option. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-65.1-ssh-install-config-sshd.patch Type: text/x-patch Size: 7249 bytes Desc: not available URL: From abokovoy at redhat.com Thu Dec 8 08:09:22 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Dec 2011 10:09:22 +0200 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4EE06A77.2080700@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> Message-ID: <20111208080922.GA19167@redhat.com> On Thu, 08 Dec 2011, Jan Cholasta wrote: > Dne 7.12.2011 17:28, Jan Cholasta napsal(a): > >[PATCH] 65 Configure ssh and sshd during ipa-client-install. > > > >For ssh, VerifyHostKeyDNS option is enabled. > > > >For sshd, KerberosAuthentication, GSSAPIAuthentication and UsePAM > >options are enabled (this can be disabled using --no-sshd > >ipa-client-install option). > > > > Changed this not to implicitly trust DNS, as discussed on > yesterday's meeting. You can make SSH trust DNS explicitly using > --ssh-trust-dns ipa-client-install option. Looks fine but I have one suggestion. Could you please abstract out paths to /etc/ssh and split its use into two stages: discovery and actual manipulation? The reason for that is the fact that many distributions have sshd installed with configs in either /etc/ssh or /etc/openssh, and from the beginning it would be nice to account for that and avoid patching it later. This is especially important for the ipa-client-install. -- / Alexander Bokovoy From mkosek at redhat.com Thu Dec 8 08:33:21 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Dec 2011 09:33:21 +0100 Subject: [Freeipa-devel] [PATCH] 903 normalize paths in certmonger In-Reply-To: <4EDFC6E5.3050904@redhat.com> References: <4EB9BC55.1010706@redhat.com> <1323253449.28014.27.camel@balmora.brq.redhat.com> <4EDFC6E5.3050904@redhat.com> Message-ID: <1323333201.16789.5.camel@balmora.brq.redhat.com> On Wed, 2011-12-07 at 15:04 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2011-11-08 at 18:33 -0500, Rob Crittenden wrote: > >> There are times we need to hunt through the certmonger request files > >> trying (such as trying to stop tracking a cert). One criteria is the > >> cert database and they need to match exactly. We weren't normalizing > >> this so something as simple as a trailing slash would cause a match to fail. > >> > >> Normalize both values to address this. > >> > >> rob > > > > Looks good. > > > > I just found few nitpicks that may be fixed before push: > > > > 1) I didn't like constructs like this one: > > '%s' % os.path.abspath(secdir) > > OK > > > > > Simple "os.path.abspath(secdir)" would be enough > > > > 2) I think get_request_id() function documentation should contain > > recognized value types: > > None: Any type > > 1: File path > > Not sure what you mean. The function takes a tuple and seems fairly well > documented to me. I meant documenting the tuple parts. But I think it is OK as it is. > > > 3) We may want also to normalize path to PW file. This is what we use > > now in ipa-server-install: > > > > 2011-12-07T10:11:25Z DEBUG args=/usr/bin/ipa-getcert start-tracking > > -d /etc/dirsrv/slapd-PKI-IPA -n Server-Cert > > -p /etc/dirsrv/slapd-PKI-IPA//pwdfile.txt > > This shoud be enough: > > - args.append(passwd_fname) > > + args.append(os.path.abspath(passwd_fname)) > > done > > rob > Hmm, a DIY patch? :-) Rebased, squashed, ACKed and pushed to master, ipa-2-1. Martin From mkosek at redhat.com Thu Dec 8 09:31:17 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Dec 2011 10:31:17 +0100 Subject: [Freeipa-devel] [PATCH] 910 fix memberof for privileges In-Reply-To: <4EDFB572.3090009@redhat.com> References: <4EDE671B.90708@redhat.com> <1323249738.28014.14.camel@balmora.brq.redhat.com> <4EDFB572.3090009@redhat.com> Message-ID: <1323336677.16789.8.camel@balmora.brq.redhat.com> On Wed, 2011-12-07 at 13:50 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Tue, 2011-12-06 at 14:03 -0500, Rob Crittenden wrote: > >> Some privileges were being created after the permissions that were > >> pointing to it causing the memberof to not be generated. > >> > >> This patch reorders things for new installs and creates a PBAC memberof > >> task that will correct an upgrade. > >> > >> rob > > > > I found few issues with this patch: > > > > 1) It needs a rebase, Makefile.am chunk does not apply. > > Done. > > > > > 2) The patch won't fix "Modify Group membership" privilege issue. The > > problem here is that this privilege does not have any permissions > > assigned at all. > > Right, I started looking at the wrong privilege. Fixed. > > > > > 3) The update has failed in my case (on F16): > > > > # ipa-ldap-updater --upgrade > > Upgrading IPA: > > [1/8]: stopping directory server > > [2/8]: saving configuration > > [3/8]: disabling listeners > > [4/8]: starting directory server > > [5/8]: upgrading server > > ipa : ERROR Upgrade failed with Unable to connect to LDAP server ldapi://%2fvar%2frun%2fslapd-IDM-LAB-BOS-REDHAT-COM.socket > > [6/8]: stopping directory server > > [7/8]: restoring configuration > > [8/8]: starting directory server > > done configuring dirsrv. > > ipa : INFO IPA upgrade failed. > > IPA upgrade failed. > > > > The socker is there though, no AVC in audit.log either. > > # ls /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket > > /var/run/slapd-IDM-LAB-BOS-REDHAT-COM.socket > > > > Did the update work for you? > > Yes, it works for me. I think this problem is unrelated to my patch. > Might be worth it to check the 389-ds logs to see if it started properly. > > rob There was still a collision in Makefile.am. Rebased and pushed to master, ipa-2-1. The problem with ipa-ldap-updater is present on F-16 only - we try to connect to socket before it is created by dirsrv. I created a ticket to address this one: https://fedorahosted.org/freeipa/ticket/2175 Martin From sbose at redhat.com Thu Dec 8 11:58:12 2011 From: sbose at redhat.com (Sumit Bose) Date: Thu, 8 Dec 2011 12:58:12 +0100 Subject: [Freeipa-devel] [PATCH] 16 Add a second module init call for newer samba versions Message-ID: <20111208115812.GH2262@localhost.localdomain> Hi, the samba team decided to rename the symbol to initialize a new module (again). This patch adds the new name and keeps the old one. bye, Sumit -------------- next part -------------- From a9036112ca47f14d9f17f665fd6bd3efba9dc7b3 Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Wed, 7 Dec 2011 17:23:53 +0100 Subject: [PATCH] Add a second module init call for newer samba versions --- daemons/ipa-sam/ipa_sam.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/daemons/ipa-sam/ipa_sam.c b/daemons/ipa-sam/ipa_sam.c index 684cd37ef64d3b73bb1feba9ca91f4a4a241af4e..be97cb7c44f98a76208f16baab96e4438ec74eca 100644 --- a/daemons/ipa-sam/ipa_sam.c +++ b/daemons/ipa-sam/ipa_sam.c @@ -3233,3 +3233,9 @@ NTSTATUS samba_module_init(void) return smb_register_passdb(PASSDB_INTERFACE_VERSION, "ipasam", pdb_init_ipasam); } + +NTSTATUS samba_init_module(void) +{ + return smb_register_passdb(PASSDB_INTERFACE_VERSION, "ipasam", + pdb_init_ipasam); +} -- 1.7.6 From abokovoy at redhat.com Thu Dec 8 12:04:39 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Dec 2011 14:04:39 +0200 Subject: [Freeipa-devel] [PATCH] 16 Add a second module init call for newer samba versions In-Reply-To: <20111208115812.GH2262@localhost.localdomain> References: <20111208115812.GH2262@localhost.localdomain> Message-ID: <20111208120438.GC19167@redhat.com> On Thu, 08 Dec 2011, Sumit Bose wrote: > the samba team decided to rename the symbol to initialize a new module > (again). This patch adds the new name and keeps the old one. ACK. :) -- / Alexander Bokovoy From mkosek at redhat.com Thu Dec 8 12:12:39 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Dec 2011 13:12:39 +0100 Subject: [Freeipa-devel] [PATCH] 177 Add connection failure recovery to IPAdmin Message-ID: <1323346359.16789.9.camel@balmora.brq.redhat.com> Recover from connection failures in IPAdmin LDAP bind functions and rather try reconnect in scope of a given timeout instead of giving up after the first failed connection. The recovery fixes ipa-ldap-updater on F-16 which always failed because of a missing dirsrv socket. https://fedorahosted.org/freeipa/ticket/2175 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-177-add-connection-failure-recovery-to-ipadmin.patch Type: text/x-patch Size: 3749 bytes Desc: not available URL: From abokovoy at redhat.com Thu Dec 8 12:36:53 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 8 Dec 2011 14:36:53 +0200 Subject: [Freeipa-devel] [PATCH] 177 Add connection failure recovery to IPAdmin In-Reply-To: <1323346359.16789.9.camel@balmora.brq.redhat.com> References: <1323346359.16789.9.camel@balmora.brq.redhat.com> Message-ID: <20111208123652.GD19167@redhat.com> On Thu, 08 Dec 2011, Martin Kosek wrote: > Recover from connection failures in IPAdmin LDAP bind functions and > rather try reconnect in scope of a given timeout instead of giving > up after the first failed connection. > > The recovery fixes ipa-ldap-updater on F-16 which always failed > because of a missing dirsrv socket. > > https://fedorahosted.org/freeipa/ticket/2175 ACK. I should have looked at a generalized fix when I was doing systemd work... Thanks! -- / Alexander Bokovoy From simo at redhat.com Thu Dec 8 13:01:05 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Dec 2011 08:01:05 -0500 Subject: [Freeipa-devel] [PATCH 56] ticket 2172 - If "make rpms" fails so will the next make In-Reply-To: <201112080139.pB81dKQg021782@int-mx12.intmail.prod.int.phx2.redhat.com> References: <201112080139.pB81dKQg021782@int-mx12.intmail.prod.int.phx2.redhat.com> Message-ID: <1323349265.16138.61.camel@willson.li.ssimo.org> On Wed, 2011-12-07 at 20:39 -0500, John Dennis wrote: > If "make rpms" fails it doesn't clean up the rpmbuild directory it created. > The next make-lint will also fail because it finds files under rpmbuild. > make-lint is invoked by "make rpms", a vicous cycle. > > The patch contains two sets of changes > > Include "rpmbuild" in the IGNORE_PATHS list of make-lint. > > Fix the Makefile to use $(RPMBUILD) consistently, there were a number > of hardcoded uses of "rpmbuild" as a direcotry. Thanks a lot John! I have been lamenting this issue forever, but never found the time to find the cause, thank you very much. Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Thu Dec 8 14:05:26 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Dec 2011 15:05:26 +0100 Subject: [Freeipa-devel] [PATCH] 177 Add connection failure recovery to IPAdmin In-Reply-To: <20111208123652.GD19167@redhat.com> References: <1323346359.16789.9.camel@balmora.brq.redhat.com> <20111208123652.GD19167@redhat.com> Message-ID: <1323353126.16789.15.camel@balmora.brq.redhat.com> On Thu, 2011-12-08 at 14:36 +0200, Alexander Bokovoy wrote: > On Thu, 08 Dec 2011, Martin Kosek wrote: > > Recover from connection failures in IPAdmin LDAP bind functions and > > rather try reconnect in scope of a given timeout instead of giving > > up after the first failed connection. > > > > The recovery fixes ipa-ldap-updater on F-16 which always failed > > because of a missing dirsrv socket. > > > > https://fedorahosted.org/freeipa/ticket/2175 > ACK. > > I should have looked at a generalized fix when I was doing systemd > work... > > Thanks! > I found out that this issue is present both in master and ipa-2-1 branches. Pushed to both. We have to be cautious for this bug as it affects all freeipa updates in F-16. End user can easily overlook this failure as no error is printed to package update log and user would have to investigate ipaupgrade.log to detect this malfunction. A workaround for current F-16 users would be running _online_ dirsrv update: # ipa-ldap-updater --ldapi Martin From pvoborni at redhat.com Thu Dec 8 14:31:01 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 08 Dec 2011 15:31:01 +0100 Subject: [Freeipa-devel] [PATCH] 052 Better displaying of long names in tables and facet headers Message-ID: <4EE0CA25.3090400@redhat.com> Tables columns have computed width. If value in one column is very long it widens the column and shortens others. This change causes that body columns are not aligned with header columns which makes the table less readable. Applying 'word-break: break-all' style breaks the word into multiple lines and solves the problem. Similar problem is in details facet when displaying text values. Very long values widens the table and a horizontal slider is displayed, which is bad. Applying same solution. In facet headers and breadcrumb navigation breaking the pkey looks bad - there should be only on line of pkey. To solve this, the pkey is limited to 63 characters (empirically measured). Long pkeys are cut. Uncut pkey is set as a title to avoid losing information. Whole breadcrumb could be about 140 chars (with current styles). 10 chars is reserved for entity link, 60 for pkey the rest (about 60 (some reservation for '>>')) for parent pkeys. The assumption is that the parent pkeys wouldn't be so long so they won't be cut anyway. Column width calculation in tables was improved. Now it counts with cell spacing, padding, border. It uses these assumptions: cell-spacing: 2px cell-padding: 6px th:right, left; td: left cell-border: th:1px; td:0px It would be better to get these measures dynamically. But right now it is good enough - better than previous calculation. Result: data cells are aligned with their header. This alignment fails if vertical scrollbar is displayed (existing problem). Also added padding to headers in association adder dialog. https://fedorahosted.org/freeipa/ticket/1890 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0052-Better-displaying-of-long-names-in-tables-and-facet-.patch Type: text/x-patch Size: 9123 bytes Desc: not available URL: From mkosek at redhat.com Thu Dec 8 16:45:03 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 08 Dec 2011 17:45:03 +0100 Subject: [Freeipa-devel] [PATCH] 178+179 Add missing managing hosts filtering options Message-ID: <1323362703.16789.17.camel@balmora.brq.redhat.com> Host object has a virtual attribute "managing" containing all hosts it manages (governed by managedBy attribute). This patch also adds standard membership filtering options: --man-hosts=HOSTS: Only hosts managing _all_ HOSTS are returned --not-man-hosts=HOSTS: Only hosts which do not manage _any_ host in HOSTS are returned https://fedorahosted.org/freeipa/ticket/1675 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-178-fix-ldap2-combine_filters.patch Type: text/x-patch Size: 1194 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-179-add-missing-managing-hosts-filtering-options.patch Type: text/x-patch Size: 10660 bytes Desc: not available URL: From jhrozek at redhat.com Thu Dec 8 16:52:45 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 8 Dec 2011 17:52:45 +0100 Subject: [Freeipa-devel] Design discussion: autofs integration Message-ID: <20111208165245.GI20911@zeppelin.brq.redhat.com> Hi, I have created a wiki page summarizing my design proposal on integrating SSSD with automounter: https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration Feedback is much appreciated - a reply to this email would probably work best. The target of this work is 1.8 Thank you! From jdennis at redhat.com Thu Dec 8 20:36:17 2011 From: jdennis at redhat.com (John Dennis) Date: Thu, 8 Dec 2011 15:36:17 -0500 Subject: [Freeipa-devel] [PATCH 57] update i18n pot file for branch ipa-2-1 Message-ID: <201112082036.pB8KaH0D011647@int-mx12.intmail.prod.int.phx2.redhat.com> -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0057-update-i18n-pot-file-for-branch-ipa-2-1.patch Type: text/x-patch Size: 326873 bytes Desc: not available URL: From jdennis at redhat.com Thu Dec 8 21:09:24 2011 From: jdennis at redhat.com (John Dennis) Date: Thu, 8 Dec 2011 16:09:24 -0500 Subject: [Freeipa-devel] [PATCH 58] update i18n pot file for branch master Message-ID: <201112082109.pB8L9O7t022694@int-mx02.intmail.prod.int.phx2.redhat.com> -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0058-update-i18n-pot-file-for-branch-master.patch Type: text/x-patch Size: 343443 bytes Desc: not available URL: From rcritten at redhat.com Thu Dec 8 21:14:38 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Dec 2011 16:14:38 -0500 Subject: [Freeipa-devel] [PATCH] 913 Fix pylint failures on F-16 Message-ID: <4EE128BE.9060609@redhat.com> A few things need to be updated to make the ipa-2-1 branch build in F-16 with pylint. I've updated the example to use the object's default_attribute list instead of using output_params(), this is preferred anyway I also replaced a few instances of add_s() with addEntry() rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-913-pylint.patch Type: text/x-patch Size: 3318 bytes Desc: not available URL: From rcritten at redhat.com Thu Dec 8 21:55:18 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Dec 2011 16:55:18 -0500 Subject: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA In-Reply-To: <1323179668.16141.42.camel@willson.li.ssimo.org> References: <1322797917.22044.108.camel@willson.li.ssimo.org> <4ED8E046.2020603@redhat.com> <1322838624.6745.21.camel@willson.li.ssimo.org> <1323128273.16141.32.camel@willson.li.ssimo.org> <1323179668.16141.42.camel@willson.li.ssimo.org> Message-ID: <4EE13246.1010506@redhat.com> Simo Sorce wrote: > On Mon, 2011-12-05 at 18:37 -0500, Simo Sorce wrote: >> On Fri, 2011-12-02 at 10:10 -0500, Simo Sorce wrote: >>> On Fri, 2011-12-02 at 09:27 -0500, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> Hello all, >>>>> >>>>> with this set of patches it is possible to allow constrained delegation >>>>> of credentials so that a service can impersonate a user when >>> >>> [..] >>> >>>> In the third patch in ipadb_get_delegation_acl() you can just fall >>>> through to the return. >>> >>> Removed useless check. >>> I also noticed I had added the prototype declaration for the new vtable >>> function in the 2nd patch instead of the 3rd where it belongs by >>> mistake. >>> >>> So I fixed that too. >>> >>>> I think the content of this e-mail should be added as a README to the >>>> source tree. >>> >>> Ok, I dumped and adapted the email content into a README file and added >>> it to the third patch. >>> >>> I also fixed the patch names as per policy. >>> >>> Simo. >> >> >> We have discovered a few issues w/ MIT 1.9 and s4u2proxy used outside of >> the 'artificial' test done by kvno. >> >> I pushed a patch to handle part of the problem as a new krb5 package in >> ipa-devel. >> >> Soon we will have a patch for mod_auth_kerb that handles an issue there. >> >> But we still have an unresolved issue when using the adtrust >> functionality and our KDC releases PACs. >> >> The attached patch can be used to deal with that case. As you can see >> this is not intended for production, but can be used until we have a >> better fix on the KDC side. >> >> Simo. > > Rebased patch 468 to apply to current master. > > Simo. > ACK x3 From jdennis at redhat.com Thu Dec 8 21:56:21 2011 From: jdennis at redhat.com (John Dennis) Date: Thu, 08 Dec 2011 16:56:21 -0500 Subject: [Freeipa-devel] String guidelines in Python Message-ID: <4EE13285.7060402@redhat.com> There are a couple of simple things you should be aware of when it comes to using strings in our Python code. 1) If the string will be internationalized (e.g. is marked with _()) and it has more than one format substitution you *MUST* use *named* format specifiers, not positional format specifiers. Here is an example of incorrect usage: _("item %s has %s value") % (name, value) Here is the correct usage: _("item %(name)s has %(value)s value") % {'name':name, 'value':value} -or- _("item %(name)s has %(value)s value") % dict(name=name, value=value} Why does this matter? Word ordering is locale dependent. Translators need the flexibility to reorder the words in the string. If you use positional format substitutions the translator can't reorder the wording. However, if you use named format substitutions the translator has the freedom to reorder the wording. Try to pick names for the for format specifiers which will provide hints to the translator as to meaning of the substitution. 2) If a function or method call has a signature like printf with a format string and a list of optional parameters to be formatted you should pass the format string and the parameters instead of formatting the string and just passing the format string. This is especially relevant to the logging methods. Here is an example of incorrect usage: self.debug("%s has %d items" % (self.name, self.count)) Here is the preferred usage: self.debug("%s has %d items", self.name, self.count) What's the difference and why does it matter? It's an efficiency issue. Many of the log methods will discard the message because it's filtered in some manner. If you pre-format the string you've done needless work if the message is discarded. The log routines will postpone formatting the message as long as it can and only formats the message after it determines the message will indeed be emitted. Other functions accepting a format string and optional parameters may also perform similar optimization. Converting some items into string format has significant cost, why perform that work only to discard it? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Thu Dec 8 22:18:50 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 08 Dec 2011 17:18:50 -0500 Subject: [Freeipa-devel] [PATCHES] Implement support for S4U2Proxy delegation in IPA In-Reply-To: <4EE13246.1010506@redhat.com> References: <1322797917.22044.108.camel@willson.li.ssimo.org> <4ED8E046.2020603@redhat.com> <1322838624.6745.21.camel@willson.li.ssimo.org> <1323128273.16141.32.camel@willson.li.ssimo.org> <1323179668.16141.42.camel@willson.li.ssimo.org> <4EE13246.1010506@redhat.com> Message-ID: <1323382730.4413.8.camel@willson.li.ssimo.org> On Thu, 2011-12-08 at 16:55 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > On Mon, 2011-12-05 at 18:37 -0500, Simo Sorce wrote: > >> On Fri, 2011-12-02 at 10:10 -0500, Simo Sorce wrote: > >>> On Fri, 2011-12-02 at 09:27 -0500, Rob Crittenden wrote: > >>>> Simo Sorce wrote: > >>>>> Hello all, > >>>>> > >>>>> with this set of patches it is possible to allow constrained delegation > >>>>> of credentials so that a service can impersonate a user when > >>> > >>> [..] > >>> > >>>> In the third patch in ipadb_get_delegation_acl() you can just fall > >>>> through to the return. > >>> > >>> Removed useless check. > >>> I also noticed I had added the prototype declaration for the new vtable > >>> function in the 2nd patch instead of the 3rd where it belongs by > >>> mistake. > >>> > >>> So I fixed that too. > >>> > >>>> I think the content of this e-mail should be added as a README to the > >>>> source tree. > >>> > >>> Ok, I dumped and adapted the email content into a README file and added > >>> it to the third patch. > >>> > >>> I also fixed the patch names as per policy. > >>> > >>> Simo. > >> > >> > >> We have discovered a few issues w/ MIT 1.9 and s4u2proxy used outside of > >> the 'artificial' test done by kvno. > >> > >> I pushed a patch to handle part of the problem as a new krb5 package in > >> ipa-devel. > >> > >> Soon we will have a patch for mod_auth_kerb that handles an issue there. > >> > >> But we still have an unresolved issue when using the adtrust > >> functionality and our KDC releases PACs. > >> > >> The attached patch can be used to deal with that case. As you can see > >> this is not intended for production, but can be used until we have a > >> better fix on the KDC side. > >> > >> Simo. > > > > Rebased patch 468 to apply to current master. > > > > Simo. > > > > ACK x3 Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Dec 8 22:26:23 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 08 Dec 2011 17:26:23 -0500 Subject: [Freeipa-devel] [PATCH] 906 Add SELinux user mapping framework. In-Reply-To: <4ED560A5.7000804@redhat.com> References: <4ECD6D4F.600@redhat.com> <20111123230047.GB14772@redhat.com> <20111128171034.GA26611@redhat.com> <4ED560A5.7000804@redhat.com> Message-ID: <4EE1398F.1020406@redhat.com> Rob Crittenden wrote: > Alexander Bokovoy wrote: >> On Thu, 24 Nov 2011, Alexander Bokovoy wrote: >>> On Wed, 23 Nov 2011, Rob Crittenden wrote: >>>> This will allow one to define what SELinux context a given user gets >>>> on a given machine. A rule can contain a set of users and hosts or it >>>> can point to an existing HBAC rule that defines them. >>>> >>>> https://fedorahosted.org/freeipa/ticket/755 >>> I read through the patch, will need to test it later this week. I >>> basically have two minor points: >>> >>> 1. Split charachter in the SE Linux user map order. >>>> + >>>> + Define SELinux user map order: >>>> + ipa config-mod >>>> --ipaselinuxusermaporder='guest_u:s0$xguest_u:s0$user_u:s0-s0:c0.c1023$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023' >>>> >>>> """) >>> $ can be considered 'active' character in all shells in a sense it >>> changes treatment of following characters from the shell perspective >>> and therefore will always require shielding from the shell's >>> influence. This increases likelyhood of error from a user side. >>> >>> Maybe / would be more neutral character? >>> >>> As you said on IRC, people might have religious feeling about >>> separators but tricking users into always thinking about >>> escaping/single quoting is equally bad. >>> >>> 2. We have two possible ways to address named properties in MagicDict >>> and NameSpace objects -- through explicit attribute use and through >>> the dictionary key. I guess for the cases when we know the attribute >>> name in advance, it would perhaps be preferrable to use the former >>> style: >>> >>>> + def pre_callback(self, ldap, dn, *keys, **options): >>>> + kw = dict(seealso=dn) >>>> + _entries = api.Command['selinuxusermap_find'](None, **kw) >>> this would be >>> _entries = api.Command.selinuxusermap_find(None, **kw) >>> >>> Other than those two minor points, the patch looks very good. I'm >>> going to give it a run on Friday. >> I tested the patch and it works for me on a new install. On upgrade of >> existing installation I've got few errors during run of >> ipa-ldap-updater for SELinux schema changes. Unfortunately, didn't >> save the log as it was 2.1 -> 2.99 upgrade as well. >> > > It turns out that other characters are just as troublesome and require > escaping (space and \). I"m going to leave it as $ unless someone comes > up with something better that the shell isn't going to whine about. > > I fixed some other minor issues and rebased. > > Upgrading isn't really testable at this point yet, other things in 3.0 > need to be addressed as well. We have a separate ticket to look into the > schema updates so I've removed the update file for now. > > rob Rebased patch rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-906-3-selinux.patch Type: text/x-patch Size: 66673 bytes Desc: not available URL: From nalin at redhat.com Thu Dec 8 23:07:30 2011 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 8 Dec 2011 18:07:30 -0500 Subject: [Freeipa-devel] [PATCH] 913 Fix pylint failures on F-16 In-Reply-To: <4EE128BE.9060609@redhat.com> References: <4EE128BE.9060609@redhat.com> Message-ID: <20111208230730.GC1054@redhat.com> On Thu, Dec 08, 2011 at 04:14:38PM -0500, Rob Crittenden wrote: > A few things need to be updated to make the ipa-2-1 branch build in > F-16 with pylint. > > I've updated the example to use the object's default_attribute list > instead of using output_params(), this is preferred anyway > > I also replaced a few instances of add_s() with addEntry() Ack: pylint is happy on my F-17 box. Nalin From edewata at redhat.com Fri Dec 9 07:02:42 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 01:02:42 -0600 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173 Create per-type DNS API In-Reply-To: <1322498136.12794.22.camel@balmora.brq.redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> Message-ID: <4EE1B292.90501@redhat.com> On 11/28/2011 10:35 AM, Martin Kosek wrote: > I have prepared a working prototype of the new structured DNS API. It > may still have rough edges (and unit tests are not ready), but it will > provide a base for discussion and for WebUI folks - so that they can > start development of the new DNS WebUI API. > > The patch takes advantage of the DNS refactor I did in 172. For all > supported non-DNSSEC RR types, the following commands are available: For the rest of the record types will there be new commands like below eventually or should we use the dnsrecord command? > dnsrecord-show ZONE NAME > dnsrecord-add ZONE NAME > dnsrecord-mod ZONE NAME VALUE Here's how the commands can be used in the DNS records list page: http://edewata.fedorapeople.org/freeipa/install/ui/#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=example.com As discussed in ticket #2094 we will add paging support for this page. This is done by calling dnsrecord-find --pkey-only to get all primary keys, then call a batch of dnsrecord-show to get full data of the records being displayed in the current page. I don't think we want to use the new dnsrecord-show here because we want to get all record types and since the space is limited we will just show the raw data. Click the Add link on the top of the page. The dialog box could be modified such that when you select a Record Type instead of showing the same Data field it will show the proper fields for the selected type. Then when you submit it will call the new dnsrecord-add command. Also discussed in #2094, we'll only have one checkbox for each record name instead of one for each value. So in this page we can only delete the entire record entry. This will be done using the existing dnsrecord-del command. And then the details page: http://edewata.fedorapeople.org/freeipa/install/ui/#dns=dnsrecord&identity=dns&navigation=identity&dnsrecord-facet=default&dnsrecord-pkey=testrec&dnszone-pkey=example.com Right now we use a single text field for each raw data. The first option is we could modify this page to use a table for each type, similar to HBAC/sudo rule. For example: SRV Records x | Priority | Weight | Port | Target [Delete] [Add] ------------------------------------------------------- x | 0 | 100 | 88 | test The content of the table will be obtained using the new dnsrecord-show. The add dialog will show the fields for the type and it will call the new dnsrecord-add command. Deletion will be done using the existing dnsrecord-del command. The other option is to keep the existing style (without tables) but instead of a single text field for each record value we will show the values in separate fields. For example: SRV Records Target: [test ] Port: [88 ] [Delete] Priority: [0 ] Weight: [100 ] [Add] When you click Update, the UI will have to translate the changes into add, modify, and delete operations. The add and modify will be done using the new dnsrecord-add/mod command. The delete will be done using the existing dnsrecord-del command. Note, regardless of these options when you open the details page the UI could execute up to 20 dnsrecord-show operations since there are 20 possible record types currently listed in the UI. > 1) The commands return a list of structured records (just like *-find > commands) instead of returning just one record. I thought that it may be > more usable this way and consistent with dnsrecord-add/mod/show commands > behavior which returns all records too. Otherwise, we would have to > change the show command API and add VALUE argument, which would specify > a value to be displayed: > dnsrecord-show ZONE NAME VALUE I think for consistency it would be better to call this command dnsrecord-find since it returns multiple entries. We might also be able to add filters in the future. > 2) Raw DNS record value is in the output too. I though it would be > useful to see the raw DNS record value + its parts at one place. Yes, the raw value will be needed for calling dnsrecord-mod or dnsrecord-del command. > 3) The commands are in format dnsrecord-cmd, for example > dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we > want to go this way, I would have to bend the server framework a little > which parses an LDAP object from the command name (LDAP object name is > dnsrecordmx in this case). This is doable, although I am not sure if > this does not have some implications in WebUI side. I agree, the extra dash would be better. When calling a command the UI concatenates entity name and method name with an '_'. In this case the entity name will remain dnsrecord and the RRTYPE will be prepended to the method name. Btw, patch #175 causes a build break: ipalib/parameters.py:718: [E1101, Param.normalize] Generator '__unicode_csv_reader' has no 'next' member -- Endi S. Dewata From edewata at redhat.com Fri Dec 9 07:17:00 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 01:17:00 -0600 Subject: [Freeipa-devel] [PATCH] 052 Better displaying of long names in tables and facet headers In-Reply-To: <4EE0CA25.3090400@redhat.com> References: <4EE0CA25.3090400@redhat.com> Message-ID: <4EE1B5EC.9090104@redhat.com> On 12/8/2011 8:31 AM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/1890 This is an improvement, so it's ACKed. There are some other issues, they can be done separately: 1. Create an HBAC service with a very long name. Open an HBAC rule, add the service, it will widen the table. Same problem with sudo rule. 2. Open the HBAC service you created in #1, the facet header is too long it messes up the tabs. The service name here should be trimmed as well. 3. Delete the HBAC service you created in #1 from command line. Reload the page in #2, it will pop up an error dialog. The content of the dialog should wrap as well. 4. The limit_text() could be useful outside of IPA.facet_header, so it can be made an independent function. 5. The limit_text() returns a string up to max_length+3 because of the additional '...'. It's better to include the '...' in the calculation so the output is not longer than the expected max_length. 6. In widget.js:1104 what are the constants 4 and 14? Can they be combined? -- Endi S. Dewata From edewata at redhat.com Fri Dec 9 07:51:54 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 01:51:54 -0600 Subject: [Freeipa-devel] [PATCH] 327 Fixed problem loading DNS records. Message-ID: <4EE1BE1A.7020000@redhat.com> The DNS records list page was not loaded correctly due to a recent change in HBAC Test. The page has been updated to use the load_all() to show all records in the zone. Ticket #388 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0327-Fixed-problem-loading-DNS-records.patch Type: text/x-patch Size: 2734 bytes Desc: not available URL: From jhrozek at redhat.com Fri Dec 9 08:48:42 2011 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 9 Dec 2011 09:48:42 +0100 Subject: [Freeipa-devel] Design discussion: autofs integration In-Reply-To: <1323388904.2089.16.camel@perseus.themaw.net> References: <20111208165245.GI20911@zeppelin.brq.redhat.com> <1323388904.2089.16.camel@perseus.themaw.net> Message-ID: <20111209084842.GA15086@zeppelin.brq.redhat.com> On Fri, Dec 09, 2011 at 08:01:44AM +0800, Ian Kent wrote: > On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote: > > Hi, > > > > I have created a wiki page summarizing my design proposal on integrating > > SSSD with automounter: > > https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration > > > > Feedback is much appreciated - a reply to this email would probably work > > best. The target of this work is 1.8 > > Thanks for writing this summary, it's excellent. > There's not much I have to say about it because it is already quite > thorough. > > One thing I dislike about the discussion, and while I let it pass in > bugs and mailing list discussions, I think it is wrong to put it in > public design documents. The statement "autofs abuses the nsswitch.conf > configuration file" I find a little offensive. autofs uses that > configuration file and parses only the "automount" entry using the same > semantic behavior as nss, so the word "abuse" is wrong and a little rude > IMHO. I'm sorry -- I didn't mean to offend you and perhaps abuse was a strong word. I've changed the design docs. That said, I'm still not convinced that it is a good idea to use another application's config file. My main concern is that users often mistakenly think that there is a standard glibc interface defined. Also, when the shared config file changes (not that it's likely that nsswitch would change drastically), you're in trouble -- for instance, sudo suffered recently when Fedora changed from using ldap.conf to nslcd.conf > > In the section "The LDAP schema used by autofs" which talks about schema > it is probably worth mentioning the difficulty with the cn attribute > being case insensitive. That introduces problems because key names > (essentially directory names) are case sensitive and I believe that is > the main reason RFC2307bis (as it relates to autofs) was adopted. > Good point, I've included that in the design page. From mkosek at redhat.com Fri Dec 9 09:07:04 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Dec 2011 10:07:04 +0100 Subject: [Freeipa-devel] [PATCH 56] ticket 2172 - If "make rpms" fails so will the next make In-Reply-To: <1323329683.16789.0.camel@balmora.brq.redhat.com> References: <201112080139.pB81dKQg021782@int-mx12.intmail.prod.int.phx2.redhat.com> <1323329683.16789.0.camel@balmora.brq.redhat.com> Message-ID: <1323421624.7177.2.camel@balmora.brq.redhat.com> On Thu, 2011-12-08 at 08:34 +0100, Martin Kosek wrote: > On Wed, 2011-12-07 at 20:39 -0500, John Dennis wrote: > > If "make rpms" fails it doesn't clean up the rpmbuild directory it created. > > The next make-lint will also fail because it finds files under rpmbuild. > > make-lint is invoked by "make rpms", a vicous cycle. > > > > The patch contains two sets of changes > > > > Include "rpmbuild" in the IGNORE_PATHS list of make-lint. > > > > Fix the Makefile to use $(RPMBUILD) consistently, there were a number > > of hardcoded uses of "rpmbuild" as a direcotry. > > ACK. Pushed to master, ipa-2-1. > > Martin John send me a patch to remove old $(RPMBUILD) before it is filled with new content for rpmbuild (attached). I found it quite useful. Pushed under one-liner rule. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Remove-old-RPMROOT-contents-before-it-is-used-for-rp.patch Type: text/x-patch Size: 668 bytes Desc: not available URL: From jkuncar at redhat.com Fri Dec 9 09:11:00 2011 From: jkuncar at redhat.com (Jiri Kuncar) Date: Fri, 09 Dec 2011 04:11:00 -0500 (EST) Subject: [Freeipa-devel] Support for Bind forward zones In-Reply-To: <633334b6-1d73-476d-ba3f-cb5597e5f48b@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <49b03baf-17fd-4860-8e79-82b032fdde6b@zmail13.collab.prod.int.phx2.redhat.com> I have prepared an initial support for forward zones. There is still an open question about global forwarder. The current solution consists in creating forward root zone: 1) `ipa dnszone-add "."` 2) addForwarder.ldif: dn: idnsname=.,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com changetype: modify add: idnsForwarders idnsForwarders: 10.16.255.2 (use your own one) 3) `ldapmodify -Y GSSAPI -f addForwarder.ldif` https://fedorahosted.org/freeipa/ticket/2108 https://bugzilla.redhat.com/show_bug.cgi?id=754433 Jiri -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-jkuncar-0002-Schema-update-idnsAllowSyncPTR-idnsForward___.patch Type: text/x-patch Size: 1747 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bind-dyndb-ldap-jkuncar-0001-Support-bind-forward-zones.patch Type: text/x-patch Size: 3266 bytes Desc: not available URL: From mkosek at redhat.com Fri Dec 9 09:45:41 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Dec 2011 10:45:41 +0100 Subject: [Freeipa-devel] Support for Bind forward zones In-Reply-To: <49b03baf-17fd-4860-8e79-82b032fdde6b@zmail13.collab.prod.int.phx2.redhat.com> References: <49b03baf-17fd-4860-8e79-82b032fdde6b@zmail13.collab.prod.int.phx2.redhat.com> Message-ID: <1323423941.7177.27.camel@balmora.brq.redhat.com> On Fri, 2011-12-09 at 04:11 -0500, Jiri Kuncar wrote: > I have prepared an initial support for forward zones. There is still an open question about global forwarder. The current solution consists in creating forward root zone: > > 1) `ipa dnszone-add "."` > 2) addForwarder.ldif: > dn: idnsname=.,cn=dns,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > changetype: modify > add: idnsForwarders > idnsForwarders: 10.16.255.2 (use your own one) > 3) `ldapmodify -Y GSSAPI -f addForwarder.ldif` > > https://fedorahosted.org/freeipa/ticket/2108 > https://bugzilla.redhat.com/show_bug.cgi?id=754433 > > Jiri I have been thinking about that and as we discussed today I don't like "abusing" a real DNS root zone for purpose of storing bind-dyndb-ldap global. I see 2 issues with this approach: 1) User has to create a real root DNS zone "." with all MUST attributes (SOA, NS records etc.) even though these values are being ignored in bind-dyndb-ldap. 2) With expansion of bind-dyndb-ldap abilities I expect more (global or per-zone) settings to show up. For example any settings related to DNSSEC (keys, etc.). And I don't think we want to place all these to the root zone LDAP object and extend idnsZone objectClass every time we add a global bind-dyndb-ldap setting stored in LDAP. This is my idea of what could be done: 1) Introduce a new objectClass "idnsConfigObject" which would hold all bind-dyndb-ldap global settings attributes. I would add the following attributes: * idnsAllowSyncPTR: global settings with semantics of sync_ptr in named.conf. * dnsForwardPolicy * idnsForwarders * idnsZoneRefresh (zone_refresh argument in named.conf) * idnsPersistentSearch (psearch argument in named.conf) 2) Create a config object in FreeIPA (in replicated space): cn=dns,cn=etc,$SUFFIX 3) Add a support for this global settings object to bind-dyndb-ldap and create a config option in named.conf pointing to the global config base DN: dynamic-db "ipa" { ... arg "config_base cn=dns,cn=etc,dc=example,dc=com"; ... }; 4) Add API for global DNS config to FreeIPA server. Example commands: $ ipa dnsconfig-show $ ipa dnsconfig-mod --forwarders=10.0.0.1,10.0.0.2 --forward-policy=only Martin From abokovoy at redhat.com Fri Dec 9 10:33:39 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 Dec 2011 12:33:39 +0200 Subject: [Freeipa-devel] Support for Bind forward zones In-Reply-To: <1323423941.7177.27.camel@balmora.brq.redhat.com> References: <49b03baf-17fd-4860-8e79-82b032fdde6b@zmail13.collab.prod.int.phx2.redhat.com> <1323423941.7177.27.camel@balmora.brq.redhat.com> Message-ID: <20111209103339.GA1818@redhat.com> On Fri, 09 Dec 2011, Martin Kosek wrote: > This is my idea of what could be done: > 1) Introduce a new objectClass "idnsConfigObject" which would hold all > bind-dyndb-ldap global settings attributes. I would add the following > attributes: > * idnsAllowSyncPTR: global settings with semantics of sync_ptr in > named.conf. > * dnsForwardPolicy > * idnsForwarders > * idnsZoneRefresh (zone_refresh argument in named.conf) > * idnsPersistentSearch (psearch argument in named.conf) > > 2) Create a config object in FreeIPA (in replicated space): > cn=dns,cn=etc,$SUFFIX > > 3) Add a support for this global settings object to bind-dyndb-ldap and > create a config option in named.conf pointing to the global config base > DN: > dynamic-db "ipa" { > ... > arg "config_base cn=dns,cn=etc,dc=example,dc=com"; > ... > }; > > 4) Add API for global DNS config to FreeIPA server. Example commands: > $ ipa dnsconfig-show > $ ipa dnsconfig-mod --forwarders=10.0.0.1,10.0.0.2 --forward-policy=only I agree with the latter approach. Looks cleaner and also allows to properly handle replicated DNS setup. -- / Alexander Bokovoy From abokovoy at redhat.com Fri Dec 9 12:53:29 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 Dec 2011 14:53:29 +0200 Subject: [Freeipa-devel] [PATCH] 913 Fix pylint failures on F-16 In-Reply-To: <20111208230730.GC1054@redhat.com> References: <4EE128BE.9060609@redhat.com> <20111208230730.GC1054@redhat.com> Message-ID: <20111209125328.GA4653@redhat.com> On Thu, 08 Dec 2011, Nalin Dahyabhai wrote: > On Thu, Dec 08, 2011 at 04:14:38PM -0500, Rob Crittenden wrote: > > A few things need to be updated to make the ipa-2-1 branch build in > > F-16 with pylint. > > > > I've updated the example to use the object's default_attribute list > > instead of using output_params(), this is preferred anyway > > > > I also replaced a few instances of add_s() with addEntry() > > Ack: pylint is happy on my F-17 box. Pushed to ipa-2-1. -- / Alexander Bokovoy From pvoborni at redhat.com Fri Dec 9 13:29:08 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Dec 2011 14:29:08 +0100 Subject: [Freeipa-devel] [PATCH] 052 Better displaying of long names in tables and facet headers In-Reply-To: <4EE1B5EC.9090104@redhat.com> References: <4EE0CA25.3090400@redhat.com> <4EE1B5EC.9090104@redhat.com> Message-ID: <4EE20D24.4090204@redhat.com> On 12/09/2011 08:17 AM, Endi Sukma Dewata wrote: > On 12/8/2011 8:31 AM, Petr Vobornik wrote: >> https://fedorahosted.org/freeipa/ticket/1890 > > This is an improvement, so it's ACKed. There are some other issues, they > can be done separately: Pushed to master. Attaching new patch which addresses following issues: > 1. Create an HBAC service with a very long name. Open an HBAC rule, add > the service, it will widen the table. Same problem with sudo rule. > The table wasn't set as 'scrollable'. I didn't find a reason why cell width calculation should be different for scrollable and 'normal', so I unified it and it fixes the problem. > 2. Open the HBAC service you created in #1, the facet header is too long > it messes up the tabs. The service name here should be trimmed as well. The pkey in facet group header is now limited to 20 chars. It would be probably good enough for normal names. It may overlap with with next facet group if current facet group has 1 facet with short name, but I think it isn't a problem now. > 3. Delete the HBAC service you created in #1 from command line. Reload > the page in #2, it will pop up an error dialog. The content of the > dialog should wrap as well. Error dialog now uses word-wrap. > 4. The limit_text() could be useful outside of IPA.facet_header, so it > can be made an independent function. Moved to ipa.js. > 5. The limit_text() returns a string up to max_length+3 because of the > additional '...'. It's better to include the '...' in the calculation so > the output is not longer than the expected max_length. Fixed. > 6. In widget.js:1104 what are the constants 4 and 14? Can they be combined? > Added comments to code. They shouldn't be combined because one applies only if the table is selectable. But thanks for pointing it out - there was actually a little error - the '14' should be in ?: statement and both of the weren't entirely correct. - Fixed 7. When a column has a width set, there is a line (widget.js:1098): width += 16; Why is it there? I'd rather subtract it. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0053-Additional-better-displaying-of-long-names.patch Type: text/x-patch Size: 7792 bytes Desc: not available URL: From simo at redhat.com Fri Dec 9 13:49:46 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 09 Dec 2011 08:49:46 -0500 Subject: [Freeipa-devel] Support for Bind forward zones In-Reply-To: <20111209103339.GA1818@redhat.com> References: <49b03baf-17fd-4860-8e79-82b032fdde6b@zmail13.collab.prod.int.phx2.redhat.com> <1323423941.7177.27.camel@balmora.brq.redhat.com> <20111209103339.GA1818@redhat.com> Message-ID: <1323438586.4413.25.camel@willson.li.ssimo.org> On Fri, 2011-12-09 at 12:33 +0200, Alexander Bokovoy wrote: > On Fri, 09 Dec 2011, Martin Kosek wrote: > > This is my idea of what could be done: > > 1) Introduce a new objectClass "idnsConfigObject" which would hold all > > bind-dyndb-ldap global settings attributes. I would add the following > > attributes: > > * idnsAllowSyncPTR: global settings with semantics of sync_ptr in > > named.conf. > > * dnsForwardPolicy > > * idnsForwarders > > * idnsZoneRefresh (zone_refresh argument in named.conf) > > * idnsPersistentSearch (psearch argument in named.conf) > > > > 2) Create a config object in FreeIPA (in replicated space): > > cn=dns,cn=etc,$SUFFIX > > > > 3) Add a support for this global settings object to bind-dyndb-ldap and > > create a config option in named.conf pointing to the global config base > > DN: > > dynamic-db "ipa" { > > ... > > arg "config_base cn=dns,cn=etc,dc=example,dc=com"; > > ... > > }; > > > > 4) Add API for global DNS config to FreeIPA server. Example commands: > > $ ipa dnsconfig-show > > $ ipa dnsconfig-mod --forwarders=10.0.0.1,10.0.0.2 --forward-policy=only > I agree with the latter approach. Looks cleaner and also allows to > properly handle replicated DNS setup. Me too, except for the location of the configuration, I think it should stay in the root node of the DNS data for simplicity. But this is a very minor point. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Dec 9 14:12:14 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 09:12:14 -0500 Subject: [Freeipa-devel] [PATCH] minor cleanup In-Reply-To: <1323127239.16141.28.camel@willson.li.ssimo.org> References: <1323127239.16141.28.camel@willson.li.ssimo.org> Message-ID: <4EE2173E.1030508@redhat.com> Simo Sorce wrote: > Straightforward cleanup. > Simo. ACK, works for me. rob From ikent at redhat.com Fri Dec 9 00:01:44 2011 From: ikent at redhat.com (Ian Kent) Date: Fri, 09 Dec 2011 08:01:44 +0800 Subject: [Freeipa-devel] Design discussion: autofs integration In-Reply-To: <20111208165245.GI20911@zeppelin.brq.redhat.com> References: <20111208165245.GI20911@zeppelin.brq.redhat.com> Message-ID: <1323388904.2089.16.camel@perseus.themaw.net> On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote: > Hi, > > I have created a wiki page summarizing my design proposal on integrating > SSSD with automounter: > https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration > > Feedback is much appreciated - a reply to this email would probably work > best. The target of this work is 1.8 Thanks for writing this summary, it's excellent. There's not much I have to say about it because it is already quite thorough. One thing I dislike about the discussion, and while I let it pass in bugs and mailing list discussions, I think it is wrong to put it in public design documents. The statement "autofs abuses the nsswitch.conf configuration file" I find a little offensive. autofs uses that configuration file and parses only the "automount" entry using the same semantic behavior as nss, so the word "abuse" is wrong and a little rude IMHO. In the section "The LDAP schema used by autofs" which talks about schema it is probably worth mentioning the difficulty with the cn attribute being case insensitive. That introduces problems because key names (essentially directory names) are case sensitive and I believe that is the main reason RFC2307bis (as it relates to autofs) was adopted. Ian From pvoborni at redhat.com Fri Dec 9 14:58:05 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Dec 2011 15:58:05 +0100 Subject: [Freeipa-devel] [PATCH] 325 Fixed matched/unmatched checkboxes in HBAC Test In-Reply-To: <4EE01DBF.5040002@redhat.com> References: <4EE01DBF.5040002@redhat.com> Message-ID: <4EE221FD.2000500@redhat.com> On 12/08/2011 03:15 AM, Endi Sukma Dewata wrote: > The checkboxes in HBAC Test run page have been fixed to show/hide > matched or unmatched rules. The New Test button has been fixed to > deselect the inputs in all facets. The test data has been updated > as well. > > Ticket #388 > ACK and pushed to master Existing minor issue which can be fixed later: 1) matched checkbox has name 'disabled' -- Petr Vobornik From pvoborni at redhat.com Fri Dec 9 14:58:21 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Dec 2011 15:58:21 +0100 Subject: [Freeipa-devel] [PATCH] 326 Added HBAC Test input validation. In-Reply-To: <4EE02490.20101@redhat.com> References: <4EE02490.20101@redhat.com> Message-ID: <4EE2220D.8090404@redhat.com> On 12/08/2011 03:44 AM, Endi Sukma Dewata wrote: > The HBAC Test pages have been modified to validate required input > before executing the test. > > Ticket #388 > ACK and pushed to master - it's an improvement Possible future enhancement: I would rather see more specific error message. The message should contain which values are missing. In this implementation if user misses to fill more than one value, he is informed only about the first missing value (by redirection to the its facet) for the others he has to check by hand (or realize it in mind) or by couple trial-error runs. In details facet it is fine because invalid or missing values are highlighted by validation messages near widgets. -- Petr Vobornik From pvoborni at redhat.com Fri Dec 9 14:58:25 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Dec 2011 15:58:25 +0100 Subject: [Freeipa-devel] [PATCH] 327 Fixed problem loading DNS records. In-Reply-To: <4EE1BE1A.7020000@redhat.com> References: <4EE1BE1A.7020000@redhat.com> Message-ID: <4EE22211.80007@redhat.com> On 12/09/2011 08:51 AM, Endi Sukma Dewata wrote: > The DNS records list page was not loaded correctly due to a recent > change in HBAC Test. The page has been updated to use the load_all() > to show all records in the zone. > > Ticket #388 > ACK and pushed to master The HBAC test page is completed, right? Can I add all commit ids to trac and close the ticket? -- Petr Vobornik From ohamada at redhat.com Fri Dec 9 15:05:42 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Fri, 09 Dec 2011 16:05:42 +0100 Subject: [Freeipa-devel] [PATCH] 5 User-add random password support In-Reply-To: <1322559082.32073.13.camel@balmora.brq.redhat.com> References: <4ECE5ABE.3060207@redhat.com> <4ECE760A.7000401@redhat.com> <1322559082.32073.13.camel@balmora.brq.redhat.com> Message-ID: <4EE223C6.1070908@redhat.com> On 11/29/2011 10:31 AM, Martin Kosek wrote: > On Thu, 2011-11-24 at 17:51 +0100, Ondrej Hamada wrote: >> On 11/24/2011 03:54 PM, Ondrej Hamada wrote: >>> https://fedorahosted.org/freeipa/ticket/1979 >>> >>> I've used code from ipalib/plugins/host.py to add support for >>> random >>> password generation. The '--random' option is now available in >>> user-add and user-mod commands. If both the 'password' and 'random' >>> options are used the 'random' option will be ignored. >>> >>> > Functionally, it works OK. I would just like to propose few > improvements: > > 1) Minor API version in VERSION file should be bumped since you add a > new option > 2) We should add some tests exercising this new functionality so that we > can detect regressions early > 3) (optional) I am thinking if the passwords we generate are not very > user friendly. I would love to see user's face when he is told that his > new password is 5QU;8l2%]y"? . > > While this is may be OK for hosts bulk passwords which are only > manipulated by admins, we may want to develop more user friendly > passwords in the user plugin. > > Martin > https://fedorahosted.org/freeipa/ticket/1979 I've used code from ipalib/plugins/host.py to add support for random password generation. The '--random' option is now available in user-add and user-mod commands. If both the 'password' and 'random' options are used the 'random' option will be ignored. Two test cases were added to unit test's module test_user_plugin.py - they test creating and modifying user with random password. Two fuzzy tests were added: test for password(string that doesn't start or end with whitespace and doesn't containt other whitespace than ' ') and for whatever string(because of krbextradata). I've slightly modified ipa_generate_password in order to make passwords for users more user-friendly(reduce number of non-letters). It has two optional parameters now - first one is string of characters that should be used for generating the passwd and second one is length of password. If none parameter is set default values will be used so there's no need to modify other plugins that use random password generator. -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-5-3-User-add-random-password-support.patch Type: text/x-patch Size: 17660 bytes Desc: not available URL: From abokovoy at redhat.com Fri Dec 9 15:25:17 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 Dec 2011 17:25:17 +0200 Subject: [Freeipa-devel] [PATCH] 906 Add SELinux user mapping framework. In-Reply-To: <4EE1398F.1020406@redhat.com> References: <4ECD6D4F.600@redhat.com> <20111123230047.GB14772@redhat.com> <20111128171034.GA26611@redhat.com> <4ED560A5.7000804@redhat.com> <4EE1398F.1020406@redhat.com> Message-ID: <20111209152516.GA11184@redhat.com> On Thu, 08 Dec 2011, Rob Crittenden wrote: > >>>Other than those two minor points, the patch looks very good. I'm > >>>going to give it a run on Friday. > >>I tested the patch and it works for me on a new install. On upgrade of > >>existing installation I've got few errors during run of > >>ipa-ldap-updater for SELinux schema changes. Unfortunately, didn't > >>save the log as it was 2.1 -> 2.99 upgrade as well. > >> > > > >It turns out that other characters are just as troublesome and require > >escaping (space and \). I"m going to leave it as $ unless someone comes > >up with something better that the shell isn't going to whine about. > > > >I fixed some other minor issues and rebased. > > > >Upgrading isn't really testable at this point yet, other things in 3.0 > >need to be addressed as well. We have a separate ticket to look into the > >schema updates so I've removed the update file for now. > > > >rob > > Rebased patch ACK. Pushed to master. I had to fix freeipa.spec.in to have proper samba4-devel dependency now that ipa-devel repository includes fixed samba4 package (instead of samba-4.0). -- / Alexander Bokovoy From pvoborni at redhat.com Fri Dec 9 15:43:06 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 09 Dec 2011 16:43:06 +0100 Subject: [Freeipa-devel] [PATCH] 054 Reordered facets in ACI Message-ID: <4EE22C8A.2040105@redhat.com> Facets in ACI have new order: * Roles: members, privileges, settings * Privileges: permissions, settings, roles * Permissions: settings, privileges https://fedorahosted.org/freeipa/ticket/2104 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0054-Reordered-facets-in-ACI.patch Type: text/x-patch Size: 1684 bytes Desc: not available URL: From mkosek at redhat.com Fri Dec 9 15:47:23 2011 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 09 Dec 2011 16:47:23 +0100 Subject: [Freeipa-devel] [PATCH] 180 Add missing --pkey-only option for selfservice and Message-ID: <1323445643.7177.45.camel@balmora.brq.redhat.com> pkey-only functionality has to be implemented separately for these modules as they are based on crud.Search instead of standard LDAPSearch. Delegation commands were modified in the process to allow ACIs without 'memberof' as delegation ACIs. This check is no longer needed since delegation ACI prefixe ensures the ACI type. https://fedorahosted.org/freeipa/ticket/2092 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-180-add-missing-pkey-only-option-for-selfservice-and-del.patch Type: text/x-patch Size: 17508 bytes Desc: not available URL: From rcritten at redhat.com Fri Dec 9 19:11:11 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 14:11:11 -0500 Subject: [Freeipa-devel] [PATCH] 899 more context with attribute in error message In-Reply-To: <1323248201.28014.8.camel@balmora.brq.redhat.com> References: <4EA1C7EB.8010003@redhat.com> <1323248201.28014.8.camel@balmora.brq.redhat.com> Message-ID: <4EE25D4F.8050101@redhat.com> Martin Kosek wrote: > On Fri, 2011-10-21 at 15:28 -0400, Rob Crittenden wrote: >> Depending on the context and how you are using input (-- options or >> set/addattr) you might get a different attribute name in the error >> message. This patch tries to clear that up a bit. >> >> See the ticket for some test cases. >> >> rob > > I found few issues with this patch: > > 1) This patch cannot be applied. First chunk (frontend.py) was already > pushed in other patch > > 2) Actually, this patch did not work for me: > > # ipa pwpolicy-mod --setattr=krbpwdmaxfailure=-1 > ipa: ERROR: invalid 'krbpwdmaxfailure': must be at least 0 > > cli_name still did not show up. > > I also see that you did the change for Int onlu. I guess we should fix > all parameters, for example StrEnum, etc.: > > # ipa sudorule-add foo --usercat=bar > ipa: ERROR: invalid 'usercat': must be one of (u'all',) > # ipa sudorule-add foo --setattr=usercategory=bar > ipa: ERROR: invalid 'usercategory': must be one of (u'all',) > > Martin > This must have gotten fixed by some other patch. This is the behavior we want. When using a named option we should return that in the error message. When using an attribute name we should return that. I think this ticket can be closed. rob From rcritten at redhat.com Fri Dec 9 19:14:41 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 14:14:41 -0500 Subject: [Freeipa-devel] [PATCH] 0033 Check all LDAP servers during IPA discovery In-Reply-To: <20111207124224.GB32281@redhat.com> References: <20111114104800.GA3927@redhat.com> <4ED8F47D.7060905@redhat.com> <20111207124224.GB32281@redhat.com> Message-ID: <4EE25E21.4050200@redhat.com> Alexander Bokovoy wrote: > On Fri, 02 Dec 2011, Rob Crittenden wrote: >> Alexander Bokovoy wrote: >>> Hi, >>> >>> This is patch proposal, I haven't checked it with multiple servers >>> setup yet. >>> >>> When discovering IPA LDAP servers through DNS records, look through all >>> servers found until first success. A master might be not available or >>> denied access due to anonymous binds disabled, for example, but >>> replica may succeed. >>> >>> Ticket #1827 >>> https://fedorahosted.org/freeipa/ticket/1827 >> >> Needs a rebase. >> >> This works fine but I wonder if someone specifies --server on the >> command-line if we should try only that server and fail if we can't >> connect. I can see someone using that so they can specify which >> server the client uses. > Rebase attached. > > If --server is specified, DNS discovery is bypassed in search() and > self.server will have the value of --server. That means the code I > changed will still work as parse_items() accepts a single item as > well. I don't see the --server code included in the patch. rob From simo at redhat.com Fri Dec 9 19:21:10 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 09 Dec 2011 14:21:10 -0500 Subject: [Freeipa-devel] [PATCH] minor cleanup In-Reply-To: <4EE2173E.1030508@redhat.com> References: <1323127239.16141.28.camel@willson.li.ssimo.org> <4EE2173E.1030508@redhat.com> Message-ID: <1323458470.4413.34.camel@willson.li.ssimo.org> On Fri, 2011-12-09 at 09:12 -0500, Rob Crittenden wrote: > Simo Sorce wrote: > > Straightforward cleanup. > > Simo. > > ACK, works for me. Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Fri Dec 9 19:46:46 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 14:46:46 -0500 Subject: [Freeipa-devel] [PATCH] 5 User-add random password support In-Reply-To: <4EE223C6.1070908@redhat.com> References: <4ECE5ABE.3060207@redhat.com> <4ECE760A.7000401@redhat.com> <1322559082.32073.13.camel@balmora.brq.redhat.com> <4EE223C6.1070908@redhat.com> Message-ID: <4EE265A6.7090802@redhat.com> Ondrej Hamada wrote: > On 11/29/2011 10:31 AM, Martin Kosek wrote: >> On Thu, 2011-11-24 at 17:51 +0100, Ondrej Hamada wrote: >>> On 11/24/2011 03:54 PM, Ondrej Hamada wrote: >>>> https://fedorahosted.org/freeipa/ticket/1979 >>>> >>>> I've used code from ipalib/plugins/host.py to add support for >>>> random >>>> password generation. The '--random' option is now available in >>>> user-add and user-mod commands. If both the 'password' and 'random' >>>> options are used the 'random' option will be ignored. >>>> >>>> >> Functionally, it works OK. I would just like to propose few >> improvements: >> >> 1) Minor API version in VERSION file should be bumped since you add a >> new option >> 2) We should add some tests exercising this new functionality so that we >> can detect regressions early >> 3) (optional) I am thinking if the passwords we generate are not very >> user friendly. I would love to see user's face when he is told that his >> new password is 5QU;8l2%]y"? . >> >> While this is may be OK for hosts bulk passwords which are only >> manipulated by admins, we may want to develop more user friendly >> passwords in the user plugin. >> >> Martin >> > https://fedorahosted.org/freeipa/ticket/1979 > > I've used code from ipalib/plugins/host.py to add > support for random password generation. The > '--random' option is now available in user-add and > user-mod commands. If both the 'password' and 'random' > options are used the 'random' option will be ignored. > > Two test cases were added to unit test's module > test_user_plugin.py - they test creating and modifying > user with random password. Two fuzzy tests were added: > test for password(string that doesn't start or end with > whitespace and doesn't containt other whitespace than > ' ') and for whatever string(because of krbextradata). > > I've slightly modified ipa_generate_password in order > to make passwords for users more user-friendly(reduce > number of non-letters). It has two optional parameters > now - first one is string of characters that should be > used for generating the passwd and second one is length > of password. If none parameter is set default values will > be used so there's no need to modify other plugins that > use random password generator. This is very, very close. I just have a couple of observations: 1. Would it be clearer if in user.py you set the character set to: string.digits + string.ascii_letters + '_,.@' ? I gather you are excluding most of the characters that would cause the shell grief on purpose, right? You can probably add in +, - and = though. 2. Indention in ipa_generate_password() is a bit off. 3. Rather than fuzzy_string() I think you should define something like fuzzy_dergeneralizedtime() that specifies the time format in those kerberos time attributes. krbextradata is probably fine as a string. rob From abokovoy at redhat.com Fri Dec 9 20:27:08 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 9 Dec 2011 22:27:08 +0200 Subject: [Freeipa-devel] [PATCH] 0033 Check all LDAP servers during IPA discovery In-Reply-To: <4EE25E21.4050200@redhat.com> References: <20111114104800.GA3927@redhat.com> <4ED8F47D.7060905@redhat.com> <20111207124224.GB32281@redhat.com> <4EE25E21.4050200@redhat.com> Message-ID: <20111209202707.GA12414@redhat.com> On Fri, 09 Dec 2011, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >On Fri, 02 Dec 2011, Rob Crittenden wrote: > >>Alexander Bokovoy wrote: > >>>Hi, > >>> > >>>This is patch proposal, I haven't checked it with multiple servers > >>>setup yet. > >>> > >>>When discovering IPA LDAP servers through DNS records, look through all > >>>servers found until first success. A master might be not available or > >>>denied access due to anonymous binds disabled, for example, but > >>>replica may succeed. > >>> > >>>Ticket #1827 > >>>https://fedorahosted.org/freeipa/ticket/1827 > >> > >>Needs a rebase. > >> > >>This works fine but I wonder if someone specifies --server on the > >>command-line if we should try only that server and fail if we can't > >>connect. I can see someone using that so they can specify which > >>server the client uses. > >Rebase attached. > > > >If --server is specified, DNS discovery is bypassed in search() and > >self.server will have the value of --server. That means the code I > >changed will still work as parse_items() accepts a single item as > >well. > > I don't see the --server code included in the patch. Because it is not needed. search() method gets value of --server option passed as server named argument. If it is not None, the whole discovery is avoided and that value is assigned to self.server. self.server is then parsed via parse_items() and iterated over -- with a single iteration in the case --server is specified. -- / Alexander Bokovoy From rcritten at redhat.com Fri Dec 9 20:55:47 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 15:55:47 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <1322813820.9851.10.camel@balmora.brq.redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> Message-ID: <4EE275D3.3030508@redhat.com> Martin Kosek wrote: > On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: >>>> I have prepared a working prototype of the new structured DNS API. It >>>> may still have rough edges (and unit tests are not ready), but it will >>>> provide a base for discussion and for WebUI folks - so that they can >>>> start development of the new DNS WebUI API. >>>> >>>> The patch takes advantage of the DNS refactor I did in 172. For all >>>> supported non-DNSSEC RR types, the following commands are available: >>>> >>>> dnsrecord-show ZONE NAME >>>> dnsrecord-add ZONE NAME >>>> dnsrecord-mod ZONE NAME VALUE >>>> >>>> This is an example of the new API in action: >>>> >>>> # ipa dnsrecord-show example.com foo >>>> Record name: foo >>>> A record: 10.0.0.1 >>>> >>>> # ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com." >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 1 >>>> ---------------------------- >>>> >>>> # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger="foo.example.com." >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 1 foo.example.com. >>>> Preference: 1 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> # ipa dnsrecordmx-show example.com foo >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 1 foo.example.com. >>>> Preference: 1 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> >>>> There is an interactive wizard to help user modify a record without >>>> specifying an updated value first. If there is just one (MX) record, no >>>> wizard would be run. >>>> >>>> # ipa dnsrecordmx-mod example.com foo --preference=2 >>>> Which MX record would you like to modify? >>>> >>>> [1]: 0 foo.example.com. >>>> [2]: 1 foo.example.com. >>>> >>>> DNS record number: 2 >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 2 foo.example.com. >>>> Preference: 2 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> # ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3 >>>> MX record: 0 foo.example.com. >>>> Preference: 0 >>>> Exchanger: foo.example.com. >>>> >>>> MX record: 3 foo.example.com. >>>> Preference: 3 >>>> Exchanger: foo.example.com. >>>> ---------------------------- >>>> Number of entries returned 2 >>>> ---------------------------- >>>> >>>> >>>> There are few open questions I am still thinking about: >>>> >>>> 1) The commands return a list of structured records (just like *-find >>>> commands) instead of returning just one record. I thought that it may be >>>> more usable this way and consistent with dnsrecord-add/mod/show commands >>>> behavior which returns all records too. Otherwise, we would have to >>>> change the show command API and add VALUE argument, which would specify >>>> a value to be displayed: >>>> dnsrecord-show ZONE NAME VALUE >>>> >>>> 2) Raw DNS record value is in the output too. I though it would be >>>> useful to see the raw DNS record value + its parts at one place. >>>> >>>> 3) The commands are in format dnsrecord-cmd, for example >>>> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we >>>> want to go this way, I would have to bend the server framework a little >>>> which parses an LDAP object from the command name (LDAP object name is >>>> dnsrecordmx in this case). This is doable, although I am not sure if >>>> this does not have some implications in WebUI side. >>>> >>>> Martin >>> >>> I rebased both patches to the most recent master. Adding CSVs now works >>> ok again (with the fix in 175): >>> >>> # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 >>> Record name: foo >>> A record: 10.0.0.1, 10.0.0.2 >>> >>> Martin >> > > Rob, thank you for the review! What do you think about the 3 open > questions I posted above? > >> I think some abbreviations can be eliminated: >> >> siz -> size >> alt -> altitude > > Sure, this can be fixed. > >> >> For MX record (and probably KX) you can make preference required. It >> should fill in without prompting since it has a default. This way it >> will show as required in the UI. > > Right, we don't want to run into issues we had with user fields. > >> >> PTRRecord doc I think would read better as "The hostname this reverse >> record points to" > > Ok. Btw do you think it would be good to document this way all these new > DNSRecord part parameters? As I checked with Petr, these would be shown > in the UI - so the UI user would benefit from it. But it will require a > lot of writing and RFC study :-) > >> >> I'm not sure I follow the makeapi change. I see the new entry types in >> API.txt but this makeapi seems to suggest the DNS api is not checked. > > This fix is in validate_doc(), which tries to check that all our > commands have proper __doc__ string. It fails with the new DNS API > commands (dnsrecordmx-add etc.) because it cannot find class definitions > in dns.py. This is expected as I generate all these LDAP command classes > on the fly from new DNSRecord parameters. > > Martin > >> >> Otherwise generally looks good. >> >> rob > > Build not working: ./make-lint ipalib/parameters.py:718: [E1101, Param.normalize] Generator '__unicode_csv_reader' has no 'next' member I found this works ok and adding records is definitely clearer but it seems odd to add with one command and delete/find with another. I could get used to it I suppose. Help per command doesn't work: $ ipa help dnsrecorda ipa: ERROR: no command nor help topic 'dnsrecorda' Not sure if we want specific help or simply point back to dnsrecord which might be a bit overwhelming. $ ipa dnsrecordloc-add --help This is is a significant improvement! rob From simo at redhat.com Fri Dec 9 20:58:13 2011 From: simo at redhat.com (Simo Sorce) Date: Fri, 09 Dec 2011 15:58:13 -0500 Subject: [Freeipa-devel] [PATCH] 16 Add a second module init call for newer samba versions In-Reply-To: <20111208120438.GC19167@redhat.com> References: <20111208115812.GH2262@localhost.localdomain> <20111208120438.GC19167@redhat.com> Message-ID: <1323464293.4413.36.camel@willson.li.ssimo.org> On Thu, 2011-12-08 at 14:04 +0200, Alexander Bokovoy wrote: > On Thu, 08 Dec 2011, Sumit Bose wrote: > > the samba team decided to rename the symbol to initialize a new module > > (again). This patch adds the new name and keeps the old one. > ACK. :) Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Fri Dec 9 21:21:48 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 15:21:48 -0600 Subject: [Freeipa-devel] [PATCH] 178+179 Add missing managing hosts filtering options In-Reply-To: <1323362703.16789.17.camel@balmora.brq.redhat.com> References: <1323362703.16789.17.camel@balmora.brq.redhat.com> Message-ID: <4EE27BEC.6090607@redhat.com> On 12/8/2011 10:45 AM, Martin Kosek wrote: > Host object has a virtual attribute "managing" containing all hosts > it manages (governed by managedBy attribute). This patch also adds > standard membership filtering options: > --man-hosts=HOSTS: Only hosts managing _all_ HOSTS are returned > --not-man-hosts=HOSTS: Only hosts which do not manage _any_ host > in HOSTS are returned > > https://fedorahosted.org/freeipa/ticket/1675 ACK, it works for me. I'll update the UI to use the new option. -- Endi S. Dewata From edewata at redhat.com Fri Dec 9 22:04:47 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 16:04:47 -0600 Subject: [Freeipa-devel] [PATCH] 178+179 Add missing managing hosts filtering options In-Reply-To: <4EE27BEC.6090607@redhat.com> References: <1323362703.16789.17.camel@balmora.brq.redhat.com> <4EE27BEC.6090607@redhat.com> Message-ID: <4EE285FF.7080202@redhat.com> On 12/9/2011 3:21 PM, Endi Sukma Dewata wrote: > On 12/8/2011 10:45 AM, Martin Kosek wrote: >> Host object has a virtual attribute "managing" containing all hosts >> it manages (governed by managedBy attribute). This patch also adds >> standard membership filtering options: >> --man-hosts=HOSTS: Only hosts managing _all_ HOSTS are returned >> --not-man-hosts=HOSTS: Only hosts which do not manage _any_ host >> in HOSTS are returned >> >> https://fedorahosted.org/freeipa/ticket/1675 > > ACK, it works for me. I'll update the UI to use the new option. I take that back. It's NACK. Patch #178 causes the dnszone-find --forward-only to return the reverse zone. -- Endi S. Dewata From rcritten at redhat.com Fri Dec 9 22:28:32 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 09 Dec 2011 17:28:32 -0500 Subject: [Freeipa-devel] [PATCH] 0033 Check all LDAP servers during IPA discovery In-Reply-To: <20111209202707.GA12414@redhat.com> References: <20111114104800.GA3927@redhat.com> <4ED8F47D.7060905@redhat.com> <20111207124224.GB32281@redhat.com> <4EE25E21.4050200@redhat.com> <20111209202707.GA12414@redhat.com> Message-ID: <4EE28B90.3010506@redhat.com> Alexander Bokovoy wrote: > On Fri, 09 Dec 2011, Rob Crittenden wrote: >> Alexander Bokovoy wrote: >>> On Fri, 02 Dec 2011, Rob Crittenden wrote: >>>> Alexander Bokovoy wrote: >>>>> Hi, >>>>> >>>>> This is patch proposal, I haven't checked it with multiple servers >>>>> setup yet. >>>>> >>>>> When discovering IPA LDAP servers through DNS records, look through all >>>>> servers found until first success. A master might be not available or >>>>> denied access due to anonymous binds disabled, for example, but >>>>> replica may succeed. >>>>> >>>>> Ticket #1827 >>>>> https://fedorahosted.org/freeipa/ticket/1827 >>>> >>>> Needs a rebase. >>>> >>>> This works fine but I wonder if someone specifies --server on the >>>> command-line if we should try only that server and fail if we can't >>>> connect. I can see someone using that so they can specify which >>>> server the client uses. >>> Rebase attached. >>> >>> If --server is specified, DNS discovery is bypassed in search() and >>> self.server will have the value of --server. That means the code I >>> changed will still work as parse_items() accepts a single item as >>> well. >> >> I don't see the --server code included in the patch. > Because it is not needed. > > search() method gets value of --server option passed as server named > argument. If it is not None, the whole discovery is avoided and that > value is assigned to self.server. > > self.server is then parsed via parse_items() and iterated over -- with > a single iteration in the case --server is specified. > Ah, right you are. Works great, pushed to master. rob From edewata at redhat.com Fri Dec 9 22:55:37 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 16:55:37 -0600 Subject: [Freeipa-devel] [PATCH] 052 Better displaying of long names in tables and facet headers In-Reply-To: <4EE20D24.4090204@redhat.com> References: <4EE0CA25.3090400@redhat.com> <4EE1B5EC.9090104@redhat.com> <4EE20D24.4090204@redhat.com> Message-ID: <4EE291E9.80601@redhat.com> On 12/9/2011 7:29 AM, Petr Vobornik wrote: > Attaching new patch which addresses following issues: ACK and pushed to master. > 7. When a column has a width set, there is a line (widget.js:1098): > width += 16; Why is it there? I'd rather subtract it. I used git blame to find this. According to revision c0eb2b60 it's supposed to widen the last column by 16px to accommodate the scroll bar. Not sure if it's the right solution, and the logic probably got lost in subsequent changes. Feel free to change it. -- Endi S. Dewata From edewata at redhat.com Fri Dec 9 22:55:44 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 16:55:44 -0600 Subject: [Freeipa-devel] [PATCH] 054 Reordered facets in ACI In-Reply-To: <4EE22C8A.2040105@redhat.com> References: <4EE22C8A.2040105@redhat.com> Message-ID: <4EE291F0.1070502@redhat.com> On 12/9/2011 9:43 AM, Petr Vobornik wrote: > Facets in ACI have new order: > * Roles: members, privileges, settings > * Privileges: permissions, settings, roles > * Permissions: settings, privileges > > https://fedorahosted.org/freeipa/ticket/2104 ACK and pushed to master. -- Endi S. Dewata From edewata at redhat.com Fri Dec 9 23:00:30 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 17:00:30 -0600 Subject: [Freeipa-devel] [PATCH] 325 Fixed matched/unmatched checkboxes in HBAC Test In-Reply-To: <4EE221FD.2000500@redhat.com> References: <4EE01DBF.5040002@redhat.com> <4EE221FD.2000500@redhat.com> Message-ID: <4EE2930E.8080702@redhat.com> On 12/9/2011 8:58 AM, Petr Vobornik wrote: > Existing minor issue which can be fixed later: > 1) matched checkbox has name 'disabled' Fixed and pushed to master under one-liner rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0328-Fixed-unmatched-checkbox-name.patch Type: text/x-patch Size: 994 bytes Desc: not available URL: From edewata at redhat.com Fri Dec 9 23:00:44 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 17:00:44 -0600 Subject: [Freeipa-devel] [PATCH] 329 Fixed combobox icon position. Message-ID: <4EE2931C.70405@redhat.com> A recent CSS change inadvertently changes position of the combobox icon. This has been fixed now. Ticket #388 Pushed to master under one-liner rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0329-Fixed-combobox-icon-position.patch Type: text/x-patch Size: 774 bytes Desc: not available URL: From edewata at redhat.com Fri Dec 9 23:21:58 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 17:21:58 -0600 Subject: [Freeipa-devel] [PATCH] 326 Added HBAC Test input validation. In-Reply-To: <4EE2220D.8090404@redhat.com> References: <4EE02490.20101@redhat.com> <4EE2220D.8090404@redhat.com> Message-ID: <4EE29816.8000501@redhat.com> On 12/9/2011 8:58 AM, Petr Vobornik wrote: > Possible future enhancement: > I would rather see more specific error message. The message should > contain which values are missing. In this implementation if user misses > to fill more than one value, he is informed only about the first missing > value (by redirection to the its facet) for the others he has to check > by hand (or realize it in mind) or by couple trial-error runs. > In details facet it is fine because invalid or missing values are > highlighted by validation messages near widgets. Agreed. Opened a new ticket: https://fedorahosted.org/freeipa/ticket/2182 -- Endi S. Dewata From edewata at redhat.com Fri Dec 9 23:25:00 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 17:25:00 -0600 Subject: [Freeipa-devel] [PATCH] 327 Fixed problem loading DNS records. In-Reply-To: <4EE22211.80007@redhat.com> References: <4EE1BE1A.7020000@redhat.com> <4EE22211.80007@redhat.com> Message-ID: <4EE298CC.5060709@redhat.com> On 12/9/2011 8:58 AM, Petr Vobornik wrote: > The HBAC test page is completed, right? Can I add all commit ids to trac > and close the ticket? The functionality is pretty much complete and the regressions found have been fixed, so I've closed the bug. -- Endi S. Dewata From edewata at redhat.com Sat Dec 10 01:23:24 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 19:23:24 -0600 Subject: [Freeipa-devel] [PATCH] 330 Fixed combobox search icon position. Message-ID: <4EE2B48C.2050902@redhat.com> A recent CSS change inadvertently changes position of the combobox search icon. This has been fixed now. Ticket #388 Pushed to master under one-liner rule. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0330-Fixed-combobox-search-icon-position.patch Type: text/x-patch Size: 788 bytes Desc: not available URL: From edewata at redhat.com Sat Dec 10 01:33:10 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 19:33:10 -0600 Subject: [Freeipa-devel] [PATCH] 180 Add missing --pkey-only option for selfservice and In-Reply-To: <1323445643.7177.45.camel@balmora.brq.redhat.com> References: <1323445643.7177.45.camel@balmora.brq.redhat.com> Message-ID: <4EE2B6D6.90301@redhat.com> On 12/9/2011 9:47 AM, Martin Kosek wrote: > pkey-only functionality has to be implemented separately for these > modules as they are based on crud.Search instead of standard > LDAPSearch. > > Delegation commands were modified in the process to allow ACIs > without 'memberof' as delegation ACIs. This check is no longer > needed since delegation ACI prefixe ensures the ACI type. > > https://fedorahosted.org/freeipa/ticket/2092 From UI perspective this is ACKed. I'm sending a patch to enable paging on these pages. -- Endi S. Dewata From edewata at redhat.com Sat Dec 10 01:33:12 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 09 Dec 2011 19:33:12 -0600 Subject: [Freeipa-devel] [PATCH] 331 Enabled paging on self-service permissions and delegations. Message-ID: <4EE2B6D8.10807@redhat.com> Paging has been enabled on self-service permissions and delegations list pages. The search facet's get_pkeys() has been fixed to handle non-array value. New test data files have been added as well. Ticket #2092 This patch depends on Martin's patch #180. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0331-Enabled-paging-on-self-service-permissions-and-deleg.patch Type: text/x-patch Size: 7427 bytes Desc: not available URL: From jeffschroed at gmail.com Fri Dec 9 01:26:43 2011 From: jeffschroed at gmail.com (Jeff Schroeder) Date: Thu, 8 Dec 2011 17:26:43 -0800 Subject: [Freeipa-devel] [SSSD] Design discussion: autofs integration In-Reply-To: <1323388904.2089.16.camel@perseus.themaw.net> References: <20111208165245.GI20911@zeppelin.brq.redhat.com> <1323388904.2089.16.camel@perseus.themaw.net> Message-ID: <232DFEB7-6802-4444-B1B4-BC07692C0EAF@gmail.com> 1 inline comment. Sent from my iPhone On Dec 8, 2011, at 16:01, Ian Kent wrote: > On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote: >> Hi, >> >> I have created a wiki page summarizing my design proposal on integrating >> SSSD with automounter: >> https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration >> >> Feedback is much appreciated - a reply to this email would probably work >> best. The target of this work is 1.8 > > Thanks for writing this summary, it's excellent. > There's not much I have to say about it because it is already quite > thorough. > > One thing I dislike about the discussion, and while I let it pass in > bugs and mailing list discussions, I think it is wrong to put it in > public design documents. The statement "autofs abuses the nsswitch.conf > configuration file" I find a little offensive. autofs uses that > configuration file and parses only the "automount" entry using the same > semantic behavior as nss, so the word "abuse" is wrong and a little rude > IMHO. From googling: define:abuse a?buse/??byo?oz/ Verb: Use (something) to bad effect or for a bad purpose; misuse. Indeed, what autofs is doing fits this definition to a tee. People reading technical documents generally have thick enough skin that the work abuse is not offensive. Not trying to flame, but I can't comprehend why you see the word abuse as offensive when it (to me) clearly is it. Especially not when it is used in a context fitting the definition. Much like how OpenVZ abuses procfs and IOCTLs, that's just how it is. If they used things as they were meant to be, it would not be abuse. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ikent at redhat.com Sat Dec 10 00:30:00 2011 From: ikent at redhat.com (Ian Kent) Date: Sat, 10 Dec 2011 08:30:00 +0800 Subject: [Freeipa-devel] Design discussion: autofs integration In-Reply-To: <20111209084842.GA15086@zeppelin.brq.redhat.com> References: <20111208165245.GI20911@zeppelin.brq.redhat.com> <1323388904.2089.16.camel@perseus.themaw.net> <20111209084842.GA15086@zeppelin.brq.redhat.com> Message-ID: <1323477000.2158.17.camel@perseus.themaw.net> On Fri, 2011-12-09 at 09:48 +0100, Jakub Hrozek wrote: > On Fri, Dec 09, 2011 at 08:01:44AM +0800, Ian Kent wrote: > > On Thu, 2011-12-08 at 17:52 +0100, Jakub Hrozek wrote: > > > Hi, > > > > > > I have created a wiki page summarizing my design proposal on integrating > > > SSSD with automounter: > > > https://fedorahosted.org/sssd/wiki/DesignDocs/AutofsIntegration > > > > > > Feedback is much appreciated - a reply to this email would probably work > > > best. The target of this work is 1.8 > > > > Thanks for writing this summary, it's excellent. > > There's not much I have to say about it because it is already quite > > thorough. > > > > One thing I dislike about the discussion, and while I let it pass in > > bugs and mailing list discussions, I think it is wrong to put it in > > public design documents. The statement "autofs abuses the nsswitch.conf > > configuration file" I find a little offensive. autofs uses that > > configuration file and parses only the "automount" entry using the same > > semantic behavior as nss, so the word "abuse" is wrong and a little rude > > IMHO. > > I'm sorry -- I didn't mean to offend you and perhaps abuse was a strong > word. I've changed the design docs. None taken, the word is simply to strong for the message that is being conveyed. > > That said, I'm still not convinced that it is a good idea to use another > application's config file. > > My main concern is that users often mistakenly think that there is a > standard glibc interface defined. Also, when the shared config file > changes (not that it's likely that nsswitch would change drastically), > you're in trouble -- for instance, sudo suffered recently when Fedora > changed from using ldap.conf to nslcd.conf It's hard to argue this point since that is my own opinion as well. But, in this case, it was so much more sensible to take the risk (the longevity of this configuration file counted in the decision) and use this particular configuration. During the initial autofs version 5 development I spent a sufficient amount of time (quite a bit actually) trying to use the glibc nss interface for the autofs ldap lookup module (including writing the glibc backend since there were no nss "automount" modules at all) to work out that using it was going to be very painful for me, not to mention that I would have had to write "all" needed source modules myself, including their backend component and hope they would be accepted into glibc within a time frame that met my tight schedule. So, the decision was made to break my own rule and re-use large portions of existing autofs code, and yes, I would have rather used a published interface, but for better or for worse, that is the way it was done which happens some times, unfortunately. Ian From ikent at redhat.com Sat Dec 10 00:40:43 2011 From: ikent at redhat.com (Ian Kent) Date: Sat, 10 Dec 2011 08:40:43 +0800 Subject: [Freeipa-devel] Design discussion: autofs integration In-Reply-To: <20111209084842.GA15086@zeppelin.brq.redhat.com> References: <20111208165245.GI20911@zeppelin.brq.redhat.com> <1323388904.2089.16.camel@perseus.themaw.net> <20111209084842.GA15086@zeppelin.brq.redhat.com> Message-ID: <1323477643.2158.23.camel@perseus.themaw.net> On Fri, 2011-12-09 at 09:48 +0100, Jakub Hrozek wrote: > > > > One thing I dislike about the discussion, and while I let it pass in > > bugs and mailing list discussions, I think it is wrong to put it in > > public design documents. The statement "autofs abuses the nsswitch.conf > > configuration file" I find a little offensive. autofs uses that > > configuration file and parses only the "automount" entry using the same > > semantic behavior as nss, so the word "abuse" is wrong and a little rude > > IMHO. > > I'm sorry -- I didn't mean to offend you and perhaps abuse was a strong > word. I've changed the design docs. Please don't get me wrong, I'm happy for people to say what they think within mailing list discussions and, to a lesser extent, within bug discussions, but in a web presented design document a little more care really should be taken IMHO. Ian From ohamada at redhat.com Mon Dec 12 12:38:07 2011 From: ohamada at redhat.com (Ondrej Hamada) Date: Mon, 12 Dec 2011 13:38:07 +0100 Subject: [Freeipa-devel] [PATCH] 5 User-add random password support In-Reply-To: <4EE265A6.7090802@redhat.com> References: <4ECE5ABE.3060207@redhat.com> <4ECE760A.7000401@redhat.com> <1322559082.32073.13.camel@balmora.brq.redhat.com> <4EE223C6.1070908@redhat.com> <4EE265A6.7090802@redhat.com> Message-ID: <4EE5F5AF.4010902@redhat.com> On 12/09/2011 08:46 PM, Rob Crittenden wrote: > Ondrej Hamada wrote: >> On 11/29/2011 10:31 AM, Martin Kosek wrote: >>> On Thu, 2011-11-24 at 17:51 +0100, Ondrej Hamada wrote: >>>> On 11/24/2011 03:54 PM, Ondrej Hamada wrote: >>>>> https://fedorahosted.org/freeipa/ticket/1979 >>>>> >>>>> I've used code from ipalib/plugins/host.py to add support for >>>>> random >>>>> password generation. The '--random' option is now available in >>>>> user-add and user-mod commands. If both the 'password' and 'random' >>>>> options are used the 'random' option will be ignored. >>>>> >>>>> >>> Functionally, it works OK. I would just like to propose few >>> improvements: >>> >>> 1) Minor API version in VERSION file should be bumped since you add a >>> new option >>> 2) We should add some tests exercising this new functionality so >>> that we >>> can detect regressions early >>> 3) (optional) I am thinking if the passwords we generate are not very >>> user friendly. I would love to see user's face when he is told that his >>> new password is 5QU;8l2%]y"? . >>> >>> While this is may be OK for hosts bulk passwords which are only >>> manipulated by admins, we may want to develop more user friendly >>> passwords in the user plugin. >>> >>> Martin >>> >> https://fedorahosted.org/freeipa/ticket/1979 >> >> I've used code from ipalib/plugins/host.py to add >> support for random password generation. The >> '--random' option is now available in user-add and >> user-mod commands. If both the 'password' and 'random' >> options are used the 'random' option will be ignored. >> >> Two test cases were added to unit test's module >> test_user_plugin.py - they test creating and modifying >> user with random password. Two fuzzy tests were added: >> test for password(string that doesn't start or end with >> whitespace and doesn't containt other whitespace than >> ' ') and for whatever string(because of krbextradata). >> >> I've slightly modified ipa_generate_password in order >> to make passwords for users more user-friendly(reduce >> number of non-letters). It has two optional parameters >> now - first one is string of characters that should be >> used for generating the passwd and second one is length >> of password. If none parameter is set default values will >> be used so there's no need to modify other plugins that >> use random password generator. > > This is very, very close. I just have a couple of observations: > > 1. Would it be clearer if in user.py you set the character set to: > string.digits + string.ascii_letters + '_,.@' ? I gather you are > excluding most of the characters that would cause the shell grief on > purpose, right? You can probably add in +, - and = though. > > 2. Indention in ipa_generate_password() is a bit off. > > 3. Rather than fuzzy_string() I think you should define something like > fuzzy_dergeneralizedtime() that specifies the time format in those > kerberos time attributes. krbextradata is probably fine as a string. > > rob Corrected and modified according to rob's proposals Ondra -- Regards, Ondrej Hamada FreeIPA team jabber: ohama at jabbim.cz IRC: ohamada -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-ohamada-5-4-User-add-random-password-support.patch Type: text/x-patch Size: 17998 bytes Desc: not available URL: From pvoborni at redhat.com Mon Dec 12 13:32:29 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 Dec 2011 14:32:29 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173 Create per-type DNS API In-Reply-To: <4EE1B292.90501@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <4EE1B292.90501@redhat.com> Message-ID: <4EE6026D.2030207@redhat.com> On 12/09/2011 08:02 AM, Endi Sukma Dewata wrote: > On 11/28/2011 10:35 AM, Martin Kosek wrote: >> I have prepared a working prototype of the new structured DNS API. It >> may still have rough edges (and unit tests are not ready), but it will >> provide a base for discussion and for WebUI folks - so that they can >> start development of the new DNS WebUI API. >> >> The patch takes advantage of the DNS refactor I did in 172. For all >> supported non-DNSSEC RR types, the following commands are available: > > For the rest of the record types will there be new commands like below > eventually or should we use the dnsrecord command? > >> dnsrecord-show ZONE NAME >> dnsrecord-add ZONE NAME >> dnsrecord-mod ZONE NAME VALUE > > Here's how the commands can be used in the DNS records list page: > > http://edewata.fedorapeople.org/freeipa/install/ui/#dns=dnszone&identity=dns&navigation=identity&dnszone-facet=default&dnszone-pkey=example.com > > > As discussed in ticket #2094 we will add paging support for this page. > This is done by calling dnsrecord-find --pkey-only to get all primary > keys, then call a batch of dnsrecord-show to get full data of the > records being displayed in the current page. I don't think we want to > use the new dnsrecord-show here because we want to get all > record types and since the space is limited we will just show the raw data. > > Click the Add link on the top of the page. The dialog box could be > modified such that when you select a Record Type instead of showing the > same Data field it will show the proper fields for the selected type. > Then when you submit it will call the new dnsrecord-add command. > > Also discussed in #2094, we'll only have one checkbox for each record > name instead of one for each value. So in this page we can only delete > the entire record entry. This will be done using the existing > dnsrecord-del command. > > And then the details page: > > http://edewata.fedorapeople.org/freeipa/install/ui/#dns=dnsrecord&identity=dns&navigation=identity&dnsrecord-facet=default&dnsrecord-pkey=testrec&dnszone-pkey=example.com > > > Right now we use a single text field for each raw data. The first option > is we could modify this page to use a table for each type, similar to > HBAC/sudo rule. For example: > > SRV Records > > x | Priority | Weight | Port | Target [Delete] [Add] > ------------------------------------------------------- > x | 0 | 100 | 88 | test > > The content of the table will be obtained using the new > dnsrecord-show. The add dialog will show the fields for the type > and it will call the new dnsrecord-add command. Deletion will be > done using the existing dnsrecord-del command. I like this option better than the second one. It seems clearer to me. Just from UI perspective (no change in commands): I would show only the the tables which have some values - to let the page be shorter and clearer. This will require an add button in the facet header - similar dialog with type selection as in add in search facet except that the idnsname would be implied. > > The other option is to keep the existing style (without tables) but > instead of a single text field for each record value we will show the > values in separate fields. For example: > > SRV Records > > Target: [test ] Port: [88 ] [Delete] > Priority: [0 ] Weight: [100 ] > > [Add] > > When you click Update, the UI will have to translate the changes into > add, modify, and delete operations. The add and modify will be done > using the new dnsrecord-add/mod command. The delete will be done > using the existing dnsrecord-del command. > > Note, regardless of these options when you open the details page the UI > could execute up to 20 dnsrecord-show operations since there are > 20 possible record types currently listed in the UI. To avoid this it would be nice to have a method like dnsrecord-find ZONE NAME (ie this one with new option) which would return the record with data structure similar to dnsrecord-show. For example (content of result): [ //record array { idnsname: 'foo', //name arecord: [ { arecord: '10.10.10.10', //raw ip_address: '10.10.10.10' } ], cnamerecord: [ { cnamerecord: 'bar.example.com.', //raw hostname: 'bar.example.com.' }, { cnamerecord: 'bar2.example.com.', //raw hostname: 'bar2.example.com.' }, ] } ] This way we would get all info we need without calling batch with 20 commands or calling dnsrecord-find and then batch with 1-20 commands. > >> 1) The commands return a list of structured records (just like *-find >> commands) instead of returning just one record. I thought that it may be >> more usable this way and consistent with dnsrecord-add/mod/show commands >> behavior which returns all records too. Otherwise, we would have to >> change the show command API and add VALUE argument, which would specify >> a value to be displayed: >> dnsrecord-show ZONE NAME VALUE > > I think for consistency it would be better to call this command > dnsrecord-find since it returns multiple entries. We might also > be able to add filters in the future. +1 > >> 2) Raw DNS record value is in the output too. I though it would be >> useful to see the raw DNS record value + its parts at one place. > > Yes, the raw value will be needed for calling dnsrecord-mod or > dnsrecord-del command. +1 > >> 3) The commands are in format dnsrecord-cmd, for example >> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we >> want to go this way, I would have to bend the server framework a little >> which parses an LDAP object from the command name (LDAP object name is >> dnsrecordmx in this case). This is doable, although I am not sure if >> this does not have some implications in WebUI side. > > I agree, the extra dash would be better. When calling a command the UI > concatenates entity name and method name with an '_'. In this case the > entity name will remain dnsrecord and the RRTYPE will be prepended to > the method name. Or we can avoid specifying the entity for command and just fill whole command name. Either way it is doable and the dash is definitely better for CLI - when I was playing with the commands I was inclined to wrote the dash. > > Btw, patch #175 causes a build break: > > ipalib/parameters.py:718: [E1101, Param.normalize] Generator > '__unicode_csv_reader' has no 'next' member > -- Petr Vobornik From pvoborni at redhat.com Mon Dec 12 15:27:02 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 Dec 2011 16:27:02 +0100 Subject: [Freeipa-devel] [PATCH] 055 Association facets are read only in self service Message-ID: <4EE61D46.2000200@redhat.com> This patch works with assumption that user in self-service mode doesn't have rights for enrolling/un-enrolling himself to/from group, role, hbac rule, net group, sudo rule. He can only read the attributes. Therefore in self service mode all user association facets are set read only. Checking and working with the actual rights would require significantly bigger effort. https://fedorahosted.org/freeipa/ticket/1972 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0055-Association-facets-are-read-only-in-self-service.patch Type: text/x-patch Size: 2668 bytes Desc: not available URL: From edewata at redhat.com Mon Dec 12 16:26:29 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 12 Dec 2011 10:26:29 -0600 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173 Create per-type DNS API In-Reply-To: <4EE6026D.2030207@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <4EE1B292.90501@redhat.com> <4EE6026D.2030207@redhat.com> Message-ID: <4EE62B35.7050604@redhat.com> On 12/12/2011 7:32 AM, Petr Vobornik wrote: >> The first option is we could modify this page to use a table for each >> type, similar to HBAC/sudo rule. For example: >> >> SRV Records >> >> x | Priority | Weight | Port | Target [Delete] [Add] >> ------------------------------------------------------- >> x | 0 | 100 | 88 | test > > I like this option better than the second one. It seems clearer to me. > > Just from UI perspective (no change in commands): I would show only the > the tables which have some values - to let the page be shorter and > clearer. This will require an add button in the facet header - similar > dialog with type selection as in add in search facet except that the > idnsname would be implied. The thing with this is that suppose you are looking for a certain type and that type doesn't exist in that particular record, you would have to look at the entire page before you know it doesn't exist. But if we show empty tables, once you see the table you know the record doesn't have the type you're looking for. Maybe we can hide the table but still show the table title (i.e. the type) and an Add button next to it? >> Note, regardless of these options when you open the details page the UI >> could execute up to 20 dnsrecord-show operations since there are >> 20 possible record types currently listed in the UI. > To avoid this it would be nice to have a method like dnsrecord-find ZONE > NAME (ie this one with new option) which would return the record with > data structure similar to dnsrecord-show. For example (content of > result): > [ //record array > { > idnsname: 'foo', //name > arecord: [ > { > arecord: '10.10.10.10', //raw > ip_address: '10.10.10.10' > } > ], > cnamerecord: [ > { > cnamerecord: 'bar.example.com.', //raw > hostname: 'bar.example.com.' > }, > { > cnamerecord: 'bar2.example.com.', //raw > hostname: 'bar2.example.com.' > }, > ] > } > ] > > This way we would get all info we need without calling batch with 20 > commands or calling dnsrecord-find and then batch with 1-20 commands. Yes, it would be great to have something like that. But the extra NAME argument above could be confused with search filter for dnsrecord-find. It might be better to use an additional flag to determine the output format (like --raw), something like this: ipa dnsrecord-find ZONE --structured ipa dnsrecord-show ZONE NAME --structured The structure could also look like this (but either way will work): [ { idnsname: 'foo', records: [ { type: 'a', data: '10.10.10.10', ip_address: '10.10.10.10' }, { type: 'cname', data: 'bar.example.com.', hostname: 'bar.example.com.' }, { type: 'cname', data: 'bar2.example.com.', hostname: 'bar2.example.com.' }, ] } ] In this case the UI won't use the dnsrecord--show/find command, but it might still be useful for people using CLI. Or instead of that we could have another option to specify which types you want to get. ipa dnsrecord-show ZONE NAME --types=a,cname --structured -- Endi S. Dewata From abokovoy at redhat.com Mon Dec 12 17:49:04 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Dec 2011 19:49:04 +0200 Subject: [Freeipa-devel] WIP: ipa trust command Message-ID: <20111212174903.GA9668@redhat.com> Hi, I'm working on ticket #1821 to introduce FreeIPA 3.0 AD trusts management CLI and GUI. It is quite apparent that most of management commands will be similar to all future trust types (AD, IPA, etc), thus, it makes sense to develop a generalized `ipa trust' family of commands that would apply to all types of trusts. Let's start with CLI. Below is a first cut at how I see trust management command line interface. Comments, corrections, and critique are all welcomed. One of FreeIPA v3.0 major features will be support for cross-realm trusts with the emphasis on trusts to Active Directory domains. This documents attempts to design a common interface for managing trusts with FreeIPA tools (command line and GUI). `ipa trust' =========== `ipa trust' is a common family of operations on trusts. Trusts can be: * created (ipa trust-add) * listed (ipa trust-find) * viewed (ipa trust-show) * removed (ipa trust-del) 1. Adding a trust `ipa trust-add' sets up a trust agreement with another realm. The command requires to know realm of the trust being added, its administrator rights, and type of the trust to establish. Proposed syntax: ipa trust-add --type ads|ipa|kerberos|etc --realmadmin --password [type-specific parameters] Creates a trust between FreeIPA realm and another realm of selected type. Only 'ads' type is currently supported. For 'ads' type running `ipa trust-add' would be equivalent to following sequence: * ipa-adtrust-install * net rpc trust create 2. Listing trusts `ipa trust-find' will show all trusts with other realms corresponding certain criteria. Proposed syntax: ipa trust-find [CRITERIA] [options] where CRITERIA is tested against realms of existing trusts Options might include: * --type ads|ipa|kerberos|etc -- type of the trust 3. Viewing details of trust `ipa trust-show' exposes details of the established trust agreement with a specified realm. Proposed syntax: ipa trust-show [options] Details shown will depend on the type of trust with following information available for all trusts: * realm name * trust type 4. Removal of existing trus `ipa trust-del' removes existing trust agreement 5. Access rights Trust management requires modification of FreeIPA LDAP database instance and potentially external resources specific to the trust nature. cn=trusts,$SUFFIX is used as a container to store information about trusts with containers inside it for different types of trusts. Currently FreeIPA 3.0 implements cn=ad,cn=trusts,$SUFFIX tree for Active Directory-related trusts. Trust management implies limited access which should be implemented with the help of 389-ds ACIs. In order to give users access to the trust management, group of trust administrators would be created, thus ACI would limit exposure to cn=trusts,$SUFFIX tree to this group and additional trust implementation-specific system users defined at cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX. Currently AD trusts implement following ACIs per trust: 1. Trust information: (target = "ldap:///cn=$DOMAIN,cn=ad,cn=trusts,$SUFFIX") (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes") (version 3.0;acl "Allow samba user to create and delete trust accounts"; allow (write,add,delete) userdn = "ldap:///$SAMBA_USER_DN";) 2. NT Passwords: (targetattr = "ipaNTHash") (version 3.0; acl "Samba user can read NT passwords"; allow (read) userdn="ldap:///$SAMBA_USER_DN";) where $SAMBA_USER_DN is DN of special user defined at uid=samba,cn=sysaccounts,cn=etc,$SUFFIX for the purpose of reading ipaNTHash attribute (NT passwords) of existing users and accessing trust information from the ipa-sam database plugin for Samba. Current approach requires creating separate ACIs per each trust and using the same system user account for all of them. As a consequence, ACIs are added during trust creation and require Directory Manager privileges which should be discouraged for 'ipa trust' set of commands. Instead, macro ACI could be created that would allow access to the trust information based on the part of DN of the system user: uid=,cn=,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX which for AD trusts would be uid=samba,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX and ACI would be modified to have follow allow stanza: (target = "ldap:///($dn),cn=trusts,$SUFFIX") (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || ipaNTTrustDirection || ipaNTTrustPartner || ipaNTFlatName || ipaNTTrustAuthOutgoing || ipaNTTrustAuthIncoming || ipaNTSecurityIdentifier || ipaNTTrustForestTrustInfo || ipaNTTrustPosixOffset || ipaNTSupportedEncryptionTypes") (version 3.0;acl "Allow trust system user to create and delete trust accounts"; allow (write,add,delete) userdn="ldap:///uid=*,($dn),cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) (targetattr = "ipaNTHash") (version 3.0; acl "Samba user can read NT passwords"; allow (read) userdn="ldap:///uid=*,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) And trust admins ACI: (target = "ldap:///cn=trusts,$SUFFIX") (targetattr = "*") (version 3.0; acl "Trust management"; allow (all) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";) This approach would allow us to have a single ACI macro for system accounts of all types of trusts for all realms and then a single ACI per trust type. Macro ACI are explained at http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Advanced_Access_Control_Using_Macro_ACIs.html -- / Alexander Bokovoy From pvoborni at redhat.com Mon Dec 12 18:21:25 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 12 Dec 2011 19:21:25 +0100 Subject: [Freeipa-devel] [PATCH] 056 Added facet tabs coloring Message-ID: <4EE64625.2020209@redhat.com> Facet tabs are now colored according to their group. https://fedorahosted.org/freeipa/ticket/1976 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0056-Added-facet-tabs-coloring.patch Type: text/x-patch Size: 5677 bytes Desc: not available URL: From simo at redhat.com Mon Dec 12 19:09:54 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Dec 2011 14:09:54 -0500 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111212174903.GA9668@redhat.com> References: <20111212174903.GA9668@redhat.com> Message-ID: <1323716994.4413.86.camel@willson.li.ssimo.org> On Mon, 2011-12-12 at 19:49 +0200, Alexander Bokovoy wrote: > Hi, > > I'm working on ticket #1821 to introduce FreeIPA 3.0 AD trusts > management CLI and GUI. It is quite apparent that most of management > commands will be similar to all future trust types (AD, IPA, etc), > thus, it makes sense to develop a generalized `ipa trust' family of > commands that would apply to all types of trusts. > > Let's start with CLI. Below is a first cut at how I see trust > management command line interface. Comments, corrections, and critique > are all welcomed. > > One of FreeIPA v3.0 major features will be support for cross-realm > trusts with the emphasis on trusts to Active Directory domains. This > documents attempts to design a common interface for managing trusts > with FreeIPA tools (command line and GUI). > > `ipa trust' > =========== > > `ipa trust' is a common family of operations on trusts. Trusts can be: > * created (ipa trust-add) > * listed (ipa trust-find) > * viewed (ipa trust-show) > * removed (ipa trust-del) > > 1. Adding a trust > > `ipa trust-add' sets up a trust agreement with another realm. The > command requires to know realm of the trust being added, its > administrator rights, and type of the trust to establish. > > Proposed syntax: > ipa trust-add --type ads|ipa|kerberos|etc --realmadmin > --password [type-specific parameters] > > Creates a trust between FreeIPA realm and another realm of selected > type. Only 'ads' type is currently supported. > > For 'ads' type running `ipa trust-add' would be equivalent to > following sequence: > * ipa-adtrust-install > * net rpc trust create I think this is problematic in one regard. It can work only on one specific server (a general problem of ipa-adtrust-install). I am not sure how to fix it though. Ideally once you create a trust all IPA servers in the domain should be able to properly handle it. But at this moment only servers on which you explicitly run ipa-adtrust-instalkl can. Actually even worse, I think ipa-adtrust-install will fail with multiple servers because the uid=samba user have a random password that cannot be communicated to other servers ... > 2. Listing trusts > > `ipa trust-find' will show all trusts with other realms corresponding > certain criteria. > > Proposed syntax: > ipa trust-find [CRITERIA] [options] > > where CRITERIA is tested against realms of existing trusts > > Options might include: > * --type ads|ipa|kerberos|etc -- type of the trust > > > 3. Viewing details of trust > > `ipa trust-show' exposes details of the established trust agreement > with a specified realm. > > Proposed syntax: > ipa trust-show [options] > > Details shown will depend on the type of trust with following > information available for all trusts: > * realm name > * trust type You may want to add trust direction here. I think we may want to support incoming only trusts with AD in future (ie we trust AD but AD admins do not want to trust IPA). > 4. Removal of existing trus > > `ipa trust-del' removes existing trust agreement > > 5. Access rights > > Trust management requires modification of FreeIPA LDAP database > instance and potentially external resources specific to the trust > nature. cn=trusts,$SUFFIX is used as a container to store information > about trusts with containers inside it for different types of trusts. > > Currently FreeIPA 3.0 implements cn=ad,cn=trusts,$SUFFIX tree for > Active Directory-related trusts. > > Trust management implies limited access which should be implemented > with the help of 389-ds ACIs. > > In order to give users access to the trust management, group of trust > administrators would be created, thus ACI would limit exposure to > cn=trusts,$SUFFIX tree to this group and additional trust > implementation-specific system users defined at cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX. > > Currently AD trusts implement following ACIs per trust: > 1. Trust information: > (target = "ldap:///cn=$DOMAIN,cn=ad,cn=trusts,$SUFFIX") > (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || > ipaNTTrustDirection || > ipaNTTrustPartner || ipaNTFlatName || > ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming || > ipaNTSecurityIdentifier || > ipaNTTrustForestTrustInfo || > ipaNTTrustPosixOffset || > ipaNTSupportedEncryptionTypes") > (version 3.0;acl "Allow samba user to create and delete trust accounts"; > allow (write,add,delete) userdn = "ldap:///$SAMBA_USER_DN";) > > 2. NT Passwords: > (targetattr = "ipaNTHash") > (version 3.0; acl "Samba user can read NT passwords"; > allow (read) userdn="ldap:///$SAMBA_USER_DN";) > > where $SAMBA_USER_DN is DN of special user defined at > uid=samba,cn=sysaccounts,cn=etc,$SUFFIX for the purpose of reading > ipaNTHash attribute (NT passwords) of existing users and accessing > trust information from the ipa-sam database plugin for Samba. > > Current approach requires creating separate ACIs per each trust and > using the same system user account for all of them. As a consequence, > ACIs are added during trust creation and require Directory Manager > privileges which should be discouraged for 'ipa trust' set of > commands. We should just use cn=* in the ACI instead of CN=$DOMAIN and add ACIs only once. > Instead, macro ACI could be created that would allow access to the trust information > based on the part of DN of the system user: > > uid=,cn=,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX > > which for AD trusts would be > > uid=samba,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX > > and ACI would be modified to have follow allow stanza: > > (target = "ldap:///($dn),cn=trusts,$SUFFIX") > (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || > ipaNTTrustDirection || > ipaNTTrustPartner || ipaNTFlatName || > ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming || > ipaNTSecurityIdentifier || > ipaNTTrustForestTrustInfo || > ipaNTTrustPosixOffset || > ipaNTSupportedEncryptionTypes") > (version 3.0;acl "Allow trust system user to create and delete trust accounts"; > allow (write,add,delete) userdn="ldap:///uid=*,($dn),cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > (targetattr = "ipaNTHash") > (version 3.0; acl "Samba user can read NT passwords"; > allow (read) userdn="ldap:///uid=*,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > And trust admins ACI: > > (target = "ldap:///cn=trusts,$SUFFIX") > (targetattr = "*") > (version 3.0; acl "Trust management"; > allow (all) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";) Although I think we need 'trust admins' ACIs, I do not think we need the macro ACI for uid=samba. We do not need multiple users for trusts, only trusts that involve samba needs a separate user at this moment. So I'd say ACK for the second part and NACK for the first. > This approach would allow us to have a single ACI macro for system > accounts of all types of trusts for all realms and then a single ACI > per trust type. We need a single ACI, just not with macros, we can have all we need with a simpler ACI, and simpler always wins :) Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Dec 12 19:10:08 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 14:10:08 -0500 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111212174903.GA9668@redhat.com> References: <20111212174903.GA9668@redhat.com> Message-ID: <4EE65190.8050409@redhat.com> Alexander Bokovoy wrote: > Hi, > > I'm working on ticket #1821 to introduce FreeIPA 3.0 AD trusts > management CLI and GUI. It is quite apparent that most of management > commands will be similar to all future trust types (AD, IPA, etc), > thus, it makes sense to develop a generalized `ipa trust' family of > commands that would apply to all types of trusts. > > Let's start with CLI. Below is a first cut at how I see trust > management command line interface. Comments, corrections, and critique > are all welcomed. > > One of FreeIPA v3.0 major features will be support for cross-realm > trusts with the emphasis on trusts to Active Directory domains. This > documents attempts to design a common interface for managing trusts > with FreeIPA tools (command line and GUI). > > `ipa trust' > =========== > > `ipa trust' is a common family of operations on trusts. Trusts can be: > * created (ipa trust-add) > * listed (ipa trust-find) > * viewed (ipa trust-show) > * removed (ipa trust-del) modified? > > 1. Adding a trust > > `ipa trust-add' sets up a trust agreement with another realm. The > command requires to know realm of the trust being added, its > administrator rights, and type of the trust to establish. > > Proposed syntax: > ipa trust-add --type ads|ipa|kerberos|etc --realmadmin > --password [type-specific parameters] > > Creates a trust between FreeIPA realm and another realm of selected > type. Only 'ads' type is currently supported. > > For 'ads' type running `ipa trust-add' would be equivalent to > following sequence: > * ipa-adtrust-install > * net rpc trust create ipa-adtrust-install runs as root and needs to do things that the IPA server can't do. > 2. Listing trusts > > `ipa trust-find' will show all trusts with other realms corresponding > certain criteria. > > Proposed syntax: > ipa trust-find [CRITERIA] [options] > > where CRITERIA is tested against realms of existing trusts > > Options might include: > * --type ads|ipa|kerberos|etc -- type of the trust ok > > > 3. Viewing details of trust > > `ipa trust-show' exposes details of the established trust agreement > with a specified realm. > > Proposed syntax: > ipa trust-show [options] > > Details shown will depend on the type of trust with following > information available for all trusts: > * realm name > * trust type ok > > 4. Removal of existing trus > > `ipa trust-del' removes existing trust agreement > > 5. Access rights > > Trust management requires modification of FreeIPA LDAP database > instance and potentially external resources specific to the trust > nature. cn=trusts,$SUFFIX is used as a container to store information > about trusts with containers inside it for different types of trusts. > > Currently FreeIPA 3.0 implements cn=ad,cn=trusts,$SUFFIX tree for > Active Directory-related trusts. > > Trust management implies limited access which should be implemented > with the help of 389-ds ACIs. > > In order to give users access to the trust management, group of trust > administrators would be created, thus ACI would limit exposure to > cn=trusts,$SUFFIX tree to this group and additional trust > implementation-specific system users defined at cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX. > > Currently AD trusts implement following ACIs per trust: > 1. Trust information: > (target = "ldap:///cn=$DOMAIN,cn=ad,cn=trusts,$SUFFIX") > (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || > ipaNTTrustDirection || > ipaNTTrustPartner || ipaNTFlatName || > ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming || > ipaNTSecurityIdentifier || > ipaNTTrustForestTrustInfo || > ipaNTTrustPosixOffset || > ipaNTSupportedEncryptionTypes") > (version 3.0;acl "Allow samba user to create and delete trust accounts"; > allow (write,add,delete) userdn = "ldap:///$SAMBA_USER_DN";) > > 2. NT Passwords: > (targetattr = "ipaNTHash") > (version 3.0; acl "Samba user can read NT passwords"; > allow (read) userdn="ldap:///$SAMBA_USER_DN";) > > where $SAMBA_USER_DN is DN of special user defined at > uid=samba,cn=sysaccounts,cn=etc,$SUFFIX for the purpose of reading > ipaNTHash attribute (NT passwords) of existing users and accessing > trust information from the ipa-sam database plugin for Samba. > > Current approach requires creating separate ACIs per each trust and > using the same system user account for all of them. As a consequence, > ACIs are added during trust creation and require Directory Manager > privileges which should be discouraged for 'ipa trust' set of > commands. > > Instead, macro ACI could be created that would allow access to the trust information > based on the part of DN of the system user: > > uid=,cn=,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX > > which for AD trusts would be > > uid=samba,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX > > and ACI would be modified to have follow allow stanza: > > (target = "ldap:///($dn),cn=trusts,$SUFFIX") > (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || > ipaNTTrustDirection || > ipaNTTrustPartner || ipaNTFlatName || > ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming || > ipaNTSecurityIdentifier || > ipaNTTrustForestTrustInfo || > ipaNTTrustPosixOffset || > ipaNTSupportedEncryptionTypes") > (version 3.0;acl "Allow trust system user to create and delete trust accounts"; > allow (write,add,delete) userdn="ldap:///uid=*,($dn),cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > (targetattr = "ipaNTHash") > (version 3.0; acl "Samba user can read NT passwords"; > allow (read) userdn="ldap:///uid=*,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > And trust admins ACI: > > (target = "ldap:///cn=trusts,$SUFFIX") > (targetattr = "*") > (version 3.0; acl "Trust management"; > allow (all) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";) > > > This approach would allow us to have a single ACI macro for system > accounts of all types of trusts for all realms and then a single ACI > per trust type. > > Macro ACI are explained at > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Advanced_Access_Control_Using_Macro_ACIs.html > > ack on aci From sbose at redhat.com Mon Dec 12 19:40:05 2011 From: sbose at redhat.com (Sumit Bose) Date: Mon, 12 Dec 2011 20:40:05 +0100 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111212174903.GA9668@redhat.com> References: <20111212174903.GA9668@redhat.com> Message-ID: <20111212194005.GT2262@localhost.localdomain> On Mon, Dec 12, 2011 at 07:49:04PM +0200, Alexander Bokovoy wrote: > Hi, > > I'm working on ticket #1821 to introduce FreeIPA 3.0 AD trusts > management CLI and GUI. It is quite apparent that most of management > commands will be similar to all future trust types (AD, IPA, etc), > thus, it makes sense to develop a generalized `ipa trust' family of > commands that would apply to all types of trusts. > > Let's start with CLI. Below is a first cut at how I see trust > management command line interface. Comments, corrections, and critique > are all welcomed. > > One of FreeIPA v3.0 major features will be support for cross-realm > trusts with the emphasis on trusts to Active Directory domains. This > documents attempts to design a common interface for managing trusts > with FreeIPA tools (command line and GUI). Thank you for the nice overview, see comments below > > `ipa trust' > =========== > > `ipa trust' is a common family of operations on trusts. Trusts can be: > * created (ipa trust-add) > * listed (ipa trust-find) > * viewed (ipa trust-show) > * removed (ipa trust-del) > > 1. Adding a trust > > `ipa trust-add' sets up a trust agreement with another realm. The > command requires to know realm of the trust being added, its > administrator rights, and type of the trust to establish. > > Proposed syntax: > ipa trust-add --type ads|ipa|kerberos|etc --realmadmin > --password [type-specific parameters] > > Creates a trust between FreeIPA realm and another realm of selected > type. Only 'ads' type is currently supported. > > For 'ads' type running `ipa trust-add' would be equivalent to > following sequence: > * ipa-adtrust-install > * net rpc trust create As Simo already mentioned theses should be two separate step and `ipa trust-add' should just check is the needed components to create AD trusts are already installed on the IPA server. Additionally I think we need some commands to define a UID range for the trusted domains, especially for AD trusts. For the domain given with the `ipa trust-add' command we could just use another command line option. But if this domain already has trusts to other domains it will become difficult to handle this with options to `ipa trust-add'. So I would suggest to add a new command to the `ipa trust' family which can set UID ranges for domains before the trust is created. If the trust is already created we may still allow to change the range but with a strong warning that existing UIDs and GIDs will change. bye, Sumit > > 2. Listing trusts > > `ipa trust-find' will show all trusts with other realms corresponding > certain criteria. > > Proposed syntax: > ipa trust-find [CRITERIA] [options] > > where CRITERIA is tested against realms of existing trusts > > Options might include: > * --type ads|ipa|kerberos|etc -- type of the trust > > > 3. Viewing details of trust > > `ipa trust-show' exposes details of the established trust agreement > with a specified realm. > > Proposed syntax: > ipa trust-show [options] > > Details shown will depend on the type of trust with following > information available for all trusts: > * realm name > * trust type > > 4. Removal of existing trus > > `ipa trust-del' removes existing trust agreement > > 5. Access rights > > Trust management requires modification of FreeIPA LDAP database > instance and potentially external resources specific to the trust > nature. cn=trusts,$SUFFIX is used as a container to store information > about trusts with containers inside it for different types of trusts. > > Currently FreeIPA 3.0 implements cn=ad,cn=trusts,$SUFFIX tree for > Active Directory-related trusts. > > Trust management implies limited access which should be implemented > with the help of 389-ds ACIs. > > In order to give users access to the trust management, group of trust > administrators would be created, thus ACI would limit exposure to > cn=trusts,$SUFFIX tree to this group and additional trust > implementation-specific system users defined at cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX. > > Currently AD trusts implement following ACIs per trust: > 1. Trust information: > (target = "ldap:///cn=$DOMAIN,cn=ad,cn=trusts,$SUFFIX") > (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || > ipaNTTrustDirection || > ipaNTTrustPartner || ipaNTFlatName || > ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming || > ipaNTSecurityIdentifier || > ipaNTTrustForestTrustInfo || > ipaNTTrustPosixOffset || > ipaNTSupportedEncryptionTypes") > (version 3.0;acl "Allow samba user to create and delete trust accounts"; > allow (write,add,delete) userdn = "ldap:///$SAMBA_USER_DN";) > > 2. NT Passwords: > (targetattr = "ipaNTHash") > (version 3.0; acl "Samba user can read NT passwords"; > allow (read) userdn="ldap:///$SAMBA_USER_DN";) > > where $SAMBA_USER_DN is DN of special user defined at > uid=samba,cn=sysaccounts,cn=etc,$SUFFIX for the purpose of reading > ipaNTHash attribute (NT passwords) of existing users and accessing > trust information from the ipa-sam database plugin for Samba. > > Current approach requires creating separate ACIs per each trust and > using the same system user account for all of them. As a consequence, > ACIs are added during trust creation and require Directory Manager > privileges which should be discouraged for 'ipa trust' set of > commands. > > Instead, macro ACI could be created that would allow access to the trust information > based on the part of DN of the system user: > > uid=,cn=,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX > > which for AD trusts would be > > uid=samba,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX > > and ACI would be modified to have follow allow stanza: > > (target = "ldap:///($dn),cn=trusts,$SUFFIX") > (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || > ipaNTTrustDirection || > ipaNTTrustPartner || ipaNTFlatName || > ipaNTTrustAuthOutgoing || > ipaNTTrustAuthIncoming || > ipaNTSecurityIdentifier || > ipaNTTrustForestTrustInfo || > ipaNTTrustPosixOffset || > ipaNTSupportedEncryptionTypes") > (version 3.0;acl "Allow trust system user to create and delete trust accounts"; > allow (write,add,delete) userdn="ldap:///uid=*,($dn),cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > (targetattr = "ipaNTHash") > (version 3.0; acl "Samba user can read NT passwords"; > allow (read) userdn="ldap:///uid=*,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > And trust admins ACI: > > (target = "ldap:///cn=trusts,$SUFFIX") > (targetattr = "*") > (version 3.0; acl "Trust management"; > allow (all) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";) > > > This approach would allow us to have a single ACI macro for system > accounts of all types of trusts for all realms and then a single ACI > per trust type. > > Macro ACI are explained at > http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Advanced_Access_Control_Using_Macro_ACIs.html > > > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From edewata at redhat.com Mon Dec 12 19:42:21 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 12 Dec 2011 13:42:21 -0600 Subject: [Freeipa-devel] [PATCH] 055 Association facets are read only in self service In-Reply-To: <4EE61D46.2000200@redhat.com> References: <4EE61D46.2000200@redhat.com> Message-ID: <4EE6591D.5080206@redhat.com> On 12/12/2011 9:27 AM, Petr Vobornik wrote: > This patch works with assumption that user in self-service mode doesn't > have rights for enrolling/un-enrolling himself to/from group, role, hbac > rule, net group, sudo rule. He can only read the attributes. Therefore > in self service mode all user association facets are set read only. > > Checking and working with the actual rights would require significantly > bigger effort. > > https://fedorahosted.org/freeipa/ticket/1972 Pushed to master. -- Endi S. Dewata From edewata at redhat.com Mon Dec 12 20:10:38 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 12 Dec 2011 14:10:38 -0600 Subject: [Freeipa-devel] [PATCH] 056 Added facet tabs coloring In-Reply-To: <4EE64625.2020209@redhat.com> References: <4EE64625.2020209@redhat.com> Message-ID: <4EE65FBE.9080206@redhat.com> On 12/12/2011 12:21 PM, Petr Vobornik wrote: > Facet tabs are now colored according to their group. > > https://fedorahosted.org/freeipa/ticket/1976 This is how it looks: http://edewata.fedorapeople.org/freeipa/install/ui/#identity=group&navigation=identity&group-facet=default&group-pkey=editors Some issues: 1. The original code uses different background images for active/inactive tabs. I think the mockup in the ticket is also showing different backgrounds. The new code uses the same background. 2. The color is coming from an image. It might be better to use CSS color so we can change/add new colors without changing the image. Low priority. 3. This is probably not an issue, but the light blue and dark blue may look too similar to some people. We can change it later if necessary. -- Endi S. Dewata From rcritten at redhat.com Mon Dec 12 20:22:15 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 15:22:15 -0500 Subject: [Freeipa-devel] [PATCH] s4u2proxy support Message-ID: <4EE66277.5060409@redhat.com> This patch adds support for s4u2proxy. This means that the Apache server will obtain the ldap service ticket on behalf of the user rather than the using having to send their TGT. The user's ticket still needs to be forwardable, we just don't require it to be forwarded any more. This patch has a slew of dependencies that aren't yet marked in the spec file. You'll need the latest krb5-server bits from the ipa-devel repo. I don't think they are fully finalized yet which is why I didn't update the spec. A new version of mod_auth_kerb is required as well. I'm in the process of submitting these upstream but for now you can grab the srpm from http://rcritten.fedorapeople.org/mod_auth_kerb-5.4-8.fc15.ipa.src.rpm To test, you just need to install IPA as normal. Nothing should change from the user's perspective. Behind the scenes you'll see that Apache gets a ccache for itself in /tmp/krb5cc_## where ## is the uid of the apache user (48 on my box). Using this ccache Apache will get an ldap service ticket on the user's behalf. The krb5kdc log will look something like: Dec 12 15:05:41 rawhide.example.com krb5kdc[18144](info): ... CONSTRAINED-DELEGATION s4u-client=admin at EXAMPLE.COM If you set LogLevel debug in /etc/httpd/conf.d/nss.conf you'll see a whole lot of extra detail in the Apache error log. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-914-nodelegation.patch Type: text/x-patch Size: 986 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-915-s2u4proxy.patch Type: text/x-patch Size: 4316 bytes Desc: not available URL: From abokovoy at redhat.com Mon Dec 12 20:22:44 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Dec 2011 22:22:44 +0200 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <1323716994.4413.86.camel@willson.li.ssimo.org> References: <20111212174903.GA9668@redhat.com> <1323716994.4413.86.camel@willson.li.ssimo.org> Message-ID: <20111212202243.GB9668@redhat.com> On Mon, 12 Dec 2011, Simo Sorce wrote: > > Creates a trust between FreeIPA realm and another realm of selected > > type. Only 'ads' type is currently supported. > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > following sequence: > > * ipa-adtrust-install > > * net rpc trust create > > I think this is problematic in one regard. It can work only on one > specific server (a general problem of ipa-adtrust-install). We really need to solve a problem of replicated files distribution. In case of ipa-adtrust-install what we have is following: 1. Simple smb.conf generated from a static template with information available everywhere on replicas: - CIFS domain name and Kerberos realm name, - DN of a system account SMB_DN to access trust information, - $SUFFIX 2. smbpasswd with a random password set for the system account SMB_DN 3. Need to restart few services on replicas once AD trust is configured Out of (1)-(3) we only lack (2). However, we can get around this by generating one system account for SMB_DN per replica: uid=,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX and set a password for each of it separately on the replica. This is also why I'm advocating for multiple uids within a trust type. For (3) we need to initiate services restart/config file generation with root privileges. This could be done by a separate daemon that binds to a local LDAP instance and triggers its actions by a replication update. An idea of this daemon was floating around for quite long and I think it is one of few options we are left. So, setting up AD trust (or any other trust type when they will be available) on one master would trigger performing similar actions on other replicas automatically -- given that all needed information can be conveyed through LDAP objects as in this particular case. In case replica will receive update in cn=trusts,$SUFFIX, the daemon would run associated action script and perform remaining configuration steps. This would require slight refactoring of adtrustinstance.py but nothing unreasonable. > I am not sure how to fix it though. Ideally once you create a trust all > IPA servers in the domain should be able to properly handle it. But at > this moment only servers on which you explicitly run > ipa-adtrust-instalkl can. > > Actually even worse, I think ipa-adtrust-install will fail with multiple > servers because the uid=samba user have a random password that cannot be > communicated to other servers ... And this is the case where multiple accounts would help. > > > 2. Listing trusts > > > > `ipa trust-find' will show all trusts with other realms corresponding > > certain criteria. > > > > Proposed syntax: > > ipa trust-find [CRITERIA] [options] > > > > where CRITERIA is tested against realms of existing trusts > > > > Options might include: > > * --type ads|ipa|kerberos|etc -- type of the trust > > > > > > 3. Viewing details of trust > > > > `ipa trust-show' exposes details of the established trust agreement > > with a specified realm. > > > > Proposed syntax: > > ipa trust-show [options] > > > > Details shown will depend on the type of trust with following > > information available for all trusts: > > * realm name > > * trust type > > You may want to add trust direction here. I think we may want to support > incoming only trusts with AD in future (ie we trust AD but AD admins do > not want to trust IPA). Yes, and maybe few other existing attributes that are already defined by our schema as ipaNT*. > > Current approach requires creating separate ACIs per each trust and > > using the same system user account for all of them. As a consequence, > > ACIs are added during trust creation and require Directory Manager > > privileges which should be discouraged for 'ipa trust' set of > > commands. > > We should just use cn=* in the ACI instead of CN=$DOMAIN and add ACIs > only once. No, look below for the proposed ACI -- it uses ($dn) to limit trust access per type -- i.e. uids defined for different trust types will not be able to modify/delete other trusts. > > (target = "ldap:///($dn),cn=trusts,$SUFFIX") > > (targetattr = "ipaNTTrustType || ipaNTTrustAttributes || > > ipaNTTrustDirection || > > ipaNTTrustPartner || ipaNTFlatName || > > ipaNTTrustAuthOutgoing || > > ipaNTTrustAuthIncoming || > > ipaNTSecurityIdentifier || > > ipaNTTrustForestTrustInfo || > > ipaNTTrustPosixOffset || > > ipaNTSupportedEncryptionTypes") > > (version 3.0;acl "Allow trust system user to create and delete trust accounts"; > > allow (write,add,delete) userdn="ldap:///uid=*,($dn),cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > > > (targetattr = "ipaNTHash") > > (version 3.0; acl "Samba user can read NT passwords"; > > allow (read) userdn="ldap:///uid=*,cn=ad,cn=trusts,cn=sysaccounts,cn=etc,$SUFFIX";) > > > > And trust admins ACI: > > > > (target = "ldap:///cn=trusts,$SUFFIX") > > (targetattr = "*") > > (version 3.0; acl "Trust management"; > > allow (all) groupdn="ldap:///cn=trust admins,cn=groups,cn=accounts,$SUFFIX";) > > Although I think we need 'trust admins' ACIs, I do not think we need the > macro ACI for uid=samba. We do not need multiple users for trusts, only > trusts that involve samba needs a separate user at this moment. Multiple system users (each per replica) will help triggering replica initiation for the trust. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Dec 12 20:24:48 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Dec 2011 22:24:48 +0200 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <4EE65190.8050409@redhat.com> References: <20111212174903.GA9668@redhat.com> <4EE65190.8050409@redhat.com> Message-ID: <20111212202448.GC9668@redhat.com> On Mon, 12 Dec 2011, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >Hi, > > > >I'm working on ticket #1821 to introduce FreeIPA 3.0 AD trusts > >management CLI and GUI. It is quite apparent that most of management > >commands will be similar to all future trust types (AD, IPA, etc), > >thus, it makes sense to develop a generalized `ipa trust' family of > >commands that would apply to all types of trusts. > > > >Let's start with CLI. Below is a first cut at how I see trust > >management command line interface. Comments, corrections, and critique > >are all welcomed. > > > >One of FreeIPA v3.0 major features will be support for cross-realm > >trusts with the emphasis on trusts to Active Directory domains. This > >documents attempts to design a common interface for managing trusts > >with FreeIPA tools (command line and GUI). > > > >`ipa trust' > >=========== > > > >`ipa trust' is a common family of operations on trusts. Trusts can be: > > * created (ipa trust-add) > > * listed (ipa trust-find) > > * viewed (ipa trust-show) > > * removed (ipa trust-del) > modified? What can me modify once trust is established? I was unsure in it and decided removing trust and re-creating is simpler. > ipa-adtrust-install runs as root and needs to do things that the IPA > server can't do. Not really -- see my answer to Simo. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Dec 12 20:27:48 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 12 Dec 2011 22:27:48 +0200 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111212194005.GT2262@localhost.localdomain> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> Message-ID: <20111212202747.GD9668@redhat.com> On Mon, 12 Dec 2011, Sumit Bose wrote: > > --password [type-specific parameters] > > > > Creates a trust between FreeIPA realm and another realm of selected > > type. Only 'ads' type is currently supported. > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > following sequence: > > * ipa-adtrust-install > > * net rpc trust create > > As Simo already mentioned theses should be two separate step and `ipa > trust-add' should just check is the needed components to create AD > trusts are already installed on the IPA server. See my answer to Simo, I think we can substantially improve this situation. > Additionally I think we need some commands to define a UID range for the > trusted domains, especially for AD trusts. For the domain given with the > `ipa trust-add' command we could just use another command line option. > But if this domain already has trusts to other domains it will become > difficult to handle this with options to `ipa trust-add'. So I would > suggest to add a new command to the `ipa trust' family which can set UID > ranges for domains before the trust is created. If the trust is already > created we may still allow to change the range but with a strong warning > that existing UIDs and GIDs will change. Ok, this would qualify for ipa trust-add options for UID/GID ranges and would also warrant addition of ipa trust-mod that Rob has proposed. What else except UID/GID ranges could be modified? -- / Alexander Bokovoy From rcritten at redhat.com Mon Dec 12 22:14:52 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 17:14:52 -0500 Subject: [Freeipa-devel] [PATCH] 916 make category and members mutually exclusive in Sudo Message-ID: <4EE67CDC.8010603@redhat.com> This patch makes all categories and their equivalent members mutually exclusive like in the HBAC plugin. So if you have usercat='all' you can't add users. Added test cases for these as well. I also modified the default list of attributes to include the RunAs attributes. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-916-sudo.patch Type: text/x-patch Size: 13500 bytes Desc: not available URL: From rcritten at redhat.com Mon Dec 12 22:22:20 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 17:22:20 -0500 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <20111207114948.GA32281@redhat.com> References: <20111114093243.GA312@redhat.com> <4ED8F15B.7060602@redhat.com> <20111207114948.GA32281@redhat.com> Message-ID: <4EE67E9C.9080805@redhat.com> Alexander Bokovoy wrote: > On Fri, 02 Dec 2011, Rob Crittenden wrote: >> Alexander Bokovoy wrote: >>> Hi, >>> >>> FreeIPA SUDO rules use --usercat/--groupcat to specify that rule >>> applies to all users or groups. Thus, sudorule-add-runasuser and >>> sudorule-add-runasgroup accept specific groups and users and do not >>> accept ALL reserved word. >>> >>> The patch validates user and group passed to these commands and >>> reports appropriate errors when these are ALL or all arguments >>> are empty. >>> >>> Ticket #1496 >>> https://fedorahosted.org/freeipa/ticket/1496 >>> >>> One thing I'm not sure about is blocking all variants of the reserved >>> word 'ALL'. The patch blocks them all due to the fact that most likely >>> any of 'all', 'All', 'ALL', 'aLL', and so on are mistyping but there >>> are might be valid cases when group or user is called 'all'. >> >> Then runasuser check reports runas-group as the attribute name, I >> think it should still be runas-user even though it is a group of >> users. > Ok. Changed. > > >> Other member commands don't consider it an error to provide any >> actual members, it treats it as a no-op. We should probably be >> consistent. > Don't understand. Did you mean 'to not provide any actual members'? > > In case you did, attached patch removes remaining checks for > runas_{user,group) to be False. > > >> It would probably be better to return the value as passed in by the >> user rather than user[0].value. > The issue here is that names come to the callback already as DNs from > LDAPAddMember's execute() method. Strictly speaking it is already > different to what user has entered as we do expansion by default to > add $SUFFIX and appropriate container. > > In the updated patch I tried to reduce DN to something reasonable by > relying on known containers and only showing full DN for cases when > these are not users/groups containers. > ACK on this patch. Do we need to add similar to HBAC plugin and sudorule-add-user, add-command, etc? rob From rcritten at redhat.com Mon Dec 12 22:26:12 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 17:26:12 -0500 Subject: [Freeipa-devel] [PATCH] 5 User-add random password support In-Reply-To: <4EE5F5AF.4010902@redhat.com> References: <4ECE5ABE.3060207@redhat.com> <4ECE760A.7000401@redhat.com> <1322559082.32073.13.camel@balmora.brq.redhat.com> <4EE223C6.1070908@redhat.com> <4EE265A6.7090802@redhat.com> <4EE5F5AF.4010902@redhat.com> Message-ID: <4EE67F84.6030103@redhat.com> Ondrej Hamada wrote: > On 12/09/2011 08:46 PM, Rob Crittenden wrote: >> Ondrej Hamada wrote: >>> On 11/29/2011 10:31 AM, Martin Kosek wrote: >>>> On Thu, 2011-11-24 at 17:51 +0100, Ondrej Hamada wrote: >>>>> On 11/24/2011 03:54 PM, Ondrej Hamada wrote: >>>>>> https://fedorahosted.org/freeipa/ticket/1979 >>>>>> >>>>>> I've used code from ipalib/plugins/host.py to add support for >>>>>> random >>>>>> password generation. The '--random' option is now available in >>>>>> user-add and user-mod commands. If both the 'password' and 'random' >>>>>> options are used the 'random' option will be ignored. >>>>>> >>>>>> >>>> Functionally, it works OK. I would just like to propose few >>>> improvements: >>>> >>>> 1) Minor API version in VERSION file should be bumped since you add a >>>> new option >>>> 2) We should add some tests exercising this new functionality so >>>> that we >>>> can detect regressions early >>>> 3) (optional) I am thinking if the passwords we generate are not very >>>> user friendly. I would love to see user's face when he is told that his >>>> new password is 5QU;8l2%]y"? . >>>> >>>> While this is may be OK for hosts bulk passwords which are only >>>> manipulated by admins, we may want to develop more user friendly >>>> passwords in the user plugin. >>>> >>>> Martin >>>> >>> https://fedorahosted.org/freeipa/ticket/1979 >>> >>> I've used code from ipalib/plugins/host.py to add >>> support for random password generation. The >>> '--random' option is now available in user-add and >>> user-mod commands. If both the 'password' and 'random' >>> options are used the 'random' option will be ignored. >>> >>> Two test cases were added to unit test's module >>> test_user_plugin.py - they test creating and modifying >>> user with random password. Two fuzzy tests were added: >>> test for password(string that doesn't start or end with >>> whitespace and doesn't containt other whitespace than >>> ' ') and for whatever string(because of krbextradata). >>> >>> I've slightly modified ipa_generate_password in order >>> to make passwords for users more user-friendly(reduce >>> number of non-letters). It has two optional parameters >>> now - first one is string of characters that should be >>> used for generating the passwd and second one is length >>> of password. If none parameter is set default values will >>> be used so there's no need to modify other plugins that >>> use random password generator. >> >> This is very, very close. I just have a couple of observations: >> >> 1. Would it be clearer if in user.py you set the character set to: >> string.digits + string.ascii_letters + '_,.@' ? I gather you are >> excluding most of the characters that would cause the shell grief on >> purpose, right? You can probably add in +, - and = though. >> >> 2. Indention in ipa_generate_password() is a bit off. >> >> 3. Rather than fuzzy_string() I think you should define something like >> fuzzy_dergeneralizedtime() that specifies the time format in those >> kerberos time attributes. krbextradata is probably fine as a string. >> >> rob > Corrected and modified according to rob's proposals > > Ondra > ACK, pushed to master. I fixed up a couple of white space issues (some intentions were 8, not 4 spaces) and expanded the commit message to ~72 chars/line. rob From abokovoy at redhat.com Mon Dec 12 22:55:36 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Dec 2011 00:55:36 +0200 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <4EE67E9C.9080805@redhat.com> References: <20111114093243.GA312@redhat.com> <4ED8F15B.7060602@redhat.com> <20111207114948.GA32281@redhat.com> <4EE67E9C.9080805@redhat.com> Message-ID: <20111212225535.GE9668@redhat.com> On Mon, 12 Dec 2011, Rob Crittenden wrote: > >>actual members, it treats it as a no-op. We should probably be > >>consistent. > >Don't understand. Did you mean 'to not provide any actual members'? > > > >In case you did, attached patch removes remaining checks for > >runas_{user,group) to be False. > > > > > >>It would probably be better to return the value as passed in by the > >>user rather than user[0].value. > >The issue here is that names come to the callback already as DNs from > >LDAPAddMember's execute() method. Strictly speaking it is already > >different to what user has entered as we do expansion by default to > >add $SUFFIX and appropriate container. > > > >In the updated patch I tried to reduce DN to something reasonable by > >relying on known containers and only showing full DN for cases when > >these are not users/groups containers. > > > > ACK on this patch. > > Do we need to add similar to HBAC plugin and sudorule-add-user, > add-command, etc? I was thinking about it as well, probably makes sense, indeed. What about reduction code to be a method of DN itself? Something like class DN: def relative_to(self, env, cn_name): try: cn_ = 'container_%s' % (cn_name) if cn_ in env: cn = DN(env[cn_])+DN(env.basedn) else: return self except: return self if self.endswith(cn): return self[0].value return self print dn.relative_to(env, 'user') If this is acceptable, I can do refactoring in a different ticket. -- / Alexander Bokovoy From simo at redhat.com Tue Dec 13 00:15:07 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 12 Dec 2011 19:15:07 -0500 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <4EE66277.5060409@redhat.com> References: <4EE66277.5060409@redhat.com> Message-ID: <1323735307.4413.109.camel@willson.li.ssimo.org> On Mon, 2011-12-12 at 15:22 -0500, Rob Crittenden wrote: > This patch adds support for s4u2proxy. This means that the Apache > server > will obtain the ldap service ticket on behalf of the user rather than > the using having to send their TGT. The user's ticket still needs to > be > forwardable, we just don't require it to be forwarded any more. Should we make the patch allow the old behavior by using a switch that revert to forwarding the TGT ? It would be useful during upgrades if some of your servers still need forwarded TGTs, or if you want to use a newer client against an old server while you have the newer stuff under test. (And to test in general). Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Dec 13 00:17:52 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 12 Dec 2011 19:17:52 -0500 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <1323735307.4413.109.camel@willson.li.ssimo.org> References: <4EE66277.5060409@redhat.com> <1323735307.4413.109.camel@willson.li.ssimo.org> Message-ID: <4EE699B0.1030403@redhat.com> On 12/12/2011 07:15 PM, Simo Sorce wrote: > On Mon, 2011-12-12 at 15:22 -0500, Rob Crittenden wrote: >> This patch adds support for s4u2proxy. This means that the Apache >> server >> will obtain the ldap service ticket on behalf of the user rather than >> the using having to send their TGT. The user's ticket still needs to >> be >> forwardable, we just don't require it to be forwarded any more. > > Should we make the patch allow the old behavior by using a switch that > revert to forwarding the TGT ? > > It would be useful during upgrades if some of your servers still need > forwarded TGTs, or if you want to use a newer client against an old > server while you have the newer stuff under test. > (And to test in general). > > Simo. +1 -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Tue Dec 13 04:07:30 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 23:07:30 -0500 Subject: [Freeipa-devel] [PATCH] 917 user automember for ipa default user Message-ID: <4EE6CF82.5010609@redhat.com> Rather than manually adding users to the default ipa users group configure automember to do it for us. This was quite simple for new installs but a bit complex on upgrades so I implemented it as an update plugin. I also added a unit test for the config module. The majority of config is ignored for now. I'm afraid we'd run into too many false positives if we test each element, and most of these just store data so there isn't a lot that can go wrong. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-917-defaultuser.patch Type: text/x-patch Size: 12807 bytes Desc: not available URL: From rcritten at redhat.com Tue Dec 13 04:09:19 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 12 Dec 2011 23:09:19 -0500 Subject: [Freeipa-devel] [PATCH] 917 user automember for ipa default user In-Reply-To: <4EE6CF82.5010609@redhat.com> References: <4EE6CF82.5010609@redhat.com> Message-ID: <4EE6CFEF.8010606@redhat.com> Rob Crittenden wrote: > Rather than manually adding users to the default ipa users group > configure automember to do it for us. > > This was quite simple for new installs but a bit complex on upgrades so > I implemented it as an update plugin. > > I also added a unit test for the config module. The majority of config > is ignored for now. I'm afraid we'd run into too many false positives if > we test each element, and most of these just store data so there isn't a > lot that can go wrong. > > rob Small revision. I wasn't shipping the update plugin. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-917-1-defaultuser.patch Type: text/x-patch Size: 13333 bytes Desc: not available URL: From pvoborni at redhat.com Tue Dec 13 09:49:07 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Dec 2011 10:49:07 +0100 Subject: [Freeipa-devel] [PATCH] 056 Added facet tabs coloring In-Reply-To: <4EE65FBE.9080206@redhat.com> References: <4EE64625.2020209@redhat.com> <4EE65FBE.9080206@redhat.com> Message-ID: <4EE71F93.6050502@redhat.com> On 12/12/2011 09:10 PM, Endi Sukma Dewata wrote: > On 12/12/2011 12:21 PM, Petr Vobornik wrote: >> Facet tabs are now colored according to their group. >> >> https://fedorahosted.org/freeipa/ticket/1976 > > This is how it looks: > > http://edewata.fedorapeople.org/freeipa/install/ui/#identity=group&navigation=identity&group-facet=default&group-pkey=editors > > > Some issues: > > 1. The original code uses different background images for > active/inactive tabs. I think the mockup in the ticket is also showing > different backgrounds. The new code uses the same background. > Fixed, using the background from mockup - but honestly I don't see much difference. > 2. The color is coming from an image. It might be better to use CSS > color so we can change/add new colors without changing the image. Low > priority. It would be quite interesting combinations of sprite image with parts of the background transparent and linear gradient made by CSS style. Not sure if it would work, probably yes. > 3. This is probably not an issue, but the light blue and dark blue may > look too similar to some people. We can change it later if necessary. > Maybe, looks fine to me. I used the colors from Kyle. 4. Also changed padding in facet tab to vertically center the text. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0056-1-Added-facet-tabs-coloring.patch Type: text/x-patch Size: 5156 bytes Desc: not available URL: From pvoborni at redhat.com Tue Dec 13 10:46:22 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Dec 2011 11:46:22 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173 Create per-type DNS API In-Reply-To: <4EE62B35.7050604@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <4EE1B292.90501@redhat.com> <4EE6026D.2030207@redhat.com> <4EE62B35.7050604@redhat.com> Message-ID: <4EE72CFE.9050505@redhat.com> On 12/12/2011 05:26 PM, Endi Sukma Dewata wrote: > On 12/12/2011 7:32 AM, Petr Vobornik wrote: >>> The first option is we could modify this page to use a table for each >>> type, similar to HBAC/sudo rule. For example: >>> >>> SRV Records >>> >>> x | Priority | Weight | Port | Target [Delete] [Add] >>> ------------------------------------------------------- >>> x | 0 | 100 | 88 | test >> >> I like this option better than the second one. It seems clearer to me. >> >> Just from UI perspective (no change in commands): I would show only the >> the tables which have some values - to let the page be shorter and >> clearer. This will require an add button in the facet header - similar >> dialog with type selection as in add in search facet except that the >> idnsname would be implied. > > The thing with this is that suppose you are looking for a certain type > and that type doesn't exist in that particular record, you would have to > look at the entire page before you know it doesn't exist. But if we show > empty tables, once you see the table you know the record doesn't have > the type you're looking for. My assumption was that there wouldn't be many values of different types for one record so it wouldn't be a problem. Probably not a correct assumption... > > Maybe we can hide the table but still show the table title (i.e. the > type) and an Add button next to it? Sounds like a reasonable compromise. > >>> Note, regardless of these options when you open the details page the UI >>> could execute up to 20 dnsrecord-show operations since there are >>> 20 possible record types currently listed in the UI. > >> To avoid this it would be nice to have a method like dnsrecord-find ZONE >> NAME (ie this one with new option) which would return the record with >> data structure similar to dnsrecord-show. For example (content of >> result): >> [ //record array >> { >> idnsname: 'foo', //name >> arecord: [ >> { >> arecord: '10.10.10.10', //raw >> ip_address: '10.10.10.10' >> } >> ], >> cnamerecord: [ >> { >> cnamerecord: 'bar.example.com.', //raw >> hostname: 'bar.example.com.' >> }, >> { >> cnamerecord: 'bar2.example.com.', //raw >> hostname: 'bar2.example.com.' >> }, >> ] >> } >> ] >> >> This way we would get all info we need without calling batch with 20 >> commands or calling dnsrecord-find and then batch with 1-20 commands. > > Yes, it would be great to have something like that. But the extra NAME > argument above could be confused with search filter for dnsrecord-find. My bad, I accidentally wrote dnsrecord-find instead of dnsrecord-find. But the idea of the structure remains and it could be beneficial in find command (search facet) too. In the case if we decide to show formatted values in the table. > It might be better to use an additional flag to determine the output > format (like --raw), something like this: > > ipa dnsrecord-find ZONE --structured > ipa dnsrecord-show ZONE NAME --structured Yes, this I had in mind by the "new option". > > The structure could also look like this (but either way will work): > > [ > { > idnsname: 'foo', > records: [ > { > type: 'a', > data: '10.10.10.10', > ip_address: '10.10.10.10' > }, > { > type: 'cname', > data: 'bar.example.com.', > hostname: 'bar.example.com.' > }, > { > type: 'cname', > data: 'bar2.example.com.', > hostname: 'bar2.example.com.' > }, > ] > } > ] > > In this case the UI won't use the dnsrecord--show/find command, > but it might still be useful for people using CLI. Or instead of that we > could have another option to specify which types you want to get. > > ipa dnsrecord-show ZONE NAME --types=a,cname --structured > -- Petr Vobornik From mkosek at redhat.com Tue Dec 13 14:13:00 2011 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 13 Dec 2011 15:13:00 +0100 Subject: [Freeipa-devel] [PATCH] 178+179 Add missing managing hosts filtering options In-Reply-To: <4EE285FF.7080202@redhat.com> References: <1323362703.16789.17.camel@balmora.brq.redhat.com> <4EE27BEC.6090607@redhat.com> <4EE285FF.7080202@redhat.com> Message-ID: <1323785580.4265.26.camel@balmora.brq.redhat.com> On Fri, 2011-12-09 at 16:04 -0600, Endi Sukma Dewata wrote: > On 12/9/2011 3:21 PM, Endi Sukma Dewata wrote: > > On 12/8/2011 10:45 AM, Martin Kosek wrote: > >> Host object has a virtual attribute "managing" containing all hosts > >> it manages (governed by managedBy attribute). This patch also adds > >> standard membership filtering options: > >> --man-hosts=HOSTS: Only hosts managing _all_ HOSTS are returned > >> --not-man-hosts=HOSTS: Only hosts which do not manage _any_ host > >> in HOSTS are returned > >> > >> https://fedorahosted.org/freeipa/ticket/1675 > > > > ACK, it works for me. I'll update the UI to use the new option. > > I take that back. It's NACK. > Patch #178 causes the dnszone-find --forward-only to return the reverse > zone. > Good catch, thanks. Fixed. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-178-2-fix-ldap2-combine_filters.patch Type: text/x-patch Size: 3623 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-179-2-add-missing-managing-hosts-filtering-options.patch Type: text/x-patch Size: 10660 bytes Desc: not available URL: From pvoborni at redhat.com Tue Dec 13 15:05:06 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 13 Dec 2011 16:05:06 +0100 Subject: [Freeipa-devel] [PATCH] 331 Enabled paging on self-service permissions and delegations. In-Reply-To: <4EE2B6D8.10807@redhat.com> References: <4EE2B6D8.10807@redhat.com> Message-ID: <4EE769A2.1050203@redhat.com> On 12/10/2011 02:33 AM, Endi Sukma Dewata wrote: > Paging has been enabled on self-service permissions and delegations > list pages. The search facet's get_pkeys() has been fixed to handle > non-array value. New test data files have been added as well. > > Ticket #2092 > > This patch depends on Martin's patch #180. > ACK Push should wait for Martin's patch ACK/push. -- Petr Vobornik From rcritten at redhat.com Tue Dec 13 15:49:35 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Dec 2011 10:49:35 -0500 Subject: [Freeipa-devel] [PATCH] pushed Referer patch Message-ID: <4EE7740F.6080907@redhat.com> I had only pushed the Referer patch for CVE-2011-3636 to the ipa-2-1 branch. I cherry-picked it into master and pushed it. rob From simo at redhat.com Tue Dec 13 16:30:47 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 13 Dec 2011 11:30:47 -0500 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111212202747.GD9668@redhat.com> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> Message-ID: <1323793847.4413.144.camel@willson.li.ssimo.org> On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > --password [type-specific parameters] > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > type. Only 'ads' type is currently supported. > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > following sequence: > > > * ipa-adtrust-install > > > * net rpc trust create > > > > As Simo already mentioned theses should be two separate step and `ipa > > trust-add' should just check is the needed components to create AD > > trusts are already installed on the IPA server. > See my answer to Simo, I think we can substantially improve this > situation. > > > Additionally I think we need some commands to define a UID range for the > > trusted domains, especially for AD trusts. For the domain given with the > > `ipa trust-add' command we could just use another command line option. > > But if this domain already has trusts to other domains it will become > > difficult to handle this with options to `ipa trust-add'. So I would > > suggest to add a new command to the `ipa trust' family which can set UID > > ranges for domains before the trust is created. If the trust is already > > created we may still allow to change the range but with a strong warning > > that existing UIDs and GIDs will change. > Ok, this would qualify for ipa trust-add options for UID/GID ranges > and would also warrant addition of ipa trust-mod that Rob has proposed. > > What else except UID/GID ranges could be modified? Ok we had a discussion this morning about how to handle this. We decided to do a few things to simplify installing and managing the problem when multiple replicas are involved. 1. We will fold back as much as possible into ipa-server-install (and update scripts for 2 -> 3 updates), in particular we will move generic ACI creation (including additional ACI for a new group called Trusts Admins), and the creation of a system user called adtrust and associated DS user under uid=adtrust,cn=sysaccount,cn=etc, 2. We will preconfigure DS so that SASL/EXTERNAL authentication with that user results in using the uid=adtrust DN that will have also pre-assigned ACIs 3. We will change samba's ipasm to use the adtrust user and SASL/EXTERNAL auth to access DS in order to have privilege separation. This means smbd keeps operating as a restricted user but will not need a password to be set via smbpasswd -e 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will verify the necessary trust objects are in place and enables starting the adtrust service (smbd daemon, cldap plugin, ...) It also adds the server to the _msdcs DNS hive. 5. Each ipa server admins need to use as a bridge to/from AD will need to be 'activated' by running ipa-adtrust-enable once for now. We can also consider automatically running it by passing a --enable-adtrust parameter to ipa-replica-install 6. We change ipa-replica-manage to make sure _msdcs records are also deleted when a replica is removed. This should be all, please send corrections if I forgot something. Simo. -- Simo Sorce * Red Hat, Inc * New York From abokovoy at redhat.com Tue Dec 13 17:08:24 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 13 Dec 2011 19:08:24 +0200 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <1323793847.4413.144.camel@willson.li.ssimo.org> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> <1323793847.4413.144.camel@willson.li.ssimo.org> Message-ID: <20111213170819.GG9668@redhat.com> On Tue, 13 Dec 2011, Simo Sorce wrote: > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > > --password [type-specific parameters] > > > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > > type. Only 'ads' type is currently supported. > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > > following sequence: > > > > * ipa-adtrust-install > > > > * net rpc trust create > > > > > > As Simo already mentioned theses should be two separate step and `ipa > > > trust-add' should just check is the needed components to create AD > > > trusts are already installed on the IPA server. > > See my answer to Simo, I think we can substantially improve this > > situation. > > > > > Additionally I think we need some commands to define a UID range for the > > > trusted domains, especially for AD trusts. For the domain given with the > > > `ipa trust-add' command we could just use another command line option. > > > But if this domain already has trusts to other domains it will become > > > difficult to handle this with options to `ipa trust-add'. So I would > > > suggest to add a new command to the `ipa trust' family which can set UID > > > ranges for domains before the trust is created. If the trust is already > > > created we may still allow to change the range but with a strong warning > > > that existing UIDs and GIDs will change. > > Ok, this would qualify for ipa trust-add options for UID/GID ranges > > and would also warrant addition of ipa trust-mod that Rob has proposed. > > > > What else except UID/GID ranges could be modified? > > > Ok we had a discussion this morning about how to handle this. > > We decided to do a few things to simplify installing and managing the > problem when multiple replicas are involved. > > 1. We will fold back as much as possible into ipa-server-install (and > update scripts for 2 -> 3 updates), in particular we will move generic > ACI creation (including additional ACI for a new group called Trusts > Admins), and the creation of a system user called adtrust and associated > DS user under uid=adtrust,cn=sysaccount,cn=etc, > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with > that user results in using the uid=adtrust DN that will have also > pre-assigned ACIs > > 3. We will change samba's ipasm to use the adtrust user and > SASL/EXTERNAL auth to access DS in order to have privilege separation. > This means smbd keeps operating as a restricted user but will not need a > password to be set via smbpasswd -e > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will > verify the necessary trust objects are in place and enables starting the > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server > to the _msdcs DNS hive. > > 5. Each ipa server admins need to use as a bridge to/from AD will need > to be 'activated' by running ipa-adtrust-enable once for now. We can > also consider automatically running it by passing a --enable-adtrust > parameter to ipa-replica-install > > 6. We change ipa-replica-manage to make sure _msdcs records are also > deleted when a replica is removed. > > > This should be all, please send corrections if I forgot something. 'ipa trust' family of commands will be used to manage trust information after configuration -- listing existing trusts, removing and modifying them. In addition, 'ipa trust-add' will do similar ground work when configuring AD trusts on the master -- it will ensure all needed records are in LDAP (or will create them) and will ask admin to use ipa-adtrust-enable to actually activate the trust. All this is due to the fact that we need to start/restart services with root privileges. This way we can have a common CLI that will stay the same for all future trust variants and instruct admins how to activate actual trust relationship once it is configured. If we'll find solutions to automate activation process, we can then replace the instructions with the actual calls to activation. -- / Alexander Bokovoy From rcritten at redhat.com Wed Dec 14 04:20:06 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 13 Dec 2011 23:20:06 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema Message-ID: <4EE823F6.4080401@redhat.com> The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter but these weren't available in the sudorule plugin. I've added support for these. sudoOrder enforces uniqueness because duplicates are undefined. I also added support for a GeneralizedTime parameter type. This is similar to the existing AccessTime parameter but it only handles a single time value. The sudo patch relies on my patch 916 or you'll have merge issues. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-918-generalizedtime.patch Type: text/x-patch Size: 9205 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-919-sudo.patch Type: text/x-patch Size: 15569 bytes Desc: not available URL: From mkosek at redhat.com Wed Dec 14 06:53:08 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Dec 2011 07:53:08 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <4EE275D3.3030508@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> <4EE275D3.3030508@redhat.com> Message-ID: <1323845588.2234.18.camel@priserak> On Fri, 2011-12-09 at 15:55 -0500, Rob Crittenden wrote: > Martin Kosek wrote: > > On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: > >> Martin Kosek wrote: > >>> On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: > >>>> I have prepared a working prototype of the new structured DNS API. It > >>>> may still have rough edges (and unit tests are not ready), but it will > >>>> provide a base for discussion and for WebUI folks - so that they can > >>>> start development of the new DNS WebUI API. > >>>> > >>>> The patch takes advantage of the DNS refactor I did in 172. For all > >>>> supported non-DNSSEC RR types, the following commands are available: > >>>> > >>>> dnsrecord-show ZONE NAME > >>>> dnsrecord-add ZONE NAME > >>>> dnsrecord-mod ZONE NAME VALUE > >>>> > >>>> This is an example of the new API in action: > >>>> > >>>> # ipa dnsrecord-show example.com foo > >>>> Record name: foo > >>>> A record: 10.0.0.1 > >>>> > >>>> # ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com." > >>>> MX record: 0 foo.example.com. > >>>> Preference: 0 > >>>> Exchanger: foo.example.com. > >>>> ---------------------------- > >>>> Number of entries returned 1 > >>>> ---------------------------- > >>>> > >>>> # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger="foo.example.com." > >>>> MX record: 0 foo.example.com. > >>>> Preference: 0 > >>>> Exchanger: foo.example.com. > >>>> > >>>> MX record: 1 foo.example.com. > >>>> Preference: 1 > >>>> Exchanger: foo.example.com. > >>>> ---------------------------- > >>>> Number of entries returned 2 > >>>> ---------------------------- > >>>> > >>>> # ipa dnsrecordmx-show example.com foo > >>>> MX record: 0 foo.example.com. > >>>> Preference: 0 > >>>> Exchanger: foo.example.com. > >>>> > >>>> MX record: 1 foo.example.com. > >>>> Preference: 1 > >>>> Exchanger: foo.example.com. > >>>> ---------------------------- > >>>> Number of entries returned 2 > >>>> ---------------------------- > >>>> > >>>> > >>>> There is an interactive wizard to help user modify a record without > >>>> specifying an updated value first. If there is just one (MX) record, no > >>>> wizard would be run. > >>>> > >>>> # ipa dnsrecordmx-mod example.com foo --preference=2 > >>>> Which MX record would you like to modify? > >>>> > >>>> [1]: 0 foo.example.com. > >>>> [2]: 1 foo.example.com. > >>>> > >>>> DNS record number: 2 > >>>> MX record: 0 foo.example.com. > >>>> Preference: 0 > >>>> Exchanger: foo.example.com. > >>>> > >>>> MX record: 2 foo.example.com. > >>>> Preference: 2 > >>>> Exchanger: foo.example.com. > >>>> ---------------------------- > >>>> Number of entries returned 2 > >>>> ---------------------------- > >>>> > >>>> # ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3 > >>>> MX record: 0 foo.example.com. > >>>> Preference: 0 > >>>> Exchanger: foo.example.com. > >>>> > >>>> MX record: 3 foo.example.com. > >>>> Preference: 3 > >>>> Exchanger: foo.example.com. > >>>> ---------------------------- > >>>> Number of entries returned 2 > >>>> ---------------------------- > >>>> > >>>> > >>>> There are few open questions I am still thinking about: > >>>> > >>>> 1) The commands return a list of structured records (just like *-find > >>>> commands) instead of returning just one record. I thought that it may be > >>>> more usable this way and consistent with dnsrecord-add/mod/show commands > >>>> behavior which returns all records too. Otherwise, we would have to > >>>> change the show command API and add VALUE argument, which would specify > >>>> a value to be displayed: > >>>> dnsrecord-show ZONE NAME VALUE > >>>> > >>>> 2) Raw DNS record value is in the output too. I though it would be > >>>> useful to see the raw DNS record value + its parts at one place. > >>>> > >>>> 3) The commands are in format dnsrecord-cmd, for example > >>>> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we > >>>> want to go this way, I would have to bend the server framework a little > >>>> which parses an LDAP object from the command name (LDAP object name is > >>>> dnsrecordmx in this case). This is doable, although I am not sure if > >>>> this does not have some implications in WebUI side. > >>>> > >>>> Martin > >>> > >>> I rebased both patches to the most recent master. Adding CSVs now works > >>> ok again (with the fix in 175): > >>> > >>> # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 > >>> Record name: foo > >>> A record: 10.0.0.1, 10.0.0.2 > >>> > >>> Martin > >> > > > > Rob, thank you for the review! What do you think about the 3 open > > questions I posted above? > > > >> I think some abbreviations can be eliminated: > >> > >> siz -> size > >> alt -> altitude > > > > Sure, this can be fixed. > > > >> > >> For MX record (and probably KX) you can make preference required. It > >> should fill in without prompting since it has a default. This way it > >> will show as required in the UI. > > > > Right, we don't want to run into issues we had with user fields. > > > >> > >> PTRRecord doc I think would read better as "The hostname this reverse > >> record points to" > > > > Ok. Btw do you think it would be good to document this way all these new > > DNSRecord part parameters? As I checked with Petr, these would be shown > > in the UI - so the UI user would benefit from it. But it will require a > > lot of writing and RFC study :-) > > > >> > >> I'm not sure I follow the makeapi change. I see the new entry types in > >> API.txt but this makeapi seems to suggest the DNS api is not checked. > > > > This fix is in validate_doc(), which tries to check that all our > > commands have proper __doc__ string. It fails with the new DNS API > > commands (dnsrecordmx-add etc.) because it cannot find class definitions > > in dns.py. This is expected as I generate all these LDAP command classes > > on the fly from new DNSRecord parameters. > > > > Martin > > > >> > >> Otherwise generally looks good. > >> > >> rob > > > > > > Build not working: > > ./make-lint > ipalib/parameters.py:718: [E1101, Param.normalize] Generator > '__unicode_csv_reader' has no 'next' member I must be using older version of pylint - it didn't occurred on my box. I will add a pylint hint to ignore this one. > > I found this works ok and adding records is definitely clearer but it > seems odd to add with one command and delete/find with another. I could > get used to it I suppose. Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this would increase the already high number of DNS commands. Endi and Petr had an idea to add a new --structured option for dnsrecord-find/dnsrecord-show which would show structured DNS records instead of raw DNS records. But I think our current framework is not ready for this. While a raw DNS record is basically one entry item (label : value), structured DNS record is an entry on its own ({label1:value1, label2:value2, ...}): - dnsrecord-find's output is ListOfEntries, but with use of --structured option it would have to be changed to something like ListOfListsOfEntries - dnsrecord-show's output would have to be changed with a use of --structured option from Entry to ListOfEntries > > Help per command doesn't work: > > $ ipa help dnsrecorda > ipa: ERROR: no command nor help topic 'dnsrecorda' Hm, help on LDAP objects (dnsrecord, dnsrecordloc) never worked. We can only get help for topics (python module name - "dns" in this case) or commands - dnsrecorda-add/mod/show. It worked for me: ipa help dnsrecorda-mod Purpose: Modify a record of resource record type A ... > > Not sure if we want specific help or simply point back to dnsrecord > which might be a bit overwhelming. > > $ ipa dnsrecordloc-add --help > > This is is a significant improvement! Yeah, I think it will help users construct even complex DNS records without having to know all the RFCs with record format. Martin From mkosek at redhat.com Wed Dec 14 07:02:29 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Dec 2011 08:02:29 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173 Create per-type DNS API In-Reply-To: <4EE1B292.90501@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <4EE1B292.90501@redhat.com> Message-ID: <1323846149.2234.26.camel@priserak> On Fri, 2011-12-09 at 01:02 -0600, Endi Sukma Dewata wrote: > On 11/28/2011 10:35 AM, Martin Kosek wrote: > > 1) The commands return a list of structured records (just like *-find > > commands) instead of returning just one record. I thought that it may be > > more usable this way and consistent with dnsrecord-add/mod/show commands > > behavior which returns all records too. Otherwise, we would have to > > change the show command API and add VALUE argument, which would specify > > a value to be displayed: > > dnsrecord-show ZONE NAME VALUE > > I think for consistency it would be better to call this command > dnsrecord-find since it returns multiple entries. We might also > be able to add filters in the future. We may do that but I would be cautious with filters - we cannot use standard LDAP filters since the structured DNS records are constructed in the framework, LDAP stores just raw values. If we go with find, it would have this syntax: dnsrecord-find ZONE NAME > > > 2) Raw DNS record value is in the output too. I though it would be > > useful to see the raw DNS record value + its parts at one place. > > Yes, the raw value will be needed for calling dnsrecord-mod or > dnsrecord-del command. Ok, I will leave it here then. I may rename it from record parameter to name common for all structured commands - "data" for example. Use may be able to make difference between structured DNS name:value pairs and the raw value. It may look like this: # ipa dnsrecordmx-show example.com @ Raw DNS data: 0 server1.example.com Preference: 0 Exchanger: server1.example.com # ipa dnsrecordns-show example.com @ Raw DNS data: vm-068.idm.lab.bos.redhat.com. Hostname: vm-068.idm.lab.bos.redhat.com. > > > 3) The commands are in format dnsrecord-cmd, for example > > dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we > > want to go this way, I would have to bend the server framework a little > > which parses an LDAP object from the command name (LDAP object name is > > dnsrecordmx in this case). This is doable, although I am not sure if > > this does not have some implications in WebUI side. > > I agree, the extra dash would be better. When calling a command the UI > concatenates entity name and method name with an '_'. In this case the > entity name will remain dnsrecord and the RRTYPE will be prepended to > the method name. I agree, I will add the dash. > > Btw, patch #175 causes a build break: > > ipalib/parameters.py:718: [E1101, Param.normalize] Generator > '__unicode_csv_reader' has no 'next' member > This will be fixed. It seems that I had an older pylint version which didn't detect this false positive. Martin From mkosek at redhat.com Wed Dec 14 07:24:42 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Dec 2011 08:24:42 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173 Create per-type DNS API In-Reply-To: <4EE72CFE.9050505@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <4EE1B292.90501@redhat.com> <4EE6026D.2030207@redhat.com> <4EE62B35.7050604@redhat.com> <4EE72CFE.9050505@redhat.com> Message-ID: <1323847482.2234.41.camel@priserak> On Tue, 2011-12-13 at 11:46 +0100, Petr Vobornik wrote: > On 12/12/2011 05:26 PM, Endi Sukma Dewata wrote: > > On 12/12/2011 7:32 AM, Petr Vobornik wrote: > >>> The first option is we could modify this page to use a table for each > >>> type, similar to HBAC/sudo rule. For example: > >>> > >>> SRV Records > >>> > >>> x | Priority | Weight | Port | Target [Delete] [Add] > >>> ------------------------------------------------------- > >>> x | 0 | 100 | 88 | test > >> > >> I like this option better than the second one. It seems clearer to me. > >> > >> Just from UI perspective (no change in commands): I would show only the > >> the tables which have some values - to let the page be shorter and > >> clearer. This will require an add button in the facet header - similar > >> dialog with type selection as in add in search facet except that the > >> idnsname would be implied. > > > > The thing with this is that suppose you are looking for a certain type > > and that type doesn't exist in that particular record, you would have to > > look at the entire page before you know it doesn't exist. But if we show > > empty tables, once you see the table you know the record doesn't have > > the type you're looking for. > > My assumption was that there wouldn't be many values of different types > for one record so it wouldn't be a problem. Probably not a correct > assumption... > > > > Maybe we can hide the table but still show the table title (i.e. the > > type) and an Add button next to it? > > Sounds like a reasonable compromise. > > > >>> Note, regardless of these options when you open the details page the UI > >>> could execute up to 20 dnsrecord-show operations since there are > >>> 20 possible record types currently listed in the UI. > > > >> To avoid this it would be nice to have a method like dnsrecord-find ZONE > >> NAME (ie this one with new option) which would return the record with > >> data structure similar to dnsrecord-show. For example (content of > >> result): > >> [ //record array > >> { > >> idnsname: 'foo', //name > >> arecord: [ > >> { > >> arecord: '10.10.10.10', //raw > >> ip_address: '10.10.10.10' > >> } > >> ], > >> cnamerecord: [ > >> { > >> cnamerecord: 'bar.example.com.', //raw > >> hostname: 'bar.example.com.' > >> }, > >> { > >> cnamerecord: 'bar2.example.com.', //raw > >> hostname: 'bar2.example.com.' > >> }, > >> ] > >> } > >> ] > >> > >> This way we would get all info we need without calling batch with 20 > >> commands or calling dnsrecord-find and then batch with 1-20 commands. > > > > Yes, it would be great to have something like that. But the extra NAME > > argument above could be confused with search filter for dnsrecord-find. > > My bad, I accidentally wrote dnsrecord-find instead of dnsrecord-find. > But the idea of the structure remains and it could be beneficial in find > command (search facet) too. In the case if we decide to show formatted > values in the table. > > > It might be better to use an additional flag to determine the output > > format (like --raw), something like this: > > > > ipa dnsrecord-find ZONE --structured > > ipa dnsrecord-show ZONE NAME --structured > > Yes, this I had in mind by the "new option". > > > > The structure could also look like this (but either way will work): > > > > [ > > { > > idnsname: 'foo', > > records: [ > > { > > type: 'a', > > data: '10.10.10.10', > > ip_address: '10.10.10.10' > > }, > > { > > type: 'cname', > > data: 'bar.example.com.', > > hostname: 'bar.example.com.' > > }, > > { > > type: 'cname', > > data: 'bar2.example.com.', > > hostname: 'bar2.example.com.' > > }, > > ] > > } > > ] > > > > In this case the UI won't use the dnsrecord--show/find command, > > but it might still be useful for people using CLI. Or instead of that we > > could have another option to specify which types you want to get. > > > > ipa dnsrecord-show ZONE NAME --types=a,cname --structured > > > > I was thinking about --structured option too, I wrote some info in a response to Rob's mail. But the thing is that --structured option changes the command's output structure too much. One command could return both Entry and ListOfEntries which is not good IMO. Another problem I see is that different RR types have parts with the same name (e.g. "preference" is both in MX, KX and NAPTR records). If any record could appear in an output entry, we would break current rule that every output parameter in an entry is uniquely defined. Though this issue could be solved with a prefix for every structured DNS record part, i.e. KX record would have "kxpreference" and "kxechanger" parts. Martin From sbose at redhat.com Wed Dec 14 09:23:54 2011 From: sbose at redhat.com (Sumit Bose) Date: Wed, 14 Dec 2011 10:23:54 +0100 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111213170819.GG9668@redhat.com> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> <1323793847.4413.144.camel@willson.li.ssimo.org> <20111213170819.GG9668@redhat.com> Message-ID: <20111214092354.GC18396@localhost.localdomain> On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote: > On Tue, 13 Dec 2011, Simo Sorce wrote: > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > > > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > > > --password [type-specific parameters] > > > > > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > > > type. Only 'ads' type is currently supported. > > > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > > > following sequence: > > > > > * ipa-adtrust-install > > > > > * net rpc trust create > > > > > > > > As Simo already mentioned theses should be two separate step and `ipa > > > > trust-add' should just check is the needed components to create AD > > > > trusts are already installed on the IPA server. > > > See my answer to Simo, I think we can substantially improve this > > > situation. > > > > > > > Additionally I think we need some commands to define a UID range for the > > > > trusted domains, especially for AD trusts. For the domain given with the > > > > `ipa trust-add' command we could just use another command line option. > > > > But if this domain already has trusts to other domains it will become > > > > difficult to handle this with options to `ipa trust-add'. So I would > > > > suggest to add a new command to the `ipa trust' family which can set UID > > > > ranges for domains before the trust is created. If the trust is already > > > > created we may still allow to change the range but with a strong warning > > > > that existing UIDs and GIDs will change. > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges > > > and would also warrant addition of ipa trust-mod that Rob has proposed. > > > > > > What else except UID/GID ranges could be modified? > > > > > > Ok we had a discussion this morning about how to handle this. > > > > We decided to do a few things to simplify installing and managing the > > problem when multiple replicas are involved. > > > > 1. We will fold back as much as possible into ipa-server-install (and > > update scripts for 2 -> 3 updates), in particular we will move generic > > ACI creation (including additional ACI for a new group called Trusts > > Admins), and the creation of a system user called adtrust and associated > > DS user under uid=adtrust,cn=sysaccount,cn=etc, > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with > > that user results in using the uid=adtrust DN that will have also > > pre-assigned ACIs > > > > 3. We will change samba's ipasm to use the adtrust user and > > SASL/EXTERNAL auth to access DS in order to have privilege separation. > > This means smbd keeps operating as a restricted user but will not need a > > password to be set via smbpasswd -e > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will > > verify the necessary trust objects are in place and enables starting the > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server > > to the _msdcs DNS hive. > > > > 5. Each ipa server admins need to use as a bridge to/from AD will need > > to be 'activated' by running ipa-adtrust-enable once for now. We can > > also consider automatically running it by passing a --enable-adtrust > > parameter to ipa-replica-install > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also > > deleted when a replica is removed. > > > > > > This should be all, please send corrections if I forgot something. > 'ipa trust' family of commands will be used to manage trust > information after configuration -- listing existing trusts, removing > and modifying them. > > In addition, 'ipa trust-add' will do similar ground work > when configuring AD trusts on the master -- it will ensure all needed > records are in LDAP (or will create them) and will ask admin to use > ipa-adtrust-enable to actually activate the trust. All this is due to > the fact that we need to start/restart services with root privileges. > > This way we can have a common CLI that will stay the same for all > future trust variants and instruct admins how to activate actual trust > relationship once it is configured. > > If we'll find solutions to automate activation process, we can then > replace the instructions with the actual calls to activation. Simo, Alexander thank you for the summary. I have an open ticket (#1614) which I planned to add to ipa-adtrust-install but which might be better solved elsewhere whit the current plans. In ticket #1614 a DNS plugin configuration shall be created to add SIDs to IPA user which should be used in the trusted AD domain as well. We can create the DNA configuration with the initial setup of the IPA domain, but since we current store SID strings in the related attribute the domain SID of the IPA domain must be know. I can think of two was to solve this. One would be to not store the SID string, but only the RID part of the SID and let the ipasam plugin add the domain SID when needed. The other that we create the ipaNTDomainAttrs object during the initial setup as well. I would prefer the second one. The only problem here is that we need a flat name (aka NetBIOS name) for the domain. ipa-adtrust-install has some logic to derive this from the IPA domain name, but there might be circumstances where we have to ask the user to provide a flat name. If this is acceptable I would vote to add the creation of the ipaNTDomainAttrs object to the initial setup of the IPA domain as well. Which way would you prefer? bye, Sumit > -- > / Alexander Bokovoy > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From jcholast at redhat.com Wed Dec 14 10:36:40 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 14 Dec 2011 11:36:40 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <1323845588.2234.18.camel@priserak> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> <4EE275D3.3030508@redhat.com> <1323845588.2234.18.camel@priserak> Message-ID: <4EE87C38.5000009@redhat.com> Dne 14.12.2011 07:53, Martin Kosek napsal(a): > On Fri, 2011-12-09 at 15:55 -0500, Rob Crittenden wrote: >> Martin Kosek wrote: >>> On Thu, 2011-12-01 at 17:18 -0500, Rob Crittenden wrote: >>>> Martin Kosek wrote: >>>>> On Mon, 2011-11-28 at 17:35 +0100, Martin Kosek wrote: >>>>>> I have prepared a working prototype of the new structured DNS API. It >>>>>> may still have rough edges (and unit tests are not ready), but it will >>>>>> provide a base for discussion and for WebUI folks - so that they can >>>>>> start development of the new DNS WebUI API. >>>>>> >>>>>> The patch takes advantage of the DNS refactor I did in 172. For all >>>>>> supported non-DNSSEC RR types, the following commands are available: >>>>>> >>>>>> dnsrecord-show ZONE NAME >>>>>> dnsrecord-add ZONE NAME >>>>>> dnsrecord-mod ZONE NAME VALUE >>>>>> >>>>>> This is an example of the new API in action: >>>>>> >>>>>> # ipa dnsrecord-show example.com foo >>>>>> Record name: foo >>>>>> A record: 10.0.0.1 >>>>>> >>>>>> # ipa dnsrecordmx-add example.com foo --exchanger="foo.example.com." >>>>>> MX record: 0 foo.example.com. >>>>>> Preference: 0 >>>>>> Exchanger: foo.example.com. >>>>>> ---------------------------- >>>>>> Number of entries returned 1 >>>>>> ---------------------------- >>>>>> >>>>>> # ipa dnsrecordmx-add example.com foo --preference=1 --exchanger="foo.example.com." >>>>>> MX record: 0 foo.example.com. >>>>>> Preference: 0 >>>>>> Exchanger: foo.example.com. >>>>>> >>>>>> MX record: 1 foo.example.com. >>>>>> Preference: 1 >>>>>> Exchanger: foo.example.com. >>>>>> ---------------------------- >>>>>> Number of entries returned 2 >>>>>> ---------------------------- >>>>>> >>>>>> # ipa dnsrecordmx-show example.com foo >>>>>> MX record: 0 foo.example.com. >>>>>> Preference: 0 >>>>>> Exchanger: foo.example.com. >>>>>> >>>>>> MX record: 1 foo.example.com. >>>>>> Preference: 1 >>>>>> Exchanger: foo.example.com. >>>>>> ---------------------------- >>>>>> Number of entries returned 2 >>>>>> ---------------------------- >>>>>> >>>>>> >>>>>> There is an interactive wizard to help user modify a record without >>>>>> specifying an updated value first. If there is just one (MX) record, no >>>>>> wizard would be run. >>>>>> >>>>>> # ipa dnsrecordmx-mod example.com foo --preference=2 >>>>>> Which MX record would you like to modify? >>>>>> >>>>>> [1]: 0 foo.example.com. >>>>>> [2]: 1 foo.example.com. >>>>>> >>>>>> DNS record number: 2 >>>>>> MX record: 0 foo.example.com. >>>>>> Preference: 0 >>>>>> Exchanger: foo.example.com. >>>>>> >>>>>> MX record: 2 foo.example.com. >>>>>> Preference: 2 >>>>>> Exchanger: foo.example.com. >>>>>> ---------------------------- >>>>>> Number of entries returned 2 >>>>>> ---------------------------- >>>>>> >>>>>> # ipa dnsrecordmx-mod example.com foo "2 foo.example.com." --preference=3 >>>>>> MX record: 0 foo.example.com. >>>>>> Preference: 0 >>>>>> Exchanger: foo.example.com. >>>>>> >>>>>> MX record: 3 foo.example.com. >>>>>> Preference: 3 >>>>>> Exchanger: foo.example.com. >>>>>> ---------------------------- >>>>>> Number of entries returned 2 >>>>>> ---------------------------- >>>>>> >>>>>> >>>>>> There are few open questions I am still thinking about: >>>>>> >>>>>> 1) The commands return a list of structured records (just like *-find >>>>>> commands) instead of returning just one record. I thought that it may be >>>>>> more usable this way and consistent with dnsrecord-add/mod/show commands >>>>>> behavior which returns all records too. Otherwise, we would have to >>>>>> change the show command API and add VALUE argument, which would specify >>>>>> a value to be displayed: >>>>>> dnsrecord-show ZONE NAME VALUE >>>>>> >>>>>> 2) Raw DNS record value is in the output too. I though it would be >>>>>> useful to see the raw DNS record value + its parts at one place. >>>>>> >>>>>> 3) The commands are in format dnsrecord-cmd, for example >>>>>> dnsrecordmx-add. I think dnsrecord-mx-add may be more readable. If we >>>>>> want to go this way, I would have to bend the server framework a little >>>>>> which parses an LDAP object from the command name (LDAP object name is >>>>>> dnsrecordmx in this case). This is doable, although I am not sure if >>>>>> this does not have some implications in WebUI side. >>>>>> >>>>>> Martin >>>>> >>>>> I rebased both patches to the most recent master. Adding CSVs now works >>>>> ok again (with the fix in 175): >>>>> >>>>> # ipa dnsrecord-mod example.com foo --a-rec=10.0.0.1,10.0.0.2 >>>>> Record name: foo >>>>> A record: 10.0.0.1, 10.0.0.2 >>>>> >>>>> Martin >>>> >>> >>> Rob, thank you for the review! What do you think about the 3 open >>> questions I posted above? >>> >>>> I think some abbreviations can be eliminated: >>>> >>>> siz -> size >>>> alt -> altitude >>> >>> Sure, this can be fixed. >>> >>>> >>>> For MX record (and probably KX) you can make preference required. It >>>> should fill in without prompting since it has a default. This way it >>>> will show as required in the UI. >>> >>> Right, we don't want to run into issues we had with user fields. >>> >>>> >>>> PTRRecord doc I think would read better as "The hostname this reverse >>>> record points to" >>> >>> Ok. Btw do you think it would be good to document this way all these new >>> DNSRecord part parameters? As I checked with Petr, these would be shown >>> in the UI - so the UI user would benefit from it. But it will require a >>> lot of writing and RFC study :-) >>> >>>> >>>> I'm not sure I follow the makeapi change. I see the new entry types in >>>> API.txt but this makeapi seems to suggest the DNS api is not checked. >>> >>> This fix is in validate_doc(), which tries to check that all our >>> commands have proper __doc__ string. It fails with the new DNS API >>> commands (dnsrecordmx-add etc.) because it cannot find class definitions >>> in dns.py. This is expected as I generate all these LDAP command classes >>> on the fly from new DNSRecord parameters. >>> >>> Martin >>> >>>> >>>> Otherwise generally looks good. >>>> >>>> rob >>> >>> >> >> Build not working: >> >> ./make-lint >> ipalib/parameters.py:718: [E1101, Param.normalize] Generator >> '__unicode_csv_reader' has no 'next' member > > I must be using older version of pylint - it didn't occurred on my box. > I will add a pylint hint to ignore this one. Regarding patch 175, I think a fix like this would be somewhat nicer: def normalize(self, value): ... if self.multivalue: if type(value) not in (tuple, list): value = (value,) if self.csv: newval = () for v in value: if isinstance(v, basestring): csvreader = self.__unicode_csv_reader([unicode(v)]) newval += tuple(csvreader.next()) #pylint: disable=E1101 else: newval += (v,) value = newval ... > >> >> I found this works ok and adding records is definitely clearer but it >> seems odd to add with one command and delete/find with another. I could >> get used to it I suppose. > > Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this > would increase the already high number of DNS commands. > > Endi and Petr had an idea to add a new --structured option for > dnsrecord-find/dnsrecord-show which would show structured DNS records > instead of raw DNS records. But I think our current framework is not > ready for this. While a raw DNS record is basically one entry item > (label : value), structured DNS record is an entry on its own > ({label1:value1, label2:value2, ...}): > - dnsrecord-find's output is ListOfEntries, but with use of > --structured option it would have to be changed to something like > ListOfListsOfEntries > - dnsrecord-show's output would have to be changed with a use of > --structured option from Entry to ListOfEntries > >> >> Help per command doesn't work: >> >> $ ipa help dnsrecorda >> ipa: ERROR: no command nor help topic 'dnsrecorda' > > Hm, help on LDAP objects (dnsrecord, dnsrecordloc) never worked. We can > only get help for topics (python module name - "dns" in this case) or > commands - dnsrecorda-add/mod/show. It worked for me: > > ipa help dnsrecorda-mod > Purpose: Modify a record of resource record type A > ... > >> >> Not sure if we want specific help or simply point back to dnsrecord >> which might be a bit overwhelming. >> >> $ ipa dnsrecordloc-add --help >> >> This is is a significant improvement! > > Yeah, I think it will help users construct even complex DNS records > without having to know all the RFCs with record format. > > Martin > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Jan Cholasta From abokovoy at redhat.com Wed Dec 14 11:58:08 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 14 Dec 2011 13:58:08 +0200 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111214092354.GC18396@localhost.localdomain> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> <1323793847.4413.144.camel@willson.li.ssimo.org> <20111213170819.GG9668@redhat.com> <20111214092354.GC18396@localhost.localdomain> Message-ID: <20111214115808.GA31520@redhat.com> On Wed, 14 Dec 2011, Sumit Bose wrote: > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote: > > On Tue, 13 Dec 2011, Simo Sorce wrote: > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > > > > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > > > > --password [type-specific parameters] > > > > > > > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > > > > type. Only 'ads' type is currently supported. > > > > > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > > > > following sequence: > > > > > > * ipa-adtrust-install > > > > > > * net rpc trust create > > > > > > > > > > As Simo already mentioned theses should be two separate step and `ipa > > > > > trust-add' should just check is the needed components to create AD > > > > > trusts are already installed on the IPA server. > > > > See my answer to Simo, I think we can substantially improve this > > > > situation. > > > > > > > > > Additionally I think we need some commands to define a UID range for the > > > > > trusted domains, especially for AD trusts. For the domain given with the > > > > > `ipa trust-add' command we could just use another command line option. > > > > > But if this domain already has trusts to other domains it will become > > > > > difficult to handle this with options to `ipa trust-add'. So I would > > > > > suggest to add a new command to the `ipa trust' family which can set UID > > > > > ranges for domains before the trust is created. If the trust is already > > > > > created we may still allow to change the range but with a strong warning > > > > > that existing UIDs and GIDs will change. > > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges > > > > and would also warrant addition of ipa trust-mod that Rob has proposed. > > > > > > > > What else except UID/GID ranges could be modified? > > > > > > > > > Ok we had a discussion this morning about how to handle this. > > > > > > We decided to do a few things to simplify installing and managing the > > > problem when multiple replicas are involved. > > > > > > 1. We will fold back as much as possible into ipa-server-install (and > > > update scripts for 2 -> 3 updates), in particular we will move generic > > > ACI creation (including additional ACI for a new group called Trusts > > > Admins), and the creation of a system user called adtrust and associated > > > DS user under uid=adtrust,cn=sysaccount,cn=etc, > > > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with > > > that user results in using the uid=adtrust DN that will have also > > > pre-assigned ACIs > > > > > > 3. We will change samba's ipasm to use the adtrust user and > > > SASL/EXTERNAL auth to access DS in order to have privilege separation. > > > This means smbd keeps operating as a restricted user but will not need a > > > password to be set via smbpasswd -e > > > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will > > > verify the necessary trust objects are in place and enables starting the > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server > > > to the _msdcs DNS hive. > > > > > > 5. Each ipa server admins need to use as a bridge to/from AD will need > > > to be 'activated' by running ipa-adtrust-enable once for now. We can > > > also consider automatically running it by passing a --enable-adtrust > > > parameter to ipa-replica-install > > > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also > > > deleted when a replica is removed. > > > > > > > > > This should be all, please send corrections if I forgot something. > > 'ipa trust' family of commands will be used to manage trust > > information after configuration -- listing existing trusts, removing > > and modifying them. > > > > In addition, 'ipa trust-add' will do similar ground work > > when configuring AD trusts on the master -- it will ensure all needed > > records are in LDAP (or will create them) and will ask admin to use > > ipa-adtrust-enable to actually activate the trust. All this is due to > > the fact that we need to start/restart services with root privileges. > > > > This way we can have a common CLI that will stay the same for all > > future trust variants and instruct admins how to activate actual trust > > relationship once it is configured. > > > > If we'll find solutions to automate activation process, we can then > > replace the instructions with the actual calls to activation. > > Simo, Alexander thank you for the summary. > > I have an open ticket (#1614) which I planned to add to > ipa-adtrust-install but which might be better solved elsewhere whit the > current plans. > > In ticket #1614 a DNS plugin configuration shall be created to add SIDs > to IPA user which should be used in the trusted AD domain as well. We > can create the DNA configuration with the initial setup of the IPA > domain, but since we current store SID strings in the related attribute > the domain SID of the IPA domain must be know. I can think of two was to > solve this. One would be to not store the SID string, but only the RID > part of the SID and let the ipasam plugin add the domain SID when > needed. The other that we create the ipaNTDomainAttrs object during the > initial setup as well. I would prefer the second one. The only problem > here is that we need a flat name (aka NetBIOS name) for the domain. > ipa-adtrust-install has some logic to derive this from the IPA domain > name, but there might be circumstances where we have to ask the user to > provide a flat name. If this is acceptable I would vote to add the > creation of the ipaNTDomainAttrs object to the initial setup of the > IPA domain as well. > > Which way would you prefer? I'm also preferring the second approach. I think we can opt to provide a separate option in ipa-server-install to specify a flat name as we now always show a summary of configuration before going into actual install. This means that generated name could be checked prior to install and overriden. -- / Alexander Bokovoy From jcholast at redhat.com Wed Dec 14 12:11:17 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 14 Dec 2011 13:11:17 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4EE823F6.4080401@redhat.com> References: <4EE823F6.4080401@redhat.com> Message-ID: <4EE89265.1000602@redhat.com> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): > The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter > but these weren't available in the sudorule plugin. > > I've added support for these. sudoOrder enforces uniqueness because > duplicates are undefined. > > I also added support for a GeneralizedTime parameter type. This is > similar to the existing AccessTime parameter but it only handles a > single time value. You should parse the date/time part of the value with time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, that way you'll get most of the validation for free. Also, it would be nice to be able to enter the value in more user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize that to LDAP generalized time. > > The sudo patch relies on my patch 916 or you'll have merge issues. > > rob > Honza -- Jan Cholasta From simo at redhat.com Wed Dec 14 12:45:53 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Dec 2011 07:45:53 -0500 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111214092354.GC18396@localhost.localdomain> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> <1323793847.4413.144.camel@willson.li.ssimo.org> <20111213170819.GG9668@redhat.com> <20111214092354.GC18396@localhost.localdomain> Message-ID: <1323866753.4413.180.camel@willson.li.ssimo.org> On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote: > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote: > > On Tue, 13 Dec 2011, Simo Sorce wrote: > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > > > > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > > > > --password [type-specific parameters] > > > > > > > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > > > > type. Only 'ads' type is currently supported. > > > > > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > > > > following sequence: > > > > > > * ipa-adtrust-install > > > > > > * net rpc trust create > > > > > > > > > > As Simo already mentioned theses should be two separate step and `ipa > > > > > trust-add' should just check is the needed components to create AD > > > > > trusts are already installed on the IPA server. > > > > See my answer to Simo, I think we can substantially improve this > > > > situation. > > > > > > > > > Additionally I think we need some commands to define a UID range for the > > > > > trusted domains, especially for AD trusts. For the domain given with the > > > > > `ipa trust-add' command we could just use another command line option. > > > > > But if this domain already has trusts to other domains it will become > > > > > difficult to handle this with options to `ipa trust-add'. So I would > > > > > suggest to add a new command to the `ipa trust' family which can set UID > > > > > ranges for domains before the trust is created. If the trust is already > > > > > created we may still allow to change the range but with a strong warning > > > > > that existing UIDs and GIDs will change. > > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges > > > > and would also warrant addition of ipa trust-mod that Rob has proposed. > > > > > > > > What else except UID/GID ranges could be modified? > > > > > > > > > Ok we had a discussion this morning about how to handle this. > > > > > > We decided to do a few things to simplify installing and managing the > > > problem when multiple replicas are involved. > > > > > > 1. We will fold back as much as possible into ipa-server-install (and > > > update scripts for 2 -> 3 updates), in particular we will move generic > > > ACI creation (including additional ACI for a new group called Trusts > > > Admins), and the creation of a system user called adtrust and associated > > > DS user under uid=adtrust,cn=sysaccount,cn=etc, > > > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with > > > that user results in using the uid=adtrust DN that will have also > > > pre-assigned ACIs > > > > > > 3. We will change samba's ipasm to use the adtrust user and > > > SASL/EXTERNAL auth to access DS in order to have privilege separation. > > > This means smbd keeps operating as a restricted user but will not need a > > > password to be set via smbpasswd -e > > > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will > > > verify the necessary trust objects are in place and enables starting the > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server > > > to the _msdcs DNS hive. > > > > > > 5. Each ipa server admins need to use as a bridge to/from AD will need > > > to be 'activated' by running ipa-adtrust-enable once for now. We can > > > also consider automatically running it by passing a --enable-adtrust > > > parameter to ipa-replica-install > > > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also > > > deleted when a replica is removed. > > > > > > > > > This should be all, please send corrections if I forgot something. > > 'ipa trust' family of commands will be used to manage trust > > information after configuration -- listing existing trusts, removing > > and modifying them. > > > > In addition, 'ipa trust-add' will do similar ground work > > when configuring AD trusts on the master -- it will ensure all needed > > records are in LDAP (or will create them) and will ask admin to use > > ipa-adtrust-enable to actually activate the trust. All this is due to > > the fact that we need to start/restart services with root privileges. > > > > This way we can have a common CLI that will stay the same for all > > future trust variants and instruct admins how to activate actual trust > > relationship once it is configured. > > > > If we'll find solutions to automate activation process, we can then > > replace the instructions with the actual calls to activation. > > Simo, Alexander thank you for the summary. > > I have an open ticket (#1614) which I planned to add to > ipa-adtrust-install but which might be better solved elsewhere whit the > current plans. > > In ticket #1614 a DNS plugin configuration shall be created to add SIDs > to IPA user which should be used in the trusted AD domain as well. We > can create the DNA configuration with the initial setup of the IPA > domain, but since we current store SID strings in the related attribute > the domain SID of the IPA domain must be know. I can think of two was to > solve this. One would be to not store the SID string, but only the RID > part of the SID and let the ipasam plugin add the domain SID when > needed. The other that we create the ipaNTDomainAttrs object during the > initial setup as well. I would prefer the second one. The only problem > here is that we need a flat name (aka NetBIOS name) for the domain. > ipa-adtrust-install has some logic to derive this from the IPA domain > name, but there might be circumstances where we have to ask the user to > provide a flat name. If this is acceptable I would vote to add the > creation of the ipaNTDomainAttrs object to the initial setup of the > IPA domain as well. > > Which way would you prefer? We can also generate the SID algorithmically from the uidNumber/gidNumber Simo. -- Simo Sorce * Red Hat, Inc * New York From sbose at redhat.com Wed Dec 14 13:12:03 2011 From: sbose at redhat.com (Sumit Bose) Date: Wed, 14 Dec 2011 14:12:03 +0100 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <1323866753.4413.180.camel@willson.li.ssimo.org> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> <1323793847.4413.144.camel@willson.li.ssimo.org> <20111213170819.GG9668@redhat.com> <20111214092354.GC18396@localhost.localdomain> <1323866753.4413.180.camel@willson.li.ssimo.org> Message-ID: <20111214131203.GA17111@localhost.localdomain> On Wed, Dec 14, 2011 at 07:45:53AM -0500, Simo Sorce wrote: > On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote: > > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote: > > > On Tue, 13 Dec 2011, Simo Sorce wrote: > > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > > > > > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > > > > > --password [type-specific parameters] > > > > > > > > > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > > > > > type. Only 'ads' type is currently supported. > > > > > > > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > > > > > following sequence: > > > > > > > * ipa-adtrust-install > > > > > > > * net rpc trust create > > > > > > > > > > > > As Simo already mentioned theses should be two separate step and `ipa > > > > > > trust-add' should just check is the needed components to create AD > > > > > > trusts are already installed on the IPA server. > > > > > See my answer to Simo, I think we can substantially improve this > > > > > situation. > > > > > > > > > > > Additionally I think we need some commands to define a UID range for the > > > > > > trusted domains, especially for AD trusts. For the domain given with the > > > > > > `ipa trust-add' command we could just use another command line option. > > > > > > But if this domain already has trusts to other domains it will become > > > > > > difficult to handle this with options to `ipa trust-add'. So I would > > > > > > suggest to add a new command to the `ipa trust' family which can set UID > > > > > > ranges for domains before the trust is created. If the trust is already > > > > > > created we may still allow to change the range but with a strong warning > > > > > > that existing UIDs and GIDs will change. > > > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges > > > > > and would also warrant addition of ipa trust-mod that Rob has proposed. > > > > > > > > > > What else except UID/GID ranges could be modified? > > > > > > > > > > > > Ok we had a discussion this morning about how to handle this. > > > > > > > > We decided to do a few things to simplify installing and managing the > > > > problem when multiple replicas are involved. > > > > > > > > 1. We will fold back as much as possible into ipa-server-install (and > > > > update scripts for 2 -> 3 updates), in particular we will move generic > > > > ACI creation (including additional ACI for a new group called Trusts > > > > Admins), and the creation of a system user called adtrust and associated > > > > DS user under uid=adtrust,cn=sysaccount,cn=etc, > > > > > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with > > > > that user results in using the uid=adtrust DN that will have also > > > > pre-assigned ACIs > > > > > > > > 3. We will change samba's ipasm to use the adtrust user and > > > > SASL/EXTERNAL auth to access DS in order to have privilege separation. > > > > This means smbd keeps operating as a restricted user but will not need a > > > > password to be set via smbpasswd -e > > > > > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will > > > > verify the necessary trust objects are in place and enables starting the > > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server > > > > to the _msdcs DNS hive. > > > > > > > > 5. Each ipa server admins need to use as a bridge to/from AD will need > > > > to be 'activated' by running ipa-adtrust-enable once for now. We can > > > > also consider automatically running it by passing a --enable-adtrust > > > > parameter to ipa-replica-install > > > > > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also > > > > deleted when a replica is removed. > > > > > > > > > > > > This should be all, please send corrections if I forgot something. > > > 'ipa trust' family of commands will be used to manage trust > > > information after configuration -- listing existing trusts, removing > > > and modifying them. > > > > > > In addition, 'ipa trust-add' will do similar ground work > > > when configuring AD trusts on the master -- it will ensure all needed > > > records are in LDAP (or will create them) and will ask admin to use > > > ipa-adtrust-enable to actually activate the trust. All this is due to > > > the fact that we need to start/restart services with root privileges. > > > > > > This way we can have a common CLI that will stay the same for all > > > future trust variants and instruct admins how to activate actual trust > > > relationship once it is configured. > > > > > > If we'll find solutions to automate activation process, we can then > > > replace the instructions with the actual calls to activation. > > > > Simo, Alexander thank you for the summary. > > > > I have an open ticket (#1614) which I planned to add to > > ipa-adtrust-install but which might be better solved elsewhere whit the > > current plans. > > > > In ticket #1614 a DNS plugin configuration shall be created to add SIDs > > to IPA user which should be used in the trusted AD domain as well. We > > can create the DNA configuration with the initial setup of the IPA > > domain, but since we current store SID strings in the related attribute > > the domain SID of the IPA domain must be know. I can think of two was to > > solve this. One would be to not store the SID string, but only the RID > > part of the SID and let the ipasam plugin add the domain SID when > > needed. The other that we create the ipaNTDomainAttrs object during the > > initial setup as well. I would prefer the second one. The only problem > > here is that we need a flat name (aka NetBIOS name) for the domain. > > ipa-adtrust-install has some logic to derive this from the IPA domain > > name, but there might be circumstances where we have to ask the user to > > provide a flat name. If this is acceptable I would vote to add the > > creation of the ipaNTDomainAttrs object to the initial setup of the > > IPA domain as well. > > > > Which way would you prefer? > > We can also generate the SID algorithmically from the > uidNumber/gidNumber Do you mean the SID of the trusted domain user? Currently I didn't set a uidNumber/gidNumber for this users, because for my tests so far I didn't needed it. And since uidNumber/gidNumber and the SID will be handle independently by the DNA plugin there would be a small chance for a collision. bye, Sumit > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From simo at redhat.com Wed Dec 14 13:31:57 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 14 Dec 2011 08:31:57 -0500 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111214131203.GA17111@localhost.localdomain> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> <1323793847.4413.144.camel@willson.li.ssimo.org> <20111213170819.GG9668@redhat.com> <20111214092354.GC18396@localhost.localdomain> <1323866753.4413.180.camel@willson.li.ssimo.org> <20111214131203.GA17111@localhost.localdomain> Message-ID: <1323869517.4413.189.camel@willson.li.ssimo.org> On Wed, 2011-12-14 at 14:12 +0100, Sumit Bose wrote: > On Wed, Dec 14, 2011 at 07:45:53AM -0500, Simo Sorce wrote: > > On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote: > > > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote: > > > > On Tue, 13 Dec 2011, Simo Sorce wrote: > > > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > > > > > > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > > > > > > --password [type-specific parameters] > > > > > > > > > > > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > > > > > > type. Only 'ads' type is currently supported. > > > > > > > > > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > > > > > > following sequence: > > > > > > > > * ipa-adtrust-install > > > > > > > > * net rpc trust create > > > > > > > > > > > > > > As Simo already mentioned theses should be two separate step and `ipa > > > > > > > trust-add' should just check is the needed components to create AD > > > > > > > trusts are already installed on the IPA server. > > > > > > See my answer to Simo, I think we can substantially improve this > > > > > > situation. > > > > > > > > > > > > > Additionally I think we need some commands to define a UID range for the > > > > > > > trusted domains, especially for AD trusts. For the domain given with the > > > > > > > `ipa trust-add' command we could just use another command line option. > > > > > > > But if this domain already has trusts to other domains it will become > > > > > > > difficult to handle this with options to `ipa trust-add'. So I would > > > > > > > suggest to add a new command to the `ipa trust' family which can set UID > > > > > > > ranges for domains before the trust is created. If the trust is already > > > > > > > created we may still allow to change the range but with a strong warning > > > > > > > that existing UIDs and GIDs will change. > > > > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges > > > > > > and would also warrant addition of ipa trust-mod that Rob has proposed. > > > > > > > > > > > > What else except UID/GID ranges could be modified? > > > > > > > > > > > > > > > Ok we had a discussion this morning about how to handle this. > > > > > > > > > > We decided to do a few things to simplify installing and managing the > > > > > problem when multiple replicas are involved. > > > > > > > > > > 1. We will fold back as much as possible into ipa-server-install (and > > > > > update scripts for 2 -> 3 updates), in particular we will move generic > > > > > ACI creation (including additional ACI for a new group called Trusts > > > > > Admins), and the creation of a system user called adtrust and associated > > > > > DS user under uid=adtrust,cn=sysaccount,cn=etc, > > > > > > > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with > > > > > that user results in using the uid=adtrust DN that will have also > > > > > pre-assigned ACIs > > > > > > > > > > 3. We will change samba's ipasm to use the adtrust user and > > > > > SASL/EXTERNAL auth to access DS in order to have privilege separation. > > > > > This means smbd keeps operating as a restricted user but will not need a > > > > > password to be set via smbpasswd -e > > > > > > > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will > > > > > verify the necessary trust objects are in place and enables starting the > > > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server > > > > > to the _msdcs DNS hive. > > > > > > > > > > 5. Each ipa server admins need to use as a bridge to/from AD will need > > > > > to be 'activated' by running ipa-adtrust-enable once for now. We can > > > > > also consider automatically running it by passing a --enable-adtrust > > > > > parameter to ipa-replica-install > > > > > > > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also > > > > > deleted when a replica is removed. > > > > > > > > > > > > > > > This should be all, please send corrections if I forgot something. > > > > 'ipa trust' family of commands will be used to manage trust > > > > information after configuration -- listing existing trusts, removing > > > > and modifying them. > > > > > > > > In addition, 'ipa trust-add' will do similar ground work > > > > when configuring AD trusts on the master -- it will ensure all needed > > > > records are in LDAP (or will create them) and will ask admin to use > > > > ipa-adtrust-enable to actually activate the trust. All this is due to > > > > the fact that we need to start/restart services with root privileges. > > > > > > > > This way we can have a common CLI that will stay the same for all > > > > future trust variants and instruct admins how to activate actual trust > > > > relationship once it is configured. > > > > > > > > If we'll find solutions to automate activation process, we can then > > > > replace the instructions with the actual calls to activation. > > > > > > Simo, Alexander thank you for the summary. > > > > > > I have an open ticket (#1614) which I planned to add to > > > ipa-adtrust-install but which might be better solved elsewhere whit the > > > current plans. > > > > > > In ticket #1614 a DNS plugin configuration shall be created to add SIDs > > > to IPA user which should be used in the trusted AD domain as well. We > > > can create the DNA configuration with the initial setup of the IPA > > > domain, but since we current store SID strings in the related attribute > > > the domain SID of the IPA domain must be know. I can think of two was to > > > solve this. One would be to not store the SID string, but only the RID > > > part of the SID and let the ipasam plugin add the domain SID when > > > needed. The other that we create the ipaNTDomainAttrs object during the > > > initial setup as well. I would prefer the second one. The only problem > > > here is that we need a flat name (aka NetBIOS name) for the domain. > > > ipa-adtrust-install has some logic to derive this from the IPA domain > > > name, but there might be circumstances where we have to ask the user to > > > provide a flat name. If this is acceptable I would vote to add the > > > creation of the ipaNTDomainAttrs object to the initial setup of the > > > IPA domain as well. > > > > > > Which way would you prefer? > > > > We can also generate the SID algorithmically from the > > uidNumber/gidNumber > > Do you mean the SID of the trusted domain user? No I meant the SID of users and groups. > Currently I didn't set a > uidNumber/gidNumber for this users, because for my tests so far I didn't > needed it. That user can have assigned a SID that is very low, so it is assured to be out of the randomly chosen ranges. > And since uidNumber/gidNumber and the SID will be handle > independently by the DNA plugin there would be a small chance for a > collision. Thing is, if you want to use DNA we have to be careful as it needs to be enabled ast the same time for all servers or risk getting some users w/o the NT SID. If we want to delay storing SIDs after adtrusts are enabled (probably a good idea as this will be the same situation as a v2 to v3 upgrade) then we need to make sure the DNA plugin is completely reconfigured from the public shared tree and not partly configured in cn=config. We will also need a fixup task to generate SIDs for all users/groups that predates the activation of the NT SID creation in DNA. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Wed Dec 14 14:23:52 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Dec 2011 09:23:52 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4EE89265.1000602@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> Message-ID: <4EE8B178.1030808@redhat.com> Jan Cholasta wrote: > Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >> The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter >> but these weren't available in the sudorule plugin. >> >> I've added support for these. sudoOrder enforces uniqueness because >> duplicates are undefined. >> >> I also added support for a GeneralizedTime parameter type. This is >> similar to the existing AccessTime parameter but it only handles a >> single time value. > > You should parse the date/time part of the value with > time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, > that way you'll get most of the validation for free. Yes but it gives a crappy error message, just saying that some data is left over not what is wrong. > Also, it would be nice to be able to enter the value in more > user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize > that to LDAP generalized time. When dealing with time there are so many ways to input and display the same values this becomes difficult. I'd expect that the times for these two attributes will be relatively simple and I somehow doubt users are going to want seconds, leap seconds or fractions, but we'll need to consider how to do it for future consistency (otherwise we could have a case where time is entered in one format for some attributes and another for others). If we input in a nice way we need to output in the same way. rob From sbose at redhat.com Wed Dec 14 14:45:08 2011 From: sbose at redhat.com (Sumit Bose) Date: Wed, 14 Dec 2011 15:45:08 +0100 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <1323869517.4413.189.camel@willson.li.ssimo.org> References: <20111212174903.GA9668@redhat.com> <20111212194005.GT2262@localhost.localdomain> <20111212202747.GD9668@redhat.com> <1323793847.4413.144.camel@willson.li.ssimo.org> <20111213170819.GG9668@redhat.com> <20111214092354.GC18396@localhost.localdomain> <1323866753.4413.180.camel@willson.li.ssimo.org> <20111214131203.GA17111@localhost.localdomain> <1323869517.4413.189.camel@willson.li.ssimo.org> Message-ID: <20111214144508.GB17111@localhost.localdomain> On Wed, Dec 14, 2011 at 08:31:57AM -0500, Simo Sorce wrote: > On Wed, 2011-12-14 at 14:12 +0100, Sumit Bose wrote: > > On Wed, Dec 14, 2011 at 07:45:53AM -0500, Simo Sorce wrote: > > > On Wed, 2011-12-14 at 10:23 +0100, Sumit Bose wrote: > > > > On Tue, Dec 13, 2011 at 07:08:24PM +0200, Alexander Bokovoy wrote: > > > > > On Tue, 13 Dec 2011, Simo Sorce wrote: > > > > > > On Mon, 2011-12-12 at 22:27 +0200, Alexander Bokovoy wrote: > > > > > > > On Mon, 12 Dec 2011, Sumit Bose wrote: > > > > > > > > > --password [type-specific parameters] > > > > > > > > > > > > > > > > > > Creates a trust between FreeIPA realm and another realm of selected > > > > > > > > > type. Only 'ads' type is currently supported. > > > > > > > > > > > > > > > > > > For 'ads' type running `ipa trust-add' would be equivalent to > > > > > > > > > following sequence: > > > > > > > > > * ipa-adtrust-install > > > > > > > > > * net rpc trust create > > > > > > > > > > > > > > > > As Simo already mentioned theses should be two separate step and `ipa > > > > > > > > trust-add' should just check is the needed components to create AD > > > > > > > > trusts are already installed on the IPA server. > > > > > > > See my answer to Simo, I think we can substantially improve this > > > > > > > situation. > > > > > > > > > > > > > > > Additionally I think we need some commands to define a UID range for the > > > > > > > > trusted domains, especially for AD trusts. For the domain given with the > > > > > > > > `ipa trust-add' command we could just use another command line option. > > > > > > > > But if this domain already has trusts to other domains it will become > > > > > > > > difficult to handle this with options to `ipa trust-add'. So I would > > > > > > > > suggest to add a new command to the `ipa trust' family which can set UID > > > > > > > > ranges for domains before the trust is created. If the trust is already > > > > > > > > created we may still allow to change the range but with a strong warning > > > > > > > > that existing UIDs and GIDs will change. > > > > > > > Ok, this would qualify for ipa trust-add options for UID/GID ranges > > > > > > > and would also warrant addition of ipa trust-mod that Rob has proposed. > > > > > > > > > > > > > > What else except UID/GID ranges could be modified? > > > > > > > > > > > > > > > > > > Ok we had a discussion this morning about how to handle this. > > > > > > > > > > > > We decided to do a few things to simplify installing and managing the > > > > > > problem when multiple replicas are involved. > > > > > > > > > > > > 1. We will fold back as much as possible into ipa-server-install (and > > > > > > update scripts for 2 -> 3 updates), in particular we will move generic > > > > > > ACI creation (including additional ACI for a new group called Trusts > > > > > > Admins), and the creation of a system user called adtrust and associated > > > > > > DS user under uid=adtrust,cn=sysaccount,cn=etc, > > > > > > > > > > > > 2. We will preconfigure DS so that SASL/EXTERNAL authentication with > > > > > > that user results in using the uid=adtrust DN that will have also > > > > > > pre-assigned ACIs > > > > > > > > > > > > 3. We will change samba's ipasm to use the adtrust user and > > > > > > SASL/EXTERNAL auth to access DS in order to have privilege separation. > > > > > > This means smbd keeps operating as a restricted user but will not need a > > > > > > password to be set via smbpasswd -e > > > > > > > > > > > > 4. We change ipa-adtrust-install to ipa-adtrust-enable, this script will > > > > > > verify the necessary trust objects are in place and enables starting the > > > > > > adtrust service (smbd daemon, cldap plugin, ...) It also adds the server > > > > > > to the _msdcs DNS hive. > > > > > > > > > > > > 5. Each ipa server admins need to use as a bridge to/from AD will need > > > > > > to be 'activated' by running ipa-adtrust-enable once for now. We can > > > > > > also consider automatically running it by passing a --enable-adtrust > > > > > > parameter to ipa-replica-install > > > > > > > > > > > > 6. We change ipa-replica-manage to make sure _msdcs records are also > > > > > > deleted when a replica is removed. > > > > > > > > > > > > > > > > > > This should be all, please send corrections if I forgot something. > > > > > 'ipa trust' family of commands will be used to manage trust > > > > > information after configuration -- listing existing trusts, removing > > > > > and modifying them. > > > > > > > > > > In addition, 'ipa trust-add' will do similar ground work > > > > > when configuring AD trusts on the master -- it will ensure all needed > > > > > records are in LDAP (or will create them) and will ask admin to use > > > > > ipa-adtrust-enable to actually activate the trust. All this is due to > > > > > the fact that we need to start/restart services with root privileges. > > > > > > > > > > This way we can have a common CLI that will stay the same for all > > > > > future trust variants and instruct admins how to activate actual trust > > > > > relationship once it is configured. > > > > > > > > > > If we'll find solutions to automate activation process, we can then > > > > > replace the instructions with the actual calls to activation. > > > > > > > > Simo, Alexander thank you for the summary. > > > > > > > > I have an open ticket (#1614) which I planned to add to > > > > ipa-adtrust-install but which might be better solved elsewhere whit the > > > > current plans. > > > > > > > > In ticket #1614 a DNS plugin configuration shall be created to add SIDs > > > > to IPA user which should be used in the trusted AD domain as well. We > > > > can create the DNA configuration with the initial setup of the IPA > > > > domain, but since we current store SID strings in the related attribute > > > > the domain SID of the IPA domain must be know. I can think of two was to > > > > solve this. One would be to not store the SID string, but only the RID > > > > part of the SID and let the ipasam plugin add the domain SID when > > > > needed. The other that we create the ipaNTDomainAttrs object during the > > > > initial setup as well. I would prefer the second one. The only problem > > > > here is that we need a flat name (aka NetBIOS name) for the domain. > > > > ipa-adtrust-install has some logic to derive this from the IPA domain > > > > name, but there might be circumstances where we have to ask the user to > > > > provide a flat name. If this is acceptable I would vote to add the > > > > creation of the ipaNTDomainAttrs object to the initial setup of the > > > > IPA domain as well. > > > > > > > > Which way would you prefer? > > > > > > We can also generate the SID algorithmically from the > > > uidNumber/gidNumber > > > > Do you mean the SID of the trusted domain user? > > No I meant the SID of users and groups. ok, I would very much favor this approach it will make things much easier. But iirc the idea was rejected some time ago, because we couldn't agree on a good algorithm which can remove the conflicts when uid and gid are the same. What would you suggest? Adding the highest bit for groups? uid*2 for users, (gid*2)+1 for groups? ... ? bye, Sumit > > > Currently I didn't set a > > uidNumber/gidNumber for this users, because for my tests so far I didn't > > needed it. > > That user can have assigned a SID that is very low, so it is assured to > be out of the randomly chosen ranges. > > > And since uidNumber/gidNumber and the SID will be handle > > independently by the DNA plugin there would be a small chance for a > > collision. > > Thing is, if you want to use DNA we have to be careful as it needs to be > enabled ast the same time for all servers or risk getting some users w/o > the NT SID. > > If we want to delay storing SIDs after adtrusts are enabled (probably a > good idea as this will be the same situation as a v2 to v3 upgrade) > then we need to make sure the DNA plugin is completely reconfigured from > the public shared tree and not partly configured in cn=config. > > We will also need a fixup task to generate SIDs for all users/groups > that predates the activation of the NT SID creation in DNA. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > From jcholast at redhat.com Wed Dec 14 15:10:03 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 14 Dec 2011 16:10:03 +0100 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4EE8B178.1030808@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> Message-ID: <4EE8BC4B.3090209@redhat.com> Dne 14.12.2011 15:23, Rob Crittenden napsal(a): > Jan Cholasta wrote: >> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>> The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter >>> but these weren't available in the sudorule plugin. >>> >>> I've added support for these. sudoOrder enforces uniqueness because >>> duplicates are undefined. >>> >>> I also added support for a GeneralizedTime parameter type. This is >>> similar to the existing AccessTime parameter but it only handles a >>> single time value. >> >> You should parse the date/time part of the value with >> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, >> that way you'll get most of the validation for free. > > Yes but it gives a crappy error message, just saying that some data is > left over not what is wrong. IMHO having a separate error message for every field in the time string (like you do in the patch) is an overkill, simple "invalid time" and/or "unknown time format" should suffice (we don't have errors like "invalid 3rd octet" for IP adresses either). > >> Also, it would be nice to be able to enter the value in more >> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize >> that to LDAP generalized time. > > When dealing with time there are so many ways to input and display the > same values this becomes difficult. > > I'd expect that the times for these two attributes will be relatively > simple and I somehow doubt users are going to want seconds, leap seconds > or fractions, but we'll need to consider how to do it for future > consistency (otherwise we could have a case where time is entered in one > format for some attributes and another for others). > > If we input in a nice way we need to output in the same way. We could make the preferred input/output time format user-configurable, defaulting to current locale time format. This format would be used for output. For input, we could go over a list of formats (first the user-configured format, then current locale format, then a handful of "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first format that can be successfully used to parse the time string. > > rob Honza -- Jan Cholasta From rcritten at redhat.com Wed Dec 14 15:21:19 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Dec 2011 10:21:19 -0500 Subject: [Freeipa-devel] [PATCH] 918, 919 update sudo schema In-Reply-To: <4EE8BC4B.3090209@redhat.com> References: <4EE823F6.4080401@redhat.com> <4EE89265.1000602@redhat.com> <4EE8B178.1030808@redhat.com> <4EE8BC4B.3090209@redhat.com> Message-ID: <4EE8BEEF.1080408@redhat.com> Jan Cholasta wrote: > Dne 14.12.2011 15:23, Rob Crittenden napsal(a): >> Jan Cholasta wrote: >>> Dne 14.12.2011 05:20, Rob Crittenden napsal(a): >>>> The sudo schema now defines sudoOrder, sudoNotBefore and sudoNotAfter >>>> but these weren't available in the sudorule plugin. >>>> >>>> I've added support for these. sudoOrder enforces uniqueness because >>>> duplicates are undefined. >>>> >>>> I also added support for a GeneralizedTime parameter type. This is >>>> similar to the existing AccessTime parameter but it only handles a >>>> single time value. >>> >>> You should parse the date/time part of the value with >>> time.strptime(timestr, '%Y%m%d%H%M%S') instead of doing it manually, >>> that way you'll get most of the validation for free. >> >> Yes but it gives a crappy error message, just saying that some data is >> left over not what is wrong. > > IMHO having a separate error message for every field in the time string > (like you do in the patch) is an overkill, simple "invalid time" and/or > "unknown time format" should suffice (we don't have errors like "invalid > 3rd octet" for IP adresses either). Well, the work is done, hard to go back on a better error message. >> >>> Also, it would be nice to be able to enter the value in more >>> user-friendly format (e.g. "2011-12-14 13:01:25 +0100") and normalize >>> that to LDAP generalized time. >> >> When dealing with time there are so many ways to input and display the >> same values this becomes difficult. >> >> I'd expect that the times for these two attributes will be relatively >> simple and I somehow doubt users are going to want seconds, leap seconds >> or fractions, but we'll need to consider how to do it for future >> consistency (otherwise we could have a case where time is entered in one >> format for some attributes and another for others). >> >> If we input in a nice way we need to output in the same way. > > We could make the preferred input/output time format user-configurable, > defaulting to current locale time format. This format would be used for > output. For input, we could go over a list of formats (first the > user-configured format, then current locale format, then a handful of > "standard" formats like YYYY-MM-DD HH:MM:SS) and use the first format > that can be successfully used to parse the time string. See how far you get into the rabbit hole with even this simple format? The LDAP GeneralizedTime needs to be either in GMT or include a differential. This gets us into the territory where the client could be in a different timezone than the server which leads us to why we dropped AccessTime in the first place. So I'd like the user to supply the timezone themselves so I don't have to guess (wrongly) and let them worry about differing timezones. rob From edewata at redhat.com Wed Dec 14 15:47:26 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Dec 2011 09:47:26 -0600 Subject: [Freeipa-devel] [PATCH] 056 Added facet tabs coloring In-Reply-To: <4EE71F93.6050502@redhat.com> References: <4EE64625.2020209@redhat.com> <4EE65FBE.9080206@redhat.com> <4EE71F93.6050502@redhat.com> Message-ID: <4EE8C50E.90103@redhat.com> On 12/13/2011 3:49 AM, Petr Vobornik wrote: >> 1. The original code uses different background images for >> active/inactive tabs. I think the mockup in the ticket is also showing >> different backgrounds. The new code uses the same background. >> > Fixed, using the background from mockup - but honestly I don't see much > difference. The inactive tabs are slightly lighter and have graduated color. The difference is very small, but the important thing is the ability to show different backgrounds for different tab states. ACK and pushed to master. -- Endi S. Dewata From ssorce at redhat.com Wed Dec 14 15:58:05 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Dec 2011 10:58:05 -0500 (EST) Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <20111214144508.GB17111@localhost.localdomain> Message-ID: <2bd062db-f7d5-407f-b4b2-040819c6c271@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > > > > We can also generate the SID algorithmically from the > > > > uidNumber/gidNumber > > > > > > Do you mean the SID of the trusted domain user? > > > > No I meant the SID of users and groups. > > ok, I would very much favor this approach it will make things much > easier. But iirc the idea was rejected some time ago, because we > couldn't agree on a good algorithm which can remove the conflicts > when > uid and gid are the same. What would you suggest? Adding the highest > bit > for groups? uid*2 for users, (gid*2)+1 for groups? ... ? Good question. So we need to decide whether we want algorithmic mapping or not (or a hybrid). Advantages of fixed NT SIDs: - Full control of users and group SIDs, you can simply remove a SID to make the user or the group unavailable wrt Windows compatibility (reduce PAC size and so on) - Do not change if the admin needs to change uidNumber or gidNumber for whatever reason. - Easy to search by SID, does not require guessing what the corresponding uid/gid are. - SIDs can be applied also to non-user/group objects w/o having to waste a uidNumber - No risk of conflicts if admins decide not to use UPGs and have unrelated groups and user that happen to algorithmically end up with the same SID (or force us to waste space to assure all groups have even RIDs and users odd RIDs) Disadvantages of fixed NT SIDs: - Requires DNA plugin to assign values since first install - Requires manual assignment, or fixup task if feature is activated after a consistent number of users/groups have been created. - third parties that have to do SID -> UID mapping on their own (think a samba server joined to the AD side and that has no knowledge these SIDs belong to an IPA domain) may get different SID -> UID mappings. I think the points above suggest we should indeed stick with the original decision of storing the SID and not go algorithmic (although the last point may be slightly annoying, it could be easily solved by forcing mappings on the other side or giving them read access to the IPA LDAP server for mapping purposes). The main issue is that we cannot assume DNA is configured from first install because an upgrade from v2 to v3 will simply go against it. But a fixup task to handle the situation shouldn't be too bad. The hardest problem will be to insure all servers that create users/groups have the DNA plugin properly configured. And a secondary, very minor, annoyance is that we will have to assign a range for SIDs as well. But this is not too hard we should probably just always assign a 200k IDs starting from 2000 or so. We do not need a random range because SIDs are unique across domains so we do not need to fear any collisions on trust relationships. So this part is easy. We limit initially to 1 Million only to keep RIDs in a very low range, so that mapping SIDs to UID/GID numbers for 3rd parties is not going to be problematic. If we assigne a larger range like 2Billion the as soon as you install a replica and create users there the range will be split in 2 and users create from that other replica will have their RID starting at 1Billion (as the range is split in 2 between the 2 replicas) which will make life difficult if someone want to limit SID ranges for posix mapping purposes. Simo. From edewata at redhat.com Wed Dec 14 18:43:46 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 14 Dec 2011 12:43:46 -0600 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <1323845588.2234.18.camel@priserak> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> <4EE275D3.3030508@redhat.com> <1323845588.2234.18.camel@priserak> Message-ID: <4EE8EE62.205@redhat.com> On 12/14/2011 12:53 AM, Martin Kosek wrote: >> I found this works ok and adding records is definitely clearer but it >> seems odd to add with one command and delete/find with another. I could >> get used to it I suppose. > > Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this > would increase the already high number of DNS commands. As suggested in the meeting, instead of having a separate command for each type: dnsrecordsrv-add ZONE NAME [srv-specific parameters...] dnsrecordmx-add ZONE NAME [mx-specific parameters...] we could use the same command but we specify the type as a parameter: dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...] dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...] This will keep the number of commands low regardless of the number of rrtypes we support now or in the future. Same thing for mod and del. All type-specific options can be made optional, or we can require some options depending on the type specified. The doc needs to specify which options are needed for each type. The interactive mode should still work too based on the type specified. If the user doesn't specify a type the command can even ask for it. > Endi and Petr had an idea to add a new --structured option for > dnsrecord-find/dnsrecord-show which would show structured DNS records > instead of raw DNS records. But I think our current framework is not > ready for this. While a raw DNS record is basically one entry item > (label : value), structured DNS record is an entry on its own > ({label1:value1, label2:value2, ...}): > - dnsrecord-find's output is ListOfEntries, but with use of > --structured option it would have to be changed to something like > ListOfListsOfEntries > - dnsrecord-show's output would have to be changed with a use of > --structured option from Entry to ListOfEntries I think we're mixing up several alternatives in the discussion. Never mind about dnsrecord-find/show returning record data in separate entries. I don't think right now it will be a good idea since they are actually attributes (no filter for certain param in the type, no primary key). What we're suggesting is the find command should always return a ListOfEntries and the show command should always return an Entry, which will be consistent with other commands. So when you call dnsrecord-show ZONE NAME without --structured, it will return a single Entry like before: { idnsname: 'foo', arecord: [ '10.10.10.10' ], cnamerecord: [ 'bar.example.com.', 'bar2.example.com.' ] } But when you specify --structured, it still returns a single Entry 'foo' but the structure of the attributes will change like this (or like the one suggested by Petr): { idnsname: 'foo', records: [ { type: 'a', data: '10.10.10.10', ip_address: '10.10.10.10' }, { type: 'cname', data: 'bar.example.com.', hostname: 'bar.example.com.' }, { type: 'cname', data: 'bar2.example.com.', hostname: 'bar2.example.com.' }, ] } If you call dnsrecord-find ZONE --structured the output will be a ListOfEntries like before, but each Entry will have a structure like above. > Another problem I see is that different RR types have parts with the > same name (e.g. "preference" is both in MX, KX and NAPTR records). If > any record could appear in an output entry, we would break current rule > that every output parameter in an entry is uniquely defined. Though this > issue could be solved with a prefix for every structured DNS record > part, i.e. KX record would have "kxpreference" and "kxechanger" parts. Since the 'records' attribute is an array in an Entry, there shouldn't be any issue about uniqueness. Also as suggested in my previous email, we can also add a --rec-types parameter to the find/show command to select which rrtypes we want to see in the result. If not specified it should return all types. -- Endi S. Dewata From dpal at redhat.com Wed Dec 14 18:59:09 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Dec 2011 13:59:09 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <4EE8EE62.205@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> <4EE275D3.3030508@redhat.com> <1323845588.2234.18.camel@priserak> <4EE8EE62.205@redhat.com> Message-ID: <4EE8F1FD.80800@redhat.com> On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote: > On 12/14/2011 12:53 AM, Martin Kosek wrote: >>> I found this works ok and adding records is definitely clearer but it >>> seems odd to add with one command and delete/find with another. I could >>> get used to it I suppose. >> >> Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this >> would increase the already high number of DNS commands. > > As suggested in the meeting, instead of having a separate command for > each type: > > dnsrecordsrv-add ZONE NAME [srv-specific parameters...] > dnsrecordmx-add ZONE NAME [mx-specific parameters...] > > we could use the same command but we specify the type as a parameter: > > dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...] > dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...] > > This will keep the number of commands low regardless of the number of > rrtypes we support now or in the future. Same thing for mod and del. > > All type-specific options can be made optional, or we can require some > options depending on the type specified. The doc needs to specify > which options are needed for each type. > > The interactive mode should still work too based on the type > specified. If the user doesn't specify a type the command can even ask > for it. > >> Endi and Petr had an idea to add a new --structured option for >> dnsrecord-find/dnsrecord-show which would show structured DNS records >> instead of raw DNS records. But I think our current framework is not >> ready for this. While a raw DNS record is basically one entry item >> (label : value), structured DNS record is an entry on its own >> ({label1:value1, label2:value2, ...}): >> - dnsrecord-find's output is ListOfEntries, but with use of >> --structured option it would have to be changed to something like >> ListOfListsOfEntries >> - dnsrecord-show's output would have to be changed with a use of >> --structured option from Entry to ListOfEntries > > I think we're mixing up several alternatives in the discussion. Never > mind about dnsrecord-find/show returning record data in > separate entries. I don't think right now it will be a good idea since > they are actually attributes (no filter for certain param in the type, > no primary key). > > What we're suggesting is the find command should always return a > ListOfEntries and the show command should always return an Entry, > which will be consistent with other commands. So when you call > dnsrecord-show ZONE NAME without --structured, it will return a single > Entry like before: > > { > idnsname: 'foo', > arecord: [ > '10.10.10.10' > ], > cnamerecord: [ > 'bar.example.com.', > 'bar2.example.com.' > ] > } > > But when you specify --structured, it still returns a single Entry > 'foo' but the structure of the attributes will change like this (or > like the one suggested by Petr): > > { > idnsname: 'foo', > records: [ > { > type: 'a', > data: '10.10.10.10', > ip_address: '10.10.10.10' > }, > { > type: 'cname', > data: 'bar.example.com.', > hostname: 'bar.example.com.' > }, > { > type: 'cname', > data: 'bar2.example.com.', > hostname: 'bar2.example.com.' > }, > ] > } > > If you call dnsrecord-find ZONE --structured the output will be a > ListOfEntries like before, but each Entry will have a structure like > above. > >> Another problem I see is that different RR types have parts with the >> same name (e.g. "preference" is both in MX, KX and NAPTR records). If >> any record could appear in an output entry, we would break current rule >> that every output parameter in an entry is uniquely defined. Though this >> issue could be solved with a prefix for every structured DNS record >> part, i.e. KX record would have "kxpreference" and "kxechanger" parts. > > Since the 'records' attribute is an array in an Entry, there shouldn't > be any issue about uniqueness. > > Also as suggested in my previous email, we can also add a --rec-types > parameter to the find/show command to select which rrtypes we want to > see in the result. If not specified it should return all types. > But as Martin mentioned on the call we loose help capabilities and make things really more complex. My vote would be to have separate commands. IMO it is better from usability point of view. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Wed Dec 14 19:14:02 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Dec 2011 14:14:02 -0500 Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <2bd062db-f7d5-407f-b4b2-040819c6c271@zmail11.collab.prod.int.phx2.redhat.com> References: <2bd062db-f7d5-407f-b4b2-040819c6c271@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4EE8F57A.8050603@redhat.com> On 12/14/2011 10:58 AM, Simo Sorce wrote: > ----- Original Message ----- >>>>> We can also generate the SID algorithmically from the >>>>> uidNumber/gidNumber >>>> Do you mean the SID of the trusted domain user? >>> No I meant the SID of users and groups. >> ok, I would very much favor this approach it will make things much >> easier. But iirc the idea was rejected some time ago, because we >> couldn't agree on a good algorithm which can remove the conflicts >> when >> uid and gid are the same. What would you suggest? Adding the highest >> bit >> for groups? uid*2 for users, (gid*2)+1 for groups? ... ? > Good question. > > So we need to decide whether we want algorithmic mapping or not (or a hybrid). > > Advantages of fixed NT SIDs: > - Full control of users and group SIDs, you can simply remove a SID to make the user or the group unavailable wrt Windows compatibility (reduce PAC size and so on) > - Do not change if the admin needs to change uidNumber or gidNumber for whatever reason. > - Easy to search by SID, does not require guessing what the corresponding uid/gid are. > - SIDs can be applied also to non-user/group objects w/o having to waste a uidNumber > - No risk of conflicts if admins decide not to use UPGs and have unrelated groups and user that happen to algorithmically end up with the same SID (or force us to waste space to assure all groups have even RIDs and users odd RIDs) > > Disadvantages of fixed NT SIDs: > - Requires DNA plugin to assign values since first install > - Requires manual assignment, or fixup task if feature is activated after a consistent number of users/groups have been created. > - third parties that have to do SID -> UID mapping on their own (think a samba server joined to the AD side and that has no knowledge these SIDs belong to an IPA domain) may get different SID -> UID mappings. > > > I think the points above suggest we should indeed stick with the original decision of storing the SID and not go algorithmic (although the last point may be slightly annoying, it could be easily solved by forcing mappings on the other side or giving them read access to the IPA LDAP server for mapping purposes). > > The main issue is that we cannot assume DNA is configured from first install because an upgrade from v2 to v3 will simply go against it. > But a fixup task to handle the situation shouldn't be too bad. > The hardest problem will be to insure all servers that create users/groups have the DNA plugin properly configured. And a secondary, very minor, annoyance is that we will have to assign a range for SIDs as well. > But this is not too hard we should probably just always assign a 200k IDs starting from 2000 or so. We do not need a random range because SIDs are unique across domains so we do not need to fear any collisions on trust relationships. So this part is easy. We limit initially to 1 Million only to keep RIDs in a very low range, so that mapping SIDs to UID/GID numbers for 3rd parties is not going to be problematic. > If we assigne a larger range like 2Billion the as soon as you install a replica and create users there the range will be split in 2 and users create from that other replica will have their RID starting at 1Billion (as the range is split in 2 between the 2 replicas) which will make life difficult if someone want to limit SID ranges for posix mapping purposes. > > Simo. > With the static IDs you will have an issue with DNA that you will have to implement 2 dimensional slicing if ranges. Right now the ranges are sliced per replica and traded accordingly. With your proposal the DNA would have to deal with a concept of group of ranges belonging to each domain and make sure that every replica has its slice for the group. I seems that it would require changes to the DNA plugin logic, not only configuration. Also the point about third parties IMO is just a showstopper. If we go with static IDs nobody would deploy us as we are nonexistent in real deployments while samba and other solutions are already deployed in multiple places. Poeple will be very frustrated to find out that our ids do not match. Man ye we should do our own samba id mapping back end that would work like idmap_rid but factor in configured range and contribute it to samba. But the problem of the collisions already exists with samba when multiple domains are in play so I really do not understand why we should try to solve the problem that is pretty much unsolvable. > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Dec 14 19:18:17 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 14 Dec 2011 14:18:17 -0500 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <4EE699B0.1030403@redhat.com> References: <4EE66277.5060409@redhat.com> <1323735307.4413.109.camel@willson.li.ssimo.org> <4EE699B0.1030403@redhat.com> Message-ID: <4EE8F679.1010509@redhat.com> Dmitri Pal wrote: > On 12/12/2011 07:15 PM, Simo Sorce wrote: >> On Mon, 2011-12-12 at 15:22 -0500, Rob Crittenden wrote: >>> This patch adds support for s4u2proxy. This means that the Apache >>> server >>> will obtain the ldap service ticket on behalf of the user rather than >>> the using having to send their TGT. The user's ticket still needs to >>> be >>> forwardable, we just don't require it to be forwarded any more. >> >> Should we make the patch allow the old behavior by using a switch that >> revert to forwarding the TGT ? >> >> It would be useful during upgrades if some of your servers still need >> forwarded TGTs, or if you want to use a newer client against an old >> server while you have the newer stuff under test. >> (And to test in general). >> >> Simo. > +1 > Updated patch attached. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-rcrit-914-1-nodelegation.patch Type: text/x-patch Size: 6035 bytes Desc: not available URL: From abokovoy at redhat.com Wed Dec 14 19:22:50 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 14 Dec 2011 21:22:50 +0200 Subject: [Freeipa-devel] [PATCH] s4u2proxy support In-Reply-To: <4EE8F679.1010509@redhat.com> References: <4EE66277.5060409@redhat.com> <1323735307.4413.109.camel@willson.li.ssimo.org> <4EE699B0.1030403@redhat.com> <4EE8F679.1010509@redhat.com> Message-ID: <20111214192250.GA11084@redhat.com> On Wed, 14 Dec 2011, Rob Crittenden wrote: > Dmitri Pal wrote: > >On 12/12/2011 07:15 PM, Simo Sorce wrote: > >>On Mon, 2011-12-12 at 15:22 -0500, Rob Crittenden wrote: > >>>This patch adds support for s4u2proxy. This means that the Apache > >>>server > >>>will obtain the ldap service ticket on behalf of the user rather than > >>>the using having to send their TGT. The user's ticket still needs to > >>>be > >>>forwardable, we just don't require it to be forwarded any more. > >> > >>Should we make the patch allow the old behavior by using a switch that > >>revert to forwarding the TGT ? > >> > >>It would be useful during upgrades if some of your servers still need > >>forwarded TGTs, or if you want to use a newer client against an old > >>server while you have the newer stuff under test. > >>(And to test in general). > >> > >>Simo. > >+1 > > > > Updated patch attached. > > rob > >From 03a2c9a536811437e4847e1c6b11d2ac0eff98f2 Mon Sep 17 00:00:00 2001 > From: Rob Crittenden > Date: Thu, 8 Dec 2011 14:23:18 -0500 > Subject: [PATCH] Don't set delegation flag in client, we're using S4U2Proxy > now > > A forwardable ticket is still required but we no longer need to send > the TGT to the IPA server. A new flag, --delegation, is available if > the old behavior is required. A minor point: please fix commit message to use proper option name: --delegate > + parser.add_option('--delegate', action='store_true', > + help='Delegate the TGT to the IPA server', > + ) Otherwise ACK. -- / Alexander Bokovoy From ssorce at redhat.com Wed Dec 14 19:57:46 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Dec 2011 14:57:46 -0500 (EST) Subject: [Freeipa-devel] WIP: ipa trust command In-Reply-To: <4EE8F57A.8050603@redhat.com> Message-ID: <980afd3d-b0f8-4727-b8c5-97a455d08957@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 12/14/2011 10:58 AM, Simo Sorce wrote: > > ----- Original Message ----- > >>>>> We can also generate the SID algorithmically from the > >>>>> uidNumber/gidNumber > >>>> Do you mean the SID of the trusted domain user? > >>> No I meant the SID of users and groups. > >> ok, I would very much favor this approach it will make things much > >> easier. But iirc the idea was rejected some time ago, because we > >> couldn't agree on a good algorithm which can remove the conflicts > >> when > >> uid and gid are the same. What would you suggest? Adding the > >> highest > >> bit > >> for groups? uid*2 for users, (gid*2)+1 for groups? ... ? > > Good question. > > > > So we need to decide whether we want algorithmic mapping or not (or > > a hybrid). > > > > Advantages of fixed NT SIDs: > > - Full control of users and group SIDs, you can simply remove a SID > > to make the user or the group unavailable wrt Windows > > compatibility (reduce PAC size and so on) > > - Do not change if the admin needs to change uidNumber or gidNumber > > for whatever reason. > > - Easy to search by SID, does not require guessing what the > > corresponding uid/gid are. > > - SIDs can be applied also to non-user/group objects w/o having to > > waste a uidNumber > > - No risk of conflicts if admins decide not to use UPGs and have > > unrelated groups and user that happen to algorithmically end up > > with the same SID (or force us to waste space to assure all groups > > have even RIDs and users odd RIDs) > > > > Disadvantages of fixed NT SIDs: > > - Requires DNA plugin to assign values since first install > > - Requires manual assignment, or fixup task if feature is activated > > after a consistent number of users/groups have been created. > > - third parties that have to do SID -> UID mapping on their own > > (think a samba server joined to the AD side and that has no > > knowledge these SIDs belong to an IPA domain) may get different > > SID -> UID mappings. > > > > > > I think the points above suggest we should indeed stick with the > > original decision of storing the SID and not go algorithmic > > (although the last point may be slightly annoying, it could be > > easily solved by forcing mappings on the other side or giving them > > read access to the IPA LDAP server for mapping purposes). > > > > The main issue is that we cannot assume DNA is configured from > > first install because an upgrade from v2 to v3 will simply go > > against it. > > But a fixup task to handle the situation shouldn't be too bad. > > The hardest problem will be to insure all servers that create > > users/groups have the DNA plugin properly configured. And a > > secondary, very minor, annoyance is that we will have to assign a > > range for SIDs as well. > > But this is not too hard we should probably just always assign a > > 200k IDs starting from 2000 or so. We do not need a random range > > because SIDs are unique across domains so we do not need to fear > > any collisions on trust relationships. So this part is easy. We > > limit initially to 1 Million only to keep RIDs in a very low > > range, so that mapping SIDs to UID/GID numbers for 3rd parties is > > not going to be problematic. > > If we assigne a larger range like 2Billion the as soon as you > > install a replica and create users there the range will be split > > in 2 and users create from that other replica will have their RID > > starting at 1Billion (as the range is split in 2 between the 2 > > replicas) which will make life difficult if someone want to limit > > SID ranges for posix mapping purposes. > > > > Simo. > > > With the static IDs you will have an issue with DNA that you will > have > to implement 2 dimensional slicing if ranges. Right now the ranges > are > sliced per replica and traded accordingly. With your proposal the DNA > would have to deal with a concept of group of ranges belonging to > each > domain and make sure that every replica has its slice for the group. > I > seems that it would require changes to the DNA plugin logic, not only > configuration. > Also the point about third parties IMO is just a showstopper. If we > go > with static IDs nobody would deploy us as we are nonexistent in real > deployments while samba and other solutions are already deployed in > multiple places. Poeple will be very frustrated to find out that our > ids > do not match. > > Man ye we should do our own samba id mapping back end that would work > like idmap_rid but factor in configured range and contribute it to > samba. > > But the problem of the collisions already exists with samba when > multiple domains are in play so I really do not understand why we > should > try to solve the problem that is pretty much unsolvable. I think you are confusing 2 problems here. 1 problem (the one you have in mind) is mapping foreign SIDs from AD domains to uid/gids, this is NOT the problem we are discussing here. What we are discussing here is how to generate the SIDs for our own domain, for consumption by AD clients. Simo. From ssorce at redhat.com Wed Dec 14 20:02:03 2011 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 14 Dec 2011 15:02:03 -0500 (EST) Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <4EE8F1FD.80800@redhat.com> Message-ID: <753a2eff-8619-474f-9e21-83a1c3384433@zmail11.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote: > > On 12/14/2011 12:53 AM, Martin Kosek wrote: > >>> I found this works ok and adding records is definitely clearer > >>> but it > >>> seems odd to add with one command and delete/find with another. I > >>> could > >>> get used to it I suppose. > >> > >> Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but > >> this > >> would increase the already high number of DNS commands. > > > > As suggested in the meeting, instead of having a separate command > > for > > each type: > > > > dnsrecordsrv-add ZONE NAME [srv-specific parameters...] > > dnsrecordmx-add ZONE NAME [mx-specific parameters...] > > > > we could use the same command but we specify the type as a > > parameter: > > > > dnsrecord-add ZONE NAME --rec-type=srv [srv-specific > > parameters...] > > dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...] > > > > This will keep the number of commands low regardless of the number > > of > > rrtypes we support now or in the future. Same thing for mod and > > del. > > > > All type-specific options can be made optional, or we can require > > some > > options depending on the type specified. The doc needs to specify > > which options are needed for each type. > > > > The interactive mode should still work too based on the type > > specified. If the user doesn't specify a type the command can even > > ask > > for it. > > > >> Endi and Petr had an idea to add a new --structured option for > >> dnsrecord-find/dnsrecord-show which would show structured DNS > >> records > >> instead of raw DNS records. But I think our current framework is > >> not > >> ready for this. While a raw DNS record is basically one entry item > >> (label : value), structured DNS record is an entry on its own > >> ({label1:value1, label2:value2, ...}): > >> - dnsrecord-find's output is ListOfEntries, but with use of > >> --structured option it would have to be changed to something like > >> ListOfListsOfEntries > >> - dnsrecord-show's output would have to be changed with a use of > >> --structured option from Entry to ListOfEntries > > > > I think we're mixing up several alternatives in the discussion. > > Never > > mind about dnsrecord-find/show returning record data in > > separate entries. I don't think right now it will be a good idea > > since > > they are actually attributes (no filter for certain param in the > > type, > > no primary key). > > > > What we're suggesting is the find command should always return a > > ListOfEntries and the show command should always return an Entry, > > which will be consistent with other commands. So when you call > > dnsrecord-show ZONE NAME without --structured, it will return a > > single > > Entry like before: > > > > { > > idnsname: 'foo', > > arecord: [ > > '10.10.10.10' > > ], > > cnamerecord: [ > > 'bar.example.com.', > > 'bar2.example.com.' > > ] > > } > > > > But when you specify --structured, it still returns a single Entry > > 'foo' but the structure of the attributes will change like this (or > > like the one suggested by Petr): > > > > { > > idnsname: 'foo', > > records: [ > > { > > type: 'a', > > data: '10.10.10.10', > > ip_address: '10.10.10.10' > > }, > > { > > type: 'cname', > > data: 'bar.example.com.', > > hostname: 'bar.example.com.' > > }, > > { > > type: 'cname', > > data: 'bar2.example.com.', > > hostname: 'bar2.example.com.' > > }, > > ] > > } > > > > If you call dnsrecord-find ZONE --structured the output will be a > > ListOfEntries like before, but each Entry will have a structure > > like > > above. > > > >> Another problem I see is that different RR types have parts with > >> the > >> same name (e.g. "preference" is both in MX, KX and NAPTR records). > >> If > >> any record could appear in an output entry, we would break current > >> rule > >> that every output parameter in an entry is uniquely defined. > >> Though this > >> issue could be solved with a prefix for every structured DNS > >> record > >> part, i.e. KX record would have "kxpreference" and "kxechanger" > >> parts. > > > > Since the 'records' attribute is an array in an Entry, there > > shouldn't > > be any issue about uniqueness. > > > > Also as suggested in my previous email, we can also add a > > --rec-types > > parameter to the find/show command to select which rrtypes we want > > to > > see in the result. If not specified it should return all types. > > > But as Martin mentioned on the call we loose help capabilities and > make > things really more complex. > My vote would be to have separate commands. IMO it is better from > usability point of view. I disagree, it will make things a lot more cumbersome and will require entire new commands if we want to add new types in future. It does not scale well and it is potentially open bounded. For the help issue I am sure we can figure out a way to pass --rec-type to help if really needed, otherwise help can simply list all know syntaxes. Simo. From dpal at redhat.com Wed Dec 14 20:31:01 2011 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 14 Dec 2011 15:31:01 -0500 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <753a2eff-8619-474f-9e21-83a1c3384433@zmail11.collab.prod.int.phx2.redhat.com> References: <753a2eff-8619-474f-9e21-83a1c3384433@zmail11.collab.prod.int.phx2.redhat.com> Message-ID: <4EE90785.7080906@redhat.com> On 12/14/2011 03:02 PM, Simo Sorce wrote: > > ----- Original Message ----- >> On 12/14/2011 01:43 PM, Endi Sukma Dewata wrote: >>> On 12/14/2011 12:53 AM, Martin Kosek wrote: >>>>> I found this works ok and adding records is definitely clearer >>>>> but it >>>>> seems odd to add with one command and delete/find with another. I >>>>> could >>>>> get used to it I suppose. >>>> Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but >>>> this >>>> would increase the already high number of DNS commands. >>> As suggested in the meeting, instead of having a separate command >>> for >>> each type: >>> >>> dnsrecordsrv-add ZONE NAME [srv-specific parameters...] >>> dnsrecordmx-add ZONE NAME [mx-specific parameters...] >>> >>> we could use the same command but we specify the type as a >>> parameter: >>> >>> dnsrecord-add ZONE NAME --rec-type=srv [srv-specific >>> parameters...] >>> dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...] >>> >>> This will keep the number of commands low regardless of the number >>> of >>> rrtypes we support now or in the future. Same thing for mod and >>> del. >>> >>> All type-specific options can be made optional, or we can require >>> some >>> options depending on the type specified. The doc needs to specify >>> which options are needed for each type. >>> >>> The interactive mode should still work too based on the type >>> specified. If the user doesn't specify a type the command can even >>> ask >>> for it. >>> >>>> Endi and Petr had an idea to add a new --structured option for >>>> dnsrecord-find/dnsrecord-show which would show structured DNS >>>> records >>>> instead of raw DNS records. But I think our current framework is >>>> not >>>> ready for this. While a raw DNS record is basically one entry item >>>> (label : value), structured DNS record is an entry on its own >>>> ({label1:value1, label2:value2, ...}): >>>> - dnsrecord-find's output is ListOfEntries, but with use of >>>> --structured option it would have to be changed to something like >>>> ListOfListsOfEntries >>>> - dnsrecord-show's output would have to be changed with a use of >>>> --structured option from Entry to ListOfEntries >>> I think we're mixing up several alternatives in the discussion. >>> Never >>> mind about dnsrecord-find/show returning record data in >>> separate entries. I don't think right now it will be a good idea >>> since >>> they are actually attributes (no filter for certain param in the >>> type, >>> no primary key). >>> >>> What we're suggesting is the find command should always return a >>> ListOfEntries and the show command should always return an Entry, >>> which will be consistent with other commands. So when you call >>> dnsrecord-show ZONE NAME without --structured, it will return a >>> single >>> Entry like before: >>> >>> { >>> idnsname: 'foo', >>> arecord: [ >>> '10.10.10.10' >>> ], >>> cnamerecord: [ >>> 'bar.example.com.', >>> 'bar2.example.com.' >>> ] >>> } >>> >>> But when you specify --structured, it still returns a single Entry >>> 'foo' but the structure of the attributes will change like this (or >>> like the one suggested by Petr): >>> >>> { >>> idnsname: 'foo', >>> records: [ >>> { >>> type: 'a', >>> data: '10.10.10.10', >>> ip_address: '10.10.10.10' >>> }, >>> { >>> type: 'cname', >>> data: 'bar.example.com.', >>> hostname: 'bar.example.com.' >>> }, >>> { >>> type: 'cname', >>> data: 'bar2.example.com.', >>> hostname: 'bar2.example.com.' >>> }, >>> ] >>> } >>> >>> If you call dnsrecord-find ZONE --structured the output will be a >>> ListOfEntries like before, but each Entry will have a structure >>> like >>> above. >>> >>>> Another problem I see is that different RR types have parts with >>>> the >>>> same name (e.g. "preference" is both in MX, KX and NAPTR records). >>>> If >>>> any record could appear in an output entry, we would break current >>>> rule >>>> that every output parameter in an entry is uniquely defined. >>>> Though this >>>> issue could be solved with a prefix for every structured DNS >>>> record >>>> part, i.e. KX record would have "kxpreference" and "kxechanger" >>>> parts. >>> Since the 'records' attribute is an array in an Entry, there >>> shouldn't >>> be any issue about uniqueness. >>> >>> Also as suggested in my previous email, we can also add a >>> --rec-types >>> parameter to the find/show command to select which rrtypes we want >>> to >>> see in the result. If not specified it should return all types. >>> >> But as Martin mentioned on the call we loose help capabilities and >> make >> things really more complex. >> My vote would be to have separate commands. IMO it is better from >> usability point of view. > I disagree, it will make things a lot more cumbersome and will require > entire new commands if we want to add new types in future. It does not > scale well and it is potentially open bounded. > For the help issue I am sure we can figure out a way to pass --rec-type > to help if really needed, otherwise help can simply list all know syntaxes. > The whole point of this work to decompose things and make them simpler. One command with dozens of options is much harder to use. I stand on my own point but we should ask community. > Simo. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From mkosek at redhat.com Wed Dec 14 20:47:59 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Dec 2011 21:47:59 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <4EE8EE62.205@redhat.com> References: <1322498136.12794.22.camel@balmora.brq.redhat.com> <1322733935.20143.5.camel@balmora.brq.redhat.com> <4ED7FD3B.3030006@redhat.com> <1322813820.9851.10.camel@balmora.brq.redhat.com> <4EE275D3.3030508@redhat.com> <1323845588.2234.18.camel@priserak> <4EE8EE62.205@redhat.com> Message-ID: <1323895679.17355.3.camel@priserak> On Wed, 2011-12-14 at 12:43 -0600, Endi Sukma Dewata wrote: > On 12/14/2011 12:53 AM, Martin Kosek wrote: > >> I found this works ok and adding records is definitely clearer but it > >> seems odd to add with one command and delete/find with another. I could > >> get used to it I suppose. > > > > Hm, we could add dnsrecord--del ZONE RECORD VALUE command, but this > > would increase the already high number of DNS commands. > > As suggested in the meeting, instead of having a separate command for > each type: > > dnsrecordsrv-add ZONE NAME [srv-specific parameters...] > dnsrecordmx-add ZONE NAME [mx-specific parameters...] > > we could use the same command but we specify the type as a parameter: > > dnsrecord-add ZONE NAME --rec-type=srv [srv-specific parameters...] > dnsrecord-add ZONE NAME --rec-type=mx [mx-specific parameters...] > > This will keep the number of commands low regardless of the number of > rrtypes we support now or in the future. Same thing for mod and del. > > All type-specific options can be made optional, or we can require some > options depending on the type specified. The doc needs to specify which > options are needed for each type. > > The interactive mode should still work too based on the type specified. > If the user doesn't specify a type the command can even ask for it. > > > Endi and Petr had an idea to add a new --structured option for > > dnsrecord-find/dnsrecord-show which would show structured DNS records > > instead of raw DNS records. But I think our current framework is not > > ready for this. While a raw DNS record is basically one entry item > > (label : value), structured DNS record is an entry on its own > > ({label1:value1, label2:value2, ...}): > > - dnsrecord-find's output is ListOfEntries, but with use of > > --structured option it would have to be changed to something like > > ListOfListsOfEntries > > - dnsrecord-show's output would have to be changed with a use of > > --structured option from Entry to ListOfEntries > > I think we're mixing up several alternatives in the discussion. Never > mind about dnsrecord-find/show returning record data in separate > entries. I don't think right now it will be a good idea since they are > actually attributes (no filter for certain param in the type, no primary > key). > > What we're suggesting is the find command should always return a > ListOfEntries and the show command should always return an Entry, which > will be consistent with other commands. So when you call dnsrecord-show > ZONE NAME without --structured, it will return a single Entry like before: > > { > idnsname: 'foo', > arecord: [ > '10.10.10.10' > ], > cnamerecord: [ > 'bar.example.com.', > 'bar2.example.com.' > ] > } > > But when you specify --structured, it still returns a single Entry 'foo' > but the structure of the attributes will change like this (or like the > one suggested by Petr): > > { > idnsname: 'foo', > records: [ > { > type: 'a', > data: '10.10.10.10', > ip_address: '10.10.10.10' > }, > { > type: 'cname', > data: 'bar.example.com.', > hostname: 'bar.example.com.' > }, > { > type: 'cname', > data: 'bar2.example.com.', > hostname: 'bar2.example.com.' > }, > ] > } > > If you call dnsrecord-find ZONE --structured the output will be a > ListOfEntries like before, but each Entry will have a structure like above. > > > Another problem I see is that different RR types have parts with the > > same name (e.g. "preference" is both in MX, KX and NAPTR records). If > > any record could appear in an output entry, we would break current rule > > that every output parameter in an entry is uniquely defined. Though this > > issue could be solved with a prefix for every structured DNS record > > part, i.e. KX record would have "kxpreference" and "kxechanger" parts. > > Since the 'records' attribute is an array in an Entry, there shouldn't > be any issue about uniqueness. > > Also as suggested in my previous email, we can also add a --rec-types > parameter to the find/show command to select which rrtypes we want to > see in the result. If not specified it should return all types. > I think this all are valid points, I will summarize the proposad approach to DNS API based on options instead of commands to separate mail. It is too important to get lost in this long thread :-) Martin From jdennis at redhat.com Wed Dec 14 20:56:56 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 14 Dec 2011 15:56:56 -0500 Subject: [Freeipa-devel] [PATCH 59] Modify spec file to add ipa_memcached service Install &, control ipa_memcached instance Message-ID: <4EE90D98.6030900@redhat.com> This patch adds an ipa memcached service, it does the following: * adds SysV initscript for ipa_memcached * adds systemd service file for ipa_memcached * adds tmpfiles.d configuration file for /var/run/ipa_memcached * adds configuration file for ipa_memcached * adds memcacheinstance.py file to create service instance during server install * invokes installation of ipa_memcached during ipa-server-install * adds dependencies to spec file * adds ipa_memcached to ipactl service control -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0059-Modify-spec-file-to-add-ipa_memcached-service.patch Type: text/x-patch Size: 9993 bytes Desc: not available URL: From jdennis at redhat.com Wed Dec 14 21:01:28 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 14 Dec 2011 16:01:28 -0500 Subject: [Freeipa-devel] [PATCH 60] Implement session support in server, Manage sessions in WSGI Message-ID: <4EE90EA8.5020803@redhat.com> This patch adds the ipalib/session.py file which implements a cookie based session cache using memcached. It also invokes the session cookie support when a HTTP request is received and stores the session data in the per-thread context object. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jdennis-0060-Implement-session-support-in-server.patch Type: text/x-patch Size: 14583 bytes Desc: not available URL: From mkosek at redhat.com Wed Dec 14 21:41:57 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Dec 2011 22:41:57 +0100 Subject: [Freeipa-devel] Optionistic approach for new DNS API Message-ID: <1323898917.17355.47.camel@priserak> Hello all, we just had a good discussion with Rob and Endi about different approach to the new DNS API. Current DNS API proposal (patches 174-176) introduced new API based on different commands, e.g. for MX RR type: ipa dnsrecord-mx-add ZONE NAME --preference=0 --exchanger=server1.example.com. ipa dnsrecord-mx-mod ZONE NAME "0 server1.example.com." --preference=1 ipa dnsrecord-mx-show ZONE NAME As a side effect, this would introduce many new commands (dnsrecord-mx-add/mod/show, dnsrecord-loc-add/mod/show, ...) which may of course be confusing. Endi proposed an different approach to use rather per-type options instead of commands, which I think is really interesting to think about. I will summarize how the API may look like. Changes to DNS module commands: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - no new DNS command would be implemented, we would just enhance current dns record commands: * dnsrecord-add, dnsrecord-mod, dnsrecord-del and dnsrecord-find - all changes must be compatible with 2.x clients, changes to output shall be triggered by 3.x option Command Structure: ~~~~~~~~~~~~~~~~~~ - we would introduce --type option which would trigger the command to use the new structured DNS options, i.e.: ipa dnsrecord-add ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. or ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 or ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. - SHOW and FIND commands do not need this new --type parameter Command Output: ~~~~~~~~~~~~~~~ - we would introduce a new --structured option which would switch command output to "structured way" and present rather parsed DNS records instead of raw DNS values (this is also needed for 2.x compatibility). For JSON output we may get: { idnsname: 'foo', records: [ { type: 'a', data: '10.10.10.10', ip_address: '10.10.10.10' }, { type: 'cname', data: 'bar.example.com.', hostname: 'bar.example.com.' }, { type: 'cname', data: 'bar2.example.com.', hostname: 'bar2.example.com.' }, ] } instead of { idnsname: 'foo', arecord: [ '10.10.10.10' ], cnamerecord: [ 'bar.example.com.', 'bar2.example.com.' ] } In CLI it may look like this: # ipa dnsrecordmx-show example.com @ --structured Record name: @ Record type: MX Data: 0 server1.example.com Preference: 0 Exchanger: server1.example.com Record type: NS Data: vm-068.idm.lab.bos.redhat.com. Hostname: vm-068.idm.lab.bos.redhat.com. instead of: # ipa dnsrecord-show example.com @ Record name: @ MX record: 0 server1.example.com NS record: vm-068.idm.lab.bos.redhat.com. Command help: ~~~~~~~~~~~~~ - since dnsrecord-add would accept all options from all DNS RR types, its list would be overwhelming and not very helpful - we can take advantage of OptionParser option groups. The help may look like this: $ ipa dnsrecord-add --help Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] Options: -h, --help show this help message and exit SRV Options: --priority Priority --weight Weight --port Port --target Target MX Options: --priority Priority --exchanger A host willing to act as a mail exchanger ... Interactive mode in CLI: ~~~~~~~~~~~~~~~~~~~~~~~~ - ADD command: - when no option is passed to dnsrecord-add command, it may ask for --type and then for the options specific for the particular type - MOD command: - when no option is passed to dnsrecord-mod command, it may provide a list of current DNS record values and ask for specific DNS record parts to be changed for chosen value - DEL command: - when no option is passed to dnsrecord-del command, it may provide a list of current DNS record values remove the chosen value Any comments, suggestions? Do you think that introducing these new options in current dnsrecord-add/mod/show/del commands would be better and more usable that introducing these capabilities in separate commands? Thanks, Martin From mkosek at redhat.com Wed Dec 14 22:00:43 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 14 Dec 2011 23:00:43 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 172+173+175 Create per-type DNS API In-Reply-To: <4EE90785.7080906@redhat.com> References: <753a2eff-8619-474f-9e21-83a1c3384433@zmail11.collab.prod.int.phx2.redhat.com> <4EE90785.7080906@redhat.com> Message-ID: <1323900043.17355.57.camel@priserak> On Wed, 2011-12-14 at 15:31 -0500, Dmitri Pal wrote: > > The whole point of this work to decompose things and make them simpler. > One command with dozens of options is much harder to use. > I stand on my own point but we should ask community. Lets see what the community would say about the API based on new options instead of new commands. I proposed an API based on the discussion with Rob and Endi in a new thread sent both to freeipa-devel and freeipa-users. This new way would require more changes to our framework which is not ready for such interface yet but if the interface is accepted it should be doable. Martin From pvoborni at redhat.com Thu Dec 15 12:52:22 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Dec 2011 13:52:22 +0100 Subject: [Freeipa-devel] [PATCH] 057 Fixed displaying of external records in rule association, widgets Message-ID: <4EE9ED86.8000506@redhat.com> It's a fix for regression introduced by widget refactoring #2040. https://fedorahosted.org/freeipa/ticket/2040 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0057-Fixed-displaying-of-external-records-in-rule-associa.patch Type: text/x-patch Size: 5297 bytes Desc: not available URL: From pvoborni at redhat.com Thu Dec 15 12:54:13 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 15 Dec 2011 13:54:13 +0100 Subject: [Freeipa-devel] [PATCH] 058 Distinguishing of external values in association tables Message-ID: <4EE9EDF5.6080808@redhat.com> Problem: Rule association widget was displaying standard records with external records in one table. User couldn't distinguish the values. When clicking on the external record link it navigated to appropriate page for that entity. But for external value there is no record to show so it displayed error. Solution: * For tables with possible external values a 'external' column was added. It displays "True" if the value is external and nothing if not. Displaying nothing is intentional. If user sees some text in external column he immediately knows that the record is external without even reading the "True" text. * Rows with external values don't have a link for navigating to record page. This prevents showing the error as no record exists. Additional changes: * Association table widget was stripped of get_records method. Loading records isn't its responsibility it's a responsibility of field. * Column was extended by possible suppressing of link creation. It's done by optional suppress_link argument in setup method. * To allow setting suppress_link attribute in inherited tables a new overridable method was created - setup_column. Possible future improvements: * Table is using dynamic setting of width for columns. Each column has the same width. For flag columns such as 'external' the width of the column is too big. It would be better to be able to set smaller fixed width and the rest of the columns width (without the width set) would be computed (to fit the table). * When a table has displayed buttons in its last column header the cells in column header have different vertical alignment. It should be united. https://fedorahosted.org/freeipa/ticket/1993 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0058-Distinguishing-of-external-values-in-association-tab.patch Type: text/x-patch Size: 9514 bytes Desc: not available URL: From ayoung at redhat.com Thu Dec 15 17:24:36 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 15 Dec 2011 12:24:36 -0500 Subject: [Freeipa-devel] Multitenancy in FreeIPA Message-ID: <4EEA2D54.5000306@redhat.com> This is a first attempt to write up an approach for multitenancy in IPA. Please provide feedback. I've attached the document as well, as that should be easier to read. Description Multi-tenancy is an aspect of Identity Management (IdM) where multiple parties use the same resource without learn any information about each other. The example is two rival companies who both operate servers hosted in a public cloud. Neither company should be aware of the existance of the other users presence in the web using, and they definitely should not be able to enumerate either the users or the hosts of the other company due to information leaks inside the cloud services. The entities stored under each tenant have a relatively high likelihood of reusing the same names. User names and group names are often have a high number of names that are commonly used. For example, both companies might have someone with the user name of asmith and a group named developers. However, in the first company, asmith has a UID of 512 and developers has a GID of 2100, but in the other company asmith has a UID of 87687 and developers has a GID of 6332. Both need to exist in the IdM server and be distinguishable from the other. IPA Status IPA currently has a completely flat data model. All data is store in two subtrees: one for the IPA user and host database, and one for the PKI CA. The kerberos server would only server out tickets for a single domain. The Directory server has the vast majority of its data open read only available to anonymous binds. The user Admin has full control over the entire set of entites in the system. IPA stores the data it manages inside a Directory Server (389) instance in a subtree that, by default, mirrors the hostname of the server. Thus the server ipa.example.com would store in the subtree cn=ipa,cn=example,cn=com. The layout of this subtree will be referred to as the current schema. The instance of the subtree itself will be referred to as the current baseDN. In addition, each IPA server manages a Kerberos Realm. By default the name of the realm matches the domain name, but in all capitals. The zone example.com would have a corresponding realm EXAMPLE.COM. Required Changes These are the changes necessary to the FreeIPA server to support a cloud deployment and multi-tenancy. Directory Server Each tenant in the cloud would get their own subtree. It would get a BaseDN of the form:cn={TENANT},cn=tenants,$suffix. This subtree would have a copy of the current schema. The initial (undeletable) suffix is used for the cloud provider. These subtrees will be referred to as tenant trees. When performing an action in the IPA server, the user is identified by their principal, which contains the Kerberos Realm name. This can be used to distinguish which domain, and by extension, which subtree, the action should use for data. Operations are limited to the current zone. Cloud administrators will need the ability to override this in order to perform maintenance operations on the tenants. The directory will no longer be world readable. Instead, ACIs will limit the users ability to read only the subtree in which they are enrolled. LDAP operations will require an authenticated bind. When updating IPA, schema changes need to be applied to each of the the tenant trees. API Each of the RPCs need to allow an optional parameter tenant. Members of the original domain with an approapriate Permission will be able to perform operations inside the tenant specified. BaseLDAP plugin Instead of just reading the BaseDN out of the configuration file, the base DN needs to be calculated based on the Kerberos principal of the calling user. This value should be cached in the WSGI application so that it does not always require multiple round trips to the LDAP server. Kerberos Each tenant would get its own Kerberos Realm, but each would trust the Cloud Provider's realm. The httpd/mod_auth_kerberos needs to be capable of accepting new realms. When adding a new tenant, we might need to update krb5.conf on the IPA server to know about the new realm. DNS The BIND DynDB back end code would need to be extended to read zone information from multiple subtrees in order to read the DNS entires in the tenant trees. It is also possible to keep the current approach, and then add the ability to identify which users and tenants can manage and control DNS entries. The simpler solution is to modify BIND Dyn DB. CA We would continue to have only one CA, and have IPA submit all Certificate requests as a single Agent. The IPA server will ensure that a user can only request certificates for entities within their own subtree. IPA-CLIENT When enrolling a host, the principal used to authenticate with the IPA server will determine which subtree will hold host. This involves changing the LDAP configuration information in the following client components: SSSD, nss_ldap, and Kerberos. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: multitenancy-0.0.0.odt Type: application/vnd.oasis.opendocument.text Size: 16213 bytes Desc: not available URL: From nkinder at redhat.com Thu Dec 15 18:42:44 2011 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 15 Dec 2011 10:42:44 -0800 Subject: [Freeipa-devel] Multitenancy in FreeIPA In-Reply-To: <4EEA2D54.5000306@redhat.com> References: <4EEA2D54.5000306@redhat.com> Message-ID: <4EEA3FA4.7000100@redhat.com> On 12/15/2011 09:24 AM, Adam Young wrote: > This is a first attempt to write up an approach for multitenancy in > IPA. Please provide feedback. I've attached the document as well, > as that should be easier to read. > > Description > Multi-tenancy is an aspect of Identity Management (IdM) where > multiple parties use the same resource without learn any information > about each other. The example is two rival companies who both > operate servers hosted in a public cloud. Neither company should be > aware of the existance of the other users presence in the web using, > and they definitely should not be able to enumerate either the users > or the hosts of the other company due to information leaks inside the > cloud services. > > The entities stored under each tenant have a relatively high > likelihood of reusing the same names. User names and group names are > often have a high number of names that are commonly used. For > example, both companies might have someone with the user name of > asmith and a group named developers. However, in the first > company, asmith has a UID of 512 and developers has a GID of 2100, > but in the other company asmith has a UID of 87687 and developers has > a GID of 6332. Both need to exist in the IdM server and be > distinguishable from the other. > IPA Status > IPA currently has a completely flat data model. All data is store in > two subtrees: one for the IPA user and host database, and one for > the PKI CA. The kerberos server would only server out tickets for a > single domain. The Directory server has the vast majority of its data > open read only available to anonymous binds. The user Admin has full > control over the entire set of entites in the system. > > > IPA stores the data it manages inside a Directory Server (389) > instance in a subtree that, by default, mirrors the hostname of the > server. Thus the server ipa.example.com would store in the subtree > cn=ipa,cn=example,cn=com. The layout of this subtree will be referred > to as the current schema. The instance of the subtree itself will be > referred to as the current baseDN. > > In addition, each IPA server manages a Kerberos Realm. By default > the name of the realm matches the domain name, but in all capitals. > The zone example.com would have a corresponding realm EXAMPLE.COM. > Required Changes > These are the changes necessary to the FreeIPA server to support a > cloud deployment and multi-tenancy. > Directory Server > Each tenant in the cloud would get their own subtree. It would get a > BaseDN of the form:cn={TENANT},cn=tenants,$suffix. This subtree > would have a copy of the current schema. The initial (undeletable) > suffix is used for the cloud provider. These subtrees will be > referred to as tenant trees. > > When performing an action in the IPA server, the user is identified > by their principal, which contains the Kerberos Realm name. This > can be used to distinguish which domain, and by extension, which > subtree, the action should use for data. Operations are limited to > the current zone. Cloud administrators will need the ability to > override this in order to perform maintenance operations on the tenants. > > The directory will no longer be world readable. Instead, ACIs will > limit the users ability to read only the subtree in which they are > enrolled. LDAP operations will require an authenticated bind. > > When updating IPA, schema changes need to be applied to each of the > the tenant trees. > API > Each of the RPCs need to allow an optional parameter tenant. Members > of the original domain with an approapriate Permission will be able to > perform operations inside the tenant specified. Some configuration changes will need to be made around a number of the Directory Server plug-ins with regards to scope. We will likely need separate configuration entries to restrict the plug-ins to each tenant subtree. This includes the following plug-ins (and maybe others as well): - memberOf - DNA - Managed Entries - Auto-Membership - Attribute Uniqueness > > BaseLDAP plugin > Instead of just reading the BaseDN out of the configuration file, the > base DN needs to be calculated based on the Kerberos principal of the > calling user. This value should be cached in the WSGI application so > that it does not always require multiple round trips to the LDAP server. > Kerberos > Each tenant would get its own Kerberos Realm, but each would trust > the Cloud Provider's realm. The httpd/mod_auth_kerberos needs to be > capable of accepting new realms. When adding a new tenant, we might > need to update krb5.conf on the IPA server to know about the new realm. > > DNS > The BIND DynDB back end code would need to be extended to read zone > information from multiple subtrees in order to read the DNS entires in > the tenant trees. > > It is also possible to keep the current approach, and then add the > ability to identify which users and tenants can manage and control DNS > entries. The simpler solution is to modify BIND Dyn DB. > > CA > We would continue to have only one CA, and have IPA submit all > Certificate requests as a single Agent. The IPA server will ensure > that a user can only request certificates for entities within their > own subtree. > IPA-CLIENT > When enrolling a host, the principal used to authenticate with the > IPA server will determine which subtree will hold host. This > involves changing the LDAP configuration information in the following > client components: SSSD, nss_ldap, and Kerberos. > > > > _______________________________________________ > 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: From edewata at redhat.com Thu Dec 15 20:01:02 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 15 Dec 2011 14:01:02 -0600 Subject: [Freeipa-devel] [PATCH] 057 Fixed displaying of external records in rule association, widgets In-Reply-To: <4EE9ED86.8000506@redhat.com> References: <4EE9ED86.8000506@redhat.com> Message-ID: <4EEA51FE.8070001@redhat.com> On 12/15/2011 6:52 AM, Petr Vobornik wrote: > It's a fix for regression introduced by widget refactoring #2040. > > https://fedorahosted.org/freeipa/ticket/2040 ACK and pushed to master. -- Endi S. Dewata From edewata at redhat.com Thu Dec 15 20:01:16 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 15 Dec 2011 14:01:16 -0600 Subject: [Freeipa-devel] [PATCH] 058 Distinguishing of external values in association tables In-Reply-To: <4EE9EDF5.6080808@redhat.com> References: <4EE9EDF5.6080808@redhat.com> Message-ID: <4EEA520C.6050602@redhat.com> ACK and pushed to master. Possible future enhancements: On 12/15/2011 6:54 AM, Petr Vobornik wrote: > * For tables with possible external values a 'external' column was > added. It displays "True" if the value is external and nothing if not. > Displaying nothing is intentional. If user sees some text in external > column he immediately knows that the record is external without even > reading the "True" text. 1. While this is consistent with Host's Enrolled column, it is different from HBAC/sudo rule's Enabled column. I think we should make it more consistent across the board. > * Association table widget was stripped of get_records method. Loading > records isn't its responsibility it's a responsibility of field. 2. Similarly, the code in association.js:485-487 can also be moved into the field. So when the widget receives the values object it's already in the form of records. > * Column was extended by possible suppressing of link creation. It's > done by optional suppress_link argument in setup method. > * To allow setting suppress_link attribute in inherited tables a new > overridable method was created - setup_column. 3. Instead of adding a new parameter to the IPA.column.setup() we can also use a custom column and override the setup() to check whether it's an external member and then suppress the link. 4. The association table widget still depends on associator and add/remove method. They should be moved into the field. -- Endi S. Dewata From rcritten at redhat.com Thu Dec 15 21:03:34 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Dec 2011 16:03:34 -0500 Subject: [Freeipa-devel] [PATCHES] 59-65 SSH public key management In-Reply-To: <4EE06A77.2080700@redhat.com> References: <4EDF9444.20209@redhat.com> <4EE06A77.2080700@redhat.com> Message-ID: <4EEA60A6.90109@redhat.com> Jan Cholasta wrote: > Dne 7.12.2011 17:28, Jan Cholasta napsal(a): >> [PATCH] 65 Configure ssh and sshd during ipa-client-install. >> >> For ssh, VerifyHostKeyDNS option is enabled. >> >> For sshd, KerberosAuthentication, GSSAPIAuthentication and UsePAM >> options are enabled (this can be disabled using --no-sshd >> ipa-client-install option). >> > > Changed this not to implicitly trust DNS, as discussed on yesterday's > meeting. You can make SSH trust DNS explicitly using --ssh-trust-dns > ipa-client-install option. > > Honza > Traceback if ipaserver package is not installed. # ipa-client-install [snip] Created /etc/ipa/default.conf ipa : ERROR cannot import plugins sub-package ipaserver.install.plugins.plugins: No module named ipaserver.install.plugins Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 1474, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 1461, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 1277, in install api.finalize() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 656, in finalize self.__do_if_not_done('load_plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 452, in __do_if_not_done getattr(self, name)() File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 599, in load_plugins self.import_plugins('ipaserver/install/plugins') File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 625, in import_plugins raise e ImportError: No module named ipaserver.install.plugins You need to use a context other than 'installer'. I used 'cli_installer' to proceed. Is this what I should expect when logging into an enrolled client: $ slogin -v doberman.example.com [ snip ] debug1: matching host key fingerprint found in DNS The authenticity of host 'doberman.example.com. (192.168.186.9)' can't be established. RSA key fingerprint is 99:4a:4e:7f:4e:79:56:f6:00:4a:db:67:63:24:77:79. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? That part seems to be working, I guess I didn't expected to be asked. When I tested without DNS it said something about key not found in DNS as I would expect. I'm unable to add another pub key: $ ipa user-mod --addattr ipasshpubkey=== tuser1 ipa: ERROR: invalid 'ipasshpubkey': must be binary data $ ipa user-mod --sshpubkey=== tuser1 [SUCCESS] I wonder if normalize_ssh_pubkeys should not be validate_ssh_pubkeys(). It isn't really converting them to some common format, just confirming that they are valid keys, right? rob From rcritten at redhat.com Thu Dec 15 21:18:08 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Dec 2011 16:18:08 -0500 Subject: [Freeipa-devel] [PATCH] 0032 Validate sudo RunAsUser/RunAsGroup arguments In-Reply-To: <20111212225535.GE9668@redhat.com> References: <20111114093243.GA312@redhat.com> <4ED8F15B.7060602@redhat.com> <20111207114948.GA32281@redhat.com> <4EE67E9C.9080805@redhat.com> <20111212225535.GE9668@redhat.com> Message-ID: <4EEA6410.2030803@redhat.com> Alexander Bokovoy wrote: > On Mon, 12 Dec 2011, Rob Crittenden wrote: >>>> actual members, it treats it as a no-op. We should probably be >>>> consistent. >>> Don't understand. Did you mean 'to not provide any actual members'? >>> >>> In case you did, attached patch removes remaining checks for >>> runas_{user,group) to be False. >>> >>> >>>> It would probably be better to return the value as passed in by the >>>> user rather than user[0].value. >>> The issue here is that names come to the callback already as DNs from >>> LDAPAddMember's execute() method. Strictly speaking it is already >>> different to what user has entered as we do expansion by default to >>> add $SUFFIX and appropriate container. >>> >>> In the updated patch I tried to reduce DN to something reasonable by >>> relying on known containers and only showing full DN for cases when >>> these are not users/groups containers. >>> >> >> ACK on this patch. >> >> Do we need to add similar to HBAC plugin and sudorule-add-user, >> add-command, etc? > I was thinking about it as well, probably makes sense, indeed. What > about reduction code to be a method of DN itself? > > Something like > > class DN: > def relative_to(self, env, cn_name): > try: > cn_ = 'container_%s' % (cn_name) > if cn_ in env: > cn = DN(env[cn_])+DN(env.basedn) > else: > return self > except: > return self > if self.endswith(cn): > return self[0].value > return self > > > print dn.relative_to(env, 'user') > > If this is acceptable, I can do refactoring in a different ticket. NACK. We still have the value passed in by the user, right (in options['user'] and options['group'])? We basically take that, create a DN out of it, then pull the same value out. Why not skip all that and just look at the raw values instead? Or there is already a helper to get the key out of a dn, see self.Object.user.get_primary_key_from_dn(str(group)) Also, I found this doesn't handle a list of users or groups. If you pass in --users=joe,all then both get added as external users (assuming joe doesn't already exist, of course). rob From edewata at redhat.com Thu Dec 15 21:20:40 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 15 Dec 2011 15:20:40 -0600 Subject: [Freeipa-devel] Optionistic approach for new DNS API In-Reply-To: <1323898917.17355.47.camel@priserak> References: <1323898917.17355.47.camel@priserak> Message-ID: <4EEA64A8.801@redhat.com> On 12/14/2011 3:41 PM, Martin Kosek wrote: > ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 > ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. I think the mod & del commands should use the same way to specify the existing data. If we use the raw data, it should be specified as an option instead of an argument: ipa dnsrecord-mod ZONE NAME --type=mx \ --rec-data="10 server1.example.com." --new-preference=20 ipa dnsrecord-del ZONE NAME --type=mx \ --rec-data="10 server1.example.com." Alternatively we can use separate option for each parameter: ipa dnsrecord-mod ZONE NAME --type=mx \ --preference=10 --exchanger=server1.example.com. \ --new-preference=0 ipa dnsrecord-del ZONE NAME --type=mx \ --preference=10 --exchanger=server1.example.com. Or we can support both. > - SHOW and FIND commands do not need this new --type parameter We can also add --types to specify the record types we want to get back in the result. This could be useful in case we want to refresh a certain table only in the record details page. Low priority. BTW, I'd rather use --rec-type instead of just --type because 'type' seems to be more generic. In case a certain DNS record type also has a 'type' parameter, it might conflict with that. Another possibility is to use a prefix for all type-specific options, e.g. --mx-preference. > - ADD command: > - when no option is passed to dnsrecord-add command, it may ask for > --type and then for the options specific for the particular type > - MOD command: > - when no option is passed to dnsrecord-mod command, it may provide a > list of current DNS record values and ask for specific DNS record parts > to be changed for chosen value > - DEL command: > - when no option is passed to dnsrecord-del command, it may provide a > list of current DNS record values remove the chosen value For consistency the mod & del commands can also ask for the type, then show the list of records in that type. This way the list can be shown in a nicely formatted table rather than just raw data. -- Endi S. Dewata From mkosek at redhat.com Thu Dec 15 22:03:09 2011 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 15 Dec 2011 23:03:09 +0100 Subject: [Freeipa-devel] Optionistic approach for new DNS API In-Reply-To: <4EEA64A8.801@redhat.com> References: <1323898917.17355.47.camel@priserak> <4EEA64A8.801@redhat.com> Message-ID: <1323986589.5594.22.camel@priserak> On Thu, 2011-12-15 at 15:20 -0600, Endi Sukma Dewata wrote: > On 12/14/2011 3:41 PM, Martin Kosek wrote: > > ipa dnsrecord-mod ZONE NAME VALUE? --type=mx --preference=0 > > ipa dnsrecord-del ZONE NAME --type=mx --preference=0 --exchanger=server1.example.com. Thanks for comments Endi! Please, see my input bellow. > > I think the mod & del commands should use the same way to specify the > existing data. > > If we use the raw data, it should be specified as an option instead of > an argument: > > ipa dnsrecord-mod ZONE NAME --type=mx \ > --rec-data="10 server1.example.com." --new-preference=20 I was also thinking about using current param "--mx-rec": ipa dnsrecord-mod ZONE NAME --mx-rec="10 server1.example.com." \ --mx-preference=20 But this would be a misuse and unexpected behavior. A new option would be better for that. > > ipa dnsrecord-del ZONE NAME --type=mx \ > --rec-data="10 server1.example.com." Current command can do that: ipa dnsrecord-del ZONE NAME --mx-rec="10 server1.example.com." We have this behavior for free. > > Alternatively we can use separate option for each parameter: > > ipa dnsrecord-mod ZONE NAME --type=mx \ > --preference=10 --exchanger=server1.example.com. \ > --new-preference=0 > > ipa dnsrecord-del ZONE NAME --type=mx \ > --preference=10 --exchanger=server1.example.com. > > Or we can support both. I think I would implement the first option first. We can extend if we see it is useful. My point is that I don't think use would bother constructing structured DNS record from its options in dnsrecord-del/mod (fill --preference and --exchanger) but rather copy&paste raw DNS value or use the interactive mode. > > > - SHOW and FIND commands do not need this new --type parameter > > We can also add --types to specify the record types we want to get back > in the result. This could be useful in case we want to refresh a certain > table only in the record details page. Low priority. Ok, noted as an idea for enhancement. I would rather like to create a functional minimalistic API first and add all the bells and whistles later when we see it is useful. > > BTW, I'd rather use --rec-type instead of just --type because 'type' > seems to be more generic. In case a certain DNS record type also has a > 'type' parameter, it might conflict with that. Another possibility is to > use a prefix for all type-specific options, e.g. --mx-preference. Actually, I was discussing this with Honza today. The problem is that we can't add conflicting options to one command (e.g. --preference for MX record and --preference for KX record). We would have to use --mx-preference and --kx-preference anyway. This would also remove the necessity to use --rec-type at all. I think we could detect the type from the options that were passed. I.e. when the following command is passed: ipa dnsrecord-add ZONE NAME --mx-preference=0 --mx-exchanger=server1.example.com. We know that MX record is being created. > > > - ADD command: > > - when no option is passed to dnsrecord-add command, it may ask for > > --type and then for the options specific for the particular type > > - MOD command: > > - when no option is passed to dnsrecord-mod command, it may provide a > > list of current DNS record values and ask for specific DNS record parts > > to be changed for chosen value > > - DEL command: > > - when no option is passed to dnsrecord-del command, it may provide a > > list of current DNS record values remove the chosen value > > For consistency the mod & del commands can also ask for the type, then > show the list of records in that type. This way the list can be shown in > a nicely formatted table rather than just raw data. > IMO the interactive help I described is more effective - use just has to choose a record and start modification for a specific RR type. With your proposal, he would have to choose a type, then choose a record of that type and then start the modification - 2 steps instead of 1. (And I don't think that formatting nice tables with records in CLI would be a priority). Martin From ayoung at redhat.com Fri Dec 16 00:03:39 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 15 Dec 2011 19:03:39 -0500 Subject: [Freeipa-devel] Multitenancy in FreeIPA In-Reply-To: <4EEA3FA4.7000100@redhat.com> References: <4EEA2D54.5000306@redhat.com> <4EEA3FA4.7000100@redhat.com> Message-ID: <4EEA8ADB.9060707@redhat.com> >> The directory will no longer be world readable. Instead, ACIs will >> limit the users ability to read only the subtree in which they are >> enrolled. LDAP operations will require an authenticated bind. >> >> When updating IPA, schema changes need to be applied to each of the >> the tenant trees. >> API >> Each of the RPCs need to allow an optional parameter tenant. >> Members of the original domain with an approapriate Permission will >> be able to perform operations inside the tenant specified. > Some configuration changes will need to be made around a number of the > Directory Server plug-ins with regards to scope. We will likely need > separate configuration entries to restrict the plug-ins to each tenant > subtree. This includes the following plug-ins (and maybe others as well): > > - memberOf > - DNA > - Managed Entries > - Auto-Membership > - Attribute Uniqueness Thanks. Created a Wiki page with the document contents, and added your input here: http://freeipa.org/page/Multitenancy http://freeipa.org/page/Multitenancy#Directory_Server_Plugins From dpal at redhat.com Fri Dec 16 00:09:49 2011 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 15 Dec 2011 19:09:49 -0500 Subject: [Freeipa-devel] Multitenancy in FreeIPA In-Reply-To: <4EEA2D54.5000306@redhat.com> References: <4EEA2D54.5000306@redhat.com> Message-ID: <4EEA8C4D.4030202@redhat.com> On 12/15/2011 12:24 PM, Adam Young wrote: > When updating IPA, schema changes need to be applied to each of the > the tenant trees. > API > Each of the RPCs need to allow an optional parameter tenant. Members > of the original domain with an approapriate Permission will be able to > perform operations inside the tenant specified. Why you need this? The principal of the authenticated user will give you the tenant domain info. -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From edewata at redhat.com Fri Dec 16 01:24:25 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 15 Dec 2011 19:24:25 -0600 Subject: [Freeipa-devel] Optionistic approach for new DNS API In-Reply-To: <1323986589.5594.22.camel@priserak> References: <1323898917.17355.47.camel@priserak> <4EEA64A8.801@redhat.com> <1323986589.5594.22.camel@priserak> Message-ID: <4EEA9DC9.6040505@redhat.com> On 12/15/2011 4:03 PM, Martin Kosek wrote: >> If we use the raw data, it should be specified as an option instead of >> an argument: >> >> ipa dnsrecord-mod ZONE NAME --type=mx \ >> --rec-data="10 server1.example.com." --new-preference=20 > > I was also thinking about using current param "--mx-rec": > > ipa dnsrecord-mod ZONE NAME --mx-rec="10 server1.example.com." \ > --mx-preference=20 > > But this would be a misuse and unexpected behavior. A new option would > be better for that. I'm OK with either options. The help doc describes the --mx-rec option as a "comma-separated list of MX records". It doesn't say how the parameter should be used. We could say the mod command can be used in 2 different modes. In the first mode (the original) the command modifies the entire record object and the ---rec is used to specify the new records. In the second mode the command modifies a record specified in the ---rec. It also syntactically means we could perform the same modification against several records at once, although I'm not sure if it makes sense: ipa dnsrecord-mod ZONE NAME \ --mx-rec="10 server1.example.com.,10 server2.example.com." --mx-preference=20 > Current command can do that: > ipa dnsrecord-del ZONE NAME --mx-rec="10 server1.example.com." > We have this behavior for free. This is probably another reason to use the same --mx-rec option in mod. >> Alternatively we can use separate option for each parameter: >> >> ipa dnsrecord-mod ZONE NAME --type=mx \ >> --preference=10 --exchanger=server1.example.com. \ >> --new-preference=0 >> >> ipa dnsrecord-del ZONE NAME --type=mx \ >> --preference=10 --exchanger=server1.example.com. >> >> Or we can support both. > > I think I would implement the first option first. We can extend if we > see it is useful. My point is that I don't think use would bother > constructing structured DNS record from its options in dnsrecord-del/mod > (fill --preference and --exchanger) but rather copy&paste raw DNS value > or use the interactive mode. It might be useful for someone writing an application using the CLI. This way we don't need to know the order of the parameters. It's a low priority, but we should plan what parameter names we're going to use in the future. If now we use --mx-preference to specify the new value, later when we implement the new mechanism we will need to use something like --mx-old-preference to specify the old value. I'd rather use --mx-new-preference for the new value. >>> - SHOW and FIND commands do not need this new --type parameter >> >> We can also add --types to specify the record types we want to get back >> in the result. This could be useful in case we want to refresh a certain >> table only in the record details page. Low priority. > > Ok, noted as an idea for enhancement. I would rather like to create a > functional minimalistic API first and add all the bells and whistles > later when we see it is useful. OK. >> BTW, I'd rather use --rec-type instead of just --type because 'type' >> seems to be more generic. In case a certain DNS record type also has a >> 'type' parameter, it might conflict with that. Another possibility is to >> use a prefix for all type-specific options, e.g. --mx-preference. > > Actually, I was discussing this with Honza today. The problem is that we > can't add conflicting options to one command (e.g. --preference for MX > record and --preference for KX record). We would have to use > --mx-preference and --kx-preference anyway. It probably depends on how it's actually implemented. I suppose it's possible to keep a separate list of options for each type-specific command, then merge the lists for the main dnsrecord-add/mod/del command while removing duplicates. But using prefix is OK too. > This would also remove the necessity to use --rec-type at all. I think > we could detect the type from the options that were passed. I.e. when > the following command is passed: > > ipa dnsrecord-add ZONE NAME --mx-preference=0 --mx-exchanger=server1.example.com. > > We know that MX record is being created. Without the --rec-type, it's syntactically possible to add/mod/del multiple RR types at once. I'm not sure if we want to support that: ipa dnsrecord-mod ZONE NAME \ --mx-preference=0 --mx-exchanger=server1.example.com \ --mx-new-preference=1 --kx-preference=0 --kx-exchanger=server1.example.com \ --kx-exchanger=server2.example.com >>> - ADD command: >>> - when no option is passed to dnsrecord-add command, it may ask for >>> --type and then for the options specific for the particular type >>> - MOD command: >>> - when no option is passed to dnsrecord-mod command, it may provide a >>> list of current DNS record values and ask for specific DNS record parts >>> to be changed for chosen value >>> - DEL command: >>> - when no option is passed to dnsrecord-del command, it may provide a >>> list of current DNS record values remove the chosen value >> >> For consistency the mod& del commands can also ask for the type, then >> show the list of records in that type. This way the list can be shown in >> a nicely formatted table rather than just raw data. > > IMO the interactive help I described is more effective - use just has to > choose a record and start modification for a specific RR type. With your > proposal, he would have to choose a type, then choose a record of that > type and then start the modification - 2 steps instead of 1. The difference is not that big. Also if we keep the --rec-type option we can skip the first step: ipa dnsrecord-mod ZONE NAME --rec-type=mx > (And I don't think that formatting nice tables with records in CLI > would be a priority). Table is a compact way to show the data while still describing what the values in the raw data mean. No. Preference Exchanger -------------------------------------- 1. 10 server1.example.com. 2. 20 server2.example.com. Without table we might have to label each value: Record #1 Preference: 10 Exchanger: server1.example.com. Record #2 Preference: 10 Exchanger: server2.example.com. or just show the raw data without labels: 1) MX: "10 server1.example.com." 2) MX: "20 server2.example.com." 3) SRV: "0 100 464 ldap" My preference would be using the table, but the other options are still acceptable. -- Endi S. Dewata From rcritten at redhat.com Fri Dec 16 03:01:12 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 15 Dec 2011 22:01:12 -0500 Subject: [Freeipa-devel] Multitenancy in FreeIPA In-Reply-To: <4EEA8C4D.4030202@redhat.com> References: <4EEA2D54.5000306@redhat.com> <4EEA8C4D.4030202@redhat.com> Message-ID: <4EEAB478.8080004@redhat.com> Dmitri Pal wrote: > On 12/15/2011 12:24 PM, Adam Young wrote: >> When updating IPA, schema changes need to be applied to each of the >> the tenant trees. >> API >> Each of the RPCs need to allow an optional parameter tenant. Members >> of the original domain with an approapriate Permission will be able to >> perform operations inside the tenant specified. > Why you need this? The principal of the authenticated user will give you > the tenant domain info. > Do we want the landlord to be able to manage tenants? Will the landlord need a special account in each tenant? rob From pvoborni at redhat.com Fri Dec 16 08:51:49 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Fri, 16 Dec 2011 09:51:49 +0100 Subject: [Freeipa-devel] [PATCH] 059 Better table column width computing Message-ID: <4EEB06A5.40508@redhat.com> Columns can have width set or not. Without setting the width it was computed based on tbody width and number of columns. This method is working well if no column has width set. The disadvantage of this approach is that all columns have the same width and so they are not reflecting their possible usage. Flag columns such as 'external' in rule association tables or various 'enable' flags in search facets can be narrower. If we set them fixed small width it will have different size because this width is not currently added to the computation. This is fixing this problem so dynamic and fixed width can be combined and the columns have desired width. Also setting fixed width for external column in rule association widget. https://fedorahosted.org/freeipa/ticket/2200 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0059-Better-table-column-width-computing.patch Type: text/x-patch Size: 4857 bytes Desc: not available URL: From ayoung at redhat.com Fri Dec 16 09:32:49 2011 From: ayoung at redhat.com (Adam Young) Date: Fri, 16 Dec 2011 04:32:49 -0500 Subject: [Freeipa-devel] Multitenancy in FreeIPA In-Reply-To: <4EEA8C4D.4030202@redhat.com> References: <4EEA2D54.5000306@redhat.com> <4EEA8C4D.4030202@redhat.com> Message-ID: <4EEB1041.2030506@redhat.com> On 12/15/2011 07:09 PM, Dmitri Pal wrote: > On 12/15/2011 12:24 PM, Adam Young wrote: >> When updating IPA, schema changes need to be applied to each of the >> the tenant trees. >> API >> Each of the RPCs need to allow an optional parameter tenant. Members >> of the original domain with an approapriate Permission will be able to >> perform operations inside the tenant specified. > Why you need this? The principal of the authenticated user will give you > the tenant domain info. > "Members of the original domain with an approapriate Permission will be able to perform operations inside the tenant specified. " This is the override. This allows a super user account that can clean things up for the end users. Say the hosting domain is fedorahosted.org, but someone in a tenant of FREEIPA has managed to delete the admin account. dpal at FEDORAHOSTED.ORG can make a call with "tenant": "freeipa.org" and add a new admin account. From edewata at redhat.com Sat Dec 17 02:45:06 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Fri, 16 Dec 2011 20:45:06 -0600 Subject: [Freeipa-devel] [PATCH] 059 Better table column width computing In-Reply-To: <4EEB06A5.40508@redhat.com> References: <4EEB06A5.40508@redhat.com> Message-ID: <4EEC0232.8080302@redhat.com> On 12/16/2011 2:51 AM, Petr Vobornik wrote: > https://fedorahosted.org/freeipa/ticket/2200 ACK and pushed to master. One minor thing, the loops in widget.js line 1120 and 1127 probably can be combined. -- Endi S. Dewata From erinn.looneytriggs at gmail.com Sun Dec 18 22:38:56 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sun, 18 Dec 2011 13:38:56 -0900 Subject: [Freeipa-devel] Sudo documentation section Incorrect? Message-ID: <4EEE6B80.2010304@gmail.com> In the documentation for configuring sudo to use freeipa, it states that you should edit /etc/nsswitch.conf and add sudoers_debug: 1. The problem is that I can't find anything in the sudo documentation suggesting that this debug line should be in nsswitch.conf, instead it seems to suggest it should be in /etc/ldap.conf. Perhaps it can be in both, I am not sure, but either the freeipa documentation is incorrect or the sudo documentation is, or both, or neither :) I can't seem to find where the debug logging goes to anyway, so testing to see if one or the other location is correct is not possible for me right now. This all came about because the augeas lens for /etc/nsswitch.conf chokes on the sudoers_debug line and in the course of trying to fix the lens I couldn't find any docs supporting the concept that it should be in nsswitch.conf. -Erinn From erinn.looneytriggs at gmail.com Sun Dec 18 22:46:35 2011 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Sun, 18 Dec 2011 13:46:35 -0900 Subject: [Freeipa-devel] Sudo documentation section Incorrect? Message-ID: <4EEE6D4B.1030404@gmail.com> Never mind, the freeipa documentation is incorrect, just read through the sudo source. I will file a bug against freeipa. -Erinn From pvoborni at redhat.com Mon Dec 19 15:44:39 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 Dec 2011 16:44:39 +0100 Subject: [Freeipa-devel] [PATCH] 060 Parsing of IPv4 and IPv6 addresses Message-ID: <4EEF5BE7.4040002@redhat.com> [Web UI] Added support of parsing and validation of IPv4 and IPv6 addresses. Class IP.address can also create reverse address from any valid IPv4 or IPv6 address. This functionality is prerequisite for tickets: https://fedorahosted.org/freeipa/ticket/1466 https://fedorahosted.org/freeipa/ticket/1975 Ticket: https://fedorahosted.org/freeipa/ticket/1466 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0060-Parsing-of-IPv4-and-IPv6-addresses.patch Type: text/x-patch Size: 23001 bytes Desc: not available URL: From alee at redhat.com Mon Dec 19 16:11:25 2011 From: alee at redhat.com (Ade Lee) Date: Mon, 19 Dec 2011 11:11:25 -0500 Subject: [Freeipa-devel] Merging dogtag and ipa databases Message-ID: <1324311086.12374.5.camel@aleeredhat.laptop> Hi all, Based on conversations with Adam, Simo and Rob, here are some thoughts on $subject: http://pki.fedoraproject.org/wiki/Merging_IPA_and_Dogtag_Databases I'll probably add more later - like the details on how cloned instance installation will run. Comments are welcome. Ade From pvoborni at redhat.com Mon Dec 19 16:12:46 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Mon, 19 Dec 2011 17:12:46 +0100 Subject: [Freeipa-devel] [PATCH] 060 Parsing of IPv4 and IPv6 addresses In-Reply-To: <4EEF5BE7.4040002@redhat.com> References: <4EEF5BE7.4040002@redhat.com> Message-ID: <4EEF627E.6050402@redhat.com> On 12/19/2011 04:44 PM, Petr Vobornik wrote: > [Web UI] > > Added support of parsing and validation of IPv4 and IPv6 addresses. > Class IP.address can also create reverse address from any valid IPv4 or > IPv6 address. > > This functionality is prerequisite for tickets: > https://fedorahosted.org/freeipa/ticket/1466 > https://fedorahosted.org/freeipa/ticket/1975 > > Ticket: https://fedorahosted.org/freeipa/ticket/1466 > Self NACK Getting reverse addresses is not functional for integer IPv4 input. Updated patch will follow tomorrow. -- Petr Vobornik From dpal at redhat.com Mon Dec 19 16:49:31 2011 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 19 Dec 2011 11:49:31 -0500 Subject: [Freeipa-devel] Merging dogtag and ipa databases In-Reply-To: <1324311086.12374.5.camel@aleeredhat.laptop> References: <1324311086.12374.5.camel@aleeredhat.laptop> Message-ID: <4EEF6B1B.8090809@redhat.com> On 12/19/2011 11:11 AM, Ade Lee wrote: > Hi all, > > Based on conversations with Adam, Simo and Rob, here are some thoughts > on $subject: > http://pki.fedoraproject.org/wiki/Merging_IPA_and_Dogtag_Databases > > I'll probably add more later - like the details on how cloned instance > installation will run. > > Comments are welcome. > > Ade > Ade, IPA has a notion of the system account too. It has system account for Kerberos for example. Those accounts are not exposed in UI and there is already a location for them. Have you considered this option? -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From abokovoy at redhat.com Mon Dec 19 20:24:27 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 19 Dec 2011 22:24:27 +0200 Subject: [Freeipa-devel] Merging dogtag and ipa databases In-Reply-To: <4EEF6B1B.8090809@redhat.com> References: <1324311086.12374.5.camel@aleeredhat.laptop> <4EEF6B1B.8090809@redhat.com> Message-ID: <20111219202427.GC31934@redhat.com> On Mon, 19 Dec 2011, Dmitri Pal wrote: > On 12/19/2011 11:11 AM, Ade Lee wrote: > > Hi all, > > > > Based on conversations with Adam, Simo and Rob, here are some thoughts > > on $subject: > > http://pki.fedoraproject.org/wiki/Merging_IPA_and_Dogtag_Databases > > > > I'll probably add more later - like the details on how cloned instance > > installation will run. > > > > Comments are welcome. > > > > Ade > > > > Ade, > > IPA has a notion of the system account too. > It has system account for Kerberos for example. > Those accounts are not exposed in UI and there is already a location for > them. There will be also system accounts for samba users on replicas in trust setup. And as freeipa-users@ discussion have shown, there are other uses for such accounts --- connecting with NAS systems, for example. So there is definitely need to consider system accounts. -- / Alexander Bokovoy From simo at redhat.com Mon Dec 19 20:52:49 2011 From: simo at redhat.com (Simo Sorce) Date: Mon, 19 Dec 2011 15:52:49 -0500 Subject: [Freeipa-devel] Merging dogtag and ipa databases In-Reply-To: <4EEF6B1B.8090809@redhat.com> References: <1324311086.12374.5.camel@aleeredhat.laptop> <4EEF6B1B.8090809@redhat.com> Message-ID: <1324327969.28622.100.camel@willson.li.ssimo.org> On Mon, 2011-12-19 at 11:49 -0500, Dmitri Pal wrote: > On 12/19/2011 11:11 AM, Ade Lee wrote: > > Hi all, > > > > Based on conversations with Adam, Simo and Rob, here are some thoughts > > on $subject: > > http://pki.fedoraproject.org/wiki/Merging_IPA_and_Dogtag_Databases > > > > I'll probably add more later - like the details on how cloned instance > > installation will run. > > > > Comments are welcome. > > > > Ade > > > > Ade, > > IPA has a notion of the system account too. > It has system account for Kerberos for example. > Those accounts are not exposed in UI and there is already a location for > them. > Have you considered this option? We do not want to have dogtag have write permission to the IPA tree, so it is better if dogtag has it's service users in it's own tree. We have nothing in IPA proper that cares for those anyway as they are application specific. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Mon Dec 19 23:01:41 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 19 Dec 2011 17:01:41 -0600 Subject: [Freeipa-devel] [PATCH] 332 Refactored entity object resolution. Message-ID: <4EEFC255.6050903@redhat.com> The IPA.get_entity() has been modified to accept either entity name or entity object. If it receives an entity object it will return the object itself. Otherwise, it will resolve the name in the entity registry. The other_entity variables have been modified to store a reference to the entity object instead of its name. The test cases have been modified to use real entity objects instead of just the names. Ticket #2042 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0332-Refactored-entity-object-resolution.patch Type: text/x-patch Size: 48705 bytes Desc: not available URL: From ayoung at redhat.com Tue Dec 20 01:07:53 2011 From: ayoung at redhat.com (Adam Young) Date: Mon, 19 Dec 2011 20:07:53 -0500 Subject: [Freeipa-devel] Merging dogtag and ipa databases In-Reply-To: <1324327969.28622.100.camel@willson.li.ssimo.org> References: <1324311086.12374.5.camel@aleeredhat.laptop> <4EEF6B1B.8090809@redhat.com> <1324327969.28622.100.camel@willson.li.ssimo.org> Message-ID: <4EEFDFE9.6010003@redhat.com> On 12/19/2011 03:52 PM, Simo Sorce wrote: > On Mon, 2011-12-19 at 11:49 -0500, Dmitri Pal wrote: >> On 12/19/2011 11:11 AM, Ade Lee wrote: >>> Hi all, >>> >>> Based on conversations with Adam, Simo and Rob, here are some thoughts >>> on $subject: >>> http://pki.fedoraproject.org/wiki/Merging_IPA_and_Dogtag_Databases >>> >>> I'll probably add more later - like the details on how cloned instance >>> installation will run. >>> >>> Comments are welcome. >>> >>> Ade >>> >> Ade, >> >> IPA has a notion of the system account too. >> It has system account for Kerberos for example. >> Those accounts are not exposed in UI and there is already a location for >> them. >> Have you considered this option? > We do not want to have dogtag have write permission to the IPA tree, so > it is better if dogtag has it's service users in it's own tree. We have > nothing in IPA proper that cares for those anyway as they are > application specific. > > Simo. > Agreed. The general rule should be that each application gets its own Subtree. From pvoborni at redhat.com Tue Dec 20 08:35:07 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Dec 2011 09:35:07 +0100 Subject: [Freeipa-devel] [PATCH] 060 Parsing of IPv4 and IPv6 addresses In-Reply-To: <4EEF627E.6050402@redhat.com> References: <4EEF5BE7.4040002@redhat.com> <4EEF627E.6050402@redhat.com> Message-ID: <4EF048BB.3010303@redhat.com> On 12/19/2011 05:12 PM, Petr Vobornik wrote: > On 12/19/2011 04:44 PM, Petr Vobornik wrote: >> [Web UI] >> >> Added support of parsing and validation of IPv4 and IPv6 addresses. >> Class IP.address can also create reverse address from any valid IPv4 or >> IPv6 address. >> >> This functionality is prerequisite for tickets: >> https://fedorahosted.org/freeipa/ticket/1466 >> https://fedorahosted.org/freeipa/ticket/1975 >> >> Ticket: https://fedorahosted.org/freeipa/ticket/1466 >> > > Self NACK > > Getting reverse addresses is not functional for integer IPv4 input. > > Updated patch will follow tomorrow. > Fixed. Attached new patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0060-1-Parsing-of-IPv4-and-IPv6-addresses.patch Type: text/x-patch Size: 23368 bytes Desc: not available URL: From pvoborni at redhat.com Tue Dec 20 13:28:56 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Dec 2011 14:28:56 +0100 Subject: [Freeipa-devel] [PATCH] 332 Refactored entity object resolution. In-Reply-To: <4EEFC255.6050903@redhat.com> References: <4EEFC255.6050903@redhat.com> Message-ID: <4EF08D98.2040906@redhat.com> On 12/20/2011 12:01 AM, Endi Sukma Dewata wrote: > The IPA.get_entity() has been modified to accept either entity name > or entity object. If it receives an entity object it will return > the object itself. Otherwise, it will resolve the name in the entity > registry. > > The other_entity variables have been modified to store a reference > to the entity object instead of its name. The test cases have been > modified to use real entity objects instead of just the names. > > Ticket #2042 > 1) when link_field is a creating a command in field.js:558 it's passing an entity instead of entity name. It causes creation of wrong command name. -- Petr Vobornik From pvoborni at redhat.com Tue Dec 20 14:14:00 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Tue, 20 Dec 2011 15:14:00 +0100 Subject: [Freeipa-devel] [PATCH] 061 Fixed labels in Sudo, HBAC rules Message-ID: <4EF09828.1090601@redhat.com> Fixed regression in labels introduced by refactoring - #1515. https://fedorahosted.org/freeipa/ticket/1515 -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0061-Fixed-labels-in-Sudo-HBAC-rules.patch Type: text/x-patch Size: 3067 bytes Desc: not available URL: From simo at redhat.com Tue Dec 20 17:46:18 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Dec 2011 12:46:18 -0500 Subject: [Freeipa-devel] [PATCH] Fix slapi plugins build Message-ID: <1324403178.28622.121.camel@willson.li.ssimo.org> This patch is needed to fix the slapi plugins to build against the thread-safe (reentrant) version of openldap libraries. I haven't changed ipa-clients because they are not threaded programs and wanted to restrict the change as much as possible. Fixes #2198. The same patch can be cherry-picked against both 2.1.x and master. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-simo-474-1-slapi-plugins-use-thread-safe-ldap-library.patch Type: text/x-patch Size: 802 bytes Desc: not available URL: From simo at redhat.com Tue Dec 20 17:55:36 2011 From: simo at redhat.com (Simo Sorce) Date: Tue, 20 Dec 2011 12:55:36 -0500 Subject: [Freeipa-devel] [PATCH] Fix slapi plugins build In-Reply-To: <1324403178.28622.121.camel@willson.li.ssimo.org> References: <1324403178.28622.121.camel@willson.li.ssimo.org> Message-ID: <1324403736.28622.123.camel@willson.li.ssimo.org> On Tue, 2011-12-20 at 12:46 -0500, Simo Sorce wrote: > This patch is needed to fix the slapi plugins to build against the > thread-safe (reentrant) version of openldap libraries. > > I haven't changed ipa-clients because they are not threaded programs and > wanted to restrict the change as much as possible. > > Fixes #2198. > > The same patch can be cherry-picked against both 2.1.x and master. I actually created 2 new patches (one for 2-1 and one for master) where I also change the spec file so that freeipa packages depend on the new 389ds package that uses the ldap_r library as both 389ds and plugins must be build with the same libraries. Simo. -- Simo Sorce * Red Hat, Inc * New York -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-2-1-simo-474-2-slapi-plugins-use-thread-safe-ldap-library.patch Type: text/x-patch Size: 1421 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-master-simo-474-2-slapi-plugins-use-thread-safe-ldap-library.patch Type: text/x-patch Size: 1427 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 20 20:57:40 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Dec 2011 14:57:40 -0600 Subject: [Freeipa-devel] [PATCH] 060 Parsing of IPv4 and IPv6 addresses In-Reply-To: <4EF048BB.3010303@redhat.com> References: <4EEF5BE7.4040002@redhat.com> <4EEF627E.6050402@redhat.com> <4EF048BB.3010303@redhat.com> Message-ID: <4EF0F6C4.8020106@redhat.com> On 12/20/2011 2:35 AM, Petr Vobornik wrote: >>> Added support of parsing and validation of IPv4 and IPv6 addresses. >>> Class IP.address can also create reverse address from any valid IPv4 or >>> IPv6 address. >>> >>> This functionality is prerequisite for tickets: >>> https://fedorahosted.org/freeipa/ticket/1466 >>> https://fedorahosted.org/freeipa/ticket/1975 >>> >>> Ticket: https://fedorahosted.org/freeipa/ticket/1466 The code isn't used yet in the main code, so it can be pushed without breaking anything. I have some suggestions though: 1. For convenience, the IP.address class probably can be made to take a string or a spec object then call parse() internally. For example: var address1 = IP.address('127.0.0.1'); var address2 = IP.address({ parts: [127, 0, 0, 1] type: 'v4-quads' }); var reverse = address1.get_reverse(); 2. The test checks the return value of parse() but it doesn't validate whether the IP address is parsed into the correct parts. It probably should do something like this: var address = IP.address('127.0.0.1'); same(address.parts, [127, 0, 0, 1]); 3. The ip_tests.html should be linked from the index.html. 4. It's probably better to use NET instead of IP for the namespace so we can add more net-related stuff. -- Endi S. Dewata From ayoung at redhat.com Tue Dec 20 21:06:37 2011 From: ayoung at redhat.com (Adam Young) Date: Tue, 20 Dec 2011 16:06:37 -0500 Subject: [Freeipa-devel] [PATCH] 0294 remove delegation from browser config Message-ID: <4EF0F8DD.5010503@redhat.com> Hold this patch until all of the S4U2 code is pushed, otherwise it will break the WebUI -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0294-Remove-delegation-from-browser-config.patch Type: text/x-patch Size: 3246 bytes Desc: not available URL: From edewata at redhat.com Tue Dec 20 21:08:19 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Dec 2011 15:08:19 -0600 Subject: [Freeipa-devel] [PATCH] 061 Fixed labels in Sudo, HBAC rules In-Reply-To: <4EF09828.1090601@redhat.com> References: <4EF09828.1090601@redhat.com> Message-ID: <4EF0F943.3000306@redhat.com> On 12/20/2011 8:14 AM, Petr Vobornik wrote: > Fixed regression in labels introduced by refactoring - #1515. > > https://fedorahosted.org/freeipa/ticket/1515 ACK. Pushed to master. -- Endi S. Dewata From edewata at redhat.com Tue Dec 20 21:29:04 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Dec 2011 15:29:04 -0600 Subject: [Freeipa-devel] [PATCH] 332 Refactored entity object resolution. In-Reply-To: <4EF08D98.2040906@redhat.com> References: <4EEFC255.6050903@redhat.com> <4EF08D98.2040906@redhat.com> Message-ID: <4EF0FE20.3000508@redhat.com> On 12/20/2011 7:28 AM, Petr Vobornik wrote: > 1) when link_field is a creating a command in field.js:558 it's passing > an entity instead of entity name. It causes creation of wrong command name. Fixed and rebased. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0332-2-Refactored-entity-object-resolution.patch Type: text/x-patch Size: 48710 bytes Desc: not available URL: From edewata at redhat.com Wed Dec 21 01:16:43 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Dec 2011 19:16:43 -0600 Subject: [Freeipa-devel] [PATCH] 333 Reload UI when the user changes. Message-ID: <4EF1337B.9080304@redhat.com> The JSON server has been modified to return the principal name in all responses. The UI has been modified to keep the principal obtained during whoami operation and check the principal returned in subsequent operations. If the principal changes the UI will reload itself. Ticket #1400 -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0333-Reload-UI-when-the-user-changes.patch Type: text/x-patch Size: 2096 bytes Desc: not available URL: From edewata at redhat.com Wed Dec 21 01:37:56 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Dec 2011 19:37:56 -0600 Subject: [Freeipa-devel] [PATCH] 333 Reload UI when the user changes. In-Reply-To: <4EF1337B.9080304@redhat.com> References: <4EF1337B.9080304@redhat.com> Message-ID: <4EF13874.7040203@redhat.com> On 12/20/2011 7:16 PM, Endi Sukma Dewata wrote: > The JSON server has been modified to return the principal name > in all responses. The UI has been modified to keep the principal > obtained during whoami operation and check the principal returned > in subsequent operations. If the principal changes the UI will > reload itself. > > Ticket #1400 New patch to fix infinite reload problem with test fixtures. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0333-2-Reload-UI-when-the-user-changes.patch Type: text/x-patch Size: 2114 bytes Desc: not available URL: From edewata at redhat.com Wed Dec 21 02:09:17 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 20 Dec 2011 20:09:17 -0600 Subject: [Freeipa-devel] [PATCH] 334 Reload UI on server upgrade. Message-ID: <4EF13FCD.9030103@redhat.com> The JSON server has been modified to return the version number in all responses. The UI has been modified to keep the version obtained during env operation and check the version returned in subsequent operations. If the version changes the UI will reload itself. Ticket #946 This can be tested using the lite server: 1. Run lite server. 2. Open the UI. 3. Change the VERSION in ipapython/version.py. 4. Restart lite server. 5. Click any link on the UI, the UI should reload. -- Endi S. Dewata -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-edewata-0334-Reload-UI-on-server-upgrade.patch Type: text/x-patch Size: 3015 bytes Desc: not available URL: From jcholast at redhat.com Wed Dec 21 13:32:44 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 21 Dec 2011 14:32:44 +0100 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <20111202202631.GA29560@redhat.com> References: <4E96B5AB.4030800@redhat.com> <4E970565.6040009@redhat.com> <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> <4ED8E717.7050302@redhat.com> <4ED8E859.1050407@redhat.com> <20111202202631.GA29560@redhat.com> Message-ID: <4EF1DFFC.4060905@redhat.com> Dne 2.12.2011 21:26, Alexander Bokovoy napsal(a): > On Fri, 02 Dec 2011, Jan Cholasta wrote: >>>> I don't like the idea of introducing a new class every time we need a >>>> ReadOnly attribute to be writable. There's quite a few places in the >>>> code where we do object.__setattr__ on ReadOnly objects. IMO the right >>>> thing to do would be to add means of whitelisting ReadOnly attributes >>>> that need to stay writable after locking. >>>> >>>>> >>>>> You can move those _select_ca(), _select_any_master(), >>>>> _host_has_service() to CaCache as they seem to not depend on anything >>>>> in class ca but rather use global api.env. >>>>> >>>>> This way you will get is a fairly simple CaCache class reusable both >>>>> in ca and ra classes. >>>> >>>> Honza >>>> >>> >>> What is the status of this patch? >>> >>> rob >> >> It fixes the issue and I wouldn't mind leaving it as it is. >> >> Alexander? > > I still don't like it. There is nothing in CA that really requires > enabling writting to ReadOnly after locking. ReadOnly is a fundamental > promise of our API and breaking it should be possible only for cases > where any other approach will be ineffective. This particular case is > rather poor implementation of CA/RA classes that could be solved in a > simpler way. > > Sometimes you need to hold promises. ;) > Updated and rebased the patch. Added a class for creating property-like attributes that cache the return value of a function call. Fixed some more unit test issues that popped up since I first made the patch. Note that some tests are still failing, most of the failures seem to be related to user private groups (see attached log). Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-54.2-fix-read-only-write.patch Type: text/x-patch Size: 9201 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.log Type: text/x-log Size: 110204 bytes Desc: not available URL: From pvoborni at redhat.com Wed Dec 21 13:50:37 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 21 Dec 2011 14:50:37 +0100 Subject: [Freeipa-devel] [PATCH] 060 Parsing of IPv4 and IPv6 addresses In-Reply-To: <4EF0F6C4.8020106@redhat.com> References: <4EEF5BE7.4040002@redhat.com> <4EEF627E.6050402@redhat.com> <4EF048BB.3010303@redhat.com> <4EF0F6C4.8020106@redhat.com> Message-ID: <4EF1E42D.2020406@redhat.com> On 12/20/2011 09:57 PM, Endi Sukma Dewata wrote: > > The code isn't used yet in the main code, so it can be pushed without > breaking anything. I have some suggestions though: > > 1. For convenience, the IP.address class probably can be made to take a > string or a spec object then call parse() internally. For example: > > var address1 = IP.address('127.0.0.1'); Added > > var address2 = IP.address({ > parts: [127, 0, 0, 1] > type: 'v4-quads' > }); > Added, but I don't see a usage for this. > var reverse = address1.get_reverse(); Address is parsed internally. You can also set the input after creating an address - as it was before. Added some tests to show the usages. > > 2. The test checks the return value of parse() but it doesn't validate > whether the IP address is parsed into the correct parts. It probably > should do something like this: > > var address = IP.address('127.0.0.1'); > same(address.parts, [127, 0, 0, 1]); Added > > 3. The ip_tests.html should be linked from the index.html. Added > > 4. It's probably better to use NET instead of IP for the namespace so we > can add more net-related stuff. > Changed. Test are still called ip_tests - I wouldn't put there any new non-ip-address related. For convenience I also attached a 'diff' patch. -- Petr Vobornik -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-pvoborni-0060-2-Parsing-of-IPv4-and-IPv6-addresses.patch Type: text/x-patch Size: 28458 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wip-freeipa-pvoborni-0066-Review-changes.patch Type: text/x-patch Size: 21398 bytes Desc: not available URL: From pvoborni at redhat.com Wed Dec 21 14:01:15 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 21 Dec 2011 15:01:15 +0100 Subject: [Freeipa-devel] [PATCH] 332 Refactored entity object resolution. In-Reply-To: <4EF0FE20.3000508@redhat.com> References: <4EEFC255.6050903@redhat.com> <4EF08D98.2040906@redhat.com> <4EF0FE20.3000508@redhat.com> Message-ID: <4EF1E6AB.3030001@redhat.com> On 12/20/2011 10:29 PM, Endi Sukma Dewata wrote: > On 12/20/2011 7:28 AM, Petr Vobornik wrote: >> 1) when link_field is a creating a command in field.js:558 it's passing >> an entity instead of entity name. It causes creation of wrong command >> name. > > Fixed and rebased. > ACK and pushed to master -- Petr Vobornik From pvoborni at redhat.com Wed Dec 21 14:59:52 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 21 Dec 2011 15:59:52 +0100 Subject: [Freeipa-devel] [PATCH] 0294 remove delegation from browser config In-Reply-To: <4EF0F8DD.5010503@redhat.com> References: <4EF0F8DD.5010503@redhat.com> Message-ID: <4EF1F468.6060800@redhat.com> On 12/20/2011 10:06 PM, Adam Young wrote: > Hold this patch until all of the S4U2 code is pushed, otherwise it will > break the WebUI > assuming it is this ticket: https://fedorahosted.org/freeipa/ticket/2207 1) why is there a services.py file ? -- Petr Vobornik From abokovoy at redhat.com Wed Dec 21 15:16:08 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 21 Dec 2011 17:16:08 +0200 Subject: [Freeipa-devel] [PATCH] 0294 remove delegation from browser config In-Reply-To: <4EF1F468.6060800@redhat.com> References: <4EF0F8DD.5010503@redhat.com> <4EF1F468.6060800@redhat.com> Message-ID: <20111221151607.GG31934@redhat.com> On Wed, 21 Dec 2011, Petr Vobornik wrote: > On 12/20/2011 10:06 PM, Adam Young wrote: > >Hold this patch until all of the S4U2 code is pushed, otherwise it will > >break the WebUI > > > > assuming it is this ticket: https://fedorahosted.org/freeipa/ticket/2207 > > 1) why is there a services.py file ? Should be ignored. It is generated file. -- / Alexander Bokovoy From simo at redhat.com Wed Dec 21 15:18:38 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 21 Dec 2011 10:18:38 -0500 Subject: [Freeipa-devel] [PATCH] 0294 remove delegation from browser config In-Reply-To: <20111221151607.GG31934@redhat.com> References: <4EF0F8DD.5010503@redhat.com> <4EF1F468.6060800@redhat.com> <20111221151607.GG31934@redhat.com> Message-ID: <1324480718.28622.149.camel@willson.li.ssimo.org> On Wed, 2011-12-21 at 17:16 +0200, Alexander Bokovoy wrote: > On Wed, 21 Dec 2011, Petr Vobornik wrote: > > > On 12/20/2011 10:06 PM, Adam Young wrote: > > >Hold this patch until all of the S4U2 code is pushed, otherwise it will > > >break the WebUI > > > > > > > assuming it is this ticket: https://fedorahosted.org/freeipa/ticket/2207 > > > > 1) why is there a services.py file ? > Should be ignored. It is generated file. Adam can you rebase without the services.py file ? Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Dec 21 15:46:21 2011 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 21 Dec 2011 16:46:21 +0100 Subject: [Freeipa-devel] [PATCH] [WIP] 182 Create per-type DNS API based on options Message-ID: <1324482381.11925.16.camel@balmora.brq.redhat.com> This is a fully functional prototype of the new DNS API based on new options instead of new commands. It still has rough edges (missing tests, extended help) but should give a very good picture about the new API and provide a base for WebUI guys. ------- Use new structured DNSRecord parameters to generate per-type API for all supported DNS RR types. This should help significantly the end-user with manipulating complex DNS record type (MX, LOC, etc.). All enhancements are integrated to current DNS record commands: 1) dnsrecord-add - Records can be either entered as a raw value (e.g. --mx-rec= "1 srv1.example.com" for MX record) or per-part: --mx-preference=1 --mx-exchanger=srv1.example.com - CLI interactive help behavior was changed. It will ask for a record type and then ask for all DNS record part values (e.g. MX Preference value, MX Exchanger value). 2) dnsrecord-mod - This command can now operate in 2 modes. When only a raw DNS record is entered (e.g. --mx-rec="1 srv1.example.com") it operates in standard mode and replaces any previous mxrecord value with the --mx-rec value. When any structured parameter (e.g. --mx-preference) is passed it modifies just the specified parts of one mxrecord value referred by --mx-rec: --mx-rec="1 srv1.example.com" --mx-preference=2 - New interactive help has been implemented. It will ask for a record to be modified (in the same manner as dnsrecord-del) and then let user change DNS record part(s) for chosen records. 3) All dnsrecord-* commands have now --structured option - When this option is passed, instead of displaying raw DNS values all DNS records are parsed and displayed per-part. Example: $ ipa dnsrecord-show example.com @ --structured Record name: @ Records: Record type: MX Record data: 0 server1.example.com. MX Preference: 0 MX Exchanger: server1.example.com. Record type: NS Record data: ns1.example.com. NS Hostname: ns1.example.com. All API changes are compatible with clients without this patch. https://fedorahosted.org/freeipa/ticket/2082 ------------------------------------------------ A little demonstration of the new API capabilities: #### New help with option groups for per-type options # ipa dnsrecord-add --help Usage: ipa [global-options] dnsrecord-add DNSZONE NAME [options] Options: ... --structured Parse all raw DNS records and return them in a structured way ... A Record: --a-rec=ARECORD Comma-separated list of raw A records --a-ip-address=STR IP Address AAAA Record: --aaaa-rec=AAAARECORD Comma-separated list of raw AAAA records --aaaa-ip-address=STR IP Address ... MX Record: --mx-rec=MXRECORD Comma-separated list of raw MX records --mx-preference=INT Preference given to this exchanger. Lower values are more preferred --mx-exchanger=STR A host willing to act as a mail exchanger #### Standard dnsrecord-add # ipa dnsrecord-add example.com server1 --a-rec=10.0.0.1 Record name: server1 A record: 10.0.0.1 #### New interactive help for dnsrecord-add # ipa dnsrecord-add example.com server1 Please choose a type of DNS resource record to be added The most common types for this type of zone are: A, AAAA DNS resource record type: AAAA AAAA IP Address: 2001:db8::1428:57ab Record name: server1 A record: 10.0.0.1 AAAA record: 2001:db8::1428:57ab # ipa dnsrecord-add example.com @ Please choose a type of DNS resource record to be added The most common types for this type of zone are: NS, MX, LOC DNS resource record type: MX MX Preference: 0 MX Exchanger: server1.example.com. Record name: example.com MX record: 0 server1.example.com. NS record: vm-068.idm.lab.bos.redhat.com. #### Old-stype mod command # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." Record name: example.com MX record: 1 server1.example.com. NS record: vm-068.idm.lab.bos.redhat.com. #### Modification via new structured options: # ipa dnsrecord-mod example.com @ --mx-rec="1 server1.example.com." --mx-preference=2 Record name: example.com MX record: 2 server1.example.com. NS record: vm-068.idm.lab.bos.redhat.com. #### Modification via new interactive help: # ipa dnsrecord-mod example.com @ No option to modify specific record provided. Current DNS record contents: MX record: 2 server1.example.com. NS record: vm-068.idm.lab.bos.redhat.com. Modify MX record '2 server1.example.com.'? Yes/No (default No): y MX Preference [2]: 3 MX Exchanger [server1.example.com.]: Modify NS record 'vm-068.idm.lab.bos.redhat.com.'? Yes/No (default No): Record name: example.com MX record: 3 server1.example.com. NS record: vm-068.idm.lab.bos.redhat.com. #### Example of use of --structured option (this will be useful for WebUI): # ipa dnsrecord-show example.com @ --structured Record name: @ Records: Record type: MX Record data: 3 server1.example.com. MX Preference: 3 MX Exchanger: server1.example.com. Record type: NS Record data: vm-068.idm.lab.bos.redhat.com. NS Hostname: vm-068.idm.lab.bos.redhat.com. #### dnsrecord-del works in the same way as the old one: # ipa dnsrecord-del example.com server1 No option to delete specific record provided. Delete all? Yes/No (default No): Current DNS record contents: AAAA record: 2001:db8::1428:57ab A record: 10.0.0.1 Delete AAAA record '2001:db8::1428:57ab'? Yes/No (default No): y Delete A record '10.0.0.1'? Yes/No (default No): Record name: server1 A record: 10.0.0.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-172-4-refactor-dnsrecord-processing.patch Type: text/x-patch Size: 95926 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-175-fix-parameter-csv-parsing.patch Type: text/x-patch Size: 1319 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-181-improve-cli-output-for-complex-commands.patch Type: text/x-patch Size: 3822 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-mkosek-182-create-per-type-dns-api.patch Type: text/x-patch Size: 107412 bytes Desc: not available URL: From pvoborni at redhat.com Wed Dec 21 16:07:09 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 21 Dec 2011 17:07:09 +0100 Subject: [Freeipa-devel] [PATCH] 334 Reload UI on server upgrade. In-Reply-To: <4EF13FCD.9030103@redhat.com> References: <4EF13FCD.9030103@redhat.com> Message-ID: <4EF2042D.5080707@redhat.com> On 12/21/2011 03:09 AM, Endi Sukma Dewata wrote: > The JSON server has been modified to return the version number > in all responses. The UI has been modified to keep the version > obtained during env operation and check the version returned > in subsequent operations. If the version changes the UI will > reload itself. > > Ticket #946 > > This can be tested using the lite server: > > 1. Run lite server. > 2. Open the UI. > 3. Change the VERSION in ipapython/version.py. > 4. Restart lite server. > 5. Click any link on the UI, the UI should reload. > ACK -- Petr Vobornik From pvoborni at redhat.com Wed Dec 21 16:07:16 2011 From: pvoborni at redhat.com (Petr Vobornik) Date: Wed, 21 Dec 2011 17:07:16 +0100 Subject: [Freeipa-devel] [PATCH] 333 Reload UI when the user changes. In-Reply-To: <4EF13874.7040203@redhat.com> References: <4EF1337B.9080304@redhat.com> <4EF13874.7040203@redhat.com> Message-ID: <4EF20434.6090501@redhat.com> On 12/21/2011 02:37 AM, Endi Sukma Dewata wrote: > On 12/20/2011 7:16 PM, Endi Sukma Dewata wrote: >> The JSON server has been modified to return the principal name >> in all responses. The UI has been modified to keep the principal >> obtained during whoami operation and check the principal returned >> in subsequent operations. If the principal changes the UI will >> reload itself. >> >> Ticket #1400 > > New patch to fix infinite reload problem with test fixtures. > ACK -- Petr Vobornik From jcholast at redhat.com Wed Dec 21 16:43:05 2011 From: jcholast at redhat.com (Jan Cholasta) Date: Wed, 21 Dec 2011 17:43:05 +0100 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <4EF1DFFC.4060905@redhat.com> References: <4E96B5AB.4030800@redhat.com> <4E970565.6040009@redhat.com> <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> <4ED8E717.7050302@redhat.com> <4ED8E859.1050407@redhat.com> <20111202202631.GA29560@redhat.com> <4EF1DFFC.4060905@redhat.com> Message-ID: <4EF20C99.3040502@redhat.com> Dne 21.12.2011 14:32, Jan Cholasta napsal(a): > Dne 2.12.2011 21:26, Alexander Bokovoy napsal(a): >> On Fri, 02 Dec 2011, Jan Cholasta wrote: >>>>> I don't like the idea of introducing a new class every time we need a >>>>> ReadOnly attribute to be writable. There's quite a few places in the >>>>> code where we do object.__setattr__ on ReadOnly objects. IMO the right >>>>> thing to do would be to add means of whitelisting ReadOnly attributes >>>>> that need to stay writable after locking. >>>>> >>>>>> >>>>>> You can move those _select_ca(), _select_any_master(), >>>>>> _host_has_service() to CaCache as they seem to not depend on anything >>>>>> in class ca but rather use global api.env. >>>>>> >>>>>> This way you will get is a fairly simple CaCache class reusable both >>>>>> in ca and ra classes. >>>>> >>>>> Honza >>>>> >>>> >>>> What is the status of this patch? >>>> >>>> rob >>> >>> It fixes the issue and I wouldn't mind leaving it as it is. >>> >>> Alexander? >> >> I still don't like it. There is nothing in CA that really requires >> enabling writting to ReadOnly after locking. ReadOnly is a fundamental >> promise of our API and breaking it should be possible only for cases >> where any other approach will be ineffective. This particular case is >> rather poor implementation of CA/RA classes that could be solved in a >> simpler way. >> >> Sometimes you need to hold promises. ;) >> > > Updated and rebased the patch. > > Added a class for creating property-like attributes that cache the > return value of a function call. > > Fixed some more unit test issues that popped up since I first made the > patch. > > Note that some tests are still failing, most of the failures seem to be > related to user private groups (see attached log). > > Honza > Fixed cachedproperty so that the return value is cached per-instance instead of per-class. Updated patch attached. Honza -- Jan Cholasta -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-jcholast-54.3-fix-read-only-write.patch Type: text/x-patch Size: 9382 bytes Desc: not available URL: From jdennis at redhat.com Wed Dec 21 19:07:57 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 21 Dec 2011 14:07:57 -0500 Subject: [Freeipa-devel] session authentication URI issues Message-ID: <4EF22E8D.3070405@redhat.com> For your holiday reading pleasure :-) Happy holidays to all. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: session_krb.txt URL: From edewata at redhat.com Wed Dec 21 19:21:42 2011 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 21 Dec 2011 13:21:42 -0600 Subject: [Freeipa-devel] [PATCH] 060 Parsing of IPv4 and IPv6 addresses In-Reply-To: <4EF1E42D.2020406@redhat.com> References: <4EEF5BE7.4040002@redhat.com> <4EEF627E.6050402@redhat.com> <4EF048BB.3010303@redhat.com> <4EF0F6C4.8020106@redhat.com> <4EF1E42D.2020406@redhat.com> Message-ID: <4EF231C6.4000501@redhat.com> On 12/21/2011 7:50 AM, Petr Vobornik wrote: > Added > Added, but I don't see a usage for this. > Added some tests to show the usages. > Added > Added > Changed. Test are still called ip_tests - I wouldn't put there any new > non-ip-address related. > For convenience I also attached a 'diff' patch. ACK. Pushed to master. -- Endi S. Dewata From abokovoy at redhat.com Wed Dec 21 20:49:54 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 21 Dec 2011 22:49:54 +0200 Subject: [Freeipa-devel] [PATCH] 54 Fix attempted write to attribute of read-only object In-Reply-To: <4EF20C99.3040502@redhat.com> References: <4E96B5AB.4030800@redhat.com> <4E970565.6040009@redhat.com> <4E97EC5B.90309@redhat.com> <20111014081859.GB8783@redhat.com> <4EAFE5D2.4010607@redhat.com> <4ED8E717.7050302@redhat.com> <4ED8E859.1050407@redhat.com> <20111202202631.GA29560@redhat.com> <4EF1DFFC.4060905@redhat.com> <4EF20C99.3040502@redhat.com> Message-ID: <20111221204954.GH31934@redhat.com> On Wed, 21 Dec 2011, Jan Cholasta wrote: > > Fixed cachedproperty so that the return value is cached per-instance > instead of per-class. > > Updated patch attached. Works for me, thanks. Could you please do a favor and use the decorator syntax as suggested by the documentation of cachedproperty class? > @@ -1218,7 +1219,6 @@ class ra(rabase.rabase): > self.ipa_key_size = "2048" > self.ipa_certificate_nickname = "ipaCert" > self.ca_certificate_nickname = "caCert" > - self.ca_host = None > try: > f = open(self.pwd_file, "r") > self.password = f.readline().strip() > @@ -1283,6 +1283,7 @@ class ra(rabase.rabase): > return host > else: > return api.env.ca_host Instead of > + ca_host = cachedproperty(_select_ca) rather have @cachedproperty def ca_host(self): where ca_host() is _select_ca(). Decorators are supported by Python 2.4. -- / Alexander Bokovoy From lars at radicore.se Wed Dec 21 21:54:05 2011 From: lars at radicore.se (=?ISO-8859-1?Q?Lars_Sj=F6str=F6m?=) Date: Wed, 21 Dec 2011 22:54:05 +0100 Subject: [Freeipa-devel] dns_discovery_domain for clients outside server domain Message-ID: Hello, I have prepared a patch for https://fedorahosted.org/freeipa/ticket/2209 Feedback appreciated. Best regards, Lars -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-add-disovery-domain-if-client-domain-is-different-fr.patch Type: text/x-patch Size: 1968 bytes Desc: not available URL: From sgallagh at redhat.com Thu Dec 22 15:29:35 2011 From: sgallagh at redhat.com (Stephen Gallagher) Date: Thu, 22 Dec 2011 10:29:35 -0500 Subject: [Freeipa-devel] session authentication URI issues In-Reply-To: <4EF22E8D.3070405@redhat.com> References: <4EF22E8D.3070405@redhat.com> Message-ID: <1324567775.2192.15.camel@sgallagh520.sgallagh.bos.redhat.com> On Wed, 2011-12-21 at 14:07 -0500, John Dennis wrote: > For your holiday reading pleasure :-) Happy holidays to all. > Ok, I want to try to restate the problem so that I'm sure I understand it. The way the session management is going to work is that the Apache server/FreeIPA application is going to kinit and get credentials on our behalf and store them in a session cache and provide us with a secure cookie. As long as we have that cookie, we have an access-key to the credential cache and apache can then use that to perform RPC requests in our name. When we connect via the CLI, we already have valid kerberos credentials, and we want to simply delegate those instead, so the Apache server doesn't need to maintain a session. What if we were to mandate that the FreeIPA server always allows issuing a TGT with a renewal time of no less than the TGT time? Then it would be possible to initiate a session by presenting our existing TGT to perform a renewal request on the apache server, which could then be cached into the session. We could then just use the session interface from then on, even in the CLI/libcurl. Is this doable? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Thu Dec 22 17:09:11 2011 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 22 Dec 2011 10:09:11 -0700 Subject: [Freeipa-devel] [PATCH] Fix slapi plugins build In-Reply-To: <1324403736.28622.123.camel@willson.li.ssimo.org> References: <1324403178.28622.121.camel@willson.li.ssimo.org> <1324403736.28622.123.camel@willson.li.ssimo.org> Message-ID: <4EF36437.3060205@redhat.com> On 12/20/2011 10:55 AM, Simo Sorce wrote: > On Tue, 2011-12-20 at 12:46 -0500, Simo Sorce wrote: >> This patch is needed to fix the slapi plugins to build against the >> thread-safe (reentrant) version of openldap libraries. >> >> I haven't changed ipa-clients because they are not threaded programs and >> wanted to restrict the change as much as possible. >> >> Fixes #2198. >> >> The same patch can be cherry-picked against both 2.1.x and master. > I actually created 2 new patches (one for 2-1 and one for master) where > I also change the spec file so that freeipa packages depend on the new > 389ds package that uses the ldap_r library as both 389ds and plugins > must be build with the same libraries. ack > Simo. > > > > _______________________________________________ > 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: From abokovoy at redhat.com Thu Dec 22 19:12:07 2011 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 22 Dec 2011 21:12:07 +0200 Subject: [Freeipa-devel] [PATCH] Fix slapi plugins build In-Reply-To: <4EF36437.3060205@redhat.com> References: <1324403178.28622.121.camel@willson.li.ssimo.org> <1324403736.28622.123.camel@willson.li.ssimo.org> <4EF36437.3060205@redhat.com> Message-ID: <20111222191207.GA20629@redhat.com> On Thu, 22 Dec 2011, Rich Megginson wrote: > On 12/20/2011 10:55 AM, Simo Sorce wrote: > >On Tue, 2011-12-20 at 12:46 -0500, Simo Sorce wrote: > >>This patch is needed to fix the slapi plugins to build against the > >>thread-safe (reentrant) version of openldap libraries. > >> > >>I haven't changed ipa-clients because they are not threaded programs and > >>wanted to restrict the change as much as possible. > >> > >>Fixes #2198. > >> > >>The same patch can be cherry-picked against both 2.1.x and master. > >I actually created 2 new patches (one for 2-1 and one for master) where > >I also change the spec file so that freeipa packages depend on the new > >389ds package that uses the ldap_r library as both 389ds and plugins > >must be build with the same libraries. > ack I've pushed it to Fedora 15, 16, and Rawhide. Fedora 16: https://admin.fedoraproject.org/updates/slapi-nis-0.28-1.fc16,freeipa-2.1.4-3.fc16,389-ds-base-1.2.10-0.6.a6.fc16 Fedora 15: https://admin.fedoraproject.org/updates/389-ds-base-1.2.10-0.6.a6.fc15,slapi-nis-0.28-1.fc15,freeipa-2.1.4-2.fc15 I'll do upstream push shortly. -- / Alexander Bokovoy From simo at redhat.com Thu Dec 22 20:06:29 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Dec 2011 15:06:29 -0500 Subject: [Freeipa-devel] session authentication URI issues In-Reply-To: <1324567775.2192.15.camel@sgallagh520.sgallagh.bos.redhat.com> References: <4EF22E8D.3070405@redhat.com> <1324567775.2192.15.camel@sgallagh520.sgallagh.bos.redhat.com> Message-ID: <1324584389.28622.178.camel@willson.li.ssimo.org> On Thu, 2011-12-22 at 10:29 -0500, Stephen Gallagher wrote: > On Wed, 2011-12-21 at 14:07 -0500, John Dennis wrote: > > For your holiday reading pleasure :-) Happy holidays to all. > > > > Ok, I want to try to restate the problem so that I'm sure I understand > it. > > The way the session management is going to work is that the Apache > server/FreeIPA application is going to kinit and get credentials on our > behalf and store them in a session cache and provide us with a secure > cookie. No. What you describe is the fallback mode used exclusively if you do not already have credentials and are redirected to a form based authentication page. In the normal case we use s4u2proxy to get a ticket on your behalf to the ldap server. We then store the whole credential cache in the session. > As long as we have that cookie, we have an access-key to the > credential cache and apache can then use that to perform RPC requests in > our name. Yes. > When we connect via the CLI, we already have valid kerberos credentials, > and we want to simply delegate those instead, so the Apache server > doesn't need to maintain a session. No. We want to use the same methods in the long term with the trick of storing the session cookie in the local cred cache so that CLI utils know where to find them. (We can also use a .ipa-cli file or the kernel keyring or something similar, we'll choose the most convenient compromise between reliability or security). However in the first implementation we can skip handling this for the CLI. > What if we were to mandate that the FreeIPA server always allows issuing > a TGT with a renewal time of no less than the TGT time? Then it would be > possible to initiate a session by presenting our existing TGT to perform > a renewal request on the apache server, which could then be cached into > the session. We could then just use the session interface from then on, > even in the CLI/libcurl. We do not want to give a TGT to the framwork. > Is this doable? Yes but undesirable, and also unnecessary. Simo. -- Simo Sorce * Red Hat, Inc * New York From ayoung at redhat.com Thu Dec 22 22:37:09 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 22 Dec 2011 17:37:09 -0500 Subject: [Freeipa-devel] session authentication URI issues In-Reply-To: <4EF22E8D.3070405@redhat.com> References: <4EF22E8D.3070405@redhat.com> Message-ID: <4EF3B115.3050308@redhat.com> On 12/21/2011 02:07 PM, John Dennis wrote: > For your holiday reading pleasure :-) Happy holidays to all. > > > > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel To answer a couple questions are almost certainly going to come up: When we first started discussing this a long while back, I looked in to what I still feel is the right long term solution, but whifch is not currently an option for release reasons. The most unified approach would extend mod_auth_krb to perform the caching of the credentials. A set of files that are Kerberos protected could have an additional specification that would stick the Credential in the session. This requires mod_auth_krb to know about mod_session. Unfortunately, due the versions of Apache and how we configure it, that does not work for IPA. Back porting mod_session to the version of Apache shipped with RHEL 6 is a non trivial undertaking. The IPA server runs with Apache in pre-fork mode, which means that each request is handled by a different process. Thus sessions, which depend on shared state, become a much heavier-weight proposal. In the future I would like to revisit this issue and attempt to integrate the change into mod_auth_krb. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoung at redhat.com Fri Dec 23 03:36:49 2011 From: ayoung at redhat.com (Adam Young) Date: Thu, 22 Dec 2011 22:36:49 -0500 Subject: [Freeipa-devel] [PATCH] 0294 remove delegation from browser config In-Reply-To: <1324480718.28622.149.camel@willson.li.ssimo.org> References: <4EF0F8DD.5010503@redhat.com> <4EF1F468.6060800@redhat.com> <20111221151607.GG31934@redhat.com> <1324480718.28622.149.camel@willson.li.ssimo.org> Message-ID: <4EF3F751.4000209@redhat.com> On 12/21/2011 10:18 AM, Simo Sorce wrote: > On Wed, 2011-12-21 at 17:16 +0200, Alexander Bokovoy wrote: >> On Wed, 21 Dec 2011, Petr Vobornik wrote: >> >>> On 12/20/2011 10:06 PM, Adam Young wrote: >>>> Hold this patch until all of the S4U2 code is pushed, otherwise it will >>>> break the WebUI >>>> >>> assuming it is this ticket: https://fedorahosted.org/freeipa/ticket/2207 >>> >>> 1) why is there a services.py file ? >> Should be ignored. It is generated file. > Adam can you rebase without the services.py file ? > > Simo. > Done. I added an additional patch that adds the services file to .gitignore -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0294-1-Remove-delegation-from-browser-config.patch Type: text/x-patch Size: 957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-admiyo-0295-ignore-generated-services-file.patch Type: text/x-patch Size: 564 bytes Desc: not available URL: From simo at redhat.com Thu Dec 22 20:25:10 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Dec 2011 15:25:10 -0500 Subject: [Freeipa-devel] session authentication URI issues In-Reply-To: <4EF22E8D.3070405@redhat.com> References: <4EF22E8D.3070405@redhat.com> Message-ID: <1324585510.28622.196.camel@willson.li.ssimo.org> On Wed, 2011-12-21 at 14:07 -0500, John Dennis wrote: > Introduction > ============ > > On our last conference call I explained there were some lingering > issues on our proposed session based authentication. It was hard to > summarize the issues in a few sentences so I promised a write-up, here > it is. > > In addition to reviewing the issues below I will point out I am not an > Apache guru, therefore it is possible I may have drawn an incorrect > conclusion or failed to see a possible solution that an Apache expert > would be aware of, please keep that in mind as you read the material > and offer constructive corrections where appropriate. Of course > general comments/questions are sought and welcomed. > > > Overview > ======== > > This describes how we currently authenticate and how we plan to > improve authentication performance. First some definitions. > > There are 4 major players: > > 1. client > 2. mod_auth_kerb (in Apache process) > 3. wsgi handler (in IPA wsgi python process) > 4. ds (directory server) You have a major flaw right here. We have 2 kind of clients. The WebUI and the CLI commands. The WebUI uses /ipa/ui and /ipa/json The CLI uses only /ipa/xmlrpc In your whole discussion below you should rethink /ipa/rpc as /ipa/json because it looks to me you are only considering the WebUI client (that's just fine). > There are several resources: > > 1. /ipa/ui (unprotected) > 2. /ipa/xmlrpc (protected) > 3. /ipa/json (protected) > 4. ds (protected, wsgi acts as proxy) > > Both /ipa/xmlrpc and /ipa/json are RPC URI's and are dispatched by our > wsgi handler, both are nearly identical for this discussion so to > simplify the discussion let's just use /ipa/rpc to mean any protected > RPC resource. > > Current Model > ============= > > This describes how things work in our current system. > > 1. Client requests /ipa/ui, this is unprotected, is static and > contains no sensitive information. Apache replies with html and > javascript. The javascript requests /ipa/rpc. > > 2. Client sends post to /ipa/rpc. > > 3. mod_auth_kerb is configured to protect /ipa/rpc, replies 401 > authenticate negotiate. > > 4. Client resends with credentials > > 5. mod_auth_kerb validates credentials > > a. if invalid replies 403 access denied (stops here) > > b. if valid creates temporary ccache, adds KRB5CCNAME to request > headers > > 6. Request passed to wsgi handler > > a. validates request, KRB5CCNAME must be present, referrer, etc. > > b. ccache saved and used to bind to ds > > c. routes to specified RPC handler. > > 7. wsgi handler replies to client > > Proposed new session based optimization > ======================================= > > The round trip negotiate and credential validation in steps 3,4,5 is > expensive. This can be avoided if we can cache the client > credentials. With client sessions we can store the client credentials > in the session bound to the client. > > A few notes about the session implementation. > > * based on session cookies, cookies must be enabled > > * session cookie is secure, only passed on secure connections, only > passed to our URL resource, never visible to client javascript > etc. > > * session cookie has a session id which is used by wsgi handler to > retrieve client session data from shared multi-process cache. > > Changes to Apache's resource protection > --------------------------------------- > > * /ipa/rpc is no longer protected by mod_auth_kerb. This is > necessary to avoid the negotiate expense in steps 3,4,5 > above. Instead the /ipa/rpc resource will be protected in our wsgi > handler via the session cookie. > > * A new protected URI is introduced, /ipa/login. This resource > does no serve any data, it is used exclusively for authentication. > > The new sequence is: > > 1. Client requests /ipa/ui, this is unprotected. Apache replies with > html and javascript. The javascript requests /ipa/rpc. > > 2. Client sends post to /ipa/rpc, which is unprotected. > > 3. wsgi handler obtains session data from session cookie. > > a. if ccache is present in session data and is valid > > - request is further validated > > - ccache is established for bind to ds > > - request is routed to RPC handler > > - wsgi handler eventually replies to client > > b. if ccache is not present or not valid processing continues ... > > 4. wsgi handler sends temporary redirect to protected /ipa/login > > 5. client sends request to /ipa/login > > 6. mod_auth_kerb replies 401 negotiate on /ipa/login > > 7. client sends credentials to /ipa/login > > 8. mod_auth_kerb validates credentials > > a. if valid > > - mod_auth_kerb permits access to /ipa/login. wsgi handler is > invoked and does the following: > > * establishes session for client > > * retrieves the ccache from KRB5CCNAME and stores it > > * sends temporary redirect back to /ipa/ui. > > a. if invalid > > - mod_auth_kerb sends 403 access denied (processing stops) > > 9. client now requests /ipa/ipc again due to redirect from step 8 > and includes session cookie. Processing repeats starting at step > 3 and since the session data now contains a valid ccache step 3a > executes, a successful reply is sent to client. > > Note: Web clients can start at the /ipa/login URI or the /ipa/ui URI, > either one will work the same. All fine so far. > Problems to be solved > ===================== > > We have added one new URI, /ipa/login which is essentially > invisible. For web clients with cookies enabled nothing has changed > other than better performance. However if cookies are disabled or if > web clients such as curl or our command line tools are used to access > the /ipa/rpc resource a problem occurs. Only because you conflated /ipa/json and /ipa/xmlrpc, treat them as separate things and it will be easier. > The /ipa/rpc resource is no longer protected by Kerberos, it's > protected > by session data, access can only be granted by exchanging session data > obtained through a sequence of request/reply interactions that need to > follow redirects. We can leave /ipa/xmlrpc mod_auth_kerb protected (while /ipa/json will be unprotected) if we are not ready to make changes to the CLI tools. > Ideally we would like access to the /ipa/rpc resource to be > transparently accessible no matter if you're using sessions or > straight Kerberos authentication. But this is impossible. Why? > > The key to understanding the problem is the location where the various > steps occur are distinct and do not interact with one another. Rather > it is a series of linear sequential steps with no branching > control. Let's examine this in more detail. > > 1. mod_auth_kerb protection is on a file system resource, not a web > URI. This is because many URI's may map to a file system resource > (uniquely identified by a URL). > > 2. authentication in Apache occurs after any translations on the > incoming URI, thus aliases and rewrites are fully processed to > obtain a file system resource. > > 3. Once a file system resource is determined Apache then asks the > question is this file system resource protected, and if so checks > access and deny rules and invokes authentication. > > 4. The application of authentication to a file system resource is > never conditional, the authentication requirement is established > when Apache initializes and configures itself. The resource is > either protected or it's not, period. > > 5. If our wsgi handler file system resource is protected by > mod_auth_kerb and we only will be invoked after the entire > negotiate process has been completed and succeeds. Thus any logic > in our wsgi handler cannot influence the authentication performed > by mod_auth_kerb because our wsgi handler handler runs only after > the entire mod_auth_kerb authentication has succeeded. > > Point 5 above is critical to understand, the /ipa/rpc resource is > either Kerberos protected or it's not. You can't have the situation > where /ipa/rpc is not Kerberos protected if a valid ccache is in the > session data but is Kerberos protected otherwise. Can we have a symlink and have /ipa/json point to the actual wsgi resource and /ipa/xmlrpc point to the symlink ? Would this allow mod_auth_kerb to be configured in different ways for the 2 ? If not we'll have to change our CLI tools at the same time we make the session work. Is there a problem for curl to follow redirects ? > Can we just have non session based clients point to /ipa/login? > --------------------------------------------------------------- > > At the moment this is not clear to me. The role of /ipa/login is to > obtain credentials and store them in a client session cache and then > redirect back the UI. > > If we want /ipa/login to process RPC requests instead of setting up > session data and redirecting then /ipa/login needs to know whether the > request was the result of a failed authentication redirect or as an > original request. It's possible there may be information in the > request header (such as a referer) that could be used to distinguish > between the two cases and to take conditional action (note this is > occurring in the wsgi handler). > > But what's the point? It's no longer transparently the same /ipa/rpc > URI. The client need to know to use a different URI to access the RPC > interface. It can't be the /ipa/rpc URI because of point 5 above. > > Can mod_rewrite determine which authentication to use? > ------------------------------------------------------ > > Is it possible to utilize mod_rewrite to examine the incoming request > and direct it to either a Kerberos protected resource or a session > protected resource depending on the contents of the request? > > Doubtful. To decide which authentication to perform it is necessary to > know if a session cookie is available. mod_rewrite give you access to > the request headers but very limited abilty to parse them, it could be > difficult to robustly inspect the cookie header components and > conditionally operate on them. > > mod_rewrite also has the abilility to call out to an external process, > but it appears as only the URI is passed, not full information about > the request, such as the headers. > > It might be possible to construct something with mod_rewrite but it's > not immediately obvious it can be done or be done robustly. Maybe this > should be investigated further (any mod_rewrite gurus want to chime > in?). > > A possible simple solution > -------------------------- > > Since a non session based client *must* know to use a different URI > why overload the /ipa/login URI? > > We would establish another URI specifically for Kerberos protected RPC > resources, for example /ipa/krb/rpc. This would be used by curl and/or > our command line tools exactly like /ipa/rpc is used today. The only > change is a different URI. Why can't we just keep /ipa/xmlrpc ? Why do you mix /ipa/json and /ipa/xmlrpc and call them the same and then propose to split them when they are separate from the start ? > For web browsers the javascript would decide which RPC URI to use > depending on whether cookies are enabled or not. For cookie enabled > browsers /ipa/rpc would be used, when cookies are disabled > /ipa/krb/rpc would be used instead. > We can have different URIs once we change the CLI, to maintain compatibility with old tools. But it would be the other way around. /ipa/xmlrpc would be krb protected by default and then we add /ipa/session/xmlrpc which is instead the session base one. Please let me know what I am missing :) Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Dec 23 03:43:00 2011 From: simo at redhat.com (Simo Sorce) Date: Thu, 22 Dec 2011 22:43:00 -0500 Subject: [Freeipa-devel] [PATCH] 0294 remove delegation from browser config In-Reply-To: <4EF3F751.4000209@redhat.com> References: <4EF0F8DD.5010503@redhat.com> <4EF1F468.6060800@redhat.com> <20111221151607.GG31934@redhat.com> <1324480718.28622.149.camel@willson.li.ssimo.org> <4EF3F751.4000209@redhat.com> Message-ID: <1324611780.28622.197.camel@willson.li.ssimo.org> On Thu, 2011-12-22 at 22:36 -0500, Adam Young wrote: > On 12/21/2011 10:18 AM, Simo Sorce wrote: > > On Wed, 2011-12-21 at 17:16 +0200, Alexander Bokovoy wrote: > >> On Wed, 21 Dec 2011, Petr Vobornik wrote: > >> > >>> On 12/20/2011 10:06 PM, Adam Young wrote: > >>>> Hold this patch until all of the S4U2 code is pushed, otherwise it will > >>>> break the WebUI > >>>> > >>> assuming it is this ticket: https://fedorahosted.org/freeipa/ticket/2207 > >>> > >>> 1) why is there a services.py file ? > >> Should be ignored. It is generated file. > > Adam can you rebase without the services.py file ? > > > > Simo. > > > Done. I added an additional patch that adds the services file to .gitignore Excellent. Simo. -- Simo Sorce * Red Hat, Inc * New York From jdennis at redhat.com Wed Dec 28 18:02:50 2011 From: jdennis at redhat.com (John Dennis) Date: Wed, 28 Dec 2011 13:02:50 -0500 Subject: [Freeipa-devel] session authentication URI issues In-Reply-To: <1324585510.28622.196.camel@willson.li.ssimo.org> References: <4EF22E8D.3070405@redhat.com> <1324585510.28622.196.camel@willson.li.ssimo.org> Message-ID: <4EFB59CA.5010305@redhat.com> On 12/22/2011 03:25 PM, Simo Sorce wrote: > The WebUI uses /ipa/ui and /ipa/json The CLI uses only /ipa/xmlrpc > > In your whole discussion below you should rethink /ipa/rpc as > /ipa/json because it looks to me you are only considering the WebUI > client (that's just fine). Only because you conflated /ipa/json and > /ipa/xmlrpc, treat them as separate things and it will be easier. > Why can't we just keep /ipa/xmlrpc ? Why do you mix /ipa/json and > /ipa/xmlrpc and call them the same and then propose to split them > when they are separate from the start ? Sometimes you get too close to what you're working on and can't see the forest for the trees. Thank you for pointing out how /ipa/json and /ipa/xml are used exclusively and independently by the web UI and the command line tools respectively. How did I get confused? Those two URI's are treated identically in the existing code base, entry into the system via /ipa/json and /ipa/xml traverse the exact same code paths and hence I incorrectly conflated them. Sometimes it takes a second pair of eyes to see the obvious, thus this discussion was useful, thank you. I have recoded the logic in ipaserver/rpcserver.py to separate the two cases. I also had to refactor some of the logic surrounding when and where backend connections with their credentials are managed. The good news is both the web UI and the command line clients seem to be working fine with the new session based authentication. I have some clean-up work to do on the code before I prepare a patch for review. In particular I would like to do a better job of storing and setting the kerberos credentials than what I'm currently doing (currently more proof-of-concept than deployable robust code). > We can have different URIs once we change the CLI, to maintain > compatibility with old tools. But it would be the other way around. > /ipa/xmlrpc would be krb protected by default and then we add > /ipa/session/xmlrpc which is instead the session base one. Yes, once we implement session support in the command line clients we'll need a new URI (e.g /ipa/session/xmlrpc). I don't see anyway around that, but given the functionality is new that won't be an issue, everything remains backwards compatible. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Thu Dec 29 03:14:30 2011 From: simo at redhat.com (Simo Sorce) Date: Wed, 28 Dec 2011 22:14:30 -0500 Subject: [Freeipa-devel] session authentication URI issues In-Reply-To: <4EFB59CA.5010305@redhat.com> References: <4EF22E8D.3070405@redhat.com> <1324585510.28622.196.camel@willson.li.ssimo.org> <4EFB59CA.5010305@redhat.com> Message-ID: <1325128470.2664.9.camel@willson.li.ssimo.org> On Wed, 2011-12-28 at 13:02 -0500, John Dennis wrote: > On 12/22/2011 03:25 PM, Simo Sorce wrote: > > The WebUI uses /ipa/ui and /ipa/json The CLI uses only /ipa/xmlrpc > > > > In your whole discussion below you should rethink /ipa/rpc as > > /ipa/json because it looks to me you are only considering the WebUI > > client (that's just fine). Only because you conflated /ipa/json and > > /ipa/xmlrpc, treat them as separate things and it will be easier. > > > Why can't we just keep /ipa/xmlrpc ? Why do you mix /ipa/json and > > /ipa/xmlrpc and call them the same and then propose to split them > > when they are separate from the start ? > > Sometimes you get too close to what you're working on and can't see the > forest for the trees. Thank you for pointing out how /ipa/json and > /ipa/xml are used exclusively and independently by the web UI and the > command line tools respectively. How did I get confused? Those two URI's > are treated identically in the existing code base, entry into the system > via /ipa/json and /ipa/xml traverse the exact same code paths and hence > I incorrectly conflated them. Sometimes it takes a second pair of eyes > to see the obvious, thus this discussion was useful, thank you. > > I have recoded the logic in ipaserver/rpcserver.py to separate the two > cases. I also had to refactor some of the logic surrounding when and > where backend connections with their credentials are managed. > > The good news is both the web UI and the command line clients seem to be > working fine with the new session based authentication. > > I have some clean-up work to do on the code before I prepare a patch for > review. In particular I would like to do a better job of storing and > setting the kerberos credentials than what I'm currently doing > (currently more proof-of-concept than deployable robust code). Great news! Glad it was just a misunderstanding and not a hard to manage issue. > > We can have different URIs once we change the CLI, to maintain > > compatibility with old tools. But it would be the other way around. > > /ipa/xmlrpc would be krb protected by default and then we add > > /ipa/session/xmlrpc which is instead the session base one. > > Yes, once we implement session support in the command line clients we'll > need a new URI (e.g /ipa/session/xmlrpc). I don't see anyway around > that, but given the functionality is new that won't be an issue, > everything remains backwards compatible. Yup, everything sounds nice and workable, thank you John. Simo. -- Simo Sorce * Red Hat, Inc * New York From jfenal at gmail.com Sat Dec 31 09:15:07 2011 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 31 Dec 2011 10:15:07 +0100 Subject: [Freeipa-devel] [PATCH] fix typo in ipalib/plugins/role.py Message-ID: diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py index bdca3ec..d01791b 100644 --- a/ipalib/plugins/role.py +++ b/ipalib/plugins/role.py @@ -45,7 +45,7 @@ EXAMPLES: Add some privileges to this role: ipa role-add-privilege --privileges=addusers junioradmin ipa role-add-privilege --privileges=change_password junioradmin - ipa role-add-privilege --privileges=add_user_to_default_group juioradmin + ipa role-add-privilege --privileges=add_user_to_default_group junioradmin Add a group of users to this role: ipa group-add --desc="User admins" useradmins -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 00-freeipa-type-role_py.patch Type: text/x-patch Size: 586 bytes Desc: not available URL: From jfenal at gmail.com Sat Dec 31 09:36:38 2011 From: jfenal at gmail.com (=?UTF-8?B?SsOpcsO0bWUgRmVuYWw=?=) Date: Sat, 31 Dec 2011 10:36:38 +0100 Subject: [Freeipa-devel] [PATCH] fix typo in ipalib/plugins/role.py (2) Message-ID: diff --git a/ipalib/plugins/role.py b/ipalib/plugins/role.py --- a/ipalib/plugins/role.py +++ b/ipalib/plugins/role.py @@ -54,7 +54,7 @@ EXAMPLES: Display information about a role: ipa role-show junioradmin - The result of this is that any users in the group 'useradmins' can + The result of this is that any users in the group 'junioradmin' can add users, reset passwords or add a user to the default IPA user group. """) -- J?r?me Fenal - jfenal AT gmail.com - http://fenal.org/ Paris.pm - http://paris.mongueurs.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-freeipa-type-role_py.patch Type: text/x-patch Size: 436 bytes Desc: not available URL: