Troubleshooting of slow user add or modify operation in certain conditions
by dweller dweller
Hi. I recently created this issue - https://github.com/389ds/389-ds-base/issues/6020
Maybe github is not the place for such general questions so I repost it here. In our deployments we have a lot of production environment for out clients. For granular access every client is placed into separate group (in github issue picture analogue is group-test-<num>) for which HBACs and SUDO rules applied.
But our support team need access all those environments, so support members are placed into the group team-support-l2 which automatically added as a member of every clients group (github issue analogue is user-group). Right now I basically expierience inability to add users to team-support-l2 because it hangs ldap server completly for several minutes, making every freeipa service that depends on ns-slapd inaccessible.
Are we doing something wrong in a way we are setting our group membership? Or should it work just fine with such number of groups?
Problem is the same for 389-ds-base-1.4.3 deployments and 389-ds-base-2.2.3 deployments.
3 months, 4 weeks
Backing up 1.4 (and soon 2.1)
by John Thurston
I'm reviewing our backup/restore scripts and processes. The directory in
question has a single suffix containing about 41,000 entries. It has a
single R/W instance, with several R/O replicas, running
389-Directory/1.4.4.
Working with on-line data, if needed, we could turn one of our R/O
instances into a R/W, and create some new replication agreements. Or, we
could build a new R/W instance, and populate it by exporting the
required information from a R/O instance. We'd have additional work to
do with certs, DNS, and hostnames to put the finishing touches on.
To make an off-line backup of our R/W instance, we have a scripted
process which does:
* dsconf userdata backup create
* dsconf userdata backend export
makes a tar of those and the contents of:
* /etc/dirsrv/slapd-userdata (to pick up certs and scheme extensions)
and parks the resulting .tar in a safe place for a couple of months.
My questions are:
1. After looking this over, I don't see that we are capturing cn=config
Is that implicit in the dsconf 'backup'? Are we just missing it? If
so, how best to capture the objects we want from it?
2. Does the answer change as we shift to 389-Directory/2.1.8 ?
--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston(a)alaska.gov
Department of Administration
State of Alaska
4 months
AD replication with pre-existing groups and user accounts
by Alexander Balz
Hi all,
I recently switched from an old Solaris LDAP to 389 Directory Server,
version 2.0.15.
The Solaris LDAP server also did a synchronization of accounts and
groups to Active Directory,
so there are already many users and groups existing which I imported to
the 389 server.
Concerning the Active Directory synchronization part I am now struggling
a bit.
It would probably be cleanest to remove the old AD user and group
accounts which have been created from Solaris LDAP
such that the 389 DS will create them all anew.
Nevertheless, this attempt was leading to storage access and login
problems for the newly synchronized accounts as Active Directory
assigned new SIDs after the sync and so the storage permissions for home
and other data storage shares got broken. No newly synced user
was able to access their data any more.
So, this procedure is not really an option, as we cannot reset
permissions on all storage servers.
Would it be possible instead to link the 389 DS accounts to the existing
accounts in Active Directory which
were created from the Solaris LDAP server somehow?
Is there e.g. an attribute in the accounts which can be added to
establish a link between 389 and AD accounts?
Currently, these existing accounts seem to be simply skipped by the AD
sync process.
Any hint on this is highly appreciated!
Thank you and best regards,
Alex
4 months, 1 week
Is possible name log pipe with log file
by Nyquist
Hello.
When leaving logs through a pipe, we are concerned that the logs may be lost if there is a problem with the reader.
So, to use both pipes and files, refer to "create a new log pipe file" in the link https://www.port389.org/docs/389ds/howto/howto-use-named-pipe-log-script.....
I have set it up. However, this setting appears to be a way to refer to the pipe in a new path, without leaving both the pipe and the file behind.
What we want to achieve is to not lose logs regardless of the pipe leader state. Any tips on this?
4 months, 2 weeks
389-ds-base name log pipe problems
by Nyquist
Hello
We are using 18 389-ds-base-1.3.10.2,
Recently, one server (A) was set up to log to a pipe.
Afterwards, a phenomenon occurs where all server connections are occupied by an external system.
The external system has stopped.
After this incident, the servers returned to normal condition, but
Only server A had intermittent port 389 inaccessibility and delays.
After this, we determined that the problem on server A was due to logging in the pipe.
After changing the pipe to a file, I restarted the server.
After that the problem went away.
We want to know the exact cause of the delay and inaccessibility that occurred on server A.
How can logging to pipe affect directory server port 389 access?
Could it be a file descriptor related issue? Why were the other 17 servers able to recover to normal?
Thanks
4 months, 2 weeks
ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett
Hi all,
We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this:
[12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”)
Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”.
Has anyone seen this kind of thing before?
This is 389ds running on CentOS7 as follows:
389-ds-base-1.3.9.1-10.el7.x86_64
Regards,
Graham
—
4 months, 2 weeks
Question about @389ds/389-directory-server copr repository
by Rosario Esposito
Hello,
I was running 389-ds 2.2.8 on a RockyLinux 8 machine.
I updated to 389-ds 2.3.7 using copr EPEL-8 repository.
Unfortunately I'm experiencing issues with the new version:
https://github.com/389ds/389-ds-base/issues/6003
So, i would like to revert to the previous version, but apparently 2.2.8 rpms are no longer available on the copr repository, then I cannot issue "dnf downgrade 389*".
Is it supposed to work that way ?
Is there clean way to go back to previous version ?
Regards,
Rosario
4 months, 2 weeks
