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] Re: list of perl-*.rpm files for a basic Cat install
I really hope you aren't just pulling a list of rpms and then installing them. Thats why package handlers like yum were invented. I'm not. I'm moving them into the yum repos for the servers that get catalyst deployed on them. This HOWTO is just how I determine what goes into a given repo. Cfengine actually does the installation, removal, and configuration of the services. This basically defines what we call a brick. 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. 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. The philosophy to which we try to adhere is set-theory, sets of files define packages, sets of packages define bricks, sets of these bricks make applications, sets of applications define a system (not to be confused, but often is with a host system), sets of systems define business functions, and sets of business functions serve customers/consumers. Now we can use this clearly defined, OO approach to system building to allow project managers (who often aren't technical) to work with business analysts (who often forget that the devil is in the details) to create new business functions at a high level, while the developers and sysadmins create packages, bricks and systems to serve the needs that aren't already met by existing components. Having a service catalog that can be re-ordered at a high-level (not unlike lego(tm) bricks) helps keep the business-function project managers out of the developers business. They only need know when a particular (higher-level) component is ready. This also nudges the architects to re-use existing work when possible rather than go off in an entirely different direction. It also eliminates the fear around change control as we know exactly which files we are changing will effect what *customers* which is really what the company officials really want to know. When they ask, If I apply this patch, what is the impact? They don't really care if a given service will be offline, they want to know what relationships with business partners will be effected. The Venn diagrams let us tell them whom and what with no ambiguity. 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 Yes, we don't have any catalyst in production just yet (I'm hoping to see more of it) but perl will be re-rpmed and repo'ed before that happens. (Still in the assembling catalyst bricks phase) 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? 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/ I had some issues with cpan2rpm in the past which caused me to standardize on cpanflute2. But this could be a cut the ends off the roast issue now. I will re-visit cpan2rpm. Thank you. ___ 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 Friday 22 August 2008 16:44:01 James S. White wrote: 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? There are http://alioth.debian.org/projects/pkg-catalyst/ and http://alioth.debian.org/projects/pkg-perl Lots of people in these groups are packaging Perl modules and (more importantly maybe) maintaining these packages. The tool used by the Debian Perl group (and myself whenever I need to package a module) is dh-make-perl. You can also use cpan2dist in CPANPLUS : ### build a debian package of DBI and it's prerequisites, ### don't bother running tests cpan2dist --format CPANPLUS::Dist::Deb --buildprereq --skiptest DBI ### build a debian package of DBI and it's prerequisites and install them cpan2dist --format CPANPLUS::Dist::Deb --buildprereq --install DBI -- Bogdan Lucaciu http://www.wiz.ro/ ___ 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] Model::LDAP vs Authentication::Credential::LDAP
On Thu, Aug 21, 2008 at 11:17:05PM -0500, Peter Karman wrote: Peter Karman wrote on 8/17/08 2:09 PM: Matt S Trout wrote on 8/17/08 12:39 PM: On Mon, Aug 11, 2008 at 11:49:00AM -0500, Peter Karman wrote: I am going to be doing something similar eventually using Net::LDAP::Class and either C::Model::LDAP or a CatalystX::CRUD::ModelAdapter::LDAP. You might look at Net::LDAP::Class to see if it makes what you're doing any easier. Damn. Net::LDAP::Class reserves -meta for a crappy metadata object. Could that not be called metadata or something to make it easier to use with catamoose? yes, it could. I'll change it for the next release. Thanks for the feedback, Matt. Uploaded as 0.09. karpet++ -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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] Patch for Catalyst::Authentication::Store::DBIx::Class::User
On Fri, Aug 22, 2008 at 12:31:20AM +0300, Bogdan Lucaciu wrote:
On Thursday 21 August 2008 23:12:40 David Jack Wange Olrik wrote:
Wouldn't it be neat to have the username field configurable, just
like 'password_field' ?
You don't need that, read this:
http://search.cpan.org/perldoc?Catalyst::Authentication::Store::DBIx::Class#Simple_Retrieval
if ($c-authenticate({
username = $c-req-params-{'username'},
password = $c-req-params-{'password'},
status = [ 'registered', 'active', 'loggedin']
})) {
These name = value pairs are used more or less directly in the DBIx::Class'
search() routine, so in most cases, you can use DBIx::Class syntax to
retrieve
the user according to whatever rules you have.
Basically you pass whatever hashref you need to $c-authenticate. The
password_field is necessary because of the possible changes done by
Credential::Password .
I think the point is that it should be possible to rename fields on the
DBIC side without eneding to change your $c-authenticate line.
--
Matt S Trout Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
___
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/
[Catalyst] CatMail list and svn set up
http://lists.scsys.co.uk/ to get onto the list. http://code2.0beta.co.uk/catmail/svn is the currently empty repository; anybody who wants an htpasswd line on it should mail m.trout at shadowcat.co.uk with one and I'll rack 'em up. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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] Patch for Catalyst::Authentication::Store::DBIx::Class::User
On Thursday 21 August 2008 23:12:40 David Jack Wange Olrik wrote: Wouldn't it be neat to have the username field configurable, just like 'password_field' ? You don't need that, read this: [ ... ] Basically you pass whatever hashref you need to $c-authenticate. The password_field is necessary because of the possible changes done by Credential::Password . I think the point is that it should be possible to rename fields on the DBIC side without eneding to change your $c-authenticate line. I disagree. The goal seems to be to loosely bind to the DB fields from the auth side. This should be handled long before the DBIx::Class store. The problem is that If we made 'username' configurable, we would have to make every field configurable. We'd need essentially a map of 'inbound fields' to 'fields to send to -search()' because username is only one of the possible ways to search users during authentication. To do it properly, we'd also have to make a generic way to handle values and translate them to what would be in the database. Taking the example from the POD status = 'active' in the auth call would need to be translatable to a 'user_access_level' field which could have the values of 'logged in' 'registered' or 'admin'. There are too many more reasonable ways to accomplish this in an application that would not be convoluted and would not bury the fact that it is occuring at all. Adding it at the store level would be difficult to do well for relatively questionable gain. Jay ___ 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: Instant AJAX web front-end for DBIx::Class
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Alex, Hartmaier Alexander wrote: I've installed 0.25 some hours ago and got it working after using dumper to add the datatype informations to my dbic model classes I've only stumbled across two problems at the moment: 1) the use of c.extjs2 in the template which needed changing to c.config.extjs2 2) [error] Caught exception in MyApp::Model::LFB::Metadata-process Use of uninitialized value in exists Okay, many thanks for these two bug reports (and a few others on IRC). I've just sent LFB v0.27 to the CPAN with these fixes and a few others (as mentioned in the Changes file). regards, oliver. - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIruL/2NPq7pwWBt4RAvxgAKDqVAr0wjQw9eaElzW3wp+Z0jnULQCaAtXb NF/1hFlJkClv7zaDaMUv3Ls= =r8tU -END PGP SIGNATURE- ___ 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] [SOT] cat webmail app?
Matt S Trout wrote: On Mon, Aug 18, 2008 at 02:14:41PM -0500, Andrew Kornak wrote: On Mon, 2008-08-18 at 10:48 +0100, Matt S Trout wrote: On Fri, Aug 08, 2008 at 05:47:25PM -0500, Andrew Kornak wrote: http://www.webmin.com/usermin.html Not Cat based but is a fairly complete perl-based, modular, extensible solution as well as a useful system administration tool. I have used Webmin and Usermin for many years and highly recommend both. How does that remotely relate to webmail? As per the web sites I included, Usermin has a fairly complete mail module that integrates with spam/virus filters and offers many options regarding your mail delivery agent. Webmin and Usermin are BSD-like licensed and offer RPM. DEB, and tar source packages. I thought it might be a useful starting point or even a reference since it is written entirely in perl and is a very mature and well supported project. Ok. I last looked at webmin about three years ago and it was an appallingly badly written pile of hacks that just happened to work, and had no webmail related component at all. Correction: It's an appallingly badly written pile of hacks that just happens to work on millions of production systems every single day. I think we'd all like to have started a project that is as popular as Webmin. (~2 million downloads per year, just from SourceForge.) Just for reference, Usermin (the project he linked to, which is the webmail and user-oriented variant of Webmin) has been around for about 7 years. It's an extremely full-featured mail client, if a little clunky in the UI (I'm working on that). It's not as popular as SquirrelMail, because it requires a root-level installation, but it's definitely more powerful. It'd probably be wise to think of Webmin/Usermin in context: It is an 11 year old project with ~450,000 lines of code, written almost entirely by *one guy* (as a hobby a good deal of that time), that has to run on systems with very old Perl versions. And, because it is used in hundreds of embedded devices and commercial products, the standard API simply cannot change. There are 114 standard modules (last time I counted), and several hundred third party modules, and Webmin has never broken backward compatibility for those modules. A module written 10 years ago will work, unmodified, in last weeks Webmin release (it won't participate in logging or ACLs or notifications, but it'll work as well as it did 10 years ago). So, sure, it's got some old-fashioned Perl code that hasn't seen a major overhaul in many years (Perl 4-isms abound, even), but it's not bad code. Perhaps it is unfamiliar looking, if you've been working with modern OO Perl style...but it's not particularly bad. Quite concise and clear, mostly, if a bit quirky. And, of course, with several million users banging on it every day, it's pretty damned well-tested. We also accept patches. (Assuming they don't break backward compatibility and they work on Perl 5.005_4 and up.) ___ 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/
