> On 18 Apr 2020, at 02:42, Mark Reynolds <mreynolds@xxxxxxxxxx> wrote:
>
> Each section [] refers to an instance on your local system. For example I have an instance named localhost. It can be found on the FS under /etc/disrv/slapd-locahost, but I could have named the instance anything, like: slapd-MARK (/etc/dirsrv/slapd-MARK). In the second case I would use the CLI as follows:
>
> # dsidm MARK user list (You can optionally use the "slapd-" prefix for clarity: dsidm slapd-MARK user list)
>
> So in my .dsrc file I would need a section like:
>
> [MARK]
> uri: ldapi://%%2fvar%%2frun%%2fslapd-MARK.socket
> ...
>
>
> So each section describes a local instance. I'm not sure you can create different profiles like what you are doing below. William knows the .dsrc stuff better than I do though so he might have additional comments when he gets online.
I feel like this is some kind of elder curse where you summon an ldap person to reveal their knowledge ...
Anyway, yes, you can have multiple sections. dsrc uses the python ini config parser, so you can do this. The only "gotcha" is the section config section "[DEFAULT]" acts as a template section and overlays into all others, so you could do:
[DEFAULT]
tls_cacertdir = /some/ca/dir
[inst]
uri =
[otherinst]
uri =
Then both would inherit the tls_cacertdir.
>
> Note - I'm not sure what version you are, but in older versions the section name must match how to type it on the CLI. So if .dsrc contains [MARK], then you MUST use: "dsidm MARK ...". If you defined the section name as [slapd-MARK] in .dsrc, then you must use: "dsidm slapd-MARK ...". This has been fixed in newer versions where you can interchange the "slapd-" anyway you want and it will still find the correct section in .dsrc.
It was fixed in 1.4.1 cycle, so Clay should have this as they are on suse with 1.4.2.x I think.
>
> HTH,
> Mark
>
> On 4/17/20 12:27 PM, Clayvahn Hunt wrote:
>> Also, W. Brown gave me this hint:
>> "There can be many sections in the dsrc though, and they can be named differently to your instances if you want. I wrote most of that code so I can explain further if you want. But you could do something like:
>>
>> [localhost]
>> uri = ldapi://%%2fvar%%2frun%%2fslapd-localhost.socket
>>
>> [localhost-ldaps]
>> uri =
>> ldaps://localhost
>> "
>>
>> I have done this (see other entries here) - but after reading this *many, many times* I do have a question. The suggestion (at least to me) suggests that I'd need multiple instances ("named differently to your instances if you want") - so that means I'd have more than one LDAP instance - one that I'd administer locally ([localhost] via ldapi) and one instance ([localhost-ldaps]) that I'd administer via ldaps. How would I ensure both instances used the same database? I don't want to have to create more work for myself.
>>
>> Can anyone offer any clarification of how I might make this configuration work with least headache?
It's not multiple instances, in dsrc you are defining connections to an instance.
So at my house I have my ldap (of course ....) . On the server to administer it I have:
[localhost]
uri = ldapi://%%2fdata%%2frun%%2fslapd-localhost.socket
binddn = cn=Directory Manager
basedn = dc=blackhats,dc=net,dc=au
Where as on my machine to remote administer the instance I have:
[idm]
uri = ldaps://idm.blackhats.net.au
binddn = cn=Directory Manager
basedn = dc=blackhats,dc=net,dc=au
There is still only "one ldap server" and "one database" but just different ways to connect. The first one is as root on the local machine and ldapi allows me to autobind as cn=directory manager. The latter lets me auth with a password for remote admin etc. It wouldn't matter if these are in the same .dsrc.
dsrc is about defining how you connect to an instance - not about what instances exist or what databases exist in them.
The definitive list of "instance" on a machine is simply found by this effective algorithm:
sudo ls -al /etc/dirsrv/slapd-*/dse.ldif
>>
>> Thanks in advance
>>
>>
>> _______________________________________________
>> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>
> --
>
> 389 Directory Server Development Team
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
