• Home
• Software
  • Catalog Index
• Mirrors
• Articles
• Wiki
• Support

Blastwave™ in 5 steps

Step 1: Be Patched Up To Date

I can not stress this enough. You can not expect your operating system to be at peak performance and stability if you do not perform regular software maintainance. At the very least you will need to apply the Solaris Recommended patch cluster. After that is complete you may then proceed.

Step 2: Install pkgutil

To do much of anything you will need pkgutil on your system.

Solaris 8 & 9 Users: You need to fetch the correct pkgutil package from Network.com thus:

• Sparc users : http://download.blastwave.org/csw/pkgutil_sparc.pkg
  
  md5    = 2284cf5fbe0e52e2aa1e0cd557a9badf
  sha256 = 905b0ead074b32943cbe0141f2372d582bf96b9f8b55490904af6b0250079951
  
  
• INTEL users : http://download.blastwave.org/csw/pkgutil_i386.pkg
  
  md5    = 7efd44ce9ddd45a12c502190f8d984be
  sha256 = 4ded35bfc6df6a9266cf9641986490452e311977208e7a7a703464d82a5fbd2d

Then you need to manually install the package thus:

Solaris 10 & Nevada or OpenSolaris™ Users:

Step 3: Fetch the Software catalog

If you look closely you will see a copy of wget is included with pkgutil. This means that pkgutil will work out of the box regardless of what rev of Solaris you are on. You don't need to worry about OpenSSL or WGET or even about basic configuration. That is all done for you.

The first thing you NEED to do is fetch the software catalog.

Special NOTE: You may need a proxy setup!
If you need a web HTTP proxy for access to the internet then be sure to create a .wgetrc file for the root user that looks like so:

Choose an IP address and port number that works for your environment.

Step 4: Security First!

All of the software from Blastwave™ is delivered via digitally signed software catalogs. You need to ensure that your catalogs are correct and have not been tampered with.

Install GNU GPG as well as the ability to verify MD5 hash values thus:

Once you have CSWgnupg installed (RFC 2440 compliant tool for secure communication) then you must fetch the Blastwave.org GPG digital key and import that key into your local key ring.

You may fetch the Blastwave key in four possible ways:

1. Manually copy and paste the key into a local file.
   Simply look at the key on the Blastwave website and then use vi to put it into a local file:
   • View the key URL at http://www.blastwave.org/gpg_key.txt
   • Put that exact key into a local file named blastwave_key.dat
   • Run (as root) /opt/csw/bin/gpg --import blastwave_key.dat
   
   
2. Fetch and install a complete edition of wget and then use it to fetch the key
   To get a full copy of CSWwget you need to run pkgutil again thus :
   • /opt/csw/bin/pkgutil --install wget
   
   Once that is complete use wget to fetch and import the key like so :
   • /opt/csw/bin/wget http://www.blastwave.org/gpg_key.txt
   • /opt/csw/bin/gpg --import gpg_key.txt
   
   
3. Use gpg to fetch the key directly from a key server. In this case you can run gpg directly to fetch the key from the MIT keyserver:
   
   # /opt/csw/bin/gpg --keyserver pgp.mit.edu --recv-keys A1999E90
   gpg: directory `/root/.gnupg' created
   gpg: new configuration file `/root/.gnupg/gpg.conf' created
   gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
   gpg: keyring `/root/.gnupg/secring.gpg' created
   gpg: keyring `/root/.gnupg/pubring.gpg' created
   gpg: requesting key A1999E90 from hkp server pgp.mit.edu
   gpg: /root/.gnupg/trustdb.gpg: trustdb created
   gpg: key A1999E90: public key “Blastwave Software (Blastwave.org Inc.) <software@blastwave.org>” imported
   gpg: no ultimately trusted keys found
   gpg: Total number processed: 1
   gpg: imported: 1
   
   
4. Use the wget binary that is included in the pkgutil tool package

The best method to use is option #3 above. If you have access to the internet directly then please perform step #3. Otherwise the last method is very safe and almost certainly reasonable for a server that does not have direct access to the internet.

Method #4 looks like so:

The last step to take is to actually employ the digital signature checks and MD5 hash verification that has been provided to you. To do this you need to do three things:

1) Verify that you have the key. Use the gpg --list-keys command:

2 ) Mark the key as being trusted for a given purpose. In this case you want to trust the signed software catalogs from Blastwave. To do this you need to edit the key and mark it as being trusted thus:

3) Lastly you need to modify the pkgutil configuration to actually use this GPG key as well as to verify the MD5 hashes of the software packages. Edit the pkgutil.conf file that you copied into /etc/opt/csw such that the lines related to GPG and MD5 are not commented out. Your pkgutil.conf should look like so:

The End Result is a secure mechanism for software delivery

You're final step is to fetch a new catalog and this time you will see that the GPG digital signature will be verified for you:

Step 5: Before you proceed...

What I have to say here will be “Motherhood” statements at best. Really just a bit of advice if you are making the leap from Linux and wonder where to set the PATH for your users and things like that.

Firstly we need to talk about the root user.

Don't mess with the root user account!

That was less than clear so I guess I had better elaborate.

It seems to be common practice to change the root users default shell.

Don't do that unless you have Solaris 10

What I do recommend is that you change the root users home directory location to /root and nothing more fancy than that. You can edit the /etc/passwd file and change the entry for the root user thus:

Be very diligent about creating the root users home directory right away and ensure that it is only readable by the root user:

Also, you may be wondering why you should not change the root users default shell to bash. Simply put, any other shell than /sbin/sh will be a dynamically linked executable with dependencies. If you were to check /sbin/sh you would find that it is a standalone program:

That means that your machine can suffer some horrible disaster and still be able to function in single user mode if you can boot the kernel and get to a running shell with the root user. That is becuase the root user only needs /sbin/sh to have a fully functional shell. If you were to use bash or any other shell then you would need a stack of dependencies. Those dependencies may not exist if they are on some other file system or on a damaged file system.

Solaris 10 is different. Solaris 10 has a default Bourne Shell /sbin/sh that is not statically linked anymore. This was done intentionally when the single/multi threaded process model was unified and the statically linked libc was removed. Solaris 10 commands in /sbin should only link with things in /lib. There are symlinks in /usr/lib to /lib for some libraries for backwards compatibility reasons. In fact, Solaris 10 is so smart that both su and login will fall back to /sbin/sh if the shell you specify in /etc/passwd for root can not be executed for some reason. What I am saying here is that you can change root's shell in Solaris 10 and still sleep well at night.

Next item is the default PATH for the root user and regular users. You can set this in the files /etc/default/login and /etc/default/su. Please feel free to be pedantic and set PATH and SUPATH in both of those files to something useful thus:

Really you can leave /opt/csw/bin out of there entirely if you want. The software from Blastwave is isolated in /opt/csw and will not interfere with your other software. You can use GNOME from somewhere else if you want. Your users can have there own .profile files that determine that they run JDS if they want.

On the other hand your users may place /opt/csw/bin first in their PATH and then will be running with the desktop software and applications from Blastwave. Again, this will be isolated. Don't be surprised if you have problems switching back and forth from different distributions of GNOME however. There are a lot of configuration files that get created in the users home directory and you can really only depend on them to work consistently when you stay on one edition of KDE or GNOME.