Using PEAR 1.4.0 to install PEAR packages on a remote host

(26)

Do you develop a website? It is infinitely better to synchronize live and development sites using the PEAR Installer

(24)

(19)

doing the PEAR thing

(19)

PEAR now fits in a bottle: meet go-pear.phar

(17)

Syndicate This Blog

RSS 0.91 feed

RSS 1.0 feed

RSS 2.0 feed

ATOM 0.3 feed

ATOM 1.0 feed

RSS 2.0 Comments

Powered by

Serendipity PHP Weblog

Saturday, March 19. 2005

Using PEAR 1.4.0 to install PEAR packages on a remote host

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.

Fortunately, this problem is definitely solved in PEAR 1.4.0!

Here is the sequence necessary to get things running:

Make sure you have a working copy of the CLI version of PEAR (the "pear" command, not the web interface)
Make sure you have ftp access to the remote host
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!

2. Make sure you have ftp access to the remote host

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.

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:


<?php

<br />&lt; php<br />echo dirname(__FILE__);<br /> &gt;<br />

?>

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. I will show 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.

In windows:

C:\remote\pear\> pear -c remote.ini install DB

In Unix:

$ pear -c remote.conf install DB

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.

However, the craziest thing about this is that you have full access to the pear installer's ability to handle and resolve dependencies! The only dependencies that can't resolve automatically are the arch, os, and possibly extension dependencies, but if you know what is installed on the remote host (and you should), that is not a big deal. This command:

$ pear -c remote.conf install -a SOAP

will install the SOAP package, and its full dependency tree (SOAP, Net_URL, HTTP_Request, Net_DIME, Net_Socket). Imagine trying to do this by hand.

The best thing about this is that it does not matter what security measures are in force on the remote host - if you can ftp in, you can install the files. PHP is not even necessary on the remote end (although it would not make much sense to be uploading PEAR files to a host that doesn't have PHP, but whatever floats your boat). Forget safe mode, trying to use the web installer - none of this is necessary any longer.

Posted by Greg Beaver in PEAR at 20:16 | Comments (19) | Trackbacks (2)

Trackbacks

Trackback specific URI for this entry

Installing Pear Packages without the Installer
The Pear Installer is my favorite feature of Pear, and I have often thought about ripping up the Xaraya installer and Modules section to do something similar. However, it always comes back to the usability of Xaraya that I can't seem to shake my mind from. Greg Beaver has a very nice small tutorial on how to install Pear Packages minus the command line interface. It takes you step by step when you are without the sbell access. Imagine Xaraya 2.0.0 with a simple click from the modules to load the new module or upgrade up from whereever. Imagine the includes sitting outside of the webroot in the include path where all you have is an index.php and var folder (prolly outside of the webroot as well) which can be updated as simply as well. For shared providers it would be easy to have multiple implementations on the box because Xaraya is in the same path as the rest of the Pear utilities. Not quite Nirvana, but man, I certainly think its an idea worth exploring for the next versions.

Weblog: Wyome
Tracked: Mar 20, 03:44

PHP web development environment tips (mostly) for WinXP users
I agree with Sean (What's under YOUR hood?), it's very useful to discuss the tools we use for development. When I started PHP development 4-5 years ago, a simple texteditor and an FTP client was enough to achieve my goals. During the years I've quit my

Weblog: Norbert Mocsnik's blog
Tracked: Jun 15, 03:09

Comments

Display comments as (Linear | Threaded)

I recently install PEAR 1.3.5 in my shared host with go-pear.php. As my first experience with PEAR, I tried to install it into 2 locations: inside/outside of htdocs.

now, I just want to uninstall one of them. But I find no way to do it although I tried to use FTP to delete it but Apache said it is denied

How could I resolve this problem?

thanks
Dinh

#1 pcdinh (Homepage) on 2005-03-20 02:17 (Reply)

The issue you're experiencing is quite common for users of the web installer. Here is the reason you're experiencing this:

The files were created by apache, using user nobody, group nobody. Your user is not nobody (kinds of sounds like a bad psychologist, eh?), and you are not a member of the nobody group, so you are not allowed to delete these files. They can only be deleted by apache!

The solution is to create a simple script that recursively traverses the directories containing pear, and deletes them. The best tack is to first create a script that prints the files in the order that they would be deleted, and then add the unlink() call in.

Hope this helps!

#1.1 Greg Beaver (Homepage) on 2005-03-20 07:24 (Reply)

I had the same problem. Here is a good recursive function to handle it:
(found this at http://us3.php.net/function.rmdir)- it worked great!

itsdapead
28-Feb-2005 10:03
Warning! On Unix-type systems, most of the "delete directory tree" functions posted here will follow & delete symbolic links (which is not what you'd expect of, say, rm-rf) so you might find more than you bargained for getting wiped.

Here's a quick kludge of an earlier submission (by tekangel) that avoids this by default.

Make sure it does what you want before you uncomment the unlink and rmdir commands!

#1.2 Chris Ishii on 2005-04-01 23:33 (Reply)

I've been struggling with this for a few days now and feel like I'm getting nowhere. I installed PEAR no prob on my local machine. I am able to use the CLI and ftp to my webserver. However, when I get to the config-create step I run into probs. Here's the error I receive:

C:\remote\pear> pear config-create -w C:\remote\pear remote.ini

Configuration File "C:\remote\pear\remote.ini" is empty

Any ideas what I'm doing wrong? I have checked and double checked all my environment variables and config files and everything seems to be pointing to the right directories. I can use the CLI to install pear packages and have not had any probs using anything. This is the only thorn in my side at the moment. Any help would be appreciated.

Thanks.

#2 eggie on 2005-10-19 13:49 (Reply)

I am experiencing the same now on both Unix and Windows while it worked like a charm weeks ago. Maybe something is broken or changed in the newest versions? Currently 0 byte files are created on both platforms.

#2.1 Norbert Mocsnik (Homepage) on 2005-10-20 09:57 (Reply)

This was indeed a bug in PEAR_Config. The problem was not caught by unit testing because the tests had mistakes in them.

This is http://pear.php.net/bugs/5676, and I just fixed it in cvs

#2.1.1 Greg Beaver (Homepage) on 2005-10-20 15:34 (Reply)

That was fast. Thanks!

#2.1.1.1 Norbert Mocsnik (Homepage) on 2005-10-20 15:38 (Reply)

Thanks! That definitely worked. But now I have another issue hehe. I'm able to get as far as setting the remote-config property in remote.ini. At that point no matter what I set it to it either throws an error or just creates a pear directory below the local directory I'm sitting in. If I type:

C:\remote\pear\> pear -c remote.ini config-set remote_config ftp://user:pass@myremotehost.com/.pearrc

I get an error saying "config-set: only the layers "user" or "system" are supported". I have .pearrc in /home/user/pear on my webserver and yes, I am changing the user and password information in the string to my ftp connection information. Any ideas?

Thanks

#2.1.1.1.1 eggie on 2005-10-21 15:16 (Reply)

Hi,

Is your PHP by chance the CGI build rather than the CLI build?

I've noticed all kinds of weird behavior from the CGI version of PHP with PEAR at different times, and it would be helpful to know this to find the problem.

#2.1.1.1.1.1 Greg Beaver (Homepage) on 2005-10-21 19:19 (Reply)

I've followed these directions several times and I just can't seem to get it to work.
I'm using Fedora Core 3. I have done a pear upgrade-all.
The process seems to work fine, but it never actually uploads anything to my ftp server. It doesn't even seem to try.

Any ideas what could be wrong?

#3 james on 2006-01-24 19:24 (Reply)

Did you install Net_FTP?

#3.1 Norbert Mocsnik (Homepage) on 2006-01-25 03:10 (Reply)

Yah. I have Net_FTP installed both system wide and with the local/remote config.

[james@delta pear]$ pwd
/home/james/remote/pear

[james@delta pear]$ pear -c remote.conf config-get remote_config
ftp://user:host@myftpserver.net/.pearrc

[james@delta pear]$ pear -c remote.conf install -f --alldeps HTML_Quickform
downloading HTML_QuickForm-3.2.5.tgz ...
Starting to download HTML_QuickForm-3.2.5.tgz (97,612 bytes)
......................done: 97,612 bytes
install ok: channel://pear.php.net/HTML_QuickForm-3.2.5

that's basically all it outputs.

I've tried a variety of packages. I've tried the whole process as root, and as a non-priv user. None of them seem to even try to do the upload.

#3.1.1 james on 2006-01-25 11:39 (Reply)

I'm getting the same results. Does anyone have a possible solution for this?

#3.1.1.1 Brett (Homepage) on 2006-02-07 21:47 (Reply)

Same results here as well.. Anyone knows how to fix this?

#3.1.1.1.1 Bjorn on 2006-03-15 05:46 (Reply)

I have a website on shared unix host and I develop from a windows desktop. Do I follow the Unix instructions or Windows instructions?

#4 Blue Star on 2006-02-20 08:01 (Reply)

Hi Blue Star,
I am in the same boat, developing on windows and trying to installed on a shared linux host. I have all of the problems on this page!

If anyone knows if it is possible to install on windows while doing a remote install on linux let me know. I may just copy down every thing in the webinstaller, use the rmdir script to delete the files, and copy it back under my user id. Seems like a pain.

What I would rather do is create a script that would run on the linux host that allows me to input CLI commands to install and uninstall, etc, using the nobody id. If WebInstaller can do it why can't it be done by me? Does such a simple script exist?
thanks!
WTF

#4.1 WTF on 2006-03-10 22:21 (Reply)

You guys are writing in the programming stratosphere. I've read lots of low-level PHP books and can't make the least bit of sense of what you're talking about.

Is there yet another book I should read before trying to attempt this stuff?

#5 Stu Ducklow (Homepage) on 2007-02-13 09:24 (Reply)

Hi Stu,

Don't worry, you need not be overwhelmed by the complexity.

Since you have already read many books, what I recommend you do now is log at least 100 hours of plain hacking. Just try to *do* something with PHP. Choose a basic thing to write, even if someone else has already done it, and try to write your own version. This way, you will learn (as I did) the basics in a way that is helpful.

For instance, I was extremely confused by the dereferencing syntax of objects for about an hour when I was first learning PHP. Why? I was trying to do this:

$this->$varname;

instead of:

$this->varname

Also, make friends with the REST interface to php.net. If you are trying to figure out how to use strpos, simply type:

php.net/strpos

and voila - instant helpful documentation. Even if the function doesn't exist, php.net will suggest a bunch of functions that might be what you're looking for.

At a certain point, all the CS/book learning/vitamins in the world will not help you one bit unless you start making your own mistakes and learning from them.

Very early on, you need to develop a system for debugging that will allow you to easily and quickly track down the source of a problem. There are several ways to do this in php (var_dump() and company, using an echo followed by exit; to see which line is crashing, etc.), and this will be far more important than any patterns you choose to develop with initially.

The first thing you develop will suck, no matter how many design patterns you've studied, no matter how much theory you think you understand. Until you work with a living, breathing machine (well, ok, it's a metaphor), and learn the idiosyncracies of the language, nothing is really all that helpful.

So, go out and do!

I'll be interested to hear your progress. As you do, of course, study the source code of others, it will give you ideas. The pear repository, zend framework, symfony, and a host of others all have public CVS repositories, you can study how people have done things. phpclasses.org sometimes has useful things, but beware using the site to learn PHP, as many classes are not coded well, and the site is designed to accept all submissions without quality control beyond user voting.

Once you feel comfortable with the language, start integrating the well-tested code of PEAR and other repositories into your toolkit, and you'll understand completely the "stratospheric" stuff you're seeing

#5.1 Greg Beaver (Homepage) on 2007-02-13 14:26 (Reply)

HI Greg

Thanks for your encouraging reply. I was writing out of frustration and didn't expect anything. I'll let you know about my progress eventually. Meantime, as a Mac user (I've been reading your blog) I never have problems with equipment and my computer hasn't crashed in months. Macs have a few network issues, but nothing like you're talking about.

Again thanks

Stu

#5.1.1 Stu Ducklow (Homepage) on 2007-02-13 15:23 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	Standard emoticons like :-) and ;-) are converted to images. E-Mail addresses will not be displayed and will only be used for E-Mail notifications To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above: BBCode format allowed You can use [geshi lang=lang_name [,ln={y\|n}]][/lang] tags to embed source code snippets
	Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.