Bug 600

Will have a look on it

CC: (none) => ennael1

I think that the wiki could play an important role - provide patching info, give examples of configuration scripts. With good info in the wiki, the contents of the backuppc package itself could just protect users to waste time when they discover that backuppc does not work and point them to what they need. Installing backuppc anyhow means reading and manually configuring.

Until the wiki becomes available for this kind of detail, maybe an additional forum section like "tips and tricks" (with subforums if it needs to be structured) could be a helpful interim.

Could you try backuppc-3.2.0-2.mga1 soon available on mirrors?

With pleasure. There may be a couple of days delay - I hope to squeeze in 3 days of skiing.

I just started to try, but there is a dependency problem to a 64-bit library (and I have no acces to a 64bit machine)

[root@pcjuergen /]# urpmi --auto-select
A requested package cannot be installed:
backuppc-3.2.0-2.mga1.noarch (due to unsatisfied libc.so.6(GLIBC_2.2.5)(64bit))
Continue installation anyway? (Y/n) n

Just updated. It's now arch dependant

Quick feedback: I still managed to install the new package and have a quick look. If I understand right, BackPC_Admin in the new package is the binary wrapper program: it should be suid in order to fulfill its role; BackupPC_Admin.cgi does not need to be suid any more.

That is certain. But, before leaving, I did not manage to get to the bottom of things - if my rapid testing is conclusive, my server (lighttpd) configuration expects - and cannot be made not to expect - the wrapper to have a .cgi suffix (in the interim solution that I made work before submitting the bug, I moved the original BackupPC_Admin.cgi to BackupPC_Admin.pl and installed the uid-switching wrapper under the name of BackupPC_Admin.cgi). I need more time to test these things (and I lack competence in configuring a server to be sure about this kind of statement).

I will pick this up when I am back (Sunday).

Here is the present state (backuppc-3.2.0-3.mga1)

1. .cgi suffix (mentioned in my last comment)
---------------------------------------------
As I had suspected, this was my problem: I have figured out how to configure lighttpd to accept a launcher with a name that does not have a suffix.


2. Binary wrapper script
------------------------
- In the Mageia package the (new) binary wrapper script (BackupPC_Admin) comes with mode 0750 - it needs to be su with r and x access for others (04755); ownership backuppc:backuppc is correct.

- The existing launcher (BackupPC_Admin.cgi) comes with su, the su should probably be dropped for security, it is not needed - but works as it is.

I am now using the out-of-the-box new BackupPC_Admin executable - manually modified the mode to 04755 - that works. But:


3. Backuppc configuration
-------------------------
The html pages displayed by backuppc are not correctly formatted - backuppc evidently does not find what they call the "image files" (.css, .gif) i.e. the/var/www/backuppc directory is not recognized. I did not manage to put this right, or to find an explanation (ownership in this directory is - with the exception of the wrapper executables - root, but with read permission for others, that should be OK; I aloso compared that to the working Mandriva setup, same thing there).

I verified the %ENV hash that is passed to BackupPC_Admin.cgi (via the new wrapper) - that looks OK and does not substantially differ from that passed in Mandriva 2010.1 (I will add an attachment with that list). So, the problem does not look like a server-to-backuppc interface issue.

The most likely culprit is the $Conf{CgiImageDirURL} variable (defined in /etc/backuppc/conf.pl). With Mandriva 2010.1, I had left that value at its default value, and it worked. In the Mageia version, I both tried (the documentation is not quite clear, given there is an alias, probably the second value is the one to use)
$Conf{CgiImageDirURL} = "/backuppc";
$Conf{CgiImageDirURL} = "/var/www/backuppc";
Does not make any difference (and I did not forget to restart backuppc after each modification) - looks like backuppc skips this definition - weird.
Note: I left $Conf{CgiCSSFile} = 'BackupPC_stnd.css' at its evidently correct default value.

There appears to be a similar problem when setting the user privileges for administration rights ( $Conf{CgiAdminUserGroup} and $Conf{CgiAdminUsers} ) - whatever I configure into these variables, all users are rejected as non priviledged when they try to access/configure PC-specific data. I can live with that, because backuppc does correctly authorise the users that are configured as owners for the PCs to be backed up (/etc/backuppc/hosts).

So, there appears to be a problem with the configuration file of backuppc, resp. making backuppc recognize certain settings (I do not see how I could have messed up the values - they are evident and the documentation is clear). I did some (maybe to short) googling, did not see any complaints in this area.

Note: I use, essentially, the default backuppc/config.pl, customized by modifying some few specific settings - the same that I always successfully changed in prior releases.


Summary
-------
Backuppc now can be used in Mageia, but with some serious restriction when controlling backuppc via its html interface.

Can I do anything more to help clarifying? I only slept over this one night - maybe that was not enough - enlightenement might still come (-.

I attach:
- a dump with the ENV variables passed to BackupPC_Admin.cgi
- a screenshot of a browser display taken in Mandriva 2010.1
- a corresponding screenshot from Mageiag
- the backuppc/config.pl which I am using

thanks for this detailed report. I will have a further look and ask if I need more information

Created attachment 226 [details]
Environment + path dumped on entry to BackupPC_Admin.cgi

Created attachment 227 [details]
Screenshot of backuppc (server control) on Mandriva 2010.1 (OK)

Created attachment 228 [details]
Screenshot of a backuppc Server control (Mageia) - badly formatted

Created attachment 229 [details]
My customized /etc/backuppc/config.pl

Sorry for this crowd of attachments - just to avoid ping-ponging  questions and answers - And thanks! I realise that backuppc is not an issue of immediate survival.

If I have some spare time, I will try to download and install the most recent tarball - see how that shapes up - time I presently dont have.

If have come to a intermediate milestone, I see somewhat clearer, but am not closer to solving the problem:

1. fixes in backuppc-3.2.0-3.mga1
   - The fixes are not sufficient: the new BackupPC_Admin executable must have
     "su" enabled - chmod 04755 works for me ("works" means: correctly launches
     BackupPC_Admin.cgi)
   - no need to have "su" enabled for BackupPC_Admin.cgi - chmod 0755
     works for me (but is not essential)
   - looking at the tarball, ownership of all files in backkuppc could be
     backuppc rather than root - but again, a question of "finesse" and not
     essential.

   With these changes, the web interface to BackupPC becomes functional, but
   the display of browser pages evidently lacks input of the stylesheet and
   of image files (xx.png, xx.gif, etc.) - not pretty, but gives a working base.

2. The stylesheet and image problem remains
   I did a lot of verifying - checked and rechecked my configuration files in
   backuppc and lighttpd, initially assuming that the files with the stylesheet
   and with the images are not found due to some configuration error on my
   side. I verified, comparing what I get in the (correctly working)
   Mdv 2001.2 setup:
   - the environment variables passed from lighttpd to backuppc are correct
   - the source code of the html pages shown is correct - the browser just 
     does not receive the stylesheet and the images
   - /var/log/lighttpd/access.log shows that (a) the request for - the backuppc
     transaction is correctly received by lighttpd, and launches backuppc
     (b) the GET requests for the stylesheet and image pages is correctly 
     received by lighttpd - although (b) appears in the logfile only when the
     next user-level request to backuppc is launched. /var/log/lighttpd
     /error.log indicates that executing the mod_cgi ends with an error
     "mod_cgi.c.590) cgi died, pid: ...".

   The problem seems to be that, after inserting the launcher executable
     - the BackupPC_Admin script is correctly launched and produces the 
       unformatted html display
     - but after launching, mod_cgi breaks and therefore does not send the
       stylesheet and image files back to the requesting browser
     - the error at line 590 is not the primary problem - it is probably due
       to the fact that /var/log/lighttpd/error.log belongs to user apache,
       but the cgi script now runs as user backuppc (I am not entirely sure
       about this explanation) - setting permissions of the log file to 0666
       makes the line-590 error go away, the primary error is due to incorrect 
       closing of the connection.

       The question is: why does closing the connection fail in the configu-
       ration with the launcher executable, what can be done about that.

    That is as far as I can reasonably go - the problem should be pursued by
    somebody who knows more about servers than I and who has the habit of
    building the server.

Problem solved.
I had in spite of all verifying used a bad configuration item in the server definition of my lighttpd.conf - cgi.assign (following a faulty suggestion found in some web site). Writing things up helped to clarify ideas to essentials.

Backuppc now runs perfect - both the backup part as the web interface

Summary:
- Mageia just needs to produce an update of the backuppc package with corrections
  as suggested in comment 15

I am struggling to get this working with Apache.
I cannot persuade Apache to launch BackupPC_Admin as a script. It just wants to download it as a binary file.

I have tried adding the directive
    <Files BackupPC_Admin>
      ForceType application/x-httpd-cgi
    </Files>

but then mod_mime_magic complains it is an unknown file type.

CC: (none) => derekjenn

I had come on the "binary file" problem with lighttpd too. This is a consequence of the suid-fix:
 - the fix replaces the standard backuppc cgi (BackupPC_Admin.cgi) script by
   a cgi that is a compiled c-program (BackupPC_Admin) where suid is accepted:
   it acts as a wrapper - after being launched with suid it does an execv of 
   the original BackupPC_Admin.cgi
 - standard configurations of lighttpd (and, apparently apache too) are set up
   for cgis that are a script, they complain when the cgi is a binary program

In lighttpd this can be fixed by adding the statement in the server definition:

      cgi.assign = ( "BackupPC_Admin" => "" )

Derek just told me in a PM that he found a corresponding fix for apache server definitions.

I really made a mess of wording in comment #15 - sorry for that. For the record, all that is needed to make the backuppc-3.2.0-3.mga1 package work is to type in a root console (after having installed the package)

   chmod 04755 /var/www/backuppc/BackupPC_Admin
               and
   chmod 0755 /var/www/backuppc/BackupPC_Admin.cgi

There is need for an update package of backuppc that corrects the spec file correspondingly.

I now have backuppc working under Apache.

Necessary changes to backuppc-3.2.0-3.mga1 were

chmod 04755 /var/www/backuppc/BackupPC_Admin
chmod 0755 /var/www/backuppc/BackupPC_Admin.cgi

as described by Juergen, and
also edit /etc/httpd/conf/webapps.d/backuppc.conf to set the handler for BackupPC_Admin

<Directory /var/www/backuppc>
    Options ExecCGI
    <Files BackupPC_Admin>
        SetHandler cgi-script
    </Files>
    DirectoryIndex BackupPC_Admin
    Allow from All
</Directory>

Cheers! no additional corrections to do in the backuppc package beyond the chmod fixes, but an important need to document how the server definition has to be done in apache and in lighttpd.

Suggestion: add a README_Mageia file to the Mageia backuppc package - probably better than and complementary to a potential "howto install backuppc in Mageia" page in the wiki. That would make life much easier for users wanting to configure backuppc into their Mageia system.

Ahmad, does this make sense? should we file a corresponding enhancement bug, or can this be piggy-backed on the present report?

Anyhow, if this is done, the text should be provided by Derek (apache) and myself (lighttpd). Should be short and sweet: packages required, the few backuppc-specific lines to change in the configuration modules - including, in particular the 10 or so lines that define the server.

Hi,

Very useful comments.
To my point of view, the modification for apache in file 
/etc/httpd/conf/webapps.d/backuppc.conf should be added in the next version of Mageia package for BackupPC and the remaining chmod fix as well.
Wiki informations are useful but a plug and play package is even better.

Regards.

Xuo.

CC: (none) => xuoy

The fix for the apache server proposed by Derek (as well as fixes for all the other known issues with backuppc) has been integrated into 3.2.0-4 - an update that is currently going through QA - but which is strictly limited to fixes of documented bugs: an enhancement of the README.mga file will be made in 3.2.1, planned for Mageia 2.

(In reply to comment #22)
> The fix for the apache server proposed by Derek (as well as fixes for all the
> other known issues with backuppc) has been integrated into 3.2.0-4 - an update
> that is currently going through QA

I see no bug report about that one for the QA.

That would be Bug 2736, but it has not been assigned to qa yet.

CC: (none) => davidwhodgins

> That would be Bug 2736, but it has not been assigned to qa yet.

1. Apache fix suggested by Derek: 
It is a problem of this bug (#600) and not #2736. The dys-function of the apache server is a direct consequence of introducing the cgi wrapper, introduced as a first step to fixing #600. There were 2 secondary steps necessary to achieve 100% functionality afterwards: the permission fix (comment #2) and the apache server fix (comment #19). I think that an update that deals with bugzilla #600 must include both fixes.

I tried to make this clear in the log of the spec file, attributing each modification to the corresponding bugzilla number, resp. the comment concerned. I am still in apprenticeship - suggestions how I can facilitate work for QA are welcome.

2. Not yet assigned to QA
Probably an apprentice fault, I will sort this out with my mentor.


PS: there may be an administrative muddle too: I figure as maintainer for #2736, not yet for #600 (I am not yet "ready" from apprenticeship).

backuppc-3.2.0-4.mga1 has been pushed to updates_testing in Mageia 1.

Please someone explain what is to be attended now (QA, status change?).

Yes sure.
"
* Submit to updates testing,
* Do at least some initial QA to check that the application/fix works
*Reassign the bug to qa-bugs@ml.mageia.org (add a comment in the bug with the package version/release at re-assign)
*Write the update announcement"

http://www.mageia.org/wiki/doku.php?id=updates_policy#version_policy ;)

For QA: Backuppc-3.2.0-4.mag1 fixes both bugzilla #600 and #2736

Assignee: bugsquad => qa-bugs

Update was pushed

Status: NEW => RESOLVED
Resolution: (none) => FIXED