I just upgraded mantis from 1.1.2-r1 to 1.1.4 via "webapp-config -U -h localhost -d mantisbt mantisbt 1.1.4". This overwrote my existing config_inc.php file with the sample file. Reproducible: Always Previous upgrades have always asked config protected this file.
This is not entirely reproducible.. On one machine I have 2 installations of mantisbt using VHOST. One of them overwrote the config file as described by the bug, but the other had the correct behaviour with config protected file. Another machine where I only have one installation of mantisbt overwrote the config file.
I have the vhost USE flag enabled, but I have only a single install. Sounds like the first install is the only one effected? emerge --info: Portage 2.1.4.5 (default/linux/x86/2008.0/server, gcc-3.4.6, glibc-2.6.1-r0, 2.6.23-gentoo-r8 i686) ================================================================= System uname: 2.6.23-gentoo-r8 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz Timestamp of tree: Wed, 22 Oct 2008 13:34:01 +0000 app-shells/bash: 3.2_p33 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium4 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://www.gtlib.gatech.edu/pub/gentoo http://gentoo.chem.wisc.edu/gentoo/ http://gentoo.cites.uiuc.edu/pub/gentoo/ ftp://mirror.datapipe.net/gentoo http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://open-systems.ufl.edu/mirrors/gentoo http://gentoo.mirrors.hoobly.com/ http://lug.mtu.edu/gentoo/" LDFLAGS="-Wl,-O1" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="apache2 bash-completion berkdb bzip2 cgi cli cracklib crypt dri gd gdbm gpm hal iconv isdnlog jpeg jpeg2k mailwrapper md5sum midi mime mudflap mysql ncurses network-cron nfs nptl nptlonly openmp pam pcre perl png pppd python readline reflection sasl session snmp spl sse2 ssl sysfs tcpd tiff truetype unicode urandom vhosts wmf x86 xml xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Well, this is really not so reproducible but I remember this was already reported some time ago... So at least this bug is confirmed. Since ebuild marks file correctly I feel this is bug in webapp-config. Assigning bug appropriately.
I've done a bit more experimenting. Running webapp-config -U several times and observing whether or not it overwrites config_inc.php, it seems to do it every alternate time (I removed any ._cfg files and copied the original config_inc.php back each time). The difference I can see is that in .webapp-mantisbt-1.1.4-r3 On a run that didn't overwrite it has the line: file 1 config-owned "config_inc.php" 1226773164 4c60109bbc91dfe5fcf13d00005569d7 And on a run that did overwrite it has: file 1 config-owned "config_inc.php" 1226771425 6b864b628df59e753e1dfb1f866d1c22 The last value is an MD5 hash of the file. After a correct run (Where it made a ._cfg file) the it is the md5sum of the existing config_inc.php On the next run, I suspect the logic looks sees that the MD5 checksums match and mistakingly assumes it is OK to overwrite it. This seems to be confirmed my more experiments: If I edit .webapp-mantisbt-1.1.4-r3 and modify a digit of the md5 of config_inc.php then an upgrade works correctly. If I leave it so it matches my existing config_inc.php then the upgrade overwrites it.
In WebappConfig: content.py in function def get_canremove(self, entry) is this bit of commented out code: This could explain these symptoms as it would then overwrite the file if its timestamp and md5 are the same as they were after the previous install/upgrade. # This is config protected. Do not remove! #if self.eowner(entry)[0:6] == 'config': # return '!cfgpro ' + self.epath(entry)
I've had 3 config files clobbered on two different machines - phpmyadmin, squirrelmail and wordpress. I didn't notice this immediately since this never happened in the past and one machine is for testing, the other infrequently used. Seems to occur on updates, not on reinstallation. I don't have the vhost useflag set on any of these apps, so webapp-config does an automatic upgrade when emerged. Another seperate issue with webapp-config/portage, post-installation text/info is not logged to the summary.log
This just happened to me again with Mantis. (Last upgrade did notice the config protection and worked as expected. This backs up what Steven said in earlier comments.) Has anyone looked into the lines Steven found?
This problem still occurs while updating an existing installation (v1.1.2) to v1.1.5 using "webapp-config -U ..." (vhost USE flag enabled)
*** Bug 250651 has been marked as a duplicate of this bug. ***
Created attachment 175277 [details, diff] webapp-config-1.50.16-config-protected-md5.patch Thank you Steve for experiments. Now I see what problem is here. webapp-config on upgrade record md5sum of previously modified config file (which is on disc during update) and any subsequent update removes that file since md5sum of file in database (.webapp-app-version file) is the same as on disc. Somebody with better python foo (this is my first python experience...) and knowledge of webapp-config needed to review attached patch. It actually adds another field to function add() which passes real_path into add and calculates md5sum based on that. Probably modification time should be calculated somehow differently too, but I don't think it matters if md5 differs.
*** Bug 346417 has been marked as a duplicate of this bug. ***
Just got hit with this on a Wordpress upgrade. Wiped out my config, but seemed to try to config-protect a lot of unnecessary files. I think the problem here is that the main dev for webapp-config is no longer active with Gentoo, sadly (it would be great if I'm wrong). Shame, because webapp-config is a really cool tool, AFAIK, no equivalents exist with such nice features on the major binary distros. I know that we need less nanny-ing in general, but it does seem that a prudent measure might be for webapp-config to offer some in-band backup of webapps' files before upgrading.
*** Bug 364529 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > Created attachment 175277 [details, diff] > webapp-config-1.50.16-config-protected-md5.patch > > Thank you Steve for experiments. Now I see what problem is here. webapp-config > on upgrade record md5sum of previously modified config file (which is on disc > during update) and any subsequent update removes that file since md5sum of file > in database (.webapp-app-version file) is the same as on disc. Somebody with > better python foo (this is my first python experience...) and knowledge of > webapp-config needed to review attached patch. It actually adds another field > to function add() which passes real_path into add and calculates md5sum based > on that. Probably modification time should be calculated somehow differently > too, but I don't think it matters if md5 differs. I'm not a Python or webapp-config expert, so I cannot comment on the quality of the code, but the functionality is definitely OK. I can repeatedly update roundcube and my config changes are not overwritten.
I'll commit this patch to webapp-config git repo at http://git.overlays.gentoo.org/gitweb/?p=proj/webapp-config.git;a=summary I'll try to keep webapp-config alive but I'm very busy with other stuff.
Committed at http://git.overlays.gentoo.org/gitweb/?p=proj/webapp-config.git;a=commit;h=6f368b35014b67c23d0eea35ed6791718f950af3 @Peter: The patch looks sane, but I changed your tabs to spaces. Python is very picky about indentation. webapp-config uses only spaces, in most places 4 spaces per indent.
I think, that this is a critical bug. When could we expect a version bump with the fix?
(In reply to comment #18) > I think, that this is a critical bug. When could we expect a version bump with > the fix? I'm going to start maintaining this package. Its in bad shape, but I'll do my best. Can you please test the latest HEAD at http://git.overlays.gentoo.org/gitweb/?p=proj/webapp-config.git;a=summary and see if this problem is fixed?
I thought it was already released.
(In reply to comment #20) > I thought it was already released. Nope the commit in comment 17 was after the last release. If you want to wait, I'll release again soon. You can test then.
It just happened to me with 1.50.18 while upgrading postfixadmin the config.inc.php was overwritten with the default and no chance to merge the changes. I just tried Peter's patch from 2008 and it seems to fix the problem for me as well.
(In reply to comment #22) > It just happened to me with 1.50.18 while upgrading postfixadmin the > config.inc.php was overwritten with the default and no chance to merge the > changes. I just tried Peter's patch from 2008 and it seems to fix the > problem for me as well. Okay, as slow as my maintenance of this is going, I should push out a release with this fix. Please don't be polite and poke me if its not out in a couple of days.
(In reply to comment #23) > (In reply to comment #22) > > It just happened to me with 1.50.18 while upgrading postfixadmin the > > config.inc.php was overwritten with the default and no chance to merge the > > changes. I just tried Peter's patch from 2008 and it seems to fix the > > problem for me as well. > > Okay, as slow as my maintenance of this is going, I should push out a > release with this fix. Please don't be polite and poke me if its not out in > a couple of days. Okay I've added webapp-config-1.50.19.ebuild to the tree. It should include the fix. Would you please test and let me know if it works for you so I can close this ancient bug :)
(In reply to comment #24) > (In reply to comment #23) > > (In reply to comment #22) > > > It just happened to me with 1.50.18 while upgrading postfixadmin the > > > config.inc.php was overwritten with the default and no chance to merge the > > > changes. I just tried Peter's patch from 2008 and it seems to fix the > > > problem for me as well. > > > > Okay, as slow as my maintenance of this is going, I should push out a > > release with this fix. Please don't be polite and poke me if its not out in > > a couple of days. > > Okay I've added webapp-config-1.50.19.ebuild to the tree. It should include > the fix. Would you please test and let me know if it works for you so I can > close this ancient bug :) Thanks very much, I have tried the new version and it seems to work properly for me.
(In reply to comment #25) > (In reply to comment #24) > > (In reply to comment #23) > > > (In reply to comment #22) > > > > It just happened to me with 1.50.18 while upgrading postfixadmin the > > > > config.inc.php was overwritten with the default and no chance to merge the > > > > changes. I just tried Peter's patch from 2008 and it seems to fix the > > > > problem for me as well. > > > > > > Okay, as slow as my maintenance of this is going, I should push out a > > > release with this fix. Please don't be polite and poke me if its not out in > > > a couple of days. > > > > Okay I've added webapp-config-1.50.19.ebuild to the tree. It should include > > the fix. Would you please test and let me know if it works for you so I can > > close this ancient bug :) > > Thanks very much, I have tried the new version and it seems to work properly > for me. Me too. So I'll close this for now, but please feel free to reopen if this issue returns. If its a different issue, start a new bug.
*** Bug 326789 has been marked as a duplicate of this bug. ***
(In reply to Anthony Basile from comment #26) > Me too. So I'll close this for now, but please feel free to reopen if this > issue returns. If its a different issue, start a new bug. Could mail-client/roundcube please be made to RDEPEND on the fixed versions of app-admin/webapp-config to avoid new users (like me) from bumping into this? Or at least warn them before they lose their configuration files.
(In reply to Jaak Ristioja from comment #28) > (In reply to Anthony Basile from comment #26) > > Me too. So I'll close this for now, but please feel free to reopen if this > > issue returns. If its a different issue, start a new bug. > > Could mail-client/roundcube please be made to RDEPEND on the fixed versions > of app-admin/webapp-config to avoid new users (like me) from bumping into > this? Or at least warn them before they lose their configuration files. I'm really confused. 1) we believe the problem is fixed, so you shouldn't loose your config, and if you are still worried, then back it up manually. 2) what does roundcube have to do with this issue?
Actually, I had this happen again to me a few months ago. I meant to post about it then, but forgot to. (Luckily I've been keeping backups.)
I think the real problem at the moment is that the fixed version of webapp-config is not in stable, whereas the actual web applications are already stable in the portage tree. Hence stable users don't actually get the bugfix in app-admin/webapp-config-1.50.19 which is still in ~testing, and keep bumping into this bug.
Jaak is probably right. I'm on webapp-config-1.50.16-r4 as I have no special unmasking/keywording for webapp-config. Wow, I would have expected the fix to make it to the masses in over a year.
*** Bug 510144 has been marked as a duplicate of this bug. ***
