Custom php.ini / my.cnf / nginx.conf files?

filliph

How do we add customisations to the way PHP / MySQL / Nginx are configured?

For PHP specifically, how do we specify which extensions to install?

There isn't a one-size-fits-all approach to this as different dev environments have different requirements, so support for this is a necessity.

chadcrowell

+1 - I just tried editing the php7.4 php.ini, then restarted the stack, and my changes were overwritten (as expected).

Indigo

The plan is to build a GUI to enable users to configure the most obvious & commonly-required config for each service. So for PHP for example, I think the single most obvious candidate is the memory_limit config. Beyond that, eventually I would like a UI where you can easily enable/disable various PHP extensions.

In the meantime unfortunately this has to be done manually, and in a particular way. Because I have personally used Indigo for almost two years on some very large projects with pretty complex infrastructure requirements, it was obvious right from the start that some users (eg me lol) would benefit from complete control over the config of all the services, beyond what is exposed in the GUI. This is actually why there's no config in the UI just yet: it just didn't need it while only one small team was using it.

So I will outline the "power users undocumented secret method" below. I apologise for the complexity, but the functionality is in place simply to provide unlimited configuration control.

note: if you do try this you'll be venturing into somewhat less stable waters; there are some known issues whereby Indigo is not automatically rebuilding the stack properly when it detects remote changes to the configuration.

Providing custom config overrides

Overview: The .indigostack files are actually bundles, and if correctly-named directories are found inside the bundle, Indigo will recursively merge them over the top of its own configuration.

So for example my workproject.indigostack bundle contains the following manually-added directory structures and files:

php_B058/etc/conf.d/php+pcre.ini where I configure pcre
php_A969/etc/php.ini where I configure a higher memory_limit
system/nginx_reverse_proxy/conf/sites-enabled/custom.conf where I set up some complex reverse proxy configs that are unlikely ever to make it into Indigo's GUI

So you can see that a) any configuration is possible and b) it's a very much hand-constructed at this stage and basically only useful to people confident modifying service configuration files.

Prepare the new config

locate the source configuration files for the service. These are inside the Indigo app bundle at Indigo.app/Contents/Resources/Services eg Indigo.app/Contents/Resources/Services/php/8.1.5/etc/php.ini.
copy that file to your Desktop, together with its containing folder(s) eg ~/Desktop/php/8.1.5/etc/php.ini
edit the config however you wish. Indigo uses Mustache templating, so you can leave that in place or feel free to override it eg memory_limit = {{memory_limit}} can be replaced with memory_limit = 256M
feel free to add any new config files in their correct locations

Move the new config into your indigostack file

find out what Indigo has named your service: in Indigo, right-click the service in the rack and select "Show Compiled in Finder"
take note of the service folder name eg php_B058
rename the folder on your desktop from php to php_B058
In Indigo, right-click on the stack and select "Show in Finder" to locate its .indigostack file
open the .indigostack file: right-click it in the finder and select "Show Package Contents"
move the new config from your Desktop to your .indigostack bundle eg mystack.indigostack/php/8.1.5/etc/php.ini
Indigo should notice the change and automatically rebuild your stack. If not, in Indigo right-click the stack and select "Rebuild..."

Yikes. It does work — as mentioned, that's how I have configured Indigo myself for some very complex scenarios. It's also not really as bad as it reads above, depending on your past experience.

If you decide to try this, let me know how you go. I'm also interested whether people think I should put the above into the documentation on the site, or whether it will just freak people out!

Finally, if you'd rather not do any of the above, and think the config you're after should really be in the service GUI please let me know; I'm keen to start adding the config UI for the most often-changed stuff.

pocahontasdividends

Indigo that should definitely be noted outside the forum, as that is extremely useful to know! in addition it would possibly help to have the xampp approach to have basic config editing of the most burning config files as textboxes and the rest as the overlays you described, possibly even as a "if you need to configure anything else" link to the documentation that explains the process

filliph

Considering 100% of the target audience are developers, I don't think you have to worry too much about scaring us with config files or right clicking a bundle file 😉

That being said, for PHP and MySQL specifically, it might make sense to have a simple textarea where we can dump extra config directives. I'm not 100% sure about MySQL, but I know PHP won't complain about a directive being overridden by a later area.

You would then dump the contents of the textarea into php_A969/etc/php/conf.d/zzzz-override.ini and using this compile-time variable to tell PHP to load additional ini files from that directory: https://www.php.net/manual/en/configuration.file.php#configuration.file.scan

That way, you don't have to ask us to override the entire php.ini file 🙂

For Nginx, you already have the /conf/conf.d/*.conf; and /conf/sites-enabled/*; include directives, which means you only have to add a general textarea (to go into /conf/conf.d/zzzz-override.conf;) and a per-site textarea. The per-site textarea needs to default to

    root "/<userpath>/.indigo/welcome";
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

(with a "Reset to default" button) and allow us to completely rewrite this block.

The reason why we need to be able to completely rewrite this block is that different sites may have different URL rewrite requirements. Here's an example of a /conf/sites-enabled/site.conf block for a XenForo 2 devboard:

location /devboards/xf22/ {
    try_files $uri $uri/ /devboards/xf22/index.php?$uri&$args;
    index index.php index.html;
}

location /devboards/xf22/install/data/ {
    internal;
}
location /devboards/xf22/install/templates/ {
    internal;
}
location /devboards/xf22/internal_data/ {
    internal;
}
location /devboards/xf22/library/ { #legacy
    internal;
}
location /devboards/xf22/src/ {
    internal;
}

(This goes above the location ~ \.php$ { part in the sites-enabled config.)

Indigo

Brilliant! Love this idea. I'm tempted to prioritise implementing this idea above even simple config editing (eg editing PHP memory with GUI) because it exposes a simple UI enabling any config imaginable. I can always add a friendlier UI for specific config later if demand is there.

The one thing in my mind is that this idea allows adding (and only in some cases overriding) config but not in any case removing existing config. Your idea for the per-site config allows complete removal of existing rules, where it's most likely to be needed, and I suppose the complete filesystem-level override mechanism described above does provide the ability for complete removal / overwrite of any config at all if needed. Your thoughts?

filliph

Indigo I'd say removing existing config shouldn't be necessary for anything other than nginx as you noted, because (at least in php.ini) you can always just do some_config_directive= and if that's the "latest" value (i.e. stored in php_A969/etc/php/conf.d/zzzz-override.ini), it should effectively "delete" the existing config.

I would imagine the same kind of "override with blank value" exists in my.cnf for MySQL.

If someone needs even more advanced-er editing than this feature would offer, they can always revert back to the "full config file override" method you detailed above 🙂

Indigo

@pocahontasdividends ok, thanks for the feedback, I'll add the above to the documentation on the site.

Indigo

(the documentation is now at https://indigostack.app/docs/how-to/advanced-configuration/)

@filliph that's cool! I did not actually know you could override PHP config with an empty directive.

Overall, I'm liking where this discussion has gone, thanks to you and the others who've participated! Just need to allocate the time to build this now... 🙂

filliph

Sounds good, once this + the XDebug thing is done, I can begin testing in earnest 😃

Indigo

Indigo 1.0.0-beta.10 has just been released which provides a UI to override the configuration of PHP services. Once any wrinkles are ironed out I will roll out a similar mechanism throughout the other services and sites config.

filliph

Indigo Saving the zzz-override.ini via the GUI doesn't cleanly shut down the system stack, giving us the "Port is already in use" error.

Indigo

@filliph interesting... thanks for the heads-up that you've seen this. I've also seen it occasionally, but not been able to reliably replicate it. I am actually thinking it's a race condition whereby sometimes nginx hasn't released the port back to the system by the time the process indicates it has exited. I'm planning to monitor previously-used ports for availability before declaring the service as fully shut down, rather than relying only on the process termination & exit code.

One question for you — do you happen to have a non-"auto" port specified? ie in the UI have you hard-coded a specific port for a service to always use? That seems to be the trigger for me getting this error, but I don't have enough perspective to confirm that.

filliph

Indigo Everything is set to auto, the only ports I've actually changed are inside Preferences -> Ports, as I'm still running Docker instances of these services 🙂

Indigo

So much for that theory then 🤪 I'll implement the port-monitoring on shutdown anyway, and see if it catches any still in-use.

Indigo

This issue should be resolved in beta 11 which has just been released.