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

ons 2014-01-29 klockan 13:29 +1300 skrev Amos Jeffries:

> "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} | "/"

My veiw is just a default squid.conf setting of
pid_filename @DEFAULT_PID_DIRECTORY@/${service_name}.pid

Where DEFAULT_PID_DIRECTORY is defined when running configure, and
${service_name} is the macro expanding servicename.

The rest of the configuration points you talk about is just different
ways of telling configure what the DEFAULT_PID_DIRECTORY path is.
  - explicit
  - derived from prefix
  - whatever other means the user selects
and seriously, none of that matters for this discussion imho.

There should be NO special cases for pid_filename in the code. Just use
the configured path with suitable macro expansions to find the pid path.

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

Problem above is that your DEFAULT_PID_PATH is static, set at configure
time. i.e. hardcoded at build time.

> Benefits:
> * multiple instances with same ./configure can run without clashing on
> .pid
> * multiple instances with default squid.conf can run without clashing
> on .pid
> * base path is configurable by user from squid.conf (via chroot)
> * default path is configurable by distributor (via --prefix or
> --with-pidfile)
> * script/code running Squid is where -n gets set, so if it needs access
> to foo.pid or test.pid separately it already knows whether it ran "-n
> foo" or "-n test".

Same with having a suitable default pid_filename setting using
service_name macro, but giving users full flexibility to change to
whatever scheme they prefer even after running configure.

If people do stupid things in squid.conf sure they will shoot themselves
in the foot. Do we need to care? Having a sane and documented default
setting is sufficient imho.

> So why do we need to configure pid_filename exactly?
> Does a user who is running under their local directory care whether its
> called squid.pid or squid3.pid or test.pid with all the rest of the
> process overlaps being collisions? I don't think so.

A user wanting to run their own instance without being able to recompile
Squid from source does care.

Same reasoning applies to cache_dir paths etc. Why do we need these
configurable in squid.conf? To me it's as obvious that the pid filename
path needs to be fully configurable in squid.conf just as any cache_dir
path needs to be.

The chroot directive is about another thing entirely, and do not even
apply in the use case discussed. Use of chroot requires full control of
the system where Squid runs as Squid MUST be started as root for chroot
to work.

> Perhapse we need to look into providing a lightweight jail/location
> directive to solve that use-case rather than forcing admin to know and
> configure each component path individually.

I don't see it as a problem. All default paths are visible in
squid.conf.documented, and there is clearly visible error messages if
one forgets one.

> * When the admin is running a single instance of Squid with default
> locations for their build. pid_filename is not needed, and not used.

There is always a built-in default.

> * When the admin is running in a different setup to the build defaults.
> pid_filename is a must, and configured. The problem is that "must"
> configure, alongside all other path directives. Squid _works_ but with a
> lot of settings that really should not be mandatory / separate just to
> change location of the entire instance.

Which boils down to providing a settable prefix macro/variable in
squid.conf and have the relevant directives using that in their default
value.

I.e. something like

set name value

to define new squid.conf macros/variables that can be used in following
directives.

Issue with this is how to handle default values with such expansions.
The default squid.conf settings are parsed before squid.conf if I
remember correctly, which means their macro expansions can't rely on
variables set in squid.conf.

service name is from command line and works.

adding a command line option for prefix? Works.

But do we really want easy relocation by a single option/directive? I
don't see a need for it, only issues from it. Having all the paths
easily relocated means the paths are also obfuscated to the causal user.
I.e. instead of pid_filename having a default
of /usr/local/squid/var/squid.pid or /var/run/squid.pid depending on
what binary he looks at it might have ${prefix}/var/squid.pid which
brings the question "what the heck is prefix in this installation?".

So what I am saying is what I said at the top. just have a plain
pid_filename directive, MAYBE with parse time macro expansion of command
line specified service name, and where service name defaults to squid if
not specified.

chroot only needs special handling if one is accessing paths BEFORE the
actual chroot() call. For most purposes it's best to ignore chroot when
talking about paths.

Regards
Henrik
Received on Wed Jan 29 2014 - 20:43:46 MST