Re: [Freeipa-devel] [PATCHES 0024-0025] Improvements to idrange.py
On 02/25/2013 02:16 PM, Tomas Babej wrote:
On Fri 22 Feb 2013 04:34:55 PM CET, Martin Kosek wrote:
On 02/22/2013 03:01 PM, Tomas Babej wrote:
On 02/21/2013 02:22 PM, Martin Kosek wrote:
On 02/20/2013 03:19 PM, Tomas Babej wrote:
On Wed 20 Feb 2013 02:24:03 PM CET, Alexander Bokovoy wrote:
On Wed, 20 Feb 2013, Tomas Babej wrote:
On 12/21/2012 12:15 PM, Tomas Babej wrote:
Hi,
Sending updated and rebased versions of patches 0024 and 0025.
Tomas
Sending rebased version, these got quite rotten.
Thanks for updating them.
@@ -504,25 +515,37 @@ class idrange_mod(LDAPUpdate):
'not be found. Please specify the SID
directly '
'using dom-sid option.'))
-try:
-(old_dn, old_attrs) = ldap.get_entry(dn,
-['ipabaseid',
-'ipaidrangesize',
-'ipabaserid',
-'ipasecondarybaserid'])
-except errors.NotFound:
-self.obj.handle_not_found(*keys)
+if in_updated_attrs('ipanttrusteddomainsid'):
+if in_updated_attrs('ipasecondarybaserid'):
+raise errors.ValidationError(name='ID Range setup',
+error=_('Options dom_sid and secondary_rid_base
cannot '
+'be used together'))
Since we agreed to refer to options by their CLI name (--dom-sid and
--secondary-rid-base) in the other patch, it makes sense to use it
here too.
-if is_set('ipanttrusteddomainsid'):
-# Validate SID as the one of trusted domains
-
self.obj.validate_trusted_domain_sid(entry_attrs['ipanttrusteddomainsid'])
+if not in_updated_attrs('ipabaserid'):
+raise errors.ValidationError(name='ID Range setup',
+error=_('Options dom_sid and rid_base must '
+'be used together'))
Same here.
+# secondary base rid must be set if and only if base rid
is set
+if in_updated_attrs('ipasecondarybaserid') !=\
+in_updated_attrs('ipabaserid'):
+raise errors.ValidationError(name='ID Range setup',
+error=_('Options secondary_rid_base and rid_base
must '
+'be used together'))
Same here.
+dict(
+desc='Try to modify ID range %r so it has only primary
rid range set' % (testrange8),
+command=('idrange_mod', [testrange8],
+ dict(ipabaserid=testrange8_base_rid)),
+expected=errors.ValidationError(
+name='ID Range setup', error='Options
secondary_rid_base and rid_base must be used together'),
+),
And synchronize error message here too.
Thanks!
Sending the updated patch 0024.
Tomas
In patch 0024 your intention is OK, but the checking functions are not:
is_set = lambda x: (x in entry_attrs) and (x is not None)
+in_updated_attrs = lambda x: any((x in attrs and x is not None)
+ for attrs in (entry_attrs,
old_attrs))
They return True even when the attribute is None because they check if *x*
is
None and not if *attrs[x]* is None. Example:
# ipa idrange-add --base-id=120 --range-size=20 --rid-base=1000
--secondary-rid-base=100 local_range
Added ID range local_range
Range name: local_range
First Posix ID of the range: 120
Number of IDs in the range: 20
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100
Range type: local domain range
This command should be NOOP, but is not:
# ipa idrange-mod local_range --dom-sid=
ipa: ERROR: invalid 'ID Range setup': Options dom-sid and
secondary-rid-base
cannot be used together
Martin
Thanks for the catch, all checking functions fixed.
Sending the complete patchset, up to date.
Tomas
I think I am being a nitpicker now (sorry), but this condition also fails if
the old_attrs has a setting, but I am removing it in a current -mod command:
# ipa idrange-add --base-id=120 --range-size=20 --rid-base=1000
--secondary-rid-base=100 local_range
Added ID range local_range
Range name: local_range
First Posix ID of the range: 120
Number of IDs in the range: 20
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100
Range type: local domain range
# ipa idrange-mod local_range --dom-sid S-1-2 --secondary-rid-base=
ipa: ERROR: invalid 'ID Range setup': Options dom-sid and secondary-rid-base
cannot be used together
Martin
Yep. Ok, the command should now handle this use case as
Re: [Freeipa-devel] [PATCH] 1087 Some missing v3 schema on upgrades
On 02/22/2013 01:36 PM, Martin Kosek wrote: On 02/18/2013 10:00 PM, Rob Crittenden wrote: An objectclass and attribute are not being added on upgrades. Missing these causes the UI to not work. I also noticed a typo in the ordering of a number of the trust attributes so fix those as well. rob ACK, works for me. Pushed to master, ipa-3-1. Martin I just noticed an issue with the ORDERING in dirsrv errors log: [26/Feb/2013:09:47:37 -0500] attr_syntax_create - Error: the ORDERING matching rule [caseIgnoreIA5OrderingMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.26] for the attribute [ipaNTSecurityIdentifier] [26/Feb/2013:09:47:37 -0500] attr_syntax_create - Error: the ORDERING matching rule [caseIgnoreIA5OrderingMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.26] for the attribute [ipaNTTrustedDomainSID] [26/Feb/2013:09:47:37 -0500] attr_syntax_create - Error: the ORDERING matching rule [caseIgnoreIA5OrderingMatch] is not compatible with the syntax [1.3.6.1.4.1.1466.115.121.1.26] for the attribute [ipaNTDomainGUID] Reopening the ticket. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] DESIGN: Recover DNA Ranges
On Mon, Feb 25, 2013 at 03:12:19PM +0100, Martin Kosek wrote: On 02/25/2013 03:09 PM, Rob Crittenden wrote: Martin Kosek wrote: ... 4) What does NOTE: We will need to be clear that this range has nothing to do with Trust ranges. actually mean? AFAIU, IPA should have all local ranges covered with a local idrange range(s). IPA ranges is completely separate from DNA ranges. You can set/modify all the local ranges you want and it won't affect the UIDs getting assigned. If it does not have it covered, it could happen that for example a new trust would overlap with this user-defined local range and we would have colliding POSIX IDs... Hmm, that's a good point. IMO, dnarange-set and dnanextrange-set should at first check if the range is covered with some local idrange and only then allowed setting the new range. I can do that as well, but again, the local ranges don't really affect the ids we hand out via DNA. rob You are right, that DNA plugin is really not aware of the idranges we set in IPA. But the idrange is still a safeguard for our POSIX IDs to not overlap with trust ranges and I think we should respect that with ipa-replica-manage. I wonder if there was not even a plan to increase cooperation between our idranges and DNA plugin, maybe Sumit or Alexander knows more. If I understand the use case and design properly, it is about re-arranging the sub-ranges each replica can use from the original range, which was given/created at installation time and which is also stored as idrange in DOMAIN.NAME_id_range,cn=ranges,cn=etc,dc=domain,dc=name with objectclass=ipaDomainIDRange. If the re-arrangement does not result in IDs which are outside of this range give by the ipaDomainIDRange object, no conflicts with idranges used by trusted domain will occur, because it is one of the task of the idrange objects to avoid those conflicts. If the original given range is exhausted completely and a completely new DNA range must be created, it should be checked with ipa idrange-find that the new range is not used and a new ipaDomainIDRange object which reserves the local range should be added. There are https://fedorahosted.org/freeipa/ticket/591 which can be used to track the coordinated creation of DNA and id-range. bye, Sumit Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0189 Remove option to use custom SSL certificates from ipa-server-install
This removes the --{dirsrv,http,pkinit}-{pkcs12,pin} options.
https://fedorahosted.org/freeipa/ticket/3151
The same options are in ipa-replica-prepare. I think we should leave
those be, so people with existing servers with custom certs can install
replicas.
--
Petr³
From 664fdd8278144caecb756acda0e6a92db40d4898 Mon Sep 17 00:00:00 2001
From: Petr Viktorin pvikt...@redhat.com
Date: Fri, 22 Feb 2013 09:55:05 -0500
Subject: [PATCH] Remove option to use custom SSL certificates from
ipa-server-install
Remove the --{dirsrv,http,pkinit}-{pkcs12,pin} options and code that
handles them.
https://fedorahosted.org/freeipa/ticket/3151
---
install/tools/ipa-server-install | 111 +++--
1 files changed, 21 insertions(+), 90 deletions(-)
diff --git a/install/tools/ipa-server-install b/install/tools/ipa-server-install
index 15591071b0983511394a2cba3d829e1b84fe328e..3ce139e6cfb66d9d17329a36c90756d448914d0c 100755
--- a/install/tools/ipa-server-install
+++ b/install/tools/ipa-server-install
@@ -70,7 +70,6 @@ from ipapython.dn import DN
import ipaclient.ntpconf
-pw_name = None
uninstalling = False
installation_cleanup = True
@@ -168,18 +167,6 @@ def parse_options():
help=File containing PKCS#10 of the external CA chain)
cert_group.add_option(--no-pkinit, dest=setup_pkinit, action=store_false,
default=True, help=disables pkinit setup steps)
-cert_group.add_option(--dirsrv_pkcs12, dest=dirsrv_pkcs12,
- help=PKCS#12 file containing the Directory Server SSL certificate)
-cert_group.add_option(--http_pkcs12, dest=http_pkcs12,
- help=PKCS#12 file containing the Apache Server SSL certificate)
-cert_group.add_option(--pkinit_pkcs12, dest=pkinit_pkcs12,
- help=PKCS#12 file containing the Kerberos KDC SSL certificate)
-cert_group.add_option(--dirsrv_pin, dest=dirsrv_pin, sensitive=True,
- help=The password of the Directory Server PKCS#12 file)
-cert_group.add_option(--http_pin, dest=http_pin, sensitive=True,
- help=The password of the Apache Server PKCS#12 file)
-cert_group.add_option(--pkinit_pin, dest=pkinit_pin,
- help=The password of the Kerberos KDC PKCS#12 file)
cert_group.add_option(--subject, action=callback, callback=subject_callback,
type=string,
help=The certificate subject base (default O=realm-name))
@@ -270,14 +257,6 @@ def parse_options():
if not options.forwarders and not options.no_forwarders:
parser.error(You must specify at least one --forwarder option or --no-forwarders option)
-# If any of the PKCS#12 options are selected, all are required. Create a
-# list of the options and count it to enforce that all are required without
-# having a huge set of it blocks.
-pkcs12 = [options.dirsrv_pkcs12, options.http_pkcs12, options.dirsrv_pin, options.http_pin]
-cnt = pkcs12.count(None)
-if cnt 0 and cnt 4:
-parser.error(All PKCS#12 options are required if any are used.)
-
if (options.external_cert_file or options.external_ca_file) and options.selfsign:
parser.error(--selfsign cannot be used with the external CA options.)
@@ -304,7 +283,7 @@ def parse_options():
(options.idmax, options.idstart))
#Automatically disable pkinit w/ dogtag until that is supported
-if not options.pkinit_pkcs12 and not options.selfsign:
+if not options.selfsign:
options.setup_pkinit = False
if options.zone_refresh 0:
@@ -561,7 +540,6 @@ def set_subject_in_config(realm_name, dm_password, suffix, subject_base):
def main():
global ds
-global pw_name
global uninstalling
global installation_cleanup
ds = None
@@ -931,26 +909,11 @@ def main():
# Create a directory server instance
ds = dsinstance.DsInstance(fstore=fstore)
-if options.dirsrv_pin:
-[pw_fd, pw_name] = tempfile.mkstemp()
-os.write(pw_fd, options.dirsrv_pin)
-os.close(pw_fd)
-
-if options.dirsrv_pkcs12:
-pkcs12_info = (options.dirsrv_pkcs12, pw_name)
-try:
-ds.create_instance(realm_name, host_name, domain_name,
- dm_password, pkcs12_info,
- subject_base=options.subject,
- hbac_allow=not options.hbac_allow)
-finally:
-os.remove(pw_name)
-else:
-ds.create_instance(realm_name, host_name, domain_name,
- dm_password, self_signed_ca=options.selfsign,
- idstart=options.idstart, idmax=options.idmax,
- subject_base=options.subject,
- hbac_allow=not options.hbac_allow)
+ds.create_instance(realm_name, host_name, domain_name,
+
[Freeipa-devel] [PATCH] 374 Remove ORDERING for IA5 attributeTypes
IA5 string syntax does not have a compatible ORDERING matching rule. Simply use default ORDERING for these attributeTypes as we already do in other cases. https://fedorahosted.org/freeipa/ticket/3398 - This is a follow-up ticket for regression introduced by Rob's 1087. I did not add any update rules for IPA servers that were already wrongly updated as we did not release any IPA version with these bad attributeTypes and I want to keep .update files small. Martin From 93f6c7a06e9679f555d0a3adc2d0898f442d867a Mon Sep 17 00:00:00 2001 From: Martin Kosek mko...@redhat.com Date: Tue, 26 Feb 2013 17:23:09 +0100 Subject: [PATCH] Remove ORDERING for IA5 attributeTypes IA5 string syntax does not have a compatible ORDERING matching rule. Simply use default ORDERING for these attributeTypes as we already do in other cases. https://fedorahosted.org/freeipa/ticket/3398 --- install/share/60basev3.ldif | 6 +++--- install/updates/60-trusts.update | 9 +++-- 2 files changed, 6 insertions(+), 9 deletions(-) diff --git a/install/share/60basev3.ldif b/install/share/60basev3.ldif index 63489aea159db23e01bfe4ead6b28b7950e06d6e..43da2e7d906021573c3717569c05b98c578485f0 100644 --- a/install/share/60basev3.ldif +++ b/install/share/60basev3.ldif @@ -5,8 +5,8 @@ ## dn: cn=schema attributeTypes: (2.16.840.1.113730.3.8.11.1 NAME 'ipaExternalMember' DESC 'External Group Member Identifier' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v3' ) -attributeTypes: (2.16.840.1.113730.3.8.11.2 NAME 'ipaNTSecurityIdentifier' DESC 'NT Security ID' EQUALITY caseIgnoreIA5Match ORDERING caseIgnoreIA5OrderingMatch SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v3' ) -attributeTypes: (2.16.840.1.113730.3.8.11.23 NAME 'ipaNTTrustedDomainSID' DESC 'NT Trusted Domain Security ID' EQUALITY caseIgnoreIA5Match ORDERING caseIgnoreIA5OrderingMatch SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v3' ) +attributeTypes: (2.16.840.1.113730.3.8.11.2 NAME 'ipaNTSecurityIdentifier' DESC 'NT Security ID' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v3' ) +attributeTypes: (2.16.840.1.113730.3.8.11.23 NAME 'ipaNTTrustedDomainSID' DESC 'NT Trusted Domain Security ID' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v3' ) attributeTypes: (2.16.840.1.113730.3.8.11.3 NAME 'ipaNTFlatName' DESC 'Flat/Netbios Name' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3' ) attributeTypes: (2.16.840.1.113730.3.8.11.4 NAME 'ipaNTFallbackPrimaryGroup' DESC 'Fallback Group to set the Primary group Security Identifier for users with UPGs' SUP distinguishedName X-ORIGIN 'IPA v3' ) attributeTypes: (2.16.840.1.113730.3.8.11.5 NAME 'ipaNTHash' DESC 'NT Hash of user password' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE X-ORIGIN 'IPA v3' ) @@ -14,7 +14,7 @@ attributeTypes: (2.16.840.1.113730.3.8.11.6 NAME 'ipaNTLogonScript' DESC 'User L attributeTypes: (2.16.840.1.113730.3.8.11.7 NAME 'ipaNTProfilePath' DESC 'User Profile Path' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3' ) attributeTypes: (2.16.840.1.113730.3.8.11.8 NAME 'ipaNTHomeDirectory' DESC 'User Home Directory Path' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3' ) attributeTypes: (2.16.840.1.113730.3.8.11.9 NAME 'ipaNTHomeDirectoryDrive' DESC 'User Home Drive Letter' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'IPA v3' ) -attributeTypes: (2.16.840.1.113730.3.8.11.10 NAME 'ipaNTDomainGUID' DESC 'NT Domain GUID' EQUALITY caseIgnoreIA5Match ORDERING caseIgnoreIA5OrderingMatch SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v3' ) +attributeTypes: (2.16.840.1.113730.3.8.11.10 NAME 'ipaNTDomainGUID' DESC 'NT Domain GUID' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE X-ORIGIN 'IPA v3' ) attributeTypes: ( 2.16.840.1.113730.3.8.11.11 NAME 'ipaNTTrustType' DESC 'Type of trust' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributeTypes: ( 2.16.840.1.113730.3.8.11.12 NAME 'ipaNTTrustAttributes' DESC 'Trust attributes for a trusted domain' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributeTypes: (
Re: [Freeipa-devel] [PATCH] 0187 CLI: Do interactive prompting after a context is created
On 02/22/2013 01:43 PM, Petr Viktorin wrote: Hello, This fixes a regression introduced by one of my help patches (abe26d5). https://fedorahosted.org/freeipa/ticket/3453 ACK. Pushed to master, ipa-3-1. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] What about desktop policies?
On 02/25/2013 02:15 PM, Loris Santamaria wrote: Hi all, some customers of ours are interested in managing desktop policies for their linux workstations, really nothing fancy, corporate background and proxy settings are the most common requests. In the past I created Gnome desktop profiles using Sabayon, distributed them using puppet and associated them to user accounts with a Sabayon specific LDAP attribute, a process a bit convoluted, and no longer possible since sabayon is no longer developed. Also it was really buggy, and very gnome specific. I was thinking in how integrate desktop policies in freeIPA in a general manner and I wanted to share my ideas with you. Hopefully some of this may be incorporated in IPA at some point in the future. Properties of a policy: * is a collection of settings * can be associated with users or groups (desktop policy) or with hosts or hostgroups (system policy) * is associated with a consumer, the client software that interprets and applies the policy. This way one could define policies for dconf, policies for kde, policies for WBEM. Properties of a setting * is a key-value pair * must conform to a schema * may be mandatory The schema: * indicates which attributes a policy may consist of * indicates which kind of value may take an attribute. Bool, string, etc. * There may be more than one schema for a given consumer. For example for dconf you may have an evolution schema, a gnome-games schema, etc. Sample policy creation process: 1. The admin creates a new schema in IPA, with a command like ipa schema-add --consumer=dconf gnomeSettingsSchema 2. The admin adds some definition to the schema: ipa schema-add-setting gnomeSettingsSchema --name=/schemas/desktop/gnome/background/picture_filename --type=string --description='File to use for the background image.' 3. He creates a new policy: ipa policy-add corporateBackground --type=desktop --consumer=dconf 4. He adds a setting to the policy: ipa policy-add-setting corporateBackground --name=/schemas/desktop/gnome/background/picture_filename --value=file:///san/wp/wallpaper.jpg --mandatory. Ipa would check that the key is defined in one of the dconf related schemas and the value is acceptable for that key. 5. He associates the policy with users: ipa-policy-add-user corporateBackground --groups=ipausers How should the policy be applied? On the workstation, on startup, an ipa related utility should check if there are any policies related to the workstation, if there are any it should call a helper capable of applying a specific type of policy. Then on user logon another ipa related utility should check if there are any policies associated with the user and call the appropriate helper, if available. For the policy created in the above example, on logon the ipa policy utility would find that there is a policy of type dconf associated with the user. It would check if there is a dconf policy helper installed and if positive it would call the helper passing it the parameters defined in the policy. Hope this is useful at least as a starting point in defining desktop policies in IPA. This is great! Thank you for sharing some ideas. We sort of stayed away from centralized policy management for quite some time. Originally we thought that IPA will do policy management and did a lot of design around it. However at some point we realized that there is an overlap with the system management and content management for which things like puppet are more suitable. We said then that IdM would focus on managing identity related policies that are traditionally served via LDAP. The things that you are talking about resemble to some extent MSFT GPO and we felt that IdM might not be the right place for it. May be it is time to reassess it. I would however not go that route at least yet. If Desktop can read additional properties related to user (background, default language, etc.) from SSSD over a DBUS interface the SSSD should be able to pull this data from the IdM (eventually). On the IdM we probably can make these additional attributes available in the user entries using class of service like we do with password policies. We have plans for SSSD to handle more attributes than posix and integrate with Desktop. https://fedorahosted.org/sssd/wiki/DesignDocs/AccountsService IMO once this work is started we would be able to see how we can configure and serve more data from IPA for clients to consume. Meanwhile I suggest you create a ticket in IPA trac and put your ideas there. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri
Re: [Freeipa-devel] [PATCH] 259 Combobox keyboard support
Looks good. The patch already provides improvements, so feel free to push. * when CB is non-editable, user can start typing, first character will open list, second will be entered into search input. Note: I wanted to copy the first char to the search box as well, but I did not figure out reliable method for converting keycode to char for non ASCII keyboard layouts Could we use keypress() for this instead of keydown()? See http://api.jquery.com/keypress/. The keypress() should return the actual character, whereas the keydown() would return the code of the keyboard key so it wouldn't be able to distinguish between 'a' and 'A', which is not what we want. Another minor thing, if the search box is in focus, you can use the Up/Down arrow to go to the list. However, from the list you cannot use the Up/Down arrow to go back to the search box, you'd have to use the Tab key. It's not really a problem, but it's not that consistent. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
