Voice of the DBA

Category: Editorial

  • DevOps and Exhibits

    Last month I did a webinar with the ATARC group on DevOps and databases. I was on a panel with a few government employees talking about the COVID-19 pandemic and how this may have changed work inside the US government.

    One of the panelists is a full stack developer for the Smithsonian. Ravyn Manuel talked a bit about her work in trying to build new exhibits for the African American History and Culture Museum, which will look to open up soon. Many of the exhibits in the museum were built to be interactive and touch capable. With the COVID-19 pandemic, they need to revisit their approach, finding ways to avoid having visitors touch shared surfaces.

    There was an article after the webinar that included a bit more information. The idea for the immediate future was to use a visitor’s mobile device with QR codes or Augmented Reality apps that engage and excite people. It’s a great challenge, and as Ravyn notes, it’s an exciting time for DevOps and developers.

    I think that’s one of the things that DevOps is supposed to produce. Some experimentation, and along with it, the excitement that comes from meeting and conquering challenges. Rather than big projects, we try smaller things, and adapt as they work, or don’t.

    DevOps is helping many organizations reinvent how they perform software development. Many of the techniques are the ones some of us have been using for years, but the focus on the term has helped lots of managers rethink their processes. I’d urge you to look at DevOps ideas, but be sure you include the database. It’s an important part of the DevOps process.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Detecting Logins

    Do you have a login on any of your SQL Server instances that is named “default”? If you do, you might have an issue with the MrbMiner malware that has infected a number of SQL Server instances. This adds a login with the name of default and the password of “@fg125kjnhn987.”.

    Stop and double check your instances now. If you use SQL Monitor, you can also add this custom metric to your alerts to look for this on an ongoing basis.

    I don’t know this is a SQL Server problem. It’s really a user/administrator issue. This works by looking for weak passwords, which is always a problem. It’s also an issue if you have an exposed SQL Server connected directly to the Internet. Shodan shows lots of SQL Servers on the Internet, and if you own any, you might be sure you have *very* strong passwords.

    Or remove them from public Internet access.

    While this is easy to detect, what if the login were stevejones? Can you detect if logins are added to your SQL Server. Sure you can, but would you really notice something strange? On my instances, where I add all logins, I would. In many organizations where I’ve worked, more than one person added logins, and logins could be added on a regular basis. Often these are associated with tickets in some system, like Jira, but even if they are, would you know an extra one got added?
    I bet most people wouldn’t notice, especially across their estate and with a team of administrators.

    That’s a problem, and it’s one where we ought to perhaps have good controls in place. There are a few places I know where every change is submitted to a pipeline of sorts, meaning that everything is logged, and given the integration with release management tools and ticketing systems, things could be audited. Maybe more importantly, approved logins could be added to a list that might be compared with the actual list on a server.

    Possible, but not necessarily simple to implement or get right. Maybe the low tech solution I’d use is a daily report that included changes from the previous day. All administrators could check it to be sure any new logins were added by one of them.

    You should know how to secure your SQL Server. Implement strong controls, and be sure that you periodically audit for anything unusual. At the very least, ensure you have monitoring so that any unusual or strange activity might be detected.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Moving in the Post Pandemic World

    After a few months of the pandemic lockdown this year, my company gave people the option of leaving the local area where our headquarters is located and moving to another part of England. Actually, since we aren’t planning on anyone coming into an office in 2020, we allowed people to move away from the cities where we are located, with a request that they remain in the same country.

    A number of companies have followed similar suit, most notably a number of big tech companies. Google has said that workers will be remote until July 2021, while Twitter has allowed workers to do so permanently.  Facebook is allowing workers to leave Silicon Valley, but their salaries may be adjusted. All are disruptive actions, and may forever change the culture for these companies.

    Remote work is changing the high tech west coast of the US. This will reshape that area, not just for these companies, but for many others that have had a symbiotic relationship with works. Restaurants, car dealers, rental business, and more will be affected. Certainly some cheer the move, upset with the price inflation and crowds that the booming tech companies brought with them.

    Personally I want to go back to an office. I miss seeing people periodically. Some others feel that way, but I’m sure plenty of people like working remotely and would appreciate the freedom to live elsewhere.

    Today, I want to ask you where that is. If your company said you could move and live somewhere else, anywhere, where would that be?

    Let’s assume that you could keep the same salary. You’d still have to manage meetings and contact with the people work with now, so changing too many time zones would be a challenge. However, dream a bit and think about how you would restructure your life if your company allowed you to do so.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • DR as a Service

    It’s not the first task when I start a new job, but often as a DBA or developer, I usually ask about Disaster Recovery (DR) plans sometime within the first six months. If I’m a DBA, of course I need a plan. If I’m a developer, however, I still need to understand how this might work as it can affect how I build the software and prepare for networking, machine changes, etc. Even if I don’t concern myself with production DR, I usually do want to make sure the VCS repos are being protected, which is something I’ve found isn’t always being handled.

    I have had to build and test DR plans as a member of an Operations team in the past. While my plans and practice are nothing like Google’s large exercises, they often reveal some issues, even when we duplicate the service without touching production. I’ve usually found the brainstorming and debating of the various ways to build a plan to be fun. Arguing for money and then actually implementing plans is less interesting, but the testing is a great challenge. I’ve had some fun days offsite where we try to recover systems and find all the little things that we take for granted in our production environment.

    These days there are companies offering DR as a Service (DRaaS), which is an interesting concept. I found an article from Michael Otey that talks about the features you might want to look for if you contract with a vendor. In the past, I would never consider this, but the more we advance in the world with cloud infrastructures and even full service co-location vendors, the more I think DRaaS makes sense.

    I wouldn’t necessarily take anyone’s word that their service meets my needs, so thinking about the requirements, and then working through a few PoCs (proof of concept) is likely very important. We do a lot of PoC work at Redgate to help customers evaluate whether Compliant Database DevOps is a good fit. I think this is important for software development, but even more important for DR plans. After all, downtime is expensive, and the last thing you want to find out when troubles arise is that some critical piece of infrastructure can’t be easily duplicated.

    I’ve used DR companies in the past, with their own physical facilities. They have impressive capabilities and marketing, but the mixing of their skills with my systems has often been rocky and lead to changes in our plans, contracts for new or fewer services, and often updated documentation for junior staff. After all, I usually expect DR situations to occur when I’m on vacation, so I plan for that.

    You never know when you’ll need to execute DR plans. It pays to think about this ahead of time and periodically test yourself and your staff.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.