Re: [Freeipa-devel] [PATCH] 011 Use sys.exit to quit scripts
On Thu, Nov 11, 2010 at 07:36:22AM +0100, Jakub Hrozek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/09/2010 08:01 PM, Rob Crittenden wrote: Jakub Hrozek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Instead of print and return, use sys.exit() to quit scripts with an error message and a non zero return code. https://fedorahosted.org/freeipa/ticket/425 This isn't applying for me. Can you try to rebase it? thanks rob It should apply cleanly once the remaining diff of the patch that logs install script options is pushed. Sorry, I did not mention there was a dependency earlier. Attached patch rebased on top of the current master Jakub From 84a3b6335bf2b7082469bc9b048245e5605a5f55 Mon Sep 17 00:00:00 2001 From: Jakub Hrozek jhro...@redhat.com Date: Mon, 8 Nov 2010 23:13:48 +0100 Subject: [PATCH] Use sys.exit to quit scripts Instead of print and return, use sys.exit() to quit scripts with an error message and a non zero return code. https://fedorahosted.org/freeipa/ticket/425 --- install/tools/ipa-compat-manage | 16 --- install/tools/ipa-dns-install |9 ++ install/tools/ipa-nis-manage | 13 +++-- install/tools/ipa-server-certinstall |5 +-- install/tools/ipa-server-install | 32 - ipa-client/ipa-install/ipa-client-install | 43 - 6 files changed, 45 insertions(+), 73 deletions(-) diff --git a/install/tools/ipa-compat-manage b/install/tools/ipa-compat-manage index ded587d..508efd8 100755 --- a/install/tools/ipa-compat-manage +++ b/install/tools/ipa-compat-manage @@ -74,11 +74,9 @@ def main(): loglevel = logging.DEBUG if len(args) != 1: -print You must specify one action, either enable or disable -sys.exit(1) +sys.exit(You must specify one action, either enable or disable) elif args[0] != enable and args[0] != disable and args[0] != status: -print Unrecognized action [ + args[0] + ] -sys.exit(1) +sys.exit(Unrecognized action [ + args[0] + ]) logging.basicConfig(level=loglevel, format='%(levelname)s %(message)s') @@ -102,9 +100,7 @@ def main(): bind_dn='cn=directory manager', bind_pw=dirman_password ) except errors.LDAPError, lde: -print An error occurred while connecting to the server. -print lde -return 1 +sys.exit(An error occurred while connecting to the server.\n%s\n % str(lde)) if args[0] == status: try: @@ -142,9 +138,9 @@ def main(): # We can't disable schema compat if the NIS plugin is enabled try: conn.get_entry(netgroup_compat_dn, normalize=False) -print The NIS plugin is configured, cannot disable compatibility. -print Run 'ipa-nis-manage disable' first. -return 2 +print sys.stderr, The NIS plugin is configured, cannot disable compatibility. +print sys.stderr, Run 'ipa-nis-manage disable' first. +sys.exit(2) except errors.NotFound: pass # Make a quick hack for now, directly delete the entries by name, diff --git a/install/tools/ipa-dns-install b/install/tools/ipa-dns-install index b7db1be..5604931 100755 --- a/install/tools/ipa-dns-install +++ b/install/tools/ipa-dns-install @@ -80,8 +80,7 @@ def main(): safe_options, options = parse_options() if os.getegid() != 0: -print Must be root to setup server -return 1 +sys.exit(Must be root to setup server) standard_logging_setup(/var/log/ipaserver-install.log, options.debug, filemode='a') print \nThe log file for this installation can be found in /var/log/ipaserver-install.log @@ -103,8 +102,7 @@ def main(): # Check bind packages are installed if not bindinstance.check_inst(options.unattended): -print Aborting installation -return 1 +sys.exit(Aborting installation) # Initialize the ipalib api cfg = dict( @@ -124,8 +122,7 @@ def main(): ip_address = resolve_host(api.env.host) if not ip_address or not verify_ip_address(ip_address): if options.unattended: -print Unable to resolve IP address for host name -return 1 +sys.exit(Unable to resolve IP address for host name) else: ip_address = read_ip_address(api.env.host, fstore) logging.debug(will use ip_address: %s\n, ip_address) diff --git a/install/tools/ipa-nis-manage b/install/tools/ipa-nis-manage index 6448d17..9151886 100755 --- a/install/tools/ipa-nis-manage +++ b/install/tools/ipa-nis-manage @@ -88,11 +88,9 @@ def main(): loglevel = logging.DEBUG if len(args) != 1: -print You must specify one action, either enable
Re: [Freeipa-devel] [PATCH] 616 handle client-install wget failure
On Fri, Nov 19, 2010 at 11:20:23PM -0500, Rob Crittenden wrote: In the client installer we fetch the CA from the IPA server. Wrap this to catch any failures that might occur (like there is an iptables rule denying access to the IPA server). I tested this by shutting down the httpd service on the IPA server and running ipa-client-install on a client. rob ACK ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0015 Configure KDC to use multiple workers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2010 02:36 PM, Simo Sorce wrote: On Mon, 22 Nov 2010 13:58:40 +0100 Jakub Hrozek jhro...@redhat.com wrote: On Mon, Nov 15, 2010 at 09:05:55PM -0500, Simo Sorce wrote: Add code to detect the number of CPUs available at install time. If the kerberos version is = 1.9 then the KDC supports multiple workers. If more than 1 CPU is available configure the KDC to start 1 worker per CPU to aid in scalability. Addresses ticket #222 Simo. As I don't have Kerberos 1.9 (does not seem to be even in F15..) I only tested that the patch modifies the /etc/sysconfig/krb5kdc file. The code looks good and seems to work fine. I have two suggestions: 1) we should test if the open() calls succeed In what case it can fail ? For instance if the file was not present, if its SELinux label was wrong..I just think it's good defensive behaviour. Although it is true that the scripts would catch the exception and print a more meaingful error message than just an ugly traceback, which was basically my point. So this might actually be fine. 2) I think that we should log that we are about to modify a file We don't do that for any of the many files we modify, why should we ? OK, If we don't do that already, it makes no sense to do it for this single occurrence. FWIW, I was thinking that as an admin I would probably like to see when config on my system changes - at least when the log level is set to debug. A more general thought (although it's certainly not a task for 2.0), maybe we should consider using Augeas, either via its Python API or just calling augtool to modify config files. The benefits would be safer modifications (augeas knows the file structure) and most probably even cleaner code. This is a good idea, can you open an enhancement ticket ? https://fedorahosted.org/freeipa/ticket/525 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzqekEACgkQHsardTLnvCV7bwCgy1QqjR7200M3ogBQkR0voZVk BnEAniLevMiMmFQZPTWc+aSySO2isBdB =Tnhc -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Added some fields to user object
On 11/22/2010 09:25 AM, Jan Zelený wrote:
Some fields were missing from user object, this change adds them
along with their l10n
https://fedorahosted.org/freeipa/ticket/305
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
NACK
Did a user-show and got this stack trace
Traceback (most recent call last):
File /home/ayoung/devel/freeipa/ipalib/plugable.py, line 538, in
import_plugins
__import__(fullname)
File /home/ayoung/devel/freeipa/ipalib/plugins/user.py, line 57, in
module
class user(LDAPObject):
File /home/ayoung/devel/freeipa/ipalib/plugins/user.py, line 185,
in user
label=_('Org. Unit'),
File /home/ayoung/devel/freeipa/ipalib/parameters.py, line 1232, in
__init__
super(Str, self).__init__(name, *rules, **kw)
File /home/ayoung/devel/freeipa/ipalib/parameters.py, line , in
__init__
super(Data, self).__init__(name, *rules, **kw)
File /home/ayoung/devel/freeipa/ipalib/parameters.py, line 404, in
__init__
check_name(self.cli_name)
File /home/ayoung/devel/freeipa/ipalib/base.py, line 244, in check_name
NAME_ERROR % (NAME_REGEX, name)
ValueError: name must match '^[a-z][_a-z0-9]*[a-z0-9]$|^[a-z]$'; got
'org-unit'
Traceback (most recent call last):
File ./lite-server.py, line 121, in module
api.finalize()
File /home/ayoung/devel/freeipa/ipalib/plugable.py, line 557, in
finalize
self.__do_if_not_done('load_plugins')
File /home/ayoung/devel/freeipa/ipalib/plugable.py, line 371, in
__do_if_not_done
getattr(self, name)()
File /home/ayoung/devel/freeipa/ipalib/plugable.py, line 509, in
load_plugins
self.import_plugins('ipalib')
File /home/ayoung/devel/freeipa/ipalib/plugable.py, line 547, in
import_plugins
raise e
ValueError: name must match '^[a-z][_a-z0-9]*[a-z0-9]$|^[a-z]$'; got
'org-unit'
___
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 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=diffversion=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] [PATCH] Make the migration plugin more configurable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2010 08:17 PM, Rob Crittenden wrote: Jakub Hrozek wrote: This patch adds new options to the migration plugin: * the option to fine-tune the objectclass of users or groups being * imported * the option to select the LDAP schema (RFC2307 or RFC2307bis) https://fedorahosted.org/freeipa/ticket/429 I don't see where the RFC 2307bis case handles nested groups. This should be supported, right? rob The code handles it (I just ran a quick test with --schema=RFC2307bis). It just iterates through all members of a group -- be it user member of group member, it's just a DN for the plugin. Jakub -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzqiVMACgkQHsardTLnvCWLFwCcD4GUp4RVUVoTzElVuHqayJOw Vq8An0tRSltlWh3Y2V92eWhyLsQwVwip =RITJ -END PGP SIGNATURE- ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 617 catch CA retrieval errors
Catch when retrieving the CA chain from dogtag fails and report a friendlier error. Also don't try to free the XML document unless it has been created. To test this do an installation on F14 with a dogtag backend without fixing the symbolic link from /usr/share/java/xalan-j2-serializer.jar to /usr/share/tomcat5/common/lib/xalan-j2-serializer.jar rob From fa9366fdc141083489736a3911d50236ca7c1801 Mon Sep 17 00:00:00 2001 From: Rob Crittenden rcrit...@redhat.com Date: Mon, 22 Nov 2010 10:27:34 -0500 Subject: [PATCH] Catch when we fail to get a cert chain from the CA during installation Also don't free the XML document if it was never created. ticket 404 --- ipapython/dogtag.py |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/ipapython/dogtag.py b/ipapython/dogtag.py index 96d9469..014127e 100644 --- a/ipapython/dogtag.py +++ b/ipapython/dogtag.py @@ -37,6 +37,7 @@ def get_ca_certchain(ca_host=None): conn = httplib.HTTPConnection(ca_host, api.env.ca_port) conn.request(GET, /ca/ee/ca/getCertChain) res = conn.getresponse() +doc = None if res.status == 200: data = res.read() conn.close() @@ -53,7 +54,10 @@ def get_ca_certchain(ca_host=None): except Exception, e: raise errors.RemoteRetrieveError(reason=Retrieving CA cert chain failed: %s % str(e)) finally: -doc.unlink() +if doc: +doc.unlink() +else: +raise errors.RemoteRetrieveError(reason=request failed with HTTP status %d % res.status) return chain -- 1.7.3.1 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Modified ipa help behavior
Jan Zelený wrote: Rob Crittendenrcrit...@redhat.com wrote: Jan Zelený wrote: Jan Zelenýjzel...@redhat.com wrote: Now each plugin can define its topic as a 2-tuple, where the first item is the name of topic it belongs to and the second item is a description of such topic. Topic descriptions must be the same for all modules belonging to the topic. By using this topics, it is possible to group plugins as we see fit. When asking for help for a particular topic, help for all modules in given topic is written. ipa help - show all topics (until now it showed all plugins) ipa helptopic - show details to given topic https://fedorahosted.org/freeipa/ticket/410 Sorry for the wrong sequence number, sending the correct one now. I think this is a good start but I find the output hard to read, both with a single topic (like user) or multiple (like sudo). The dashed lines and the extra spaces make my eyes cross a bit What I don't have is any good suggestion to change it up. I realize you are jamming together discrete things that may or may not look nice together. I suppose a few suggestions might be: - a SEEALSO-like where you print the topics at the bottom so it is obvious that multiple things are jammed together - A single dashed-line all the way across (more or less) with a single space before and after might be a less jarring separator. IIRC we have some output code that should handle screen sizes for you. - I'm not sure if combining all the commands into a single list is the right thing or not. It may not be necessary with the SEEALSO. So nack for now but this is headed in the right direction. rob I gave this some thought: Output for each single-module topic is given by module's doc string. How good readability it has is not up to help function, but rather up to the developer of that particular module. The only thing I can do is not to display the separator. And as for multiple topics - I can change the concept to support two-level topics. That way when asking for the first level, it would display either entire single-module topic with its commands or it will only display a brief description of the topic and a list of its subtopics (this is based on your suggestion with SEEALSO section). Asking for one of these subtopics will output the same help as it would for single-module topic. I'm not sure about usability of this though. Personally I'd probably be asking who invented a help, which needs 4 shell commands to get to a help of IPA command: ipa help ipa help sudo ipa help sudocmd ipa help sudocmd-add I tried your other suggestions and the result doesn't look significantly better than the current one. What do you think is the best way to proceed? Jan The multiple commands for a given logical topic weren't really a consideration when the framework was created. At that time we were only considering very high-level topics like user, group and host. To example on your comment about the per-module documentation, that seems to be key. We have a separate ticket open against hbac-add to include per-command documentation on access time format. So I'm wondering if we need to re-think how we'd documenting things. Right now we have on the order of 178 commands. That is a LOT of man pages even if we used some sort of automated XML system. We just need to do the right thing before GA. Rather than combining the help from all the similar commands just show the top-level and include a SEEALSO? So for example for: ipa help hbac We would just show the hbac top-level help and include a SEEALSO for hbacsvc and hbacsvcgroup rather than including those top-level help as well? Similarly for sudo. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0100-top-nav-index
On 11/19/2010 06:53 PM, Endi Sukma Dewata wrote: On 11/19/2010 4:09 PM, Adam Young wrote: This will not work with entities that do not have associated tabs, e.g. hbacsvc, hbacsvcgroups, sudocmd, sudocmdgroups. For these entities the IPA.tab_state() will return undefined, so the ipa_column_widget.setup() will fail. To reproduce this problem, try clicking the search results in hbacsvc or hbacsvcgroups. For some reason it will bring you to the user search page. We need to figure out the proper way to handle these entities. It probably requires framework modification. Been pondering this during the weekend. I am not a huge fan of burying things like HBAC and Sudo entities so deep. There is little reason to force a use to search for these things, and so I suspect, over time we will adjust the UI to let them float up higher in the navigation structure. Without reordering things now, I propose we allow for a three level structure in the tab_set. Top level will not be an entity. Second level will be an entity. third level will be a nested entity. Nested entities are not related in any way to the entity that they are nested under except by convention. Thus, sudocmd and sudocmdgrps may get nested under sudorules, but they could easily be placed as peers. Contrast these with DNS records, that require the the DNS Zone value. For 3 level deep nesting, we will need a naming scheme to make these work. something like #subtab=sudoruleentity=sudocmd contrast this with #entity=sudorule Thus, the entity value always points to the object, not necessarily at the leaf node of the navigation tree. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] Fix a couple of problems in C code
On Thu, 18 Nov 2010 15:16:49 +0100 Jakub Hrozek jhro...@redhat.com wrote: On Mon, Nov 08, 2010 at 10:14:18PM +0100, Jakub Hrozek wrote: [PATCH 1/6] Common include file for SLAPI plugin logging Consolidate the common logging macros into common/util.h and use them in SLAPI plugins instead of calling slapi_log_error() directly. https://fedorahosted.org/freeipa/ticket/408 NACK, reintroduces a define of a function that was private to 389ds that we stoppped using. Everything else look fine [PATCH 2/6] Stricter compilation flags Use a little stricter compilation flags, in particular -Wall and treat implicit function declarations as errors. ACK [PATCH 3/6] Use internal implementation of internal Kerberos functions Don't use KRB5_PRIVATE. The patch implements and uses the following krb5 functions that are otherwise private in recent MIT Kerberos releases: * krb5_principal2salt_norealm * krb5_free_ktypes NACK, i we re-implement functions we should use our own namespace or we risk conflicts with the real functions in the library. [PATCH 4/6] Don't use deprecated ldap_bind_s ldap_bind_s is marked as deprecated in new libldap releases. ACK [PATCH 5/6] Silence compilation warnings in SLAPI plugins The most important part of the patch is exporting hexbuf() in ipapwd.h Also uses strcasecmp() instead of PL_strcasecmp() since we were not including nspr headers and linking against it - I hope this is OK, we can revert if we need to be portable to platforms with no strcasecmp(). The rest are cosmetic fixes. It seems to me that hexbuf() is used only in ipapwd_encoding.c, what about moving it there and making it static instead ? Adding the header would make less changes than replacing PL_strcasecmp everywhere. Any reason why replacing is easier than just adding the proper header ? [PATCH 6/6] ipa-client code cleanup Fixes errors about implicit function declaration and moves duplicated gettext code into a common module. Also silences some warnings. ACK Patches 3 - 6 fix https://fedorahosted.org/freeipa/ticket/454 Attached are patches rebased on top of current master, esp. the UUID patch. Only needs minor changes, mostly a very good set, thanks! Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0015 Configure KDC to use multiple workers
On Mon, 22 Nov 2010 16:04:51 +0100 Jakub Hrozek jhro...@redhat.com wrote: This could have been shortened to Ack :-) Pushed to master. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [SSSD] Proposed changes to the HBAC grammar
Stephen Gallagher wrote: 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. I have to comment on many things with the current state of grammar so for easier reference I copied it here and commented inline timerange = Absolute / Periodic Absolute = absolute WSP generalizedTime WSP ~ WSP generalizedTime generalizedTime as defined in RFC 4517 section 3.3.13 but without time zone at the end. Periodic = periodic WSP Yearly / Monthly / Weekly / Daily Yearly = yearly WSP Y-specifier WSP range-specified Monthly = monthly WSP M-specifier WSP range-specifier Weekly = weekly WSP W-specifier WSP range-specifier Daily = daily WSP range-specifier Y-specifier = Y-month / Y-week / Y-day Y-month = month WSP month-number WSP M-specifier Y-week = week WSP week-of-the-year WSP W-specifier Y-day = day WSP day-of-the-year M-specifier = M-on / M-day If we read grammar so far we will end up with the following uses of the M-specifier periodic monthly M-specifier range periodic yearly month 1,4,7 M-specifier range So far so good. Now we have two variants of the M-specifier M-on and M-day M-on = on WSP day-of-the-week WSP day-of-the-month-range The intent of this one was to be able to specify the weekday within a month M-day = day WSP day-of-the-month-interval This one for calendar days within a month W-specifier = day WSP day-of-the-week month-number = interval 1-12 week-of-the-year = interval 1-52 septet-of-the-month = interval 1-5 The septet is not used any more and should be removed, right? 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 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. 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. Also current grammar does not allow me to use ranges which I want to use here. I want to be able to express Wednesday of the first and third week of the month. Capability to do so it completely lost. 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. 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. 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
Re: [Freeipa-devel] [PATCH] 0100-top-nav-index
Adam Young wrote: On 11/19/2010 06:53 PM, Endi Sukma Dewata wrote: On 11/19/2010 4:09 PM, Adam Young wrote: This will not work with entities that do not have associated tabs, e.g. hbacsvc, hbacsvcgroups, sudocmd, sudocmdgroups. For these entities the IPA.tab_state() will return undefined, so the ipa_column_widget.setup() will fail. To reproduce this problem, try clicking the search results in hbacsvc or hbacsvcgroups. For some reason it will bring you to the user search page. We need to figure out the proper way to handle these entities. It probably requires framework modification. Been pondering this during the weekend. I am not a huge fan of burying things like HBAC and Sudo entities so deep. There is little reason to force a use to search for these things, and so I suspect, over time we will adjust the UI to let them float up higher in the navigation structure. Without reordering things now, I propose we allow for a three level structure in the tab_set. Top level will not be an entity. Second level will be an entity. third level will be a nested entity. Nested entities are not related in any way to the entity that they are nested under except by convention. Thus, sudocmd and sudocmdgrps may get nested under sudorules, but they could easily be placed as peers. Contrast these with DNS records, that require the the DNS Zone value. For 3 level deep nesting, we will need a naming scheme to make these work. something like #subtab=sudoruleentity=sudocmd contrast this with #entity=sudorule Thus, the entity value always points to the object, not necessarily at the leaf node of the navigation tree. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Do I read you right that instead of using actions menu you want to as another row of the tabs at the top? I am not sure I agree with this. -- 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
Re: [Freeipa-devel] [PATCH] 0100-top-nav-index
Dmitri Pal wrote: Adam Young wrote: On 11/19/2010 06:53 PM, Endi Sukma Dewata wrote: On 11/19/2010 4:09 PM, Adam Young wrote: This will not work with entities that do not have associated tabs, e.g. hbacsvc, hbacsvcgroups, sudocmd, sudocmdgroups. For these entities the IPA.tab_state() will return undefined, so the ipa_column_widget.setup() will fail. To reproduce this problem, try clicking the search results in hbacsvc or hbacsvcgroups. For some reason it will bring you to the user search page. We need to figure out the proper way to handle these entities. It probably requires framework modification. Been pondering this during the weekend. I am not a huge fan of burying things like HBAC and Sudo entities so deep. There is little reason to force a use to search for these things, and so I suspect, over time we will adjust the UI to let them float up higher in the navigation structure. Without reordering things now, I propose we allow for a three level structure in the tab_set. Top level will not be an entity. Second level will be an entity. third level will be a nested entity. Nested entities are not related in any way to the entity that they are nested under except by convention. Thus, sudocmd and sudocmdgrps may get nested under sudorules, but they could easily be placed as peers. Contrast these with DNS records, that require the the DNS Zone value. For 3 level deep nesting, we will need a naming scheme to make these work. something like #subtab=sudoruleentity=sudocmd contrast this with #entity=sudorule Thus, the entity value always points to the object, not necessarily at the leaf node of the navigation tree. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel Do I read you right that instead of using actions menu you want to as use another row of the tabs at the top? I am not sure I agree with this. -- 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
Re: [Freeipa-devel] [PATCH] 0001 Ensure that Apache is running in Prefork mode
On 11/15/2010 05:21 AM, Jan Zelený wrote: Jan Zelenyjzel...@redhat.com wrote: Rob Crittendenrcrit...@redhat.com wrote: Jan Zelený wrote: Rob Crittendenrcrit...@redhat.com wrote: Jan Zelený wrote: I tried one other solution, but this approach was recommended to me by Pavel. It seems to be working fine. If you don't agree with the concept (detection per request), I can present you the original one. https://fedorahosted.org/freeipa/ticket/252 Jan nack. I think we need some logging to say IPA does not work with the threaded MPM, use the pre-fork MPM or something like that. Otherwise it is going to silently fail and users will have no idea why. I added logging as you requested. I'm still not quite sure how does the logging work exactly, but as I understand it, this way it should be ok. Jan nack, I can still run httpd.worker and serve IPA requests. We do things to the environment so we need to be sure that each request is isolated from all others which is why we want to run in multi-process mode. rob I based that patch on WSGI specification, which says: This value should evaluate true if the application object may be simultaneously invoked by another thread in the same process, and should evaluate false otherwise. I didn't realize that this condition may be evaluated as false even when running multiple threads. That means I have to abandon this approach and try the original one. I'm going to sync the patch I have prepared with the current HEAD and I'll send it ASAP. Ok, so I've hit a small complication and I had to update the patch, so the detection is as robust as possible. This patch is working in Fedora environment, where the packaging of httpd is ... well ... strange at least. The only situation it isn't handling 100% well is the case when 2 different Apache servers are running. But since that's not common case and I can't think of a way to detect which instance is running current WSGI script, the script just doesn't allow such situation. Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK and pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0016 Tune directory server
On 11/18/2010 08:40 PM, Adam Young wrote:
On 11/17/2010 04:26 PM, Simo Sorce wrote:
On Tue, 16 Nov 2010 14:09:58 -0500
Simo Sorcesso...@redhat.com wrote:
This patch bumps up the default number of files allowed by default for
directory server. This allows more clients and also reserves a bigger
number of FDs (at least according to doc) for replication agreements
and such things.
Ticket 464.
Changed the patch to restore files on uninstall. Now 0016-2 depends on
0017 attached here too.
Simo.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Patched 17 failed to apply. Ran using git am as well as patch -p1
Here's the rej
--- ipaserver/install/dsinstance.py
+++ ipaserver/install/dsinstance.py
@@ -185,6 +186,12 @@
else:
self.suffix = None
+if fstore:
+self.fstore = fstore
+else:
+self.fstore = sysrestore.FileStore('/var/lib/ipa/sysrestore')
+
+
def create_instance(self, ds_user, realm_name, fqdn, domain_name,
dm_password, pkcs12_info=None,
self_signed_ca=False,
idstart=1100, idmax=99, subject_base=None,
Tried patch 16-2 and it failed, too. Here's the rej
--- ipaserver/install/dsinstance.py
+++ ipaserver/install/dsinstance.py
@@ -185,10 +185,7 @@
else:
self.suffix = None
-if fstore:
-self.fstore = fstore
-else:
-self.fstore = sysrestore.FileStore('/var/lib/ipa/sysrestore')
+self.fstore = sysrestore.FileStore('/var/lib/ipa/sysrestore')
def create_instance(self, ds_user, realm_name, fqdn, domain_name,
@@ -533,6 +531,7 @@
self.stop()
try:
+self.fstore.restore_file(/etc/security/limits.conf)
self.fstore.restore_file(/etc/sysconfig/dirsrv)
except ValueError, error:
logging.debug(error)
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
ACK and pushed to master
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0011 Change DNA configuration to use shared configuration
On 11/19/2010 03:08 PM, Simo Sorce wrote: On Thu, 11 Nov 2010 19:51:23 -0500 Simo Sorcesso...@redhat.com wrote: With this patch 2 changes are introduced. 1. idranges are unified, the --uidstart and --gistart options are removed and instead --idtsrat and --idmax are provided at install time. This is a prerequisite to simplify configuration for the next change. 2. DNA is configured to share range configurations among multiple masters now. When replicas are installed an invalid range is configured so that they are forced to contact another peer as soon as someone tries to create a user/group on that master. The replica will get a part of the available range from the peer for its use. Simo. Rebased on top of current master, or it would fail to apply. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK and pushed to master. Note that I've just applied and built it, but did not run the code it changes. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0020 Make pkinit optional in ipa-replica-prepare
Fixes #527 Simo. -- Simo Sorce * Red Hat, Inc * New York From ea5b717d0db97c33a62239319baddf80aeeb5dba Mon Sep 17 00:00:00 2001 From: Simo Sorce sso...@redhat.com Date: Mon, 22 Nov 2010 13:29:56 -0500 Subject: [PATCH] Make pkinit setup optional in ipa-replica-prepare too. Fixes: https://fedorahosted.org/freeipa/ticket/527 --- install/tools/ipa-replica-prepare |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/install/tools/ipa-replica-prepare b/install/tools/ipa-replica-prepare index af768015510f47eacfd7643359216a9f49497020..bafb89e45d1e2dc219de9dc7bc568596e5030ad6 100755 --- a/install/tools/ipa-replica-prepare +++ b/install/tools/ipa-replica-prepare @@ -84,6 +84,10 @@ def parse_options(): if len(args) != 1: parser.error(must provide the fully-qualified name of the replica) +#Automatically disable pkinit w/ dogtag until that is supported +if not options.pkinit_pkcs12 and not options.selfsign: +options.setup_pkinit = False + return options, args def get_subject_base(host_name, dm_password, suffix): -- 1.7.3.2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0020 Make pkinit optional in ipa-replica-prepare
Simo Sorce wrote: Fixes #527 Simo. There is no selfsign option in ipa-replica-prepare. At best you can detect whether it is selfsigned by calling certs.ipa_self_signed() rob ___ 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] [PATCH] 0020 Make pkinit optional in ipa-replica-prepare
On Mon, 22 Nov 2010 13:34:57 -0500 Simo Sorce sso...@redhat.com wrote: Fixes #527 Simo. A copypaste from ipa-server-install was a bit too optimistic. Attached a new patch that actually works (tested). Simo. -- Simo Sorce * Red Hat, Inc * New York From ee86bee78184bf7a647243492dfcd1a97e402545 Mon Sep 17 00:00:00 2001 From: Simo Sorce sso...@redhat.com Date: Mon, 22 Nov 2010 13:29:56 -0500 Subject: [PATCH] Make pkinit setup optional in ipa-replica-prepare too. Fixes: https://fedorahosted.org/freeipa/ticket/527 --- install/tools/ipa-replica-prepare |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/install/tools/ipa-replica-prepare b/install/tools/ipa-replica-prepare index af768015510f47eacfd7643359216a9f49497020..d70741f1a1208ca6a2a1a6cad4d09ae4962b8040 100755 --- a/install/tools/ipa-replica-prepare +++ b/install/tools/ipa-replica-prepare @@ -242,6 +242,11 @@ def main(): api.bootstrap(in_server=True) api.finalize() +#Automatically disable pkinit w/ dogtag until that is supported +#[certs.ipa_self_signed() must be called only after api.finalize()] +if not options.pkinit_pkcs12 and not certs.ipa_self_signed(): +options.setup_pkinit = False + if options.ip_address: if not bindinstance.dns_container_exists(api.env.host, api.env.realm): print You can't add a DNS record because DNS is not set up. -- 1.7.3.2 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0011 Change DNA configuration to use shared configuration
Adam Young wrote: On 11/19/2010 03:08 PM, Simo Sorce wrote: On Thu, 11 Nov 2010 19:51:23 -0500 Simo Sorcesso...@redhat.com wrote: With this patch 2 changes are introduced. 1. idranges are unified, the --uidstart and --gistart options are removed and instead --idtsrat and --idmax are provided at install time. This is a prerequisite to simplify configuration for the next change. 2. DNA is configured to share range configurations among multiple masters now. When replicas are installed an invalid range is configured so that they are forced to contact another peer as soon as someone tries to create a user/group on that master. The replica will get a part of the available range from the peer for its use. Simo. Rebased on top of current master, or it would fail to apply. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK and pushed to master. Note that I've just applied and built it, but did not run the code it changes. It is testing out ok for me. I installed with idstart=5000 and my first user was added with uid=5003. I created a replica and the first user there had uid=505500 rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] don't use kerberos path
I pushed this under the 1-liner rule.
Don't use full pathnames for kerberos binaries, let PATH find them.
Kerberos binaries may be in /usr/kerberos/*bin or /usr/*bin, let PATH
sort it out.
diff --git a/ipaserver/install/krbinstance.py
b/ipaserver/install/krbinstance.py
index 41c6878..8c22e6f 100644
--- a/ipaserver/install/krbinstance.py
+++ b/ipaserver/install/krbinstance.py
@@ -367,7 +367,7 @@ class KrbInstance(service.Service):
MIN_KRB5KDC_WITH_WORKERS = 1.9
cpus = os.sysconf('SC_NPROCESSORS_ONLN')
workers = False
-(stdout, stderr, rc) = ipautil.run(['/usr/bin/klist', '-V'],
raiseonerr=False)
+(stdout, stderr, rc) = ipautil.run(['klist', '-V'],
raiseonerr=False)
if rc == 0:
verstr = stdout.split()[-1]
ver = version.LooseVersion(verstr)
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] SUDO Rule Search and Details Pages
On 11/19/2010 12:21 PM, Endi Sukma Dewata wrote: On 11/19/2010 11:18 AM, Dmitri Pal wrote: Endi Sukma Dewata wrote: On 11/19/2010 10:22 AM, Adam Young wrote: ACK. However, you will need to rebase, as Rob already made the index.html addition to ipa.spec.in Thanks. Rebased and pushed to master. I suspect it is the first pass at those since the UXD spec is underway for the SUDO pages. Yes, this is based on HBAC. At least the functionality works. We can revise the page again when the spec becomes available. ACK and pushed to master ___ 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
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. And I really want them there. Why? What technical argument necessitates this? I'm inclined to agree with Stephen here. He has a good point. Consistency, same pattern, same construct so less code... Those are pretty significant arguments for me. There are couple other things that came from a discussion with UXD which I will describe in a different thread. -- 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
[Freeipa-devel] Other issues with HBAC calendar
Hi, During the conversation with Ben and Kyle today over the calendar screen two things came up: 1) Time zone 2) Duration Time zone It makes perfect sense to allow the admin to enter the rule and specify the time zone that the admin used to enter the time. Internally it will be converted to UTC but for the purpose of easier rule creation specifying time zone is helpful. Our grammar right now does not allow saving the zone since we plan to convert time to UTC, however when the value is fetched from the LDAP and presented for editing it is unclear which time zone it was entered in. Also there are two approaches to dealing with time zone information in general. Imagine you have a drop down with time zones. Imagine you entered time and then change the selected time zone in the drop down. Should the time you entered be automatically adjusted? First approach says yes but that means that we will have to implement a complex time recalculator since in corner cases the time difference between the time zones will affect the starting. The second option is to say: the time zone is just a specifier for the whole time rule indicating that the time values were entered in the given time zone. The when you change the value of the time zone you do not recalculate anything. With the right UI structure this can be made more obvious. However when the value fetched from the LDAP and displayed it might be useful to recalculate so I see two options how we can deal with the time zones. a) Do not save the time zone but recalculate the time (and date ???) when you change time zone in the drop down both in add and edit cases. When you fetch and display always use UTC but allow admin to change the timezone view at his will. b) Save time zone in the rule. As Simo pointed the time zone definition change from time to time so it makes sense to actually save offset and timezone as additional hint. This way we can easily convert the time stamp into the specified time zone and back at save and retrieval with no need to implement complex logic in the UI. IMO the second option is simpler but requires yet another change to grammar. I suggest we add offset and time zone as optional fields somewhere at the end of the rule or after start time. 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? -- 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
