2010
09.02

Webmin not autostarting on boot? Sometime over the last year or so, for some reason Webmin stopped starting after a reboot. I’ve always done a manual restart with a: /etc/init.d/webmin start command, so I figured added it to /etc/rc.d/rc.local would fix it. But it didn’t.

Apparently, Webmin has a separate startup script of:
/etc/webmin/start

So, to fix the boot startup issue, just add that snippet to your/etc/rc.d/rc.local file, and it will correct the problem!

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2010
08.31

We are all eagerly awaiting the release of ChromeOS in November. But why wait? You can easily hack Ubuntu 10.04 into a minified (yes, it’s actually a stripped down further) version of ChromeOS. Sure, it won’t have all of the built-in security and other features that may be absolutely necessary for a production-level install, but it will give you sub-5 second boot times, while automatically logging you in and presenting you with the fabulous Chrome window directly after boot.

How, you may ask? It’s fairly simple to create a minimal install of Ubuntu, then modify the bootstrapping process to make it all yours – I’ll show you how.

The first thing you need to do is download the latest copy of Ubuntu (10.04 at the time of this writing) from http://www.ubuntu.com/server/get-ubuntu/download. I prefer the 64-bit version on all operating system installs. After downloaded and burned to a cd, boot up from it and press F4 at the splash screen and select Minimal Install. This will only install the absolute minimum requirements for an OS. I also didn’t install any options whatsoever (including LVM, miscellaneous options, etc.) as each option could potentially slow down the boot time.

After ubuntu is installed, login from the provided terminal prompt and run the following snippets. Use google-chrome-beta if you want to use the beta version of the Chrome browser instead.
wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -
sudo sh -c 'echo "deb http://dl.google.com/linux/deb/ stable main" >> /etc/apt/sources.list.d/google.list'
sudo apt-get update
sudo apt-get install google-chrome-stable xorg nano

After the prerequisites are installed, create a couple user-defined preference files to signal to start x and boot into Chrome.
nano ~/.bash_profile
#!/bin/bash
startx

nano ~/.xsession
#!/bin/bash
/opt/google/chrome/google-chrome

The last step is to autologin the user. Make sure you enter this line correctly, otherwise you may have to install Ubuntu all over again. Yes, it’s that important. Replace ‘username’ with your username.
nano /etc/init/tty1.conf
exec /bin/login -f username < /dev/tty1 > /dev/tty1 2>&1

Now, just do a ‘sudo reboot’ and you should be golden. You can edit any of the files at a later time by just exiting out of Chrome (click the X) which will return you to the terminal.

This process is just meant to demonstrate the power of Ubuntu, and how easily it can be modified to your needs. My settings booted so fast (under 2 seconds without the computer’s signal prompt), that it started the Chrome browser before the ethernet card was even established which forced me to use F5 to refresh to load google.com. Pretty insane.

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2010
01.18

 I’ve recently been involved with a site that was experiencing a heavy level of Slowloris attacks. Slowloris is a DoS (Denial of Service) attack that was made with a very simple agenda – to shutdown websites with a very low-level attacking client. It seems to mainly affect Apache, the most popular web server in the world (newer web servers such as Lighttpd and nginx are unaffected). It has been recently talked about in a variety of magazines and publications such as Linux Magazine and HowToForge.com.

With various possible fixes given in those articles, I was unable to completely guard against the attack. While it seemed as though the Apache module mod_evasive was the only thing partly helping the attacks, it was not a 100% fix to the problem. Migrating off Apache was not an option at this time, so I thought about it and came to the conclusion that I can have a script automatically restart Apache when the number of current open Apache processes increases past a set threshold. So, I created the following script and placed at /etc/custom/anti_slowloris.sh:

#!/bin/bash
# author: mark shust
# created: 2009.10.12 09:16

# get number of apache processes
apachemem=`ps axo 'pid user size cmd' | grep apache | grep -v '\(root\|grep\)' | wc -l`

# restart apache if there are more than the defined number of running processes
if [ $apachemem -gt 25 ] ; then
/etc/init.d/httpd restart
fi

What this script essentially does in count the number of current open Apache processes, and if is past a certain limit (in this case, 25), it will automatically restart apache. This script has now been running on a cron for 3 months and during that time we have no longer had any issues at all regarding these DoS attacks. Feel free to use the script and modify it as necessary. Below is the related cron setup (basically runs every 5 minutes). Since it is such a tiny script it pretty much takes up no load on the server:

0,5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/custom/anti_slowloris.sh

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2009
11.19

Here is another hot topic that seems extremely confusing from the start, but is actually very easy to implement. Amazon Web Services EC2 seems to be the most fully-featured cloud-based web services on the internet. Amazon was the first major party to rollout a massive network of VM’s in the ‘cloud’ and remains to be the highest-respected service out there for Linux computing.

Due to the way Amazon is setup using XEN vm software, if there was ever physical hard drive failure, an ‘instance’ would essentially vanish into thin air (all except ‘Volumes). Not good. There does lie great integration with S3 (Amazon’s Simple Storage) that enables you to backup your instance to S3 for easy retrieval in the even that the random occurence actually does happen.

Summarizing the process in as very few steps as possible, the below is how one would go about creating a ‘bundle’, transferring it to S3 for reliable backup, and registering it as an AMI in your AWS Console.

Create Bundle

*ETA: 20 minutes

  • Replace X’s with X.509 Certificate Private Key & Certificate.
  • Replace 123456789012 with AWS Account ID (found on Security Credentials page).

/home/ec2/bin/ec2-bundle-vol --destination /mnt --privatekey /root/pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem --cert /root/cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem --user 123456789012 --exclude /home --prefix image-20091119 --arch i386

Upload to S3 Bucket

*ETA: 5 minutes

  • Replace X’s with Access Key ID & Secret Access Key (found on Security Credentials page).
  • Replace BUCKETNAME with name of bucket setup on S3.

/home/ec2/bin/ec2-upload-bundle -b BUCKETNAME/instance-snapshots/image-20091119 --manifest /mnt/image-20091119.manifest.xml --access-key XXXXXXXXXXXXXXXXXXXX --secret-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Remove Unneeded Bundle Files

  • Bundle is now stored on S3, so no need to keep a copy locally.

rm -rf /mnt/im*

Register Bundle on S3 as AMI

*ETA: 1 minute

  • AMI is defaulted to Private AMI. You may change this from the AWS Console.
  • Replace X’s with X.509 Certificate Private Key & Certificate.
  • Replace BUCKETNAME with name of bucket setup on S3.

/home/ec2/bin/ec2-register --private-key /root/pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem --cert /root/cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem BUCKETNAME/instance-snapshots/image-20091119/image-20091119.manifest.xml

Other

Be sure to note, that if you have an EBS storage that is connecting on boot via /etc/fstab, you will need to provide an alternate fstab file and then activate it after instance launch. It is best to copy /etc/fstab to something like /etc/fstab.bundled, and then comment out the EBS drive for easy uncommenting later. If you do not do this, there is a good chance the instance will not boot and will be inaccessible.

Below is a sample line for bundling the instance with a customized fstab file.

/home/ec2/bin/ec2-bundle-vol --destination /mnt --privatekey /root/pk-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem --cert /root/cert-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.pem --user 123456789012 --exclude /home --prefix image-20091119 --arch i386 --fstab /etc/fstab.bundled

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2009
11.13

On the initial surface, upgrading Drupal appears complex, when in actuality it’s very rudimentary. A lot of the tutorials and resources on how to upgrade are just plain confusing and not to the point.

The following is a list of command lines and steps in order to upgrade Drupal quickly and easily in 3 EASY STEPS! It just can’t get easier, and I have yet to see one posting that includes this way of doing it, which is really just the quickest/easier/cleanest/simplest way to get it done.

  1. Go to your root directory (one step below public_html), download Drupal, and unpack it. Replace 6.x with the new version you are upgrading to.
    wget http://ftp.drupal.org/files/projects/drupal-6.x.tar.gz
    tar -zxf drupal-6.x.tar.gz
  2. Sync the new files up with your current install.
    rsync -av drupal-6.x/ public_html/
  3. Go to your domain and run the update script.
    http://www.domain.com/update.php

The entire upgrade process takes only a few minutes. I dare and challenge you to find a quicker and simpler way of upgrading Drupal — because there isn’t one.

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2009
10.16

Here is a neat trick to get much better colored diff’s out of subversion when you are in command line. Just add the following lines anywhere in your ~/.bashrc or ~/.bash_profile file, and you will have nice colored diff’s just like Git.

#colordiff
function svndiff() {
local SVN="`which svn`"
# The colordiff utility (http://colordiff.sourceforge.net) is
# needed for this enhancement to work
# Thanks to Lukas Kahwe Smith for the addition to
# leave out whitespace changes
# Thanks to Robin Speekenbrink for the hint to the -R
# switch of less, which should fix problems some of
# you might have with colorization.
${SVN} diff "$@" --diff-cmd `which diff` -x "-u -w"|colordiff|less -R
}

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2009
09.21

Injection attacks and vulnerabilities are extremely common, and can be prevented in just about any case with proper coding and setting permissions correctly. There are a vast array of cross-site scripting (XSS) attacks and worms out there (I’m sure you’ve stumbled on a site with the words ‘viagra’ or ‘xanax’ in the page, and it looks very out-of-place and not consistent with the site’s content). These are usually caused by bots searching the web for securities vulnerabilities.

It is important to put the proper XSS checks in place, and fixing your website permissions by executing the following commands in the root folder of your website:

find ./ -type d -exec chmod 755 {} \;

find ./ -type f -exec chmod 644 {} \;

This resets all folders and files to their default permission sets and will help prevent these attacks from happening in the future.

If you fear your website has been attacked, you can do a global search on all the files for a certain keyword (ex. viagra, xanax, etc.). This will provide the filename and text of the infected file so that you can cleanup the code.

find . -type f -name *.php | xargs grep xanax

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2009
09.17

When installing new packages on CentOS on a 64-bit machine, it installs both 32-bit (i386) and 64-bit (x64_86) versions. This is completely unwanted and may lead to undesired results, and has recently caused problems with machines I manage with high-load running apache (possible 32-bit packages installed on a 64-bit machine?). Regardless, the i386 packages are completely unnecessary and should be removed if you are running a 64-bit machine, which is most-likely just about every server out there.

You can run the following command to display a list of all i386 packages on your machine. You can be assured that there is a x64_86 version installed for every one of those i386 packages.

rpm -qa --qf '%{name}.%{ARCH}\n' | grep i386

To remove a i386 package, just designate the package to be removed and add .i386 to the end of it (ex. yum remove xulrunner.i386). In order to change the default config for installing new packages, add this at the bottom of your /etc/yum.conf file:

# Only install x64_86 packages
multilib_policy=best

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter
2009
08.20

Let’s say you have your dream machine setup on the most recent version of Ubuntu, and have already spent hours upon hours setting it up. You’ve installed Zend Studio, Putty, Photoshop, Open Office, yada yada yada. You think you’re done for good with that dreaded bi-monthly re-format of Windows XP/Vista.

But just when you think all is fine and dandy, you find a piece of software that just refuses to run on Wine or Virtualbox (just when you think that isn’t possible… just picture the need to connect to a Windows app, that uses a legacy serial port that has no Ubuntu driver — so it never gets detected by vmware or virtualbox). Yes, there are some rare needs for a native Windows XP install.

I recently had to go through this process and came across two great write-ups. The first step is to add on the necessary hard drive partitions and formats alongside your ubuntu install. You can either do this with a GParted Live CD or the native Ubuntu Live CD. Then, all there is to do is to install Windows, then modify the master boot record for it to respond to Grub once again.

These documents should help you out greatly:

How to dual-boot Vista with Linux (with Linux installed first)

How to Install WinXP after Ubuntu with Gparted

Share and Enjoy:
  • Facebook
  • LinkedIn
  • Twitter