Discussion:
[BackupPC-users] Can not get Web interface to work
Kevin Fries
2004-05-18 16:37:00 UTC
Permalink
I am not being able to get the web interface to come up. When I first
pull it up, it asks me for a username and password. If I supply
incorrect username and password that does not exist in my LDAP server,
it fails like it should. Once I supply valid credentials, I get:

*Error: Unable to read config.pl or language strings!!

*Ughhhhh, can anyone help me? I have it set up on apache 2 on a Fedora
Core 2 machine set up with the standard setup. When the program set up,
it kept trying ot set everything to username backuppc and a group of
503. I thought this may be the problem, so I changed all the 503 to
group apache so the web server can read the files. This did not work.

I also checked to see if the sperl was installed, and it came up with
something, but not what the instructions said it should.... However, the
script runs, so I am not sure if this is the problem. Here is what I
get when checking for sperl:

[***@Ruby BackupPC]# find / | grep sperl
/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/sperl.o
[***@Ruby BackupPC]#

All help greatly appreciated
--
Kevin Fries
Network Administrator
Hydrologic Consultants, Inc of Colorado
(303) 969-8033 FAX: (303) 969-8357
Ben
2004-05-19 02:22:08 UTC
Permalink
Have you tried checking the permissions on config.pl? It needs to be the
same permission that the web server runs as.

I don't think it has to do with your apache/perl setup, as it probably
would have come back with an internal server error.
Post by Kevin Fries
I am not being able to get the web interface to come up. When I first
pull it up, it asks me for a username and password. If I supply
incorrect username and password that does not exist in my LDAP server,
Error: Unable to read config.pl or language strings!!
Ughhhhh, can anyone help me? I have it set up on apache 2 on a Fedora
Core 2 machine set up with the standard setup. When the program set
up, it kept trying ot set everything to username backuppc and a group
of 503. I thought this may be the problem, so I changed all the 503
to group apache so the web server can read the files. This did not
work.
I also checked to see if the sperl was installed, and it came up with
something, but not what the instructions said it should.... However,
the script runs, so I am not sure if this is the problem. Here is
/usr/lib/perl5/5.8.3/i386-linux-thread-multi/CORE/sperl.o
All help greatly appreciated
--
Kevin Fries
Network Administrator
Hydrologic Consultants, Inc of Colorado
(303) 969-8033 FAX: (303) 969-8357
Kevin Fries
2004-05-19 02:46:01 UTC
Permalink
Post by Ben
Have you tried checking the permissions on config.pl? It needs to be the
same permission that the web server runs as.
I don't think it has to do with your apache/perl setup, as it probably
would have come back with an internal server error.
My permissions are as follows:

[***@Ruby /]# ls -la /home/backuppc/conf
total 57
drwxr-x--- 2 backuppc apache 104 May 18 12:05 .
drwxr-x--- 8 backuppc 503 192 May 17 13:48 ..
-rw-r----- 1 backuppc apache 50523 May 18 12:05 config.pl
-rw-r--r-- 1 backuppc apache 2250 May 17 14:01 hosts
[***@Ruby /]# ls -la /var/www/cgi-bin/
total 84
drwxr-xr-x 2 root root 4096 May 17 16:36 .
drwxr-xr-x 8 root root 4096 May 16 17:07 ..
-r-xr-xr-- 1 backuppc apache 67492 May 17 13:48 BackupPC_Admin
[***@Ruby /]# ls -la /usr/local/BackupPC/lib/BackupPC/Lang/
total 148
drwxr-xr-x 2 backuppc apache 4096 May 17 13:48 .
drwxr-xr-x 5 root root 4096 May 17 13:48 ..
-r--r--r-- 1 backuppc apache 35664 May 17 13:48 de.pm
-r--r--r-- 1 backuppc apache 32472 May 17 13:48 en.pm
-r--r--r-- 1 backuppc apache 35372 May 17 13:48 es.pm
-r--r--r-- 1 backuppc apache 36137 May 17 13:48 fr.pm
[***@Ruby /]#

server runs as apache:apache. That was the first thing I checked, so that
explains why I am so confused.

BTW, a full backup is running tonight very successfully. So the program is
working great, now I just need to allow my users access to the file.

---
Kevin Fries
Network Administrator
Hydrologic Consultants, Inc of Colorado
(303) 969-8033 FAX: (303) 969-8357
Ben
2004-05-19 02:55:05 UTC
Permalink
I still think it's a permissions problem. Try getting apache to run as
the backuppc user - this is what I did to get it working.
Post by Kevin Fries
Post by Ben
Have you tried checking the permissions on config.pl? It needs to be the
same permission that the web server runs as.
I don't think it has to do with your apache/perl setup, as it probably
would have come back with an internal server error.
total 57
drwxr-x--- 2 backuppc apache 104 May 18 12:05 .
drwxr-x--- 8 backuppc 503 192 May 17 13:48 ..
-rw-r----- 1 backuppc apache 50523 May 18 12:05 config.pl
-rw-r--r-- 1 backuppc apache 2250 May 17 14:01 hosts
total 84
drwxr-xr-x 2 root root 4096 May 17 16:36 .
drwxr-xr-x 8 root root 4096 May 16 17:07 ..
-r-xr-xr-- 1 backuppc apache 67492 May 17 13:48 BackupPC_Admin
total 148
drwxr-xr-x 2 backuppc apache 4096 May 17 13:48 .
drwxr-xr-x 5 root root 4096 May 17 13:48 ..
-r--r--r-- 1 backuppc apache 35664 May 17 13:48 de.pm
-r--r--r-- 1 backuppc apache 32472 May 17 13:48 en.pm
-r--r--r-- 1 backuppc apache 35372 May 17 13:48 es.pm
-r--r--r-- 1 backuppc apache 36137 May 17 13:48 fr.pm
server runs as apache:apache. That was the first thing I checked, so that
explains why I am so confused.
BTW, a full backup is running tonight very successfully. So the program is
working great, now I just need to allow my users access to the file.
---
Kevin Fries
Network Administrator
Hydrologic Consultants, Inc of Colorado
(303) 969-8033 FAX: (303) 969-8357
-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
BackupPC-users mailing list
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
Craig Barratt
2004-05-19 03:05:03 UTC
Permalink
Post by Kevin Fries
Post by Ben
Have you tried checking the permissions on config.pl? It needs to be the
same permission that the web server runs as.
I don't think it has to do with your apache/perl setup, as it probably
would have come back with an internal server error.
total 57
drwxr-x--- 2 backuppc apache 104 May 18 12:05 .
drwxr-x--- 8 backuppc 503 192 May 17 13:48 ..
-rw-r----- 1 backuppc apache 50523 May 18 12:05 config.pl
-rw-r--r-- 1 backuppc apache 2250 May 17 14:01 hosts
You might have a problem with /home/backuppc. It's gid is 503,
which I assume is not apache, so I suspect apache can't read
/home/backuppc.

Try this:

su apache
wc /home/backuppc/conf/config.pl
Post by Kevin Fries
total 84
drwxr-xr-x 2 root root 4096 May 17 16:36 .
drwxr-xr-x 8 root root 4096 May 16 17:07 ..
-r-xr-xr-- 1 backuppc apache 67492 May 17 13:48 BackupPC_Admin
total 148
drwxr-xr-x 2 backuppc apache 4096 May 17 13:48 .
drwxr-xr-x 5 root root 4096 May 17 13:48 ..
-r--r--r-- 1 backuppc apache 35664 May 17 13:48 de.pm
-r--r--r-- 1 backuppc apache 32472 May 17 13:48 en.pm
-r--r--r-- 1 backuppc apache 35372 May 17 13:48 es.pm
-r--r--r-- 1 backuppc apache 36137 May 17 13:48 fr.pm
server runs as apache:apache. That was the first thing I checked, so that
explains why I am so confused.
I notice you are not running BackupPC_Admin as user backuppc. For
BackupPC_Admin to be able to browse backups the entire pool will
also need to be group apache and group readable. Assuming you have
done this, thing should work correctly. But then *any* CGI script
can read any of the backup files, so make sure that regular users
cannot install their own CGI scripts. Any you will probably need
to put user backuppc into group apache.
Post by Kevin Fries
BTW, a full backup is running tonight very successfully. So the program is
working great, now I just need to allow my users access to the file.
That would be a good thing...

Craig
Kevin Fries
2004-05-19 04:00:07 UTC
Permalink
Backups are fine, its just the web interface that is an issue. I checked
the pc folder and there is a new 7GB backup of the only PC currently
configured (others will be added tomorrow).
Post by Craig Barratt
Post by Kevin Fries
Post by Ben
Have you tried checking the permissions on config.pl? It needs to be the
same permission that the web server runs as.
I don't think it has to do with your apache/perl setup, as it probably
would have come back with an internal server error.
total 57
drwxr-x--- 2 backuppc apache 104 May 18 12:05 .
drwxr-x--- 8 backuppc 503 192 May 17 13:48 ..
-rw-r----- 1 backuppc apache 50523 May 18 12:05 config.pl
-rw-r--r-- 1 backuppc apache 2250 May 17 14:01 hosts
You might have a problem with /home/backuppc. It's gid is 503,
which I assume is not apache, so I suspect apache can't read
/home/backuppc.
su apache
wc /home/backuppc/conf/config.pl
This will not work on my machine since apache does not have a valid shell, I
could not even issue a "su apache -c 'wc /home/backuppc/conf/config.pl'"
command. I just get account unavailable.... hmmm now that I think about
this, a little further, does CGI require the creation of a shell?
Post by Craig Barratt
I notice you are not running BackupPC_Admin as user backuppc. For
BackupPC_Admin to be able to browse backups the entire pool will
also need to be group apache and group readable. Assuming you have
done this, thing should work correctly. But then *any* CGI script
can read any of the backup files, so make sure that regular users
cannot install their own CGI scripts. Any you will probably need
to put user backuppc into group apache.
Not an issue. All the files are mode 750 with ownership = backuppc:apache.
I am not concerned about other CGIs, having access. This machine will only
run two web based applications, both are internal personnel only: this; and
eGroupware. I will be the only ligitimate user with the root password, or
access to the cgi-bin directory. So allowing the server access to the files
is less of an issue. These backups are of Windows machines, it would be
easier to hack those machines than it would be to hack my linux box, gain
access to the apache or root accounts so that they can write to the cgi-bin
folder to gain access to our backups via a web interface.
Carl Wilhelm Soderstrom
2004-05-19 12:46:02 UTC
Permalink
Post by Kevin Fries
Post by Craig Barratt
su apache
wc /home/backuppc/conf/config.pl
This will not work on my machine since apache does not have a valid shell,
su - apache -s /bin/bash

the '-s' specifies the shell to use.
the '-' is short for '-l' and means to do a full login; which sets up all
the environment variables just like a regular login. (just like doing 'su -'
to become root, instead of 'su').

Carl Soderstrom.
--
Systems Administrator
Real-Time Enterprises
www.real-time.com
Craig Barratt
2004-05-19 04:12:04 UTC
Permalink
Post by Kevin Fries
Backups are fine, its just the web interface that is an issue. I checked
the pc folder and there is a new 7GB backup of the only PC currently
configured (others will be added tomorrow).
Ok.
Post by Kevin Fries
Post by Craig Barratt
Post by Kevin Fries
total 57
drwxr-x--- 2 backuppc apache 104 May 18 12:05 .
drwxr-x--- 8 backuppc 503 192 May 17 13:48 ..
-rw-r----- 1 backuppc apache 50523 May 18 12:05 config.pl
-rw-r--r-- 1 backuppc apache 2250 May 17 14:01 hosts
You might have a problem with /home/backuppc. It's gid is 503,
which I assume is not apache, so I suspect apache can't read
/home/backuppc.
su apache
wc /home/backuppc/conf/config.pl
This will not work on my machine since apache does not have a valid shell, I
could not even issue a "su apache -c 'wc /home/backuppc/conf/config.pl'"
command. I just get account unavailable.... hmmm now that I think about
this, a little further, does CGI require the creation of a shell?
The CGI is working fine since you get a well-formed page (even though it
has an error about not being able to read config/language strings).

But it still looks like /home/backuppc has the wrong group, so apache
cannot access anything below there. Please make sure /home/backuppc
is backuppc:apache, not backuppc:503. Also verify /home is o+rx so
apache can get below there too.

Craig
Kevin Fries
2004-05-19 15:37:02 UTC
Permalink
Post by Craig Barratt
The CGI is working fine since you get a well-formed page (even though it
has an error about not being able to read config/language strings).
But it still looks like /home/backuppc has the wrong group, so apache
cannot access anything below there. Please make sure /home/backuppc
is backuppc:apache, not backuppc:503. Also verify /home is o+rx so
apache can get below there too.
Craig
Thanks to all that helped, but I got it running. Here is what I did:

Fixed that /home/backuppc to be bacuppc:apache

Ran the CGI again, and it started complaining that the user was 48 (apache)
instead of 78 (backuppc). Having had enough, it was time to do what I was
trying hard to avoid, and just get it working. I changed the port to 8080,
the httpd thread owner to backuppc and the thread group to backuppc. Once I
restarted Apache, the page worked exactly as advertised.

The problem seems to be in the SUID part of perl. It apparently is not
working correctly in Fedora Core 2.

Until I can figure out how to make SUID to work correctly, I will simply
have to run two web servers... such a waste.

On the positive side, my users got the first look at the new backup system,
and they are wonderfully impressed.... Thanks to the maintainers, this is an
awesome application. Putting this as a set of RPMs (one for backup, one for
the web interface) and added into newer distros like Fedora would really go
along way to helping the cause. Find me a low cost alternative to this
program for Windows.... This is the type of application that helps convince
Windows admins to bite the bullet and deploy a Linux box. Great Work Guys!
Les Mikesell
2004-05-19 15:57:06 UTC
Permalink
Post by Kevin Fries
The problem seems to be in the SUID part of perl. It apparently is not
working correctly in Fedora Core 2.
Maybe it isn't installed. Try:
yum install perl-suidperl
Post by Kevin Fries
Until I can figure out how to make SUID to work correctly, I will simply
have to run two web servers... such a waste.
Two instances of the same program will share a copy of the executable
code in memory, so it isn't as wasteful as you might think.
---
Les Mikesell
***@futuresource.com
Doug Lytle
2004-05-19 16:15:10 UTC
Permalink
Kevin,

I've always ran BackupPC as user apache. No problems to date.

Doug
Post by Craig Barratt
The CGI is working fine since you get a well-formed page (even though it
has an error about not being able to read config/language strings).
But it still looks like /home/backuppc has the wrong group, so apache
cannot access anything below there. Please make sure /home/backuppc
is backuppc:apache, not backuppc:503. Also verify /home is o+rx so
apache can get below there too.
Craig
Craig Barratt
2004-05-19 18:59:05 UTC
Permalink
Post by Kevin Fries
Post by Craig Barratt
The CGI is working fine since you get a well-formed page (even though it
has an error about not being able to read config/language strings).
But it still looks like /home/backuppc has the wrong group, so apache
cannot access anything below there. Please make sure /home/backuppc
is backuppc:apache, not backuppc:503. Also verify /home is o+rx so
apache can get below there too.
Craig
Fixed that /home/backuppc to be bacuppc:apache
Ran the CGI again, and it started complaining that the user was 48 (apache)
instead of 78 (backuppc). Having had enough, it was time to do what I was
trying hard to avoid, and just get it working. I changed the port to 8080,
the httpd thread owner to backuppc and the thread group to backuppc. Once I
restarted Apache, the page worked exactly as advertised.
You could have set $Conf{BackupPCUserVerify} = 0 to turn off the
BackupPC user check, but the risk is that the first time you
inadvertently run, for example, BackupPC or BackupPC_dump manually
to debug a problem you could create many files owned by the wrong
user (eg: root), which might not be accessible by BackupPC.

Perhaps I need a $Conf{BackupPCCGIUser} in addition to $Conf{BackupPCUser}?
But there are already too many config options so I think not.
Post by Kevin Fries
The problem seems to be in the SUID part of perl. It apparently is not
working correctly in Fedora Core 2.
Until I can figure out how to make SUID to work correctly, I will simply
have to run two web servers... such a waste.
Perl goes to great lengths to make suid secure and therefore hard
to setup. In particular, perl must be configured with the "emulate
suid" question answered with a "yes". This creates the sperl wrapper.
It's possible that this is not enabled on Fedora. The other trap is
the nosuid mount option will disable any suid program. Some of this
is in the docs.
Post by Kevin Fries
On the positive side, my users got the first look at the new backup system,
and they are wonderfully impressed.... Thanks to the maintainers, this is an
awesome application. Putting this as a set of RPMs (one for backup, one for
the web interface) and added into newer distros like Fedora would really go
along way to helping the cause. Find me a low cost alternative to this
program for Windows.... This is the type of application that helps convince
Windows admins to bite the bullet and deploy a Linux box. Great Work Guys!
Thanks!

Craig

Continue reading on narkive:
Loading...