Re: (RADIATOR) SessionDatabase question
Hello Chris - On Monday 19 March 2001 13:10, Chris M wrote: > >> The only problem I forsee is, how do I make the SessionDatabase > >> high-availability? In other words, is there a way to replicate > >> the DB INSERTs and DELETEs so that auth or acct radiator > >> processes talking to MySQL can have entries simultaneously > >> made in SessionDatabases on two different machines? Since > >> MySQL doesn't have any replication features built in, how do > >> people accomplish this syncing? > > > > The simplest thing to do is just use a single SQL host, but use a > > high-availability multi-processor machine with hot-swap RAID disks. This > > is usually *much* easier to do than trying to replicate databases. > > > > hth > > > > Hugh > > I certainly agree and do this, however, there is always going to be the > need to reboot the machine. Linux and other Unices still require reboots > once a month. > I'll leave this argument to others. > I just noticed that MySQL 3.23 has some kind of replication feature in it > now, anyone used this that can give this a review? > One other approach is to use the new features in Radiator 2.18 to put a load balancing proxy(s) in front of your production Radiator hosts, and configure the proxy(s) with caching and accounting failover to a flat file. You can then have the proxies run independently for the short periods of time that your database is unavailable. regards Hugh -- 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.
Re: (RADIATOR) SessionDatabase question
Chris M wrote: > > >> The only problem I forsee is, how do I make the SessionDatabase > >> high-availability? In other words, is there a way to replicate > >> the DB INSERTs and DELETEs so that auth or acct radiator > >> processes talking to MySQL can have entries simultaneously > >> made in SessionDatabases on two different machines? Since > >> MySQL doesn't have any replication features built in, how do > >> people accomplish this syncing? > >> > > > > The simplest thing to do is just use a single SQL host, but use a > > high-availability multi-processor machine with hot-swap RAID disks. This is > > usually *much* easier to do than trying to replicate databases. > > > > hth > > > > Hugh > > I certainly agree and do this, however, there is always going to be the need > to reboot the machine. Linux and other Unices still require reboots once a > month. Ummm, why? I've got Linux systems that go a year or more without rebooting, and without trouble. Are you experiencing memory leaks in yours that're causing troubles? The ONLY reason I ever reboot my production servers is if I need to move them to a new UPS, or (rarely) to update the kernel for one reason or another. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com === 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.
Re: (RADIATOR) SessionDatabase question
>> The only problem I forsee is, how do I make the SessionDatabase >> high-availability? In other words, is there a way to replicate >> the DB INSERTs and DELETEs so that auth or acct radiator >> processes talking to MySQL can have entries simultaneously >> made in SessionDatabases on two different machines? Since >> MySQL doesn't have any replication features built in, how do >> people accomplish this syncing? >> > > The simplest thing to do is just use a single SQL host, but use a > high-availability multi-processor machine with hot-swap RAID disks. This is > usually *much* easier to do than trying to replicate databases. > > hth > > Hugh I certainly agree and do this, however, there is always going to be the need to reboot the machine. Linux and other Unices still require reboots once a month. I just noticed that MySQL 3.23 has some kind of replication feature in it now, anyone used this that can give this a review? Chris === 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.
Re: (RADIATOR) SessionDatabase Question
Mike, Thanks for the response. However, that would only work if I could specify a different SessionDatabase per AuthBy clause within the same Realm. But you can't. For example, it would work if I could do the following: AuthByPolicy ContinueUntilAccept SessionDatabase SDB1 DBSourcedbi:mysql:dom1 DBUsername username DBAuth x AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ from SUBSCRIBERS where USERNAME='%n' SessionDatabase SDB2 DBSourcedbi:mysql:dom2 DBUsername username DBAuth xx AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ from SUBSCRIBERS where USERNAME='%n' But if I try this it errors out saying Unknown keyword 'SessionDatabase'. If I move the session database above the AuthBy statement then it works. Regards, Kevin Fowler <[EMAIL PROTECTED]> System Administrator Raex Internet On Wed, 3 Nov 1999, Mike McCauley wrote: > Hi Kevin, > > The default behaviour for the session databases is to log the _original_ > username prior to any RewriteUsername > > In that case of SQL SessionDatabase, it is easy to alter the configuration so > it uses whatever you want as the username. You would probably want to change > AddQuery and CountQuery. The default uses %u to get the original unrewritten > username. You caould chabge this as you see fit. > > Hope that helps. > Cheers. > > > > On Nov 2, 1:49pm, Kevin Fowler wrote: > > Subject: (RADIATOR) SessionDatabase Question > > Hello, > > We have multiple groups of customers authenticating out of multiple > > databases with some of the usernames being the same. They need to be > > able to authenticate with realms and without realms. The problem is with > > the SessionDatabase. All of the following example username and password > > pairs need to work correctly from the same radius server: > > > > [EMAIL PROTECTED] > > password1 > > > > user1 > > password1 > > > > [EMAIL PROTECTED] > > password2 > > > > user1 > > password2 > > > >I accomplished this by setting up a realm for dom1.com and > > dom2.com. They each use a different database of users. If no realm is > > specified then I have two AuthBy clauses to attempt to authenticate off of > > each of the two databases. The AuthByPolicy is set to > > ContinueUntilAccept. So the same username could log on with different > > passwords depending on what database they are in. > >The authentication works great the problem is with the > > SessionDatabase. If they authenticated with the dom1.com realm then it > > sends [EMAIL PROTECTED] to the RADONLINE table. If they authenticate without > > a realm then it just send user1 to the table. This stops the other user1 > > from being able to log on. What I would prefer is a way to append > > @dom1.com to the username if they are in the first database and @dom2.com > > to the username if they are in the second database. We tried the > > RewriteUsername method but it will not work because you can't rewrite the > > username within each AuthBy clause. We also tried having different > > SessionDatabases but again you can't specify a different SessionDatabase > > per AuthBy clause only per Realm. > >Let me know if anyone has an idea of a better way to do this or if > > anyone had a solution to the way I am trying to do it. Thanks in advance > > for any help. At the bottom I have included an example of my config file. > > > > Regards, > > Kevin Fowler <[EMAIL PROTECTED]> > > System Administrator > > Raex Internet > > > > --- sample radus.cfg file --- > > > > > > AuthByPolicy ContinueUntilAccept > > SessionDatabase SDB1 > > > > > > DBSourcedbi:mysql:dom1 > > DBUsername username > > DBAuth x > > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > > from SUBSCRIBERS where USERNAME='%n' > > > > > > > > DBSourcedbi:mysql:dom2 > > DBUsername username > > DBAuth xx > > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > > from SUBSCRIBERS where USERNAME='%n' > > > > > > > > > > AuthByPolicy ContinueUntilAccept > > SessionDatabase SDB1 > > RewriteUsername s/^([^@]+).*/$1/ > > > > DBSourcedbi:mysql:dom1 > > DBUsername username > > DBAuth xxx > > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > > from SUBSCRIBERS where USERNAME='%n' > > > > > > > > > > AuthByPolicy ContinueUntilAccept > > SessionDatabase SDB1 > > RewriteUsername s/^([^@]+).*/$1/ > > > > DBSourcedbi:mysql:dom2 > > DBUsername username > > DBAuth x > > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > > from SUBSCRIBERS where USERNAME='%n' > > > > > > > > > > D
Re: (RADIATOR) SessionDatabase Question
Hello Kevin - On Wed, 03 Nov 1999, Kevin Fowler wrote: > Hello, > We have multiple groups of customers authenticating out of multiple > databases with some of the usernames being the same. They need to be > able to authenticate with realms and without realms. The problem is with > the SessionDatabase. All of the following example username and password > pairs need to work correctly from the same radius server: > > [EMAIL PROTECTED] > password1 > > user1 > password1 > > [EMAIL PROTECTED] > password2 > > user1 > password2 > >I accomplished this by setting up a realm for dom1.com and > dom2.com. They each use a different database of users. If no realm is > specified then I have two AuthBy clauses to attempt to authenticate off of > each of the two databases. The AuthByPolicy is set to > ContinueUntilAccept. So the same username could log on with different > passwords depending on what database they are in. >The authentication works great the problem is with the > SessionDatabase. If they authenticated with the dom1.com realm then it > sends [EMAIL PROTECTED] to the RADONLINE table. If they authenticate without > a realm then it just send user1 to the table. This stops the other user1 > from being able to log on. What I would prefer is a way to append > @dom1.com to the username if they are in the first database and @dom2.com > to the username if they are in the second database. We tried the > RewriteUsername method but it will not work because you can't rewrite the > username within each AuthBy clause. We also tried having different > SessionDatabases but again you can't specify a different SessionDatabase > per AuthBy clause only per Realm. >Let me know if anyone has an idea of a better way to do this or if > anyone had a solution to the way I am trying to do it. Thanks in advance > for any help. At the bottom I have included an example of my config file. > The two solutions that I can see are: 1. If you can identify the user by the NAS they dial in to, you can set a DefaultRealm: # This Client is used by dom1 users DefaultRealm dom1.com ... # This Client is used by dom2 users DefaultRealm dom2.com ... 2. Set up a PreClientHook to rewite the username prior to it being inserted in the SessionDatabase. In both cases, you would then only need the two specific Realm clauses. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SessionDatabase Question
Hi Kevin, The default behaviour for the session databases is to log the _original_ username prior to any RewriteUsername In that case of SQL SessionDatabase, it is easy to alter the configuration so it uses whatever you want as the username. You would probably want to change AddQuery and CountQuery. The default uses %u to get the original unrewritten username. You caould chabge this as you see fit. Hope that helps. Cheers. On Nov 2, 1:49pm, Kevin Fowler wrote: > Subject: (RADIATOR) SessionDatabase Question > Hello, > We have multiple groups of customers authenticating out of multiple > databases with some of the usernames being the same. They need to be > able to authenticate with realms and without realms. The problem is with > the SessionDatabase. All of the following example username and password > pairs need to work correctly from the same radius server: > > [EMAIL PROTECTED] > password1 > > user1 > password1 > > [EMAIL PROTECTED] > password2 > > user1 > password2 > >I accomplished this by setting up a realm for dom1.com and > dom2.com. They each use a different database of users. If no realm is > specified then I have two AuthBy clauses to attempt to authenticate off of > each of the two databases. The AuthByPolicy is set to > ContinueUntilAccept. So the same username could log on with different > passwords depending on what database they are in. >The authentication works great the problem is with the > SessionDatabase. If they authenticated with the dom1.com realm then it > sends [EMAIL PROTECTED] to the RADONLINE table. If they authenticate without > a realm then it just send user1 to the table. This stops the other user1 > from being able to log on. What I would prefer is a way to append > @dom1.com to the username if they are in the first database and @dom2.com > to the username if they are in the second database. We tried the > RewriteUsername method but it will not work because you can't rewrite the > username within each AuthBy clause. We also tried having different > SessionDatabases but again you can't specify a different SessionDatabase > per AuthBy clause only per Realm. >Let me know if anyone has an idea of a better way to do this or if > anyone had a solution to the way I am trying to do it. Thanks in advance > for any help. At the bottom I have included an example of my config file. > > Regards, > Kevin Fowler <[EMAIL PROTECTED]> > System Administrator > Raex Internet > > --- sample radus.cfg file --- > > > AuthByPolicy ContinueUntilAccept > SessionDatabase SDB1 > > > DBSourcedbi:mysql:dom1 > DBUsername username > DBAuth x > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > from SUBSCRIBERS where USERNAME='%n' > > > > DBSourcedbi:mysql:dom2 > DBUsername username > DBAuth xx > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > from SUBSCRIBERS where USERNAME='%n' > > > > > AuthByPolicy ContinueUntilAccept > SessionDatabase SDB1 > RewriteUsername s/^([^@]+).*/$1/ > > DBSourcedbi:mysql:dom1 > DBUsername username > DBAuth xxx > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > from SUBSCRIBERS where USERNAME='%n' > > > > > AuthByPolicy ContinueUntilAccept > SessionDatabase SDB1 > RewriteUsername s/^([^@]+).*/$1/ > > DBSourcedbi:mysql:dom2 > DBUsername username > DBAuth x > AuthSelect select PASSWORD, CHECKATTR, REPLYATTR \ > from SUBSCRIBERS where USERNAME='%n' > > > > > DBSourcedbi:mysql:sessiondb:machine > DBUsername username > DBAuth > Identifier SDB1 > > > > > > === > Archive at http://www.thesite.com.au/~radiator/ > To unsubscribe, email '[EMAIL PROTECTED]' with > 'unsubscribe radiator' in the body of the message. >-- End of excerpt from Kevin Fowler -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
