Since this our first time running a 389-DS upgrade in a replication
master/slave env, and there are no special references in documentation,
from your past experience, should we consider upgrading first the slave
or master DS? ( upgrade 389-DS 1.2.2 to 1.3.4 )
Thank you for your continue support
Your message was not delivered due to the following reason:
Your message was not delivered because the destination server was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within 7 days:
Host 188.8.131.52 is not responding.
The following recipients could not receive this message:
Please reply to postmaster(a)redhat.com
if you feel this message to be in error.
we are tying to upgrade to 389-ds 1.3.4 from 1.2.2 , after rpm installed
and update the server , when restarting the DS geting the following in
DS errorlog, there is no such "entryallowWeakCipher" in cfg file , what
should we dissable see entries for this cn
SSL alert: Cipher rsa_rc4_128_md5 is weak. It is enabled since
allowWeakCipher is "on" (default setting for the backward
compatibility). We strongly recommend to set it to "off". Please
replace the value of allowWeakCipher with "off" in the encryption config
entry cn=encryption,cn=config and restart the server.
nsSSL3: off ----->>> This was on but turn to "off"
Thank you for your time
Is it just ordinary behavior with 389 DS that search results may take a
very loong time just after starting the server when there are no entries
in the cache yet?
And when the cache is fully saturated (enough cache configured for all
the entries) results become dramatically down - for instance from 4
minutes to 4 seconds.
If this this is so, is there anything that could be done to fill in the
cache automatically after startup?
We have some 60 000 entries, RHEL 7.1, 389-Directory/184.108.40.206
B2015.267.1737 on VMWare.
We have quite a heavy use of roles, and this seems to be a significant
issue especially with them - or at least with them.
We have used the Sun DSEE previously and are quite new to 389 DS. The
technology seems very similar although.
Thanks a lot in advance!
Tampere University of Applied Sciences