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

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?

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.

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!

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.

Philosophical bent: I'm from the camp that gives user nobody 'root'
privileges, so any one who runs a daemon as user 'nobody on my system
gets a piece of my mind! (I don't really run user nobody w/root, but
it's the _principle_... If I have all those daemons thinking they are
all user 'nobody', then they can talk to each other and write in each
other space -- and I don't know WHAT daemon is writing or talking to any
other daemon ... can't just ignore them, or they will 'rise up' talking
and 'whispering' behind our backs -- it's called a 'covert channel'.
Heard it on the history channel! :-) I always try to run every daemon
under its own user.group to prohibit any unwanted cross mangling.
Besides, it allows me to put myself in select daemon groups I want to
manage or audit and not need root. And I would feel awful about myself
putting myself in the nobody group (not to mention it might allow me to
mess with things that I don't want to accidently mess with -- just like
running as root all the time might do, but slightly less dangerous).

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

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!

I refer to my experience with 2 utilities last week that unpacked
multipart rar files.

We have the now 'totally free' 7zip, which seems to do the job no matter
what -- to the best of its ability and always seems to do what you want
even if there was a problem (unless it can't recover). Then there's the
commercial product winzip which whines about all sorts of things when it
something goes wrong and makes you press extra buttons or just plain
won't work. Like the last 3 songs in part1 of an 8 part rar archive
were corrupt. 7zip extracted all songs then told me that those 3 songs
were likely corrupt but all the rest had extracted fine. Winzip
encountered the 3 songs and died, refusing to go on. It wouldn't start
at part2, it just wouldn't extract anything because it knew the archive
as a whole was 'corrupt' because of those 3 files.

Guess which utility I intended never to buy another copy of?

Their support people gave me some complex process to recover the
files...but..WHY? Why not just extract them like 7-zip did from 2 years
ago? It uses multi-cores for compression (I've seen it use up to 3),
not winzip, and it's files are 30% smaller than winzip's best
compression. I don't need the aggravation. ...

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.
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
Received on Wed Jan 20 2010 - 01:56:07 MST