[Xorp-hackers] AW: [Xorp-users] Does xorp latest CVS have some problem with the export command?
Kristian Larsson
kristian@juniks.net
Fri, 4 Nov 2005 11:41:54 +0100
On Fri, Nov 04, 2005 at 10:45:46AM +0100, Patrick Preuss wrote:
>
>
>
> > We have already support for notifying the user if some configuration
> > statement is obsoleted: the "%deprecated" keyword in the
> > configuration template files. E.g., add "enabled: true"
> > config statement to an interface and try to start with or load that config
> > file. The rtrmgr will refuse and will print a predefined error
> > message.
> If something similar to this happens during startup, eg. Read the config
> parts and mark them as obsolete / error, the line in the show config could
> look like: "E> enable: true"
I'm not sure if I understand you correctly, but I
think I do and it's a great idea ;)
When xorp reads a line it doesn't know what to do
with (ie corrupt line, old configuration statement
...) it comments the line and marks it with error:
E> or whatever is suitable.
> > Unfortunately this mechanism has its limitations. E.g., it can tell
> > you if a node in the configuration tree has been deprecated, but it
> > cannot tell you if the syntax of a node has been changed (as it
> > seems to be the case with the old/new policy for RIP).
>
> In this case the config file should contain something like the "version
> 12.4" line on the cisco's so you could determine witch parts are differ
> Between versions. So it will be possible to show parts witch have been
> obsolete, changed and so on.
My patch to BugZilla 53 includes this :)
>
> > We don't have yet a functionality to rewrite old configs into new
> > ones, because we are still in the process of tweaking various
> > things, and such tool will quickly become obsolete (or an additional
> > burden to maintain and keep it up to date).
>
> I think not to rewrite the config in all parts, may the rip is such a thing
> where it goes or not, have not thought about it yet, but for example:
> If the config changes from:
>
> Protocols {
> Ospf4 {
> ....
> }
> }
>
> To
>
> Protocols {
> Ospf {
> .... keeps the same
> }
> }
>
> The next time you write the config there will be the new version.
>
> You can add a mechanism for such rules, something like check config url, it
> will have the side effect for an "aaa" subsystem, you can control the access
> to statements for a user, group, like the Juniper does. I know this will be
> A lot of work ;-)
>
> But for Production env. Where you might not have full access it would be a
> good idea.
I think it's both difficult and dangerous to have
XORP change stuff automatically for you, it would
be better to just warn and let the user decide on
action.
I don't really understand what you mean with the
AAA system?
Kristian
>
>
>
> _______________________________________________
> Xorp-hackers mailing list
> Xorp-hackers@icir.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers