RSS

@iliajie when you say parameters, you mean an argument to the script? Yes, that's right.

@iliajie when you say parameters, you mean an argument to the script?

$DOM appear to be the global environment variable (https://www.virtualmin.com/docs/development/template-variables/#variables-in-domain-modification-scripts) set by VM Please read further down the linked page! I will remove the time from the commit message Thanks! if we don't need two separate scripts, i am assuming you mean we will use a simple script that just commit /etc changes then the same script will be registered as pre and post modification script in virtualmin, correct? If yes then the commit message won't be specific to the operation, it will just be something generic It will be a script that runs during pre- and post-commands, using different parameters. And no, it will still be specific to the operation.

@iliajie $DOM appear to be the global environment variable (https://www.virtualmin.com/docs/development/template-variables/#variables-in-domain-modification-scripts) set by VM (https://www.virtualmin.com/docs/development/template-variables/#domain-template-variables) I will remove the time from the commit message if we don't need two separate scripts, i am assuming you mean we will use a simple script that just commit /etc changes then the same script will be registered as pre and post modification script in virtualmin, correct? If yes then the commit message won't be specific to the operation, it will just be something generic

Elvis, there are a few things to address. First, the $DOM variable isn’t set. Use printenv to check what’s actually available during script execution. Second, there’s no need to set $DATETIME, as Git already tracks that. Lastly, I don’t think we need two separate scripts—these can be combined into one.

Plus, it's usually a better idea to strengthen the error management at the place where the connectivity is used Agreed! This is exactly what I did.

Using ping to test connectivity is not really the best way. ICMP can be blocked for reducing attack surface. Better test closest to what you need to test: netcat (nc) for tcp connections (like dns server on port 53) or curl for http connections. But if install should be possible offline, indeed, those tests are not warranted. Plus, it's usually a better idea to strengthen the error management at the place where the connectivity is used, so it behaves depending what is needed, than doing a global check beforehand: situation may change in fractions of seconds.

Reverted! Thanks @iliajie

I think it is even better to give users commit hash so that they can easily revert or do whatever No need for this—the commit hash is always accessible via a Git command. Maybe write that to the server log ? i added it Definitely not. Notice i have added sudo on the etckeeper command now, is that fine? No, there’s no need for sudo since those commands are already run as root. Thanks!

@iliajie I think it is even better to give users commit hash so that they can easily revert or do whatever Maybe write that to the server log ? i added it Notice i have added sudo on the etckeeper command now, is that fine? without super user access etckeeper vcs run in a different context for instance it run in very different folder not even the current folder of the scripts