3 ms·
Most of the problems you're describing with bash are symptomatic of larger problems: > The problem with bash is if you have different operating systems spread
by iamsohungry 11y ago
Most of the problems you're describing with bash are symptomatic of larger problems:
> The problem with bash is if you have different operating systems spread around, like CentOS 5, 6, 7 in our case, you wind up with a whole bunch of conditions figuring out what to do for specific OS versions.
This is a very poor approach to this problem in this situation. You're supporting 3 systems. It's not unreasonable to maintain 3 branches for 3 branches of the code, and with tools like `git` it's easy to backport features when it's possible without code change. This also gives you better measurement of the cost of maintaining support for legacy systems so you know when it's time to pay the cost of upgrading. And when you do upgrade, you simply stop patching the CentOS 5 branch, and you're not left with a bunch of if statements in your active codebase testing for a system that you no longer care about.
SaltStack might do better when targeting, for example, many many different Linux distros. But even then, it only solves a 99% use case, and the tools are opaque enough that fixing the 1% may take just as much time as writing more portable bash.
> There's also the non-DRYness of "a whole bunch of bash scripts." You could maybe figure out some sort of include system to avoid repetition, but it's bash... it won't be pretty.
It's really not that complicated or bad. `source` is typically all you need.
There's also a larger antipattern here, which is that if your configuration is so complicated that you're feeling pain, you're probably not curating your dependencies very well. Configuration isn't the worst way in which you're going to feel this pain: if you're letting so many dependencies into your system that you're having trouble installing them all, you're almost certainly installing a lot of bad libraries and you're going to find that you also have trouble implementing features using libraries that are poorly-designed. I'm definitely not espousing a blanket fear of NIH code, but if you don't take care on which dependencies you decide to include, you're going to end up with a lot of problems.
- carlivar 11y agoI agree with most of what you say. Unfortunately we have inherited a tremendous amount of technical debt that isn't as easy to pay off as it sounds. Our big apps are pretty straightforward because probably 90% of our bare-metal servers are roughly 10 core applications. That's roughly 6500 servers. It's the "long tail" of the other 500 servers with, say, 100 different applications running on them that is trickier. I probably need to do a better job justifying attention in this area.