This message was deleted.
# general
s
This message was deleted.
v
Not sure what your mean by "service startup script" and in which way it breaks. Iirc the changes were done because there were code injection vulnerabilities or something like that. But you can anytime configure your own start script templates and the configure the previous ones.
r
@Vampire what I meant of ” service start script ” is we use the
startScripts
task in our
build.gradle
file to generate the scripts for cross platforms along with some replace token instructions for $APP_NAME etc, during this task execution it is using those new POSIX shell script changes to generate the final application scripts which does not understood by my BASH based shell and throws an error like below,
Copy code
ERROR com.oracle.dicom.agent.core.DIAgentInstallation - java.io.FileNotFoundException: /etc/runit/artifacts/sample-service/$APP_HOME/template/config-template.jar (No such file or directory)
in the above error $APP_NAME is the token which gets replaced with proper APP_NAME which is NOT happening due to changes made to scripts mentioned in my earlier msg.
Following is the logic we are currently using to replace the tokens in the platform specific scripts,
Copy code
createConfigureAgentApp {
        classpath += files('../__ETC__')
        doLast {
            unixScript.text = unixScript.text.replace('MY_APP_HOME', '\$APP_HOME')
            windowsScript.text = windowsScript.text.replace('MY_APP_HOME', '%~dp0..')
            unixScript.text = unixScript.text.replace('__ETC__', '../etc')
            windowsScript.text = windowsScript.text.replace('__ETC__', '..\\etc')
        }
    }
v
And
MY_APP_HOME
is used where? Probably somewhere it was expanded earlier, which was exactly using that vulnerability that was fixed now.
e
the built-in unix start script template is here but customizing it is easy, just write your own (or copy and modify) then set it
Copy code
startScripts {
    unixStartScriptGenerator.template = resources.text.fromString("customUnixStartScript.txt")
}
better than editing it after the fact
v
better than editing it after the fact
I don't agree to that statement. You miss improvements to the built-in templates then. I usually prefer some replacement on the result too for these scripts.
e
if they're doing something like this they aren't going to be able to take advantage of improvements to the script anyway
r
@ephemient thanks for the pointers, Yes I’m looking into one of this route to overcome the current issue and unblock the rollout of
6.9.2
version for our internal builds. @Vampire I agree with you we should not override and loose the new functionality and fixes. But the new changes looks to be breaking/regressing the users whose default shell is
bash
which is not a POSIX complaint in nature out-of-box. Off the topic, I’m curious to know why the updated version of
gradlew
wrapper script file is reverted in the issue where it introduced these POSIX shell script improvements? If 6.9.2 is adding this support, it should also be shipped with updated wrapper script which is POSIX compliance right? Is it something is missing in the 6.9.2 Git Tag or it is a known change?