Voice of the DBA

Tag: DevOps

  • Bad Culture Bad Security

    I ran across a blog noting that Cisco has a vulnerability in a new product. The blog also lists two (one, two) articles showing that Cisco has had hard-coded credentials in the past. I understand that many times a known process is repeated, essentially copy-pasted between people, and we have similar issues as we have had in the past. However, in 2022 or 2023, it’s unacceptable to hard-code credentials in digital systems that will be used in today’s world.

    What’s worse than having this issue is stating that the fix is “an upgrade”. Their verbiage for those without a service contract is: “Customers should have the product serial number available and be prepared to provide the URL of this advisory as evidence of entitlement to a free upgrade.” Which, to me, is not only bad for the world, but it’s equivalent to the stuff that bulls leave behind in the fields.

    I suspect that this product and software were based on something that already exists, and it was rushed out without a good security evaluation. Or perhaps there are developers and managers who don’t think that hard-coding credentials will compromise security.

    That’s a cultural problem. Either you’re going too fast, or you don’t take this seriously, either way, you don’t have a good culture that values quality and protection. Certainly, their disclaimer about needing valid contracts or proving you have a device to get a security patch for a flaw they built is also a sign of a poor culture that doesn’t really understand the problems they are creating, nor are they taking responsibility for the issues.

    At the very least, fixing their poor security ought to be free and easy. I get that there are likely some software upgrades included in this patch, given the nature of software development and limited branches under support. However, there are other ways to ensure those features aren’t enabled for customers who shouldn’t have them. Making the entire world of computer network infrastructure less secure because you want customers to pay for your mistakes isn’t a model I’d want to adapt.

    I know many people don’t want more regulation or guidelines from governments (or even from insurance), but if I were going to accept some universal restriction, this would be the place. If you use hard-coded passwords, your product can’t be sold and no insurance claims apply if you are sued.

    Maybe that would change the way Cisco and others build software.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • SQL Saturday Boston 2023 Slide Decks

    Thanks to everyone who came to my sessions at SQL Saturday Boston 2023. I’ve added the decks to the schedule, so you can click my session and will see the download there. You can see this below, and all speakers can edit their sessions and upload the deck. See the download below:

    2023-10-14 13_43_08-SQL Saturday Boston 2023 (#1046)

    I’ve also copied the links here for slides:

    For the first session, Architecting Zero Downtime Database Deployments, there is also a GitHub repo here. Clone the repo down (or fork) and you can follow the sessions along. The repo is at: https://github.com/way0utwest/ZeroDowntime

    In here, there are a few folders, as shown here:

    2023-10-14 13_45_44-way0utwest_ZeroDowntime_ Code for my zero downtime presentation

    The two items from the session are the DBClient, which is a Visual Studio 2019 project, and the SQL folder, which has all the setup (and teardown code). Each script is numbered, and you can run them in order. There are also some comments in each for when to flip feature flags.

    If you find issues, please submit an issue in the repo.

  • You Always Have a Software Pipeline

    I was working with a customer recently and they said they didn’t want to set up a pipeline. Somehow they wanted magically to see changes that developers made to their database appear in their production database without making any effort to build or configure a pipeline in a tool like Octopus Deploy.

    As I was thinking about how to find them a solution they would accept, I realized that I’ve always had a pipeline for software. Early on, this was a copy of all the files in a folder sent to the client for Clipper and dBase apps. Later, my pipeline was copying around all the VB6 files from a .zip file and executing a few SQL scripts that were sent to me in emails.

    At one point, I had developers just tell me the software pipeline was them copying files to a server while I had to move all the changes from the QA server to production. I didn’t like that one for two reasons. One was that the developers would sometimes forget to move a change from dev to QA, despite claiming they’d tested the application. Two was that the developers sometimes moved too much to QA, and had changes to the schema that they hadn’t finished in their app. SQL Compare couldn’t help me in either of those cases.

    Over the years, I learned that a slightly thought-out pipeline is better than nothing. I wrote my scripts to simulate what Flyway does today, executing the scripts I’d placed in a folder. I added logging that would capture output results and save them for later review. I learned how tools such as Team City or Jenkins could execute the same thing I could but in a more repeatable, reliable manner. After all, my reliability at 4:55 p.m. on Friday isn’t as good as it is at 2 pm on a Tuesday.

    DevOps is about learning and taking advantage of tooling. Look at what works in your pipeline and find repeatable, reliable ways of accomplishing those tasks without humans doing more than clicking a button to approve something. It’s about using your creativity to improve the process and codifying it in a way. It’s about being better than we were last week while ensuring the process isn’t dependent on any particular person. After all, I might leave for vacation.

    Or find another job.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • The Database DevOps Roadshow Continues (with fun photos)

    At SQL Saturday Denver 2023, I had a few people ask me about the Redgate Database DevOps roadshow and how it was going. A few people asked about the van as well.

    Here’s the van, with my ready to rock in Chicago:

    IMG_5860

    Chicago is done, but we have a few more dates coming:

    • Oct 11 – Atlanta
    • Oct 19 – Jacksonville
    • Oct 26 – San Diego
    • Nov 1 – San Francisco
    • Nov 14 – Seattle

    All these are on the Redgate Events page.

    IMG_5776_copy

    I won’t be doing any in October, as you can see above, I’m tired. With the 3 US ones and the 3 UK ones I did across Aug/Sept, I was gone 24 days from Aug 23-Sept 21. I need a break, as shown below:

    IMG_6182

    The show goes on, and I’ll see (some) of you in Nov.

    Redgate-on-the-move