Thank you so much for the help.
So, I use the directive 'chroot' in the squid.conf.How I told you before, if I do: chroot /etc/squid-3.5.6 libexec/basic_ncsa_auth it runs, that's why I'm sure that basic_ncsa_auth it's running correctly, I suspect maybe this IPCcreate run as another user that cannot access the basic_ncsa_auth or maybe IPCcreate its located in a directory that cannot see the libexec/basice_ncsa relative path
That's a weird scenario.
2015-07-24 11:02 GMT-03:00 Amos Jeffries <squid3@xxxxxxxxxxxxx>:
On 25/07/2015 12:10 a.m., Jorgeley Junior wrote:
> please guys, help me.
> Any suggestions?
>
Squid is not generally run in a chroot. The master / coordinator daemon
manager process requires root access for several things and spawns
workers that are dropped automatically to highly restricted access
anyway. You already found out how big the dependency pool of libraries is.
I guess what I'm getting at is that this is a rarely tested situation.
To complicate matters there are three different combinations of "chroot"
that Squid can run.
* External chroot. Where you enter the chroot before starting Squid and
it thinks the chroot content is the whole system.
* configured chroot. Where you configure Squid master process to chroot
its low-privilege workers with the squid.conf chroot directive.
* Linux containers. Similar to the first, but you dont have to copy
files into a separate chroot area. Just assign visibility/access to the
OS areas.
The error is pretty clear though. The problem is that something is
unable to load a file during helper startup.
Either Squid is unable to read/open/see the helper binary file itself.
Or the helper is unable to open a file it needs to operate.
"ipcCreate:" is a big hint that its Squid not finding the helper binary
named.
So is Squid being run from inside the chroot, or using "chroot"
directive in squid.conf?
Amos
--
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
