I've run into a situation where one of the files in /var/lib/dirsrv/<instance>/changelogdb has grown almost as large as the partition it's on. In my directory server configs, I noticed I was keeping an unlimited changelog, so I set that to what seems like a reasonably long amount of time (18 weeks) but didn't see any decrease in the file size. I'm wondering now about the best course of action. I can
a) move the whole dirsrv directory to another partition with more space available and symlink the old location to the new, which worked when I tested it, but I wanted to make sure I wouldn't be hosing something up the next time I upgrade.
b) find some means of manually shrinking the *.db ( can you even do that?)
c) point dirsrv at a new location, and reinitialize the consumers (which doesn't seem all that desirable)
Has anyone else found it necessary to shrink your changelogdb?
I'd like to start a patch on dynamic group expansion, but dunno where to
Can you point me?
Should be something like reusing VLV code?
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
"Il seguente messaggio contiene informazioni riservate. Qualora questo
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto
della legge in materia di protezione dei dati personali."
The 389 team is pleased to announce the availability of Release
Candidate 1 of version 1.2.6. This release a couple of bug fixes.
***We need your help! Please help us test this software.*** It is a
release candidate, so it may have a few glitches, but it has been tested
for regressions and for new feature bugs. The Fedora system
strongly encourages packages to be in Testing until verified and pushed
to Stable. If we don't get any feedback while the packages are in
Testing, the packages will remain in limbo, or get pushed to Stable.
The more testing we get, the faster we can release these packages to
Stable. See the Release Notes for information about how to provide
testing feedback (or just send an email to
The packages that need testing are:
* 389-ds-base-1.2.6.rc1 - 389-ds-base
* 389-admin-1.1.11.rc1 - 389-admin
There are some new console/java packages too, and there is a new version
of the 389-ds "meta" package - 1.2.1
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
=== Bugs Fixed ===
This release contains a couple of bug fixes. The complete list of bugs
fixed is found at the link below. Note that bugs marked as MODIFIED
have been fixed but are still in testing.
* Tracking bug for 1.2.6 release -
To modify some parameters of the conguration, like nsslapd-cachememsize, it
is required to stop the server and manually change the setting in the
dse.ldif. Is there any way/command/utility to modify that file without using
grep and sed? I say this because when doing this, we must be careful to
check if the attribute is defined, if not create or replace its value using
sed; or change that value only for certain databases, not for all. It should
be like an ldapmodify, but not using an LDAP server, just loading the
specified dse.ldif file and applying the changes specified in other ldif
Any suggestion? Regards.
Although I think the best solution for this is that Samba only update the
Unix password, and the server generates dinamically the sambaLM and sambaNT
passwords using a plugin (perhaps, in the future, we will contribute with
this plugins, but not right now), I have solved the problem described in my
first message in this way, in the samba configuration:
* ldap passwd sync = No
* unix password sync = Yes
* passwd program = /usr/bin/perl -w
/opt/ldap/smbldap-tools/bin/smbldap-passwd -u %u
* passwd chat = "Changing UNIX password for*\nNew password*" %n\n "*Retype
new password*" %n\n "*Password changed*"
So when a user tries to modify his password, then Samba tries to call the
"passwd program", and only if the command returns succesfully (the "passwd
chat" is ok), then it tries to update samba passwords, so the LDAP password
policies are checked when calling the smbldap-passwd script, because it will
fail if the password is not strong enough and the server rejects it.
I had to modify the script smbldap-passwd, because when the password is
changed succesfully, it did'nt print anything, and "passwd chat" needs some
string to check that the change has been succesfully (i had added "password
changed" in the script after the ldap operation when it is succesfull).
Hope this can help somebody.
El 21 de junio de 2010 15:46, Miguel Medalha <miguelmedalha(a)sapo.pt>escribió:
> Emmm, well, this makes samba update userPassword when changing the
>> password from Windows. But if i change the password from Linux, samba
>> passwords are not updated, because linux machines are autheticating directly
>> with LDAP, not with Samba (just userPassword).
> In that case, the LDAP server must be capable of updating the Samba
> passwords when the LDAP password is changed, which takes us back to your
> original question.
> Anyway, the smb.conf parameter to use for that would be:
> "ldap passwd sync = Only"
> (Only = Only update the LDAP password and let the LDAP server do the rest.)
> If the 389 server doesn't do the required operation, I suppose that by
> using the regular LDAP tools (ldapmodify, ldappasswd, etc.) combined with a
> shell script it will be easy to modify all passwords with a single command.
. . . but before we release to the stable repositories, we need your
feedback. Please take a moment to let us know (reply to this message is
fine - bodhi karma is preferred) if you have used 389-ds-base 1.2.6.rc2
and/or 389-admin 1.1.11.rc1 (and related packages) and, if so, what
problems you had, if any. We're trying to be good Fedora community
citizens, while at the same time getting the code out our users quickly.
We have a Windows 2003 AD domain here at work. We have a mix of Windows
servers and Linux servers, and we are looking to consolidate functions
down a little bit. If we can remove the need for AD, we can have 1
Windows server and the rest will be Linux. I've seen from reading the
389-ds site and docs that 389-ds and AD can share information, but what
about REPLACING AD?
Years ago, our functions at work, along with how machines were configured,
lent themselves to having an AD domain. These days, the basic function of
our domain is for authentication. Thats it, nothing else (no Exchange, no
Group Policy, etc.). So, it would seem like 389-ds would suit our needs
very well. So this leads to my question(s):
Has anyone replaced an AD domain with a 389-ds? How did you do it? How
hard was it to migrate the user information from AD to 389-ds? I know
that the Windows box will need pGina installed on it, too. I plan on
putting 2 servers into a test environment to have 389-ds running on 1 with
CentOS 5.4 and Windows 2003 on the other with pGina 1.8.8 on it to test
it. But I'd like to hear if my long-term plan/hope is feasible and if it
can be accomplished.
Common ARTS Software Development
We use 389 Directory as part of our development lab. Every time when we do
a new test, we need to repopulate our 389 directory to a clean slate (i.e.
delete all existing data and re-create a base hierarchy tree).
Our current way of doing so is simply using the ldapdelete command to remove
all existing data and use ldapadd to re-create the base hierarchy tree.
This approach is okay but sometime it could take up to 20 to 30 minutes to
delete all existing data depending on the amount of data saved in the
Is there a more efficient way to repopulate the 389 Directory?
I'm having a problem on a CentOs Directory Server 8.1 multiple master setup.
The database of one of the servers has been marked as corrupt and has been
brought offline by the Directory Server.
Ldapclients querying the ldapserver for e.g. loggin in of users get an
errormessage, effectively disabling users to log in.
I'm wondering what the best method is to recover from this situation.
I can think of a few :
1) Starting the ldapserver, deleting the database, recreating it and
restoring a backup.
2) Starting the ldapserver, deleting the database and reinitialising the
server from the other master.
Can anyone give me some hints if this wil work or would another approach be
Thanks for your advise,