Re: [BackupPC-users] CGI Script Fails to Run But Actual Text of Script Displays Instead

[Greg Harris]

Apache is not reading the .php files as php, but text.

Thanks,

Greg Harris

On Apr 26, 2020, at 8:22 PM, Akibu Flash  wrote:


I am running an Arch Linux server (5.6.6) for the purpose of backing up several 
Windows 10 machines on a home local area  network.  I have installed the 
package distribution and also Apache with mod_perl support.  Backuppc along 
with Apache are listed as running when I check systemctl status for each.  From 
one of the Windows 10 machines on the network, I am able to access the BackupPC 
server by typing in the backuppc server address appended with /BackupPC_Admin.  
However, I seem to only get the actual text of the script rather than the 
script running.  Any guidance on what I am doing wrong.  I have followed 
https://wiki.archlinux.org/index.php/BackupPC to the letter.  Particularly, I 
have followed the below section regarding single purpose Apache:

Apache configuration

BackupPC has a web interface that allows you to easily control it. You can 
access it using Apache and mod_perl or a C wrapper but other webservers like 
lighttpd works too. Install 
apache from the official 
repositories.

Edit Apache configuration

BackupPC's web UI needs to run as the user backuppc, but Apache normally runs 
under the user http. There are several ways to fix this. The two demonstrated 
here are common for single-purpose servers (Apache is only used to serve the 
BackupPC UI) or for multi-purpose servers (Apache may also server other 
websites under the regular http user).

Setting up Apache for single-purpose use is a bit easier but not as flexible.

General settings

Edit /etc/backuppc/config.pl. Set administrator name:

$Conf{CgiAdminUsers} = 'admin';


Next, we need to add a users file and set the admin password:

# htpasswd -c /etc/backuppc/backuppc.users admin


The BackupPC-Webfrontend is initially configured so that you can only access it 
from the localhost. If you want to access it from all machines in your network, 
you have to edit /etc/httpd/conf/extra/backuppc.conf. Edit the line:

Require ip 127.0.0.1


to:

Require ip 127.0.0.1 192.168.0


where you have to replace 192.168.0 to your corresponding IP-Adresses you want 
to gain access from. After one of the configuration steps below has also been 
performed, [re]start the Apache service.

Single-purpose Apache settings

Install 
mod_perlAUR from the official 
repositories.

Edit the Apache configuration file to load mod_perl, tell Apache to run as user 
backuppc and to include /etc/httpd/conf/extra/backuppc.conf:

/etc/httpd/conf/httpd.conf

 LoadModule perl_module modules/mod_perl.so
 User backuppc
 Group backuppc
 Include conf/extra/backuppc.conf

I assume that it is a simple fix but don't quite know where to begin.  Any 
assistance is appreciated.  Thanks.

Akibu
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

[BackupPC-users] CGI Script Fails to Run But Actual Text of Script Displays Instead

[Akibu Flash]

I am running an Arch Linux server (5.6.6) for the purpose of backing up several 
Windows 10 machines on a home local area  network.  I have installed the 
package distribution and also Apache with mod_perl support.  Backuppc along 
with Apache are listed as running when I check systemctl status for each.  From 
one of the Windows 10 machines on the network, I am able to access the BackupPC 
server by typing in the backuppc server address appended with /BackupPC_Admin.  
However, I seem to only get the actual text of the script rather than the 
script running.  Any guidance on what I am doing wrong.  I have followed 
https://wiki.archlinux.org/index.php/BackupPC to the letter.  Particularly, I 
have followed the below section regarding single purpose Apache:

Apache configuration

BackupPC has a web interface that allows you to easily control it. You can 
access it using Apache and mod_perl or a C wrapper but other webservers like 
lighttpd works too. Install 
apache from the official 
repositories.

Edit Apache configuration

BackupPC's web UI needs to run as the user backuppc, but Apache normally runs 
under the user http. There are several ways to fix this. The two demonstrated 
here are common for single-purpose servers (Apache is only used to serve the 
BackupPC UI) or for multi-purpose servers (Apache may also server other 
websites under the regular http user).

Setting up Apache for single-purpose use is a bit easier but not as flexible.

General settings

Edit /etc/backuppc/config.pl. Set administrator name:

$Conf{CgiAdminUsers} = 'admin';


Next, we need to add a users file and set the admin password:

# htpasswd -c /etc/backuppc/backuppc.users admin


The BackupPC-Webfrontend is initially configured so that you can only access it 
from the localhost. If you want to access it from all machines in your network, 
you have to edit /etc/httpd/conf/extra/backuppc.conf. Edit the line:

Require ip 127.0.0.1


to:

Require ip 127.0.0.1 192.168.0


where you have to replace 192.168.0 to your corresponding IP-Adresses you want 
to gain access from. After one of the configuration steps below has also been 
performed, [re]start the Apache service.

Single-purpose Apache settings

Install 
mod_perlAUR from the official 
repositories.

Edit the Apache configuration file to load mod_perl, tell Apache to run as user 
backuppc and to include /etc/httpd/conf/extra/backuppc.conf:

/etc/httpd/conf/httpd.conf

 LoadModule perl_module modules/mod_perl.so
 User backuppc
 Group backuppc
 Include conf/extra/backuppc.conf

I assume that it is a simple fix but don't quite know where to begin.  Any 
assistance is appreciated.  Thanks.

Akibu
___
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List:https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

Re: [BackupPC-users] full backup ok, incremental fails

[Graham Seaman]

That worked. Thanks for the help!

Graham

On 26/04/2020 17:35, Craig Barratt via BackupPC-users wrote:

Sorry, the correct form should be "$@":

#!/bin/sh -f
exec /bin/tar -c "$@"

(Note that you want to force tar to have the -c option, not exec).

Craig



On Sun, Apr 26, 2020 at 5:14 AM Graham Seaman > wrote:


Hi Craig

I set sudoers to allow backuppc to run tar as root with no
password, and incremental backups work fine.

This is only marginally less secure than the old setup, which
allowed backuppc to run the script which called tar, so I guess I
can live with this.

But in case you have any other ideas, here's my tiny script that's
now definitely what's causing the problem (the quote marks are
double quotes, not two single quotes):

#!/bin/sh -f

exec -c /bin/tar "$*"


Graham


On 26/04/2020 04:09, Craig Barratt via BackupPC-users wrote:

It would be helpful if you included the edited script in your
reply.  Did you use double quotes, or two single quotes?

I'd recommend trying without the script, just the make sure it
works correctly.  Then you can be sure it's an issue with how the
script handles/splits arguments.

Craig

On Sat, Apr 25, 2020 at 2:49 PM Graham Seaman
mailto:gra...@theseamans.net>> wrote:

Craig

Quoting $* gives me a new error:

/bin/tar: invalid option -- ' '

(I get exactly the same error whether I use $incrDate or
$incrDate+)

That script is to avoid potential security problems from
relaxing the rules in sudoers, so I'd rather not get rid of
it, but I'm a bit surprised no-one else has the same problems
(and that it apparently used to work for me once)

Graham


On 25/04/2020 17:59, Craig Barratt via BackupPC-users wrote:

Graham,

Your script is the problem.  Using $* causes the shell the
resplit arguments at whitespace.  To preserve the arguments
you need to put that in quotes:

exec /bin/tar -c "$*"

Craig

On Sat, Apr 25, 2020 at 5:04 AM Graham Seaman
mailto:gra...@theseamans.net>> wrote:

Thanks Craig

That's clearly the problem, but I'm still mystified.

I have backuppc running on my home server; the storage
is on a NAS NFS
mounted on the home server. Backing up other hosts on my
network (both
full and incremental) over rsync works fine.

The home server backs up using tar. The command in the
log is:

Running: /usr/bin/sudo
/etc/backuppc/localtar/tar_create.sh -v -f - -C
/etc --totals --newer=2020-04-22 21:18:10 .

If I set

 $Conf{TarIncrArgs} = '--newer=$incrDate+ $fileList+';


then incremental backups of the home server fail with:

/bin/tar: Substituting -9223372036854775807 for unknown
date format
‘2020-04-22\\’
/bin/tar: 21\:18\:10: Cannot stat: No such file or directory

If instead I set:

$Conf{TarIncrArgs} = '--newer=$incrDate $fileList';

then incremental backups fail with:

/bin/tar: Option --after-date: Treating date
'2020-04-22' as 2020-04-22
00:00:00
/bin/tar: 21\:18\:10: Cannot stat: No such file or directory

Could it be to do with my localtar/tar_create.sh? (I
created this so
long ago I no longer remember where it came from).

This is just:

#!/bin/sh -f
exec /bin/tar -c $*

Thanks again

Graham

On 25/04/2020 02:59, Craig Barratt via BackupPC-users wrote:
> Graham,
>
> This is a problem with shell (likely ssh) escaping of
arguments that
> contain a space.
>
> For incremental backups a timestamp is passed as an
argument to tar
> running on the client.  The argument should be a date
and time, eg:
>
>     --after-date 2020-04-22\ 21:18:10'
>
> Notice there needs to be a backslash before the space,
so it is part of
> a single argument, not two separate arguments.
>
> You can tell BackupPC to escape an argument (to
protect it from passing
> via ssh) by adding a "+" to the end of the argument
name, eg:
>
>     $Conf{TarIncrArgs} = '--newer=$incrDate+ $fileList+';
>
>
> Craig
>
> On Fri, Apr 24, 2020 at 3:17 PM Graham Seaman
mailto:gra...@theseamans.net>
> 

Re: [BackupPC-users] full backup ok, incremental fails

[Craig Barratt via BackupPC-users]

Sorry, the correct form should be "$@":

#!/bin/sh -f
exec /bin/tar -c "$@"

(Note that you want to force tar to have the -c option, not exec).

Craig



On Sun, Apr 26, 2020 at 5:14 AM Graham Seaman  wrote:

> Hi Craig
>
> I set sudoers to allow backuppc to run tar as root with no password, and
> incremental backups work fine.
>
> This is only marginally less secure than the old setup, which allowed
> backuppc to run the script which called tar, so I guess I can live with
> this.
>
> But in case you have any other ideas, here's my tiny script that's now
> definitely what's causing the problem (the quote marks are double quotes,
> not two single quotes):
>
> #!/bin/sh -f
>
> exec -c /bin/tar "$*"
>
>
> Graham
>
>
> On 26/04/2020 04:09, Craig Barratt via BackupPC-users wrote:
>
> It would be helpful if you included the edited script in your reply.  Did
> you use double quotes, or two single quotes?
>
> I'd recommend trying without the script, just the make sure it works
> correctly.  Then you can be sure it's an issue with how the script
> handles/splits arguments.
>
> Craig
>
> On Sat, Apr 25, 2020 at 2:49 PM Graham Seaman 
> wrote:
>
>> Craig
>>
>> Quoting $* gives me a new error:
>>
>> /bin/tar: invalid option -- ' '
>>
>> (I get exactly the same error whether I use $incrDate or $incrDate+)
>>
>> That script is to avoid potential security problems from relaxing the
>> rules in sudoers, so I'd rather not get rid of it, but I'm a bit surprised
>> no-one else has the same problems (and that it apparently used to work for
>> me once)
>>
>> Graham
>>
>>
>> On 25/04/2020 17:59, Craig Barratt via BackupPC-users wrote:
>>
>> Graham,
>>
>> Your script is the problem.  Using $* causes the shell the resplit
>> arguments at whitespace.  To preserve the arguments you need to put that in
>> quotes:
>>
>> exec /bin/tar -c "$*"
>>
>> Craig
>>
>> On Sat, Apr 25, 2020 at 5:04 AM Graham Seaman 
>> wrote:
>>
>>> Thanks Craig
>>>
>>> That's clearly the problem, but I'm still mystified.
>>>
>>> I have backuppc running on my home server; the storage is on a NAS NFS
>>> mounted on the home server. Backing up other hosts on my network (both
>>> full and incremental) over rsync works fine.
>>>
>>> The home server backs up using tar. The command in the log is:
>>>
>>> Running: /usr/bin/sudo /etc/backuppc/localtar/tar_create.sh -v -f - -C
>>> /etc --totals --newer=2020-04-22 21:18:10 .
>>>
>>> If I set
>>>
>>>  $Conf{TarIncrArgs} = '--newer=$incrDate+ $fileList+';
>>>
>>>
>>> then incremental backups of the home server fail with:
>>>
>>> /bin/tar: Substituting -9223372036854775807 for unknown date format
>>> ‘2020-04-22\\’
>>> /bin/tar: 21\:18\:10: Cannot stat: No such file or directory
>>>
>>> If instead I set:
>>>
>>> $Conf{TarIncrArgs} = '--newer=$incrDate $fileList';
>>>
>>> then incremental backups fail with:
>>>
>>> /bin/tar: Option --after-date: Treating date '2020-04-22' as 2020-04-22
>>> 00:00:00
>>> /bin/tar: 21\:18\:10: Cannot stat: No such file or directory
>>>
>>> Could it be to do with my localtar/tar_create.sh? (I created this so
>>> long ago I no longer remember where it came from).
>>>
>>> This is just:
>>>
>>> #!/bin/sh -f
>>> exec /bin/tar -c $*
>>>
>>> Thanks again
>>>
>>> Graham
>>>
>>> On 25/04/2020 02:59, Craig Barratt via BackupPC-users wrote:
>>> > Graham,
>>> >
>>> > This is a problem with shell (likely ssh) escaping of arguments that
>>> > contain a space.
>>> >
>>> > For incremental backups a timestamp is passed as an argument to tar
>>> > running on the client.  The argument should be a date and time, eg:
>>> >
>>> > --after-date 2020-04-22\ 21:18:10'
>>> >
>>> > Notice there needs to be a backslash before the space, so it is part of
>>> > a single argument, not two separate arguments.
>>> >
>>> > You can tell BackupPC to escape an argument (to protect it from passing
>>> > via ssh) by adding a "+" to the end of the argument name, eg:
>>> >
>>> > $Conf{TarIncrArgs} = '--newer=$incrDate+ $fileList+';
>>> >
>>> >
>>> > Craig
>>> >
>>> > On Fri, Apr 24, 2020 at 3:17 PM Graham Seaman >> > > wrote:
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Ok, I guess its this (from the start of XferLOG.bad):
>>> >
>>> > /bin/tar: Option --after-date: Treating date '2020-04-22' as
>>> 2020-04-22
>>> > 00:00:00
>>> > /bin/tar: 21\:18\:10: Cannot stat: No such file or directory
>>> >
>>> > which is kind of confusing, as it goes on to copy the rest of the
>>> > directory and then says '0 Errors'. Anyway, its correct that there
>>> is no
>>> > file called '21:18:10'. Any idea why it thinks there should be?
>>> >
>>> > Graham
>>> >
>>> >
>>> > On 24/04/2020 20:59, Craig Barratt via BackupPC-users wrote:
>>> > > Graham,
>>> > >
>>> > > Tar exit status of 512 means it encountered some sort of error
>>> > (eg, file
>>> > > read error) while it was running on the target client.  Please
>>> look at
>>> > > the XferLOG.bad 

Re: [BackupPC-users] full backup ok, incremental fails

[Graham Seaman]

Hi Craig

I set sudoers to allow backuppc to run tar as root with no password, and 
incremental backups work fine.


This is only marginally less secure than the old setup, which allowed 
backuppc to run the script which called tar, so I guess I can live with 
this.


But in case you have any other ideas, here's my tiny script that's now 
definitely what's causing the problem (the quote marks are double 
quotes, not two single quotes):


#!/bin/sh -f

exec -c /bin/tar "$*"


Graham


On 26/04/2020 04:09, Craig Barratt via BackupPC-users wrote:
It would be helpful if you included the edited script in your reply.  
Did you use double quotes, or two single quotes?


I'd recommend trying without the script, just the make sure it works 
correctly.  Then you can be sure it's an issue with how the script 
handles/splits arguments.


Craig

On Sat, Apr 25, 2020 at 2:49 PM Graham Seaman > wrote:


Craig

Quoting $* gives me a new error:

/bin/tar: invalid option -- ' '

(I get exactly the same error whether I use $incrDate or $incrDate+)

That script is to avoid potential security problems from relaxing
the rules in sudoers, so I'd rather not get rid of it, but I'm a
bit surprised no-one else has the same problems (and that it
apparently used to work for me once)

Graham


On 25/04/2020 17:59, Craig Barratt via BackupPC-users wrote:

Graham,

Your script is the problem.  Using $* causes the shell the
resplit arguments at whitespace.  To preserve the arguments you
need to put that in quotes:

exec /bin/tar -c "$*"

Craig

On Sat, Apr 25, 2020 at 5:04 AM Graham Seaman
mailto:gra...@theseamans.net>> wrote:

Thanks Craig

That's clearly the problem, but I'm still mystified.

I have backuppc running on my home server; the storage is on
a NAS NFS
mounted on the home server. Backing up other hosts on my
network (both
full and incremental) over rsync works fine.

The home server backs up using tar. The command in the log is:

Running: /usr/bin/sudo /etc/backuppc/localtar/tar_create.sh
-v -f - -C
/etc --totals --newer=2020-04-22 21:18:10 .

If I set

 $Conf{TarIncrArgs} = '--newer=$incrDate+ $fileList+';


then incremental backups of the home server fail with:

/bin/tar: Substituting -9223372036854775807 for unknown date
format
‘2020-04-22\\’
/bin/tar: 21\:18\:10: Cannot stat: No such file or directory

If instead I set:

$Conf{TarIncrArgs} = '--newer=$incrDate $fileList';

then incremental backups fail with:

/bin/tar: Option --after-date: Treating date '2020-04-22' as
2020-04-22
00:00:00
/bin/tar: 21\:18\:10: Cannot stat: No such file or directory

Could it be to do with my localtar/tar_create.sh? (I created
this so
long ago I no longer remember where it came from).

This is just:

#!/bin/sh -f
exec /bin/tar -c $*

Thanks again

Graham

On 25/04/2020 02:59, Craig Barratt via BackupPC-users wrote:
> Graham,
>
> This is a problem with shell (likely ssh) escaping of
arguments that
> contain a space.
>
> For incremental backups a timestamp is passed as an
argument to tar
> running on the client.  The argument should be a date and
time, eg:
>
>     --after-date 2020-04-22\ 21:18:10'
>
> Notice there needs to be a backslash before the space, so
it is part of
> a single argument, not two separate arguments.
>
> You can tell BackupPC to escape an argument (to protect it
from passing
> via ssh) by adding a "+" to the end of the argument name, eg:
>
>     $Conf{TarIncrArgs} = '--newer=$incrDate+ $fileList+';
>
>
> Craig
>
> On Fri, Apr 24, 2020 at 3:17 PM Graham Seaman
mailto:gra...@theseamans.net>
> >> wrote:
>
>
>
>
>
>
>
>
>     Ok, I guess its this (from the start of XferLOG.bad):
>
>     /bin/tar: Option --after-date: Treating date
'2020-04-22' as 2020-04-22
>     00:00:00
>     /bin/tar: 21\:18\:10: Cannot stat: No such file or
directory
>
>     which is kind of confusing, as it goes on to copy the
rest of the
>     directory and then says '0 Errors'. Anyway, its correct
that there is no
>     file called '21:18:10'. Any idea why it thinks there
should be?
>
>     Graham
>
>
>     On 24/04/2020 20:59, Craig Barratt via BackupPC-users