compiling 389-ds 3.6(or newer) on ubuntu 16.04
by Alberto Viana
As far as I can see (with a little research on some tickets) lib nunc-stans
is now enabled by default in 389 (389-ds-base) and I'm trying to compiling
it on ubuntu 16.04 and was getting the following error:
/.libs/libnunc-stans.so: undefined reference to `event_add'
./.libs/libnunc-stans.so: undefined reference to `event_base_loop'
./.libs/libnunc-stans.so: undefined reference to `event_set_log_callback'
./.libs/libnunc-stans.so: undefined reference to `event_base_free'
./.libs/libnunc-stans.so: undefined reference to `event_assign'
./.libs/libnunc-stans.so: undefined reference to `event_set_mem_functions'
./.libs/libnunc-stans.so: undefined reference to `event_base_new'
./.libs/libnunc-stans.so: undefined reference to `event_del'
collect2: error: ld returned 1 exit status
Nunc-stans depends on libevent-dev (at least on ubuntu):
gcc -g -O2 -o .libs/ns-slapd ldap/servers/slapd/ns_slapd-abandon.o
ldap/servers/slapd/ns_slapd-auth.o ldap/servers/slapd/ns_slapd-bind.o
ldap/servers/slapd/ns_slapd-compare.o ldap/servers/slapd/ns_slapd-config.o
ldap/servers/slapd/ns_slapd-configdse.o
ldap/servers/slapd/ns_slapd-connection.o
ldap/servers/slapd/ns_slapd-conntable.o ldap/servers/slapd/ns_slapd-daemon.o
ldap/servers/slapd/ns_slapd-detach.o ldap/servers/slapd/ns_slapd-extendop.o
ldap/servers/slapd/ns_slapd-fedse.o ldap/servers/slapd/ns_slapd-fileio.o
ldap/servers/slapd/ns_slapd-getopt_ext.o ldap/servers/slapd/ns_slapd-globals.o
ldap/servers/slapd/ns_slapd-house.o ldap/servers/slapd/ns_slapd-init.o
ldap/servers/slapd/ns_slapd-main.o ldap/servers/slapd/ns_slapd-monitor.o
ldap/servers/slapd/ns_slapd-passwd_extop.o
ldap/servers/slapd/ns_slapd-psearch.o
ldap/servers/slapd/ns_slapd-pw_mgmt.o ldap/servers/slapd/ns_slapd-pw_verify.o
ldap/servers/slapd/ns_slapd-rootdse.o ldap/servers/slapd/ns_slapd-sasl_io.o
ldap/servers/slapd/ns_slapd-saslbind.o ldap/servers/slapd/ns_slapd-search.o
ldap/servers/slapd/ns_slapd-start_tls_extop.o
ldap/servers/slapd/ns_slapd-strdup.o
ldap/servers/slapd/ns_slapd-stubs.o ldap/servers/slapd/ns_slapd-tempnam.o
ldap/servers/slapd/ns_slapd-unbind.o
ldap/servers/slapd/ns_slapd-getsocketpeer.o
./.libs/libnunc-stans.so ./.libs/libslapd.so ./.libs/libldaputil.so
-lldap_r -llber -lssl3 -lnss3 -ldl -lplc4 -lplds4 -lnspr4 -lsasl2
-L/usr/lib/x86_64-linux-gnu/ -lsvrcore -lpthread -Wl,-rpath
-Wl,/opt/dirsrv/lib/dirsrv
Seems to be missing the libevent(-levent), my workaround was to add it
manually:
LIBS=-levent ./configure
I'm not sure if is an expected behavior, but anyway I just want to share my
workaround.
Cheers,
Alberto Viana
6 years, 9 months
PAM PASS Through Plugin
by Harald Pape
Hello, a few days ago i have installed a DS and configured a Pam pass through plugin to authenticate against a backend ldap system, following the instructions. my Problem is that it Looks like the plugin will not activateted for authentication. Can some one help me?
With kind regards
Harald
6 years, 9 months
PAM PASS Through Plugin
by harald.pape＠aomation.de
Hello,
a few days ago i have installed a DS and configured a Pam pass through plugin to authenticate against a backend ldap system, following the instructions. my Problem is that it Looks like the plugin will not activateted for authentication.
Can some one help me?
With kund regards
Harald
6 years, 9 months
Announcing 389 Directory Server version 1.3.5.18
by Mark Reynolds
389 Directory Server 1.3.5.18
The 389 Directory Server team is proud to announce 389-ds-base
version 1.3.5.18.
Fedora packages are available from the Fedora 24, and 25.
The new packages and versions are:
* 389-ds-base-1.3.5.18-1
Source tarballs are available for download at Download 389-ds-base
Source <http://www.port389.org/binaries/389-ds-base-1.3.5.18.tar.bz2>
and Download nunc-stans Source
<http://www.port389.org/binaries/nunc-stans-0.1.8.tar.bz2>.
Highlights in 1.3.5.18
* Bug fixes
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 an Admin Server installed
(389-admin), otherwise just 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 an Admin Server installed
(389-admin), otherwise just run *setup-ds.pl -u* 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...
as well as:
F24 https://bodhi.fedoraproject.org/updates/FEDORA-2017-f0ace457f7
<https://bodhi.fedoraproject.org/updates/FEDORA-2017-f0ace457f7> F25
https://bodhi.fedoraproject.org/updates/FEDORA-2017-a4824a5fb4
<https://bodhi.fedoraproject.org/updates/FEDORA-2017-a4824a5fb4>
If you find a bug, or would like to see a new feature, file it in our
Trac instance: https://pagure.io/389-ds-base/new_issue
* Bump version to 1.3.5.18
* Ticket 49273 - Fix logging from previous patch
* Ticket 49273 - bak2db doesn’t operate with dbversion
* Ticket 49273 - crash when DBVERSION is corrupt.
* Ticket 49241 - add symblic link location to db2bak.pl output
* Ticket 49157 - fix error in ds-logpipe.py
* Ticket 49246 - ns-slapd crashes in role cache creation
* Ticket 48989 - Re-implement lock counter
* Ticket 48989 - missing return in counter
* Ticket 48989 - Improve counter overflow fix
* Ticket 49157 - ds-logpipe.py crashes for non-existing users
* Ticket 49241 - Update man page and usage for db2bak.pl
* Ticket 49209 - Hang due to omitted replica lock release
6 years, 9 months
Question about password policy implementation
by Darren Struthers
I have inherited an instance of 389 Directory Server running version
1.2.10.2. I have observed some inconsistency in the server's behavior when
I apply a user-level password policy to an account which has not previously
had one (either directly via a user-level policy or indirectly via a
subtree-level policy). I have applied a basic policy with a 7-day password
expiration and 7-day warning period on several accounts. When I did this,
some accounts seemed to start the 7-day clock upon a subsequent login,
while others seemed to have no observable effect (i.e. the account state
warning for a near expiration is not returned after authentication).
Does anyone know what factors could result in this inconsistency in this
version? The behavior seems to diverge along account age lines, with older
accounts seeming to behave differently than the newer accounts, leading me
to wonder if someone previously applied and removed password policies at
either the user- or subtree-level in the past, and if so, whether that
could potentially lead to the inconsistency I'm observing.
A secondary question: does anyone know if it is possible to see the state
of the expiration timer for accounts in this version?
Any information or advice anyone has is appreciated. I can provide more
information about the server in question if necessary.
Thanks,
Darren
--
Darren M. Struthers
Systems Developer
Information & Technology Services
Pacific Lutheran University
Tacoma, WA 98447
Phone: 253.535.7470
6 years, 9 months
One way sync from AD to 389-ds
by Andrew Radygin
Hi guys!
I need to do subj operation, without ssl and syncpass, and seems that I do
everything according
https://access.redhat.com/documentation/en-us/red_hat_directory_server/9....
but no luck yet :(
Maybe someone have such experience? It this possible ever?
error.log from DS with debug mode turned on:
=========
[07/Jul/2017:14:45:46.205742598 +0300] NSMMReplicationPlugin - windows sync
- Running Dirsync
[07/Jul/2017:14:45:46.307205965 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): State: wait_for_changes ->
wait_for_changes
[07/Jul/2017:14:45:46.332118308 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): State: wait_for_changes ->
ready_to_acquire_replica
[07/Jul/2017:14:45:46.357281411 +0300] acquire_replica, supplier RUV:
[07/Jul/2017:14:45:46.382317390 +0300] NSMMReplicationPlugin - supplier:
{replicageneration} 595a5d92000000010000
[07/Jul/2017:14:45:46.407471865 +0300] acquire_replica, consumer RUV:
[07/Jul/2017:14:45:46.524295603 +0300] NSMMReplicationPlugin - consumer:
{replicageneration} 595a5d92000000010000
[07/Jul/2017:14:45:46.551039635 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): Trying non-secure slapi_ldap_init_ext
[07/Jul/2017:14:45:46.568052882 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): binddn =
cn=robot-cauth,ou=techusers,dc=**,dc=****,dc=***, passwd = *********
[07/Jul/2017:14:45:46.591223907 +0300] windows_conn_connect : detected
Win2k3 or later peer
[07/Jul/2017:14:45:46.609678106 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): No linger to cancel on the connection
[07/Jul/2017:14:45:46.626666798 +0300] _csngen_adjust_local_time: gen state
before 595f733f0002:1499427647:0:0
[07/Jul/2017:14:45:46.643179966 +0300] _csngen_adjust_local_time: gen state
after 595f746a0000:1499427946:0:0
[07/Jul/2017:14:45:46.659915068 +0300] NSMMReplicationPlugin - windows sync
- windows_acquire_replica returned success (101)
[07/Jul/2017:14:45:46.676553114 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): State: ready_to_acquire_replica ->
sending_updates
[07/Jul/2017:14:45:46.790456360 +0300] NSMMReplicationPlugin - changelog
program - _cl5GetDBFile: no DB object found for database
/var/lib/dirsrv/slapd-ds/changelogdb/229c6c82-600111e7-8cfc9a96-210bea69_595a5d92000000010000.db
[07/Jul/2017:14:45:46.976986924 +0300] NSMMReplicationPlugin - changelog
program - cl5CreateReplayIteratorEx: could not find DB object for replica
[07/Jul/2017:14:45:47.002210180 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): No changes to send
[07/Jul/2017:14:45:47.019263819 +0300] Calling dirsync search request plugin
[07/Jul/2017:14:45:47.088348158 +0300] Sending dirsync search request
[07/Jul/2017:14:45:47.163592499 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): Beginning linger on the connection
[07/Jul/2017:14:45:47.227723975 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): State: sending_updates ->
wait_for_changes
[07/Jul/2017:14:46:47.229642395 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): Linger timeout has expired on the
connection
[07/Jul/2017:14:46:47.315570281 +0300] NSMMReplicationPlugin - windows sync
- agmt="cn=From-ad" (ad01-sklk:389): Disconnected from the consumer
=========
And here is Replica Agreement:
===========
dn: cn=From-ad,cn=replica,cn=dc\3D**\2Cdc\3D****\2Cdc\3Dnet,cn=mapping tre
e,cn=config
objectClass: top
objectClass: nsDSWindowsReplicationAgreement
description: uni-direct sync from AD
cn: From-ad
nsds7WindowsReplicaSubtree: cn=users,dc=**,dc=*****,dc=**
nsds7DirectoryReplicaSubtree: cn=users,dc=**,dc=****,dc=**
nsds7NewWinUserSyncEnabled: on
nsds7NewWinGroupSyncEnabled: on
nsds7WindowsDomain: **.*****.**
nsDS5ReplicaRoot: dc=**,dc=****,dc=***
nsDS5ReplicaHost: ad01-sklk....
nsDS5ReplicaPort: 389
nsDS5ReplicaBindDN: cn=robot-cauth,ou=techusers,dc=**,dc=****,dc=***
nsDS5ReplicaBindMethod: SIMPLE
nsDS5ReplicaCredentials: ******************
creatorsName:
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config
createTimestamp: 20170703152542Z
modifyTimestamp: 20170707115048Z
oneWaySync: fromWindows
nsds50ruv: {replicageneration} 595a5d92000000010000
================
It seems like DS trying to push changes to AD (why?! I've added onewaysync
'fromwindows' attr to agreement), but even no try to pull AD tree from it...
I really need advice in it, there is no sense from google.
--
Best regards, Andrew.
6 years, 9 months
oneway sync from AD to 389-ds
by randrewg＠gmail.com
Hi guys!
I need to do subj operation, without ssl and syncpass, and seems that I do everything according https://access.redhat.com/documentation/en-us/red_hat_directory_server/9...., but no luck yet :(
Maybe someone have such experience? It this possible ever?
I could attach error.log from DS with debug mode turned on.
It seems like DS trying to push changes to AD (why?! I've added onewaysync 'fromwindows' attr to agreement), but even no try to pull AD tree from it...
I really need advice in it, from google there is no sense.
6 years, 9 months
Re: IIAP - Ldap authentication
by Narendra Laga
Hi,
can any one help on below issue.
we are integrating 389-DS with cyberoam, while doing test connection we are facing below error.
Please check the below Ldap authentication errors and check for the solution.
@ green color is anonymous, yellow color is error of admin integration
[05/Jul/2017:05:36:47.061794640 -0400] conn=18 fd=76 slot=76 connection from 192.168.1.xx to 192.168.1.xx
[05/Jul/2017:05:36:47.061901295 -0400] conn=18 op=0 BIND dn="" method=128 version=3
[05/Jul/2017:05:36:47.061967021 -0400] conn=18 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[05/Jul/2017:05:36:47.062430621 -0400] conn=18 op=1 UNBIND
[05/Jul/2017:05:36:47.062449012 -0400] conn=18 op=1 fd=76 closed - U1
[05/Jul/2017:05:38:01.813877357 -0400] conn=19 fd=76 slot=76 connection from 192.168.1.xx to 192.168.1.xx
[05/Jul/2017:05:38:01.814000145 -0400] conn=19 op=0 BIND dn="Directory Manager,dc=text,dc=in" authzid="(null)", invalid bind dn
[05/Jul/2017:05:38:01.814048128 -0400] conn=19 op=0 RESULT err=34 tag=97 nentries=0 etime=0
[05/Jul/2017:05:38:01.814627178 -0400] conn=19 op=1 UNBIND
[05/Jul/2017:05:38:01.814642192 -0400] conn=19 op=1 fd=76 closed - U1
[05/Jul/2017:05:38:59.609119006 -0400] conn=20 fd=76 slot=76 connection from 192.168.1.254 to 192.168.1.159
[05/Jul/2017:05:38:59.609238893 -0400] conn=20 op=0 BIND dn="Directory Manager,dc=text,dc=in" authzid="(null)", invalid bind dn
Thanks & Regards,
Narendra.Laga
Engineer, NOC Operations
Locuz Enterprise Solutions Ltd | Tel : +91- 4045004678
http://www.locuz.com<http://www.locuz.com/in/>
6 years, 9 months
