Re: [RFC] Squid process model and service name impact

On 01/29/2014 02:00 AM, Amos Jeffries wrote:

> Lets assume for a minute or ten that we all agree with this design and
> start implementing it ...
>
> A default Squid will need the following new directives:
>
> collapsed_forwarding_metadata_shm
> collapsed_forwarding_queues_shm
> collapsed_forwarding_readers_shm
...
> * cache_dir needs to have;
> * a new option added to explicitly configure the path to the disker[...]
> * a new option to link to the shared-memory segment for readers, and
> * a new option to link to the shared-memory segment for writers.
>
>
> Then we get to the UDS sockets...
>
> # assuming that we optimize a bit with a param for the process number
> # for a standard 8-core box with 2 cores for OS & coordinator.
> workers 6
> cordinator_process_uds_path /path/to/coordinator/uds/socket.ipc
> kid_process_uds_path 1 /path/to/kid1/uds/socket.ipc
> kid_process_uds_path 2 /path/to/kid2/uds/socket.ipc
> kid_process_uds_path 3 /path/to/kid3/uds/wheeee.ipc
> kid_process_uds_path 4 /path/to/kid4/uds/socket.ipc
> kid_process_uds_path 5 /path/to/kid5/uds/socket.ipc
> kid_process_uds_path 6 /path/to/kid6/uds/haha.ipc

The kid executable (e.g., disker, coordinator, worker, etc.) path is
already covered by the current Squid executable path.

All others above (and more) can be covered with the following two
options, with reasonable defaults (which may include a service name
component), until we have a need for something more refined:

  shared_memory_dir
  uds_dir

Not bad, IMO!

Furthermore, I think it is a good idea to eventually add a squid.conf
option to overwrite --prefix effects:

  root_dir

> The complaints that have been coming in to me have been that squid.conf
> is too complicated already and simple things (like running under another
> directory would seem to be at first glance) are too hard for both
> newbies and for admin with limited problem-solving time.

Please do not forget that adding implicit default dependencies like
service name inside paths also increases complexity, arguably more so
than adding explicit path options. Nobody has objected to adding service
name components to defaults (AFAIK), but they could use your own
complexity argument against you. That does not invalidate the argument
itself, of course, it just shows that it applies to both alternatives
under consideration. We should not be using that argument because it
does not add value to the debate (unless we invent and agree on a
complexity measure of some kind).

> Driving this entire discussion we so far have just 3 use-cases:

> 1) bug about this not working:
> /sbin/squid -f 1.conf
> /sbin/squid -f 2.conf
>
> NP: the idea of *everything* being in squid.conf is just an idea.

It is not just an idea. It is an ideal :-).

> Already had to customize command-line to get the -f option going.

Bootstrapping will always be a necessary exception to an ideal, of course.

> 2) use-case for admin running squid under a /foo path different
> from the system default ("/fbar").
>
> NP: chroot is available, but apparently a bit strict.

> 3) package distributors wanting OS-specific defaults for:
> - PID file
> - logs directory
> - documentation directory

I have also heard from folks that wanted to place either IPC socket
files or shared memory segment handlers in a special directory that
their appliance designated for such things (with the right permissions,
SELinux capabilities, etc.).

>> - I see nothing wrong with taking an optional parameter to influence
>> the default values of unspecified paths

> Which is pretty much what I am loosly aiming at with -n service_name for
> collision avoidance when everything has the same root path and having
> the rest explicitly in FHS layout below configured-path (chroot).

Yes, the "ideal" approach covers your approach well :-). Voting is not
the same as building consensus, but FWIW, that "ideal" alternative seems
to be now supported by Henrik, Kinkie, Christos, and me:

Aim at configuring every absolute path (or absolute path prefix) via
squid.conf, with convenient option defaults that may depend on other
options.

> PS. If someone wants to create a /var (or /foo/*) layout that does not
> match the FHS (S = standard) layout for these filesystem based objects,
> then please let them come forward with a reason for it.

Personally, I cannot force anybody to come forward, but the reasons I
have heard from such folks are: permissions/capabilities, existing
layout compatibility, and possibly read-only setups. Nothing that cannot
be solved by other means, of course, but that is no different from folks
that want to run concurrent Squid instances without rebuilding Squid.

Cheers,

Alex.
Received on Wed Jan 29 2014 - 17:55:27 MST