While I am more than willing to hand-follow all the dependencies for the various CPAN modules we need, I'm positive that someone has run into this before and has a solution. What I need is a script that will create a tarball of all the CPAN distros I list (given a Perl version), including all their dependencies, then provide a script within that tarball to install them in the right order (dependencies first).
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
For a standalone application like this, have you considered/tried using PAR?
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
Another suggestion I can offer is to look into alias's Task namespace and ideas.
Only thing I couldn't figure out yet is whether cpan/cpanplus can download dependent dists automatically.
Suposing that you're using your workstation to develop (you're not deploying directly to the production enviroment, are you?) you can download all modules and dependencies that you need. When you think the stuff is ready for deploy, you can use the module CPAN::Distro Builder to create a tarball with those modules. If you have many modules that needs to be shipped to the production server, then you probably will want to search at CPAN for the various modules that generates a list of dependencies (CPAN::Unwind is a candidate for that).
Other solution is to use the repository that you have at your machine and copy it to the production server. Once there, you just need to setup CPAN to use a file as an URL and points to the repository that you had copied in the filesystem.
---------------------------------
"You have enemies? Good. That means you've stood up for something, sometime in your life." - Sir Winston Churchill
We use a perl program that builds all our modules, and it has to manage the dependencies. It uses the dependencies listed in the module as a starting point, but many modules do not list their dependencies correctly, so we have to refine the list by hand. Of course, the dependencies themselves depend on the version of perl, since more modules are brought into the core in higher versions.
What we did, is give the it-department of the company a list of prerestiqued modules, and let them do the installation of the server. Next, if the program failed due to the miss of one or more modules, they were responsible (and took that serious luckily)
I do think, if you explain and negotiate, a lot will be possible, and let your client participate. (and make him responsible)
In these cases, I give our clients a minicpan on a CD (maybe even with their stuff added with CPAN::Mini::Inject). They configure their CPAN.pm (or whatever) to grab files off of the disk rather than the network. Everything works peachy.
brian d foy
Subscribe to The Perl Review
We develop a pretty tricky mod_perl2/mason app with a supertuned mysql (all compiled with intels c++ compiler for best performance - around 25% faster). And we create a big rpm of everything for its proper place, we only check the kernel release.
Except, the client is paranoid and won't let this machine talk to the "Big Bad Outside World". Only my machine is allowed to talk to it from outside their DMZ.As a security advocate, I wouldn't call the person paranoid. Yes, too much security, and you can't get anything done. But it is common place to have production machines, if that is what this is, to do very VERY specific things. I'm sorry if it sounds like I'm jumping down your throat, but I am asking people who read what you wrote and think of some of the consequences of not DMZing. webservers normally have connections only comming in from a certain set of ips, if yer doing nat, or a load balancer, this may be small. If the device is just packet forwarding, it's huge! The connections going out from the same server would normally be really small, since as a web server, its duty is to serve pages, not to be a resource to access other foreign resources. That being said, anything going onto the machine, normally is verified as the required set of changes for auditing and quality purposes. If one day, CPAN was hacked, as public repositories have had happen, and you tried to use it, that new machine will have, "bad code". If you package you modules, and it went down a pipe to get to production, directly from dev or through QA, 1) The code you downloaded has had a justation period for like people to download the code and say, "HOLY CRAP!", 2) What everyone has validated and audited that is going into production, really is just that. No suprise upgrades. Easiest suggestion I can recommend, have a target that is, "pristine." Install a tool like tripwire and run it against the pristine target. Now run CPAN. Run a tripwire report to see what has changed. That will be your list of things to export. A nicer way would be to have two copies of production on a dev box, then run cpan targetting one. Do a diff. Enjoy! :) Both solutions would work even if you weren't using CPAN and can't easily figure out the differences for modules, configuration files, beer.. stuff.. yeah.
Yes! Thank you Sporty! I don't think the client's requirements are unreasonable at all..
--Pileofrogs
The only thing that made me wonder is the emphasis on outside connectivity, rather than on the code being introduced to the machine. I have the feeling that
- Only allowing the cpan shell to go out and download code, while closing everything else down, is pretty simple to arrange with a simple set of firewall rules
- The risk of unwanted traffic to the machine is way lower than the inherent risk of installing foreign code
Personally, I'd rather trust my firewall rules than the new code. If I were paranoid about security, I'd prefer to audit each and every newly installed module in favor of worrying about network traffic during the installation. Of course, that's a much harder problem, and for practical reasons alone I'd be inclined to trust CPAN code to be secure. But then I'd no longer be paranoid :-)
From a dictionary..
# Exhibiting or characterized by extreme and irrational fear or distrust of others: a paranoid suspicion that the phone might be bugged.Extreme and irrational fear or distrust. Note the keyword irrational. If I'm mincing words, forgive me. 'cause the context and the further context implies a negative tone, not something tongue-in-cheek, thus my lengthly reply."paranoid." The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004. Answers.com 02 Feb. 2006. http://www.answers.com/topic/paranoid
Once a machine is established as secure, it needs to stay such. Outbound firewalling prevents installed malware or plain ol' hacked machines, to not be used for DDOS uses, spam uses, or as a proxy of sorts.
It's not about all about the quality of CPAN. It's about what was tested, still working. It's about the sysadmin having the go-ahead from QA, that some N being installed, nothing more, nothing less.
Any repository can be hacked, or bad uploads to the repository, can occurr. Don't fool yourself into thinking that copying something you know is workign from a dev or qa box to production, is silly, vs getting it from CPAN.