I have a bad habit of wanting to post something of a certain size and weight before I post anything at all. The end result? I don't post anything! As the beginnings of an attempt to break this habit, I offer some almost entirely unrelated items I have come across lately. The top two items are from some recent adventures in Linux administration, while the last one is a really dumb one with an ASP.NET app.
Paranoid hosts.deny Can Trip You Up
One of my Debian-based firewall servers had the 'paranoid' option set in its /etc/hosts.deny file. The purpose of this option is to block access to any remote host where the host name does not match the address. I imagine it would work by pulling a PTR record from the IP, and then querying the resulting host name to see if it matches back to the IP again.
That system has had that setting for quite some time now, and it never caused me any trouble. Every connection I have apparently used in that time has had its DNS settings properly set. But I recently used a connection at a partner's office, which was provided through a small, local cable company. Hair-pulling ensued; While I had no trouble accessing the services on the systems behind the firewall, I could not connect to the SSH or VPN services provided by the firewall itself. Packet sniffing showed there were packets going back and forth. As I recall (it's been a few weeks now), something in syslog prompted me to think of hosts.deny;
I don't know how prevalent it is that ISPs will have improperly setup PTR records, but it's something to keep in mind.
I Was Creating a New Grub menu.lst Every Kernel Upgrade!
On another Debian-based firewall system I have, I kept a backup copy of Grub's menu.lst file to restore over the automatically generated one every time I did a kernel upgrade. This is a big-time case of "RTFM!" The reason I was doing it has to do with the perculiarities of the hard drive subsystem on the motherboard in question, requiring me to need to use the IDs of the drives.
But if I had simply read the comments in menu.lst, or read the man page, I would have known I had two options: 1) add special entries before/after the 'AUTOMAGIC KERNELS LIST' section or, more appropos for my situation 2) edit the default options within that section. The default menu.lst file comes with comments that describe the process quite well; the key lines are commented by a single hash (#), and that hash must remain there. When configuration of a new kernel is done, the defaults entered there are used. I was actually considering replacing this server with another one due to this issue, when all it took was literally a 30-second fix.
Don't Forget That Global.asax File!
Okay, you say, what kind of silly advice is that? Who would forget to upload one of the files of a web site? And wouldn't it be obvious when it happened? Of course, ASP.NET folks know that Global.asax is a special file. It's not a page that you load (requests for it are specifically denied by IIS by default, in fact), but it is frequently a vital file. Application-level code runs - or does not run - based on it.
I almost always use Code-Behinds in ASP.NET, where the 'web site files' (including Global.asax) merely contain markup, and then names of the compiled program objects from which they are to derive - those objects having been programmed via the 'code-behind' files, which are pure C# code, in my case. Even though all the code is compiled in an assembly, the web files are still needed (without some other special circumstances); The layout/design and markup code is still in the ASPX files - you will get the standard "File Not Found" error if such a file was not uploaded.
But the Global.asax is a special case. If it does not exist, the result is simply that no application-level code is run. This should seem obvious, but without the Global.asax being present in the web directory, the ASP.NET runtime has no way of knowing what, if any, HttpApplication-derived object that may or may not be in your code should run. You could derive a dozen such objects and compile them in your assembly. You may have compiled only one, but you don't want it used. My point is, the Global.asax file and the markup contained therein is the way that the runtime knows what you intended.
In my case, this oversight was the reason on my development system, a global variable set in Application_Start was valid, but on the staging server it was NULL.