This simple BASH password reset script will enable you to reset any mysql user password without knowing the current password

I would not recommend running it on a live production system as it requires shutting down the mysql server.

Heres the script:, it needs to be run as root.

# Kill any mysql processes currently running
echo 'Shutting down any mysql processes...'
killall -vw mysqld
 
# Start mysql without grant tables
mysqld_safe --skip-grant-tables >res 2>&1 &
 
echo 'Resetting password...'
 
#Sleep for 5 while the new mysql process loads (if get a connection error you might need to increase this.
sleep 5
 
#Update user with new password
mysql mysql -e "UPDATE user SET Password=PASSWORD('$2') WHERE User='$1';FLUSH PRIVILEGES;"
 
echo 'Cleaning up..'
 
#Kill the insecure mysql process
killall -v mysqld

First variable is the user you want to reset, second variable is the password.

sh mysqlreset root newpassword

Squid is built in C so without a C compiler i was faced with two options. Build GCC on the solaris box or find a pre-complied Solaris binary for squid. Well i’ve built GCC before an its not a whole heep of fun so I chickened out and went for a squid binary. Here are the steps required.

Goto www.sunfreeware.com

Pick the OS and Processor from the left hand menu and then find the squid binary.

Download the squid binary package to /opt/temp. Note solaris 8 didn’t have the excellent wget by default so you might need to push it on to the server via ftp.

Use gunzip to extract the package.
gunzip -xf squidfilename.gz

Add the package using pkgadd and follow the instructions.
pkgadd squidfilename

Squid is installed in /usr/local/squid

In order to run squid you need to give make the logs directory writeable
chmod 665 /usr/local/squid/log

You’ll also need to create a cache dir
mkdir /usr/local/squid/cache

Make the directory writeable
chmod 665 /usr/local/squid/cache

Know you need to create the cache filestructure. To do this run squid with the -z option
./usr/local/squid/bin/squid -z

You can alter the squid settings by editing /usr/local/squid/etc/squid.conf When you’re happy you can know run squid.
./usr/local/squid/bin/squid

Elastic web hosting in its simplest terms is a hosting account where resources can be rapidly expanded to meet demand. Still very much a new technology its use is gradually beginning to pick up as more and more people discover the limitations of fixed resource hosting. On a typical fixed hosting account you’re allocated a fixed amount of resources and the amount you pay is based on the size of those resources. This model means that in order to keep your site running smoothly you need to be able to accurately predict the maximum amount of load that the server will be subjected to. This can be a nightmare for small startup companies who may find it hard to judge how quickly their service will grow. With fixed resource hosting there are two options:

1. Buy a huge amount of resources initially so that should your website take off or receive unusually traffic spikes you won’t have to worry about migrating to a new server. This is a very costly solution and is often not viable for small startups.
2. Buy a limited amount of resources initially and hope that you will have time to migrate the site to a new server should the website traffic increase. More cost effective but what happens if you your traffic increases rapidly over a number of days. The server gets swamped, there is no time to migrate and you’re facing downtime.
But now there is a third option – Elastic hosting

With elastic hosting you can allocate additional resources in minutes should you server recieve an exceptional amount of traffic. Take for example Digg. Many smaller sites that get on the first page fall over because they do not have the resources to handle the huge amount of traffic that arrives over a period of 3-4 hours. In such a short space of time there is no chance of migrating the site to a new server and updating the name severs accordingly. This results in a loss of vistors and possibly missing out on potential revenue. Elastic hosting solves this. Not only can you allocate additional resources very quickly but more importantly it is often possible to automate the process. This is how it works.

1. A background process monitors resources on your server, it checks free memory, bandwidth, processing speed and disk space. More complex setups may also detect the rate of visitors to the site.

2. A sudden spike of traffic to the site causes the available memory to drop below a suitable level. The background process detects this drop and spawns another identical server and manages traffic with a load balancer.

3. The spike of traffic dies and the free memory on the server rises to an acceptable level. The background process recognizes this and terminates the additional resource.

You only pay for the amount of resources used. So instead of paying for a large amount of resources all the time you only pay for the additional resources when they are required.

Elastic Hosting Providers

Currently the most advanced elastic hosting package appears to be from Amazon in the form of their Amazon EC2 (elastic computing cloud) service. This service works in conjunction with their S3 image hosting service and data transfer between the services is completely free. Which means your bandwidth costs will be considerably lower than on a standard webhost. The only bandwidth you pay for is for data transfered outside of the amazon network. I’m currently testing this service out and will report back with my findings within a month or two.

In theory you could run mongrel, bind it to port 80 and do away with apache all together. There are a few reasons why i don’t wanna do this:

1. I like apache, although its a bit of a resource hog its a solid and secure webserver, has tons of great features and a large community behind it.

2. The other stuff I’ll be running on the server is made up of static pages and other CGI scripts for which I still believe apache is the best option.

In order to serve a rails application on the default port 80 we will use apaches mod_proxy to forward requests to the mongrel server sitting on  custom ports. To improve the performance its best to run more than once instance of the mongrel server and make use of apaches mod_proxy_balancer.

In order for this to work you’ll require a server running apache 2.2 and yum (or apt-get if your running a debian flavour).

Installing ruby

yum install ruby ruby-devel
wget http://rubyforge.org/frs/download.php/11289/rubygems-0.9.0.tgz
tar -xzf rubygems-0.9.0.tgz
cd rubygems-0.9.0
ruby setup.rb

Installing mongrel

gem install mongrel

Building a test rails application

mkdir /var/www/rails
cd /var/www/rails
rails mytest

Starting mongrel

adduser mongrel
cd mytest
chown -R :mongrel *
su mongrel
mongrel_rails start -d -p 3001 -P log/mongrel1.pid
mongrel_rails start -d -p 3002 -P log/mongrel2.pid
mongrel_rails start -d -p 3003 -P log/mongrel3.pid

Make sure you start mongrel in the root directory of your rails project. If successful we now have three mongrel instances. To verify type ps -aux | grep mongrel

Configuring Apache

You’ll need to add the following code to your httpd.conf file

#define mongrel cluster
<proxy balancer://mongrelcluster>
  BalancerMember http://127.0.0.1:3001
  BalancerMember http://127.0.0.1:3002
  BalancerMember http://127.0.0.1:3003
</proxy>
 
#forward requests to mongrel cluster
<virtualhost *:80>
  ServerName yourdomain.com
  ServerAlias www.yourdomain.com
  ProxyPass / balancer://mongrelcluster/
  ProxyPassReverse / balancer://mongrelcluster/
  ProxyPreserveHost on
</virtualhost>

Finally navigate to yourdomain.com and you should see the ‘Welcome Aboard’ default rails page.