So we have NetworkManager. I am not at all sure if this is just an Ubuntu/Debian thing, but they exist in both.
And NetworkManager has a dispatcher.d but it is not very difficult from if-up.d, right? It executes all the scripts in if-up.d as well. It has somewhat more environment variables available to its scripts. Other than that I have not witnessed a large number of differences.
NetworkManager of course has a nice command line interface as well, particularly, I believe, if you want to control wifi networks or hotspots.
But I am more interested today in default bootup sequences for when a device is to be brought online.
So the first thing to understand is that run-parts has a flag called --exit-on-error and it is usually automatically set by ifup. This means that if any script in if-up.d/ fails, it will cease execution of the rest and not flag the interface as being brought online in that primitive system that just sets a line of text in /var/run/network/ifstate. But the weird thing is that the scripts in if-up.d are by default (as per the installation) not ordered the way rc.d/ scripts are. They are not numbered, so any order is quite arbitrary or random. That is a weird combination.
ifup does have a flag --ignore-errors, which renders the opposite behaviour.
However, the /etc/network/interfaces file does not have flag for that, which means the "auto" keyword will just do the default behaviour for ifup, which renders the non-default behaviour of run-parts, which causes it to exit on error.
Then we (I) don't yet know what NetworkManager would do. But it executes run-parts without the parameter, causing a different behaviour. So we can see right away then that this causes for a different design.
Now the goal really for me is:
a. being able to fail the ifup if required
b. being able to chain different scripts together in order.
The problem for me is that there is only one fail-condition, which is not-0. If there were different fail conditions, one script could be given the error code of a previous script, but obviously run-parts would not support that.
Currently I have like scripts that first test for a link (which then is a hard-fail) and other scripts that depend on the link which are soft-fail, they should not prevent the IF from coming up, but still they are chained together at times.
So how can I communicate from one script to the next? One quite ..attractive solution would perhaps be to write your own internal run-parts engine, that just executes scripts that run-parts will not execute directly.
In the sense that dispatcher.d/01ifupdown would execute run-parts, and run-parts would again run a script called "soft-fail" which would chain together other scripts using exit codes.
It is an easy solution, I think I will implement it now.
And NetworkManager has a dispatcher.d but it is not very difficult from if-up.d, right? It executes all the scripts in if-up.d as well. It has somewhat more environment variables available to its scripts. Other than that I have not witnessed a large number of differences.
NetworkManager of course has a nice command line interface as well, particularly, I believe, if you want to control wifi networks or hotspots.
But I am more interested today in default bootup sequences for when a device is to be brought online.
So the first thing to understand is that run-parts has a flag called --exit-on-error and it is usually automatically set by ifup. This means that if any script in if-up.d/ fails, it will cease execution of the rest and not flag the interface as being brought online in that primitive system that just sets a line of text in /var/run/network/ifstate. But the weird thing is that the scripts in if-up.d are by default (as per the installation) not ordered the way rc.d/ scripts are. They are not numbered, so any order is quite arbitrary or random. That is a weird combination.
ifup does have a flag --ignore-errors, which renders the opposite behaviour.
However, the /etc/network/interfaces file does not have flag for that, which means the "auto" keyword will just do the default behaviour for ifup, which renders the non-default behaviour of run-parts, which causes it to exit on error.
Then we (I) don't yet know what NetworkManager would do. But it executes run-parts without the parameter, causing a different behaviour. So we can see right away then that this causes for a different design.
Now the goal really for me is:
a. being able to fail the ifup if required
b. being able to chain different scripts together in order.
The problem for me is that there is only one fail-condition, which is not-0. If there were different fail conditions, one script could be given the error code of a previous script, but obviously run-parts would not support that.
Currently I have like scripts that first test for a link (which then is a hard-fail) and other scripts that depend on the link which are soft-fail, they should not prevent the IF from coming up, but still they are chained together at times.
So how can I communicate from one script to the next? One quite ..attractive solution would perhaps be to write your own internal run-parts engine, that just executes scripts that run-parts will not execute directly.
In the sense that dispatcher.d/01ifupdown would execute run-parts, and run-parts would again run a script called "soft-fail" which would chain together other scripts using exit codes.
It is an easy solution, I think I will implement it now.