Voice of the DBA

Category: Editorial

  • Something Old Something New

    My neighbor had a 1978 Ford Bronco when I was growing up. He drove his kids and I around to various events, and I loved that car. The look, the removable back, the spacious interior. It was a car I’ve always wanted to own. As I’ve gotten older, however, the rough ride and lack of modern amenities have made me rethink buying an older version. I’ve become spoiled in my older age

    Ford just announced a modern version of the Bronco, bringing back the iconic truck after over two decades. What is interesting to me is that they appear to be trying to take a page from software design and customized websites by allowing lots of custom options. It appears in this look at the truck that much of the truck body can be removed and replaced with custom sections. I’m sure plenty of third party companies will offer new colors, shapes, lights, and even accessories that might truly make this car your own.

    Of course, car manufacturers want to make money, too. There are some mechanical differences with engines, transmissions, and suspension, but also a variety of settings for the drivetrain. However, different trim levels have different numbers of drivetrain settings. I wonder if there is a difference in the models or this is a software limitation (with a different physical switch). I wouldn’t be surprised if this were the case.

    I had hoped years ago that we would start seeing more customization in cars with manufacturers building a flat chassis and custom bodies, having features into software, providing interfaces, allowing for more plugins from their own and partner suppliers. Instead, it seems like we’ve gotten more and more proprietary designs, trying to lock in users rather than selling the flexibility of design. I guess that’s the way of capitalism, doing what’s best for the company rather than creating an ecosystem that might excite the consumer.

    While I know modern vehicles are built for efficiency and airflow, I think many of them start to look alike. I would hate to see every car look the same, as they have in some movies. I miss the different designs and details from the past. I would like to think that at some point we’ll see modern electric engines, controls, and features available in customized, 3D printed bodies and better software interfaces that allow us to bring back the look of the past with the best of today.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Communicate Through Commit

    Using Version Control is a skill, and it’s one that most technical professionals should learn. Even sysadmins and infrastructure people can benefit from version control, especially as people use infrastructure as code and GitOps with products like Terraform.

    Writing a commit message is a bit of an art, and it’s a good skill to have. I saw a post on how to write one, and I like the overall advice. Talk about why you’re making the change, not what you’re doing.

    The post has good practical advice about structuring a commit message, especially to ensure the messages are terse and easy to understand. Like much of coding, to do this well requires practice, and feedback. Ensuring your team agrees on how to do this and reviewing messages to help everyone improve will build a more cohesive team as well as reduce the amount of explicit communication you need to have.

    Our time is precious as developers, but our attention is even more precious. Every interruption from Slack, a text, or any synchronous communication could break our flow. Many of us complain about meetings taking time out of our day, but the small questions and queries from others, especially at random times, can be worse than meetings.

    Building standards, habits, and providing short documentation in common areas, like commit messages, can reduce the need for one developer to interrupt another. The more we work together as a team, by agreeing on and adopting standards, the better we work together as a team.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Hacking the Admin

    Recently Twitter had a security breach, with a silly scam. At least, I’d think it was silly. I saw a tweet from Elon Musk noting that he’d return $2k in bitcoin for every $1k anyone sent to him. He was feeling generous.

    While that might seem silly, a number of other high profile accounts were breached and seemed to lend some level of veracity to the offer. I saw a few news reports that the hackers made off with over US$100,000, so apparently at least a few people were fooled. Twitter locked down verified accounts for a bit while it investigated, removed some tweets, and tried to close the security hole.

    What is disturbing here is that apparently the hack took place through Twitter syadmins, with privileged accounts. As of this writing, it isn’t clear if this was social engineering or a sysadmin worked with hackers, but there were internal tools allowing Twitter employees to post tweets on behalf of users.

    I have no idea how this happened, but I’m assuming this is some sort of data change made to their system. If this were an RDBMS with a “tweets” table, this would be adding a row to the table with links to the verified accounts’ linkage. Not a hard change in the SQL Server world, and certainly the type of change that most admins could make.

    The question might be should they be allowed? Many of us have made ad hoc data changes to systems to correct an issue, and some of us do this regularly.

    This reminds me of some customers whose DBAs aren’t allowed to directly connect from SSMS (or other clients) to production and make changes. All changes, including ad hoc data changes, must be submitted to some sort of pipeline, where the change is logged, and perhaps approved by someone else. A different sort of two factor authentication.

    Should this be a more common pattern of access to production systems? Limiting access by everyone, even admins? I know we need to trust administrators, but what happens when administrators get fooled by social engineering? A thorny attack vector that we ought to be considering in our architectures.

    Steve Jones
    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Adapting Privacy

    Lawyers will be lawyers.

    That’s a quote from a piece at Ars Technica on how and why search engine startup Neeva changed their privacy policy. Their business model relied on users paying Neeva to keep their data private. The goal being a secure platform that considered users privacy. An admirable goal, and one that I might have been welling to fund. There is a lot of data out there, and while I don’t mind companies improving their service to me with data about me, I don’t like them sharing it.

    In this case, Neeva didn’t read their terms of service very well. I don’t think this was malicious, but it was a mistake. I’m sure they used a legal group that someone recommended to them, and the lawyers were trying to craft a document that was structured to protect the company and allow for flexibility. Sharing data with affiliates and advertisers would seem to go against their model, but it’s something lawyers might think is fine. If you read the article, you can see how Neeva has adjusted their terms.

    As the world grows more digital, and we all deal with an ever increasing number of organizations, data privacy will become more important to some, perhaps many people. The ideas of reducing data retention, limiting transfer of data, and giving users more control is an idea that may take hold, especially if a few companies start to succeed with this business model. We’ve seen pressure on companies throughout this year cause them to shift their previous stances, sometimes dramatically.

    For those of us that work with data, this might mean easier administration in some ways. Certainly we will have to alter our systems for archival or more flexibly data retention policies. We might even need to adapt our data models to include more fields that allow us to easily decide what data to keep, remove, or obfuscate things.

    In fact, I wonder if that’s the future of privacy. We de-link old users by randomly setting values for PII data and keeping other information like sales values or URLs clicked as useful information for aggregation without any risk of disclosure.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.