Well, here I am. I took a break from Friday evening until this evening and then got back to work, and I have just finished the most terrible and nasty job of transferring the hosted site content over to Pericles.
Compress, copy, uncompress, change a few paths, add to /etc/hosts to "trick" the server into thinking the DNS is pointed here already when its still really on the old box, and edit /etc/apache2/pericles.conf (I include this from the main httpd.conf file) to tell it to pull from 192.168.0.1 instead of the real VirtualHosting IP. Run apache2 -k restart, and try it out in Firefox. Wash, Rinse, Repeat. About 35 times.
One of the things I had to do was set permissions on the web files so that my scripts were able to write to the folders they needed to. In Ubuntu, the default Apache2 user seems to be www-data.
After testing all the sites, it is now time to set up the necessary FTP accounts with access to their proper folders, to change the IP *back* to the real one in the pericles.conf, to install a fresh grab of the mysql database, to change the IP of the machine itself, and then to physically swap boxes and bring the new server online. After that, I expect chaos :-) Just kidding. I think I've checked everything out. I'm also limiting myself to finish this in the next 3 hours or else to hold off until another night so that this operation doesn't run into morning time.
I'll report back again once more progress has been made.
Showing posts with label Apache. Show all posts
Showing posts with label Apache. Show all posts
Saturday, December 9, 2006
Wednesday, December 6, 2006
Converting Hardcoded Pathnames
The next step on my adventure with Pericles is to convert all of the hard-coded pathnames from F:\Web to /var/www (as well as any other hardcoded paths I find.) I've been pretty careful not to use hard-coded names in unnecessary places, putting most of them in simple configuration include files and so forth, because I knew from the beginning that this day would come.
I typed grep and it turns out that I have a convenient version of Turbo grep (comes with any Insprise/Borland product of the last decade), but GNU grep should work just as well. The syntax for turbo grep that I'm using is:
grep -di "f:" *.ph*>hardcoded
I'm using *.ph* because I am searching all *.php and *.ph files. I typically use *.ph for include files instead of *.inc, the -di means search subdirectories and ignore case, and I keep my data and web files on the F: drive. I'm redirecting the output to a file named hardcoded so that I can use it as a checklist. I'll do the same thing again but, like this:
grep -di "c:" *.ph*>>hardcoded
To get all references to anything on the C: drive (I know I refer to an executable font conversion tool from one place, for example.) and the double angle brackets mean to append the result to my previous file instead of overwriting.
Now that I have my checklist, here's the plan:
I want to convert all the code while still on the Windows box to support Linux based on a single configuration change. I will make an include file with one function in it that takes any path given as a parameter and if it starts with /var/www, to convert it back to F:/Web. This will allow Linux to be the native language with a "patch" for Windows support. This should have been part of my plan from day 1 (two years ago), but it didn't occur to me. The idea is that I can replace this function with an "identity" function such as: function linpath($a) { return $a; } in order to use raw Linux paths instead of Windows.
I will also do similar adaptations on a situational basis as I run into any F: or C: references that can't be solved with the above include file.
I anticipate some difficulties with file permissions since Apache on Linux is more secure than Apache on windows. My main resolution to this will be to consolidate the affected items that need to be accessed into consistent areas that the Apache process has access to read. If I have any chroot issues, I can overcome them with the use of mount --bind as explained in my article on setting up FTP.
This path translation will probably be the most tedious task in the Pericles project. I'll report back when I have finished.
4:18 P.M. - Upon more deliberate consideration, I have determined to abandon this undertaking and instead to change the paths manually. Why? There only seems to be about one per website, with an odd exception here or there. The trouble crops up when deciding exactly how to include the file with the path mapping function without using a path for itself. Furthermore, even if I install it into the default includes path, it seems silly to include a file only to help correctly include another file. May as well just change them when the time comes.
I typed grep and it turns out that I have a convenient version of Turbo grep (comes with any Insprise/Borland product of the last decade), but GNU grep should work just as well. The syntax for turbo grep that I'm using is:
grep -di "f:" *.ph*>hardcoded
I'm using *.ph* because I am searching all *.php and *.ph files. I typically use *.ph for include files instead of *.inc, the -di means search subdirectories and ignore case, and I keep my data and web files on the F: drive. I'm redirecting the output to a file named hardcoded so that I can use it as a checklist. I'll do the same thing again but, like this:
grep -di "c:" *.ph*>>hardcoded
To get all references to anything on the C: drive (I know I refer to an executable font conversion tool from one place, for example.) and the double angle brackets mean to append the result to my previous file instead of overwriting.
Now that I have my checklist, here's the plan:
I want to convert all the code while still on the Windows box to support Linux based on a single configuration change. I will make an include file with one function in it that takes any path given as a parameter and if it starts with /var/www, to convert it back to F:/Web. This will allow Linux to be the native language with a "patch" for Windows support. This should have been part of my plan from day 1 (two years ago), but it didn't occur to me. The idea is that I can replace this function with an "identity" function such as: function linpath($a) { return $a; } in order to use raw Linux paths instead of Windows.
I will also do similar adaptations on a situational basis as I run into any F: or C: references that can't be solved with the above include file.
I anticipate some difficulties with file permissions since Apache on Linux is more secure than Apache on windows. My main resolution to this will be to consolidate the affected items that need to be accessed into consistent areas that the Apache process has access to read. If I have any chroot issues, I can overcome them with the use of mount --bind as explained in my article on setting up FTP.
This path translation will probably be the most tedious task in the Pericles project. I'll report back when I have finished.
4:18 P.M. - Upon more deliberate consideration, I have determined to abandon this undertaking and instead to change the paths manually. Why? There only seems to be about one per website, with an odd exception here or there. The trouble crops up when deciding exactly how to include the file with the path mapping function without using a path for itself. Furthermore, even if I install it into the default includes path, it seems silly to include a file only to help correctly include another file. May as well just change them when the time comes.
Configuring PHP
I'm now trying to get PHP working on Pericles.
The first thing I should point out, is that I started by doing a vanilla LAMP install from the Ubuntu Server disc. This means I already had Apache2 and PHP5 installed "out of the package", but they aren't configured adequately for my needs.
I dropped a simple file in /var/www that would echo the output of phpinfo() so that I could compare it with my existing WAMP server's setup.
Here are the major differences that I need to adjust:
magic_quotes_gpc needs to be turned off. It's a stupid thing, blast them for making it default to on. post_max_size and upload_max_filesize need to be increased, because I have people uploading large megapixel images through http forms. 2M doesn't quite cut it any more these days. The gd module needs to be enabled. The zip module, or a substitute for it, needs to be enabled (I use this to automatically unpack files uploaded to a designated FTP account for daily processing.) I notice a few other differences, but I think they're minor. If I run into problems with them later, I'll follow up with details on how to fix them.
I discovered that by installing the php5-gd package with Synaptic, and then restarting Apache I gained gd2 support. That was easy. To restart Apache:
This does a graceful restart (it won't force any connections to close that are still opened). I realize this is a new box, so there won't be any connections hanging open anyway, but it is good to get into this habit early on.
I reloaded the phpinfo() test file, and there is now a section for gd which says version: 2.0 or higher, and everything looks enabled (freetype, t1lib, gif, jpg, png, wbmp)
I think the zip module I was using was part of pecl. I know pecl is similar to pear, and now that I think about it, I know I'll need pear support too, so if it hasn't already been done, php5-cli and php-pear should now be installed with Synaptic. The reason we need to install php5-cli is because pear is a command-line utility, and requires the command-line version of PHP in order to run. Don't worry: php5-cli and libapache2-mod-php5 peacefully coexist. I opened a shell, typed pear, and there it is!
On a whim, I typed pecl, and it also runs. It looks like pear and pecl come as a pair (no pun intended).
Back to Synaptic, we need to install php5-dev because we will need a tool called phpize in order to complete the next step. php5-dev has several dependencies that it will automatically install.
Now, the magic command:
When its finished, it will say: You should add "extension=zip.so" to php.ini
Do what it says. Add the line extension=zip.so at the very end of the file, because that's where the automatically added extensions (mysql, mysqli, gd) ended up. You may want to also add the same line into the /etc/php5/cli/php.ini so that you have zip support when you use php for shell scripting.
Save your changes and:
If you look at the phpinfo() output again, you'll now see the zip section near the bottom. This is
really easy.
While we're editing these two ini files, lets search for and change the following lines to these new values:
memory_limit = 16M
post_max_size = 16M
magic_quotes_gpc = Off
upload_max_filesize = 10M
Remember to set these for both /etc/php5/apache2/php.ini and /etc/php5/cli/php.ini
Another tool I sometimes use (if I need to programatically submit a post):
Well, I think that's everything I use. Restart apache2 one last time and see if it all works.
The first thing I should point out, is that I started by doing a vanilla LAMP install from the Ubuntu Server disc. This means I already had Apache2 and PHP5 installed "out of the package", but they aren't configured adequately for my needs.
I dropped a simple file in /var/www that would echo the output of phpinfo() so that I could compare it with my existing WAMP server's setup.
If you don't have Apache working yet...
You can use php5-cli (install this with Synaptic) as an alternative to view the phpinfo() at a shell prompt:php
<?php echo phpinfo(); ?>
(Press CTRL+D)
A plain text rendering of phpinfo() will appear, which you can scroll back to view in your console buffer.
Here are the major differences that I need to adjust:
magic_quotes_gpc needs to be turned off. It's a stupid thing, blast them for making it default to on. post_max_size and upload_max_filesize need to be increased, because I have people uploading large megapixel images through http forms. 2M doesn't quite cut it any more these days. The gd module needs to be enabled. The zip module, or a substitute for it, needs to be enabled (I use this to automatically unpack files uploaded to a designated FTP account for daily processing.) I notice a few other differences, but I think they're minor. If I run into problems with them later, I'll follow up with details on how to fix them.
I discovered that by installing the php5-gd package with Synaptic, and then restarting Apache I gained gd2 support. That was easy. To restart Apache:
sudo apache2 -k graceful
This does a graceful restart (it won't force any connections to close that are still opened). I realize this is a new box, so there won't be any connections hanging open anyway, but it is good to get into this habit early on.
I reloaded the phpinfo() test file, and there is now a section for gd which says version: 2.0 or higher, and everything looks enabled (freetype, t1lib, gif, jpg, png, wbmp)
I think the zip module I was using was part of pecl. I know pecl is similar to pear, and now that I think about it, I know I'll need pear support too, so if it hasn't already been done, php5-cli and php-pear should now be installed with Synaptic. The reason we need to install php5-cli is because pear is a command-line utility, and requires the command-line version of PHP in order to run. Don't worry: php5-cli and libapache2-mod-php5 peacefully coexist. I opened a shell, typed pear, and there it is!
On a whim, I typed pecl, and it also runs. It looks like pear and pecl come as a pair (no pun intended).
Back to Synaptic, we need to install php5-dev because we will need a tool called phpize in order to complete the next step. php5-dev has several dependencies that it will automatically install.
Now, the magic command:
sudo pecl install zip
When its finished, it will say: You should add "extension=zip.so" to php.ini
cd /etc/php5/apache2
sudo editor php.ini
Do what it says. Add the line extension=zip.so at the very end of the file, because that's where the automatically added extensions (mysql, mysqli, gd) ended up. You may want to also add the same line into the /etc/php5/cli/php.ini so that you have zip support when you use php for shell scripting.
Save your changes and:
sudo apache2 -k graceful
If you look at the phpinfo() output again, you'll now see the zip section near the bottom. This is
really easy.
While we're editing these two ini files, lets search for and change the following lines to these new values:
memory_limit = 16M
post_max_size = 16M
magic_quotes_gpc = Off
upload_max_filesize = 10M
Remember to set these for both /etc/php5/apache2/php.ini and /etc/php5/cli/php.ini
Another tool I sometimes use (if I need to programatically submit a post):
sudo pear install HTTP_Request
Well, I think that's everything I use. Restart apache2 one last time and see if it all works.
Tuesday, December 5, 2006
WAMP to LAMP
I'm starting a series to document my progress on converting a very specialized WAMP server over to a LAMP server.
WAMP = Windows, Apache, MySQL, PHP
LAMP = Linux, etc.
I am going to name this box Pericles (Mostly for the sake of giving it a tag in the blog so that you can read all about its life by clicking Pericles here or on the sidebar.)
To begin with, I want to explain why I was using a WAMP server to begin with. Most people either go all Microsoft or all Open Source. This server was born to fulfill one pressing need: A friend of mine had a website already written in ASP that he needed a new hosting provider for, and neither of us had time to deal with anything as serious as a rewrite at that time. So, we found a neat plug-in for Apache on windows that allowed it to execute ASP code. This worked, and our small Web-hosting business was born.
Fast-forward two years.
We now host around twenty websites on this box, and the need for ASP is gone because the original site has been rewritten in PHP. Furthermore, the specs on that box were outdated when we started, and it is time for a faster CPU. We bought a new system at the Day After Thanksgiving sale and we are now ready to go Open Source.
We've installed Ubuntu 6.10 (Edgy Eft) from the Server disc, and then added the ubuntu-desktop package manually to get a GUI desktop. We need the GUI desktop for a couple of reasons: 1) We're new at administering Linux and it helps us feel a little more confident. 2)
I've developed a few tools over the past two years that handle frequent back-end tasks as Windows applications. I don't have time to port them all at once, so I am going to have to do it piece by piece, thus I will run the unported tools by using Wine in the meantime.
Once I got Edgy booting smoothly and configured for our graphics card (it required a resolution tweak using dpkg-reconfigure xserver-xorg to get it looking correct on our LCD) this is our official starting point.
To follow our ongoing drama, click on the Pericles category/label in the sidebar.
WAMP = Windows, Apache, MySQL, PHP
LAMP = Linux, etc.
I am going to name this box Pericles (Mostly for the sake of giving it a tag in the blog so that you can read all about its life by clicking Pericles here or on the sidebar.)
To begin with, I want to explain why I was using a WAMP server to begin with. Most people either go all Microsoft or all Open Source. This server was born to fulfill one pressing need: A friend of mine had a website already written in ASP that he needed a new hosting provider for, and neither of us had time to deal with anything as serious as a rewrite at that time. So, we found a neat plug-in for Apache on windows that allowed it to execute ASP code. This worked, and our small Web-hosting business was born.
Fast-forward two years.
We now host around twenty websites on this box, and the need for ASP is gone because the original site has been rewritten in PHP. Furthermore, the specs on that box were outdated when we started, and it is time for a faster CPU. We bought a new system at the Day After Thanksgiving sale and we are now ready to go Open Source.
We've installed Ubuntu 6.10 (Edgy Eft) from the Server disc, and then added the ubuntu-desktop package manually to get a GUI desktop. We need the GUI desktop for a couple of reasons: 1) We're new at administering Linux and it helps us feel a little more confident. 2)
I've developed a few tools over the past two years that handle frequent back-end tasks as Windows applications. I don't have time to port them all at once, so I am going to have to do it piece by piece, thus I will run the unported tools by using Wine in the meantime.
Once I got Edgy booting smoothly and configured for our graphics card (it required a resolution tweak using dpkg-reconfigure xserver-xorg to get it looking correct on our LCD) this is our official starting point.
To follow our ongoing drama, click on the Pericles category/label in the sidebar.
Subscribe to:
Posts (Atom)