[PATCH] clean(er) squid.conf
Here is a quick patch I think builds a clean squid.conf file for use
The gist of it is to build to shift the existing squid.conf.default to
the name squid.conf.documented (anyone got a better one?)
Then to generate a new squid.conf.default from that by pruning the
comments and empty lines.
It's essentially what most of us experienced guys are doing anyway when
we have to, but at install time for the newbies.
NP: haven't tested yet, just throwing up for comments.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE8
=== modified file 'src/Makefile.am'
--- src/Makefile.am 2008-08-09 05:59:55 +
+++ src/Makefile.am 2008-08-20 05:06:07 +
@@ -979,6 +979,7 @@
sysconf_DATA = \
squid.conf.default \
+ squid.conf.documented \
mime.conf.default
data_DATA = \
@@ -1078,10 +1079,13 @@
## If autodependency works well this is not needed anymore
cache_cf.o: cf_parser.h
-# squd.conf.default is built by cf_gen when making cf_parser.h
-squid.conf.default: cf_parser.h
+# squid.conf.default is built by cf_gen when making cf_parser.h
+squid.conf.documented: cf_parser.h
true
+squid.conf.default: squid.conf.documented
+ grep -v -E ^[#\ ] squid.conf.documented squid.conf.default
+
cf_parser.h: cf.data cf_gen$(EXEEXT)
./cf_gen cf.data $(srcdir)/cf.data.depend
@@ -1131,6 +1135,10 @@
echo $(INSTALL_DATA) squid.conf.default $(DESTDIR)$(DEFAULT_CONFIG_FILE); \
$(INSTALL_DATA) squid.conf.default $(DESTDIR)$(DEFAULT_CONFIG_FILE); \
fi
+ echo $(INSTALL_DATA) squid.conf.default $(DESTDIR)$(DEFAULT_CONFIG_FILE).default; \
+ $(INSTALL_DATA) squid.conf.default $(DESTDIR)$(DEFAULT_CONFIG_FILE).default; \
+ echo $(INSTALL_DATA) squid.conf.documented $(DESTDIR)$(DEFAULT_CONFIG_FILE).documented; \
+ $(INSTALL_DATA) squid.conf.documented $(DESTDIR)$(DEFAULT_CONFIG_FILE).documented; \
$(mkinstalldirs) $(DESTDIR)$(DEFAULT_LOG_PREFIX)
uninstall-local:
@@ -1145,7 +1153,7 @@
# $(RM) -f $(DESTDIR)$(DEFAULT_CONFIG_FILE); \
# fi
-DISTCLEANFILES = cf_gen_defines.h cf.data cf_parser.h squid.conf.default \
+DISTCLEANFILES = cf_gen_defines.h cf.data cf_parser.h squid.conf.default squid.conf.documented \
globals.cc string_arrays.c repl_modules.cc
##install-pinger:
=== modified file 'src/cf_gen.cc'
--- src/cf_gen.cc 2008-03-16 22:10:18 +
+++ src/cf_gen.cc 2008-08-20 05:06:40 +
@@ -54,7 +54,7 @@
#define MAX_LINE 1024 /* longest configuration line */
#define _PATH_PARSER cf_parser.h
-#define _PATH_SQUID_CONF squid.conf.default
+#define _PATH_SQUID_CONF squid.conf.documented
#define _PATH_CF_DEPEND cf.data.depend
enum State {
Re: [PATCH] clean(er) squid.conf
On Wed, 2008-08-20 at 19:03 +1200, Amos Jeffries wrote: Here is a quick patch I think builds a clean squid.conf file for use The gist of it is to build to shift the existing squid.conf.default to the name squid.conf.documented (anyone got a better one?) Then to generate a new squid.conf.default from that by pruning the comments and empty lines. It's essentially what most of us experienced guys are doing anyway when we have to, but at install time for the newbies. NP: haven't tested yet, just throwing up for comments. yes yes yes yes yes :) -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: FAQ Update
On Wed, Aug 20, 2008 at 5:40 AM, Amos Jeffries [EMAIL PROTECTED] wrote: So far this is only a 1 minute chat between Adrian and myself, but I think its worthwhile doing and we all need to discuss at least. Issue: theres a lot of obsolete text in the FAQ. Adrians (probably joking): 'chuck it and start again'. Amos: 'no, chuck everything only relevant for 2.5 and earlier, re-evaluate based on whats left' I'd go for the latter: the FAQ is _huge_.. -- /kinkie
Re: [PATCH] clean(er) squid.conf
Robert Collins wrote: On Wed, 2008-08-20 at 19:03 +1200, Amos Jeffries wrote: Here is a quick patch I think builds a clean squid.conf file for use The gist of it is to build to shift the existing squid.conf.default to the name squid.conf.documented (anyone got a better one?) Then to generate a new squid.conf.default from that by pruning the comments and empty lines. It's essentially what most of us experienced guys are doing anyway when we have to, but at install time for the newbies. NP: haven't tested yet, just throwing up for comments. yes yes yes yes yes :) -Rob Well, I know your biased :-) Oh, and I forgot to mention. It also force-installs squid.conf.documented and squid.conf.default. Assuming that squid.conf is the one user edits to be left untouched. Such that users always have the most current *.documented version for their install, and the distribution maintainers can automate their stuff based on the clean most-current *.default (same arguments promoted for cachemgr.conf.default creation earlier by maintainers) Amos -- Please use Squid 2.7.STABLE4 or 3.0.STABLE8
Re: astyle
Amos Jeffries wrote:
Alex Rousskov wrote:
On Mon, 2008-01-07 at 23:55 +0200, Tsantilas Christos wrote:
Alex Rousskov wrote:
On Sat, 2008-01-05 at 13:05 +0200, Tsantilas Christos wrote:
...
I suggest removing break-blocks both because of the above bug and
because it is trying to detect unrelated blocks, classes, etc. which
smells too much like AI to me.
The --brackets=linux (-l) option is useful though. Can you check
whether
there is another --brackets option that works without the above bug and
does the subset of what --brackets=linux does?
We can only use the --brackets=break option which works well.
This option format the code as:
void Foo(bool isFoo)
{
if (isFoo)
{
bar();
}
else
{
anotherBar();
}
}
(This format is awful but considering the hours I spent to merge the
HEAD in async-calls ... it is the best :-) ! )
What do others think regarding making the above a temporary format
default until astyle improves or a better replacement is available?
[Not] spending hours on merging branches can be a strong-enough
motivation to use less-than-perfect format above...
Or would it be better to post-process atyle-formatted code to untangle
Less processing the better.
So putting up with a small ugly in exchange for a complicated hack is
okay by me.
On the bit-field problem, I have a similar mind. Even though the wrap is
extremely ugly the suggested fix makes code almost unreadable.
If we have to go the way of hacking bitfields around astyle, I would
suggest going to a macro (yuck). Like so:
#define BITFIELD(name,bits) unsigned int name : bits
struct {
BITFIELD(name, 1);
BITFIELD(flag, 1);
}
#if FOO {
}
lines?
Cheers,
Alex.
Amos
How was this going Christos?
We are getting close to feature finalization on 3.1.
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE8
Re: [PATCH] clean(er) squid.conf
On Wed, 2008-08-20 at 19:03 +1200, Amos Jeffries wrote: Here is a quick patch I think builds a clean squid.conf file for use The gist of it is to build to shift the existing squid.conf.default to the name squid.conf.documented (anyone got a better one?) Then to generate a new squid.conf.default from that by pruning the comments and empty lines. It's essentially what most of us experienced guys are doing anyway when we have to, but at install time for the newbies. NP: haven't tested yet, just throwing up for comments. +1 on the idea but have not reviewed the implementation. Please note that this will cause headaches for distributions that include squid.conf patches (e.g., CentOS Squid RPMs). Thanks, Alex.
Re: FAQ Update
On Wed, 2008-08-20 at 10:07 +0200, Kinkie wrote: On Wed, Aug 20, 2008 at 5:40 AM, Amos Jeffries [EMAIL PROTECTED] wrote: So far this is only a 1 minute chat between Adrian and myself, but I think its worthwhile doing and we all need to discuss at least. Issue: theres a lot of obsolete text in the FAQ. Adrians (probably joking): 'chuck it and start again'. Amos: 'no, chuck everything only relevant for 2.5 and earlier, re-evaluate based on whats left' I'd go for the latter: the FAQ is _huge_. Folks are still using 2.5 so we should at least archive the old FAQ if things get deleted. Deleting the whole thing is not a good option, IMO, but it is a lot of work to review and cleanup each item. Perhaps we can have two indexes into the same FAQ: one index links to reviewed and reasonable accurate/fresh entries only. The other links to all (or other?) entries. Both can be built automatically if we add a tag to fresh/reviewed FAQ entries. HTH, Alex.
Re: 3.2 plans
On Wed, 2008-08-20 at 15:06 +1200, Amos Jeffries wrote: At the AusMeeting08 we also laid out a few features needed in 3.2. I've cleaned up the quick roadmap notes we made live. Now seemed like a good time to experiment with the priority-based ordering system discussed a few months back. Could people please have a look at the Squid-3 roadmap page and give their opinions on that new ordering system. Better/Worse/Ugly? http://wiki.squid-cache.org/RoadMap/Squid3 We will also shortly need to set a deadline for feature requests to 3.2. I'm minded to say end October (mirroring the suggested 3.1 release date). I am not quite sure what Priority rating gives us in practice and I am not sure we should order items by priority rather than by likelihood of completion. If a developer commits to adding a feature, what effect will priority have on that person? As for users, their priority is usually more complex than a 1/2/3 rating _we_ can assign. User priority is very context-dependent and is relative to other features, budget, time, etc. HTH, Alex.
Re: astyle
Hi Amos,
I had post the latest version of the formatter (plus a small script
for checking md5 signatures):
http://www.mail-archive.com/squid-dev@squid-cache.org/msg07208.html
In all test I run, worked without problems.
I think it is OK.
Regards,
Christos
Amos Jeffries wrote:
Amos Jeffries wrote:
Alex Rousskov wrote:
On Mon, 2008-01-07 at 23:55 +0200, Tsantilas Christos wrote:
Alex Rousskov wrote:
On Sat, 2008-01-05 at 13:05 +0200, Tsantilas Christos wrote:
...
I suggest removing break-blocks both because of the above bug and
because it is trying to detect unrelated blocks, classes, etc. which
smells too much like AI to me.
The --brackets=linux (-l) option is useful though. Can you check
whether
there is another --brackets option that works without the above bug
and
does the subset of what --brackets=linux does?
We can only use the --brackets=break option which works well.
This option format the code as:
void Foo(bool isFoo)
{
if (isFoo)
{
bar();
}
else
{
anotherBar();
}
}
(This format is awful but considering the hours I spent to merge the
HEAD in async-calls ... it is the best :-) ! )
What do others think regarding making the above a temporary format
default until astyle improves or a better replacement is available?
[Not] spending hours on merging branches can be a strong-enough
motivation to use less-than-perfect format above...
Or would it be better to post-process atyle-formatted code to untangle
Less processing the better.
So putting up with a small ugly in exchange for a complicated hack is
okay by me.
On the bit-field problem, I have a similar mind. Even though the wrap
is extremely ugly the suggested fix makes code almost unreadable.
If we have to go the way of hacking bitfields around astyle, I would
suggest going to a macro (yuck). Like so:
#define BITFIELD(name,bits) unsigned int name : bits
struct {
BITFIELD(name, 1);
BITFIELD(flag, 1);
}
#if FOO {
}
lines?
Cheers,
Alex.
Amos
How was this going Christos?
We are getting close to feature finalization on 3.1.
Amos
Re: FAQ Update
On Wed, Aug 20, 2008 at 7:47 PM, Alex Rousskov [EMAIL PROTECTED] wrote: On Wed, 2008-08-20 at 10:07 +0200, Kinkie wrote: On Wed, Aug 20, 2008 at 5:40 AM, Amos Jeffries [EMAIL PROTECTED] wrote: So far this is only a 1 minute chat between Adrian and myself, but I think its worthwhile doing and we all need to discuss at least. Issue: theres a lot of obsolete text in the FAQ. Adrians (probably joking): 'chuck it and start again'. Amos: 'no, chuck everything only relevant for 2.5 and earlier, re-evaluate based on whats left' I'd go for the latter: the FAQ is _huge_. Folks are still using 2.5 so we should at least archive the old FAQ if things get deleted. Deleting the whole thing is not a good option, IMO, but it is a lot of work to review and cleanup each item. Perhaps we can have two indexes into the same FAQ: one index links to reviewed and reasonable accurate/fresh entries only. The other links to all (or other?) entries. Both can be built automatically if we add a tag to fresh/reviewed FAQ entries. THE Solution to this (capital S) is to split the wiki into its individual entries, to be tagged in various ways and assembled as-needed. Unfortunatley this requires the wiki engine to be extended to support metadata. There are a few threads going on in the MoinMoin dev community on how to achieve this, but at this time there's nothing relly useful in terms of code. I can try to come up with something which could at least solve our problem (a first attempt was the ForEach macro, which however has issues of its own) -- /kinkie
Re: [PATCH] clean(er) squid.conf
On ons, 2008-08-20 at 19:03 +1200, Amos Jeffries wrote: Here is a quick patch I think builds a clean squid.conf file for use The gist of it is to build to shift the existing squid.conf.default to the name squid.conf.documented (anyone got a better one?) Or integrade the cfgman script and build the documentation in HTML only.. Then to generate a new squid.conf.default from that by pruning the comments and empty lines. It's probably better to built it from cf.data, by just including the COMMENT and NO_COMMENT sections. This way we can get some meaningful comments into the file. And maybe there needs to be some new tag for clean config comment not included in the manual. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [PATCH] clean(er) squid.conf
On ons, 2008-08-20 at 20:18 +1200, Amos Jeffries wrote: It also force-installs squid.conf.documented and squid.conf.default. Assuming that squid.conf is the one user edits to be left untouched. .default is supposed to be force installed already. If it's not thats a bug. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [PATCH] clean(er) squid.conf
On ons, 2008-08-20 at 11:43 -0600, Alex Rousskov wrote: Please note that this will cause headaches for distributions that include squid.conf patches (e.g., CentOS Squid RPMs). Do they really patch squid.conf and not cf.data.pre? The RPMs I have seen patches cf.data.pre as they should. Regards Henrik signature.asc Description: This is a digitally signed message part
ClearingTheCache
Noticed the update of http://wiki.squid-cache.org/SquidFaq/ClearingTheCache . To fix simple cases such as the above where the cache just needs to have a portion of the total removed Altering squid.conf and reconfiguring squid is sufficient. Squid will handle the changes automatically and purge the cache down to size again within 10 minutes of the configure. IME it can take *much* longer than 10 minutes, and if the box is under load, doing this can cause problems. -- Mark Nottingham [EMAIL PROTECTED]
Re: ClearingTheCache
On Thu, 2008-08-21 at 08:09 +1000, Mark Nottingham wrote: Noticed the update of http://wiki.squid-cache.org/SquidFaq/ClearingTheCache . To fix simple cases such as the above where the cache just needs to have a portion of the total removed Altering squid.conf and reconfiguring squid is sufficient. Squid will handle the changes automatically and purge the cache down to size again within 10 minutes of the configure. IME it can take *much* longer than 10 minutes, and if the box is under load, doing this can cause problems. Then we should have a bug open - simple things like this should not cause problems. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: [PATCH] clean(er) squid.conf
On Thu, 2008-08-21 at 00:08 +0200, Henrik Nordstrom wrote: On ons, 2008-08-20 at 11:43 -0600, Alex Rousskov wrote: Please note that this will cause headaches for distributions that include squid.conf patches (e.g., CentOS Squid RPMs). Do they really patch squid.conf and not cf.data.pre? The RPMs I have seen patches cf.data.pre as they should. You are right! This should not really be a problem then. Thanks, Alex.
How to use IPv6 in preference to IPv4?
Hello. [I am not a subscriber to the dev list, so please CC me with any responses. Thank you.] I am playing with a 3.HEAD-20080820 build of Squid, to use it's support for IPv6. It seems to be working well (maybe a little slow relative to v2.7S4, both on Linux) except for one irritation. Given a site with both A and records, Squid always opts for the IPv4 connection. It seems that a lot of predominantly-IPv6 sites also maintain an IPv4 address, just so they can tell you to get on board with IPv6. For sites with only records, Squid does a great job of getting the content to me. Even the use of the square-bracket scheme (e.g. http://[www.kame.net]/ ) isn't enough to coax Squid into IPv6 land when a IPv4 address is also found by DNS look-up. How can I instruct Squid to prefer the IPv6 address over an IPv4 address? Thanks.
