> On 18 Apr 2023, at 16:37, Johannes Kastl <kastl@b1-systems.de> wrote:
>
> Hi all,
>
> sorry if this is a dumb one, but I am not getting dsctl working with a remote instance running in Kubernetes. In fact, I am not getting it to read the .dscrc file at all, it seems.
>
> In my user's home directory I have this ~/.dsrc (copied and adapted from the Getting started guide):
>
> [ldap389]
> uri = ldap://192.168.99.165
> basedn = dc=example,dc=de
> binddn = cn=Directory Manager
>
> But when calling "/usr/sbin/dsctl ldap389 status" it says it cannot find the instance information.
>
> $ /usr/sbin/dsctl ldap389 status
> No such instance 'ldap389'
> Unable to access instance information. Are you running as the correct user? (usually dirsrv or root)
dsctl requires root/dirsrv because it assumes you are on the same host as the dirsrv instance. There are three commands:
dsctl - requires root/dirsrv, and tries to manipulate an instance directly via local system actions, things like dse.ldif and ldapi. It bypasses the uri provided, it's trying to "manage the system".
dsconf - required cn=Directory Manager and connects via the ldap uri.
dsidm - requires a bind dn with no aci's or limited write aci's in a backend and connects via ldap uri.
So when you are running remotely you *can not* use dsctl to manage a remote instance - only dsconf and dsidm can do this.
dsctl must be run as root/dirsrv on the same host or inside the container of the instance.
>
> So I copied the file to /root/.dsrc and executed the command as root: Same error.
>
> I am guessing it does not find the file, so I tried to use the "dsctl dsrc" command, but I think this is broken. It does not accept anything without an instance argument, although the manpage says to call it as "dscl dsrc ..."
>
>> $ sudo /usr/sbin/dsctl dsrc display
>> usage: dsctl [-h] [-v] [-j] [-l]
>> [instance] {restart,start,stop,status,remove,db2index,db2bak,db2ldif,dbverify,bak2db,ldif2db,backups,ldifs,tls,healthcheck,get-nsstate,ldifgen,dsrc,cockpit,dblib} ...
>> dsctl: error: argument {restart,start,stop,status,remove,db2index,db2bak,db2ldif,dbverify,bak2db,ldif2db,backups,ldifs,tls,healthcheck,get-nsstate,ldifgen,dsrc,cockpit,dblib}: invalid choice: 'display' (choose from 'restart', 'start', 'stop', 'status', 'remove', 'db2index', 'db2bak', 'db2ldif', 'dbverify', 'bak2db', 'ldif2db', 'backups', 'ldifs', 'tls', 'healthcheck', 'get-nsstate', 'ldifgen', 'dsrc', 'cockpit', 'dblib')
>
> When calling it with an instance I am back to the "No such instance" error I had previously.
>
> OS is openSUSE Tumbleweed, package version is lib389-2.3.2~git53.a01e230-1.1.x86_64.
--
Sincerely,
William Brown
Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@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.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
No comments:
Post a Comment