Mailing List Archive

Re: fix for a bug in quagga-0.96.3's OSPF UI
Hi Sangeeta,

I hope you dont mind me Cc'ing quagga-dev - but i think it might be
useful to see if others have opinions. (there's a more general
behavioural issue here, see below).

On Tue, 14 Oct 2003, Sangeeta Misra wrote:

> Paul,
>
> I was trying things with quagga-0.96.3, and noticed that "write file"
> really does not save any of the debug commands that a user might type at
> the ENABLE mode of ospfd telnet UI (ie telnet <machinename> 2604). It
> only works in CONFIGURE mode. This looks broken to me
>
> One way to reproduce this bug is to try out the following steps:
> A. telnet localhost 2604
> B enable
> C sho run ( make sure the command you are about to type in D does not exist)
> D debug ospf event
> E write file
> C sho run ( you will note that the command at Step E really did not get
> saved in ospfd.conf file
> NOTE: You can also do a diff between the .sav file and the updated file
> to see the bug
>
> I have a fix for it - see attched. I would appreciate it if you can
> code review, and provide input as to if this is something that can
> be patched into the Quagga CVS repository

Hmm.... just looking at this now.

While your patch is fine and would solve the immediate problem at
hand, I think there's a bigger problem. Namely, for some reason
Zebra^WQuagga /deliberately/ distinguishes between config node debug
commands (the conf_debug_*) and enable node (term_debug_*).

What exactly the difference is supposed to be, i dont know. Maybe the
correct answer is that all term_debug_* should be cleared when the
user logs off the vty?

Or perhaps the term_debug_*'s should not go to the log file?

I dont know..

Ultimately, I think either have to:

- find some more useful behaviour for enable node debug. Unless the
current "enable node debug does not get saved behaviour" is what
people want.

otherwise:

- just remove the enable node/term_debug_* stuff altogether.

> Thanks in advance
> Sangeeta

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Computers don't actually think.
You just think they think.
(We think.)
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
Paul Jakma wrote:

>On Tue, 14 Oct 2003, Sangeeta Misra wrote:
>
>
>
>> Paul,
>>
>>I was trying things with quagga-0.96.3, and noticed that "write file"
>>really does not save any of the debug commands that a user might type at
>>the ENABLE mode of ospfd telnet UI (ie telnet <machinename> 2604). It
>>only works in CONFIGURE mode. This looks broken to me
>>
>>One way to reproduce this bug is to try out the following steps:
>>A. telnet localhost 2604
>>B enable
>>C sho run ( make sure the command you are about to type in D does not exist)
>>D debug ospf event
>>E write file
>>C sho run ( you will note that the command at Step E really did not get
>>saved in ospfd.conf file
>>NOTE: You can also do a diff between the .sav file and the updated file
>>to see the bug
>>
>>I have a fix for it - see attched. I would appreciate it if you can
>>code review, and provide input as to if this is something that can
>>be patched into the Quagga CVS repository
>>
>>
>
>Hmm.... just looking at this now.
>
>While your patch is fine and would solve the immediate problem at
>hand, I think there's a bigger problem. Namely, for some reason
>Zebra^WQuagga /deliberately/ distinguishes between config node debug
>commands (the conf_debug_*) and enable node (term_debug_*).
>
>What exactly the difference is supposed to be, i dont know.
>
> Maybe the
>correct answer is that all term_debug_* should be cleared when the
>user logs off the vty?
>
>Or perhaps the term_debug_*'s should not go to the log file?
>
>I dont know..
>
I dont know either. But this behaviour is not unique to the ospfd
daemon and applies to all the daemons in Zebra/Quagga software.

>
>Ultimately, I think either have to:
>
>- find some more useful behaviour for enable node debug. Unless the
>current "enable node debug does not get saved behaviour" is what
>people want.
>
I was under the impression that the purpose of View, Enable , and
configure mods were:
View mode - allows user to see current state
Enable node - allows user to debug a daemon
Configure mode - allows user to change configration on the fly and have
all the capabilities of other two modes

If the above is correct then the ability to do "write file" of
debugging options in enable mode makes sense. Is the above not true?


>
>otherwise:
>
>- just remove the enable node/term_debug_* stuff altogether.
>
Can you kindly clarify what you see the purpose of Enable mode to be?

>
>
>
The fix would have to be revisited depending on the resolution of the
above issue.
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
On Sat, 18 Oct 2003, Sangeeta Misra wrote:

> I dont know either. But this behaviour is not unique to the ospfd
> daemon and applies to all the daemons in Zebra/Quagga software.

yep, absolutely. Though notice, eg, bgpd uses macros that effectively
eliminate the differences - if you set one, it sets the other.

> I was under the impression that the purpose of View, Enable , and
> configure mods were:

> View mode - allows user to see current state

> Enable node - allows user to debug a daemon

> Configure mode - allows user to change configration on the fly and have
> all the capabilities of other two modes
>
> If the above is correct then the ability to do "write file" of
> debugging options in enable mode makes sense. Is the above not
> true?

yes, I'd agree with you.

> >- just remove the enable node/term_debug_* stuff altogether.
> >
> Can you kindly clarify what you see the purpose of Enable mode to be?

The flip-side - remove the conf_debug_* stuff - would also make
sense, especially in light of above. I dont know what's right, but
having 2 identical lists of debug commands under 2 different nodes
doesnt make sense to my mind.

I just dont understand why the 2 sets exist, other than that enable
node doesnt get written out to the config file (why would you not?
why would you?).

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Always draw your curves, then plot your reading.
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
Paul Jakma wrote:

...
>>If the above is correct then the ability to do "write file" of
>>debugging options in enable mode makes sense. Is the above not
>>true?
>
>
> yes, I'd agree with you.

I don't: 'write file' generates the configuration of a router, that is,
everything syntactically residing under the config node. Since there's
no configuration outside the config node (ie, in enable node) then this
means dump every configuration command. However, the 'debug ...'
commands are special wrt to this guideline, and I think there are good
reasons for that (see below).

...
> The flip-side - remove the conf_debug_* stuff - would also make
> sense, especially in light of above. I dont know what's right, but
> having 2 identical lists of debug commands under 2 different nodes
> doesnt make sense to my mind.
>
> I just dont understand why the 2 sets exist, other than that enable
> node doesnt get written out to the config file (why would you not?
> why would you?).

There is one major problem with debug command residing in config node
only: config access is exclusive, so if your config node is locked
somehow (somebody holds it, you're using a front-end configuration tool
that retains exclusive access, etc) then you can't debug your router;
since that's bad, I believe that debug commands were made available at
the enable node as well. And, not dumping them during 'write file' makes
a lot of sense to me, from the CLI structure POV (see above).

Plus, I wonder, why does this duality bother you in the first place? I
mean, what's wrong with having a configuration-originated 'debug'
commands, and per-access 'debug' commands (those activated from the
enable node)?

Gilad
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
Gilad Arnold wrote:

>
> Paul Jakma wrote:
>
> ...
>
>>> If the above is correct then the ability to do "write file" of
>>> debugging options in enable mode makes sense. Is the above not
>>> true?
>>
>>
>>
>> yes, I'd agree with you.
>
>
> I don't: 'write file' generates the configuration of a router, that
> is, everything syntactically residing under the config node. Since
> there's no configuration outside the config node (ie, in enable node)
> then this means dump every configuration command. However, the 'debug
> ...' commands are special wrt to this guideline, and I think there are
> good reasons for that (see below).
>
> ...
>
>> The flip-side - remove the conf_debug_* stuff - would also make
>> sense, especially in light of above. I dont know what's right, but
>> having 2 identical lists of debug commands under 2 different nodes
>> doesnt make sense to my mind.
>>
>> I just dont understand why the 2 sets exist, other than that enable
>> node doesnt get written out to the config file (why would you not?
>> why would you?).
>
>
> There is one major problem with debug command residing in config node
> only: config access is exclusive, so if your config node is locked
> somehow (somebody holds it, you're using a front-end configuration
> tool that retains exclusive access, etc) then you can't debug your
> router; since that's bad, I believe that debug commands were made
> available at the enable node as well. And, not dumping them during
> 'write file' makes a lot of sense to me, from the CLI structure POV
> (see above).

Gilad,
So let me see I understand your point. You believe it makes sense to
have debug capabilities in both enable and configure modes,but a user
in enable mode * should not have * "write file/write memory" command
access at all. In fact you would like to see the ability to modify the
config file to be exclusive to the Config node only Correct? It
certainly makes the authorization roles clearer.

However I am wondering if this change is made ( ie essentially remove
"write file /write memory" from enable node) how many current users
will get affected by this.

Paul points out:

Though notice, eg, bgpd uses macros that effectively
eliminate the differences - if you set one, it sets the other.

I think the debugging behaviour should be consistent across all daemons(bgpd doing things differently than the other daemons does not make sense to me)


Sangeeta
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
Hi,


Sangeeta Misra wrote:

>> There is one major problem with debug command residing in config node
>> only: config access is exclusive, so if your config node is locked
>> somehow (somebody holds it, you're using a front-end configuration
>> tool that retains exclusive access, etc) then you can't debug your
>> router; since that's bad, I believe that debug commands were made
>> available at the enable node as well. And, not dumping them during
>> 'write file' makes a lot of sense to me, from the CLI structure POV
>> (see above).
>
>
> Gilad,
> So let me see I understand your point. You believe it makes sense to
> have debug capabilities in both enable and configure modes,but a user
> in enable mode * should not have * "write file/write memory" command
> access at all. In fact you would like to see the ability to modify the
> config file to be exclusive to the Config node only Correct? It
> certainly makes the authorization roles clearer.

I'm not sure we're talking about the same thing: I was referring to the
presence of 'debug ...' commands in both config and enable node, with
different persistency wrt 'write file' (== 'copy running-config
startup-config'). Apparently, you were referring to the location of the
'write file' command itself -- as for this one, generally 'write file'
(or it's new substitute 'copy running-config startup-config') should not
reside in the config node, since it is not a configuration command but
an atomic directive; however, since it's far more convenient to issue
'write file' without leaving the config node each time, I believe the
zebra/quagga's VTY allows a shortcut to this command from each and every
node below enable node.

So, what I'm saying is (as far as my understanding goes, of course):

- 'debug' commands should reside on both enable and config nodes

- those commands, if configured from the config node, are persistent wrt
'write file' command

- as for their instance in the enable node, clearly it shouldn't be
included in the config dump, since it isn't under config node

- there's a legitimate question whether those commands are synonyms to
the same thing, hence are semantically equivalent (that is, turning on
'debug zebra events' at enable node simply triggers the same command in
config node) -- I'm not sure, but I think they shouldn't be.

- the 'write file' command is naturally an enable node one, but using
"syntactic sugar" for it throughout VTY is common practice -- I don't
think it should be changed.


> However I am wondering if this change is made ( ie essentially remove
> "write file /write memory" from enable node) how many current users
> will get affected by this.

You absolutely don't won't to do this, IMO.


> I think the debugging behaviour should be consistent across all
> daemons(bgpd doing things differently than the other daemons does not
> make sense to me)

I agree with that. I just think it requires careful thinking.

Gilad
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
On Sun, 19 Oct 2003, Gilad Arnold wrote:

> I don't: 'write file' generates the configuration of a router, that is,
> everything syntactically residing under the config node.

agreed.

> Since there's no configuration outside the config node (ie, in
> enable node) then this means dump every configuration command.

right.

> However, the 'debug ...' commands are special wrt to this
> guideline, and I think there are good reasons for that (see below).

well, that's what i'm wondering about :)

> > I just dont understand why the 2 sets exist, other than that enable
> > node doesnt get written out to the config file (why would you not?
> > why would you?).
>
> There is one major problem with debug command residing in config
> node only: config access is exclusive, so if your config node is
> locked somehow (somebody holds it, you're using a front-end
> configuration tool that retains exclusive access, etc) then you
> can't debug your router; since that's bad, I believe that debug
> commands were made available at the enable node as well. And, not
> dumping them during 'write file' makes a lot of sense to me, from
> the CLI structure POV (see above).

Well, i think we long ago already agreed, on the zebra list, that the
exclusive lock on config node was a good thing. why should this lock
be subverted for debug, if not for other config node commands? I
mean, if the exclusive lock is a problem, lets just get rid of it for
config node :)

my real problem though is with the enable node debug commands
manipulating seperate debug arrays, and hence not being written out.
its confusing.

i'd rather:

- accept debug is special wrt to the config lock, and provide enable
node aliases for debug commands which manipulate the regular
config_debug_ arrays (and hence get written out, hence remove the
term_debug_ arrays)

or

- clear the term_debug arrays when a vty is closed.

> Plus, I wonder, why does this duality bother you in the first
> place? I mean, what's wrong with having a configuration-originated
> 'debug' commands, and per-access 'debug' commands (those activated
> from the enable node)?

because the per access debug commands are /not/ per access - they
persist!

[root@fogarty sources.list.d]# telnet localhost ospfd
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.

Hello, this is quagga (version 0.96.3).
[snippage]
fogarty.jakma.org# sho debugging ospf
Zebra debugging status:
fogarty.jakma.org# debug ospf zebra
fogarty.jakma.org# sho debugging ospf
Zebra debugging status:
OSPF Zebra debugging is on
fogarty.jakma.org# Connection closed by foreign host.
[root@fogarty sources.list.d]# telnet localhost ospfd
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.

Hello, this is quagga (version 0.96.3).
[snip]
fogarty.jakma.org# sho debug os
Zebra debugging status:
OSPF Zebra debugging is on
fogarty.jakma.org# no debug ospf zebra
fogarty.jakma.org#
fogarty.jakma.org# Connection closed by foreign host.

See? :)

That's just does not make sense!

i think either we get rid of the term_debug_ and make enable_node
debug commands manipulate just the config_debug_ arrays, or the
enable_node term_debug_ arrays are cleared on vty close.

The latter i think will result in "i set debug, but it didnt seem to
do anything" messages (people setting debug, logging out, not seeing
any debug), so i think perhaps removing the term_debug_ arrays is
more sensible.

or not? :)

> Gilad

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Committees have become so important nowadays that subcommittees have to
be appointed to do the work.
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
Paul Jakma wrote:

> Well, i think we long ago already agreed, on the zebra list, that the
> exclusive lock on config node was a good thing. why should this lock
> be subverted for debug, if not for other config node commands? I
> mean, if the exclusive lock is a problem, lets just get rid of it for
> config node :)

Exclusive config lock is essential, no doubt. However, 'debug' commands
are essential even without config access, IMO. The question is what
semantics you provide those commands with, in particular the enable node
ones.

> my real problem though is with the enable node debug commands
> manipulating seperate debug arrays, and hence not being written out.
> its confusing.

I'm not sure it's a problem, as long as (a) the semantics is
non-ambigous and consistent wrt vty instances, and (b) it's a uniform
behavior accross quagga's various daemons. Right now, both seem to be
violated... ;->

> i'd rather:
>
> - accept debug is special wrt to the config lock, and provide enable
> node aliases for debug commands which manipulate the regular
> config_debug_ arrays (and hence get written out, hence remove the
> term_debug_ arrays)

AFAICT, this is exactly what's going on with the zebra daemon (see
zebra/debug.c) -- apparently, ospfd is the only daemon which uses
term_debug_* and conf_debug_* method. So, this option is acceptable,
then again there's the question of why would someone introduce such a
complicated mechanism to support distinct config and enable mode debug
commands, if it's all in vain?

> or
>
> - clear the term_debug arrays when a vty is closed.

No, I don't think this solves anything: even if you do that, seemingly
making the term_debug_* properties being "non-persistent", they are
still *global*, in the sense that (a) two parallel excuting vty
instances share the same term_debug_* values, hence they can affect each
other's properties, and (b) the essence of 'debug' commands is in fact
affecting the single log stream generated by the daemon -- there's no
terminal-specific dump, as it is with a Cisco terminal (IIRC). So, the
"locality" of enable node debug commands is in doubt with or without
clearing the term_debug_* values, I'd say.

So, in addition to your first proposal (which is acceptable but implies
the reversal of the debug code introduced in ospfd), I believe two other
options exist:

- allow distinct config/enable debug commands, with the former being
persistent wrt "write file" and the latter are not (IOW, the same as
it's with ospfd) -- no issues of locality are involved, everything is
global, but enable node commands are non-persistent.

- go for the per-instance term_debug_* properties: this will probably
make things clearer, and more justifiable for the purist user... ;-> But
I'm not sure it's worth the effort (dynamic allocation of the
term_debug_* struct, better definition of where the output should be
directed to, etc).

> because the per access debug commands are /not/ per access - they
> persist!

Okay, I got it ;->

Gilad
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
On Mon, 20 Oct 2003, Gilad Arnold wrote:

> commands are essential even without config access, IMO. The
> question is what semantics you provide those commands with, in
> particular the enable node ones.

yes. indeed, "what should the semantics be?" is what i'm curious
about :)

> I'm not sure it's a problem, as long as (a) the semantics is
> non-ambigous and consistent wrt vty instances, and (b) it's a
> uniform behavior accross quagga's various daemons. Right now, both
> seem to be violated... ;->

exactly.

> AFAICT, this is exactly what's going on with the zebra daemon (see
> zebra/debug.c) -- apparently, ospfd is the only daemon which uses
> term_debug_* and conf_debug_* method. So, this option is
> acceptable, then again there's the question of why would someone
> introduce such a complicated mechanism to support distinct config
> and enable mode debug commands, if it's all in vain?

yeah, i dont get it either.

> > - clear the term_debug arrays when a vty is closed.
>
> No, I don't think this solves anything: even if you do that,
> seemingly making the term_debug_* properties being
> "non-persistent", they are still *global*, in the sense that (a)
> two parallel excuting vty instances share the same term_debug_*
> values,

yep.

> hence they can affect each other's properties, and (b) the essence
> of 'debug' commands is in fact affecting the single log stream
> generated by the daemon -- there's no terminal-specific dump, as it
> is with a Cisco terminal (IIRC). So, the "locality" of enable node
> debug commands is in doubt with or without clearing the
> term_debug_* values, I'd say.

we could make the term_debug_ vty specific, then somehow see about
making 'terminal monitor' be able to only catch the vty specific
term_debug_'s. Might even be neat to specify whether to capture the
global debug output stream (conf + term debug's) or just the vty
specific stream. (dont know how feasible this is).

> So, in addition to your first proposal (which is acceptable but
> implies the reversal of the debug code introduced in ospfd), I
> believe two other options exist:
>
> - allow distinct config/enable debug commands, with the former
> being persistent wrt "write file" and the latter are not (IOW, the
> same as it's with ospfd) -- no issues of locality are involved,

yes, but enable node debug /not/ writing out is, to my mind,
confusing. On IOS these do write out, dont they? (if IOS has enable
node debug commands?)

> everything is global, but enable node commands are non-persistent.

non-persistent in what way though? you might not restart a daemon for
/yonks/, esp if its zebra or bgpd. in the meantime, you're wondering
why the hell the logs are so verbose when you cant see any debug
commands in the config.

> - go for the per-instance term_debug_* properties: this will
> probably make things clearer, and more justifiable for the purist
> user... ;-> But I'm not sure it's worth the effort (dynamic
> allocation of the term_debug_* struct, better definition of where
> the output should be directed to, etc).

or, very simple:

- rip out term_debug_, make the enable node debug commands manipulate
conf_debug_ also.

> Okay, I got it ;->

yes, i see :)

> Gilad

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
All the evidence concerning the universe has not yet been collected,
so there's still hope.
Re: fix for a bug in quagga-0.96.3's OSPF UI [ In reply to ]
I am assuming we all agree that the acceptable way to fix this problem
would be Paul's most recent proposal

- rip out term_debug_, make the enable node debug commands manipulate
conf_debug_ also.

Let me know , and I can rework the fix

Sangeeta


Paul Jakma wrote:

> On Mon, 20 Oct 2003, Gilad Arnold wrote:
>
> > commands are essential even without config access, IMO. The
> > question is what semantics you provide those commands with, in
> > particular the enable node ones.
>
> yes. indeed, "what should the semantics be?" is what i'm curious
> about :)
>
> > I'm not sure it's a problem, as long as (a) the semantics is
> > non-ambigous and consistent wrt vty instances, and (b) it's a
> > uniform behavior accross quagga's various daemons. Right now, both
> > seem to be violated... ;->
>
> exactly.
>
> > AFAICT, this is exactly what's going on with the zebra daemon (see
> > zebra/debug.c) -- apparently, ospfd is the only daemon which uses
> > term_debug_* and conf_debug_* method. So, this option is
> > acceptable, then again there's the question of why would someone
> > introduce such a complicated mechanism to support distinct config
> > and enable mode debug commands, if it's all in vain?
>
> yeah, i dont get it either.
>
> > > - clear the term_debug arrays when a vty is closed.
> >
> > No, I don't think this solves anything: even if you do that,
> > seemingly making the term_debug_* properties being
> > "non-persistent", they are still *global*, in the sense that (a)
> > two parallel excuting vty instances share the same term_debug_*
> > values,
>
> yep.
>
> > hence they can affect each other's properties, and (b) the essence
> > of 'debug' commands is in fact affecting the single log stream
> > generated by the daemon -- there's no terminal-specific dump, as it
> > is with a Cisco terminal (IIRC). So, the "locality" of enable node
> > debug commands is in doubt with or without clearing the
> > term_debug_* values, I'd say.
>
> we could make the term_debug_ vty specific, then somehow see about
> making 'terminal monitor' be able to only catch the vty specific
> term_debug_'s. Might even be neat to specify whether to capture the
> global debug output stream (conf + term debug's) or just the vty
> specific stream. (dont know how feasible this is).
>
> > So, in addition to your first proposal (which is acceptable but
> > implies the reversal of the debug code introduced in ospfd), I
> > believe two other options exist:
> >
> > - allow distinct config/enable debug commands, with the former
> > being persistent wrt "write file" and the latter are not (IOW, the
> > same as it's with ospfd) -- no issues of locality are involved,
>
> yes, but enable node debug /not/ writing out is, to my mind,
> confusing. On IOS these do write out, dont they? (if IOS has enable
> node debug commands?)
>
> > everything is global, but enable node commands are non-persistent.
>
> non-persistent in what way though? you might not restart a daemon for
> /yonks/, esp if its zebra or bgpd. in the meantime, you're wondering
> why the hell the logs are so verbose when you cant see any debug
> commands in the config.
>
> > - go for the per-instance term_debug_* properties: this will
> > probably make things clearer, and more justifiable for the purist
> > user... ;-> But I'm not sure it's worth the effort (dynamic
> > allocation of the term_debug_* struct, better definition of where
> > the output should be directed to, etc).
>
> or, very simple:
>
> - rip out term_debug_, make the enable node debug commands manipulate
> conf_debug_ also.
>