Voice of the DBA

Category: Editorial

  • Automated Driving

    In the book Red Thunder (highly recommended), the highways are under the control of some computer system. You approach a highway, get into some merge lane, and then a freeway computer takes control of your car, disconnecting the steering and foot controls and drives you along. When you want to get off, you signal, the computer moves you to an off ramp, and then releases control. It’s efficient, with the computer putting cars bumper to bumper, with a few inches between them since everything is under control.

    It sounds great to me, but I’m not sure we’ll ever want to completely put our transport under so much computer control. However people are trying, with automated subways and trains, but many of these still have an operator. There are quite a few projects looking at bringing this type of control to cars, though I’m not sure if we’ll ever get approval for something like this without some type of closed track that only allows automated cars.

    Think about all the issues you see in computer software, even supposedly well-written software. There are always bugs and unexpected code paths or even demands being made of the software. There’s also not enough testing to convince many people that we can really write extremely high quality, complex software that can handle something like traffic maneuvers.

    Then there’s the security. Whether it’s a central system that controls flow on a road or a distributed system in each vehicle, can you imagine the possible consequences if there were some security breach? What if someone finds a way to do some sort of SQL-Injection like attack, such as the one I show above?

    As much as I’d like to be able to ride in my own car, but have it handle the driving chores sometimes, I’m not sure our technology is anywhere close to the level it would need to be for me to trust it.

  • Code of Conduct for Software Maintenance

    I ran across this article about a recent symposium for CIOs where a code of conduct for IT maintenance that was developed as a guideline for how companies want their software vendors to behave.  This is strictly a customer driven initiative, organized by the Gartner Group, to try and ensure that software companies treat their customers fairly.

    I was surprised to hear that the CIO of Lowes say that software maintenance costs are the largest growing line item in his budget. If that continues, then the price of maintaining software could be a real issue for companies. If it is, then will they slow down they software upgrade cycles? What happens to the innovation of software if companies expect versions to be in production use for 5-7 years? Will that impact the 18-24 month cycle of SQL Server?

    It’s hard to say what might happen, but I do think that sometimes the cost of software maintenance is out of line with the true maintenance costs. Is a 20% margin fair? Especially when it seems every software package out there needs regular maintenance in order to work well. Is that because software just needs repair and enhancement once it gets used by the public? Or is it because software vendors are not testing enough and expecting clients to just live with their level of quality?

    The code is a good idea, and if enough large companies agree that adherence is necessary for them to purchase upgrades, I can see software companies starting to abide by its provisions. I have to say that Microsoft already follows some of the guidelines, like regular patches for its products. I think Microsoft has fair licensing practices for test and development machines, though it might be nice to see different support levels for different levels of criticality.

    Steve Jones

  • Should You Write Down Your Passwords?

    Today’s editorial was originally published on June 27, 2005 and is being reprinted today as Steve is out of town.

    According to Jesper Johansson, senior security program manager at Microsoft, the security industry is giving out the wrong advice by forbidding people to write down their passwords. Strong passwords are impossible to remember and lead to people picking easy passwords or using the same password across all the systems that they access.

    And using the same password across all systems us poor security. I tend to agree with that in most cases because if one system is compromised then all of them are. However, for the administrators, it’s problematic if all systems have different passwords. Then the cost (in time) of administering these systems goes up. I admit that in most of my jobs I’ve used the same sa password on all servers and the same administrator password on all systems. The caveat is that we change those passwords often, usually every 30 days and always when an administrator leaves. While a security breach would leave all systems vulnerable, the window of opportunity is fairly small.

    Bruce Schneier says that it’s impossible to remember strong passwords. And now password cracking programs are hip to the 3 for e and 0 for o replacements (and others). Plus with distributed cracking programs and cheap hardware, it takes less and less time to crack passwords for anyone that truly wants to get at your systems.

    It’s quite a quandary for people. To me there are two problems we are trying to solve. One is protecting systems for the administrators. These are more technically competent people and should be required to build stronger passwords. The system that I liked the best over the years was the central storage of all our administrator passwords (Windows Admin, SQL, Exchange, service accounts, etc.) in a central storage file. We used Password Safe for this on a network share accessible to administrators only. We changed the file password periodically and scripted changes of the various passwords every 30 days. Usually we’d solicit some theme and assign an administrator to change the passwords.

    The other problem is how to get users to create and deal with complex passwords. Of all the suggestions that I’ve seen, I think writing them down is a good idea. Make stringent requirements, 12 characters, mixed case, numbers, etc., require changes often, but allow them to write them down. Not on sticky notes, not posted, but maybe a card that they keep in their wallet or purse. Or these days, maybe their cell phone.

    Now if we could just somehow secure your cell phones. Maybe outlaw Bluetooth?

    Steve Jones

  • Enterprise Management

    One of the things that I’ve had to do in my career is manage large numbers of servers. There was a time when two of us managed several hundred instances of SQL Server, and managed to do it very well with a lot of automation. Recently I saw someone post a note about having 400+ servers to manage, and they were wondering how to perform enterprise management. In Oracle environments, they mentioned using OEM, RMAN and other tools to manage backups centrally and wanted to know what SQL Server solutions were out there.

    I know things have changed quite a bit from the SQL Server 2000 days when we had to build all our own tools, so I wanted to ask the question as a poll this Friday:

    What do you do for central management of lots of instances?

    If you have more than 50 instances, what tools do you use to try and ensure you have a well managed environment. With the addition of the Central Management Server and Policy Based Management  to SQL Server, it definitely is easier to handle a larger load of instances

    This Friday I’m wondering what tips and techniques you think work well for managing lots of instances. Any tricks you’ve used? Any third party products that are very handy? Share you knowledge this Friday.

    Steve Jones