389-devel

389-devel@lists.fedoraproject.org

1 participants
5356 discussions

please review: PR 6239 - RFE - Add option to write audit log in json format
by Mark Reynolds 27 Jun '24

27 Jun '24

https://github.com/389ds/389-ds-base/pull/6239 https://www.port389.org/docs/389ds/design/audit-json-logging-design.html -- Identity Management Development Team

1 0

please review: PR 6180 - audit log buffering doesn't handle large updates
by Mark Reynolds 28 May '24

28 May '24

https://github.com/389ds/389-ds-base/pull/6180/files -- Identity Management Development Team

1 0

Please review: PR 14 (wiki) - Audit JSON logging design
by Mark Reynolds 09 Apr '24

09 Apr '24

This is a rough draft of a design for JSON logging of audit events. Please share your thoughts on this and how it could potentially be improved. https://github.com/389ds/389ds.github.io/pull/14 Thanks! -- Identity Management Development Team

1 0

please review: PR 6116 - Add client info to audit log events
by Mark Reynolds 05 Mar '24

05 Mar '24

https://github.com/389ds/389-ds-base/pull/6116 -- Identity Management Development Team

1 0

please review: PR 6113 - New MFA operation note for logging/auditing
by Mark Reynolds 01 Mar '24

01 Mar '24

https://github.com/389ds/389-ds-base/pull/6113 -- Identity Management Development Team

1 0

please review: PR 6109 - Add log buffering to audit/auditfail logs
by Mark Reynolds 28 Feb '24

28 Feb '24

https://github.com/389ds/389-ds-base/pull/6109 -- Identity Management Development Team

1 0

Please Review: PR #6091: vlv search may return wrong result.
by Pierre Rogier 21 Feb '24

21 Feb '24

In practice there were several issues so vlv index were not properly recreated by import/bulk import/reindex https://github.com/389ds/389-ds-base/pull/6091 -- -- 389 Directory Server Development Team

1 0

389-ds-base Branching Strategy
by Simon Pichugin 06 Feb '24

06 Feb '24

Hi team, I want to clarify and document our branching and release strategy to set the correct expectations for different distributions and future 389-ds-base maintainers. Recently, I assumed that we have this branching strategy: - The development happens in the *main.* We cherry-pick the needed fixes to other branches as required. - When we release a new *X.Y *version (bump version, create tag, create release), we create a separate branch *389-ds-base-X.Y.* - The main at this point becomes future *389-ds-base-X.Y+1* (without bumping the version there, for now), and we continue the development there while cherry-picking to other branches + 389-ds-base-X.Y. It ignited a discussion... So please, if you disagree with the above, describe the release flow you think we have/should have. We must make it very transparent for other distributions besides RHEL/Fedora. Also, an important question will be: - Do SUSE/Debian/Archlinux/etc. need the *389-ds-base-X.Y *branch created right away after the *X.Y* official GitHub release? Or can it be postponed? Please, maintainers, let us know. Regards, Simon

2 1

Fwd: SSSD not using 389-ds to auth for SUDO
by Bindu G 23 Jan '24

23 Jan '24

Hello All, ldapsearch output as follows: # LDAPAdministrator1, Groups, cee, nsn dn: cn=LDAPAdministrator1,ou=Groups,ou=cee,o=nsn member: uid=bindu1,ou=People,ou=cee,o=nsn member: uid=bindu2,ou=People,ou=cee,o=nsn objectClass: top objectClass: groupofnames objectClass: posixGroup objectClass: nsMemberOf cn: LDAPAdministrator1 gidNumber: 1520 # %LDAPAdministrator1, Groups, cee, nsn dn: cn=%LDAPAdministrator1,ou=Groups,ou=cee,o=nsn cn: %LDAPAdministrator1 objectClass: top objectClass: sudoRole sudoHost: ALL sudoCommand: ALL sudoOption: !authenticate sudoRunAsUser: ALL sudoUser: %LDAPAdministrator1 /etc/sssd/sssd.conf [nss] enum_cache_timeout = 30 filter_users = root filter_groups = root reconnection_retries = 3 memcache_timeout = 3600 [pam] offline_credentials_expiration = 3 offline_failed_login_attempts = 5 [sudo] debug_level = 9 [ssh] [domain/cee] debug_level = 9 full_name_format = %1$s min_id = 1500 max_id = 41999 enumerate = true cache_credentials = true account_cache_expiration = 5 id_provider = ldap auth_provider = ldap access_provider = ldap chpass_provider = ldap ldap_uri = ldap://lcm-int-vip ldap_tls_reqcert = demand ldap_tls_cacert = /var/lib/pki/endpoints/sssd/cacert/infrastructure-chain.pem ldap_id_use_start_tls = true ldap_enumeration_refresh_timeout = 10 ldap_purge_cache_timeout = 60 entry_cache_timeout = 600 ldap_network_timeout = 2 ldap_user_search_base = ou=People,ou=cee,o=nsn ldap_schema = rfc2307bis ldap_default_bind_dn = uid=sssdadmin_infra,ou=ServiceUsers,ou=cee,o=nsn ldap_default_authtok_type = password ldap_default_authtok = IPgqe9ihhWUXWUeVo2bp3caiZ4HUzP4VdZI6KvKo ldap_user_object_class = posixAccount ldap_user_name = uid ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_gecos = description ldap_user_home_directory = homeDirectory ldap_user_shell = loginShell ldap_ns_account_lock = nsAccountLock ldap_user_ssh_public_key = sshPublicKey ldap_group_object_class = posixGroup ldap_group_name = cn ldap_group_gid_number = gidNumber ldap_group_member = member ldap_pwd_policy = none ldap_account_expire_policy = 389ds ldap_access_order = filter, expireldap_access_filter = (|(memberOf=cn=group1,ou=groups,ou=cee,o=nsn)(memberOf=cn=LDAPAdministrator1,ou=Groups,ou=cee,o=nsn)) sudo_provider = ldap ldap_sudo_search_base = cn=%LDAPAdministrator1,ou=Groups,ou=cee,o=nsn when I try to run sudo su command it’s prompting for password and in the logs I can see (2024-01-19 15:32:59): [sudo] [cache_req_done] (0x0400): CR #13: Finished: Success (2024-01-19 15:32:59): [sudo] [sysdb_get_sudo_user_info] (0x0400): Original name: bindu2@cee (2024-01-19 15:32:59): [sudo] [sysdb_get_sudo_user_info] (0x0400): Cased name: bindu2@cee (2024-01-19 15:32:59): [sudo] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(dataExpireTimestamp<=1705674779)(|(name=defaults)(sudoUser=ALL)(sudoUser=bindu2@cee)(sudoUser=#1602)(sudoUser=%LDAPAdministrator1@cee)(sudoUser=%LDAP\20Users@cee)(sudoUser=+ *)))](2024-01-19 15:32:59): [sudo] [sudosrv_refresh_rules_send] (0x0400): No expired rules were found for [bindu2@cee@cee].(2024-01-19 15:32:59): [sudo] [sudosrv_fetch_rules] (0x0400): Retrieving rules for [bindu2@cee@cee](2024-01-19 15:32:59): [sudo] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=bindu2@cee)(sudoUser=#1602)(sudoUser=%LDAPAdministrator1@cee)(sudoUser=%LDAP\20Users@cee)))](2024-01-19 15:32:59): [sudo] [sudosrv_cached_rules_by_user] (0x0400): Replacing sudoUser attribute with sudoUser: #1602(2024-01-19 15:32:59): [sudo] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(sudoUser=+*)(!(|(sudoUser=ALL)(sudoUser=bindu2@cee)(sudoUser=#1602)(sudoUser=%LDAPAdministrator1@cee)(sudoUser=%LDAP\20Users@cee))))] (2024-01-19 15:32:59): [sudo] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [bindu2@cee@cee] (2024-01-19 15:32:59): [sudo] [sudosrv_build_response] (0x2000): error: [0] (2024-01-19 15:32:59): [sudo] [sudosrv_build_response] (0x2000): rules_num: [0] Any help is highly appreciated. Thanks, Bindu

2 1

389 DS memory growth
by Nazarenko, Alexander 17 Nov '23

17 Nov '23

Hello colleagues, On March 22nd we updated the 389-ds-base.x86_64 and 389-ds-base-libs.x86_64 packages on our eight RHEL 7.9 production servers from version 1.3.10.2-17.el7_9 to version 1.3.11.1-1.el7_9. We also updated the kernel from kernel 3.10.0-1160.80.1.el7.x86_64 to kernel-3.10.0-1160.88.1.el7.x86_64 during the same update. Approximately 12 days later, on April 3rd, all the hosts started exhibiting memory growth issues whereby the “slapd” process was using over 90% of the available system memory of 32GB, which was NOT happening for a couple of years prior to applying any of the available package updates on the systems. Two of the eight hosts act as Primaries (formerly referred to as masters), while 6 of the hosts act as read-only replicas. Three of the read-only replicas are used by our authorization system while the other three read-only replicas are used by customer-based applications. Currently we use system controls to restrict the memory usage. My question is whether this is something that other users also experience, and what is the recommended way to stabilize the DS servers in this type of situation? Thanks, - Alex

3 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-devel