Created attachment 146026 [details] squid34 port dir old An attempt to make a port for squid34. It's stable and the only one supported by upstream version of squid. It's based on existing www/squid33 and port made by Dennis Glatting. I know, it's a mess in PLIST_FILES, but it's the first step. I plan to convert it to normal pkg-plist format in future, but not now. I checked and tried every option. FS_COSS and ECAP don't build. Don't know how to fix it. Marked as broken. Others are ok and they are staging without any problems. No more "WARNING: no_suid: setuid(0): (1) Operation not permitted" messages in logs (thanks to the www/squid33). What's the difference between www/squid33? - latest squid-3.4.6 with latest patches. - more files in SHEBANG_FILES. - reorder a bit PLIST_FILES stuff + honor SSL. - add squid_krb5_ktname to rc.d script. Hope someone else will test it and maybe provide a patch to fix 2 broken oprions. P.S. Maybe it should be at www/squid, not in www/squid34?
Created attachment 146028 [details] squid34 port dir
hi timp87, We are in no rush for squid34, so please provide a version with a static plist. Okay, I see this covers today's fixes, that's good. We also need to get the option count down. - also, I can't see the shar right now because it's gzipped, don't do that. Just attach it plain text. I'm fine with moving it to www/squid if we deprecate squid33 when it comes with a message that we'll only have one version of squid in the future and this is it.
> We are in no rush for squid34, so please provide a version with a static plist. Please, let's commit it to www/squid34? and when I provide static plist version we will move it to www/squid? And delete then other versions. > We also need to get the option count down. I'm not sure which one. > - also, I can't see the shar right now because it's gzipped, don't do that. > Just attach it plain text. Sorry. It's just a port's dir. Is it written somewhere in porters handbook? > I'm fine with moving it to www/squid if we deprecate squid33 when it comes with a message that we'll only have one version of squid in the future and this is it. Great!
(In reply to timp87 from comment #3) > > We are in no rush for squid34, so please provide a version with a static plist. > Please, let's commit it to www/squid34? and when I provide static plist > version we will move it to www/squid? And delete then other versions. sorry, no. People are pretty upset with how PLIST is in squid 32 and 33, I won't commit another one on a promise to fix it. Let's fix it first. > > > We also need to get the option count down. > I'm not sure which one. Any option that doesn't require external dependencies, build by default (not an option). The rest we have to see, but I'd say build common ones unconditionally. Ask other squid people, I don't use it so I can't help. > > > - also, I can't see the shar right now because it's gzipped, don't do that. > > Just attach it plain text. > Sorry. It's just a port's dir. Is it written somewhere in porters handbook? I am not aware of where is says "gzip your shar before providing it". If the PBH says that it needs to be changed. I am talking about bugzilla. I want to set the shar's text without having to gunzip it first. That' true for any file < 1 Mb (bugzilla's attachment size limit)
> sorry, no. People are pretty upset with how PLIST is in squid 32 and 33, I won't commit another one on a promise to fix it. Let's fix it first. it's a pitty :(. This kills my motivation a bit. We lived with that whole life. It works now without problems. It stages with every option. Any alternative is much better then no alternative. > Any option that doesn't require external dependencies, build by default (not an option). The rest we have to see, but I'd say build common ones unconditionally. Ask other squid people, I don't use it so I can't help. > I am not aware of where is says "gzip your shar before providing it". If the PBH says that it needs to be changed. I am talking about bugzilla. I want to set the shar's text without having to gunzip it first. That' true for any file < 1 Mb (bugzilla's attachment size limit) I'm not arguing or grumbling here (I do it under the first quote). I just wanted to see an example or a place where I could learn.
(In reply to timp87 from comment #5) > > sorry, no. People are pretty upset with how PLIST is in squid 32 and 33, > > I won't commit another one on a promise to fix it. Let's fix it first. > it's a pitty :(. This kills my motivation a bit. We lived with that whole > life. > It works now without problems. It stages with every option. > Any alternative is much better then no alternative. If that is true, then converting it to a static plist will be relatively easy. The hard part is making it work with the numerous options and testing that it actually works (which means running poudriere numerous times). The plist is easy, it's the testing that is hard, and you claim that is complete. (I am skeptical a bit though) > I'm not arguing or grumbling here (I do it under the first quote). I just > wanted to see an example or a place where I could learn. I don't really know what you mean. Why do you need an example to update unzipped files? Just don't gzip them before you upload them.
Look at error_dirs, error_dir_links and error_files in Makefile. Do you have an idea how I can handle this bunch of same filenames in static pkg-plist?
Sorry, nevermind
I use Squid in a production environment (three or four instances). It is on my task list to update my hack-a-package this month. If no on else is stepping up to the plate to port Squid 3.4 to ports I'll accept the challenge.
Give me a week or two
sure, update the PR when you are ready.
you will be very interested in bug 192846
(In reply to John Marino from comment #12) > you will be very interested in bug 192846 Thanks. Squid has a lot of options. I was going through them earlier today looking to simplify.
I think we must be careful with option cutting. IMO options are one of the killer feature of FreeBSD ports. Look at options for postfix or openldap-server, for example. Squid is complex software and I don't think it's bad to have many options.
you are not "cutting" options in the sense the capability is lost. You are building it with that capability as a default. Any option that is off by default means it's not in a binary package. The more options there are, the more likely the binary package is useless. Even there are tons of options, as many as possible should be turned on by default so the capability is in the binary package, leaving only source builders to remove them manually. I get the idea you are focused on building from source. You need to be looking at this from a useful binary package point of view.
Created attachment 146062 [details] based on today's squid33 it's supposed to be www/squid Maybe we can switch back (remove expiration) fir those ports http://svnweb.freebsd.org/ports?view=revision&revision=365187 ?
i disagree. If they can't switch to squid33 before they get pruned, then they can't switch to squid 34 either.
I think squid33 must exist for some time (a half of a year or even more) in parallel with squid 3.4. Because it's already tested and check version
(In reply to timp87 from comment #18) > I think squid33 must exist for some time (a half of a year or even more) in > parallel with squid 3.4. > Because it's already tested and check version squid34 won't be committed until it's the same quality as squid33 and then squid33 will probably be deprecated because the company says they only support one (1) release at a time, which means squid33 is already not supported.
> squid34 won't be committed until it's the same quality as squid33 So is new shar the same quality as squid33?
i haven't looked at yet, is it finished? You did all the options refactoring to the best of your ability? also the share should start with squid/ not ./squid. I think in this case it doesn't matter though.
Created attachment 146065 [details] squid34.shar fix OptionsNG convert pkg-plist
(In reply to takefu from comment #22) > Created attachment 146065 [details] > squid34.shar > > fix OptionsNG > convert pkg-plist I'm currently running this shar on one of my servers. Although it has been running less than an hour, it seems to be working fine (including ICAP).
(In reply to takefu from comment #22) > Created attachment 146065 [details] > squid34.shar > > fix OptionsNG > convert pkg-plist I've been running it since it was presented. No problems except squid 3.4 eats much more CPU than squid 3.3 in my setup (negotiate_kerberos_auth + ext_kerberos_ldap_group_acl). Perhaps it's not related to port, but to squid itself.
(In reply to timp87 from comment #24) > I've been running it since it was presented. No problems except squid 3.4 > eats much more CPU than squid 3.3 in my setup (negotiate_kerberos_auth + > ext_kerberos_ldap_group_acl). Perhaps it's not related to port, but to squid > itself. Kerberos-related is corrupt. Especially in the clang is mad 'common'. Wait for the fix in the upstream.
(In reply to takefu from comment #25) > (In reply to timp87 from comment #24) > > > I've been running it since it was presented. No problems except squid 3.4 > > eats much more CPU than squid 3.3 in my setup (negotiate_kerberos_auth + > > ext_kerberos_ldap_group_acl). Perhaps it's not related to port, but to squid > > itself. > > Kerberos-related is corrupt. > Especially in the clang is mad 'common'. > Wait for the fix in the upstream. Thank you! Thats why I asked to safe squid33 for some time. But, no luck
So what we going to do now/next? Just in case. John (or someone else responsible for ports commit), if you decide commit it to the www/squid then don't forget to remove PKGNAMESUFFIX from Makefile.
(In reply to takefu from comment #25) > (In reply to timp87 from comment #24) > Kerberos-related is corrupt. > Especially in the clang is mad 'common'. > Wait for the fix in the upstream. I thought we are waiting for upstream as takefu said, "wait". I'm actually fine with waiting until 15 September. If we put it in before, we have to call it www/squid34 and then move it to www/squid after www/squid is removed. We can't call it www/squid *NOW* because there's a port there.
(In reply to John Marino from comment #28) > (In reply to takefu from comment #25) > > (In reply to timp87 from comment #24) > > Kerberos-related is corrupt. > > Especially in the clang is mad 'common'. > > Wait for the fix in the upstream. > > I thought we are waiting for upstream as takefu said, "wait". > > I'm actually fine with waiting until 15 September. > If we put it in before, we have to call it www/squid34 and then move it to > www/squid after www/squid is removed. > > We can't call it www/squid *NOW* because there's a port there. Ok, understood. I hope the upstream knows about that problem at least. takefu, do you have any additional info? Dennis Glatting, I looked at patches that you provided for initial version of this port. Sorry, if I ask stupid questions, but: Are all of them still valid for 3.4.6? For xample, is files/patch-src_base_Vector.h still valid? There was a similar fix included in 3.4.3 http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch
(In reply to timp87 from comment #29) > (In reply to John Marino from comment #28) > > (In reply to takefu from comment #25) > > > (In reply to timp87 from comment #24) > > > Kerberos-related is corrupt. > > > Especially in the clang is mad 'common'. > > > Wait for the fix in the upstream. > > > > I thought we are waiting for upstream as takefu said, "wait". > > > > I'm actually fine with waiting until 15 September. > > If we put it in before, we have to call it www/squid34 and then move it to > > www/squid after www/squid is removed. > > > > We can't call it www/squid *NOW* because there's a port there. > > Ok, understood. > I hope the upstream knows about that problem at least. > takefu, do you have any additional info? > > Dennis Glatting, I looked at patches that you provided for initial version > of this port. Sorry, if I ask stupid questions, but: > > Are all of them still valid for 3.4.6? > For example, is files/patch-src_base_Vector.h still valid? There was a > similar fix included in 3.4.3 > http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch 3.4.6 compiles without patch-src_base_Vector.h whereas 3.4.2 does not. 3.4.6 includes (integrated) 13082.patch whereas my version of 3.4.2 did not. If memory serves, it wasn't available at the time. Without running the code I conclude patch-src_base_Vector.h is no longer valid. I'm installing the non-patch-src_base_Vector.h code now for test, before coffee.
(In reply to Dennis Glatting from comment #30) > (In reply to timp87 from comment #29) > > (In reply to John Marino from comment #28) > > > (In reply to takefu from comment #25) > > > > (In reply to timp87 from comment #24) > > > > Kerberos-related is corrupt. > > > > Especially in the clang is mad 'common'. > > > > Wait for the fix in the upstream. > > > > > > I thought we are waiting for upstream as takefu said, "wait". > > > > > > I'm actually fine with waiting until 15 September. > > > If we put it in before, we have to call it www/squid34 and then move it to > > > www/squid after www/squid is removed. > > > > > > We can't call it www/squid *NOW* because there's a port there. > > > > Ok, understood. > > I hope the upstream knows about that problem at least. > > takefu, do you have any additional info? > > > > Dennis Glatting, I looked at patches that you provided for initial version > > of this port. Sorry, if I ask stupid questions, but: > > > > Are all of them still valid for 3.4.6? > > For example, is files/patch-src_base_Vector.h still valid? There was a > > similar fix included in 3.4.3 > > http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch > > 3.4.6 compiles without patch-src_base_Vector.h whereas 3.4.2 does not. > 3.4.6 includes (integrated) 13082.patch whereas my version of 3.4.2 did not. > If memory serves, it wasn't available at the time. > > Without running the code I conclude patch-src_base_Vector.h is no longer > valid. I'm installing the non-patch-src_base_Vector.h code now for test, > before coffee. The code is running and servicing requests. I see in the log a problem related to the PID but that may be *my* problem because I'm running multiple instances and have to redefine the PID file in rc.conf. I'll look into that problem this weekend when I won't be (significantly) impacting users+machines.
(In reply to John Marino from comment #28) > (In reply to takefu from comment #25) > > (In reply to timp87 from comment #24) > > Kerberos-related is corrupt. > > Especially in the clang is mad 'common'. > > Wait for the fix in the upstream. > > I thought we are waiting for upstream as takefu said, "wait". > > I'm actually fine with waiting until 15 September. > If we put it in before, we have to call it www/squid34 and then move it to > www/squid after www/squid is removed. > > We can't call it www/squid *NOW* because there's a port there. www/squid is 2.7.x. The Squid web site lists 2.7's "latest release date" as 16Mar2010. The site also says about 2.7 *and* 3.3: Provided for archival purposes only. Not intended for general use in new installations. The latest release date for 3.3 is listed as 08Mar2014. http://www.squid-cache.org/Versions/
(In reply to Dennis Glatting from comment #32) > www/squid is 2.7.x. The Squid web site lists 2.7's "latest release date" as > 16Mar2010. The site also says about 2.7 *and* 3.3: > > Provided for archival purposes only. Not intended for > general use in new installations. > > The latest release date for 3.3 is listed as 08Mar2014. > > http://www.squid-cache.org/Versions/ I don't know what you are getting at, honestly. The Squid developers have explicitly defined 2.7 EOL as Aug 2012, and also explicitly said they only support one release at a time. This was in response to the question, "Where are your EOL dates published?"
(In reply to Dennis Glatting from comment #31) > (In reply to Dennis Glatting from comment #30) > > (In reply to timp87 from comment #29) > > > (In reply to John Marino from comment #28) > > > > (In reply to takefu from comment #25) > > > > > (In reply to timp87 from comment #24) > > > > > Kerberos-related is corrupt. > > > > > Especially in the clang is mad 'common'. > > > > > Wait for the fix in the upstream. > > > > > > > > I thought we are waiting for upstream as takefu said, "wait". > > > > > > > > I'm actually fine with waiting until 15 September. > > > > If we put it in before, we have to call it www/squid34 and then move it to > > > > www/squid after www/squid is removed. > > > > > > > > We can't call it www/squid *NOW* because there's a port there. > > > > > > Ok, understood. > > > I hope the upstream knows about that problem at least. > > > takefu, do you have any additional info? > > > > > > Dennis Glatting, I looked at patches that you provided for initial version > > > of this port. Sorry, if I ask stupid questions, but: > > > > > > Are all of them still valid for 3.4.6? > > > For example, is files/patch-src_base_Vector.h still valid? There was a > > > similar fix included in 3.4.3 > > > http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13082.patch > > > > 3.4.6 compiles without patch-src_base_Vector.h whereas 3.4.2 does not. > > 3.4.6 includes (integrated) 13082.patch whereas my version of 3.4.2 did not. > > If memory serves, it wasn't available at the time. > > > > Without running the code I conclude patch-src_base_Vector.h is no longer > > valid. I'm installing the non-patch-src_base_Vector.h code now for test, > > before coffee. > > The code is running and servicing requests. I see in the log a problem > related to the PID but that may be *my* problem because I'm running multiple > instances and have to redefine the PID file in rc.conf. I'll look into that > problem this weekend when I won't be (significantly) impacting > users+machines. As for the other patches... Several of the patches supporting a modified strlen(). The problem is Squid will call strlen() with NULL. As of r270339 the FreeBSD strlen() does not check for NULL. See the following comment from Dimitry on this problem. http://lists.freebsd.org/pipermail/freebsd-ports/2014-February/089773.html
(In reply to John Marino from comment #33) > (In reply to Dennis Glatting from comment #32) > > www/squid is 2.7.x. The Squid web site lists 2.7's "latest release date" as > > 16Mar2010. The site also says about 2.7 *and* 3.3: > > > > Provided for archival purposes only. Not intended for > > general use in new installations. > > > > The latest release date for 3.3 is listed as 08Mar2014. > > > > http://www.squid-cache.org/Versions/ > > > I don't know what you are getting at, honestly. > > The Squid developers have explicitly defined 2.7 EOL as Aug 2012, and also > explicitly said they only support one release at a time. This was in > response to the question, "Where are your EOL dates published?" I'm not sure there is a point to www/squid except for graceful deprecation.
sure, but it's due to be removed on 15 September so we are all in agreement.
Created attachment 146412 [details] Updates www/squid34 to 3.4.7 Version 3.4.7 was released today. Attached is an updated shar file. I am running this version on one of my active servers but only for the last hour. I am NOT a Kerberos site. There is a CVE against 3.4.6 /and/ the 3.3 version in ports but 3.4.7 is fixed. The impacted version also includes 3.4.6 previously posted here but another change set is all that is needed. * CVE-2014-3609 : SQUID-2014:2 Denial of service in request processing http://www.squid-cache.org/Advisories/SQUID-2014_2.txt This vulnerability allows any client who is allowed to use the proxy to perform a denial of service attack on Squid. This issue is particularly impacting reverse-proxy installations. A simple squid.conf workaround is available for quick use and those unable to upgrade. See the Advisory notice for details.
My comment about Squid 3.3 is not valid. My mirror caught the update while I was working on 3.4.7.
They fixed my problem with kerberos in 3.4.7. It works as expected now. But it still eats o lot of CPU.
In 3 days, www/squid and www/squid32 will be removed. Please make sure all recent updates to www/squid33 are also captured in this shar. I would imagine the diff between this shar and www/squid33 is not great (or should not be great)
(In reply to John Marino from comment #40) > In 3 days, www/squid and www/squid32 will be removed. > > Please make sure all recent updates to www/squid33 are also captured in this > shar. I would imagine the diff between this shar and www/squid33 is not > great (or should not be great) Completely agree. The new port for squid34 should be based on existing www/squid33.
The 15th is tomorrow. Is an update coming before then?
Can I have a status ASAP? www/squid is expired right now.
(In reply to John Marino from comment #43) > Can I have a status ASAP? www/squid is expired right now. Sorry, status of what?
Created attachment 147372 [details] squid34.shar Update squid3.4.7 https://redports.org/buildarchive/20140916045831-30528/
takefu: thanks timp87: I've been expecting a final submission, one that captured the most recent changes of squid33. My last few comments on this PR were about requesting that submission, you said, "I agree" and thus I expected it. Since it didn't come, I was asking where it was and when it was coming.
(In reply to John Marino from comment #46) > takefu: thanks > > timp87: I've been expecting a final submission, one that captured the most > recent changes of squid33. My last few comments on this PR were about > requesting that submission, you said, "I agree" and thus I expected it. > Since it didn't come, I was asking where it was and when it was coming. Ah, sorry. I decided I'm not good at this. takefu and Dennis are better choice.
(In reply to timp87 from comment #47) > (In reply to John Marino from comment #46) > > takefu: thanks > > > > timp87: I've been expecting a final submission, one that captured the most > > recent changes of squid33. My last few comments on this PR were about > > requesting that submission, you said, "I agree" and thus I expected it. > > Since it didn't come, I was asking where it was and when it was coming. > > Ah, sorry. I decided I'm not good at this. takefu and Dennis are better > choice. delete is squid32, add squid34. It's the best choice to do so, I think.
The plan is: 1) delete all remaining ports dependent on www/squid 2) delete www/squid32 3) install this share in www/squid (not www/squid34!) 4) deprecate www/squid33 (say 4 months?) It is not a good idea to have more than one squid port. Only the current release is supported.
I tested the proposed port, it works fine. It's September, 16, and we still don't have 3.4 in ports. Do something. Add www/squid34 or replace 2.7 with 3.4, it doesn't matter. You're like wasting time discussing unimportant things. Squid 2.7 is long gone, those who still need this antiquity will still be able to fetch it with svn.
(In reply to emz from comment #50) > I tested the proposed port, it works fine. > It's September, 16, and we still don't have 3.4 in ports. > Do something. Add www/squid34 or replace 2.7 with 3.4, it doesn't matter. > You're like wasting time discussing unimportant things. Squid 2.7 is long > gone, those who still need this antiquity will still be able to fetch it > with svn. You do realize the very earliest this was going to be committed was the 15 of september, right? Are you really chastising somebody (e.g. me) for not having it in ports already? I do have other things to do, including $REALJOB. I find this comment very pushy and not helpful at all.
I have found this attitude spectacular. Real job. Yeah. Sorry I was messing with your real job with our 'FreeBSD MMORPG' game.
How old are you? It's probably best if that's your last "contribution" to this PR. Thanks.
You're absolutely right - everyone wondering why this isn't commited is either still a child or some slacker without a Real Job. How old are you ? I guess early twenties.
Please, let's not quarrel and offend each other. John, if you do not mind (i hope it's right expression), I'll provide a shar file for www/squid which will be based on lastest www/squid33.
(In reply to timp87 from comment #55) > John, if you do not mind (i hope it's right expression), I'll provide a shar > file for www/squid which will be based on lastest www/squid33. Isn't that what takefu provided (other than putting it at www/squid34 instead of www/squid)? It would be helpful if you can verify what takefu provide and tell me if you agree with it. If you agree, I'll just use that.
(In reply to John Marino from comment #56) > (In reply to timp87 from comment #55) > > John, if you do not mind (i hope it's right expression), I'll provide a shar > > file for www/squid which will be based on lastest www/squid33. > > Isn't that what takefu provided (other than putting it at www/squid34 > instead of www/squid)? > > It would be helpful if you can verify what takefu provide and tell me if you > agree with it. If you agree, I'll just use that. Not just, but not so serious. That patch didn't catch thing like rename STRICT_HTTP option to LAX_HTTP, removal of FS_COSS and small fix for pkg-plist.
(In reply to timp87 from comment #57) > Not just, but not so serious. That patch didn't catch thing like rename > STRICT_HTTP option to LAX_HTTP, removal of FS_COSS and small fix for > pkg-plist. Okay, that's a productive review. I would definitely appreciate an updated shar from you then, thanks!
(In reply to John Marino from comment #58) > (In reply to timp87 from comment #57) > > Not just, but not so serious. That patch didn't catch thing like rename > > STRICT_HTTP option to LAX_HTTP, removal of FS_COSS and small fix for > > pkg-plist. > > Okay, that's a productive review. I would definitely appreciate an updated > shar from you then, thanks! Do you wanted a _shar_ file for www/squid34 or www/squid? =) Sorry.
Use "www/squid". The PKGNAME should match as well.
Created attachment 147376 [details] shar for www/squid (3.4.7) Done. It catches all recent changes to the www/squid33 port.
Thanks! I don't see a reason to define SQUID_STABLE_VERSION or have the PKGNAMESUFFIX commented out, so I'll probably remove those and define PORTVERSION as 3.4.7 That's minor stuff though.
A commit references this bug: Author: marino Date: Tue Sep 16 12:29:21 UTC 2014 New revision: 368307 URL: http://svnweb.freebsd.org/changeset/ports/368307 Log: www/squid: Upgrade version 2.7.9 => 3.4.7 From now on, there will only be one squid port, this one. Squid33 has been deprecated and will expire on 31 JAN 2015. PR: 192828 Submitted by: timp87 (gmail) Contributions: takefu (airport.fm), Dennis Glatting Changes: head/www/squid/Makefile head/www/squid/distinfo head/www/squid/files/extra-patch-src-cf.data.pre.aufs head/www/squid/files/patch-compat_Makefile.in head/www/squid/files/patch-compat_strlen.c head/www/squid/files/patch-configure head/www/squid/files/patch-helpers-basic_auth-SMB-Makefile.in head/www/squid/files/patch-helpers-basic_auth-SMB-smb_auth.sh head/www/squid/files/patch-include-squid_types.h head/www/squid/files/patch-squid_kerb_auth head/www/squid/files/patch-src-cf.data.pre head/www/squid/files/patch-src_tools.cc head/www/squid/files/patch-tools-Makefile.in head/www/squid/files/pkg-deinstall.in head/www/squid/files/pkg-install.in head/www/squid/files/pkg-message.in head/www/squid/files/squid.in head/www/squid/pkg-descr head/www/squid/pkg-plist head/www/squid33/Makefile
Thanks timp87. There were a couple of more tweaks that were necessary, mainly the CONFLICTS needs to be updated but nothing major. it built in poudriere just fine as well. Closing this PR finally!