Firefox Config

Posted by John
on Thursday, 20 November 2008

to access the Firefox Configuration area, type this into your address box and hit enter...

about:config

If you completely screw things up you can reset to the defaults by...

  • Start Firefox in Safe Mode
  • Check the Reset to Defaults box
  • Click the Make Changes and Restart button

Keeping track of resources with Monit

Posted by John
on Sunday, 08 June 2008

Another handy tool i've grown to like is Monit, which makes keeping tabs on memory-hungry processes much easier.

Basically once configured it helps keep an eye on particular process (e.g PostFix, PostGreSQL, Apache or your disk space). If one is starting to use too much memory, your running low on disk space or it's just no longer responding it can automatically restart it for you and alert you in the process; making system administration that little bit easier.

Installing

Install with Aptitude using,

sudo aptitude install Monit

After which it will tell you it's won't start until it's been configured,

Starting daemon monitor: -e monit won't be started/stopped
  unless it it's configured
  -e  please configure monit and then edit /etc/default/monit
  -e  and set the "startup" variable to 1 in order to allow
  -e  monit to start

Configuring

First make a backup copy of it's initial config, in case you need to rollback:

sudo cp /etc/monit/monitrc /etc/monit/monitrc.orig

Now edit it with:

sudo nano /etc/monit/monitrc
  • uncomment set daemon 120, so monit will run every two minutes.
  • uncomment set alert and enter the email address you want to use for email alerts.
  • uncomment include /etc/monit.d/* so it will read in all config files within that directory.
  • save and create the monit.d directory,

    sudo mkdir /etc/monit.d

By using a wildcard for that last config change you can build up separate .monitrc files for each service you want to monitor, making future modifications easier.

For example, monitor disk usage using:

sudo nano /etc/monit.d/system.monitrc

check system mysite.com
  if loadavg (1min) > 4 then alert
  if loadavg (5min) > 2 then alert
  if memory usage > 85% then alert

check device rootfs with path /dev/sda1
  if space usage > 85% then alert

Starting

After making your changes, check the syntax you used is correct with,

sudo monit -t

...if you uncommented the last line include /etc/monit.d/* and you've got no config files in there you'll get an error stating it can't find any config files there. don't worry too much about that, no need running it if you haven't got anything for it to do.

Now edit,

sudo nano /etc/default/monit

And change startup=0 to 1 to enable it, save the file and run,

sudo /etc/init.d/monit start

To start the service, stop it with,

sudo /etc/init.d/monit stop

...based partly on an example from Monit for Peace of Mind & Monitoring Ubuntu Services with Monit. More info at the official Monit site.

Plus a good example pastie here,

Rails Sessions

Posted by John
on Sunday, 09 March 2008

rails is love

To make a truly intelligent web application your gonna sooner or later have to play around with Sessions, which is basically a Cookie's big brother.

Store in DB

Now Rails initally will store all it's session data in a text file within the /tmp/sessions directory of your rails app, which is usually ok, but if you're gonna build a production-ready app you're gonna want to up the ante somewhat and store them in your DB.

This is simply done by opening up your environment.rb file and un-commenting the following line...

(within /config/environment.rb) config.actioncontroller.sessionstore = :activerecordstore

Then in the command-line generate a RAKE DB migration for your Session objects (so they're stored in your db from now on).

rake db:sessions:create rake db:migrate

Bingo, you now have a table within your database hooked up and ready to store your session data perfectly.

Storing Session Objects

Now that you've got your DB storing your session data, why don't we start creating some session objects.

This is done by...

session[:order] = 'ASC'

Here, we've simply created a new session object, storing in it a text value of 'ASC'; cool eh?

We can then check to see if our session is empty via...

if session[:order].blank? ..do stuff..

So if our session object contains nothing we can initialise it correctly.

Common Gotcha

Now one of the good things with switching sessions over to your db is that it'll secure your app a little bit better and your performance will improve.

Plus if your building your app on your dev machine, then transfer it to your live box, but can't find a reason why your sessions don't work there it's usually down to file permissions for the session file; by switching sessions over to a db you remove any future problem of this.

Good eh,

NGINX Config Update

Posted by John
on Tuesday, 04 March 2008

Using the Firebug addon YSlow from Yahoo I managed to tune site performance a little more by adding 'expires' to the nginx.conf file

location ~* ^.+.(jpg|jpeg|gif|js)$ { root /var/www/apps/myapp/public; access_log off; expires 30d; }

What this basically does is tell NGINX that any files of type jpg, jpeg, gif, and js with the root dir specified shouldn't be logged for access and have an expires value set to 30 days.

As most of the images I use on-site don't change that much this works perfect for me.

Updated my NGINX example files in the [CODE DOWNLOADS] area so you can grab a copy.

More tips located at...

How-To: Multiple Ruby Apps on the Same Box

Posted by John
on Friday, 24 August 2007

So you’ve deployed your first app to your nice lil’ Linux box via Capistrano, wahey!!

Now presuming you don’t really want to dedicate each server to one app alone, how would you get more than one app on there?

Here’s how,

Apache 2 .Conf

remote onto your server and edit the apache2 .conf file

/usr/local/apache2/conf/httpd.conf

  • look for a line saying ServerName
  • append the server’s IP address to the end of this
  • un-comment it

now when you try restarting apache remotely it’ll know where it is.

next check down the bottom of the file for:

  • Listen 80
  • Include conf/apps/
  • NameVirtualHost * :80

this tells Apache which port to listen to for incoming http requests and to load the config files in the conf/apps/ dir on startup.

Editing your Apps Deploy.rb

Now before you deploy your second app to the new server you must make sure it’ll use a different proxy port. Now by default your first app’l have used 8000 and 8001 so the obvious choice is to use 9000 and 9001.

So, navigate to your second ruby apps /config/ dir and edit it’s deploy.rb file

secondapp/config/deploy.rb

  • first off, you can copy & paste bits from your first apps deploy.rb to make your second, just remember to change the svn repository location to default (as you’ll make your own) and change your apps name.
  • look for => set :apache_proxy_port, 8000 and change it to 9000

deploy your 2nd app

in your second apps dir using the capistrano + deprec gems,

  • cap deprec_setup
  • cap setup_scm <= this’ll give you a new svn location for your app, add it to your deploy.rb file
  • cap deploy_with_migrations
  • cap restart_apache

afterwards you should have 2 ruby apps running on the same server!

If you get problems…

Now life isn’t perfect so chances are you’re gonna run into problems, so here’s some common commands and gotcha’s to help you,

Mongrel Complains .PID files already exist!

  • …ssh in and goto /var/www/apps/secondapp/current/tmp/ and run: rm *.pid

How Do I Re-Start Mongrel?

  • …navigate to app root & run: cap restart_mongrel_cluster

Second App keeps pointing to first, ARGH!!!

  • …ssh in and goto /usr/local/apache2/conf/apps/
  • …run: nano secondapp.conf
  • …make sure <VirtualHost *:80> and it’s balancemember is using 9000 and 9001

Restart Server?

  • …ssh in and run shutdown -r now

Restart Mongrel + Apache?

  • …navigate to first app and run: cap restart_mongrel_cluster
  • …goto second app my run: cap restart_mongrel_cluster
  • …run: cap restart_apache

If you still get problems drop me a line and i’ll try to help,

Best of luck,

John.