[389-users] Re: Admin Gateway over https

[William Brown]

On Thu, 2018-03-08 at 05:26 +, Eric Wheeler wrote:
> Thanks for the confirmation regarding secure connections and the
> clarification regarding dsgw. I will focus on other alternatives. I
> would be interested in exploring cli tools and the API. Any resources
> to which you could point me would be appreciated. Thanks for the
> help.


Sorry for the very late reply,

The new cli tools with 1.4.x are explained here:

http://www.port389.org/docs/389ds/design/dsadm-dsconf.html

These are a thin wrapper on our python library which has documentation
(and I wish I could rememeber where it is >.>)

There is a lot of example code, and I would be happy to help you get
some working demos going, and explain how it all works if you want to
pursue this further.

Thanks! 


> > -Original message-
> > From: William Brown
> > Sent: Wednesday, March 7 2018, 1:47 pm
> > To: General discussion list for the 389 Directory server project.
> > Subject: [389-users] Re: Admin Gateway over https
> >  
> > On Wed, 2018-03-07 at 01:18 +, Eric Wheeler wrote:
> > > How does one properly configure the Directory Server Gateway to
> > run
> > > over https? Is such a setup necessary for secure connections if
> > ldaps
> > > over 636 is active?
> > 
> > Yes, because you have:
> > 
> > client -> https -> ldaps
> > 
> > So you have to protect each stage of the communication.
> > 
> > >  I edited dsgw-httpd.conf until I was able to connect to the
> > gateway
> > > via https, but the setup was pretty buggy. Afterwards, I came
> > across
> > > a page in the documentation stating this file shouldn’t be
> > touched.
> > > 
> > > My goal is to use the DS Gateway to edit the directory using
> > secure
> > > connections without resorting to other tools such as phpLDAPadmin
> > > which I’ve read is really designed for OpenLDAP.
> > 
> > While I understand your desire, the dsgw software hasn't been
> > touched
> > by us in a long time - and I highly suspect it won't be supported
> > for
> > much longer. Sadly though, as far as a "web tool" we've had some
> > delays
> > building this up but it is on the way!
> > 
> > Instead for 1.4.x we plan to release better cli tools with much
> > more
> > functionality that should be able to do everything you want. 
> > 
> > If you want to know more about these tools and our API for server
> > interaction, I'm happy to provide you resources about this to help
> > you
> > and get it fit for your requirements,
> > 
> > Hope that helps,
> > 
> > 
> > > ___
> > > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > > To unsubscribe send an email to 389-users-leave@lists.fedoraproje
> > ct.o
> > > rg
> > ___
> > 389-users mailing list -- 389-users@lists.fedoraproject.org
> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject
> > .org
-- 
Thanks,

William Brown
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: How to containerize 389DS using Docker in production systems

[William Brown]

On Thu, 2018-03-08 at 12:24 +0100, Alberto García Sola wrote:
> It's great knowing you are getting a proper container support.
> Reading your message, I've found this docker folder withing the
> source that I hadn't seen yet: https://pagure.io/389-ds-
> base/blob/master/f/docker , with same examples of how to use it
> beyond the demo.

Great, I would love to hear your feedback on this. 

> Thank you for the great explanation regarding the situation. 
> I'll try to report back any issues we find using Docker from the
> current MASTER branch, though there are two (IMHO) big stoppers to
> get this into production:
> The persistance part (https://pagure.io/389-ds-base/issue/49213).

It's a bit more subtle I think. You can build the image and it creates
a /etc/dirsrv/slapd-localhost. BUT if you want persistance you have to
overlap volumes ONTO /etc/dirsrv/slapd-localhost AND
/var/lib/disrv/slapd-localhost.

The issue then is ns-slapd starts and sees empty folders! So suddenly
it won't start.

If you can extract a /etc/dirsrv/slapd-localhost *AND* a
/var/lib/dirsrv/slapd-localhost into these places and then bind mount
them, you will have persistence! It's just not a friendly user
experience today, and I want it to be as simple as:

docker run -v  389ds:latest

And you get persistence without messing about. 

> The upgrade part, which is an essential part of the containers
> philosophy, though not such a big stopper as the previous one.

This just needs some polish, but this ticket I kind of forgot about
shows we have some mechanisms in place that can provide upgrade support
already, so I think it's 90% there:

https://pagure.io/389-ds-base/issue/49447

The other patch provides attribute level "upgrade" support, not just
"ensure these entries exists" support.

> I guess it would be difficult to say, but do you manage any ETAs?

Sorry, I don't have an ETA. There are three major goals for me in the
coming weeks:

* Finish up work on connection system cleanup
* Improve and finish work on our new cli tools (read more here: http://
www.port389.org/docs/389ds/design/dsadm-dsconf.html)
* Container support

Probably in that order.

So I can't give an ETA, but I'll be sure to post updates to 389-users
and requests for comment when I have more substantial work complete :)

I'm still also thinking about scripting of the server and how to manage
this, so I'm thinking about ideas which again I'll post design
documents and ask for feedback. 

Hope that helps,


> Alberto.
> 
> El 08/03/2018 a las 4:42, William Brown escribió:
> > On Wed, 2018-03-07 at 23:50 +, tda...@email.arizona.edu wrote:
> > > > On Wed, 2018-03-07 at 08:52 +0100, Alberto García Sola wrote:
> > > > 
> > > > Hi there,
> > > > 
> > > > I'm currently working on docker support in 389-ds.
> > > 
> > > William, I'm really glad to hear this. We've been running 389
> > > server
> > > in docker in EC2 instances for months now and it works great. We
> > > have
> > > home grown scripts for automating the DS installation and
> > > replication
> > > between 2 DS instances, but it would be awesome to use a
> > > supported
> > > setup instead, so I'd really like to try what you have. Our setup
> > > uses mounted EBS volumes that contain all the necessary DS
> > > folders so
> > > that the EC2s can be blown away and recreated any time we want.
> > 
> > Hope you don't mind, but this is a bit of a brain dump. we have
> > some
> > open tickets about this. Currently we have LOADS of support here
> > for
> > containers, like detection of container memory and process limits,
> > support for containerised installs in dscreate, and more.
> > 
> > But first I want to describe the general picture and situation.
> > 
> > It would be great to have a temporary demo instance like:
> > 
> > docker run 389ds:1.4.0
> > 
> > And that *works*.
> > 
> > Now, when you want to really use it in production something more
> > like:
> > 
> > docker run -v /etc/dirsrv:/etc/dirsrv -v
> > /var/lib/dirsrv:/var/lib/dirsrv 389ds:1.4.0
> > 
> > And now you have persistance, and can pull, upgrade, destroy,
> > everything.
> > 
> > If you want a readonly ephemeral replica, something maybe like:
> > 
> > docker run -e replication_manager=12345 389ds:1.4.0
> > 
> > Which would trigger the replica ID to become 65535 and set the
> > replication manager password (which could now be pushed to from
> > another
> > instance).
> > 
> > So what are the challenges to these scenarios? 
> > 
> > Well, the first scenario "kinda works" today, but you don't get
> > persistence, and we have to ship a known password. The barrier here
> > is
> > that ns-slapd (our server binary) needs assistance from
> > dscreate/setup-
> > ds.pl to create dse.ldif and it's related instance parts.
> > 
> > So we need to move the *SETUP* logic of DS out of python and INTO
> > an
> > early runtime part of ns-slapd, to be able to process a .inf +
> > envvariables to create dse.ldif on startup if it does not exist.
> > 
> > Thankfully 

[389-users] Re: help building test-plugin

[William Brown]

On Thu, 2018-03-08 at 14:32 -0500, Harvey, Robert wrote:
> I'm hoping that someone can help me find out why my pre-bind plugin
> clauses ns-slapd to crash when the slapi_search_internal_get_entry
> function is called. What I'm seeing is that after starting ns-slapd,
> the plugin will crash slapd consistently or it will work
> consistently. This is with the same plugin in place and with the same
> user. So after some restarts the plugin crashes the slapd and after
> other starts I can bind and unbind with the same account dozens of
> times successfully.  

Hi there.

As a general development rule, I would strongly advise you enable the
ASAN build functions, as this will help you find data corruptions and
crashes *at the source* rather then when they flow through the
application. 

Another general question is "what do you want to achieve" with your
plugin? What's the purpose of it? 

> 
>  
> 
> This what I have installed:
> 
> [root@njbbldapp21 ~]# rpm -qa | grep 389
> 389-ds-base-libs-1.3.6.1-26.el7_4.x86_64
> 389-dsgw-1.1.11-5.el7.x86_64
> 389-console-1.1.18-1.el7.noarch
> 389-adminutil-1.1.21-2.el7.x86_64
> 389-admin-console-1.1.12-1.el7.noarch
> 389-ds-console-1.2.16-1.el7.noarch
> 389-ds-console-doc-1.2.16-1.el7.noarch
> 389-ds-1.2.2-6.el7.noarch
> 389-ds-base-1.3.6.1-26.el7_4.x86_64
> 389-ds-base-devel-1.3.6.1-26.el7_4.x86_64
> 389-admin-console-doc-1.1.12-1.el7.noarch
> 389-admin-1.1.46-1.el7.x86_64
> 
> Here's my Makefile:
> 
> CC = gcc
> LD = ld 
> 
> INCLUDE_FLAGS = -I /usr/lib64/dirsrv/plugins -I
> /opt/adminhome/aharvero/slap/389-ds-base-1.4.0.5/ldap/servers/slapd
> -I /usr/include/nspr4  -I /opt/adminhome/aharvero/slap/389-ds-base-
> 1.4.0.5/ldap/include  
> 
> #CFLAGS = $(INCLUDE_FLAGS) -D_REENTRANT -fPIC -z defs -shared
> CFLAGS = $(INCLUDE_FLAGS) -D_REENTRANT -fPIC -z defs -shared 
> -lsladpd -ltcmalloc -lldap_r -llber -lsasl2 -l svrcore -lssl3 -l nss3
> -lkrb5 -l k5crypto -lcom_err -lpcre -lpthread -lsystemd -l plc4 -l
> plds4 -lc
> #LDFLAGS = -G 
> 
> LDFLAGS = -G -fPIC -z defs -shared -lc -l:libplc4.so
> -l:libslapd.so.0.1.0 -l:libldap_r-2.4.so.2 -l:liblber-2.4.so.2 -L
> /usr/lib64/dirsrv -L /lib64
> 
> OBJS =  mybind.o 
> 
> all: libmybind-plugin.so
> 
> 
> libmybind-plugin.so: $(OBJS)
> $(LD) $(LDFLAGS) -o $@ $(OBJS)
> 
> .c.o:
> $(CC) $(CFLAGS) -c $<
> 
> clean:
> -rm -f $(OBJS) libmybind-plugin.so
> 
> 
> Here's the plugin:
> 
> 
> $ cat mybind.c
> 
> #ifdef HAVE_CONFIG_H
> #include 
> #endif
> 
> /
>  mybind.c
> 
>  This source file provides an example of a pre-operation plug-in
>  function that handles authentication.
> 
>  dn: cn=mybind,cn=plugins,cn=config
>  objectClass: top
>  objectClass: nsSlapdPlugin
>  objectClass: extensibleObject
>  cn: mybind
>  nsslapd-pluginPath: libmybind-plugin
>  nsslapd-pluginInitfunc: mybind_init
>  nsslapd-pluginType: preoperation
>  nsslapd-pluginEnabled: on
>  nsslapd-plugin-depends-on-type: database
>  nsslapd-pluginId: mybind
> 
>  /
> 
> /* #include  */
> #include 
> #include 
> #include "slapi-plugin.h"
> 
> #define VENDOR "myco"
> #define DS_PACKAGE_VERSION "1.1.1.1"
> #define MYPLUGINID "mybind"
> 
> #define CALLBACK_OK 0
> #define CALLBACK_ERR -1

Try using an enum rather than #defines so that the complier type
checker can assist you. 

> 
> static void *plugin_id = NULL;
> 
> #include "slapi-private.h"

You probably want slapi-plugin.h unless you have something you NEED
from private because this could change (we don't make api guarantees
about it).

> #include 

Try to avoid the NSPR str functions as they are slower than the glibc
counterparts, and we want to move away from nspr overtime. 

> 
> static Slapi_PluginDesc bindpdesc = { MYPLUGINID, VENDOR,
> DS_PACKAGE_VERSION,
> "mybind control plugin" };
> 
> /* Pre-operation plug-in function */
> int
> test_bind(Slapi_PBlock *pb)
> {
> char *dn , *attrs[2] = {SLAPI_USERPWD_ATTR, NULL};

Try and avoid this syntax, using instead

char *dn = NULL; 
char *attrs[2] = {SLAPI_USERPWD_ATTR, NULL};

> const char *mydn;
> int method, rc = LDAP_SUCCESS;

Try to use int32_t rather than int because int is an undefined size.

> struct berval *credentials;
> struct berval **pwvals;
> Slapi_DN *sdn = NULL;
> Slapi_Entry *e = NULL;
> Slapi_Attr *attr = NULL;
> 
> Slapi_Value *sv_creds = NULL;
> 
> /* Log a message to the server error log. */
> slapi_log_error(SLAPI_LOG_PLUGIN, MYPLUGINID ,
>   "Pre-operation bind function called.\n");
> /* Gets parameters available when processing an LDAP bind
>operation. */
> if (slapi_pblock_get(pb, SLAPI_BIND_TARGET, ) != 0 ||
> slapi_pblock_get(pb, SLAPI_BIND_METHOD, ) != 0 ||
>  slapi_pblock_get(pb, SLAPI_BIND_CREDENTIALS, )
> != 0) {
>   slapi_log_error(SLAPI_LOG_PLUGIN, MYPLUGINID,
>   

[389-users] Re: Configuring single-master replication from the cli

[William Brown]

On Fri, 2018-03-09 at 17:27 +0100, Julian Kippels wrote:
> Am Fri, 09 Mar 2018 17:23:39 +0100
> schrieb Ludwig Krispenz :
> 
> > did you look into chapter 15.2:  Configuring Replication from the 
> > Command Line ?
> > 
> 
> Somehow I feel incredibly stupid right now…

Not at all! I always feel stupid configuring replication, and I help
develop the server ... There are no stupid questions, and we want to
help you configure your server. (And hearing this reminds me that the
work we are doing on tools to improve admin experience is important!)

So generally our documentation is really good, as Ludwig has referred
you to. I think first you should try and understand conceptually how
replication works between servers, then we can discuss specifics of the
configuration elements.

So please ask any questions you have, and we'll be happy to help you.

Thanks! 

> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.o
> rg
-- 
Thanks,

William Brown
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org