[Fedora-directory-devel] skew time error
by vinod gupta
hi,
we installed FDS 1.04 on red hat linux servers with MMR. Everything seems to
be working fine till 4-5 months and suddenly all the MMR broken and says too
excessive skew time and replication aborting. I have tried all the possible
ways that has been mentioned in some of the posts but it din't help. After
some time the same errors come again and again. I have checked my server
time they are all in sync. I am clueless now. Can anybody suggest a way to
help me out of this problem.
Regards
Vinod
15 years, 2 months
[Fedora-directory-devel] memberOf plug-in memory leaks and bugs, proposals of patch
by Ivanov Andrey (M.)
Hi,
I have tried to adapt the memberOf plugin as it exists in today in
the CVS to our production environment - it is a very nice and USEFUL
addition to server features, especially if one has to manage direct
and indirect groups.
We have several relatively large groups (~ 3000 entries). It turned
out that at each full group members delete and recreation I've had
huge memory leaks (~ 100 Mb per each full delete/recreation). I've
tried to narrow it down in the plug-in. here is what i have found (i
structured it in paragraphs) :
§1.There are several slapi_search_internal_get_entry() calls that
return a copy of Slapi_Entry *e that is never released by
slapi_entry_free(). Here are the proposed changes :
--- /tmp/fedora-ds-base-cvs/ldap/servers/plugins/memberof/memberof.c
2008-02-19 07:04:56.000000000 +0100
+++ /tmp/memberof-patched.c 2008-03-23 22:13:00.000000000 +0100
@@ -1019,6 +1019,7 @@
}
bail:
+ slapi_entry_free(e);
return rc;
}
@@ -1310,6 +1311,7 @@
}
slapi_sdn_free(&sdn);
+ slapi_entry_free(group_e);
return rc;
}
@@ -1826,6 +1828,8 @@
bail:
slapi_ch_free_string(&filter_str);
+ slapi_entry_free(group_e);
+ slapi_entry_free(opto_e);
slapi_log_error( SLAPI_LOG_TRACE, MEMBEROF_PLUGIN_SUBSYSTEM,
"<-- memberof_is_legit_member\n" );
§2. I don't know whether the arrays pre_array and post_array in
memberofd_replace_list() function should be freed. I think they should
because they are allocated by slapi_ch_malloc(), but i'm not sure and
i don't know how i should free them - i am not a specialist of the
plugin API. Anyway, apparently this part of code is never used by our
group management applications so i don't have a memory leak caused by
this function.
§3. If we make MODRDN on an INDIRECT group the original indirect group
DN is deleted from memberof but the renamed indirect group DN is not
added. It may be fixed by running every once in a while the memberOf
fixup task BUT in this particular case the attribute will never be
fixed - because of the problem in §4 :
§4. I propose to delete all the memberOf attribute values at the
beginning of the fix thread. Otherwise if we have in the entry a
"memberOf" attribute value equal to a DN of a direct group, the
memeberOf fix task (the function memberof_fix_memberof_callback())
will NEVER add the indirect groupsDNs that depend on the
abovementioned direct group, so this thread is not really a FULL FIX
thread :) Here are the proposed changes to avoid it:
--- /tmp/fedora-ds-base-cvs/ldap/servers/plugins/memberof/memberof.c
2008-02-19 07:04:56.000000000 +0100
+++ /tmp/memberof-patched.c 2008-03-23 22:13:00.000000000 +0100
@@ -2006,6 +2010,7 @@
/* memberof_fix_memberof_callback()
* Add initial and/or fix up broken group list in entry
*
+ * 0. Delete all the memberOf attribute values
* 1. Make sure direct membership groups are in the entry
* 2. Add all groups that current group list allows through nested membership
* 3. Trim groups that have no relationship to entry
@@ -2016,6 +2021,9 @@
char *dn = slapi_entry_get_dn(e);
memberof_add_groups data = {dn, dn};
+ /* step 0. */
+ slapi_entry_attr_delete(e, MEMBEROF_ATTR);
+
/* step 1. and step 2. */
rc = memberof_call_foreach_dn(0, dn, MEMBEROF_GROUP_ATTR,
memberof_add_groups_search_callback, &data);
§5. After the code changes proposed in "§1" i still have ~600 bytes
memory increase per 5000 modifications (2500 DEL & 2500 ADDs to group
membership, the memory increases mainly at DEL operations). I don't
know whether it is due to connection management in slapd code or to
the plug-in itself but it is a much more acceptable value for me than
100Mb :)
§6. #define MEMBEROF_GROUP_ATTR_TYPE "uid" is declared but never used
in the plug-in code...
Thanks once more for this plug-in!
15 years, 2 months
[Fedora-directory-devel] Problems creating a Samba4 LDAP Backend
by Andrew Bartlett
Over the past few weeks, I have been testing OpenLDAP as a backend for
Samba4.
I've been working with the OpenLDAP team on my requirements, and there
has been some really good outcomes - the memberOf module has been
improved, as has the refint module.
However, I seem to have hit a brick wall, in the form of (internal)
transaction support. I need an LDAP backend to support internal
transactions - that is, when for example a 'member' modification is
made, all the memberOf attributes must be updated before the call
returns. Similarly, if a user or group moves, all the member/memberOf
attributes that link the user to their groups must also move, before the
modrdn returns.
The Samba4 test ldap.js tests this behaviour extensively, because I want
to be sure it works.
As understand the discussion I've had with the OpenLDAP team, OpenLDAP
does not support this, and will not support it for perhaps some time.
Similarly, from discussions with the Fedora DS team at the CIFS
developer days, I understand that it is similarly very unlikely that
Fedora DS will support internal transactions. (It also does not support
subtree renames, which we also need).
The fact that LDAP does not expose a transaction API was always going to
be a difficult part of having Samba4 use an LDAP backend, but I always
assumed that if we pushed the really hard bit - updating linked
attributes - into the LDAP server that we could at least always have a
consistent DB. (It turns out this is one of the primary uses of
transactions anyway.)
But without that consistency, and without knowing as a caller if all the
updates succeed, I'm worried about how we can safely move forward.
This is especially disappointing because I was hoping that these free,
replicating LDAP servers might solve the backed replication problem for
me, without needing to use AD replication.
Does anybody have any ideas or suggestions on how I could get around
this?
Should we drop the LDAP backend as a nice idea, but not going to work,
and focus on DRS or some other form of replication?
Can someone imagine a sane way to reconstruct the DN links, including
subtree renames, without the help of the LDAP backend? Could we ban
subtree renames (as Fedora DS does), and try to handle this ourselves
(with pre/post checks and a good deal of prayer)?
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
15 years, 2 months
[Fedora-directory-devel] Where to note Samba4 required features?
by Andrew Bartlett
Given my previous mail about the suitability of OpenLDAP and Fedora DS
as a Samba4, can someone remind me where I need to list my feature
requests? I realise that things like subtree renames and transactions
might be positioned somewhere between 'unlikely' and 'never' (give
discussions on the technical complexity in the codebase), but I figure I
should list them somewhere...
Thanks,
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
15 years, 2 months
[Fedora-directory-devel] Please review: [Bug 436388] LDAPI: introduce --enable-autobind to support AUTOBIND
by Noriko Hosoi
Summary: LDAPI: introduce --enable-autobind to support AUTOBIND
https://bugzilla.redhat.com/show_bug.cgi?id=436388
Description of problem:
* Auto bind codes are all in the ENABLE_AUTOBIND macro. Should we
enable it and support the functionality?
rmeggins wrote:
> > Yes, but turned off by default.
>
Okay. then should we add --enable-autobind to configure.ac? rmeggins wrote:
> > Yes.
>
Or should ENABLE_AUTOBIND be part of LDAPI? I feel autobind is tightly
coupled with LDAPI, ENABLE_AUTOBIND could be replaced with ENABLE_LDAPI
and merge template-ldapi-autobind into template-ldapi-default? rmeggins
wrote:
> > I think there may be some security conscious people who will not want to
>
enable autobind at all and will want to build without it.
------- Additional Comments From nhosoi(a)redhat.com 2008-03-14 18:19 EST -------
autoconf gets uid # and gid # from the LDAPI UNIX socket and retrieve the
matched entry from the backend to bind the server.
For example,
Assume these are my uid # and gid # on the test system:
$ id
uid=12345(nhosoi) gid=12345(nhosoi)
Add this posix account to the server:
dn: uid=nhosoi, dc=example,dc=com
objectclass: top
objectclass: posixAccount
cn: noriko hosoi
uid: nhosoi
uidNumber: 12345
gidNumber: 12345
homeDirectory: /home/nhosoi
loginShell: bash
userPassword: nhosoi
Then, run the search against LDAPI UNIX socket without the bind user. Autobind
internally searches an entry with the filter
(&(uidNumber=12345)(gidNumber=12345)) and binds using the found entry.
$ ldapsearch -H ldapi://%2fvar%2frun%2fslapd-laputa.socket/ -w nhosoi -Y
DIGEST-MD5 -b "dc=example,dc=com" "(cn=*)"
SASL/DIGEST-MD5 authentication started
SASL username: nhosoi
SASL SSF: 128
SASL installing layers
[...]
Tested on RHEL4.
To use autobind, ldapi, autobind, and maptoentries need to be turned on.
nsslapd-ldapifilepath: /var/run/slapd-laputa.socket
nsslapd-ldapilisten: on
nsslapd-ldapiautobind: on
nsslapd-ldapimaprootdn: cn=Directory Manager
nsslapd-ldapimaptoentries: on
nsslapd-ldapiuidnumbertype: uidNumber
nsslapd-ldapigidnumbertype: gidNumber
nsslapd-ldapientrysearchbase: dc=example,dc=com
nsslapd-ldapiautodnsuffix: cn=peercred,cn=external,cn=auth
------- Additional Comments From nhosoi(a)redhat.com 2008-03-14 18:30 EST -------
Created an attachment (id=298099)
--> (https://bugzilla.redhat.com/attachment.cgi?id=298099&action=view)
cvs diff configure.ac Makefile.am
15 years, 2 months
[Fedora-directory-devel] Please review: [Bug 436397] New: LDAPI: move default LDAPI UNIX socket from /var/run/dirsrv/slapd-ID.socket to /var/run/slapd-ID.socket
by Noriko Hosoi
After the discussion, we agreed to move the LDAPI UNIX socket from
RHDS/FDS run_dir (/var/run/dirsrv, by default) to its parent directory.
Thanks,
--noriko
https://bugzilla.redhat.com/show_bug.cgi?id=436397
Summary: LDAPI: move default LDAPI UNIX socket from
/var/run/dirsrv/slapd-ID.socket to /var/run/slapd-
ID.socket
Product: Fedora Directory Server
Version: 1.1.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: Directory Server
AssignedTo: nhosoi(a)redhat.com
ReportedBy: nhosoi(a)redhat.com
QAContact: ckannan(a)redhat.com
Estimated Hours: 0.0
Description of problem:
* If fedora-ds-base is installed by root, the mode of
/var/run/dirsrv is 0750, which prevents ordinary users to access
the UNIX socket. Should the mode be 0755? Or we don't allow
non-root/non-nobody users to use LDAPI?
drwxr-x--- 2 nobody nobody 4096 Mar 5 13:57 /var/run/dirsrv/
It's set by makeDSDirs in DSCreate.pm.
rmeggins wrote:
> > We should see what OpenLDAP does - they use /var/run/ldapi by default - what
>
mode is that by default? It's about the intermediate directory's
permission. OpenLDAP just has /var and /var/run. ldapi is already the
socket, isn't it? rmeggins wrote:
> > Yes.
>
We have one more level /var/run/dirsrv, which is hiding the socket from
non-root and non-nobody... But yes, I have to install openldap and
investigate more. rmeggins wrote:
> > Hmm - we probably don't want to open up /var/run/dirsrv if we don't have to -
>
maybe we should move the socket into /var/run? e.g.
/var/run/slapd-instance.socket? I think that's a good idea. One thing
I'd like to make sure is we have to worry about RHDS/FDS coexisting with
OpenLDAP server on one host? Something like, if port 389 is already
taken, our setup-ds offers alternative. Do we need to do something
similar for LDAPI socket? rmeggins wrote:
> > If there is already a /var/run/ldapi and it is in use by openldap (or another
>
redhat/fedora ds) we probably don't want to use it. nalin wrote:
> > When OpenLDAP's libldap gets 'ldapi:///' as a URI, it tries to connect
> > to '/var/run/ldapi'. Perhaps we should just use that?
> >
> > Nalin
>
------- Additional Comments From nhosoi(a)redhat.com 2008-03-13 16:36 EST -------
Created an attachment (id=297983)
--> (https://bugzilla.redhat.com/attachment.cgi?id=297983&action=view)
cvs diff DSCreate.pm.in
Description: create an LDAPI UNIX socket at the parent dir of run_dir
(/var/run/dirsrv, by default).
Test result.
Installed by root and the server's owner is nobody.
# ls -l /var/run/slapd-*socket
srw-rw-rw- 1 root root 0 Mar 13 10:28 /var/run/slapd-laputa1.socket
[..] - Red Hat-Directory/8.0.0 B2008.073.1814 starting up
[..] - slapd started. Listening on All Interfaces port 10391 for LDAP requests
[..] - Listening on /var/run/slapd-laputa1.socket for LDAPI requests
15 years, 2 months
[Fedora-directory-devel] Please Review: (435730) Allow fractional replication between masters
by Nathan Kinder
https://bugzilla.redhat.com/show_bug.cgi?id=435730
Resolves: bug 435730
Bug Description: Fractional replication is only currently allowed when the
agreement destination is a read-only replica. We should allow fraction
replication when the destination is a master or a hub, with the caveat
that the attributes replicated for all agreements between masters are
exactly the same.
This change is needed to support attributes that are dynamically generated
by each server instance, as is done when using the recently added memberOf
plug-in.
Reviewed by: ???
Files: see diff
Branch: HEAD, Directory_Server_8_0_Branch
Fix Description: The fix simply removes the check to see if we're trying
to use a fractional agreement with a non-read-only replica when we
acquire
the replica.
Platforms tested: RHEL5.1 i386
Flag Day: no
Doc impact: Yes. We need to document that agreements need to replicate
the same attributes in both directions when using fractional between
masters.
https://bugzilla.redhat.com/attachment.cgi?id=296630&action=diff
15 years, 3 months
[Fedora-directory-devel] Creating an OSX Port
by Todd Nine
Hi all,
I'm a J2EE Developer, and an amateur system admin. I absolutely love
Fedora Directory, and I'd like to attempt to port the console to Mac and
create a simple install DMG. I read on the requirements that a Sun JDK is
required. Has anyone successfully run on an OS X jdk. Is it even possible,
or does it require linux specific gtk libraries in java?
Thanks,
Todd
15 years, 3 months