First we need to get the latest build of Ruby Enterprise Edition (Ruby EE from now on) from http://www.rubyenterpriseedition.com
This is the latest at the time of this writing. Check the website for the most recent and just check your version numbers in the next steps.
Now we need to extract the source
$ wget http://rubyforge.org/frs/download.php/68719/ruby-enterprise-1.8.7-2010.01.tar.gz
Now we can start the install
$ tar xzvf ruby-enterprise-1.8.7-2010.01.tar.gz
The installer will auto check for dependencies like the C Compiler, the make tool, OpenSSL, etc. If you’re missing any of these it will show you the command to run which is a simple
$ sudo ./ruby-enterprise-1.8.7-2010.01/installer
After we pass the checks, we can start the install. It will ask for the “Target directory” we would like to install RubyEE in. By default it’s /opt/ruby-enterprise-X.X.X-XXXX.XX I change mine to simply be /opt/ruby-enterprise which makes upgrades a bit easier.
Now you’ll see a lot of output on the screen as it installs RubyEE. You may also notice that the installer will install some useful libraries such as Rails, Passenger etc.
Now if you type
$ sudo yum install OpenSSL
You’ll probably get A: no ruby in (/some/directories/) or B: The path to your original install of ruby on your machine. To fix this we will set the path up in /etc/profile.d/ruby.sh
Open that file in your favorite editor, or create it if it doesn’t exist with
$ which ruby
Inside that file add
$ sudo nano /etc/profile.d/ruby.sh
Then reload the profile by running
export PATH=/opt/ruby-enterprise/bin:${PATH}
Now if you run which ruby it will find it. You can also do
$ source /etc/profile
which should return something like
$ ruby -v
You are now done! Now you can install gems under the RubyEE version just by calling the gem command and not the full path of /opt/ruby-enterprise
My next article will be on installing, configuring, and using Passenger.
ruby 1.8.7 (2009-12-24 patchlevel 248) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2010.01
Sometimes your want to make your IP address to point to somewhere other than the host it’s currently point to. The way Apache works is that it loads vhosts in order number-alpahbetically. So when I created “adminnoob.conf” as my new config my IP now pointed to adminnoob.com. This is an easy fix. In my httpd.conf I load all my vhosts like so:
But again apache decides the order. In order to change this, all we need to do is create a new conf called something like 000_default.conf. That will load first and point to wherever you want!# Loads all vhosts
Include conf/vhosts/*.conf
When you’re working at the airport or coffee shop, you should never trust their wifi to provide secure wireless internet. Especially if you plan to visit secure sites such as banks, server control panel, etc. You never know who might be at there with you. In this case you should tunnel your traffic through ssh. To do this, simply start a new session in your terminal.
First we need to connect to our server and we are going to create a SOCKS Proxy
Now we need to configure our connection to use our newly created SOCKS Proxy. We’re going to use 127.0.0.1:8080 I took a screen shot of how mine looks.
$ ssh admin@172.17.2.88 -D 8080
Now you’re set! If you visit something like http://ipmonkey.com you should see the IP address of the server you’re connected to.
So recently I ran into an issue where our backup script would only work properly when we ran it manually. That’s another story. However to try and catch what was wrong with the cron job we had to figure out a way to log what was happening. So what I did was the following on a CentOS machine. I opened the crontab file /etc/crontab and inside there you have four jobs that run at different times:
I was running the script under cron.daily so that’s what I wanted to log to see what was happening. So I appended this:
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
so you get:
> /home/admin/s3sync/backup.log
Which will output the results of your cron job to a backup.log text file. The single02 4 * * * root run-parts /etc/cron.daily >> /var/log/backup.log
One of the most secure things you can do to your server is to disable password logins. You should always disable root login. The first thing you need to do is locally retrieve or create your public ssh key. To see if you have one already created check in this location. On a Mac it’s
If that files is created then you’re set, if not then do the following.
~/.ssh/id_dsa.pub
The passphrase part is optional, if you’re not the only person that uses that particular machine I would strongly suggest you provide a passphrase.
Now that you have or created a ssh key we need to add that key to our server. We can do this with one command. Keep in mind that if you are adding a key then that is another command. You don’t want to replace other people’s key on the server.
$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/user/.ssh/id_rsa.
Your public key has been saved in /Users/user/.ssh/id_rsa.pub.
The key fingerprint is:
01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db user@localhost
The key's randomart image is:
--[ RSA 2048]----
| . |
| = o O . |
| = * * |
| o = |
| o S . |
| o o = |
| o . E |
| |
| |
-----------------
If you need to append your public key to that file then you will have to do something like this:
$ scp .ssh/id_rsa.pub user@domain.com:.ssh/authorized_keys
Now you can login to your server without a password! (Unless you chose a passphrase) Please leave a comment if I missed something, or if something doesn’t work.$ cat ~/.ssh/id_rsa.pub | ssh user@domain.com "cat >> .ssh/authorized_keys"
