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
