suggestions.. :)

Hi

I am working through squid "from basics" again for a Squid-related project.

I think that over the next 6 months or so there will be lots of mail like
this.

Most of the stuff in the mail messages is about stuff that isn't
immediately obvious to the "new squid user", and will make the setup of a
new cache difficult. The rest is just "silly question" stuff.

If you think that something is a good idea, please say so. If you have some
spare time, please think of fiddling things like the below - most of them
are very straight forward. If I think that something is a real problem I will
change something, and my hope is that if people vote "yes, that's a good
idea", then Duane will include it in the next patch. You can't expect
someone who is intimate with every like of Squid code to see things from
a new user's perspective. I am rediscovering all sorts of niggles that I
had completely forgotten about.

These aren't bugs, really, more niggles. As niggles I don't expect people
to agree with every one, so please vote, or vote by implementing! I really,
really don't have time to do all of these things... the project is all
after-hours stuff, and is going to take all of my time... believe me. I believe
that there will be a benefit for squid as large as doing the coding for the
below.

Silly Question:

If /usr/local/squid/bin/* are executable only by root, and the
effective_user_id is set to 'squid' or 'nobody', will squid be able to
restart the dnsservers?

Suggestions:

1) squid -z creates a swap.state that has a flag indicating not to
        re-create the store, and also to init the cache-digest to
        all 0's. the cache-digest creation slows things to a crawl
        on startup.

        My rc scripts actually re-make the squid filesystem on a
        reboot... since I only reboot when the whole system
        crashes I don't care if the hit rate is a little lower for
        a while. I then call squid -z.

        The problem with digests is that squid crawls for minutes on
        slow systems after startup with an absolutely clean cache.

        'squid -z0' could, for example, create a completely empty
        swap state file, while a plain '-z' could simply make all the
        directories.

        This flag could also stop Squid from rebuilding the directory
        store with "storeRebuildFromDirectory".

2) When running squid -z with /usr/local owned by root, and
        not readable by the user set in effective_user_id, the error
        message isn't very useful to someone that has very little Unix
        knowledge. We want to be user-friendly enough for NT users with
        very little Unix experience to use Squid (since it's the best
        software out :).

        What would be ideal is to 'walk the tree' up towards the final
        cache_dir, and see when we actually cannot access the directory (is
        the 'x' bit set for me?) and print a message saying something like
        "the user effective_user does not have access to files below
        /usr/local/".

        Printing "create filed on /usr/local/squid/cache/00" doesn't help
        a very new user.

3) GNU-standard command-line options

        'squid --help', 'squid --debug' and so forth, instead of
        'squid -h' and 'squid -d'. --help should at least work.

        same goes for 'client'... that '-I' and '-i' stuff is irritating :)

4) Squid.conf parsing.

        an option to parse the config file and say 'it makes sense'
        would be good. '~squid/bin/squid --check' would parse the file
        and warn me of typos. It's not going to stop me breaking everything
        with a messed-up acl change, but it's going to warn me if I set
        the http port to ":wq!" by mistake.

5) test acls.

        I quite often want to make acl changes, but I have so many
        lines that I am weary I am going to break something. A
        'acl tagname src 10.0.0.0/255.255.255.0 -test' would be nice
        if it could simply log all matches to the log file... but
        allows accesses that fail to match.

        I could then check and see if I have done something silly
        (like deny access to all our customers) :)

6) shutdown info

        Squid simply writes the number of objects written to the index
        to the cache.log on fatal errors. It would be nice if it indicated
        how many left, and what percentage complete it is.

7) an easy way to specify a different default http port

        It's irritating to have to put "-p 8080" in the client
        options every time on my machine. A configure option to change the
        default port from 3128 would be nice.

8) quick abort

        I have just realised that it's quite likely that the people
        complaining that their Squid stats don't match their router
        stats probably have quick_abort on. Since we log the number of
        bytes written to the client (and the time for the same) it's
        quite likely that this is the discrepancy. The log file format
        could be changed to indicate the real size, with the size written
        to the client in another field.

        This would also help you find those annoying people that
        consistently start and abort large downloads.

9) Make and rc file included with the source. It would be nice to
        have a 'RunCache stop' option that would shutdown Squid using
        '-kshutdown'. RunCache would need to keep a pid file somewhere.

Oskar

---
"Haven't slept at all. I don't see why people insist on sleeping. You feel
so much better if you don't. And how can anyone want to lose a minute -
a single minute of being alive?"				-- Think Twice