Re: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption
On 11/16/2013 04:17 AM, Simo Sorce wrote: On Fri, 2013-11-15 at 14:26 +0100, Petr Vobornik wrote: It's quite a lot of patches so I did not attach them here. You can see the code in my private repo: git://fedorapeople.org/~pvoborni/freeipa.git branch 'rcue'. I can't see it listed here: http://fedorapeople.org/cgit Can you `touch ~/public_git/freeipa.git/git-daemon-export-ok` so that cgit will pick it up ? Simo. Done -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 111] ipa-client-install: Publish CA certificate to systemwide store
On 11/15/2013 03:36 PM, Rob Crittenden wrote:
Tomas Babej wrote:
On 11/15/2013 02:46 PM, Ana Krivokapic wrote:
On 11/13/2013 02:57 PM, Tomas Babej wrote:
On 09/27/2013 10:14 AM, Martin Kosek wrote:
On 09/26/2013 04:46 PM, Jan Cholasta wrote:
On 26.9.2013 12:59, Tomas Babej wrote:
On 09/26/2013 12:54 PM, Jan Cholasta wrote:
On 24.9.2013 18:14, Nalin Dahyabhai wrote:
On Tue, Sep 24, 2013 at 01:30:10PM +0200, Jan Cholasta wrote:
We discussed this with Tomáš off-line and it turns out that
ipa-client-install fails if the CA cert is not added to
/etc/pki/nssdb.
However, according to p11-kit docs it should work:
http://p11-glue.freedesktop.org/doc/p11-kit/trust-nss.html. I
wonder what needs to be done to make it work in IPA...
On my system, there's no symlink to libnssckbi.so (or the right
location
in the link farm under /etc/alternatives) in /etc/pki/nssdb, so
that
database isn't going to automatically pull in the list of
trusted CAs
that p11-kit maintains.
Whether the database under /etc/pki/nssdb should automatically
include
the usual set of trust anchors is probably a different
conversation.
Thanks for the info.
Tomáš, the patch is fine then. I have one more nitpick though:
why did
you change the default NSS database to the NSS database? The
database in /etc/pki/nssdb *is* the default NSS database, so
please
change it back. Also I think systemwide CA trust database is
better
than systemwide CA store.
Honza
I fixed the descriptions. Updated patch attached.
Tomas
Thanks.
There's one more thing: we should probably check if
/usr/bin/update-ca-trust
exists before using it, for the sake of cross-distro compatibility.
Right. I am also thinking if this functionality should not be
somehow integrated into the platform files so that it can be
overriden in platforms that do not have the systemwide storage.
Martin
Updated patch attached, requires my patch 130.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
The patch works fine; a couple of nitpicks:
1) The import of root_logger in services.py.in is unused.
2) In ipa-client-install, you log the return values of functions
insert_ca_cert_into_systemwide_ca_store() and
remove_ca_cert_from_systemwide_ca_store(). But these functions do not
return any values, so you will always be logging `None`.
Thanks for the review,
I removed the code (it was meant for debugging purposes only).
Updated patch attached.
Adding the CA to the NSS cert database is considered a fatal error.
Should adding it to the global trust database be fatal as well?
I don't know the answer, but if we want to do this at some point
should these functions return True/False to denote success/failure?
rob
I don't think it should be considered fatal, at least not now.
I updated the patch to return the success/failure status, even though,
this could be done when it will be required. But doesn't hurt anything
either, at least other platform files will develop systemwide CA store
functions with this approach in mind.
Updated patch attached.
--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org
From cf08fabea67b4594a2a97154ef6568a6db4e1f0a Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Tue, 24 Sep 2013 10:54:57 +0200
Subject: [PATCH] ipa-client-install: Publish CA certificate to systemwide
store
During the installation, copy the CA certificate to the systemwide
store (/etc/pki/ca-trust/source/anchors/ipa-ca.crt) and update the
systemwide CA database.
This allows browsers to access IPA WebUI without warning out of the
box.
https://fedorahosted.org/freeipa/ticket/3504
---
ipa-client/ipa-install/ipa-client-install | 13 +-
ipapython/platform/fedora19/__init__.py | 67 ++-
ipapython/services.py.in | 11 -
3 files changed, 88 insertions(+), 3 deletions(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 7095e922663af73edae5a537a923888794b74879..e79cb48b04e7bdf23f6fd757e022e57dbb544640 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -673,6 +673,9 @@ def uninstall(options, env):
root_logger.warning('Please remove /etc/ipa/default.conf manually, '
'as it can cause subsequent installation to fail.')
+# Remove the CA cert from the systemwide certificate store
+ipaservices.remove_ca_cert_from_systemwide_ca_store(CACERT)
+
# Remove the CA cert
try:
os.remove(CACERT)
@@ -2403,12 +2406,20 @@ def install(options, env, fstore, statestore):
return CLIENT_INSTALL_ERROR
root_logger.info(Configured /etc/sssd/sssd.conf)
+# Add the CA to the platform-dependant systemwide CA store
+
Re: [Freeipa-devel] idempotent installer [from LinuxAlt 2013]
I don't really agree with you that it is all that difficult to get a real LDAPv3 server up and running. I've built quite a few of them over the years and what I mostly found was it was just poorly documented.Although I will say putting it all into one uniform toolset is ambitious, its not the first time its been attempted SuSE had a similar project based on openldap Perl and Java before Novel bought and them and killed it which was very similar.1) Kerberos V servers are the easiest thing in the world to setup as long as you aren't using LDAP as the backend database. I've done several presentations over the last 14 years where I was able to teach an entire room how to build and manage a Kerberos V infrastructure in 2 Hours or less. Furthermore you can even configure PAM To do Kerberos auth without a keytab file on the host as long as you except the fact that users will not be able to change their passwords on those hosts, which is fantastic for edge facing host such as web servers.2) LDAP servers are not easy to understand at first but once you get use to the but once you create some LDIF templates its not too ad. There were always 3 difficult parts though two of which are made easier by 389 server but are hardly new, the first time I saw 389 Server I had a nasty flashback of supporting SCO servers running Netscape Directory Server syncing to NT4 domain controllers. The finally one which it works around via plugins is most applications despite saying they are LDAPv3 compatible are really doing LDAPv2 over TLS. Simply put instead of doing a bind to authenticate users like the RFC's specify they are searching for the password field in the users account and validating it themselves.3) The biggest difficulties people always had were always in the SASL layer the Cyrus SASL project has almost no real practical documentation and many people in the early 2000's were writing documentation and presentations based on a site written by someone who claimed to be an LDAPv3 expert that appeared in the late 90s which was flat out wrong. To be honest the only good documentation on Cyrus SASL I've ever seen is on the Postfix site.4) The other big difficulty was stabilizing of nscd. I can't tell you how many times I've seen people complain about it who never looked at tuning it. With its default setting its tuned for a desktop with local auth not a server using LDAP auth. Most of the problem with it centered around using the memory mapped file mode instead of the sockets connection mode, that with having too low a configured thread limit to really handle server activity was a recipe for disaster.5) TLS can be easy if you are willing to pay for a 3rd party wildcard cert. Self signed certs have always been a bad idea and incompatible with LDAPv3. DogtagPKI does make it easier to create a more robust CA/PKI infrastructure but again its nothing new its just an updated version of Netscape's Certificate manager.Now that said I'm glad to see RedHat bought all that great Netscape code and GPLed it because it was always good codebase which was neglected by SUN and AOL, and I think Red Hat and the free speech software community have been and will continue to be greater custodians of that codebase.What most impresses me with FreeIPA is the fact that its pushed fixes into the MIT Kerberos V project for problems that have been know about for over a decade which in the past were declared as limitations rather than bugs by its original developers. While I still do firmly believe Heimdal Kerberos is a far superior Kerberos server for the first time ever I now consider MIT Kerberos V stable enough for mission critical environments which is a huge step forward.-- Sent from my HP Pre3On Nov 15, 2013 11:44, Derek Moore derek.p.mo...@gmail.com wrote: Practically though, I think an idempotent installer opens a lot of cans of worms. Do we limit some answers to their original? Take for instance the REALM. Can someone change it on-the-fly? It would have some deep repercussions. Similarly, changing the hostname. There are all kinds of corner cases. This is very true! Nothing is quite so complex as realm controllers for krb5+ldap+nss+sssd+bind+ca+blah+blim+blam!You guys sure have your work cut out for you!About the only other Red Hat projects I've seen that are nearly as complex as FreeIPA are oVirt OpenShift (ok, maybe Cluster Suite, too), in terms of fully taking over the host being configured and the insane amount of inter-dependencies therein and the fragility of installers (installers from nightlies, alpha, or beta; I like to live on the bleeding edge). In ~2002 I setup my own hand-rolled krb5+ldap+nss realm cluster for virtual domain web email hosting, and I swear that took me weeks. It is a joy to have something like FreeIPA these days. Once again I'll take the opportunity to pimp otopi, even if it may not be the right solution for you guys, they are trying to solve similar problems in a similarly complex
Re: [Freeipa-devel] [PATCH] 0084 Make sure state of services is preserved after client uninstall
On 11/15/2013 05:03 PM, Tomas Babej wrote: On 11/07/2013 05:25 PM, Ana Krivokapic wrote: Hello, This patch addresses ticket https://fedorahosted.org/freeipa/ticket/3790. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Looking good.. I have two questions: 1.) Nitpick: I'd suggest we rename the save_state(service) and restore_state(service) to more descriptive save_service_state/restore_service_state? Well, if the argument you are passing to these function does not have a name which suggests it is a service (which it should have anyway), you can do: `save_state(service=x)`. So I don't think `save_service_state(x)` is more readable. 2.) There are other places in ipa-client-install where we save and restore the state of the service. Having abstracted that into a function, should we use this at other places as well? I looked at other instances in ipa-client-install where service states are saved and restored. It seems that each of these cases includes some custom logic which does not make it possible to use the two functions I've added. -- Tomas Babej Associate Software Engeneer | Red Hat | Identity Management RHCE | Brno Site | IRC: tbabej | freeipa.org -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0258-0265 Add schema updater based on IPA schema files
On 11/15/2013 05:28 PM, Petr Viktorin wrote: On 11/15/2013 02:09 PM, Petr Viktorin wrote: On 11/11/2013 04:18 PM, Ana Krivokapic wrote: On 11/11/2013 02:53 PM, Ana Krivokapic wrote: On 11/11/2013 12:32 PM, Petr Viktorin wrote: On 11/07/2013 02:34 PM, Ana Krivokapic wrote: On 11/01/2013 03:26 PM, Petr Viktorin wrote: On 09/13/2013 06:44 PM, Petr Viktorin wrote: On 08/01/2013 04:52 PM, Petr Viktorin wrote: Hello, With these patches, schema updates will be based on the ldif files we use for installation. https://fedorahosted.org/freeipa/ticket/3454 This is a RFE, here is the design doc: http://www.freeipa.org/page/V3/Improved_schema_updater I found and filed a bug in python-ldap[0]: it sometimes ignores parts of schema LDIFs when parsing them. Patch 0275 works around the bug. Please apply on top of 0258-0265 (they still apply cleanly). [0] https://bugzilla.redhat.com/show_bug.cgi?id=1007820 The recent ipaldap patches resulted in a small conflict. Attaching rebased patches. I have tested the patches and overall they seem to work fine. Some questions/comments are below. Patch 258: You catch `ldap.LOCAL_ERROR` in the `connect()` function, which is called from `__init__()`, so no need to catch it again in `__init__()`. I've added a comment instead of the try/catch Patch 259: ACK Patch 260: # Usually the modlist order does not matter. # However, for schema updates, we want 'attributetypes' before # 'objectclasses'. # A simple sort will ensure this. modlist.sort() Since `modlist` is a list of tuples, it is sorted by the first elements in the tuples, then by the seconds elements, etc. Which means the resulting list will be sorted by the modification type first (`MOD_ADD`, `MOD_DELETE`, etc), and by `attributetypes`/`objectclasses` second. Was this the desired effect? I've added a sort key; it should be safer now. Hmm, the key you added still retains the default sorting behavior - it will sort by the first elements of the tuples first. Since we need sorting by the second elements, I think the key here should be: key=lambda m: m[1].lower() Right, I see what you mean. I've made the change and tested it a bit. Patch 261: Man page updates look good, but several options in the man page have 3 dashes in the long form instead of 2. I have attached a mini-patch that fixes this along with a couple of typos in the man page. Feel free to squash it to your patch 261. Nice catch! Squashed. Patch 262: Whitespace warnings. I didn't see any with my settings; could you be more specific? $ git am ~/freeipa-pviktori-0262.3-Remove-schema-modifications-from-update-files.patch Applying: Remove schema modifications from update files /home/ana/freeipa/.git/rebase-apply/patch:497: new blank line at EOF. + /home/ana/freeipa/.git/rebase-apply/patch:693: new blank line at EOF. + warning: 2 lines add whitespace errors. Thanks! fixed. [...] I'm also seeing some errors when testing the patches. During ipa-server-install, restarting of DS is failing: [22/38]: restarting directory server ipa : CRITICAL Failed to restart the directory server (Command '/bin/systemctl restart dirsrv@IDM-LAB-ENG-BRQ-REDHAT-COM.service' returned non-zero exit status 1). See the installation log for details. The dirsrv log indicates that one of the ldif files is not syntactically valid: [11/Nov/2013:16:10:21 +0100] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM/schema/60basev3.ldif (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class (2.16.840.1.113730.3.8.12.7 NAME 'ipaKrb5DelegationACL' SUP groupOfPrincipals STRUCTURAL MAY ( ipaAllowToImpersonate $ ipaAllowedTarget ) EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v3' ): Failed to parse objectclass, error(2) at ( distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v3' )) [11/Nov/2013:16:10:21 +0100] dse - Please edit the file to correct the reported problems and then restart the server. Are you seeing this in your setup? No, ipa-server-install works for me. Does this happen every time? I can't find an error in the syntax there. The bug was only visible on f20 which has a new version of 389. Thanks to Nathan Kinder for spotting the mistake (matching rulesyntax on an objectClass) for me, and to 389's new schema parser for being nice and strict. I'm only attaching the changed patch. Thanks, it works well now. ACK for the whole patch set. -- Regards, Ana Krivokapic Associate Software Engineer FreeIPA team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCHES] 0258-0265 Add schema updater based on IPA schema files
On 11/18/2013 04:12 PM, Ana Krivokapic wrote: On 11/15/2013 05:28 PM, Petr Viktorin wrote: On 11/15/2013 02:09 PM, Petr Viktorin wrote: On 11/11/2013 04:18 PM, Ana Krivokapic wrote: On 11/11/2013 02:53 PM, Ana Krivokapic wrote: On 11/11/2013 12:32 PM, Petr Viktorin wrote: On 11/07/2013 02:34 PM, Ana Krivokapic wrote: On 11/01/2013 03:26 PM, Petr Viktorin wrote: On 09/13/2013 06:44 PM, Petr Viktorin wrote: On 08/01/2013 04:52 PM, Petr Viktorin wrote: Hello, With these patches, schema updates will be based on the ldif files we use for installation. https://fedorahosted.org/freeipa/ticket/3454 This is a RFE, here is the design doc: http://www.freeipa.org/page/V3/Improved_schema_updater I found and filed a bug in python-ldap[0]: it sometimes ignores parts of schema LDIFs when parsing them. Patch 0275 works around the bug. Please apply on top of 0258-0265 (they still apply cleanly). [0] https://bugzilla.redhat.com/show_bug.cgi?id=1007820 The recent ipaldap patches resulted in a small conflict. Attaching rebased patches. I have tested the patches and overall they seem to work fine. Some questions/comments are below. Patch 258: You catch `ldap.LOCAL_ERROR` in the `connect()` function, which is called from `__init__()`, so no need to catch it again in `__init__()`. I've added a comment instead of the try/catch Patch 259: ACK Patch 260: # Usually the modlist order does not matter. # However, for schema updates, we want 'attributetypes' before # 'objectclasses'. # A simple sort will ensure this. modlist.sort() Since `modlist` is a list of tuples, it is sorted by the first elements in the tuples, then by the seconds elements, etc. Which means the resulting list will be sorted by the modification type first (`MOD_ADD`, `MOD_DELETE`, etc), and by `attributetypes`/`objectclasses` second. Was this the desired effect? I've added a sort key; it should be safer now. Hmm, the key you added still retains the default sorting behavior - it will sort by the first elements of the tuples first. Since we need sorting by the second elements, I think the key here should be: key=lambda m: m[1].lower() Right, I see what you mean. I've made the change and tested it a bit. Patch 261: Man page updates look good, but several options in the man page have 3 dashes in the long form instead of 2. I have attached a mini-patch that fixes this along with a couple of typos in the man page. Feel free to squash it to your patch 261. Nice catch! Squashed. Patch 262: Whitespace warnings. I didn't see any with my settings; could you be more specific? $ git am ~/freeipa-pviktori-0262.3-Remove-schema-modifications-from-update-files.patch Applying: Remove schema modifications from update files /home/ana/freeipa/.git/rebase-apply/patch:497: new blank line at EOF. + /home/ana/freeipa/.git/rebase-apply/patch:693: new blank line at EOF. + warning: 2 lines add whitespace errors. Thanks! fixed. [...] I'm also seeing some errors when testing the patches. During ipa-server-install, restarting of DS is failing: [22/38]: restarting directory server ipa : CRITICAL Failed to restart the directory server (Command '/bin/systemctl restart dirsrv@IDM-LAB-ENG-BRQ-REDHAT-COM.service' returned non-zero exit status 1). See the installation log for details. The dirsrv log indicates that one of the ldif files is not syntactically valid: [11/Nov/2013:16:10:21 +0100] dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-IDM-LAB-ENG-BRQ-REDHAT-COM/schema/60basev3.ldif (lineno: 1) is invalid, error code 21 (Invalid syntax) - object class (2.16.840.1.113730.3.8.12.7 NAME 'ipaKrb5DelegationACL' SUP groupOfPrincipals STRUCTURAL MAY ( ipaAllowToImpersonate $ ipaAllowedTarget ) EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v3' ): Failed to parse objectclass, error(2) at ( distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v3' )) [11/Nov/2013:16:10:21 +0100] dse - Please edit the file to correct the reported problems and then restart the server. Are you seeing this in your setup? No, ipa-server-install works for me. Does this happen every time? I can't find an error in the syntax there. The bug was only visible on f20 which has a new version of 389. Thanks to Nathan Kinder for spotting the mistake (matching rulesyntax on an objectClass) for me, and to 389's new schema parser for being nice and strict. I'm only attaching the changed patch. Thanks, it works well now. ACK for the whole patch set. Thank you! Pushed to master: 2bc7803b69d15a246486ab5c8a44ead7593e8e90 -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption
On 11/15/2013 05:43 PM, Petr Viktorin wrote: On 11/15/2013 03:28 PM, Petr Vobornik wrote: On 11/15/2013 02:40 PM, Petr Viktorin wrote: On 11/15/2013 02:26 PM, Petr Vobornik wrote: Hello list, this is a first part of RCUE adoption effort. Main themes of this patch set are: - use RCUE navigation https://fedorahosted.org/freeipa/ticket/3902 - new styles for textboxes, textareas, radio/checkbox buttons and buttons- part of https://fedorahosted.org/freeipa/ticket/3904 - new internal form layout (tables replaced by divs) - layout does not have fixed size https://fedorahosted.org/freeipa/ticket/3435 - new dialog styles + removed dependency on jQuery UI dialog - icons replaced by Font Awesome glyphs Example is at: http://pvoborni.fedorapeople.org/rcue/ Some reasonings and additional info: 1. RCUE includes Bootstrap which defines o lot of styles for a lot of things. That messed up the UI and therefore I did the form changes now. 2. jQuery UI is pretty big lib and we used it only for dialog and buttons. Buttons were replaced by RCUE buttons so removal of dialog dependency was a obvious step to get rid of the whole lib. The lib is removed from main UI but is still present in separate pages - will be removed later. 3. Dojo and jQuery were upgraded to latest versions.https://fedorahosted.org/freeipa/ticket/2811 This approach was ACKed by Kyle from a design perspective with a note that we will review and fixed some styling after second phase. We should not release until then. The second phase, which I'm working on right now, will consist of: * login screen https://fedorahosted.org/freeipa/ticket/3903 * new styles for standalone pages * necessary responsive enhancement (the ultimate future goal is responsive layout) It's quite a lot of patches so I did not attach them here. You can see the code in my private repo: git://fedorapeople.org/~pvoborni/freeipa.git branch 'rcue'. Wow. Do we really need all these third-party fonts and styles in our repo? It's common in Web development to offer all versions and let the browser to choose one. Since FreeIPA Web UI supports IE9+ we can safely reduce the font files only to .woff fonts http://caniuse.com/woff. We can also discard all Italic fonts (not used atm). Fedora 20 has a new feature called Web Assets http://fedoraproject.org/wiki/Changes/Web_Assets which should solve such bundles. I'm not convinced that it's in usable state atm. That doesn't answer the question of why we need third-party compiled assets in the repo. Fedora spec files can also have multiple Sources, if we need to bundle for distribution. I worry that it will be just source of build errors and such. For example I would like to have access to the files during development without running rpm build or using crystal ball to figure out what is needed and where to get it. Now I would suggest to use Bower http://bower.io/ to solve it, but it requires Node.js so I won't do that. Here is some information about possible sources. Does it look usable to you in any way? 1. Open Sans - hard to find usable source, they should be in googlefontdirectory http://code.google.com/p/googlefontdirectory/ but that's 2.5GB+ Mercuial repo... - some unofficial source (can be used by Bower): https://github.com/FontFaceKit/open-sans It has a bit different font-face declaration which would require additional changes 2. Overpass - official distribution [1] contains only .ttf fonts - .woff version is in git repo https://git.fedorahosted.org/cgit/overpass-fonts.git 3. Font Awesome - provides tarball http://fontawesome.io/assets/font-awesome-4.0.3.zip - should not be a problem if I don't count .less files which required some changes because lesscpy could not process them Fedora doesn't have any standalone .woff font packaged. [1] https://fedorahosted.org/releases/o/v/overpass-fonts/Overpass-Fonts-1.01.tar.gz -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH 0016] Add RADIUS proxy support to ipalib CLI
On 11/15/2013 12:34 PM, Petr Viktorin wrote: On 11/12/2013 12:17 AM, Nathaniel McCallum wrote: On Fri, 2013-11-08 at 13:26 +0100, Petr Viktorin wrote: We've since decided that we'll carry LDAP content updates only in update files, so you can leave indices.ldif referint-conf.ldif unchanged. Schema, on the other hand, will still be in ldif files (and soon *only* in ldif files). Heads up: this was merged. When you get a merge conflict just remove the schema update file. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] ACI changes overview/roadmap
Hello, We had a private conversation about time management that grew into a design discussion, so I'm moving it to the appropriate list. This is about ACI changes: https://fedorahosted.org/freeipa/ticket/3566 The work is now tracked by additional several tickets (and corresponding design documents). In order of planned completion: https://fedorahosted.org/freeipa/ticket/4034 - New permissions system https://fedorahosted.org/freeipa/ticket/4032 - Anonymous and All permissions https://fedorahosted.org/freeipa/ticket/4033 - Managed permissions https://fedorahosted.org/freeipa/ticket/4035 - ACI audit tool On 11/18/2013 07:49 PM, Simo Sorce wrote: On Mon, 2013-11-18 at 19:29 +0100, Petr Viktorin wrote: On 11/18/2013 06:19 PM, Dmitri Pal wrote: Please factor in impact on the extensibility and API. * Regarding extensibility: Right now we say to add schema, create plugin and things would work. With this change we need clear guidance on what ACI changes need to be made and how they need to be made when IPA is customized. We actually do ask What are the ACIs for your entries? in http://www.freeipa.org/page/General_considerations I'd like to have the default ACI definitions for plugins in the plugin code, next to things like default_attributes, attribute_members, password_attributes, etc. So this is contained in the create plugin step, with all plugins available as examples. I'm attaching a patch from the set I sent earlier (rejected because more ground work is needed); it shows the changes I envision would be needed in a plugin. (re-attaching for the list to see) +1 this should make ACI more digestible too, as you can lok at them in the context of the plugin that uses them. However we must be careful with conflicting ACIs, we need to come up with a well know procedure to handle cases where one plugin may try to create permissions that conflict with those of another plugin. We'll only have allow ACIs so changes here will not reduce functionality (but possibly security). You'll notice that this style only supports attaching permissions to the object(s) provided by the plugin. Any other permissions would have to be supplied in update files, as today, so they'd hopefully receive the attention they do today. Or more, since they'd be exceptions. * API/CLI I suspect there will be case when ACI prevents exposure of an attribute that was assumed by some logic to always be availble. I suspect API would blow up badly. We need to prevent this and make sure we have test that run API/CLI when different attributes are not readable. The main use case here is configuring what is readable by anonymous vs. by logged-in users, and you always need a ticket to use the API. But it is correct that the API will currently fail in pretty mysterious ways if read access is denied. Perhaps we should modify ipaldap's get_entry friends to double-check attribute-level rights on the requested attributes? Anyway we'll probably need to say that if you explicitly un-allow access to an attribute, you're pretty much on your own. I think we need to change this. There may be legitimate reason to require an emergency block of an attribute for an environment, and if at all possible that should not completely break all functionality. I agree here. If you block writing to the attribute it is ok to break functions that change stuff. If you block reading we should probably replace the attribute with a special constructs that causes the plugin to show a good error message or to blank out the relevant field and display a message that tells why part of the information is not available. Yes, for most attributes we can do that with a framework change to always check attribute-level rights. The other part is attributes we actually process rather. From a quick scan we seem to be doing a fairly good job always checking if an attribute is present before using it, but we need to - Ensure that is always the case, and - Make sure the functionality makes sense if the attribute is hidden by ACIs rather than just doesn't exist. Think something like not seeing some don't delete flag on an entry. That's a monumental task that we can't reasonably finish (or test). So we need to warn users they should know all the implications before hiding attributes. -- Petr³ From f4db999711d2bc48e00db08bf4976dc588d91db4 Mon Sep 17 00:00:00 2001 From: Petr Viktorin pvikt...@redhat.com Date: Thu, 19 Sep 2013 17:41:04 +0200 Subject: [PATCH] Add Object metadata and update plugin for managed permissions The default read permission is added for User as an example. Part of the work for: https://fedorahosted.org/freeipa/ticket/3566 Design: http://www.freeipa.org/page/V3/Managed_Read_permissions --- ipalib/plugins/baseldap.py | 1 + ipalib/plugins/user.py | 25 + .../install/plugins/update_managed_permissions.py | 103 + 3 files changed, 129 insertions(+) create
Re: [Freeipa-devel] [PATCH] 463-530 First part of RCUE adoption
On 11/18/2013 06:17 PM, Petr Vobornik wrote: On 11/15/2013 05:43 PM, Petr Viktorin wrote: On 11/15/2013 03:28 PM, Petr Vobornik wrote: On 11/15/2013 02:40 PM, Petr Viktorin wrote: On 11/15/2013 02:26 PM, Petr Vobornik wrote: [...] It's quite a lot of patches so I did not attach them here. You can see the code in my private repo: git://fedorapeople.org/~pvoborni/freeipa.git branch 'rcue'. Wow. Do we really need all these third-party fonts and styles in our repo? It's common in Web development to offer all versions and let the browser to choose one. Since FreeIPA Web UI supports IE9+ we can safely reduce the font files only to .woff fonts http://caniuse.com/woff. We can also discard all Italic fonts (not used atm). Fedora 20 has a new feature called Web Assets http://fedoraproject.org/wiki/Changes/Web_Assets which should solve such bundles. I'm not convinced that it's in usable state atm. That doesn't answer the question of why we need third-party compiled assets in the repo. Fedora spec files can also have multiple Sources, if we need to bundle for distribution. I worry that it will be just source of build errors and such. For example I would like to have access to the files during development without running rpm build or using crystal ball to figure out what is needed and where to get it. A curious requirement, bundling everything in the Git repo. I'm afraid I don't really understand your thinking here. In the world I live in, a repo should contain upstream source files. Third-party dependencies must be listed, and need to be installed for building/using the project, and compiled artifacts should be compiled from sources. Having third-party compiled stuff means bundling, forking, and other similar swear words. Needing a crystal ball to locate the source is a packager's nightmare. And this patchset put us in that situation, for any kind of checking if these are up to date or what the licenses are. Now I would suggest to use Bower http://bower.io/ to solve it, but it requires Node.js so I won't do that. Here is some information about possible sources. Does it look usable to you in any way? 1. Open Sans - hard to find usable source, they should be in googlefontdirectory http://code.google.com/p/googlefontdirectory/ but that's 2.5GB+ Mercuial repo... - some unofficial source (can be used by Bower): https://github.com/FontFaceKit/open-sans It has a bit different font-face declaration which would require additional changes 2. Overpass - official distribution [1] contains only .ttf fonts - .woff version is in git repo https://git.fedorahosted.org/cgit/overpass-fonts.git 3. Font Awesome - provides tarball http://fontawesome.io/assets/font-awesome-4.0.3.zip - should not be a problem if I don't count .less files which required some changes because lesscpy could not process them So we have a fork there as well? Did you try to submit the patch upstream? So, now we need to package these so that we can depend on them, right? At least that's how it works with any other project we want to depend on if it's not in Fedora yet. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
