In this Section
Strongbolt 1.x Installation Notes
Troubleshooting strongbolt 1 installation
Updating the ROM
Identify your ROM type
Strongbolt 1 forum
Strongbolt FAQ
CentOS3 BlueQuartz Howto
Strongbolt Compatibility
Tips and Tricks
SB1 kernel update
SANTA CLARA, CA -- May 13, 2002 -- Sun Microsystems, Inc. is making the delivery of network applications simpler and more affordable than ever with the introduction of the Sun Cobalt RaQ(tm) 550 server appliance.
Read more...     
The Strongbolt2 ROM
With the arrival of Strongbolt2, we have a new ROM for Cobalt servers.
The new ROM is based on the source from, but modified to include a 2.6 kernel. The reason for this is to facillitate booting from USB and support for extra hardware.
Read more...     
Strongbolt 2 upgrade released
A new year sees a completely new release of Strongbolt.
The Strongbolt2 upgrade is an easy process that just involves installing a couple of packages through the package management interface (bluelinq).
Read more...     
Support from OS Office is nothing short of amazing.
Finding companies that stand behind their products these days can be challenging, but the staff at OS Office proves they still exist.
I continue to be stunned by their response times and outstanding service.
Jim Murray
Read more...   
Tips and Tricks

Tips and Tricks

Rebuilding a RAID set

The following example assumes that you have a failed hdc drive, which you have now replaced.
If you have a failed hda drive, reverse the drives.


This command dumps the hda partition structure to a text file:

 sfdisk -d /dev/hda > /tmp/hda.out

This command tells hdc to use that configuration to clone the part sizes:

 sfdisk /dev/hdc < /tmp/hda.out

We now have the parts cloned, and we are ready to re-build the RAID set:

mdadm --add /dev/md1 /dev/hdc1
mdadm --add /dev/md2 /dev/hdc2
mdadm --add /dev/md3 /dev/hdc3
mdadm --add /dev/md5 /dev/hdc5
mdadm --add /dev/md6 /dev/hdc6

The RAID will rebuild now


Server administration Tips and Tricks

One of our customers has recently been compromised by an unknown party.

Several thousand html and php files were compromised to include malicious code :

 The code that was added was as follows:


Whatever the purpose of this iframe, whether it was browser theft, or a dormant popup advert campaign, it was not welcome.

 If you have any similar infected files please see the following:

First Sweep (cleans html files)

for i in $(find / \( -name "*.html" -o -name "*.php" \); do perl -p -i -e 's///' $i; done

Second Sweep (Cleans PHP files)

for i in $(find / \( -name "*.html" -o -name "*.php" \);do perl -p -i -e 's/echo \"\";//g' $i; done

This should clean the affected files and remove the unwanted code.

Restricting access to your servers' services

There are several ways to restrict and allow access to your servers services; firewalls, configuration directives and more.

One popular way to restrict access to your Unix or Linux machine, is to modify the /etc/hosts.allow and /etc/host.deny files. These files are used by the tcpd (tcp wrapper) and sshd programs to decide whether or not to accept a connection coming in from another IP address. We recommend that to start with, you restrict access to only those network addresses you are certain should be allowed access. The following example files allow connections from any address in the network domain, but no others.

Be very careful with these files. As the wrong configuration will lock you out of your server!!


# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
# Make sure that you are careful with this file, as misconfiguration can
# lock you out of your server.
# Only allow connections within the domain.


The following file controls which hosts are denied access to services./etc/hosts.deny file content. With this configuration, access to your machine from all hosts is denied, except for those specified in hosts.allow.


# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
# deny all by default, only allowing hosts or domains listed in hosts.allow.
# ALL: ALL # This will prevent access to all services except the ones
# described in the hosts.allow file

sshd: All

Log Files

As a general rule, its a good idea to Check Your Log Files Regularly. These files can indicate whether or not someone is trying to break into your server. They can also help to highlight the services which may be vulnerable to penetration.

You can find the log files in the /var/log directory. The following files are worth checking:

* /var/log/messages general system messages
* /var/log/secure connections to the machine
* /var/log/wtmp log of user logins (read by 'last').