Re: [OPEN-ILS-DEV] Security team coordination
Hi all, I understand there is a project either being planned or under way to change or rehost our mailing lists, and I hear Chris Sharp of GPLS is working on this. Chris, if this is indeed under your auspices and underway, we should coordinate this soon. If, however, it will be a while before anything happens in this area, ESI would be happy to host the security list for the community -- we can set this up very quickly. Since it should be low membership and relatively low traffic, moving it later shouldn't be a problem. Just let me know (assuming we don't change the plan to something other than a moderated, private list -- see below). Yes, Mike, that's right - GPLS has created a dedicated list server for the Evergreen Community. The only obstacle to going live that I'm aware of is the need for a new IP block for the new list server and some other servers on which GPLS is currently hosting. I'm back today from two weeks off, so I'll make it a top priority to get a status report on where we are on this and report back to this and the General list as soon as I know something. Chris Sharp PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 csh...@georgialibraries.org http://pines.georgialibraries.org/ - Original Message - From: Mike Rylander mrylan...@gmail.com To: Evergreen Development Discussion List OPEN-ILS-DEV@list.georgialibraries.org Sent: Tuesday, December 21, 2010 1:32:36 PM Subject: [OPEN-ILS-DEV] Security team coordination Dan Scott recently set up an Evergreen Security Team on LaunchPad for the purpose of accepting, triaging, prioritizing and attacking security-related issues (vulnerabilities, etc) in Evergreen. However, beyond the membership -- all of whom will be alerted when a bug is tagged as a security issue (IIUC) -- there is no closed communication channel for the security team. This is important because we want to be able to address security issues before exploits are in the wild. So, to that end, I would like to propose the creation of an open-ils-security mailing list. This list would need to allow anyone to post, but would be moderated for non-members. Members would be the Evergreen Security Team. This poses some amount of overhead to security team members, but may be a necessary evil. I understand there is a project either being planned or under way to change or rehost our mailing lists, and I hear Chris Sharp of GPLS is working on this. Chris, if this is indeed under your auspices and underway, we should coordinate this soon. If, however, it will be a while before anything happens in this area, ESI would be happy to host the security list for the community -- we can set this up very quickly. Since it should be low membership and relatively low traffic, moving it later shouldn't be a problem. Just let me know (assuming we don't change the plan to something other than a moderated, private list -- see below). Ideas for alternate methods of communication amongst security team members are welcome, so if you can think of something that would work better for those that will be on the team and have less overhead, please reply here! -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: mi...@esilibrary.com | web: http://www.esilibrary.com
Re: [OPEN-ILS-DEV] Batch program dying on cstore timeouts
Quoting Mike Rylander mrylan...@gmail.com: There is, though it's not Java but Perl: http://svn.open-ils.org/trac/OpenSRF/browser/trunk/src/perl/lib/OpenSRF/MultiSession.pm John, I think you could fake something like this strictly in Java using a ThreadPoolExecutor in Java and wrapping your OpenSRF calls in Tasks/Futures. A Multisession OpenSRF Java module could probably be implemented in a similar way. Of course, that limits you to using JRE 1.5.0 or later. On a related note, we're running into a similar problem with the view holds shelf menu option. We get very similar cstore deaths on our test/demo servers. I'm going to modify the code to perhaps use Mutlisession for that to see if it fixes things for us, that is if it is still a problem after I do a reload this week. If it does, I'll send a patch. Jason
[OPEN-ILS-DEV] ***SPAM*** Appropriate updates to Java OpenSRF/Open-ILS API
Hi Folks, Last month, Dan Scott and I had some discussion on the IRC channel about our working with the less-used Java API and the fact that it needed some updating. In the course of our work, we've added the ability for it to handle some additional message/response types. As we might as well be sure we've done what we can to improve the API (in addition to needs we happened upon in the application we were working on), I have a few questions some of you folks who are more in the know might be able to answer: 1) What things come immediately to mind in terms of the API needing to support OpenSRF interactions/operations/functionality that are new since the Java API was originally created back when OpenSRF was at 0.9 (or whatever the exact version was)? 2) Given that the Java API was, iirc, intended to provide some quite specific capabilities (in support of early Acq efforts), was anything in particular left out? 3) The documentation mentions using the Python API as a reasonable model for a port to another language. I know there's been some recent work on the Python API; is it essentially functionally complete at this point? Thanks much! John
[OPEN-ILS-DEV] 2011 Evergreen International Conference - 2nd Call for Program Submissions - Deadline 1/14 5:00 p.m. EST
Happy New Year to all! The 2011 Evergreen International Conference planning team continues to accept presentation proposals for the conference. We have received fewer than 10 submissions so far but we are hopeful for more. If you have been waiting in the wings for your moment to shine, here it is! There are three programming tracks, and we hope to have a broad spectrum of programming within each track: 1) Front line - Best practices and techniques for using Evergreen in day-to-day library operations 2) Administration - programs targeted at managers and administrators seeking information about the feasibility, cost issues, and other topics related to using Evergreen and open source software in consortial and standalone environments 3) Technology - Issues of interest related to system administration, software development, implementation, hardware, and integration with other software Presentation sessions will be 55 minutes in length - multi-part presentations will be considered if your presentation requires more time. All presenters can expect a laptop with Web access and PowerPoint, a computer projector and a microphone. *Proposal guidelines:* 1) All submissions must include a session title, short description appropriate for the conference program (no more than 200 words), and the names, institutions, job titles and email addresses of those who will be presenting the material at the conference. 2) Note your intended track (Tech, Administration and Front Line Users) and presumed technical level of your audience. 3) Let us know of any accessibility requirements. Please submit your proposals at the following site: http://www.surveymonkey.com/s/7R7MSMF before 5:00 p.m. EST on January 14, 2011. The third annual Evergreen International Conference will be held at the Decatur Holiday Inn and Conference Center in Decatur, Georgia on April 27 - 30, 2011. Details about the conference may be found at the conference website: http://pines.georgialibraries.org/evergreen2011 We continue to look forward to your submissions! Chris Sharp PINES Program Manager Georgia Public Library Service 1800 Century Place, Suite 150 Atlanta, Georgia 30345 (404) 235-7147 csh...@georgialibraries.org http://pines.georgialibraries.org/
Re: [OPEN-ILS-DEV] ***SPAM*** Appropriate updates to Java OpenSRF/Open-ILS API
Hi John, On Tue, Jan 4, 2011 at 10:10 AM, John Craig jc-mailingl...@alphagconsulting.com wrote: Hi Folks, Last month, Dan Scott and I had some discussion on the IRC channel about our working with the less-used Java API and the fact that it needed some updating. In the course of our work, we've added the ability for it to handle some additional message/response types. As we might as well be sure we've done what we can to improve the API (in addition to needs we happened upon in the application we were working on), I have a few questions some of you folks who are more in the know might be able to answer: 1) What things come immediately to mind in terms of the API needing to support OpenSRF interactions/operations/functionality that are new since the Java API was originally created back when OpenSRF was at 0.9 (or whatever the exact version was)? 2) Given that the Java API was, iirc, intended to provide some quite specific capabilities (in support of early Acq efforts), was anything in particular left out? The Java client was designed to be a full-featured OpenSRF client and, at the time, from what I recall (It's been a few years since I last used it), it behaved much like any OpenSRF client. I glanced at the code today to refresh my memory and was pleasantly surprised to see that, at first glance, it appears to be generally consistent and up to date with the rest of OpenSRF (i.e. version 0.9). I'm positive there are bugs and almost certainly some missing pieces, but repairing them should not require large architectural changes to the code. The Java Evergreen libraries are more likely to be out of date, since there has been more shift on the EG side than OpenSRF in the last couple of years. One issue that comes to mind is the loss of array_position for IDL fields. open_ils.idl.* will need some attention to resolve that. 3) The documentation mentions using the Python API as a reasonable model for a port to another language. I know there's been some recent work on the Python API; is it essentially functionally complete at this point? From the perspective of an OpenSRF client, the Python code is as functionally complete as the C code, possibly more so in some respects. It's just not battle-hardened, so it probably has some bugs and/or areas that need better fault tolerance. I think it would make a suitable reference implementation, though. It's the most recent implementation (so it's very much to-the-point), the code is relatively clean, and Python is easy to read. Also, the IDL code in the Python Evergreen modules is up to date... Good luck. I hope this helps. -b -- Bill Erickson | VP, Software Development Integration | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 877-OPEN-ILS (673-6457) | email: erick...@esilibrary.com | web: http://esilibrary.com
