Re: Request For Business Transaction
He sure trusts a lot of people, asking a mailing list... -- You will attract cultured and artistic people to your home. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cuotas de conexion
On Wed, 11 Jun 2003 10:34:47 -0300, Guillermo Schimmel wrote: > I think that you are wrong in that. > > There is a lot of people who speak spanish on this list, mainly because > it is in our poor countries where we find VERY useful a radius server > which is robust and free. Of course. but it's useful EVERYWHERE to have a radius server which is robust and free. > I am in many mailing lists where the people can post in any languaje, > and you just need to have some patience, (and tolerance) with the > messages that you dont understand. The problem is that if more and more people start posting in their mother (non-English) tongue, less and less people will be able to answer. Even worse, less and less people will understand the answers that DO come, making is harder and harder to LEARN from the mailing list, which is, in fact, what it's all about. Even though there are plenty of Spaniards posting to the list, or any other nationality for that matter, there are still astronomically more people who do NOT speak Spanish, or some other language that does not start with Eng and end with lish. And that they can't understand the questions, isn't their problem, it's the poster's problem, which is bad. However, they also can't understand the ANSWERS, which is worse. > I'm seeing more spanish mails every day in this list, and we have (IMHO) > two options: Ask the people for a little patience, or create a new > spanish-freeradius-list. The secret third option would be to just post in English. If someone REALLY can't, let whoever answers help the list with some kind of translation. This would, instead of 95% of the list requiring patience and tolerance (which of course they don't have), require 5% of the list make a little effort. However, I doubt something like it will ever happen, and I doubt this mail has any kind of impact, I just felt like answering :P -- There is a 20% chance of tomorrow. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: problem compiling freeradius rlm_sql_mysql module
On Thu, 12 Jun 2003 08:02:34 +0200, Roberto Pioli wrote: > I try compiling freeradius 0.8.1 on a red hat 9 with mysql installed with > rpm. > I use ./configure --with-mysql-include-dir ,but the module rlm_sql_mysql is > not compiled. > How can I do? > > Thanks > > Teb! > What does configure tell you about the module? If it's not compiling, it's giving some kind of error message. You probably just need the mysql client development files though. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Stay the curse. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: sql module usage
On Wed, 11 Jun 2003 10:31:25 +0300, Ar wrote:
> Hi, It's about FreeRadius 0.8.1 and rlm_sql module usage and configuring
> radiusd.conf.
>
> Is it possible to use two sql modules (sql1 and sql2) derived
> from original rlm_sql module?
Yes, like all other modules. They're called instances. You can just copy the sql.conf
file and change it's contents to fit the second instance. Don't forget to include it
in radiusd.conf, and don't forget to change the instance name, like
sql sql_instance_name { directives }
unlike the default sql.conf.
> Is it possible to use only one of them in authorize section
> depending on some radius Attributes (like User-Name, etc.)
Why on earth would you want to?
What I see now is someone wanting to keep a list of users who use sql1, and a list of
users who use sql2. If that's the case you might as well use the plain old users
file...
Although I think i have the wrong idea :P
>
> Best regards to all,
> Arunas
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
--
Is this really happening?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cuotas de conexion
On Tue, 10 Jun 2003 15:03:53 -0400, Liyu wrote: > Buenas tardes, alguien me puede orientar como puedo ponerle a mi > servidor Radius cuotas de conexión a los usuarios. Pueden darme algún > ejemplo, es que soy nuevo en esto. > -- > _*Liyuán García Caballero*_ > *Consultor Informático* > *ESI, Ciego de Avila* > *Cuba*. > > _* Contactame en*_ > > Telf: 53-033-28734 ext. 120 > AIM: liyuang > Yahoo,MSN: liyuangarcia. > > *Usando Linux rh 8.0 > * > > _*Notas del día*_ > Libre de virus, pagos y multas por uso ilegal de software propietario. > You know, posting to the list in a language only a handful of other people understand kind of defeats the purpose of the whole 'mailing list' idea. -- It was all so different before everything changed. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius 160 MB vsz ?
On Tue, 10 Jun 2003 13:54:15 +0200, Thomas Krause (Webmatic) wrote: > > > Pieter Droogendijk wrote: > >>> > >>>USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > >>>radiusd 5664 0.0 1.1 164080 2880 ?? Ss Sun07AM 0:03.70 > >>>/usr/local/sbin/radiusd > >>> > >> > >>Nope. I guess there's a memory leak somewhere > >>I've got same problem here > > > > > > remember that max_requests_per_server exists to keep memleaks (if that's indeed > > what it is) from getting out of control. > > okay, i set max_requests_per_server = 300 stopped and started > radiusd, but: > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > radiusd 20548 0.0 1.1 164152 2908 ?? Ss1:46PM 0:00.01 > /usr/local/sbin/radiusd > > Regards, > Thomas. Alright, so it's big before doing anything useful? If that's the case max_requests_per_server won't do anyone any good... I just checked, and I have 10 processes, each with a VSZ of 20064. I couldn't say what your problem is, Sorry. Maybe there's something obfuscated in your configuration, or a strange unsupported camel-spitting llama module that makes the size go postal... > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- You will inherit millions of dollars. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radius 160 MB vsz ?
On Tue, 10 Jun 2003 12:39:34 +0200, Degrande_Samuel wrote: > According to Thomas Krause (Webmatic) (Tue, 10 Jun 2003 08:27:15 +0200): > > > > Hi, > > I'm using freeradius-snapshot-20030527 at FreeBSD 4.8. Is it > > okay, that the vsize of the radiusd is 160 MB? > > > > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > > radiusd 5664 0.0 1.1 164080 2880 ?? Ss Sun07AM 0:03.70 > > /usr/local/sbin/radiusd > > > > Regards, > > Thomas. > > Nope. I guess there's a memory leak somewhere > I've got same problem here remember that max_requests_per_server exists to keep memleaks (if that's indeed what it is) from getting out of control. > > > > > > > - > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > -- > Samuel Degrande LIFL - UMR 8022 CNRS - Bat M3 > Phone: (33)3.20.43.47.38 USTL - Universite de Lille 1 > Fax: (33)3.20.43.65.66 59655 VILLENEUVE D'ASCQ CEDEX - FRANCE > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- You worry too much about your job. Stop it. You are not paid enough to worry. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ACCEPT reply after ldap authentication timeout
On Wed, 28 May 2003 17:43:45 +0300 (EEST), Kostas Kalevras wrote: > On Wed, 28 May 2003, Pieter Droogendijk wrote: > > > Greetings, > > > > I'm facing an odd problem at the moment. > > > > The ISP i work for has it's own radius servers, however we don't own the CVX. > > The company that owns the CVX decided that it would be a good idea to > > automatically reject a dialup connection if the connection process (which, of > > course, includes our radius servers) takes longer then 6 seconds. And this > > poses a problem. > > > > The solution we came up with, in the first place, was to disable the password > > authentication. The new systems (which use freeradius) however, should include > > authentication as well. But since the overall timeout is only 6 seconds, and > > the LDAP gets some extreme loads at certain times, we can't reach that. > > > > I just benchmarked the server with an ldap timeout of 2 seconds (all three > > ldap timeouts that is), and 10% of 500.000 requests were rejected because of > > the timeout, which is unacceptable. > > I believe that the bottleneck is the authentication part. The BIND operation > requires a new connection (with all the corresponding overhead) as well as > processing in the ldap server side (do a crypt() on the supplied password). If > you are also using TLS (you don't say anything about it) then things will start > getting out of hand. There's nothing you can do to the ldap module to fix that > (it's how the LDAP protocol works). The only thing you can do is: > > * Put the radius server on the same machine as the ldap server and use ldapi > (ldap over unix sockets) if that is supported. I already thought of running a local ldap mirror on the radius machine, and I'll start benchmarking this friday or next monday. I'll most certainly follow all (or at least most) of your advice. thanks. > * Use the PAP/CHAP module and the password extraction mechanism of the ldap > module so that you don't need to run the ldap module in the authentication fase. > I believe that as long as your ldap server caches are working fine the > authorization part of rlm_ldap will work just fine without timeouts. > > > > > What I need is something in between the two solutions; REJECT if the > > authorization takes longer then X seconds, ACCEPT if the password > > authentication takes longer then Y seconds, or send an ACCEPT or REJECT > > according to succesful authorization and authentication responses, where > > X+Y<6. > > > > Is there any valid way, besides patching the ldap module to make the return > > value at timeouts configurable, that would solve this problem? Maybe someone > > has another solution? > > > > Thanks in advance, > > > > Pieter Droogendijk > > > > -- > > There is an old time toast which is golden for its beauty. > > "When you ascend the hill of prosperity may you not meet a friend." > > -- Mark Twain > > > > - > > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > > -- > Kostas Kalevras Network Operations Center > [EMAIL PROTECTED] National Technical University of Athens, Greece > Work Phone: +30 210 7721861 > 'Go back to the shadow' Gandalf > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- You love peace. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ACCEPT reply after ldap authentication timeout
On Wed, 28 May 2003 10:25:09 -0400, Alan DeKok wrote: > Pieter Droogendijk <[EMAIL PROTECTED]> wrote: > > The solution we came up with, in the first place, was to disable the > > password authentication. The new systems (which use freeradius) > > however, should include authentication as well. But since the > > overall timeout is only 6 seconds, and the LDAP gets some extreme > > loads at certain times, we can't reach that. > > Then I would suggest upgrading the machine running the LDAP server. > > The alternative, if the per-user LDAP configuration is *very* > simple, is to write a 'cache' module, which will cache > username/passwords, so that the LDAP server isn't hammered. > Sorry, there's a user base of 1.5 mil, and we get about 500k sessions every day. Writing a cache module would not be very useful. > > What I need is something in between the two solutions; REJECT if the > > authorization takes longer then X seconds, ACCEPT if the password > > authentication takes longer then Y seconds, > > Authentication is taking 2 seconds, against the LDAP server? > There's GOT to be a better way... > One authentication, no, but once the load goes up to 80 per second just from one server, things just start slowing down. > > or send an ACCEPT or REJECT according to succesful authorization and > > authentication responses, where X+Y<6. > > That's a horrendously evil hack, and I would strongly advise against > it. I know :P > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- Perilous to all of us are the devices of an art deeper than we ourselves possess. -- Gandalf the Grey [J.R.R. Tolkien, "Lord of the Rings"] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ACCEPT reply after ldap authentication timeout
On 28 May 2003 13:11:39 +0200, Chris van Meerendonk wrote: > On Wed, 2003-05-28 at 12:40, Pieter Droogendijk wrote: > > Greetings, > > > > I'm facing an odd problem at the moment. > > > > The ISP i work for has it's own radius servers, however we don't own the CVX. The > > company that owns the CVX decided that it would be a good idea to automatically > > reject a dialup connection if the connection process (which, of course, includes > > our radius servers) takes longer then 6 seconds. And this poses a problem. > > On a CVX, the default radius timeout is set to 3 seconds with 3 retries > per radius server, but this is apart from the time the rest of the > connection setup takes. The modem connect-timeout defaults to 6 > milliseconds and the ppp-modem EstablishTimeLimit defaults to 12 > msec. This can be seperately configured for isdn and analog modems. > > With these settings we don't have any problems. Do you have a backup > radiusserver configured at the CVX? I'm not sure which timeout you're > pointing to, I guess the radius timeout. Yes, the radius timeout. I don't know much about the CVX, I've never been allowed to touch it. All I was told was that the whole radius process can't take longer then 6 seconds, or a connection is terminated. Problem is, it just takes too long to do authorize and authenticate to an ldap. I don't know why, maybe the ldaps are just crap. The things are THE number one bottleneck everywhere. > > Regards, > > Chris > > > The solution we came up with, in the first place, was to disable the password > > authentication. The new systems (which use freeradius) however, should include > > authentication as well. But since the overall timeout is only 6 seconds, and the > > LDAP gets some extreme loads at certain times, we can't reach that. > > > > I just benchmarked the server with an ldap timeout of 2 seconds (all three ldap > > timeouts that is), and 10% of 500.000 requests were rejected because of the > > timeout, which is unacceptable. > > > > What I need is something in between the two solutions; REJECT if the authorization > > takes longer then X seconds, ACCEPT if the password authentication takes longer > > then Y seconds, or send an ACCEPT or REJECT according to succesful authorization > > and authentication responses, where X+Y<6. > > > > Is there any valid way, besides patching the ldap module to make the return value > > at timeouts configurable, that would solve this problem? Maybe someone has another > > solution? > > > > Thanks in advance, > > > > Pieter Droogendijk > > > > -- > > There is an old time toast which is golden for its beauty. > > "When you ascend the hill of prosperity may you not meet a friend." > > -- Mark Twain > > > > - > > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > > > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > -- You are the only person to ever get this message. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ACCEPT reply after ldap authentication timeout
Greetings, I'm facing an odd problem at the moment. The ISP i work for has it's own radius servers, however we don't own the CVX. The company that owns the CVX decided that it would be a good idea to automatically reject a dialup connection if the connection process (which, of course, includes our radius servers) takes longer then 6 seconds. And this poses a problem. The solution we came up with, in the first place, was to disable the password authentication. The new systems (which use freeradius) however, should include authentication as well. But since the overall timeout is only 6 seconds, and the LDAP gets some extreme loads at certain times, we can't reach that. I just benchmarked the server with an ldap timeout of 2 seconds (all three ldap timeouts that is), and 10% of 500.000 requests were rejected because of the timeout, which is unacceptable. What I need is something in between the two solutions; REJECT if the authorization takes longer then X seconds, ACCEPT if the password authentication takes longer then Y seconds, or send an ACCEPT or REJECT according to succesful authorization and authentication responses, where X+Y<6. Is there any valid way, besides patching the ldap module to make the return value at timeouts configurable, that would solve this problem? Maybe someone has another solution? Thanks in advance, Pieter Droogendijk -- There is an old time toast which is golden for its beauty. "When you ascend the hill of prosperity may you not meet a friend." -- Mark Twain - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
