autofixer: option to locally cache/store autofixes
The autofixer is a pretty cool utility but at least in one case it can have issues: the iptablesflush fix.
If your server is in a position where you need to use the iptablesflush feature in the WHM autofixer, there's a good chance you're not going to be able to make outbound requests from the server, yet since the autofixer requires this to get the script to run it can cause problems. Sure, a lot of the time the break is either limited to a specific service (in which case this isn't a problem) or is bad enough to break the whole server (in which case you might not even be able to get to WHM anyway), but I've seen it more than enough times where the very firewall break I'm trying to fix blocks the request to use the iptables flush script.
What I suggest is adding a local autofixer directory to servers. It can be updated by upcp, and it can either contain all or some of the autofix scripts. Then, a few things can occur:
1) if a file is local that is requested by autofixer, the local file can either be run immediately, or it can be a fallback in case there's an error pulling it from the remote server
2) either all of the autofixer scripts can be put in this local directory, or just specific ones like the iptablesflush one can, and then all of the others can be pulled remotely as usual if this is better for the feature's plan, if something isn't in the directory it will automatically be pulled from the server anyway
3) if a new fix is added, there's no problem with adding it to upcp right away, since it would still work just fine if it's added to the remote server first then the local directory later - this wouldn't be impacted for quick hotfixes
4) Users could even add their own autofix scripts to the folder if they want, it's an easy way to add server configuration specific quick fixes to WHM.
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
I am a bit confused on how the local store of autofixers would resolve the issue you specifically describe. If the server in question can't reach out to httpupdate.cpanel.net to download the requested autofixer, it would not have been able to run a cPanel update in the first place to know it is being asked to run an autofixer.
autofixers are often designed to be one-time use and instantly deprecated. There are of course exceptions to this, but I would caution the use of autofixers outside of their automated run unless you're fully aware of what the autofixer is doing.
For those that you deem worthwhile to run consistently or use in regular troubleshooting, I'd feel that we'd rather get a script in /scripts/ or some other intended mechanism to accomplish that task. I'd encourage you to post separate feature requests accordingly for those behaviors.
With regard to extending autofixers to allow 3rd party development, the system was never designed with that in mind and therefore allowing 3rd party elements to sit alongside cPanel developed autofixers is something that would warrant further security investigation. I personally would see the value in ensuring the autofixers stay cPanel distributed.
What sorts of things were you looking to leverage the autofixer system for? Perhaps it can be tackled through existing APIs or other development that doesn't leverage a system intended primarily for one-off one-use fixes.
I am a bit confused on how the local store of autofixers would resolve the issue you specifically describe. If the server in question can't reach out to httpupdate.cpanel.net to download the requested autofixer, it would not have been able to run a cPanel update in the first place to know it is being asked to run an autofixer.
autofixers are often designed to be one-time use and instantly deprecated. There are of course exceptions to this, but I would caution the use of autofixers outside of their automated run unless you're fully aware of what the autofixer is doing.
For those that you deem worthwhile to run consistently or use in regular troubleshooting, I'd feel that we'd rather get a script in /scripts/ or some other intended mechanism to accomplish that task. I'd encourage you to post separate feature requests accordingly for those behaviors.
With regard to extending autofixers to allow 3rd party development, the system was never designed with that in mind and therefore allowing 3rd party elements to sit alongside cPanel developed autofixers is something that would warrant further security investigation. I personally would see the value in ensuring the autofixers stay cPanel distributed.
What sorts of things were you looking to leverage the autofixer system for? Perhaps it can be tackled through existing APIs or other development that doesn't leverage a system intended primarily for one-off one-use fixes.
I am a bit confused on how the local store of autofixers would resolve the issue you specifically describe. If the server in question can't reach out to httpupdate.cpanel.net to download the requested autofixer, it would not have been able to run a cPanel update in the first place to know it is being asked to run an autofixer.
autofixers are often designed to be one-time use and instantly deprecated. There are of course exceptions to this, but I would caution the use of autofixers outside of their automated run unless you're fully aware of what the autofixer is doing.
For those that you deem worthwhile to run consistently or use in regular troubleshooting, I'd feel that we'd rather get a script in /scripts/ or some other intended mechanism to accomplish that task. I'd encourage you to post separate feature requests accordingly for those behaviors.
With regard to extending autofixers to allow 3rd party development, the system was never designed with that in mind and therefore allowing 3rd party elements to sit alongside cPanel developed autofixers is something that would warrant further security investigation. I personally would see the value in ensuring the autofixers stay cPanel distributed.
What sorts of things were you looking to leverage the autofixer system for? Perhaps it can be tackled through existing APIs or other development that doesn't leverage a system intended primarily for one-off one-use fixes.
I am a bit confused on how the local store of autofixers would resolve the issue you specifically describe. If the server in question can't reach out to httpupdate.cpanel.net to download the requested autofixer, it would not have been able to run a cPanel update in the first place to know it is being asked to run an autofixer.
autofixers are often designed to be one-time use and instantly deprecated. There are of course exceptions to this, but I would caution the use of autofixers outside of their automated run unless you're fully aware of what the autofixer is doing.
For those that you deem worthwhile to run consistently or use in regular troubleshooting, I'd feel that we'd rather get a script in /scripts/ or some other intended mechanism to accomplish that task. I'd encourage you to post separate feature requests accordingly for those behaviors.
With regard to extending autofixers to allow 3rd party development, the system was never designed with that in mind and therefore allowing 3rd party elements to sit alongside cPanel developed autofixers is something that would warrant further security investigation. I personally would see the value in ensuring the autofixers stay cPanel distributed.
What sorts of things were you looking to leverage the autofixer system for? Perhaps it can be tackled through existing APIs or other development that doesn't leverage a system intended primarily for one-off one-use fixes.
Replies have been locked on this page!