Hi Jacob,
On Wed, Jun 08, 2011 at 08:47:15PM -0400, Jacob Fenwick wrote:
> Willy,
>
> Thanks for your quick response.
>
> I did some experimenting and realized you were right.
> I think my issue why I couldn't run it as anything but root was because I
> was using the -p option to store the pid in /var/run/haproxy.pid, which
> could only accessed by root.
That's a common issue when switching a conf written for root to a non-root
user.
> However, I am still having some problems.
>
> I'm trying to restart haproxy using a Python script that I call from Apache
> using this haproxy command:
> /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -st 4140
I'm assuming that you fixed the "-p /var/run/haproxy.pid" above.
> I'm not exactly sure what I'm doing wrong but I'm getting this error:
> * Starting haproxy haproxy
> [ALERT] 158/203608 (4374) : error when trying to preserve previous UNIX
> socket (/tmp/haproxy). Aborting.
This looks like the global stats socket.
> [ALERT] 158/203608 (4374) : [/usr/sbin/haproxy.main()] Some protocols failed
> to start their listeners! Exiting.
> ...fail!
>
> Before this error I was having some issues that were clearly privilege
> related.
> I've verified that /var/run/haproxy.pid and /tmp/haproxy, which both seem to
> be accessed, both have chmod 777.
It makes no sense to set chmod 777 to such entries, because :
- neither /var/run/haproxy.pid nor the socket needs to be executable
- what is important is not that any user on the system can write to
those files (or sockets) but that you have write access to the
directory hosting them.
In practice, when haproxy tries to remove the pidfile, if it fails, it
silently ignores it provided that it can rewrite the file. But you should
definitely move that pidfile out of /var/run if you intend to run your
process without root permissions.
However, for the stats socket, it *needs* to be able to link/unlink the
old socket. If it fails, it means that you simply don't have the permissions
on /tmp/haproxy. I'm sure that you first started it as root and that you left
/tmp/haproxy owned by root. Whatever the chmod you'll do there will no way
for a non-root user to link/unlink this entry as long as it's owned by root
due to the sticky bit on the /tmp directory.
> Everyone at least has read/write access on /etc/haproxy/haproxy.cfg.
Here again, it makes no sense to give RW access to everyone. It's the worst
thing to do. Some services such as SSH carefully check permissions on their
config files and refuse to start or to accept keys if some files have too
much permission, because they expect those files could have been compromised.
> The user Apache runs the script as is www-data, so I made sure to start
> haproxy with the global parameter user set to www-data.
> Not sure if you have to be the same user as you started it as the first time
> but I assume you do.
You have to remove this global user, because haproxy will not have the
possibility to change it since it's not root. Same for the group.
> Do you know what I could be doing wrong here?
What I'm analysing is that you're trying to make it work with many locations
which are limited to root only, but without root permissions. What you should
*really* do is to make a specific directory which is owned by the www-data
user and put your sockets, pid file etc... there. This directory could very
well be /var/run/haproxy if it helps. The problems you're facing are just
standard unix permissions issues.
Hoping this helps,
Willy
