{"id":606,"date":"2010-07-05T17:58:54","date_gmt":"2010-07-05T17:58:54","guid":{"rendered":"https:\/\/copyright.lboro.ac.uk\/lorls\/?p=606"},"modified":"2010-07-05T17:58:54","modified_gmt":"2010-07-05T17:58:54","slug":"installer-progress","status":"publish","type":"post","link":"https:\/\/blog.lboro.ac.uk\/lorls\/lorls\/lump\/installer-progress","title":{"rendered":"Installer progress&#8230;"},"content":{"rendered":"<p>Writing a web driven installer for LUMP in Perl is proving to be, er, &#8220;interesting&#8221;. \u00a0Today has seen some useful progress and its probably worth noting some of the tricks used (mostly because they&#8217;re rather esoteric and bug hunting might be fun in a few years time when I&#8217;ve forgotten why I did what I did!).<\/p>\n<p>The first thing I had to get going was bootstrapping the the required CPAN modules as documented in my previous post. \u00a0This is now working OK. \u00a0A few gotchas to note:<\/p>\n<ul>\n<li>When you fork off a child process from a CGI script that you want to be &#8220;long lived&#8221; (ie outlive the parent process that has returned some HTML to the user), you need to close down STDOUT, STDIN and STDERR, otherwise Apache hangs around waiting for the child to finish. \u00a0This can actually be handy, as you can then reopen file handles with those names pointing elsewhere (such as to a session file) and record the output of other tools that the child calls upon (such as the very chatty CPAN::Shell).<\/li>\n<li>CPAN::Shell doesn&#8217;t appear to return a useful error status, so programmatically you can&#8217;t tell if your module install worked or not (the verbose output is designed to tell a human). \u00a0To find out if a module is installed, you have to try to &#8220;use&#8221; that module again &#8211; once installed the use statement should work.<\/li>\n<li>Talking of use statements its worth noting that these are best done inside eval()&#8217;s, as that allows you to capture errors (as in the case of a module that has failed to install). \u00a0You have to be careful whether you have compile or run time binding though, especially if you&#8217;re eval()ing stuff with variables in that you&#8217;re planning on instantiating during the run. \u00a0Perl -cw is your friend as usual by warning you about dodgy compile time issues.<\/li>\n<\/ul>\n<p>Once I could successfully install CPAN modules in to a private LUMP modules directory, the next thing to consider was the database. \u00a0The installer CGI script asked the user for the database name, database account and database password to use and then checks to see if it can gain access. \u00a0For most noobs this won&#8217;t work as they won&#8217;t have a database\/account\/password, so the CGI script traps that error and asks if they&#8217;d like it to create the database for them. \u00a0This requires them supplying the database root password and then (assuming its right) creates the database and grants SELECT\/INSERT rights to the named user identified by the given password.<\/p>\n<p>The CGI script then checks that this user can connect to the database &#8211; if they can&#8217;t then something has gone wrong with the basic creation and we have to tell them to fiddle by hand. \u00a0Assuming that is OK, it then changes back to the database root user to do the schema creation (as the user only has SELECT\/INSERT privs). \u00a0This however called for another hack: we&#8217;ve kept the database schema and index definitions in SQL text files. \u00a0During development we&#8217;ve just source&#8217;d these in with the mysql command line client &#8211; but this won&#8217;t work from Perl&#8217;s DBI interface and I don&#8217;t want to rely on finding the mysql command line client and system()&#8217;ing out to it.<\/p>\n<p>So my next trick was another Perl script: the installer_maker. \u00a0This is a simple filter script that reads a &#8220;template&#8221; installer script in and writes out a proper installer with a couple of lines in the template replaced by some Perl array structures &#8211; one for the table schema and one for the indexes. \u00a0These arrays simply contain one SQL statement in each element that the installer_maker has ripped out of the LUMP schema and indexes SQL text files. \u00a0Bingo! \u00a0We can now carry on tweaking the schema\/indexes in the files we&#8217;re used to in development, whilst not having to remember to do lots of code twiddling to keep the installer in sync &#8211; we just need to run installer_maker before making a distribution. \u00a0Hopefully that should result in less chance of our dev schemas getting out of step with released production schemas and the bugs that could result from that.<\/p>\n<p>So its looking promising now, and from a user perspective is probably far friendly than the command line Perl installer from LORLS. \u00a0The next thing to write is a routine in the installer that can check the schema and indexes in a live database against the schema\/indexes we have now got embedded in the installer. \u00a0If they differ in some way we need to tell the admin running the installer and let them decide whether to ignore the difference (bad idea probably), tweak it by hand or (preferably) let the installer tweak their schema\/indexes. \u00a0Hopefully in the long term this will be a useful place to hang LUMP schema\/index upgrades on &#8211; folk could use the installer not only to load new versions of the Perl code but also update their database structure. \u00a0That&#8217;ll need some serious testing though&#8230; \ud83d\ude42<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Writing a web driven installer for LUMP in Perl is proving to be, er, &#8220;interesting&#8221;. \u00a0Today has seen some useful progress and its probably worth noting some of the tricks used (mostly because they&#8217;re rather esoteric and bug hunting might be fun in a few years time when I&#8217;ve forgotten why I did what I [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[4],"tags":[],"class_list":["post-606","post","type-post","status-publish","format-standard","hentry","category-lump","count-0","even alt","author-cojpk","last"],"_links":{"self":[{"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/posts\/606","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/comments?post=606"}],"version-history":[{"count":0,"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/posts\/606\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/media?parent=606"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/categories?post=606"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lboro.ac.uk\/lorls\/wp-json\/wp\/v2\/tags?post=606"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}