So finally got some time for a code review for you :) This plugin seems pretty simple - and pretty specific to your needs. But it’s a good example of a place to start in 389 development.
Something I’d love to see is a way for you to compile and test this with ASAN - it’s a dynamic analysis tool that checks for mis-use of memory in C, which is a huge benefit to preventing many types of common attacks and crashes. As some little things: in void hashit, you use “int i=0” then “for (i; …)” in the loop with an array. In C, size_t is the correct indexing to array type, and this project uses C99, so you can do: for (size_t i = 0; thing[i]; …) This prevents re-use of I in other loops, and matters more in larger functions. You probably don’t need the _win32 defines, we haven’t build on windows in a long time :) try to use int32_t, not int. C defines int as a “type that holds at least 16 bits” (I think), and it’s only modern assumptions that it’s 32 that changed that. long is technically the “32bit minimum” type, and “long long” is 64. But in the slapi headers we pull in inttypes.h, so we recommend “int<width>_t”. Specific is always good. Do you use the hashit function anywhere? With this in mind, perhaps it’s worth investing in making a “cos replacement” that instead of using virtual attributes, writes the data the entries themself? Additionally, allowing formatting/templating? I think that would solve your use case (except you want hashing/scripting, which may be out of scope …). > On 20 Feb 2019, at 10:17, Olivier JUDITH <gnu...@gmail.com> wrote: > > Sorry , i forgot my makefile > To be honest i use the exemple provided in the documentation . > For testing, i've deployed the compiled plugin on my local instance > # Makefile for Directory Server plug-in examples > # > CC = gcc > LD = gcc > CFLAGS = -fPIC -I /usr/include/nspr4 -Wall > LDFLAGS = -shared -z defs -L/usr/lib64/dirsrv -lslapd > OBJS = mycodesaslbind.o mycodeextendedop.o mycodepreop.o mycodepostop.o > mycodeentry.o > all: mycode-plugin.so > libtest-plugin.so: $(OBJS) > $(LD) $(LDFLAGS) -o $@ $(OBJS) > .c.o: > $(CC) $(CFLAGS) -c $< > clean: > -rm -f $(OBJS) mycode-plugin.so > > Le mer. 20 févr. 2019 à 01:04, William Brown <wbr...@suse.de> a écrit : > > > > On 20 Feb 2019, at 09:56, Olivier JUDITH <gnu...@gmail.com> wrote: > > > > Hi William > > > > It's a simple testing code not finished yet but i think it could help > > beginners like me > > Don't be cruel with me i'm not a C progorammer. > > We do our best here to be constructive and helpful, not cruel. Thanks for > providing your code! I’ll review it and give feedback if you would like, > > > The goal here is to create 4 new attributes aCode, bCode, > > aCodeHas,bCodeHash everytime a new entry is added. > > A step to add is how to filter by kind of entry or by DN . > > Great! > > When you were compiling it, what steps did you take? How did you perform > testing? > > Thanks :) > > > > > Le lun. 18 févr. 2019 à 02:26, William Brown <wbr...@suse.de> a écrit : > > Yeah, I don’t think cos can do templating. > > > > If you would be willing Oliver, would you submit your code to the project, > > and allow it to be made generic? That could help quite a few people out > > with similar queries. > > > > > On 17 Feb 2019, at 00:20, Olivier JUDITH <gnu...@gmail.com> wrote: > > > > > > Hi , > > > > > > There is a way to add attribute to user entry automatically called CoS . > > > You can take a look on this link > > > https://access.redhat.com/documwanentation/en-us/red_hat_directory_server/9.0/html/administration_guide/advanced_entry_management-assigning_class_of_service > > > > > > But afaik you cannot add an email based on the uid except if CoS support > > > macros like ACI. To do that you have to create your own plugin see > > > :https://access.redhat.com/documentation/en-us/red_hat_directory_server/9.0/html/plug-in_guide/ > > > I did the same for another kind of attribute. > > > It works fine for me > > > > > > > > > Le sam. 16 févr. 2019 à 14:29, Rosario Esposito > > > <rosario.espos...@na.infn.it> a écrit : > > > > > > Hello, > > > let's say whenever I create a new entry: > > > > > > uid=myuser,ou=people,dc=example,dc=com > > > > > > I would like this entry to have the attribute: > > > > > > mail: myu...@example.com > > > > > > (i.e. the value of 'mail' should be automatically set to the value of > > > 'uid' + '@example.com') > > > > > > Is there a way for 389ds to do this task automatically ? > > > > > > > > > Thanks, > > > -- > > > Rosario Esposito > > > System Administrator > > > INFN - Napoli > > > Phone: +39 081 676170 > > > Email: rosario.espos...@na.infn.it > > > _______________________________________________ > > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > > _______________________________________________ > > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > > > — > > Sincerely, > > > > William Brown > > Software Engineer, 389 Directory Server > > SUSE Labs > > _______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > <mycode.c>_______________________________________________ > > 389-users mailing list -- 389-users@lists.fedoraproject.org > > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > > — > Sincerely, > > William Brown > Software Engineer, 389 Directory Server > SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org — Sincerely, William Brown Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
