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

On 29/01/2014 7:11 p.m., Kinkie wrote:
>> "hard-coded" is being used a bit much here. I don't think any of us are
>> arguing for that.
>> Lets look at the BNF:
>>
>> FOO.pid = chroot pid_filename
>>
>> chroot = {squid.conf chroot} | "/"
>>
>> pid_filename = {squid.conf pid_filename} | DEFAULT_PID_FILE
>>
>> DEFAULT_PID_FILE = {./configure --with-pidfile} | ( PREFIX "/squid.pid" )
>>
>> PREFIX = {./configure --prefix} | "/"
>>
>> We have no less than 4 configuration points for this one file, some of which
>> replace others , and some join unless other has been configured. I am
>> proposing we can do with a simpler setup:
>>
>> FOO.pid = chroot DEFAULT_PID_PATH "/" service_name ".pid"
>>
>> chroot = {squid.conf chroot} | "/"
>>
>> service_name = {squid -n FOO} | "squid"
>>
>> DEFAULT_PID_PATH = {./configure --with-pidfile} | PREFIX
>>
>> PREFIX = {./configure --prefix} | "/"
>>
>> Most of the configuration is in path. The file name part is "static" but
>> configurable via command line with less of the per-worker problems brought
>> in by squid.conf flexibility (chroot still suffers those).
>
>
>
> Sorry for coming in only now, but isn't this a bit limiting?
> I mean, under this proposal there is no way of escaping DEFAULT_PID_PATH..
> I suspect this discussion is starting to transcend the problem it aims to solve.
> I'll get my 2c in:
> IMO it is right for paths to be absolutely configureable in squid.conf.
> At the same time, I see nothing wrong with having a concept of an
> "instance name" which could default to "squid" or to "" when not
> provided. The trick is in trying to make it all self-consistent; then
> legacy comes in to make things complicated.
>
> So, IMO:
> - every possible path should be explicitly configureable in squid.conf
> or command line. We're almost there but not (see shm). When a path is
> fully specified, it overrides everything else.

[sorry in advance for the length]

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

There seem to be a few other components using shared-memory already that
need explicit component enabling (ie rock store, shared-memory
cache_mem). Thanks to Alex hint about GenerateName() I have not had to
test a Squid with them running, so unknown number of .shm paths but
going by CF there will be probably be several for each.

* cache_dir needs to have;
  * a new option added to explicitly configure the path to the disker
process UDS socket when rock type is used, and
  * 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

 # $diety help that admin with a 64-core machine.

Remember in order to get these workers/diskers to communicate, these
sockets MUST be explicitly configured in a way that all processes
needing them are aware of the path. ie. no using ${process_number} or
${process_name} to shrink that config file down!

In future there will also be (at least):

* external_acl_type for shared-memory result cache

* auth_param needs a new option (or two) for the shared-memory username
cache access. And Digest another for nonce caching.

* store-ID result cache shared memory?

* url-rewriter result cache shared memory?

Now, say some admin wants Henriks use-case to run Squid under the path
/foo when its built for path /oops/sorry. How many directives are they
forced to configure? why did they have to? and why are you guys so
adamant this is a good design choice?

Also, how many other components have we not even investigated for
SMP-aware or shared-memory requirements yet?

 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.

I dont even want to think about the squid-users traffic
misconfigurations of any one of these will cause. (To be fully honest
admin misconfiguration pain is a major factor behind my design choices
so far on this whole topic).

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.
   Already had to customize command-line to get the -f option going.

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.
    (worked fine for me testing the -n stuff so far)

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

  NP: ability to patch is present for this case, but if we can help
   them to avoid is good and ./configure options already exist.

> - if needed, we could make config-file parsing a multi-pass affair,
> after all it's not really performance-critical, to have early pickup
> of options which influence later decisions. I suspect the effort would
> be significant, but let's ignore that for now

Ew. just ew.

Yes this *is* a (relatively) critical-path operation. During a
reconfigure the listening ports are down and all active traffic paused
for the duration of squid.conf parsing. We have an occasional complaint
about that and a non-small number of users running squid -k reconfigure
as often as a 60-second cron job.

> - I see nothing wrong with taking an optional parameter to influence
> the default values of unspecified paths to something less hardcoded
> than now. The general structure we use is consistent with GNU
> guidelines, and I would recommend not to change that. At the same
> time, having a "-${servicename}" added to file name defaults when
> servicename is specified by the admin won't hurt .

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

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.

Amos
Received on Wed Jan 29 2014 - 09:00:51 MST