Installing a local copy of PEAR through ftp has become a piece of cake in PEAR 1.4.0+.
One of the banes of many user's existence is trying to install PEAR on a remote host
that does not have shell access. Often, the only choice is to use FTP, but even this
is a problem for more complex packages that take advantage of installer features like replacements.
Here is the sequence necessary to get things running:
Make sure you have a working copy of the CLI version of PEAR on your local computer
(the "pear" command, not the web interface)
Make sure you have ftp access to the remote host, and write access through ftp
Note the full path to your home directory
Create a customized configuration file for both the local and remote host
Upload the remote configuration file to the remote host
Using the local configuration file, set the remote_config value to the location
of the configuration file on the remote host
Install packages at will!
1. Make sure you have a working copy of the CLI version of PEAR (the "pear"
command, not the web interface)
Read The installation instructions.
2. Make sure you have ftp access to the remote host, and write access through ftp
This is pretty straightforward - if you can loging using the ftp command in a DOS
prompt or from a unix shell, you have ftp access. Note that sftp is not yet supported
by PEAR, but will be as soon as the Net_FTP package supports sftp.
Write down the user and password that you need to login.
Testing write access is easy. If you can upload a file, you have write access.
3. Note the full path to your home directory
This is also pretty straightforward. Upload this script to the root directory of
your web host to find out:
<?php
echo dirname(__FILE__);
?> |
Chances are, it will be something like: /home/username/htdocs.
When you log into ftp, if you can change directory to /home/username, that's great.
4. create a customized config file for both the local and the remote host
This is also quite simple. Here is how to do this on windows and unix.
Windows first:
Pick a location to store your local copy of the remote code. For example,
C:\remote\pear. From a Command prompt (click Start here =>
Programs and search for the Command Prompt), type:
C:\> mkdir remote
C:\> cd remote
C:\remote\> mkdir pear
C:\remote\> cd pear
C:\remote\pear> pear config-create -w C:\remote\pear remote.ini
C:\remote\pear> pear config-create /home/username/pear .pearrc |
In Unix, follow a similar process:
$ cd
$ mkdir remote
$ cd remote
$ mkdir pear
$ cd pear
$ pear config-create /home/mylocaluser remote.conf
$ pear config-create /home/username/pear .pearrc |
5. upload the remote configuration file to the remote host
This is straightforward - in both operating systems, use ftp to upload
.pearrc to /home/username/pear/.pearrc
6. using the local configuration file, set the remote_config value to the
location of the configuration file on the remote host
In windows:
C:\remote\pear\> pear -c remote.ini config-set remote_config ftp://user:pass@myremotehost.com/.pearrc |
In Unix:
$ pear -c remote.conf config-set remote_config ftp://user:pass@myremotehost.com/.pearrc |
7. install packages at will!
From this point on, you can use the pear command normally, and it will automatically
synchronize the local and the remote repositories.
How does it work?
Simple. The installer installs the package locally, and then uses Net_FTP and uploads
a copy of each locally installed file to its equivalent location remotely. All commands
that affect installation (install, upgrade, even upgrade-all) can be used with this
option. The "remote_config" option tells the installer that it should automatically
mirror the local copy to the remote host.
Even more exciting, the remote configuration file is used for any replacements. In
other words, if a file expects to get the path to data files through the data_dir
configuration directive, then it will have the path on the remote host
(/home/username/pear/data) rather than the local copy (
C:\remote\pear\data). This has
one side effect: the local copy will not work on the local machine, but if you think
of it as a backup copy (In an emergency, you can always just upload the entire contents
to the remote host using regular old ftp or scp), the reasoning becomes obvious.
It is important to note that some packages install themselves differently on windows and on
unix. Be sure you know whether this is the case before installing, or ensure that your
local and remote systems are the same kind of operating system.
