The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
I need a couple of sub domain names for a customer.
Customer tells me one of their suppliers does that for them.
Call those guys, but they don't do that, the customer does that themselves.
Go to the guy who is supposedly responsible for domain names, but he looks at me like he's never even heard of the word before.
Speak to the IT manager who redirects me to the supplier again.
So I call the supplier telling them that the IT manager told me I should really talk to them, but they just forward me to the same guy again.
I just send out an email with all the DNS records I need to the guy and his manager and let them fix it.
This same supplier does all other system administration.
Now I want to set up Azure file sync.
Call person A, seems their servers are outdated and they need to run a couple of updates before we can even run the sync tool.
Server needs to be restarted, which needs to happen in the evening.
Person A forgets this, leaving me with person B the next day who has no clue why it isn't working.
We find out the server wasn't restarted, which person B will do.
Forgets it too.
Ultimately, a week later, the server is restarted and person C is assigned to me.
Person C has no idea which server I'm talking about and neither have I since no one tells me anything.
Person A just so happens to be in the room and he can tell us the server name.
WE NEED ANOTHER UPDATE!
A few days later I'm able to setup the sync using TeamViewer.
I now need to set up a new file sync
Person A helped me on Monday, and he knows a bit about Azure as well, but person D who knows nothing about Azure is on site today and he is now calling A to ask what server I'm talking about
AND THIS IS THEIR MOST RESPONSIVE AND HELPFUL SUPPLIER!
I've got a slightly different problem such that I know who handles the DNS records and forward them all the information the vendor provides me to get things set up. All good so far.
Then the guy who handles the DNS piece tells me I have to send the rule exactly as I want it added. Reasoning is that if it doesn't work or breaks anything else then I'm the one who wrote the rule, so it is my fault. Except I'm not a DNS/networking person, I don't know what other rules are in there which might be affected, and so on.
Funny you mention DNS issues. I had an issue pop up 7 days ago that caused me to have to re-deploy about dozen apps/utility modules. A hostname for an ftp resource I have used for over 15 years suddenly quit resolving.
I checked the a/cname dns records and they check out fine. I switch to another hostname listed there and it connects just fine.
Good right? Not quite. Maybe someone else can learn a lesson from this, so here goes:
Over the last 15 years, that ftp hostname had become baked into our desktop apps that utilized ftp...around a dozen or so. Actually, the hostname and username were both hard-coded. The password is actually defaulted but gets it's value from a publicly available xml resource. (encrypted of course!) The idea was that I might need to change the password but never the hostname/username.
Ah, but it really wasn't catastrophic...the secondary ftp resource picked up the slack in most cases. It's nice when careful planning pays off!
Anyhow, I had to change the hard-coded hostname that was failing in those applications to the one that works then recompile/redeploy which was easy enough but wasted half a day doing so.
What I should have done is allow the hostname/username to be fully dynamic like the password but that would have required more time/effort than it was worth. If I were starting over with it, I'd definitely have all the pieces able to be changed on the fly.
Also, nothing to do with DNS, but rather a lesson in IP Based security done poorly, then corrected.
I have a customer with 60+ sites and around 400 or so devices using a couple of Azure web apps. All sites are WAN connected and use a common gateway for the internet. When these apps were developed over 4 years ago, all the sites used a really small set of outbound IP addresses...usually just 2 or 3 in use at a time.
The allowed IP addresses were simply stored in a comma-delimited appSetting in the Azure config section. If they changed, which had become rare, I'd get notified and have to go add the new address to the list. This method worked pretty well until last week when their IT dept. decided to become more granular on the outbound assignments and the number being used jumped to over 20.
My little method suddenly became totally inadequate for the task, so I rewrote it and did it the right way by adding another layer to handle a simple range check. The ranges are added as a comma delimited list of uInt lower and upper values in the Azure config section. The current customer is using 2 distinct ranges.
As before, the client's IP address is checked for a direct match. If a match is not found, the address is converted to a uInt and the range is checked for each range pair. So far this is working well...the hard part was finding a reverse IP tool that gives ranges, then writing a tool that converts those to uInts. Out of about 10 different reverse IP tools, only MXToolbox gave the ranges I needed.
While I'm writing a book, I also took the opportunity to address other shortcomings with the current systems mostly dealing with error logging and reporting. I'm probably going to be scared of what I find! The original method to deal with handled errors was to set a general error message and where appropriate details, then redirect to an error page displaying the reason we are here and a simple email link to report it directly. Very few end users would actually try to report anything, maybe because the mailto link was basic and didn't include a subject or body.
The error pages now trigger a database record for logging, unless of course the problem is the database! To be honest, when I wrote this app over 5 years ago, it was 4 months from the date they asked for it until going live. Their acceptance was based on a really primitive php/MySQL opensource project my business partner found and made me customize enough for a demo. When they finally decided to go a year later, I immediately announced that I was not doing anymore php and that I was starting from scratch. It was a lot of late nights and weekends and a rocky implementation but somewhere after the first week of fixing bad data every night, I got it right and it's been a great little application that requires very little of my time to support/monitor...until one little variable that's out of your control changes and exposes a weakness. I'm leaving it way better than it was before!