Re: BodyReader
On Fri, 28 Apr 2006, Henrik Nordstrom wrote: tor 2006-04-27 klockan 19:27 + skrev [EMAIL PROTECTED]: Replacing ClientBody class with BodyReader. Seems to be some issues there, maybe 64-bit related. BodyReader.cc: In member function "void BodyReader::read(void (*)(MemBuf&, void*), void*)": BodyReader.cc:51: error: cast from "size_t (*)(void*, MemBuf&, size_t)" to "int" loses precision strange. I removed the cast.
Re: Getpwnam helper fix
Henrik Nordstrom wrote: > > Sounds like a excellent idea. > > To be correct the helper has to support both concurrently. The same > system may have both shadow and non-shadow users. So how you are > supposed to use these is that you first try with getspnam(), if that > fails fall back on getpwnam(). > > Not all systems have getspnam() so a new configure test may be needed. > Also there is noticeable security implications as the helper has to be > installed set-user-id root (or set-group-id shadow on systems using a > shadow group) in order to be able to use getspnam(). Because of this > it's perhaps better to make a new getspnam helper based on the getpwnam > helper code. > > Regards > Henrik First, thanks for the fast reply. I took a quick look on the configure tests that squid make, and didn't saw it looking for shadow.h or the shadow suite (correct me if I'm wrong). So i think that a simple test should suffice. And perhaps a variable like HAVE_SHADOW_H could be added to the config.h. I didn't knew that some systems have the 2 kind of authentication, but if you say so, i believe. Nowadays, the majority of systems have some kind of shadowing. On BSD systems, the encrypted passwords are kept in /etc/master.passwd and, much like shadow, only root can see it. But, in BSD systems, the getpwnam function works, you only need to run the program that is calling it as root. So, the helper, on BSD systems, must be installed suid root. This way, the getpwnam plugin would work only on BSD systems and systems that are POSIX compliant, but do not have shadowed passwords. I can write a new helper using the getspnam function or can modify the getpwnam helper to do both the authentications. I believe that the second is the most desirable, because on the systems you mentioned (that have both methods), only some users would authenticate (ie. the ones that the helper you are using can authenticate). Anyway, the helper should be run with the suid root bit set, or could use some kind of privilege separation. The plugin i wrote does this. So even if the OpenVPN process drop it's privileges and is run in a chroot, users still authenticate, because my plugin does a fork() and leave a background process running as root. And a new configure test should be made to look for the shadow suite. Any ideas? The plugin i made for the OpenVPN can be found on: http://sourceforge.net/projects/auth-passwd/ My regards, -- Giancarlo Razzolini Linux User 172199 Moleque Sem Conteudo Numero #002 Slackware Current OpenBSD Stable Snike Tecnologia em Informática 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85 signature.asc Description: OpenPGP digital signature
from IRC
(I don't get why xassert is disabled when PURIFY is set.. Duane?) I don't remember exactly any more. Maybe because assert() interferred with purify's ability to get a good stack trace. It can be removed as far as I'm concerned.
Re: cvs commit: squid3/src cache_cf.cc
On Fri, 2006-04-28 at 08:34 +1000, Robert Collins wrote:
> On Thu, 2006-04-27 at 19:07 +, [EMAIL PROTECTED] wrote:
> > wessels 2006/04/27 13:07:16 MDT
> >
> > Modified files:
> > src cache_cf.cc
> > Log:
> > bugfix: ICAPConfig calls aclParseAccessLine(), which now takes a
> > ConfigParser argument. Use the LegacyParser from cache_cf.cc, but
> > we need to make it global instead of static.
> >
> > Revision ChangesPath
> > 1.492 +2 -2 squid3/src/cache_cf.cc
>
> I'm trying to decouple the parser from the config with the LegacyParser:
> adding the parser as a common parameter to the modular parser like:
>
> aclParseAccessLine(LegacyParser, head);
>
> For example in cache_cf.cc:
>
> static void
> parse_icap_service_type(ICAPConfig * cfg)
> {
> cfg->parseICAPService(LegacyParser);
> }
>
>
> Is that OK?
Attached a patch to make it so.
The point of this is to allow testing of configuration using modules
without linking cache_cf.o in - because that drags in all of squid by
reference. Instead the tokeniser only is brought in.
Rob
--
GPG key available at: .
=== modified file 'a/src/ICAP/ICAPConfig.cc'
--- a/src/ICAP/ICAPConfig.cc
+++ b/src/ICAP/ICAPConfig.cc
@@ -34,8 +34,8 @@
#include "squid.h"
+#include "ACL.h"
#include "ConfigParser.h"
-#include "ACL.h"
#include "Store.h"
#include "Array.h" // really Vector
#include "ICAPConfig.h"
@@ -45,9 +45,7 @@
#include "ACLChecklist.h"
#include "wordlist.h"
-extern ConfigParser LegacyParser; // from cache_cf.cc
ICAPConfig TheICAPConfig;
-extern ConfigParser LegacyParser; // found in cache_cf.cc
ICAPServiceRep::Pointer
ICAPConfig::findService(const String& key)
@@ -352,7 +350,7 @@
};
void
-ICAPConfig::parseICAPAccess()
+ICAPConfig::parseICAPAccess(ConfigParser &parser)
{
String aKey;
ConfigParser::ParseString(&aKey);
@@ -362,7 +360,7 @@
fatalf("Did not find ICAP class '%s' referenced on line %d\n",
aKey.buf(), config_lineno);
-aclParseAccessLine(LegacyParser, &theClass->accessList);
+aclParseAccessLine(parser, &theClass->accessList);
};
void
=== modified file 'a/src/ICAP/ICAPConfig.h'
--- a/src/ICAP/ICAPConfig.h
+++ b/src/ICAP/ICAPConfig.h
@@ -39,6 +39,8 @@
#include "ICAPServiceRep.h"
class acl_access;
+
+class ConfigParser;
class ICAPConfig;
@@ -116,7 +118,7 @@
void freeICAPClass(void);
void dumpICAPClass(StoreEntry *, const char *);
-void parseICAPAccess(void);
+void parseICAPAccess(ConfigParser &parser);
void freeICAPAccess(void);
void dumpICAPAccess(StoreEntry *, const char *);
=== modified file 'a/src/cache_cf.cc'
--- a/src/cache_cf.cc
+++ b/src/cache_cf.cc
@@ -145,8 +145,12 @@
#endif /* USE_SSL */
static void parse_b_size_t(size_t * var);
-/* a parser for legacy code that uses the global approach */
-ConfigParser LegacyParser = ConfigParser();
+/* a parser for legacy code that uses the global approach
+ * This is static so that it is only exposed to cache_cf.
+ * Other modules needing access to a ConfigParser should
+ * have it provided to them in their parserFOO methods.
+ */
+static ConfigParser LegacyParser = ConfigParser();
void
self_destruct(void)
@@ -3260,7 +3264,7 @@
static void
parse_icap_access_type(ICAPConfig * cfg)
{
-cfg->parseICAPAccess();
+cfg->parseICAPAccess(LegacyParser);
}
static void
signature.asc
Description: This is a digitally signed message part
Re: BodyReader
tor 2006-04-27 klockan 19:27 + skrev [EMAIL PROTECTED]: > Replacing ClientBody class with BodyReader. Seems to be some issues there, maybe 64-bit related. BodyReader.cc: In member function "void BodyReader::read(void (*)(MemBuf&, void*), void*)": BodyReader.cc:51: error: cast from "size_t (*)(void*, MemBuf&, size_t)" to "int" loses precision Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: Getpwnam helper fix
tor 2006-04-27 klockan 17:44 -0300 skrev Giancarlo Razzolini: > I recently wrote a plugin for the OpenVPN program that authenticate > users either using the getpwnam or the getspnam functions. > A parameter in it's makefile must be set to enable/disable SHADOW > authentication, because i didn't wanted to use autoconf. I took a look > in the code from the getpwnam helper and i think it shouldn't take more > than a day to make it authenticate using either getpwnam or getspnam > functions. And i really want to contribute with this proxy that helped > me many times. I want to hear any comments from you guys. Sounds like a excellent idea. To be correct the helper has to support both concurrently. The same system may have both shadow and non-shadow users. So how you are supposed to use these is that you first try with getspnam(), if that fails fall back on getpwnam(). Not all systems have getspnam() so a new configure test may be needed. Also there is noticeable security implications as the helper has to be installed set-user-id root (or set-group-id shadow on systems using a shadow group) in order to be able to use getspnam(). Because of this it's perhaps better to make a new getspnam helper based on the getpwnam helper code. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: cvs commit: squid3/src cache_cf.cc
On Thu, 2006-04-27 at 19:07 +, [EMAIL PROTECTED] wrote:
> wessels 2006/04/27 13:07:16 MDT
>
> Modified files:
> src cache_cf.cc
> Log:
> bugfix: ICAPConfig calls aclParseAccessLine(), which now takes a
> ConfigParser argument. Use the LegacyParser from cache_cf.cc, but
> we need to make it global instead of static.
>
> Revision ChangesPath
> 1.492 +2 -2 squid3/src/cache_cf.cc
I'm trying to decouple the parser from the config with the LegacyParser:
adding the parser as a common parameter to the modular parser like:
aclParseAccessLine(LegacyParser, head);
For example in cache_cf.cc:
static void
parse_icap_service_type(ICAPConfig * cfg)
{
cfg->parseICAPService(LegacyParser);
}
Is that OK?
Rob
--
GPG key available at: .
signature.asc
Description: This is a digitally signed message part
Re: refresh.cc - refreshIsCachable()
The return value of refreshIsCachable() can be calculated without making a call to refreshCheck(). I.e. you can remove the call to refreshCheck() from refreshIsCachable(), and refreshIsCachable() will still return the correct result. Sorry, still not following you. refreshIsCachable() uses the 'reason' value in an early if statement: if (reason < 200) /* Does not need refresh. This is certainly cachable */ return 1; And there are numerous cases where refreshCheck() would return FRESH_* (i.e. < 200) values. DW
Re: wikis...
On Mon, 2006-04-24 at 13:23 -0600, Duane Wessels wrote: > > That's not how I remember it. From what I remember the objection from > > Duane wrt Kinkies wiki was more of a control and backup issue. docuwiki > > was selected by Duane as it's trivial to back up, and additionally the > > back-end content isn't hard to reuse for other purposes later on. > > I'm happy for Kinkie to host the officialk wiki. I would prefer it > to be "wiki.squid-cache.org". I agree Moin looks nicer on the outside. That's the place where it's meant to go in my opinion too :) Kinkie
Re: wikis...
On Mon, 2006-04-24 at 22:15 +0200, Henrik Nordstrom wrote: > mån 2006-04-24 klockan 13:23 -0600 skrev Duane Wessels: > > > I'm happy for Kinkie to host the officialk wiki. I would prefer it > > to be "wiki.squid-cache.org". I agree Moin looks nicer on the outside. > > Good. > > > I did > > like that it used plain text files which meant that we could store > > changes in CVS, but thats minor I guess. > > So does MoinMoin. > >"simple page storage (moin simply stores exactly what you see in the > editor into a directory that is named like the page)" > > Kinkie, would it be possible to set up a rsync access of the wiki data, > allowing it to be internally mirrored to squid-cache.org for backup > purposes to ensure continuance in the unlikely event you should > disappear for some time? Sure, no problem. We can discuss the details offline. Kinkie
Re: refresh.cc - refreshIsCachable()
On 27 Apr 2006, at 11:10, Duane Wessels wrote: On Tue, 25 Apr 2006, Doug Dixon wrote: It looks like the call to refreshCheck() is only used to short- circuit the function (if you can call it a short circuit, given the size of the callout) and to update some statistics. The main, and original, purpose of refreshCheck() is to check the request against the 'refresh_pattern' configuration values from squid.conf. Yep, refreshCheck() is used elsewhere and that's fine - it's just the call from refreshIsCachable() that I'm questioning. I can't see the reason stats being used anywhere, but maybe I overlooked something. (And anyway... should this function even be updating the refreshCounts[rcStore].total stat, given the fact this just checks a couple of flags?) The 'reason' return value and related statistcs are definately used. You can see refresh statistics in the cache manager 'refresh' page. Ah sorry, you're right :) However, the return value can be calculated without calling it, and the statistic it updates is never used. Would something like this be cleaner/quicker and still correct? I'm not sure which function "it" refers to. We can't NOT call refreshCheck(), ala your suggested refreshIsCachable() replacement. refreshIsCachable() could be made slightly shorter and cleaner, but I don't think its worth the trouble. The return value of refreshIsCachable() can be calculated without making a call to refreshCheck(). I.e. you can remove the call to refreshCheck() from refreshIsCachable (), and refreshIsCachable() will still return the correct result. The only side-effect is the loss of the refreshCounts[rcStore] stats... but since the meaning of this stat is (per CacheMgr cgi) "calls to refresh check", this stat should always be zero if we don't make the call. I.e. if we lose the call to refreshCheck, the right thing to do is lose the statistic. Cheers Doug
