I have a project to rotate some of our ldap logs to our archiving solution
for longer retention. However this solution requires our logs to have
names that match: <logname>.YYYY-MM-DD*. Right now my 389 instance rotates
logs (access and errors) every day into a format like
access.YYYYMMDD-hhmmss. Is there any way to change this construct of log
rotation? Obviously I could script around this, but if there was a way to
change this in an LDAP configuration that would be preferable.
I am trying to make Samba authenticate to DS. I used this guide
http://port389.org/wiki/Howto:Samba, the Samba server is set up also to
authenticate users via SSH/console following this guide
Things are working this way:
when I add a user to Samba (smbpasswd -a user), the LDAP scheme for the
user is modified and there are several new attributes added. One of them
is sambaNTPassword, which seems to be used for authentication. When I
set it via phpldapadmin to '123', the user authenticates with this
password, and not with the one used for SSH for example.
Is there a way to 'force' samba to use the 'password' value instead of
'sambaNTPassword'? I don't want to tell the user that he must remember
different password for accessing Samba.
Thanks in advance,
Is it required (or at least suggested) that multi-mastered directory server
instances have the equal values for dbcache and entry cache settings? If
so, what adverse effects result from not configuring the caches similarly?
With DNA configured for allocating POSIX uids with an MMR setup we see
the range split in half with every new replica provisioned. This is
It appears that if a replica is deleted then its range is lost. Is there
a way to recover this range?
Since each has a start/max value, I guess what we'd have to do is find
whatever server has the closest min value and extend the max value on
that master. I'm assuming we'll need to delegate writing to the DNA
config entry, which I'm a little uncomfortable with.
Is it also safe to assume that this wouldn't require a restart?
Would it be better to instead write a tool to help manage the DNA ranges?
Hi all - thanks for reading!
We are using 389/RHDS as a PKI repository.
We are having an issue with the case of DNs in the directory - switching between upper and lower cases. This may be a string issue. Hopefully someone who's experienced this can help educate me.
My main question is simple - how is the letter case of a DN (or root suffix) controlled? And how can this be changed?
For example, with a "c=us" root suffix, we have a lab directory with a sub-suffix of "o=Lab,c=US".
Another directory has the same "c=us" root suffix, but the sub-suffix we've created is "o=Entrust,c=us"
It may be by scripting the creation of the sub-suffixes that we've done this. We're trying to determine the difference, because we want all directories and therefore certificates issued, to have a c=US country code - capitalized.
In the console, the case of a DN or name is displayed all in lowercase when you view the properties. However in the directory tree view, you can see case differences, and the full DN display on the bottom seems to show the actual case.
I am trying Initialise consumer and i am seeing this in the master server :
Unable to parse the response to the startReplication extended
operation. Replication is aborting.
Incremental update failed and requires administrator action
NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=" (:636)".
NSMMReplicationPlugin - Finished total update of replica "agmt="cn="
(:636)". Sent 253 entries.
NSMMReplicationPlugin - agmt="cn=" (:636): Unable to parse the
response to the startReplication extended operation. Replication is
NSMMReplicationPlugin - agmt="cn=" (:636): Incremental update failed
and requires administrator action
in slave :
NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
referrals for replica dc=xxx,dc=lan: 32
NSMMReplicationPlugin - multimaster_be_state_change: replica
dc=xxx,dc=xxx is going offline; disabling replication
what could be the issue??
how to solve this issue??
i just want some guidance about how to setup slave and start the replication.
we have a master server which is already running.
now i want to setup a slave
what will be the best way to do this ?? (example copying cert files .... )
just copy from master to slave will work ?? or do i need do this via
command line ??
any web link about setup slave from master ..
Thanks for any advise towards this
I'm setting up new 389 ds servers and importing data from old 389
server. One thing is unclear to me. I would like to enforce password
expiration which was not used in old server. Could you explain the
following example value to me:
passwordExpirationTime: 2011 09 16 07 10 26 Z
=> does that mean YYYY-MM-DD-HH-MM-SS (I read max. value is Jan 18 2038)?
=> value does not seem to update automatically, no I need to update it
And how does directory wide setting "Password expires in __ days" relate
The 389 Project team is pleased to announce the release of 389-ds-base-18.104.22.168. This release has fixes for bugs found in 1.3.0 testing and bugs from earlier releases.
Fixed bugs for 22.214.171.124:
Ticket 584 - Existence of an entry is not checked when its password is to be deleted
Ticket 562 - Crash when deleting suffix
yum install --enablerepo=updates-testing 389-ds
yum upgrade --enablerepo=updates-testing 389-ds-base idm-console-framework 389-admin 389-ds-console 389-admin-console 389-dsgw 389-adminutil
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
* Go to https://admin.fedoraproject.org/updates
* In the Search box in the upper right hand corner, type in the name of the package
* In the list, find the version and release you are using (if you're not sure, use rpm -qi <package name> on your system) and click on the release
* On the page for the update, scroll down to "Add a comment" and provide your input
Or just send us an email to 389-users(a)lists.fedoraproject.org
If you find a bug, or would like to see a new feature, you can enter it
here - https://fedorahosted.org/389
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
anyone tried to intergrate these two? All the guides I have found are
for MS AD, I tried to replace stuff like ASAMaccount with other values,
but no luck. I can log in, but UCMDB can not retrieve the groups from
LDAP or vice versa.
Thanks in advance,