Upgrading from 1.3.5.10-21 to 1.3.6-1.24
by Sergei Gerasenko
Hello,
I’m getting ready to upgrade from 1.3.5 to 1.3.6 and I’m wondering if there are any possible issues with this. I’ve heard that the replication protocol has changed in regards to the replication protocol for example. Anything else to be concerned about in terms of the schema changes, etc?
Thanks for any insight.
Sergei
6 years, 2 months
Announcing 389 Directory Server 1.4.0.4
by Mark Reynolds
389 Directory Server 1.4.0.4
The 389 Directory Server team is proud to announce 389-ds-base
version 1.4.0.4
Fedora packages are available on Fedora 28(rawhide).
https://koji.fedoraproject.org/koji/taskinfo?taskID=23262737
<https://koji.fedoraproject.org/koji/taskinfo?taskID=23262737>
The new packages and versions are:
* 389-ds-base-1.4.0.4-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.0.4.tar.bz2>
Highlights in 1.4.0.4
* Version change
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* if you have 389-admin installed,
otherwise please run *setup-ds.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* if you have 389-admin installed, otherwise please
run *setup-ds.pl* to update your directory server/admin
server/console information.
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 1.4.0.4
* Ticket 49540 - Indexing task is reported finished too early
regarding the backend status
* Ticket 49534 - Fix coverity regression
* Ticket 49544 - cli release preperation, group improvements
* Ticket 49542 - Unpackaged files on el7 break rpm build
* Ticket 49541 - repl config should not allow rid 65535 for masters
* Ticket 49370 - Add all the password policy defaults to a new
local policy
* Ticket 49425 - improve demo objects for install
* Ticket 49537 - allow asan to build with stable rustc
* Ticket 49526 - Improve create_test.py script
* Ticket 49516 - Add python 3 support for replication suite
* Ticket 49534 - Fix coverity issues and regression
* Ticket 49532 - coverity issues - fix compiler warnings & clang issues
* Ticket 49531 - coverity issues - fix memory leaks
* Ticket 49463 - After cleanALLruv, there is a flow of keep alive DEL
* Ticket 49529 - Fix Coverity warnings: invalid deferences
* Ticket 49509 - Indexing of internationalized matching rules is failing
* Ticket 49527 - Improve ds* cli tool testing
* Ticket 49474 - purge saslmaps before gssapi test
* Ticket 49413 - Changelog trimming ignores disabled replica-agreement
* Ticket 49446 - cleanallruv should ignore cleaned replica Id in
processing changelog if in force mode
* Ticket 49278 - GetEffectiveRights gives false-negative
* Ticket 49508 - memory leak in cn=replica plugin setup
* Ticket 48118 - Add CI test case
* Ticket 49520 - Cockpit UI - Add database chaining HTML
* Ticket 49512 - Add ds-cockpit-setup to rpm spec file
* Ticket 49523 - Refactor CI test
* Ticket 49524 - Password policy: minimum token length fails when the
token length is equal to attribute length
* Ticket 49517 - Cockpit UI - Add correct png files
* Ticket 49517 - Cockput UI - revise config layout
* Ticket 49523 - memberof: schema violation error message is confusing
as memberof will likely repair target entry
* Ticket 49312 - Added a new test case for “-D configdir”
* Ticket 49512 - remove backup directories from cockpit source
* Ticket 49512 - Add initial Cockpit UI Plugin
* Ticket 49515 - cannot link, missing -fPIC
* Ticket 49474 - Improve GSSAPI testing capability
* Ticket 49493 - heap use after free in csn_as_string
* Ticket 49379 - Add Python 3 support to CI test
* Ticket 49431 - Add CI test case
* Ticket 49495 - cos stress test and improvements.
* Ticket 49495 - Fix memory management is vattr.
* Ticket 49494 - python 2 bytes mode.
* Ticket 49471 - heap-buffer-overflow in ss_unescape
* Ticket 48184 - close connections at shutdown cleanly.
* Ticket 49218 - Certmap - support TLS tests
* Ticket 49470 - overflow in pblock_get
* Ticket 49443 - Add CI test case
* Ticket 49484 - Minor cli tool fixes.
* Ticket 49486 - change ns stress core to use absolute int width.
* Ticket 49445 - Improve regression test to detect memory leak.
* Ticket 49445 - Memory leak in ldif2db
* Ticket 49485 - Typo in gccsec_defs
* Ticket 49479 - Remove unused ‘batch’ argument from lib389
* Ticket 49480 - Improvements to support IPA install.
* Ticket 49474 - sasl allow mechs does not operate correctly
* Ticket 49449 - Load sysctl values on rpm upgrade.
* Ticket 49374 - Add CI test case
* Ticket 49325 - fix rust linking.
* Ticket 49475 - docker poc improvements.
* Ticket 49461 - Improve db2index handling for test 49290
* Ticket 47536 - Add Python 3 support and move test case to suites
* Ticket 49444 - huaf in task.c during high load import
* Ticket 49460 - replica_write_ruv log a failure even when it succeeds
* Ticket 49298 - Ticket with test case and remove-ds.pl
* Ticket 49408 - Add a test case for nsds5ReplicaId checks
* Ticket 3 lib389 - python 3 support for subset of pwd cases
* Ticket 35 lib389 - dsconf automember support
6 years, 2 months
dirsrv hangs on starting
by pgb 205
we are running
FC26
ds-389 1.3.6.6-2
This is actually when starting freeipa with ipact -d start
I get
ipactl -d status
ipa: DEBUG: importing all plugin modules in ipaserver.plugins...
ipa: DEBUG: importing plugin module ipaserver.plugins.aci
ipa: DEBUG: importing plugin module ipaserver.plugins.automember
ipa: DEBUG: importing plugin module ipaserver.plugins.automount
ipa: DEBUG: importing plugin module ipaserver.plugins.baseldap
ipa: DEBUG: ipaserver.plugins.baseldap is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.baseuser
ipa: DEBUG: importing plugin module ipaserver.plugins.batch
ipa: DEBUG: importing plugin module ipaserver.plugins.ca
ipa: DEBUG: importing plugin module ipaserver.plugins.caacl
ipa: DEBUG: importing plugin module ipaserver.plugins.cert
ipa: DEBUG: importing plugin module ipaserver.plugins.certprofile
ipa: DEBUG: importing plugin module ipaserver.plugins.config
ipa: DEBUG: importing plugin module ipaserver.plugins.delegation
ipa: DEBUG: importing plugin module ipaserver.plugins.dns
ipa: DEBUG: importing plugin module ipaserver.plugins.dnsserver
ipa: DEBUG: importing plugin module ipaserver.plugins.dogtag
ipa: DEBUG: importing plugin module ipaserver.plugins.domainlevel
ipa: DEBUG: importing plugin module ipaserver.plugins.group
ipa: DEBUG: importing plugin module ipaserver.plugins.hbac
ipa: DEBUG: ipaserver.plugins.hbac is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.hbacrule
ipa: DEBUG: importing plugin module ipaserver.plugins.hbacsvc
ipa: DEBUG: importing plugin module ipaserver.plugins.hbacsvcgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.hbactest
ipa: DEBUG: importing plugin module ipaserver.plugins.host
ipa: DEBUG: importing plugin module ipaserver.plugins.hostgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.idrange
ipa: DEBUG: importing plugin module ipaserver.plugins.idviews
ipa: DEBUG: importing plugin module ipaserver.plugins.local
ipa: DEBUG: importing plugin module ipaserver.plugins.join
ipa: DEBUG: importing plugin module ipaserver.plugins.krbtpolicy
ipa: DEBUG: importing plugin module ipaserver.plugins.ldap2
ipa: DEBUG: importing plugin module ipaserver.plugins.location
ipa: DEBUG: importing plugin module ipaserver.plugins.migration
ipa: DEBUG: importing plugin module ipaserver.plugins.misc
ipa: DEBUG: importing plugin module ipaserver.plugins.netgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.otp
ipa: DEBUG: ipaserver.plugins.otp is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.otpconfig
ipa: DEBUG: importing plugin module ipaserver.plugins.otptoken
ipa: DEBUG: importing plugin module ipaserver.plugins.passwd
ipa: DEBUG: importing plugin module ipaserver.plugins.permission
ipa: DEBUG: importing plugin module ipaserver.plugins.ping
ipa: DEBUG: importing plugin module ipaserver.plugins.pkinit
ipa: DEBUG: importing plugin module ipaserver.plugins.privilege
ipa: DEBUG: importing plugin module ipaserver.plugins.pwpolicy
ipa: DEBUG: Starting external process
ipa: DEBUG: args=klist -V
ipa: DEBUG: Process finished, return code=0
ipa: DEBUG: stdout=Kerberos 5 version 1.15.1
ipa: DEBUG: stderr=
ipa: DEBUG: importing plugin module ipaserver.plugins.rabase
ipa: DEBUG: ipaserver.plugins.rabase is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.radiusproxy
ipa: DEBUG: importing plugin module ipaserver.plugins.realmdomains
ipa: DEBUG: importing plugin module ipaserver.plugins.role
ipa: DEBUG: importing plugin module ipaserver.plugins.schema
ipa: DEBUG: importing plugin module ipaserver.plugins.selfservice
ipa: DEBUG: importing plugin module ipaserver.plugins.selinuxusermap
ipa: DEBUG: importing plugin module ipaserver.plugins.server
ipa: DEBUG: importing plugin module ipaserver.plugins.serverrole
ipa: DEBUG: importing plugin module ipaserver.plugins.serverroles
ipa: DEBUG: importing plugin module ipaserver.plugins.service
ipa: DEBUG: importing plugin module ipaserver.plugins.servicedelegation
ipa: DEBUG: importing plugin module ipaserver.plugins.session
ipa: DEBUG: importing plugin module ipaserver.plugins.stageuser
ipa: DEBUG: importing plugin module ipaserver.plugins.sudo
ipa: DEBUG: ipaserver.plugins.sudo is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.sudocmd
ipa: DEBUG: importing plugin module ipaserver.plugins.sudocmdgroup
ipa: DEBUG: importing plugin module ipaserver.plugins.sudorule
ipa: DEBUG: importing plugin module ipaserver.plugins.topology
ipa: DEBUG: importing plugin module ipaserver.plugins.trust
ipa: DEBUG: importing plugin module ipaserver.plugins.user
ipa: DEBUG: importing plugin module ipaserver.plugins.vault
ipa: DEBUG: importing plugin module ipaserver.plugins.virtual
ipa: DEBUG: ipaserver.plugins.virtual is not a valid plugin module
ipa: DEBUG: importing plugin module ipaserver.plugins.xmlserver
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/bin/systemctl is-active dirsrv(a)domain-local.service
ipa: DEBUG: Process finished, return code=3
ipa: DEBUG: stdout=activating
ipa: DEBUG: stderr=
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/bin/systemctl is-active dirsrv(a)domain-local.service
ipa: DEBUG: Process finished, return code=3
ipa: DEBUG: stdout=activating
ipa: DEBUG: stderr=
ipa: DEBUG: Starting external process
ipa: DEBUG: args=/bin/systemctl is-active dirsrv(a)domain-local.service
ipa: DEBUG: Process finished, return code=3
ipa: DEBUG: stdout=activating
...
the last block keep repeating forever.
My question is how do I increase debugging level to give me proper information.
There are several troubleshooting levels here
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html
but which one would be most appropriate in this situation?
Or something else I can/should take a look at?
thank you
6 years, 2 months
PR_Write error
by tdarby＠email.arizona.edu
OS: Fedora 26
389 Server 1.3.7.6
I'm getting one or two of these a day on two servers that are MM replicas of each other:
ERR - write_function - PR_Write(371) Netscape Portable Runtime error -12135 (unknown error)
What is this? A write error certainly doesn't sound good.
6 years, 2 months
Configuring password syncing 389 -> AD
by Daniel Franciscus
Hi,
We currently are syncing passwords from Active Directory to 389 via the Passsync service installed on our domain controllers. We would like to reverse this, and set up syncing passwords (and only passwords no other attributes) from 389 to AD (while keeping password syncing from AD to 389 in place). The documentation provided seems convoluted. Can anyone tell me if this can be done, and how I would go about it? In addition, I do not want to use ADCA in our AD domain, I would rather use a 3rd party cert.
Thanks,
Dan Franciscus
Systems Administrator
Information Technology Group
Institute for Advanced Study
609-734-8138
6 years, 3 months
Re: [SOLVED] Account lockout for failed logins not working as expected
by Mitch Patenaude
So the problems were
1) I needed to set 'passwordUnlock: on' even though that's supposed to be the default value
2) In 'cn=config' I needed to set 'passwordIsGlobalPolicy: on' on every server to enable replication of lockout params.
Thanks to Kevin Kelly for pointing me in the right direction. The relevant documentation can be found here:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8....
-- Mitch
On 1/16/18, 1:44 PM, "Mitch Patenaude" <mpatenaude(a)shutterfly.com> wrote:
I'm trying to implement account lockouts for <n> failed login attempts in a multi-master environment.
I used something like the following ldif to enable to lockouts:
dn: cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com",cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
changetype: modify
add: passwordLockout
passwordLockout: on
-
add: passwordMaxFailure
passwordMaxFailure: 5
-
add: passwordResetFailureCount
passwordResetFailureCount: 1800
-
add: passwordLockoutDuration
passwordLockoutDuration: 1800
It works (kind of), but there are 2 problems:
1) Even though the passwordLockoutDuration is only 30 minutes, it locks the user out indefinitely (i.e. accountUnlockTime: 19700101000000Z)
2) The accountUnlockTime attribute doesn't get replicated, so the user is only locked out of 1 of the 4 master servers.
Any idea what I am doing wrong?
Thanks,
-- Mitch Patenaude mpatenaude(a)shutterfly.com Systems engineer
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
6 years, 3 months
Account lockout for failed logins not working as expected
by Mitch Patenaude
I'm trying to implement account lockouts for <n> failed login attempts in a multi-master environment.
I used something like the following ldif to enable to lockouts:
dn: cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com",cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
changetype: modify
add: passwordLockout
passwordLockout: on
-
add: passwordMaxFailure
passwordMaxFailure: 5
-
add: passwordResetFailureCount
passwordResetFailureCount: 1800
-
add: passwordLockoutDuration
passwordLockoutDuration: 1800
It works (kind of), but there are 2 problems:
1) Even though the passwordLockoutDuration is only 30 minutes, it locks the user out indefinitely (i.e. accountUnlockTime: 19700101000000Z)
2) The accountUnlockTime attribute doesn't get replicated, so the user is only locked out of 1 of the 4 master servers.
Any idea what I am doing wrong?
Thanks,
-- Mitch Patenaude mpatenaude(a)shutterfly.com Systems engineer
6 years, 3 months
How to use lib389 to create an instance?
by Rich Megginson
I keep getting this error:
Traceback (most recent call last):
File "/home/rmeggins/scripts/repltest.py", line 53, in <module>
m1 = tools.DirSrvTools.createInstance(createargs)
File "/home/rmeggins/ds/ds.git/src/lib389/lib389/tools.py", line 627,
in createInstance
cfgdn = lib389.CFGSUFFIX
NameError: global name 'lib389' is not defined
this fixes it (but causes other problems):
--- a/src/lib389/lib389/tools.py
+++ b/src/lib389/lib389/tools.py
@@ -31,6 +31,7 @@ import getpass
# from .nss_ssl import nss_create_new_database
from threading import Timer
+import lib389
from lib389.paths import Paths
6 years, 3 months
[important] Removing i686 support
by William Brown
Hi,
We have begun the process to remove i686 support from the server. You
should plan that all 1.4.x builds will support 64bit platforms only.
https://pagure.io/389-ds-base/issue/49514
We recommend that you move to a 64bit platform (x86_64, aarch64,
ppc64le) which we support.
Thanks,
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
6 years, 3 months
Re: monitoring
by Sergei Gerasenko
> What is an "error" in your data?
The “error” graph graphs the “errors” attribute from cn=snmp,cn=monitor. I don’t know what conditions actually increment that value.
6 years, 3 months
