* [gentoo-user] CONFIG_PROTECT problem
@ 2005-07-15 14:31 Peter Campion-Bye
2005-07-15 18:28 ` Richard Fish
2005-07-15 18:32 ` Edward Catmur
0 siblings, 2 replies; 3+ messages in thread
From: Peter Campion-Bye @ 2005-07-15 14:31 UTC (permalink / raw
To: gentoo-user
Hi,
Apologies if I've misunderstood the use of CONFIG_PROTECT, but I think
I've found a hole in it. As I have lots of stuff under
/var/www/localhost/htdocs which contains configuration files mixed in with
the code ( phpmyadmin, phpldapadmin, phpwiki, squirrelmail, gallery etc )
I have put the path /var/www/localhost/htdocs into CONFIG_PROTECT in
make.conf. When one of these packages is upgraded this seems to work fine.
Last night, after upgrading PHP to 4.4.0 my wiki was broken. I thought a
good place to start would be to re-emerge phpwiki, so I did. During the
emerge it flashed up a message about this being a package that it couldn't
upgrade, so it would be unmerged it first. It appears that this bypassed
the CONFIG_PROTECT mechanism, as when the new files were installed the
original had been removed, so no ._cfg0000_ files were created for the
changed files.
Having no recent backup (lesson learned!) I had to recreate the phpwiki
config, which is a non-trivial job.
So the question is, how can config files be protected in this kind of
situation (other than backing them up) - is there another mechanism to
protect files from being overwritten, and how many packages are likely to
do an unmerge before re-emerging, and is there ay way of knowing? I
believe the default behaviour on umnerging a package is to leave its
configuration files in place, this doesn't seem to apply to the web apps.
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-user] CONFIG_PROTECT problem
2005-07-15 14:31 [gentoo-user] CONFIG_PROTECT problem Peter Campion-Bye
@ 2005-07-15 18:28 ` Richard Fish
2005-07-15 18:32 ` Edward Catmur
1 sibling, 0 replies; 3+ messages in thread
From: Richard Fish @ 2005-07-15 18:28 UTC (permalink / raw
To: gentoo-user
Peter Campion-Bye wrote:
>Hi,
>Apologies if I've misunderstood the use of CONFIG_PROTECT, but I think
>I've found a hole in it. As I have lots of stuff under
>/var/www/localhost/htdocs which contains configuration files mixed in with
>the code ( phpmyadmin, phpldapadmin, phpwiki, squirrelmail, gallery etc )
>I have put the path /var/www/localhost/htdocs into CONFIG_PROTECT in
>make.conf. When one of these packages is upgraded this seems to work fine.
>Last night, after upgrading PHP to 4.4.0 my wiki was broken. I thought a
>good place to start would be to re-emerge phpwiki, so I did. During the
>emerge it flashed up a message about this being a package that it couldn't
>upgrade, so it would be unmerged it first. It appears that this bypassed
>the CONFIG_PROTECT mechanism, as when the new files were installed the
>original had been removed, so no ._cfg0000_ files were created for the
>changed files.
>Having no recent backup (lesson learned!) I had to recreate the phpwiki
>config, which is a non-trivial job.
>So the question is, how can config files be protected in this kind of
>situation (other than backing them up) - is there another mechanism to
>protect files from being overwritten, and how many packages are likely to
>do an unmerge before re-emerging, and is there ay way of knowing? I
>believe the default behaviour on umnerging a package is to leave its
>configuration files in place, this doesn't seem to apply to the web apps
>
>
Ouch. Do you by chance have CONFIG_PROTECT_MASK set also? Check
"emerge --info"..
-Richard
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [gentoo-user] CONFIG_PROTECT problem
2005-07-15 14:31 [gentoo-user] CONFIG_PROTECT problem Peter Campion-Bye
2005-07-15 18:28 ` Richard Fish
@ 2005-07-15 18:32 ` Edward Catmur
1 sibling, 0 replies; 3+ messages in thread
From: Edward Catmur @ 2005-07-15 18:32 UTC (permalink / raw
To: gentoo-user
On Fri, 2005-07-15 at 15:31 +0100, Peter Campion-Bye wrote:
> Hi,
> Apologies if I've misunderstood the use of CONFIG_PROTECT, but I think
> I've found a hole in it. As I have lots of stuff under
> /var/www/localhost/htdocs which contains configuration files mixed in with
> the code ( phpmyadmin, phpldapadmin, phpwiki, squirrelmail, gallery etc )
> I have put the path /var/www/localhost/htdocs into CONFIG_PROTECT in
> make.conf. When one of these packages is upgraded this seems to work fine.
> Last night, after upgrading PHP to 4.4.0 my wiki was broken. I thought a
> good place to start would be to re-emerge phpwiki, so I did. During the
> emerge it flashed up a message about this being a package that it couldn't
> upgrade, so it would be unmerged it first. It appears that this bypassed
> the CONFIG_PROTECT mechanism, as when the new files were installed the
> original had been removed, so no ._cfg0000_ files were created for the
> changed files.
> Having no recent backup (lesson learned!) I had to recreate the phpwiki
> config, which is a non-trivial job.
> So the question is, how can config files be protected in this kind of
> situation (other than backing them up) - is there another mechanism to
> protect files from being overwritten, and how many packages are likely to
> do an unmerge before re-emerging, and is there ay way of knowing? I
> believe the default behaviour on umnerging a package is to leave its
> configuration files in place, this doesn't seem to apply to the web apps.
phpwiki I believe uses webapp-config rather than the default ebuild
staging method of installing applications. Have you read the
documentation to webapp-config?
--
gentoo-user@gentoo.org mailing list
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-07-15 18:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-07-15 14:31 [gentoo-user] CONFIG_PROTECT problem Peter Campion-Bye
2005-07-15 18:28 ` Richard Fish
2005-07-15 18:32 ` Edward Catmur
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox