On 5/6/2019 12:01 PM, Matt Vander Werf wrote:
I would think it would be good if it wasn't required for the clients, IMO. At least for us, EPEL is not on all our client systems (nor do we expect it ever will be). I imagine this isn't unusual a case either. bash is almost always universally available, so it makes more sense to me to stick with that for clients.
I completely expect that the server may need EPEL installed for it to get everything it needs.
Out of curiosity, what is the reason for using dash over bash? I don't have much familiarity with dash, so I wasn't sure.
A combination of performance, security, and a bit of cargo cultism from back in the earliest days of the packages. dash (and its predecessor ash) are tiny compared to bash, so they launch much quicker and are less likely to have side-effects from a bash profile change accidentally affecting the xymon user account. The latter (ash) was actually often compiled statically as well, which made it even more resilient to some sort of library/package update mishap.
On resource-constrained systems, forking overhead can add up -- especially if it happens in a critical loop somewhere. One of xymon's strengths is that there's actually very little forking that occurs once the server has started up, but alarm scripts during a flood, or a lot of hits to the shell scripts that launch(ed) for each CGI (svcstatus.sh, etc) can tip over a box.
On the Debian/Ubuntu side, a lot of the rationale given behind https://wiki.ubuntu.com/DashAsBinSh is still basically valid. Fedora/EL probably would have pushed something like this *eventually*, but it was around this time that systemd was proposed as the end-all solution to long boot times. The rest, as they say, is history.
HTH,
-jc