Is it working?

Is whatever you are doing working? 

That seems like an easy question, but it's a lot harder than is usually assumed.  It can be a problem of undefined success criteria.  When you set out to define your whats-it did you clearly define the success criteria?  If I'm guessing correctly you probably didn't.  

So why don't you sit back and define your success criteria.  Is this one of those full fledged plans, or just some concoction running through the back of your mind.  Because executing those is a pain in the ass. Turning that twisted hunk of an amorphous idea into reality is the stuff dreams are made of.  But with the plans you got going right now, it might as well be a pipe dream.  

Cue another drug reference.  Pipe dream: something that a person ingesting large amounts of drugs would imagine as the drugs run through their system.  Assumed to be something magical and fanciful.  

Might as well be a pipe dream with the level of pre-planning that went into this thing.  But you say "I know what I'm doing.  I've been thinking this out for years." And that's the problem.  You've been thinking about doing this thing, and not actually executing.  You've been listening to the collection of people that tell you it's more important to dream big dreams.  Sure, those are great.  But until they are executed they are worthless.  

Dreams without execution are worthless.  I'd almost say they are worse than worthless.  They are the half-thought ideas that are dragging you down when you should be going up.  You know what makes you feel better?  Executing some of those dreams.  Better to write a book that sells one copy than never finish the book.  Because it could sell a million copies.  But you will never know until you get the idea out of your head.  

Now that we've got that bit in order... How do we tell if this thing we want is actually succeeding?  Go back to the idea you created.  Go back to your original document.  Your original document should contain a few intervening steps that show where you are going, and how to guess that you are on target.  Did you complete goal one?  Are you talking to the people about your project?  Are you marketing it well?  Or at all.  I hope you are marketing it.  Are you making it a little bit closer to the finish line?  

Or are you stuck in a nebulous la-la land where you do things that don't really matter?  Because that's the way to tell if you are going the right direction.  Are you going somewhere and getting some sort of result.  Are there more words written?  More subscribers?  More content produced?  An income?  More income?  More hits to the website?  More comments?  

And which of those things is actually worth measuring?

The hard question about hard questions is that they are hard.  Which sounds like the stupidest sentence in the world.  Let me ask the question in a different manner:

Does it matter if you wake up at 5 am?

There's a lot of posts about that.  Lots of rise and grind people in the world who declare 5 am is the magic hour.  I do it.  I have been doing it for years.  But is that really the secret?

What about the midnight people?  Work until 1 or 2 in the morning after the hustle and bustle of the day is over.  That's the real ticket.  Or is it?  

I'll give you a real big hint: the time of day doesn't matter ONE BIT.  5 AM.  3 AM.  4 AM.  11 PM.  12 AM.  The specific time doesn't matter at all.  

Now let the hate mail flow...

What does matter?  That you have some time in every single day scheduled out to work on whatever it is you want to work on, free from distractions and free from the interruption of the rest of the world.  Freedom to work on what needs to be worked on without having to answer the beck and call of the world.  

That is what matters.  The time does not. Regularity matters.  Isolation matters.  Working on the important thing matters.  

All the rest is junk.

So how do you measure whether this thing is working or not? 

If I knew that...  well.  I wouldn't be here, trying to figure out the same thing.  

The Brilliance of Companies

I've worked for various companies over the years, and I've realized a few things.

The most important one is this: the crowd is not smarter than you.

Perfect example of this kind of logic: we don't like situation X because of the way we did this.

Let's go build another one with the same problem as X.


I wish I could be more specific, but it's an ah-ha moment when it happens.  It's the smartest people in the room complaining for 20 straight minutes about a design they created, then refusing to fix it in the next new design.

People: this happens everywhere.   The Abilene Paradox is still alive and well.

want to

Friday, I was at a store, listening to the people talk as I worked.  I was installing cellular backup devices.  But that's of little consequence to the story.  Anyways, one of the people in the store was talking about how they didn't want to go to work.  In the end, the person did show up to work.  I guess that's good.

But my real thought about this: when did coming to work become a question of something you want to do? 

I guess back when I was young, I had that possibility that I could have called in for work out of not wanting to go.  Back then, I didn't have paid time off.  No vacation.  If you wanted time off, you didn't go to work.  But you didn't get paid when you didn't show up. 

Getting paid has always been my interest in going to work.  If I didn't need the money, I simply didn't work.  That was just the way it was. 

 Work has never been something that I let the words of "want to" into my vocabulary.  It was simply a matter of "you are going".

"Want to" never entered the equation.  

How did we get here

I work for an established company.  The company has changed since I've been a part of the company.  Partly because I keep driving change.

Why in the world would I want to do that?

And that, is the essence of this tirade.

It's very easy to sit back and say you are an original thinker.  It's also very easy to sit back and criticize someone else's plan.

So I present the Dale Carnegie/man solution.  The next time you find something that doesn't make any sense at work, don't gripe.  Seriously.  Don't gripe.

Ask people why that policy is in place.  Ask questions about how the policy was put in place in the first place.

If the answer becomes "because that's the way we've always done it" then you are ripe for revision.

"I don't know" is also a good one to work on.

Whether you believe it or not, there are many policies and procedures that end up "because that's the way its always been done".  And there is a lot of "I don't know" in the procedure.

So... once you've find something like that, figure out whether you have the ability to change it.  If you are in IT, you aren't going to change marketing without some deep evidence.  You aren't going to change operations.

Initially, look to change your own department.  Because then you are dealing with people you know and policies you have internalized.

There are two ways to approach producing the change.  The first is to get permission.  The second is to implement and ask forgiveness.

I usually go with the second approach for two reasons.  1) No one understands the need to adjust the policy, and rocking the boat is probably not going to happen.  2) Your idea might sound great on paper, but suck in implementation.

So implement the easiest possible answer to the problem, and start using it.  You might come to the conclusion that your idea sucks.  Good.  Kill it then.  Go back to the drawing board and come up with a new solution to the problem.

If the idea is awesome, show other people.  Get them to start using your idea as opposed to the other policy.  See if people gravitate towards the new policy or the old.

I ended up implementing a Cacti server in this way.  I think it was a great idea, but no one uses it other than me.  So to me that's a partial success.

What I've been working on recently is a different way to document.  It's mostly a combination of PHP, Apache web pages, and a MySql database.  So far, the implementation doesn't work.  But the idea seems valid.  So I'll keep working on it until the idea is operational.  Documentation is always the hardest part of the IT world.  The second hardest part is designing a knowledge base that people are going to use.  You want a solution that is easy to implement and follow.  And a webpage seems to be a good idea.  But the non-technical parts of my team aren't going to run queries against a database.  That's beyond them.  So I have to provide a solution for them.  And that's what this approach is.

Try it.  You may find the cruddy company policies go away.

And you may find yourself with a load of new work.

Either is good.

Happiness is...

I've heard people discuss how a store experience can make a customer happy.

If you hear someone selling this, run the other way as fast as possible.  They are disconnected from reality and will not solve your problem.

First, happiness is a choice.  It has nothing to do with the circumstance.  It has nothing to do with what you have or don't have.  You choose to be happy.

If you are not choosing to be happy, you are probably basing your happiness on external factors.  As such, you are probably either affected by stuffitis or you have no direction in life.  You buy stuff to make you happy, and wonder why you aren't happy.  That person has confused happiness with temporary amusement.

Second, don't try to make your customer happy.  See point 1.  You are not a psychologist (unless that's your business. I'm assuming most of you aren't).  Try to engage and entertain your customers.  But don't try to make them happy.

Because you can't make them happy.

That bears repeating again.

You can not make your customers happy.

Engage your customers.  Entertain them.  Delight them.  But realize all of these are temporary, transitory emotions.  They fall suite to whim just like everything else.  But that just means you have to keep bringing your A game every time.  Because every single experience is a new opportunity to engage a customer.

Wayne Hose Assignments in Base 39

So POP discount wouldn't work.  And POP discount is something the company wants working.  We were dealing with a Commander, running a base 39 application.   Verifone had told me I needed to set everything up for Wayne auto configuration.  My pumps are all 3+1. In layman's terms, that means I have two physical hoses on the pump.  One hose distributes 3 grades of fuel.  A 2nd hose distributes another grade of fuel.  In this case, the 3 represents Nolead, Plus, and Super.  The +1 represents Diesel.  Nolead and Super are pure grades, and Plus is a 60/40 blend.

Wayne says you should set up a 3+1 as Diesel, none, none, Super, Plus, Nolead.  Fuel assignments worked great, but POP discount didn't work

A short discussion on acronyms.  POP can either mean Point of Presence, or Point of Payment.  One refers to a gas pump.  The other refers to a pin pad.  At one point, I knew the story of who created two same lettered acryonyms in the Verifone world.

Anyways, the answer.  Or maybe not.

I asked a person who went to VASC school, taught by Verifone itself, back in December. Dude aced the test.  He had no idea what Wayne auto configuration was.

So, Verifone told me the hose assignment should be set up as Gilbarco normally set them up.  Gilbarco setups up their hose assignments on a 3+1 as Nolead, Plus, Super, none, none, Diesel.  Now, Verifone told me to use the "Gilbarco" method to assign hoses, but don't skip positions.  Great, so we just missed true Gilbarco setup.

So, the new hose assignment is Nolead, Plus, Super, Diesel.  I go check pumps.  And everything has hose assignments, but it's not right.

In the midst of the drive back to the town, I figure out the answer, and its back to SFC days.

SFC is the Smart Fuel Controller.  Imagine a box that is way too small fitting way too many wires and is a bit too complicated.

So...  Change the hose assignments to (and here's the real answer)....

Diesel, Super, Plus, Nolead, none, none, none, none

So...

That's it.  

Correlation/Causation

I think there are two big difficulties in the IT world.  Both are especially relevant to the C-Store world.  One is turf wars.  Turf wars are when departments are more concerned with covering their own behind rather than working with other departments.  You can only hope to fix that one, but it's not likely going to happen.

  The second issue is this: correlation does not equate to causation.  In laymans terms: just because two things happened around the same time doesn't mean one caused the other. I had a failed Verifone Commander install a few days ago.  I could never get the gas pumps to talk.  They happened to be Gilbarco Advantages.  This was my first site with more than 16 pumps.  Interestingly enough, this was my first site with more than 12 pumps.  That number becomes relevant in a minute.

Anyways, credit processing worked fine.  Ran like a champ.  But I couldn't get the pumps to talk.  The site was Gilbarco with a PAM 1000 and 2 D-Boxes.  I spent a long time trying to get it to work, but never could.

So I decided to put the old equipment back in place, and attempted to get it back to working.  Pumps still wouldn't talk.  I finally called in some pump techs, and we got 5 of the 10 dispensers communicating.  We decided that was good enough for now.  After the weekend, I called the pump company and scheduled them to come install the site.

The install was done in 4 hours.

What happened?  Remember that magic number 12 I was talking about before?   The PAM 1000 can only address 12 pumps with a single board.  You can add more boards to talk to more pumps.  But you start over the pump addressing.  This is not information I knew prior to installing.

So, when I plugged 16 pumps into one board, nothing would talk.  Why?  Because there were duplicate addresses out on the system.  Not only that, there were multiple duplicate addresses.  Because fueling position 13-20 had internal pump number of 1-8.

The fix (had I known the situation) would be renumber the pumps.  Which is what the pump company did.

Or, start over on the 2nd fuel board at position 13.  That would have solved the issue quite easily.

So where does causation/correlation come in to this argument?  Simple.  The belief that changing out the point of sale system caused the pumps not to communicate.

I'm not a pump tech, and that's rare in this industry.  I am a Verifone VASC and a CCENT, but my knowledge stops at the 2 wire going to the pump.  I have to work with other pump techs and hope they know what they are doing.  And hope that they aren't having turf wars.

As a footnote to the story.

As I was leaving the parking lot, I noticed the site was changing gas prices.  After getting back ot hte office, I had conversations with 4 different people about why the price sign wouldn't change, and no one seemed to believe what I was saying.  The gas price sign was changed by a key fob.  Always has.  I didn't mess with that during this install.  But now, the gas price sign wouldn't change.

It took a bit of convincing to for people to realize that the gas price sign was at fault, not the point of sale system.

Anyways...

Back to SNMP and other things

I used to hate SNMP.  I’m not sure I still don’t.  It’s been annoying to set up.  I’m still fighting with SNMPWALK on SNMPv3 and getting data from a Cisco router and switch. Eh well. I’ll get into that at some other point.  

I have to admit Cacti was one of the better than I thought it could be.  I followed the right instructions and have started doing some SNMP polling and producing some decently relevant graphs on information someone in IT would think could be important.  Luckily, I happened to set it up on a site that had Internet issues later that day.  It worked out great because I ended up diagnosing the issue while trying to connect to my Cacti web page.  Turns out there was interference on the network in the area and the site was dropping about 18% of packets.  Which explains why they were having network connection issues. 

 The other thing I keep looking and thinking about is network security.  Which seems to be something everyone says they need, but no one does anything about.  I pissed off a networking vendor because I told the person I wanted three single purpose servers instead of one multipurpose server.  Everything I've ever read on servers says one purpose per server.  Don't end up with a multipurpose server. 

Eventually, the server needs replaced.  And then you have numerous tools that need replaced or fixed in order to solve all the problems you used with that server.  I mean sure, the RADIUS / print / file server / new thing part two server is great.  But wouldn't it be simpler to have a RADIUS server that does nothing but RADIUS authentication.  Or a print server that does nothing but handle printing.  And then, when you need to upgrade that server you take down one function.  Instead of the 25 different things running on one server.  

I guess the second part of that conversation is "don't turn on any service that you don't need" on a server.  Great.  That's a lot simpler with a single purpose server.  The print server doesn't need to do anything but print.  The file server needs fat bandwidth to reach it, and that's about it.  Virtualize it all.  It's not like you need a physical server for all that.  

But what do I know?  

C# this time, and Lua

Well, after a bit of digging, I'm back into C#.  I'm looking at that because of the need to examine the current status of a network.  And I had something like that built in VB.net, but i couldn't figure out threading.  So the program didn't play nice or update very well.

Well, I found a few webpages and figured that out.  This post on dailycoding.com was one of them.  That really helped get the ball rolling, so now I can run a ping function in the background and invoke updates to get things changed during program execution.  I'm guessing that I finally learned something out of that one because the code had been stripped down enough to where there wasn't a huge collection of extemporaneous junk that needed beat past.  Is it that hard to write code documentation that gives basic understanding without having to reinvent the wheel?

Which brings me to Lua.  I started using some products from Digital Loggers.  Basically the Rack Mount AC PDU.  It's a great product with a great concept, but changing from Basic on the Web Power Switch to Lua on the Rack Mount AC PDU causes havoc.  All the scripting type stuff that used to be easy with the Basic scripting language now has to be rewritten from scratch.

Did I mention you have to fight past bad Lua documentation?  I'm not necessarily saying Lua has bad documentation.  I'm saying Digital Loggers implementation of Lua is a pain.

For example...

function test_display()
    DISPLAY "\1Percent %%\v"
    DISPLAY "\2Backslash \\\v"

    DISPLAY "\1%a\v" --  current Bus A

This is an example of some code provided to change the display.  

Great.  Can someone tell me where the variable name is in that code block?   I know the -- blocks are comments.  DISPLAY is a command to show something on the display. Got that working.  Great.  

Secondly, on the script bit I know the line \1% indicates the first line, and anything afterwards is printed out.  But where is the variable?  

So if I want to put in a wait function, and then display on the screen "rebooting computer", I have to write individual reboot functions for every single device.

I could just write a wait(time in seconds, device name as string) function and call that whenever I needed.  But as is, it looks like I'm having to write inline functions.

Joy.  That defeats the entire purpose of object oriented coding and complex scripting languages.

On Call

Part of my unofficial job title is trying to figure out how to solve fundamental problems.  Fundamental problems are those that cause a collection of other issues.  One such issue is replacing the battery pack in a Ruby.  Replace the battery pack, and then you have fewer boot fix issues.  Getting rid of Buypak 6.00.06 seems to be one as well.  Maybe Buypak 6.00.10, too.

Anyways, solving those kind of issues involves a lot of thinking and some decent analytic software.  We use SysAid for our helpdesk/ticket management software.  It works pretty good.  Anyways, looking at categories of service requests is hard when you have serial offenders of people who don't categorize or assign service requests.  When you've got 100+ open service requests, and around 60 haven't even been given a category, it's hard to deal with the real issues.  With that many open service requests, it's hard to even identify where the real issues are.

I guess I'm used to using intuition and on calls to figure out where issues really exist.  On call is a special time.  I'm not going to lie.  Most of the time, they suck.  It's a soul grinding time of 60-70 hour weeks of nothing but pure panic level.  Everything is a crisis and the world is always falling apart.  Very few of the crisis are real crisis.  But it's a necessary evil.

Almost every on call teaches me something.  Moving in towards network administration, I get less of the day to day breakage and problems that occur.  In many ways, that separates my time away from crisis to solving bigger problems with longer term solutions.  But it is hard to solve long term problems if you don't know what those problems are.

Its fundamental root problems that need solved to really make a difference in the amount of service requests.  If you don't solve those problems, then you don't decrease the work order load.  Is the issue training?  Or is the issue user error?  Some user error issues can be traced to training issues.  Others can be traced to bad software.  It's a matter of figuring out which is the real issue.

What does anyone else do to solve fundamental issues?  What about on calls?

Garbage In/Garbage Out

I’ve been thinking of the concept of garbage in / garbage out.  It’s a computer science concept.  It’s an interesting concept.  The idea is that a computer is capable of processing all sorts of data, not just good data.  So if you give a computer bad data, it will spit out bad results.  Makes perfect sense in the computer world.  But what about applying the concept to life? 

Seems perfectly applicable to me, but it’s hard to interpret what constitutes good or bad information.  The basic concept I’m trying is limit the type of music I intentionally listen to.  I find that it’s hard to maintain the correct mindset when being assaulted by lyrics that preach the wrong kind of information.

Building the concept of where I want to be in relation to where I am is only limited by what my mind thinks I’m capable of.  But when you feed your mind information telling it that something can’t be done, then you are defeating yourself.  Logically, your brain is sitting there telling you that the music you are listening to is not affecting you.  But it is, and the effect is incredibly subtle.  It’s something easy to test, though it requires a bit of discipline.  What I did was eliminate music with words from my day to day listening. 

I guess I spent too much time listening to people doing bad things to other people.  Or listening to music written by people who are convinced the world is out to get them.  Or those that think the world owes them something.  I’m generally more inclined to think the world is ambivalent to individual existence.  Life is not fair, or easy.  But that doesn’t mean there is plenty of great stuff to pull out of the world.  In the grand scheme of things, the individual human life spans a very short period and has very little impact.  So really, our lives don’t matter all that much.

But mentally, people don’t want to believe that.  They want to believe in the importance and reach of their life.  But it’s simply not the case for the most part.  So you get a collection of garbage thrown in your brain that tells you the wrong thing and leads you to the wrong conclusions.  And generally, these conclusions are very logical.  Andy Andrews describes it as “thinking logically to the wrong conclusion”. 

So my recent approach has been to take in less garbage with the hopes of getting better information out.  I recently took a 4 day weekend after 17 straight days at work.  I had to work 17 straight days because I had been focusing on solving the wrong problem.  See, there’s the right problem and the wrong problem.  If you solve the wrong problem, you have to keep solving the problem over and over again.  It just doesn’t work.  What I finally realized in those last three or four days was I could have easily avoided working 17 days straight if I had done the correct thing.  What I needed to do was document better.  If I had documented better, then I could have turned anyone calling me to look at the document in question and follow it to its conclusions.  If the document was incapable of producing an answer, then there must have been some other issue.

What good does it do to create wonderful systems that have no documentation or notes? 

The next steps

Now that the Routing and Switching class is over, it's time to get ready for the CCENT.  I'm aiming for that in the next month.  I was aiming for two weeks, but I can get a voucher for half-priced testing, so I'm going to go for the voucher.

That being said, let's go back to network security.

I had a AHA! moment last week on network security, and it leads me to believe a very large vendor does not really provide security updates.  They also have some serious problems with their code.  It's all Apache web server, but it's an unpatched version of Apache that still has some serious vulnerabilities.

About a year ago, or maybe a little less, I realized when we replaced a router, all of our internal vulnerability scans started passing.  It was weird.  But I didn't know what it could have been.  Over the past couple of weeks, I've been working on replacing their router with my own.  After breaking our internal vulnerability scanner for a couple of weeks, our vendor finally fixed the device.

About the same time, we ran into a situation where a location suddenly started showing up as failing when it had been passing.  Thinking back, during the intervening period we had upgraded the site and swapped out the equipment.  At that point, we had swapped out a router.  And suddenly the site started failing scans.

Not suddenly, but it seems like it.  So I started thinking about what could have gone wrong during the upgrade.  Everything is built from standard equipment.  The results are pretty predictable and cookie cutter.  So how did this cookie fall out of the cutter mess up?  We'd tried a different configuration with the router, and the site ended up failing internal scans.

So, why did this router fail and other pass?  It's pretty simple: access control lists.  There was an implicit deny on the VLAN with the internal scanner.

Now I know why my scans are all passing.  The door to the scanner is closed.  And the equipment we're dealing with is no way near as secure as we thought.  All because of Apache.

It's also the realization that I can fake a passing scan in less than 30 minutes by simply throwing an ACL in every single router we have.  It'd be easy.  I already know the syntax.  Come to think of it, I could make it highly precise, so it wouldn't be something I could automate.

Anyways.

It just pisses me off that a multi-national company can't patch Apache.  Or, that I have to find the holes in their system.

Now, off to figure out Apache on my own so I can ramp up my network base lining and turn all the data I've collected into something usable.

I should probably write an article on that.   It's basically a combination of Java, mySQL, and some Ubuntu cron jobs.

Network Baselines

Like I said, I’ve been working on network baseline analysis.  Beginning problem is that I don’t have a baseline to begin with, nor do I have any way to examine the current baseline of the network.  So, I’m at a loss of where to start. 

I read one book where a basic baseline can be created by pinging all available hosts.  It’s not the greatest baseline, but it is the beginning, and it’s better than nothing.  What I’ve got is nothing.  So what I did is wrote a batch file using a FOR loop to ping all devices and print the output to a file.  After that, I ran an arp –a and appended that to the end of the file. 

So it’s not the greatest baseline.  But it does give me an idea of what standard network performance should be, at least as far as PING goes.  I guess the next part is trying to dump the information into a webpage or a database so the information can be examined later and compared to what it has been at various points. 

I guess I should probably add the ITILv3 documentation to my reading list.  The only problem is I’m not definite the ITIL information actually provides information on how to baseline a network.  I understand the basics and the conceptual theory.  It’s a matter of going out and doing the work.  And sorry, SNMP is not the way to baseline.  Everyone has it turned off due to the insecurities in the system. 

Just a quick look at Cisco, and the only encrypted version they have only supports DES.  So the options are send the data as plaintext, or send it as an algorithm that has already been replaced due to inherent weakness.   15 years ago, DES was cracked in 22 hours.  15 years ago, I was happy with 400 MHz processor running 128 Mb of RAM. 

In comparison, I’m writing this on a laptop with an Intel Core i5 running at 2.5 GHz with 4 GB of RAM.  Shot in the dark, but I think a couple of these suckers could crack DES in a day.  And if someone breaches your network and doesn’t get caught, then what is a day?  What is 10 days? 

Plumbers and Janitors

After a long trip around the Panhandle, I’m back at home.  I think I drove 250 miles today in my trek to get things ready for PCI 2.0 compliance.  It ended up being about a 10 hour day, but I enjoyed it.  It’s not every day you get to see good actions and results.  Maybe more on that later.

I find a lot of people in my industry don’t really spend the time or effort to achieve much.  Whether it be a chain or a person, they all seem to be drawn to mediocrity.  Either that, or I just don’t know what motivates them.  It’s very likely they don’t know what motivates themselves, either.  Just a lot of slouching towards the weekend with no real goal in sight, and no plan. 

I think I read in one book or another that the average IT person is best equated to a janitor or a plumber.  Both experience the same problem.  It’s in how they deal with the problem that makes their job descriptions different.  The problem in question for a janitor and a plumber is a leak.  A janitor spends most of their time mopping up the same leak.  They deal with the same problem over and over again.  A plumber finds the source of the leak, and stops the leak. 

With that idea in mind, I set out to be a plumber.  In order to be a plumber in the IT world, you have to know a lot and you have to begin to understand root causes.  If you are app’ing 5 Ruby II’s a month (not to be confused with a Ruby 2) due to lost program on a reboot, then you need to figure out how to solve the problem.   The solution is app the Ruby.  The problem is not the random power fluctuation.  The problem is the Ruby doesn’t hold on to its programming.  So the answer is replace every single Ruby battery pack.  Guess what?  You then forget how to app Rubys because they retain memory through a reboot. 

A bit busy

Can you say busy?  Yup.  It’s been.  It’s been the good kind of busy, though.  I spent a few days building a new Active Directory Group Policy.  Default templates work well, but they still need tweaked.  Not everything works out as well as you’d think.  Or at least not always.

I’ve been contemplating security in depth, and I’m pretty sure my old beliefs about security are still true: security is an illusion we like to tell ourselves to ignore reality.  It really is.  Several companies I’ve dealt with are completely clueless as to what they do and how they operate.  They are no more aware of their failings than the man in the moon.  It’s moderately hilarious, but only in the sick, sad sort of way.  I guess there is always a need to upgrade and move forward in a technology related company.  The inertia of doing nothing often gets in the way of real accomplishment. 

I think that will be it for today.  I spent a few minutes working on the Java StopWatch, but not enough to do anything of interest.   Yay.   I have large letters and I set up a font.  But they aren’t centered in the boxes so they are kind of ugly.   But at least the numbers are large and readable.

Friday post

On call can be one of the most hellish weeks.  Though finally moving to hourly, it can also be one of the most lucrative.  If I work my from 8a-5p with a one hour lunch break, I'll be up to 61.5 hours for the week.  I say lucrative, because 21 hours of overtime almost gets me to the point of a double paycheck.

After years of being on salary, I would not go back. Salary is sold on ridiculous lie.  The lie is the person on salary will get paid more even though they don't work 40 hours that week.  I'm not sure that ever happened in the time I was on salary.  It was always 45 hours plus.  So my hourly rate was tanking like a mad man every minute I stuck around.  Now, I feel like I'm being valued with my time.

When I was on salary, for three or four months I worked a week of 70 plus hours one a month.  If I were to do that now, the pay would be astronomical.   Since I've been keeping track this year, the most I've hit is 67.5 hours in a week.   And the pay check was awesome.

Insurance

So, it’s an on-call week.  Generally that means everyone and their dog decides I need to work on some special project for them.  It can make me feel good that I have the interest of so many, but really.  Can’t it all wait until next week when I’m back to peace and patience and not neck deep in a thousand different people yelling at me to fix things yesterday?

Enough of that train of thought.

It’s that time of year for insurance, and it’s strange that I think I’m finally properly insured, or at least close to where I should be.  I’ve got car, renters, health, life, short term disability, and long term disability.  Which makes for expensive bills but decently mitigated risk.  It seems stupid, but I think I’m finally covered to the point where I should be.  Is it expensive?  You bet.  But it’s worth it. 

Do I really want to contemplate to contemplate what would happen if I fell off a ladder and was injured and couldn’t work?  Not really, but I don’t want to be homeless, either.  Sure, it’s expensive but you should deal with getting all of the above if you can.  I reduce a bit of the cost by raising deductibles and elimination periods.  I generally keep two weeks in vacation and cash in the bank, so an elimination period of two weeks is easy on short-term disability. 

Maybe Nial Ferguson was right. Either that, or I need to quit reading so many books.  

But it's hard to not read so many books when it becomes easy to pick and choose the parts that mean a lot and fit together.  I think most of the books I've read in the last two or three years have changed my perspective in some way.   Mostly for the better.  Or at least I'd like to think so.

More things I should probably know: SNMPv1/2 and SNMPv3

In the category of more things I should know (AKA I hate printers).  

Printers are often built off Simple Network Management Protocol (SNMP).  SNMP could have been a great thing.  It allowed a lot of different things to be done remotely, and was great for the system administrator miles away from the site.

Then people realized that SNMP version 1 and 2 have no real way to be secured.  None.  There is no way to create secure SNMPv1/2.  So the only thing to do is turn it off on the printer.  After you turn off SNMP v1/2 on the printer, your printer goes offline and now you can't print.

The Windows troubleshooter tells you the printer is powered off.  You moan.  You groan.  You Google things.

Anyways, the answer is in turning off SNMP on the device.   Note this problem only applies to network printers.  USB printers don't have this issue because they have a direct connection.

In Windows 7, navigate to devices and printers.
Right click the offending printer.
Printer properties.
Ports tab
Find the check marked tab, and hit configure port.

See that lovely SNMP Status Enabled check mark?   Get rid of it.  

Ok until you are out of all the messages, and magically your offending printer spits out 85 sheets of paper because someone hit the print 30 times, thinking they hadn't hit the button.

Now that you've solved the Windows problem, it's back to the printer.

So, the printer companies occasionally make software to check on their printers and get meter readings.  Larger companies lease printers and charge monthly and for printing more than an allocated amount.  Or they charge by the page.  For those companies to make and collect their money, they have a tendency to use SNMP to get readings from each printer.  Compare the beginning from the ending, and you have pages used.  

Simple.

But SNMP v1/2 aren't secure so you have to find how to turn on SNMPv3 on the printer.  That's usually a matter of finding some sort of web interface and then setting up the read and read/write strings.  That usually varies by printer manufacturer.  

So what about Windows?  Windows doesn't support SNMPv3, and Microsoft is removing SNMP support in future versions of Windows.  If you really like SNMPv3, and can't live without it you have to find your own SNMP tool.

I find SNMP interesting, but the inability to secure it properly and the need to get 3rd party support to get it working properly tells me the easiest thing to do is turn it off and get rid of it.

FYI, SNMPv1/2 vulnerabilities are considered bad ones and will cause a failure in internal PCI compliance scans.

Changing passwords... and Eclipse

Want to figure out how much you know about a system? Change a password.  Sounds stupid, but automation is often setup under a single user account.  In a large company (I’m hoping) you find that only one password affects one process.  In a small company you will run into craziness.  But I would encourage you to change passwords, even ones where you don’t have a great deal of information on what happens when the password changes.

If anything, it becomes a good time to write documentation.  Let’s face it, you are supposed to have documentation on everything you do anyways.  Password changes are no different.  If you have built the infrastructure properly, then a password change should only effect one device or service.  That may seem like a lot of passwords.  It is.  But if you aren’t willing to put effort into security, you won’t have any.  

Moving on…

And Eclipsing we will go…  I took my final today, and I don’t have any site upgrades planned until January, so I think it’s time to get the mobile apps I have built in head tested and running.  That means breaking several things I would normally use at work.  But I suppose that will have to work.

Monday Ramblings

Here are some ramblings for Monday.

The subcontract work fell through.  I spent about 45 minutes on the phone explaining how TCP/IP layer 3 works, and finally got them to know what they needed to know.  I guess a broad knowledge of networking helps a lot when working in an industry that is increasingly network based.  It doesn't help that most networking issues happen at layer 1.  The issue there was a layer 3 addressing issue.  Pictures don't help some people.

After messing with my current reading chart, I determined it will take me (on average) until January 17th to finish the next book.  Strange what a few excel formulas can do.  It's almost magical.   The formula here happens to be

(today's date + (estimated remaining sessions * average days between reading))

estimated remaining sessions = (total pages - current page ) / average increase in page count

So, by close to February I'll be back into an old Security+ book, Some time after that, I'll be into the book on Physics.  Progress, as it were, is happening.  After starting over with the Active Directory book, I'm about 12.7% complete with my reading goal.  That doesn't seem like much, but it more progress than I've made in years.  

It's hard to remember that progress only happens when it is intentional.  Rambling through life will not get you where you want to go.  Make a plan, and go there.  That's the only way to get to the end of the path.  And if that path takes reading 5,200 pages, then so be it.  At least you've got a plan, which is a lot more than most people have.

Finals are next Monday, so I'll finish up Introduction to Networking then and be free for a few weeks.  Fighting issues with the next class, but we'll see what happens with that.  The issue is a supply/demand problem.  The next class filled up in three days.  Every other class doesn't have the people as the one section I want to take.  Lovely stuff.