Re: [Freeipa-devel] [PATCH] 1049 validate MLS value
On 08/28/2012 11:16 PM, Rob Crittenden wrote: Validate that the MLS value in a SELinux user map user is in the range c0..c1023. Existing tests validate correct values, empty values, I'm just adding a high value test. rob ACK. Pushed to master, ipa-3-0. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 202 Password policy paging with proper sorting
On 08/28/2012 04:50 PM, Endi Sukma Dewata wrote: ACK. Pushed to master, ipa-3-0. Some comments below. On 8/27/2012 10:51 AM, Petr Vobornik wrote: This patch adds option to disable sorting when paging. It allowed to enable paging in password policy with order of items untouched (they are sorted on server side by priority). Is the sorting we see in the UI and CLI identical to the actual sorting used to resolve the policy? I notice that they are sorted lexicographically instead of numerically. I hope not. New ticket about the sorting: https://fedorahosted.org/freeipa/ticket/3039 Also fixing issue when paging is disabled and command summary = null. It displayed 'null' in facet footer. https://fedorahosted.org/freeipa/ticket/2677 Note: personally I would left paging disabled in password policy page. I don't think it is beneficial. It slows things down and there would be hardly more than 100 policies. This should be confirmed by someone more familiar with actual deployments. I'd have no objections. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 201 Successful action notification
On 08/28/2012 04:49 PM, Endi Sukma Dewata wrote: On 8/27/2012 5:57 AM, Petr Vobornik wrote: User was not notified about success of actions executed from action list, action panel or facet control bar. This patch adds IPA.notify_success(message) call. It creates a yellow notification area with supplied message in Web UI header in the middle of the green area (empty space of first level navigation). This area is displayed for 3s and then it fades out (800ms). It also fades out when it is clicked. This call is used(directly or indirectly) in: * search facets: delete, disable, enable actions * details facets: delete action * user details facet: reset password action * host details facet: unprovision, set OTP actions * service details facet: unprovision action * host and service details facet: request, revoke, restore certificates actions * group details facet: change to POSIX/external actions * dns zone details facet: add/remove permission actions https://fedorahosted.org/freeipa/ticket/2977 ACK. Pushed to master, ipa-3-0. What do you think about creating a console/log page to show the action history? This way if the user misses the notification he still can check the logs. The logs will be stored in memory only and have size limit. The page can also be used to show the CLI commands of those actions. I was thinking about it as well. New ticket: https://fedorahosted.org/freeipa/ticket/3040 I guess it will have really low priority. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 200 Fix issue which broke setup of Web UI unit tests
On 08/28/2012 04:46 PM, Endi Sukma Dewata wrote: On 8/27/2012 5:52 AM, Petr Vobornik wrote: Fix issue which broke setup of Web UI unit tests Web UI itself wasn't negatively affected. Issue introduced in be144da672e0634f7aaeff69d662cbc4d11aff0f (#2897). https://fedorahosted.org/freeipa/ticket/2897 ACK. Pushed to master, ipa-3-0. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 198 Revert change causing failure in test automation
On 08/28/2012 04:43 PM, Endi Sukma Dewata wrote: On 8/22/2012 2:50 AM, Petr Vobornik wrote: Move of click handler in patch for #2834 causes failure of automation tests. This patch reverts the problematic part. It should not affect function of fix for #2834. https://fedorahosted.org/freeipa/ticket/3014 ACK. Pushed to master, ipa-3-0. -- Petr Vobornik ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH 0006] Improves sssd.conf handling during ipa-client uninstall
On 08/27/2012 04:55 PM, Martin Kosek wrote:
On 08/27/2012 03:37 PM, Jakub Hrozek wrote:
On Mon, Aug 27, 2012 at 02:57:44PM +0200, Martin Kosek wrote:
I think that the right behavior of SSSD conf uninstall should be the following:
* sssd.conf existed before IPA install + non-IPA domains in sssd.conf found:
- move backed conf up sssd.conf.bkp (and inform the user)
- use SSSDConfig delete_domain function to remove ipa domain from sssd.conf
- restart sssd afterwards
I'm confused here, which of the files is the original
pre-ipa-client-install file?
This is the backed up sssd.conf. I thought that it may be useful for user to
still have an access to it after uninstall.
How does the non-ipa domain end up in the sssd.conf file? Does it have
to be configured manually or does ipa-client-install merge the list of
domains on installation?
ipa-client-install merge the list of the domains. It overrides the old
sssd.conf only when we cannot parse the sssd.conf and --preserve-sssd option
was not set.
Martin
Hi,
The sssd.conf file is no longer left behind in case sssd was not
configured before the installation. However, the patch goes behind
the scope of this ticked and improves the handling of sssd.conf
during the ipa-client-install --uninstall in general.
The current behaviour (well documented in source code) is as follows:
- In general, the IPA domain is simply removed from the sssd.conf
file, instead of sssd.conf being rewritten from the backup. This
preserves any domains added after installation.
- If sssd.conf existed before the installation, it is restored to
sssd.conf.bkp. However, any IPA domains from pre-installation
sssd.conf should have been merged during the installation.
- If sssd.conf did not exist before the installation, and no other
domains than IPA domain exist in it, the patch makes sure that
sssd.conf is moved to sssd.conf.deleted so user experiences no
crash during any next installation due to its existence.
https://fedorahosted.org/freeipa/ticket/2740
Tomas
From fac8d676d2e727977a8a52bdd2990eb2839b54c4 Mon Sep 17 00:00:00 2001
From: Tomas Babej tba...@redhat.com
Date: Fri, 17 Aug 2012 08:56:45 -0400
Subject: [PATCH] Improves sssd.conf handling during ipa-client uninstall
The sssd.conf file is no longer left behind in case sssd was not
configured before the installation. However, the patch goes behind
the scope of this ticked and improves the handling of sssd.conf
during the ipa-client-install --uninstall in general.
The current behaviour (well documented in source code) is as follows:
- In general, the IPA domain is simply removed from the sssd.conf
file, instead of sssd.conf being rewritten from the backup. This
preserves any domains added after installation.
- If sssd.conf existed before the installation, it is restored to
sssd.conf.bkp. However, any IPA domains from pre-installation
sssd.conf should have been merged during the installation.
- If sssd.conf did not exist before the installation, and no other
domains than IPA domain exist in it, the patch makes sure that
sssd.conf is moved to sssd.conf.deleted so user experiences no
crash during any next installation due to its existence.
https://fedorahosted.org/freeipa/ticket/2740
---
ipa-client/ipa-install/ipa-client-install | 107 +-
1 file changed, 92 insertions(+), 15 deletions(-)
diff --git a/ipa-client/ipa-install/ipa-client-install b/ipa-client/ipa-install/ipa-client-install
index 2e65921e8de2dfe68443f5b5875954d71dd48ed2..c5cef15e1fb3a3e1d7cfd070f4288d3839accfc8 100755
--- a/ipa-client/ipa-install/ipa-client-install
+++ b/ipa-client/ipa-install/ipa-client-install
@@ -183,6 +183,36 @@ def nssldap_exists():
return (retval, files_found)
+# helper function for uninstall
+# deletes IPA domain from sssd.conf
+def delete_IPA_domain():
+sssd = ipaservices.service('sssd')
+try:
+sssdconfig = SSSDConfig.SSSDConfig()
+sssdconfig.import_config()
+domains = sssdconfig.list_active_domains()
+
+IPA_domain_name = None
+
+for name in domains:
+domain = sssdconfig.get_domain(name)
+try:
+provider = domain.get_option('id_provider')
+if provider == ipa:
+IPA_domain_name = name
+break
+except SSSDConfig.NoOptionError:
+continue
+
+if IPA_domain_name != None:
+sssdconfig.delete_domain(IPA_domain_name)
+sssdconfig.write()
+else:
+root_logger.warning(IPA domain could not be found in +
+sssd.conf and therefore not deleted)
+except IOError:
+root_logger.warning(IPA domain could not be deleted. No access to the sssd.conf file.)
+
def uninstall(options, env):
if not fstore.has_files():
@@ -212,7 +242,12 @@ def uninstall(options, env):
sssdconfig =
Re: [Freeipa-devel] Paging in Web UI
On 08/28/2012 08:31 PM, Endi Sukma Dewata wrote: On 8/28/2012 11:23 AM, Petr Vobornik wrote: Your possible solution does not address how many results are fetched (unless I misunderstood). If paging is enabled it doesn't, but it expects, that admin will disable it for larger setups.For smaller setups it isn't of much an issue. If paging is disabled, the limit is server 'search size limit' or --sizelimit option supplied by Web UI. I'm not sure how per-user preferences are handled in browsers, but don't forget we now have session support in the server. Server session data is available for use. I was thinking about using browser local storage (basically key-value DB). It has a benefit over session, that it survives a browser restart but it should contain only non-sensitive data (other users may see it). You mean browser cookie? No. https://developer.mozilla.org/en-US/docs/DOM/Storage Petr Spacek also suggested to have an attribute in user object to store IPA specific data as JSON. Therefore changing browser wouldn't be an issue. If you don't want to fetch every record to implement paging smartly in conjunction with it's performance issues why not do the query on the server, cache the results in the session, and have the RPC return the total number of results plus a subset of the result. Another RPC could retrieve the next/previous subset of results from the cached result in the session. I think most software do paging like this. I don't know the reasons for not doing it that way first time. My solution was counting with that we still don't want to do it. Endi do you know the reasons? Earlier sessions didn't exists, but it is doable without them too. Yes, at the time the sessions didn't exist and we needed a quick/temporary solution. I agree ideally this should be done on the server side, but how would the server maintain the paging information? The server can keep the search result (either just the pkey list or the entire entries) in memcached, but the result might be large and there might be multiple users accessing multiple search pages, so the total memory requirement could be large. I can imagine that if used only by admins it may be OK but if such functionality would be used by other applications it may become problem. If we don't want the server to keep the search result, the server could rerun the search and return only the requested page and discard most of the results each time the user change page. This may affect server performance. We can also use Simple Paged Results, but if I understood correctly it requires the httpd to maintain an open connection to the LDAP server for each user and for each page. I'm not sure memcached can be used to move the connection object among forked httpd processes. Also Simple Paged Results can only go forward, so no Prev button unless somebody keeps the results. Seems unusable. Another possibility is to use VLV, but it seems to require open connection too and only works with a predefined filter. Apart from the possible connection problem I think it is very usable for default views of search pages. User can freely page. I don't understand from the wiki page if it can reasonably obtain total record count. Here's the page I wrote about this: http://freeipa.org/page/IPAv3_Directory_Browsing Currently we're using Option #2 but I'm not sure if we use SPR between httpd and the LDAP server. But even with SPR the result is still bound by some limits. It looks you have to connect as Directory Manager to get the complete list of pkey list/entries. See the table in this page: This is one of the main reasons why I say it is broken. http://directory.fedoraproject.org/wiki/Simple_Paged_Results_Design The current implementation (keeping the pkey list in the UI) is conceptually similar to the front-end approach described in the above page. IMO a modification of a hybrid solution may be best: When user opens page a VLV result would be shown. User can page and see all the data. Currently we don't support custom sorting so disability of custom sorting isn't an issue. With predefined sorts we can even improved these possibilities. If there is many records and user don't want to go through pages he will use search. If the search string is good he should fit to search limit so I wouldn't use paging at this moment. If not the case and he really don't know how to improve the filter he should have option to enable paging (current implementation) and go through the records by hand. Such record set should fit to limit of 2000 records. If not the filter is really bad. If we don't want to implement VLV or until that time I would set not-paging as default setting. I don't think there any need in JSON formatted data for pretty printing with indentation. Is it an accident or oversight we're pretty printing the JSON data in an RPC. For large data sets compression would be a win, but most of our RPC communication is not large.
Re: [Freeipa-devel] Paging in Web UI
On 08/29/2012 07:34 AM, John Dennis wrote: On 08/28/2012 02:31 PM, Endi Sukma Dewata wrote: The server can keep the search result (either just the pkey list or the entire entries) in memcached, but the result might be large and there might be multiple users accessing multiple search pages, so the total memory requirement could be large. The default max size of an entry in memcached is 1MB. It can be increased to an upper limit of 128MB (but the memcached implementors do not recommend this due to degraded performance and the impact on the system). The session data is stored in a dict. You would be sharing the session data with other parts of the system. Currently that only includes the authentication data which is relatively small. I believe there is also some minor bookkeeping overhead that detracts from the per item total. If we need to exceed the upper bound for paged data I suppose we could implement caching within the cache. Almost 1MB of data is a lot of paging (and that limit can be increased), it would take a fair amount of paging to consume all that data. But the cached query could be broken up into cached chunks to limit the impact on memcached and to accommodate truly unlimited paging. In most instance you would fetch the next/prev page from the cache but if you walked off either end of the cached query you could query again and cache that result. In fact two levels of caching might be an actual implementation requirement to handle all cases. We can also use Simple Paged Results, but if I understood correctly it requires the httpd to maintain an open connection to the LDAP server for each user and for each page. Not for each user. In 389-ds-base-1.2.11 you can have multiple simple paged result searches on a single connection - see https://fedorahosted.org/389/ticket/260 This is the problem that VLV and Simple Paged Results are trying to solve - how to allow users to scroll/page through very large result sets. I'm not sure memcached can be used to move the connection object among forked httpd processes. Also Simple Paged Results can only go forward, so no Prev button unless somebody keeps the results. No, the connection object cannot be moved between processes via memcached because sockets are a property of the process that created it. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Paging in Web UI
On 08/29/2012 10:35 AM, Rich Megginson wrote: On 08/29/2012 07:34 AM, John Dennis wrote: On 08/28/2012 02:31 PM, Endi Sukma Dewata wrote: We can also use Simple Paged Results, but if I understood correctly it requires the httpd to maintain an open connection to the LDAP server for each user and for each page. Not for each user. In 389-ds-base-1.2.11 you can have multiple simple paged result searches on a single connection - see https://fedorahosted.org/389/ticket/260 Well this is the crux of the problem. We do not maintain a connection per user. LDAP connections exist for the duration of a single IPA RPC call. Those RPC calls may be multiplexed across multiple IPA server instances, each of which is it's own process. Our LDAP connections are very short lived and are scattered across processes. This is the problem that VLV and Simple Paged Results are trying to solve - how to allow users to scroll/page through very large result sets. -- John Dennis jden...@redhat.com 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] Paging in Web UI
On 8/29/2012 9:49 AM, Rich Megginson wrote: We can also use Simple Paged Results, but if I understood correctly it requires the httpd to maintain an open connection to the LDAP server foreach user and for each page. Not for each user. In 389-ds-base-1.2.11 you can have multiple simple paged result searches on a single connection - see https://fedorahosted.org/389/ticket/260 Well this is the crux of the problem. We do not maintain a connection per user. LDAP connections exist for the duration of a single IPA RPC call. Those RPC calls may be multiplexed across multiple IPA server instances, each of which is it's own process. Our LDAP connections are very short lived and are scattered across processes. So it sounds like, in order to be useful to IPA, we need to extend simple paged results: 1) ability to have the cookie (i.e. the results list and current position in that list) live outside of a connection 2) ability to go backwards in a list Is this correct? If so, please file 389 RFE's for these. For (1) how does the httpd send the information that it wants to use the result list from a previous connection? Is it going to use a new LDAP control? Or would there be a session ID? If we implement (2) does it mean the pages still need to be accessed sequentially, or can we jump to any random page? Also if I understood correctly the LDAP connections are made using user credentials, not Directory Manager, so things like nsslapd-sizelimit will apply. Does it mean a non-admin cannot browse the entire directory? -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Paging in Web UI
On 08/29/2012 09:16 AM, Endi Sukma Dewata wrote: On 8/29/2012 9:49 AM, Rich Megginson wrote: We can also use Simple Paged Results, but if I understood correctly it requires the httpd to maintain an open connection to the LDAP server foreach user and for each page. Not for each user. In 389-ds-base-1.2.11 you can have multiple simple paged result searches on a single connection - see https://fedorahosted.org/389/ticket/260 Well this is the crux of the problem. We do not maintain a connection per user. LDAP connections exist for the duration of a single IPA RPC call. Those RPC calls may be multiplexed across multiple IPA server instances, each of which is it's own process. Our LDAP connections are very short lived and are scattered across processes. So it sounds like, in order to be useful to IPA, we need to extend simple paged results: 1) ability to have the cookie (i.e. the results list and current position in that list) live outside of a connection 2) ability to go backwards in a list Is this correct? If so, please file 389 RFE's for these. For (1) how does the httpd send the information that it wants to use the result list from a previous connection? Is it going to use a new LDAP control? Not sure. Might be able to use the existing simple paged result control. Or would there be a session ID? If we implement (2) does it mean the pages still need to be accessed sequentially, or can we jump to any random page? We should be able support random page access. But I think we could support the ability to go backwards from the current page without random access support. Also if I understood correctly the LDAP connections are made using user credentials, not Directory Manager, so things like nsslapd-sizelimit will apply. Does it mean a non-admin cannot browse the entire directory? in 1.2.10 we have different limits for paged result searches: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Ticket #2866 - referential integrity in IPA
On 08/27/2012 11:32 PM, Rich Megginson wrote: On 08/27/2012 02:27 PM, Martin Kosek wrote: On Mon, 2012-08-27 at 10:29 -0600, Rich Megginson wrote: On 08/27/2012 10:24 AM, Martin Kosek wrote: On 08/17/2012 04:00 PM, Rich Megginson wrote: On 08/17/2012 07:44 AM, Martin Kosek wrote: Hi guys, I am now investigating ticket #2866: https://fedorahosted.org/freeipa/ticket/2866 And I am thinking about possible solutions for this problem. In a nutshell, we do not properly check referential integrity in some IPA objects where we keep one-way DN references to other objects, e.g. in - managedBy attribute for a host object - memberhost attribute for HBAC rule object - memberuser attribute for user object - memberallowcmd or memberdenycmd for SUDO command object (reported in #2866) ... Currently, I see 2 approaches to solve this: 1) Add relevant checks to our ipalib plugins where problematic operations with these operations are being executed (like we do for selinuxusermap's seealso attribute in HBAC plugin) This of course would not prevent direct LDAP deletes. 2) Implement a preop DS plugin that would hook to MODRDN and DELETE callbacks and check that this object's DN is not referenced in other objects. And if it does, it would reject such modification. Second option would be to delete the attribute value with now invalid reference. This would be probably more suitable for example for references to user objects. Any comments to these possible approaches are welcome. Rich, do you think that as an alternative to these 2 approaches, memberOf plugin could be eventually modified to do this task? This is very similar to the referential integrity plugin already in 389, except instead of cleaning up references to moved and deleted entries, you want it to prevent moving or deleting an entry if that entry is referenced by the managedby/memberhost/memberuser/memberallowcmd/memberdenycmd of some other entry. I think that using or enhancing current DS referential integrity plugin will be the best and the most consistent way to go. We already use that plugin for some user attributes like manager or secretary. seeAlso is already covered by default, so for example seeAlso attribute in SELinux usermap object referencing an HBAC rule will get removed when relevant HBAC rule is removed (I just checked that). Note that the managed entry plugin (mep) already handles this for the managedby attribute. I assume you are referencing mepmanagedby and mepmanagedentry attributes which then produce errors like this one: # ipa netgroup-del foo ipa: ERROR: Server is unwilling to perform: Deleting a managed entry is not allowed. It needs to be manually unlinked first. managedBy attribute used by hosts objects I had in mind seems to not be covered. But you are right, this is pretty much what I wanted. Though in case of MEP, there is a link in both referenced objects, but in our case, we have just the one-way link. Are you already using the memberof plugin for memberhost/memberuser/memberallowcmd/memberdenycmd? This doesn't seem like a job for memberof, this seems like more of a new check for the referential integrity plugin. I am now considering if current move/delete clean up already present in Referential Integrity plugin would not be sufficient for us. Rich, please correct me if I am wrong, but in that case, we would just need to add relevant attribute names (memberhost/memberuser/memberallowcmd/memberdenycmd...) to Referential Integrity plugin configuration as nsslapd-pluginarg7, nsslapd-pluginarg8, ... I wonder if there would be some performance issues if we add attributes to the list this way. No, not if they are indexed for presence and equality. But referential integrity will not prevent deletion or moving entries - it will delete/move references. I understand that. After some reconsideration, I think that cleaning up dangling references as postop should be OK for most of the referential attributes we use. But I would like a second opinion on that. So do I understand it correctly, that in case we want to go this way in IPA, the recommended approach DS-wise would be to: - add presence and equality indexes to IPA for the attributes we want to have checked for referential integrity - configure DS Referential Integrity plugin to check these attributes Or would it be better to wait on relevant DS changes you mentioned that Noriko is working on? Also look at the Linked Attribute plugin - it may be able to do what you want right now - http://port389.org/wiki/Linked_Attributes_Design Yes, but this plugin is only relevant for bi-directional links and not for uni-directional links we have in IPA (memberhost/memberuser/memberallowcmd/memberdenycmd...), isn't it? I.e. there is nothing to be filled for managedType attribute of the config. Maybe if the link plugin is enhanced for the uni-directional links too it would help us. It would
Re: [Freeipa-devel] Paging in Web UI
On 8/29/2012 8:49 AM, Petr Vobornik wrote: Another possibility is to use VLV, but it seems to require open connection too and only works with a predefined filter. Apart from the possible connection problem I think it is very usable for default views of search pages. User can freely page. I don't understand from the wiki page if it can reasonably obtain total record count. Correction, VLV doesn't seem to require a continuous connection. The server will return a 'contentCount' in the VLV response: http://www.ietf.org/proceedings/55/I-D/draft-ietf-ldapext-ldapv3-vlv-09.txt IMO a modification of a hybrid solution may be best: When user opens page a VLV result would be shown. User can page and see all the data. Currently we don't support custom sorting so disability of custom sorting isn't an issue. With predefined sorts we can even improved these possibilities. If there is many records and user don't want to go through pages he will use search. If the search string is good he should fit to search limit so I wouldn't use paging at this moment. If not the case and he really don't know how to improve the filter he should have option to enable paging (current implementation) and go through the records by hand. Such record set should fit to limit of 2000 records. If not the filter is really bad. The thing is the filter is only used on certain attributes only. For example I have a user with full name Test User. Searching the Test User in the filter doesn't return anything because the server doesn't search the cn or displayName attributes. In that case I'd have to search with first name or last name only, which may return too many results. If we don't want to implement VLV or until that time I would set not-paging as default setting. How about this, when you open the search page for the first time it will do a regular search, no paging. Instead of showing the paging controls (Prev Next buttons) we show See more results... If you click that it will rerun the search with paging (which will give us the total number of entries) and show the paging control. Agreed, but if we implement the single continuous page I described in the earlier email the page size won't be much of an issue anymore. It may matter. For example when testing Web UI permissions. It often requires to navigate to the last page. I can enter the number directly and press enter or extend it for times (hypothetically) but I would rather see those 90 permissions right away because I can be at the list end in 0.5s. If we use a continuous page we can use a bigger default page size, say 100 entries. We probably could optimize it such that if you scroll directly to the bottom it will load just the last page. We probably could also combine it with initial non-paging search like above, so you'll need to click See more results..., then the page will extend and you can scroll to the last entry. We can also improve pager to offer some subset of pages. For example: First Prev 22 23 *24* 25 26 Next Last Page [ ] where 24 is current page. Yes, that will work too. Regarding the continuous paging: I would extend the page by clicking at a bar at the end of the list and/or by mouse-scrolling at the end of the list? Ideally the scroll bar size should correspond to the visible part of the entire page. So you should be able to go anywhere in the entire page by moving the scroll bar around (either by keyboard, mouse click, mouse drag, or mouse scroll). In this case no need to extend the page. The thing is that we might have to create a table with many empty rows, which could be big, and populate them if they become visible. Maybe there's a way to avoid creating empty rows, we'll need to investigate. Alternatively we could do like image search on bing.com. If you bring the scroll bar say within 10% from the bottom it will load the next page. The thing is it will load the page sequentially, and if you continue to the bottom you'll end up with a very big table. Another possibility, we can use the top 10% of the scroll bar as a Prev button, and the bottom %10 as the Next button, and we remove the pages that aren't visible anymore. But this is not much different than the current implementation, only different presentation. -- Endi S. Dewata ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
