Recently in Random Category

From Wikipedia:

"The UK MoD reported that some of its major systems and desktops were infected. The worm has spread across administrative offices, NavyStar/N* desktops aboard various Royal Navy warships and Royal Navy submarines..."

I have to ask myself, WHY?!?!?!?!?!

Imagine you are a weapons operator on board one of her majesties finest submarines, the alarm comes over the general announcement circuit followed by "man battle stations torpedo", and at launch time there is a problem because the launch console cannot resolve the DNS query for the weapons launch console -- all because of Conficker!

This may sound like an unrealistic scenario, but I'm not so sure that it is. As a matter of fact, I think it's a very realistic scenario. Why, because you cannot stop oblivious people from clicking on things in MSN like, "Hey dude, how's tricks? Check out these pills! They helped me get lucky this weekend, ROFL LULZ!!!1!!!11!!11. Click here to check them out."

You cannot stop the same oblivious people from saving something on a USB stick from the same now infected computer and bringing that down to the boat no matter how hard you try. Why? Because these guys are gonna bring down pics of their naked girlfriends (or boyfriends) and letters from mum and anything else whathaveya.

In turn, you cannot stop the same people from finding SOME WAY to get those files on to the network. Yes, it may be a long shot that it ends up on the same VLAN or air-gapped network for weapons systems, but it only takes one nub to do it and then someone is gonna look stupid -- as if they don't already.

This follows the disturbing news from last year of the Royal Navy to up and use M$ Windows Battle Star Galactica Edition on warships (including submarines). I don't know what committee of half baked morons decided to approve something like this, but obviously there is a whole chain of people that were sleeping while this decision was made, or their input was simply ignored. Most likely it was the former.

Submarines require the utmost in quality. Some things, like people's lives and national security, require more attention than other things. I wouldn't step foot on any submarine that relies on code probably written by a bunch of .NET software developers that have not the first clue how an operating system assigns memory or how those processes are scheduled -- not to mention a base operating system from a company with wreckless security and quality nighmare of a record.

"Emergency blow!"

"Shit Captain, the BCP just blue screened!"

Godspeed to you sailors. 

 

The fact I would even post this suggests that I am not an Oracle DBA. Shamefully, I attended the Oracle Administrator I course a couple years ago but am no better off because I just can't find the time. Anyway, I find myself having to fiddle with Oracle on and off beyond the basic startup, shutdown and writing scripts to replace my DBA. Yes, I must admit, I don't micromanage, I just automate it >:-}

I wrote some scripts some time ago to do various things such as setting Oracle's db_file_name_convert and log_file_name_convert in a larger project that used Oracle's RMAN to automatically duplicate databases. Some time later, we added another database to the cluster. This exploited a "bug" in the code (mine, yes) which set the first parameter to db_file_name_convert empty. So, the bad entry in the spfile looked like 'db_file_name_convert = '', '/path/to/db'. Just to save some time, I will recreate what happened:

SQL> alter system set db_file_name_convert = '', '/opt/ora-three/DEVEL3' scope=spfile sid='*';

System altered.

SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORA-01078: failure in processing system parameters
LRM-00117: syntax error at ',' at the start of input
SQL> 

For some of us, you're in trouble. Why? Because looking up those error codes reveals very little information. After digging around for a while on Google, there were hints to something foul in the spfile. I opened up the spfile and noticed that erroneous line db_file_name_convert.

From previous experience, you cannot edit the spfile with a tool like vim because it is a binary file and vim somehow fouls this. I thought I'd be clever and do it with sed. But, alas, this did not work, either.

ORA-27046: file size is not a multiple of logical block size
Additional information: 1

The easiest way to fix this is simply use good ol' strings to make a pfile from the spfile and recreate the spfile. Apparently, besides the binary padding, the spfile is the same as the pfile. Maybe some Oracle DBAs will have something to say about this:

$ strings spfileDEVEL3.ora > pfile.ora

Now, edit this file with your favorite text editor and fix the erroneous line because a pfile is a plain ol' text file. After that, recreate the spfile from this pfile and start Oracle.

SQL> create spfile from pfile='/opt/ora-three/pfile.ora';

File created.

SQL> startup nomount
ORACLE instance started.

Total System Global Area  788529152 bytes
Fixed Size		    2076008 bytes
Variable Size		  230687384 bytes
Database Buffers	  549453824 bytes
Redo Buffers		    6311936 bytes
SQL> 

On the way to work this morning -- and just outside my flat -- I spotted the Google street view car. Seems this one was a little Vauxhall with an even bigger panoramic camera array mounted prominently on the roof. The image below I snapped with my mobile camera while I was walking, so it's not the perfect photo. However, you can still make out the Google logo on the door:


Sightings of Google's controversial vehicles are nothing new. On its début in London, it was widely publicized with one being stopped by the police. I for one welcome our enterprising overlords -- it's far more comfortable than the real "big brother's" never-ending installation of video surveillance on every street and in every tube station. Some day when you have nothing better to do, spend time cruising the virtual Google street view, it's amusing what you can find frozen in time.