Security is challenging to get right. It's always a complex balancing act between what users want and what administrators need. Between placing the server in a hermetically sealed container with no cables running the outside world, and setting the server up on the busiest street corner in town with an already logged-in administrator account pulled up on the attached monitor. Depending on the O/S update policy in practice at your company, that last example can be roughly the equivalent of connecting your server to the Internet.
Here at TDWTF, security is a common topic of submissions. If only because there are so many different (and creative) ways to set things up that are wrong and only a couple of ways to set it up that are correct. And there is a non-zero percentage of administrators that are, shall we say, less than diligent in how they go about their job. We're sure that none of you fit into that category. We're talking about other people.
Fred S. never much cared for zebra striping, the UI pattern than was all the rage after Mac OS X launched in 2001. It found its way into other Mac applications, web pages, even onto Linux. Like a tsunami of alternating grey-and-white waves, it overtook everything in its path.
After numerous requests from users, the project manager for WeightTracker asked Fred to add zebra striping to the weight journal window. Fred had inherited oversight of the application after the original developer, Louis, had been poached by their underperforming rival.
As an IT infrastructure manager, Jerry spent more time skimming his junkmail folder than he liked. Unfortunately, a large number of important messages landed there, because Garrett, the CSO, mandated an extremely aggressive approach to identifying spam. No less than once a week, a vital message was marked as spam.
"I was looking at prices for a train journey," writes Hamish, "I think my company's accountant might raise an eyebrow if I upgraded to first class".
"Chinese buffet2". Licensed under CC BY-SA 3.0 via Wikimedia Commons.
Assembler. C. C++. C#. PHP. Javascript. Bash. Perl. Ruby. Java. These were just some of the technologies featured on the resume of a candidate Christian recently interviewed for a senior Linux sysadmin position. The impressive list of programming languages (and related data-interchange acronyms like XSLT and JSON) made the candidate, let's call him Rob, seem more qualified for a developer position, but he went on to list common web server databases like MySQL and Postgres (plus a couple flavours of NoSQL), and, finally, the qualifications Christian was actually interested in: Tomcat, JBOSS, the Hotspot JVM, and every major Linux distro. While the resume reeked of keyword-baiting, Christian didn't want to risk missing out on an excellent sysadmin who just happened to spend a lot of time hacking, and brought Rob in.
Christian kicked off the interview by describing their infrastructure. Working for a major enterprise, his division was responsible for fifteen hundred Java application servers, clustered into groups of three or four. He explained to Rob how they managed the large number of identical deployments using Puppet, with SVN to track changes to their enormous catalog of scripts. He got through most of their rollout and monitoring processes before Rob cut in with a question.
Peter came across this helpful little utility function:
public static DateTime EPOCH_UTC()
{
DateTime epoch = new DateTime(1980, 1, 1, 0, 0, 0);
return epoch;
}DBAs are supposed to bring knowledge of the underpinnings of databases to the table. How to lay out tables and indices across disks for linear vs. striped access. How to properly set up partitioning for different types of access. Granting assorted privileges and roles. Managing backup and aging off data in a controlled manner, and so forth.
Some take pride in showing developers the "right" way. Some are maniacal in their tight-fisted my-way-or-the-highway approach. Others seem better suited to a career of asking do you want fries with that?
A little while back, I posted a user survey and asked for some general comments -- thanks to everyone who replied and shared their thoughts. I was hoping to share the survey results sooner, but I got a bit caught up in that Release! Kickstarter project.
In addition to some basic demographics questions, the survey asked some questions about a site redesign:
Correct now, optimize later. is one of the most important developer mantras and Scott K. followed it to a fault. He was on a team of programmers debugging a C# package management application, which used Microsoft SQL for revision tracking. Make sure it works right the first time; you can always tease out more performance after launch.
But if your program takes ten minutes to extract a C# package, as Scott discovered, you might want to optimize sooner rather than later.
"When War Thunder crashed, apparently there were some squirrels hiding in there and they gnawed on something. I don't know which button I'm supposed to push!" Jay wrote.
