Bug 11879 - Piranha web admin tool errors on lvs.cf
Summary: Piranha web admin tool errors on lvs.cf
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: piranha
Version: 6.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Phil Copeland
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-06-03 02:38 UTC by dimambro
Modified: 2008-05-01 15:37 UTC (History)
0 users

Clone Of:
Last Closed: 2000-06-19 22:24:56 UTC

Attachments (Terms of Use)

Description dimambro 2000-06-03 02:38:37 UTC
First time execution of piranha web admin tool gave following message:

There was an error opening or creating the lvs.cf configuration file
The most likely cause is that the file permissions are incorrect.
They should be set as follows

-rw-rw-r--   1 piranha  nobody 0 Mar 1 12:00 /etc/lvs.cf
You can achieve this by issuing the following 3 commands as root
 touch /etc/lvs.cf
 chmod 664 /etc/lvs.cf
 chown piranha.nobody /etc/lvs.cf

I have set permissions and ownership as stated in the above message wil 
negative results.

I found workaround of setting owner to nobody and group to piranha. Now it 

Comment 1 Phil Copeland 2000-07-18 18:32:55 UTC
Piranha was packaged to work out of the box on with a RH install
The default httpd.conf that the apache server installs is below

# User/Group: The name (or #number) of the user/group to run httpd as.
#  . On SCO (ODT 3) use "User nouser" and "Group nogroup".
#  . On HPUX you may not be able to use shared memory as nobody, and the
#    suggested workaround is to create a user www and use that user.
#  NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
#  when the value of (unsigned)Group is above 60000; 
#  don't use Group nobody on these systems!
User nobody
Group nobody

because every file access piranha makes is made with the User/Group access
rights of the web server itself, there is an assumption that it will be

The important thing here was to make sure that the web server would have file
permission rights to alter the lvs.cf file

that is why the permission mask was 664 (-rw-rw-r--) to allow the *group* write

Your assumption of changing the ownerships is mostly correct as the web server
you are running is likely running as user nobody, though your group may be set
as maybe -1 or -2 as opposed to the label nobody


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