[PATCH] Add a special filter type to handle enumerations
by Sumit Bose
Hi,
this patch adds a special filter type for enumarations instead of using
'name=*'. I think this makes the code easier to read and understand,
allows the usage of a '*' in user or group names (although it might be
recommended to do without) and fixes trac ticket #676.
bye,
Sumit
13 years, 4 months
[PATCH] Reset all failover services when going online
by Sumit Bose
Hi,
this patch resets the status of all failover services and the
went_offline time if we receive a reset_offline request. Before the
request was introduced we waited until all the timeouts were over and
tried an online operation with the next request. After a reset_offline
request is received it is expected that the next request will
immediately goes online. To achieve this all timeouts and status must be
reset.
This patch should fix the scenario from trac ticket #655.
bye,
Sumit
13 years, 5 months
Other issues with HBAC calendar
by Dmitri Pal
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/
13 years, 5 months
[PATCH] Print correct error messages for dp_err_to_string()
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All errnum values passed into this function throughout the code
are PAM error codes, but we were passing them through strerror()
to print them, which is only meaningful for ERRNO error codes.
This patch changes dp_err_to_string() to use pam_strerror().
Fixes https://fedorahosted.org/sssd/ticket/636
Note: the first argument to pam_strerror() requiring a PAM handle is
historical and not necessary. I tested that passing it NULL results in
no unexpected behavior.
- --
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/
iEYEARECAAYFAkzmzqkACgkQeiVVYja6o6PIXwCgqWXP1Sm1ym1PaDcWeBjgxB+K
FcQAn3o5A0KmgT/Z0X0itrTmqiO3sGQl
=1LHe
-----END PGP SIGNATURE-----
13 years, 5 months
Re: [SSSD] [Freeipa-devel] Proposed changes to the HBAC grammar
by Stephen Gallagher
-----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-----
13 years, 5 months
[PATCH] Fix client libs thread safety
by Simo Sorce
Had some spare time today and wanted to fix this issue.
The attached patch instruments nss and pam clients to use a pthread
mutex to prevent multiple threads from stomping on each other.
The patch is quite simple and basic testing seem to show no issues.
It may be worth of back-porting to older versions.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
13 years, 5 months
[PATCH][DING-LIBS] Fix license text for several files that should be LGPLv3+
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is NOT a relicensing. These files were mislabeled. They were
always LGPLv3+.
Patch applies to both master and ding_libs-0-1 branches.
- --
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/
iEYEARECAAYFAkzmdIkACgkQeiVVYja6o6O0iACdFsMSqulcRfqildnRd4eONKFQ
K30An3Bc8rg+dJQnhQJo0mzVZUm+KJk0
=mV2C
-----END PGP SIGNATURE-----
13 years, 5 months
