Re: changes in head--please don't make some of them permanent...not good

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 20 Jan 2010 15:55:24 +1300

On Tue, 19 Jan 2010 16:58:22 -0800, Linda W <squid-user_at_tlinx.org> wrote:
> I figured out how to get a copy of the head -- not a trivial task given
> that the procedure to get it is broken in multiple places.
>
> When I followed the links to the bzr website and downloaded things it
> gave me bzr-tools 1.6, which refused to work on the grounds that it was
> too hold.
>
> After finding a 2.x, I tried it, and the cbranch command wouldn't work.
>
> I'm not sure what the difference is between cbranch and branch, but
> branch seemed to get me the labeled branch (? or maybe it didn't?) but
> I built it and it got around the compile problem I had with enabling the
> ECAP support.
>
>
>
> Then I ran into some new compatibility issues....and I have some
> comments on them.
>
>
> 1) On starting the new version it threw a new error on ftp_column_width?
> Um...how can we set columns?
>
> 32 is WAY too few. I had mine set to 80...I'm not on a tty, and with a
> proportional font 80 is easily display and most things are not
> truncated. On distro's most files get their names truncated. If that's
> being removed can it be raised to around 80 or more?

You mean the squid.conf setting? It's no longer relevant at all. The FTP
listings are now pure HTML pages. With the filename list scaled by the
displaying browser to fit the available page width. No filenames or text
gets truncated AFAIK.
The filename display space can be altered in the /etc/squid/errorpage.css
file under "special event: FTP / Gopher directory listing" by setting the
"#dirlisting td.filename { width: ... }".

>
> 2) next up was 'group' to run as...I had it set to 'squid'. It died.
> saying it couldn't switch. Not a bit issue, but it shouldn't have
> failed and it shouldn't have died. It is started by startproc as -u
> squid -g squid The items in the config file were 'intelligent defaults
> should the start script get munged -- WHICH it did during the last suse
> upgrade -- only the options in the file kept it running smoothing as
> user/group squid. I prefer redundancy to failure. Nevertheless, squid
> is in group squid and has squid as its primary group, so why it would
> fail to be able to change groups into it I don't know. Either way - it
> should have been able to detect that it was already running as group
> squid and had no problem with not being able to change (if it felt that
> it needed to change even though it was already running in the requested
> group). Bottom line -- it shouldn't have died and shouldn't have needed
> to try switching groups.

Configuring the group is an administrative requirement that group and ONLY
that group be used by Squid. Replacing any permissions the OS has setup
previously.
AFAIK, that has always been the case. There is no change in 3.1 about
that.

>
> 3) there are comments about cache-store being uninterpretable by mortal
> man and could just be turned off -- HOW? When I left it blank it
> defaulted to /var/cache/squid for a dir to write the log in. I tried
> 'none' and thought that worked until this update, when I was told it
> couldn't write to 'none' . I tried 'off' but it couldn't write to off
> either. It really was upset about the empty string "". So trying to
> follow the advice to turn it off -- how does one do that? Darn squid-M5
> -- no off switch!
>

Sorry. But what "cache-store" are you referring to? cache_store_log?
cache_swap_log? cache_dir?

>
> 4) but then it's was confused about who it was running as. I know it
> was running as squid as all the files it was creating and accessing were
> owned by squid.squid, but the error message told me that the files had
> to be owned by user 'nobody'. Neh... I don't think so.
>

squid.conf:
  cache_effective_user squid

or build with
 ./configure --with-default-user=squid

>
> 4...cont...but anyway. it shouldn't have been mentioning 'nobody' when
> it was configured to run as squid by startproc (apparently, I missed
> some compile time option to internally change it to nobody, as my old
> squid.conf had it run as user squid by default, not nobody).
>

If your squid.conf still be cache_effective_user this was probably caused
by the bug in setting the group access privileges (UID/GID are set at the
same time).

>
> and 5...it just up and died because, running as squid, it can't ICMP.
> Well SO WHAT? IT's been running just fine for 5 years without ICMP'ing,
> apparently, so I certainly don't need it to die of a fatal error. It
> might issue a log message, but the default action shouldn't be halt &
> die, if any assumption is wrong, it should be 'try to work'. Users
> prefer things work -- warn them in log files and/or on the console, but
> work!

New bug. Yay :(

>
> Bottom line -- I don't want software that complains about every ache and
> pain. I want software that just works, by default. As I mentioned
> before -- the only reason my squid continued working when Suse updated
> by startup script (or maybe I did it running some update...I don't read
> every script line) was because of the lines in the squid file to tell it
> to run as user.group squid.squid So even when it got root --it did the
> right thing and still ran as squid.squid. I want to keep that ability.

As designed since 2.6 Squid runs two core processes:
  A master started as root whose only job is to receive administrative
controls and make sure a slave process keeps running.
  And a child slave process a nobody/whatever who does all the network
interactions at some unprivileged operation level.

> I don't want it dying because it can't switch from group squid when it
> is already in squid! Now if it was ROOT and it couldn't switch to
> squid, that'd different -- that's a security problem. but if it is a
> unprivileged user and can't switch users -- but all the files are
> accessible -- I wouldn't die. If it was really configured incorrectly,
> the files wouldn't be accessible.
>
> Linda

Amos
Received on Wed Jan 20 2010 - 02:55:28 MST

This archive was generated by hypermail 2.2.0 : Wed Jan 20 2010 - 12:00:06 MST