ServerAdmins.NET

So if you’re ever connected to a remote machine (or several), and you frequently see this message after you walk away from your term for a bit…


Write failed: Broken pipe


Do this from the machine you’re connecting from. SSHD for Macs/Linux boxes should all have this file. Windows, I’m not so much sure on.

(if not root already)

sudo echo "ServerAliveInterval 5" >> /etc/ssh_config


Or just open it up in your favorite text editor, save and call it good.

What’s happening here is that somewhere between you and your destination, there’s a long enough of a timeout happening that you hit SSHs internal timeout. This line just forces your SSH client to send a keepalive pulse fairly regularly to the endpoint.

Anyway, dumb quick fix to what ails so many of is.

This took me awhile to figure out today, so I figure it’s worth a post (and we all know I’m WAAAY behind on those!).

The problem I ran into was with an OpenStack (diablo build) instance that we use internally at my work. To make a long story short, I chose to go around the nova-network method of routing and use my own hardware gateway as opposed to using the software appliance provided by the OpenStack setup.

Now, a brief bit of Background here.

1. Openstack is a “Virtualization Fabric”, i.e., a piece of software that ties together hypervisors with a nice API. It handles the networking, connection to the hypervisors, sercurity and let’s you access everything with an API. This is the same software that the Rackspace Cloud is setup and comparable to what VPS.Net uses (onapp.com).

2. Openstack is comprised of components, nova-network handles the networking, routing and firewalling. Nova-api handles the API calls. Nova-scheduler handles all the scheduling. Nova-compute actually interfaces with the hypervisors and creates/manages the VMs with nova-volume providing an EBS style of volume provisioning.

3. When you provision a VM, it automatically routes through the machine you’ve designated to run nova-network, I didn’t like this.

So, I decided to change how the networking on the VMs routes to the public internet. There’s a service called ‘dnsmasq’ that runs on the nova-network machine which hands out IP and basic configuration information to your VMs when they come up. It gives your VMs their IP, Gateway, subnet mask, resolvers and a few other items as well. So here’s, where things needed to change.

Step 1. Know your real network gateway!

Traditionally in an openstack setup, your VMs will route like this…

VM->Nova-network appliance->network gateway->Internet.

I was modifying it to route as follows…

VM->Network Gateway->Internet.

This is handled by adding one line to your nova.conf file, and creating a super basic configuation file to go along with it. By adding ‘–dnsmasq_config_file=/etc/nova/dnsmasq.conf’ to your nova.conf file, and ensuring that /etc/nova/dnsmasq.conf looks like the following snippet, you’ll 1. route through your own gateway, and 2. use your own resolvers.

—-
dhcp-option=6,10.1.100.254
dhcp-option=3,10.1.100.254
—-

dhcp-option 6 should be set to the resolver you want to use, and dhcp-option 3 should be set to the gateway you want to use.

After that, do a ‘killall dnsmasq; /etc/init.d/nova-network restart’, and then restart your instances and you should be good to go!

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.

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




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.