Enabling Local Development

Sometimes you've got to take a step back from what you know and think.  We've been managing hosts files for years.  In fact, one of my previous posts discusses how we make sure each user keeps the most up-to-date copy on their PC.  That's still required for some things, but when my most recent request came in to assist with local development on the developers machines it gave me pause.  This is what I came up with ...

Use DNS.  We already have DNS setup for our domain mydomain.local.  All of the machines in our environment register themselves there.  We also maintain local copies of our public domains with the internal private IPs so we can manage and test the environments even when they're not publicly accessible.  One of the things we implemented many years ago were wildcard entries so ...

A host entry for * in the domain mydomain.com would resolve for pickle.mydomain.com, mail.mydomain.com or www.mydomain.com.  We also implemented subdomains in the scheme to allow for simple development and testing.  A * entry in dev.mydomain.com and test.mydomain.com makes pickle.dev.mydomain.com and www.test.mydomain.com valid ;)

The developers were using their local hosts file to reference pickle.dev.mydomain.com so that the URLs would match data driven lookups.  The trouble is they had to maintain a huge hosts file and things can get crossthreaded very easily.

That's when it hit me ... use a wildcard entry in a new subdomain named local and point it to 127.0.0.1 in DNS.  Now pickle.local.mydomain.com and www.local.mydomain.com both work from each developers' local workstation.  The hosts file entries are greatly reduced and revisions/management of said files has all but been eliminated.

It also makes surfing from the server itself possible which can be priceless in troubleshooting -- or proving to the devs it really is their code having a problem and not the server, network or firewall! ;)

My PC is chatty (snmp-read)

I've been on a firewall monitoring kick lately and I've noticed a lot of office computers chatting on http and/or snmp.  Mine for one was trying to open snmp-read on 192.168.1.4 all throughout the day.  That drives me crazy.  Yeah, I'm that guy.

So, how do you go about running that down?  Use the firewall to your advantage.

The firewall will tell you not only what IP address and port you're trying to talk to, but it will also tell you what port you're talking from on your PC.

Now we can use netstat -ano to tell us what process ID (PID) is using the the source port 65365.

Finally, we can use procexplore (a free SysInternals tool) to determine what process has PID 1740.  You can also use Task Manager, but I like the SysInternals tool better.

The print spooler ... dang it!

And, there you have it.  My girlfriend's printer.

My next post will hopefully be on how to make it stop talking all day long ;)  Really Microsoft?!  Do we need to query the device every 70 seconds?  Why don't we just talk to the printer when we try to use it.

And people wonder why are PCs run so slowly ... sheesh.

Stupid Ping Tricks

Is there a way to tell if a server is up with a DOS bat file? Yes! I've used this to wait for a network resource to become available before continuing a script.

:PING
ping -n 1 -w 50 192.168.11.1 > nul
if errorlevel 1 goto PING

Is there a way to tell if a server is up with a .vbs file? Yes! I'm using a modified version of this to return a 1 or a 0 for MRTG trending.

On Error Resume Next

strTarget = "10.123.30.12" 'IP address or hostname

Set objShell = CreateObject("WScript.Shell")

Set objExec = objShell.Exec("ping -n 1 -w 50 " & strTarget)

strPingResults = LCase(objExec.StdOut.ReadAll)

'WScript.Echo strPingResults

if err.number > 0 then

WScript.Echo "ERROR"

End If

If InStr(strPingResults, "reply from " & strTarget) Then

WScript.Echo strTarget & " responded to ping."

Else

WScript.Echo strTarget & " did not respond to ping."

End If