Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
On 2016-05-28 22:21, Stefan Fritsch wrote: > I think I have a patch that does this correctly. Sounds promising. Be Is it generic enough s.t. it could be reused by other packages with similar problems? (right now I remember squid and libreoffice, but I think there were more) > Is it possible with piuparts to test these upgrade paths: > > wheezy -> jessie 8.0 -> stretch > wheezy -> jessie 8.recent -> stretch > wheezy -> jessie 8.0 -> jessie 8.recent -> stretch > > It may be a bit complicated because 8.0 is not on the mirrors anymore. we could use archive.d.org > If yes, would you have time to do the testing? Thanks in advance. If you help me a bit :-) It will require some scripting ... and maybe some new piuparts features to be coded - on my side. Do you have only one set of new packages for stretch to be tested or are there new packages targeting jessie as well? So the upgrade path will actually be wheezy -> jessie X.Y -> stretch+new (or up to wheezy -> jessie X.Y -> jessie X.Z(+new) -> stretch -> stetch+new) (with a "reference" ending in plain stretch, to see if you actually fixed something) Build the packages for amd64 and put them together with a Packages.gz on some webspace. If it's more than one source package for a distro - no problem, throw them all into one repo. Version must be higher than the version in stretch, s.t. I can use stretch + your repo and have apt do the right thing. If there are packages for jessie (or a different package set to be tested for stretch), put them in another repo. Can you find the sources.list entry needed to install jessie 8.0 from archive.d.org? (Full jessie 8.0, not just a few packages.) Then I need a list of packages (indivudal ones or sets, from wheezy) to be tested on these upgrade paths. And there is the option --with-recommends, if needed. You'll get some logfiles to analyze in return. Sounds not too complicated :-) Andreas PS: Do you want to do tests with user-modified conffiles as well? These should probably get prompts and "fail". Requires a recipe for modification.
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
Here is a status update. In 2.4.10-10+deb8u2 in the Debian 8.2 point release, I have included this fix: * Fix upgrade logic: When upgrading from wheezy with apache2.2-common but without apache2 installed to jessie, part of the conffile handling logic would not run, causing outdated conffile content to be kept. This is part of the solution for bug #794933. The other part will be included in the upgrade to Debian 9 (stretch). This means that systems that were upgraded from wheezy direcly to jessie 8.2 or newer won't encounter the bug. But those systems that were upgraded to an early version of jessie now have some conffiles with old contents from wheezy instead of the new content from jessie. And dpkg thinks that the user changed the conffiles, which will cause conffile questions during the next upgrade that changes the affected conffiles. To avoid these questions, I intend to * include the correct content of the conffiles base64 encoded in the preinst. This is very ugly but there seems to be no other way. In preinst, the files of the new package are not unpacked, yet. * check in preinst if the conffiles on disk match the wheezy versions * if yes, replace them with the correct version (and save backup copies) * let dpkg do the upgrade. dpkg will not ask questions about the affected conffiles because they already have exactly the same content as in the new package. * in postinst, delete the saved copies of the old content I think I have a patch that does this correctly. Is it possible with piuparts to test these upgrade paths: wheezy -> jessie 8.0 -> stretch wheezy -> jessie 8.recent -> stretch wheezy -> jessie 8.0 -> jessie 8.recent -> stretch It may be a bit complicated because 8.0 is not on the mirrors anymore. If yes, would you have time to do the testing? Thanks in advance. Cheers, Stefan
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
AFAICS, this happens when one upgrades from wheezy from a state where only apache2.2-common is installed but not apache2. There is a bug in apache2's preinst in jessie that makes it not recognize this case and not execute the conffile handling. While I think I have a fix, I am not not sure that I want to change the upgrade logic in a stable point release. FTR, attached is the diff I meant (redone from memory and not re-tested).diff --git a/debian/apache2.preinst b/debian/apache2.preinst index ed5a382..1adc647 100644 --- a/debian/apache2.preinst +++ b/debian/apache2.preinst @@ -49,8 +49,9 @@ obsolete_conffile_exists() fi done - for CONFFILE in $MOVED_CONFFILES_IN ; do - if [ -e /etc/apache2/conf.d/$CONFFILE ] ; then + for CONFFILE in $MOVED_CONFFILES ; do + CONFFILE=$( echo $CONFFILE | cut -d: -f1 ) + if [ -e $CONFFILE ] ; then return 0 fi done
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
Package: apache2-suexec-custom Version: 2.4.16-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package failed the piuparts upgrade test because dpkg detected a conffile as being modified and then prompted the user for an action. As there is no user input, this fails. But this is not the real problem, the real problem is that this prompt shows up in the first place, as there was nobody modifying this conffile at all, the package has just been installed and upgraded... This is a violation of policy 10.7.3, see https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3, which says [These scripts handling conffiles] must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens. https://wiki.debian.org/DpkgConffileHandling should help with figuring out how to do this properly. In https://lists.debian.org/debian-devel/2009/08/msg00675.html and followups it has been agreed that these bugs are to be filed with severity serious. From the attached log (scroll to the bottom...): Setting up apache2 (2.4.16-1) ... Configuration file '/etc/apache2/conf-available/security.conf' == Modified (by you or by a script) since installation. == Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** security.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package apache2 (--configure): end of file on stdin at conffile prompt This was observed while doing a wheezy - jessie - stretch upgrade test. I did not see such behavior while testing the other apache packages. cheers, Andreas apache2-suexec-custom_2.4.16-1.log.gz Description: application/gzip
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
On Saturday 08 August 2015 11:38:14, Andreas Beckmann wrote: during a test with piuparts I noticed your package failed the piuparts upgrade test because dpkg detected a conffile as being modified and then prompted the user for an action. As there is no user input, this fails. But this is not the real problem, the real problem is that this prompt shows up in the first place, as there was nobody modifying this conffile at all, the package has just been installed and upgraded... This was observed while doing a wheezy - jessie - stretch upgrade test. I did not see such behavior while testing the other apache packages. AFAICS, this happens when one upgrades from wheezy from a state where only apache2.2-common is installed but not apache2. There is a bug in apache2's preinst in jessie that makes it not recognize this case and not execute the conffile handling. While I think I have a fix, I am not not sure that I want to change the upgrade logic in a stable point release. I will have to think about it. If you are at debconf, maybe we can talk about it there. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/10987462.0zZFbdI45S@k
Bug#794933: apache2-suexec-custom: prompting due to modified conffiles which were not modified by the user: /etc/apache2/conf-available/security.conf
On 2015-08-08 22:34, Stefan Fritsch wrote: On Saturday 08 August 2015 11:38:14, Andreas Beckmann wrote: This was observed while doing a wheezy - jessie - stretch upgrade test. I did not see such behavior while testing the other apache packages. This now shows up on all (or at least a lot of) upgrade paths involving apache packages (many php packages among them), so apache2-suexec-custom was only the first to fail. Always while Setting up apache2 (2.4.16-1). AFAICS, this happens when one upgrades from wheezy from a state where only apache2.2-common is installed but not apache2. There is a bug in apache2's preinst in jessie that makes it not recognize this case and not execute the conffile handling. While I think I have a fix, I am not not sure that I want to change the upgrade logic in a stable point release. I haven't seen this bug in upgrades to jessie so far, only in the followup upgrade to stretch. This could be the case if that conffile has not changed between wheezy and jessie, but changes from jessie to stretch ... (and it would blow up in jessie, too, if you would ever have to ship an updated version of that conffile in jessie). So maybe it is not neccessary to fix it in jessie if it can be fixed in stretch instead. If you have a patch, I could check the specific upgrade paths in my piuparts setup (without uploading to sid and waiting for a migration to testing). I will have to think about it. If you are at debconf, maybe we can talk about it there. No, I'll be on holidays then ... Andreas -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55c66e58.6090...@debian.org
