[Fedora-directory-devel] Please review: Bug 233642: MMR breaks with time skew errors
by Rich Megginson
https://bugzilla.redhat.com/show_bug.cgi?id=233642
Resolves: bug 233642
Bug Description: MMR breaks with time skew errors
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: CSN remote offset generation seems broken. We seem to
accumulate a remote offset that keeps growing until we hit the limit of
1 day, then replication stops. The idea behind the remote offset is
that servers may be seconds or minutes off. When replication starts,
one of the itmes in the payload of the start extop is the latest CSN
from the supplier. The CSN timestamp field is (sampled_time + local
offset + remote offset). Sampled time comes from the time thread in the
server that updates the time once per second. This allows the consumer,
if also a master, to adjust its CSN generation so as not to generate
duplicates or CSNs less than those from the supplier. However, the
logic in csngen_adjust_time appears to be wrong:
remote_offset = remote_time - gen->state.sampled_time;
That is, remote_offset = (remote sampled_time + remote local offset +
remote remote offset) - gen->state.sampled_time
It should be
remote_offset = remote_time - (sampled_time + local offset +
remote offset)
Since the sampled time is not the actual current time, it may be off by
1 second. So the new remote_offset will be at least 1 second more than
it should be. Since this is the same remote_offset used to generate the
CSN to send back to the other master, this offset would keep increasing
and increasing over time. The script attached to the bug helps measure
this effect. The new code also attempts to refresh the sampled time
while adjusting to make sure we have as current a sampled_time as
possible. In the old code, the remote_offset is "sent" back and forth
between the masters, carried along in the CSN timestamp generation. In
the new code, this can happen too, but to a far less extent, and should
max out at (real offset + N seconds) where N is the number of masters.
In the old code, you could only call csngen_adjust_time if you first
made sure the remote timestamp >= local timestamp. I have removed this
restriction and moved that logic into csngen_adjust_time. I also
cleaned up the code in the consumer extop - I combined the checking of
the CSN from the extop with the max CSN from the supplier RUV - now we
only adjust the time once based on the max of all of these CSNs sent by
the supplier.
Finally, I cleaned up the error handling in a few places that assumed
all errors were time skew errors.
Platforms tested: RHEL5, F8, F9
Flag Day: no
Doc impact: no
QA impact: Should test MMR and use the script to measure the offset effect.
https://bugzilla.redhat.com/attachment.cgi?id=310040&action=diff
15 years, 5 months
[Fedora-directory-devel] Please review: [Bug 437525] GER: allow GER for non-existing entries
by Noriko Hosoi
Summary: GER: allow GER for non-existing entries
https://bugzilla.redhat.com/show_bug.cgi?id=437525
FDS is trying to support these requirements.
http://directory.fedoraproject.org/wiki?title=Get_Effective_Rights_for_no...
> Get Effective Rights is enhanced to support these requirements:
>
> 1. a requester should be able to see the effective rights of each
> entry returned from the search request if the subject user is
> identical to the requester. This functionality can be used, e.g., for
> an address card to determine which fields to be writable and to be
> grayed out depending upon the user who opens the card.
>
> 2. the attribute list to be retrieved accepts '*' for the all the
> available attributes belonging to the returned entry as well as '+'
> for the operational attributes to allow the requester get the
> effective rights of all the non-existing attributes.
>
> 3. the attribute list to be retrieved accepts
> "<attr>@<objectclassname>", where <attr> is an attribute type (e.g.,
> cn) or '*' for all attributes and <objectclassname> is a type of
> objectclass (e.g., inetorgperson).
>
Your reviews would be greatly appreciated.
--noriko
------- Additional Comments From nhosoi(a)redhat.com 2008-06-20 19:24 EST -------
Created an attachment (id=309953)
--> (https://bugzilla.redhat.com/attachment.cgi?id=309953&action=view)
cvs diffs
Files:
ldap/servers/slapd/charray.c
ldap/servers/slapd/opshared.c
ldap/servers/slapd/pblock.c
ldap/servers/slapd/result.c
ldap/servers/slapd/schema.c
ldap/servers/slapd/search.c
ldap/servers/slapd/slapi-plugin.h
ldap/servers/slapd/slapi-private.h
ldap/servers/plugins/acl/acleffectiverights.c
ldap/servers/plugins/chainingdb/cb_config.c
ldap/servers/plugins/chainingdb/cb_controls.c
ldap/servers/plugins/chainingdb/cb_instance.c
Change descriptions:
[slapd/charray.c]
new: charray_merge_nodup -- merge 2 string arrays skipping the duplicates
modified: charray_remove -- introduced "freeit" flag. If true, the removed
string is freed. (The API is used only in chainingdb. The change is applied
to the plugin.)
[slapd/opshared.c]
modified: check OP_FLAG_GET_EFFECTIVE_RIGHTS in the iterate to support
"@<objectclass>". It's needed to do at the location since we have to call acl
plugin even
when no entries are returned from the search. If no entries are returned and
"@<objectclass>" is found in the attribute list, acl effective rights code
generates the corresponding template entry.
[slapd/pblock.c]
place to store gerattrs is added (SLAPI_SEARCH_GERATTRS), where gerattrs is an
array of strings which store "...@<objectclass>".
[slapd/result.c]
moved OP_FLAG_GET_EFFECTIVE_RIGHTS checking to iterate (opshared.c)
[slapd/schema.c]
new: slapi_schema_list_objectclass_attributes -- return the required and/or
allowed attributes belonging to the given objectclass. This is used to support
"*" and "+" in the get effective rights.
new: slapi_schema_get_superior_name -- return the superior objectclass name of
the given objectclass.
[slapd/search.c]
if "<attr>@<objectclass>" is found in the attribute list, cut the <attr> part
out and added to the attrs array (pblock SLAPI_SEARCH_ATTRS) and store the
original
string to the gerattrs (pblock SLAPI_SEARCH_GERATTRS).
[plugin/acl/acleffectiverights.c]
modified: _ger_g_permission_granted -- if the requester and the subject user
are
identical, give "g" permission
modified: _ger_parse_control -- replaced strcpy with memmove since strcpy does
not guarantee the result of the overlap copy.
modified: _ger_get_attrs_rights -- support "*" (all attributes belonging to the
object) and "+" (operational attributes). If repeated attributes are found in
the given attribute list, they are reduced to one.
new: _ger_generate_template_entry -- generate a template entry if
"@<objectclass>" is passed.
[pluginc/cb/*]
adjusted to the updated charray_remove.
Please see also this wiki page for the overview and test cases.
http://directory.fedoraproject.org/wiki/Get_Effective_Rights_for_non-pres...
15 years, 5 months
[Fedora-directory-devel] Using Directory Client without an admin server running
by "Sztupák Sz. Zsolt"
Hi!
I was just curious: Is it officially possible to use the directory
client for LDAP-related jobs without having an admin server running? I
mean most of the things you'll use the client for is LDAP related
(adding-removing users, changing attributes, changing ACLs, etc.), and
there is no need for an admin server to be running.
Unofficially I managed to hack a small groovy script that will run the
DS client (inside fedora-ds-1.1.jar) and connect to a server. Browsing
the directory and changing attributes works, but adding a new entry, or
changing ACL-s will crash the program (but I'm trying to figure out
why). You still need an "o=netscaperoot" base in your LDAP directory,
but at least the admin server need not be running (we are running a
service on a Gentoo Linux based machine with Lighttpd, and don't want to
use/install Apache).
SztupY
console.groovy:
// create a fedora-ds-1.1.jar in your home directory containing all
classes (merge all jar files IDM uses into one named fedora-ds-1.1.jar)
for this script to work
import com.netscape.admin.dirserv.DSAdmin;
import com.netscape.management.client.console.*;
import com.netscape.management.client.util.Debug;
import java.awt.*;
import netscape.ldap.*;
com.netscape.management.client.util.Debug.setTraceLevel(9);
DSAdmin d = new DSAdmin();
ConsoleInfo i = new
ConsoleInfo("HOST_NAME",389,"USER_NAME","PASSWORD","o=NetscapeRoot");
LDAPConnection c = new LDAPConnection();
c.connect("HOST_NAME",389,"USER_NAME","PASSWORD");
i.setLDAPConnection(c);
i.setCurrentDN("cn=SERVER_NAME,cn=fedora directory server,cn=server
group,cn=HOST_NAME,o=netscaperoot");
i.setAdminOS("Windows"); // in Windows
d.initialize(i);
Component cc = d.getCustomPanel();
d.select(null);
d.run(null);
15 years, 5 months
[Fedora-directory-devel] Please Review: (450989) memberOf: Make group and memberOf attributes configurable
by Nathan Kinder
https://bugzilla.redhat.com/show_bug.cgi?id=450989
Resolves: bug 450989
Bug Description: The memberOf plug-in is currently hardcoded to use
the "member" and "memberOf" attributes for group membership. These
attributes should be configurable.
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: The fix allows these attributes to be configured in the
plug-in
configuration entry. The configuration can be dynamically changed
over LDAP
with the server running. We ensure that the configuration doesn't
change while
a memberOf operation is in progress by obtaining the memberOf lock
while the
changes are applied. I also made the filter that is used to check if
a group
membership change is made a part of the configuration struct since it
is based
off of one of the configurable attributes.
In addition to the above changes, I removed an unnecessary function
that was
wrapping slapi_str2filter(). The previous code was doing a malloc of
the filter
string, needlessly duplicating the string, then creating the
Slapi_Filter (which
does a malloc as well). The two copies of the filter string were then
just
free'd. This was inefficient, so I removed the wrapper function so
that we
simply malloc the filter string and pass it to slapi_str2filter() to
allocate
the Slapi_Filter. This saves us one malloc/free.
Platforms tested: F9 i386
Flag Day: No.
Doc impact: Yes, the config attributes will need to be doc'd.
https://bugzilla.redhat.com/attachment.cgi?id=309023&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=309024
https://bugzilla.redhat.com/attachment.cgi?id=309025
15 years, 5 months