[CentOS] how to prevent files and directories from being deleted?

Wed Oct 4 13:01:41 UTC 2017
Steve Clark <steve.clark at netwolves.com>

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:
> 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!

Stephen Clark