Bug 730053 - BackupPC breaks with recent upgrade because /var/run/BackupPC doesn't exist
Summary: BackupPC breaks with recent upgrade because /var/run/BackupPC doesn't exist
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: BackupPC
Version: 15
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Bernard Johnson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-11 16:17 UTC by Reid Rivenburgh
Modified: 2013-01-28 17:24 UTC (History)
9 users (show)

Fixed In Version: BackupPC-3.2.1-4.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-09-09 16:55:29 UTC


Attachments (Terms of Use)

Description Reid Rivenburgh 2011-08-11 16:17:29 UTC
Description of problem:
I recently upgraded to BackupPC-3.2.1-1.fc15.x86_64, which apparently now uses /var/run/BackupPC.  That directory didn't exist on my machine, so it would silently fail to start.  The LOG file didn't provide much help, but strace revealed the problem.  I don't know much about rpm, but it seems like a script should be run that creates the directory.  (Maybe the script does do that and just failed on my machine for some reason; I upgraded about a month ago, and I just rebooted today.)

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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Richard Shaw 2011-08-11 23:32:35 UTC
I can reproduce. Same problem, same solution.

Comment 2 Richard Shaw 2011-08-11 23:44:25 UTC
Ok, I did a "rpm -ql BackupPC" which does show a "/var/run/BackupPC" which explains why it works when I first install, however, it appears something is removing that directory. This is all very strange.

In reviewing the spec file I came across the following section:

%if 0%{?_with_systemd}
%{_unitdir}/backuppc.service
%config(noreplace) %{_sysconfdir}/tmpfiles.d/%{name}.conf
%else
%attr(0755,root,root) %{_initrddir}/backuppc
%dir %attr(0775,backuppc,backuppc) %{_localstatedir}/run/%{name}
%endif

Should the line that grabs /var/run/BackupPC be placed outside of the if conditional or is that directory only needed with sysvinit and not systemd?

Richard

Comment 3 Bernard Johnson 2011-08-12 05:23:41 UTC
(In reply to comment #2)
> Ok, I did a "rpm -ql BackupPC" which does show a "/var/run/BackupPC" which
> explains why it works when I first install, however, it appears something is
> removing that directory. This is all very strange.

I keyed on tmpfiles.d being in > F15, but it appears that it starts in F15.  I'll have to change around the conditionals a bit.  I guess I need to check when systemd was introduced too - make sure I didn't get that wrong.

I'll try to get a test build out this weekend.

Comment 4 Richard Shaw 2011-08-12 11:40:11 UTC
Well of course systemd is available in F15 but I figured that BackupPC was sticking with the old system since from what I understand (from reading the devel list) no one is supposed to switch from old to new within a release, so the next chance to switch to a systemd based install will be F16, which is how the conditionals in the spec file seem to be setup. (i.e. fedora > 15)

Is that correct?

Comment 5 Bernard Johnson 2011-08-12 14:59:16 UTC
And therein lies the problem.  Originally when I started working on the spec, I was going to bring systemd support into F15.  But then as you mentioned, the next chance became F16.  When I added tmpfiles.d support, I used the same conditional - it really goes hand and hand with systemd.  So what I'll have to do is include tmpfiles.d support back to F15 and leave systemd support where it is.

Comment 6 Bernard Johnson 2011-08-13 04:20:49 UTC
Please try this scratch build and see if it resolves the problem for F15.

Thanks

Comment 8 Richard Shaw 2011-08-15 01:05:34 UTC
So far so good, it hasn't stopped running.

I was able to cause an SEAlert though. From the http interface I clicked on "Log" and got this:

SELinux is preventing /usr/bin/perl from read access on the file /var/log/BackupPC/LOG.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that perl should be allowed read access on the LOG file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:httpd_t:s0
Target Context                system_u:object_r:var_log_t:s0
Target Objects                /var/log/BackupPC/LOG [ file ]
Source                        BackupPC_Admin.
Source Path                   /usr/bin/perl
Port                          <Unknown>
Host                          hobbes.localdomain
Source RPM Packages           perl-5.12.4-160.fc15
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.16-35.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     hobbes.localdomain
Platform                      Linux hobbes.localdomain 2.6.40-4.fc15.x86_64 #1
                              SMP Fri Jul 29 18:46:53 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Sun 14 Aug 2011 07:56:07 PM CDT
Last Seen                     Sun 14 Aug 2011 07:56:07 PM CDT
Local ID                      2e6c75fa-7d5b-4d1f-ba0e-090631c18bc3

Raw Audit Messages
type=AVC msg=audit(1313369767.589:820): avc:  denied  { read } for  pid=4272 comm="BackupPC_Admin." name="LOG" dev=dm-3 ino=11010082 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file


type=AVC msg=audit(1313369767.589:820): avc:  denied  { open } for  pid=4272 comm="BackupPC_Admin." name="LOG" dev=dm-3 ino=11010082 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file


type=SYSCALL msg=audit(1313369767.589:820): arch=x86_64 syscall=open success=yes exit=ESRCH a0=2118610 a1=0 a2=1b6 a3=7fe11b306e30 items=0 ppid=15379 pid=4272 auid=4294967295 uid=48 gid=489 euid=489 suid=489 fsuid=489 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null)

Hash: BackupPC_Admin.,httpd_t,var_log_t,file,read

audit2allow

#============= httpd_t ==============
allow httpd_t var_log_t:file { read open };

audit2allow -R

#============= httpd_t ==============
allow httpd_t var_log_t:file { read open };


Instead of following the default directions for audit2allow which greps through the entire log, I only pulled the last (and appropriate) entry. Audit2allow then gives:
"""
module backuppc 1.0;

require {
        type var_log_t;
        type httpd_t;
        class file open;
}

#============= httpd_t ==============
allow httpd_t var_log_t:file open;
"""

I think this is what needs to be added to the selinux context in the spec.

Richard

Comment 9 Daniel Walsh 2011-08-15 10:18:54 UTC
Richard please open a separate bug for this.  It looks like we need a new label for BackupPC and to allow apache to read it.

Comment 10 Jan ONDREJ 2011-08-16 14:41:26 UTC
Same problem here. Your BackupPC.conf file from your scratch build has 2 problems. At first mistake (backukppc instead of backuppc) and modes (775) should be before UID/GID. Here is a patch:

--- /tmp/BackupPC.conf  2011-08-13 06:15:24.000000000 +0200
+++ BackupPC.conf       2011-08-16 16:28:09.000000000 +0200
@@ -1 +1 @@
-D /var/run/BackupPC backukppc backuppc 775 -
+D /var/run/BackupPC 775 backuppc backuppc -

With this file I need to run:
  systemd-tmpfiles --create

and then backuppc starts well.
I am not sure, if you need to start systemd-tmpfiles manually after update of package or it will be run automatically.

Comment 11 Richard Shaw 2011-08-16 18:23:15 UTC
I think you mean BackupPC.tmpfiles.

Comment 12 Jan ONDREJ 2011-08-17 06:12:31 UTC
(In reply to comment #11)
> I think you mean BackupPC.tmpfiles.

No, I mean /etc/tmpfiles.d/BackupPC.conf from x86_64 package, but looks like it's BackupPC.tmpfiles in src.rpm. :-)

Please, update this file and make an testing update in bodhi. Thanks.

Comment 13 Bernard Johnson 2011-08-19 22:15:17 UTC
Here is another scratch build.

http://koji.fedoraproject.org/koji/taskinfo?taskID=3287658

(In reply to comment #10)

> I am not sure, if you need to start systemd-tmpfiles manually after update of
> package or it will be run automatically.

This page: http://fedoraproject.org/wiki/Packaging:Tmpfiles.d says "tmpfiles.d is a service provided by both systemd and upstart in Fedora 15 and later for managing temporary files and directories." and "Configuring tmpfiles.d just involves dropping a file into %{_sysconfdir}/tmpfiles.d/ that tells the init system what directories need to be created."

I don't have a system with tmpfiles.d to confirm this on, but if you can check that functionality I would appreciate it.


I will address the selinux errors in the bug that it was reported (bz 730704)

Comment 14 Jan ONDREJ 2011-08-20 07:28:22 UTC
(In reply to comment #13)
> Here is another scratch build.
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=3287658

Package looks well. I can test it on a production system, if you make an testing update in bodhi.

> > I am not sure, if you need to start systemd-tmpfiles manually after update of
> > package or it will be run automatically.
> 
> This page: http://fedoraproject.org/wiki/Packaging:Tmpfiles.d says "tmpfiles.d
> is a service provided by both systemd and upstart in Fedora 15 and later for
> managing temporary files and directories." and "Configuring tmpfiles.d just
> involves dropping a file into %{_sysconfdir}/tmpfiles.d/ that tells the init
> system what directories need to be created."

I think they don't need to process tmpfiles restart for normal packages. If somebody updates fc15 package from fc14- (or older) there is no need to restart tmpfiles. In old system (fc14-) tmpfiles are created on real filesystem, after restart they will be created using tmpfiles.d.

But your current package has missing tmpfile, so an user should restart their system after update or at least reload tmpfiles creation. May be you can suggest reboot using bodhi, even if it's not necessary.

Comment 15 Fedora Update System 2011-08-25 02:52:55 UTC
BackupPC-3.2.1-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc16

Comment 16 Kevin Cousin 2011-08-25 13:38:54 UTC
(In reply to comment #15)
> BackupPC-3.2.1-4.fc16 has been submitted as an update for Fedora 16.
> https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc16

Will the package push in Fedora 15 ?

Comment 17 Fedora Update System 2011-08-26 14:18:50 UTC
Package BackupPC-3.2.1-4.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing BackupPC-3.2.1-4.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc16
then log in and leave karma (feedback).

Comment 18 Johan Cwiklinski 2011-09-04 07:45:34 UTC
(In reply to comment #16)
> Will the package push in Fedora 15 ?

Package is available in updates-testing repository for F-15 (see: https://admin.fedoraproject.org/updates/BackupPC-3.2.1-4.fc15).

Missing /var/run/BackupPC bug seems to be solved with that build.

Comment 19 Fedora Update System 2011-09-09 16:55:23 UTC
BackupPC-3.2.1-4.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Ryne McCall 2011-11-18 03:47:02 UTC
The problem still exists for me in Fedora 16.

I'm using:
~]$ rpm -q BackupPC
BackupPC-3.2.1-6.fc16.x86_64

/var/run/BackupPC does not exist after package install.

So, the backuppc daemon failed to start with:
2011-11-17 22:16:10 unix bind() failed: No such file or directory

After creating /var/run/BackupPC, the daemon starts.

Comment 21 Bernard Johnson 2011-11-18 15:49:53 UTC
(In reply to comment #20)
> The problem still exists for me in Fedora 16.

What is the contents of /etc/tmpfiles.d/BackupPC.conf ?

Comment 22 Ryne McCall 2011-11-20 21:36:32 UTC
~]$ cat /etc/tmpfiles.d/BackupPC.conf 
D /var/run/BackupPC 0775 root backuppc -

Comment 23 Bernard Johnson 2011-11-21 02:52:50 UTC
Please add a new bug and we can debug further.

Comment 24 Joel Uckelman 2013-01-27 11:48:51 UTC
The missing /var/run/BackupPC directory is still a problem with 3.2.1-10 on Fedora 17. I upgraded from the previous version of BackupPC last night, and found that I had to manually create /var/run/BackuPC after the upgrade in order for BackuPC to work.

Comment 25 Richard Shaw 2013-01-27 14:28:12 UTC
Yes, I recently attempted to fedup to F18 which was a disaster. After complete reinstall I had to add this directory before BackupPC would start.

Comment 26 Nix Nooi 2013-01-27 23:50:40 UTC
NAME=Fedora
VERSION="17 (Beefy Miracle)"
ID=fedora
VERSION_ID=17
PRETTY_NAME="Fedora 17 (Beefy Miracle)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:17"

BackupPC-3.2.1-10.fc17.i686

there was no /etc/tmpfiles.d/BackupPC.conf file

I made the /var/run/BackupPC dir - did not fix my issue. I rebooted. The dir /var/run/BackupPC was gone when I was back up. I made /etc/tmpfiles.d/BackupPC.conf by hand according to Comment 22. I rebooted again. The dir was made and the service worked.

Comment 27 Nix Nooi 2013-01-27 23:54:45 UTC
I would add a new bug if I knew how. I tried to clone this one as a start, but I did not get far.

Comment 28 Johan Cwiklinski 2013-01-28 07:10:12 UTC
Missing directories may not related to the current bug, but to bz #896626 

Try BackupPC-3.2.1-11.fc17 from testing repositories; this release should fix your issue.

Comment 29 Joel Uckelman 2013-01-28 09:03:43 UTC
(In reply to comment #26)
> NAME=Fedora
> VERSION="17 (Beefy Miracle)"
> ID=fedora
> VERSION_ID=17
> PRETTY_NAME="Fedora 17 (Beefy Miracle)"
> ANSI_COLOR="0;34"
> CPE_NAME="cpe:/o:fedoraproject:fedora:17"
> 
> BackupPC-3.2.1-10.fc17.i686
> 
> there was no /etc/tmpfiles.d/BackupPC.conf file
> 
> I made the /var/run/BackupPC dir - did not fix my issue. I rebooted. The dir
> /var/run/BackupPC was gone when I was back up. I made
> /etc/tmpfiles.d/BackupPC.conf by hand according to Comment 22. I rebooted
> again. The dir was made and the service worked.

I concur. Creating /var/run/BackupPC was only a temporary fix; it was gone when I rebooted.

Comment 30 Daniel Walsh 2013-01-28 17:24:53 UTC
You might want to start adding NamedFileTransrules to your policy.

optional_policy(`
	gen_require(`
		attribute unconfined_domain_type;
	')
	files_pid_filetrans(unconfined_domain_type, backup_var_run_t, dir, "BackupPC")
')

THis would cause all confined domains to create /run/BackupPC with the proper label.


Note You need to log in before you can comment on or make changes to this bug.