Using dsctl and .dscrc: How to properly connect to a remote instance?
by Johannes Kastl
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)
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.
Any hints are welcome!
Kind Regards,
Johannes
--
Johannes Kastl
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
Mail: kastl(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
http://www.b1-systems.de
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
1 year
389ds container images and tags
by Johannes Kastl
Hi all,
I am in the process of rewriting my helm chart for 389ds (stay tuned, I'll send
another mail once it is ready), and noticed the lack of recent tags for the
container images:
https://hub.docker.com/r/389ds/dirsrv only has 2.1, 2.2 and latest. 2.2 and
latest are 8 months old.
https://quay.io/repository/389ds/dirsrv?tab=tags only has latest and c9s without
any version tags (or I did not find them?).
Would it be possible to publish the tags more often? And maybe publish all patch
versions (2.2.1, 2.2.6, ...) in addition?
Using "latest" or "stable" is not a good idea for container workloads, as it
does not allow rollbacks in case of errors or changed behaviour. Rolling back is
easy using helm charts, but only if the image can be changed back from say 2.2.6
to 2.2.5 by helm. When using stable or 2.2 or similar, the new image will be
fetched and the old one discarded, so it will be lost and no longer usable.
Having usable tags would really be helpful, so I would be happy if this could be
done.
Have a nice day, everyone!
Kind Regards,
Johannes
--
Johannes Kastl
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
Mail: kastl(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
http://www.b1-systems.de
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
1 year
Helm chart for 389ds
by Johannes Kastl
Hi all,
I finally had some time to rework my helm chart for 389ds. It seems to be in a
working state, so if anyone is interested I would be glad to have some testers.
Please be aware that this is the first version, use at your own risk and proceed
with caution. Here be dragons...
That said, it works for me, I get a working pod that I can interact with using
ldapsearch/ldapadd/... and dsidm. (dsctl does not work for $REASONS, see my
earlier mail).
> https://github.com/johanneskastl/helm-charts/blob/main/charts/389ds/READM...
This chart might be opinionated, as I tailored it to my needs (e.g. using a
Let's encrypt TLS certificate, ...).
By default, it creates a service of type Loadbalancer with ports 389 and 636
(TCP). It uses the TLS certificate from a Kubernetes secret and the CA
certificate from a configMap that is created automatically. The README has the
full details and explanations.
It is currently based on the 2.2 image from dockerhub due to the missing tags,
see my other earlier mail. :-)
Please feel free to point out any errors or improvements. I cannot promise to
integrate each and every request, but I'll do my best.
Kind Regards,
Johannes
--
Johannes Kastl
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
Mail: kastl(a)b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
http://www.b1-systems.de
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537
1 year
ACME certificate and NSS databases
by John Thurston
We currently use publicly-signed, and manually renewed, certificates on
our internal directory servers. On other internal and external systems,
we use public and private certificates handled by ACME-compliant agents.
I took a quick look, and was reminded that 389-Directory keeps its certs
in an NSS database. Before I go hack together my own wrapper on
certutil, I thought I'd ask:
Does anyone have a working ACME/Let's Encrypt agent they want to share?
--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston(a)alaska.gov
Department of Administration
State of Alaska
1 year
