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
