We have experienced it running 2.19 on Solaris and running 3.1 on RedHat. Both of these are using the kerberos 5 pam from redhat.
The config is below. Mike LogDir /var/log/radius DbDir /usr/local/radiator # Use a low trace level in production systems. Increase # it to 4 or 5 for debugging, or use the -trace flag to radiusd #Trace 4 #<SNMPAgent> # ROCommunity #</SNMPAgent> # You will probably want to add other Clients to suit your site, # one for each NAS you want to work with <Client DEFAULT> DupInterval 0 DefaultRealm MODEMS </Client> <AuthLog FILE> Identifier Modem_Login_Failures Filename %L/Modem_Login_Failures LogFailure 1 FailureFormat %l:NAS %N User:%U:%T:%{NAS-Port-Type}:%{Calling-Station-Id}:%1:Fail </Authlog> <AuthLog FILE> Identifier Backbone_Login_Failures Filename %L/Backbone_Login_Failures LogFailure 1 FailureFormat %l:NAS %N User:%U:%T:%{NAS-Port-Type}:From %{Calling-Station-Id}:%1 :Fail </Authlog> <AuthLog FILE> Identifier Datacomm_Login_Failures Filename %L/Datacomm_Login_Failures LogFailure 1 FailureFormat %l:NAS %N User:%U:%T:%{NAS-Port-Type}:%{Calling-Station-Id}:%1:Fail </Authlog> <AuthLog FILE> Identifier VPN_Login_Failures Filename %L/VPN_Login_Failures LogFailure 1 FailureFormat %l:NAS %N User:%U:%T:%{NAS-Port-Type}:From %{Calling-Station-Id}:%1 :Fail </Authlog> <Handler Realm=MODEMS,NAS-Port-Type=Async,NAS-IP-Address=128.138.x.x> RewriteUsername s/^([^@]+).*/$1/ <AuthBy GROUP> AuthByPolicy ContinueUntilReject <AuthBy PAM> Service radiusd </AuthBy> <AuthBy FILE> Filename %D/backbone_users </AuthBy> </AuthBy> AuthLog Modem_Login_Failures </Handler> <Handler Realm=MODEMS,NAS-Port-Type=Virtual> RewriteUsername s/^([^@]+).*/$1/ <AuthBy GROUP> AuthByPolicy ContinueUntilReject <AuthBy PAM> Service radiusd </AuthBy> <AuthBy FILE> Filename %D/backbone_users </AuthBy> </AuthBy> AuthLog Backbone_Login_Failures # Log accounting to a detail file AcctLogFileName %L/modems_backbone_users </Handler> <Handler Realm=MODEMS> RewriteUsername s/^([^@]+).*/$1/ <AuthBy GROUP> AuthByPolicy ContinueUntilReject <AuthBy PAM> Service radiusd </AuthBy> </AuthBy> AuthLog Modem_Login_Failures AcctLogFileName %L/Modems </Handler> <Handler Realm=Off_Campus_VPN> RewriteUsername s/^([^@]+).*/$1/ <AuthBy GROUP> AuthByPolicy ContinueUntilReject <AuthBy PAM> Service radiusd </AuthBy> </AuthBy> AuthLog VPN_Login_Failures AcctLogFileName %L/Off_Campus_VPN </Handler> <Handler Realm=Backbone_Devices> RewriteUsername s/^([^@]+).*/$1/ <AuthBy GROUP> AuthByPolicy ContinueUntilReject <AuthBy PAM> Service radiusd </AuthBy> <AuthBy FILE> Filename %D/backbone_users </AuthBy> </AuthBy> AuthLog Backbone_Login_Failures # Log accounting to a detail file AcctLogFileName %L/backbone_devices </Handler> <Handler Realm=Datacomm_Devices> RewriteUsername s/^([^@]+).*/$1/ <AuthBy GROUP> AuthByPolicy ContinueUntilReject <AuthBy PAM> Service radiusd </AuthBy> <AuthBy FILE> Filename %D/backbone_users </AuthBy> </AuthBy> AuthLog Datacomm_Login_Failures # Log accounting to a detail file AcctLogFileName %L/datacomm_devices </Handler> <Client 128.138.x.x> # tcom5300 DefaultRealm MODEMS </Client> More identical clients for remaining term servers. <Client 128.138.x.x> # rgnt-6500 DefaultRealm Backbone_Devices </Client> More indentical clients. On Tue, 30 Jul 2002, Mike McCauley wrote: > Hello Mike, > > > On Tue, 30 Jul 2002 10:32, Hugh Irvine wrote: > > Hello Mike - > > > > I have copied this mail to Mike for his comments. > > I would normally expect to see a Radiator process to stabilise at 5 to 10 MB > (depending on the exact config in use). > > Dan has independently indicated that his problem seems to be FreeBSD specific. > What OS and platform are you on? > > > > > > regards > > > > Hugh > > > > On Tuesday, July 30, 2002, at 05:40 AM, Forbes Mike wrote: > > > What is the standard memory usage for radiator? We have 900 or so > > > modems > > > authenticating to this, is radiator keeping a state table of the > > > sessions > > > and if so how much space would that take up per user. I am seeing > > > memory continuing to ramp up from almost nothing to 30megs oon up to > > > 250megs. > > > > > > I am still trying to track down a memory leak with radiator > > > authenticating > > > via PAM (Kereberos). I have tested on a SUN which has a different PAM > > > infrastructure than RedHat and get the same results as my RedHat > > > test.(they could both have the leak I guess). > > > > > > As far as in depth testing of this, is this something I can take up > > > with > > > tech support, or is there some direction you can point me on doing > > > testing (not sure where to go to find a memory leak). > > > > > > Thanks, > > > > > > Mike Forbes > > > > > > On Sat, 27 Jul 2002, Mike > > > > > > McCauley wrote: > > >> Hello Dan, > > >> > > >> I wasnt able to reproduce this problem here with Radiator 3.1, your > > >> config > > >> file and testing with > > >> > > >> ./radpwtst -service_type Authenticate-Only -nas_port_type Virtual > > >> -notrace > > >> -user mikem-fred -iterations 100000 > > >> > > >> On my linux box, size of raadiusd stabilised quickly at 5616 Kb. > > >> > > >> What version of Radiator are you using, and what flags are you passing > > >> to your > > >> radpwtst? > > >> > > >> > > >> Cheers. > > >> > > >> On Wed, 24 Jul 2002 08:54, Dan Melomedman wrote: > > >>> 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' > > >>> > > >>> USER PID %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. > > >> > > >> -- > > >> Mike McCauley [EMAIL PROTECTED] > > >> Open System Consultants Pty. Ltd Unix, 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, Active Directory etc etc > > >> on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc > > >> > > >> === > > >> 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. > > > > > > === > > > 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. > > -- > Mike McCauley [EMAIL PROTECTED] > Open System Consultants Pty. Ltd Unix, 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, Active Directory etc etc > on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X etc etc > > === 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.