RightScale (www.rightscale.com) is a great and easy way to setup, monitor and run Amazon EC2 virtual server instances.
Within RightScale, you can define "RightScripts" to be run during boot, run or shutdown of the server instance.
With this, it is quite easy to automatically setup an EBS volume for the instance.
Just create a new RightScript and paste the following script into it:
#!/bin/sh
ebs_device_node=$EBS_DEVICE_NODE
ebs_device_node_partition="${ebs_device_node}1"
# todo: check of the device node exists.
if [ ! -b $ebs_device_node ]; then
echo "Block Device $ebs_device_node does not exist. Exiting"
exit 1
fi
if [ ! -d $EBS_MOUNT_POINT ]; then
echo "EBS Storage not provisioned, setting up..."
echo "STEP1: Partition EBS STORAGE $ebs_device_node"
# note: next step needs the sequence "n<enter>p<enter>1<enter><enter><enter>w<enter>" to work!
fdisk $ebs_device_node << EOF
n
p
1
w
EOF
ret=$?
if [ $ret != 0 ]; then
echo "FDISK FAILED. Aborting".
exit 1
fi
echo "formatting $ebs_device_node_partition"
mkfs.ext3 $ebs_device_node_partition
ret=$?
if [ $ret != 0 ]; then
echo "formatting $ebs_device_node_partition FAILED. Aborting".
exit 1
fi
echo "Creating mount point $EBS_MOUNT_POINT"
mkdir $EBS_MOUNT_POINT
if [ $ret != 0 ]; then
echo "Creation of mount point $EBS_MOUNT_POINT FAILED. Aborting".
exit 1
fi
echo "Adding EBS Storage mount point $EBS_MOUNT_POINT to /etc/fstab"
echo "$ebs_device_node_partition $EBS_MOUNT_POINT ext3 defaults 0 0" >> /etc/fstab
echo "Mounting $EBS_MOUNT_POINT"
mount $EBS_MOUNT_POINT
else
echo "EBS Storage already set up. Exiting."
exit
fi
echo "finished."
Note: You need to have the two blank lines for fdisk in the script, as this is needed to partition the volume propperly.
- If you got the script, assign it to a server template.
- Now create an EBS volume in a zone with device node /dev/sdj and any size you need.
- Then launch an instance of the server template in the same zone as the EBS volume.
- Fill in the Inputs of the instance (e.g. /dev/sdj as the device node and /EBS-VOLUME as the mount point)
- And immediately attach the EBS volume to the instance.
Thats it.
The script will check during start if the volume is already setup. This means, it runs only once.
Saturday, December 6, 2008
Friday, November 21, 2008
How to speedup ssh login to Mac OSX 10.x systems
If you login to MacOS X systems, you will notice a long delay until you are able to login.
Reason for this is the same as for all other ssh2 daemons (Linux, Solaris etc.).
DNS reverse lookup requests.
The sshd daemon tries to figure out your reverse ip.
This may take a very long time.
To avoid the long delay, simply add the following line to the OSX sshd server box:
vi /etc/sshd_config
UseDNS no
Save the file. No reboot necessary.
Reason for this is the same as for all other ssh2 daemons (Linux, Solaris etc.).
DNS reverse lookup requests.
The sshd daemon tries to figure out your reverse ip.
This may take a very long time.
To avoid the long delay, simply add the following line to the OSX sshd server box:
vi /etc/sshd_config
UseDNS no
Save the file. No reboot necessary.
Tuesday, September 16, 2008
How to use formated maven2 timeStamp and buildNumber using buildnumber-maven-plugin mojo?
Today I was wondering how to use a formatted build timestamp and the current svn build version in your maven pom using the buildnumber-maven-plugin mojo, as most of the postings I found say it doesnt work. But it does. Read on.
The trick is to use two execution sections, one for the buildNumber (the current svn version) and another one for the formated timestamp, but this time we store the value in a new property called buildTimestamp.
With this, you can use the two properties ${buildNumber} and ${buildTimestamp} wherever you want.
Tip: Define the plugin in the main pom.xml file. It gets executed in every maven sub module.
<plugins>
<plugin>
<groupid>org.codehaus.mojo</groupid>
<artifactid>buildnumber-maven-plugin</artifactid>
<executions>
<execution>
<!-- buildNumber -->
<id>generate-buildNumber</id>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
<configuration>
<docheck>false</docheck>
<doupdate>false</doupdate>
</configuration>
</execution>
<execution>
<!-- buildTimestamp -->
<id>generate-timestamp</id>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
<configuration>
<format>{0,date,yyyy-MM-dd_HH-mm}</format>
<items>
<item>timestamp</item>
</items>
<docheck>false</docheck>
<doupdate>false</doupdate>
<buildnumberpropertyname>buildTimestamp</buildnumberpropertyname>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
The trick is to use two execution sections, one for the buildNumber (the current svn version) and another one for the formated timestamp, but this time we store the value in a new property called buildTimestamp.
With this, you can use the two properties ${buildNumber} and ${buildTimestamp} wherever you want.
Tip: Define the plugin in the main pom.xml file. It gets executed in every maven sub module.
<plugins>
<plugin>
<groupid>org.codehaus.mojo</groupid>
<artifactid>buildnumber-maven-plugin</artifactid>
<executions>
<execution>
<!-- buildNumber -->
<id>generate-buildNumber</id>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
<configuration>
<docheck>false</docheck>
<doupdate>false</doupdate>
</configuration>
</execution>
<execution>
<!-- buildTimestamp -->
<id>generate-timestamp</id>
<phase>validate</phase>
<goals>
<goal>create</goal>
</goals>
<configuration>
<format>{0,date,yyyy-MM-dd_HH-mm}</format>
<items>
<item>timestamp</item>
</items>
<docheck>false</docheck>
<doupdate>false</doupdate>
<buildnumberpropertyname>buildTimestamp</buildnumberpropertyname>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
Labels:
build-timestamp,
buildnumber-maven-plugin,
maven,
maven2,
mvn
Monday, September 15, 2008
CentOS 4 - How to remove old Kernel versions?
Over time you get many obsolete kernel versions in CentOS4 (or RedHat Server 4).
The yum update feature installs new kernel versions, but doesn't remove old ones.
This fills up /boot more and more.
Here is how to get rid of the old kernel versions in a clean manner:
What kernels are installed:
yum list installed | grep -i kernel
Uninstall old version kernel-VERSION
Example: yum remove kernel-2.6.9-67.0.22.EL
Warning: Do not deinstall the most recent version. You might hose your system...
Tip:
On a SMP system, CentOS installs both UP and SMP versions of the kernel.
Therefore, remove both kernels.
CentOS5 by default keeps only the 4 most recent kernel versions. Therefore, no action must be performed on this system.
The yum update feature installs new kernel versions, but doesn't remove old ones.
This fills up /boot more and more.
Here is how to get rid of the old kernel versions in a clean manner:
What kernels are installed:
yum list installed | grep -i kernel
Uninstall old version kernel-
Example: yum remove kernel-2.6.9-67.0.22.EL
Warning: Do not deinstall the most recent version. You might hose your system...
Tip:
On a SMP system, CentOS installs both UP and SMP versions of the kernel.
Therefore, remove both kernels.
Subscribe to:
Posts (Atom)