Archive for the ‘Web’ Category

Mosso Hosting gets Rave Review from Sys Admin

Thursday, September 25th, 2008

Mosso, the Cloud Hosting offering from market-leading hosting provider Rackspace, has received a rave review about their on-the-fly scalability under load.

Mosso is a hosting platform that allows you to be flexible with your configuration. Their Linux offering includes PHP 4 & 5, MySQL 4 & 5, Ruby on Rails, Perl, and Python technologies for building your application. Their cloud is, from their website, “an advanced, enterprise-level hosting platform that beats the pants off of running your own servers - and scales easier, too.”

The platform is easy on the budget, too. I’d rather not talk numbers here, so, contact Mosso for more information!

/cs

Configuring Simple Virtual FTP Users in vsftpd using PAM

Tuesday, July 29th, 2008

This tutorial will set up a basic virtual user config for vsftpd on a RHEL5-based system.  I recommend that you make backups of existing config files before implementing this solution, in case you need to revert.  This allows virtual “guest” users to log in with individual usernames and passwords and have access to a base directory.

I suggest building the initial files in a directory of their own first, and the steps below outline copying the files into place.

Six simple steps:

Step 1: Create the virtual user database.

Create a text file with each username/password pair on two lines, i.e:

# cat /etc/logins.txt
username
password
username2
password2

Then, use BerkleyDB to has the file, and change its permissions:

# db_load -T -t hash -f logins.txt /etc/vsftpd_login.db
# chmod 600 /etc/vsftpd_login.db

Step 2: Create a PAM file which uses your new database.

# cat > vsftpd.pam
auth required /lib/security/pam_userdb.so db=/etc/vsftpd_login
account required /lib/security/pam_userdb.so db=/etc/vsftpd_login

# cp vsftpd.pam /etc/pam.d/vsftpd

Step 3: Set up the location of the files for the virtual users by creating a “wrapper user”.

# useradd -d /home/ftpsite virtual

Step 4: Create your vsftpd.conf config file.

# cat > vsftpd.virtusr.conf
anonymous_enable=NO
local_enable=YES
write_enable=NO    # change to YES if you want uploads available
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
chroot_local_user=YES
guest_enable=YES
guest_username=virtual
listen=YES
listen_port=10021    # optional
pasv_min_port=30000    # optional
pasv_max_port=30999    # optional

# cp /etc/vsftpd.conf /etc/vsftpd.conf.orig
# cp vsftpd.virtusr.conf /etc/vsftpd.conf

Step 5: Restart vsftpd.

# /etc/init.d/vsftpd restart

Step 6: Test.  I think you can figure this one out on your own.

Hold on to the logins.txt file, and simply update it and rebuild the DB when you need to add a user.  This allows several users access to the same directory and files.  Only give access to people you trust.

/cs

Goosh.org - What more could you want?

Wednesday, June 4th, 2008

I have found search engine heaven in the form of Goosh.org.

Basically, it is a UNIX-shell-styled google page, that returns listings to the “standard output” of the page.

The Goosh, or Google Shell

The beauty of it is that Google’s page has always been so simple and elegant, but Goosh takes these to the next level, making searching the web as easy as administering a Linux server, uh, sort of.

There are simple shell-like commands that you can use to manipulate the search in different ways:

web [keywords] - google web search (default if no command given)
images [keywords] - google images search
wiki [keywords] - Wikipedia search
news [keywords] - google news search
blogs [keywords] - google blog search
feeds [keywords] - google feed search
video [keywords] - google video search
place [keywords] - google maps search
translate [lang1] [lang2] <words> - goog
le translation

Those commands are modes, and you can use the “cd” command to change the default behaviour.  So, if you need a translator, simply type:

Sample of site content

cd translate

and you have a nice translator.

Other commands available include:

open <url> - open a URL in a new page
in (site) [keywords] - in-site searches
lucky [keywords] - the “Feelin’ Lucky” button

The best part, though, is this command:

addengine

This command adds Goosh to Firefox (or Icecat, in my case!) so that you can use it as your default search engine!  A simple Ctrl-K will put me in the search box, and Alt-Enter opens the results in a new tab.

I think this will be a great addition to the Google Application Suite someday, kind of like a Crazy Uncle Ned or something!

/cs

Flash and Java plugins in Icecat

Friday, May 30th, 2008

So, I needed a flash and a java plugin for Icecat, once I got it installed.

On Ubuntu, installing the Flash player is easy:

$ sudo apt-get install flashplugin-nonfree

What’s not so easy is getting Icecat to use it.

I installed Icecat in /usr/local/src, and symlinked “icecat” to the actual directory. So, my Icecat plugins are in /usr/local/src/icecat/plugins. Here’s how I linked the flash plugin in:

$ cd /usr/local/src/icecat/plugins
$ ln -s /usr/lib/flashplugin-nonfree/libflashplayer.so libflashplayer.so

I did this while Icecat was running, and immediately had flash capability. I confirmed by typing “about:plugins” into the URL box.

Visiting \

For the Java plugin, I downloaded j2se 1.4 (which is EoL’d, by the way!!) from here:

http://java.sun.com/j2se/1.4.2/index.jsp

In much the same fashion, I cd’d to /usr/local/src, and moved the binary there. I ran this:

$ sudo sh j2re-1_4_2_18-linux-i586.bin

to extract the files. Then I ran the following commands:

$ sudo ln -s j2re1.4.2_18 java
$ cd /usr/local/src/icecat/plugins/
$ sudo ln -s /usr/local/src/java/plugin/i386/ns610-gcc32/libjavaplugin_oji.so libjavaplugin_oji.so

Keep in mind that this is for my previous icecat install.  For firefox, the plugin will go in /usr/lib/firefox-3.0/plugins, and for Iceweasel on Debian, it will go in /usr/lib/iceweasel/plugins.

This was also done while Icecat was running, without issue. Now, I can surf Hulu and YouTube and play java applet games at work! Shh, don’t tell!

/cs

Need FF2 in Hardy? Try GNU’s IceCat.

Friday, April 18th, 2008

OK, so I have a special requirement for using Firefox 2. However, I run Hardy, and it has a default install of (i can’t believe it) the BETA version of Firefox 3.0b5. Golly.

So, I tried installing the firefox2 package from the Ubuntu repos, and had issues with some of the addons I use. I tried the “binary” tarball from the Firefox website. No go - it still wants to revert to FF3. As any seasoned Ubuntu user knows, don’t eff with Ubuntu. Going around making things work can sometimes cause problems with things, well, working.

THe Fox and the CatAfter some research, I found IceCat.

IceCat is “the GNU version of the Firefox browser.” Basically, the GNU guys took Mozilla’s code, and compiled it without using the “proprietary” parts, meaning the Logo and the name, among other things.

So, I downloaded the IceCat tarball. I unpacked it, expecting it to whigh out on me, as the Firefox tarball did, and low and behold! Right there next to my FF3 window was IceCat 2.0.0.13, running at the same time!

I figured it had to be too good to be true, and went about installing my needed Firefox extensions. AND THEY WORKED! HooRAH!

So, needless to say, I’m sold on IceCat as a GREAT replacement/addendum to Firefox. Get it. Use it. Love it.

/cs

Superbugs and You

Sunday, April 13th, 2008

So, I read an article that is both sensical and scary:

Flaming Mountainside: Breeding Internet Superbugs

I get a LOT of junk mail in my USPS mailbox in front of my house, and I pretty much ignore it, as long as it doesn’t look terribly important. It goes right into the trash.

I have to agree with vixie in the above article; the issue is not being solved, just pushed away.

In the Linux Admin world, currently, in order to have a mail server that will send to Yahoo! and AOL, among others, you already have to jump through plenty of hoops:

These are just a few things to try, and still, the spam keeps flowing, because the spammer has a need to get his message through.  I suppose I could try Spamassassin or Postini.  Some companies even offer to manage the spam problem for you (and they do a pretty darn good job of it, too!).

As the old saying goes, “Necessity is the mother of invention.” Continuing to “fix” the spam issue will cause the number of spammers fluent in loopholes to exceed the number of hackers available to fix the problem.

All in all, how do we fix the spam issue? The same way we fix the junk mail issue: The delete key.

/cs

Addons in Firefox3 (at your own risk!)

Monday, March 10th, 2008

Ooh, I installed Ubuntu’s beta, the Hardy Heron, and I was unthrilled to find that they are including a BETA version of Firefox as the default browser.

Who knows, maybe it’ll be official by April, but for now, it’s still BETA!

I use a few plugins for various things, and was equally unthrilled to find that none of the were compatible with FF3.  Unthrilled, but not completely unsurprised.  The same issue happened when they release FF2 some time ago.

So, I found a way to fix it.

AboutConfig.png

In the Address Bar, type “about:config”.  This will prompt you (which I laughed at) that it might “void your warranty”.  Right click on a blank space, and click New->Boolean.  Enter the value string “extensions.checkCompatibility” and select “false” for the boolean value.

CreatedConfigValue.png

Restart FF, and voila!  I was able to successfully use the ShowIP and Signature plugins, which I use quite regularly.

I am now happy.  :)

/cs

Create a Self-Signed Cert with OpenSSL

Sunday, February 17th, 2008

Every once in a while, the need arises for a certificate without the exorbitant price tag that comes with Thawte or Verisign. Of course, those outfits will give you a certificate that matches the CA certs built in to common browsers like Firefox and Safari. Or IE. But I don’t like IE. But for a personal email account over SSL or for an admin site for your company, why not create a self-signed certificate?

Using openssl one can do a multitude of cool things, including creating your own self-signed certificate.

Here’s an example of using a self-signed cert for web content.

For the exercises presented here, you’ll need access to the following:

  1. An Apache Webserver. It will match the configuration options I have presented here.
  2. A domain name. Just an example.com in your hosts file will work, or visit Network Solutions to purchase one.
  3. Access to the command line on the server that has your Apache install, with appropriate permissions to edit the configuration.

For my examples, I will be running Red Hat Enterprise Linux 4 (Update 6) and Red Hat’s Apache version for the implementation, and will be running Ubuntu 7.04 Desktop for some of the command examples. Typically, there shouldn’t be much difference in the commands run, but the implementation can vary from distro to distro. Ubuntu and Debian’s stock Apache implementations and configuration are very complex compared to Red Hat’s.

Once you have the requisites taken care of, then let’s get a little familiar with the openssl command.

Open up two terminals, and issue the following command:

$ openssl req -x509 -days 365 -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcert.pem

Press enter. You’ll see that this will spit out a LOT of information. To sum up, it basically says “Please tell me some information.” You’ll be prompted for the following information:

  • Country Name (2 letter code)
  • State or Province Name (full name)
  • Locality Name (eg, city)
  • Organization Name (eg, company)
  • Organizational Unit Name (eg, section)
  • Common Name (eg, YOUR name)
  • Email Address

Some key things to note are that the state should be fully typed out, ie, Texas, not TX. Also, the Common Name is the name of the URL that will be using the certificate, such as secure,ozymo.com.

This will create a hostcert.pem and hostkey.pem file containing the certificate and the ke, respectively:

$ ls -lah *.pem
-rw-r–r– 1 chuck chuck 1.4K 2008-02-17 15:09 hostcert.pem
-rw-r–r– 1 chuck chuck 891 2008-02-17 15:09 hostkey.pem

OK - so, we have our certificate and key now. Let’s give them a couple tests to make sure they work properly.

In the same terminal we just used, let’s issue these two commands to test continuity between the cert and the key:

$ openssl x509 -in hostcert.pem -noout -modulus
$ openssl rsa -in hostkey.pem -noout -modulus

These commands will spit out a modulus of the cert and key, and if they are the same, then the cert and the key match. If they differ, something has gone terribly wrong.

Another test we can set up includes creating a test server and test client, and this is where that other terminal you opened comes in. In the first terminal, which we have been using, issue the following command:

$ openssl s_server -accept 9000 -cert hostcert.pem -key hostkey.pem

This command will be followed by some output and the word “ACCEPT”. This means it is listening on port 9000. Now go to the other terminal, and run the following command as root or with sudo:

$ sudo netstat -ntpl | grep :9000
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 1668/openssl

As you can see, the server is listening. In the other terminal, run this command to make a connection. I have included some of the output, as I really wanted to illustrate only two key points in this example:

$ openssl s_client -connect localhost:9000 -CApath /etc/grid-security/certificates | grep handshake
depth=0 /C=US/ST=Texas/L=XXXXXX XXXX/O=The PiRS Network/OU=ozymo.com/CN=www.ozymo.com/emailAddress=chuckstearns@ozymo.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Texas/L=XXXXXX XXXX/O=The PiRS Network/OU=ozymo.com/CN=www.ozymo.com/emailAddress=chuckstearns@ozymo.com
verify return:1
SSL handshake has read 1414 bytes and written 252 bytes

As you can see on line three of the ouput, there was a verification error because we have a self-signed certificate, but, on line 8, you can see that the SSL handshake was indeed successful.

So, let’s get this configured in an Apache vhost so that we can have secure, encrypted content. Sounds like fun, right?

First, you will need to upload the certificate. Do this in whichever manner suits you. I used scp.

Log into your server via SSH. Open the Apache configuration file in which your SSL vhosts reside. Add the following lines to enable the certificate we just created:

SSLEngine On
SSLCertificateFile /path/to/hostcert.pem
SSLCertificateKeyFile /path/to/kostkey.pem

I leave the rest of the configuration up to you, as it is your server.

Now, all that has to be done is to restart Apache, and visit the common name you used in the cert with the prefix https://

Remember that you will receive a cert error, because it it self-signed and not registered with any CA. Maybe we’ll cover creating a CA in a later entry.

/cs

Client-side mailto: Link Encoding in HTML Pages

Wednesday, January 30th, 2008

This always seems to be a sore subject among webmasters, and I have seen some quite silly contrived solutions:

  • addy@DELETE_THISdomain.com
  • mayemail @ mydomain com
  • Please contact us for contact information

To me, these seem very creative (except for the last one which was really kind of a joke).

I have found and implemented a solution on my server that seems to work very well for eluding this issue. It’s a little piece of javascript I like to call menc.js.

(more…)