[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 23:58:59 +0100
On Fri, Nov 04, 2005 at 04:35:13PM +0100, Patrick Marc Preuss wrote:
>
> > I still think it's dangerous.
> > What if you just wanna try out a new version, you
> > find out it sucks. You switch back. But the new
> > xorp has rearranged your configuration file so now
> > the old version won't accept it.
> > Warning is enough ;)
>
> Oh, well what i meant was no to save the config automaticly,
> only the running config should be affected. and if you have as
> system like Juniper where you have up to 50 Versions it might also
> be possible to go back.
>
> Normaly you wouldn't jump from: 10.1 -> 12.4 on all routers you would check
> this with some routers nearby. Normaly you would go from 12.4.1 -> 12.4.1a
> or 12.4.3 some minor steps where such big changes normaly would not made.
>
> This is a thing how the lifecycle of the versions is.
Still, I don't see why stuff should change
automagically?
You test the new software on one system, you'll
notice ospf4 has changed name to ospf, you change
your configs and voila it works ;)
Perhaps this should be an option in that
alternative configuraion we've discussed (you know
the one with a second config file or compile time
options).
>
> >
> > > > I don't really understand what you mean with the
> > > > AAA system?
> > >
> > > aaa stands usualy for autentication, authorisation and accounting.
> > > With this you can say user a can do all things on the router, user b can
> > not
> > > or can only edit interface config or can change the state of interfaces
> > but
> > > is not allowed to edit routing processes. You can use this subsystem for
> > > Dial-In, ipsec and so on.
> > I am aware of what it is. I've setup a numerous
> > TACACS solutions ;)
> > What I don't understand is how this automagic
> > check of configuration files will affect AAA?
>
> From my point of view the same function in the code can check if the command
> is valid for the actual system and for the user who whants to do this.
Aha!
Although it is a good idea I don't beleive that
these functions would share very much code-wise.
Though I'm probably wrong ;)
Kristian