[389-users] Re: New Install Missing Schema Files

[Trevor Fong]

Hi Patrick,

Thanks for the link to those docs.  

I finally succeeded with a combination of tips from Mark and Patrick:
1. removed /usr/share/dirsrv/schema/10rfc2307.ldif
2. copied /usr/share/dirsrv/data/10rfc2307bis.ldif to /usr/share/dirsrv/schema/

It seems that for 389 DS 1.3.6.1, /usr/share/dirsrv/schema/ takes precedence 
over /etc/dirsrv/slapd-/schema/

This seems to be different for 389 DS 1.2.11, where the converse is true.

However, I was reading more re schema:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/administration_guide/index

11.1.1. Default Schema Files
The schema for Directory Server is defined in several different schema files 
(LDIF files which define schema elements). The Directory Server schema files 
are located in the /usr/share/dirsrv/schema/ directory. The files in this 
directory are used as templates for new Directory Server instances. Adding a 
new schema into this directory will make it available to any new instances.

Do the docs need to be updated?

Thanks,
Trev
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: New Install Missing Schema Files

[Patrick Landry]

There are several references to 10rfc2307bis.ldif in the Red Hat Directory 
Server version 10 "Configuration, Command, and File Reference" 
manual . This one talks about replacing 60autofs.ldif with 10rfc2307bis.ldif . 
5.2.16. automountInformation 
This attribute contains information used by the autofs automounter. 

Note 
The automountInformation attribute is defined in 60autofs.ldif in the Directory 
Server. To use the updated RFC 2307 schema, remove the 60autofs.ldif file and 
copy the 10rfc2307bis.ldif file from the /usr/share/dirsrv/data directory to 
the /etc/dirsrv/slapd- instance /schema directory. 

This one talks about replacing 10rfc2307.ldif with 10rfc2307bis.ldif. 
5.2.17. bootFile 
This attribute contains the boot image file name. 

Note 
The bootFile attribute is defined in 10rfc2307.ldif in the Directory Server. To 
use the updated RFC 2307 schema, remove the 10rfc2307.ldif file and copy the 
10rfc2307bis.ldif file from the /usr/share/dirsrv/data directory to the 
/etc/dirsrv/slapd- instance /schema directory. 

I have not needed to do this but I would think that if you do want to use 
10rfc2307bis.ldif you would have 
to remove both 60autofs.ldif and 10rfc2307.ldif to avoid conflicting 
(duplicate) attribute definitions. 

- Original Message -

> From: "Trevor Fong" 
> To: "General discussion list for the 389 Directory server project."
> <389-users@lists.fedoraproject.org>
> Sent: Tuesday, October 10, 2017 12:16:34 PM
> Subject: [389-users] Re: New Install Missing Schema Files

> Oh - I get it now; core schema is now immutably maintained in
> /usr/share/dirsrv/schema/ and is referenced by each slapd instance.

> How do I go about overriding the core schema?
> For example, if I wanted to replace 10rfc2307.ldif with 10rfc2307bis.ldif,
> what would I do?
> Previously, we would remove
> /etc/dirsrv/slapd-/schema/10rfc2307.ldif and add
> /etc/dirsrv/slapd-/schema/10rfc2307bis.ldif
> How would we accomplish this now with core schema immutably maintained in
> /usr/share/dirsrv/schema/?

> Currently I get the fatal error:

> [10/Oct/2017:10:07:50.514409639 -0700] - ERR - dse_read_one_file - The entry
> cn=schema in file /etc/dirsrv/slapd-eldapdcp1/schema/10rfc2307bis.ldif
> (lineno: 1) is invalid, error code 20 (Type or value exists) - object class
> nisMap: The name does not match the OID "1.3.6.1.1.1.2.9". Another object
> class is already using the name or OID.

> because it clashes with the default /usr/share/dirsrv/schema/10rfc2307.ldif

> Thanks,
> Trev

> On 10 October 2017 at 09:46, Mark Reynolds < marey...@redhat.com > wrote:

> > On 10/10/2017 12:36 PM, Trevor Fong wrote:
> 

> > > Hi Mark and Michael,
> > 
> 

> > > Thanks a lot for your replies.
> > 
> 
> > > I've run the setup-ds.pl (and also tried setup-ds-admin.pl ),
> > > /etc/dirsrv/slapd-/schema only contains 99user.ldif.
> > 
> 
> > > /usr/share/dirsrv/schema does indeed contain all the default schema
> > > files,
> > > but it doesn't look like they're copied to the instance schema dir.
> > 
> 

> > Correct, the core schema stays in /usr/share/dirsrv/schema, while custom
> > schema is in the instance directory.
> 

> > Are you running into problems?
> 

> > > Trev
> > 
> 

> > > On 10 October 2017 at 08:19, Mark Reynolds < marey...@redhat.com > wrote:
> > 
> 

> > > > On 10/10/2017 11:13 AM, Trevor Fong wrote:
> > > 
> > 
> 
> > > > > Hi Everyone,
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > I just did a new install and it looks like no schema files were
> > > > > included
> > > > > with it?
> > > 
> > 
> 
> > > > > I seem to remember that previously, included schema files would be in
> > > > > /etc/dirsrv/schema and would get copied into any new instances that
> > > > > were
> > > > > set up.
> > > 
> > 
> 
> > > > > However with this install /etc/dirsrv/schema/ only contained
> > > > > 99user.ldif
> > > 
> > 
> 
> > > > > Am I missing something?
> > > 
> > 
> 
> > > > Things were changed for the "core" server schema. It should be in
> > > 
> > 
> 
> > > > /usr/share/dirsrv/schema
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > Thanks a lot,
> > > 
> > 
> 
> > > > > Trev
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > Here’s what I did:
> > > 
> > 
> 
> > > > >
> > > 
> > 
> 
> > > > > [root@eldapdch1 tfong]# uname -a
> > > 
> > 
> 
> > > > > Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24
> > > > > EDT
> > > > > 2017 x86_64 x86_64 x86_64 GNU/Linux
> > > 
> > 
> 
> > > > > [root@eldapdch1 etc]# yum install 389-ds
> > > 
> > 
> 
> > > > > Loaded plugins: rhnplugin, search-disabled-repos
> > > 
> > 
> 
> > > > > This system is receiving updates from RHN Classic or Red Hat
> > > > > Satellite.
> > > 
> > 
> 
> > > > > Resolving Dependencies
> > > 
> > 
> 
> > > > > --> Running transaction check
> > > 
> > 
> 
> > > > > ---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
> > > 
> > 
> 
> > > > > --> Processing Dependency: 389-dsgw for package:
> > > > > 

[389-users] Re: New Install Missing Schema Files

[Mark Reynolds]

On 10/10/2017 02:19 PM, Mark Reynolds wrote:
>
>
> On 10/10/2017 01:12 PM, Trevor Fong wrote:
>> Oh - I get it now; core schema is now immutably maintained in
>> /usr/share/dirsrv/schema/ and is referenced by each slapd instance.  
>>
>> How do I go about overriding the core schema? 
> You are not supposed to :-/
>
> You can try stopping the server, then replacing the file in
> /usr/dirsrv/share/schema.  It looks like it's still pulling it into: 
> /etc/dirsrv/slapd-eldapdcp1/schema, so you might have to do it in two
> locations
>> For example, if I wanted to replace 10rfc2307.ldif
>> with 10rfc2307bis.ldif, what would I do?
>> Previously, we would remove
>> /etc/dirsrv/slapd-/schema/10rfc2307.ldif and add
>> /etc/dirsrv/slapd-/schema/10rfc2307bis.ldif
>> How would we accomplish this now with core schema immutably
>> maintained in /usr/share/dirsrv/schema/?
>>
>> Currently I get the fatal error:
>>
>> [10/Oct/2017:10:07:50.514409639 -0700] - ERR - dse_read_one_file -
>> The entry cn=schema in file
>> /etc/dirsrv/slapd-eldapdcp1/schema/10rfc2307bis.ldif (lineno: 1) is
>> invalid, error code 20 (Type or value exists) - object class nisMap:
>> The name does not match the OID "1.3.6.1.1.1.2.9". Another object
>> class is already using the name or OID.
>>
>> because it clashes with the
>> default /usr/share/dirsrv/schema/10rfc2307.ldif
>>
>> Thanks,
>> Trev
>>
>>
>> On 10 October 2017 at 09:46, Mark Reynolds > > wrote:
>>
>>
>>
>> On 10/10/2017 12:36 PM, Trevor Fong wrote:
>>> Hi Mark and Michael,
>>>
>>> Thanks a lot for your replies.
>>> I've run the setup-ds.pl  (and also
>>> tried setup-ds-admin.pl ),
>>> /etc/dirsrv/slapd-/schema only contains 99user.ldif.
>>> /usr/share/dirsrv/schema does indeed contain all the default
>>> schema files, but it doesn't look like they're copied to the
>>> instance schema dir.
>> Correct, the core schema stays in /usr/share/dirsrv/schema, while
>> custom schema is in the instance directory.
>>
>> Are you running into problems?
>>
>>>
>>> Trev 
>>>
>>> On 10 October 2017 at 08:19, Mark Reynolds >> > wrote:
>>>
>>>
>>>
>>> On 10/10/2017 11:13 AM, Trevor Fong wrote:
>>> > Hi Everyone,
>>> >
>>> > I just did a new install and it looks like no schema files
>>> were included with it?
>>> > I seem to remember that previously, included schema files
>>> would be in /etc/dirsrv/schema and would get copied into any
>>> new instances that were set up.
>>> > However with this install /etc/dirsrv/schema/ only
>>> contained 99user.ldif
>>> > Am I missing something?
>>> Things were changed for the "core" server schema.  It should
>>> be in
>>> /usr/share/dirsrv/schema
>>> >
>>> > Thanks a lot,
>>> > Trev
>>> >
>>> > Here’s what I did:
>>> >
>>> > [root@eldapdch1 tfong]# uname -a
>>> > Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9
>>> 03:55:24 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
>>> > [root@eldapdch1 etc]# yum install 389-ds
>>> > Loaded plugins: rhnplugin, search-disabled-repos
>>> > This system is receiving updates from RHN Classic or Red
>>> Hat Satellite.
>>> > Resolving Dependencies
>>> > --> Running transaction check
>>> > ---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
>>> > --> Processing Dependency: 389-dsgw for package:
>>> 389-ds-1.2.2-6.el7.noarch
>>> > --> Processing Dependency: 389-ds-console-doc for package:
>>> 389-ds-1.2.2-6.el7.noarch
>>> > --> Processing Dependency: 389-ds-console for package:
>>> 389-ds-1.2.2-6.el7.noarch
>>> > --> Processing Dependency: 389-ds-base for package:
>>> 389-ds-1.2.2-6.el7.noarch
>>> > --> Processing Dependency: 389-console for package:
>>> 389-ds-1.2.2-6.el7.noarch
>>> > --> Processing Dependency: 389-admin-console-doc for
>>> package: 389-ds-1.2.2-6.el7.noarch
>>> > --> Processing Dependency: 389-admin-console for package:
>>> 389-ds-1.2.2-6.el7.noarch
>>> > --> Processing Dependency: 389-admin for package:
>>> 389-ds-1.2.2-6.el7.noarch
>>> > --> Running transaction check
>>> > ---> Package 389-admin.x86_64 0:1.1.46-1.el7 will be installed
>>> > --> Processing Dependency: libadmsslutil.so.0()(64bit) for
>>> package: 389-admin-1.1.46-1.el7.x86_64
>>> > --> Processing Dependency: libadminutil.so.0()(64bit) for
>>> package: 389-admin-1.1.46-1.el7.x86_64
>>> > ---> Package 389-admin-console.noarch 0:1.1.12-1.el7 will
>>> be installed
>>> > ---> Package 

[389-users] USN and single-master replication?

[Thomas Walker]

Hi,

We're currently using 389ds as a backend for sssd and would like to try to 
improve the performance by enabling USN on the server side.  Our current 
architecture, however, hides the individual client facing ldap servers behind a 
load-balanced VIP so the client never actually knows which backend it may hit.  
This poses a problem with USNs because successive requests may not hit the same 
server and the USNs are local to the server and explicitily not replicated.  I 
understand why this is the case (so that multimaster configs work correctly) 
but we only run a single master that replicates out to the client-facing ldap 
servers (which in turn refer any updates back to the master).

It sounds like we would actually *want* to force the replication of the USNs 
out to the client facing servers (so that it doesn't matter which backend you 
hit, the numbers will always match) but I can't figure out how to do that (or 
even if it is possible).  The USN plugin adds 'EXCLUDE entryusn' to the default 
nsDS5ReplicatedAttributeList on startup and my attempts to override it this on 
the individual replication agreemetns have, thus far, not worked.

Is there some way to make this setup work with USNs?

Thanks...
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: New Install Missing Schema Files

[Trevor Fong]

Oh - I get it now; core schema is now immutably maintained in
/usr/share/dirsrv/schema/ and is referenced by each slapd instance.

How do I go about overriding the core schema?
For example, if I wanted to replace 10rfc2307.ldif with 10rfc2307bis.ldif,
what would I do?
Previously, we would remove /etc/dirsrv/slapd-/schema/10rfc2307.ldif
and add /etc/dirsrv/slapd-/schema/10rfc2307bis.ldif
How would we accomplish this now with core schema immutably maintained in
/usr/share/dirsrv/schema/?

Currently I get the fatal error:

[10/Oct/2017:10:07:50.514409639 -0700] - ERR - dse_read_one_file - The
entry cn=schema in file /etc/dirsrv/slapd-eldapdcp1/schema/10rfc2307bis.ldif
(lineno: 1) is invalid, error code 20 (Type or value exists) - object class
nisMap: The name does not match the OID "1.3.6.1.1.1.2.9". Another object
class is already using the name or OID.

because it clashes with the default /usr/share/dirsrv/schema/10rfc2307.ldif

Thanks,
Trev

On 10 October 2017 at 09:46, Mark Reynolds  wrote:

>
>
> On 10/10/2017 12:36 PM, Trevor Fong wrote:
>
> Hi Mark and Michael,
>
> Thanks a lot for your replies.
> I've run the setup-ds.pl (and also tried setup-ds-admin.pl),
> /etc/dirsrv/slapd-/schema only contains 99user.ldif.
> /usr/share/dirsrv/schema does indeed contain all the default schema files,
> but it doesn't look like they're copied to the instance schema dir.
>
> Correct, the core schema stays in /usr/share/dirsrv/schema, while custom
> schema is in the instance directory.
>
> Are you running into problems?
>
>
> Trev
>
> On 10 October 2017 at 08:19, Mark Reynolds  wrote:
>
>>
>>
>> On 10/10/2017 11:13 AM, Trevor Fong wrote:
>> > Hi Everyone,
>> >
>> > I just did a new install and it looks like no schema files were
>> included with it?
>> > I seem to remember that previously, included schema files would be in
>> /etc/dirsrv/schema and would get copied into any new instances that were
>> set up.
>> > However with this install /etc/dirsrv/schema/ only contained 99user.ldif
>> > Am I missing something?
>> Things were changed for the "core" server schema.  It should be in
>> /usr/share/dirsrv/schema
>> >
>> > Thanks a lot,
>> > Trev
>> >
>> > Here’s what I did:
>> >
>> > [root@eldapdch1 tfong]# uname -a
>> > Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24 EDT
>> 2017 x86_64 x86_64 x86_64 GNU/Linux
>> > [root@eldapdch1 etc]# yum install 389-ds
>> > Loaded plugins: rhnplugin, search-disabled-repos
>> > This system is receiving updates from RHN Classic or Red Hat Satellite.
>> > Resolving Dependencies
>> > --> Running transaction check
>> > ---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
>> > --> Processing Dependency: 389-dsgw for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Processing Dependency: 389-ds-console-doc for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Processing Dependency: 389-ds-console for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Processing Dependency: 389-ds-base for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Processing Dependency: 389-console for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Processing Dependency: 389-admin-console-doc for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Processing Dependency: 389-admin-console for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Processing Dependency: 389-admin for package:
>> 389-ds-1.2.2-6.el7.noarch
>> > --> Running transaction check
>> > ---> Package 389-admin.x86_64 0:1.1.46-1.el7 will be installed
>> > --> Processing Dependency: libadmsslutil.so.0()(64bit) for package:
>> 389-admin-1.1.46-1.el7.x86_64
>> > --> Processing Dependency: libadminutil.so.0()(64bit) for package:
>> 389-admin-1.1.46-1.el7.x86_64
>> > ---> Package 389-admin-console.noarch 0:1.1.12-1.el7 will be installed
>> > ---> Package 389-admin-console-doc.noarch 0:1.1.12-1.el7 will be
>> installed
>> > ---> Package 389-console.noarch 0:1.1.18-1.el7 will be installed
>> > ---> Package 389-ds-base.x86_64 0:1.3.6.1-19.el7_4 will be installed
>> > --> Processing Dependency: 389-ds-base-libs = 1.3.6.1-19.el7_4 for
>> package: 389-ds-base-1.3.6.1-19.el7_4.x86_64
>> > --> Processing Dependency: libnunc-stans.so.0()(64bit) for package:
>> 389-ds-base-1.3.6.1-19.el7_4.x86_64
>> > --> Processing Dependency: libsds.so.0()(64bit) for package:
>> 389-ds-base-1.3.6.1-19.el7_4.x86_64
>> > --> Processing Dependency: libns-dshttpd-1.3.6.1.so()(64bit) for
>> package: 389-ds-base-1.3.6.1-19.el7_4.x86_64
>> > --> Processing Dependency: libslapd.so.0()(64bit) for package:
>> 389-ds-base-1.3.6.1-19.el7_4.x86_64
>> > ---> Package 389-ds-console.noarch 0:1.2.16-1.el7 will be installed
>> > ---> Package 389-ds-console-doc.noarch 0:1.2.16-1.el7 will be installed
>> > ---> Package 389-dsgw.x86_64 0:1.1.11-5.el7 will be installed
>> > --> Running transaction check
>> > ---> Package 389-adminutil.x86_64 0:1.1.21-2.el7 will be installed
>> > ---> Package 389-ds-base-libs.x86_64 0:1.3.6.1-19.el7_4 will be
>> installed
>> 

[389-users] Re: New Install Missing Schema Files

[Mark Reynolds]

On 10/10/2017 12:36 PM, Trevor Fong wrote:
> Hi Mark and Michael,
>
> Thanks a lot for your replies.
> I've run the setup-ds.pl  (and also
> tried setup-ds-admin.pl ),
> /etc/dirsrv/slapd-/schema only contains 99user.ldif.
> /usr/share/dirsrv/schema does indeed contain all the default schema
> files, but it doesn't look like they're copied to the instance schema dir.
Correct, the core schema stays in /usr/share/dirsrv/schema, while custom
schema is in the instance directory.

Are you running into problems?
>
> Trev 
>
> On 10 October 2017 at 08:19, Mark Reynolds  > wrote:
>
>
>
> On 10/10/2017 11:13 AM, Trevor Fong wrote:
> > Hi Everyone,
> >
> > I just did a new install and it looks like no schema files were
> included with it?
> > I seem to remember that previously, included schema files would
> be in /etc/dirsrv/schema and would get copied into any new
> instances that were set up.
> > However with this install /etc/dirsrv/schema/ only contained
> 99user.ldif
> > Am I missing something?
> Things were changed for the "core" server schema.  It should be in
> /usr/share/dirsrv/schema
> >
> > Thanks a lot,
> > Trev
> >
> > Here’s what I did:
> >
> > [root@eldapdch1 tfong]# uname -a
> > Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9
> 03:55:24 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux
> > [root@eldapdch1 etc]# yum install 389-ds
> > Loaded plugins: rhnplugin, search-disabled-repos
> > This system is receiving updates from RHN Classic or Red Hat
> Satellite.
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
> > --> Processing Dependency: 389-dsgw for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-ds-console-doc for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-ds-console for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-ds-base for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-console for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-admin-console-doc for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-admin-console for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-admin for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Running transaction check
> > ---> Package 389-admin.x86_64 0:1.1.46-1.el7 will be installed
> > --> Processing Dependency: libadmsslutil.so.0()(64bit) for
> package: 389-admin-1.1.46-1.el7.x86_64
> > --> Processing Dependency: libadminutil.so.0()(64bit) for
> package: 389-admin-1.1.46-1.el7.x86_64
> > ---> Package 389-admin-console.noarch 0:1.1.12-1.el7 will be
> installed
> > ---> Package 389-admin-console-doc.noarch 0:1.1.12-1.el7 will be
> installed
> > ---> Package 389-console.noarch 0:1.1.18-1.el7 will be installed
> > ---> Package 389-ds-base.x86_64 0:1.3.6.1-19.el7_4 will be installed
> > --> Processing Dependency: 389-ds-base-libs = 1.3.6.1-19.el7_4
> for package: 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libnunc-stans.so.0()(64bit) for
> package: 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libsds.so.0()(64bit) for package:
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libns-dshttpd-1.3.6.1.so
> ()(64bit) for package:
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libslapd.so.0()(64bit) for package:
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > ---> Package 389-ds-console.noarch 0:1.2.16-1.el7 will be installed
> > ---> Package 389-ds-console-doc.noarch 0:1.2.16-1.el7 will be
> installed
> > ---> Package 389-dsgw.x86_64 0:1.1.11-5.el7 will be installed
> > --> Running transaction check
> > ---> Package 389-adminutil.x86_64 0:1.1.21-2.el7 will be installed
> > ---> Package 389-ds-base-libs.x86_64 0:1.3.6.1-19.el7_4 will be
> installed
> > --> Finished Dependency Resolution
> >
> > Dependencies Resolved
> >
> >
> 
> =
> > Package                                              Arch       
>                           Version                                 
>           Repository                                           Size
> >
> 
> 

[389-users] Re: New Install Missing Schema Files

[Trevor Fong]

Hi Mark and Michael,

Thanks a lot for your replies.
I've run the setup-ds.pl (and also tried setup-ds-admin.pl),
/etc/dirsrv/slapd-/schema only contains 99user.ldif.
/usr/share/dirsrv/schema does indeed contain all the default schema files,
but it doesn't look like they're copied to the instance schema dir.

Trev

On 10 October 2017 at 08:19, Mark Reynolds  wrote:

>
>
> On 10/10/2017 11:13 AM, Trevor Fong wrote:
> > Hi Everyone,
> >
> > I just did a new install and it looks like no schema files were included
> with it?
> > I seem to remember that previously, included schema files would be in
> /etc/dirsrv/schema and would get copied into any new instances that were
> set up.
> > However with this install /etc/dirsrv/schema/ only contained 99user.ldif
> > Am I missing something?
> Things were changed for the "core" server schema.  It should be in
> /usr/share/dirsrv/schema
> >
> > Thanks a lot,
> > Trev
> >
> > Here’s what I did:
> >
> > [root@eldapdch1 tfong]# uname -a
> > Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24 EDT
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> > [root@eldapdch1 etc]# yum install 389-ds
> > Loaded plugins: rhnplugin, search-disabled-repos
> > This system is receiving updates from RHN Classic or Red Hat Satellite.
> > Resolving Dependencies
> > --> Running transaction check
> > ---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
> > --> Processing Dependency: 389-dsgw for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-ds-console-doc for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-ds-console for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-ds-base for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-console for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-admin-console-doc for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-admin-console for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Processing Dependency: 389-admin for package:
> 389-ds-1.2.2-6.el7.noarch
> > --> Running transaction check
> > ---> Package 389-admin.x86_64 0:1.1.46-1.el7 will be installed
> > --> Processing Dependency: libadmsslutil.so.0()(64bit) for package:
> 389-admin-1.1.46-1.el7.x86_64
> > --> Processing Dependency: libadminutil.so.0()(64bit) for package:
> 389-admin-1.1.46-1.el7.x86_64
> > ---> Package 389-admin-console.noarch 0:1.1.12-1.el7 will be installed
> > ---> Package 389-admin-console-doc.noarch 0:1.1.12-1.el7 will be
> installed
> > ---> Package 389-console.noarch 0:1.1.18-1.el7 will be installed
> > ---> Package 389-ds-base.x86_64 0:1.3.6.1-19.el7_4 will be installed
> > --> Processing Dependency: 389-ds-base-libs = 1.3.6.1-19.el7_4 for
> package: 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libnunc-stans.so.0()(64bit) for package:
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libsds.so.0()(64bit) for package:
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libns-dshttpd-1.3.6.1.so()(64bit) for
> package: 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > --> Processing Dependency: libslapd.so.0()(64bit) for package:
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> > ---> Package 389-ds-console.noarch 0:1.2.16-1.el7 will be installed
> > ---> Package 389-ds-console-doc.noarch 0:1.2.16-1.el7 will be installed
> > ---> Package 389-dsgw.x86_64 0:1.1.11-5.el7 will be installed
> > --> Running transaction check
> > ---> Package 389-adminutil.x86_64 0:1.1.21-2.el7 will be installed
> > ---> Package 389-ds-base-libs.x86_64 0:1.3.6.1-19.el7_4 will be installed
> > --> Finished Dependency Resolution
> >
> > Dependencies Resolved
> >
> > 
> 
> 
> =
> > Package  Arch
>   Version
> Repository   Size
> > 
> 
> 
> =
> > Installing:
> > 389-ds   noarch
>   1.2.2-6.el7epel
>11 k
> > Installing for dependencies:
> > 389-adminx86_64
>   1.1.46-1.el7   epel
>   391 k
> > 389-admin-consolenoarch
>   1.1.12-1.el7   epel
>   204 k
> > 389-admin-console-doc   

[389-users] Re: New Install Missing Schema Files

[Michal Medvecky]

You have to run setup-ds after package installation

> On 10 Oct 2017, at 17:13, Trevor Fong  wrote:
> 
> Hi Everyone,
> 
> I just did a new install and it looks like no schema files were included with 
> it?
> I seem to remember that previously, included schema files would be in 
> /etc/dirsrv/schema and would get copied into any new instances that were set 
> up.
> However with this install /etc/dirsrv/schema/ only contained 99user.ldif
> Am I missing something?
> 
> Thanks a lot,
> Trev
> 
> Here’s what I did:
> 
> [root@eldapdch1 tfong]# uname -a
> Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24 EDT 2017 
> x86_64 x86_64 x86_64 GNU/Linux
> [root@eldapdch1 etc]# yum install 389-ds
> Loaded plugins: rhnplugin, search-disabled-repos
> This system is receiving updates from RHN Classic or Red Hat Satellite.
> Resolving Dependencies
> --> Running transaction check
> ---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
> --> Processing Dependency: 389-dsgw for package: 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-ds-console-doc for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-ds-console for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-ds-base for package: 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-console for package: 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-admin-console-doc for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-admin-console for package: 
> 389-ds-1.2.2-6.el7.noarch
> --> Processing Dependency: 389-admin for package: 389-ds-1.2.2-6.el7.noarch
> --> Running transaction check
> ---> Package 389-admin.x86_64 0:1.1.46-1.el7 will be installed
> --> Processing Dependency: libadmsslutil.so.0()(64bit) for package: 
> 389-admin-1.1.46-1.el7.x86_64
> --> Processing Dependency: libadminutil.so.0()(64bit) for package: 
> 389-admin-1.1.46-1.el7.x86_64
> ---> Package 389-admin-console.noarch 0:1.1.12-1.el7 will be installed
> ---> Package 389-admin-console-doc.noarch 0:1.1.12-1.el7 will be installed
> ---> Package 389-console.noarch 0:1.1.18-1.el7 will be installed
> ---> Package 389-ds-base.x86_64 0:1.3.6.1-19.el7_4 will be installed
> --> Processing Dependency: 389-ds-base-libs = 1.3.6.1-19.el7_4 for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libnunc-stans.so.0()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libsds.so.0()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libns-dshttpd-1.3.6.1.so()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> --> Processing Dependency: libslapd.so.0()(64bit) for package: 
> 389-ds-base-1.3.6.1-19.el7_4.x86_64
> ---> Package 389-ds-console.noarch 0:1.2.16-1.el7 will be installed
> ---> Package 389-ds-console-doc.noarch 0:1.2.16-1.el7 will be installed
> ---> Package 389-dsgw.x86_64 0:1.1.11-5.el7 will be installed
> --> Running transaction check
> ---> Package 389-adminutil.x86_64 0:1.1.21-2.el7 will be installed
> ---> Package 389-ds-base-libs.x86_64 0:1.3.6.1-19.el7_4 will be installed
> --> Finished Dependency Resolution
> 
> Dependencies Resolved
> 
> =
> Package  Arch 
>  VersionRepository
>Size
> =
> Installing:
> 389-ds   noarch   
>  1.2.2-6.el7epel  
>11 k
> Installing for dependencies:
> 389-adminx86_64   
>  1.1.46-1.el7   epel  
>   391 k
> 389-admin-consolenoarch   
>  1.1.12-1.el7   epel  
>   204 k
> 389-admin-console-docnoarch   
>  1.1.12-1.el7   epel  
>45 k
> 389-adminutilx86_64   
>  1.1.21-2.el7   epel  
>73 k
> 389-console  noarch 

[389-users] New Install Missing Schema Files

[Trevor Fong]

Hi Everyone,
 
I just did a new install and it looks like no schema files were included with 
it?
I seem to remember that previously, included schema files would be in 
/etc/dirsrv/schema and would get copied into any new instances that were set up.
However with this install /etc/dirsrv/schema/ only contained 99user.ldif
Am I missing something?
 
Thanks a lot,
Trev
 
Here’s what I did:
 
[root@eldapdch1 tfong]# uname -a
Linux eldapdch1 3.10.0-693.2.2.el7.x86_64 #1 SMP Sat Sep 9 03:55:24 EDT 2017 
x86_64 x86_64 x86_64 GNU/Linux
[root@eldapdch1 etc]# yum install 389-ds
Loaded plugins: rhnplugin, search-disabled-repos
This system is receiving updates from RHN Classic or Red Hat Satellite.
Resolving Dependencies
--> Running transaction check
---> Package 389-ds.noarch 0:1.2.2-6.el7 will be installed
--> Processing Dependency: 389-dsgw for package: 389-ds-1.2.2-6.el7.noarch
--> Processing Dependency: 389-ds-console-doc for package: 
389-ds-1.2.2-6.el7.noarch
--> Processing Dependency: 389-ds-console for package: 389-ds-1.2.2-6.el7.noarch
--> Processing Dependency: 389-ds-base for package: 389-ds-1.2.2-6.el7.noarch
--> Processing Dependency: 389-console for package: 389-ds-1.2.2-6.el7.noarch
--> Processing Dependency: 389-admin-console-doc for package: 
389-ds-1.2.2-6.el7.noarch
--> Processing Dependency: 389-admin-console for package: 
389-ds-1.2.2-6.el7.noarch
--> Processing Dependency: 389-admin for package: 389-ds-1.2.2-6.el7.noarch
--> Running transaction check
---> Package 389-admin.x86_64 0:1.1.46-1.el7 will be installed
--> Processing Dependency: libadmsslutil.so.0()(64bit) for package: 
389-admin-1.1.46-1.el7.x86_64
--> Processing Dependency: libadminutil.so.0()(64bit) for package: 
389-admin-1.1.46-1.el7.x86_64
---> Package 389-admin-console.noarch 0:1.1.12-1.el7 will be installed
---> Package 389-admin-console-doc.noarch 0:1.1.12-1.el7 will be installed
---> Package 389-console.noarch 0:1.1.18-1.el7 will be installed
---> Package 389-ds-base.x86_64 0:1.3.6.1-19.el7_4 will be installed
--> Processing Dependency: 389-ds-base-libs = 1.3.6.1-19.el7_4 for package: 
389-ds-base-1.3.6.1-19.el7_4.x86_64
--> Processing Dependency: libnunc-stans.so.0()(64bit) for package: 
389-ds-base-1.3.6.1-19.el7_4.x86_64
--> Processing Dependency: libsds.so.0()(64bit) for package: 
389-ds-base-1.3.6.1-19.el7_4.x86_64
--> Processing Dependency: libns-dshttpd-1.3.6.1.so()(64bit) for package: 
389-ds-base-1.3.6.1-19.el7_4.x86_64
--> Processing Dependency: libslapd.so.0()(64bit) for package: 
389-ds-base-1.3.6.1-19.el7_4.x86_64
---> Package 389-ds-console.noarch 0:1.2.16-1.el7 will be installed
---> Package 389-ds-console-doc.noarch 0:1.2.16-1.el7 will be installed
---> Package 389-dsgw.x86_64 0:1.1.11-5.el7 will be installed
--> Running transaction check
---> Package 389-adminutil.x86_64 0:1.1.21-2.el7 will be installed
---> Package 389-ds-base-libs.x86_64 0:1.3.6.1-19.el7_4 will be installed
--> Finished Dependency Resolution
 
Dependencies Resolved
 
=
Package  Arch   
   VersionRepository
   Size
=
Installing:
389-ds   noarch 
   1.2.2-6.el7epel  
   11 k
Installing for dependencies:
389-adminx86_64 
   1.1.46-1.el7   epel  
  391 k
389-admin-consolenoarch 
   1.1.12-1.el7   epel  
  204 k
389-admin-console-docnoarch 
   1.1.12-1.el7   epel  
   45 k
389-adminutilx86_64 
   1.1.21-2.el7   epel  
   73 k
389-console  noarch 
   1.1.18-1.el7   epel  
   75 k
389-ds-base  x86_64 
   1.3.6.1-19.el7_4   

[389-users] Re: 1.3.6 dirsrv crash: ERR - valueset_value_syntax_cmp - slapi_attr_values2keys_sv failed for type lastUpdated

[Mark Reynolds]

On 10/10/2017 10:27 AM, tda...@email.arizona.edu wrote:
>> When the server crashes do you get a core dump or similar? That would
>> really help. 
> Where do I find a core dump?
First you need to make sure cores are allowed to be generated:

http://www.port389.org/docs/389ds/FAQ/faq.html#sts=Debugging%C2%A0Crashes

Where the core file gets written can vary on OS/OS config.  It is
sometimes found here:

/var/spool/abrt/*/coredump

or /var/lib/systemd/coredump/ You could also just search the filesystem
for "core". Once you find it, attach gdb and get a stack trace. See the
doc above for more info on that as well.Regards, Mark

>
>> I think the issue with the lastUpdated type is that this is a custom
>> element of your schema - I can't find any references to it at all in our
>> code base. Can you send me your schema definiton for this attribute? 
> This is the entry that after I deleted it enabled the server to start up 
> again:
> dn: cn=grouperstatus, ou=People,dc=eds,dc=arizona,dc=edu
> objectClass: edsstatus
> objectClass: top
> cn: grouperstatus
>
> It contains the multi-valued attributes lastUpdated and lastStarted, both 
> strings.
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 1.3.6 dirsrv crash: ERR - valueset_value_syntax_cmp - slapi_attr_values2keys_sv failed for type lastUpdated

[tdarby]

> When the server crashes do you get a core dump or similar? That would
> really help. 

Where do I find a core dump?

> I think the issue with the lastUpdated type is that this is a custom
> element of your schema - I can't find any references to it at all in our
> code base. Can you send me your schema definiton for this attribute? 

This is the entry that after I deleted it enabled the server to start up again:
dn: cn=grouperstatus, ou=People,dc=eds,dc=arizona,dc=edu
objectClass: edsstatus
objectClass: top
cn: grouperstatus

It contains the multi-valued attributes lastUpdated and lastStarted, both 
strings.
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 1.3.6 dirsrv crash: ERR - valueset_value_syntax_cmp - slapi_attr_values2keys_sv failed for type lastUpdated

[Mark Reynolds]

On 10/10/2017 09:56 AM, tda...@email.arizona.edu wrote:
>> On 10/09/2017 05:33 PM, tdarby(a)email.arizona.edu wrote:
>> Okay the version you have has a few
>> known crashes.  They have been fixed
>> in 1.3.6.1-20 and up.  This fix will also be part of RHEL's 7.4 batch
>> update 2.
> Thanks, I don't see a way to get a higher packaged version with CentOS 7.4. 
> I'm not committed to CentOS. What about switching to Fedora 26 in order to 
> get the 1.3.6.8 package?
That's up to you :-)    What is nice about fedora in this regard is that
you can always get the latest (upstream) version.  If you could at least
test this on Fedora with the latest version of 389 so we can rule out if
its a known issue or a new one.
>
> Is there anything I can do about the attrlist_replace - attr_replace 
> nsslapd-referral messages filling up the errors log?
This is now fixed upstream on Fedora (26 and up)

Downstream, RHEL 7.4 does not have the fix yet, but it will in Batch
Update 3 (a few months away)
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 1.3.6 dirsrv crash: ERR - valueset_value_syntax_cmp - slapi_attr_values2keys_sv failed for type lastUpdated

[William Brown]

On Sat, 2017-10-07 at 15:11 +, tda...@email.arizona.edu wrote:
> OS: CentOS Linux release 7.4.1708 (Core) 
> dirsrv: 1.3.6.1 B2017.249.1616
> 
> I've had two of these running in multi-master replication for a week now with 
> no issues, but last night they both crashed at the same time and there were a 
> lot of these just before they died:
> 
> [06/Oct/2017:22:30:41.990009449 -0700] - ERR - valueset_value_syntax_cmp - 
> slapi_attr_values2keys_sv failed for type lastUpdated
> [06/Oct/2017:22:30:41.991965822 -0700] - ERR - valueset_value_syntax_cmp - 
> slapi_attr_values2keys_sv failed for type lastUpdated
> [06/Oct/2017:22:30:41.993908534 -0700] - ERR - valueset_value_syntax_cmp - 
> slapi_attr_values2keys_sv failed for type lastUpdated
> 
> When I try to start either server now, I get the usual recovery messages and 
> then a bunch of these errors and a crash. I've checked as many things as I 
> can think of, including dse.ldif, which is fine.
> 

When the server crashes do you get a core dump or similar? That would
really help. 

I think the issue with the lastUpdated type is that this is a custom
element of your schema - I can't find any references to it at all in our
code base. Can you send me your schema definiton for this attribute? 

> Unrelated probably, but annoying, my error logs are also filling up with lots 
> of these:
> [06/Oct/2017:21:51:16.987020789 -0700] - ERR - attrlist_replace - 
> attr_replace (nsslapd-referral, 
> ldap://ldap2.arizona.edu:389/dc%3Deds%2Cdc%3Darizona%2Cdc%3Dedu) failed.


I think the error is fixed in 1.3.7 ... 

> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane



signature.asc
Description: This is a digitally signed message part
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 1.3.6 dirsrv crash: ERR - valueset_value_syntax_cmp - slapi_attr_values2keys_sv failed for type lastUpdated

[tdarby]

> On 10/09/2017 05:33 PM, tdarby(a)email.arizona.edu wrote:
> Okay the version you have has a few
> known crashes.  They have been fixed
> in 1.3.6.1-20 and up.  This fix will also be part of RHEL's 7.4 batch
> update 2.

Thanks, I don't see a way to get a higher packaged version with CentOS 7.4. I'm 
not committed to CentOS. What about switching to Fedora 26 in order to get the 
1.3.6.8 package?

Is there anything I can do about the attrlist_replace - attr_replace 
nsslapd-referral messages filling up the errors log?
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389DS console with HTTPS

[Vincent CAZAUBON]

Thanks you for your answer, now I know that it's possible.



Vincent CAZAUBON
Centre informatique - Cirti
SI-SECURITE
Architecture/intégrateur ldap


2 rue de Coulongé CS 61911 44319 NANTES Cedex 03
vincent.cazau...@urssaf.fr


Contribuons au respect de l'environnement, n'imprimez ce courriel qu'en 
cas de nécessité et ayez le réflexe recto-verso




De :Paul Robert Marino 
A : "General discussion list for the 389 Directory server project." 
<389-users@lists.fedoraproject.org>, 
Cc :Stella LE LOC'H 
Date :  10/10/2017 12:16
Objet : [389-users] Re: 389DS console with HTTPS



One more minor correction that path on windows is C 
:\windows\system32\drivers\etc\hosts

Sent from my BlackBerry - the most secure mobile device
From: prmari...@gmail.com
Sent: October 10, 2017 6:12 AM
To: 389-users@lists.fedoraproject.org
Cc: stella.lel...@urssaf.fr
Subject: Re: [389-users] 389DS console with HTTPS

Sorry spell checker on my phone did some thing going strange it replaced 
CNAME with came.
So in the alternative CNAME scenario the subject can match a CNAME in the 
DNS but that CNAME must match an A record with a matching reverse lookup 
record for the forward A record.

You can also use /etc / hosts files to work around this on Windows it's 
located in C:\windows\system32\etc


Sent from my BlackBerry - the most secure mobile device
From: prmari...@gmail.com
Sent: October 10, 2017 6:06 AM
To: 389-users@lists.fedoraproject.org
Cc: stella.lel...@urssaf.fr
Subject: Re: [389-users] 389DS console with HTTPS

This is a general SSL TLS thing.
In general the host must be resolvable Via a A record in the DNS which 
matches both a forward and reverse lookup. Alternatively you can use a 
came for the forward lookup but it must map to a A record which has a 
matching reverse lookup record to the A record the came points to.

Sent from my BlackBerry - the most secure mobile device
From: vincent.cazau...@urssaf.fr
Sent: October 10, 2017 2:54 AM
To: 389-users@lists.fedoraproject.org
Reply-to: 389-users@lists.fedoraproject.org
Cc: stella.lel...@urssaf.fr
Subject: [389-users] 389DS console with HTTPS



Hello, 

Is it possible to secure communication between my 389DS console on my 
Window7 client computer and my 389-admin server on my Centos Server ? 
I want to use HTTPS instead HTTP. 
Is there any limitation between the server's FQDN and the subject of the 
Centos HTTPS server certificate ? 

You will find below releases and versions of my main 389 components: 
Centos Linux release 7.3.1611 (Core) 
389-admin Version: 1.1.46 Release: 1.el7 
389-ds-base Version: 1.3.5.10 Release 15.el7_3 
389-admin-console Version 1.1.12 Release 1.el7 
389-console Version 1.1.18 Release 1.el7 
389 Management Console on Windows 7: Console Framework  1.1.14 
Best regards, 



Vincent CAZAUBON
Centre informatique - Cirti
SI-SECURITE
Architecture/intégrateur ldap 



2 rue de Coulongé CS 61911 44319 NANTES Cedex 03
vincent.cazau...@urssaf.fr




Contribuons au respect de l'environnement, n'imprimez ce courriel qu'en 
cas de nécessité et ayez le réflexe recto-verso



___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389DS console with HTTPS

[Paul Robert Marino]

  One more minor correction that path on windows is C :\windows\system32\drivers\etc\hostsSent from my BlackBerry - the most secure mobile deviceFrom: prmari...@gmail.comSent: October 10, 2017 6:12 AMTo: 389-users@lists.fedoraproject.orgCc: stella.lel...@urssaf.frSubject: Re: [389-users] 389DS console with HTTPSSorry spell checker on my phone did some thing going strange it replaced CNAME with came.So in the alternative CNAME scenario the subject can match a CNAME in the DNS but that CNAME must match an A record with a matching reverse lookup record for the forward A record.You can also use /etc / hosts files to work around this on Windows it's located in C:\windows\system32\etc Sent from my BlackBerry - the most secure mobile device   From:  prmari...@gmail.comSent: October 10, 2017 6:06 AMTo:  389-users@lists.fedoraproject.orgCc:  stella.lel...@urssaf.frSubject: Re: [389-users] 389DS console with HTTPSThis is a general SSL TLS thing.In general the host must be resolvable Via a A record in the DNS which matches both a forward and reverse lookup. Alternatively you can use a came for the forward lookup but it must map to a A record which has a matching reverse lookup record to the A record the came points to.Sent from my BlackBerry - the most secure mobile device   From:  vincent.cazau...@urssaf.frSent: October 10, 2017 2:54 AMTo:  389-users@lists.fedoraproject.orgReply-to:  389-users@lists.fedoraproject.orgCc:  stella.lel...@urssaf.frSubject: [389-users] 389DS console with HTTPS  

Hello,

Is it possible to secure communication
between my 389DS console on my Window7 client computer and my 389-admin
server on my Centos Server ?
I want to use HTTPS instead HTTP.
Is there any limitation between the
server's FQDN and the subject of the Centos HTTPS server certificate
?

You will find below releases and versions
of my main 389 components:

Centos Linux release 7.3.1611 (Core)
389-admin Version: 1.1.46 Release: 1.el7
389-ds-base Version: 1.3.5.10 Release
15.el7_3
389-admin-console Version 1.1.12 Release
1.el7
389-console Version 1.1.18 Release 1.el7
389 Management Console on Windows 7:
Console Framework  1.1.14
Best regards,




Vincent
CAZAUBON
Centre informatique - Cirti
SI-SECURITE
Architecture/intégrateur ldap


2 rue de Coulongé
CS 61911 44319 NANTES Cedex 03
vincent.cazau...@urssaf.fr


Contribuons au respect de
l'environnement, n'imprimez ce courriel qu'en cas de nécessité et ayez
le réflexe recto-verso
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389DS console with HTTPS

[Paul Robert Marino]

  Sorry spell checker on my phone did some thing going strange it replaced CNAME with came.So in the alternative CNAME scenario the subject can match a CNAME in the DNS but that CNAME must match an A record with a matching reverse lookup record for the forward A record.You can also use /etc / hosts files to work around this on Windows it's located in C:\windows\system32\etc Sent from my BlackBerry - the most secure mobile deviceFrom: prmari...@gmail.comSent: October 10, 2017 6:06 AMTo: 389-users@lists.fedoraproject.orgCc: stella.lel...@urssaf.frSubject: Re: [389-users] 389DS console with HTTPSThis is a general SSL TLS thing.In general the host must be resolvable Via a A record in the DNS which matches both a forward and reverse lookup. Alternatively you can use a came for the forward lookup but it must map to a A record which has a matching reverse lookup record to the A record the came points to.Sent from my BlackBerry - the most secure mobile device   From:  vincent.cazau...@urssaf.frSent: October 10, 2017 2:54 AMTo:  389-users@lists.fedoraproject.orgReply-to:  389-users@lists.fedoraproject.orgCc:  stella.lel...@urssaf.frSubject: [389-users] 389DS console with HTTPS  

Hello,

Is it possible to secure communication
between my 389DS console on my Window7 client computer and my 389-admin
server on my Centos Server ?
I want to use HTTPS instead HTTP.
Is there any limitation between the
server's FQDN and the subject of the Centos HTTPS server certificate
?

You will find below releases and versions
of my main 389 components:

Centos Linux release 7.3.1611 (Core)
389-admin Version: 1.1.46 Release: 1.el7
389-ds-base Version: 1.3.5.10 Release
15.el7_3
389-admin-console Version 1.1.12 Release
1.el7
389-console Version 1.1.18 Release 1.el7
389 Management Console on Windows 7:
Console Framework  1.1.14
Best regards,




Vincent
CAZAUBON
Centre informatique - Cirti
SI-SECURITE
Architecture/intégrateur ldap


2 rue de Coulongé
CS 61911 44319 NANTES Cedex 03
vincent.cazau...@urssaf.fr


Contribuons au respect de
l'environnement, n'imprimez ce courriel qu'en cas de nécessité et ayez
le réflexe recto-verso
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: 389DS console with HTTPS

[Paul Robert Marino]

  This is a general SSL TLS thing.In general the host must be resolvable Via a A record in the DNS which matches both a forward and reverse lookup. Alternatively you can use a came for the forward lookup but it must map to a A record which has a matching reverse lookup record to the A record the came points to.Sent from my BlackBerry - the most secure mobile deviceFrom: vincent.cazau...@urssaf.frSent: October 10, 2017 2:54 AMTo: 389-users@lists.fedoraproject.orgReply-to: 389-users@lists.fedoraproject.orgCc: stella.lel...@urssaf.frSubject: [389-users] 389DS console with HTTPS  

Hello,

Is it possible to secure communication
between my 389DS console on my Window7 client computer and my 389-admin
server on my Centos Server ?
I want to use HTTPS instead HTTP.
Is there any limitation between the
server's FQDN and the subject of the Centos HTTPS server certificate
?

You will find below releases and versions
of my main 389 components:

Centos Linux release 7.3.1611 (Core)
389-admin Version: 1.1.46 Release: 1.el7
389-ds-base Version: 1.3.5.10 Release
15.el7_3
389-admin-console Version 1.1.12 Release
1.el7
389-console Version 1.1.18 Release 1.el7
389 Management Console on Windows 7:
Console Framework  1.1.14
Best regards,




Vincent
CAZAUBON
Centre informatique - Cirti
SI-SECURITE
Architecture/intégrateur ldap


2 rue de Coulongé
CS 61911 44319 NANTES Cedex 03
vincent.cazau...@urssaf.fr


Contribuons au respect de
l'environnement, n'imprimez ce courriel qu'en cas de nécessité et ayez
le réflexe recto-verso
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] 389DS console with HTTPS

[Vincent CAZAUBON]

Hello,

Is it possible to secure communication between my 389DS console on my 
Window7 client computer and my 389-admin server on my Centos Server ?
I want to use HTTPS instead HTTP.
Is there any limitation between the server's FQDN and the subject of the 
Centos HTTPS server certificate ?

You will find below releases and versions of my main 389 components:

Centos Linux release 7.3.1611 (Core)
389-admin Version: 1.1.46 Release: 1.el7
389-ds-base Version: 1.3.5.10 Release 15.el7_3
389-admin-console Version 1.1.12 Release 1.el7
389-console Version 1.1.18 Release 1.el7
389 Management Console on Windows 7: Console Framework  1.1.14

Best regards,




Vincent CAZAUBON
Centre informatique - Cirti
SI-SECURITE
Architecture/intégrateur ldap


2 rue de Coulongé CS 61911 44319 NANTES Cedex 03
vincent.cazau...@urssaf.fr


Contribuons au respect de l'environnement, n'imprimez ce courriel qu'en 
cas de nécessité et ayez le réflexe recto-verso
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org