Re: [Catalyst] Where best to store database connection information?
Adam Witney wrote: I guess my question was more about any security issue of having the database username/password stored in a text file. And what do people consider best practice for this from a security point of view? One mechanism that may help is to move the DB connection data out - a way to do this is https://metacpan.org/pod/DBIx::Class::Schema::Config Which moves the problem around... I tend to have dev info with configs referring to sqlite - no passwords. Deployed versions have configs built up from templates in ansible, credentials either gitcrypt-ed or ansible vaulted. Nigel. -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catakyst::Runtime 5.90018 install issues
Seven Reeds wrote: I am running RedHat Enterprise 5.8, perl v5.8.8 Presumably system perl. I tried installing the runtime and devel modules from CPAN but they failed the tests. I am only focusing on the runtime tests at this time though. I haven't tried getting this to work on RHEL 5 perl for a couple of years. Back then it could be done, but needed work - a couple of sets of tests needed to be ignored (I didn't spend a lot of time working out why). Now I don't bother. Perlbrew, perl 5.16.x and current CPAN is one hell of a lot easier, and more stable when RHEL issue a perl bugfix. Same apples to RHEL 6 - perl 5.10 is not exactly modern either. Nigel. -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Deploying with Perlbrew
Todd Lyons wrote: Do you package new or updated modules as separate RPMs or do you just rebuild the whole RPM? Its one big rpm at present. I can see that there could be a use case for having large subsystems in their own rpm, but currently rebuilding everything works for me. Nigel. -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Deploying with Perlbrew
Personally I now build a perl rpm package (based around perlbrew, parallel installs with the system perl - based in /opt/perl) which includes everything within Task::Work (a task module I maintain) and builds against a mini cpan snapshot which is occasionally updated as I see fit. Build takes less than 2 hours, and works on 2 OS releases (Centos 5 + 6) under 2 architectures. However I don't have a lot of skewed application sets to work with so working to one blessed perl package is OK for me... Nigel. -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Controller: find_meta not found
On 15 Feb 2012, at 00:12, Seth Daniel wrote: Array found where operator expected at /opt/perl/5.10/lib/site_perl/5.10.1/Catalyst/Controller.pm line 215, at end of line (Missing operator before ?) Undefined subroutine Catalyst::Controller::find_meta called at /opt/perl/5.10/lib/site_perl/5.10.1/Catalyst/Controller.pm line 199. Compilation failed in require at /opt/perl/5.10/lib/site_perl/5.10.1/Module/Runtime.pm line 317. at /opt/perl/5.10/lib/site_perl/5.10.1/Catalyst/Script/Server.pm line 239 I'm seeing examples of this coming up from CPAN testers reports for one of my modules. The vast majority of results are passes, but a few get this failure or one of a couple of similarish ones (fails so far are listed below). Fails are over a variety of perl versions across BSD and Solaris platforms. I'm aiming to spend a bit of time chasing this in the next couple of days, although hints would be very welcome... [and I must at this point say a huge thanks to the CPAN testers guys] Nigel. Catalyst-Authentication-Credential-RemoteHTTP-0.04: - x86_64-linux-ld / 5.14.2: - FAIL http://www.cpantesters.org/cpan/report/0bb31504-5176-11e1-9519-d24f9aeef8c6 - x86_64-linux-thread-multi-ld / 5.14.2: - FAIL http://www.cpantesters.org/cpan/report/0cc8b138-5176-11e1-9519-d24f9aeef8c6 Catalyst-Authentication-Credential-RemoteHTTP-0.05: - OpenBSD.amd64-openbsd / 5.8.9: - FAIL http://www.cpantesters.org/cpan/report/248b678c-56aa-11e1-9d6f-f6dbfa7543f5 - amd64-freebsd / 5.8.9: - FAIL http://www.cpantesters.org/cpan/report/25e0218a-5647-11e1-9d6f-f6dbfa7543f5 - amd64-freebsd-thread-multi / 5.8.9: - FAIL http://www.cpantesters.org/cpan/report/c1e01ec6-5662-11e1-9d6f-f6dbfa7543f5 - i86pc-solaris / 5.10.1: - FAIL http://www.cpantesters.org/cpan/report/3b4f6918-56a6-11e1-9d6f-f6dbfa7543f5 - i86pc-solaris / 5.8.9: - FAIL http://www.cpantesters.org/cpan/report/db3f32fc-562c-11e1-9d6f-f6dbfa7543f5 - i86pc-solaris-64int / 5.8.9: - FAIL http://www.cpantesters.org/cpan/report/391b099c-5659-11e1-9d6f-f6dbfa7543f5 - i86pc-solaris-thread-multi / 5.8.9: - FAIL http://www.cpantesters.org/cpan/report/29e700c4-564b-11e1-9d6f-f6dbfa7543f5 - OpenBSD.amd64-openbsd-thread-multi / 5.8.9: - FAIL http://www.cpantesters.org/cpan/report/dd58795e-56bd-11e1-9d6f-f6dbfa7543f5 - i86pc-solaris-64int / 5.10.1: - FAIL http://www.cpantesters.org/cpan/report/2e0c9c76-56d3-11e1-9d6f-f6dbfa7543f5 - i86pc-solaris-thread-multi / 5.10.1: - FAIL http://www.cpantesters.org/cpan/report/ac74c214-56c4-11e1-9d6f-f6dbfa7543f5 - i86pc-solaris-thread-multi-64int / 5.10.1: - FAIL http://www.cpantesters.org/cpan/report/1867ca94-56b5-11e1-9d6f-f6dbfa7543f5 -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] error while starting my dev enviroment
On 10 Jul 2011, at 19:14, Charlie Gonzalez wrote: Does this mean that when making a decision on an OS for Catalyst apps the best choice of a linux OS is CentOs or Redhat? If you are using the system perl then the worst choice of OS is probably Centos or Red Hat - Centos 6.0 is just about to be released and has perl 5.10 - which is outside the perl bug fix policy; and will remain so for its complete 7 year (or whatever) life. I now build a perlsupport rpm package which uses the magic of perlbrew to build a perl into /opt/perl along with all the modules I use to support perl applications. Nigel. -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [ANNOUNCE] Catalyst-Runtime-5.89002-TRIAL PSGI Catalyst - third development release
On 3 Mar 2011, at 18:28, Fernan Aguero wrote: Although it was not clear in any of the Plack/PSGI documentation that I've read, my guess is that only framework developers care about this. I, as a developer of web applications, shouldn't. Right? You should care in that it simplifies your choices - rather than needing to select an environment with a framework and web server that integrate, you now go for a PSGI supported webserver and can switch frameworks on top of that defined hand-off point. Should make it much easier if, say, you end up with multiple frameworks (ie when you are transitioning functionality from one to another). Nigel. -- [ Nigel Metheringham -- ni...@dotdot.it ] [ Ellipsis Intangible Technologies ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Help Deploying on mod-fcgi Rather than mod_fastcgi
I'd suggest deleting that /tmp/sumo entirely and letting it recreate. Its probably not really a good idea to have it in /tmp shareable by different uids either, but to try and get stuff running I'd just zilch it for now and then work on analysing how it should be done :-) Nigel. -- [ Nigel Metheringham nigel.methering...@intechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst 5.8: the Perl MVC Framework - Packt Publishing
On 1 Aug 2010, at 18:08, Roderick A. Anderson wrote: I'm always in the market for dead tree or captured electron media but I don't remember seeing any posts on the list by the author -- Antano Solar John. Got a copy on its way, so should be able to say something about it in a couple of weeks (which may not be helpful if you were offered a time-limited discount as an upgrade from the previous Packt book). Nigel. -- [ Nigel Metheringham nigel.methering...@intechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Contributing code
On 22 Jun 2010, at 18:26, Tomas Doran wrote: But I get exactly what you're saying about the clone URI - that would be entirely useful here.. Should just be a case of setting @git_base_url_list in the overall gitweb config file. Nigel. -- [ Nigel Metheringham nigel.methering...@intechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow Makefile.PL
On 23 Mar 2010, at 21:52, Wade Stuart wrote: The other option is to wait (up to 2 minutes) for RAM to write to disk and the sleep light to slow blink before moving your lappy; I am just too impatient. See also http://www.jinx.de/SmartSleep.html ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Change user password
On 1 Feb 2010, at 21:09, Bogdan Lucaciu wrote: Considering you just want to check the password and not reauthenticate the user, using check_password is less overhead, saves you a trip to the database, and it's probably cleaner. Otherwise I doubt there's any side-efect in calling $c-authenticate directly, and the performance overhead is probably not important, as you would probably need to run this code quite rarely. And it's probably more readable for people not knowing the Authentication internals Its worth pointing out that http://search.cpan.org/perldoc?Catalyst::Plugin::Authentication::Internals does not document the check_password method, and so those implementing credentials may not implement it. I'd go with $c-authenticate as it is a documented route into the API and should be handled by all credential modules. Nigel. -- [ Nigel Metheringham nigel.methering...@intechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Lighttpd and mod_perlite
On 31 May 2009, at 20:19, Kiffin Gish wrote: Just wondering what kind of experience folks in the catalyst community have had using lighttpd/mod_perlite as replacements for the more widely accepted apache/mod_perl stack. While apache might be better in being proven technology and mod_perl being better documented, I'm still looking for lightweight and scalable options. Not one of I had heard of up until now, and a quick google make it look a little bleeding edge for my taste. However, I, and many others, are using lighttpd with fastcgi with great success - there are a number of articles on this including a few advent calendar ones. Nigel. -- [ Nigel Metheringham nigel.methering...@intechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DBIx makes Catalyst startup painfully slow
On 10 Feb 2009, at 10:53, Neo [GC] wrote: Apart from Catalyst being really resource hungry, the startup time for the application (testserver oder fastcgi) is ok, about 4 seconds on my development-system (CentOS on VMware Fusion on MacOS X Leopard, Core 2 Duo 2.2GHz). It's not perfect for developing, but it is completely acceptable. What version of Centos? What perl are you using? But as soon as I activate my DBIx schemas, the startup time multiplies: 12 seconds with my first (and most important) schema, 25 seconds when using all schemas. Have a look at this document (from a dev DBIC release):- http://search.cpan.org/~ribasushi/DBIx-Class-0.08099_06/lib/DBIx/Class/Manual/Troubleshooting.pod#Perl_Performance_Issues_on_Red_Hat_Systems or http://tinyurl.com/cwb6tq (look at Performance section at bottom). Nigel. -- [ Nigel Metheringham nigel.methering...@intechnology.com ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] uri_for doesn't work
On 30 Oct 2008, at 10:23, carlo maisola wrote: where is my problem? im forgetting something? Is your context object definitely called c? Check in your TT view that you have CATALYST_VAR = 'c', inside the __PACKAGE__-config() hash Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
On 18 Aug 2008, at 22:00, James S. White wrote: My notes are here: http://github.com/fapestniegd/wcyd/tree/master/scratch/procedures/el5/installing_catalyst_on_el5 I really hope you aren't just pulling a list of rpms and then installing them. Thats why package handlers like yum were invented. There are a lot of them (~137), I am very surprised at this. I currently have 470 perl-*.rpm files in my repo (for Centos 4 - I haven't currently got production Centos 5 cat). The vast majority of these are catalyst/dbix-class and there dependancies, although there is also a rebuild of the perl packages themselves and the dual-life modules. Note that the perl on all versions of RHEL5 prior to 5.3 (which is not released yet) is not suitable for running DBIX::Class - see https://bugzilla.redhat.com/show_bug.cgi?id=379791 Anyhow I would strongly suggest you look at cpanrpm effort and join that campaign - see http://www.perlfoundation.org/perl5/index.cgi?cpanrpm http://lists.dave.org.uk/mailman/listinfo/cpanrpm Other comments... cpanflute/cpanflute2 are very old and produce rather rocky rpms. cpan2rpm is rather better but tends to miss dependancies. cpanspec is very good - see http://fedoraproject.org/wiki/Perl/cpanspec http://cpanspec.sourceforge.net/ Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: list of perl-*.rpm files for a basic Cat install
On 22 Aug 2008, at 14:44, James S. White wrote: [Regarding number of rpms needed for cat/DBIX] This was just what it took to get the base catalyst going. If your particular App needs other perl modules, that goes in a separate brick. Thinking about it, I always rebuild rpms in a clean environment (mach for the older stuff - Centos 4.x, mock for newer) which means my repo contains not just the rpms I put on a production box, but also the ones I need to make those build, test etc. A production server currently has 235 perl rpms on it. Anyhow I would strongly suggest you look at cpanrpm effort and join that campaign - see http://www.perlfoundation.org/perl5/index.cgi?cpanrpm http://lists.dave.org.uk/mailman/listinfo/cpanrpm Good information. I will certainly look into this. Is there an equivalent org for .debs? As I understand it the cpanrpm effort is aiming to build on similar work done for debs. I only have one debian box though (not at work) and that uses CPAN instead. Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Duplicate entries with C::P::Session::Store::DBIC and MySQL
On 29 Jul 2008, at 12:30, Tobias Kremer wrote: The short time window between the find() and create() calls of the find_or_create() method indeed is the problem. It sounds like this window should be too small to ever happen but in reality it happens very often in our (and other's) applications. I can force the problem by hammering reload in my browser. Run the find_or_create within a transaction. You could even extend find_or_create to package it within a transaction if you wanted. Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
On 11 Apr 2008, at 12:41, Paul Makepeace wrote: I'm curious, is there a compelling reason you're using one of the nine(!) RSS standards versus Atom? ... my $feed = XML::Feed-new('Atom'); Going somewhat off-topic, when I was trying this I found XML::Feed was producing Atom feeds that caused apoplexy to the feed validators I tried, so I changed to XML::Atom::SimpleFeed (which has other issues but was at least producing output that the checker was happy with). Are you generating valid Atom with XML::Feed or did I hold the wrong end of the chainsaw? Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Ubuntu / Catalyst
On 13 Nov 2007, at 11:16, Richard Jones wrote: Possibly a bit OT now, but as I'm about to set up another production server and was going to use CentOS 5, I'm a bit concerned. Matt mentioned fstab and init, but not as far as I can see Perl - in what way is Perl broken on CentOS 5? Some bodged backports make certain operations stupidly slow. For an example see the (Fedora) bug report 253728 https://bugzilla.redhat.com/show_bug.cgi?id=253728 As of a couple of weeks back this was definitely in RHEL5/Centos5. Bearing in mind the timing of the recent RHEL5.1 release (no Centos 5.1 as yet), I really expect that its in there too - and I am not convinced the RH guys have given pushing this fix out any priority at all... Nigel. -- [ Nigel Metheringham [EMAIL PROTECTED] ] [ - Comments in this message are my own and not ITO opinion/policy - ] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/