#47513 tmpfiles.d references /var/lock when they should reference /run/lock
Closed: Fixed None Opened 6 years ago by nkinder.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1008306

+++ This bug was initially created as a clone of Bug #996716 +++

Description of problem:
I Setup a replication server and after reboot it fails to start ipa.  I did the
install three different times and every time I'm able to create the replicaton
server but after a reboot it fails to start.

After much digging I finally found out that the /var/lock/dirsrv/slapd-INSTANCE
dirs are not being created.

/var/lock is a symlink to /run/lock so I updated the tmpfiles.d to point to
/run/lock instead and now ipa starts fine on bootup.

Version-Release number of selected component (if applicable):
3.2.2

How reproducible:
Everytime on my VM host when doing replication.
Strange thing is my Master host has the same config files and it starts fine.

Additional Info:

journalctl shows the following failure:
Aug 13 12:45:45 pippin.home.pecknet.com systemd-tmpfiles[191]: Failed to create
directory /var/lock/dirsrv: No such file or directory
Aug 13 12:45:45 pippin.home.pecknet.com systemd-tmpfiles[191]: Failed to create
directory /var/lock/dirsrv/slapd-HOME-PECKNET-COM: No such file or directory

Could be a race condition where /run/lock doesn't exist yet? (That is created
from /usr/lib/tmpfiles.d/legacy)

--- Additional comment from Martin Kosek on 2013-08-14 02:24:19 EDT ---

I noticed the "/var/lock" symlinks in dirsrv's tmpfiles config file:

 # cat /etc/tmpfiles.d/dirsrv-IDM-LAB-BOS-REDHAT-COM.conf
d /var/run/dirsrv 0770 dirsrv dirsrv
d /var/lock/dirsrv 0770 dirsrv dirsrv
d /var/lock/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM 0770 dirsrv dirsrv

However, is this something that IPA should tackle? It is created during
setup-ds.pl phase, by DS. I would expect that DS would update it during upgrade
(if necessary). Rich, please advise if this is something that IPA is expected
to do.

--- Additional comment from Alexander Bokovoy on 2013-08-14 02:37:37 EDT ---

Similar update to tmpfiles.d needs to be done on Dogtag side as pki-* configs
also mention /var/lock and /var/run.

It is worth to file Dogtag bug for that.

As for FreeIPA, we need to avoid running systemd upgrade tool unless we are
upgrading from Fedora 16. This needs to be done ASAP.

--- Additional comment from Martin Kosek on 2013-08-14 02:58:06 EDT ---

(In reply to Alexander Bokovoy from comment #2)
> Similar update to tmpfiles.d needs to be done on Dogtag side as pki-*
> configs also mention /var/lock and /var/run.
>
> It is worth to file Dogtag bug for that.

+1. I cloned this bug.

> As for FreeIPA, we need to avoid running systemd upgrade tool unless we are
> upgrading from Fedora 16. This needs to be done ASAP.

How would you differentiate, that you are upgrading from Fedora 16?

Anyway, I think we should remove this script altogether in both Fedora 19 and
Fedora 20. Even Fedora 17 is already end of life, so I do not think we are
expected to support upgrades from pre-EOL Fedora to 19 or 20.

--- Additional comment from Nathan Kinder on 2013-08-14 12:43:16 EDT ---

(In reply to Martin Kosek from comment #1)
> I noticed the "/var/lock" symlinks in dirsrv's tmpfiles config file:
>
>  # cat /etc/tmpfiles.d/dirsrv-IDM-LAB-BOS-REDHAT-COM.conf
> d /var/run/dirsrv 0770 dirsrv dirsrv
> d /var/lock/dirsrv 0770 dirsrv dirsrv
> d /var/lock/dirsrv/slapd-IDM-LAB-BOS-REDHAT-COM 0770 dirsrv dirsrv
>
> However, is this something that IPA should tackle? It is created during
> setup-ds.pl phase, by DS. I would expect that DS would update it during
> upgrade (if necessary). Rich, please advise if this is something that IPA is
> expected to do.

This does seem to be some sort of race condition, as a fresh install of
389-ds-base on F19 works fine on a reboot in my testing.  We could change this
to use /run/lock instead of /var/lock in our tmpfiles.d config in DS, but I
don't understand why that should be necessary.  I would like to understand what
is happening before making this change.

The fact that using /run/lock instead of /var/lock is working around the
problem indicates that /usr/lib/tmpfiles.d/legacy.conf is being processed
before /etc/tmpfiles.d/dirsrv.conf, as the /run/lock directory must already
exist.  This doesn't explain why /var/lock wouldn't work, as /var/lock is a
persistent symlink on a normal filesystem as far as I can tell.  If /run/lock
exists, /var/lock should work just fine.

--- Additional comment from Bill Peck on 2013-08-14 12:57:14 EDT ---

If someone can tell me how to gather more data or enable certain debugging from
systemd to try and shed some light on the issue I'd be more than happy to do
it.

Should the systemd developers be cc'ed on this?

Thanks

--- Additional comment from Martin Kosek on 2013-08-15 02:24:57 EDT ---

Good idea. Adding Michal of systemd to chime in if this area is familiar to
him.

--- Additional comment from Michal Sekletar on 2013-08-21 12:24:45 EDT ---

First of all sorry for not commenting earlier. I think we are hitting an actual
bug in systemd-tmpfiles here, since using /run/lock works and /var/lock
doesn't.

Just fyi, tmpfiles drop-in configuration is applied in a way that config files
in /etc override those in /usr and after parsing all config files,
configuration is then applied according to lexicographical ordering of config
file names, but regardless of location.

This means that /etc/tmpfiles.d/dirsrv* config files are applied earlier than
/usr/lib/tmpfiles.d/legacy.conf. However, this *shouldn't* matter since we
always create whole hierarchy for each path specified in config files and if
there is overlap with configuration in later config files then path modes are
fixed-up accordingly.

AFAIK, the bug is that that we don't canonicalize path before we start with
creating parent hierarchy for path specified in configuration file.

Please use /run paths as a workaround for the time being. Although you might
want to keep those and stop using legacy /var paths.

Btw, freeipa-server ships /etc/tmpfiles.d/ipa.conf in package payload. Note
that you shouldn't do that as per Fedora Packaging Guidelines policy.

--- Additional comment from Rob Crittenden on 2013-08-27 09:28:58 EDT ---

(In reply to Michal Sekletar from comment #7)
> Btw, freeipa-server ships /etc/tmpfiles.d/ipa.conf in package payload. Note
> that you shouldn't do that as per Fedora Packaging Guidelines policy.

I'm not sure I follow. It looks like we are incorrectly marking it as config,
and using the wrong directory, is that what you mean?

--- Additional comment from Michal Sekletar on 2013-08-27 11:31:39 EDT ---

Sorry for confusing statement. I was referring to the path
/etc/tmpfiles.d/ipa.conf.

As you correctly pointed out, tmpfiles drop-in shouldn't be in /etc/ and
shouldn't be marked as config.

--- Additional comment from Martin Kosek on 2013-09-02 11:25:11 EDT ---

Thanks, I will create an upstream ticket to fix the ipa.conf drop-in and place
it in the right directory to avoid violating the guidelines.

--- Additional comment from Martin Kosek on 2013-09-02 11:31:12 EDT ---

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3894

--- Additional comment from Martin Kosek on 2013-09-03 10:30:01 EDT ---

Upstream ticket in Comment 11 was closed as a duplicate of:
https://fedorahosted.org/freeipa/ticket/3881

--- Additional comment from Orion Poplawski on 2013-09-13 09:36:35 EDT ---

I can edit /etc/tmpfiles.d/dirsrv@NWRA-COM, but then something seems to be
changing it back (perhaps updates of 386-ds/ipa).

I thought /usr/lib/tmpfiles.d was for static files (i.e. files provided with the package), and /etc/tmpfiles.d was for dynamic files (i.e. files created at runtime - by setup-ds.pl).

Replying to [comment:6 rmeggins]:

I thought /usr/lib/tmpfiles.d was for static files (i.e. files provided with the package), and /etc/tmpfiles.d was for dynamic files (i.e. files created at runtime - by setup-ds.pl).

I'm not sure exactly. I was following the comments by Michal Sekletar in https://bugzilla.redhat.com/show_bug.cgi?id=1008610

IPA also made this change as well, so I figured we should too.

Replying to [comment:7 mreynolds]:

Replying to [comment:6 rmeggins]:

I thought /usr/lib/tmpfiles.d was for static files (i.e. files provided with the package), and /etc/tmpfiles.d was for dynamic files (i.e. files created at runtime - by setup-ds.pl).

I'm not sure exactly. I was following the comments by Michal Sekletar in https://bugzilla.redhat.com/show_bug.cgi?id=1008610

IPA also made this change as well, so I figured we should too.

Here are the contents of ipa.conf:
{{{
d /var/run/ipa_memcached 0700 apache apache
d /var/run/ipa 0700 root root
}}}
These files/directories/users are created at package install time. So it is perfectly fine to have this file be static. The problem is that, at least with base 389, our configuration is dynamic - we don't know what the user ID will be.
{{{
d /var/run/dirsrv 0770 nobody nobody
d /var/lock/dirsrv 0770 nobody nobody
d /var/lock/dirsrv/slapd-localhost 0770 nobody nobody
}}}
Rather than fight against systemd/tmpfiles and "/run" perhaps we should just use "/run" for the DS run_dir and lock_dir.

Replying to [comment:8 rmeggins]:

Replying to [comment:7 mreynolds]:

Replying to [comment:6 rmeggins]:

I thought /usr/lib/tmpfiles.d was for static files (i.e. files provided with the package), and /etc/tmpfiles.d was for dynamic files (i.e. files created at runtime - by setup-ds.pl).

I'm not sure exactly. I was following the comments by Michal Sekletar in https://bugzilla.redhat.com/show_bug.cgi?id=1008610

IPA also made this change as well, so I figured we should too.

Here are the contents of ipa.conf:
{{{
d /var/run/ipa_memcached 0700 apache apache
d /var/run/ipa 0700 root root
}}}
These files/directories/users are created at package install time. So it is perfectly fine to have this file be static. The problem is that, at least with base 389, our configuration is dynamic - we don't know what the user ID will be.
{{{
d /var/run/dirsrv 0770 nobody nobody
d /var/lock/dirsrv 0770 nobody nobody
d /var/lock/dirsrv/slapd-localhost 0770 nobody nobody
}}}
Rather than fight against systemd/tmpfiles and "/run" perhaps we should just use "/run" for the DS run_dir and lock_dir.

Works for me, I'll rework the patch.

Replying to [comment:9 mreynolds]:

Replying to [comment:8 rmeggins]:

Replying to [comment:7 mreynolds]:

Replying to [comment:6 rmeggins]:

I thought /usr/lib/tmpfiles.d was for static files (i.e. files provided with the package), and /etc/tmpfiles.d was for dynamic files (i.e. files created at runtime - by setup-ds.pl).

I'm not sure exactly. I was following the comments by Michal Sekletar in https://bugzilla.redhat.com/show_bug.cgi?id=1008610

IPA also made this change as well, so I figured we should too.

Here are the contents of ipa.conf:
{{{
d /var/run/ipa_memcached 0700 apache apache
d /var/run/ipa 0700 root root
}}}
These files/directories/users are created at package install time. So it is perfectly fine to have this file be static. The problem is that, at least with base 389, our configuration is dynamic - we don't know what the user ID will be.
{{{
d /var/run/dirsrv 0770 nobody nobody
d /var/lock/dirsrv 0770 nobody nobody
d /var/lock/dirsrv/slapd-localhost 0770 nobody nobody
}}}
Rather than fight against systemd/tmpfiles and "/run" perhaps we should just use "/run" for the DS run_dir and lock_dir.

Works for me, I'll rework the patch.

New patch attached(with autogen.sh). The main code change is in DSCreate.pm, and I renamed the global attribute to "localrundir" and its used for the lock and run dirs.

I think you used the wrong version of autoconf - did you run autogen.sh on f18?

On second thought - it would be quite a large change to use /run instead of /var/lock and /var/run - external scripts, external apps, selinux, documentation, etc. - not good.

So I guess if your original patch works, let's just go with it. If someone complains that we are dynamically updating files in /usr/lib/tmpfiles.d, we will just then insist that they fix the dependency order in tmpfiles.d such that we can force /etc/tmpfiles.d/dirsrv* to be loaded after legacy.conf

Replying to [comment:11 rmeggins]:

I think you used the wrong version of autoconf - did you run autogen.sh on f18?

Hmmm, ran it rhel64.

On second thought - it would be quite a large change to use /run instead of /var/lock and /var/run - external scripts, external apps, selinux, documentation, etc. - not good.

So I guess if your original patch works, let's just go with it. If someone complains that we are dynamically updating files in /usr/lib/tmpfiles.d, we will just then insist that they fix the dependency order in tmpfiles.d such that we can force /etc/tmpfiles.d/dirsrv* to be loaded after legacy.conf

I had removed the spec file update, are you saying I should add it back? The spec file update is not necessary to fix the original ticket. I was originally thinking I should make the spec file update just to be complete since I was already working in that area, but like you said for dynamic conf files, it should be in /etc/tmpfiles.d/

Replying to [comment:12 mreynolds]:

Replying to [comment:11 rmeggins]:

I think you used the wrong version of autoconf - did you run autogen.sh on f18?

Hmmm, ran it rhel64.

On second thought - it would be quite a large change to use /run instead of /var/lock and /var/run - external scripts, external apps, selinux, documentation, etc. - not good.

Well, internally we only use the /run for setup-ds.pl. Do external apps look at the tmpfile.d conf file?

So I guess if your original patch works, let's just go with it.

It does change the value in the tmpfile.d config file to use /run/lock.

So now I'm a bit confused as to what you want me to do, as you said we should use not /run at all.

If someone complains that we are dynamically updating files in /usr/lib/tmpfiles.d, we will just then insist that they fix the dependency order in tmpfiles.d such that we can force /etc/tmpfiles.d/dirsrv* to be loaded after legacy.conf

I had removed the spec file update, are you saying I should add it back? The spec file update is not necessary to fix the original ticket. I was originally thinking I should make the spec file update just to be complete since I was already working in that area, but like you said for dynamic conf files, it should be in /etc/tmpfiles.d/

Replying to [comment:13 mreynolds]:

Replying to [comment:12 mreynolds]:

Replying to [comment:11 rmeggins]:

I think you used the wrong version of autoconf - did you run autogen.sh on f18?

Hmmm, ran it rhel64.

You'll need to use fedora 18.

On second thought - it would be quite a large change to use /run instead of /var/lock and /var/run - external scripts, external apps, selinux, documentation, etc. - not good.

Well, internally we only use the /run for setup-ds.pl. Do external apps look at the tmpfile.d conf file?

But your change doesn't affect only the config files in tmpfiles.d - your change affects the lock_dir and run_dir used by the directory server - core server and scripts. For example, look at everywhere in DSCreate.pm.in that lock_dir and run_dir are used.

Is the intent of the change to only use /run in the tmpfiles.d conf files for dirsrv instances?

So I guess if your original patch works, let's just go with it.

It does change the value in the tmpfile.d config file to use /run/lock.

So now I'm a bit confused as to what you want me to do, as you said we should use not /run at all.

If someone complains that we are dynamically updating files in /usr/lib/tmpfiles.d, we will just then insist that they fix the dependency order in tmpfiles.d such that we can force /etc/tmpfiles.d/dirsrv* to be loaded after legacy.conf

I had removed the spec file update, are you saying I should add it back? The spec file update is not necessary to fix the original ticket. I was originally thinking I should make the spec file update just to be complete since I was already working in that area, but like you said for dynamic conf files, it should be in /etc/tmpfiles.d/

Replying to [comment:14 rmeggins]:

Replying to [comment:13 mreynolds]:

Replying to [comment:12 mreynolds]:

Replying to [comment:11 rmeggins]:

I think you used the wrong version of autoconf - did you run autogen.sh on f18?

Hmmm, ran it rhel64.

You'll need to use fedora 18.

On second thought - it would be quite a large change to use /run instead of /var/lock and /var/run - external scripts, external apps, selinux, documentation, etc. - not good.

Well, internally we only use the /run for setup-ds.pl. Do external apps look at the tmpfile.d conf file?

But your change doesn't affect only the config files in tmpfiles.d - your change affects the lock_dir and run_dir used by the directory server - core server and scripts. For example, look at everywhere in DSCreate.pm.in that lock_dir and run_dir are used.

Is the intent of the change to only use /run in the tmpfiles.d conf files for dirsrv instances?

Yes. Ok, well I can make it do just that, and not set {lock_dir}.

So I guess if your original patch works, let's just go with it.

It does change the value in the tmpfile.d config file to use /run/lock.

So now I'm a bit confused as to what you want me to do, as you said we should use not /run at all.

If someone complains that we are dynamically updating files in /usr/lib/tmpfiles.d, we will just then insist that they fix the dependency order in tmpfiles.d such that we can force /etc/tmpfiles.d/dirsrv* to be loaded after legacy.conf

I had removed the spec file update, are you saying I should add it back? The spec file update is not necessary to fix the original ticket. I was originally thinking I should make the spec file update just to be complete since I was already working in that area, but like you said for dynamic conf files, it should be in /etc/tmpfiles.d/

New patch is attached that only updates the tmpfiles.d configuration file.

Did you use autogen.sh on f18? If so, then I guess you'll have to use autogen.sh on f19.

{{{
configure.ac:
+ localrundir='/run'

DSCreate.pm.in:
+ if( -d "$localrundir"){
+ $rundir = $localrundir
+ $lockdir = "$localrundir/lock/@PACKAGE_NAME@/slapd-$servid";
+ $parentdir = "$localrundir/lock";
...
+ print DOTDFILE "d $rundir 0770 $username $groupname\n";
+ print DOTDFILE "d $parentdir 0770 $username $groupname\n";
+ print DOTDFILE "d $lockdir 0770 $username $groupname\n";
}}}
So this means that $rundir is "/run", $parentdir is "/run/lock", and $lockdir is "/run/lock/dirsrv/slapd-INST"? Shouldn't $rundir be "/run/dirsrv", $parentdir be "/run/lock/dirsrv", and $lockdir be "/run/lock/dirsrv/slapd-INST"?

Yes, you must run autogen.sh on F18 or later

Replying to [comment:18 rmeggins]:

Did you use autogen.sh on f18? If so, then I guess you'll have to use autogen.sh on f19.

{{{
configure.ac:
+ localrundir='/run'

DSCreate.pm.in:
+ if( -d "$localrundir"){
+ $rundir = $localrundir
+ $lockdir = "$localrundir/lock/@PACKAGE_NAME@/slapd-$servid";
+ $parentdir = "$localrundir/lock";
...
+ print DOTDFILE "d $rundir 0770 $username $groupname\n";
+ print DOTDFILE "d $parentdir 0770 $username $groupname\n";
+ print DOTDFILE "d $lockdir 0770 $username $groupname\n";
}}}
So this means that $rundir is "/run", $parentdir is "/run/lock", and $lockdir is "/run/lock/dirsrv/slapd-INST"? Shouldn't $rundir be "/run/dirsrv", $parentdir be "/run/lock/dirsrv", and $lockdir be "/run/lock/dirsrv/slapd-INST"?

You're right, rundir and parentdir are incorrect. Since I ran autogen on rhel64, I need to redo this anyway.

Replying to [comment:20 mreynolds]:

Replying to [comment:18 rmeggins]:

Did you use autogen.sh on f18? If so, then I guess you'll have to use autogen.sh on f19.

{{{
configure.ac:
+ localrundir='/run'

DSCreate.pm.in:
+ if( -d "$localrundir"){
+ $rundir = $localrundir
+ $lockdir = "$localrundir/lock/@PACKAGE_NAME@/slapd-$servid";
+ $parentdir = "$localrundir/lock";
...
+ print DOTDFILE "d $rundir 0770 $username $groupname\n";
+ print DOTDFILE "d $parentdir 0770 $username $groupname\n";
+ print DOTDFILE "d $lockdir 0770 $username $groupname\n";
}}}
So this means that $rundir is "/run", $parentdir is "/run/lock", and $lockdir is "/run/lock/dirsrv/slapd-INST"? Shouldn't $rundir be "/run/dirsrv", $parentdir be "/run/lock/dirsrv", and $lockdir be "/run/lock/dirsrv/slapd-INST"?

You're right, rundir and parentdir are incorrect. Since I ran autogen on rhel64, I need to redo this anyway.

Used autoconf 2.69 from F19, and fixed the other issues.

New patch attached...

master:

git merge ticket47513
Updating f9d1d9e..385b5dc
Fast-forward
Makefile.am | 2 +
Makefile.in | 4911 +++++++++++++++++----------------
aclocal.m4 | 334 ++-
compile | 9 +-
config.guess | 182 +-
config.sub | 88 +-
configure | 65 +-
configure.ac | 3 +
depcomp | 454 ++--
ldap/admin/src/scripts/DSCreate.pm.in | 21 +-
missing | 405 +--
11 files changed, 3380 insertions(+), 3094 deletions(-)

git push origin master
Counting objects: 33, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 38.97 KiB, done.
Total 17 (delta 14), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
f9d1d9e..385b5dc master -> master

commit 385b5dc
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Sep 23 15:47:00 2013 -0400

1.3.1

git merge ticket-47513
Updating 8d34f77..c244a9b
Fast-forward
Makefile.am | 2 +
Makefile.in | 4893 +++++++++++++++++----------------
aclocal.m4 | 334 ++-
compile | 9 +-
config.guess | 182 +-
config.sub | 88 +-
configure | 65 +-
configure.ac | 3 +
depcomp | 454 ++--
ldap/admin/src/scripts/DSCreate.pm.in | 20 +-
missing | 405 +--
11 files changed, 3369 insertions(+), 3086 deletions(-)

git push origin 389-ds-base-1.3.1
Counting objects: 33, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (16/16), done.
Writing objects: 100% (17/17), 39.01 KiB, done.
Total 17 (delta 14), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
8d34f77..c244a9b 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

commit c244a9b
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Sep 23 17:22:11 2013 -0400

"So I guess if your original patch works, let's just go with it. If someone complains that we are dynamically updating files in /usr/lib/tmpfiles.d, we will just then insist that they fix the dependency order in tmpfiles.d such that we can force /etc/tmpfiles.d/dirsrv* to be loaded after legacy.conf"

I think logically speaking it makes sense for you to put the file in /usr/lib/tmpfiles.d anyway, really. Whether it comes out of the RPM or the 389-ds install script, effectively, the version in /usr/lib is the 'base version' of that file, as systemd looks at it.

If you keep in mind the basic philosophy of this systemd design - that the 'system copy' of the file, which should not be modified, lives in /usr, and if the user/local sysadmin wants to make a site-specific modification to it, they should copy it into /etc and modify it there - then having 389's 'base copy' of the file be in /usr makes sense, I think. If you started putting it in /etc, it would break the 'local sysadmin makes site-specific modifications in /etc' model.

1.3.1 is not working correctly, %localrundir% is not being found. In master(1.3.2) it is working correctly. Something went wrong when updating configure/makefile for 1.3.1. Investigating...

Turns out 1.3.1 is ok, but something was wrong with 1.3.1-10 build.

Improved the checking/setting of the localrundir in the setup process.

I think the real problem is that the spec files do not set --with-fhs

Replying to [comment:28 rmeggins]:

I think the real problem is that the spec files do not set --with-fhs

Correct, but this is addressing a completely different issue. There will be second patch for the upcoming configure.ac changes.

git push origin master
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 856 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
d876e6d..9e38a3b master -> master

commit 9e38a3b
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Sep 30 12:11:34 2013 -0400

git push origin 389-ds-base-1.3.1
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 917 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
4347de5..bb1fc96 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

Going to work on the configure.ac patch next...

[mareynol@localhost ds]$ git merge ticket47513
Updating 9e38a3b..081ce00
Fast-forward
Makefile.in | 48 +++++++++++++++++++++++++-----------------------
configure | 2 ++
configure.ac | 2 ++
3 files changed, 29 insertions(+), 23 deletions(-)
[mareynol@localhost ds]$ git push origin mater
error: src refspec mater does not match any.
error: failed to push some refs to 'ssh://git.fedorahosted.org/git/389/ds.git'
[mareynol@localhost ds]$ git push origin master
Counting objects: 9, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 1.05 KiB, done.
Total 5 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
9e38a3b..081ce00 master -> master

commit 081ce00
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Sep 30 12:28:35 2013 -0400

1.3.1

git merge localrundir
Updating bb1fc96..a78fa58
Fast-forward
configure | 2 ++
configure.ac | 2 ++
2 files changed, 4 insertions(+), 0 deletions(-)

git push origin 389-ds-base-1.3.1
Counting objects: 7, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 628 bytes, done.
Total 4 (delta 3), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
bb1fc96..a78fa58 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

commit a78fa58
Author: Mark Reynolds mreynolds@redhat.com
Date: Mon Sep 30 12:41:58 2013 -0400

Replying to [comment:24 adamwill]:

"So I guess if your original patch works, let's just go with it. If someone complains that we are dynamically updating files in /usr/lib/tmpfiles.d, we will just then insist that they fix the dependency order in tmpfiles.d such that we can force /etc/tmpfiles.d/dirsrv* to be loaded after legacy.conf"

I think logically speaking it makes sense for you to put the file in /usr/lib/tmpfiles.d anyway, really. Whether it comes out of the RPM or the 389-ds install script, effectively, the version in /usr/lib is the 'base version' of that file, as systemd looks at it.

If you keep in mind the basic philosophy of this systemd design - that the 'system copy' of the file, which should not be modified, lives in /usr, and if the user/local sysadmin wants to make a site-specific modification to it, they should copy it into /etc and modify it there - then having 389's 'base copy' of the file be in /usr makes sense, I think. If you started putting it in /etc, it would break the 'local sysadmin makes site-specific modifications in /etc' model.

1) "the 'system copy' of the file, which should not be modified, lives in /usr"
Then setup should not put files in /usr

2) One way to think of setup-ds.pl is a "wizard" script for the user/local sysadmin. setup-ds.pl allows the user/local sysadmin to make site-specific modifications to files, albeit indirectly. And the admin can make changes to /etc/tmpfiles.d/dirsrv-instance.conf after setup-ds.pl, which will be preserved.

So I don't think we need to/should change anything.

This isn't working using 389-ds-base-1.3.2.0-1.fc20.x86_64 on F20. I created an instance and the following is in /etc/tmpfiles.d/dirsrv-example.conf:

d /var/run/dirsrv 0770 nobody nobody
d /var/lock/dirsrv 0770 nobody nobody
d /var/lock/dirsrv/slapd-example 0770 nobody nobody

Pushed the additional string comparison patch to master, 1.3.2, and 1.3.1:

master - 0394b2b
389-ds-base-1.3.2 - 0bd980d
389-ds-base-1.3.1 - 848f5c8

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.1.12

2 years ago

Login to comment on this ticket.

Metadata