Re: [CODE4LIB] EZProxy changes / alternatives ?
Hello Riley, and everyone participating. Your email is a very succinct summary of what many are likely thinking right now about EZproxy, its future, and open source or other alternatives. As a nonprofit membership organization, OCLC strives to align its pricingwith our mission to serve our members. Our goal is to continue to deliver value through the EZproxy service at a price that makes it accessible to as many libraries as possible, while continuing to develop the service and provide support to its users. There are no plans to substantially change the pricing model of the stand-alone EZproxy service. Regarding innovation, IPV6 development starts next month with an IPV6 release planned later this year. We also have some final testing on EZproxy's GZIP compression functionality, as well as statistical reporting features in the pipeline. And of course, we continue to make our maintenance fixes and improvements. We will release as many features as we can and continue to deliver increased value at a reasonable price. We recognize and respect the importance of the open source ethic and the breadth of open source activity in the library community and believe libraries always benefit from having choices in the services they use. That said, the EZproxy application provides great value to its users that would not easily be replicated. In addition to the internal mechanics of providing proxied access to remote users, it includes nearly 15 years of ensuring access to hundreds of e-content targets--including a very long tail--using many authentication models, both in libraries and with content providers. With that in mind, we believe the current model is quite reasonable compared to rebuilding that kind of effort from scratch. We look forward to enhancing the stand-alone EZproxy service under its new business model as well as enhancing the service offered with the turn-key hosted model. Your input and suggestions are welcome, as always. We look forward to working together to continue to reduce barriers of access to e-content in our community. Don Don Hamparian Sr. Product Manager Identity Management and EZproxy OCLC 614.764.6017 (w) 614.975.5750 (m) On Mon, Feb 3, 2014 at 10:24 PM, Riley Childs wrote: > I never thought about this before, but it makes perfect sense, it is > impossible for the only product in the industry to maintain a perpetual > licensing model, EZProxy is the only one stop shop of its kind, and that is > exactly the reason an alternative is needed. Not because EZProxy is lacking > or expensive (it is a great product for the price) but as many others have > said: it is the only one, service vendors require EZProxy, we need to > change that purely for the sake of improvement, if the OCLC has incentive > to improve it will, but right now it has the market cornered, leaving no > need for inovation. > > This was basically what everyone has said (I think!) and there are valid > points for staying with EZProxy or switching, but the one that is most > pressing: monopoly, EZProxy is a unique animal, and who knows? $500/year > today $1000/year tomorrow, maybe even client access licenses? That is the > real reason an alternative is needed now. > > I hope this makes sense > //Riley > > Sent from my iPhone > > > On Feb 3, 2014, at 4:21 PM, "Peter Murray" > wrote: > > > > I think it also useful to think about this from the service provider's > perspective. There have been a few calls for enhancements/fixes in this > thread, but with no source of ongoing revenue (for self-hosted > installations, at least) I don't know how we can realistically expect the > service provider to devote resources to those enhancements/fixes. The $500 > paid for the perpetual right to run the software is good if you never > expect the software to change, particularly for something that has the > market saturation that EZproxy does (since there is a decreasing number of > new subscribers to pay the bills for added development). The same could be > said for paying the way of the technical writers to write documentation for > the new features added to the system. > > > > > > Peter > > -- > > Peter Murray > > Assistant Director, Technology Services Development > > LYRASIS > > peter.mur...@lyrasis.org > > +1 678-235-2955 > > 800.999.8558 x2955 >
Re: [CODE4LIB] EZProxy changes / alternatives ?
I never thought about this before, but it makes perfect sense, it is impossible for the only product in the industry to maintain a perpetual licensing model, EZProxy is the only one stop shop of its kind, and that is exactly the reason an alternative is needed. Not because EZProxy is lacking or expensive (it is a great product for the price) but as many others have said: it is the only one, service vendors require EZProxy, we need to change that purely for the sake of improvement, if the OCLC has incentive to improve it will, but right now it has the market cornered, leaving no need for inovation. This was basically what everyone has said (I think!) and there are valid points for staying with EZProxy or switching, but the one that is most pressing: monopoly, EZProxy is a unique animal, and who knows? $500/year today $1000/year tomorrow, maybe even client access licenses? That is the real reason an alternative is needed now. I hope this makes sense //Riley Sent from my iPhone > On Feb 3, 2014, at 4:21 PM, "Peter Murray" wrote: > > I think it also useful to think about this from the service provider’s > perspective. There have been a few calls for enhancements/fixes in this > thread, but with no source of ongoing revenue (for self-hosted installations, > at least) I don’t know how we can realistically expect the service provider > to devote resources to those enhancements/fixes. The $500 paid for the > perpetual right to run the software is good if you never expect the software > to change, particularly for something that has the market saturation that > EZproxy does (since there is a decreasing number of new subscribers to pay > the bills for added development). The same could be said for paying the way > of the technical writers to write documentation for the new features added to > the system. > > > Peter > -- > Peter Murray > Assistant Director, Technology Services Development > LYRASIS > peter.mur...@lyrasis.org > +1 678-235-2955 > 800.999.8558 x2955
Re: [CODE4LIB] EZProxy changes / alternatives ?
Peter, I think that's a good point, but OCLC knew upfront that this is the model for this product when they acquired it. So, this should have been part of the calculation when considering the acquisition -- but this component fills a very important part of their overall authentication stack for a lot of their other services (we are talking about Article proxying, but it's used with Illiad, WorldCat Local, WMS -- so it has a lot of different uses and has been enhanced a lot if you are a user of these other services. I think that OCLC does a good job shepherding the development, but I think Andrew hits why it would be useful to have an open alternative. It's very likely that even with an open alternative, you cannot completely divorce yourself from Ezproxy if you use another OCLC services. But I've had a number of times recently where I would have loved the ability to hack the proxy. --tr -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Peter Murray Sent: Monday, February 3, 2014 4:21 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? I think it also useful to think about this from the service provider's perspective. There have been a few calls for enhancements/fixes in this thread, but with no source of ongoing revenue (for self-hosted installations, at least) I don't know how we can realistically expect the service provider to devote resources to those enhancements/fixes. The $500 paid for the perpetual right to run the software is good if you never expect the software to change, particularly for something that has the market saturation that EZproxy does (since there is a decreasing number of new subscribers to pay the bills for added development). The same could be said for paying the way of the technical writers to write documentation for the new features added to the system. Peter -- Peter Murray Assistant Director, Technology Services Development LYRASIS peter.mur...@lyrasis.org +1 678-235-2955 800.999.8558 x2955
Re: [CODE4LIB] EZProxy changes / alternatives ?
I think it also useful to think about this from the service provider’s perspective. There have been a few calls for enhancements/fixes in this thread, but with no source of ongoing revenue (for self-hosted installations, at least) I don’t know how we can realistically expect the service provider to devote resources to those enhancements/fixes. The $500 paid for the perpetual right to run the software is good if you never expect the software to change, particularly for something that has the market saturation that EZproxy does (since there is a decreasing number of new subscribers to pay the bills for added development). The same could be said for paying the way of the technical writers to write documentation for the new features added to the system. Peter -- Peter Murray Assistant Director, Technology Services Development LYRASIS peter.mur...@lyrasis.org +1 678-235-2955 800.999.8558 x2955
Re: [CODE4LIB] EZProxy changes / alternatives ?
On 04/02/14 05:09, Andrew Anderson wrote: There exists a trivial DoS attack against EZproxy that I reported to OCLC about 2 years ago, and has not been addressed yet. ... and as soon as that gets a CVE (see http://cve.mitre.org/), corporate IT departments will force libraries to upgrade to the latest version or turn the software off. cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
I realize that the EZProxy list is the vendor's list but to some extent, I think some of this conversation needs to happen there too. Perhaps there's others there who can support an initiative to develop some sort of an alternative. However, many libraries on that list though will be in the same boat as me/my library, I suspect: I may or may not have the technical expertise to monkey with other options, but I definitely don't have the time. It would be hard to justify to my boss that I'm spending time on a proxy alternative when we already have EZProxy. When I'd asked EZProxy list about alternatives I heard about this: HANServer: http://www.hh-han.com/en/default.cfm I haven't done a thorough analysis of functionality because I got nervous about getting English language support from a German company, though I see now that they're partnering with LM Information Delivery (I don't know who THEY are either...) I really do think that the library community needs to do something and this whole thread has served to reinforce that - $500 per year or no. -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Scott Prater Sent: Monday, February 03, 2014 9:06 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? I'd add to the list that EZProxy integration with Shibboleth is fairly minimal; for example, it doesn't support chaining attribute authorities, which is an issue for us. We opened a ticket several years requesting that feature, but realistically, I doubt it will ever get added. If EZProxy were open source, and if I could make changes to it and push them back up to codebase, I'd be a lot happier with it. Given the market share it already has, I would think that releasing the source code would be a good marketing decision: the pool of interested developers who could implement new features, and help debug problems, would increase dramatically, and also contribute to making the software more secure. Perhaps with OCLC's new EZProxy hosted service, there would be less of a financial incentive to keep the source closed, and more of a product development incentive to open it up? -- Scott On 02/03/2014 10:09 AM, Andrew Anderson wrote: > For me it's a little more concrete, and a little less abstract when it comes > to why a viable alternative to EZproxy is necessary. It has very little to > do with the cost of EZproxy itself, and much more to do with support, > features, and functionality. > > There exists a trivial DoS attack against EZproxy that I reported to OCLC > about 2 years ago, and has not been addressed yet. > > Native IPv6 support by EZproxy has slipped by years now. I have patrons > using IPv6 for access today that I want to provide a better experience than > forcing them to use a 6to4 gateway at their ISP. > > You cannot proxy https to http with EZproxy to secure the patron to proxy > side of the proxy communication, increasing your patron's privacy. > > I have requested that OCLC make a minor change to their existing AD > authentication support to enable generic LDAP/Kerberos authentication that > was denied because "no one wants it". Since they support AD, 95% of the code > required already exists, and would make a lot more sense than some of the > other authentication schemes that EZproxy already supports. This closes the > door on integration with eDirectory, IPA, SUN Directory Server, OpenLDAP, > etc. for no good reason. > > OCLC has been the steward of EZproxy for over 5 years now, and in that time, > they are yet to fully document the software. Every few months some new > obscure configuration option gets discussed on the EZproxy list that I've > never seen before, and I have been working with this software for over a > decade now. This is not only limited to existing configuration options, > either - there was no documentation on the new MimeFilter option when it was > first introduced. I would have expected that the IT staff at OCLC that is > managing the EZproxy service would have demanded full documentation by now, > and that documentation would have been released to customers as well. > > EZproxy does not cluster well. The peering support is functional, but not > seamless when there is a failure. When a proxy in the server pool goes down, > the patron is prompted for authentication again when they land on a new proxy > server, since EZproxy does not share session state. External load balancers > cannot fix this problem, either, for the same reason. > > EZproxy does not support gzip compression, causing library access use an > additional 80-90% bandwidth for textual content (HTML, CSS, JS, etc). > > EZproxy does not support caching, cau
Re: [CODE4LIB] EZProxy changes / alternatives ?
I'd add to the list that EZProxy integration with Shibboleth is fairly minimal; for example, it doesn't support chaining attribute authorities, which is an issue for us. We opened a ticket several years requesting that feature, but realistically, I doubt it will ever get added. If EZProxy were open source, and if I could make changes to it and push them back up to codebase, I'd be a lot happier with it. Given the market share it already has, I would think that releasing the source code would be a good marketing decision: the pool of interested developers who could implement new features, and help debug problems, would increase dramatically, and also contribute to making the software more secure. Perhaps with OCLC's new EZProxy hosted service, there would be less of a financial incentive to keep the source closed, and more of a product development incentive to open it up? -- Scott On 02/03/2014 10:09 AM, Andrew Anderson wrote: For me it’s a little more concrete, and a little less abstract when it comes to why a viable alternative to EZproxy is necessary. It has very little to do with the cost of EZproxy itself, and much more to do with support, features, and functionality. There exists a trivial DoS attack against EZproxy that I reported to OCLC about 2 years ago, and has not been addressed yet. Native IPv6 support by EZproxy has slipped by years now. I have patrons using IPv6 for access today that I want to provide a better experience than forcing them to use a 6to4 gateway at their ISP. You cannot proxy https to http with EZproxy to secure the patron to proxy side of the proxy communication, increasing your patron’s privacy. I have requested that OCLC make a minor change to their existing AD authentication support to enable generic LDAP/Kerberos authentication that was denied because “no one wants it”. Since they support AD, 95% of the code required already exists, and would make a lot more sense than some of the other authentication schemes that EZproxy already supports. This closes the door on integration with eDirectory, IPA, SUN Directory Server, OpenLDAP, etc. for no good reason. OCLC has been the steward of EZproxy for over 5 years now, and in that time, they are yet to fully document the software. Every few months some new obscure configuration option gets discussed on the EZproxy list that I’ve never seen before, and I have been working with this software for over a decade now. This is not only limited to existing configuration options, either — there was no documentation on the new MimeFilter option when it was first introduced. I would have expected that the IT staff at OCLC that is managing the EZproxy service would have demanded full documentation by now, and that documentation would have been released to customers as well. EZproxy does not cluster well. The peering support is functional, but not seamless when there is a failure. When a proxy in the server pool goes down, the patron is prompted for authentication again when they land on a new proxy server, since EZproxy does not share session state. External load balancers cannot fix this problem, either, for the same reason. EZproxy does not support gzip compression, causing library access use an additional 80-90% bandwidth for textual content (HTML, CSS, JS, etc). EZproxy does not support caching, causing library access to use an additional 30-50% additional bandwidth for cacheable web assets. (And yes, you can park a cache in front of EZproxy to offset this, which is how I collected the 30-50% numbers, but doing so breaks the “it’s easy and just works” model that EZproxy promises.) Combine the lack of gzip support with the lack of caching support, and you are looking at around a 60-80% overall increase in bandwidth consumption. When you have a user community measured in hundreds of users, things like gzip compression and caching may not matter as much, but when your user community is measured in the hundreds of thousands of patrons, these things really do matter, and mean the difference between doubling your bandwidth costs this year, or deferring that expense 5-7 years down the road. So it’s not _just_ $500 per year when you take a step back and look at the bigger picture. It’s $500 per year, plus the per Mb cost of your internet connection — both inbound and outbound — which can be measured in hundreds of dollars per month for larger sites. If you could could cut that by 2/3 just by switching to a different proxy solution, that might get your attention, even if you shifted the $500/yr support costs to a different entity. Imagine never hearing “wow this library network is slow” again because a web page that used to load 1MB of content was able to gzip that down to 600KB, and 300KB of that content was served off the local proxy server, leaving just 300KB to pull off the remote server. How much is a better user experience worth to you? Bottom line:
Re: [CODE4LIB] EZProxy changes / alternatives ?
For me it’s a little more concrete, and a little less abstract when it comes to why a viable alternative to EZproxy is necessary. It has very little to do with the cost of EZproxy itself, and much more to do with support, features, and functionality. There exists a trivial DoS attack against EZproxy that I reported to OCLC about 2 years ago, and has not been addressed yet. Native IPv6 support by EZproxy has slipped by years now. I have patrons using IPv6 for access today that I want to provide a better experience than forcing them to use a 6to4 gateway at their ISP. You cannot proxy https to http with EZproxy to secure the patron to proxy side of the proxy communication, increasing your patron’s privacy. I have requested that OCLC make a minor change to their existing AD authentication support to enable generic LDAP/Kerberos authentication that was denied because “no one wants it”. Since they support AD, 95% of the code required already exists, and would make a lot more sense than some of the other authentication schemes that EZproxy already supports. This closes the door on integration with eDirectory, IPA, SUN Directory Server, OpenLDAP, etc. for no good reason. OCLC has been the steward of EZproxy for over 5 years now, and in that time, they are yet to fully document the software. Every few months some new obscure configuration option gets discussed on the EZproxy list that I’ve never seen before, and I have been working with this software for over a decade now. This is not only limited to existing configuration options, either — there was no documentation on the new MimeFilter option when it was first introduced. I would have expected that the IT staff at OCLC that is managing the EZproxy service would have demanded full documentation by now, and that documentation would have been released to customers as well. EZproxy does not cluster well. The peering support is functional, but not seamless when there is a failure. When a proxy in the server pool goes down, the patron is prompted for authentication again when they land on a new proxy server, since EZproxy does not share session state. External load balancers cannot fix this problem, either, for the same reason. EZproxy does not support gzip compression, causing library access use an additional 80-90% bandwidth for textual content (HTML, CSS, JS, etc). EZproxy does not support caching, causing library access to use an additional 30-50% additional bandwidth for cacheable web assets. (And yes, you can park a cache in front of EZproxy to offset this, which is how I collected the 30-50% numbers, but doing so breaks the “it’s easy and just works” model that EZproxy promises.) Combine the lack of gzip support with the lack of caching support, and you are looking at around a 60-80% overall increase in bandwidth consumption. When you have a user community measured in hundreds of users, things like gzip compression and caching may not matter as much, but when your user community is measured in the hundreds of thousands of patrons, these things really do matter, and mean the difference between doubling your bandwidth costs this year, or deferring that expense 5-7 years down the road. So it’s not _just_ $500 per year when you take a step back and look at the bigger picture. It’s $500 per year, plus the per Mb cost of your internet connection — both inbound and outbound — which can be measured in hundreds of dollars per month for larger sites. If you could could cut that by 2/3 just by switching to a different proxy solution, that might get your attention, even if you shifted the $500/yr support costs to a different entity. Imagine never hearing “wow this library network is slow” again because a web page that used to load 1MB of content was able to gzip that down to 600KB, and 300KB of that content was served off the local proxy server, leaving just 300KB to pull off the remote server. How much is a better user experience worth to you? Bottom line: competition is good. Just look at how Internet Explorer is almost a sane browser now, thanks largely to competition from Firefox and Chrome. If coming up with a viable alternative to EZproxy using open source tools causes a security, features, and functionality arms race, then everyone wins. -- Andrew Anderson, Director of Development, Library and Information Resources Network, Inc. http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes On Jan 31, 2014, at 18:43, Kyle Banerjee wrote: > On Fri, Jan 31, 2014 at 3:10 PM, Salazar, Christina < > christina.sala...@csuci.edu> wrote: > >> I think though that razor thin budgets aside, the EZProxy using community >> is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC >> peeps (just kiddin') but now we're so captive to EZProxy, what are our >> options if OCLC wants to gradually (or not so gradually) jack up the price? >> >> Does being this
Re: [CODE4LIB] EZProxy changes / alternatives ?
So the OCLC is starting to become THE one stop shop, next thing you know they will be making an offer on LibGuides. Sent from my iPhone > On Feb 2, 2014, at 8:43 PM, "stuart yeates" wrote: > > It's worse than that. > > The price we were quoted for hosting seems to have been picked so it can > be offered with a 90% discount when bundled with a package deal with > other OCLC products; buying into the on-going balkanization of the industry. > > cheers > stuart > >> On 01/02/14 16:24, Roy Tennant wrote: >> When it comes to hedging bets, I'd sure rather hedge my $50,000 bet than my >> $500 one. Just sayin'. >> Roy >> >> >> On Fri, Jan 31, 2014 at 6:04 PM, BWS Johnson >> wrote: >> >>> Salvete! >>> >>> Tisn't necessarily Socialist to hedge one's bets. Look at what Wall >>> St. experts advise when one is unsure of whether to hold or sell. Monopoly >>> is only ever in the interest of those that hold it. >>> >>>Short term the aquarium is enticing, but do you enjoy your >>> collapsed dorsal fin? >>> >>> Cheers, >>> Brooke >>> >>> -- On Fri, Jan 31, 2014 6:10 PM EST Salazar, Christina wrote: I think though that razor thin budgets aside, the EZProxy using community >>> is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC >>> peeps (just kiddin') but now we're so captive to EZProxy, what are our >>> options if OCLC wants to gradually (or not so gradually) jack up the price? Does being this captive to a single product justify community developer >>> time? I think so but I'm probably just a damn socialist. > On Jan 31, 2014, at 1:36 PM, "Tim McGeary" wrote: > > Even with razor thin budgets, this is a no brainer. May they need >>> decide > between buying 10 new books or license EZProxy? Possibly, but if they >>> have > a need for EZProxy, that's still a no brainer - until a solid OSS > replacement that includes as robust a developer /support community comes > around. But again, at $500/year, I don't see a lot of incentive to >>> invest > in such a project. > > >> On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs wrote: > > But there are places on a razor thin budget, and things like this throw > them off ball acne > > Sent from my iPhone > >> On Jan 31, 2014, at 3:32 PM, "Tim McGeary" >>> wrote: >> >> So what's the price point that EZProxy needs to climb to make it more >> realistic to put resources into an alternative. At $500/year, I don't > even >> have to think about justifying it. At 1% (or less) of the cost of > position >> with little to no prior experience needed, it doesn't make a lot of >>> sense >> to invest in an open source alternative, even on a campus that heavily > uses >> Shibboleth. >> >> Tim >> >> >>> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer >> wrote: >> >> Not only that, but it's also expressly designed for the purpose of > reverse >> proxying subscription databases in a library environment. There are > tons >> of things vendors do that would be incredibly frustrating to get >>> working >> properly in Squid, nginx, or Apache that have already been solved by >> EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy > does >> (rather than improving access to their resources). >> >> Art Rhyno used to say that the major thing that was inhibiting the >> widespread adoption of Shibboleth was how simple and cheap EZProxy was. > I >> think there is a lot of truth to that. >> >> -Ross. >> >> >> On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee < >>> kyle.baner...@gmail.com >>> wrote: >> >>> EZproxy is a self-installing statically compiled single binary >> download, >>> with a built-in administrative interface that makes most common >>> administrative tasks point-and-click, that works on Linux and Windows >>> systems, and requires very little in the way of resources to run. It >>> also >>> has a library of a few hundred vendor stanzas that can be copied and >>> pasted >>> and work the majority of the time. >>> >>> To successfully replace EZproxy in this setting, it would need to be >>> packaged in such a way that it is equally easy to install and > maintain, >>> and >>> the library of vendor stanzas would need to be developed as apache >> conf.d >>> files. >>> >>> This. The real gain with EZProxy is that configuring it is crazy easy. >> You >>> just drop it in and run it -- it's feasible for someone with no >> experience >>> in proxying or systems administration to get it operational in a few >>> minutes. That is why I think virtualizing a system that makes >>> accessing >> the >>> more powerful features of EZProxy easy is a good alternative. >>> >>> ky
Re: [CODE4LIB] EZProxy changes / alternatives ?
It's worse than that. The price we were quoted for hosting seems to have been picked so it can be offered with a 90% discount when bundled with a package deal with other OCLC products; buying into the on-going balkanization of the industry. cheers stuart On 01/02/14 16:24, Roy Tennant wrote: When it comes to hedging bets, I'd sure rather hedge my $50,000 bet than my $500 one. Just sayin'. Roy On Fri, Jan 31, 2014 at 6:04 PM, BWS Johnson wrote: Salvete! Tisn't necessarily Socialist to hedge one's bets. Look at what Wall St. experts advise when one is unsure of whether to hold or sell. Monopoly is only ever in the interest of those that hold it. Short term the aquarium is enticing, but do you enjoy your collapsed dorsal fin? Cheers, Brooke -- On Fri, Jan 31, 2014 6:10 PM EST Salazar, Christina wrote: I think though that razor thin budgets aside, the EZProxy using community is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC peeps (just kiddin') but now we're so captive to EZProxy, what are our options if OCLC wants to gradually (or not so gradually) jack up the price? Does being this captive to a single product justify community developer time? I think so but I'm probably just a damn socialist. On Jan 31, 2014, at 1:36 PM, "Tim McGeary" wrote: Even with razor thin budgets, this is a no brainer. May they need decide between buying 10 new books or license EZProxy? Possibly, but if they have a need for EZProxy, that's still a no brainer - until a solid OSS replacement that includes as robust a developer /support community comes around. But again, at $500/year, I don't see a lot of incentive to invest in such a project. On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs wrote: But there are places on a razor thin budget, and things like this throw them off ball acne Sent from my iPhone On Jan 31, 2014, at 3:32 PM, "Tim McGeary" wrote: So what's the price point that EZProxy needs to climb to make it more realistic to put resources into an alternative. At $500/year, I don't even have to think about justifying it. At 1% (or less) of the cost of position with little to no prior experience needed, it doesn't make a lot of sense to invest in an open source alternative, even on a campus that heavily uses Shibboleth. Tim On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer wrote: Not only that, but it's also expressly designed for the purpose of reverse proxying subscription databases in a library environment. There are tons of things vendors do that would be incredibly frustrating to get working properly in Squid, nginx, or Apache that have already been solved by EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy does (rather than improving access to their resources). Art Rhyno used to say that the major thing that was inhibiting the widespread adoption of Shibboleth was how simple and cheap EZProxy was. I think there is a lot of truth to that. -Ross. On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee < kyle.baner...@gmail.com wrote: EZproxy is a self-installing statically compiled single binary download, with a built-in administrative interface that makes most common administrative tasks point-and-click, that works on Linux and Windows systems, and requires very little in the way of resources to run. It also has a library of a few hundred vendor stanzas that can be copied and pasted and work the majority of the time. To successfully replace EZproxy in this setting, it would need to be packaged in such a way that it is equally easy to install and maintain, and the library of vendor stanzas would need to be developed as apache conf.d files. This. The real gain with EZProxy is that configuring it is crazy easy. You just drop it in and run it -- it's feasible for someone with no experience in proxying or systems administration to get it operational in a few minutes. That is why I think virtualizing a system that makes accessing the more powerful features of EZProxy easy is a good alternative. kyle -- Tim McGeary timmcge...@gmail.com GTalk/Yahoo/Skype/Twitter: timmcgeary 484-294-7660 (cell) -- Tim McGeary timmcge...@gmail.com GTalk/Yahoo/Skype/Twitter: timmcgeary 484-294-7660 (cell) -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
The institution sacrifices 10 books each year, in the long term this is a lot of money, it isn't a mater of money also, it is the issue there is no alternative to EZProxy. Sent from my iPhone > On Feb 2, 2014, at 3:58 PM, "Wilhelmina Randtke" wrote: > > $500 this year. Five years out, it won't be less than $495 each year, but > potentially much more. > > -Wilhelmina Randtke > > >> On Fri, Jan 31, 2014 at 9:24 PM, Roy Tennant wrote: >> >> When it comes to hedging bets, I'd sure rather hedge my $50,000 bet than my >> $500 one. Just sayin'. >> Roy >> >> >> On Fri, Jan 31, 2014 at 6:04 PM, BWS Johnson >> wrote: >> >>> Salvete! >>> >>> Tisn't necessarily Socialist to hedge one's bets. Look at what Wall >>> St. experts advise when one is unsure of whether to hold or sell. >> Monopoly >>> is only ever in the interest of those that hold it. >>> >>> Short term the aquarium is enticing, but do you enjoy your >>> collapsed dorsal fin? >>> >>> Cheers, >>> Brooke >>> >>> -- On Fri, Jan 31, 2014 6:10 PM EST Salazar, Christina wrote: I think though that razor thin budgets aside, the EZProxy using >> community >>> is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC >>> peeps (just kiddin') but now we're so captive to EZProxy, what are our >>> options if OCLC wants to gradually (or not so gradually) jack up the >> price? Does being this captive to a single product justify community developer >>> time? I think so but I'm probably just a damn socialist. On Jan 31, 2014, at 1:36 PM, "Tim McGeary" >> wrote: > Even with razor thin budgets, this is a no brainer. May they need >>> decide > between buying 10 new books or license EZProxy? Possibly, but if they >>> have > a need for EZProxy, that's still a no brainer - until a solid OSS > replacement that includes as robust a developer /support community >> comes > around. But again, at $500/year, I don't see a lot of incentive to >>> invest > in such a project. > > > On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs < >> rchi...@cucawarriors.com wrote: > > But there are places on a razor thin budget, and things like this >> throw > them off ball acne > > Sent from my iPhone > >> On Jan 31, 2014, at 3:32 PM, "Tim McGeary" >>> wrote: >> >> So what's the price point that EZProxy needs to climb to make it more >> realistic to put resources into an alternative. At $500/year, I >> don't > even >> have to think about justifying it. At 1% (or less) of the cost of > position >> with little to no prior experience needed, it doesn't make a lot of >>> sense >> to invest in an open source alternative, even on a campus that >> heavily > uses >> Shibboleth. >> >> Tim >> >> >>> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer >> wrote: >> >> Not only that, but it's also expressly designed for the purpose of > reverse >> proxying subscription databases in a library environment. There are > tons >> of things vendors do that would be incredibly frustrating to get >>> working >> properly in Squid, nginx, or Apache that have already been solved by >> EZProxy. Which is self-fulfilling: vendors then cater to what >> EZProxy > does >> (rather than improving access to their resources). >> >> Art Rhyno used to say that the major thing that was inhibiting the >> widespread adoption of Shibboleth was how simple and cheap EZProxy >> was. > I >> think there is a lot of truth to that. >> >> -Ross. >> >> >> On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee < >>> kyle.baner...@gmail.com >>> wrote: >> >>> EZproxy is a self-installing statically compiled single binary >> download, >>> with a built-in administrative interface that makes most common >>> administrative tasks point-and-click, that works on Linux and >> Windows >>> systems, and requires very little in the way of resources to run. >> It >>> also >>> has a library of a few hundred vendor stanzas that can be copied and >>> pasted >>> and work the majority of the time. >>> >>> To successfully replace EZproxy in this setting, it would need to be >>> packaged in such a way that it is equally easy to install and > maintain, >>> and >>> the library of vendor stanzas would need to be developed as apache >> conf.d >>> files. >>> >>> This. The real gain with EZProxy is that configuring it is crazy >> easy. >> You >>> just drop it in and run it -- it's feasible for someone with no >> experience >>> in proxying or systems administration to get it operational in a few >>> minutes. That is why I think virtualizing a system that makes >>> accessing >> the >>> more powerful features of EZProxy easy is a good alternative. >>> >>> kyl
Re: [CODE4LIB] EZProxy changes / alternatives ?
$500 this year. Five years out, it won't be less than $495 each year, but potentially much more. -Wilhelmina Randtke On Fri, Jan 31, 2014 at 9:24 PM, Roy Tennant wrote: > When it comes to hedging bets, I'd sure rather hedge my $50,000 bet than my > $500 one. Just sayin'. > Roy > > > On Fri, Jan 31, 2014 at 6:04 PM, BWS Johnson >wrote: > > > Salvete! > > > > Tisn't necessarily Socialist to hedge one's bets. Look at what Wall > > St. experts advise when one is unsure of whether to hold or sell. > Monopoly > > is only ever in the interest of those that hold it. > > > >Short term the aquarium is enticing, but do you enjoy your > > collapsed dorsal fin? > > > > Cheers, > > Brooke > > > > -- > > On Fri, Jan 31, 2014 6:10 PM EST Salazar, Christina wrote: > > > > >I think though that razor thin budgets aside, the EZProxy using > community > > is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC > > peeps (just kiddin') but now we're so captive to EZProxy, what are our > > options if OCLC wants to gradually (or not so gradually) jack up the > price? > > > > > >Does being this captive to a single product justify community developer > > time? > > > > > >I think so but I'm probably just a damn socialist. > > > > > >On Jan 31, 2014, at 1:36 PM, "Tim McGeary" > wrote: > > > > > >> Even with razor thin budgets, this is a no brainer. May they need > > decide > > >> between buying 10 new books or license EZProxy? Possibly, but if they > > have > > >> a need for EZProxy, that's still a no brainer - until a solid OSS > > >> replacement that includes as robust a developer /support community > comes > > >> around. But again, at $500/year, I don't see a lot of incentive to > > invest > > >> in such a project. > > >> > > >> > > >> On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs < > rchi...@cucawarriors.com > > >wrote: > > >> > > >> But there are places on a razor thin budget, and things like this > throw > > >> them off ball acne > > >> > > >> Sent from my iPhone > > >> > > >>> On Jan 31, 2014, at 3:32 PM, "Tim McGeary" > > wrote: > > >>> > > >>> So what's the price point that EZProxy needs to climb to make it more > > >>> realistic to put resources into an alternative. At $500/year, I > don't > > >> even > > >>> have to think about justifying it. At 1% (or less) of the cost of > > >> position > > >>> with little to no prior experience needed, it doesn't make a lot of > > sense > > >>> to invest in an open source alternative, even on a campus that > heavily > > >> uses > > >>> Shibboleth. > > >>> > > >>> Tim > > >>> > > >>> > > >>> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer > > >> wrote: > > >>> > > >>> Not only that, but it's also expressly designed for the purpose of > > >> reverse > > >>> proxying subscription databases in a library environment. There are > > >> tons > > >>> of things vendors do that would be incredibly frustrating to get > > working > > >>> properly in Squid, nginx, or Apache that have already been solved by > > >>> EZProxy. Which is self-fulfilling: vendors then cater to what > EZProxy > > >> does > > >>> (rather than improving access to their resources). > > >>> > > >>> Art Rhyno used to say that the major thing that was inhibiting the > > >>> widespread adoption of Shibboleth was how simple and cheap EZProxy > was. > > >> I > > >>> think there is a lot of truth to that. > > >>> > > >>> -Ross. > > >>> > > >>> > > >>> On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee < > > kyle.baner...@gmail.com > > wrote: > > >>> > > EZproxy is a self-installing statically compiled single binary > > >>> download, > > with a built-in administrative interface that makes most common > > administrative tasks point-and-click, that works on Linux and > Windows > > systems, and requires very little in the way of resources to run. > It > > also > > has a library of a few hundred vendor stanzas that can be copied and > > pasted > > and work the majority of the time. > > > > To successfully replace EZproxy in this setting, it would need to be > > packaged in such a way that it is equally easy to install and > > >> maintain, > > and > > the library of vendor stanzas would need to be developed as apache > > >>> conf.d > > files. > > > > This. The real gain with EZProxy is that configuring it is crazy > easy. > > >>> You > > just drop it in and run it -- it's feasible for someone with no > > >>> experience > > in proxying or systems administration to get it operational in a few > > minutes. That is why I think virtualizing a system that makes > > accessing > > >>> the > > more powerful features of EZProxy easy is a good alternative. > > > > kyle > > >>> > > >>> > > >>> > > >>> -- > > >>> Tim McGeary > > >>> timmcge...@gmail.com > > >>> GTalk/Yahoo/Skype/Twitter: timmcgeary > > >>> 484-294-7660 (cell) > > >> > > >> > > >> > > >> -- > > >> Tim McGear
Re: [CODE4LIB] EZProxy changes / alternatives ?
On 01/02/14 08:34, Mosior, Benjamin wrote: Does anyone have any thoughts on how to move forward with organizing the development and adoption of an alternative proxy solution? A collaborative Google Doc? Perhaps a LibraryProxy GitHub Organization? I'd say that more than anything else what is needed is for techies to do experiments, document and share the results. These could either follow on from the example of Andrew Anderson earlier in this thread or strike out in different directions. cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
When it comes to hedging bets, I'd sure rather hedge my $50,000 bet than my $500 one. Just sayin'. Roy On Fri, Jan 31, 2014 at 6:04 PM, BWS Johnson wrote: > Salvete! > > Tisn't necessarily Socialist to hedge one's bets. Look at what Wall > St. experts advise when one is unsure of whether to hold or sell. Monopoly > is only ever in the interest of those that hold it. > >Short term the aquarium is enticing, but do you enjoy your > collapsed dorsal fin? > > Cheers, > Brooke > > -- > On Fri, Jan 31, 2014 6:10 PM EST Salazar, Christina wrote: > > >I think though that razor thin budgets aside, the EZProxy using community > is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC > peeps (just kiddin') but now we're so captive to EZProxy, what are our > options if OCLC wants to gradually (or not so gradually) jack up the price? > > > >Does being this captive to a single product justify community developer > time? > > > >I think so but I'm probably just a damn socialist. > > > >On Jan 31, 2014, at 1:36 PM, "Tim McGeary" wrote: > > > >> Even with razor thin budgets, this is a no brainer. May they need > decide > >> between buying 10 new books or license EZProxy? Possibly, but if they > have > >> a need for EZProxy, that's still a no brainer - until a solid OSS > >> replacement that includes as robust a developer /support community comes > >> around. But again, at $500/year, I don't see a lot of incentive to > invest > >> in such a project. > >> > >> > >> On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs >wrote: > >> > >> But there are places on a razor thin budget, and things like this throw > >> them off ball acne > >> > >> Sent from my iPhone > >> > >>> On Jan 31, 2014, at 3:32 PM, "Tim McGeary" > wrote: > >>> > >>> So what's the price point that EZProxy needs to climb to make it more > >>> realistic to put resources into an alternative. At $500/year, I don't > >> even > >>> have to think about justifying it. At 1% (or less) of the cost of > >> position > >>> with little to no prior experience needed, it doesn't make a lot of > sense > >>> to invest in an open source alternative, even on a campus that heavily > >> uses > >>> Shibboleth. > >>> > >>> Tim > >>> > >>> > >>> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer > >> wrote: > >>> > >>> Not only that, but it's also expressly designed for the purpose of > >> reverse > >>> proxying subscription databases in a library environment. There are > >> tons > >>> of things vendors do that would be incredibly frustrating to get > working > >>> properly in Squid, nginx, or Apache that have already been solved by > >>> EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy > >> does > >>> (rather than improving access to their resources). > >>> > >>> Art Rhyno used to say that the major thing that was inhibiting the > >>> widespread adoption of Shibboleth was how simple and cheap EZProxy was. > >> I > >>> think there is a lot of truth to that. > >>> > >>> -Ross. > >>> > >>> > >>> On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee < > kyle.baner...@gmail.com > wrote: > >>> > EZproxy is a self-installing statically compiled single binary > >>> download, > with a built-in administrative interface that makes most common > administrative tasks point-and-click, that works on Linux and Windows > systems, and requires very little in the way of resources to run. It > also > has a library of a few hundred vendor stanzas that can be copied and > pasted > and work the majority of the time. > > To successfully replace EZproxy in this setting, it would need to be > packaged in such a way that it is equally easy to install and > >> maintain, > and > the library of vendor stanzas would need to be developed as apache > >>> conf.d > files. > > This. The real gain with EZProxy is that configuring it is crazy easy. > >>> You > just drop it in and run it -- it's feasible for someone with no > >>> experience > in proxying or systems administration to get it operational in a few > minutes. That is why I think virtualizing a system that makes > accessing > >>> the > more powerful features of EZProxy easy is a good alternative. > > kyle > >>> > >>> > >>> > >>> -- > >>> Tim McGeary > >>> timmcge...@gmail.com > >>> GTalk/Yahoo/Skype/Twitter: timmcgeary > >>> 484-294-7660 (cell) > >> > >> > >> > >> -- > >> Tim McGeary > >> timmcge...@gmail.com > >> GTalk/Yahoo/Skype/Twitter: timmcgeary > >> 484-294-7660 (cell) >
Re: [CODE4LIB] EZProxy changes / alternatives ?
Exactly! OCLC already knows they are the only game in town, that is what drove them to the new pricing scheme, so what is to stop them from jacking up prices even more? They are the Gold, Silver, and Bronze standard, so maybe it is time to develop an alternative, in the hope it will garner vendor support. //Riley Sent from my iPhone > On Jan 31, 2014, at 6:12 PM, "Salazar, Christina" > wrote: > > I think though that razor thin budgets aside, the EZProxy using community is > vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC peeps > (just kiddin') but now we're so captive to EZProxy, what are our options if > OCLC wants to gradually (or not so gradually) jack up the price? > > Does being this captive to a single product justify community developer time? > > I think so but I'm probably just a damn socialist. > >> On Jan 31, 2014, at 1:36 PM, "Tim McGeary" wrote: >> >> Even with razor thin budgets, this is a no brainer. May they need decide >> between buying 10 new books or license EZProxy? Possibly, but if they have >> a need for EZProxy, that's still a no brainer - until a solid OSS >> replacement that includes as robust a developer /support community comes >> around. But again, at $500/year, I don't see a lot of incentive to invest >> in such a project. >> >> >> On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs >> wrote: >> >>> But there are places on a razor thin budget, and things like this throw >>> them off ball acne >>> >>> Sent from my iPhone >>> On Jan 31, 2014, at 3:32 PM, "Tim McGeary" wrote: So what's the price point that EZProxy needs to climb to make it more realistic to put resources into an alternative. At $500/year, I don't >>> even have to think about justifying it. At 1% (or less) of the cost of >>> position with little to no prior experience needed, it doesn't make a lot of sense to invest in an open source alternative, even on a campus that heavily >>> uses Shibboleth. Tim > On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer >>> wrote: > > Not only that, but it's also expressly designed for the purpose of >>> reverse > proxying subscription databases in a library environment. There are >>> tons > of things vendors do that would be incredibly frustrating to get working > properly in Squid, nginx, or Apache that have already been solved by > EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy >>> does > (rather than improving access to their resources). > > Art Rhyno used to say that the major thing that was inhibiting the > widespread adoption of Shibboleth was how simple and cheap EZProxy was. >>> I > think there is a lot of truth to that. > > -Ross. > > > On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee > wrote: > >>> EZproxy is a self-installing statically compiled single binary > download, >>> with a built-in administrative interface that makes most common >>> administrative tasks point-and-click, that works on Linux and Windows >>> systems, and requires very little in the way of resources to run. It >> also >>> has a library of a few hundred vendor stanzas that can be copied and >> pasted >>> and work the majority of the time. >>> >>> To successfully replace EZproxy in this setting, it would need to be >>> packaged in such a way that it is equally easy to install and >>> maintain, >> and >>> the library of vendor stanzas would need to be developed as apache > conf.d >>> files. >> >> This. The real gain with EZProxy is that configuring it is crazy easy. > You >> just drop it in and run it -- it's feasible for someone with no > experience >> in proxying or systems administration to get it operational in a few >> minutes. That is why I think virtualizing a system that makes accessing > the >> more powerful features of EZProxy easy is a good alternative. >> >> kyle -- Tim McGeary timmcge...@gmail.com GTalk/Yahoo/Skype/Twitter: timmcgeary 484-294-7660 (cell) >> >> >> >> -- >> Tim McGeary >> timmcge...@gmail.com >> GTalk/Yahoo/Skype/Twitter: timmcgeary >> 484-294-7660 (cell)
Re: [CODE4LIB] EZProxy changes / alternatives ?
Salvete! Tisn't necessarily Socialist to hedge one's bets. Look at what Wall St. experts advise when one is unsure of whether to hold or sell. Monopoly is only ever in the interest of those that hold it. Short term the aquarium is enticing, but do you enjoy your collapsed dorsal fin? Cheers, Brooke -- On Fri, Jan 31, 2014 6:10 PM EST Salazar, Christina wrote: >I think though that razor thin budgets aside, the EZProxy using community is >vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC peeps >(just kiddin') but now we're so captive to EZProxy, what are our options if >OCLC wants to gradually (or not so gradually) jack up the price? > >Does being this captive to a single product justify community developer time? > >I think so but I'm probably just a damn socialist. > >On Jan 31, 2014, at 1:36 PM, "Tim McGeary" wrote: > >> Even with razor thin budgets, this is a no brainer. May they need decide >> between buying 10 new books or license EZProxy? Possibly, but if they have >> a need for EZProxy, that's still a no brainer - until a solid OSS >> replacement that includes as robust a developer /support community comes >> around. But again, at $500/year, I don't see a lot of incentive to invest >> in such a project. >> >> >> On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs >> wrote: >> >> But there are places on a razor thin budget, and things like this throw >> them off ball acne >> >> Sent from my iPhone >> >>> On Jan 31, 2014, at 3:32 PM, "Tim McGeary" wrote: >>> >>> So what's the price point that EZProxy needs to climb to make it more >>> realistic to put resources into an alternative. At $500/year, I don't >> even >>> have to think about justifying it. At 1% (or less) of the cost of >> position >>> with little to no prior experience needed, it doesn't make a lot of sense >>> to invest in an open source alternative, even on a campus that heavily >> uses >>> Shibboleth. >>> >>> Tim >>> >>> >>> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer >> wrote: >>> >>> Not only that, but it's also expressly designed for the purpose of >> reverse >>> proxying subscription databases in a library environment. There are >> tons >>> of things vendors do that would be incredibly frustrating to get working >>> properly in Squid, nginx, or Apache that have already been solved by >>> EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy >> does >>> (rather than improving access to their resources). >>> >>> Art Rhyno used to say that the major thing that was inhibiting the >>> widespread adoption of Shibboleth was how simple and cheap EZProxy was. >> I >>> think there is a lot of truth to that. >>> >>> -Ross. >>> >>> >>> On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee >>> wrote: >>> EZproxy is a self-installing statically compiled single binary >>> download, with a built-in administrative interface that makes most common administrative tasks point-and-click, that works on Linux and Windows systems, and requires very little in the way of resources to run. It also has a library of a few hundred vendor stanzas that can be copied and pasted and work the majority of the time. To successfully replace EZproxy in this setting, it would need to be packaged in such a way that it is equally easy to install and >> maintain, and the library of vendor stanzas would need to be developed as apache >>> conf.d files. This. The real gain with EZProxy is that configuring it is crazy easy. >>> You just drop it in and run it -- it's feasible for someone with no >>> experience in proxying or systems administration to get it operational in a few minutes. That is why I think virtualizing a system that makes accessing >>> the more powerful features of EZProxy easy is a good alternative. kyle >>> >>> >>> >>> -- >>> Tim McGeary >>> timmcge...@gmail.com >>> GTalk/Yahoo/Skype/Twitter: timmcgeary >>> 484-294-7660 (cell) >> >> >> >> -- >> Tim McGeary >> timmcge...@gmail.com >> GTalk/Yahoo/Skype/Twitter: timmcgeary >> 484-294-7660 (cell)
Re: [CODE4LIB] EZProxy changes / alternatives ?
On Fri, Jan 31, 2014 at 3:10 PM, Salazar, Christina < christina.sala...@csuci.edu> wrote: > I think though that razor thin budgets aside, the EZProxy using community > is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC > peeps (just kiddin') but now we're so captive to EZProxy, what are our > options if OCLC wants to gradually (or not so gradually) jack up the price? > > Does being this captive to a single product justify community developer > time? > In all fairness, most of us could be said to be captive to a number of open source tools. OCLC is a library cooperative so member libraries have mechanisms to push things one way or the other (keeping in mind that it's a big ship to turn). But every now and then, member libraries speak up when they see something that they think doesn't serve their interests and OCLC changes as a result -- remember the record use policy flap a couple years back? I seriously doubt they'd do anything too nutty with EZProxy because too many libraries care about it. kyle
Re: [CODE4LIB] EZProxy changes / alternatives ?
I think though that razor thin budgets aside, the EZProxy using community is vulnerable to what amounts to a monopoly. Don't get any ideas, OCLC peeps (just kiddin') but now we're so captive to EZProxy, what are our options if OCLC wants to gradually (or not so gradually) jack up the price? Does being this captive to a single product justify community developer time? I think so but I'm probably just a damn socialist. On Jan 31, 2014, at 1:36 PM, "Tim McGeary" wrote: > Even with razor thin budgets, this is a no brainer. May they need decide > between buying 10 new books or license EZProxy? Possibly, but if they have > a need for EZProxy, that's still a no brainer - until a solid OSS > replacement that includes as robust a developer /support community comes > around. But again, at $500/year, I don't see a lot of incentive to invest > in such a project. > > > On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs wrote: > >> But there are places on a razor thin budget, and things like this throw >> them off ball acne >> >> Sent from my iPhone >> >>> On Jan 31, 2014, at 3:32 PM, "Tim McGeary" wrote: >>> >>> So what's the price point that EZProxy needs to climb to make it more >>> realistic to put resources into an alternative. At $500/year, I don't >> even >>> have to think about justifying it. At 1% (or less) of the cost of >> position >>> with little to no prior experience needed, it doesn't make a lot of sense >>> to invest in an open source alternative, even on a campus that heavily >> uses >>> Shibboleth. >>> >>> Tim >>> >>> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer >> wrote: Not only that, but it's also expressly designed for the purpose of >> reverse proxying subscription databases in a library environment. There are >> tons of things vendors do that would be incredibly frustrating to get working properly in Squid, nginx, or Apache that have already been solved by EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy >> does (rather than improving access to their resources). Art Rhyno used to say that the major thing that was inhibiting the widespread adoption of Shibboleth was how simple and cheap EZProxy was. >> I think there is a lot of truth to that. -Ross. On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee wrote: >> EZproxy is a self-installing statically compiled single binary download, >> with a built-in administrative interface that makes most common >> administrative tasks point-and-click, that works on Linux and Windows >> systems, and requires very little in the way of resources to run. It > also >> has a library of a few hundred vendor stanzas that can be copied and > pasted >> and work the majority of the time. >> >> To successfully replace EZproxy in this setting, it would need to be >> packaged in such a way that it is equally easy to install and >> maintain, > and >> the library of vendor stanzas would need to be developed as apache conf.d >> files. > > This. The real gain with EZProxy is that configuring it is crazy easy. You > just drop it in and run it -- it's feasible for someone with no experience > in proxying or systems administration to get it operational in a few > minutes. That is why I think virtualizing a system that makes accessing the > more powerful features of EZProxy easy is a good alternative. > > kyle >>> >>> >>> >>> -- >>> Tim McGeary >>> timmcge...@gmail.com >>> GTalk/Yahoo/Skype/Twitter: timmcgeary >>> 484-294-7660 (cell) > > > > -- > Tim McGeary > timmcge...@gmail.com > GTalk/Yahoo/Skype/Twitter: timmcgeary > 484-294-7660 (cell)
Re: [CODE4LIB] EZProxy changes / alternatives ?
Even with razor thin budgets, this is a no brainer. May they need decide between buying 10 new books or license EZProxy? Possibly, but if they have a need for EZProxy, that's still a no brainer - until a solid OSS replacement that includes as robust a developer /support community comes around. But again, at $500/year, I don't see a lot of incentive to invest in such a project. On Fri, Jan 31, 2014 at 3:55 PM, Riley Childs wrote: > But there are places on a razor thin budget, and things like this throw > them off ball acne > > Sent from my iPhone > > > On Jan 31, 2014, at 3:32 PM, "Tim McGeary" wrote: > > > > So what's the price point that EZProxy needs to climb to make it more > > realistic to put resources into an alternative. At $500/year, I don't > even > > have to think about justifying it. At 1% (or less) of the cost of > position > > with little to no prior experience needed, it doesn't make a lot of sense > > to invest in an open source alternative, even on a campus that heavily > uses > > Shibboleth. > > > > Tim > > > > > >> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer > wrote: > >> > >> Not only that, but it's also expressly designed for the purpose of > reverse > >> proxying subscription databases in a library environment. There are > tons > >> of things vendors do that would be incredibly frustrating to get working > >> properly in Squid, nginx, or Apache that have already been solved by > >> EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy > does > >> (rather than improving access to their resources). > >> > >> Art Rhyno used to say that the major thing that was inhibiting the > >> widespread adoption of Shibboleth was how simple and cheap EZProxy was. > I > >> think there is a lot of truth to that. > >> > >> -Ross. > >> > >> > >> On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee >>> wrote: > >> > EZproxy is a self-installing statically compiled single binary > >> download, > with a built-in administrative interface that makes most common > administrative tasks point-and-click, that works on Linux and Windows > systems, and requires very little in the way of resources to run. It > >>> also > has a library of a few hundred vendor stanzas that can be copied and > >>> pasted > and work the majority of the time. > > To successfully replace EZproxy in this setting, it would need to be > packaged in such a way that it is equally easy to install and > maintain, > >>> and > the library of vendor stanzas would need to be developed as apache > >> conf.d > files. > >>> > >>> This. The real gain with EZProxy is that configuring it is crazy easy. > >> You > >>> just drop it in and run it -- it's feasible for someone with no > >> experience > >>> in proxying or systems administration to get it operational in a few > >>> minutes. That is why I think virtualizing a system that makes accessing > >> the > >>> more powerful features of EZProxy easy is a good alternative. > >>> > >>> kyle > > > > > > > > -- > > Tim McGeary > > timmcge...@gmail.com > > GTalk/Yahoo/Skype/Twitter: timmcgeary > > 484-294-7660 (cell) > -- Tim McGeary timmcge...@gmail.com GTalk/Yahoo/Skype/Twitter: timmcgeary 484-294-7660 (cell)
Re: [CODE4LIB] EZProxy changes / alternatives ?
But there are places on a razor thin budget, and things like this throw them off ball acne Sent from my iPhone > On Jan 31, 2014, at 3:32 PM, "Tim McGeary" wrote: > > So what's the price point that EZProxy needs to climb to make it more > realistic to put resources into an alternative. At $500/year, I don't even > have to think about justifying it. At 1% (or less) of the cost of position > with little to no prior experience needed, it doesn't make a lot of sense > to invest in an open source alternative, even on a campus that heavily uses > Shibboleth. > > Tim > > >> On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer wrote: >> >> Not only that, but it's also expressly designed for the purpose of reverse >> proxying subscription databases in a library environment. There are tons >> of things vendors do that would be incredibly frustrating to get working >> properly in Squid, nginx, or Apache that have already been solved by >> EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy does >> (rather than improving access to their resources). >> >> Art Rhyno used to say that the major thing that was inhibiting the >> widespread adoption of Shibboleth was how simple and cheap EZProxy was. I >> think there is a lot of truth to that. >> >> -Ross. >> >> >> On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee >> wrote: >> EZproxy is a self-installing statically compiled single binary >> download, with a built-in administrative interface that makes most common administrative tasks point-and-click, that works on Linux and Windows systems, and requires very little in the way of resources to run. It >>> also has a library of a few hundred vendor stanzas that can be copied and >>> pasted and work the majority of the time. To successfully replace EZproxy in this setting, it would need to be packaged in such a way that it is equally easy to install and maintain, >>> and the library of vendor stanzas would need to be developed as apache >> conf.d files. >>> >>> This. The real gain with EZProxy is that configuring it is crazy easy. >> You >>> just drop it in and run it -- it's feasible for someone with no >> experience >>> in proxying or systems administration to get it operational in a few >>> minutes. That is why I think virtualizing a system that makes accessing >> the >>> more powerful features of EZProxy easy is a good alternative. >>> >>> kyle > > > > -- > Tim McGeary > timmcge...@gmail.com > GTalk/Yahoo/Skype/Twitter: timmcgeary > 484-294-7660 (cell)
Re: [CODE4LIB] EZProxy changes / alternatives ?
So what's the price point that EZProxy needs to climb to make it more realistic to put resources into an alternative. At $500/year, I don't even have to think about justifying it. At 1% (or less) of the cost of position with little to no prior experience needed, it doesn't make a lot of sense to invest in an open source alternative, even on a campus that heavily uses Shibboleth. Tim On Fri, Jan 31, 2014 at 1:36 PM, Ross Singer wrote: > Not only that, but it's also expressly designed for the purpose of reverse > proxying subscription databases in a library environment. There are tons > of things vendors do that would be incredibly frustrating to get working > properly in Squid, nginx, or Apache that have already been solved by > EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy does > (rather than improving access to their resources). > > Art Rhyno used to say that the major thing that was inhibiting the > widespread adoption of Shibboleth was how simple and cheap EZProxy was. I > think there is a lot of truth to that. > > -Ross. > > > On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee >wrote: > > > > EZproxy is a self-installing statically compiled single binary > download, > > > with a built-in administrative interface that makes most common > > > administrative tasks point-and-click, that works on Linux and Windows > > > systems, and requires very little in the way of resources to run. It > > also > > > has a library of a few hundred vendor stanzas that can be copied and > > pasted > > > and work the majority of the time. > > > > > > To successfully replace EZproxy in this setting, it would need to be > > > packaged in such a way that it is equally easy to install and maintain, > > and > > > the library of vendor stanzas would need to be developed as apache > conf.d > > > files. > > > > > > > This. The real gain with EZProxy is that configuring it is crazy easy. > You > > just drop it in and run it -- it's feasible for someone with no > experience > > in proxying or systems administration to get it operational in a few > > minutes. That is why I think virtualizing a system that makes accessing > the > > more powerful features of EZProxy easy is a good alternative. > > > > kyle > > > -- Tim McGeary timmcge...@gmail.com GTalk/Yahoo/Skype/Twitter: timmcgeary 484-294-7660 (cell)
Re: [CODE4LIB] EZProxy changes / alternatives ?
Does anyone have any thoughts on how to move forward with organizing the development and adoption of an alternative proxy solution? A collaborative Google Doc? Perhaps a LibraryProxy GitHub Organization? Benjamin Mosior
Re: [CODE4LIB] EZProxy changes / alternatives ?
Not only that, but it's also expressly designed for the purpose of reverse proxying subscription databases in a library environment. There are tons of things vendors do that would be incredibly frustrating to get working properly in Squid, nginx, or Apache that have already been solved by EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy does (rather than improving access to their resources). Art Rhyno used to say that the major thing that was inhibiting the widespread adoption of Shibboleth was how simple and cheap EZProxy was. I think there is a lot of truth to that. -Ross. On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee wrote: > > EZproxy is a self-installing statically compiled single binary download, > > with a built-in administrative interface that makes most common > > administrative tasks point-and-click, that works on Linux and Windows > > systems, and requires very little in the way of resources to run. It > also > > has a library of a few hundred vendor stanzas that can be copied and > pasted > > and work the majority of the time. > > > > To successfully replace EZproxy in this setting, it would need to be > > packaged in such a way that it is equally easy to install and maintain, > and > > the library of vendor stanzas would need to be developed as apache conf.d > > files. > > > > This. The real gain with EZProxy is that configuring it is crazy easy. You > just drop it in and run it -- it's feasible for someone with no experience > in proxying or systems administration to get it operational in a few > minutes. That is why I think virtualizing a system that makes accessing the > more powerful features of EZProxy easy is a good alternative. > > kyle >
Re: [CODE4LIB] EZProxy changes / alternatives ?
> EZproxy is a self-installing statically compiled single binary download, > with a built-in administrative interface that makes most common > administrative tasks point-and-click, that works on Linux and Windows > systems, and requires very little in the way of resources to run. It also > has a library of a few hundred vendor stanzas that can be copied and pasted > and work the majority of the time. > > To successfully replace EZproxy in this setting, it would need to be > packaged in such a way that it is equally easy to install and maintain, and > the library of vendor stanzas would need to be developed as apache conf.d > files. > This. The real gain with EZProxy is that configuring it is crazy easy. You just drop it in and run it -- it's feasible for someone with no experience in proxying or systems administration to get it operational in a few minutes. That is why I think virtualizing a system that makes accessing the more powerful features of EZProxy easy is a good alternative. kyle
Re: [CODE4LIB] EZProxy changes / alternatives ?
EZproxy is a self-installing statically compiled single binary download, with a built-in administrative interface that makes most common administrative tasks point-and-click, that works on Linux and Windows systems, and requires very little in the way of resources to run. It also has a library of a few hundred vendor stanzas that can be copied and pasted and work the majority of the time. To successfully replace EZproxy in this setting, it would need to be packaged in such a way that it is equally easy to install and maintain, and the library of vendor stanzas would need to be developed as apache conf.d files. Re: nginx from another reply in this thread, I am keeping my eye on it for future projects, but one thing it does not have currently is the wealth of Apache modules. Some of the authentication that is commonly used in a library setting are supported by existing Apache modules, while nginx does not support them. Since it was developed with a different set of priorities, supporting things like Athens/CAS/SAML were not the main focus of nginx historically. -- Andrew Anderson, Director of Development, Library and Information Resources Network, Inc. http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes On Jan 31, 2014, at 12:43, Timothy Cornwell wrote: > I have an IT background and some apache proxy experience, and it seems fairly > easy - for me. I understand it may not be for libraries with limited IT > resources. I am not at all familiar with EZProxy, so I have to ask: > > What is it about EZProxy that makes it attractive for those libraries with > limited IT resources? > > -T > > > > -Original Message- > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Kyle > Banerjee > Sent: Friday, January 31, 2014 12:14 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? > > Many good ideas in this thread. > > One thing I'd just like to throw out there is that there are some ideas that > may be good to distribute in the form of virtual machines and this might be > one of them. > > Proxying is needed by practically all libraries and takes little in terms of > systems resources. But many libraries with limited IT resources would have > trouble implementing alternatives to ezproxy -- especially if they have to > use authentication features not supported by Apache HTTPD. Even for those who > do have enough staff time, it seems kind of nuts to have everyone spending > time solving the same problems. > > kyle > > > On Fri, Jan 31, 2014 at 5:43 AM, Ryan Eby wrote: > >> There was actually a breakout in 2011? Code4lib discussing Apache and >> using it as a proxy. I believe Terry Reese and Jeremy Frumkin, then >> from Oregon?, were the ones leading it. There was lots of interest but >> I'm not sure if anything took off or if they have documentation >> somewhere of how far they got. I remember it being about getting >> something a consortia of libraries could use together so may have been >> more complex requirements than what is looked for here. >> >> >> http://wiki.code4lib.org/index.php/Can_we_hack_on_this:_Open_Extensibl >> e_Proxy:_going_beyond_EZProxy%3F >> >> -- >> Ryan Eby >>
Re: [CODE4LIB] EZProxy changes / alternatives ?
It is ubiquitous in the library community, so support is easy to find. There is also a lot of EZproxy support from vendors, who often post EZproxy config setups for their databases on their support sites. Josh Welker -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Timothy Cornwell Sent: Friday, January 31, 2014 11:44 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? I have an IT background and some apache proxy experience, and it seems fairly easy - for me. I understand it may not be for libraries with limited IT resources. I am not at all familiar with EZProxy, so I have to ask: What is it about EZProxy that makes it attractive for those libraries with limited IT resources? -T -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Kyle Banerjee Sent: Friday, January 31, 2014 12:14 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? Many good ideas in this thread. One thing I'd just like to throw out there is that there are some ideas that may be good to distribute in the form of virtual machines and this might be one of them. Proxying is needed by practically all libraries and takes little in terms of systems resources. But many libraries with limited IT resources would have trouble implementing alternatives to ezproxy -- especially if they have to use authentication features not supported by Apache HTTPD. Even for those who do have enough staff time, it seems kind of nuts to have everyone spending time solving the same problems. kyle On Fri, Jan 31, 2014 at 5:43 AM, Ryan Eby wrote: > There was actually a breakout in 2011? Code4lib discussing Apache and > using it as a proxy. I believe Terry Reese and Jeremy Frumkin, then > from Oregon?, were the ones leading it. There was lots of interest but > I'm not sure if anything took off or if they have documentation > somewhere of how far they got. I remember it being about getting > something a consortia of libraries could use together so may have been > more complex requirements than what is looked for here. > > > http://wiki.code4lib.org/index.php/Can_we_hack_on_this:_Open_Extensibl > e_Proxy:_going_beyond_EZProxy%3F > > -- > Ryan Eby >
Re: [CODE4LIB] EZProxy changes / alternatives ?
I have an IT background and some apache proxy experience, and it seems fairly easy - for me. I understand it may not be for libraries with limited IT resources. I am not at all familiar with EZProxy, so I have to ask: What is it about EZProxy that makes it attractive for those libraries with limited IT resources? -T -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Kyle Banerjee Sent: Friday, January 31, 2014 12:14 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? Many good ideas in this thread. One thing I'd just like to throw out there is that there are some ideas that may be good to distribute in the form of virtual machines and this might be one of them. Proxying is needed by practically all libraries and takes little in terms of systems resources. But many libraries with limited IT resources would have trouble implementing alternatives to ezproxy -- especially if they have to use authentication features not supported by Apache HTTPD. Even for those who do have enough staff time, it seems kind of nuts to have everyone spending time solving the same problems. kyle On Fri, Jan 31, 2014 at 5:43 AM, Ryan Eby wrote: > There was actually a breakout in 2011? Code4lib discussing Apache and > using it as a proxy. I believe Terry Reese and Jeremy Frumkin, then > from Oregon?, were the ones leading it. There was lots of interest but > I'm not sure if anything took off or if they have documentation > somewhere of how far they got. I remember it being about getting > something a consortia of libraries could use together so may have been > more complex requirements than what is looked for here. > > > http://wiki.code4lib.org/index.php/Can_we_hack_on_this:_Open_Extensibl > e_Proxy:_going_beyond_EZProxy%3F > > -- > Ryan Eby >
Re: [CODE4LIB] EZProxy changes / alternatives ?
Many good ideas in this thread. One thing I'd just like to throw out there is that there are some ideas that may be good to distribute in the form of virtual machines and this might be one of them. Proxying is needed by practically all libraries and takes little in terms of systems resources. But many libraries with limited IT resources would have trouble implementing alternatives to ezproxy -- especially if they have to use authentication features not supported by Apache HTTPD. Even for those who do have enough staff time, it seems kind of nuts to have everyone spending time solving the same problems. kyle On Fri, Jan 31, 2014 at 5:43 AM, Ryan Eby wrote: > There was actually a breakout in 2011? Code4lib discussing Apache and > using it as a proxy. I believe Terry Reese and Jeremy Frumkin, then from > Oregon?, were the ones leading it. There was lots of interest but I'm not > sure if anything took off or if they have documentation somewhere of how > far they got. I remember it being about getting something a consortia of > libraries could use together so may have been more complex requirements > than what is looked for here. > > > http://wiki.code4lib.org/index.php/Can_we_hack_on_this:_Open_Extensible_Proxy:_going_beyond_EZProxy%3F > > -- > Ryan Eby >
Re: [CODE4LIB] EZProxy changes / alternatives ?
If there is a demand for an EZProxy alternative, nginx might be a better way to go. Nginx is a reverse proxy ootb, and it is very configurable. It is fast, simple and, notably, it is fast. Cary On Jan 31, 2014, at 5:43 AM, Ryan Eby wrote: > There was actually a breakout in 2011? Code4lib discussing Apache and using > it as a proxy. I believe Terry Reese and Jeremy Frumkin, then from Oregon?, > were the ones leading it. There was lots of interest but I’m not sure if > anything took off or if they have documentation somewhere of how far they > got. I remember it being about getting something a consortia of libraries > could use together so may have been more complex requirements than what is > looked for here. > > http://wiki.code4lib.org/index.php/Can_we_hack_on_this:_Open_Extensible_Proxy:_going_beyond_EZProxy%3F > > -- > Ryan Eby
Re: [CODE4LIB] EZProxy changes / alternatives ?
There was actually a breakout in 2011? Code4lib discussing Apache and using it as a proxy. I believe Terry Reese and Jeremy Frumkin, then from Oregon?, were the ones leading it. There was lots of interest but I’m not sure if anything took off or if they have documentation somewhere of how far they got. I remember it being about getting something a consortia of libraries could use together so may have been more complex requirements than what is looked for here. http://wiki.code4lib.org/index.php/Can_we_hack_on_this:_Open_Extensible_Proxy:_going_beyond_EZProxy%3F -- Ryan Eby
Re: [CODE4LIB] EZProxy changes / alternatives ?
Well I think there are acctually working solutions if you Google EZProxy squid you find tons of people who have cobbled together solutions, you just need the best pieces together to make it work! Who wants to start the GitHub repo? Sent from my iPhone > On Jan 29, 2014, at 8:58 PM, "Scott Prater" wrote: > > I second Stuart's kudos. Replacing EZProxy with an Apache proxy sounds just > crazy enough to be brilliant. I could see an open source recipe book taking > shape: how to accomplish EZProxy functions using Apache modules and their > directives. I think that might end up being more useful than yet another > standalone proxy application. > > -- Scott >> On 01/29/14, stuart yeates wrote: >> Thank you Andrew, that is insanely useful. >> >> cheers >> stuart >> >>> On 30/01/14 12:00, Andrew Anderson wrote: >>> When OCLC first announced their purchase of EZproxy, we started a low >>> priority research project to see what the alternatives were a few years >>> ago, and what it would take to bring them into a production ready state. >>> The two open source solutions we evaluated were Squid and Apache HTTPd. We >>> considered other options (e.g. Apache Traffic Server), but limited the >>> research to these two pieces of software since they are already widely used >>> and familiar to most system administrators. >>> >>> Long story short, Squid did not support URL rewriting in a way that we felt >>> would be able to be supported well, between requiring patches to the core >>> C++ server code, or an external rewriting processes, or an ICAP server >>> implementation. Some of that has improved a bit since the original >>> evaluation, but the built-in support for URL rewriting may still need some >>> time to mature. Another aspect of Squid that did not seem to be a good fit >>> was that it is somewhat limited in its authentication mechanisms vs Apache >>> HTTPd. >>> >>> So we moved on to evaluating Apache HTTPd with the mod_proxy family of >>> modules. While Apache HTTPd does not support the advanced cache federation >>> features as Squid, it has grown to be a robust proxy solution in its own >>> right, and the 2.4 release appears to have all of the required pieces out >>> of the box, with the mod_proxy_html module functionality. In addition to >>> basic URL rewriting support, you get full HTTP protocol support, mature >>> IPv6 support, GZIP support, just about any authentication mechanism you >>> need, a server that you can self-host content with easily, as well as a >>> built-in HTTP object cache. >>> >>> How would it work? >>> >>> Here’s the current EZproxy stanza for ProQuest: >>> >>> HTTPHeader X-Requested-With >>> HTTPHeader Accept-Encoding >>> Title ProQuest >>> URL http://search.proquest.com/ip >>> DJ proquest.com >>> HJ gateway.proquest.com >>> DJ umi.com >>> HJ fedsearch.proquest.com >>> HJ literature.proquest.com >>> DJ conquest-leg-insight.com >>> DJ conquestsystems.com >>> DJ m.search.proquest.com >>> DJ media.proquest.com >>> NeverProxy order.proquest.com >>> NeverProxy rss.proquest.com >>> >>> Here’s an Apache HTTPd configuration using ProQuest that accomplishes much >>> of the same functionality for the main search.proquest.com interface: >>> >>> >>> ServerName search.proquest.com.fqdn >>> >>> ProxyRequests Off >>> ProxyVia On >>> >>> RewriteEngine On >>> RewriteRule ^/(.*) http://search.proquest.com/$1 [P] >>> >>> >>> AllowMethods GET POST OPTIONS >>> ProxyPassReverse http://search.proquest.com/ >>> ProxyPassReverseCookieDomain search.proquest.com search.proquest.com.fqdn >>> CacheEnable disk >>> SetOutputFilter INFLATE;DEFLATE >>> Header Append Vary User-Agent env=!dont-vary >>> # Put Authentication directives here >>> ErrorDocument 401 /path/to/login >>> Require Valid-User >>> >>> >>> >>> A few notes on this: >>> >>> - There is no need for NeverProxy: if you do not define a VirtualHost for >>> the hostname, it is not proxied. So instead of HJ and DJ lines, you add a >>> new VirtualHost block for each hostname that needs to be proxied. The >>> astute will ask “what about services that have dozens or hundreds of host >>> entries, like Sage?” Those can be handled by the ProxyExpress features in >>> Apache HTTPd. >>> >>> - There is no need for HTTPHeader: since Apache HTTPd is a full HTTP >>> proxy/server, it supports all HTTP headers natively. >>> >>> - Some of the hostnames that are in EZproxy stanzas are not needed, and >>> some are legacy hostnames that are no longer used by the vendor >>> >>> - Some of the hostnames that are in EZproxy stanzas are for CDN hosted >>> content that requires no special access (e.g. JavaScript/CSS/graphics >>> assets that make up the vendor’s user interface). Another example: how many >>> of you have “DJ google.com” in one of your stanzas? Now how many of you >>> registered your IP addresses with Google in any way? Outside of Google >>> Scholar, I suspect the answer to those questions are “nearly everyone” and >>> “nearly no o
Re: [CODE4LIB] EZProxy changes / alternatives ?
I second Stuart's kudos. Replacing EZProxy with an Apache proxy sounds just crazy enough to be brilliant. I could see an open source recipe book taking shape: how to accomplish EZProxy functions using Apache modules and their directives. I think that might end up being more useful than yet another standalone proxy application. -- Scott On 01/29/14, stuart yeates wrote: > Thank you Andrew, that is insanely useful. > > cheers > stuart > > On 30/01/14 12:00, Andrew Anderson wrote: > >When OCLC first announced their purchase of EZproxy, we started a low > >priority research project to see what the alternatives were a few years ago, > >and what it would take to bring them into a production ready state. The two > >open source solutions we evaluated were Squid and Apache HTTPd. We > >considered other options (e.g. Apache Traffic Server), but limited the > >research to these two pieces of software since they are already widely used > >and familiar to most system administrators. > > > >Long story short, Squid did not support URL rewriting in a way that we felt > >would be able to be supported well, between requiring patches to the core > >C++ server code, or an external rewriting processes, or an ICAP server > >implementation. Some of that has improved a bit since the original > >evaluation, but the built-in support for URL rewriting may still need some > >time to mature. Another aspect of Squid that did not seem to be a good fit > >was that it is somewhat limited in its authentication mechanisms vs Apache > >HTTPd. > > > >So we moved on to evaluating Apache HTTPd with the mod_proxy family of > >modules. While Apache HTTPd does not support the advanced cache federation > >features as Squid, it has grown to be a robust proxy solution in its own > >right, and the 2.4 release appears to have all of the required pieces out of > >the box, with the mod_proxy_html module functionality. In addition to basic > >URL rewriting support, you get full HTTP protocol support, mature IPv6 > >support, GZIP support, just about any authentication mechanism you need, a > >server that you can self-host content with easily, as well as a built-in > >HTTP object cache. > > > >How would it work? > > > >Here’s the current EZproxy stanza for ProQuest: > > > >HTTPHeader X-Requested-With > >HTTPHeader Accept-Encoding > >Title ProQuest > >URL http://search.proquest.com/ip > >DJ proquest.com > >HJ gateway.proquest.com > >DJ umi.com > >HJ fedsearch.proquest.com > >HJ literature.proquest.com > >DJ conquest-leg-insight.com > >DJ conquestsystems.com > >DJ m.search.proquest.com > >DJ media.proquest.com > >NeverProxy order.proquest.com > >NeverProxy rss.proquest.com > > > >Here’s an Apache HTTPd configuration using ProQuest that accomplishes much > >of the same functionality for the main search.proquest.com interface: > > > > > > ServerName search.proquest.com.fqdn > > > > ProxyRequests Off > > ProxyVia On > > > > RewriteEngine On > > RewriteRule ^/(.*) http://search.proquest.com/$1 [P] > > > > > > AllowMethods GET POST OPTIONS > > ProxyPassReverse http://search.proquest.com/ > > ProxyPassReverseCookieDomain search.proquest.com search.proquest.com.fqdn > > CacheEnable disk > > SetOutputFilter INFLATE;DEFLATE > > Header Append Vary User-Agent env=!dont-vary > > # Put Authentication directives here > > ErrorDocument 401 /path/to/login > > Require Valid-User > > > > > > > >A few notes on this: > > > >- There is no need for NeverProxy: if you do not define a VirtualHost for > >the hostname, it is not proxied. So instead of HJ and DJ lines, you add a > >new VirtualHost block for each hostname that needs to be proxied. The astute > >will ask “what about services that have dozens or hundreds of host entries, > >like Sage?” Those can be handled by the ProxyExpress features in Apache > >HTTPd. > > > >- There is no need for HTTPHeader: since Apache HTTPd is a full HTTP > >proxy/server, it supports all HTTP headers natively. > > > >- Some of the hostnames that are in EZproxy stanzas are not needed, and some > >are legacy hostnames that are no longer used by the vendor > > > >- Some of the hostnames that are in EZproxy stanzas are for CDN hosted > >content that requires no special access (e.g. JavaScript/CSS/graphics assets > >that make up the vendor’s user interface). Another example: how many of you > >have “DJ google.com” in one of your stanzas? Now how many of you registered > >your IP addresses with Google in any way? Outside of Google Scholar, I > >suspect the answer to those questions are “nearly everyone” and “nearly no > >one”, respectively. > > > >- Some of the hostnames are for things that no sane person would do: How > >many people run their discovery services through their EZproxy server vs. > >authenticating their discovery platform by IP address with vendors directly? > > > >- Something that this configuration does that EZproxy does not do is enable > >object caching. This can easily save 30-50% of your
Re: [CODE4LIB] EZProxy changes / alternatives ?
EZproxy can achieve the same result with > an external caching proxy server). > > - More complex vendor platforms (e.g. Gale Cengage) need ProxyHTML > directives and ProxyHTMLURLMap configured, and multiple VirtualHost > sections to get them fully working. These can be a little fun to get > working initially. > > - Some services need redirects edited to work correctly, and not break out > of the proxy: > > Header edit Location http://vendor/ http://vendor.fqdn/ > > - Some vendors send wrong HTTP headers for the MIME type, and > mod_proxy_html exposes this in some cases as it rewrites the page. There > may be a better way to do this, but this is what I threw together for > testing: > > > ProxyHTMLEnable Off > SetOutputFilter INFLATE;dummy-html-to-plain > ExtFilterOptions LogStdErr Onfail=remove > > ExtFilterDefine dummy-html-to-plain mode=output intype=text/html > outtype=text/plain cmd="/bin/cat -" > > So what's currently missing in the Apache HTTPd solution? > > - Services that use an authentication token (predominantly ebook vendors) > need special support written. I have been entertaining using mod_lua for > this to make this support relatively easy for someone who is not hard-core > technical to maintain. > > - Services that are not IP authenticated, but use one of the Form-based > authentication variants. I suspect that an approach that injects a script > tag into the page pointing to javascript that handles the form > fill/submission might be a sane approach here. This should also cleanly > deal with the ASP.net abominations that use __PAGESTATE to store sessions > client-side instead of server-side. > > - EZproxy's built-in DNS server (enabled with the "DNS" directive) would > need to be handled using a separate DNS server (there are several options > to choose from). > > - In this setup, standard systems-level management and reporting tools > would be used instead of the /admin interface in EZproxy > > - In this setup, the functionality of the EZproxy /menu URL would need to > be handled externally. This may not be a real issue, as many academic > sites already use LMS or portal systems instead of the EZproxy to direct > students to resources, so this feature may not be as critical to replicate. > > - And of course, extensive testing. While the above ProQuest stanza works > for the main ProQuest search interface, it won't work for everyone, > everywhere just yet. > > Bottom line: Yes, Apache HTTPd is a viable EZproxy alternative if you have > a system administrator who knows their way around Apache HTTPd, and are > willing to spend some time getting to know your vendor services intimately. > > All of this testing was done on Fedora 19 for the 2.4 version of HTTPd, > which should be available in RHEL7/CentOS7 soon, so about the time that > hard decisions are to be made regarding EZproxy vs something else, that > something else may very well be Apache HTTPd with vendor-specific > configuration files. > > -- > Andrew Anderson, Director of Development, Library and Information > Resources Network, Inc. > http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | > http://www.facebook.com/LIRNnotes > > On Jan 29, 2014, at 14:42, Margo Duncan wrote: > > > Would you *have* to be hosted? We're in a rural part of the USA and > network connections from here to anywhere aren't great, so we try to host > most everything we can. EZProxy really is "EZ" to host yourself. > > > > Margo > > > > -Original Message- > > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of > stuart yeates > > Sent: Wednesday, January 29, 2014 1:40 PM > > To: CODE4LIB@LISTSERV.ND.EDU > > Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? > > > > The text I've seen talks about "[e]xpanded reporting capabilities to > support management decisions" in forthcoming versions and encourages > towards the hosted solution. > > > > Since we're in .nz, they'd put our hosted proxy server in .au, but the > network connection between .nz and .au is via the continental .us, which > puts an extra trans-pacific network loop in 99% of our proxied network > connections. > > > > cheers > > stuart > > > > On 30/01/14 03:14, Ingraham Dwyer, Andy wrote: > >> OCLC announced in April 2013 the changes in their license model for > North America. EZProxy's license moves from requiring a one-time purchase > of US$495 to a *annual* fee of $495, or through their hosted service, with > the fee depending on
Re: [CODE4LIB] EZProxy changes / alternatives ?
complex vendor platforms (e.g. Gale Cengage) need ProxyHTML > directives and ProxyHTMLURLMap configured, and multiple VirtualHost > sections to get them fully working. These can be a little fun to get > working initially. > > - Some services need redirects edited to work correctly, and not break out > of the proxy: > > Header edit Location http://vendor/ http://vendor.fqdn/ > > - Some vendors send wrong HTTP headers for the MIME type, and > mod_proxy_html exposes this in some cases as it rewrites the page. There > may be a better way to do this, but this is what I threw together for > testing: > > > ProxyHTMLEnable Off > SetOutputFilter INFLATE;dummy-html-to-plain > ExtFilterOptions LogStdErr Onfail=remove > > ExtFilterDefine dummy-html-to-plain mode=output intype=text/html > outtype=text/plain cmd="/bin/cat -" > > So what's currently missing in the Apache HTTPd solution? > > - Services that use an authentication token (predominantly ebook vendors) > need special support written. I have been entertaining using mod_lua for > this to make this support relatively easy for someone who is not hard-core > technical to maintain. > > - Services that are not IP authenticated, but use one of the Form-based > authentication variants. I suspect that an approach that injects a script > tag into the page pointing to javascript that handles the form > fill/submission might be a sane approach here. This should also cleanly > deal with the ASP.net abominations that use __PAGESTATE to store sessions > client-side instead of server-side. > > - EZproxy's built-in DNS server (enabled with the "DNS" directive) would > need to be handled using a separate DNS server (there are several options > to choose from). > > - In this setup, standard systems-level management and reporting tools > would be used instead of the /admin interface in EZproxy > > - In this setup, the functionality of the EZproxy /menu URL would need to > be handled externally. This may not be a real issue, as many academic > sites already use LMS or portal systems instead of the EZproxy to direct > students to resources, so this feature may not be as critical to replicate. > > - And of course, extensive testing. While the above ProQuest stanza works > for the main ProQuest search interface, it won't work for everyone, > everywhere just yet. > > Bottom line: Yes, Apache HTTPd is a viable EZproxy alternative if you have > a system administrator who knows their way around Apache HTTPd, and are > willing to spend some time getting to know your vendor services intimately. > > All of this testing was done on Fedora 19 for the 2.4 version of HTTPd, > which should be available in RHEL7/CentOS7 soon, so about the time that > hard decisions are to be made regarding EZproxy vs something else, that > something else may very well be Apache HTTPd with vendor-specific > configuration files. > > -- > Andrew Anderson, Director of Development, Library and Information > Resources Network, Inc. > http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | > http://www.facebook.com/LIRNnotes > > On Jan 29, 2014, at 14:42, Margo Duncan wrote: > > > Would you *have* to be hosted? We're in a rural part of the USA and > network connections from here to anywhere aren't great, so we try to host > most everything we can. EZProxy really is "EZ" to host yourself. > > > > Margo > > > > -Original Message- > > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of > stuart yeates > > Sent: Wednesday, January 29, 2014 1:40 PM > > To: CODE4LIB@LISTSERV.ND.EDU > > Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? > > > > The text I've seen talks about "[e]xpanded reporting capabilities to > support management decisions" in forthcoming versions and encourages > towards the hosted solution. > > > > Since we're in .nz, they'd put our hosted proxy server in .au, but the > network connection between .nz and .au is via the continental .us, which > puts an extra trans-pacific network loop in 99% of our proxied network > connections. > > > > cheers > > stuart > > > > On 30/01/14 03:14, Ingraham Dwyer, Andy wrote: > >> OCLC announced in April 2013 the changes in their license model for > North America. EZProxy's license moves from requiring a one-time purchase > of US$495 to a *annual* fee of $495, or through their hosted service, with > the fee depending on scale of service. The old one-time purchase license > is no longer offered for sale as of Jul
Re: [CODE4LIB] EZProxy changes / alternatives ?
Thank you Andrew, that is insanely useful. cheers stuart On 30/01/14 12:00, Andrew Anderson wrote: When OCLC first announced their purchase of EZproxy, we started a low priority research project to see what the alternatives were a few years ago, and what it would take to bring them into a production ready state. The two open source solutions we evaluated were Squid and Apache HTTPd. We considered other options (e.g. Apache Traffic Server), but limited the research to these two pieces of software since they are already widely used and familiar to most system administrators. Long story short, Squid did not support URL rewriting in a way that we felt would be able to be supported well, between requiring patches to the core C++ server code, or an external rewriting processes, or an ICAP server implementation. Some of that has improved a bit since the original evaluation, but the built-in support for URL rewriting may still need some time to mature. Another aspect of Squid that did not seem to be a good fit was that it is somewhat limited in its authentication mechanisms vs Apache HTTPd. So we moved on to evaluating Apache HTTPd with the mod_proxy family of modules. While Apache HTTPd does not support the advanced cache federation features as Squid, it has grown to be a robust proxy solution in its own right, and the 2.4 release appears to have all of the required pieces out of the box, with the mod_proxy_html module functionality. In addition to basic URL rewriting support, you get full HTTP protocol support, mature IPv6 support, GZIP support, just about any authentication mechanism you need, a server that you can self-host content with easily, as well as a built-in HTTP object cache. How would it work? Here’s the current EZproxy stanza for ProQuest: HTTPHeader X-Requested-With HTTPHeader Accept-Encoding Title ProQuest URL http://search.proquest.com/ip DJ proquest.com HJ gateway.proquest.com DJ umi.com HJ fedsearch.proquest.com HJ literature.proquest.com DJ conquest-leg-insight.com DJ conquestsystems.com DJ m.search.proquest.com DJ media.proquest.com NeverProxy order.proquest.com NeverProxy rss.proquest.com Here’s an Apache HTTPd configuration using ProQuest that accomplishes much of the same functionality for the main search.proquest.com interface: ServerName search.proquest.com.fqdn ProxyRequests Off ProxyVia On RewriteEngine On RewriteRule ^/(.*) http://search.proquest.com/$1 [P] AllowMethods GET POST OPTIONS ProxyPassReverse http://search.proquest.com/ ProxyPassReverseCookieDomain search.proquest.com search.proquest.com.fqdn CacheEnable disk SetOutputFilter INFLATE;DEFLATE Header Append Vary User-Agent env=!dont-vary # Put Authentication directives here ErrorDocument 401 /path/to/login Require Valid-User A few notes on this: - There is no need for NeverProxy: if you do not define a VirtualHost for the hostname, it is not proxied. So instead of HJ and DJ lines, you add a new VirtualHost block for each hostname that needs to be proxied. The astute will ask “what about services that have dozens or hundreds of host entries, like Sage?” Those can be handled by the ProxyExpress features in Apache HTTPd. - There is no need for HTTPHeader: since Apache HTTPd is a full HTTP proxy/server, it supports all HTTP headers natively. - Some of the hostnames that are in EZproxy stanzas are not needed, and some are legacy hostnames that are no longer used by the vendor - Some of the hostnames that are in EZproxy stanzas are for CDN hosted content that requires no special access (e.g. JavaScript/CSS/graphics assets that make up the vendor’s user interface). Another example: how many of you have “DJ google.com” in one of your stanzas? Now how many of you registered your IP addresses with Google in any way? Outside of Google Scholar, I suspect the answer to those questions are “nearly everyone” and “nearly no one”, respectively. - Some of the hostnames are for things that no sane person would do: How many people run their discovery services through their EZproxy server vs. authenticating their discovery platform by IP address with vendors directly? - Something that this configuration does that EZproxy does not do is enable object caching. This can easily save 30-50% of your upstream bandwidth usage (Proxy/ProxySSL in EZproxy can achieve the same result with an external caching proxy server). - More complex vendor platforms (e.g. Gale Cengage) need ProxyHTML directives and ProxyHTMLURLMap configured, and multiple VirtualHost sections to get them fully working. These can be a little fun to get working initially. - Some services need redirects edited to work correctly, and not break out of the proxy: Header edit Location http://vendor/ http://vendor.fqdn/ - Some vendors send wrong HTTP headers for the MIME type, and mod_proxy_html exposes this in some cases as it rewrites the page. There may be a bet
Re: [CODE4LIB] EZProxy changes / alternatives ?
SetOutputFilter INFLATE;dummy-html-to-plain ExtFilterOptions LogStdErr Onfail=remove ExtFilterDefine dummy-html-to-plain mode=output intype=text/html outtype=text/plain cmd=“/bin/cat -“ So what’s currently missing in the Apache HTTPd solution? - Services that use an authentication token (predominantly ebook vendors) need special support written. I have been entertaining using mod_lua for this to make this support relatively easy for someone who is not hard-core technical to maintain. - Services that are not IP authenticated, but use one of the Form-based authentication variants. I suspect that an approach that injects a script tag into the page pointing to javascript that handles the form fill/submission might be a sane approach here. This should also cleanly deal with the ASP.net abominations that use __PAGESTATE to store sessions client-side instead of server-side. - EZproxy’s built-in DNS server (enabled with the “DNS” directive) would need to be handled using a separate DNS server (there are several options to choose from). - In this setup, standard systems-level management and reporting tools would be used instead of the /admin interface in EZproxy - In this setup, the functionality of the EZproxy /menu URL would need to be handled externally. This may not be a real issue, as many academic sites already use LMS or portal systems instead of the EZproxy to direct students to resources, so this feature may not be as critical to replicate. - And of course, extensive testing. While the above ProQuest stanza works for the main ProQuest search interface, it won’t work for everyone, everywhere just yet. Bottom line: Yes, Apache HTTPd is a viable EZproxy alternative if you have a system administrator who knows their way around Apache HTTPd, and are willing to spend some time getting to know your vendor services intimately. All of this testing was done on Fedora 19 for the 2.4 version of HTTPd, which should be available in RHEL7/CentOS7 soon, so about the time that hard decisions are to be made regarding EZproxy vs something else, that something else may very well be Apache HTTPd with vendor-specific configuration files. -- Andrew Anderson, Director of Development, Library and Information Resources Network, Inc. http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes On Jan 29, 2014, at 14:42, Margo Duncan wrote: > Would you *have* to be hosted? We're in a rural part of the USA and network > connections from here to anywhere aren't great, so we try to host most > everything we can. EZProxy really is "EZ" to host yourself. > > Margo > > -Original Message- > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of > stuart yeates > Sent: Wednesday, January 29, 2014 1:40 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? > > The text I've seen talks about "[e]xpanded reporting capabilities to support > management decisions" in forthcoming versions and encourages towards the > hosted solution. > > Since we're in .nz, they'd put our hosted proxy server in .au, but the > network connection between .nz and .au is via the continental .us, which puts > an extra trans-pacific network loop in 99% of our proxied network connections. > > cheers > stuart > > On 30/01/14 03:14, Ingraham Dwyer, Andy wrote: >> OCLC announced in April 2013 the changes in their license model for North >> America. EZProxy's license moves from requiring a one-time purchase of >> US$495 to a *annual* fee of $495, or through their hosted service, with the >> fee depending on scale of service. The old one-time purchase license is no >> longer offered for sale as of July 1, 2013. I don't have any details about >> pricing for other parts of the world. >> >> An important thing to recognize here, is that they cannot legally change the >> terms of a license that is already in effect. The software you have >> purchased under the old license is still yours to use, indefinitely. OCLC >> has even released several maintenance updates during 2013 that are available >> to current license-holders. In fact, they released V5.7 in early January >> 2014, and made that available to all license-holders. However, all updates >> after that version are only available to holders of the yearly subscription. >> The hosted product is updated to the most current version automatically. >> >> My recommendation is: If your installation of EZProxy works, don't change >> it. Yet. Upgrade your installation to the last version available under the >> old license, and use that for as long as you can. At this poi
Re: [CODE4LIB] EZProxy changes / alternatives ?
The subscription fee for Australia and New Zealand is AU$600 (excluding GST) per year. They say: "Our 2014 releases will concentrate on IPV6 and reporting capabilities." I've just discovered that we're currently running 5.1c, which was released in 2009. So perhaps we'll be able to survive on 5.7 for a while? :-) David On 30 January 2014 03:14, Ingraham Dwyer, Andy wrote: > OCLC announced in April 2013 the changes in their license model for North > America. EZProxy's license moves from requiring a one-time purchase of > US$495 to a *annual* fee of $495, or through their hosted service, with the > fee depending on scale of service. The old one-time purchase license is no > longer offered for sale as of July 1, 2013. I don't have any details about > pricing for other parts of the world. > > An important thing to recognize here, is that they cannot legally change the > terms of a license that is already in effect. The software you have > purchased under the old license is still yours to use, indefinitely. OCLC > has even released several maintenance updates during 2013 that are available > to current license-holders. In fact, they released V5.7 in early January > 2014, and made that available to all license-holders. However, all updates > after that version are only available to holders of the yearly subscription. > The hosted product is updated to the most current version automatically. > > My recommendation is: If your installation of EZProxy works, don't change > it. Yet. Upgrade your installation to the last version available under the > old license, and use that for as long as you can. At this point, there are > no world-changing new features that have been added to the product. There is > speculation that IPv6 support will be the next big feature-add, but I haven't > heard anything official. Start planning and budgeting for a change, either > to the yearly fee, or the cost of hosted, or to some as-yet-undetermined > alternative. But I see no need to start paying now for updates you don't > need. > > -Andy > > > > Andy Ingraham Dwyer > Infrastructure Specialist > State Library of Ohio > 274 E. 1st Avenue > Columbus, OH 43201 > library.ohio.gov > > > -Original Message- > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of > stuart yeates > Sent: Tuesday, January 28, 2014 10:03 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? > > I probably should have been more specific. > > Does anyone have experience switching from EzProxy to anything else? > > Is anyone else aware of the coming OCLC changes and considering switching? > > Does anyone have a worked example like: "My EzProxy config for site Y looked > like A; after the switch, my X config for site Z looked like B"? > > I'm aware of this good article: > http://journal.code4lib.org/articles/7470 > > cheers > stuart > > > On 29/01/14 15:24, stuart yeates wrote: >> We've just received notification of forth-coming changes to EZProxy, >> which will require us to pay an arm and a leg for future versions to >> install locally and/or host with OCLC AU with a ~ 10,000km round trip. >> >> What are the alternatives? >> >> cheers >> stuart > > > -- > Stuart Yeates > Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
If you ask nicely they would likely place it where you want, I would ;) Sent from my iPhone > On Jan 29, 2014, at 3:36 PM, "Cary Gordon" wrote: > > EZProxy is not a very challenging service to setup or run. You could set it > up locally or pick one of the many cloud hosting providers in NZ, including > IBM. > > We manage an EZProxy server for a library cooperative in Northern California > on a small AWS instance. Its average load level is "bored". > > Cary > >> On Jan 29, 2014, at 11:39 AM, stuart yeates wrote: >> >> The text I've seen talks about "[e]xpanded reporting capabilities to support >> management decisions" in forthcoming versions and encourages towards the >> hosted solution. >> >> Since we're in .nz, they'd put our hosted proxy server in .au, but the >> network connection between .nz and .au is via the continental .us, which >> puts an extra trans-pacific network loop in 99% of our proxied network >> connections. >> >> cheers >> stuart >> >>> On 30/01/14 03:14, Ingraham Dwyer, Andy wrote: >>> OCLC announced in April 2013 the changes in their license model for North >>> America. EZProxy's license moves from requiring a one-time purchase of >>> US$495 to a *annual* fee of $495, or through their hosted service, with the >>> fee depending on scale of service. The old one-time purchase license is no >>> longer offered for sale as of July 1, 2013. I don't have any details about >>> pricing for other parts of the world. >>> >>> An important thing to recognize here, is that they cannot legally change >>> the terms of a license that is already in effect. The software you have >>> purchased under the old license is still yours to use, indefinitely. OCLC >>> has even released several maintenance updates during 2013 that are >>> available to current license-holders. In fact, they released V5.7 in early >>> January 2014, and made that available to all license-holders. However, all >>> updates after that version are only available to holders of the yearly >>> subscription. The hosted product is updated to the most current version >>> automatically. >>> >>> My recommendation is: If your installation of EZProxy works, don't change >>> it. Yet. Upgrade your installation to the last version available under >>> the old license, and use that for as long as you can. At this point, there >>> are no world-changing new features that have been added to the product. >>> There is speculation that IPv6 support will be the next big feature-add, >>> but I haven't heard anything official. Start planning and budgeting for a >>> change, either to the yearly fee, or the cost of hosted, or to some >>> as-yet-undetermined alternative. But I see no need to start paying now for >>> updates you don't need. >>> >>> -Andy >>> >>> >>> >>> Andy Ingraham Dwyer >>> Infrastructure Specialist >>> State Library of Ohio >>> 274 E. 1st Avenue >>> Columbus, OH 43201 >>> library.ohio.gov >>> >>> >>> -Original Message- >>> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of >>> stuart yeates >>> Sent: Tuesday, January 28, 2014 10:03 PM >>> To: CODE4LIB@LISTSERV.ND.EDU >>> Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? >>> >>> I probably should have been more specific. >>> >>> Does anyone have experience switching from EzProxy to anything else? >>> >>> Is anyone else aware of the coming OCLC changes and considering switching? >>> >>> Does anyone have a worked example like: "My EzProxy config for site Y >>> looked like A; after the switch, my X config for site Z looked like B"? >>> >>> I'm aware of this good article: >>> http://journal.code4lib.org/articles/7470 >>> >>> cheers >>> stuart >>> >>> >>>> On 29/01/14 15:24, stuart yeates wrote: >>>> We've just received notification of forth-coming changes to EZProxy, >>>> which will require us to pay an arm and a leg for future versions to >>>> install locally and/or host with OCLC AU with a ~ 10,000km round trip. >>>> >>>> What are the alternatives? >>>> >>>> cheers >>>> stuart >>> >>> >>> -- >>> Stuart Yeates >>> Library Technology Services http://www.victoria.ac.nz/library/ >> >> >> -- >> Stuart Yeates >> Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
EZProxy is not a very challenging service to setup or run. You could set it up locally or pick one of the many cloud hosting providers in NZ, including IBM. We manage an EZProxy server for a library cooperative in Northern California on a small AWS instance. Its average load level is "bored". Cary On Jan 29, 2014, at 11:39 AM, stuart yeates wrote: > The text I've seen talks about "[e]xpanded reporting capabilities to support > management decisions" in forthcoming versions and encourages towards the > hosted solution. > > Since we're in .nz, they'd put our hosted proxy server in .au, but the > network connection between .nz and .au is via the continental .us, which puts > an extra trans-pacific network loop in 99% of our proxied network connections. > > cheers > stuart > > On 30/01/14 03:14, Ingraham Dwyer, Andy wrote: >> OCLC announced in April 2013 the changes in their license model for North >> America. EZProxy's license moves from requiring a one-time purchase of >> US$495 to a *annual* fee of $495, or through their hosted service, with the >> fee depending on scale of service. The old one-time purchase license is no >> longer offered for sale as of July 1, 2013. I don't have any details about >> pricing for other parts of the world. >> >> An important thing to recognize here, is that they cannot legally change the >> terms of a license that is already in effect. The software you have >> purchased under the old license is still yours to use, indefinitely. OCLC >> has even released several maintenance updates during 2013 that are available >> to current license-holders. In fact, they released V5.7 in early January >> 2014, and made that available to all license-holders. However, all updates >> after that version are only available to holders of the yearly subscription. >> The hosted product is updated to the most current version automatically. >> >> My recommendation is: If your installation of EZProxy works, don't change >> it. Yet. Upgrade your installation to the last version available under the >> old license, and use that for as long as you can. At this point, there are >> no world-changing new features that have been added to the product. There >> is speculation that IPv6 support will be the next big feature-add, but I >> haven't heard anything official. Start planning and budgeting for a change, >> either to the yearly fee, or the cost of hosted, or to some >> as-yet-undetermined alternative. But I see no need to start paying now for >> updates you don't need. >> >> -Andy >> >> >> >> Andy Ingraham Dwyer >> Infrastructure Specialist >> State Library of Ohio >> 274 E. 1st Avenue >> Columbus, OH 43201 >> library.ohio.gov >> >> >> -Original Message- >> From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of >> stuart yeates >> Sent: Tuesday, January 28, 2014 10:03 PM >> To: CODE4LIB@LISTSERV.ND.EDU >> Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? >> >> I probably should have been more specific. >> >> Does anyone have experience switching from EzProxy to anything else? >> >> Is anyone else aware of the coming OCLC changes and considering switching? >> >> Does anyone have a worked example like: "My EzProxy config for site Y looked >> like A; after the switch, my X config for site Z looked like B"? >> >> I'm aware of this good article: >> http://journal.code4lib.org/articles/7470 >> >> cheers >> stuart >> >> >> On 29/01/14 15:24, stuart yeates wrote: >>> We've just received notification of forth-coming changes to EZProxy, >>> which will require us to pay an arm and a leg for future versions to >>> install locally and/or host with OCLC AU with a ~ 10,000km round trip. >>> >>> What are the alternatives? >>> >>> cheers >>> stuart >> >> >> -- >> Stuart Yeates >> Library Technology Services http://www.victoria.ac.nz/library/ >> > > > -- > Stuart Yeates > Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
Would you *have* to be hosted? We're in a rural part of the USA and network connections from here to anywhere aren't great, so we try to host most everything we can. EZProxy really is "EZ" to host yourself. Margo -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of stuart yeates Sent: Wednesday, January 29, 2014 1:40 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? The text I've seen talks about "[e]xpanded reporting capabilities to support management decisions" in forthcoming versions and encourages towards the hosted solution. Since we're in .nz, they'd put our hosted proxy server in .au, but the network connection between .nz and .au is via the continental .us, which puts an extra trans-pacific network loop in 99% of our proxied network connections. cheers stuart On 30/01/14 03:14, Ingraham Dwyer, Andy wrote: > OCLC announced in April 2013 the changes in their license model for North > America. EZProxy's license moves from requiring a one-time purchase of > US$495 to a *annual* fee of $495, or through their hosted service, with the > fee depending on scale of service. The old one-time purchase license is no > longer offered for sale as of July 1, 2013. I don't have any details about > pricing for other parts of the world. > > An important thing to recognize here, is that they cannot legally change the > terms of a license that is already in effect. The software you have > purchased under the old license is still yours to use, indefinitely. OCLC > has even released several maintenance updates during 2013 that are available > to current license-holders. In fact, they released V5.7 in early January > 2014, and made that available to all license-holders. However, all updates > after that version are only available to holders of the yearly subscription. > The hosted product is updated to the most current version automatically. > > My recommendation is: If your installation of EZProxy works, don't change > it. Yet. Upgrade your installation to the last version available under the > old license, and use that for as long as you can. At this point, there are > no world-changing new features that have been added to the product. There is > speculation that IPv6 support will be the next big feature-add, but I haven't > heard anything official. Start planning and budgeting for a change, either > to the yearly fee, or the cost of hosted, or to some as-yet-undetermined > alternative. But I see no need to start paying now for updates you don't > need. > > -Andy > > > > Andy Ingraham Dwyer > Infrastructure Specialist > State Library of Ohio > 274 E. 1st Avenue > Columbus, OH 43201 > library.ohio.gov > > > -Original Message- > From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf > Of stuart yeates > Sent: Tuesday, January 28, 2014 10:03 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? > > I probably should have been more specific. > > Does anyone have experience switching from EzProxy to anything else? > > Is anyone else aware of the coming OCLC changes and considering switching? > > Does anyone have a worked example like: "My EzProxy config for site Y looked > like A; after the switch, my X config for site Z looked like B"? > > I'm aware of this good article: > http://journal.code4lib.org/articles/7470 > > cheers > stuart > > > On 29/01/14 15:24, stuart yeates wrote: >> We've just received notification of forth-coming changes to EZProxy, >> which will require us to pay an arm and a leg for future versions to >> install locally and/or host with OCLC AU with a ~ 10,000km round trip. >> >> What are the alternatives? >> >> cheers >> stuart > > > -- > Stuart Yeates > Library Technology Services http://www.victoria.ac.nz/library/ > -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
The text I've seen talks about "[e]xpanded reporting capabilities to support management decisions" in forthcoming versions and encourages towards the hosted solution. Since we're in .nz, they'd put our hosted proxy server in .au, but the network connection between .nz and .au is via the continental .us, which puts an extra trans-pacific network loop in 99% of our proxied network connections. cheers stuart On 30/01/14 03:14, Ingraham Dwyer, Andy wrote: OCLC announced in April 2013 the changes in their license model for North America. EZProxy's license moves from requiring a one-time purchase of US$495 to a *annual* fee of $495, or through their hosted service, with the fee depending on scale of service. The old one-time purchase license is no longer offered for sale as of July 1, 2013. I don't have any details about pricing for other parts of the world. An important thing to recognize here, is that they cannot legally change the terms of a license that is already in effect. The software you have purchased under the old license is still yours to use, indefinitely. OCLC has even released several maintenance updates during 2013 that are available to current license-holders. In fact, they released V5.7 in early January 2014, and made that available to all license-holders. However, all updates after that version are only available to holders of the yearly subscription. The hosted product is updated to the most current version automatically. My recommendation is: If your installation of EZProxy works, don't change it. Yet. Upgrade your installation to the last version available under the old license, and use that for as long as you can. At this point, there are no world-changing new features that have been added to the product. There is speculation that IPv6 support will be the next big feature-add, but I haven't heard anything official. Start planning and budgeting for a change, either to the yearly fee, or the cost of hosted, or to some as-yet-undetermined alternative. But I see no need to start paying now for updates you don't need. -Andy Andy Ingraham Dwyer Infrastructure Specialist State Library of Ohio 274 E. 1st Avenue Columbus, OH 43201 library.ohio.gov -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of stuart yeates Sent: Tuesday, January 28, 2014 10:03 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? I probably should have been more specific. Does anyone have experience switching from EzProxy to anything else? Is anyone else aware of the coming OCLC changes and considering switching? Does anyone have a worked example like: "My EzProxy config for site Y looked like A; after the switch, my X config for site Z looked like B"? I'm aware of this good article: http://journal.code4lib.org/articles/7470 cheers stuart On 29/01/14 15:24, stuart yeates wrote: We've just received notification of forth-coming changes to EZProxy, which will require us to pay an arm and a leg for future versions to install locally and/or host with OCLC AU with a ~ 10,000km round trip. What are the alternatives? cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/ -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
What about using some of the open source WSO2 products to mimic the same functionality as EZProxy? This sounds like a task that Enterprise Service Bus combined (ESB) with Identity Server (IS) could do. Most of their products are some version of an Apache project or other wrapped up in a common user interface. http://wso2.com/products/ They're free, so the price is right. Rick -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Riley Childs Sent: Tuesday, January 28, 2014 10:13 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? What about CAS, it has some proxy component...I think. Sent from my iPhone > On Jan 28, 2014, at 10:11 PM, "tmccanna" > wrote: > > Ditto to Andreas. > > > Sent from my Verizon Wireless 4G LTE Smartphone > > Original message From: Andreas > Orphanides Date:01/28/2014 9:29 PM > (GMT-05:00) To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? > That's simple for the techs, but VPNs can be a royal pain > in the keester if you're an end-user, for a variety of reasons. It should be > incumbent on us as information specialists to unburden the user to the extent > possible. > > > On Tue, Jan 28, 2014 at 9:23 PM, Aaron Addison > wrote: > >> Some use Squid, its not hard to set up. But most vendors publish >> rules with ezproxy in mind. >> >> The other fairly simple solution is to run a VPN for access, and >> require people to use that. >> >> Aaron >> >> >> On Tuesday, January 28, 2014, stuart yeates >> wrote: >> >>> We've just received notification of forth-coming changes to EZProxy, >> which >>> will require us to pay an arm and a leg for future versions to >>> install locally and/or host with OCLC AU with a ~ 10,000km round trip. >>> >>> What are the alternatives? >>> >>> cheers >>> stuart >>> -- >>> Stuart Yeates >>> Library Technology Services http://www.victoria.ac.nz/library/ >>
Re: [CODE4LIB] EZProxy changes / alternatives ?
OCLC announced in April 2013 the changes in their license model for North America. EZProxy's license moves from requiring a one-time purchase of US$495 to a *annual* fee of $495, or through their hosted service, with the fee depending on scale of service. The old one-time purchase license is no longer offered for sale as of July 1, 2013. I don't have any details about pricing for other parts of the world. An important thing to recognize here, is that they cannot legally change the terms of a license that is already in effect. The software you have purchased under the old license is still yours to use, indefinitely. OCLC has even released several maintenance updates during 2013 that are available to current license-holders. In fact, they released V5.7 in early January 2014, and made that available to all license-holders. However, all updates after that version are only available to holders of the yearly subscription. The hosted product is updated to the most current version automatically. My recommendation is: If your installation of EZProxy works, don't change it. Yet. Upgrade your installation to the last version available under the old license, and use that for as long as you can. At this point, there are no world-changing new features that have been added to the product. There is speculation that IPv6 support will be the next big feature-add, but I haven't heard anything official. Start planning and budgeting for a change, either to the yearly fee, or the cost of hosted, or to some as-yet-undetermined alternative. But I see no need to start paying now for updates you don't need. -Andy Andy Ingraham Dwyer Infrastructure Specialist State Library of Ohio 274 E. 1st Avenue Columbus, OH 43201 library.ohio.gov -Original Message- From: Code for Libraries [mailto:CODE4LIB@LISTSERV.ND.EDU] On Behalf Of stuart yeates Sent: Tuesday, January 28, 2014 10:03 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? I probably should have been more specific. Does anyone have experience switching from EzProxy to anything else? Is anyone else aware of the coming OCLC changes and considering switching? Does anyone have a worked example like: "My EzProxy config for site Y looked like A; after the switch, my X config for site Z looked like B"? I'm aware of this good article: http://journal.code4lib.org/articles/7470 cheers stuart On 29/01/14 15:24, stuart yeates wrote: > We've just received notification of forth-coming changes to EZProxy, > which will require us to pay an arm and a leg for future versions to > install locally and/or host with OCLC AU with a ~ 10,000km round trip. > > What are the alternatives? > > cheers > stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
What about CAS, it has some proxy component...I think. Sent from my iPhone > On Jan 28, 2014, at 10:11 PM, "tmccanna" > wrote: > > Ditto to Andreas. > > > Sent from my Verizon Wireless 4G LTE Smartphone > > Original message From: Andreas Orphanides > Date:01/28/2014 9:29 PM (GMT-05:00) > To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] > EZProxy changes / alternatives ? > That's simple for the techs, but VPNs can be a royal pain in the > keester if > you're an end-user, for a variety of reasons. It should be incumbent on us > as information specialists to unburden the user to the extent possible. > > > On Tue, Jan 28, 2014 at 9:23 PM, Aaron Addison > wrote: > >> Some use Squid, its not hard to set up. But most vendors publish rules >> with ezproxy in mind. >> >> The other fairly simple solution is to run a VPN for access, and require >> people to use that. >> >> Aaron >> >> >> On Tuesday, January 28, 2014, stuart yeates >> wrote: >> >>> We've just received notification of forth-coming changes to EZProxy, >> which >>> will require us to pay an arm and a leg for future versions to install >>> locally and/or host with OCLC AU with a ~ 10,000km round trip. >>> >>> What are the alternatives? >>> >>> cheers >>> stuart >>> -- >>> Stuart Yeates >>> Library Technology Services http://www.victoria.ac.nz/library/ >>
Re: [CODE4LIB] EZProxy changes / alternatives ?
Ditto to Andreas. Sent from my Verizon Wireless 4G LTE Smartphone Original message From: Andreas Orphanides Date:01/28/2014 9:29 PM (GMT-05:00) To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] EZProxy changes / alternatives ? That's simple for the techs, but VPNs can be a royal pain in the keester if you're an end-user, for a variety of reasons. It should be incumbent on us as information specialists to unburden the user to the extent possible. On Tue, Jan 28, 2014 at 9:23 PM, Aaron Addison wrote: > Some use Squid, its not hard to set up. But most vendors publish rules > with ezproxy in mind. > > The other fairly simple solution is to run a VPN for access, and require > people to use that. > > Aaron > > > On Tuesday, January 28, 2014, stuart yeates > wrote: > > > We've just received notification of forth-coming changes to EZProxy, > which > > will require us to pay an arm and a leg for future versions to install > > locally and/or host with OCLC AU with a ~ 10,000km round trip. > > > > What are the alternatives? > > > > cheers > > stuart > > -- > > Stuart Yeates > > Library Technology Services http://www.victoria.ac.nz/library/ > > >
Re: [CODE4LIB] EZProxy changes / alternatives ?
Someone actually has a empty repo on GitHub called "freeproxy" but that might take a while... Sent from my iPhone > On Jan 28, 2014, at 9:52 PM, "Ross Singer" wrote: > > I hate to say it, but Squid will not be simple to get the kind of results > EZProxy gets. Shibboleth can take care of a handful (of probably some of > your larger, more commonly accessed?) resources. Maybe Squid can take care > of the rest, but my guess is it's the smaller, more niche resources that are > the most problematic. > > Stuart, can you go into some more detail regarding OCLC's changes? Is it > just a massive price hike? Are they egregious terms of service? > > Once upon a time (pre-OCLC), EZProxy was a one-time fee, is that not the case > anymore? I mean, can you not just keep running the version you're currently > on? > > -Ross. > >> On Jan 28, 2014, at 9:43 PM, Riley Childs wrote: >> >> My solution came from Google, but it was people setting up the solution, >> from what I can tell EZProxy had the market cornered, but Squid should be >> simple enough to setup, and with the coming changes more people in your boat >> will be able to solutionize! >> >> Sent from my iPhone >> >>> On Jan 28, 2014, at 9:40 PM, "stuart yeates" >>> wrote: >>> >>> I probably should have been more specific. >>> >>> Does anyone have experience switching from EzProxy to anything else? >>> >>> Is anyone else aware of the coming OCLC changes and considering switching? >>> >>> Does anyone have a worked example like: "My EzProxy config for site Y >>> looked like A; after the switch, my X config for site Z looked like B"? >>> >>> I'm aware of this good article: >>> http://journal.code4lib.org/articles/7470 >>> >>> cheers >>> stuart >>> >>> On 29/01/14 15:24, stuart yeates wrote: We've just received notification of forth-coming changes to EZProxy, which will require us to pay an arm and a leg for future versions to install locally and/or host with OCLC AU with a ~ 10,000km round trip. What are the alternatives? cheers stuart >>> >>> >>> -- >>> Stuart Yeates >>> Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
I hate to say it, but Squid will not be simple to get the kind of results EZProxy gets. Shibboleth can take care of a handful (of probably some of your larger, more commonly accessed?) resources. Maybe Squid can take care of the rest, but my guess is it's the smaller, more niche resources that are the most problematic. Stuart, can you go into some more detail regarding OCLC's changes? Is it just a massive price hike? Are they egregious terms of service? Once upon a time (pre-OCLC), EZProxy was a one-time fee, is that not the case anymore? I mean, can you not just keep running the version you're currently on? -Ross. On Jan 28, 2014, at 9:43 PM, Riley Childs wrote: > My solution came from Google, but it was people setting up the solution, from > what I can tell EZProxy had the market cornered, but Squid should be simple > enough to setup, and with the coming changes more people in your boat will be > able to solutionize! > > Sent from my iPhone > >> On Jan 28, 2014, at 9:40 PM, "stuart yeates" wrote: >> >> I probably should have been more specific. >> >> Does anyone have experience switching from EzProxy to anything else? >> >> Is anyone else aware of the coming OCLC changes and considering switching? >> >> Does anyone have a worked example like: "My EzProxy config for site Y >> looked like A; after the switch, my X config for site Z looked like B"? >> >> I'm aware of this good article: >> http://journal.code4lib.org/articles/7470 >> >> cheers >> stuart >> >> >>> On 29/01/14 15:24, stuart yeates wrote: >>> We've just received notification of forth-coming changes to EZProxy, >>> which will require us to pay an arm and a leg for future versions to >>> install locally and/or host with OCLC AU with a ~ 10,000km round trip. >>> >>> What are the alternatives? >>> >>> cheers >>> stuart >> >> >> -- >> Stuart Yeates >> Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
My solution came from Google, but it was people setting up the solution, from what I can tell EZProxy had the market cornered, but Squid should be simple enough to setup, and with the coming changes more people in your boat will be able to solutionize! Sent from my iPhone > On Jan 28, 2014, at 9:40 PM, "stuart yeates" wrote: > > I probably should have been more specific. > > Does anyone have experience switching from EzProxy to anything else? > > Is anyone else aware of the coming OCLC changes and considering switching? > > Does anyone have a worked example like: "My EzProxy config for site Y > looked like A; after the switch, my X config for site Z looked like B"? > > I'm aware of this good article: > http://journal.code4lib.org/articles/7470 > > cheers > stuart > > >> On 29/01/14 15:24, stuart yeates wrote: >> We've just received notification of forth-coming changes to EZProxy, >> which will require us to pay an arm and a leg for future versions to >> install locally and/or host with OCLC AU with a ~ 10,000km round trip. >> >> What are the alternatives? >> >> cheers >> stuart > > > -- > Stuart Yeates > Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
I probably should have been more specific. Does anyone have experience switching from EzProxy to anything else? Is anyone else aware of the coming OCLC changes and considering switching? Does anyone have a worked example like: "My EzProxy config for site Y looked like A; after the switch, my X config for site Z looked like B"? I'm aware of this good article: http://journal.code4lib.org/articles/7470 cheers stuart On 29/01/14 15:24, stuart yeates wrote: We've just received notification of forth-coming changes to EZProxy, which will require us to pay an arm and a leg for future versions to install locally and/or host with OCLC AU with a ~ 10,000km round trip. What are the alternatives? cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
A VPN could be a stopgap while you figure something else out, but yes I agree they are a pain for patrons. Plus from a security standpoint I wouldn't want patrons VPNing into my network, too many holes. Sent from my iPhone > On Jan 28, 2014, at 9:26 PM, "Andreas Orphanides" wrote: > > That's simple for the techs, but VPNs can be a royal pain in the keester if > you're an end-user, for a variety of reasons. It should be incumbent on us > as information specialists to unburden the user to the extent possible. > > > On Tue, Jan 28, 2014 at 9:23 PM, Aaron Addison > wrote: > >> Some use Squid, its not hard to set up. But most vendors publish rules >> with ezproxy in mind. >> >> The other fairly simple solution is to run a VPN for access, and require >> people to use that. >> >> Aaron >> >> >> On Tuesday, January 28, 2014, stuart yeates >> wrote: >> >>> We've just received notification of forth-coming changes to EZProxy, >> which >>> will require us to pay an arm and a leg for future versions to install >>> locally and/or host with OCLC AU with a ~ 10,000km round trip. >>> >>> What are the alternatives? >>> >>> cheers >>> stuart >>> -- >>> Stuart Yeates >>> Library Technology Services http://www.victoria.ac.nz/library/ >>
Re: [CODE4LIB] EZProxy changes / alternatives ?
That's simple for the techs, but VPNs can be a royal pain in the keester if you're an end-user, for a variety of reasons. It should be incumbent on us as information specialists to unburden the user to the extent possible. On Tue, Jan 28, 2014 at 9:23 PM, Aaron Addison wrote: > Some use Squid, its not hard to set up. But most vendors publish rules > with ezproxy in mind. > > The other fairly simple solution is to run a VPN for access, and require > people to use that. > > Aaron > > > On Tuesday, January 28, 2014, stuart yeates > wrote: > > > We've just received notification of forth-coming changes to EZProxy, > which > > will require us to pay an arm and a leg for future versions to install > > locally and/or host with OCLC AU with a ~ 10,000km round trip. > > > > What are the alternatives? > > > > cheers > > stuart > > -- > > Stuart Yeates > > Library Technology Services http://www.victoria.ac.nz/library/ > > >
Re: [CODE4LIB] EZProxy changes / alternatives ?
Some use Squid, its not hard to set up. But most vendors publish rules with ezproxy in mind. The other fairly simple solution is to run a VPN for access, and require people to use that. Aaron On Tuesday, January 28, 2014, stuart yeates wrote: > We've just received notification of forth-coming changes to EZProxy, which > will require us to pay an arm and a leg for future versions to install > locally and/or host with OCLC AU with a ~ 10,000km round trip. > > What are the alternatives? > > cheers > stuart > -- > Stuart Yeates > Library Technology Services http://www.victoria.ac.nz/library/ >
Re: [CODE4LIB] EZProxy changes / alternatives ?
Did a little research I think Squid would work, not as a drop in replacement. Same with apache (there is a proxy redirect directive...I don't recall it). I haven't tried either solution, but they seem to have the same concept, albeit with a little more configuration! Good Luck //Riley Sent from my iPhone > On Jan 28, 2014, at 9:04 PM, "stuart yeates" wrote: > > We've just received notification of forth-coming changes to EZProxy, > which will require us to pay an arm and a leg for future versions to > install locally and/or host with OCLC AU with a ~ 10,000km round trip. > > What are the alternatives? > > cheers > stuart > -- > Stuart Yeates > Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
EZProxy is a proxy for use with vendors that have products gateway'd by IP address. It allows users who are off-campus to access resources that are locked down by IP address as though the user was on campus. It does deep-packet inspection to write URLs and javascript, facing DNS stuff, etc. It's a product from OCLC, see http://www.oclc.org/en-US/ezproxy.html cheers stuart On 29/01/14 15:05, Riley Childs wrote: Ok, what exactly is EZProxy, I could never figure that out, if I knew I could help :) Sent from my iPhone On Jan 28, 2014, at 9:04 PM, "stuart yeates" wrote: We've just received notification of forth-coming changes to EZProxy, which will require us to pay an arm and a leg for future versions to install locally and/or host with OCLC AU with a ~ 10,000km round trip. What are the alternatives? cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/ -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
Re: [CODE4LIB] EZProxy changes / alternatives ?
Ok, what exactly is EZProxy, I could never figure that out, if I knew I could help :) Sent from my iPhone > On Jan 28, 2014, at 9:04 PM, "stuart yeates" wrote: > > We've just received notification of forth-coming changes to EZProxy, > which will require us to pay an arm and a leg for future versions to > install locally and/or host with OCLC AU with a ~ 10,000km round trip. > > What are the alternatives? > > cheers > stuart > -- > Stuart Yeates > Library Technology Services http://www.victoria.ac.nz/library/
[CODE4LIB] EZProxy changes / alternatives ?
We've just received notification of forth-coming changes to EZProxy, which will require us to pay an arm and a leg for future versions to install locally and/or host with OCLC AU with a ~ 10,000km round trip. What are the alternatives? cheers stuart -- Stuart Yeates Library Technology Services http://www.victoria.ac.nz/library/
