On 10/04/2017 08:39 AM, Mark Haney wrote: > On 10/04/2017 08:22 AM, Gary Stainburn wrote: >> On Wednesday 04 October 2017 12:54:44 Mark Haney wrote: >>> Sorry, but if you have to use packages that don't originate from CentOS >>> and they do that, then I wouldn't use them. Period. I'd compile from >>> source before I used something configured that way. >> This perspective to some extent employs cutting your nose of dispite youre >> face. Before Packages were introduced, everyone compiled from source. That >> was a pain, and a long process, especially when you had dependancies that you >> also had to compile. Packages eased this process but kept the dependancy >> issue. > If you think using non-standard packages that put /persistent/ items in > non-persistent locations like /var/run in production environments is far > more acceptable than compiling from source because of package management > 'benefits' then (to me anyway) you're lazy and dangerous with critical > data. My statement still stands. Let me be clear: > > THIS. IS. NOT. ACCEPTABLE. > > The fact you'd rather bandaid a problem (in production no less) than > follow proper standards or compile from source to avoid said bandaid > would be a fire-able offense in any IT shop I've ever worked at. >> Package managers got round (mostly) both the dependancy problem and updating >> too. The problem with package maintainers not keeping up to date shows that >> this still isn't perfect. >> >> However, if you go back to compiling from source then you lose all of these >> benefits. >> >> Thankfully I do not earn my keep by watering lawns. I do not believe that >> this is acceptable, but by the same token I have to earn my keep and that >> involves having working production servers and services. >> >> I have managed to get round this problem in the past through manually doing >> the same function as systemd-tmpfiles. It is a small price to pay to have a >> working, (relatively) up to date server. > The fact you find this acceptable means you're either the only > 'qualified' (and even that is subject to doubt) person there, or your > management is too ignorant to understand the danger. I'm sorry, but in > no way is this acceptable for production level servers. I'm sure, if you > asked 100 IT people you'd get 100 to agree with me. Being flippant with > production servers is never acceptable. > > Of course, most people refuse to listen to logic and reason because they > are convinced they are right despite evidence (and best practices over > 40+ years of Unix) to the contrary. > > I'll end this by saying, I hope the production servers you have don't > provide critical services that could jeopardize the lives of people. > I'd ask who you work for, to make sure I avoid them at all costs, but > I'm not sure I'd be told. > > Again, denying 40+ years of Unix design and best practices because > you're too lazy to manage compiling from source to avoid denying those > practices is truly one of the most astonishing things I've ever seen in > the 25 years I've been in IT. > > Then again, maybe I'm old-fashioned when I expect to do something and do > it right rather than half-ass it. > Don't know how long you have been working with UNIX but there was no /var/run 40 years ago! http://www.rhyshaden.com/unix.htm -- Stephen Clark