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

On 2014-01-30 06:55, Alex Rousskov wrote:
> 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.

What?
  Executable path as I understand it is in .../sbin/ usually.

>
> 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
>

+1. I was hoping chroot would double for that as you can probably tell
from my past posts. Still do, but only if we can do that without
breaking the chroot security properties.

>
>> 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.).
>

Okay. I had not heard that one being brought up yet. Thank you.

Do you have any knowledge whether that differs from the "run" debate
(/var/run vs. /run vs. /tmp/run vs. /opt/run mounting point) between the
major OS FHS implementers?

>
>>> - 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.

Amos
Received on Wed Jan 29 2014 - 22:44:53 MST