> On 18 Apr 2020, at 02:42, Mark Reynolds <[email protected]> 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 -- [email protected]
>> To unsubscribe send an email to [email protected]
>> 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/[email protected]
>
> --
>
> 389 Directory Server Development Team
> _______________________________________________
> 389-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
