FreeBSD-7.2-amd64 added to the build-farm
Hi all, I've set up and hooked to Hudson (for 3.X builds, 2.X will follow unless someone beats me to it) a FreeBSD-7.2-amd64 vhost. Builds are currently silent, and failing. The system is accessible from eu as diablo. The root password is the same as vobsd, user hudson has no password. -- /kinkie
Re: Patch to authenticate securely to upstream ISA server(or others)
Markus Moeller wrote: In some setups the upstream proxy requires a secue authentication method (Negotiate, NTLM). The attached patches (2.7 and 3.0) allow this with Negotiate. Regards Markus Hi Markus, Good to see this feature appearing. Just a few things to fix up before this can go in: * Makefile.am lines for linking peer_proxy_negotiate_auth.cc seem to be indented with spaces instead of the automake required tabs. * Unfortunately 3.0 is closed for new features. Can we get a diff against 3.HEAD code please? * there is zero documentation for the new option settings. Please add to the cache_peer entry of src/cf.data.pre with the new details for login=NEGOTIATE. * there is also no documentation for any of the code. Please prefix each new function and global in your new code with at least an overview description of what it does. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13
Re: Fixing bug #7
ons 2009-08-26 klockan 00:01 +1200 skrev Amos Jeffries: Hmm, I'm thinking there should not be too much functional change to make this fix Bug-7 in a slightly better way than squid-2 did. Oh, but there is... all this change does is to allow older objects to get back into memory. It does not change how in-memory objects gets updated with new info. This change does not make fixing bug #7 any easier or harder. What if: promoted objects had their disk copy dropped when the memory copy changes? that gets halfway there. if nothing else it will make Squid fetch a clean new copy next time after the memory copy dies. And what about the objects which never get promoted back into memory? if changed memory-promoted objects could get 'demoted' to a new disk filenumber that would solve bug-7 fully for the promotable objects. Yes, but you would still need to solve it for the other objects. side case would be the ones that don't get promoted. they are still screwed over for now. Exactly. Of have I got the disk/memory interaction overview completely screwed in my head? Only partially. For disk objects the cache_mem is seen as a shadow copy, not as a replacement. Depending on timing, object size and access pattern a single client may access both. The big change here is to actually write these objects out to disk again, and is what the Squid-2 approach does by looping the data into a new StoreEntry. Changing the cache to do the same while keeping the same StoreEntry requires fairly substantial surgery to the disk cache interface, which is actually unrelated to the in-memory update, and requires a different swapout mechanism than used today, swapping out the parsed headers and not the raw received data as done today.. Currently the in-memory updated objects is inconsistent, with parsed headers being updated but the raw object data is still the original data we once upon a time received from the network. The swapout knows nothing about headers and just swaps out the raw object data as-is, with a little meta header added infront (the TLV area). Regards Henrik
Re: /bzr/squid3/trunk/ r9933: Fully transparent PASSTHRU option for authentication to peers.
From what I can tell the difference between the PASSTHRU and PASS is only that PASSTHRU do not add any injected credentials from external_acl, right? Imho there is no need for more than two of these options. PASS - WWW+Proxy authentication passed along as-is if present. external_acl auth added as basic Proxy-Auth if none present. PROXYPASS - WWW+Proxy authentication passed along as-is. Proxy authentication converted to WWW authentication if WWW auth not present. If neither proxy of WWW authentication present then external_acl auth added as basic WWW auth (maybe this should have higher priority than proxy auth here...) If peer is an origin server then we should perhaps strip Proxy auth from the outgoing request. Could also do this by default in PROXYPASS to make the difference between the two more obvious, making the rules as follow: !originserver+PASS: Proxy WWW auth passed along as-is. If not Proxy-auth present then add external acl auth credentials as basic proxy auth. originserver+PASS: WWW auth pased along as-is. Maybe external_acl credentials as well (priority?) originserver+nothing set: No auth passed along (not trusted). PROXYPASS: WWW-auth passed along as-is. If no WWW-auth present then convert either Proxy-Auth or external acl credentials to Basic WWW auth. Regards Henrik
Re: [PATCH] DiskIO detection cleanup.
Bundle Buggy has detected this merge request. For details, see: http://bundlebuggy.aaronbentley.com/project/squid/request/%3C4A92A5EE.5070700%40treenet.co.nz%3E Project: Squid
Re: /bzr/squid3/trunk/ r9933: Fully transparent PASSTHRU option for authentication to peers.
Henrik Nordstrom wrote: From what I can tell the difference between the PASSTHRU and PASS is only that PASSTHRU do not add any injected credentials from external_acl, right? Imho there is no need for more than two of these options. I kind of agree. This is a step towards cleaning up the permutations a bit. The old ones are not really pass-thru. As you note they all did some synthesizing which can under some circumstances is mutually exclusive with real pass-thru. We temporarily have three: PROXYPASS synthetic WWW-Auth PASS synthetic Proxy-Auth PASSTHRU semantic transparency The fact that the first two were abusable as pass-thru and PASS in particular in too many guides used as semantic transparent pass-thru is a problem. PASS - WWW+Proxy authentication passed along as-is if present. external_acl auth added as basic Proxy-Auth if none present. Ideally yes. However the addition of Proxy-Auth from local environment (without the option NOT to) breaks setups where side-band auth is done and the real header auth needs to be fully semantically transparent. (We just hit this case needing semantic transparent WWW-Auth pass-thru which brought the confusion to light). I'd like to see PASS die simply because of the confusion we see in the help lists. PASSTHRU is intended to replace it for most peoples intended usages. PROXYPASS not being documented to date has been a stroke of luck. It's behaviour can be modified only slightly and without affecting any correct configurations which already should have originserver and login=PROXYPASS. Which would bring it back to two officially supported for 3.2: PROXYPASS synthetic WWW-Auth if originserver PROXYPASS synthetic Proxy-Auth if not originserver PASSTHRU semantic transparency ... and we deprecate login=PASS as replaced. PROXYPASS - WWW+Proxy authentication passed along as-is. Proxy authentication converted to WWW authentication if WWW auth not present. If neither proxy of WWW authentication present then external_acl auth added as basic WWW auth (maybe this should have higher priority than proxy auth here...) sigh. Did I miss the ext_acl appending there. ...back to documentation additions :( If peer is an origin server then we should perhaps strip Proxy auth from the outgoing request. Could also do this by default in PROXYPASS to make the difference between the two more obvious, making the rules as follow: This is what is _now_ happening when PROXYPASS is specified: Proxy-Auth is only passed in its WWW-Auth form if that translate is hit. Before this addition PROXYPASS was semantic transparent for Proxy-Auth and as you describe for WWW-Auth. Depending entirely on the 'originserver' flag. !originserver+PASS: Proxy WWW auth passed along as-is. If not Proxy-auth present then add external acl auth credentials as basic proxy auth. originserver+PASS: WWW auth pased along as-is. Maybe external_acl credentials as well (priority?) see above re: PASS. originserver+nothing set: No auth passed along (not trusted). aye. PROXYPASS: WWW-auth passed along as-is. If no WWW-auth present then convert either Proxy-Auth or external acl credentials to Basic WWW auth. aye. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13
Re: [PATCH] DiskIO detection cleanup.
t Theres a few bits of polish I know still needed: * some of the DiskIO dependencies I could not find clearly remain outside the scan block. * according to Robert the Windows Overlapping IO needs to be broken out into its own module. That is another cleanup sub-project. And the build defaults needs to be assessed: Current default is to enable only UFS with Blocking DiskIO * should we now make all disk modules default-enable? (to improve the experience of those building without these two options) +1 from me on by default enabling all disk modules where the known dependencies are met. * or, given that the default config is memory-only should we now make all disk modules default-disable? No thanks. There already is a too frequent question on how to enable different I/O types.. Regards Henrik
Re: [PATCH] DiskIO detection cleanup.
I haven't read the patch yet, but I concur with Henrik. We should default-enable as much as possible: An unused DiskIO module has almost no footprint - simply a registration entry and a link dependency on $whatever was needed. Rebuilding your squid because it doesn't have what you need is _much_ more painful. Even the smallest embedded devices are pretty huge these days, so the extra libs don't concern me. -Rob signature.asc Description: This is a digitally signed message part
Re: Patch to authenticate securely to upstream ISA server(or others)
Amos Jeffries squ...@treenet.co.nz wrote in message news:4a93cd1b.9030...@treenet.co.nz... Markus Moeller wrote: In some setups the upstream proxy requires a secue authentication method (Negotiate, NTLM). The attached patches (2.7 and 3.0) allow this with Negotiate. Regards Markus Hi Markus, Good to see this feature appearing. Just a few things to fix up before this can go in: * Makefile.am lines for linking peer_proxy_negotiate_auth.cc seem to be indented with spaces instead of the automake required tabs. * Unfortunately 3.0 is closed for new features. Can we get a diff against 3.HEAD code please? * there is zero documentation for the new option settings. Please add to the cache_peer entry of src/cf.data.pre with the new details for login=NEGOTIATE. * there is also no documentation for any of the code. Please prefix each new function and global in your new code with at least an overview description of what it does. Thank you for the feedback. I will work on your suggestions. Amos -- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE18 Current Beta Squid 3.1.0.13 Regards Markus
Build failed in Hudson: 3.1-amd64-CentOS-5.3 #11
See http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/11/changes Changes: [Amos Jeffries squ...@treenet.co.nz] Author: Francesco Chemolli kin...@squid-cache.org Fix some bash-isms in the test-suite. [Amos Jeffries squ...@treenet.co.nz] Remove bashism from testHeaders.sh -- [...truncated 5011 lines...] make[3]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/negotiate_auth' make[4]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/negotiate_auth' make[4]: Nothing to be done for `installcheck-am'. make[4]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/negotiate_auth' make[3]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/negotiate_auth' Making installcheck in external_acl make[3]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/external_acl' make[4]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/external_acl' make[4]: Nothing to be done for `installcheck-am'. make[4]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/external_acl' make[3]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers/external_acl' make[3]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers' make[3]: Nothing to be done for `installcheck-am'. make[3]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers' make[2]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/helpers' Making installcheck in test-suite make[2]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/test-suite' make[2]: Nothing to be done for `installcheck'. make[2]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/test-suite' Making installcheck in tools make[2]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/tools' make[3]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/tools' make[3]: Nothing to be done for `installcheck-am'. make[3]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/tools' make[2]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/tools' make[2]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build' make[2]: Nothing to be done for `installcheck-am'. make[2]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build' make[1]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build' make[1]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build' Making uninstall in compat make[2]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/compat' make[2]: Nothing to be done for `uninstall'. make[2]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/compat' Making uninstall in lib make[2]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/lib' make[3]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/lib' make[3]: Nothing to be done for `uninstall-am'. make[3]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/lib' make[2]: Leaving directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/lib' Making uninstall in snmplib make[2]: Entering directory `http://build.squid-cache.org/job/3.1-amd64-CentOS-5.3/ws/btlayer-00-default/squid-3.1.0.13-BZR/_build/snmplib' make[2]: Nothing to be done for `uninstall'. make[2]: Leaving directory
