Re: (RADIATOR) Radiator + Oracle Bug?
Hugh Irvine wrote: > > Hello Wesley - > > If the SQL database access times out, Radiator by default will wait 10 > minutes before trying again. > > You can adjust the Timeout and FailureBackoffTime parameters in the > AuthBy SQL clause. > > See sections 6.28.4 and 6.28.5 in the Radiator 3.6 reference manual. > > regards > > Hugh > > > On Sunday, Jul 20, 2003, at 19:11 Australia/Melbourne, Wesley Hof wrote: This shouldn't stop/freeze the perl process though? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Database support fault tolerance
Hugh Irvine wrote: > > Hello Dan - > > It would be fairly simple to have Radiator write to a flat file for > accounting, and then have a cron job or similar load the data into the > database periodically. You will find a simple utility to do this in the > file "goodies/radimportacct". > > regards > > Hugh A cron job is too dirty of a hack, some other trigger would be better. What to do about sessions though? They need to find a way to the database too, unless someone has some specialized (network) session service written (which I would love to use instead of an SQL DB anyway). === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Fwd: Re: (RADIATOR) Database support fault tolerance
Hugh Irvine wrote: > > Hello Dan - > > It would be fairly simple to have Radiator write to a flat file for > accounting, and then have a cron job or similar load the data into the > database periodically. You will find a simple utility to do this in the > file "goodies/radimportacct". I was hoping more for something like this included in Radiator's design. Would benefit many, really. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Database support fault tolerance
Our users are getting sick and tired due to RADIUS service unavailability every time something happens to the network where the database server sits, or the database server itself. To remind, we use LDAP for authentication, and SQL Server for sessions/logging. LDAP has been great, where database connectivity has been problematic, and a major pain in the arse in general. In some cases, Radiator would hang if there are database connection failures. A failure with the unixODBC client translates into Radiator process failure. Right now Radiator's availability is directly dependent on the quality of the Perl libraries, including the database libraries/clients. Our service could be much more available if SQL was handled by an outside process with a queue in the middle. If something happens to this SQL helper process, the network, or the database server, then the queue simply grows in size, and Radiator continues running happily, authenticating users. When the problems are fixed, the queue is relayed to the SQL server, and no logging records are lost. If we want to be fancy, this extra process may even be temporarily handling sessions in place of RADONLINE (instead of simply ignoring them returning OK back to Radiator), and notifying system administrators when it can't talk to the SQL database. This system is not only a more resilient design, but more scalable too since Radiator will return as soon as it writes to the queue, not waiting for the database server. Please let me know your thoughts; let's discuss this idea further. Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Two miniscule timestamp patches
I need to log to stdout without the timestamp (because I use multilog
for automatic rotation and TAI timestamps), so here is NoTimestamp. Hope
it's okay to send to the mailing list, and it's useful to someone.
--- Log.pm Wed May 22 22:03:18 2002
+++ /usr/local/lib/perl5/site_perl/5.8.0/Radius/Log.pm Thu Feb 13 18:10:12 2003
@@ -52,8 +52,13 @@
my ($priority, $s, $p) = @_;
# Print to stdout as well, if required
-print scalar localtime(time) . ': '
- . $Radius::Log::priorityToString[$priority] . ': ' . $s . "\n"
+if (!$main::config->{NoTimestamp})
+{
+ print scalar localtime(time) . ': ' ;
+
+}
+
+ print $Radius::Log::priorityToString[$priority] . ': ' . $s . "\n"
if $main::config->{LogStdout}
&& ($priority <= $main::config->{Trace}
|| ($p && $p->{PacketTrace}));
--- ServerConfig.pm Fri Nov 29 01:10:02 2002
+++ /usr/local/lib/perl5/site_perl/5.8.0/Radius/ServerConfig.pm Thu Feb 13 18:03:05
+2003
@@ -22,6 +22,7 @@
'DictionaryFile' => 'string',
'PidFile'=> 'string',
'LogStdout' => 'flag',
+ 'NoTimestamp'=> 'flag',
'SnmpgetProg'=> 'string',
'SnmpsetProg'=> 'string',
'SnmpwalkProg' => 'string',
Re: (RADIATOR) Concurrent access in SessDBM.
Hugh Irvine wrote: > > Hello Dan - > > DBM locking is not supported and we find that most Radiator users have > an SQL database for billing and customer management already, so an SQL > session database (which supports locking, multiple access, etc.) tends > to make more sense. Hi Hugh. We use LDAP for customer management (much better). Also RDBMS is not a requirement for either sessions, or accounting. We are using RDBMS for accounting records, but the _only_ reason why we're using RDBMS for sessions is lack of concurrent access in SessDBM. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Concurrent access in SessDBM.
Would it be feasable to add locking to SessDBM such that we have multiple readers and one writer to the DBM file? The session database doesn't need any relational features, and the related bloat and bugs. Look at what it takes just to set up a reliable database connection. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Rodopi & Radiator
Tim Jung wrote: > I am still stuck if anyone has any suggestions. First, you need to be asking these questions on the FreeTDS mailing list. Other than that, I would compile sqsh against the FreeTDS library, and use sqsh to log in with the SQL Server account and database to verify access. You can also log error messages with SQL Server itself, and then view them with NT event viewer. Make sure the FreeTDS library is not compiled with pthread support. Another option may be compiling DBD:Sybase against Sybase's OpenClient libarries. May cost money. So far my experience with database connectivity from Perl on Unix to Windows has been very bad. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) FreeTDS & DBD-Sybase Install
Tim Jung wrote: > I found this out from the author of the DBD::Sybase module. He posted this > to the FreeTDS mailing list back in October 2002. He is specifically > talking about the errors that are generated when you run the 'make test' > option on the DBD::Sybase module using FreeTDS. > > So it would look like that until more work is done on FreeTDS that it > doesn't support 100% of everything that MS-SQL is capable of doing. Thus Exactly. However, everything Radiator needs by default is supported. The reason why we dropped FreeTDS is because it didn't know how to handle broken connections, and hung perl. We still use FreeTDS with PHP. It's quirky, but we got it to work for what we need it to do. > the DBD::Sybase won't pass all the 'make test' tests using FreeTDS v0.60 or > the CVS version v0.61 as of today. I guess it is possible that the release > version of v0.61 might up the level of support though. Although it would > seem than 85%-86% support isn't too bad for an Open Source package talking > to a commercial closed source database. :) Knowing that they don't have specs and need to reverse engineer, it's an achievement, however they had problems such as memory leaks and buffer overflows/segfaults in FreeTDS, which suggests they put features first, and stability/quality second. Not good. > So the question that remains is which version of the TDS protocol is needed > to talk with MS-SQL 7.0 SP3 so Radiator can talk to the Rodopi databases? > Should I use the 4.2 protocol or the 7.0 protocol? Specifically I am > interested in using the "Auth Rodopi" stuff in Radiator. Anyone here know > for sure? If you read their documentation you'd know it's TDS 7.0. Have fun. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Different NASes, same realms
Hugh Irvine wrote: > > Hello Dan - > > The best way to do this sort of thing is like this: > > # define Client clauses > > > Identifier Ascend-Type-A > . > > > AuthBy Auth-Ascend-Type-A > .. > Ouch, I missed client identifiers in the documentation. Are there any plans to reorganize documentation into multiple HTML pages? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Different NASes, same realms
We are getting into compatibility problems with different Ascend NASes from our providers, which requires us to run different AuthBy for each. Since we use them with the same realms, what is the best way to differentiate NASes? Rewrite realms to something weird like realm.com-provider in the s? Any other way? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator stops ...
> > Hmm ... I guess the answer is YMMV, then. > > To anyone looking for solutions like this, I would say that Easysoft were > very helpful getting their stuff up and running, and your best bet is > probably to try both. It was certainly better than Openlink, and I believe > their pricing is more competitive as well. > > But I'll stick with FreeTDS myself, thanks. Their support is very good indeed. There was a bug in UnixODBC dropped connection handling, which was fixed right after I reported it. My gripe is it takes so much bloat just to access databases. ODBC manager, ODBC driver, perl ODBC modules. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator stops ...
Matthew Trout wrote: > > Of course Easysoft OOB is even better as far as > > compatibility/reliability are concerned, albeit at a higher cost. > > You're kidding, right? > > In production use, Easysoft is absolutely lovely bar for one minor 'feature' > (at least in the version I had) - if the NT side of the Easysoft bridge hits > the full number of permitted threads it then refuses to accept any further > connections without a stop/start on the service. I got bored of trying to We didn't have problems you had with it. In fact we switched from FreeTDS to OOB becasue FreeTDS was too flaky for us. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator stops ...
Matthew Trout wrote: > I'd suggest dumping openlink as well; it's overpriced and the windows side > (last time I had to suffer it) was far from production-grade reliability. If > you're trying to connect to an MS SQL Server from *n?x, I've found FreeTDS > (www.freetds.org) to be far superior, and a lot faster since TDS has a lot > less overhead than ODBC. DBD::Sybase will build quite happily against > FreeTDS, at which point you could use it with Radiator quite happily. Of course Easysoft OOB is even better as far as compatibility/reliability are concerned, albeit at a higher cost. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) GlobalVar
I am tidying up my configuration files, and I find that GlobalVars don't work everywhere. I look at the documentation, and it doesn't tell me where they do not work. Variables like LDAP passwords and filters that I found by trial and error do not work. LDAP host does work, but then, in the log file the variable name is reported instead of the variable value. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Auth-Type and LDAP
Enrique Diez wrote: > Hi All, > I would like to know if there is an LDAP-Attribute (customized or > standarized) in order to define the kind of authentication required for an > user entry. > For example, a user LDAP entry can be validated by the Radiator Radius > Server via /etc/unix/password or a remote radius or ACE/SERVER according to > the value of an "Auth-type" LDAP attribute. We use objectClass. If a user's LDAP entry allows dial-up authentication, then his objectclass attribute will include 'dialUpUser' value. The Radiator LDAP filters are set accordingly. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Connecting from linux to SQL 2000
Matthew Hobbs wrote: > Currently I'm using DBI:Sybase on Mandrake 8.2 to connect to MS SQL 6.5 > All works well > Looking at FreeTDS (0.6) its says it can connect to SQL 2000 using DBI::Sybase > is this true ? This is a question for the FreeTDS list. I just tried FreeTDS 0.53, with TDS version set to 7.0 with MS SQL 2000. Seems to work. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) MySQL + Radiator = Hang
Tony Bunce wrote: > We have radiator setup on two servers using a MS SQL server for user > authentication and mysql for accounting. If you're using unixODBC 2.2.3 or earlier, upgrade. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Re: (RADAR) RADAR without X
> StatsLog clause. And if you want a tool to restart Radiator > automatically and let you know why it did so, you should use the > "restartWrapper" utility provided in the goodies directory for this > purpose. See the relevant sections of the Radiator 3.4 reference manual. Another (very convenient) way to automatically restart Radiator is to use daemontools. One more way is on systems which init supports it, specify radiusd should be started on boot and restarted on exit in /etc/inittab. Autorestart is important especially if you use ODBC since perl process likes to segfault with some ODBC drivers (especially when an idle connection is dropped by the ODBC server or a firewall). This leads me to ask this question. Could any subscribed users comment on Easysoft's OOB? We went from FreeTDS to OOB, and perl still segfaults on dropped connections from the OOB server. Dropped connections should result in graceful reconnects, not given up on with a segfault (note this is not a Radiator issue, the DBD-ODBC, DBI, unixODBC, and OOB driver are suspects here. But where to start looking for the bug?). === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Sessions
Hi. Our Radiator needs to authenticate more that one service from the same realm. We need to guarantee that a user can get one session per each service with the same account, but only one session. For example, once a user has authenticated for dial-up, he wants to use a VPN client - one more session, but for a different service. The trick is a user must not be allowed to get more than one session for either service. What needs to be done? A separate session DB for each handler? Anything else? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Mac OS X Questions
Marcel Brown wrote: > A few more questions regarding Mac OS X and MS SQL access > > If connecting to MS SQL from ODBC on UNIX requires an ODBC driver, > where can I get a driver? Do people here have experience with this on > Mac OS X? > > I keep reading that DBD-Sybase is compatible with MS-SQL. If I were > to use DBD-Sybase instead of DBD-ODBC, do I still need an additional > driver? Anyone here have experience using DBD-Sybase for MS SQL with > any UNIX, not just Mac OS X? > > Thanks! > Marcel > Try FreeTDS first. We had more success with ODBC-ODBC bridge. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator stop without a reason
Paulo Sousa wrote: > > Dan > > I'm currently use libdbd-sybase-perl (that depends freetds), running > debian GNU/Linux woody 3.0 :) > Do u know how i can resolve that??? Not yet. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Patrick Muldoon(NOC) wrote: > We use DBD::Sybase with FreeTDS to connect to MSSQL Server 2000 from > FreeBSD, and it works great, have never had any trouble. > > What version of FreeTDS are you using? > > You can also do some debugging with FreeTDS to see if it is the one > hanging. > http://www.freetds.org/userguide/x1873.htm#AEN1877 > > Hope this helps, > > -Patrick I am happy for you. We are using MSSQL 7.0, with service pack 2. We also use FreeTDS with PHP, and had some minor problems, but nothing major. There are/were many really screwy problems with FreeTDS like memory leaks and segfaults, and part of the problem is the reverse engineering, but it's a good suspect. We're always using the latest version of FreeTDS, and AFAIK it's been 0.53 for quite a while. This server hang problem is very irritating, and ambiguity of it really sucks. Where to look? DBD:Sybase? FreeTDS? MSSQL? So many layers. Does anyone on this list use MSSQL with Sybase client libraries by any chance? UnixODBC or iODBC with a commercial ODBC driver? What are your results? I've used Sybase client libraries with MSSQL 6.5 in the past with good results. Had more problems with 7.0. BTW, FreeTDS have a very early version of an ODBC driver. They're willing to finish it if you sponsor them. If FreeTDS makes you a profit, may as well support the developers :) === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Mike McCauley wrote: > Hi Dan, > > OK, > > here is a new version of SqlDb.pm that implements a new DisconnectAfterQuery > flag. This will cause AuthBy SQL and other SQL users to disconnect after > every SQL 'do' and after every 'getOneRow'. > > Let me know how you go. > > Cheers. > Thanks for all your effort, Mike. The problem didn't go away, however. I am suspecting a FreeTDS problem now. Server just hangs. 'top' shows it's in 'sbwait' state. 'netstat' shows an open connection to the MS SQL machine. Paulo Souso's Radiator also hangs, by the way. They use MS SQL too. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator stop without a reason
Paulo Sousa wrote: > > > Hi Dan > > I'm using a linux box that auths on M$ SQL Server. :) > > Paulo Sousa > We have exactly the same problem. You are using FreeTDS? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator stop without a reason
Hugh Irvine wrote: > > Hello Paul - > > I will need to know what hardware/sorftware platform you are using and I > will need to see a copy of your configuration file (no secrets) together > with a trace 4 debug showing what is happening. I will also need to know > what version of Radiator you are running. > > regards > > Hugh > > > On Thursday, September 5, 2002, at 03:36 AM, Paulo Sousa wrote: > Are you using MSSQL by any chance? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Mike McCauley wrote:
> On Wed, 28 Aug 2002 08:32, Hugh Irvine wrote:
> > Hello Dan -
> >
> > I would have to suggest that you use a more sensible database.
>
> Of course that there might be other reasons that prevent you from doing that.
>
> I am a bit puzzled though: I would normally expect Radiator to attempt to
> reconnect and have another go after failing to execute that query the first
> time?
>
> Perhaps if you send more the the trace file we might see if that is happening?
>
> Cheers.
>
Here's what happens:
1) If the server has been writing to MSSQL server frequently, no problems.
2) If the server has not written anything over TCP connection to MSSQL
in quite a long while, the server is blocked. Any subsequent
requests to the server fail. This is the last thing in the log before a
block:
Wed Aug 28 18:58:52 2002 707093: DEBUG: do query is: insert into
failedattempts
(LoggedAt,User_Name,NAS_IP_Address,Caller_ID,NAS_Port,Failure_Message,
Active_Handler) values ('2002-08-28
18:58:52.000','dan','203.63.154.1','987654321','1234','''Bad
Password''', 'prodnetilla') .
I suspect a problem may be with FreeTDS libraries, DBD::Sybase, or MSSQL
server itself. Unfortunately I can't use a different database for
logging for beauraucratical reasons.
A connect-log-disconnect feature would be a quick fix for this. It would
also allow some people simple load balancing with round-robin DNS to
boot.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Mike McCauley wrote:
> Its a first for me too.
> I could conceive of a 'DisconnectAfterQuery' flag that would disconnect after
> every SQL query was finished, but Im reluctant to add it since I dont think
> it would be widely useful, and when it was used it would significantly slow
> things down.
Performance is not an issue for us right now, since we barely get a few
dozen authentications per day.
> Do I understand from the below that you are connecting to MS-SQL from Radiator
> running on a FreeBSD box?
>
> We havent heard of similar behaviour, even from FreeBSD to MS-SQL. It is
> possible that using keep-alives or similar might alleviate the problem?
>
> Cheers.
The problem is our MS SQL Server 7.0 (yuck!), service pack 2 drops connections if
they're idle for a long enough time:
Tue Aug 13 09:39:24 2002: ERR: do failed for 'insert into failedattempts
(LoggedAt,User_Name,NAS_IP_Address,Caller_ID,NAS_Port,Failure_Message,
Active_Handler) values ('2002-08-13 09:39:24.000','soconnell','10.0.2.201','',
'29374','''Bad Password''','prodnetilla')': Server message number=10018 severity=9
state=0 line=0
server=OpenClient text=The connection was closed
I am just looking for a a quick work-around. MS' site actually has a blurb about
configuring time-outs
for DB connections, but we couldn't find such an option at least for our
service pack.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) SQL Server Connection Handling
Hugh Irvine wrote: > > Hello Dan - > > Can you please tell me what database you are using and what platform? > > thanks > > Hugh I thought SQL Server implied MS SQL Server :). This is FreeBSD. Anyway, we need connect-log-disconnect behavior instead of the current implementation. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) SQL Server Connection Handling
Hi. Is it possible to quickly disable persistent connections for SQL logging? Persistent connections do not work well with our SQL Server, since they time out. Short failure backoff times do not help either since I think any DB connection failure trips the RADIUS authentication code on the devices we authenticate (they stop talking to Radiator). === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Memory leak in one of the modules or perl executable.
Hugh Irvine writes: > > Hello Dan - > > Mike is travelling this week, but he will look at this when he returns. > > In the meantime, can you please tell me how you are testing? And could you > also send me the details of how you are testing and the outputs of "ps", > "top" or whatever you are using to measure the memory usage? Also please > include anything else that might be useful in tracing the problem. > > thanks and regards > > Hugh I am running radpwtst on the same machine recursively with a simple bash script, which does a correct query. Radiator authenticates using AuthBy TEST. Until I stop it. This is before the script is run: ps auxw | egrep 'CPU|radiusd' USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND radiusd 2202 0.1 0.6 8156 7760 p0 S+6:34PM 0:01.08 /usr/local/bin/perl /usr/local/bin/radiusd -config_file ./test.cfg And after the script is finished (a few hundred querys): radiusd 2202 0.7 0.7 10196 9756 p0 S+6:34PM 0:07.74 /usr/local/bin/perl /usr/local/bin/radiusd -config_file ./test.cf Note the difference in size and resident set size values. If the server and client are left to run longer, it will be so large that it will need to be restarted. I can do this automatically with daemontools, but it is not a fix. This is not due a to a module load, since even on the first query, the process does not jump megabytes in size. Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Memory leak in one of the modules or perl executable.
I noticed the perl process is growing linearly as the requests come in. Grows in size quite rapidly, eventually needs to be restarted. I suspected FreeTDS or OpenLDAP libraries (and these may too have leaks and probably do, but that testing is later). To see if it could be something else, I created a simple config file with just AuthByTEST. Still leaks. This is on FreeBSD 4.5-STABLE and Perl 5.6.1. Perl 5.8.0 also leaks when running Radiator. Time::Hires is also installed. No other modules were used for this test. Here's my config (with fake system-related data): LogStdout PidFile /tmp/testradiusd.pid AuthPort1898 AcctPort1899 BindAddress ip.add.re.ss LogDir /tmp DbDir /tmp DictionaryFile /blah/blah/dictionary NoIgnoreDuplicates Access-Request #for testing only Secret test RewriteUsername s/^(.*)\-(.*)/$1\@$2/ #user-org to user@org DefaultRealm test Identifier test Identifier test AuthBy test === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) LDAP and CHAP
Ayotunde Itayemi writes: > Hi, > > Depending on your patience, number of clients and time, you could get Mobius > Freeware's > w32crack - run it continuously for a few days after extracting the username > and encrypted This cannot help us, since we do not use NT user database. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) LDAP and CHAP
Hugh Irvine writes: > > Hello Dan - > > You can use CHAP with any database, however the password stored therein > *must* be in cleartext, as you can only use cleartext passwords with CHAP. > > regards > > Hugh The problem is all our dial-ups have hashed passwords, and returning them to clear text would be impossible. The problem is Broadwing now requires CHAP for some of the POPs, and doesn't for others. Are there any work-arounds for this? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) LDAP and CHAP
Does Radiator allow CHAP passwords with LDAP databases? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Our Interesting Requirement for Radiator
Hi. Here's what required by our installation. We have our account entries in the LDAP directory. Every account can be authenticated using RADIUS for several services like VPN tunnels, dial-up etc. There needs to be an expirattion date for each type of service. IOW there's a different expiration date attribute for each RADIUS-authenticated service. From what I've read in the docs, Radiator only supports one expiration attribute per directory entry natively. We need an ability to configure a separate expiration date attribute for each sevice an LDAP entry could authenticate. Is there any way we can achieve what I've described above? Thanks much. -- Excessive functionality is a root to security disasters. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Logging Active Handler
Hi. I need to log active handler identifier to the SQL table. In other words, the handler where the failure occurs should be logged. What do I need to do? I read documentation, but it's not exactly clear to me as how to do it. -- History has shown that the road to injustice is frequently lit with the light of good intention === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Failed Attempts, Time::HiRes
Hi. A few questions: How to log failed attempts to an SQL database? The table will look something like this: Column_nameType Length Nullable -- - --- --- LoggedAt datetime 8yes User_Name varchar 255 yes NAS_IP_Address varchar 255 yes Authen_Failure_Reason varchar 255 yes Author_Failure_Reason varchar 255 yes Caller_ID varchar 255 yes NAS_Port varchar 255 yes Source_NAS varchar 255 yes Descriptionvarchar 255 yes I also installed the Time::HiRes module, but Radiator refuses to log with microseconds without any warning messages. Yes, I restarted the server completely, instead of SIGHUP. Also, some attributes are not found in the dictionary, I am using 'ascend2' in addition to 'dictionary'. I suspect these are proprietary Cisco attributes which are in the packet trace. Should I worry about this, or what's a quick and dirty method of disabling these error messages so they do not fill up the log? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging Accounting to SQL without SQL authentication
Hugh Irvine writes: > > Identifier SQLAccounting > .. > AuthSelect > AccountingTable ACCOUNTING > AcctColumnDef . > .. > > > AuthByPolicy ContinueAlways > AuthBy SQLAccounting > AuthBy CheckLDAP > . > Thanks. It's great it works, but it's a work around. SQL accounting should be independent of AuthBy SQL. Next version maybe? :) === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Logging Accounting to SQL without SQL authentication
Hi. We want to log accounting to our SQL DB, but we are using LDAP DB for authentication. What can we do? doesn't mention AccountingTable functionality from . Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) radiator hanging itself...
Check if it's blocked by a disk or a database. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Weird realms
Hugh Irvine writes: > > Hello Dan - > > You can either do what you describe (probably with a single global > RewriteUsername), or you can use Handlers with regular expressions. > > Ie. > > Which is more efficient rewrite and , or ? Thanks. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Weird realms
We have a few realms like m_devn and devn. So they're prefixes, not suffixes after "@", but with ".". For example m_devn.dan. What's the best way to handle something like this? Rewrite them in the client interface config to something @m_devn?, then handle with later? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Logging to MSSQL 7.0
Hugh Irvine writes: > BTW - you say that Radiator is *almost* perfect - we would be keen to hear > any suggestions for improvements. > > regards > > Hugh Hi Hugh, : I'd like to be able to fork an external program, and pipe the log data to it for logging, instead of logging directly to a file. I'd like to use the daemontools' 'multilog' since it does nice log rotation and TAI timestamping. Is there some way to rotate logs in Radiator? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Logging to MSSQL 7.0
First, let me add my praise about this product to the already long list. We're evaluating Radiator. This is the best commercial server product I have ever dealt with, great job! Finally a RADIUS server that's almost, if not, perfect. Rock on! Anyway, we use FreeTDS for PHP scripts, and some things work, some break and cause segfaults depending on the features we're trying to use through FreeTDS. As much as I hate logging to the database, some of our existing reporting scripts (VB Script) require it anyway, so this is a part of evaluation as well. Do any of you on this list log to an MSSQL database from a Unix variant with FreeTDS library? Any caveats? Thanks much. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
