> On 18 Apr 2023, at 16:37, Johannes Kastl <kastl@xxxxxxxxxxxxx> 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@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
