Re: equivalent of Debian config-package?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux