Announcing 389 Directory Server 1.4.4.2
by Mark Reynolds
389 Directory Server 1.4.4.2
The 389 Directory Server team is proud to announce 389-ds-base version
1.4.4.2
Fedora packages are available on Rawhide (Fedora 33).
https://koji.fedoraproject.org/koji/taskinfo?taskID=44234677
<https://koji.fedoraproject.org/koji/taskinfo?taskID=44234677>
The new packages and versions are:
* 389-ds-base-1.4.4.2-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.4.2.tar.bz2>
Highlights in 1.4.4.2
* 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 the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
steps required.
There are no upgrade steps besides installing the new rpms
See Install_Guide
<http://www.port389.org/docs/389ds/howto/howto-install-389.html> for
more information about the initial installation and setup
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.4.2
* Issue 51078 - Add nsslapd-enable-upgrade-hash to the schema
* Issue 51054 - Revise ACI target syntax checking
* Issue 51068 - deadlock when updating the schema
* Issue 51042 - try to use both c_rehash and openssl rehash
* Issue 51042 - switch from c_rehash to openssl rehash
* Issue 50992 - Bump jemalloc version and enable profiling
* Issue 51060 - unable to set sslVersionMin to TLS1.0
* Issue 51064 - Unable to install server where IPv6 is disabled
* Issue 51051 - CLI fix consistency issues with confirmations
* Issue 50655 - etime displayed has an order of magnitude 10 times
smaller than it should be
* Issue 49731 - undo db_home_dir under /dev/shm/dirsrv for now
* Issue 51054 - AddressSanitizer: heap-buffer-overflow in ldap_utf8prev
* Issue 49761 - Fix CI tests
* Issue 51047 - React deprecating ComponentWillMount
* Issue 50499 - fix npm audit issues
* Issue 50545 - Port dbgen.pl to dsctl
* Issue 51027 - Test passwordHistory is not rewritten on a fail attempt
--
389 Directory Server Development Team
4 years
Replication error: network error 0
by Graham Leggett
Hi all,
I have two servers, an older CentOS7 server running 389-ds-base-1.3.10.1-5.el7, and a newer CentOS8 server running 389-ds-base-1.4.1.3-7.module_el8.1.0+234+96aec258, and I want to set up multi-master-replication between them.
The replication agreement for CentOS7-> CentOS8 works great, replication is working fine.
The replication agreement for CentOS8 -> CentOS7 doesn’t work, giving the following strange error:
[07/May/2020:18:42:59.201795217 +0200] - ERR - slapi_ldap_bind - Could not send bind request for id [cn=Replication Manager,cn=config] authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 (Invalid function argument.), network error 0 (Unknown error, host “x.x.x:636”)
At the core of the above message is "network error 0”, otherwise known as “success”.
Does this ring a bell with anyone?
Regards,
Graham
—
4 years
pwadmin not working
by Alberto Viana
Hi Guys,
389 1.4.2.8
pwadmin is not working as expected:
dsconf RNP pwpolicy set --pwdadmin
cn=GRP_SRV_PREHASHED_PASSWORD,dc=my,dc=domain
In an specific OU, this user has the following permissions:
dn: OU=POP-PA,dc=my,dc=domain
aci: (targetattr="brPersonCPF || schacDateOfBirth || ntUserCreateNewAccount
||
ntUserDeleteAccount || mail || objectClass || ntUserDomainId || cn ||
given
Name || sn || uid || ntUserDeleteAccount") (version 3.0;acl "All
attributes
pop-pa Permissions";allow (add,write,read,search,compare,delete)
userdn="ldap
:///uid=app.pop-pa.w,dc=my,dc=domain";)
aci: (targetattr="userPassword") (version 3.0;acl "userPassword attributes
pop
-pa Permissions";allow (add,read,compare)
userdn="ldap:///uid=app.pop-pa.w,dc=my,dc=domain";)
But I'm still getting the error:
ldapmodify -a -c -h localhost -D "uid=app.pop-pa.w,dc=my,dc=domain" -W -f
anderson.ldif
adding new entry "uid=anderson.souza,dc=my,dc=domain"
ldap_add: Constraint violation (19)
additional info: invalid password syntax - passwords with storage scheme
are not allowed
The user app.pop-pa.w is in GRP_SRV_PREHASHED_PASSWORD group.
Everything was working fine in my previous version of 389 with same config
(1.3.7.4)
Thanks
4 years
Re: anonymous queries on second suffix subtrees
by Mark Reynolds
On 4/30/20 9:53 AM, Mc Laughlin David Bruce (ID BD) wrote:
>
> Hi, Mark.
>
>
> I did not expect a reply so soon!
>
>
> When I query as "Directory Manager", I get the expected result.
>
>
> I used the setup-ds.pl script to create the o=ethz,c=ch root suffx.
>
You should be using dscreate to create your instance, not setup-ds.pl
>
> I used "dsconf backend create" to add the second suffix (o=psi,c=ch).
>
Did you add any entries to o=psi,c=ch ?
>
> The subtrees are not properly connected to their respective root suffixes.
>
> Could this problem be caused by missing entries in the two "root
> suffix" databases?
>
>
> [root@el-dap ~]#
> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL -x
> -b 'o=psi,c=ch' '(ou=*)'
> No such object (32)
So you did not initialize this suffix. It is empty.
When creating the backend you could have created the top database node
entry by adding the "--create-suffix" option:
# dsconf slapd-YOUR_INSTANCE backend create --suffix o=psi,c=ch
--create-suffix
Note - dscreate or dsconf do not add any aci's by default. You have to
add the aci's after initializing the database with some data.
> [root@el-dap ~]#
>
>
> Anonymous queries on the two subtrees (ou=staff & ou=student) on root
> suffix (o=ethz,c=ch)
>
> return the expected result.
>
So searches on "ou=staff,o=ethz,c=ch" work? But just searching on
"o=ethz,c=ch" does not? I'm getting confused because you keep changing
which suffixes work or don't work. First it was subtree's under
o=psi,c=ch that didn't return any results, now it's different subtrees
under o=ethz,c=ch
So if you are having issues with anything under "o=ethz,c=ch" then can
you please run this search, and also clarify which subtrees work and
don't work for anonymous searches under this suffix "o=ethz,c=ch":
# ldapsearch -D "cn=directory manager" -W -b "o=ethz,c=ch" aci=* aci
Thanks,
Mark
>
> However, anonymous queries on the o=ethz,c=ch root suffix also return
> no records.
>
>
> with best regards,
>
> David
>
>
> e-mail: david.mclaughlin(a)id.ethz.ch <mailto:david.mclaughlin@id.ethz.ch>
>
>
> ------------------------------------------------------------------------
> *From:* Mark Reynolds <mreynolds(a)redhat.com>
> *Sent:* 30 April 2020 3:10 PM
> *To:* General discussion list for the 389 Directory server project.;
> Mc Laughlin David Bruce (ID BD)
> *Subject:* Re: [389-users] anonymous queries on second suffix subtrees
>
>
> On 4/30/20 7:14 AM, Mc Laughlin David Bruce (ID BD) wrote:
>> Hello, 389ers.
>>
>> I am migrating a whitepages server from OpenLDAP to 389-DS.
>>
>> My instance has a root suffix with two subtrees (for staff and students).
>> Anonymous queries of the two root suffix subtrees return the expected
>> results.
>>
>> The instance also has a second suffix of "o=psi,c=ch" with three
>> subtrees:
>> ou=contacts,o=psi,c=ch
>> ou=groups,o=psi,c=ch
>> ou=users,o=psi,c=ch
>>
>> Anonymous queries of the three "o=psi,c=ch" subtrees return NO records.
>>
>> I have added ACIs for the three "o=psi,c=ch" subtrees and restarted
>> the instance, but
>> anonymous queries of any of the three "o=psi,c=ch" subtrees STILL
>> return no records.
>>
>> Does anyone know how to allow anonymous queries?
>
> First you don't need to restart the server when you add or change
> ACI's. If you run the search as "cn=directory manager" does it return
> the results you expect?
>
> Can you share all the ACI's you added to o=psi,c=ch subtrees? Maybe
> gather all of them by using this search:
>
> # ldapsearch -D "cn=directory manager" -W -b "o=psi,c=ch" aci=* aci
>
> Thanks,
> Mark
>
>
>>
>> Thanks,
>> David
>>
>> [root@el-dap ~]#
>> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -D
>> "cn=Directory Manager" -W -x -b "ou=users,o=psi,c=ch" -s sub
>> '(aci=*)' aci
>> Enter LDAP Password:
>> # extended LDIF
>> #
>> # LDAPv3
>> # base <ou=users,o=psi,c=ch> with scope subtree
>> # filter: (aci=*)
>> # requesting: aci
>> #
>> # users, psi, ch
>> dn: ou=users,o=psi,c=ch
>> aci: (target = "ldap:///ou=users,o=psi,c=ch")(version 3.0; acl
>> "Anonymous read
>> , search for users";allow (read, search) userdn = "ldap:///anyone";)
>> # search result
>> search: 2
>> result: 0 Success
>> # numResponses: 2
>> # numEntries: 1
>> [root@el-dap ~]#
>>
>>
>> [root@el-dap ~]#
>> [root@el-dap ~]# /usr/bin/ldapsearch -H ldap://el-dap.ethz.ch/ -LLL
>> -x -b 'ou=users,o=psi,c=ch' '(cn=*kohler*)'
>> [root@el-dap ~]#
>>
>>
>> [root@el-dap ~]#
>> [root@el-dap ~]# tail /var/log/dirsrv/slapd-el-dap/access
>> [30/Apr/2020:10:23:02.362530519 +0200] conn=5 fd=64 slot=64
>> connection from 129.132.65.9 to 129.132.65.9
>> [30/Apr/2020:10:23:02.362748318 +0200] conn=5 op=0 BIND dn=""
>> method=128 version=3
>> [30/Apr/2020:10:23:02.362795436 +0200] conn=5 op=0 RESULT err=0
>> tag=97 nentries=0 etime=0.0000179605 dn=""
>> [30/Apr/2020:10:23:02.363025956 +0200] conn=5 op=1 SRCH
>> base="ou=users,o=psi,c=ch" scope=2 filter="(cn=*kohler*)" attrs=ALL
>> [30/Apr/2020:10:23:02.363471926 +0200] conn=5 op=1 RESULT err=0
>> tag=101 nentries=0 etime=0.0000606595
>> [30/Apr/2020:10:23:02.363649360 +0200] conn=5 op=2 UNBIND
>> [30/Apr/2020:10:23:02.363680129 +0200] conn=5 op=2 fd=64 closed - U1
>> [root@el-dap ~]#
>>
>> ___________________________________________________
>>
>> David McLaughlin
>>
>> ETH Zürich / Swiss Federal Institute of Technology
>>
>> Informatikdienste
>>
>> Basisdienste
>>
>> Mail, Archive & Directories group
>>
>> CH-8092 Zürich
>>
>> Tel.: +41 44 632 3531
>>
>> e-mail: david.mclaughlin(a)id.ethz.ch <mailto:david.mclaughlin@id.ethz.ch>
>>
>>
>> _______________________________________________
>> 389-users mailing list --389-users(a)lists.fedoraproject.org
>> To unsubscribe send an email to389-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.fe...
> --
>
> 389 Directory Server Development Team
--
389 Directory Server Development Team
4 years
DNA plugin not working
by CHAMBERLAIN James
Hi all,
I’m trying to use the DNA plugin to add uidNumbers on posixAccounts. Everything worked fine in testing, but now that it’s in production I’m seeing the following error:
ERR - dna-plugin -_dna_pre_op_add - Failed to allocate a new ID!! 2
I’ve followed the advice in the knowledge base (https://access.redhat.com/solutions/875133), about adding an equality index with an nsMatchingRule of integerOrderingMatch, but have not seen any difference in the server’s behavior. Any ideas what I should try next?
Thanks,
James
This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email and all attachments,
(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com>
For other languages, go to https://www.3ds.com/terms/email-disclaimer
4 years
Re: [EXTERNAL] Re: setup-ds-admin fails to install admin server
by William Brown
> On 2 May 2020, at 00:52, Crocker, Deborah <crock(a)ua.edu> wrote:
>
> Well, there we go. A typo in an /etc/hosts entry pointed to an instance that actually had o=netscaperoot. You may delete my posts as I sit here in shame....
No shame. The amount of time I have spent debugging and tracing things only to realise I was connected to the wrong ldap server or was missing a * or something ... it happens to the best of us, and I'm glad you solved it!
>
> Deborah Crocker, PhD
> Systems Engineer III
> Office of Information Technology
> The University of Alabama
> Box 870346
> Tuscaloosa, AL 36587
> Office 205-348-3758 | Fax 205-348-9393
> deborah.crocker(a)ua.edu
>
>
> -----Original Message-----
> From: Mark Reynolds <mreynolds(a)redhat.com>
> Sent: Friday, May 1, 2020 7:57 AM
> To: Crocker, Deborah <crock(a)ua.edu>; General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>
> Subject: [EXTERNAL] Re: [389-users] setup-ds-admin fails to install admin server
>
> Sorry no idea why this is happening based on the information you told me. I've never heard of this happening with a completely fresh install. Are you sure there is no pre-existing directory server you are installing on top of? If you look under /etc/dirsrv/ are there any "slapd-INSTANCE" directories?
>
> So remove the old instance using remove-ds-admin.pl. Then try running it with the debugger enabled:
>
> # setup-ds-admin.pl -ddddd
>
> If it still fails, then please provide the access log (/var/log/dirsrv/slapd-INSTANCE/access), and the debug output from setup-ds-admin.pl
>
> Mark
>
> On 5/1/20 8:44 AM, Crocker, Deborah wrote:
>> I'm using the option 2 install [typical] interactive and take the defaults. The only thing I end up typing in is passwords.
>>
>> Deborah Crocker, PhD
>> Systems Engineer III
>> Office of Information Technology
>> The University of Alabama
>> Box 870346
>> Tuscaloosa, AL 36587
>> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu
>>
>>
>> -----Original Message-----
>> From: Mark Reynolds <mreynolds(a)redhat.com>
>> Sent: Friday, May 1, 2020 7:17 AM
>> To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; Crocker, Deborah <crock(a)ua.edu>
>> Subject: [EXTERNAL] Re: [389-users] setup-ds-admin fails to install admin server
>>
>>
>> On 4/30/20 5:23 PM, Crocker, Deborah wrote:
>>> Why do I get this error on a setup-ds-admin.pl This was a fresh install.
>>> -----------------------
>>> The suffix 'o=NetscapeRoot' already exists. Config entry DN 'cn=o\3Dnetscaperoot,cn=mapping tree,cn=config'.
>> And what options are you using when you install? Are you using a silent install file or interactive mode?
>>
>> Are "you" setting o=netscaperoot during the install? If so, do not do that, as the server is already going to create this suffix.
>>
>> Mark
>>
>>> Failed to create the configuration directory server
>>> -----------------------
>>>
>>> The setup has
>>> Centos 7.8
>>> Epel install
>>> 389-ds-base: 1.3.10.1
>>> 389-admin: 1.1.46
>>>
>>> TIA
>>>
>>> Deborah Crocker, PhD
>>> Systems Engineer III
>>> Office of Information Technology
>>> The University of Alabama
>>> Box 870346
>>> Tuscaloosa, AL 36587
>>> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu
>>>
>>>
>>> -----Original Message-----
>>> From: Mark Reynolds <mreynolds(a)redhat.com>
>>> Sent: Thursday, April 30, 2020 2:06 PM
>>> To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; CHAMBERLAIN James <James.CHAMBERLAIN(a)3ds.com>
>>> Subject: [EXTERNAL] [389-users] Re: [389-announce] Notice of Legacy Tool removal for 389 Directory Server
>>>
>>>
>>> On 4/30/20 2:34 PM, CHAMBERLAIN James wrote:
>>>> Hi Mark,
>>>>
>>>>> On Apr 29, 2020, at 5:10 PM, Mark Reynolds <mreynolds(a)redhat.com> wrote:
>>>>>
>>>>> On 4/29/20 5:07 PM, Mark Reynolds wrote:
>>>>>> We've been talking about this for quite some time...
>>>>>>
>>>>>> A majority of all the old legacy perl and shell scripts have now been ported to the new CLI tools. Starting sometime in Fedora 33 we will stop shipping the legacy tools sub-package as part of 389 Directory Server.
>>>>> To be more specific the 389-ds-base-1.4.4 version is where the removal of the legacy tools subpackage will occur.
>>>> Does this includes tools like db2ldif.pl?
>>> Correct, all of those scripts will be removed. So all the shell and perl scripts (except for logconv.pl) will no longer be available starting at some point in 1.4.4. The new CLI tools (dscreate, dsctl, and dsconf) can do everything all those other scripts could do plus more.
>>>
>>> If you need help porting something to the new CLI I'd be glad to help.
>>>
>>> Mark
>>>
>>>> Anything that matches anything that matches "rpm -ql 389-ds-base | grep pl$ | grep sbin”, plus any shell scripts?
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>>> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
>>>>
>>>> If you are not one of the named recipients or have received this email
>>>> in error,
>>>>
>>>> (i) you should not read, disclose, or copy it,
>>>>
>>>> (ii) please notify sender of your receipt by reply email and delete
>>>> this email and all attachments,
>>>>
>>>> (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
>>>>
>>>>
>>>> Please be informed that your personal data are processed according to
>>>> our data privacy policy as described on our website. Should you have
>>>> any questions related to personal data protection, please contact 3DS
>>>> Data Protection Officer at
>>>> 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com>
>>>>
>>>>
>>>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
>>>> _______________________________________________
>>>> 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.fedorapr
>>>> oject.org
>
> --
>
> 389 Directory Server Development Team
>
> _______________________________________________
> 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...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
4 years
Re: [EXTERNAL] Re: setup-ds-admin fails to install admin server
by Mark Reynolds
On 5/1/20 10:52 AM, Crocker, Deborah wrote:
> Well, there we go. A typo in an /etc/hosts entry pointed to an instance that actually had o=netscaperoot. You may delete my posts as I sit here in shame....
Glad you figured it out, I would not have thought a typo in /etc/hosts
would impact the install. Good to know - this could be beneficial
information to other people who might run into the same issue.
Thanks,
Mark
>
> Deborah Crocker, PhD
> Systems Engineer III
> Office of Information Technology
> The University of Alabama
> Box 870346
> Tuscaloosa, AL 36587
> Office 205-348-3758 | Fax 205-348-9393
> deborah.crocker(a)ua.edu
>
>
> -----Original Message-----
> From: Mark Reynolds <mreynolds(a)redhat.com>
> Sent: Friday, May 1, 2020 7:57 AM
> To: Crocker, Deborah <crock(a)ua.edu>; General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>
> Subject: [EXTERNAL] Re: [389-users] setup-ds-admin fails to install admin server
>
> Sorry no idea why this is happening based on the information you told me. I've never heard of this happening with a completely fresh install. Are you sure there is no pre-existing directory server you are installing on top of? If you look under /etc/dirsrv/ are there any "slapd-INSTANCE" directories?
>
> So remove the old instance using remove-ds-admin.pl. Then try running it with the debugger enabled:
>
> # setup-ds-admin.pl -ddddd
>
> If it still fails, then please provide the access log (/var/log/dirsrv/slapd-INSTANCE/access), and the debug output from setup-ds-admin.pl
>
> Mark
>
> On 5/1/20 8:44 AM, Crocker, Deborah wrote:
>> I'm using the option 2 install [typical] interactive and take the defaults. The only thing I end up typing in is passwords.
>>
>> Deborah Crocker, PhD
>> Systems Engineer III
>> Office of Information Technology
>> The University of Alabama
>> Box 870346
>> Tuscaloosa, AL 36587
>> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu
>>
>>
>> -----Original Message-----
>> From: Mark Reynolds <mreynolds(a)redhat.com>
>> Sent: Friday, May 1, 2020 7:17 AM
>> To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; Crocker, Deborah <crock(a)ua.edu>
>> Subject: [EXTERNAL] Re: [389-users] setup-ds-admin fails to install admin server
>>
>>
>> On 4/30/20 5:23 PM, Crocker, Deborah wrote:
>>> Why do I get this error on a setup-ds-admin.pl This was a fresh install.
>>> -----------------------
>>> The suffix 'o=NetscapeRoot' already exists. Config entry DN 'cn=o\3Dnetscaperoot,cn=mapping tree,cn=config'.
>> And what options are you using when you install? Are you using a silent install file or interactive mode?
>>
>> Are "you" setting o=netscaperoot during the install? If so, do not do that, as the server is already going to create this suffix.
>>
>> Mark
>>
>>> Failed to create the configuration directory server
>>> -----------------------
>>>
>>> The setup has
>>> Centos 7.8
>>> Epel install
>>> 389-ds-base: 1.3.10.1
>>> 389-admin: 1.1.46
>>>
>>> TIA
>>>
>>> Deborah Crocker, PhD
>>> Systems Engineer III
>>> Office of Information Technology
>>> The University of Alabama
>>> Box 870346
>>> Tuscaloosa, AL 36587
>>> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu
>>>
>>>
>>> -----Original Message-----
>>> From: Mark Reynolds <mreynolds(a)redhat.com>
>>> Sent: Thursday, April 30, 2020 2:06 PM
>>> To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; CHAMBERLAIN James <James.CHAMBERLAIN(a)3ds.com>
>>> Subject: [EXTERNAL] [389-users] Re: [389-announce] Notice of Legacy Tool removal for 389 Directory Server
>>>
>>>
>>> On 4/30/20 2:34 PM, CHAMBERLAIN James wrote:
>>>> Hi Mark,
>>>>
>>>>> On Apr 29, 2020, at 5:10 PM, Mark Reynolds <mreynolds(a)redhat.com> wrote:
>>>>>
>>>>> On 4/29/20 5:07 PM, Mark Reynolds wrote:
>>>>>> We've been talking about this for quite some time...
>>>>>>
>>>>>> A majority of all the old legacy perl and shell scripts have now been ported to the new CLI tools. Starting sometime in Fedora 33 we will stop shipping the legacy tools sub-package as part of 389 Directory Server.
>>>>> To be more specific the 389-ds-base-1.4.4 version is where the removal of the legacy tools subpackage will occur.
>>>> Does this includes tools like db2ldif.pl?
>>> Correct, all of those scripts will be removed. So all the shell and perl scripts (except for logconv.pl) will no longer be available starting at some point in 1.4.4. The new CLI tools (dscreate, dsctl, and dsconf) can do everything all those other scripts could do plus more.
>>>
>>> If you need help porting something to the new CLI I'd be glad to help.
>>>
>>> Mark
>>>
>>>> Anything that matches anything that matches "rpm -ql 389-ds-base | grep pl$ | grep sbin”, plus any shell scripts?
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>>> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
>>>>
>>>> If you are not one of the named recipients or have received this email
>>>> in error,
>>>>
>>>> (i) you should not read, disclose, or copy it,
>>>>
>>>> (ii) please notify sender of your receipt by reply email and delete
>>>> this email and all attachments,
>>>>
>>>> (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
>>>>
>>>>
>>>> Please be informed that your personal data are processed according to
>>>> our data privacy policy as described on our website. Should you have
>>>> any questions related to personal data protection, please contact 3DS
>>>> Data Protection Officer at
>>>> 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com>
>>>>
>>>>
>>>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
>>>> _______________________________________________
>>>> 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.fedorapr
>>>> oject.org
--
389 Directory Server Development Team
4 years, 1 month
Re: [EXTERNAL] Re: setup-ds-admin fails to install admin server
by Mark Reynolds
Sorry no idea why this is happening based on the information you told
me. I've never heard of this happening with a completely fresh
install. Are you sure there is no pre-existing directory server you are
installing on top of? If you look under /etc/dirsrv/ are there any
"slapd-INSTANCE" directories?
So remove the old instance using remove-ds-admin.pl. Then try running
it with the debugger enabled:
# setup-ds-admin.pl -ddddd
If it still fails, then please provide the access log
(/var/log/dirsrv/slapd-INSTANCE/access), and the debug output from
setup-ds-admin.pl
Mark
On 5/1/20 8:44 AM, Crocker, Deborah wrote:
> I'm using the option 2 install [typical] interactive and take the defaults. The only thing I end up typing in is passwords.
>
> Deborah Crocker, PhD
> Systems Engineer III
> Office of Information Technology
> The University of Alabama
> Box 870346
> Tuscaloosa, AL 36587
> Office 205-348-3758 | Fax 205-348-9393
> deborah.crocker(a)ua.edu
>
>
> -----Original Message-----
> From: Mark Reynolds <mreynolds(a)redhat.com>
> Sent: Friday, May 1, 2020 7:17 AM
> To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; Crocker, Deborah <crock(a)ua.edu>
> Subject: [EXTERNAL] Re: [389-users] setup-ds-admin fails to install admin server
>
>
> On 4/30/20 5:23 PM, Crocker, Deborah wrote:
>> Why do I get this error on a setup-ds-admin.pl This was a fresh install.
>> -----------------------
>> The suffix 'o=NetscapeRoot' already exists. Config entry DN 'cn=o\3Dnetscaperoot,cn=mapping tree,cn=config'.
> And what options are you using when you install? Are you using a silent install file or interactive mode?
>
> Are "you" setting o=netscaperoot during the install? If so, do not do that, as the server is already going to create this suffix.
>
> Mark
>
>> Failed to create the configuration directory server
>> -----------------------
>>
>> The setup has
>> Centos 7.8
>> Epel install
>> 389-ds-base: 1.3.10.1
>> 389-admin: 1.1.46
>>
>> TIA
>>
>> Deborah Crocker, PhD
>> Systems Engineer III
>> Office of Information Technology
>> The University of Alabama
>> Box 870346
>> Tuscaloosa, AL 36587
>> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu
>>
>>
>> -----Original Message-----
>> From: Mark Reynolds <mreynolds(a)redhat.com>
>> Sent: Thursday, April 30, 2020 2:06 PM
>> To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; CHAMBERLAIN James <James.CHAMBERLAIN(a)3ds.com>
>> Subject: [EXTERNAL] [389-users] Re: [389-announce] Notice of Legacy Tool removal for 389 Directory Server
>>
>>
>> On 4/30/20 2:34 PM, CHAMBERLAIN James wrote:
>>> Hi Mark,
>>>
>>>> On Apr 29, 2020, at 5:10 PM, Mark Reynolds <mreynolds(a)redhat.com> wrote:
>>>>
>>>> On 4/29/20 5:07 PM, Mark Reynolds wrote:
>>>>> We've been talking about this for quite some time...
>>>>>
>>>>> A majority of all the old legacy perl and shell scripts have now been ported to the new CLI tools. Starting sometime in Fedora 33 we will stop shipping the legacy tools sub-package as part of 389 Directory Server.
>>>> To be more specific the 389-ds-base-1.4.4 version is where the removal of the legacy tools subpackage will occur.
>>> Does this includes tools like db2ldif.pl?
>> Correct, all of those scripts will be removed. So all the shell and perl scripts (except for logconv.pl) will no longer be available starting at some point in 1.4.4. The new CLI tools (dscreate, dsctl, and dsconf) can do everything all those other scripts could do plus more.
>>
>> If you need help porting something to the new CLI I'd be glad to help.
>>
>> Mark
>>
>>> Anything that matches anything that matches "rpm -ql 389-ds-base | grep pl$ | grep sbin”, plus any shell scripts?
>>>
>>> Thanks,
>>>
>>> James
>>>
>>> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
>>>
>>> If you are not one of the named recipients or have received this email
>>> in error,
>>>
>>> (i) you should not read, disclose, or copy it,
>>>
>>> (ii) please notify sender of your receipt by reply email and delete
>>> this email and all attachments,
>>>
>>> (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
>>>
>>>
>>> Please be informed that your personal data are processed according to
>>> our data privacy policy as described on our website. Should you have
>>> any questions related to personal data protection, please contact 3DS
>>> Data Protection Officer at
>>> 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com>
>>>
>>>
>>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
>>> _______________________________________________
>>> 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.fedorapr
>>> oject.org
--
389 Directory Server Development Team
4 years, 1 month
Re: setup-ds-admin fails to install admin server
by Mark Reynolds
On 4/30/20 5:23 PM, Crocker, Deborah wrote:
> Why do I get this error on a setup-ds-admin.pl? This was a fresh install.
> -----------------------
> The suffix 'o=NetscapeRoot' already exists. Config entry DN 'cn=o\3Dnetscaperoot,cn=mapping tree,cn=config'.
And what options are you using when you install? Are you using a silent
install file or interactive mode?
Are "you" setting o=netscaperoot during the install? If so, do not do
that, as the server is already going to create this suffix.
Mark
>
> Failed to create the configuration directory server
> -----------------------
>
> The setup has
> Centos 7.8
> Epel install
> 389-ds-base: 1.3.10.1
> 389-admin: 1.1.46
>
> TIA
>
> Deborah Crocker, PhD
> Systems Engineer III
> Office of Information Technology
> The University of Alabama
> Box 870346
> Tuscaloosa, AL 36587
> Office 205-348-3758 | Fax 205-348-9393
> deborah.crocker(a)ua.edu
>
>
> -----Original Message-----
> From: Mark Reynolds <mreynolds(a)redhat.com>
> Sent: Thursday, April 30, 2020 2:06 PM
> To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org>; CHAMBERLAIN James <James.CHAMBERLAIN(a)3ds.com>
> Subject: [EXTERNAL] [389-users] Re: [389-announce] Notice of Legacy Tool removal for 389 Directory Server
>
>
> On 4/30/20 2:34 PM, CHAMBERLAIN James wrote:
>> Hi Mark,
>>
>>> On Apr 29, 2020, at 5:10 PM, Mark Reynolds <mreynolds(a)redhat.com> wrote:
>>>
>>> On 4/29/20 5:07 PM, Mark Reynolds wrote:
>>>> We've been talking about this for quite some time...
>>>>
>>>> A majority of all the old legacy perl and shell scripts have now been ported to the new CLI tools. Starting sometime in Fedora 33 we will stop shipping the legacy tools sub-package as part of 389 Directory Server.
>>> To be more specific the 389-ds-base-1.4.4 version is where the removal of the legacy tools subpackage will occur.
>> Does this includes tools like db2ldif.pl?
> Correct, all of those scripts will be removed. So all the shell and perl scripts (except for logconv.pl) will no longer be available starting at some point in 1.4.4. The new CLI tools (dscreate, dsctl, and dsconf) can do everything all those other scripts could do plus more.
>
> If you need help porting something to the new CLI I'd be glad to help.
>
> Mark
>
>> Anything that matches anything that matches "rpm -ql 389-ds-base | grep pl$ | grep sbin”, plus any shell scripts?
>>
>> Thanks,
>>
>> James
>>
>> This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.
>>
>> If you are not one of the named recipients or have received this email
>> in error,
>>
>> (i) you should not read, disclose, or copy it,
>>
>> (ii) please notify sender of your receipt by reply email and delete
>> this email and all attachments,
>>
>> (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.
>>
>>
>> Please be informed that your personal data are processed according to
>> our data privacy policy as described on our website. Should you have
>> any questions related to personal data protection, please contact 3DS
>> Data Protection Officer at
>> 3DS.compliance-privacy(a)3ds.com<mailto:3DS.compliance-privacy@3ds.com>
>>
>>
>> For other languages, go to https://www.3ds.com/terms/email-disclaimer
>> _______________________________________________
>> 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.fedorapr
>> oject.org
--
389 Directory Server Development Team
4 years, 1 month
