Bug#557785: vzctl: symlinked config file: symlink overwritten when --save isspecified
Robert Heinzmann
Version: 3.0.22-14
Severity: normal
If you use symlinks like: /etc/vz/conf/<id>.conf ->
/vz/<id>/conf/<id>.conf, which is very helpfull for DRBD or replicated
setups, the symlink in /etc/vz/conf/<id>.conf is overwritten when you
change the config file with --save.
This bug is known and there is a fix for it in GIT.
http://bugzilla.openvz.org/show_bug.cgi?id=1270
It would be great if this patch would be backported for 3.0.22 to enable
HA setups with shared storage.
Regards,
Robert
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-openvz-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages vzctl depends on:
ii iproute 20080725-2 networking and traffic
control too
ii libc6 2.7-18 GNU C Library: Shared
libraries
ii vzquota 3.0.11-1 server virtualization
solution - q
Versions of packages vzctl recommends:
ii rsync 3.0.3-2 fast remote file copy
program (lik
Versions of packages vzctl suggests:
pn linux-patch-openvz <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ola Lundqvist
Thanks a lot for your report.
On Tue, Nov 24, 2009 at 01:38:02PM +0100, Robert Heinzmann wrote:
> Package: vzctl
> Version: 3.0.22-14
> Severity: normal
>
> If you use symlinks like: /etc/vz/conf/<id>.conf ->
> /vz/<id>/conf/<id>.conf, which is very helpfull for DRBD or replicated
> setups, the symlink in /etc/vz/conf/<id>.conf is overwritten when you
> change the config file with --save.
>
> This bug is known and there is a fix for it in GIT.
>
> http://bugzilla.openvz.org/show_bug.cgi?id=1270
>
> It would be great if this patch would be backported for 3.0.22 to enable
> HA setups with shared storage.
I agree, but this is hard due to that the 3.0.22 version is
in stable and stable is only updated because of really important bugs
like data corruption or serious security fixes.
However it depends on the percieved severity of this issue. It is a
form of data corruption so it may be possible. What is your opinion on this
matter?
What I can do is to backport this to the version in stable (3.0.23) but
I'm not sure it is worth it as the 3.0.24 should be available quite soon.
Kir may know more in this area.
Best regards,
// Ola
> Regards,
> Robert
>
>
>
> -- System Information:
> Debian Release: 5.0.3
> APT prefers stable
> APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 2.6.26-2-openvz-amd64 (SMP w/8 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/bash
>
> Versions of packages vzctl depends on:
> ii iproute 20080725-2 networking and traffic
> control too
> ii libc6 2.7-18 GNU C Library: Shared
> libraries
> ii vzquota 3.0.11-1 server virtualization
> solution - q
>
> Versions of packages vzctl recommends:
> ii rsync 3.0.3-2 fast remote file copy
> program (lik
>
> Versions of packages vzctl suggests:
> pn linux-patch-openvz <none> (no description available)
>
> -- no debconf information
>
>
>
--
--------------------- Ola Lundqvist ---------------------------
/ op...@debian.org Annebergsslingan 37 \
| o...@inguza.com 654 65 KARLSTAD |
| http://inguza.com/ +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Robert Heinzmann
Is this a data corruption issue ? I think not in the first place, but It can become one.
Consider the typical HA scenario (* is the active config and node):
[NODEA*]-- --- [NODEB]
|
[CFG*]
(shared storage
/ drbd)
Let's assume you are changing the IP of the machine, or some other config parameter like some disk device on NODEA with --save. What happens is:
Before Failover, after --save:
[NODEA*] --- [NODEB]
| |
[modCFG*] [CFG]
Everythign runs fine. Now if you are NOT aware of the bug, if you failover, your old config is restored and you may access wrong devices, use a wrong IP (duplicate?) etc ... This probably happens weeks after the change (--save) and you will have trouble finding the issue.
After Failover:
[NODEA] --- [NODEB*]
| |
[modCFG] [CFG*]
So for me it seems important that this bug can be found by people looking for this. If it needs fixing - yes, but how ?
A)
* Fix in stable
(This will probably not break any existing configurations, it will just keep links that were removed before)
Pro: would help fast
Pro: no side effetcs
Con: does it break anything ?
B)
* Mark this bug as beeing a known bug up and including 3.0.23 in lenny (so that other peaople find it)
* Fix in 3.0.23 (patch)
* Backport 3.0.23 to lenny
Pro: can be done now
Con: what is 3.0.23 - is it a stable release ?
Con: maybe side effects with 3.0.23
C)
* Mark this bug as beeing a known bug up and including 3.0.23 in lenny (so that other peaople find it)
* Wait for 3.0.24 in sid (in the meantime live with a wrapper script/job)
* Backport 3.0.24 to lenny
Pro: 3.0.24 will be the next stable
Con: When will 3.0.24 arrive ?
I think B) is not the best option. For me A) would be nice, hoever I can also live with C) for the sake of stability.
Regards,
Robert
Ola Lundqvist
thanks
Hi Robert and Debian Release team
On Wed, Nov 25, 2009 at 10:17:28AM +0100, Robert Heinzmann wrote:
> Ol� Ola :)
:-)
> Is this a data corruption issue ? I think not in the first place, but It can become one.
>
> Consider the typical HA scenario (* is the active config and node):
>
> [NODEA*]-- --- [NODEB]
> |
> [CFG*]
> (shared storage
> / drbd)
>
> Let's assume you are changing the IP of the machine, or some other config parameter like some disk device on NODEA with --save. What happens is:
>
>
> Before Failover, after --save:
>
> [NODEA*] --- [NODEB]
> | |
> [modCFG*] [CFG]
>
>
> Everythign runs fine. Now if you are NOT aware of the bug, if you failover, your old config is restored and you may access wrong devices, use a wrong IP (duplicate?) etc ... This probably happens weeks after the change (--save) and you will have trouble finding the issue.
>
> After Failover:
>
> [NODEA] --- [NODEB*]
> | |
> [modCFG] [CFG*]
>
> So for me it seems important that this bug can be found by people looking for this. If it needs fixing - yes, but how ?
I see. Yes this is a data corruption issue, however only in the long term
and only if not following default practice. However it is still important to fix.
> A)
>
> * Fix in stable
> (This will probably not break any existing configurations, it will just keep links that were removed before)
>
> Pro: would help fast
> Pro: no side effetcs
> Con: does it break anything ?
Would be a good thing if stable release team accept this kind of update.
Added:
Con: maybe side effects with 3.0.22 ? Likely not. Just as below.
> B)
>
> * Mark this bug as beeing a known bug up and including 3.0.23 in lenny (so that other peaople find it)
> * Fix in 3.0.23 (patch)
> * Backport 3.0.23 to lenny
>
> Pro: can be done now
> Con: what is 3.0.23 - is it a stable release ?
Yes it is a stable release.
> Con: maybe side effects with 3.0.23
Likely not.
Backporting 3.0.23 is not an option just as backporting 3.0.24 is not an option.
See below.
>
> C)
>
> * Mark this bug as beeing a known bug up and including 3.0.23 in lenny (so that other peaople find it)
> * Wait for 3.0.24 in sid (in the meantime live with a wrapper script/job)
> * Backport 3.0.24 to lenny
>
> Pro: 3.0.24 will be the next stable
> Con: When will 3.0.24 arrive ?
We do not yet know when 3.0.24 will arrive. Upstream have not given a clear statement
about that. Not more than "we should probably release it soon".
Backporting 3.0.24 can be done but only in the backports.org archive and not in the
real stable release. This will never be accepted by the release managers.
>
> I think B) is not the best option. For me A) would be nice, hoever I can also live with C) for the sake of stability.
>
I'd vote for doing the first part of B now (fix in 3.0.23) and then
let the Debian release management decide on whether this is allowed
to be fixed in stable.
Best regards,
// Ola
> Regards,
> Robert
>
>
>
>
--
--------------------- Ola Lundqvist ---------------------------
/ op...@debian.org Annebergsslingan 37 \
| o...@inguza.com 654 65 KARLSTAD |
| http://inguza.com/ +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
--
Adam D. Barratt
Hi,
On Sun, 2009-11-29 at 12:30 +0100, Ola Lundqvist wrote:
> > A)
> >
> > * Fix in stable
> > (This will probably not break any existing configurations, it will just keep links that were removed before)
> >
> > Pro: would help fast
> > Pro: no side effetcs
> > Con: does it break anything ?
>
> Would be a good thing if stable release team accept this kind of update.
> Added:
> Con: maybe side effects with 3.0.22 ? Likely not. Just as below.
Please could you provide a debdiff for your proposed change?
Regards,
Adam