Hello Mariano -
My general approach in creating configuration files is to do as much as
possible in one single file using GlobalVar's that are set at run time on the
command line to create different instances.
As regards something like AuthLog FILE, as it will never be called in an
accounting-only instance, it will not cause any performance problems at all.
regards
Hugh
On Tuesday 08 May 2001 06:44, Mariano Absatz wrote:
> El 3 May 2001, a las 11:07, Hugh Irvine escribi�:
> > Hello Mariano -
> >
> > On Thursday 03 May 2001 06:15, Mariano Absatz wrote:
> > > Hi... on my delayed reading of the list I found this:
> > >
> > > El 18 Apr 2001, a las 9:45, Hugh Irvine escribi�:
> > > > Hello Andy -
> > > >
> > > > The session database will be accessed by both authentication (to
> > > > delete and to check limits) and accounting (to insert and delete).
> > >
> > > <SNIP>
> > >
> > > So... I have different instances of Radiator for accounting and
> > > authentication, then BOTH have to have the <SessionDatabase> clause?
> > > And should they be identical?
> >
> > Yes. This is the same situation as having multiple machines running
> > Radiator - they all need to share the same session database (if coherency
> > among them is an issue).
> >
> > > On re-reading the "Performance and Tunning" section in the manual
> > > (http://www.open.com.au/radiator/ref.html#pgfId=406539), I find a good
> > > list of hints, but most of them are sometimes not very usefull when you
> > > DO have to do some strange things... anyway, since I saw it many times
> > > in the list, the separation between an Authentication server and an
> > > Accounting server in different instances even when it is in the same
> > > machine, seems to be a no-lose proposition, since you are losing no
> > > functionality at all (I think) and you don't have to buy extra hardware
> > > (it's easy to say "see, boss, I need 4 or 5 more Sun Netras T1 to
> > > improve radius speed" only to hear him say "gee, why don't you do it
> > > with that Sparc I that no one is using now?").
> > >
> > > Since I see this so often said in the list, it might get a subsection
> > > with some configuration tips for this, like, "you have to put this kind
> > > of sections on the auth config, those sections in the acct config and
> > > this bunch in both... maybe you should use "Include common.cfg" for
> > > these last ones...
> > >
> > > Put it in the wishlist for the next release (2.18.2? 2.19? please don't
> > > do anything like naming it "Radiator 20" -� la Solaris- or "Radiator
> > > 2001" or "Radiator NE (Nonsense Edition)" -� la MS- :-)
> >
> > I have been thinking about adding some more complex configuration files
> > to the goodies section and I can see that the manual could contain some
> > more detail. Thanks for the suggestion.
>
> On a general way, I would like to be as "clean" as possible when writing
> my config files and repeat as little as possible.
>
> I am writing 3 config files:
>
> 1)radius-auth.cfg
> 2)radius-acct.cfg
> 3)radius-common.cfg
>
> first thing 1) & 2) do is include 3), which has the common configuration.
>
> 1) & 2) obviously have the corresponding authport & acctport, and
> SNMPAgent in different ports.
>
> >From a maintainance point of view, I woul like to have as much as
>
> possible in 3), from what you say in your message, for instance
> <SessionDatabase> must be there.
>
> Now, if I put EVERYTHING except authport, acctport and SNMPAgent in 3),
> will that have a performance penalty?
>
> Obviously, it will be slower at startup, but that is not an issue, since,
> once it's working, I don't expect to shut it down except for programmed
> upgrades or the like...
>
> Otherwise, is there a rule of thumb as to what goes where? I could start
> putting everything in 3) and then migrating to the obvious choice where
> there is one and see how I'm doing, but I think that will take a lot of
> trial and error...
>
> For instance <AuthLog FILE> could go only in 1) (I think), but would it
> be "bad" if I put it in 3)?
>
> TIA
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
