January Thaw

I learned a long time ago there are things I can control, I can do something about, or things that are going to happen, and all I can do is focus on what I can affect.

So of late, I've been working on looking for and applying for jobs.  I've used a lot of web sites over the years, and there are some that are really useful, and some that sure look like they might want to be some day when they figure out what it is they want to do.  Linked-In certainly seems like the second type.  

My challenge is, with well over two decades of IT experience, my resume leans that way.  Which does mean that I've got a great deal of experience testing things, finding the one comma or minor detail that seriously affects a very long line of other operations.  For example, one task I was given at a new job was figuring out why a particular operation worked sometimes, and didn't at others.  I often joke that there are some problems that are "location problems."  That is, when I'm not there, it won't work.  When I get there, they work just fine.  And while intermittent failures are among the most frustrating to deal with, it's inevitable that something changed between when I wasn't there and when I was there.  

In this example, I was working with a database server issue.  Our application ran on Microsoft SQL Server.  Back in the early days of computing, the first "killer application" was a spreadsheet called Visicalc.  That is, it ran on the Apple ][ series computers.  People would buy them and bring them into the office, and they gave people an incredible amount of power to evaluate "what-if" questions.  

Visicalc on the Apple led to Lotus 123 on the original IBM PC, which was succeeded by Excel today.  It handles lists of information easily.  And it also hides what is probably the third killer app family, databases.  In the simplest of terms, a database is a list of information that looks like a table, or an Excel spreadsheet.  Where the real power comes from is when you need to combine several tables.  You may have one table that has all of the client names for your organization - the company's name, address, phone number, all the basics.  

Then you have another table of contacts.  The contacts are all people who work for your clients.  Rather than make a bigger table with the address, phone number, and contact's name, what you can do is put their names in a new table, with a link to that other table, the company table.  Rather than store all of that information in two places, you have one place for each.  Your contact table will probably have the person's name, and a few other specific details - like their direct phone number so you don't need to go through someone else, if they have a direct number.  You may enter their email address, the name of their wife, their kids, their birthday, and other information.  

With two tables, what you can do is set up a "relationship" - Joe Smith works for Smith Company, so you can connect the two.  Now, if his co-worker Mary Morris leaves Smith Company and goes to Jones Manufacturing, you can change her employer - but her birthday, her husband's name, the name of her kids won't change.  The email address will, but in a well-designed database, you'd actually have three tables - one with company information, one with personal information, and one with professional contact information.  If you wanted to send a birthday card to Mary after she switched companies, the professional contact table would have a date that Mary left Smith Company, a starting record for Jones Manufacturing, and her new contact phone number and email address - but the Jones Manufacturing office wouldn't move  just because she joined.  

Databases like SQL Server often contain hundreds of tables.  Our application had tables for inventory, tables for sales information, and lots of other details.  It was used by sales people who would be traveling from site to site.  Back in the early 2000s, cell phones were pretty new, internet through thin air was very expensive.  But our application did permit the user to open their computer, fire up the application, and interact with the data.  It would show sales information, recent orders, contacts, anything a sales person would need to know.  They could make their sales calls from their home office, their business site, or even sit down on the other side of a table from the client - if they had access to the internet, they could update everything.

Since full-time internet access wasn't guaranteed, we used another complex operation which was called "replication".  People would update their local copy of the information, then when they got on-line, their local database would talk to the server.

Sometimes.  

Sometimes it would, sometimes it couldn't.  It would throw off a weird error that didn't make any sense at all.  So I started my research.  And I discovered quite a few things.  Which is where the world got all the more complex for me.  

Back in the early 2000s, we were just getting a handle on what needed to be secured on computers connected to the internet.  I'm a Boy Scout, so frankly I'm a bit naive when it comes to breaking and entering, stealing information, and doing various nefarious things.  So I do tend to rely on experts.  Which was where I learned a whole heck of a lot.  

To keep things reasonably simple, our computers do several things when connected to the internet.  They may be checking for new emails, surfing web sites, watching videos, all sorts of other things.  When they first started to build the internet, they knew a lot of systems would want to use it to communicate, so they started giving certain systems assigned pipes.  When you connect a computer to the internet, it's really better not to think in terms of an electrical connection (which it is), but rather think of it as a great big fat pipe.  Inside that fat pipe are thousands of individual thin pipes.  They carry specific signals.  Some only flow in one direction, some have traffic back and forth.  Some systems use only one or two, some may use a half dozen or more. 

Huh?  Well, to simplify - if you're using good old Outlook to get email, it sends a signal out a specific pipe to ask the server if there's any new messages.  The server responds.  That's after you log into the server - not the first time in the morning, but every time it asks the server if there's anything new, it logs in - sends your username and password, and the server confirms it's correct down another pipe.  Then the messages come back to your computer.  

When you look at a web site, that content comes in a different pipe, that your browser then displays.  Getting back to my example, the software we used needed to connect to it's remote partner, then confirm whether any changes occurred.  Then it would send the changes from the local computer to the server, and download the changes from the server to the local computer.  

But wait a minute, I hear you saying, what if the same thing changes?  That's where it gets a little tricky, but fortunately, that thought occurred to the folks who wrote the software.  There was a part of the program written to check to see if the same record had been modified, and if so, it sorted out which one was the newest - and if it couldn't figure out what to do, it would generate a notice to someone to review and figure out what needs to happen.  

The problem we were running into was that the two computers could see one another.  They could say hello, see that changes needed to be updated, but couldn't speak to one another.  That's because a couple of the pipes that they needed to use were blocked.  That's how some computer security works.  

Early on, it didn't occur to anyone that someone wishing to do evil to these systems might ever get access to them - it used to be that you had to have physical access to the computer, or a terminal connected to it, to do harm.  When the internet came along, all of a sudden the entire world might be able to have access to any system connected to the internet.  After I left college and was working at a Software Etc. where I eventually became a store manager, we sold lots of computer books.  Most of them were all about how to accomplish something, but one caught my eye, and I ended up buying it - The Cuckoo's Egg by Clifford Stoll (No, I haven't signed up as an Amazon Affiliate, I don't get anything if you buy a copy of this book, but if you haven't read it, you should).  It's a very detailed account of how Mr. Stoll, an astronomer, ended up running a VAX (A computer I was incredibly familiar with) at a science site, discovered a hacker trying to use his computer to get information, and used it to trap an early international hacker who was actually arrested while in the act.  

The point of this is that I learned that we needed to open up two ports in most firewalls (If you look at this list, it shows ports 1433/1434 for MSSQL Server communication).  So once we opened up those ports, everything worked well...  Until shortly after September 11th, 2001.  

Tuesday morning, September 12th, I came into the office and learned that there was a problem with our application - and all other applications world wide running on Microsoft's SQL Server.  There was a malicious process that was corrupting any computer running SQL Server, connected to the internet.  Because some twisted individual wrote a script and used our collective stupidity against us. 

Back in 2001, just a few months after the Melissa virus roared through email servers that allowed Outlook to connect, Nimda became a gigantic pain.  To talk to one another, two Microsoft SQL Servers needed to know and share passwords.  Back at the time, if you had three SQL Server computers, they all needed to use the same password for the "Admin" user to connect one another.  And because we were all white knights who never did anything wrong, we used the same password - which Microsoft recommended in their documentation.  So I could disinfect a computer and reinstall SQL server, connect it to the internet, and within 45 seconds, it would be infected again.  

So after some experimenting, I built a cable and loaded up a laptop.  I would walk over to an infected computer, unplug the network cable from the back of the computer, and plug in my new network cable.  It was a "crossover" cable.  Most of the time when you connect a computer to a network, you connect it to a device that receives a signal on one wire, and sends communication out on another.  Most modern network cables use eight wires, and if you plug two computers together with a normal network cable, they would both use the same wire to Send, and the same wire to Receive.  A little bit like connecting the mouth of one person to the mouth of another, rather than sending the signals from one's mouth to the other's ears.  

The cable I made was a "crossover" cable - it connected the send signal from one computer to the receive on the other.  I disinfected the messed up computer, downloaded a clean installation of SQL Server from the laptop, and then went into the software and changed the Admin account password.  Then I reconnected it to the internet.  Other infected SQL Servers could see it, but they couldn't send it the bad information to mess it up.  Disinfecting the twenty-plus computers in the office took the rest of that week, but when I passed my instructions on to our corporate home office IT staff on how to get rid of the problem, I got a call from the head of corporate IT, corporate Security, the head of operations, and the CEO.  They really appreciated the work I'd done - and I told them, honestly, it was nice to have something to focus on besides the horrible news coming out about the terrorist attacks.  

It really was - I could focus on resolving concrete problems I understood, rather than worry.  So I'm focusing now on sending resumes, looking for jobs on Indeed, and I'm really only checking Linked-In every week or so, because their job links aren't very helpful.  I've managed to filter some of the stuff I don't need to see, but it's still a lot of bushwhacking to find the good stuff.  So I'm still here, still digging for health care jobs, because the detail-oriented skills I've developed help make sure I'm doing the health-care stuff right.  I enjoy it, and I like making a big difference for people.  Or at least, did.  I'll keep looking.