What can be more annoying than beeping each time you make some sort of a mistake typing in a command or editing a document? I don't think anything else can beat that, incessant beeping tops my chart of computer annoyances. If you have your terminal open in an X Window environment (regardless of the window manager or desktop environment used), you can turn off the beeps as easily as running the xset command:

xset b off

Running the xset command will suppress the bell by the X Window. By the way if you're trying to run this command on a Solaris machine on Sparc, the command is located in /usr/openwin/bin directory (a rather unusual location if you're coming from Linux or other Unix background). You can of course put this command into your shell profile or rc script to disable the bell automatically each time you perform a login.

If you're a bash user, there an even more elegant solution that will work not only under X Window, but also at the terminal console. Just add the following directive to your .inputrc file in your home directory:

set bellstyle none

Don't forget that you have to add the directive to .inputrc and not to .profile or .bashrc, because otherwise this directive will not work.

Hmmm, it looks like Sun is getting serious with PostgreSQL database and packaging it with Solaris 10. In this news story Sun is reported to have migrated a customer off of Oracle/Linux combination onto PostgreSQL/Solaris with much success. I'm sure this sort of move is not going to gel very well with Oracle, who has been a long standing Sun partner. And for a good reason - Solaris has always been the #1 deployment platform for Oracle with almost 2/3 of all Oracle deployments going on to some version of Solaris. But Sun's move toward open source databases to bolster its platform is easy to explain and Oracle is culprit undermining the relationship. The relational database behemoth does not proclaim any loyalty lately and instead of keeping the relationship strong with Sun, Oracle decided to ride the Linux hype wave with its "Unbreakable Linux" campaign. I'm not sure how successful Oracle is going to be with Linux as the platform of choice in the long term, but it is still looking like Solaris is the way to go if you're serious about having a solid platform for your database. This slight rift between Sun and Oracle is making the game actually more interesting and I hope Sun gets even more serious about bolstering PostgreSQL into a more competent contender against the likes of Oracle and DB2. As a matter of fact I would expect Sun to integrate PostgreSQL into already solid Java Enterprise System stack of middleware products that is missing only one piece - a database. That would at least make the product more visible to potential customers and integrating the PostgreSQL with other products in the Java Enterprise System stack would definitely increased its acceptance at least between Sun faithful.

News stories announcing that some big institution lost backup tapes containing private data for millions of identities became pretty common nowadays. And it is hardly surprising considering that there is always room for mistake when number of tapes shuffled back and forth is large enough and performed frequently. What is surprising that the the take-up of encrypting the data before it is stored on tape is has not been very rapid at all -- it seems like the majority of tapes floating out there still have all the data on them in easily readable formats. Even though there is really a lot at stake each time you loose a tape (which with todays capacities can contain millions of records easily), the storage and archiving practices are historically slow and conservative in respect to reacting or embracing change. Even though on the scape of an enterprise-wide backup system the switch to encrypting data on tape is not a trivial exercise, on a smaller scale though encrypting the data before it hits the tape is very simple. On Solaris 10 for instance you already have all the tools you need to achieve this. Solaris 10 now ships with a wonderful crypto framework out of the box, which makes most of the encryption/decryption activities pretty much trivial.

In this case lets assume we want to encrypt all data produced by ufsdump while we backup some particular filesystem on our machine. For these purposes we will rely on arcfour algorithm supported by Solaris crypto framework. Arcfour is particularly well suited for this sort of task due to its comparative lightness in respect to CPU consumption needed to perform the encryption process. And in case of system backups this is particularly relevant -- you need the lightest encryption algo possible that is capable of doing the job when backing up gigabytes of data. Long story short, on Solaris you can be running secure encrypted back in almost no time flat without relying on any additional equipment or software. So here is how you can do it:

1. Create a 128 byte key to be used to encrypt and decrypt the data. You can create the key manually picking a sequence of bytes that makes sense to you, but otherwise a quick and more efficient way to do it is to generate a random key:

# dd=/dev/random bs=128 count=1 of=/etc/mykeys/backup.k

It goes without saying that after generating the key you should keep it secure.

2. After the key is generated you can immediately start using it to encrypt the backups going to tape:

# ufsdump 0f - /var | encrypt -a arcfour \
-k /etc/mykeys/backup.k | dd of=/dev/rmt/0

That's it, the data stored on tape will be secure from prying eyes, unless of course someone has your key. And you don't have to worry as much if the tape gets lost.

3. In order to decrypt and restore the data on tape you will have to use the same key:

# decrypt -a arcfour -k /etc/mykeys/backup.k \
-i /dev/rmt/0 | ufsrestore xvf -

Very easy and best of all it won't cost you a penny to implement this feature.

Once in a while you might run into a situation when an application process is not behaving correctly, hangs, or leaks memory gradually ballooning in size. Usually it is an indication of a bug in the process and most of the time you would need to get in touch with application developers with sufficient evidence to describe the suspected bug. Since overwhelmingly sysadmins don't like developers poking around the production machines and trying to debug a process in production, the best way of providing the "evidence" in these sorts of situations is to provide a core dump of the process which should allow the application developers to evaluate the state of the process and hopefully draw some conclusions from that. On Solaris it is a trivially simple matter with just invoking a gcore utility on the process id and bam, you've got yourself a shiny new core dump from the process. On HP-UX on the other hand this matter is not so simple, since there is no utility like gcore provided with the OS. Thankfully there is a way out of this situation, but you have to rely on the helpful hand of gdb debugger to accomplish this task. Starting with gdb 3.2 onward there is a dumpcore command in the debugger that will write out a memory image of the process to a core file if invoked on an attached process. For instance assuming we wanted to dump core for process id 1234 on an HP-UX system, here is the sequence we would follow:

# gdb
HP gdb 3.3 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 3.3 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.

(gdb) attach 1234
Attaching to process 1234
No executable file name was specified
(gdb) dumpcore
Dumping core to the core file core.1234
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: , process 1234

Well, here you go -- you've got yourself a core file from the running process. Now ship the core fie to the application developers for further analysis or if you're up to the task, debug it yourself.

I came across an interesting nuance in Solaris 10 that seems to have been been introduced into the name resolution process with the release of version 10. Apparently the /etc/inet/ipnodes database is now always searched before /etc/hosts database with DNS configured. The reason it matters is that in my testing and development environment I used to overriding the fully qualified domain name of production machines with the IP address of the development environment in order to have both environments being identical in terms of naming (with the exception of IP addresses). As you would guess this was done the old fashion way by inserting custom entries in /etc/hosts, which would resolve a given name to the desired IP address before the resolution process would hit other naming sources (DNS). With Solaris 10 it was a rude awakening when the OS started ignoring the entries in /etc/hosts and instead started picking up the name resolution from DNS - just the opposite from what I wanted to do.

Well, as it comes out with Solaris 10 the /etc/inet/ipnodes database is searched before the /etc/hosts database and therefore implicitly a name would get resolved via DNS before hitting the /etc/hosts. In other words the current name resolution sequence when DNS is configured (nsswitch.dns) under Solaris 10 is as listed below:

1. /etc/inet/ipnodes
2. DNS
3. /etc/hosts
4. DNS

So moral of this story is that if you need to override the name resolution in DNS with a local entry, do it via /etc/inet/ipnodes instead of /etc/hosts.

Grapevine is talking that there is a good chance that HP will announce the HP-UX 11i v3 on Feb 16. The reason for such speculations is the fact that HP just announced a press conference that will be held by Ann Livermore, Mark Hudson, and Nick van der Zweep all of which are executives with strong ties to the Servers division at HP and most notably Virtualization and Utility Computing division in case of van der Zweep. I would not see this collection of HP's big wigs holding a press conference for no other reason but to make some sort of an announcement related to either HP-UX or the Itanium platform. And since there isn't anything interesting on the horizon in relation to Itanium, that leaves us only with some sort of an announcement related to HP-UX.

If it is indeed the HP-UX 11i v3 announcement that is in the pipeline, it begs a question why HP has been so shy about talking about and god forbid promoting this new HP-UX release. Or is it yet another time for HP having nothing to promote? Did HP fail on delivering yet another set of promised features? Feb 16 is going to be an interesting day.

SANS institute produces and publishes a "survival" time statistics based on the empirical data gathered from its storm centers. Survival time is basically the amount of time that it takes for an unpatched machined placed on the wide open network to be hacked in. Well, as it comes out in SANS report the survival time for an average Microsoft Windows machine is 237 minutes, which means on average a new shiny install of Windows exposed to the Big Bad Internet will fall into the hands of hackers in a matter of just under 4 hours. For an average Unix machine (I know it is too ambiguous of a definition for the variety of Unix flavours out there), the average survival times is 3894 minutes, which is at least 16 times more respectable than Windows. But a bigger moral of the story is that it is big bad world out there in the vast expanses of the Internet and no one is completely immune if left completely exposed.

Sun just issued an advisory for a security issue in Solaris 10 that can cause a Denial of Service (DoS) attack against machines running the latest version of Solaris. It looks like this vulnerability in the Solaris 10 network stack in the ICMP protocol handling process in particular allows attackers to panic the system by issuing a specially crafted ICMP packet to a vulnerable machine. It looks like both x86 and SPARC versions of Solaris 10 OS are effected by this vuln, but you should feel safe if you're running an older version 8 or 9 of Solaris. You can identify if your machine was panicked by this ping of death by simply checking the panic stack trace, which would look like the following:

ip:ill_refrele+0x8(0x0, 0x0, 0x0, 0x1010)
ip:ip_output+0x149c(0x0?, 0x6000864f2c0?, 0x60001bcede0?, , 0x2)
ip:ip_wput(0x60001bcede0, 0x600053ac140) - frame recycled
unix:put+0x1c0(0x60001bcede0?, 0x600053ac140)
ip:icmp_inbound+0xb88(0x60001bcece8, 0x6000864f2c0, 0x0, 0x30000c31268, 0x0, 0x0, 0x0, 0x1, , 0x2)
ip:ip_proto_input+0x56c(, 0x6000864f2c0, 0x600086e7500, 0x60003a24ed8, 0x30000c31268)
ip:ip_input+0x7d0(0x30000c31268, 0x0, , , 0xffffffff)
ip:ip_rput(0x60001bcece8, 0x6000864f300) - frame recycled

Sun at this point wouldn't divulge into disclosing which flags or which combination of flags in the ICMP packet that cause the panic to occur, which is understandable. Sun was quick to release a patch to fix this vulnerability, so if you feel you need to protect your system from "ping of death", then you should download and install patch 118833-28 for Solaris 10 on SPARC and patch 118855-28 for Solaris 10 x86.

The full advisory from Sun in regards to this vulnerability can be found here.