389 directory server console crash and core dump
by xinhuan zheng
Today I installed the 389 Directory Server and Directory Console. However, the console keeps crashing and dumping core. However, it failed to write core dump, leaving a log file into root directory.
The first time when it dumps core:
1. Launch the 389-console
2. Login
3. Select Directory Server Instance, in my case, its userauth1, open it
4. Choose Configuration Tab, expand data
5. Right click on it, choose New Suffix
6. Type in New Suffix name: dc=test2,dc=com
7. Type in Database name: test2
8. Click OK.
Then it dumps core. I re-launch the console, but I cannot find the newly added suffix.
So I decide to add it again, but the console spit out error that "suffix already exists". Console does not display the newly added suffix, however, it thinks it does exist.
I repeated adding another new suffix with a different name. It works without core dump.
I repeated adding/deleting new suffix a few more times. It appears core dump happens either when adding or deleting root suffix, randomly.
I need help to figure out
1) How do I delete the root suffix that cannot be displayed by the console?
2) How do I make console stable.
The java package, java-1.6.0-openjdk-1.6.0.38-1.13.10.0.el6_7.x86_64, is installed and used on my CentOS 6.7 x86_64 machine.
Thanks,
7 years, 12 months
Re: locking performance and scalability (eye candy gnuplots inside!)
by Howard Chu
> The spinlocks of course just do their thing, and then we're much more
> reliant upon the hardware to provide fairness, and as we see, this may
> not be a safe bet.
>
> We also see in the third graph and fifth graphs that the first core
> performed badly compared to the others. I do not know why, but it needs
> explanation.
>
> Relating to this though, although I don't have other plots, but I did do
> quite a lot of benchmarking with the prototype benchmark app, and I
> seemed to find on some machines that some cores *always* did badly, and
> for *all* lock types. I have a weak suspicion it reflects internal
> memory access arrangements in the core itself. However, this was on VMs
> - although they were all dedicated hardware, so I had no neighbours on
> the box - so it could just be Xen doing strange things.
Even though it's a VM, numactl -H may still show something relevant.
BerkeleyDB did adaptive locking, using a spinlock before falling back to a
heavier weight system mutex. In practice we always found that spinlocks are
only a win within a single CPU socket; as soon as you have cross-socket
contention they're horrible.
The other obvious contributor to system balance is interrupt steering. Most
kernels seem to have irqbalance working by default these days, but you may
still wind up with a particular core getting more than a fair share of
interrupts sent to it. Again, not something you can directly tweak inside a VM
with any meaningful effect. Aside from that, it's not always beneficial to do
what irqbalance does. Sometimes you get much better system throughput by
sacrificing a core, sending all interrupts to it, leaving all the remaining
cores for the application. Fewer context switches on the remaining cores,
which leads to much higher efficiency.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years
Installing 389DS on CentOS7, missing rpms?
by Jonathan Vaughn
TL;DR: Are 389-admin-console / 389-ds-console just the java GUI admin
tools, in which case I don't need them on the server?
We are starting the process of upgrading all our CentOS 6 systems to 7, and
along the way we're of course upgrading 389DS.
Hopefully I can simply spin up a new 389DS on a machine that is upgraded
(from scratch) to 7, set up MMR and let it consume everything off one of
the existing replicas, then take one of the old ones out of service, rinse
and repeat until they're all done.
Having been many years since settings these up, I am for all intents and
purposes having to relearn everything.
Various guides to installing 389DS on CentOS 7 indicate some packages
aren't available that I would need. Some of these have become available via
either 'epel' or 'updates', but I'm still missing some.
Have:
389-admin.x86_64 1.1.38-1.el7 epel
389-adminutil.x86_64 1.1.21-2.el7 epel
389-adminutil-devel.x86_64 1.1.21-2.el7 epel
389-console.noarch 1.1.9-1.el7 epel
389-ds-base.x86_64 1.3.4.0-26.el7_2 updates
389-ds-base-devel.x86_64 1.3.4.0-26.el7_2 updates
389-ds-base-libs.x86_64 1.3.4.0-26.el7_2 updates
idm-console-framework.noarch 1.1.14-1.el7 epel
Don't have:
389-admin-console
389-ds-console
What exactly do these missing packages provide, and will I be fine without
them? From the descriptions on rpmfind.net it sounds like these are just
the java admin consoles, which I don't really need since I normally do
everything from consoles installed on my workstation instead - though it
would be nice to have them so we at least have the option of someone
running them with an X tunnel if they don't have them installed locally,
but that's not mission critical.
8 years
Replication critical problem
by Dael Maselli
Our authentication and authorization infrastructure is based on 3
multi-master server and 2 slaves with 35 databases each, all have the
following version of 389:
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.11.15-60.el6.x86_64
389-ds-base-libs-1.2.11.15-60.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.11-1.el6.x86_64
We are experiencing a strange behavior, replication of new attributes,
new values of attributes and modification of values are propagated
correctly, but deleting a value of attribute are propagated randomly, no
matter of what master starts the modification or what database we
modify, big or little ones.
I tried reinitializing database from one master but the problem
persists, no errors are logged.
Now our server are not synchronized and this is, as you can imagine,
very bad ;-)
Thank you very much!
Regards,
Dael Maselli.
--
___________________________________________________________________
Dael Maselli --- INFN-LNF Computing Service -- +39.06.9403.2214
___________________________________________________________________
* http://www.lnf.infn.it/~dmaselli/ *
___________________________________________________________________
Democracy is two wolves and a lamb voting on what to have for lunch
___________________________________________________________________
8 years
Unable to connect to Admin server via 389 windows console
by Daniel Franciscus
Hello,
I am having an issue connecting to our 389 server, but only from windows servers it seems. It works fine on a Windows 7 workstation.
What I have checked:
* Verified connectivity to port 9830
* Verified java version 7.0.90 installed and in the Path environment variable
* Can ping the hostname of the 389 server
* Tested on two Windows Server 2012 R2 servers
I get the error: Cannot connect to the Admin server "<server name>" The URL is not correct or the server is not running.
Dan Franciscus
Systems Administrator
Information Technology Group
Institute for Advanced Study
609-734-8138
8 years
Fwd: Adding a root user with uid 0
by Dhiraj Deshpande
Hello Guys,
I want to add an user with UID 0. When i add any user with UID 0, it won't
reflects on client side. It shows no user found. But if i change the same
user's UID to non-zero, it reflects on client side.
Some how it is not taking a root account. Anybody faced the same?
--
--
Thanks & Regards
Dhiraj S. Deshpande
8 years
389 Backup
by wodel youchi
Hi,
Is it possible to create a specific user to use to backup 389DS server
other than the Directory Manager, to use the db2bak.pl with a cronjob
without exposing the DM password.
Regards.
8 years
User Password Hash Support
by Wendt, Trevor
Is there a way for 389ds to support an ldif import of users with a password format of "{SHA-256, 10000, 24}<hash_string_87_characters_long>=" ?
Currently the import is successful but 389ds converts it to an SSHA format and salt pairing but when trying authenticate with the known password, account fails.
Thanks.
________________________________
This electronic message transmission contains information from Black Hills Corporation, its affiliate or subsidiary, which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware the disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic transmission in error, please reply to sender immediately; then delete this message without copying it or further reading.
8 years