The Geekery

I recently wrote about the 2007 DST changes that are coming up very rapidly (this weekend in fact), and all the changes we’re having to go through. One of the things that keeps slipping my mind, because it works so well, is the infrastructure. I use it every day, all day, and rely on it heavily. While the DST stuff isn’t going to make a huge difference to it, it’s nice to have logs reporting any issues in the right time. So I went to check on the availability for updates on the Cisco and Dell switching infrastructure we have. There wasn’t any. In fact, there wasn’t really any mention of the possible impact at all. This is where I started to get a little concerned, until I started playing around in the application. There is a command, on both the Dell, and Cisco switches, that will let you pre-define the DST date and times each year.

pix > ena

pix #> config t

pix (config)> clock summer-time CST date Mar 11 2007 02:00 \ 

    Nov 4 2007 02:00

This sets the summer time shift on the new DST dates for this year. The command is almost identical on the Dell switches, the Cisco switches, and the Cisco routers.

Technorati Tags: Work, Tech, DST

One of the corporate policies that was sent down from up high during the last audit was desktop firewalls. We originally had it set so when on the corporate network, the Windows firewall was off, when off the network, it was on. We then tweaked that, and set it to optional when off the network (with default being on), and off when on the network. Corporate security didn’t like that, and said we needed to enable it both off and on the network, and that they also recommended a second firewall. Their recommended product hadn’t been released or updated in 3 years as it had been incorporated into “Symantec Client Security”. This isn’t bad, we just got an add-on for our Symantec Anti-Virus to have the firewall included.

Symantec’s recommended method of deploying the firewall service is to start off with a clean desktop. Install all the usual utilities that you will be requiring as part of every day operations for the company, run the firewall, and applications, permitting what is required. When a suitable time has passed, a day or two, take the firewall administrator, and export the firewall policy. This can then be used as a template to push to the remote computers. This is pretty easy, and is documented fairly well here. Documented pretty well, right up until it comes to deploying it. It appears to stop right at the exporting part, which makes figuring out deployment fairly difficult. I figured you could just deploy it by right clicking on a guest in the SSC, and telling it to deploy a policy, but there is no options for it there. So I started looking around, and came across this pdf. About half way down after documenting the methods of deploying the client, it mentions that the policies can be updated by right clicking on the “Groups” section, rather than the computer. Well, I didn’t have any groups, at least not yet, so I created one, and sure enough, there was the “deploy policy” option.

I began to wonder if I’d have to force all the computers into a single group to deploy this, but then I thought better of it. I right clicked the server, and the same option was there too. So in theory, I could deploy to the whole server group without any issue. Well, that’s where the better half of my brain kicked in, and reminded me of the users, application base, and possible impacts. I have created a handful of groups that we can use for the deployment of the new policies. Why multiple groups? Well, imagine if you deployed your shiney new policy to 150 people all at once, and something was wrong, and you killed access to the internet. Would you want to be on the phone with that hickup? I didn’t think so. What I’ve gone with is a roll based group setup. Each department has their own group, and each computer will be moved to the associated group. This will allow me to build policies that meet the needs for each department, without having to worry about crashing the entire network.

Technorati Tags: Work, Tech, Firewall, Symantec

I had to chuckle at this one. Probably everybody knows the story of the Trojan Horse, and how it was used to smuggle soldiers in. This link provided by Dark Reading’s “Firewalled” suggests that history really doesn’t teach us much.

Technorati Tags: Humour, Security

I am, once again, sitting on a 0200 conference call for an emergency change request to push a bug fix to production. I’m bubbling with frustration right now because once again, we spend 40 minutes unsure of:

• How to test the bug
• If the bug was what it was
• Who should be testing
• What the successful result should have been

The problem with tonights update was pretty simple. A small stored procedure change, executed in a few seconds, by the corporate DBAs. The first few minutes of testing was filled with… “well I ran it, but I’m not sure, so get the other guy” statements. When he jumped on, he did the same thing, announced to the world it worked, but didn’t believe the code change had been run before the first guy executed the code. This of course was not true, but he was pretty adamant about this.

Then the first guy proceeds to ask if the VPN would impact it, to which the second guy said it might do, and you should VPN into the corporate network. I proceed to explain that access to the production network from the corporate office would be identical, with the exception of source IP (I didn’t explain that bit as I feared confusing the pool souls), as their home connection. The second guy agreed, then proceeded to tell the first guy to use the VPN.

Then the question/statement came up that we wasn’t sure it was fixed because one of the QA guys testing the issue from another point reported an error. Here is where I nearly lost it, and yelled down the phone, but decided on the mute button instead. The second developer guy, proceeded to tell us that dev guy 1 got the error because his clock was wrong, and that because the clock was wrong, he didn’t see the code changes yet. At this point, I decided to mute the phone, and go find a drink. I was thinking of something incredibly strong, but I have more testing todo tonight as they are also doing load balancer updates.

Right now, I’m trying to figure out if dev guy 2 was joking or not. He’s not the kind of guy to joke about stuff like this, so I’m really worried… I mean really worried.

Technorati Tags: Work, Rant