Bug#315467: missing kill-quagga-prompt when upgrading

2005-07-01 Thread Achilleas Kotsis
I think this bug's severity should be set to wishlist, losing routes 
temporarily because of a daemon restart does not count as data
loss.
Nearly every daemon gets restarted after installation, dh_installinit 
(debhelper) defaults to that anyway.

Nevertheless, please consider restarting quagga after installation, or adding a 
debconf prompt of choosing between a
stop-upgrade-start and an upgrade-restart path. openvpn does that, I quote the 
debconf dialog:


In some cases you may be upgrading openvpn in a remote server using a VPN to do 
so. The upgrade process stops the
running daemon before installing the new version, in that case you may lose 
your connection, the upgrade may be
interrupted, and you may not be able to reconnect to the remote host.
Unless you do your upgrades locally, it is advised NOT to stop openvpn before 
it gets upgraded. The installation
process will restart it once it's done.

This option will take effect in your next upgrade.
Would you like to stop openvpn before it gets upgraded?


I think this should be the case with quagga. If you try to upgade a remote 
router and you rely on quagga running to have your
connection established, you will get disconnected before the upgrade and the 
upgrade will probably fail if user input is needed (eg.
upgrading a conffile).

Achilleas Kotsis a.k.a. Achille
Webpage: http://www.cslab.ntua.gr/~akots/
AWMN.org: http://www.awmn.org/
-- whois awk?, sed Grep --



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#315467: missing kill-quagga-prompt when upgrading

2005-06-23 Thread Michael Horn
Please have a look at how openvpn is upgraded. people like you are the 
source of instability in the global routing table. Have a nice day.


regards Michael Horn
...who switched to lfs or openbgpd instead of debian.

p.s. you might want to read up a bit on how the world out there works 
before building crappy packets and annoying other people with 'em.

--
Michael Horn Network Consulting | nibbler.de | I route, therefore you are
+
Po.Box 810221 | 90247 Nuremberg | GSM: +4916 | FAX: +49162345



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#315467: missing kill-quagga-prompt when upgrading

2005-06-23 Thread Christian Hammers
Hello

On 2005-06-23 Michael Horn wrote:
 people like you are the source of instability in the global routing table
[...]
 regards Michael Horn
 ...who switched to lfs or openbgpd instead of debian.

(lfs = Linux From Scratch?)

The only source of routing table instability is the reconnection that
happens when the old daemon is stopped and the new is started.

So did you check if you are really able to upgrade the BGP server daemon
from OpenBGPd or whichever LFS might use *without* having to reconnect?

BGP uses TCP connections and so far I have never seen a daemon that really
tries to handover a running TCP connection to another daemon or uses a
mini-proxy to keep the real binary behind that (which in both cases would
be far beyond Debian packaging but major work for the authors of Quagga).

I would be interested in a working example on how somebody was able to
do it better to submit it as feature request on 
[EMAIL PROTECTED]
(you might want to start a discussion there yourself)

bye,

-christian-


P.S.: I only focused on the above issue. That servers are generally shutdown 
immediately
  when they are upgraded and thus upgrades of critical packages should only 
happen
  during maintenance windows, is simply the way Debian works. If you don't 
like this, 
  I'm sorry that I have to recommend you to another distro then.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#315467: missing kill-quagga-prompt when upgrading

2005-06-22 Thread Michael Horn
Package: quagga
Version: 0.98.3-1
Severity: grave
Justification: causes non-serious data loss


updating quagga it removes all (163k) routes from the kernel without
prompting - this leads to extreme suffering in real-world scenarios.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages quagga depends on:
ii  debconf 1.4.30.13Debian configuration management sy
ii  iproute 20041019-3   Professional tools to control the 
ii  libc6   2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libcap1 1:1.10-14support for getting/setting POSIX.
ii  libncurses5 5.4-4Shared libraries for terminal hand
ii  libpam0g0.76-22  Pluggable Authentication Modules l
ii  libreadline44.3-11   GNU readline and history libraries
ii  libsnmp55.1.2-6.1NET SNMP (Simple Network Managemen
ii  libssl0.9.7 0.9.7e-3 SSL shared libraries
ii  logrotate   3.7-2Log rotation utility

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#315467: missing kill-quagga-prompt when upgrading

2005-06-22 Thread Christian Hammers
Hello Michael

On 2005-06-22 Michael Horn wrote:
 updating quagga it removes all (163k) routes from the kernel without
 prompting - this leads to extreme suffering in real-world scenarios.

Eh? How exactly do you expect a server to get upgraded without getting
restarted? Or do you just mean it should just not delete the routes
when stopping?

The latter is explained with the fact that Quagga cannot know from which 
daemon a route has been inserted once it is there and would have severy
problems when starting up with all routes alredy present because even if
e.g. ospfd would be shutdown, it cannot safely decide if a given route
may now be killed if that route had already been present when Quagga had
been started.

You can normally assume that upgrading any Unix daemon means shutting it
down and afterwards restarting it again. Just like a Cisco router AFAIK 
cannot be upgraded to a new IOS version while continuing to run.

bye,

-christian-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#315467: missing kill-quagga-prompt when upgrading

2005-06-22 Thread Michael Horn

Hello Christian,

On Wed, 22 Jun 2005, Christian Hammers wrote:


Hello Michael

On 2005-06-22 Michael Horn wrote:

updating quagga it removes all (163k) routes from the kernel without
prompting - this leads to extreme suffering in real-world scenarios.


Eh? How exactly do you expect a server to get upgraded without getting
restarted? Or do you just mean it should just not delete the routes
when stopping?


is should ask the user if it should. possibly one could employ a way to do 
the update only on the next restart of the demon.



The latter is explained with the fact that Quagga cannot know from which
daemon a route has been inserted once it is there and would have severy
problems when starting up with all routes alredy present because even if
e.g. ospfd would be shutdown, it cannot safely decide if a given route
may now be killed if that route had already been present when Quagga had
been started.


yes - that's perfectly true.


You can normally assume that upgrading any Unix daemon means shutting it
down and afterwards restarting it again. Just like a Cisco router AFAIK
cannot be upgraded to a new IOS version while continuing to run.


cisco!=x86 quagga box ;)

after all - i just expect a software to warn me before it could cause 
severe problems like a restarting quagga. so the best way to prevent users 
from being scared to death would be if you warn them before you kill their 
routing demon.


regards,
Michael

--
Michael Horn Network Consulting | nibbler.de | I route, therefore you are
+
Po.Box 810221 | 90247 Nuremberg | GSM: +4916 | FAX: +49162345



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#315467: missing kill-quagga-prompt when upgrading

2005-06-22 Thread Christian Hammers
Hello Michael

On 2005-06-22 Michael Horn wrote:
 cisco!=x86 quagga box ;)
 
 after all - i just expect a software to warn me before it could cause 
 severe problems like a restarting quagga. so the best way to prevent users 
 from being scared to death would be if you warn them before you kill their 
 routing demon.

Sorry, bug after all it was you who requested that the daemon should be
upgraded. It's the way Unix and esp. Debian Linux works that when upgrading
a server, it is stopped, the new files are installed and then started.
Apache, MySQL, BIND, all work this way. And as a routing daemon like Quagga
normally does not run on any box but on a router I only expect somewhat
experienced admins as users.

Of course, just installing the new version but not restarting it might
be possible but IMHO is at least as dangerous as you might not know if
the next reboot happens to be on a crash during the night and expecting
to have a brand new version running perfectly might not be the savest thing
to do. It would be quite unexpected for normal Linux admins, too and major
work for me... 
If on the other hand you planned the downtime anyway, just wait for it with
upgrading the package... 

BTW, you exclude packages from normal apt-get upgrade runs with
echo quagga hold | dpkg --set-selections
it then just gets upgraded when you explicitly ask for it with
apt-get install quagga.

bye,

-christian-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#315467: missing kill-quagga-prompt when upgrading

2005-06-22 Thread Florian Weimer
* Christian Hammers:

 Sorry, bug after all it was you who requested that the daemon should be
 upgraded. It's the way Unix and esp. Debian Linux works that when upgrading
 a server, it is stopped, the new files are installed and then started.
 Apache, MySQL, BIND, all work this way.

Apache's Debian doesn't, AFAIK, but I share your view: the service has
to be restarted if an update is requested.  Graceful handover to a new
daemon would be a nice thing to have -- it's not just the kernel
routes which cause problems.  Your BGP sessions flap as well.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]