Re: [Freeipa-devel] terminology: "main/primary/? DNS domain" for FreeIPA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/08/2015 09:34 AM, Petr Spacek wrote: > Hello list, > > I'm in process of reviewing and fixing some of our docs and it > seems that we do not have established term for The Domain user > specified during ipa-server-install. > > Term "DNS domain" is not specific enough because FreeIPA can manage > multiple DNS domains but only one of them contains SRV records. > Term "IdM domain" sounds too vague for the same reasons. > > What about "primary DNS domain"? Or "primary IdM domain"? > > What term is used in AD world? My google-fu is weak on this. > > Ideas are more than welcome! > In active directory, they use the term "Forest" to describe a top-level domain. The first domain created always has the same name as the forest (so: e.g. example.com). When adding new servers, you are given the option of adding a new domain to an existing forest (which then becomes subdomain.example.com) or creating a new forest. (Or creating a replica server of an existing domain, of course). -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEYEARECAAYFAlYWhYgACgkQeiVVYja6o6PVsACfV+AUb7TiBFiEaQBI4M0pS8cD 4KYAn2eajHx9K8JsMDc8R4Yjv8s4jHrp =Pil0 -END PGP SIGNATURE- -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] ipa-devel repos on jdennis.fedorapeople.org
On Thu, 2015-08-27 at 08:20 -0400, John Dennis wrote: > On 08/27/2015 04:27 AM, Petr Spacek wrote: > > On 15.7.2015 09:44, Jan Pazdziora wrote: > > > On Tue, Jul 14, 2015 at 12:49:23PM -0400, John Dennis wrote: > > > > On 07/14/2015 12:03 PM, Petr Spacek wrote: > > > > > Hello, > > > > > > > > > > Is anyone using repos > > > > > https://jdennis.fedorapeople.org/ipa-devel/ > > > > > ? > > > > > > > > > > AFAIK nobody in Brno is seriously using it but I'm not sure > > > > > about people > > > > > outside the Brno. > > > > > > > > > > Could we use COPR instead and get out of builder business? > > > > > Upcoming lab > > > > > maintenance window could be a good time to do that. > > > > > > > > I would love to get out of the builder business and I suspect > > > > Nalin would as > > > > well [1]. The question came up in our Monday meeting as well. > > > > Nobody seem to > > > > know if anyone was using these builds and why we weren't using > > > > COPR. The > > > > > > The Fedora infra admins should be able to provide HTTP logs for > > > the > > > repo, if you needs some numbers about potential usage. > > > > That is a good idea! I got logs from Fedora admins and as far as I > > can tell, > > in the last month there were only 7 RPM downloads and nothing else. > > > > The 7 hits I found was for > > /ipa-devel/rhel/6/x86_64/os/sssd-1.13.1- > > 0.20150813T1121Zgit137d5dd.el6.i686.rpm and > > other packages from the same version. > > > > I did not find any hits for IPA packages at all. All the remaining > > traffic > > (except the 7 RPM hits) was from repo data refreshes: > > - 83 % is RHEL 5 repodata > > - 13 % is RHEL 6 repodata > > - remaining ~ 4 % of noise is Fedora repodata > > > > It seems to me that we can get out the builder business completely > > and > > decommission ipa-devel and replace it with COPR. > > > > Do you agree? John? Nathaniel? Stephen? Anyone? :-) > > Yes, I agree. Do we have a cut off date when I can stop the service? > Given that the traffic was so small, it looks likely that only a single person is still using it. Probably safe to just kill it off and wait for that person to ask where to go. signature.asc Description: This is a digitally signed message part -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] [PATCH] Fix license exception
On Fri, 2015-02-20 at 09:34 -0500, Simo Sorce wrote: > During internal conversations it occurred to me we link to OpenSSL > but never provided the proper exception for downstreams. > > Attached patch fixes the problem. > > Simo. > +this exception statement from your version.i If you delete the exception Small typo there "version.i" signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Announcing FreeIPA 4.0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/15/2014 12:16 PM, Nathaniel McCallum wrote: > On Mon, 2014-09-15 at 17:26 +0200, Petr Viktorin wrote: >> On 09/15/2014 04:45 PM, Nathaniel McCallum wrote: >>> FYI, for any Fedora testers out there, we have updated to 4.0.3 >>> in Fedora 21 in part because it substantially reduces the size >>> of the install media for the upcoming Alpha release. If you'd >>> like to test and provide feedback on the packages, the link is >>> here: >>> >>> https://admin.fedoraproject.org/updates/FEDORA-2014-10811 >> >> Actually, this update came too late for the Alpha. It will be >> considered for Beta. >> >> >> Use the updates-testing repo if you want to test FreeIPA in f21 >> Alpha. > > https://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist > > See bug: 1117432. Actually, we need to get that removed from Freeze Exception. The original plan was for python-qrcode and a simple rebuild of FreeIPA to go in. However, FreeIPA has made significant changes (pulling in new 389 and dogtag packages) and it is now too risky to include in the already-very-late-Alpha. It's unfortunate, but that's going to have to go in for Beta. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQXMBAACgkQeiVVYja6o6MdGQCcDGvTVvdZfdYNrClAeZa5eYKL 0KQAn11ahaY2BbA5boyiR4SPwef6HGuv =zHrh -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Change BuildRequires for Java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2014 07:59 AM, Stephen Gallagher wrote: > Requiring a specific version of Java leads to breakages, like the > one happening on nightly builds in Fedora Rawhide right now. We > should use the more generic 'java' BuildRequires instead of the > versioned one. > > > This is breaking my nightly static analysis scans on Rawhide. > > It was pointed out on IRC that we should be using java-headless as well. Updated patch attached. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP0kb0ACgkQeiVVYja6o6PpRQCeMwFoK+Pm1YILMhGqW6gxPF8B f54AmgPufg9fMKo2/l4h3yh5/13S6SHW =lFv4 -END PGP SIGNATURE- >From 660a209df59fec3108466bbf10bdb5f37b17fbaa Mon Sep 17 00:00:00 2001 From: Stephen Gallagher Date: Wed, 20 Aug 2014 07:56:59 -0400 Subject: [PATCH] Change BuildRequires for Java Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. --- freeipa.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6f22bc92f76f2e4bd732a995e392d6845dab27b7..163f2a476bccc4a06e13c3f78e7204755d2b03af 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -65,7 +65,7 @@ BuildRequires: m2crypto BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: libsss_nss_idmap-devel -BuildRequires: java-1.7.0-openjdk +BuildRequires: java-headless BuildRequires: rhino BuildRequires: libverto-devel BuildRequires: systemd -- 2.0.4 0001-Change-BuildRequires-for-Java.patch.sig Description: PGP signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] Change BuildRequires for Java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. This is breaking my nightly static analysis scans on Rawhide. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP0jZoACgkQeiVVYja6o6OyNgCeL/x+CKnGMhuw8tGM/X3xi5Po L+8AoKI14SRizGxPmBpjhuZkxk8uZlLU =l8zE -END PGP SIGNATURE- >From 19bdee103f9db004a3869cffd7ad516bc5661784 Mon Sep 17 00:00:00 2001 From: Stephen Gallagher Date: Wed, 20 Aug 2014 07:56:59 -0400 Subject: [PATCH] Change BuildRequires for Java Requiring a specific version of Java leads to breakages, like the one happening on nightly builds in Fedora Rawhide right now. We should use the more generic 'java' BuildRequires instead of the versioned one. --- freeipa.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/freeipa.spec.in b/freeipa.spec.in index 6f22bc92f76f2e4bd732a995e392d6845dab27b7..47a14f4cfd9ab2e05ba6910cb85d2f34c965a8b5 100644 --- a/freeipa.spec.in +++ b/freeipa.spec.in @@ -65,7 +65,7 @@ BuildRequires: m2crypto BuildRequires: check BuildRequires: libsss_idmap-devel BuildRequires: libsss_nss_idmap-devel -BuildRequires: java-1.7.0-openjdk +BuildRequires: java BuildRequires: rhino BuildRequires: libverto-devel BuildRequires: systemd -- 2.0.4 0001-Change-BuildRequires-for-Java.patch.sig Description: PGP signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] IPA-CLIENT: NSS test needs to check against the domain name
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In situations where the FreeIPA server is configured with different domain and realm values, we will fail to test for the admin account in the ipa-client-install script. With this patch, we will correctly run 'getent passwd admin@DOMAIN' -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIowI8ACgkQeiVVYja6o6ORiwCgnX1uVtWTktYpKdrVxuVTyQjZ WCsAn0ULhTR0TsfcCsEpknVwgkAN0d7F =KpH4 -END PGP SIGNATURE- >From c679c8c00f1ac208c190482f7b46384bb5e5dc3f Mon Sep 17 00:00:00 2001 From: Stephen Gallagher Date: Thu, 5 Sep 2013 13:21:53 -0400 Subject: [PATCH] IPA-CLIENT: NSS test needs to check against the domain name In situations where the FreeIPA server is configured with different domain and realm values, we will fail to test for the admin account in the ipa-client-install script. With this patch, we will correctly run 'getent passwd admin@DOMAIN' --- ipa-client/ipa-install/ipa-client-install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install index 3bfd5a4455c786d638a8ab1984f780dd537a103d..3b35cf1d8b00b82782a4600124aa20d828a37426 100755 --- a/ipa-client/ipa-install/ipa-client-install +++ b/ipa-client/ipa-install/ipa-client-install @@ -2500,7 +2500,7 @@ def install(options, env, fstore, statestore): # Particulary, SSSD might take longer than 6-8 seconds. while n < 10 and not found: try: -ipautil.run(["getent", "passwd", "admin@%s" % cli_realm]) +ipautil.run(["getent", "passwd", "admin@%s" % cli_domain]) found = True except Exception, e: time.sleep(1) -- 1.8.3.1 0001-IPA-CLIENT-NSS-test-needs-to-check-against-the-domai.patch.sig Description: PGP signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Announcing SSSD 1.9.0 beta 3
The SSSD is proud to announce the third of five preview releases of version 1.9 of the System Security Services Daemon. Beta 4 will be released on July 10th and include a new AD provider (wrapping the intricacies of setting up AD, configuring LDAP attributes and Kerberos realm into a simpler set of configuration options) Beta 5 will be released on July 31st and will contain a new tool for "seeding" accounts with a temporary password for sending machines to remotees as well as introducing a concept of primary vs. secondary servers. After Beta 5, no new features will be added to SSSD 1.9.0 and we will focus on stability and our backlog of bugfixes until the final release around September 1st. We will most likely issue a series of release candidate builds prior to that, but these have not yet been scheduled. As always, you can download the latest sources at https://fedorahosted.org/sssd/ == Highlights == * Add a new PAC responder for dealing with cross-realm Kerberos trusts * Terminate idle connections to the NSS and PAM responders * Switch from libunistring to glib2 for unicode support == Tickets Fixed == https://fedorahosted.org/sssd/ticket/1163 [Feature] SSSD AD Integration Feature (Cross Realm Kerberos Trusts) https://fedorahosted.org/sssd/ticket/1354 Add support for terminating idle connections in sssd_nss https://fedorahosted.org/sssd/ticket/1383 sssd_nss segfaults performing netgroup lookups without a specified domain == Detailed Changelog == Jan Zeleny (5): * Fix possible segfault in sdap_save_group() * PAC responder: add some utility functions * PAC responder: test suite * Fix re_expression matching with subdomains * SELinux user maps: pick just one map Shantanu Goel (4): * Set return errno to the value prior to calling close(). * Log message if close() fails in destructor. * Do not send SIGPIPE on disconnection * Add support for terminating idle connections Simo Sorce (2): * Do not leak file descriptors in client libs. * Add close on exec support for old platforms Stef Walter (1): * Move some debug lines to new debug log levels Stephen Gallagher (6): * Bumping version to 1.9.0 beta 3 * Fix typo breaking DIR cache detection * Make the client idle timeout configurable * UTILS: Fix segfault due to sss_parse_name_for_domains * BUILD: Change default unicode library to glib2 * Update translations for 1.9.0 beta 3 release Sumit Bose (11): * PAC responder: add basic infrastructure * PAC responder: add the core functionality * PAC responder: support in spec file * PAC client: add basic support in common client code * PAC client: add krb5 authdata plugin * Add support for ID ranges * Add range support to PAC responder * Try to build PAC responder only if all dependencies are available * Build pac responder tests only if pac responder is build * Add man page section for the PAC responder * Set default for subdomain_homedir signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] Announcing SSSD 1.9.0 beta 2
Ok, I have a bit of egg on my face here. I accidentally pushed a patch related to the Kerberos DIR cache support that had a debugging "#if 0" left in it. Because of this, DIR cache support is actually non-functional in 1.9.0 beta 2. I'm attaching a patch to fix this to this email (already pushed upstream) so anyone who wants to build beta 2 to try out the DIR cache support must apply this patch for it to work. We decided not to reroll the beta for this one patch, since beta 3 is being released on Friday anyway. On Fri, 2012-06-15 at 15:22 -0400, Stephen Gallagher wrote: > The SSSD team is proud to announce the second beta of our upcoming 1.9.0 > release. We have revised our beta plan and will be having five betas > instead of three as originally communicated. Originally, the plan was to > have our next beta be the final one, at the end of July. We now have the > following schedule: > > Beta 3 will be released next Friday (Jun 22nd) or the following Monday > and contain enhancements necessary to support Kerberos cross-realm > trusts with FreeIPA, a server-side piece of which will be released a few > days after. > > Beta 4 will be released on July 10th and include a new AD provider > (wrapping the intricacies of setting up AD, configuring LDAP attributes > and Kerberos realm into a simpler set of configuration options) > > Beta 5 will be released on July 31st and will contain a new tool for > "seeding" accounts with a temporary password for sending machines to > remotees as well as introducing a concept of primary vs. secondary > servers. > > After Beta 5, no new features will be added to SSSD 1.9.0 and we will > focus on stability and our backlog of bugfixes until the final release > around September 1st. We will most likely issue a series of release > candidate builds prior to that, but these have not yet been scheduled. > > As always, you can download the latest sources at > https://fedorahosted.org/sssd/ > > > == Highlights == > * Add support for the Kerberos DIR cache for storing multiple TGTs > automatically > * Major performance enhancement when storing large groups in the cache > * Major performance enhancement when performing initgroups() against > Active Directory > * SSSDConfig data file default locations can now be set during > configure for easier packaging > > == Tickets Fixed == > https://fedorahosted.org/sssd/ticket/974 > [RFE] Support DIR: credential caches for multiple TGT support > > https://fedorahosted.org/sssd/ticket/984 > RFE: sssd should support Netscape LDAP password expiration controls > > https://fedorahosted.org/sssd/ticket/1213 > Warn to syslog when dereference requests fail > > https://fedorahosted.org/sssd/ticket/1240 > sudo: contact data provider only once > > https://fedorahosted.org/sssd/ticket/1255 > RFE: change the way we deal with fake users > > https://fedorahosted.org/sssd/ticket/1256 > Document the expectations about ghost users showing in the lookups > > https://fedorahosted.org/sssd/ticket/1330 > Potential NULL dereference in sss_krb5_read_etypes_for_keytab > > https://fedorahosted.org/sssd/ticket/1336 > Please only use named parameters in translatable strings > > https://fedorahosted.org/sssd/ticket/1337 > Minor typos in SSSD messages and man pages > > https://fedorahosted.org/sssd/ticket/1346 > in-memory cache causes nss to segfault if it cannot be initialized > properly > > https://fedorahosted.org/sssd/ticket/1367 > Optimize AD memberOf lookups with LDAP_MATCHING_RULE_IN_CHAIN > > == Detailed Changelog == > Ariel Barria (3): > * Potential NULL dereference in proxy provider > * Warn to syslog when dereference requests fail > * Clarify how comments work in sssd.conf > > Jakub Hrozek (20): > * NSS: keep a pointer to body after body is reallocated > * Use sized_string correctly in FQDN domains > * Use the sysdb attribute name, not LDAP attribute name > * LDAP nested groups: Do not process callback with _post deep in the > nested structure > * Send 16bit protocol numbers from the sss_client > * Revert the client packet length, too, after reverting the packet > protocol > * Fix the default sssd.conf path > * Fix the 0.11 sysdb upgrade > * sss_names_init: Report correct error code if allocation failed > * Two small krb5_child fixes > * Provide more debugging in krb5_child and ldap_child > * Allow redefining the KRB5_CHILD path > * Split parse_krb5_child_response so it can be reused > * Add a krb5_child test tool > * Residual util functions > * Handle trailing slash in the ccname template > * Add a credential cache back end
[Freeipa-devel] Announcing SSSD 1.9.0 beta 2
mains - ask for information about master domain * Allow fast memcache timeout to be configurable * Fix an issue in ghost users * Provide "service filter" for SELinux context * Fixed debug message in sdap_save_group() Joshua Roys (1): * Simple implementation of Netscape password warning expiration control Nick Guay (1): * added DEBUG messages to krb5_child and ldap_child Stef Walter (1): * Make re_expression and full_name_format per domain options Stephen Gallagher (27): * Bumping version ton 1.8.92 for beta 2 development * RPM: Allow running 'make rpms' on RHEL 5 machines * NSS: Expire in-memory netgroup cache before the nowait timeout * Always use positional arguments in translatable strings * KRB5: Avoid NULL-dereference with empty keytab * Update translation sources * NSS: Fix segfault when mmap cache cannot be initialized * NSS: Restore original protocol for getservbyport * SSSDConfig: Make SSSDConfig a package * SSSDConfig: Make default config and schema file locations configurable * PAM: Better pam_reply message * SYSDB: Reduce noise level of debug messages in lookups * LDAP: Remove redundant check * LDAP: Fix incorrect switch statement in sdap_get_initgr_done() * LDAP: Add helper function to get list of a user's groups from sysdb * LDAP: Make sdap_initgr_common_store() non-static * LDAP: Add ldap_*_use_matching_rule_in_chain options * LDAP: Add support for AD chain matching extension in group lookups * LDAP: Add support for AD chain matching extension in initgroups * LDAP: Auto-detect support for the ldap match rule * LDAP: Fix missing variable in debug message * SSS_CLIENT: Fix uninitialized value error * Fix compilation on older little-endian systems * KRB5: Update DEBUG macros for create_ccache_dir and find_ccdir_parent_data * KRB5: Auto-detect DIR cache support in configure * KRB5: Avoid shadowing dirname * Updating translations for 1.9.0 beta 2 release Sumit Bose (4): * Rename struct dom_sid to struct sss_dom_sid * Fix libsss_hbac library version * sss_idmap: add support for samba struct dom_sid * sss_idmap: fix typo which prevents sub auth larger then 2^31 Yuri Chornoivan (1): * Fix typos in message and man pages. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] About private ssh host keys in IPA
On Fri, 2012-06-01 at 09:24 -0400, Simo Sorce wrote: > This is about Ticket 1978 (originally rhbz746036). > > This RFE asks for storing private SSH Host Keys in FreeIPA. > > We have been triaging this ticket today, and I have to admit I am biased > toward simply closing down the ticket. > > However we want to reach out community and interested parties that > opened the tick to understand if there are reasons strong enough to > consider implementing it. > > The reason I am against this is that in FreeIPA we already provide > public Key integration. This means that when the host is re-installed > new keys are loaded in IPA and clients do not get the obnoxious warning > message that keys have changed, because enrolled clients (with the > appropriate integration bits) trust FreeIPA so they do not need to ask > the user to confirm on a key change. > > Storing Private Keys poses various liability issues, in order to be able > to restore keys you need to give access to those keys to an admin, as > there is no other way to authenticate just the host itself (it was just > blown away and reinstalled). > This means any admin account that can perform reinstalls need to have > access to *read* private keys out of LDAP, which means that > A) The central tenet of Asymetric authentication is that private keys > are 'private'. > B) keys are readable from LDAP to some accounts, any slight error in > ACIs would risk exposing all private keys. > C) most probably low level (junior admin) accounts will have read access > to pretty much all private keys, because those admins are the one tasked > with re-installs. However those admins are also the ones less trusted, > yet by giving them access to private keys they are enabled to perform > MITM attacks against pretty much any of the machines managed by FreeIPA. > > For these reasons I am against storing SSH Private Keys. I would like to > know what are the reasons to instead implement this feature and the > security considerations around those reasons. > >From my point of view the balance between feature vs security issues > trips in disfavor of implementing the feature but I am willing to be > convinced otherwise if there are good reasons to, and security issues > can be properly addressed with some clever scheme. For the record, I am also in favor of just closing the ticket. It's much safer and wiser to require re-provisioning of the public key in the FreeIPA server than it is to try storing the private key. I suspect that when we had the original conversation on IRC, it was before we had decided that FreeIPA would be managing public keys. I am firmly against ever storing host private keys in a central location. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Adding indices and permissions to FreeIPA
On Tue, 2012-05-15 at 15:53 +0200, Petr Viktorin wrote: > On 05/15/2012 03:29 PM, William Brown wrote: > > Hi simo > > > >> Hi William, > >> do you have a public repo you are pushing your work to ? > >> It would be nice to have early access so we can check your > >> implementation is in line with FreeIPA. It will allow your contribution > >> to get in more easily if we can comment early on around schema, DIT and > >> other behavior you need to implement. > > > > I haven't had much time to focus on this so far, So I only have a > > limited amount of work completed. It has mainly been learning the > > FreeIPA code, adding some skeleton files, and working out the schema. > > > > I have tried to push my work to my github from my branch, but I'm > > getting an error on push. > > > > git push github master > > Counting objects: 38943, done. > > Compressing objects: 100% (8100/8100), done. > > error: object 0b36ce6dcbfc8d7e6cda632e06a09c369428a2db:invalid > > author/committer line - bad date > > fatal: Error in object > > error: pack-objects died of signal 13 > > error: failed to push some refs to > > 'g...@github.com:Firstyear/FreeIPA-dhcp.git' > > > > That object appears to be. > > > > commit 0b36ce6dcbfc8d7e6cda632e06a09c369428a2db > > Merge: 451a28c a9e4e5a > > Author: Karl MacMillan > > Date: Thu Jan 1 00:00:00 1970 + > > > > Merge. > > > > Any advice on this issue would be welcome. In the mean time, I'm happy > > to just send in formatted patches. > > Unfortunately, there are some patches in the FreeIPA history that Github > chokes on (most likely the problem is with the zero commit date). Since > Git history is immutable, there's not much we can do now. > > As a workaround, Bitbucket seems to work: > https://bitbucket.org/encukou/freeipa > > > I'll contact Github about this later today. > Another option would be to use a Fedora People repository: http://fedoraproject.org/wiki/Infrastructure/fedorapeople.org#BETA_git_hosting_support The catch is that you need to be a member of at least one group in Fedora besides the FPCA-signed group. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Announcing SSSD 1.9.0 beta 1
ging messages * SSH: Add missing break statements to sss_ssh_format_pubkey * SSH: Use fchmod instead of chmod on known_hosts file * SSH: Replace blocking getaddrinfo call in the responder with asynchronous resolver code * SSH: Remove unused --file option of sss_ssh_knownhostsproxy * SSH: Update sss_ssh_knownhostsproxy manual page * Include missing source files to the list of source files which contain translatable strings * SSH: Allow clients to explicitly specify host alias * SSH: Canonicalize host name and do reverse DNS lookup in sss_ssh_knownhostsproxy * SSH: Fix infinite loop in sss_ssh_knownhostsproxy * UTIL: Add HMAC-SHA-1 function * SSH: Add support for hashed known_hosts Jan Engelhardt (1): * build: resolve link failure Jan Zeleny (34): * Fixed issue with netgroup update in IPA provider * Don't give memory context in confdb where not needed * IPA hosts refactoring * SELinux related attributes added to config API * Delete missing attributes from netgroups to be stored * Modifications to simplify list_missing_attrs * Fix the script path * Fixed uninitialized pointer in SSH known host proxy * Fixed uninitialized pointer in SSH authorized keys client * Add umask before mkstemp() call in SSH responder * Fixed resource leak in ssh client code * Removed a block of dead code in sdap_async_groups.c * Removed unused block of code is sdap_fill_memberships() * Removed unused function sysdb_attrs_users_from_ldb_vals() * Fixed memory context in sdap_fill_memberships() * Fixed minor memory leak in ldap provider * Sysdb routines for subdomains * Add some utility functions for subdomains * Add conn_name to allow different names for domains and connections * Responder part of the subdomain retrieval work * Modified responder_get_domain() * Retrieve subdomains if there is a request for fully qualified user * Ask for subdomains in responder in the first request after startup * New config option for subdomains * Moved expand_homedir_template() from NSS responder to utility code * Add ID operations in subdomains * Send PAM requests for subdomains to the right provider * Basic support for subdomains in auth provider * Carry sysdb context and domain info in be_req structure * Accept be_req instead if be_ctx in LDAP access provider * Detect subdomain request in IPA access provider * Utilize sysdb context within be_req in HBAC * Two fixes in responder subdomain code * Modify behavior of pam_pwd_expiration_warning Marco Pizzoli (1): * Two manual pages fixes Pavel Březina (16): * Improve debug messages in sysdb_sudo_check_time() * SUDO responder: check if the input is a UTF-8 string * Refactor sss_result into sss_sudo_result * Redesign purging of the sudo cache * Honor case_sensitive option in sudo responder * Move sudo_dom_ctx.user to local variable * Hide --debug option in sss_debuglevel * Two memory leaks in sss_sudo_get_values * Missing debug message if sdap_sudo_refresh_set_timer fails * Use of unininitialized value in sudosrv_cache_set_entry and sudosrv_cache_lookup_internal * Use of unininitialized value in sss_sudo_parse_response * Potential NULL-dereference in sudosrv_cmd_get_sudorules * sudo api: check sss_status instead of errnop in sss_sudo_send_recv_generic() * Install and uninstall all documentation * fix copy and paste error in comment * Fix typo in debug message Simo Sorce (11): * nss_group: Cache the result from sssd when the glibc provided buffer is too small. * pam_sss: keep selinux optional * Use the correct hash table for pending requests * util: Helper headers for shared memory cache * nsssrv: shared memory cache server initialization * nsssrv: Add memory cache record handling utils * nsssrv: add handling of memory cache passwd map * sss_client: Add common shared memory cache utils * sss_client: shared memory cache passwd map support * nsssrv: add handling of memory cache group map * sss_client: shared memory cache group map support Stef Walter (6): * Fix erronous reference to the 'allow' access_provider * execv, excvp and exec_child never return EOK * If canon'ing principals, write ccache with updated default principal * Remove erroneous failure message in find_principal_in_keytab * Limit krb5_get_init_creds_keytab() to etypes in keytab * Clearer documentation for use_fully_qualified_names Stephen Gallagher (96): * Set version to 1.9dev * Updating translatable strings for string freeze * Updating translations * Remove dead code * Fix missing NULL check after malloc * Avoid uninitialized value comparison * Add missing breaks to switch statements * Fix uninitialized in_transaction * Fix bad failure handling in be_sudo_handler() * Check for failure in sss_packet_grow() * Fix uninitialized value error in proxy provider * Ensure NULL-termination in get_uid_from_pid() * Move sss_ssh_* binaries to the main 'sssd' package * Always include all manpage XML files in the distribution ta
Re: [Freeipa-devel] samba4 woes
On Fri, 2012-04-20 at 22:27 +0300, Alexander Bokovoy wrote: > :) > > It failed to build due to koji issues, not the build issues. > > We had also incompatible libldb in F16/F15 that prevented us going to > alpha18 instead of alpha16 in those distributions. > > I hope Andreas (CC:) will be able to look at the issue soon... > FWIW, I own libldb, so if you need it updated, I'm your man. Just so you know, rebuilding libldb ALSO forces a rebuild of libtalloc, libtdb, libtevent, SSSD and possibly openchange, so an update like that has to be carefully coordinated. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Announcing SSSD 1.8.0 beta 1
Integration - periodical update of rules in data provider * SUDO Integration - make sysdb_get_sudo_filter() more configurable * SUDO Integration - prepare data provider for new responder commands * SUDO Integration - responder command for cn=defaults * SUDO Integration - SUDO API can request only cn=defaults record * SUDO Integration - test client changed * SUDO Integration - manual page * SUDO Integration - in-memory cache in responder * SUDO Integration - responder 'sudo_timed' option * SUDO Integration - fix offline behaviour * SUDO Integration - sysdb_sudo_check_time() fix Simo Sorce (9): * make dist fixes * tests: fix test group of utf8 tests * nsssrv: remove unused macro * nsssrv: add string manipulation helper * nsssrv: use sized_string in fill_pwent * nsssrv: use sized_string in fill_grent * util: add murmurhash3 hash function * Add a random + identity test for murmurhash3 * util: Fix murmurhash3 on machines with old glibc Stephen Gallagher (46): * Bump version to 1.8.0 * Add compatibility layer for Heimdal Kerberos implementation * Importing new translations for 1.7.0 release * Log fixes for sdap_call_conn_cb * LDAP: Copy URI instead of pointing at failover service record * NSS: Validate input string lengths * NSS: Improve DEBUG messages for netgroup cache * Raise the debug level of two very noisy statements * IPA: Detect nsupdate support for the realm directive * NSS: Add sss_readrep_copy_string * LDAP: Add option to disable paging control * SYSDB: Redundant check is redundant. * Fix invalid index in pidfile() * RESPONDER: Extend sss_dp_account_send() to include extra data * DP: Fix bugs in sss_dp_get_account_int * LDAP: Improve debugging for sdap_parse_deref * Move sized_string declaration to utils * UTIL: Add strtouint16 * SYSDB: Move add_string and add_ulong to sysdb_private.h * DP: Handle parsing extra results in be_get_account_info * SYSDB: Add sysdb routines for manipulating service entries * SYSDB: Add indexes for servicePort and serviceProtocol * NSS: Add client support for services (non-enumeration) * DP: Add support for services in dp requests * NSS: Add negative cache routines for services * NSS: Add getservbyname and getservbyport support to the NSS Responder * PROXY: add support for service lookups (non-enumeration) * NSS: Add client support for [set|get|end]servent() * SYSDB: add support for enumerating services * NSS: Add service enumeration support to NSS provider * PROXY: add support for enumerating services * Rename sss_dp_type to sss_dp_sudo_type * SSSDConfigAPI: Move sssd.api.* to /usr/share/sssd * SYSDB: extend sysdb_store_service() to accept additional attributes * SYSDB: Add sysdb_attrs_get_uint16_t * LDAP: Add support for service lookups (non-enum) * LDAP: Add enumeration support for services * IPA: Add support for services lookups (non-enum) * LDAP: Add new options for service maps * KRB5: Add syslog messages for Kerberos failures * LDAP: Do not fail if RootDSE check cannot determine search bases * LDAP: Fix incorrect search timeouts * NSS: Add individual timeouts for entry types * Build all experimental features during 'make distcheck' * Set version to 1.7.91 for 1.8.0beta1 * Updating translatable strings for string freeze signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] New SSSD FAQ page in the works
It's come up more than once that SSSD needs a Frequently Asked Questions page to field some of our more common questions. I'm reaching out to the SSSD and FreeIPA user and developer communities to help us flesh out this page. I've begun it with the two most common questions I've received lately, as well as a basic primer on enabling debug logging to help identify issues. I'd like some additional suggestions on what questions should be answered on that page, as well as opening the page to volunteer-edits to add answers to any questions they may have had and solved (or enlisted aid in solving) in the past. The page is available at https://fedorahosted.org/sssd/wiki/FAQ and can be edited by anyone with a free Fedora account. If you don't have one, you can register quickly and easily at https://admin.fedorahosted.org/accounts Thank you very much for your contributions. Once this page has some meat, I will also be looking for interested translators to take a stab at making it accessible to non-English-native users. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] session authentication URI issues
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? signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
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. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Session design document
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). signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Samba package name change samba-4.0 -> samba4
On Wed, 2011-11-30 at 14:40 +0100, Sumit Bose wrote: > Hi, > > we recently changed the name of the samba packages in the ipa-devel > respository. The packages are now called samba4-* and libsmbclient4-* > instead of samba-4.0-* and libsmbclient-4.0-* . > > The name was changed because the samba packages will updated the samba4 > packages which are currently available for Fedora and RHEL6 in some time. > > There is no other way as to manually remove the old packages and install the > new ones. Yes there is. Mark the new packages as "Obsoletes: samba-4.0" signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] LDAPS for the IPA LDAP server?
On Mon, 2011-11-07 at 21:24 -0500, Adam Young wrote: > I noticed that the PKI Directory server has a secure port set but the > IPA DS instance does not: > > PKI > nsslapd-secureport: 7390 > > Why doesn IPA set up ldapson port 636? I think you're confused. FreeIPA does indeed set up to listen on both 636 (LDAPS) and 389 (LDAP/TLS) by default. Take a look at 'netstat -lptn' as root. If you cannot connect to the LDAPS port, it may be due to a firewall issue or a certificate issue (make sure you have the FreeIPA CA cert loaded in /etc/openldap/cacerts and have called cacertdir_rehash on that directory) signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 130 ipa-client assumes a single namingcontext
On Fri, 2011-09-30 at 16:15 -0400, Simo Sorce wrote: > On Fri, 2011-09-30 at 16:02 -0400, Stephen Gallagher wrote: > > On Thu, 2011-09-29 at 15:20 +0200, Martin Kosek wrote: > > > How to test: > > > 1) Add new naming context (suffix) to your LDAP database with installed > > > IPA (see attached LDIF). The server should return the new suffix as the > > > first one. You can change with its base DN if it does not. > > > 2) Install IPA client against the server. ipa-client-install should the > > > LDAP server as the IPA one only if the patch is applied on the client > > > > > > --- > > > > > > When LDAP server contains more that one suffixes, the ipa client > > > installation does not detect it as IPA server and fails to install. > > > Fix ipa server discovery so that it correctly searches all naming > > > contexts for the IPA one. > > > > > > https://fedorahosted.org/freeipa/ticket/1868 > > > > > > Tangentially related, it would be prudent for FreeIPA server > > installations to set not only namingContexts but also the > > defaultNamingContext. This way, clients autodetecting the ldap search > > base from the RootDSE will have an unambiguous way to do so (in the > > event that multiple namingContexts have been added) > > Please CC yourself here to be notified when this will be available in > DS: https://bugzilla.redhat.com/show_bug.cgi?id=742317 I'd like to add some more information on this (which I also just opened as upstream ticket https://fedorahosted.org/freeipa/ticket/1919). Right now, FreeIPA is set up with a single namingContexts, which is the 'dc=example,dc=com' root of the LDAP tree. The problem is that this search domain encompasses both the standard cn=accounts and the cn=compat trees. This means that SSSD, if set up as an RFC2307bis client instead of a full ipa-client-install (which explicitly sets the search base to cn=accounts) cannot safely auto-detect the search base to use. I think that FreeIPA should ship with the following settings in the RootDSE: defaultNamingContext: cn=accounts,dc=example,dc=com namingContexts: dc=example,dc=com namingContexts: cn=accounts,dc=example,dc=com and if compat mode is also enabled: namingContexts: cn=compat,dc=example,dc=com This will allow us to auto-detect in a sane way, as well as allowing us to easily communicate to clients that compat mode is or is not enabled. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 130 ipa-client assumes a single namingcontext
On Thu, 2011-09-29 at 15:20 +0200, Martin Kosek wrote: > How to test: > 1) Add new naming context (suffix) to your LDAP database with installed > IPA (see attached LDIF). The server should return the new suffix as the > first one. You can change with its base DN if it does not. > 2) Install IPA client against the server. ipa-client-install should the > LDAP server as the IPA one only if the patch is applied on the client > > --- > > When LDAP server contains more that one suffixes, the ipa client > installation does not detect it as IPA server and fails to install. > Fix ipa server discovery so that it correctly searches all naming > contexts for the IPA one. > > https://fedorahosted.org/freeipa/ticket/1868 Tangentially related, it would be prudent for FreeIPA server installations to set not only namingContexts but also the defaultNamingContext. This way, clients autodetecting the ldap search base from the RootDSE will have an unambiguous way to do so (in the event that multiple namingContexts have been added) signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] FreeIPA and per-machine views
On Thu, 2011-09-22 at 21:55 -0400, Dmitri Pal wrote: > On 09/21/2011 10:07 PM, Stephen Gallagher wrote: > > I've ben working on the multiple search base feature in SSSD and I've had > > some thoughts that might be relevant to the FreeIPA v3 core effort. The > > idea behind multiple search bases is fairly simple; instead of simply > > checking one subtree for user or group information, you check several in > > series, stopping at the first match. > > > > I was looking into this to identify the primary reasons why a deployment > > might use such an approach and I came up with two important use-cases. > > > > 1) This is a fairly simple way to extend a network you don't fully control. > > A classic example might be a Computer Science department at a university. > > They would want to use the campus user accounts (probably provided by the > > university IT department), but also add new groups for sharing or access > > control on CS department machines. This could be done with multiple search > > bases by setting the first base to the CS department subtree and the second > > base to a replicated university subtree. > > I do not think we want to deal with multiple subtrees of users in the > same IPA instance. We already decided against it in the past when we > flattened the tree. At least I am not convinced that this is actually > needed. I am actually aware of one more use case why people do different > subtrees for users. It is because they have duplication of the uid/gid. > Though it is bad it is a reality that people deal with. And they deal > with it by having subtrees in DS. But it will not help in our case as > IPA is built with the notion of the unified uid/gid namespace. The only > thing will help in both cases is different IPA domains with trust > relations so I suggest we focus on that part rather than support of > multiple subtrees for users. If IPA trusts still do not work for the > user may be staying with a free from DS server is a better choice. > > > 2) The second important use-case is for dealing with third-party > > applications with hard-coded groups. For a hypothetical example, let's say > > that a closed-source database program requires a user to be in the group > > 'dbadmins' in order to access a shell for editing the database. However, > > there may be more than one such database deployed in the network, possibly > > among different teams. Having multiple search bases allows different > > machines to have different views of this group. > > That is an interesting use case. But rather than creating views I would > suggest a different approach. In IPA we create a way to specify > alternative location for specific override groups. For example we now > have "cn=groups, cn=accounts,..." where all groups live. > we can have "cn=overridegroups, cn=accounts,..." and allow creation of > the special subtrees like we do with locations for maps. UI and CLI can > be modified to allow to manage these areas. I do not think that would be > a rocket science. > > On the SSSD side we can have an sssd_group_override_base parameter that > would define an override base for that machine. The logic in the SSSD > will be to read groups from override base first (it is expected that > there will be a small subset of groups that are used by specific app > like DB for example) and then the normal groups from the search base but > discard the groups that already have been fetched from the override > location (or something like this. I bet it is more complex and I will > leave it to you to define actual implementation, but I hope it > illustrates good enough what I am trying to propose). May be Jan's > delete group functionality would be really handy for this use case. > I was thinking on similar lines, but rather than have an extra option on the client, it would be better if we could configure the IPA server so that SSSD client could request the set of bases that it needs to use. For example, right now we're able to auto-detect our standard search base by asking the RootDSE for the namingContexts attribute. What we could do on the IPA server side is, in the cn=config tree or somewhere more appropriate, add a record that provides ordered naming contexts for each client (or hostgroup). Something like: cn=override1,cn=searchbases,cn=config memberOf: cn=hostgroup1,cn=hostgroups,... memberOf: cn=hostA,cn=hosts,... searchBaseList: search_base?scope?filter priority: 100 Then at online connection, SSSD could issue a search request in the cn=searchbases tree for any override specification for which this host or its hostgroups are a member. They would order by priority and then include the stand
[Freeipa-devel] FreeIPA and per-machine views
I've ben working on the multiple search base feature in SSSD and I've had some thoughts that might be relevant to the FreeIPA v3 core effort. The idea behind multiple search bases is fairly simple; instead of simply checking one subtree for user or group information, you check several in series, stopping at the first match. I was looking into this to identify the primary reasons why a deployment might use such an approach and I came up with two important use-cases. 1) This is a fairly simple way to extend a network you don't fully control. A classic example might be a Computer Science department at a university. They would want to use the campus user accounts (probably provided by the university IT department), but also add new groups for sharing or access control on CS department machines. This could be done with multiple search bases by setting the first base to the CS department subtree and the second base to a replicated university subtree. 2) The second important use-case is for dealing with third-party applications with hard-coded groups. For a hypothetical example, let's say that a closed-source database program requires a user to be in the group 'dbadmins' in order to access a shell for editing the database. However, there may be more than one such database deployed in the network, possibly among different teams. Having multiple search bases allows different machines to have different views of this group. I think it's definitely worth discussing how we might address these same use-cases in FreeIPA v3. My thought was that we might want to implement custom "views" of LDAP based on the hostgroups to which a client belongs. I can see a lot of implementation difficulties with this, however. Alternate ideas are most welcome. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0012 Modify existing SSSD configuration instead of dropping it
On Tue, 2011-09-13 at 16:33 +0300, Alexander Bokovoy wrote: > On Tue, 13 Sep 2011, Stephen Gallagher wrote: > > > > File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1207, in > > > > import_config > > > > fd = open(configfile, 'r') > > > > IOError: [Errno 2] No such file or directory: '/etc/sssd/sssd.conf' > > > Right, we need to fallback to new sssd.conf in case of any exception, > > > not only for ParsingError. > > Actually, that's not necessarily true. Do we want to fall back on > > permission error, for instance? This could result in clobbering an > > existing file (if for example the existing sssd.conf's SELinux context > > is wrong, preventing reading, but when we create a new one and save it > > in place later we have the right context and it replaces the old one). > Let's define what we want to see here. > > 1. There is no sssd.conf -> create new one (unlikely for existing SSSD > installation -- if we went to this path, we already found SSSD > installed) Actually, this is fairly likely in future releases. There's so much noise in the example configuration that I've decided that we're going to install it as %doc instead of %config. So a raw installation of the SSSD package will have no sssd.conf in place. We obviously need to consider this. > 2. There is sssd.conf -> modify existing one >2.1. Can't open for write -> report error Agreed. >2.2. Can't open and read due to parsing error -> create new one > ... There are two issues here. Failure to open for reading and ParseError on read. That said, I think they should be handled the same way (see below). Unfortunately, we have additional issues here... The SSSDConfig API is more strict with options than the SSSD itself is. Specifically, the SSSD will ignore unknown options entirely, but the SSSDConfig will through a ParseError on unknown options. The long-term goal is for SSSD to be more strict about this, but we don't currently have a way to do this. So as I see it, we have three choices for dealing with ParseError: 1) Back up the existing sssd.conf and replace it with a completely new one for FreeIPA. Pros: sssd.conf is guaranteed to parse cleanly. FreeIPA client install completes successfully. Cons: existing configuration (which may have worked) is not preserved. 2) Be restrictive on ParseError and throw an error telling them to fix their config file. Pros: we don't break an existing setup. Cons: FreeIPA installation has been broken. 3) Default to one of the above but provide a command-line flag to behave the other way. This is probably our best bet. I'd suggest defaulting to replacing the config file on ParseError (with a loud message at the END of ipa-client-install pointing to the backed-up file). > > What are other cases? > > > > Admittedly, it's a contrived example, but where contrived examples > > exist, so can real issues. > True. > signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0012 Modify existing SSSD configuration instead of dropping it
On Tue, 2011-09-13 at 16:22 +0300, Alexander Bokovoy wrote: > On Tue, 13 Sep 2011, Martin Kosek wrote: > > > So this patch is unblocked. To solve delayed data initialization from > > > SSSD in NSS responder we might simply increase number of tries to 10 > > > in case SSSD is in use. > > That sounds good. I made few tests of this patch and I still see a > > problem here. What if, for any reason, sssd.conf is not present on the > > machine? IPA client installation then crashes: > > > > # ipa-client-install --server vm-139.idm.lab.bos.redhat.com --domain > > idm.lab.bos.redhat.com > > DNS domain 'idm.lab.bos.redhat.com' is not configured for automatic KDC > > address lookup. > > KDC address will be set to fixed value. > > > > Discovery was successful! > > Hostname: vm-027.idm.lab.bos.redhat.com > > Realm: IDM.LAB.BOS.REDHAT.COM > > DNS Domain: idm.lab.bos.redhat.com > > IPA Server: vm-139.idm.lab.bos.redhat.com > > BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > > > > > Continue to configure the system with these values? [no]: y > > User authorized to enroll computers: admin > > Password for ad...@idm.lab.bos.redhat.com: > > > > Enrolled in IPA realm IDM.LAB.BOS.REDHAT.COM > > Created /etc/ipa/default.conf > > Traceback (most recent call last): > > File "/usr/sbin/ipa-client-install", line 1144, in > > sys.exit(main()) > > File "/usr/sbin/ipa-client-install", line 1133, in main > > rval = install(options, env, fstore, statestore) > > File "/usr/sbin/ipa-client-install", line 977, in install > > if configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, > > options): > > File "/usr/sbin/ipa-client-install", line 600, in configure_sssd_conf > > sssdconfig.import_config() > > File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1207, in > > import_config > > fd = open(configfile, 'r') > > IOError: [Errno 2] No such file or directory: '/etc/sssd/sssd.conf' > Right, we need to fallback to new sssd.conf in case of any exception, > not only for ParsingError. Actually, that's not necessarily true. Do we want to fall back on permission error, for instance? This could result in clobbering an existing file (if for example the existing sssd.conf's SELinux context is wrong, preventing reading, but when we create a new one and save it in place later we have the right context and it replaces the old one). Admittedly, it's a contrived example, but where contrived examples exist, so can real issues. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0012 Modify existing SSSD configuration instead of dropping it
On Tue, 2011-09-13 at 15:08 +0200, Martin Kosek wrote: > On Tue, 2011-09-13 at 15:11 +0300, Alexander Bokovoy wrote: > > On Thu, 08 Sep 2011, Alexander Bokovoy wrote: > > > > > On Wed, 07 Sep 2011, Stephen Gallagher wrote: > > > > > > > On Wed, 2011-09-07 at 16:15 +0300, Alexander Bokovoy wrote: > > > > > Hi! > > > > > > > > > > When modifying SSSD configuration, attempt to add new domain rather > > > > > than replacing whole configuration file. > > > > > > > > > > Only replace file in case it is impossible to parse it by current > > > > > SSSD > > > > > version. > > > > > > > > > > https://fedorahosted.org/freeipa/ticket/1750 > > > > > > > > Looks good to me. Ack. > > > Unfortunately, there is a bug in libini_config that prevents modifying > > > existing sssd configuration as it becomes unreadable by libini_config. > > > > > > https://fedorahosted.org/sssd/ticket/991 > > > > > > I would suggest to postpone this patch until libini_config bug is > > > fixed and released. > > After some research it appears there is no issue with libini_config, > > SSSD happily reads configs amended by ipa-client-install, with or > > without empty line between sections. > > > > The issue Marko was seeing in SSSD991 or FreeIPA1174 is unrelated to > > this change. It is an issue of timing -- by time we ask for 'getent > > passwd admin', SSSD might have not started its providers. We are > > trying to wait 1 second and do re-try for 5 times but some people have > > experienced delays up to 10 seconds. > > > > So this patch is unblocked. To solve delayed data initialization from > > SSSD in NSS responder we might simply increase number of tries to 10 > > in case SSSD is in use. > > > > > > That sounds good. I made few tests of this patch and I still see a > problem here. What if, for any reason, sssd.conf is not present on the > machine? IPA client installation then crashes: > > # ipa-client-install --server vm-139.idm.lab.bos.redhat.com --domain > idm.lab.bos.redhat.com > DNS domain 'idm.lab.bos.redhat.com' is not configured for automatic KDC > address lookup. > KDC address will be set to fixed value. > > Discovery was successful! > Hostname: vm-027.idm.lab.bos.redhat.com > Realm: IDM.LAB.BOS.REDHAT.COM > DNS Domain: idm.lab.bos.redhat.com > IPA Server: vm-139.idm.lab.bos.redhat.com > BaseDN: dc=idm,dc=lab,dc=bos,dc=redhat,dc=com > > > Continue to configure the system with these values? [no]: y > User authorized to enroll computers: admin > Password for ad...@idm.lab.bos.redhat.com: > > Enrolled in IPA realm IDM.LAB.BOS.REDHAT.COM > Created /etc/ipa/default.conf > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 1144, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 1133, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 977, in install > if configure_sssd_conf(fstore, cli_realm, cli_domain, cli_server, > options): > File "/usr/sbin/ipa-client-install", line 600, in configure_sssd_conf > sssdconfig.import_config() > File "/usr/lib/python2.7/site-packages/SSSDConfig.py", line 1207, in > import_config > fd = open(configfile, 'r') > IOError: [Errno 2] No such file or directory: '/etc/sssd/sssd.conf' ipa-client-install should be trapping this error and calling SSSDConfig.new_config() to create a blank configuration. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0012 Modify existing SSSD configuration instead of dropping it
On Wed, 2011-09-07 at 16:15 +0300, Alexander Bokovoy wrote: > Hi! > > When modifying SSSD configuration, attempt to add new domain rather > than replacing whole configuration file. > > Only replace file in case it is impossible to parse it by current SSSD > version. > > https://fedorahosted.org/freeipa/ticket/1750 Looks good to me. Ack. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Proposal: drop DENY rules from HBAC
We discussed today on the FreeIPA status meeting the possibility of dropping support for DENY rules from the HBAC specification. I'm submitting it for discussion. Specifically, I'm looking to hear whether there any any FreeIPA admins out there that have a strong opinion on whether the DENY rules need to be included. The current design of HBAC specifies that 1) If no ALLOW rules match, access is denied 2) If one or more ALLOW rules match and no DENY rules match, access is allowed. 3) If one or more DENY rules match, access is denied. Thus, DENY rules exist only to provide exceptions from the ALLOW rules. There exists no ALLOW+DENY combination that cannot be constructed from ALLOW rules only.[1] DENY rules introduce a lot of edge-cases for evaluation. The most important of which is the availability of the group membership for the user logging in. Depending on the mechanism used to log in (for example, GSSAPI over SSH or cross-realm Kerberos trust where the user is provided by the PAC), SSSD's cache may not have a complete list of groups for this user. If the login is occurring during offline mode (where SSSD cannot contact the LDAP server to refresh the user's groups), SSSD cannot determine whether DENY rules would match for the user. This therefore translates into a potential security issue. We implemented a workaround in the SSSD evaluator to resolve this by guaranteeing that we do a full lookup of all groups referenced by rules while we are retrieving the rules from FreeIPA. However, this requires at least one additional lookup against the LDAP server (possibly many if there is need to resolve nestings). This results in a significantly slower login while online. We also have issues related to source host evaluation. Some applications will provide an IP address instead of a hostname in the pam_rhost attribute. Our only recourse here is to perform a reverse-DNS lookup to try and identify the real hostname(s) of the server. However, in many real-world environments, reverse DNS is unavailable or misconfigured. In the case of ALLOW rules, this would lead to a match failure and an implicit denial. However, a failure to properly match a DENY rule can result in unexpected access being granted. This is a potentially serious security issue. Given these edge cases (and performance issues of the noted workaround), I propose that we should drop DENY rules from the HBAC specification and limit ourselves only to ALLOW rules (which are much safer). Beyond the obvious advantages for our implementation, I believe that this will be less complex for users to write their rules. [1] Some rules are complex to simulate, such as "Allow access from all PAM services EXCEPT telnet". But in a sane environment, all access should be via whitelist. If a customer is using an exception rule, they should re-evaluate this. signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 806 configure sssd to talk to local master
On Mon, 2011-06-20 at 15:42 -0400, Rob Crittenden wrote: > On masters configure sssd to only talk to the local master rather than > having _srv_ as well. If we use _srv_ and a remote master is down the > local master will have problems as well. > > ticket https://fedorahosted.org/freeipa/ticket/1187 Ack signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Summary of Session discussion
On Thu, 2011-05-26 at 14:43 -0400, Simo Sorce wrote: > On Thu, 2011-05-26 at 14:19 -0400, Dmitri Pal wrote: > > Cookie can be stored on the home directory of the user and user home > > directory can be NFS mounted so if we save anything important in the > > cookie the NFS root would be able to impersonate the user. It assumes > > that TGTs are not stored on the NFS in this case so replacing the TGT > > auth with fast session cookie auth would be a security issue. > > I hope I understand the issue correctly. > > We can store the the cookie in the ccache, so that we have it in the > same place the TGT is. We shouldn't save it in the home, as it is > insecure indeed. I'd like to point out that this is a strong argument for adding the SSSD/LDB Kerberos credential cache. It's unsafe to store the user's credential cache in their home directory (because it may be an NFS mount and therefore vulnerable to root on another machine). However, the other common location for a credential cache is in /tmp, which becomes an issue for systems running with pam_namespace or sandboxing (where different processes have different views of the contents of /tmp). To avoid both of these situations, it might be best for us to store the credential cache in SSSD. For more information, see https://fedorahosted.org/sssd/ticket/652 and https://bugzilla.redhat.com/show_bug.cgi?id=618689 signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 062 Update spec with missing BuildRequires for pylint check
On Thu, 2011-05-05 at 15:09 +0200, Martin Kosek wrote: > https://fedorahosted.org/freeipa/ticket/1203 > Ack signature.asc Description: This is a digitally signed message part ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [Freeipa-users] 6.1 beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2011 04:43 PM, Sigbjorn Lie wrote: > On 04/04/2011 10:28 PM, Stephen Gallagher wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 04/04/2011 04:20 PM, Sigbjorn Lie wrote: >>> On 04/04/2011 10:12 PM, Stephen Gallagher wrote: >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> On 04/04/2011 03:52 PM, Sigbjorn Lie wrote: >>>>> On 04/04/2011 09:36 PM, Stephen Gallagher wrote: >>>>>> -BEGIN PGP SIGNED MESSAGE- >>>>>> Hash: SHA1 >>>>>> >>>>>> On 04/04/2011 03:06 PM, Dmitri Pal wrote: >>>>>>> On 04/04/2011 03:01 PM, Sigbjorn Lie wrote: >>>>>>>> I also noticed that in /etc/sssd/sssd.conf the ipa server is >>>>>>>> specified >>>>>>>> with: >>>>>>>> ipa_server = _srv_, ipa01.ix.test.com >>>>>>>> >>>>>>>> sssd doesn't resolve anything from IPA until I remove "_srv_," >>>>>>>> >>>>>>> Stephen, was there a recent bug on this matter in SSSD? >>>>>>> >>>>>> The purpose of _srv_ is to check DNS for IPA server addresses first. >>>>>> The >>>>>> idea is that if you have more than one IPA server in service, then >>>>>> you >>>>>> can use DNS to list all of them. Otherwise, the ipa-client-install >>>>>> can >>>>>> only specify a static list of servers at the time of install. This >>>>>> would >>>>>> mean that if the IPA servers changed IP addresses or new ones entered >>>>>> production, it would be necessary to change all of the client >>>>>> configuration files. >>>>>> >>>>>> I'm puzzled why you would need to remove this, unless your DNS >>>>>> server is >>>>>> returning something other than FreeIPA servers for a SRV request >>>>>> directed at _ldap.tcp >>>>>> >>>>> I have verfied that the _ldap._tcp is resolving correctly. DNS was set >>>>> up using "ipa-server-install --setup-dns". I discovered this at the >>>>> IPA >>>>> server. This is a newly installed IPA server at RH 6.1 beta >>>>> installed a >>>>> few hours ago. No IP addresses changed. >>>>> >>>>> >>>>> # host -t srv _ldap._tcp >>>>> _ldap._tcp.ix.test.com has SRV record 0 100 389 ipa01.ix.test.com. >>>> Is the domain part of the client machine also ix.test.com? >>>> >>>> The way we determine which SRV record to use is as follows: >>>> 1) If dns_discovery_domain exists in the config file, it is always >>>> used. >>>> 2) If not, first try the domain part of the machine's hostname (aka >>>> hostname -d) >>>> 3) If that fails, try the name of the SSSD domain (in sssd.conf >>>> [domain/] >>>> >>>> IIRC ipa-client-install should set [domain/] so if >>>> that's not the same as your DNS domain, we could be having problems. >>>> >>>> Can we see your sssd.conf please? (feel free to sanitize as needed) >>>> >>> Please see the requested output below. This is taken from the IPA >>> server, which had the issue. DNS servers in resolv.conf set to the IP of >>> the IPA server. >>> >>> >>> # hostname -d >>> ix.test.com >>> >>> # more sssd.conf >>> [sssd] >>> services = nss, pam >>> config_file_version = 2 >>> >>> domains = ix.test.com >>> [nss] >>> >>> [pam] >>> >>> [domain/ix.test.com] >>> cache_credentials = True >>> ipa_domain = ix.test.com >>> id_provider = ipa >>> auth_provider = ipa >>> access_provider = ipa >>> chpass_provider = ipa >>> #ipa_server = _srv_, ipa01.ix.test.com >>> ipa_server = ipa01.ix.test.com >>> >>> [domain/default] >>> cache_credentials = True >>> krb5_realm = IX.TEST.COM >>> krb5_kdcip = ipa01.ix.test.com:88 >>> auth_provider = krb5 >>> chpass_provider = krb5 >>> krb5_kpasswd = ipa01.ix.test.com:749 >>> >> That's very strange. There should be no issue with using _srv_ in this >> configuration. Would you mind setting 'debug_level = 9' in >> [domain/ix.test.com], turning _srv_ back on, restarting SSSD, trying a >> request and then send me /var/log/sssd/sssd_ix.test.com.log to look at? >> I'd like to know why we're failing to resolve it. >> > Sure, see the attached file. I'm sending private, unscrambeled. > > For some reason it started working now, sluggish, but working. Takes > 0.488s to look up a new user account using "# id username" > > The log file is too much to read for me just now, it's getting late. :) Can you show me the output from 'dig' instead of SRV? The logs you sent seem to be telling me that the TTL is set to something extremely short, because we're marking it as expired pretty much instantly. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aMfYACgkQeiVVYja6o6PPQACfW6+sTJwQN/sPigJVh7Un6X8m x8EAn1qLk5hJKX11OwJ06dFLewkEUt01 =c9UJ -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 763 use full name for gecos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2011 10:41 AM, Sumit Bose wrote: > On Mon, Apr 04, 2011 at 10:01:29AM -0400, Stephen Gallagher wrote: > On 04/04/2011 09:58 AM, Stephen Gallagher wrote: >>>> On 04/01/2011 06:14 PM, Rich Megginson wrote: >>>>> On 04/01/2011 02:17 PM, Rob Crittenden wrote: >>>>>> Stephen Gallagher wrote: >>>>>>> -BEGIN PGP SIGNED MESSAGE- >>>>>>> Hash: SHA1 >>>>>>> >>>>>>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>>>>>>> Use fullname for gecos instead of uid. >>>>>>>> >>>>>>>> ticket 1146 >>>>>>> >>>>>>> >>>>>>> While it probably doesn't actually matter for these tests, I should note >>>>>>> that the GECOS attribute in LDAP is IA5String, not UTF8. >>>>>>> >>>>>>> Otherwise, Ack. >>>>>> >>>>>> It is defined using Directory String syntax by 389-ds. According to >>>>>> rfc 2307 it should be an IA5String, not sure why it isn't but we >>>>>> inherit this schema. >>>>> It is defined in the original rfc 2307 as Directory String, but 2307bis >>>>> redefined it to IA5String. >>>> >>>> >>>> Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined >>>> as IA5String in both. >>>> >>>> From http://www.ietf.org/rfc/rfc2307.txt: >>>> 3. Attribute definitions >>>> >>>>This section contains attribute definitions to be implemented by DUAs >>>>supporting this schema. >>>> ... >>>> ( nisSchema.1.2 NAME 'gecos' >>>> DESC 'The GECOS field; the common name' >>>> EQUALITY caseIgnoreIA5Match >>>> SUBSTRINGS caseIgnoreIA5SubstringsMatch >>>> SYNTAX 'IA5String' SINGLE-VALUE ) >>>> >>>> >>>> And from http://www.padl.com/~lukeh/rfc2307bis.txt >>>> 3. Attribute definitions >>>> >>>> This section contains attribute definitions to be implemented by >>>> DUAs supporting this schema. >>>> ... >>>> ( 1.3.6.1.1.1.1.2 NAME 'gecos' >>>>DESC 'The GECOS field; the common name' >>>>EQUALITY caseIgnoreIA5Match >>>>SUBSTRINGS caseIgnoreIA5SubstringsMatch >>>>SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >>>>SINGLE-VALUE ) >>>> > > > Hmm, strange. http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ > defines it as DirectoryString. > > So I have no idea which one is "more correct" for RFC 2307bis. > >> Look at the diffs in >> http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ > >> There are currently -00, -01 and -02 of the draft. With that in mind, Ack. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2aAhsACgkQeiVVYja6o6O6vgCfQ3OaAzTfA0d3s/FKKxensJGe ojsAoIaRo5dHTvE6Swio3I8wrmx9NBlA =fRLZ -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 763 use full name for gecos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/04/2011 09:58 AM, Stephen Gallagher wrote: > On 04/01/2011 06:14 PM, Rich Megginson wrote: >> On 04/01/2011 02:17 PM, Rob Crittenden wrote: >>> Stephen Gallagher wrote: >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>>>> Use fullname for gecos instead of uid. >>>>> >>>>> ticket 1146 >>>> >>>> >>>> While it probably doesn't actually matter for these tests, I should note >>>> that the GECOS attribute in LDAP is IA5String, not UTF8. >>>> >>>> Otherwise, Ack. >>> >>> It is defined using Directory String syntax by 389-ds. According to >>> rfc 2307 it should be an IA5String, not sure why it isn't but we >>> inherit this schema. >> It is defined in the original rfc 2307 as Directory String, but 2307bis >> redefined it to IA5String. > > > Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined > as IA5String in both. > > From http://www.ietf.org/rfc/rfc2307.txt: > 3. Attribute definitions > >This section contains attribute definitions to be implemented by DUAs >supporting this schema. > ... > ( nisSchema.1.2 NAME 'gecos' > DESC 'The GECOS field; the common name' > EQUALITY caseIgnoreIA5Match > SUBSTRINGS caseIgnoreIA5SubstringsMatch > SYNTAX 'IA5String' SINGLE-VALUE ) > > > And from http://www.padl.com/~lukeh/rfc2307bis.txt > 3. Attribute definitions > > This section contains attribute definitions to be implemented by > DUAs supporting this schema. > ... > ( 1.3.6.1.1.1.1.2 NAME 'gecos' >DESC 'The GECOS field; the common name' >EQUALITY caseIgnoreIA5Match >SUBSTRINGS caseIgnoreIA5SubstringsMatch >SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 >SINGLE-VALUE ) > Hmm, strange. http://bgp.potaroo.net/ietf/idref/draft-howard-rfc2307bis/ defines it as DirectoryString. So I have no idea which one is "more correct" for RFC 2307bis. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ZzzkACgkQeiVVYja6o6NEzQCeN9LxMNSd05Kqj6NHhRxOfXAw wsUAmwVplkWHnsLN/z2DY0RSJL+mbNMZ =gI9S -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 763 use full name for gecos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2011 06:14 PM, Rich Megginson wrote: > On 04/01/2011 02:17 PM, Rob Crittenden wrote: >> Stephen Gallagher wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> On 04/01/2011 03:55 PM, Rob Crittenden wrote: >>>> Use fullname for gecos instead of uid. >>>> >>>> ticket 1146 >>> >>> >>> While it probably doesn't actually matter for these tests, I should note >>> that the GECOS attribute in LDAP is IA5String, not UTF8. >>> >>> Otherwise, Ack. >> >> It is defined using Directory String syntax by 389-ds. According to >> rfc 2307 it should be an IA5String, not sure why it isn't but we >> inherit this schema. > It is defined in the original rfc 2307 as Directory String, but 2307bis > redefined it to IA5String. Actually, I just looked at both RFC 2307 and RFC 2307bis. It's defined as IA5String in both. - From http://www.ietf.org/rfc/rfc2307.txt: 3. Attribute definitions This section contains attribute definitions to be implemented by DUAs supporting this schema. ... ( nisSchema.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' SINGLE-VALUE ) And from http://www.padl.com/~lukeh/rfc2307bis.txt 3. Attribute definitions This section contains attribute definitions to be implemented by DUAs supporting this schema. ... ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'The GECOS field; the common name' EQUALITY caseIgnoreIA5Match SUBSTRINGS caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE ) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2ZzpQACgkQeiVVYja6o6NBBgCghFzG3FyVhAJV54TfytAad2K5 auwAnRqIrpk08cwTMdmGNep0tCndi5NM =ZxMd -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 763 use full name for gecos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2011 03:55 PM, Rob Crittenden wrote: > Use fullname for gecos instead of uid. > > ticket 1146 While it probably doesn't actually matter for these tests, I should note that the GECOS attribute in LDAP is IA5String, not UTF8. Otherwise, Ack. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2WMAcACgkQeiVVYja6o6NYDgCcCddPwcHxkmoWe0Q9au18V1Cb GkoAoKe5GNDnK6GEbKRj6/Qlio0XUsIT =fV9L -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 21 Escape LDAP characters in member and memberof searches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/30/2011 04:22 PM, JR Aquino wrote: > On Mar 30, 2011, at 1:01 PM, Stephen Gallagher wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 03/30/2011 03:53 PM, JR Aquino wrote: >>> >>> On Mar 30, 2011, at 12:05 PM, JR Aquino wrote: >>> >>>> The FreeIPA framework performs unescaped searches to enumerate group >>>> membership. >>>> >>>> The following patch corrects this behavior. >>>> >>>> -JR >>>> >>>> ___ >>>> Freeipa-devel mailing list >>>> Freeipa-devel@redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-devel >>> >>> Self NACK >>> >>> Attached is the corrected patch. >>> >>> search_group_dn = _ldap_filter.escape_filter_chars(search_group_dn) >>> >>> Is now correctly changed to: >>> >>> search_group_dn = _ldap_filter.escape_filter_chars(group_dn) >>> >> >> Nack. This is a step in the right direction, but you're not actually >> using this value anywhere. >> >> I think you wanted to have the next line changed to: >> >> searchfilter = "(memberof=%s)" % search_group_dn >> >> - -- >> Stephen Gallagher >> RHCE 804006346421761 > > Oh! You are right. > > Attached is the corrected patch. Ack - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2TkgQACgkQeiVVYja6o6MFoACgruAs/QgalqNzBLrge9H+k9HE 6dcAn0WL5DDgUWA60wUCYvDDEXlRDNWz =co8G -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 21 Escape LDAP characters in member and memberof searches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/30/2011 03:53 PM, JR Aquino wrote: > > On Mar 30, 2011, at 12:05 PM, JR Aquino wrote: > >> The FreeIPA framework performs unescaped searches to enumerate group >> membership. >> >> The following patch corrects this behavior. >> >> -JR >> >> ___ >> Freeipa-devel mailing list >> Freeipa-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Self NACK > > Attached is the corrected patch. > > search_group_dn = _ldap_filter.escape_filter_chars(search_group_dn) > > Is now correctly changed to: > > search_group_dn = _ldap_filter.escape_filter_chars(group_dn) > Nack. This is a step in the right direction, but you're not actually using this value anywhere. I think you wanted to have the next line changed to: searchfilter = "(memberof=%s)" % search_group_dn - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2TjDAACgkQeiVVYja6o6NQIQCfc4x3PqTqwyqNNHcJXTwPrFYo /tEAnR1uEjPYPdqKVU/duw9UG0aZD7hL =nLiN -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix gidnumber option of user-add command.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/28/2011 09:15 AM, Dmitri Pal wrote: > On 03/28/2011 07:23 AM, Pavel Zuna wrote: >> With this patch, the gidNumber is set automatically only if it wasn't >> specified explicitly by the user. >> >> Ticket #1127 >> >> Pavel >> >> >> ___ >> Freeipa-devel mailing list >> Freeipa-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Should we have another option like -noprivategroup to solve the cases > when the private group is not needed or has a GID collision with other > groups? > I agree, this would make migration scripts a lot simpler. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2QoUEACgkQeiVVYja6o6MIDwCdHHl0zF42urzaZe3Pb91Wdiy4 ADIAn3Z5LwABA/WI4ngbShj998XtNXrt =GHnf -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Dropping support for Fedora 13
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2011 09:32 PM, Rob Crittenden wrote: > Nalin Dahyabhai wrote: >> On Wed, Jan 12, 2011 at 05:49:42PM -0500, Rob Crittenden wrote: >>> With the patch titled '674 drop build dep on mozlap' freeipa v2 will >>> no longer build on Fedora 13. >> >> So just to be clear, we should stop trying to build git snapshot builds >> on f13? If so, is this for everything, just the freeipa package, or >> something in between? >> >> Nalin > > I believe everything for F13 assuming nobody else is using our devel > repo for other things. > Please leave the SSSD building for F13 for a while yet. We do have users playing with it there. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wSPQACgkQeiVVYja6o6NNHACfYQxApPBFxszp41wH60QJQwdg YAEAnRQSfLq4u9tl5BF+C+SgObEO/HBz =pAXr -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] bind-dyndb-ldap: Don't leave empty nodes in LDAP after DDNS update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2011 01:25 PM, Adam Tkac wrote: > On Wed, Jan 12, 2011 at 01:15:36PM -0500, Stephen Gallagher wrote: >> Nack. >> >> Your prototype for ldap_modify_do() includes 'isc_result_t delete_node', >> but the actual implementation expects 'isc_boolean_t delete_node'. I'm >> guessing that by coincidence these typedefs are the same primitive type, >> but I'd rather they both use isc_boolean_t which is more correct. >> >> Otherwise it looks good to me. > > Good catch! Fixed patch is attached. > > Regards, Adam > Ack - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0t8owACgkQeiVVYja6o6MMYQCcDkN3rfHWqPFd6EbyaK04HVL/ M10Ani4631Mf21ZPdAqKINf1N7wLCZQ9 =HNiC -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] bind-dyndb-ldap: Don't leave empty nodes in LDAP after DDNS update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2011 07:37 AM, Adam Tkac wrote: > Hello, > > bind-dyndb-ldap currently leaves empty nodes in LDAP when the last > DNS resource record associated with the node was removed: > > Before DDNS update: > > dn: idnsName=test,idnsName=example.com,ou=dns,dc=example,dc=com > aRecord: 1.1.1.1 > dNSTTL: > objectClass: idnsRecord > idnsName: test > > After DDNS update (removal of "test.example.com A 1.1.1.1" record): > > dn: idnsName=test,idnsName=example.com,ou=dns,dc=example,dc=com > dNSTTL: > objectClass: idnsRecord > idnsName: test > > As you can see this node is empty and useless. > > With the patch the whole node is removed. > > Comments are welcomed. > > Regards, Adam Nack. Your prototype for ldap_modify_do() includes 'isc_result_t delete_node', but the actual implementation expects 'isc_boolean_t delete_node'. I'm guessing that by coincidence these typedefs are the same primitive type, but I'd rather they both use isc_boolean_t which is more correct. Otherwise it looks good to me. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0t78gACgkQeiVVYja6o6M3rQCeI8y2pRMVjfaXJ8atOCByQIE/ CVIAoKIFVdTy0DFe6Du2Q3SsXMGHUV7O =ZlI/ -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] [bind-dyndb-ldap] Two patches for minor Coverity issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/05/2011 05:00 AM, Adam Tkac wrote: > On Tue, Jan 04, 2011 at 03:41:12PM -0500, Stephen Gallagher wrote: > Patch 0001: Fix missing varargs cleanup > > The CHECK() macro may cause execution to skip down to the cleanup > tag. If this happens, it would mean that we never called va_end() > on "backup". > > This patch reorganizes the code slightly to ensure that va_end() > is always called. > > > Patch 0002: Fix potential out-of-bounds write > > If there are exactly LD_MAX_SPLITS entries resulting from this > split, the mandatory trailing NULL entry will be written to one > entry past the end of the static arrayof LD_MAX_SPLITS size. > >> Both patches look fine for me, ack. Please push them. > Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0kZL8ACgkQeiVVYja6o6O+YgCdFny0PHIvy/14UeMcRwzVaXOX Gt8AniwOyMt8oSZEEMTnJ9QRwsEJp+yW =ttzH -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES] [bind-dyndb-ldap] Two patches for minor Coverity issues
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patch 0001: Fix missing varargs cleanup
The CHECK() macro may cause execution to skip down to the cleanup
tag. If this happens, it would mean that we never called va_end()
on "backup".
This patch reorganizes the code slightly to ensure that va_end()
is always called.
Patch 0002: Fix potential out-of-bounds write
If there are exactly LD_MAX_SPLITS entries resulting from this
split, the mandatory trailing NULL entry will be written to one
entry past the end of the static arrayof LD_MAX_SPLITS size.
- --
Stephen Gallagher
RHCE 804006346421761
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0jhegACgkQeiVVYja6o6PGlwCgnO1jSmW1VhO3kJh3C818655M
DaEAoK5b0f4VLiRkkKgMaJnGrjRoHv9+
=XJeu
-END PGP SIGNATURE-
From 4cc3a923c1e26ac4c286afd47df1d823920ef56b Mon Sep 17 00:00:00 2001
From: Stephen Gallagher
Date: Tue, 4 Jan 2011 15:28:46 -0500
Subject: [PATCH 1/2] Fix missing varargs cleanup
The CHECK() macro may cause execution to skip down to the cleanup
tag. If this happens, it would mean that we never called va_end()
on "backup".
This patch reorganizes the code slightly to ensure that va_end()
is always called.
---
src/str.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/str.c b/src/str.c
index b975aac7ba8c1028a71ac499dfe39530aba4e61f..611ae2028ec06d2e8e9e270eb6a6e0eaa37adcae 100644
--- a/src/str.c
+++ b/src/str.c
@@ -431,16 +431,16 @@ str_vsprintf(ld_string_t *dest, const char *format, va_list ap)
CHECK(str_alloc(dest, len));
len = vsnprintf(dest->data, dest->allocated, format, backup);
}
- va_end(backup);
if (len < 0) {
result = ISC_R_FAILURE;
goto cleanup;
}
- return ISC_R_SUCCESS;
+ result = ISC_R_SUCCESS;
cleanup:
+ va_end(backup);
return result;
}
--
1.7.3.4
From 93d709e47444ba38c314b4cece980a829c4f23b9 Mon Sep 17 00:00:00 2001
From: Stephen Gallagher
Date: Tue, 4 Jan 2011 15:33:02 -0500
Subject: [PATCH 2/2] Fix potential out-of-bounds write
If there are exactly LD_MAX_SPLITS entries resulting from this
split, the mandatory trailing NULL entry will be written to one
entry past the end of the static arrayof LD_MAX_SPLITS size.
---
src/str.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/str.c b/src/str.c
index 611ae2028ec06d2e8e9e270eb6a6e0eaa37adcae..56faa12dce3c7c7bde59d947b69907b9f63d315d 100644
--- a/src/str.c
+++ b/src/str.c
@@ -570,7 +570,7 @@ str_split(const ld_string_t *src, const char delimiter, ld_split_t *split)
current_pos = 0;
save = 1;
for (unsigned int i = 0;
- i < split->allocated && current_pos < LD_MAX_SPLITS;
+ i < split->allocated && current_pos < LD_MAX_SPLITS - 1;
i++) {
if (save && split->data[i] != '\0') {
split->splits[current_pos] = split->data + i;
--
1.7.3.4
0001-Fix-missing-varargs-cleanup.patch.sig
Description: PGP signature
0002-Fix-potential-out-of-bounds-write.patch.sig
Description: PGP signature
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] bynd-dyndb-ldap: Fix keytab checking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/2010 11:47 AM, Zoran Pericic wrote: > On 12/16/2010 08:06 PM, Simo Sorce wrote: > >> Obvious ACK, >> I will put the change in myself unless you can send me a git formatted >> patch I can git am into my tree. > > Thunerbird converted tabs to spaces. I hope this is ok. > Zoran, it is generally preferred to create the patch with the command: git format-patch -M -C --patience --full-index -1 Then attach the file to the email, rather than copying it in. If you have more than one patch in your tree that you want to send, change "-1" to "-2", "-3", etc. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0LmKoACgkQeiVVYja6o6MOdQCgrNMqGqpd57oX6dY75SU50Oqw TakAoK+Ez7RNR/piaP1eutba2dRU8cYn =+K+j -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCHES] Three patches for bind-dyndb-ldap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
These three patches were submitted to me directly. Just forwarding them
to the freeipa-devel list so they can be properly reviewed.
- Original Message
Subject: Re: bind-dyndb-ldap
Date: Wed, 15 Dec 2010 19:49:49 +0100
From: Zoran Pericic
To: Stephen Gallagher
On 12/14/2010 08:26 PM, Stephen Gallagher wrote:
> In the past, you have each requested commit privilege to the
> bind-dyndb-ldap project. This project was mostly abandoned, and I have
> taken it over in a sustaining capacity. If you have patches and similar
> that you would like to have considered for inclusion, please let me know.
I have submited 3 ticket to https://fedorahosted.org/bind-dyndb-ldap/ ,
ticket #27, #28, #29. This should be included.
I am using dyndb-ldap so I will try to fix any bugs I find but I'am not
planing to be full time maintainer so commit right is not necessery but
would be nice to know where could I contribute to this project
(buzilla?, https://fedorahosted.org/bind-dyndb-ldap?).
Best regards,
Zoran Pericic
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk0KZGgACgkQeiVVYja6o6NV9gCgsAg8y7W2WctmwHzgqhRmurbS
MYQAn0PoHNZmutTV6K7S4NkqSA1209eC
=qHRN
-END PGP SIGNATURE-
diff -urN bind-dyndb-ldap-0.1.0b.org/src/zone_register.c bind-dyndb-ldap-0.1.0b.add_zone/src/zone_register.c
--- bind-dyndb-ldap-0.1.0b.org/src/zone_register.c 2009-09-06 22:50:15.0 +0200
+++ bind-dyndb-ldap-0.1.0b.add_zone/src/zone_register.c 2010-11-21 04:04:19.782059900 +0100
@@ -182,7 +182,7 @@
/* First make sure the node doesn't exist. */
result = dns_rbt_findname(zr->rbt, name, 0, NULL, &dummy);
- if (result != ISC_R_NOTFOUND) {
+ if ((result != ISC_R_NOTFOUND)&&(result != DNS_R_PARTIALMATCH)) {
if (result == ISC_R_SUCCESS)
result = ISC_R_EXISTS;
log_error_r("failed to add zone to the zone register");
diff -urN bind-dyndb-ldap-0.1.0b.org/src/krb5_helper.c bind-dyndb-ldap-0.1.0b.keytab/src/krb5_helper.c
--- bind-dyndb-ldap-0.1.0b.org/src/krb5_helper.c 2009-09-06 22:50:14.0 +0200
+++ bind-dyndb-ldap-0.1.0b.keytab/src/krb5_helper.c 2010-11-21 05:04:47.623713693 +0100
@@ -106,12 +106,13 @@
REQUIRE(principal != NULL && principal[0] != '\0');
+ log_error("Trying keytab file name: '%s'", keyfile);
if (keyfile == NULL || keyfile[0] == '\0') {
log_debug(2, "Using default keytab file name: %s",
DEFAULT_KEYTAB);
keyfile = DEFAULT_KEYTAB;
} else {
- if (strcmp(keyfile, "FILE:") != 0) {
+ if (strncmp(keyfile, "FILE:", 5) != 0) {
log_error("Unknown keytab file name format, "
"missing leading 'FILE:' prefix");
return ISC_R_FAILURE;
diff -urN bind-dyndb-ldap-0.1.0b.org/src/ldap_helper.c bind-dyndb-ldap-0.1.0b.krb5_principal/src/ldap_helper.c
--- bind-dyndb-ldap-0.1.0b.org/src/ldap_helper.c 2010-03-24 11:55:30.0 +0100
+++ bind-dyndb-ldap-0.1.0b.krb5_principal/src/ldap_helper.c 2010-11-18 00:17:57.503920016 +0100
@@ -128,6 +128,7 @@
ldap_auth_t auth_method;
ld_string_t *bind_dn;
ld_string_t *password;
+ ld_string_t *krb5_principal;
ld_string_t *sasl_mech;
ld_string_t *sasl_user;
ld_string_t *sasl_auth_name;
@@ -293,6 +294,7 @@
{ "auth_method", default_string("none") },
{ "bind_dn", default_string("") },
{ "password", default_string("") },
+ { "krb5_principal", default_string("") },
{ "sasl_mech", default_string("GSSAPI") },
{ "sasl_user", default_string("") },
{ "sasl_auth_name", default_string("") },
@@ -330,6 +332,7 @@
CHECK(str_new(mctx, &ldap_inst->base));
CHECK(str_new(mctx, &ldap_inst->bind_dn));
CHECK(str_new(mctx, &ldap_inst->password));
+ CHECK(str_new(mctx, &ldap_inst->krb5_principal));
CHECK(str_new(mctx, &ldap_inst->sasl_mech));
CHECK(str_new(mctx, &ldap_inst->sasl_user));
CHECK(str_new(mctx, &ldap_inst->sasl_auth_name));
@@ -346,6 +349,7 @@
ldap_settings[i++].target = auth_method_str;
ldap_settings[i++].target = ldap_inst->bind_dn;
ldap_settings[i++].target = ldap_inst->password;
+ ldap_settings[i++].target = ldap_inst->krb5_principal;
ldap_settings[i++].target = ldap_inst->sasl_mech;
ldap_settings[i++].target = ldap_inst->sasl_user;
ldap_settings[i++].target = ldap_inst->sasl_auth_name;
@@ -380,13 +384,24 @@
}
/* check we have the right data when SASL/GSSAPI is selected */
- if ((ldap_inst->auth_method == AUTH_SASL) &&
- (str_casecmp_char(ldap_inst->sasl_mech, "GSSAPI") == 0)) {
- if ((ldap_inst->sasl_user == NULL) ||
- (str_
Re: [Freeipa-devel] Plans for bind-dyndb-ldap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/2010 01:57 PM, Stephen Gallagher wrote: > 1) Petition the Fedora Infrastructure team to turn over ownership of > this upstream project. This is likely to meet with resistance without > the input of the current owner (who is more or less unreachable at this > point). The bind-dyndb-ldap project was initiated with FreeIPA as its > primary patron, but I'm not certain this would be sufficient argument to > the admins to annex the project. Apparently, this was indeed sufficient to take over the project. I've been made the project sponsor, and I've granted Simo commit privilege as well. So we should be alright to make fixes as needed from now on. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0Hx5kACgkQeiVVYja6o6P1ogCfZriFVstvBJGW8sFQZTqqchCb GggAoKEB+LAurg6vJ+aMiGz16Uazm5Ip =JrKB -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Plans for bind-dyndb-ldap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 FreeIPA v2 DNS integration relies on a BIND plugin to store the DNS data in LDAP, which was written by Martin Nagy. Martin, who left the FreeIPA development team some time ago was the only person with commit access to this repository, leaving it both unmaintained and uneditable. We need to discuss how to proceed with this dependency on FreeIPA. Originally, Martin's plan was to campaign for this plugin's acceptance into the BIND upstream, and to terminate the separate bind-dyndb-ldap project. I think that this is a valuable long-term goal, but we need to discuss shorter-term needs. As we work to finalize FreeIPA v2, it's very likely that we will discover one or more bugs in bind-dyndb-ldap. If this happens, we will have to provide patches and get them included in Fedora. However, Fedora has a strong policy against shipping patches that aren't upstream, and we have no way currently of pushing them upstream. So I figure that we have the following options to consider: 1) Petition the Fedora Infrastructure team to turn over ownership of this upstream project. This is likely to meet with resistance without the input of the current owner (who is more or less unreachable at this point). The bind-dyndb-ldap project was initiated with FreeIPA as its primary patron, but I'm not certain this would be sufficient argument to the admins to annex the project. 2) Open dialog with the BIND upstream and push very hard to merge this code into their mainline, then involve ourselves with their process to push patches. This is probably our best long-term approach, but currently we have no control over when the ldap plugin would be merged, and how soon afterwards that it would be pushed into Fedora. 3) Fork bind-dyndb-ldap into a new project that we maintain and include in Fedora. This is the least controversial approach, as it will involve no difficult political maneuvering to include. However, it also requires an additional effort in setting up a new project and getting packages approved in Fedora. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0Hvg0ACgkQeiVVYja6o6M7VgCeIje+BcvlS5k8C0KgHC3tqhrI s8IAniYxCMx2MqG0idk82RhFXxCgtO48 =m7Ry -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0024 - Better random ranges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/07/2010 08:13 AM, Simo Sorce wrote: > On Tue, 07 Dec 2010 07:40:36 -0500 > Stephen Gallagher wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 12/06/2010 06:51 PM, Simo Sorce wrote: >>> >>> This patch reduced the size of the default range (from 1 million to >>> 200.000) and also changes the way the range is selected. >>> Instead of starting at a completely random number, it selects 1 out >>> of 1 random 200k ranges so that the range starts at multiples >>> of 200k. >>> >>> This makes it so that 2 different installs either do not overlap at >>> all or overlap completely (once in 10k times) instead of potentially >>> partially overlapping. >>> >> >> Instead of using a random number here, why don't we do something more >> predictable (so installing FreeIPA on the same machine will hit the >> same range). >> >> Something we used to do at my old job was base it on the IPv4 address >> of the primary network adapter in the machine. Basically, we could >> take the integer representation of the IP address, take the modulus >> 1 of it, and choose the range from that. > > That's not needed, if you want to force a specific range you can simply > pass an option to the installer. > >> This would also provide a guarantee that replicas on the same network >> would get unique ranges (instead of a 1 in 10,000 chance of doubling >> up). > > Replicas take a cut of the range from the first master, sharing the > assigned initial range between them (see the DNA plugin[1] Shared > config to understand how it works) > >> These are just suggestions. The patch as it exists right now looks >> fine to me (though I haven't tested it). > > I have tested it :) > > Simo. > > [1] http://directory.fedoraproject.org/wiki/DNA_Plugin > In that case: ack. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+NNAACgkQeiVVYja6o6ODEgCgnsbBx5gGBNU8Jrb8IfnaaXhv LVAAoKU7aCwJ5Uut7hmoLxeOMEJyb4I1 =avc3 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0024 - Better random ranges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/06/2010 06:51 PM, Simo Sorce wrote: > > This patch reduced the size of the default range (from 1 million to > 200.000) and also changes the way the range is selected. > Instead of starting at a completely random number, it selects 1 out of > 1 random 200k ranges so that the range starts at multiples of 200k. > > This makes it so that 2 different installs either do not overlap at all > or overlap completely (once in 10k times) instead of potentially > partially overlapping. > Instead of using a random number here, why don't we do something more predictable (so installing FreeIPA on the same machine will hit the same range). Something we used to do at my old job was base it on the IPv4 address of the primary network adapter in the machine. Basically, we could take the integer representation of the IP address, take the modulus 1 of it, and choose the range from that. This would also provide a guarantee that replicas on the same network would get unique ranges (instead of a 1 in 10,000 chance of doubling up). These are just suggestions. The patch as it exists right now looks fine to me (though I haven't tested it). - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkz+Kz8ACgkQeiVVYja6o6PqdQCePglfhYZRDYJXhOuawrCuarCt SOwAn3g/kl7zvWWRRC7QegTWdb5Asjsm =eT2Z -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 11:15 AM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> On 11/23/2010 04:32 PM, Simo Sorce wrote: >>> On Tue, 23 Nov 2010 16:07:47 -0500 >>> Rob Crittenden wrote: >> >>>> I don't want to throw a wrench in, but what if you have multiple >>>> replicas in various distant locations, WHICH server is the time >>>> relative to? >>> By server I think Steve meant the machine currently evaluation the >>> access control decision. "Host" would have been a happier term. >> >> >> No, I was actually talking about the FreeIPA server in this situation, >> but Rob is right that there is no guarantee in a multi-master situation >> that the servers themselves are in the same timezone. >> >> Given this, I think the only sane thing to do here is to always use UTC >> (and state clearly that this is what is happening) >> > > I was always saying that the time should be in the UTC only when it is > evaluated on the server . I do not think that "local" is a good solution. > But I think the whole idea with the timezones have been misinterpreted > so let me try to explain one more time. > He is the workflow that I have in mind: > > 1) Admin creates a rule with time definition using UI and CLI > 2) Rule is saved in the LDAP attribute > 3) Rule gets replicated between IPA servers > 4) SSSD fetches the rule from an IPA server > 5) SSSD validates the rule > > Let us say that the rule is entered, saved, transfered and interpreted > on the client as UTC. Sounds reasonable and not that complex from the > implementation POW. Good! > The only issue I see is that the admin during step 1 does not think in > terms of UTC as Ben pointed out. He thinks in user time or server time > i.e. tries to relate the rule to some reasonable time markers (start of > a shift, end of a working day, midnight at a special location etc.) > So I was suggesting the following: > 1) Allow admin to specify in what time zone he entered the time > 2) Pass the time definition together with the time zone he selected to > the server > 3) Before saving the rule the server would convert the rule into UTC and > stick the TZ info hint into the rule > 4) When SSSD retrieves the attribute it will know that time is in UTC > and will ignore any TZ hints stored in the rule > 5) The TZ hint only need for UI/CLI when admin fetches the rule and > looks at it. In this case the server will take attribute which is in > UTC, extract a TZ hint from the rule and use that TZ to convert UTC > value it has to the value in the specified TZ. This is what is sent to > the client and displayed in the UI/CLI. > > So TZ is needed only for the administrative purposes and not for SSSD. I > hope it is clear now. > I was also suggesting to save offset together with the TZ hint but I > guess this can be dropped. > Can we agree to keep the TZ as hint for the management purposes in the rule? > Dmitri, this simply cannot work, because time zones are not static. You can't tell the administrator he is defining something in the Eastern time zone from 09:00-17:00 EST and then store that value as UTC. Because when DST happens, suddenly this will be equivalent to 08:00-16:00 EDT. And the meaning of the rule is lost. So if you want to define a timezone for a rule, it MUST be stored as local time plus timezone identifier, so that when it is evaluated it will use the appropriate offset for that moment in history. You can't just send a UTC value down to SSSD. After lunch, I'm going to write up the completely new proposal that Adam and I are suggesting to avoid the future upgrade issue for SSSD as well. It will account for the problem you're trying to solve here. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztRXkACgkQeiVVYja6o6N4nwCeMQ5Rby7kGQADKbYj0EdEqfzi JDYAnRBS+A3rY/dg7kQVMeEB8CEHIcSr =G3lr -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/24/2010 11:26 AM, Dmitri Pal wrote: > >> >>> Duration >> >>> New grammar allows DDHHMM for the duration. UI proposes to limit the >>> duration to less than 24 hours since more than 24 hour windows can start >>> overlapping and thus allowing to enter duration days was confusing to >>> the users who tried the UI. We need to reconcile this a bit between >>> what can be stored and what can be displayed. IMO it makes sense to >>> allow windows more than 24 hours (regular service window over weekend >>> for example). But on the other hand I see how having a separate field >>> for number of duration days in the UI might be confusing. I would vote >>> for not having days in the UI at all but allowing any numeric value to >>> be entered into the hours field. This however rises a question whether >>> we want to have the duration be in DDHHMM format in grammar or in just >>> NMM format where N is any numeric value that represents unlimited number >>> of hours. Thoughts? >> >> >> I agree that we don't want to have > 24 hours in the UI. >> >> DDHHMM is easier to parse, and I can't come up with an example where a >> window of longer than 99 days makes sense. Instead, it should be a >> recurring event. >> >> > > Steven, please think about the case when the rule needs to be edited in > UI and it has some value for DD - say 1. > What you display in UI then? If you do not allow to enter days and you > not allow more than 24 hours in the hour field you will fail to > translate the rule to the proposed UI. > The only option would be to show the raw rule in this case. IMO this > does not seem like the best option to me. > I think the DD is redundant and other means should be used to schedule > windows bigger than 2 days however the HH should IMO allow 1-48 ours to > allow specifying a week end outage like: > from 1AM Sat to 11PM Sun. If it is more than 2 days it is reasonable to > ask to split the rule into several slices. > I don't want the internal representation to have arbitrary limitations set by the WebUI. It's trivial for the WebUI to be designed to convert hours to days and reverse. So we can store it in DDHHMM format and display it in the WebUI as hours if we really want to. To someone writing a rule by hand, the DDHHMM representation is going to be far more useful. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztQ2EACgkQeiVVYja6o6McjgCfZ7RfnLM+wU4KUqXdKac9PuWE q50An07EzeToJV6YlhStTrBg1mDIkw8s =hO6C -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/23/2010 04:32 PM, Simo Sorce wrote: > On Tue, 23 Nov 2010 16:07:47 -0500 > Rob Crittenden wrote: > >> I don't want to throw a wrench in, but what if you have multiple >> replicas in various distant locations, WHICH server is the time >> relative to? > > By server I think Steve meant the machine currently evaluation the > access control decision. "Host" would have been a happier term. No, I was actually talking about the FreeIPA server in this situation, but Rob is right that there is no guarantee in a multi-master situation that the servers themselves are in the same timezone. Given this, I think the only sane thing to do here is to always use UTC (and state clearly that this is what is happening) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkztJaoACgkQeiVVYja6o6MPPgCglv9EY4OaQk6PaEEXhUIIdFu4 HVQAn1gqQom24AmJ/qMUoxWN/4mr/+M4 =hSe5 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Other issues with HBAC calendar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2010 10:54 PM, Dmitri Pal wrote: > Hi, > > During the conversation with Ben and Kyle today over the calendar screen > two things came up: > 1) Time zone > 2) Duration > > Time zone > Time zone should always be entered relative to the server, not the user entering it. This should be clearly identified in the UI. Then there's no ambiguity upon reading it back out, as it is ALWAYS relative to the server. > > Duration > > New grammar allows DDHHMM for the duration. UI proposes to limit the > duration to less than 24 hours since more than 24 hour windows can start > overlapping and thus allowing to enter duration days was confusing to > the users who tried the UI. We need to reconcile this a bit between > what can be stored and what can be displayed. IMO it makes sense to > allow windows more than 24 hours (regular service window over weekend > for example). But on the other hand I see how having a separate field > for number of duration days in the UI might be confusing. I would vote > for not having days in the UI at all but allowing any numeric value to > be entered into the hours field. This however rises a question whether > we want to have the duration be in DDHHMM format in grammar or in just > NMM format where N is any numeric value that represents unlimited number > of hours. Thoughts? > I agree that we don't want to have > 24 hours in the UI. DDHHMM is easier to parse, and I can't come up with an example where a window of longer than 99 days makes sense. Instead, it should be a recurring event. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzr4WkACgkQeiVVYja6o6PmXgCbBKNR3qb5uh2hJlfF1TsQLkMz yx4AnAuGm/PADzU9CFa2+DRCmLbDxq1k =7+wV -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2010 12:22 PM, Dmitri Pal wrote >> >> septet-of-the-month = interval 1-5 > > The septet is not used any more and should be removed, right? Yeah, I missed removing that. I've deleted it from the page now. > >> day-of-the-month-interval = interval day-of-the-month > > This should be a plain interval from 1-31 with no negatives since it is used > in the M-day rule > I would argue that M-day can be just replaced with > > M-day = "day" WSP interval 1-31 > I disagree. With this construction, we can say: accessTime = periodic monthly day -1 at 0900 + 000800 (Read: on the last day of the month from 09:00 to 17:00) This would be useful for e.g. a regularly-scheduled backup task. > Keep in mind that definition of the interval here is as described below: > interval XX-YY = a comma-separated list of items from XX to YY, or > dash-separated ranges. > For example, (interval 1-31) 3-7,10,12,15,25-31 with no spaces inside. > > So definition of the day-of-the-month-interval can be then removed. > Agreed. I've simplified the display of this. >> day-of-the-month-range = "between" WSP day-of-the-month WSP "and" WSP >> day-of-the-month >> >> day-of-the-month = "-31" to "31" > > > This notion allows me to enter "between -31 and 3" which does not make any > sense. I'll clarify with "-31" to "-1" OR "0" to "31". > Also current grammar does not allow me to use ranges which I want to use here. Please explain what range you want here. I'm specifically avoiding "intervals" here because it's too complex to understand. Describing events with arbitrary intervals like this would be better done with the M-day approach. > I want to be able to express "Wednesday" of the first and third week of the > month. Capability to do so it completely lost. Wrong. accessTime is multivalued. You just create two entries, one for the first week, one for the third week. They are additive. > We abandoned the term "septet" not because of the bad idea but because this > is a confusing word. But we can leave without it as long as I can use complex > intervals. > After more thinking I would like to reject idea of the negative numbers. > Instead we can do the following: > > > M-on = "on" WSP day-of-the-week WSP "during" WSP day-of-the-month-range > day-of-the-month-range = interval 1-31 / last-days > last-days = "last" WSP sequential-days > sequential-days = single number from the 1-31 range > > So if we want to say "Wednesday" of the first and third week of the month I > will use: > > periodic monthly on Wed during 1-7,15-21 > > if I want to say Wednesday during last two weeks of the month I will say: > > periodic monthly on Wed during last 14 > > IMO it is cleaner and simpler and allows to express all the notions we want > to express. > See above. I really don't want intervals in the M-on grammar, since it makes it extremely difficult to comprehend by mere mortals. > > >> day-of-the-week = interval 1-7 (or Mon-Sun) >> >> range-specifier = "at" WSP HHMM WSP "+" WSP duration-specifier > > What is the value and significance of the "+" here? Is it just for > readability? Then I would suggest that we replace it with the word "for". > Sure, "for" is fine. >> duration-specifier = DDHHMM >> >> DD = "00" to "31" >> >> HH = "00" to "23" >> >> MM = "00" to "59" >> >> >> interval XX-YY = a comma-separated list of items from XX to YY, or >> dash-separated ranges. >> range = dash-separated range > > This definition seems incomplete but I do not know how to make it better... > >> For example, (interval 1-31) 3-7,10,12,15,25-31 with no spaces inside. > > > Thank you, > Dmitri Pal > > Sr. Engineering Manager IPA project, > Red Hat Inc. > > > --- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzqvi4ACgkQeiVVYja6o6ODqQCgm5eK3onDby9Of4arf53p8oNM GV8AoIhFQUXZNF8EiJ4d6S/BAujAHnAy =PCv6 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have updated the grammar page at https://fedorahosted.org/sssd/wiki/HBAC_Grammar again. The main changes made are these: * Eliminate the arbitrary "singular" from monthly repetitions * Add negative numbers for days of the month for counting from the end * For readability, replaced "-" with "and" for "between DAY and DAY" * For readability, added delimiter "at" before the range-specifier Please reread the page for more detail. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzqi/4ACgkQeiVVYja6o6Nv6ACfSvLHsASBQbqipVbjZGZhFfkX moIAn0SV8RsrpuAeJicMyFD2k7KeUzzT =NkXL -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2010 04:09 PM, Dmitri Pal wrote: > Stephen Gallagher wrote: >> Breaking the thread intentionally to bring back focus. >> >> With Adam's recent input, I've modified the grammar to what I hope will >> be it's final form. >> >> The complete grammar is available at >> https://fedorahosted.org/sssd/wiki/HBAC_Grammar >> >> The differences from my previous proposal (involving septets) is here: >> https://fedorahosted.org/sssd/wiki/HBAC_Grammar?action=diff&version=3 >> >> >> The primary change is that instead of introducing the septet concept, we >> will specify "day within a range". So the first Friday of the month >> would be: >> >> accessTime = periodic monthly on Fri between 1-7 >> >> Tuesdays for the second half of the month would be: >> accessTime = periodic monthly on Tue between 15-31 >> >> >> I don't anticipate that last being very common, but it's now possible. >> >> Please chime in if you have any further comments about the grammar, or >> we will declare this final and move to adjusting the implementation next >> week. >> > Why you are making it singular? > Why it can't be: > accessTime = periodic monthly on Tue, Thu between 15-31 > or > accessTime = periodic monthly on Mon-Wed between 15-31 > or > accessTime = periodic monthly on 1,2,3 between 15-31 <- meaning same as > above > > It seems that "singular" in this case is an artificial limitation. I'll agree with this. We can remove the "singular" limitation. > However I would also treat the last portion of the rule differently. > In stead of: > > M-on = "on" WSP day-of-the-week-singular WSP "between" WSP > day-of-the-month-range > and > day-of-the-month-range = range 1-31 > > M-on = "on" WSP day-of-the-week WSP "during-7-day-set" WSP day-set > day-set = day-set-list / day-set-range > day-set-list = "1-7","8-14","15-21","22-28","29+" > or alternatively > day-set-list = "1","2","3","4","5" <- meaning first seven days, second seven > days etc. > if we use this version them day-set-range can be just: > day-set-range = 1-5 > otherwise it might be a bit more ugly. > If we now combine day set-list and day set range into one list range in the > same way as we allow in interval for days we would be able to express > > accessTime = periodic monthly on Tue, Thu between 15-31 > > it will look like: > > accessTime = periodic monthly on Tue, Thu during-7-day-set 2-3 > or > accessTime = periodic monthly on Tue, Thu during-7-day-set 2,3 > > as well as > accessTime = periodic monthly on Tue, Thu during-7-day-set 1<--- > meaning first Tue and Thu of the month > > or > > accessTime = periodic monthly on Tue, Thu during-7-day-set 1-5 <--- > meaning all Tue and Thu of the month > > > I would actually argue that we would be able to reuse the interval logic from > the month for this so it should not be more work than what has been proposed. > I am opposed to this completely. It's both unreadable and incomprehensible to most users. I think the language we've described between eliminating the "singular" limitation and adding negative numbers to describe the numbers back from the end of the month will provide all the versatility we need. Adding "7-day-set" is no different from the "septet" we discussed previously and shot down. Examples with my current proposal: The first Tuesday and Thursday of the month: accessTime = periodic monthly on Tue,Thu between 1 - 7 All Tuesdays and Thursdays in the month: accessTime = periodic monthly on Tue,Thu between 1 - 31 The last Tuesday and Thursday of the month: accessTime = periodic monthly on Tue,Thus between -7 - -1 I'm questioning whether for readability (especially with negative values in play) we should switch to: accessTime = periodic monthly on Tue,Thus between -7 and -1 Using "and" in place of the range hyphen. Thoughts? - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzqiLcACgkQeiVVYja6o6NGoACfUyTjhvYx8eFcXUWcmdAi2oT4 zfIAoJMipLumnwIvSSNBT0G3NmRxQOom =hnac -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2010 04:09 PM, Endi Sukma Dewata wrote: > On 11/19/2010 2:56 PM, Stephen Gallagher wrote: >>> So we loose the possibility of saying: the last friday of the month ? >> >> It's not impossible, it can still be done with this schema, though it's >> somewhat more complicated. >> >> You'd need to set it up as separate rules for each particular month. > > How about this? > accessTime = periodic monthly on Friday between (last_day_of_month-6) to > last_day_of_month > Actually, I think this would be easier to handle: accessTime = periodic monthly on Friday between -7 - -1 So we define negative day-of-the-month numbers as number of days from the end of the month, with -1 being the last day of the month. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzqhtEACgkQeiVVYja6o6NxwACgk2f2OWfD8H9s+MK2RE6E73JF 5HMAnAi5fPZwSWEWx1UqE1Xv92zlBX8Z =dksU -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2010 03:55 PM, Simo Sorce wrote: > On Fri, 19 Nov 2010 15:31:30 -0500 > Stephen Gallagher wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Breaking the thread intentionally to bring back focus. >> >> With Adam's recent input, I've modified the grammar to what I hope >> will be it's final form. >> >> The complete grammar is available at >> https://fedorahosted.org/sssd/wiki/HBAC_Grammar >> >> The differences from my previous proposal (involving septets) is here: >> https://fedorahosted.org/sssd/wiki/HBAC_Grammar?action=diff&version=3 >> >> >> The primary change is that instead of introducing the septet concept, >> we will specify "day within a range". So the first Friday of the month >> would be: >> >> accessTime = periodic monthly on Fri between 1-7 >> >> Tuesdays for the second half of the month would be: >> accessTime = periodic monthly on Tue between 15-31 >> >> >> I don't anticipate that last being very common, but it's now possible. >> >> Please chime in if you have any further comments about the grammar, or >> we will declare this final and move to adjusting the implementation >> next week. > > So we loose the possibility of saying: the last friday of the month ? It's not impossible, it can still be done with this schema, though it's somewhat more complicated. You'd need to set it up as separate rules for each particular month. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzm5JcACgkQeiVVYja6o6Pv1wCeNLivqHkH4tbT0kPFboa/EnZx HTMAni0PdakTcad85YDMZ4NUmygZl9TW =ddmI -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Breaking the thread intentionally to bring back focus. With Adam's recent input, I've modified the grammar to what I hope will be it's final form. The complete grammar is available at https://fedorahosted.org/sssd/wiki/HBAC_Grammar The differences from my previous proposal (involving septets) is here: https://fedorahosted.org/sssd/wiki/HBAC_Grammar?action=diff&version=3 The primary change is that instead of introducing the septet concept, we will specify "day within a range". So the first Friday of the month would be: accessTime = periodic monthly on Fri between 1-7 Tuesdays for the second half of the month would be: accessTime = periodic monthly on Tue between 15-31 I don't anticipate that last being very common, but it's now possible. Please chime in if you have any further comments about the grammar, or we will declare this final and move to adjusting the implementation next week. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzm3qIACgkQeiVVYja6o6OgkgCeLQiHkFJCfgIPRAtmHdcN/iar mZEAn0+RuUCV9/8EepbqW/zdpQZqXD+z =+wsh -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2010 07:49 AM, Sumit Bose wrote: > On Thu, Nov 18, 2010 at 05:27:13PM -0500, Dmitri Pal wrote: >> Adam Young wrote: >>> On 11/18/2010 04:02 PM, Stephen Gallagher wrote: >>> On 11/18/2010 09:55 AM, Dmitri Pal wrote: >>> >>>>>> Steve can you summarize where we are and what we agreed to, >>> please, and >>>>>> identify the questions that we need to answer. >>>>>> >>> >>> Simo, Adam and I had a long discussion on IRC regarding the time rules >>> today (complete log attached). >>> >>> The short version is that we're going to continue (mostly) with the >>> current grammar for the time rules, with a few changes. >>> >>> 1) We need to replace week-of-the-month with day-of-the-septet. This day >>> should not be a range or multi-valued to eliminate confusion >>> 2) We need to replace the time range with a duration >>> 3) We should add startDate and endDate as attributes on the HBAC object >>> (separate from the accessTime). I propose these should be in LDAP >>> generalizedTime so that it's possible to construct filters around them. >>> This effectively sets the beginning and end of a periodic schedule. >>> >>> >>>> OK, just please stop calling it septet. I think Drums, Bass, Piano, >>> 2 Saxes, Trumpet, Trombone Jazz combo when I hear that. It isl ike >>> octet versus byteit means the same thing, and just annoys people. >>> >>>> What you really want is to call it week-of-the-month as opposed to >>> week. I realize that is more verbose, but we don't sound like >>> smarty-pants. >>> >>> >>> >>> >>> I've drawn up a new grammar definition and published it to the SSSD wiki >>> (not currently linked from anywhere): >>> https://fedorahosted.org/sssd/wiki/HBAC_Grammar >>> >>> Please review and give feedback. >>> >>> >> I thought that first septet is the first seven days of the month based >> on earlier mails from Steven. Is this a true statement? >> The whole issue started with ambiguity of the notion of the "N-th week" >> of the month. >> What is it the week-of-the-month? Is it first seven day regardless what >> day of the week is the first day of the month (this is what I thought a >> septet is) or fist full week from Monday to Sunday or from Sunday to >> Saturday, or it is the first usually partial week? This is the ambiguity >> that we want to avoid! >> >> If the septet is what I think it is then we can't name it the >> week-of-the-month and IMO septet is a good term here. However then there >> is a bug in grammar as septet can be only 1-5 not 1-6. >> > > if I understand the septets correctly the 5th septet will cover days > 29-35. When will you need the 6th? > Dmitri is correct. That was a typo on my part. I've fixed that on the wiki page now. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzmdzUACgkQeiVVYja6o6MxKwCgll4QvAq9TlQoDmEkjvGwWpsm 5tQAoJK1iPMj+QuTD2GJVQETbyqpuQpO =HFwW -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2010 06:16 PM, Dmitri Pal wrote: > Adam Young wrote: >> On 11/18/2010 05:27 PM, Dmitri Pal wrote: >>> Adam Young wrote: >>> >>>> On 11/18/2010 04:02 PM, Stephen Gallagher wrote: >>>> On 11/18/2010 09:55 AM, Dmitri Pal wrote: >>>> >>>> >>>>>>> Steve can you summarize where we are and what we agreed to, >>>>>>> >>>> please, and >>>> >>>>>>> identify the questions that we need to answer. >>>>>>> >>>>>>> >>>> Simo, Adam and I had a long discussion on IRC regarding the time rules >>>> today (complete log attached). >>>> >>>> The short version is that we're going to continue (mostly) with the >>>> current grammar for the time rules, with a few changes. >>>> >>>> 1) We need to replace week-of-the-month with day-of-the-septet. This >>>> day >>>> should not be a range or multi-valued to eliminate confusion >>>> 2) We need to replace the time range with a duration >>>> 3) We should add startDate and endDate as attributes on the HBAC object >>>> (separate from the accessTime). I propose these should be in LDAP >>>> generalizedTime so that it's possible to construct filters around them. >>>> This effectively sets the beginning and end of a periodic schedule. >>>> >>>> >>>> >>>>> OK, just please stop calling it septet. I think Drums, Bass, Piano, >>>>> >>>> 2 Saxes, Trumpet, Trombone Jazz combo when I hear that. It isl ike >>>> octet versus byteit means the same thing, and just annoys people. >>>> >>>> >>>>> What you really want is to call it week-of-the-month as opposed to >>>>> >>>> week. I realize that is more verbose, but we don't sound like >>>> smarty-pants. >>>> >>>> >>>> >>>> >>>> I've drawn up a new grammar definition and published it to the SSSD >>>> wiki >>>> (not currently linked from anywhere): >>>> https://fedorahosted.org/sssd/wiki/HBAC_Grammar >>>> >>>> Please review and give feedback. >>>> >>>> >>>> >>> I thought that first septet is the first seven days of the month based >>> on earlier mails from Steven. Is this a true statement? >>> The whole issue started with ambiguity of the notion of the "N-th week" >>> of the month. >>> What is it the week-of-the-month? Is it first seven day regardless what >>> day of the week is the first day of the month (this is what I thought a >>> septet is) or fist full week from Monday to Sunday or from Sunday to >>> Saturday, or it is the first usually partial week? This is the ambiguity >>> that we want to avoid! >>> >>> If the septet is what I think it is then we can't name it the >>> week-of-the-month and IMO septet is a good term here. However then there >>> is a bug in grammar as septet can be only 1-5 not 1-6. >>> >> >> OK, if this is really what is driving the grammar, I'm going to have >> to NACK. >> >> Lets make something that is intelligible. We don't want to be >> inventing concepts like Septet. Or Septave, since 8 days is already >> called an octave. >> >> Here's the Cron line that Steve posted before. It represents THe >> first wednesday of the month. >> >> 0 8 1-7 * 3 >> >> >> Lets keep the concept of week, starting on Sunday, add in the concept >> of day of the month, and mix the two together. >> >> Does the current grammar (pre-septet) support that? Something like: >> >> accessTime: periodic monthly between day 1-7 wednesday >> No, it does not. That's the specific reason for introducing septet, to add this support. However, you make an interesting point. Perhaps we could introduce a more generic term than septet to allow the above. Though I think user comprehension would be made easier if we turned the construct into something closer to: accessTime: periodic monthly Wed between day 1-7 Though for the parser, I think it would be best to have a delimiter between Monthly and Wed. I'm open to suggestions for what makes sense, though. "encompass"? "inclusive"? "position"? >> > > It does not support this. > It requires to specify either a week of the month after "monthly" and > then day within a week (as numbers or the letter day names) or a set of > numbers representing days or ranges of ways with thin the month. > You can't with exiting schema unambiguously define "first Wednesday of > the month" without the proposed "septet" changes. > - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzmYI8ACgkQeiVVYja6o6N6nACfeoqLtaVfLQo8P9V+HeUgObfp dr4AnjK5+NlPAFFFW5JiP74HFEzZ/gGK =s+6m -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2010 09:55 AM, Dmitri Pal wrote: > Steve can you summarize where we are and what we agreed to, please, and > identify the questions that we need to answer. Simo, Adam and I had a long discussion on IRC regarding the time rules today (complete log attached). The short version is that we're going to continue (mostly) with the current grammar for the time rules, with a few changes. 1) We need to replace week-of-the-month with day-of-the-septet. This day should not be a range or multi-valued to eliminate confusion 2) We need to replace the time range with a duration 3) We should add startDate and endDate as attributes on the HBAC object (separate from the accessTime). I propose these should be in LDAP generalizedTime so that it's possible to construct filters around them. This effectively sets the beginning and end of a periodic schedule. I've drawn up a new grammar definition and published it to the SSSD wiki (not currently linked from anywhere): https://fedorahosted.org/sssd/wiki/HBAC_Grammar Please review and give feedback. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzllFMACgkQeiVVYja6o6PNIwCfQeLMCrWS0dW3t+pD8raTJ7d5 /7oAmwUAFMY1XAb289ysIGzSq3sPMjJF =a0mt -END PGP SIGNATURE- (12:51:03 PM) sgallagh: simo, ayoung: Can we discuss the time grammar live? (12:51:21 PM) sgallagh: dpal wants a summary, but we have two opposing proposals on the list 12:55 (12:55:46 PM) ayoung: sure sgallagh (12:58:01 PM) sgallagh: ayoung, simo: So the two proposals are: (12:58:18 PM) sgallagh: 1) Modify the current interface slightly to support septets and try to make the UI work with that (12:58:31 PM) sgallagh: 2) Replace the current grammar entirely with cron+duration (12:58:37 PM) ***ayoung hates the word septets. (12:58:48 PM) sgallagh: ayoung: It was less ambiguous than "week" (12:59:31 PM) ayoung: sgallagh, what does the current grammar do that that the cron grammer doesn't? (12:59:56 PM) sgallagh: ayoung: Save us a week of rewriting the parsers and HBAC provider in SSSD? 13:00 (01:00:40 PM) sgallagh: Also, we will need to discuss the UTC vs Local Time situation, but we'll hold that until later (01:00:40 PM) ayoung: sgallagh, no, I mean, what doesn't it represent? (01:00:55 PM) ayoung: OK, TZ is one issue. (01:01:11 PM) sgallagh: That's an issue for both grammars, so that can wait (01:02:25 PM) sgallagh: ayoung: I don't know that there's any huge difference between the capabilities of the current grammar and the cron grammer (01:02:29 PM) sgallagh: *grammar (01:02:46 PM) sgallagh: Actually, I take that back. The current grammar can do individual events (01:03:04 PM) sgallagh: For example, "this rule only applies on this ONE date in all time" (01:03:09 PM) sgallagh: Cron mandates repetition (01:03:17 PM) sgallagh: Once a year at minimum (01:04:42 PM) ayoung: sgallagh, yep, because the Unix apprao9ch assumes you' (01:04:51 PM) ayoung: ll use at for that. OK, that is two issues 13:05 (01:05:56 PM) ayoung: Here's my take: we are going to try to get people to use IPA. The principal of "least surprise" says that if it is scheduling, make it look like that standard for scheduling. (01:06:04 PM) ayoung: cron is posix. (01:06:25 PM) sgallagh: As an aside, regardless of which grammar we choose, I also want to add an optional startDate and endDate attribute to the HBAC object. So we can define whether certain rules start "next year" and end "in three years" (for example) (01:07:00 PM) sgallagh: But that's easy and an aside (01:07:07 PM) ayoung: sgallagh, agreed. (01:07:46 PM) ayoung: well...hmm, maybe not (01:07:55 PM) sgallagh: ? (01:08:10 PM) ayoung: I'm wondering if we want to split it into a cron part and an at part (01:08:25 PM) ayoung: at says : deploy this rule, undeploy this rule (01:08:34 PM) ayoung: cron is just the repitition (01:08:57 PM) sgallagh: I thought at just said "Do this AT this time" and only fired once (01:08:58 PM) ayoung: not sure if "start this 3 months from now" is really that useful. (01:09:06 PM) ayoung: sgallagh, that is correct (01:09:31 PM) sgallagh: ayoung: Example: you've hired a group of contract workers to start in January and work for one year. (01:09:39 PM) dpal: EnigmaObfuscate, ping, I am very busy this week but I see the mails about SUDO. I will reply and comment early next week. (01:09:48 PM) ayoung: you would use "at" to deploy the rules when they start 13:10 (01:10:02 PM) sgallagh: ayoung: That's not how we'd do it in SSSD (01:10:27 PM) ayoung: sgallagh, understood. I'
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2010 09:31 AM, Adam Young wrote: > On 11/18/2010 07:09 AM, Stephen Gallagher wrote: > On 11/17/2010 04:51 PM, Adam Young wrote: > >>>> On 11/17/2010 04:31 PM, Simo Sorce wrote: >>>> >>>>> On Wed, 17 Nov 2010 16:07:24 -0500 >>>>> Stephen Gallagher wrote: >>>>> >>>>> >>>>> >>>>>> This will require two changes to the HBAC schema. First of all, we >>>>>> plan to drop the week-of-the-month concept entirely and replace it >>>>>> with septet-of-the-month. This is being done to eliminate the >>>>>> ambiguity entirely. Secondly, we will need to describe >>>>>> day-of-the-septet in the grammar (where the day of the septet >>>>>> describes the name of the weekday, and not its numerical position >>>>>> within the septet, as that would be a useless and complex duplication >>>>>> of the day-of-the-month concept). >>>>>> >>>>>> >>>>>> >>>>> I think we can keep using 1-7 in the septet with the >>>>> understanding that 1 is always Monday, 2 is always Tuesday and so on. >>>>> >>>>> Simo. >>>>> >>>>> >>>>> >>>> I'd like to propose that we have a goal to be as close to the Cron >>>> grammar as practicable. So we should allow 0 or 7 for Sunday. This is in >>>> keeping with your proposal. >>>> >>>> >>>> >>>> Here are the examples from the crontab 5 manpage; >>>> >>>> # run five minutes after midnight, every day >>>> 5 0 * * * $HOME/bin/daily.job>> $HOME/tmp/out 2>&1 >>>> # run at 2:15pm on the first of every month -- output mailed to paul >>>> 15 14 1 * * $HOME/bin/monthly >>>> # run at 10 pm on weekdays, annoy Joe >>>> 0 22 * * 1-5 mail -s "Its 10pm" joe%Joe,%%Where are your kids?% >>>> 23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday" >>>> 5 4 * * sun echo "run at 5 after 4 every sunday" >>>> >>>> >>>> >>>> I'm not sure that 'First Wednesday of the month' is possible with this >>>> grammar, either. Yet, somehow, it has survived many years. >>>> >>>> > > 0 8 1-7 * 3 (read, 08:00 on the Wednesday that falls between the 1st > and 7th day of the 6th month) > >> Yep: except you meant every month. > Whoops. I had that example written down earlier from some theoretical constructs I was working on, and just changed that to * but forgot to change the comment. > >> OK. So we add a duration to this grammar, declare victory and go home. > >> I propose adding a hyphen and then duration in days:hours:minutes > >> 0 8 1-7 * 3 : 0:0:30 #from 8 - 8:30 > >> 0 8 1-7 * 3 : 0:2:0 #from 8 - 10: > >> 0 8 1-7 * 3 : 2:0:0 #For 48 hours > I'm not sure we want to do that. I still think we want to try to use our existing representation internally, as long as we can map them bi-directionally in a reasonable way. Mostly because rewriting the time rules parser is a big job that I'd like to see us avoid if possible. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzlOVsACgkQeiVVYja6o6NN7wCdEu+kb5vWoi3k0KW9WJpbi8l9 fP4AoKcpR5XUzeKmHTWeUxo4VzTWJDRv =Hvbm -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2010 04:48 PM, Sumit Bose wrote: > On Wed, Nov 17, 2010 at 04:07:24PM -0500, Stephen Gallagher wrote: > After extended discussion, Simo, Ben and I discussed replacing this > week-of-the-month concept with a septet-of-the-month concept instead. > > This would be described by: > accessTime: periodic monthly septet 1 day 3 0800-1700 > > and would literally translate as "The wednesday that exists within the > first septet of the month". The first septet being the range of day 1 > through day 7, the second septet being day 8 through 14, and so forth. > >> I would like to suggest to allow negative numbers to cover 'the last >> Wednesdays of the month'. > Doing the forward septets is easy (1*x..7*x), but the reverse septets are more complicated (since they would be (y-1*x..y-7*x), where y is the total number of days in the month (which also has to account for leap years). I think it might be a nice enhancement, but I recommend that we not include it right now, given the tight release schedule for FreeIPA v2. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzlGjAACgkQeiVVYja6o6PLxQCfW4OakzaQH+OPtlD4kOsyh7BN voMAn1G+dMWRTx5jwxL1yu5lkbuWX+Qz =ZDmw -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2010 06:37 PM, Endi Sukma Dewata wrote: > On 11/17/2010 5:24 PM, Endi Sukma Dewata wrote: >> Will the user need to be aware of this issue? In other words, will the >> UI enforce the user to split a schedule that crosses midnight manually? >> >> If yes, there are some issues: >> >> 1. Some schedules that have to be split because of local time zone can >> actually be merged in UTC. In that case do we want to merge it or keep >> them separate? For example: >> - Original: 2100-0159 local (UTC-3) >> - Entered in UI: 2100-2359 and -0159 local >> - Stored on server: >> a) keep the split schedules: -0259 and 0300-0459 UTC >> b) merge it: -0359 UTC >> >> 2. Some schedules that have to be split because of local time zone may >> need to be split differently in UTC. Will this confuse users? For >> example: >> - Original: 2100-0159 local (UTC-2) >> - Entered in UI: 2100-2359 and -0159 local >> - Stored on server: >> a) split the first part: 2300-2359, -0159, and 0200-0359 UTC >> b) merge if possible: 2300-2359 and -0359 UTC >> >> Alternatively, the splitting issue can be hidden by the UI, but UI and >> CLI will be inconsistent. >> > > Also, when viewing an existing schedule, the UTC schedule may not fit > the UI for the local time zone, requiring a split too. > The intent from a user interface perspective (Web UI or CLI) was that we would allow the user to specify the start time, a duration and a repetition, and that internally we would convert that into the format described above. Of course, the UI->accessTime conversion is easy. It might be tricky to do the reverse when reading it back to the user. I'm open to suggestions on how to handle this. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzlGCUACgkQeiVVYja6o6OIiwCfdIhgFv5YYEfYyW2cea7oFZNP GywAnizSgA1FKzSAcKZqN9hnzNhuMm+a =tSss -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2010 04:51 PM, Adam Young wrote: > On 11/17/2010 04:31 PM, Simo Sorce wrote: >> On Wed, 17 Nov 2010 16:07:24 -0500 >> Stephen Gallagher wrote: >> >> >>> This will require two changes to the HBAC schema. First of all, we >>> plan to drop the week-of-the-month concept entirely and replace it >>> with septet-of-the-month. This is being done to eliminate the >>> ambiguity entirely. Secondly, we will need to describe >>> day-of-the-septet in the grammar (where the day of the septet >>> describes the name of the weekday, and not its numerical position >>> within the septet, as that would be a useless and complex duplication >>> of the day-of-the-month concept). >>> >>> >> I think we can keep using 1-7 in the septet with the >> understanding that 1 is always Monday, 2 is always Tuesday and so on. >> >> Simo. >> >> > I'd like to propose that we have a goal to be as close to the Cron > grammar as practicable. So we should allow 0 or 7 for Sunday. This is in > keeping with your proposal. > > > > Here are the examples from the crontab 5 manpage; > > # run five minutes after midnight, every day > 5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1 > # run at 2:15pm on the first of every month -- output mailed to paul > 15 14 1 * * $HOME/bin/monthly > # run at 10 pm on weekdays, annoy Joe > 0 22 * * 1-5 mail -s "It’s 10pm" joe%Joe,%%Where are your kids?% > 23 0-23/2 * * * echo "run 23 minutes after midn, 2am, 4am ..., everyday" > 5 4 * * sun echo "run at 5 after 4 every sunday" > > > > I'm not sure that 'First Wednesday of the month' is possible with this > grammar, either. Yet, somehow, it has survived many years. > 0 8 1-7 * 3 (read, 08:00 on the Wednesday that falls between the 1st and 7th day of the 6th month) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzlF4UACgkQeiVVYja6o6NTtwCfRBeGkTqDMHYj+SPMydCfFila wCYAn1Z8gbd0qlaWSEchzqbTe86jWDXM =r9zs -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Proposed changes to the HBAC grammar
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 During a discussion today about how to represent the HBAC grammar in the FreeIPA GUI, it became apparent that there was a limitation in the grammar. Specifically, it's not possible to describe in a non-ambiguous way "The first Wednesday of the month". Right now, this would be described by: accessTime: periodic monthly week 1 day 3 0800-1700 However, this literally means "Wednesdays that appear as the first week on a wall calendar". Meaning that if the month began on a Thursday, this rule would not fire this month. Thus it's not behaving in a way that would be reasonably expected by a user. After extended discussion, Simo, Ben and I discussed replacing this week-of-the-month concept with a septet-of-the-month concept instead. This would be described by: accessTime: periodic monthly septet 1 day 3 0800-1700 and would literally translate as "The wednesday that exists within the first septet of the month". The first septet being the range of day 1 through day 7, the second septet being day 8 through 14, and so forth. We all feel that this would map closer to a user's expectation when describing "the Nth Wednesday of the month", since it's a guarantee that Wednesday will appear only once within a septet. This will require two changes to the HBAC schema. First of all, we plan to drop the week-of-the-month concept entirely and replace it with septet-of-the-month. This is being done to eliminate the ambiguity entirely. Secondly, we will need to describe day-of-the-septet in the grammar (where the day of the septet describes the name of the weekday, and not its numerical position within the septet, as that would be a useless and complex duplication of the day-of-the-month concept). In a related note, we also discussed how to handle describing activity windows that cross the midnight boundary. It's my recommendation that we should handle examples like the following by breaking them into two separate accessTime attributes, one that describes the portion preceding midnight and describes the set of days wherein the block starts, and a second accessTime attribute that is offset by one day and describes the portion taking place after midnight. Second-shift (17:00-01:59, M-S*) *starts Monday, ends Saturday morning becomes accessTime: periodic weekly day 1-5 1700-2359 accessTime: periodic weekly day 2-6 -0159 - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzkRAwACgkQeiVVYja6o6NtHwCgi3Vk2Q2aZXKIRHM3fbWOsLHE X6UAn3zECofcDzG1+gJClyUlDVZvKnmS =+zfc -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Handling nested netgroups (looking for recommendations)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 First, a little overview on netgroups. Netgroups in LDAP can contain two attributes: 1) nistNetgroupTriple - Contains a literal triple of (host, username, domain) 2) memberNisNetgroup - The name (or DN, more on that later) of another netgroup. Returning triples are simple, we just return them as-is. However, returning nested netgroups introduces a bit of additional complexity. Currently, nss_ldap just returns the name of the memberNisNetgroup directly to glibc and allows it to handle it. This means that glibc will make an extra, internal set of setnetgrent(), getnetgrent() endnetgrent() calls to nss_ldap. Or not: the design of glibc means that if the nested netgroup appears in an NSS provider listed in nsswitch.conf before nss_ldap, it will be returned from there, rather than nss_ldap. This means that it is theoretically possible for a local file to override the centralized LDAP for a netgroup. With SSSD, our original plan was that we should always treat the LDAP server as authoritative. We would internally handle recursive lookups for nested netgroups and unravel them ourselves before returning them to glibc. We would only return nested names in this case if the specified member does not exist on the LDAP server (in this case we will assume that it's meant to be handled by another netgroup provider). To illustrate the difference: With nsswitch.conf: netgroup files nss_ldap On LDAP: ldapnetgroup1: (user1, host1, ldapdomain) extranetgroup2 extranetgroup2: (user2, host2, ldapdomain) In local files: extranetgroup2: (localuser, localhost, localdomain) With nss_ldap, making a request for ldapnetgroup1 would return to the calling application (after glibc completed all its internal lookups): ldapnetgroup1: (user1, host1, ldapdomain), (localuser, localhost, localdomain) Whereas with the proposed approach for SSSD: With nssswitch.conf: netgroup files sss We would get back from glibc: ldapnetgroup1: (user1, host1, ldapdomain), (user2, host2, ldapdomain) So the difference in behavior should be clear now. The obvious advantage to this approach is that the central server will always be considered authoritative for its entries. We will assume that the specified member should use the LDAP representation as its first option, and fail over to glibc's lookup for other netgroup providers only if it does not exist in LDAP. This should provide a more stable environment, however it does differ from the current expected behavior as defined by nss_ldap. To enumerate the options we can follow: 1) We can behave exactly as nss_ldap does. If we locate a member netgroup, we can return that directly to glibc and expect to have it look it up as needed. Pros: identical behavior to the current state. Cons: makes additional requests to the SSSD that we could be handling internally without a lot of back-and-forth to glibc. 2) We can assume that member entries in LDAP refer to LDAP entries unless we cannot locate them. In this case, we can internally handle the recursive lookups to LDAP. Any member netgroups that we don't find in LDAP should be returned to glibc to process. Pros: we can control nesting limits this way. The memberOf plugin also does a good job with protecting us against loops. We can parallelize the lookups of multiple member netgroups for performance. Cons: we are changing the behavior as described above. Appendix) There is no formal specification of netgroups. It's possible for the memberNisNetgroup attribute to contain either a simple name or a full LDAP distinguished name. If a full DN is provided, we should assume that this means that it must be in LDAP, and stop processing (and don't return it) if we get a DN that doesn't match. For entries that are not complete DN's, we should choose one of the two aforementioned approaches. Please comment if you have an opinion. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyiMSIACgkQeiVVYja6o6MuxwCghVhG3baFori0Retl6itILvLe NqkAn3Sn5EZkgP5Yoztuvh/KHudWP48S =tcYu -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 459 remove Requires on python-krbV
On 06/01/2010 02:43 PM, Rob Crittenden wrote: I used python-krbV to get the configured kerberos realm so we could clean up /etc/krb5.keytab. This is a bit heavy-weight for one line of code. We can instead parse /etc/ipa/default.conf to get the same thing without an additional Requires. rob Patch looks good to me. Ack. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 454 add su-l hbac service
On 05/27/2010 10:59 AM, Rob Crittenden wrote: Add another default hbac service, su-l. rob Ack -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 453 fix gpg2 usage
On 05/26/2010 03:24 PM, Rob Crittenden wrote: Replica preparation and installation is not working in F-13 because of gpg2. It now requires the --batch argument when using the --passphrase* options. This patch is for ipa-1.2.2 but the same principal applies to master as well. Note that this fixes some whitespace issues as well. rob Ack. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 448 fix default hbac rule, add default services
On 05/20/2010 01:54 PM, Rob Crittenden wrote: Add the 'all' serviceCategory to the default allow_all HBAC rule and add some standard services: ftp, login, sshd, su, sudo. rob Please add 'su-l' as well -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 438 client uninstaller work
On 05/06/2010 10:15 PM, Rob Crittenden wrote: Check to see if we are installed before doing an uninstall. Uses the same mechanism as is used to see if we are already installed. I also changed this so the --force flag will override on install and uninstall. rob Ack. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] named.conf: Add trailing dot to the fake_mname
On 05/01/2010 03:23 PM, Martin Nagy wrote: Hi, Yet another trailing dot issue, but this one was kept hidden because only the latest bind-dyndb-ldap package uses the fake_mname option. Thanks to Stephen for finding this one. Martin Ack. -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 10/10] Add gettext translation test using test language.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/12/2010 01:09 PM, John Dennis wrote: > > > Just a minor nitpick, but it's more traditional to use the notation $(MAKE) -C install/po test_lang rather than explicitly changing into that directory first. If I remember correctly, make will log it to the screen explicitly this way. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuaou8ACgkQeiVVYja6o6OaqgCgqnCPZ6LRy4ggyNFEaGtR4o/7 x2oAn3i2lFZtQ9NmVUNB3eJ96PPxCBGQ =uAh7 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Add contributors file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2010 05:30 PM, John Dennis wrote: > Add contributors file. This gets installed along side the LICENSE and > README files in the doc dir for each rpm package. > My name is spelled "Stephen", not "Steven". - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuFJEcACgkQeiVVYja6o6PdFACeJotWvaYt8Ct4aZl9fntwKcIw 66YAoJpKCwB21qKhiLKnhHSZEgn7xpCt =NyTA -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] jderose 046 Add buildrequires script
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/19/2010 10:32 AM, Jason Gerard DeRose wrote: > I want to make our development process more easily automated and > repeatable, so I started on this script to install all the packages a > person would likely need to hack on the server. I'm using this to > bootstrap fresh VMs. > > Plus this lowers the barrier for new developers. > FYI, on Fedora and similar one can also do: yum-builddep and it will automatically pull in any build dependencies listed in the SRPM. Alternately, 'yum-builddep --enablerepo=ipa-devel ipa-server' will also accomplish this (assuming they have the development repo in their yum configuration) I think directing people to use this will prove easier than trying to maintain this script separate from the RPM spec. It would also probably be easy to parse the RPM spec itself to accomplish this. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkt+sy8ACgkQeiVVYja6o6NRVwCfQakzfTv0MEyN6oFH6uhmIDnz CcYAoKfVBTKkf71ERN05ydVI+tREAcpQ =YqNO -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] git patch email issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/2010 05:43 PM, John Dennis wrote: > > 1) Continue to send patches the way we have making sure Thunderbird is > configured to base64 encode them. Accept the fact that when displayed in > a mail reader any UTF-8 will be garbled and you have to manually force > Thunderbird to render the patch in UTF-8. The contents of the patch > remains uncorrupted, it's just a display issue in the mail reader. > > 2) Configure git-send-email to add the correct SMTP headers and use > git-send-email. This is probably preferred because it's actually correct > from an RFC standpoint. > > Option 2 is actually pretty easy to use. My ~/.gitconfig is set up like > this: > > [sendemail] > smtpserver = smtp.corp.redhat.com > to = freeipa-devel@redhat.com > from = John Dennis > confirm = never > [format] > headers = "Content-Type: text/plain; > charset=\"utf-8\"\nContent-Transfer-Encoding: 8bit\n" > > Those defaults in my .gitconfig means I never have to add any command > line args to either git-format-patch or git-send-email, it's as easy as: > > % git format-patch -1 > % git send-email 0001-some-patch-file > > The downside of using git-send-email is whoever is applying the patch > will have to save the entire email to a file instead of an attachment, > which might be slightly more awkward. But as you can see from above it's > very hard, and in most cases impossible, to get a patch sent as an > attachment to have the correct charset specified. This is a pretty > serious shortcoming and calls into question the use of attachments in > the first place. > The problem with option 2 is that you can only send a single patch as a single email. This makes it difficult to invest a group of patches with a sense that they are meant to sequentially effect a specific result. I for one very often submit two or more patches as attachments to the same email. Furthermore, sometimes it's useful to provide more information about a patch than you put in the commit message. I think 'git send-email' is unsuitable for our purposes, and I strongly recommend the use of base64 encoding. Also, for the record, Thunderbird can be configured to use UTF-8 for incoming and outgoing mail by default. In Thunderbird preferences, go to Display->Formatting->Fonts & Encodings. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkt5f+sACgkQeiVVYja6o6MZpACfcQxZkzo/aRFqOpbOujqSXN6C LsAAniYbAjCbzUasJm4478Q2YOuclaPK =Ue5e -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] add Polish translation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/11/2010 06:45 PM, John Dennis wrote: > On 02/11/2010 06:36 PM, John Dennis wrote: >> Woo ho! We got our first translation, Polish. > > NAK > > Something got screwed up with the encoding when the patch was sent > through email. I need to figure out what went wrong and resubmit it. > I suggest always sending translation patches as forced base-64 encoded attachments. Sometimes the extended character set gets broken by mailman. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkt1PK0ACgkQeiVVYja6o6NDDwCgokzquH9kJPfMOsjeaS7SxVqq ReQAnRYaWMkunFHokAl5oq84aqw+8yMS =vIVJ -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Make child processes exit when parent dies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/11/2009 11:43 AM, Stephen Gallagher wrote: > On 08/11/2009 10:44 AM, Jakub Hrozek wrote: >> On 08/06/2009 05:13 PM, Jakub Hrozek wrote: >>> We could catch most signals the way we do catch SIGTERM and relay them >>> to children. This still wouldn't cover the SIGKILL case where the admin >>> shoots down monitor. This is cross-platform which is of course huge >>> advantage. >>> But in my opinion, we should still use prctl() where available, because >>> it is much cleaner solution -- you don't have to explicitly enumerate >>> all the signals to handle and you can also cover the SIGKILL case. > >> Attached is a patch that says the same in C. > >> Jakub > > Ack > > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel > > Pushed to master. _______ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqBnSIACgkQeiVVYja6o6N3dgCfUYdGUV63W9BBBkeoZH+CRQb8 hJIAn1SPtm0KuDu27Gx+4UJUFV6jyXve =+GZt -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Make child processes exit when parent dies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/11/2009 10:44 AM, Jakub Hrozek wrote: > On 08/06/2009 05:13 PM, Jakub Hrozek wrote: >> We could catch most signals the way we do catch SIGTERM and relay them >> to children. This still wouldn't cover the SIGKILL case where the admin >> shoots down monitor. This is cross-platform which is of course huge >> advantage. > >> But in my opinion, we should still use prctl() where available, because >> it is much cleaner solution -- you don't have to explicitly enumerate >> all the signals to handle and you can also cover the SIGKILL case. > > > Attached is a patch that says the same in C. > > Jakub Ack - ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkqBkYcACgkQeiVVYja6o6Nw2wCfe1mA+9hzZbsbDOdQqj/0K64S SwMAn0+X7+blI3d/WcFEQ7KYh94ccGg0 =ITeU -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Make child processes exit when parent dies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2009 12:55 PM, Dmitri Pal wrote: > if it detects that parent process goes away. Am I wrong? Yes. Orphan children become children of init instead. This is in fact how daemonizing works. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp7DJ8ACgkQeiVVYja6o6OBvACffsiv8YjXvB/tEQ804VZY3a2B kgUAn0qdM4X84Ix3WxgC9XfJFjt498bt =IFJL -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Make child processes exit when parent dies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/06/2009 05:53 AM, Simo Sorce wrote: > On Wed, 2009-08-05 at 18:25 -0400, Dmitri Pal wrote: >> Jakub Hrozek wrote: >>> The attached patch addresses ticket #84. >>> >>> The implementation is unfortunately Linux-specific as it uses the >>> prctl(2) syscall. Ideas how to accomplish this in a cross-platform >>> manner are welcome. >>> >>> Jakub >> How do we fork processes? >> If we just fork and do not daemonize then children should just die >> (system sends sigterm to children AFAIR) when the parent process exits. >> At least that is what used to happen in old days on Solaris, HP and AIX. >> If we fork and then make the process a new process group leader by using >> setpgrp() then it terns into a service. It PPID becomes 1 (AFAIR - have >> done it many years ago). >> If our children are independent processes there is no good way other >> than pass in the IP of the parent at the initialization and periodically >> check if the process is still around and its start time is before child's. >> >> If the problem we are trying to solve is to exit back ends when monitor >> dies we should either keep the children as members of the same group or >> use the periodic check approach. > > I have to say I am a bit surprised about this patch too. > Last time I put my hands on it we were using process groups exactly so > that when monitor is killed all other process die as well. In my > experience this works fine in master. In what cases do this fail ? > > Simo. > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel In the event that the monitor segfaults or is killed with SIGKILL, it terminates immediately and does not signal the children to exit. That is what this is meant to address. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp63QUACgkQeiVVYja6o6NXsgCeJz2quGG9L6u8yjGJu9UBoodZ sUIAnRf4S1nypddjLUKPBg9JzzwHSOlO =UMKV -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New List: sssd development moves
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/2009 12:03 PM, Simo Sorce wrote: > Hello Freeipa and sssd developers and followers, > we've decided to move sssd development to its own mailing list so that > freeipa proper development and sssd are not intermixed. > > sssd is not simply a component of Freeipa although it will be a key > piece of the client functionality, sssd works on its own in contexts > that do not involve Freeipa servers. > So to avoid confusion and to let the 2 projects have a better mail flow > we decided to create a development list for sssd at: > sssd-de...@list.fedorahosted.org > > If you are interested in following sssd development we advice you to > subscribe to this new list. > > Any new patch review and sssd related discussion will be moved to this > new list starting now. > > Have fun, > Simo. > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Correction: the list is at sssd-de...@lists.fedorahosted.org (note the plural lists) You can subscribe here: https://fedorahosted.org/mailman/listinfo/sssd-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5risACgkQeiVVYja6o6PXJgCgoyeh7zXKzCANXxjKr1GeA7cp cHYAoKuD5UZ06cx2hzeIB95zCeba/00g =wo+D -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/05/2009 04:51 AM, Jakub Hrozek wrote:
> On 08/04/2009 09:17 PM, Stephen Gallagher wrote:
>> Patch 1: Ack.
>
>> Patch 2: Nack.
>> In sss_groupadd.c, sss_groupdel.c and sss_groupmod.c:
>> if (data->domain && data->uid && data->domain != dom) {
>> should be data->gid instead.
>
> Thanks, I really need an editor plugin that will give me an electric
> shock anytime I copy-n-paste code..
>
> New patches attached.
>
> Jakub
Pushed to master.
- --
Stephen Gallagher
RHCE 804006346421761
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkp5lm0ACgkQeiVVYja6o6MMPwCeOgvh8mmh/jxGDMM2VoTS/+xo
pNwAoKuTD+mDxputCGVferhvA1FwG7Un
=aclU
-END PGP SIGNATURE-
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix adding to groups on user creation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2009 01:23 PM, Jakub Hrozek wrote: > Fixes a copy-paste error that prevented the -G/--groups parameter of > useradd from working. > > Jakub - Pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5llkACgkQeiVVYja6o6PoDQCglrLPEpuxOGICzegeaBKu9xEH IIMAmQGJDHwXw6CBDECTr/zdhmr09rf+ =ryPh -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Consolidate tevent helpers]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2009 11:05 AM, Jakub Hrozek wrote: > We use several macros that substitute tevent functions not available in > the current F11 release. The attached patch just moves these definitions > to one place in util/util.h to avoid unnecessary duplication. > > Jakub > - Pushed to master - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5ljsACgkQeiVVYja6o6OSbwCfdY0tCVDTamx6HuVm/8AF8Pg/ LckAn3NsMqiRRkfsI9N8SewAYZSO8XEg =zknU -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix typo in function call in pamsrv_cmd.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2009 07:47 AM, Jakub Hrozek wrote: > I was looking into how negative cache is implemented and used in sssd > and spotted a typo in function call name that would break compilation if > HAVE_NEG_CACHE was defined. > > Jakub Nack. This code will all be changing soon, and this may not actually be a typo. - ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5jj4ACgkQeiVVYja6o6PmdwCdGrQeiB+PAvNDQR7/nhMK03uD pZcAoJhNLXuDvQ76pKCyqgUlB8Bs1whU =Yged -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix adding to groups on user creation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2009 01:23 PM, Jakub Hrozek wrote: > Fixes a copy-paste error that prevented the -G/--groups parameter of > useradd from working. > > Jakub Ack - ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5jbYACgkQeiVVYja6o6PumgCdHEPGxSWt0urnBQGyoNJVbZvn +wIAoIn8HRscXsO7g7TCGxtDYKCxOT/1 =aT79 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Make child processes exit when parent dies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2009 07:08 AM, Jakub Hrozek wrote: > The attached patch addresses ticket #84. > > The implementation is unfortunately Linux-specific as it uses the > prctl(2) syscall. Ideas how to accomplish this in a cross-platform > manner are welcome. > > Jakub Nack. Why are you creating a new configure test for prctl? Just change AC_CHECK_FUNCS(sigprocmask sigblock sigaction getpgrp) to AC_CHECK_FUNCS(sigprocmask sigblock sigaction getpgrp prctl) The effect is identical. (It produces HAVE_PRCTL in config.h) - ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5jIgACgkQeiVVYja6o6PK+wCfadFuewMcWcdZWyXhdQ20gyvC X0QAoKQSZ+2OJ2lXsI57vLJn61iRSphs =WKik -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Consolidate tevent helpers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2009 11:05 AM, Jakub Hrozek wrote: > We use several macros that substitute tevent functions not available in > the current F11 release. The attached patch just moves these definitions > to one place in util/util.h to avoid unnecessary duplication. > > Jakub > Looks fine to me. Ack. - ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5de8ACgkQeiVVYja6o6O7GwCfap/oC4x3Rq59UTrIx4EoL+Aw boAAniEfs9wZPq6QxvMIIUItbgsfzu4v =QfXk -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/05/2009 04:51 AM, Jakub Hrozek wrote:
> On 08/04/2009 09:17 PM, Stephen Gallagher wrote:
>> Patch 1: Ack.
>
>> Patch 2: Nack.
>> In sss_groupadd.c, sss_groupdel.c and sss_groupmod.c:
>> if (data->domain && data->uid && data->domain != dom) {
>> should be data->gid instead.
>
> Thanks, I really need an editor plugin that will give me an electric
> shock anytime I copy-n-paste code..
>
> New patches attached.
>
> Jakub
Ack.
-
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
- --
Stephen Gallagher
RHCE 804006346421761
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkp5dR8ACgkQeiVVYja6o6OHhQCdGjEnAhY8xug8ILQemkgm7n8X
KcAAoJdITm9UhWvuEqaXEY4lDD3Xcb7i
=VsSW
-END PGP SIGNATURE-
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] contribution policy update, what's next
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2009 05:58 PM, Karsten Wade wrote: > Yesterday I lurked on a call with Stephen Gallagher and Richard > Fontana, legal expert on FLOSS licensing. > > Due to audio problems, I wasn't able to fully participate, but I did > hear an implicit agreement to the contribution policy draft I wrote > up. > > I think it may need a few tweaks; I'm going to propose some and get > Richard back on the phone to get an explicit OK from him. > > Stephen -- since SSSD has it's own upstream space, do you want me to > work up a draft contribution policy for there? That is, I know your > licensing questions are still open, but we can get a draft with > alternate endings depending on potential outcomes. > Yes, that would be a good next step. > == What's next == > > With the CLA requirement removed, next I have to enumerate exactly > where it stands as a barrier and figure out how to remove it. There > are some other technological barriers to reconsider. > > For any system we require a CLA for e.g. fedorahosted.org access, that > is just a human check process, right? We remove the CLA requirement > when considering people for SCM access. > > For patches, we need to figure out how to structure it so that people > can contribute patches via this list with it clear the patch is > submitted under the contribution policy. Perhaps a single sentence + > URL at the beginning of each patch email? It seems to me we could > also have people add themselves to a list via the wiki (history proves > the real user did it), and if you are on there, you don't need to > include the sentence in your patches. Obviously a better solution is > needed, meaning we need to run our own directory or rely more upon an > external (e.g. Fedora Account System). We might be able to get by > with OpenID, for example. Editing the SSSD wiki already requires a Fedora account, so if we go with the "adding your name to a wiki page" idea, I think that's probably completely sufficient. On the other hand, having a Fedora account already implies that you have signed the Fedora CLA. > > For the wiki, we can remove the human requirement, but we still have a > technical barrier for entry. It would be smoothest if people could: > > 1. Sign up for an account > 2. In that sign-up they read the contribution policy and agree to it >as part of signing up > 3. They get wiki edit access > > All automatic with no human intervention required. > > Figuring out solutions there is my next important task once we have a > solid contribution policy to refer to. > > Meanwhile, if we can widen the field of people with "Create wiki users > upon request", that would be good. I volunteer. Maybe for now an > email request for access to a freeipa-* list would suffice? > > - Karsten > Our present wiki comes to us through the Fedorahosted servers, and as such relies on the users having a Fedora account themselves. Do you feel that this restriction is to severe? > > -------- > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp5cfAACgkQeiVVYja6o6Mm7ACgnl2VCh61h6aTb/KrRFJxHlfO ttwAniGdVQruGif/D0lfVwyaPOj/OUS5 =ZFt7 -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] Allow the tools to operate on fully qualified names
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/01/2009 11:27 AM, Jakub Hrozek wrote:
> Hello,
> Attached are two patches that allow the tools to operate on fully
> qualified names, that is, names in the form of u...@domain.
>
> [PATCH 1/2] Move parsing of names and domains into util/
> I used the already existing facility for parsing names from the
> responder. This patch moves it into util/ for general consumption.
>
> [PATCH 2/2] Parse fully qualified names in tools
> Allow adding users into different domains not only by specifying
> ID directly but also by specifying fully qualified name. Exit when
> both specifications are used in conflict.
>
> Thanks,
> Jakub
>
Patch 1: Ack.
Patch 2: Nack.
In sss_groupadd.c, sss_groupdel.c and sss_groupmod.c:
if (data->domain && data->uid && data->domain != dom) {
should be data->gid instead.
-
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
- --
Stephen Gallagher
RHCE 804006346421761
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkp4iVMACgkQeiVVYja6o6PuCACdFPR0VlvjIhhkAY5ORtxMlGnl
X2IAni33p4SF6L2IcKbv1j8eMveJZ6eG
=DU86
-END PGP SIGNATURE-
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] PATCH: fix race condition in ldap driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2009 12:54 PM, Simo Sorce wrote: > Jenny found that on her machine a race condition could prevent operation > to happen in the right order. > Interestingly this never happened on my machine that has a somewhat > higher latency vs the ldap server. > > This patch simply serializes handling replies from ldap using a store > and forward technique. > > Simo. > > > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack and pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4cuAACgkQeiVVYja6o6PozwCfZseaaFZ0pqhdFmdvx0ju9X8Y +3AAnjsOppLvmJ1hgcRR8VTn1B8CMJ0P =QuMU -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Files to builde SSSD package 0.4.1 (not working yet)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/2009 09:47 AM, Miguel P.C. wrote: > Hi Stephen, hola everyone, > > > I'm working with a computer that is not my usual "build computer" so I'm > trying to get all I need installed and give it a try. > Now I'm on holidays so I'm spending as little time on anything that > makes me think as possible. (I need a break, you know!). > Anyway, I'm finding time to finish some little things left from work > this week, as next two I won't have internet access. > I'll try to give you a bit of a report on how sssd builds on Karmic B4 > friday (... if possible). > > BTW I'll use SSSD HEAD and Karmic with the latest updates. Is that OK? > > M* > Yeah, that's preferable. As I've said, we want to support Ubuntu with the 0.5.0 release. We're not really planning to attempt to get 0.4.1 to work (too much has changed/improved since then that it would be difficult and backwards to try and work from there) > > > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp4ZpsACgkQeiVVYja6o6NuUACdGau8cwzuBW+ywLAL3qpJGQmB ALIAnjALFwb5L9oPuhwlFR23RczoEJWI =A6O+ -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] PATCH: fixes LDAP driver searches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/03/2009 01:44 PM, Simo Sorce wrote: > On Mon, 2009-08-03 at 13:34 -0400, Stephen Gallagher wrote: >> On 08/03/2009 01:18 PM, Simo Sorce wrote: >>> Stupid typo was making all searches just vanish in thin air. >>> Should work fine with this patch. > >> Nack. >> >> You're testing if(ret==EOK) below the switch statement, but it's not >> initialized, and it's only set for >> case LDAP_RES_BIND: >> case LDAP_RES_SEARCH_RESULT: >> case LDAP_RES_MODIFY: >> case LDAP_RES_ADD: >> case LDAP_RES_DELETE: >> case LDAP_RES_MODDN: >> case LDAP_RES_COMPARE: >> case LDAP_RES_EXTENDED: >> case LDAP_RES_INTERMEDIATE: > > Right, that check is actually not really needed anymore. > Attached patch that changes the code so that the useless check is > removed. > > Simo. > > > > > > > _______ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel Ack and pushed to master. - -- Stephen Gallagher RHCE 804006346421761 Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkp3JIMACgkQeiVVYja6o6OZ2gCfUjXDB7qJTwqSLmQ6HZbDiczM 4fsAoKiS1pvS76ItQCFNl3Hu17NlKIPb =m1Dm -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
