ServerAdmins.NET » howto

XCache 1.3.0 install – with cPanel and CentOS

chrism — Sat, 26 Jun 2010 04:57:58 +0000

Hey there!

I figure it’s been a little bit, so I’ve gone ahead and decided to update the XCache installer for version 1.3.0, and my favorite control panel, cPanel.

This is incredibly easy to do and should get a basic/barebones XCache installation up and going fairly quickly on your CentOS + cPanel machine.

First, let’s grab our XCache sources…
cd /usr/src/ wget http://xcache.lighttpd.net/pub/Releases/1.3.0/xcache-1.3.0.tar.gz

Now, go ahead and unarchive the source, and change into the XCache build dir…
tar -xzvf xcache-1.3.0.tar.gz cd xcache-1.3.0

Let’s prep our sources for the current PHP ecosystem…
root@SERVER [/usr/src/xcache-1.3.0]# phpize Configuring for: PHP Api Version: 20041225 Zend Module Api No: 20060613 Zend Extension Api No: 220060519

Now that should have gotten everything sorted with our sources so the XCache install is ready for our PHP version and environment, Let’s go ahead and kick off the build! Keep in mind, this build should be fairly fast and lightweight.

./configure && make && make install
The above line basically says “Run configure, if that is successful w/o errors, run a make, and if that finishes w/o error, run the install”. Once this is complete, you should see a line that says something like the following…
Installing shared extensions: /usr/local/lib/php/extensions/no-debug-non-zts-20060613/
This is going to be where our xcache.so file is located, however when cPanel builds your php.ini file, it’s going to have that set already. So getting the base module loaded is as simple as running the following command.
echo "extension=xcache.so" >> /usr/local/lib/php.ini
After that, you should be able to do a quick check of the PHP CLI and verify that it loaded properly with the ‘php -v’ command…
root@SERVER [/usr/src/xcache-1.3.0]# php -v PHP 5.2.13 (cli) (built: Jun 16 2010 09:27:33) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies with XCache v1.3.0, Copyright (c) 2005-2009, by mOo

And there you go, you can safely restart Apache now and you should be serving cached content. Please keep in mind, you’ll need to configure your XCache setup to ensure everything is working properly, all we’ve done here is install the base module.

I’d suggest taking a look at our other article regarding the tuning of XCache for a bit more information on this.

That does it for now!

Howto show the current runlevel in linux…

chrism — Fri, 28 May 2010 12:51:17 +0000

Quick one here, mostly for my own notes than anything else.

An easy way to see the existing runlevel is with the ‘who -r’ command.

root@server:~ # who -r run-level 3 May 22 03:54 last=S

Here we show the last boot and current runlevel (3). In order to modify this, you can open up /etc/inittab and look for the following line.

id:3:initdefault:

This shows that runlevel 3 is the default one kicked off by init on a bootup.

For what it’s worth, this refers to the directories in /etc/rc.d/rcX.d/, where X is #. The number correlates to the runlevel of your machine, and all of the scripts stored in that directory are executed when that runlevel is enabled.

TMYK!

Howto enable CGI in the builtin OSX webserver

chrism — Sat, 15 May 2010 00:24:13 +0000

Recently I’ve caught myself writing more code on my Macbook and for the first time in… YEARS, not needing an internet connection to actually be productive. To be quite honest, it’s a bit weird.

So, the first thing I wanted was the ability to run/exec CGI via a webserver. At first, I was thinking I’d go about a source build of Apache, and then I remembered OSX comes with one built in. Huzzah!

So, first let’s enable the builtin webserver.

System Preferences -> Sharing, and then click on “Web Sharing”. Go ahead and close out the window now, you’ve just fired off Apache. (hooray!). You should now be able to open your browser of choice and go to http://127.0.0.1/~

Now, the document root is going to be off of your user account in /sites/. My user is chrismm on my machine, so /Users/chrismm/Sites/ is my public HTML. Any web content you want to view with the above URL needs to go off of this directory. Go ahead and add the obligatory "Helloworld.html", I'll wait.

Now that that's done and functioning, I needed to get some hawt hawt Perl/CGI action going on. This, was incredibly easy.

OSX's main httpd.conf does a per-user http include in /private/etc/apache2/users/.conf, so once again for me, it was /private/etc/apache2/users/chrismm.conf. This file contains just a super basic Directory configuration for apache to parse and we only need to make one quick change here…

First and foremost, we need to be the root user, so go ahead and open up Terminal (Finder->Applications->Utilities -> Terminal), and type ‘sudo su -’ . Here, you’ll be prompted to enter your password.

Keep in mind as soon as you do this, you are the root user on your machine, ***BE VERY CAREFUL AS IF YOU ARE NOT YOU CAN END UP WITH A WORTHLESS WORKSTATION ***.

Now, go ahead and open up the include for your user, at /private/etc/apache2/users/.conf, and make the following changes.

Original:
maynard:beta root# cat /private/etc/apache2/users/chrismm.conf Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all


Needs to be changed to....

maynard:beta root# cat /private/etc/apache2/users/chrismm.conf Options Indexes MultiViews ExecCGI AllowOverride None Order allow,deny Allow from all

See that? All I added was “ExecCGI” at the end of that Options statement. We’re halfway done now!

One more change…

Go ahead and open up ‘/private/etc/apache2/original/httpd.conf’ in your text editor of choice, and search for ” #AddHandler cgi-script .cgi”

Go ahead and remove the ‘#’ mark, save and exit.

Now, let’s restart the webserver…

killall -HUP httpd

Done!

And now, you can use your CGI and be happy.

Updating the FreeBSD Ports tree, easily…

chrism — Thu, 28 Jan 2010 01:18:00 +0000

I’m feeling a bit lazy tonight, and wanted to get an update here, so for a bit I’ll show you a handy little tool to update your ports tree on FreeBSD. After that, I’ll show you the ugly, old method.

Quick and easy…

Newer versions of FreeBSD come equipped with the ‘portsnap’ utility. This, makes it *VERY* simple to update your ports tree.

For your first run, do this…
portsnap fetch && portsnap extract

This is going to grab a snapshot of the current ports tree, and simply extract it over your new tree, replacing *everything* as it goes. You should only run the ‘extract’ command the first time you run portsnap.

After that, you’ll want to run the following for any further updates…

portsnap fetch && portsnap update

Not only is this much quicker, it doesn’t overwrite everything.

If you want to use this in a cron’d task, you should use the ‘portsnap cron 1′ command. It should be noted the number appended to the end of this is the number in seconds that portsnap will randomize the start of the app from. For example, if you say ‘cron 2000′, portsnap will kick off *sometime* in the next 2000 seconds. The reasoning for this is for larger serverfarms. If you’re running that in cron on all of them and give portsnap a large window, it will keep them all from starting at the same time, loading the BSD servers and abusing your bandwidth. I used 1 in the command above as I wasn’t really looking to use that. Keep in mind this will only fetch the updates, you still need to update the tree afterwords…

A cron entry for this would look something like the following…

0 3 * * * root /usr/sbin/portsnap cron && /usr/sbin/portsnap update

So for normal, day to day operation once you’ve initialized your ports tree the following is what you’ll want to use and update.

/usr/sbin/portsnap fetch && /usr/sbin/portsnap update

Now, if you don’t have portsnap, you should use the following method to update your ports tree. We’re going to go oldschool with cvsup here.

Edit: From reader Bazzoola points out that this is outdated and antiquated and well, he’s 100% right. Any current installations of FreeBSD should have the portsnap utility installed so this shouldn’t be necessary. Consider it here for the sake of memories.

First of all, let’s find our fastest cvsup mirror…

[root@R34 ~]# cd /usr/ports/sysutils/fastest_cvsup/ [root@R34 /usr/ports/sysutils/fastest_cvsup]# make && make install

This is going to install the ‘fastest_cvsup’ port… Afterwords, for the US locale, you can run the following to find your fastest cvsup mirror…

[root@R34 /usr/ports/sysutils/fastest_cvsup]# fastest_cvsup -c us >> Querying servers in countries: us --> Connecting to cvsup.us.freebsd.org [72.233.193.64]... - server replied: ! Access limit exceeded; try again later - time taken: 69.51 ms --> Connecting to cvsup2.us.freebsd.org [130.94.149.166]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 27.19 ms --> Connecting to cvsup3.us.freebsd.org [128.31.0.28]... - server replied: ! Access denied - time taken: 31.65 ms --> Connecting to cvsup4.us.freebsd.org [149.20.64.73]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 55.77 ms --> Connecting to cvsup5.us.freebsd.org [208.83.20.166]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 36.99 ms --> Connecting to cvsup6.us.freebsd.org [64.202.113.190]... * error: connect: Invalid argument --> Connecting to cvsup7.us.freebsd.org [64.215.216.140]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 26.64 ms --> Connecting to cvsup8.us.freebsd.org [216.165.129.134]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 6.23 ms --> Connecting to cvsup9.us.freebsd.org [128.205.32.21]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 26.28 ms --> Connecting to cvsup10.us.freebsd.org [69.147.83.48]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 54.01 ms --> Connecting to cvsup11.us.freebsd.org [63.87.62.77]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 35.11 ms --> Connecting to cvsup12.us.freebsd.org [128.205.32.24]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 26.86 ms --> Connecting to cvsup13.us.freebsd.org [128.205.32.24]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 26.54 ms --> Connecting to cvsup14.us.freebsd.org [216.87.78.137]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 34.63 ms --> Connecting to cvsup15.us.freebsd.org [35.9.37.225]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 23.49 ms --> Connecting to cvsup16.us.freebsd.org [128.143.108.35]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 23.47 ms --> Connecting to cvsup17.us.freebsd.org [65.212.71.21]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 35.93 ms --> Connecting to cvsup18.us.freebsd.org [128.205.32.84]... - server replied: OK 17 0 SNAP_16_1h CVSup server ready - time taken: 3026.06 ms

>> Speed Daemons: - 1st: cvsup8.us.freebsd.org 6.23 ms - 2st: cvsup16.us.freebsd.org 23.47 ms - 3st: cvsup15.us.freebsd.org 23.49 ms [root@R34 /usr/ports/sysutils/fastest_cvsup]#

Cvsup8 it is!

So now, let’s get our ports-supfile in place…

cp /usr/share/examples/cvsup/ports-supfile /root/

Now edit /root/ports-supfile and look for the following line…

*default host=CHANGE_THIS.FreeBSD.org

And modify it to read…
*default host=csup8.freebsd.org

Now, run the following to get *everything* up to date…

cvsup -g -L 2 /root/ports-supfile

Voila, you have an updated ports tree.