Re: [Koha] Enabling SSL for Koha staff view
On Sat, May 14, 2011 at 7:06 AM, MJ Ray m...@phonecoop.coop wrote: Mizst Audens wrote: Your server returned a 400 Bad Request for the http on port 443. :-) Yes, it detected the http and served you html, did you notice? :-) Only an error message, but as I wrote: serving http seamlessly is probably a bad idea (easy to lose security by typo). Oh I thought that was a standard error message or something, since my server does the same thing without any configuration. And anyway I thought you were referring to serving a functioning page, not an error message. But glad to hear that SNI is going to come standard now, at least in some distro. I think that information pertaining to Koha deployment should be considered relevant to the list, and in my opinion that includes some nuances of all the facilities that Koha requires for its operations and for the needs of the library, in this case adding security for the staff interface. Sorry, but I feel the list needs a limit. Configuring Apache HTTPD isn't specific to Koha, there is plenty of help available on more mainstream sites and the Koha list seems pretty busy with Koha questions already, without adding the setup of Apache, MySQL and GNU/Linux to it. Also, there are other ways to secure the staff interface without dealing with this, such as a VPN. Yes, there needs to be some limit, but I think not having this in Koha list is counter productive. We at least need to be able to discuss the issues that Koha users can run into, or what kind of config is best when trying to run Koha, etc. Same thing with setting up mail for Koha and that sort of thing. All the posts stay in its own topic anyway. Sure, you can use VPN. And you can use SSL. So? Surely, anyone considering to add SSL to their Koha server is going to run into these issues. Surely not? I think most users run only one Koha. See TC's post. He was trying to add SSL to both OPAC and staff area. That makes it two virtualhosts, and he did run into a problem trying to get SSL to work. --Mizst Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Enabling SSL for Koha staff view
You must create another virtual host at another port (for example, 8081) for the staff area and enable SSL for that virtual host, and it will require another SSL certificate. Your staff will need to use (example) https://127.0.1.1:8081 if they want to use SSL, and http://127.0.1.1:8080 if they don't want to use SSL. Note that https://127.0.1.1 is in fact an alias for https://127.0.1.1:443. You already used 443 for the OPAC, so you'll need another port for the staff. --Mizst 2011/5/7 Altaf Mahmud altaf.mah...@gmail.com Hello, I'm trying to implement SSL in my Koha server running on Debian 6.0 (squeeze). I've implemented it for my OPAC view, I've created another file 'koha-ssl' in ../apache2/sites-available/ directory and enabled it. I've edited ../apache2/sites-available/koha like following: NameVirtualHost *:80 VirtualHost 127.0.1.1:80 . . /VirtualHost And ../apache2/sites-available/koha-ssl like following: NameVirtualHost *:443 VirtualHost 127.0.1.1:443 . SSLEngine On SSLCertificateFile/etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key . /VirtualHost Now https://127.0.1.1/ is showing the OPAC. But I can't figure it out how to implement it for staff-view VirtualHost 127.0.1.1:8080 Request for port 80 is redirecting to port 443, how can I do that for port 8080? In fact, I don't have any prior idea on doing this; a descriptive suggestion is appropriate for me. Thanks. -- Altaf Mahmud System Programmer Ayesha Abed Library BRAC University Bangladesh. ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] perl modue Graphics::Magick not found
The bug was already filed by Joe Atzberger in Jan 2011. The link is: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5599 In it, he proposes using Perl::Version to compare the version strings instead of the existing custom way. However, there is no working code yet. --Mizst http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5599 On Sat, Apr 30, 2011 at 3:10 AM, Chris Nighswonger cnighswon...@foundations.edu wrote: 2011/4/29 Mizst Audens mizs...@gmail.com For Ubuntu, 1.3.12 is actually the newer version found in 10.10 and is stable. 1.3.5 is an older version from 9.10. The dependency checker tool in Koha simply parses the version number incorrectly so it believes that you have a lower version. Thanks for pointing out this bug. Please open a formal bug at bugs.koha-community.org. Kind Regards, Chris ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha doesn't generate check-out and check-in notices
To my knowledge, Koha does not work with ssmtp or any non-daemon MTAs (such as nullmailer). Koha uses Perl's SMTP routines which tries to connect to TCP 25 of localhost looking for a SMTP server. However, ssmtp only runs as sendmail bin and does not listen for such a connection. Try postfix instead. --Mizst 2011/4/27 glernil evangelista infotech@gmail.com Good day! I'm configuring koha to send notices to patrons through their email address. I used ssmtp as my MTA and gmail as my mail server. Sending of email through command line is quite successful. I had process_message_queue in my crontab set to send messages every minute. I made it sure that messaging preferences for each category is configured to send check-out and check-in notices. And of course, I created check-out and check-in notices. Eventually, I tried to check-out an item for a patron but when I check the notices tab in the OPAC there is no generated check-out notice. I can't figure out what is the problem here. Please help.. -- Luceat Lux Vestra Let Your Light Shine! Straordinario Nelle Cose Ordinarie Making ordinary things extraordinary ... Glernil Evangelista Library Staff - College Library St. Bridget College - Batangas Philippines, 4200 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Undefined subroutine
You might need to add this at the beginning of Sendmail.pm:
use http://perldoc.perl.org/functions/use.html Encode;
Not entirely sure though.
--Mizst
2011/4/29 Cybermon cyber...@gmail.com
Dear All,
When I update patron information by UTF-8 by ,,,/koha/opac-userupdate.pl ?
I have following error:
Undefined subroutine Mail::Sendmail::encode called at
/usr/share/perl5/Mail/Sendmail.pm line 308.
I just added following script for /usr/share/perl5/Mail/sendmail.pm
$mail{'Message'} = encode_qp(encode(UTF-8, $mail{'Message'}));
How can I fix it ?
Gana
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list http://koha-community.org
Koha@lists.katipo.co.nz
http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] memc missing
I don't know about Debian, but I've had more than my fair share of problems with packages from Ubuntu repo, and usually a compile from upstream source fixes the problems. I remember a case with php5-gd where Debian refuses to update their repo to the new version, causing widespread problems for any php app relying on image scaling. For a while, the only way to fix it was to compile from upstream source. So you see where I'm coming from. But besides that, an immediately visible benefit is that you don't have to go hunt for package names in repos if you use cpan. You can just grab the name that's given by the dependency checker. --Mizst On Sat, Apr 30, 2011 at 6:03 AM, Chris Cormack ch...@bigballofwax.co.nzwrote: 2011/4/30 Mizst Audens mizs...@gmail.com: Sorry for misunderstanding. Normally you get perl modules from CPAN like this: $ cpan CGI::Session::Driver::memcached That's usually a safer bet than relying on distro repository. Normally you'd fall back to the repo when there's a conflict of some sort, or it fail to compile. I thought you tried cpan without the -ached part so it could not be found at first. I disagree, I would thoroughly recommend that if you are using Debian you should always use the packaged version first, and only use CPAN if it isn't packaged. That way you get the added security of the debian security team looking at your bugs, system upgrades don't break your locally installed modules, and a myriad of other reasons. Having said that, for this one, you can either grab the package from sid (unstable) and dpkg -i it on, or use dh-make-perl or as a last resort CPAN it on. It obviously missed the cut for squeeze. Chris ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] memc missing
I'd say it's relevant for Koha deployers, but I'll email you. :-) --Mizst On Sat, Apr 30, 2011 at 6:52 AM, Chris Cormack ch...@bigballofwax.co.nzwrote: On 30 April 2011 11:47, Mizst Audens mizs...@gmail.com wrote: I don't know about Debian, but I've had more than my fair share of problems with packages from Ubuntu repo, and usually a compile from upstream source fixes the problems. I remember a case with php5-gd where Debian refuses to update their repo to the new version, causing widespread problems for any php app relying on image scaling. For a while, the only way to fix it was to compile from upstream source. So you see where I'm coming from. But besides that, an immediately visible benefit is that you don't have to go hunt for package names in repos if you use cpan. You can just grab the name that's given by the dependency checker. --Mizst Way off topic for the koha list now, so if you want to continue discussing why you think using packages is worse than compiling from source, feel free to email me off list. (I do have counterpoints for everything you just mentioned :)) Chris ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
