How Things Work Today or The Joys of Consulting

A person with company A has a concern about some work that needs to be done. They call outsource IT firm B with whom they have a contract. Firm B has nobody on staff with the required experience. Company B is big and well known. Their solution: call recruiter C who in turn checks their database and realizes that Linux systems consultant D has the experience. Hi! I'm D.

Unfortunately this is being handled like a game of telephone and the information C gave to D (me) didn't clearly explain what they needed so D (me) asked for more information. In the meanwhile I get a note from B forwarded by C that makes it very clear what is needed. Thank you, C, but... I now have to go back to C to tell them my question is irrelevant. Asking it would make me look stupid because it really isn't the issue at all. If that message gets through in time I give them what they need to present me successfully to B and A. Fortunately C did get the message before presenting D to B.

Why might this still not happen? B presents this as if A is demanding someone who has worked on the exact same hardware running the exact same application. That's why I asked an irrelevant application question in the first place. Software vendor E supports the revised environment for their application and actually has this all very well documented. I work with E for another client so I have access to their knowledge base. I can definitely solve the problem. That doesn't change the fact that I don't match on the irrelevant points of experience and they may turn around and look for someone who does.

Welcome to the world of IT consulting in 2017. Does this make sense to anyone? It doesn't to me.

List of Linux System Hardening Resources

My recent post about how quickly newly commissioned Linux systems can be attacked and possibly compromised led to a bunch of e-mail queries about resources which explain how to lock down a variety of Linux distributions. Most such guides are distribution specific because, while the basic principles are always the same, there are significant differences between distributions and even versions of the same distribution that make writing a generic guide difficult at best.

I did compile a list which I added to the comments. However, based on the number of questions I've received I thought it would be best to publish the list as a blog post, something people could easily find and bookmark, with some additions to what I originally posted. I've limited this list to distributions commonly used in businesses (large and small), academia, and in non-profits. I have not included specialized distributions, including those designed for use by security professionals. Most of these distributions also are excellent choices for personal use.


Red Hat Enterprise Linux / Centos / Scientific Linux / Springdale Linux

• Red Hat Enterprise Linux 7 Security Guide
  Chapter 4: Hardening Your System with Tools and Services
• Red Hat Enterprise Linux 6 Security Guide
  
• University of Texas Red Hat Enterprise Linux 7 Hardening Checklist
  
• CIS Red Hat Enterprise Linux Security Benchmarks

Debian

• Securing Debian Manual
  
• Debian Wiki: Hardening

SUSE

• Suse Linux Enterprise Server 11 SP4 Security and Hardening
  
• OpenSUSE Security Portal

Ubuntu

• Harden Ubuntu
  
• Ubuntu Community Help Wiki: Security

32-bit Enterprise Linux Still Matters

I've been testing the Red Hat Enterprise Linux 7 Release Candidate. One thing that stuck out right away was the lack of a 32-bit x86 build. In last week's DistroWatch Weekly Jesse Smith questioned the need for such a build, which is only useful on legacy hardware, in the enterprise. He wrote:

"Something which caught my attention while reading this question was the requirement for a 32-bit operating system with newer software than Red Hat Enterprise Linux 6 offers. It seems unusual that someone would want new software versions, enterprise support and a 32-bit operating system. New software and legacy hardware (or new software and enterprise environments) rarely go together and it might be worth looking into whether these criteria are really necessary."

While I certainly understand Jesse's point about 32-bit being legacy hardware, there are still many use cases where 32-bit and current enterprise quality software and OS are necessary. Many current Linux apps are still very light and can run very well on rather old hardware, both in the server room and on the desktop.

I've done a lot of support of government servers and they run for about forever, as in until they serve no further use. Even retired, old servers are often repurposed and put back into service due to budget restrictions and/or long lead times to order new equipment under the required procedures for government procurement. In the United States this is especially true at the state level. When a server is repurposed it is usually reloaded with the current enterprise standard Linux distrubution release and applications, not legacy releases. That's one common use case.

Non-profits and small businesses often get by with older equipment as well, and in the case of non-profits it may even be donated second hand equipment that was no longer useful in it's former commercial enterprise home. Once again, a 32-bit OS and current software makes sense in cases like this.

My personal hope is that the free enterprise Linux clones will take Red Hat's 64-bit sources and create a 32-bit version. It isn't hard to do but it is time consuming. CentOS has already made clear they will release a 32-bit build(see comment by developer Johnny Hughes below), which leaves Scientific Linux and Springdale Linux.

[Note: This article was expanded from my comments on DistroWatch Weekly, Issue 560.]

Linux, Standards and the Enterprise: Why Red Hat Enterprise Linux Remains the Best Choice

Dietrich Schmitz, writing for the Linux Advocates website, posted an article yesterday about how Red Hat's adherence to the Linux Standards Base (LSB) guarantees stability and reduces costs in the enterprise. While I agree with Mr. Schmitz wholeheartedly, from my perspective the reasons by Red Hat Enterprise Linux remains both the leader and the best choice in business, government and non-profit spaces goes far beyond the LSB.

I've been a professional UNIX/Linux systems administrator for 18 years now. I've had to implement, maintain and support servers from all of the enterprise distributions and a few distributions not generally used in the enterprise as well for my employers and customers over the years. I'm a big advocate for Red Hat and the various free clones (CentOS, Scientific Linux and Springdale Linux) as the best solution for most organizations. First, it's exceptionally stable as Mr. Schmitz points out. Second, it offers the longest support period at 10 years. Third, they have excellent and professional support.* Fourth, they do the best job at insuring compatibility with both FOSS and commercial apps during the full 10 year release cycle.

My big issue with SUSE Linux Enterprise (SLES/SLED) is that they do push major version changes of the kernel, tool chain and apps in what they euphemistically call Service Packs. The Service Packs are actually major releases recently and have been known to cause major breakage and pain. My experience with their support organization here in the U.S. has been less than satisfactory, particularly the time needed to respond to and resolve issues.

Canonical (Ubuntu) has much shorter support periods than either Red Hat or SUSE. They also don't backport additional hardware support or patches into their kernel, forcing you to either do the SUSE style update gamble even more frequently than with SUSE or else to run without needed support and/or vulnerabilities.

The free clones of Red Hat Enterprise Linux I mentioned earlier are not permitted to name their source, referring merely to "the upstream provider," but pretty much everyone in the Linux community knows precisely what they mean. They represent a real advantage to Red Hat (the distribution if not the business) in that they allow businesses to try before they buy. They provide the opportunity to run a test bed or non-critical system at reduced cost. The clones also allow non-profits and cash strapped small businesses to forgo commercial support, at least for a time, and still use software that is entirely compatible with the leading enterprise Linux distribution. As organizations grow and their needs change converting a server or workstation running a clone to a genuine, supported Red Hat system is a simple process.

Finally, I'm sure fans of Debian and Slackware packaging will disagree with me, but keeping to standards, specifically the LSB, also goes a long way to insure application compatibility. I think it's vital that all enterprise distros follow standards.

*= Disclaimer: I was part of the support team for seven months as a consultant in 2005. I no longer am affiliated with Red Hat in any way, shape or form. [NOTE: This article originally appeared as a comment on LXer.com in abbreviated form.]