On 7 June 2018 at 12:11, Dave Love <loveshack@xxxxxxxxxxxxxxxxx> wrote: > Stephen John Smoogen <smooge@xxxxxxxxx> writes: > >> 4. System administration/configuration management is 99% "I have a >> solution I endure and I don't have time to re-engineer it." and 1% "Oh >> I think I want to write my own configuration management toolkit >> because I can't endure what I am doing now." You are going to get >> pushback from any site you are proposing this to until you show it is >> useful for them. > > I'm not convinced I need Unix system management explaining after so > long, or how my department works. I missed the mark in what I was trying to explain as I should not have used "you" The part I was talking about is that there have been several "lets do configuration management in rpms" little side projects. They ran into problems because every site does things their own way and no one liked how someone else did it. Some people expect that the configurations are idempotent and reversible. This means that rpm -e lab01-config brings the box back to original state. Other people expect that the configurations are interactive by the user which can be done via debs but not rpm. Others have made site wide decisions on language so ruby/perl/python must be how the tool has to be written. Then there are the disagreements on philosophies of RPMs altering other RPMs with %pre/%post %trigger rules for updates of those packages. I have had to do each of the above at one point or another and it usually made whatever tool I built only work at that site. What I have seen done recently is that people were putting a puppet or ansible config set in an rpm and then requiring that tool. It would then run a "recipe" in %post or via a cron job and would run a unset recipe in a %preun. Still a bit racy but worked for small configs. It was still site specific as how those recipes lined up were authors "how I expect the world to be" versus some generic version. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/HLYCW24X3BZVHDLKEQJP2G5EZXX6LBLF/
