Determining max CSN of running server
by William Faulk
I'm having another replication problem where changes made on a particular server are not being replicated outward at all. Right now, I'm trying to determine what's going on during the replication process.
(Caveat: I'm still running an old version of 389ds: v1.3.10. In particular, the dsconf utility does not exist.)
My understanding is that when a server receives a change from a client, it wraps it up as a CSN and starts a replication session with its peers, during which it sends a message that states the greatest CSN that it originated. First off, is that a correct understanding?
If so, how can I determine what CSN a particular server is telling its replication peers during those sessions? I have a feeling that this server is, for some reason, sending an inaccurate number.
In the cn=replica,cn=...,cn=mapping tree,cn=config tree, there are entries for each of the servers topology peers, and they contain nsds50ruv attributes that seem to be the RUVs that that server has received from those peers, right? But the nsds50ruv attribute also exists directly in the cn=replica if you explicitly ask for it. Is it possible that this is the server's own RUV?
Can I rely on the nsds50ruv attributes on this server's peers' cn=replica nsds50ruv attribute values to be an accurate reflection of what this server is sending as its CSN in replication sessions?
Any other way to see what's going on in a replication session? (I'm even trying to decrypt a network capture, but I'm not having any luck with that yet.)
In particular, I see the max CSN for this server in all of these RUVs less than CSNs recorded in the server's own log files.
--
William Faulk
1 month, 3 weeks
Can't delete groups / users
by Phill Harvey-Smith
Hi all,
I've been following the SuSE guide to setting up 389-ds available at :
https://doc.opensuse.org/documentation/leap/security/html/book-security/c...
I've been able to setup a default instance with dscreate
dscreate from-file traken-test-template.txt
This shows up ok, and I can create users/groups
ldap-test:~ # dsidm traken-test group list
demo_group
test
But when I try and delete a group I get :
ldap-test:~ # dsidm traken-test group delete
Enter dn to delete : test
Deleting Group test :
Type 'Yes I am sure' to continue: Yes I am sure
Error: The entry does not exist
What could be wrong?
Also is there a flag I can pass to dsidm to not have to type 'Yes I am
sure' every time, this will make automating stuff a pain.....
I'll include below my create script (with comments stripped) and my ~/.dsrc
Cheers.
Phill.
[general]
full_machine_name = ldap-test.ftt
start = True
[slapd]
db_lib = mdb
instance_name = traken-test
ldapi = /run/slapd-{instance_name}.socket
mdb_max_size = 21138142003.2
port = 389
root_password = redacted
secure_port = 636
self_sign_cert = True
elf_sign_cert_valid_months = 24
[backend-userroot]
changelog_max_age = 7d
changelog_max_entries = -1
create_suffix_entry = False
enable_replication = False
replica_binddn = cn=replication manager,cn=config
replica_bindgroup =
replica_bindpw =
replica_id = 1
replica_role = supplier
require_index = False
hangelog_max_entries = -1
create_suffix_entry = False
enable_replication = False
replica_binddn = cn=replication manager,cn=config
replica_bindgroup =
replica_bindpw =
replica_id = 1
replica_role = supplier
require_index = False
sample_entries = yes
suffix = dc=traken-test,dc=ftt
and my ~/.dsrc[traken-test]
uri = ldapi://%%2fvar%%2frun%%2fslapd-traken-test.socket
basedn = dc=traken-test,dc=ftt
binddn = cn=Directory Manager
2 months
Re: Fwd: dscontainer as non root
by Viktor Ashirov
On Mon, Feb 12, 2024 at 5:37 PM Antony Jose <anto346(a)gmail.com> wrote:
> Thanks Viktor for the response. Appreciate it.
> I have provided an attachment with the details. Dockerfile, kubectl error
> log and security context construct has been provided.
>
> I am using sles15 bci as base os. Do we need add 389 user in Dockerfile?
> Please let me know if you want any further information.
>
The error:
KeyError: 'getpwuid(): uid not found: 389'
indicates that there is no 389 uid found inside the container.
When the 389-ds package is installed, dirsrv user is created by using
systemd-sysusers configuration.
In Fedora/RHEL it has a preference for 389 uid/gid:
https://src.fedoraproject.org/rpms/389-ds-base/blob/rawhide/f/389-ds-base...
But in SUSE it has no preference and takes the first available uid/gid:
https://build.opensuse.org/package/view_file/network:ldap/389-ds/dirsrv-u...
a28855ee79c7:/ # cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
dirsrv:x:499:486:User for 389 directory server:/var/lib/dirsrv:/sbin/nologin
So in your case dirsrv user has 499 as the uid and 486 as gid.
I don't know how stable these mappings are.
And securityContext accepts these values as int64 only, so it's not
possible to specify 'dirsrv' user:
https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/po...
You can add dirsrv user and group with 389 uid/gid before installing
389-ds. And then use 389 as runAsUser and fsGroup values.
HTH
>
>
>
> On Mon, Feb 12, 2024 at 9:38 PM Viktor Ashirov <vashirov(a)redhat.com>
> wrote:
>
>> Hi Antony,
>>
>> On Mon, Feb 12, 2024 at 3:37 PM Mark Reynolds <mareynol(a)redhat.com>
>> wrote:
>>
>>> Forwarding to the correct list....
>>>
>>>
>>> -------- Forwarded Message --------
>>> Subject: dscontainer as non root
>>> Date: Mon, 12 Feb 2024 20:01:09 +0530
>>> From: Antony Jose <anto346(a)gmail.com> <anto346(a)gmail.com>
>>> To: 389-users-owner(a)lists.fedoraproject.org
>>>
>>> Hi,
>>> Can we run dscontainer as non root process. I have deployed
>>> dscontainer on k8s cluster as root user. However running as root user is
>>> not the best security practice. Is there a tested way we can reliably run
>>> ds389 as non root user. I tried tweaking security policies to use a non
>>> root user. However, I get errors during dscontainer start up.
>>>
>> dscontainer certainly can run as non-root user, in the doc that you
>> linked there is a securityContext section with runAsUser and fsGroup values
>> that are set to 389, which is dirsrv user.
>>
>> Can you share errors that you get?
>> Thanks.
>>
>>
>>>
>>> Took inspiration from this doc
>>> https://www.port389.org/docs/389ds/howto/howto-deploy-389ds-on-openshift....
>>>
>>>
>>> Regards
>>> Antony
>>> --
>>> _______________________________________________
>>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>>> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>>> Fedora Code of Conduct:
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
>>> Do not reply to spam, report it:
>>> https://pagure.io/fedora-infrastructure/new_issue
>>>
>>
>>
>> --
>> Viktor
>>
>
--
Viktor
2 months, 2 weeks
Fwd: dscontainer as non root
by Mark Reynolds
Forwarding to the correct list....
-------- Forwarded Message --------
Subject: dscontainer as non root
Date: Mon, 12 Feb 2024 20:01:09 +0530
From: Antony Jose <anto346(a)gmail.com>
To: 389-users-owner(a)lists.fedoraproject.org
Hi,
Can we run dscontainer as non root process. I have deployed
dscontainer on k8s cluster as root user. However running as root user is
not the best security practice. Is there a tested way we can reliably
run ds389 as non root user. I tried tweaking security policies to use a
non root user. However, I get errors during dscontainer start up.
Took inspiration from this doc
https://www.port389.org/docs/389ds/howto/howto-deploy-389ds-on-openshift....
Regards
Antony
2 months, 2 weeks
