|
|
|
9.3 Installing the PDBA Toolkit for UnixThere are three basic steps involved in installing the toolkit on Unix systems:
You will need to follow the steps in this section to install the PDBA Toolkit on your Unix platform so the scripts introduced in later chapters will work properly. 9.3.1 Setting the PDBA EnvironmentPDBA_HOME is the default directory for the PDBA Toolkit and all of its associated files. However, as we mentioned earlier in the discussion of the PDBA module, it may not be necessary to set PDBA_HOME on Unix. If you create an account dedicated to running the PDBA Toolkit, you may be happy enough storing its configuration files under the HOME structure of that account. Recall from our earlier discussion that this is where PDBA will look for them if PDBA_HOME has not been set. For instance, for new user oramon in the /home directory, the default location will be under /home/oramon/pdba. 9.3.1.1 Setting PDBA_HOME from the command lineIf you do wish to explicitly control the location of PDBA_HOME, it's as easy as this: $ export PDBA_HOME=/u01/my_pdba_home_dir To avoid typing this line as part of every login, edit your .profile file or equivalent, and add PDBA_HOME to the usual suspects required for the toolkit's installation. They are: 9.3.2 Installing the PDBA Perl Modules and ScriptsBefore actually installing the toolkit there are some other tasks you will need to deal with:
We'll first install the additional Perl modules needed for the PDBA Toolkit. 9.3.2.1 Installing additional modulesThere are three external Perl modules we need to load. We've kept this list of extras to a minimum in order to keep installation as simple as possible. However, as we developed this toolkit, we did try to follow the maxim of Perl programmers everywhere: "Laziness is a virtue." Put another way, Perl programmers are advised to avoid reinventing the wheel whenever possible and to make use of existing code wherever they can. These are the necessary modules; all of which can be installed from CPAN:
When connected to the Internet, the easiest way of installing these modules is this: $ perl -MCPAN -e "shell" cpan> install Date::Format cpan> install Crypt::RC4 cpan> install Mail::Sendmail cpan> quit Lockfile removed.
9.3.2.2 Determining installation locations for Perl modulesNow we can go ahead with the toolkit installation. First you need to download the toolkit. You can download PDBA-1.0.tar.gz, or its latest derivative, from our O'Reilly site:[5]
You now need to make two important decisions:
We generally want all of our Perl modules to be stored within the default Perl library tree. However, if you wish to install these modules elsewhere — perhaps to control access — use the PREFIX switch. For example, the following will install everything under ~/oramon/pdba: $ perl Makefile.PL PREFIX=/home/oramon/pdba This will mean that the modules get installed in directories that normally are invisible to Perl. The installer will take care of this by adding a code line near the top of PDBA executable shell scripts, as in the following: use lib qq{/home/oramon/pdba/lib/site_perl/5.6.1/};
Later on, this specification will tell Perl where to find the PDBA modules as Perl requires them. However, we recommend that you accept the default Perl library locations just to keep everything simple. 9.3.2.3 Determining installation locations for Perl scriptsThe recommended location for the Perl scripts isn't as obvious. Perl's ExtUtils::MakeMaker generally places scripts within the /usr/bin location. However, we (or your system administrator) may prefer /usr/local/bin. A slight command-line modification changes the target script directory as follows: $ perl Makefile.PL INSTALLSCRIPT=/usr/local/bin Installing the PDBA scripts in /usr/local/bin has the added advantage of separating the executable scripts from the OS binaries found in /usr/bin. This makes your scripts less vulnerable during system upgrades or rebuilds. Making them publicly available under /usr/local/bin still avoids a security risk (as the configuration files contain the confidential information). This information may be easily protected inside a user account such as oramon. 9.3.2.4 INSTALLSITELIBInstallation variations are possible too. For example, you might wish to put the modules in /home/oramon/pdba and the executable scripts in /usr/local/bin. But beware! You might think the following would suffice: $ perl Makefile.PL PREFIX=/home/oramon/pdba INSTALLSCRIPT=/usr/local/bin Alas, this produces unintuitive results. Rather than placing executables in /usr/local/bin, you'll find them lurking in /home/oramon/local/bin. This is because PREFIX takes precedence over INSTALLSCRIPT. We must instead substitute INSTALLSITELIB for PREFIX: $ perl Makefile.PL INSTALLSITELIB=/home/oramon/pdba INSTALLSCRIPT=/usr/local/bin For more on this and other MakeMaker variations, try the following command: $ perldoc ExtUtils::MakeMaker 9.3.2.5 Ready to installFrom now on, we'll assume that the PDBA Toolkit is being built by the oramon account. Follow these steps:
9.3.3 Installing PDBA Unix Configuration FilesWe'll store our Unix configurables via the highly sophisticated flat-file method,[6] albeit one with a special twist. While PDBA modules and scripts are now installed in the proper locations, the configuration files remain within the build directory. Let's find them a proper home:
$ cd $PDBA_HOME/PDBA-1.0 Of course, the final location of the files will depend on how you set PDBA_HOME:
To install the default configuration files, you simply need to execute this command: $ perl cp_config The cp_config script checks any potential PDBA_HOME value, determines what to do, and then installs the files accordingly (as described earlier). To configure these files, skip the Win32 installation, and go directly to the Section 9.5, later in this chapter, as configuration is similar for both platforms. |
|
|
|
