# Best practice for managing a large configuration file in a role **URL:** \ **Category:** Get Help\ **Tags:** ini\ **Created:** [February 29, 2024, 9:51am UTC](https://forum.ansible.com/t/best-practice-for-managing-a-large-configuration-file-in-a-role/4132 "2024-02-29T09:51:49Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![wzzrd](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/wzzrd/32/2087_2.png) [@wzzrd](https://forum.ansible.com/u/wzzrd)\ **Post date:** [February 29, 2024, 9:51am UTC](https://forum.ansible.com/t/best-practice-for-managing-a-large-configuration-file-in-a-role/4132/1 "2024-02-29T09:51:49Z")
I’m a bit of a hobbyist, working on a collection to deploy Gitea and related tools. One thing I struggle with, is the astoundingly large set of configuration options for Gitea. It’s 600+ options long in a 2500+ line config file. For another collection I built (for atuin), it was relatively easy to template the whole configuration file, and put all options with their default values in `defaults/main.yml`. However, I’m not looking forward to doing this with a 2,500 line ini file. Alternatively, I could work with the lineinfile or general\_ini modules (which would save me from templating the config file, I think), but that might become unwieldly with 2,500 lines of config file. Or I could do what I’ve seen in some other places, which is basically say: put the contents of your desired config file in a variable, and let the role use that to populate a config file. So basically a one variable template. But that feels like a shortcut that isn’t very helpful to new users. What is considered best practice in this context? Ideally, I would not want people to have to write their configuration file in a variable, and ideally I don’t want to maintain a 2,500 line configuration file template. I guess I could script much of templating the config file, but before I set about doing that, I would appreciate some input… ---
**Author:** ![chris](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/chris/32/293_2.png) [@chris](https://forum.ansible.com/u/chris)\ **Post date:** [February 29, 2024, 12:52pm UTC](https://forum.ansible.com/t/best-practice-for-managing-a-large-configuration-file-in-a-role/4132/2 "2024-02-29T12:52:10Z")
I’d use the [from\_ini](https://docs.ansible.com/ansible/latest/collections/community/general/from_ini_filter.html) to read the file (or `community.general.jc` with the JC ini parsers if that isn’t suitable, for example due to the lack of [support for ini files without section headers](https://github.com/ansible-collections/community.general/issues/7889) or duplicates). And [community.general.ini\_file](https://docs.ansible.com/ansible/latest/collections/community/general/ini_file_module.html) to write the file. However perhaps `community.general.ini_file` with only a `path` argument would also work for reading the file as well as writing it? Suggesting that people use [JC](https://github.com/kellyjonbrazil/jc/) on the command line to read the INI file as YAML for the config is also something to consider, eg: ```bash cat gitea.ini | jc --ini -yp ``` In order to get all their existing config into Ansible. This way you could only have the variables in Ansible that you want to change in the role defaults, eg: ```yaml gitea_conf: foo: bar ``` And it would also work with all the 600+ options if people want to add them. Templating the file sounds like too much of a PITA especially if config options available change with versions etc… Also note that recent versions of the `ini_file` module have a [modify\_inactive\_option](https://docs.ansible.com/ansible/latest/collections/community/general/ini_file_module.html#parameter-modify_inactive_option) which really helps with keeping large files (I’m thinking PHP and MariaDB config files) that are updated using Ansible also human readable (I have been using `line_infile` to remove the commented version of the option before updating the files using `ini_file` and need to update my roles to use `modify_inactive_option `).