Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Ehmanns <universeii@gmx.de>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] openldap: add support to build the server
Date: Fri, 12 Feb 2016 10:26:40 +0100	[thread overview]
Message-ID: <56BDA550.6030606@gmx.de> (raw)
In-Reply-To: <56A20B5E.3040206@gmx.de>

Dear all,
can someone please advise me how to continue with this patch?

Regards,
Andreas


Am 22.01.2016 um 11:58 schrieb Andreas Ehmanns:
> Thomas,
> slapd writes the PID file to the location defined in 
> /etc/openldap/slapd.conf
>
> The configuration file defines "pidfile" as 
> /var/run/openldap/slapd.pid. Maybe we have different conf files when 
> we build the rootfs?
> I had a look at a previous build without the new patch of the 
> openldap.mk (where we delete unused files now).
> Without this new feature you find two files in /etc/openldap:
>   - slapd.conf with 644 permissions and pidfile defined as 
> /var/run/openldap/slapd.pid
>   - slapd.conf.default with 600 permission and pidfile defined as 
> /var/run/slapd.pid
> It seems that in your builds you have slapd.conf.default as conf file 
> and in my builds I have slapd.conf used by slapd.
>
> How could that happen?
>
> Regards,
> Andreas
>
>
> Am 22.01.2016 um 11:03 schrieb Thomas Petazzoni:
>> Andreas,
>>
>> On Fri, 22 Jan 2016 10:50:59 +0100, Andreas Ehmanns wrote:
>>
>>> this is very weird. Did you really use the latest patch? On my target
>>> the LDAP server is starting without any problems. It seems that we use
>>> different init scripts or something else is wrong. Please have a 
>>> look at
>>> my answers below:
>> I think I used the latest version, i.e
>> http://patchwork.ozlabs.org/patch/567988/. But of course I can't be
>> sure since I've removed the commit from my Git tree.
>>
>>
>>>>    1/ The /etc/openldap/slapd.conf file doesn't exist. This happens 
>>>> when
>>>>       you build with BR2_PACKAGE_OPENLDAP_CLIENTS disabled. I think I
>>>>       already mentioned this problem in a previous review of this 
>>>> patch.
>>>>       I fixed this problem by doing:
>>> Yes, you're right. I've overseen this comment in your previous email.
>>> Sorry for the inconvenience and thanks for patch.
>>> I'll fix this.
>> Thanks!
>>
>>>>    2/ The /etc/openldap/slapd.conf file has permissions that do not 
>>>> allow
>>>>       the slapd daemon to read it. I fixed this problem by:
>>> When I build the rootfs this file has 644 permissions on the target and
>>> the ldap server starts without problems. Strange that it's different
>>> when I build the target rootfs and when you do it. Could it be that
>>> there is a unknown dependency to other packages?
>> Hum, weird. I'll retest again.
>>
>>> Nevertheless I think it is a good idea to change the owner of this file
>>> to ldap:ldap.
>>> I changed the init script as you proposed.
>> Well, if the permissions are sufficient for the daemon to read the
>> configuration file, then there's no need to add stuff in the init
>> script to change the ownership of the file.
>>
>>>>    3/ The sldap daemon doesn't start because it tries to write its PID
>>>>       file to /var/run/, where it doesn't have write permissions, 
>>>> while it
>>>>       should create it in /var/run/openldap. Here is the message I 
>>>> get in
>>>>       the logs:
>>> That's not correct. Looking at the init script you can see that the PID
>>> file is:
>>> PIDFILE=/var/run/openldap/slapd.pid
>> Yes, but this is only passed to start-stop-daemon, and
>> start-stop-daemon does *not* create the PID file. This -p $PIDFILE
>> option only allows start-stop-daemon to verify that the PID file has
>> been created by the daemon.
>>
>> Where is openldap told that its init script should be
>> in /var/run/openldap/ ?
>>
>>>> Also, there is something weird: when the daemon fails to start, it
>>>> doesn't show "done." (with your code) or "FAIL" (with my suggestion).
>>>> Can you have a look ?
>>> Yes. The reason was a "set -e" in the init script. I removed it and the
>>> logging is fine now.
>> Ah, yes, indeed. Thanks for the explanation!
>>
>> Thomas
>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>

  reply	other threads:[~2016-02-12  9:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-15  9:40 [Buildroot] [PATCH 1/1] openldap: add support to build the server Andreas Ehmanns
2016-01-20 22:59 ` Thomas Petazzoni
2016-01-22  9:50   ` Andreas Ehmanns
2016-01-22 10:03     ` Thomas Petazzoni
2016-01-22 10:58       ` Andreas Ehmanns
2016-02-12  9:26         ` Andreas Ehmanns [this message]
2016-02-25 20:39         ` Andreas Ehmanns
  -- strict thread matches above, loose matches on Subject: below --
2015-12-17 20:41 Andreas Ehmanns
2015-12-29 11:19 ` Thomas Petazzoni
2016-01-03 14:07   ` Andreas Ehmanns
2016-01-12 21:02   ` Andreas Ehmanns
2016-01-12 21:09     ` Thomas Petazzoni
2016-01-13 17:31       ` Andreas Ehmanns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56BDA550.6030606@gmx.de \
    --to=universeii@gmx.de \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox