Post install script has error in RegEx
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
tomcat7 (Debian) |
Fix Released
|
Unknown
|
||||
tomcat7 (Ubuntu) | ||||||
Trusty |
Fix Released
|
High
|
Unassigned | |||
Xenial |
Won't Fix
|
High
|
Unassigned | |||
Yakkety |
Won't Fix
|
High
|
Unassigned | |||
tomcat8 (Debian) |
Fix Released
|
Unknown
|
||||
tomcat8 (Ubuntu) |
Fix Released
|
High
|
Unassigned | |||
Xenial |
Fix Released
|
High
|
Unassigned | |||
Yakkety |
Fix Released
|
High
|
Unassigned | |||
Zesty |
Fix Released
|
High
|
Unassigned |
Bug Description
== Begin SRU Template ==
[Impact]
* On upgrade of tomcat7 package, if a user has updated their JAVA_OPTS variable to include a '%' an upgrade will fail. The sed command in the postinst uses the '%' character to act as a delimiter, previous versions used '/' however it was updated to '%' in hopes it was far less common.
* This SRU updates it to a character that should not be found in the JAVA_ARGS value, namely '\001'.
* This is the same solution Debian and tomcat maintainers are now using for Tomcat8.
[Test Case]
An example to test Tomcat7 on Trusty. The same instructions can apply to Tomcat8 on the other releases.
Overview: Install the version from the current release. Modify JAVA_OPTS and then install the version from proposed to validate it upgrades successfully.
* lxc launch ubuntu-daily:trusty trusty
* lxc exec trusty bash
* apt install tomcat7
* Edit /etc/default/
* # Enable proposed
* apt update
* apt install tomcat7
* When asked, 'Keep the local version currently installed'
* With the fix, install will complete
* Without the fix, the error as described under "Other Info" will appear
[Regression Potential]
* Users currently experiencing this issue would be expecting a SRU fix to come from us. Working around it would require changing their JAVA_OPTS temporarily, accepting the maintainers version of the defaults script, or modifying the package's postinst script directly.
* In either case the proposed fix will over write any changes an end user may have made to the postinst, and all for correctly working expected behavior.
* There is the slight, albeit incredibly low chance, that someone actually has the '\001' character in their JAVA_OPTS. In which, case the upgrade would fail as this bug describes.
[Other Info]
* Using a new delimiter that is far less likely to be in someone's path. This is not the first time the delimiter has changed, as it originally as '/' which is obviously going to show up as soon as someone adds a path.
* Upstream change to tomcat8: https:/
* Error message on failure:
Setting up tomcat7 (7.0.52-
sed: -e expression #1, char 97: unknown option to `s'
dpkg: error processing package tomcat7 (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
tomcat7
E: Sub-process /usr/bin/dpkg returned an error code (1)
== End SRU Template ==
description: | updated |
Changed in tomcat7 (Debian): | |
status: | Unknown → New |
description: | updated |
description: | updated |
Changed in tomcat8 (Debian): | |
status: | Unknown → Fix Released |
no longer affects: | tomcat7 (Ubuntu Zesty) |
no longer affects: | tomcat7 (Ubuntu) |
Changed in tomcat7 (Debian): | |
status: | New → Fix Released |
Changed in tomcat7 (Ubuntu Trusty): | |
assignee: | Joshua Powers (powersj) → nobody |
Changed in tomcat8 (Ubuntu Zesty): | |
assignee: | Joshua Powers (powersj) → nobody |
Changed in tomcat8 (Ubuntu Xenial): | |
assignee: | Joshua Powers (powersj) → nobody |
Changed in tomcat8 (Ubuntu): | |
assignee: | Joshua Powers (powersj) → nobody |
Changed in tomcat7 (Ubuntu Xenial): | |
assignee: | Joshua Powers (powersj) → nobody |
Changed in tomcat8 (Ubuntu Yakkety): | |
assignee: | Joshua Powers (powersj) → nobody |
Changed in tomcat7 (Ubuntu Xenial): | |
status: | Triaged → Won't Fix |
Thank you for taking the time to file a bug report and try to solve it!
Looking at your proposed resolution if we were to escape the $ then it
would replace %JAVA_OPTS with $JAVA_OPTS, however I do not believe that
is what we want. The goal of this line is to set the JAVA_OPTS based on
the following:
db_get tomcat7/javaopts && JAVA_OPTS="$RET" || JAVA_OPTS= "-Djava. awt.headless= true -Xmx128m -XX:+UseConcMar kSweepGC"
You will also note how the previous two lines do not escape
$TOMCAT7_USER or $TOMCAT7_GROUP.
My initial guess is that JAVA_OPTS may have the '%' character in it.
That would in turn mess up the sed command since '%' is used as the
delimiter in that statement. In fact there was a similar Debian bug [1]
reported about this issue with the '/' character. There is a comment
as to changing to '%' as it shows up less often :)
[1] https:/ /bugs.debian. org/cgi- bin/bugreport. cgi?bug= 597814