I have seen the following scenario that may lead to a corrupted and possibly invalid configuration file after using UpdateConfig through AMI, at least with Asterisk 11.25:

There is a configuration file a.conf that contains several sections and also contains a #include “b.conf”, which defines a few sections of its own. Both files a.conf and b.conf start out syntactically valid and with no duplicate categories between the two files.

An AMI client requests a category listing (ListCategories) from a.conf . The listing of categories is returned, including the ones defined in b.conf. There is no indication in the answer about the true source of the categories.

The AMI client attempts to use UpdateConfig with the set of actions EmptyCat, followed by a few Append to define new variables. The intent is to complete replace the content of the category with a new set of variables. It happens that the chosen category is actually defined in b.conf.

The actual result is that b.conf is left unmodified, and the variables that were supposed to go in the emptied category are instead prepended to the #include “b.conf” statement, without the [category] delimiter that starts a new category. This syntactically places the variables as a content of whatever section was before the #include, and if the #include happens to appear as the first line of the file a.conf, it leads to variables outside of any category, leading to an invalid configuration file.

Is there a way to prevent this scenario, without actually going to the filesystem and trying my hand at parsing the configuration file for any #include’s that might be the true source of the categories I want to update? For the sake of argument, my AMI
client runs on a different machine, so direct filesystem access is nontrivial.