SSH Client Configuration

I have a VPS which is host to many websites. Some of those sites are permitted ssh access for their admins. However I am the admin to several sites myself. Each site has a different username (login/password) for administration. Additionally I have changed the ssh port to a different number (instead of the default 22) to avoid some script/bot attacks.

All of this makes for very inconvenient ssh usage and plenty of typing errors. For example:

# ssh -p33333 username_site1@site1domain.com
# ssh -p33333 username_site2@site2domain.net

Fortunately ssh provides a client configuration file to make “shortcuts” for things like this.
If you start by reading the ssh_config man page:

# man ssh_config

It will reveal 4 useful options:

  • Host – A “shortcut” name which can be used instead of the full hostname address.
  • Hostname – The real host name which is the actual server to log into.
  • Port – Port number on the host server.
  • User – The username used to log in. Typically ssh will use the current unix username if not specified.

So using the above example. I created the the file: ~/.ssh/config:

[mirandam@atlas ~]$ cd .ssh
[mirandam@atlas .ssh]$ touch config

with the following contents:

Host site1
Hostname site1domain.com
Port 33333
User username_site1

Host site2
Hostname site2domain.net
Port 33333
User username_site2

Now I can ssh to either site with a simpler command. These do exactly the same as the previous ssh commands:

# ssh site1
# ssh site2

NOTE: Read the man page carefully. If you see the following error:

Bad owner or permissions on /home/mirandam/.ssh/config

This means you did not properly set the permissions on the config file. To fix:

# chmod 600 ~/.ssh/config

There are many other options in the config file for users who might have more specific options (X11 Forwarding, Timeouts, Compression, etc.).
For anyone with multiple ssh accounts on different servers, this is very convenient to implement. Note this also works for scp and sftp.

Google Apps for Domains

I spend way too much time and effort tweaking my SpamAssassin settings on my server just so I can get my email and spam situation manageable.

Anyways, I’m getting sick of the trouble so I am trying out Google Apps for Domains. This allows me to use my own domain name, but using Gmail for email and other Google web based applications (such as “Docs” and “Calendar”) all for free. It is basically the whole set of Google applications made to work from your own domain. The best part is that it can be configured to work without interfering with your actual website. So you can still run your blog, web page or forum.

There are some significant benefits since Google is managing a lot of the software on their side.

Email
In Gmail I can create easily email address aliases or use “subadressing” without messing with things like CPanel or Exim. This is very useful for mailing lists among other things.

Calendar
Even though Google Apps was designed for multiple users, it is just affective for a single user. The Calendar feature can be used online or it can be made to work with desktop applications like Evolution.

Setup
If you want to use this free service, all you need is a domain name (you don’t necessarily need hosting). I was a bit hesitant to mess my main server, so I decided use my unused mjmwired.com which I have through 1and1. Google does a very good job providing information for configurations through some of the most popular domain name providers. Using 1and1 config options, I can redirect subdomains such as mail.mjmwired.com directly to the Gmail login for my domain.

Google Apps for Domains can be used for individuals or even communities or groups (of up to 50 people) for free. The enterprise options provide even more features (at a cost). If you ever considered trying it out, it is not too expensive to get a $7 domain name and the setup takes merely a few hours.

So far I’ve found it quite convenient, and I might migrate further to Google Apps in the future. Even though I too have my reservations about Google’s Privacy issues, this feature is too nice to ignore.

Should I Migrate to PHP5?

I noted some sites started pushing to PHP5 with the announcement last year that PHP4 would be EOL (end-of-life) in 2007. In truth I understand that there is no longer a compelling reason to remain with PHP4. The biggest obstacle was older software that did not support PHP5 (since version 5 is incompatible with version 4 in some respects). However there is no reason why most of that software cannot be updated, and if so I am pretty sure that some alternate version 5 compatible software exists. I also read some claims that in simpler configurations PHP4 could be faster/less memory than PHP5. I don’t know if that’s true or not. Finally the biggest problem: most web hosting providers are content with PHP4 meeting all their needs and have no reason to upgrade. I do agree to this in some ways.

My biggest problems with PHP in general are its very poor track record for security, its flaws in design/configuration and finally it’s tendency to break software on updates. In some ways: its just a nuisance to maintain!!! PHP4 will be supported for critical security issues till 2008-08-08 by the PHP developers. However being open source there is no reason why someone else could not support it after that. Redhat Enterprise Linux still supports a PHP 4.3.9 package. I was supporting a 4.3.11 package for Fedora which I updated last in 2007 for Fedora 7. However I only installed it on my personal web server on a development box. I guess it would be really easy to finally abandon supporting old packages and just move to version 5, however I don’t know the effect it may have on my public server with a dozen or so websites.

For now I will set a deadline for myself to migrate to PHP5 by the August deadline. However for the time being, if people would find it useful I am considering repackaging the RHEL PHP 4.3.9 for Fedora 8. My 4.3.11 package is greatly out of date. On my development server, I’ll just go ahead and install the PHP5.2 included in Fedora 8. That will be my testing ground for my server updates coming soon.

Realistically in the long run I should just slowly stop using PHP altogether, given that PHP6 will be another mess very soon. Perhaps I will look into Python or J2EE options, not sure yet.

PHP4 on Fedora Core 6

The need for PHP4 has not changed much since Fedora Core 5 (FC5). Hence I have taken the time to update the SRC.RPM that I had originally distributed for FC5 to support Fedora Core 6 (FC6). Included are several security updates as well. FC5 users who used this file previously should update.

The updated source RPM package is provided on the following guide:

PHP4 on Fedora Core 6

Steps provided should work for FC6, FC5 as well as FC4. Although no testing was done for FC4. There are some precompiled binary RPM’s provided as well. (The binaries MAY be out of date.)

As always, these have only minimal testing by myself. Furthermore, please take care when using these files on production servers.

PHP4 on Fedora Core 5 x86_64

I do not know how many people require PHP4 on Fedora Core 5. However since I find that I use it, I am providing PHP4 binary RPMs.

Since I made the files available I did receive some complaints. Primarily a compile failure on x86_64 architecture and a compile failure on PPC architecture. I have no means to test PPC, however I have tested with x86_64 and had success.

For x86_64 architecture, I have tested the src.rpm against the default FC5 rpm’s and the latest updated rpm’s (as of 08 July 2006), both work without problem.

PHP4 on Fedora Core

SpamAssassin Failure

SpamAssassin is a free tool for mailservers to identify SPAM. It has a several parameters it checks (forged headers, HTML only content, blacklisted hosts, improper mail relays, etc) and assigns a score for every parameter. If the total score is greater than the threshold, it is marked as spam and either tagged, moved to a separate mailbox or deleted. I started using SpamAssassin in April of 2005 and it has caught thousands of messages. I know this isn’t large, but it made my inbox manageable.

Originally I set the threshold at 5 however this still lead to several messages a day. So I kept reducing the score, by 0.1 till I stopped at 4.5 and I only had 1 spam message every 3-4 days. I was completely satisified even though an occasional non-spam did get improperly marked (usually an SMS from a cell phone).

As of June 15, SpamAssassin has failed me. I am getting dozens of junk mail passing into my inbox daily. I am seeing scores of 3, 0 and even -0.7. Either the spammers got smart or the scores are not properly being assigned. I am using the latest version SpamAssassin 3.1.3 and I haven’t changed any options.

I may have to investigate further with my hosting provider. But I am curious if anyone else seen this?

PHP4 on Fedora Core 5

Apparently some developers still require PHP4 on their web servers. The previous method for doing so on Fedora Core 4 (FC4) was to use the FC3 RPM’s. (A formal procedure was provided by the guide: PHP4 on FC4.)

Since the release of FC5, the dependancies and outdated linking from the FC3 RPM packages may be difficult to resolve. It is recommended to recompile the PHP4 SRC.RPM and link it to the running software provided in FC5. However, there are some needed changes to the SRC.RPM. There is a modified source RPM package provided on the following guide:

PHP4 on Fedora Core

Steps provided should work for FC5 as well as FC4. There are some precompiled binary RPM’s provided as well.

These have only been tested by myself. I would appreciate it if anyone can report as to how well these work!

The VPS Search

After using shared hosting services on Linux servers for the past few years, I was thinking about experimenting with a VPS (virtual private servers). Currently shared hosting services are highly competitive. If you shop around you can find great deals to host a simple website most with a comprehensive feature set. However these are all very limited. My basis for a VPS was to acquire a server that had room to grow but yet more manageable and more affordable than a dedicated server. These were some of my considerations.

Cost
There are VPS solutions as cheap as $30/month for a fairly basic setup. By basic I’ve seen: 5GB disk space, 100GB transfer bandwidth and CPanel service. However availability and/or reliability of the cheaper service tend to make them a poorer choice. Through my research I found that a fairly typical price was between $40-60/month. And some competitive features were 7-10GB disk, with 100-150GB. Even then, the typical “step-up” options were almost doubled features with a price of $100/month. Logically this doesn’t seem very practical as you can obtain some dedicated servers for $100 or even do a co-location server for less. Hence my target was $50/month.

Reliability
The more I read, the more I realized that reliability is a serious concern with VPS’s. Apparently many people have experienced considerable downtime or hard to diagnose problems. My guess would be poor technical support as it is very easy to misconfigure or corrupt a virtualized operating system. I came to accept that some VPS providers may have more downtime compared to shared hosting providers. Again this is only preliminary research.

Many providers do offer some sort of monitoring service (either free or extra charge). These can vary from simple ping commands from an external server at timed intervals. Or significantly more complex tools, however they all seem to imply that monitoring is in your best interest.

Linux
Almost all VPS providers will use some distribution of Linux. Technically, it could be another form of Unix (or even Windows with “Remote Desktop”). Additionaly most will have a preference to a Redhat variation (Redhat 9.0, Fedora Core, CentOS, RHEL). The benefit here is that I can duplicate a great deal of testing at home before I deploy a complex setup on the VPS.

Virtuozzo (the VPS management software in Linux) relies on some tweaking done to the virtuallized booting kernel in VPS. Hence when I saw Fedora Core 2 available, I blindly assumed it used a 2.6 based kernel, when in fact it was a 2.4 variant. On other VPS’s running CentOS, I’ve seen similar characteristics. — The bottom line is that it is beneficial to have a more up to date distribution even if you really shouldn’t modify it too heavily (i.e. Redhat 9.0 is almost 3 years old).

Software on the distributions will be fairly typical to any Linux: apache, database, mail, etc. However for management there are some options such as CPanel or Plesk or even perhaps a service specific option. If you want to save money (between $7-20/month) you can forgo the specialized options and even elect Webmin. However I doubt that it is nicely geared to be helpful for webhosting on a VPS or for running multiple shared websites.

Growth
This is final most significant factor. Depending on the partitioning of the VPS on the host machine, the VPS may or may not be able to grow. Example: If a 100GB disk layout was cut up in to 10 separate 10GB partitions and 1 user required an upgrade, this would not be possible!. They would have to buy a new VPS or transfer to another physical host. Hence it is very important that you understand your growth. Keep in mind that 1GB of disk space already goes to the Linux installed. Basic upgrades like software packages and bandwidth may be available, but physical resources may be fixed upon setup. Know these facts in advance.

Conclusion
Getting a VPS took me a little more time than I expected, but the research was much less than when I learned shared hosting in 2002. I plan to be up and running with my selection in the next few days.

From what Rob mentioned from his VPS experience, selection was probably the easy part!