Re: Dependencies of Freeradius 2.0.5
Leander S. wrote: > I know about radius -X ... I already setted up the version 1.1.7 > succesfully ... but now I'm working on almost complety revised version > 2.0.5 ... so SQL configs are different for me and I might made some > mistakes there so that the radius -X is not showing me some pg code ... ;/ As always, start off with the default config. > ./configure --with-your-personal-options | grep WARNING > > --> There is nothing saying anything about sql , or pg or postgres in > ./configure --help ... There is *generic* help for configuring modules. If there was a few lines of text for every module, the "configure --help" output would be huge... and no ne would read it. > You may want to give me an example especialy for postgres ?! Would be > great. > --> I also tryed: ./configure --with-postgresql=YES > --enable-postgresql=YES --with-rlm-postgresql-lib-dir=/usr/local/lib/ > --with-rlm-postgresql-include-dir=/usr/local/lib/ > --> But I haven't had more luck than before .. and also no more WARNING > messages to read than I've had before .. so there might be something > wrong ... Try reading the output of configure. Look for "postgres". It will show lots of messages about what it's doing to find postgres. > But anyway .. here's how I used to run it usually ... because you said > it trys to build as much modules as possible if the neccessary software > stuff like postgresql-server/client is already preinstalled ... so > postgres support for freeradius should work also ... but .. sadly .. it > won't do it yet for me ... ;) I'm not convinced of that, to be honest. > root /usr/src/freeradius-server-2.0.5 # ./configure | grep WARNING ... > ... ^^ which looks fine for me so far ... because I only need PostgreSQL > ... not Oracle or MySQL. Yes. It looks like the postgres module *is* being built. > but if I now go ahead and do: # ./configure, gmake, gmake install Blindly? Without reading the output? Why? If you're having issues getting something to work, the READ. The reason the configure && make && make install process prints out messages is for you to READ THEM. If everything works, most of the output can be ignored. If something goes wrong, you need to READ THE OUTPUT. Did you read the output to see if it *did* build && install the postgresl module? If not, why? > and > finally run radius -X it shows me not even one time anything about pg or > postgres module ...: Let me guess: You didn't configure the server to use SQL. You didn't un-comment SQL in any of the examples. You didn't configure sql.conf to point to your postgresql database. If SQL isn't configured, the server won't load it. If SQL is configured, the server will load it. If SQL is configured, AND the Postgresql module wasn't built, the server will print out error messages, and refuse to start. IIRC, you were told this earlier, too. > no more sql infomation ^^ postgresql seems not even to be loaded when > radius starts ... Because you didn't tell the server it needed to use SQL. > a step further I noticed there is even no module in: > > root /usr/src/freeradius-server-2.0.5 # ls -lach > /usr/local/etc/raddb/modules/ The file is in raddb/sql.conf. It's not hard to find the file. Honest. It's in the same place as in 1.1.7. Or, just read radiusd.conf. Or use "grep". It's a wonderful tool that comes with most Unix systems. And I take the inability to find sql.conf as proof that you haven't configured the server to use SQL. And you haven't configured SQL to use postgres. So the server won't use SQL, because you haven't told it to use SQL. > so it might be still missed .. but what part is missed to get postgresql > support? You need to tell the server to use SQL. Just like in 1.1.7. You need to tell the SQL module to load postgres. Just like in 1.1.7. > I already do have PostgreSQL Server 8.3 compiled and > successfully running and I also do have PostgreSQL Client 8.1 also > already installed from binary to my FreeBSD.. so WTF? ;) ?? The server doesn't know the postgresql admin name or password. So it can't magically start using postgres as soon as the postgres module is built. You have to edit the default configs. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Dependencies of Freeradius 2.0.5
Hi Alan, I know about radius -X ... I already setted up the version 1.1.7 succesfully ... but now I'm working on almost complety revised version 2.0.5 ... so SQL configs are different for me and I might made some mistakes there so that the radius -X is not showing me some pg code ... ;/ Btw.: ./configure --with-your-personal-options | grep WARNING --> There is nothing saying anything about sql , or pg or postgres in ./configure --help ... You may want to give me an example especialy for postgres ?! Would be great. --> I also tryed: ./configure --with-postgresql=YES --enable-postgresql=YES --with-rlm-postgresql-lib-dir=/usr/local/lib/ --with-rlm-postgresql-include-dir=/usr/local/lib/ --> But I haven't had more luck than before .. and also no more WARNING messages to read than I've had before .. so there might be something wrong ... But anyway .. here's how I used to run it usually ... because you said it trys to build as much modules as possible if the neccessary software stuff like postgresql-server/client is already preinstalled ... so postgres support for freeradius should work also ... but .. sadly .. it won't do it yet for me ... ;) root /usr/src/freeradius-server-2.0.5 # ./configure | grep WARNING config.status: WARNING: ./Make.inc.in seems to ignore the --datarootdir setting config.status: WARNING: ./src/include/build-radpaths-h.in seems to ignore the --datarootdir setting chmod: check-radiusd-config: No such file or directory configure: WARNING: silently not building rlm_eap_ikev2. configure: WARNING: FAILURE: rlm_eap_ikev2 requires: libeap-ikev2 EAPIKEv2/connector.h. configure: WARNING: the TNCS library isn't found! configure: WARNING: silently not building rlm_eap_tnc. configure: WARNING: FAILURE: rlm_eap_tnc requires: -lTNCS. configure: WARNING: silently not building rlm_krb5. configure: WARNING: FAILURE: rlm_krb5 requires: krb5. configure: WARNING: silently not building rlm_ldap. configure: WARNING: FAILURE: rlm_ldap requires: libldap_r ldap.h. configure: WARNING: silently not building rlm_python. configure: WARNING: FAILURE: rlm_python requires: python-binary. configure: WARNING: oracle headers not found. Use --with-oracle-home-dir=. configure: WARNING: silently not building rlm_sql_oracle. configure: WARNING: FAILURE: rlm_sql_oracle requires: oci.h. root /usr/src/freeradius-server-2.0.5 # ... ^^ which looks fine for me so far ... because I only need PostgreSQL ... not Oracle or MySQL. but if I now go ahead and do: # ./configure, gmake, gmake install and finally run radius -X it shows me not even one time anything about pg or postgres module ...: root /usr/src/freeradius-server-2.0.5 # radiusd -X FreeRADIUS Version 2.0.5, for host x86_64-unknown-freebsd7.0, built on Jun 23 2008 at 02:01:51 Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. Starting - reading configuration files ... including configuration file /usr/local/etc/raddb/radiusd.conf including configuration file /usr/local/etc/raddb/proxy.conf including configuration file /usr/local/etc/raddb/clients.conf including configuration file /usr/local/etc/raddb/snmp.conf including files in directory /usr/local/etc/raddb/modules/ including configuration file /usr/local/etc/raddb/modules/policy including configuration file /usr/local/etc/raddb/modules/acct_unique including configuration file /usr/local/etc/raddb/modules/unix including configuration file /usr/local/etc/raddb/modules/chap including configuration file /usr/local/etc/raddb/modules/preprocess including configuration file /usr/local/etc/raddb/modules/expiration including configuration file /usr/local/etc/raddb/modules/mac2vlan including configuration file /usr/local/etc/raddb/modules/mschap including configuration file /usr/local/etc/raddb/modules/ippool including configuration file /usr/local/etc/raddb/modules/files including configuration file /usr/local/etc/raddb/modules/krb5 including configuration file /usr/local/etc/raddb/modules/passwd including configuration file /usr/local/etc/raddb/modules/radutmp including configuration file /usr/local/etc/raddb/modules/attr_rewrite including configuration file /usr/local/etc/raddb/modules/echo including configuration file /usr/local/etc/raddb/modules/etc_group including configuration file /usr/local/etc/raddb/modules/pap including configuration file /usr/local/etc/raddb/modules/realm including configuration file /usr/local/etc/raddb/modules/pam including configuration file /usr/local/etc/raddb/modules/always including configuration file /usr/local/etc/raddb/modules/exec including configuration file /usr/local/etc/raddb/modules/logintime including configuration file /usr/local/etc/raddb/modules/sql_log including configuration file /usr/local/etc/raddb/modules/smbpasswd includ
Re: Dependencies of Freeradius 2.0.5
Thank you very much for your work David! But I rather want to compile it by myself, because: a) I don't want to update all my ports, because than I am "supposed" to update my RELEASE version of FreeBSD to an STABLE version and reinstall all packages and re-check my configuration files in etc ... bla bla ... (it's a production server) b) I might need to upgrade FreeRADIUServer in future ... and _only_ FreeRADIUServer .. so it might be a good exercise for me to get know about how to compile FreeRADIUServer and also of the dependencies I'll need in my case to be a little more independent and flexible of the provided binary packages of FreeBSD. Best regards, Leander David Wood schrieb: Hi Leander and all, In message <[EMAIL PROTECTED]>, Leander S. <[EMAIL PROTECTED]> writes Yes, thanks I understood this. But the Reason why I'm asking is, because I want to know about the version numbers which are required for example with snmp - because I use FreeBSD 7.0 RELEASE and there might be not the newst snmp software ready to install from the ports. The latest SNMP software is available in FreeBSD ports - well, very nearly. net-mgmt/net-snmp is currently at version 5.4.1 whilst it looks like Net SNMP version 5.4.1.2 has just been released. However, the issue with SNMP is not how new the SNMP software is! As has been said, the SNMP code in FreeRADIUS has rotted; it's not 64 bit safe, it uses the obsolescent smux protocol and it uses the ucd-snmp API. The latter of these issues means FreeRADIUS's SNMP code only works on FreeBSD against the obsolescent net-mgmt/net-snmp4 port, which is UCD SNMP. The correct way ahead with the FreeRADIUS SNMP code is widely acknowledged to be a rewrite using AgentX - however the new statistics code may turn out to be a better option. I wonder if the current SNMP code will be retired now that the statistics code is available. Rather than worrying about the dependencies, you could just install the FreeBSD net/freeradius2 port. I've done all the work for you - I've even provided an option to install every FreeRADIUS feature for which the libraries are available in ports. The net/freeradius2 port isn't in 7.0-RELEASE - it missed the deadline to be included. Even if it hadn't missed the deadline, it would have been version 2.0.0. All you need to do is to bring your ports tree up to date via your favourite method. 'portsnap fetch update' will do the job. At the moment, the port is still 2.0.3 - there's been some configuration management stuff to sort out that needs to go in the upgrade to 2.0.5. Once you have an up to date ports tree in /usr/ports, the following commands should download and install a pre-release version of the 2.0.5 port: cp -R /usr/ports/net/freeradius2 freeradius2 fetch http://www.wood2.org.uk/freebsd/port-freeradius2-2.0.5.patch patch -sd freeradius2 -i ../port-freeradius2-2.0.5.patch && \ find freeradius2 -name '*.orig' -delete ( cd freeradius2 ; make install ) should do the job. I suggest copying and pasting those lines to a shell prompt. Note that the last step almost certainly requires root privileges. If you did not already have a FreeRADIUS configuration in /usr/local/etc/raddb, a copy of the sample configuration is made there ready for your customisation and raddb/certs has been bootstrapped so that the server is ready to go. Unless you deliberately disable the USER option, the server is configured to use the freeradius user and freeradius group (the group and user are created if necessary). This is recommended from a security perspective. The port installs an rc.d script for radiusd. Finally, you'll get a message on screen giving you various useful information including pointers to the documentation and the FreeRADIUS Wiki. I hope that this latest version of the port is easier to get going 'out of the box' than any previous version. Whilst it's a pre-release, I've completed my testing on it tonight - the only task remaining is to write up some documentation, then hopefully I can get it committed to the ports tree. ** IMPORTANT ** If you have an existing FreeRADIUS configuration, back up /usr/local/etc/raddb *before* uninstalling the old FreeRADIUS port - otherwise you will finish up with unmodified files being deleted from your existing configuration and these files not being restored after you install the 2.0.5 port. This is the issue that's delaying the upgrade until it's properly documented. The behaviour of the port is being changed to prevent this problem in the future. For more details, see http://www.freebsd.org/cgi/query-pr.cgi?pr=124439 ** IMPORTANT ** It is important to read /usr/ports/UPDATING after updating your ports tree. If you haven't already been through this, there's been an update to gettext that means many ports need rebuilding. Best wishes, David (FreeBSD port maintainer for FreeRADIUS) - List info/subscribe/unsubscribe? See http://www
dhcp server - some patches
Sorry, i don't know (havn't read maybe :) ) how to submit patches.
I'll paste here
First one ... allows receive DHCP-Inform messages.
--- dhcp.c 2008-06-23 02:46:17.0 +0300
+++ dhcp_new.c 2008-06-23 02:45:26.0 +0300
@@ -190,7 +190,7 @@
if ((packet->data[240] != 53) ||
(packet->data[241] != 1) ||
(packet->data[242] == 0) ||
- (packet->data[242] >= 8)) {
+ (packet->data[242] > 8)) {
fprintf(stderr, "Unknown, or badly formatted DHCP packet\n");
rad_free(&packet);
return NULL;
Second one ... patches for updating reply->code correctly depending on modules
answer(last DHCP-Message-Type update will be in action). Actualy client
must!!! supply in some update section DHCP-Message-Type.
Otherwise i think no reply at all(not tested) :) .
And i think there no need to respond with NAK in reject, fail and other cases
(and DECLINE response is client side only). There is no need for that garbage
traffic. If module fails then fails. NAK message to client will not help in
this case :) Or maybe i don't want to respond at all (ignore) :)
--- dhcpd.c 2008-06-23 02:38:57.0 +0300
+++ dhcpd_new.c 2008-06-23 02:43:19.0 +0300
@@ -46,17 +46,13 @@
switch (rcode) {
case RLM_MODULE_OK:
case RLM_MODULE_UPDATED:
- if (request->packet->code == (PW_DHCP_DISCOVER)) {
- request->reply->code = PW_DHCP_OFFER;
- break;
-
- } else if (request->packet->code == PW_DHCP_REQUEST) {
- request->reply->code = PW_DHCP_ACK;
- break;
- }
-
- /* FALL-THROUGH */
+ vp = pairfind(request->reply->vps, DHCP2ATTR(53));
+ if (vp) {
+ request->reply->code = vp->vp_integer + PW_DHCP_OFFSET;
+ break;
+ }
+ break; /* no DHCP-Message-Type in reply, maybe other modules will
update.*/
default:
case RLM_MODULE_REJECT:
case RLM_MODULE_FAIL:
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
SQL radwho radsqlwho
Here's what I'm using. It very likely will not work out-of-the-box on
a stock freeradius, and it's PostgreSQL-specific.
#!/usr/local/bin/perl
#
use Time::Local;
use DBI;
use Getopt::Std;
$SQL_HOST="pgsql.example.com";
getopts('ah');
if ($opt_h) {
print STDERR prepare(qq[SET DATESTYLE TO 'Postgres';]);
unless ($sth->execute) {
print "SET DATESTYLE failed: " . $DBI::errstr . "\n";
}
$sth->finish;
my $sth = $dbh->prepare(qq[SET TIME ZONE 'Africa/Mogadishu';]);
unless ($sth->execute) {
print "SET TIME ZONE failed: " . $DBI::errstr . "\n";
}
$sth->finish;
unless (length($logname)) {
$query="SELECT
username
,nasipaddress
,modulationtype,framedipaddress,nasportid,split_part(connectspeed,
'-', 1) AS connectspeed, to_char(now() - acctstarttime, 'HH24:MI:SS')
AS sessiontime, to_char(acctstarttime, 'HH24:MI Mon DD') AS starttime
FROM radacct WHERE acctstoptime IS NULL ORDER BY acctstarttime";
} else {
$logname=$dbh->quote($logname);
$query="SELECT
username
,nasipaddress
,modulationtype,framedipaddress,nasportid,split_part(connectspeed,
'-', 1) AS connectspeed, to_char(now() - acctstarttime, 'HH24:MI:SS')
AS sessiontime, to_char(acctstarttime, 'HH24:MI Mon DD') AS starttime
FROM radacct WHERE username=$logname AND acctstoptime IS NULL ORDER BY
acctstarttime";
}
&detail_format;
my $sth = $dbh->prepare(qq[$query]);
unless ($sth->execute) {
print "SELECT failed: " . $DBI::errstr . "\n";
}
if ($sth->rows) {
my $hash_ref;
while ($hash_ref = $sth->fetchrow_hashref) {
$username=$hash_ref->{username};
$framedip=$hash_ref->{framedipaddress};
$modtype=$hash_ref->{modulationtype};
$speed=$hash_ref->{connectspeed};
$sesstime=$hash_ref->{sessiontime};
$starttime=$hash_ref->{starttime};
if ($opt_a) {
$username='';
}
write;
}
}
$sth->finish;
$dbh->disconnect;
sub detail_format
{
$%=0;
$-=0;
$==59;
$^ = "DETAIL_TOP";
$~ = "DETAIL";
}
format DETAIL_TOP =
Login IDIP Address Modulation Speed Time When
.
format DETAIL =
@< @<< @< @ @
@
$username, $framedip, $modtype, $speed, $sesstime, $starttime
.
--
Have you "man unlang"ed today?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radacct/radutmp out of sync
Tuc at T-B-O-H.NET wrote: > Is there an SQL version of "radwho"? I've taught the people to use > radwho to determine who is logged on, and don't see another utility or > string I can pass to radwho. SQL command-line tools can do the same thing with a properly formatted query. So far, no one has submitted one. > 4. LOG FILES > > 4a. /var/log/radutmp > > In this file the currently logged in users are held. The program "radwho" > reads this file and gives you a summary. Rogue sessions can be deleted > from this file with the "radzap" program. SQL command-line tools can do the same thing with a properly formatted query. > It also seems "radzap" depends on the accuracy of radwho to > be able to pipe information ro radzap. So it seems to be able to use > atleast 2 of the supplied utilities, radutmp is necessary and can't > be substituted with SQL, unless I am looking in the wrong place. The SQL databases have all of the same information that's available in radutmp. They often have more, because radutmp has strict limits on the kind of records it can store. "radwho" and "radzap" exist only to manipulate "radutmp". If you're using SQL instead of radutmp, then those programs can be replaced with programs that manipulate SQL instead of radutmp. There's nothing magic about radutmp. It exists only because 10 years ago, it was often easier to use than an SQL DB. There is less need today to use radutmp. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Code fix for next release
> > Tuc at T-B-O-H.NET wrote: > > Can Bug 517 (Patch for radwho to correct time output and IP > > address outpu) be included in the next release? I've used the supplied > > patch and find it works quite well. Would be nice not to have to repatch > > on the next release. > > Done. > Many thanks. Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radacct/radutmp out of sync
> > Tuc at T-B-O-H.NET wrote: > > Ok, thanks. I have to do more work to see if radutmp EVER had a > > record for the user or not. My initial thought was that when the user logged > > off and an accounting stop record was sent, that it updated the radutmp > > file, > > and then "SOMETHING" happened that the sql radacct didn't get updated. I > > never > > thought that for some reason the accounting start and interim update records > > were getting into sql but none of it ever making radutmp. > > radutmp is a historical hack. If you're using SQL, there's no need to > use radutmp. > > > Are radutmp entrys ONLY created during accounting start requests, and > > deleted during accounting stop records (Or Accounting On/Off for a NAS), or > > can an accounting interim-update cause the creation of a radutmp entry that > > wasn't there previously? > > I haven't looked at that module in a long time, sorry. > > I *really* suggest not using radumtp if you're using SQL. > Is there an SQL version of "radwho"? I've taught the people to use radwho to determine who is logged on, and don't see another utility or string I can pass to radwho. From the README in doc directory : 4. LOG FILES 4a. /var/log/radutmp In this file the currently logged in users are held. The program "radwho" reads this file and gives you a summary. Rogue sessions can be deleted from this file with the "radzap" program. It also seems "radzap" depends on the accuracy of radwho to be able to pipe information ro radzap. So it seems to be able to use atleast 2 of the supplied utilities, radutmp is necessary and can't be substituted with SQL, unless I am looking in the wrong place. Thanks, Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
Chris wrote:
> Then when someone cuts and pastes a default config module to modify,
> they just might key into the fact that they need to define an sql module
> named x-sql-module without having to go to the documentation at all.
I disagree. Given 10 years of history on this list, if you tell
people to create an "sql1" instance of the "sql" module, they'll write
"sql1 sql1 { ...", and then wonder why it doesn't work. This has
already happened any number of times.
Not many people do this, of course. Most read the documentation and
figure it out. But a persistent vocal minority does exactly this.
Adding more documentation to help them is largely a waste of time.
> You know, before deploying this time around I searched for a way to make
> a monetary contribution and came up empty. I then decided I would wait
> for the book and buy that but there isn't one.
You honestly can't be serious. Is this some kind of joke? Really?
There are contributions other than money. Code patches or
documentation patches are always welcome (subject to review, of course).
Claiming that you could only contribute money is nonsense.
> I might very well take the time to make these changes to the default
> config and submit patches, but it'd obviously be a waste of time because
> you've already determined such changes are useless, or at least not
> *useful*.
Yes... the fact that I disagree with you, and have historical evidence
to back up my position is evidence that you shouldn't contribute.
> Actually, I said the software was a "gem". It's the "config file
> comments as a substitute for documentation" that sucks.
So... submit documentation. Documentation that will *help*. But
adding a third or fourth copy of existing documentation in a different
form doesn't count.
Sorry. I want to make the server *better*. I don't want four copies
of the same piece of documentation.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radacct/radutmp out of sync
Tuc at T-B-O-H.NET wrote: > Ok, thanks. I have to do more work to see if radutmp EVER had a > record for the user or not. My initial thought was that when the user logged > off and an accounting stop record was sent, that it updated the radutmp file, > and then "SOMETHING" happened that the sql radacct didn't get updated. I never > thought that for some reason the accounting start and interim update records > were getting into sql but none of it ever making radutmp. radutmp is a historical hack. If you're using SQL, there's no need to use radutmp. > Are radutmp entrys ONLY created during accounting start requests, and > deleted during accounting stop records (Or Accounting On/Off for a NAS), or > can an accounting interim-update cause the creation of a radutmp entry that > wasn't there previously? I haven't looked at that module in a long time, sorry. I *really* suggest not using radumtp if you're using SQL. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
Tuc at T-B-O-H.NET wrote: > So does this mean that bug 517, which includes code which looks > reasonable, and has been tested in my setup (For what thats worth) submitted > on Feb 8, 2008... And missed the 2.0.2 version (Not sure when freeze was > for that, since it was less than a week later)... And missed : ... many releases. Patches don't always go in immediately. Some patches are edited before being committed. In general, most fixes go in quickly. See any number of posts to the mailing list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Code fix for next release
Tuc at T-B-O-H.NET wrote: > Can Bug 517 (Patch for radwho to correct time output and IP > address outpu) be included in the next release? I've used the supplied > patch and find it works quite well. Would be nice not to have to repatch > on the next release. Done. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
Have a look at CVS. If it's there, it will be in 2.0.6. Ivan Kalik Kalik Informatika ISP Dana 22/6/2008, "Tuc at T-B-O-H.NET" <[EMAIL PROTECTED]> piše: >> >> Submit a *useful* patch, and it will go in. Until then, please >> continue to profit from a project that "sucks". A project to which >> you've contributed nothing. The sheer hypocrisy of that position should >> be evident to everyone. >> > So does this mean that bug 517, which includes code which looks >reasonable, and has been tested in my setup (For what thats worth) submitted >on Feb 8, 2008... And missed the 2.0.2 version (Not sure when freeze was >for that, since it was less than a week later)... And missed : > >17 March 2008 - Version 2.0.3 > >30 April 2008 - Version 2.0.4 > >7 June 2008 - Version 2.0.5 > > will definitely make a 2.0.6 release? > > Thanks, Tuc >- >List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
On Jun 22, 2008, at 9:53 AM, Alan DeKok wrote:
Chris wrote:
So if possibly improving inherent clarity in the default config
nets a
"why bother, nobody'll read it anyway" from you, why should anyone
else
care?
Nice try.
The module configuration is documented in radiusd.conf, in the
"modules" section. It explains clearly the syntax and behavior of the
module configuration. It is further documented in the files in the
"doc" directory, and in the example module configurations (modules/
directory in 2.0.5, or radiusd.conf in other versions.)
Your suggestion to duplicate the documentation in *more* places is
not
helpful. Especially since your original complaint was in response to
someone who was told *what* to read, and *where* to read it... and
still
had issues.
Please demonstrate how adding *more* documentation will help people
who don't read the existing documentation that they're told to read.
Use examples. Please.
I'm not suggesting more documentation. I'm suggesting modules in the
default config be defined in a consistent manner for, well,
consistency and clarity. Thus making that segment of the
documentation less necessary.
Instead of:
modules {
sql { }
sql another-sql-module { }
}
It would be more clear to eliminate the dual syntax of defining
modules with something like this:
modules {
sql sql-module { }
sql another-sql-module { }
}
Then when someone cuts and pastes a default config module to modify,
they just might key into the fact that they need to define an sql
module named x-sql-module without having to go to the documentation at
all.
The real issue is you got caught. You have vocal complaints about a
product that until now, you've refused to contribute to... despite
profiting from it. When this was pointed out, you searched desperate
for some justifaction to "prove" that any contribution wouldn't be
accepted and got caught again.
You know, before deploying this time around I searched for a way to
make a monetary contribution and came up empty. I then decided I
would wait for the book and buy that but there isn't one.
Submit a *useful* patch, and it will go in. Until then, please
continue to profit from a project that "sucks". A project to which
you've contributed nothing. The sheer hypocrisy of that position
should
be evident to everyone.
I might very well take the time to make these changes to the default
config and submit patches, but it'd obviously be a waste of time
because you've already determined such changes are useless, or at
least not *useful*.
Actually, I said the software was a "gem". It's the "config file
comments as a substitute for documentation" that sucks.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: radacct/radutmp out of sync
> > Tuc at T-B-O-H.NET wrote: > > What are some possible causes in 2.0.4 for the radacct (MySQL) and > > radutmp (That feeds radwho) to get out of sync. It seems almost 100% of the > > time, radwho/radutmp isn't showing the user, while radacct has no > > acctstoptime. > > radutmp requires specific information to store a utmp record. If that > information isn't in an accounting request, no record is created. > Ok, thanks. I have to do more work to see if radutmp EVER had a record for the user or not. My initial thought was that when the user logged off and an accounting stop record was sent, that it updated the radutmp file, and then "SOMETHING" happened that the sql radacct didn't get updated. I never thought that for some reason the accounting start and interim update records were getting into sql but none of it ever making radutmp. Are radutmp entrys ONLY created during accounting start requests, and deleted during accounting stop records (Or Accounting On/Off for a NAS), or can an accounting interim-update cause the creation of a radutmp entry that wasn't there previously? Thanks, Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
> > Submit a *useful* patch, and it will go in. Until then, please > continue to profit from a project that "sucks". A project to which > you've contributed nothing. The sheer hypocrisy of that position should > be evident to everyone. > So does this mean that bug 517, which includes code which looks reasonable, and has been tested in my setup (For what thats worth) submitted on Feb 8, 2008... And missed the 2.0.2 version (Not sure when freeze was for that, since it was less than a week later)... And missed : 17 March 2008 - Version 2.0.3 30 April 2008 - Version 2.0.4 7 June 2008 - Version 2.0.5 will definitely make a 2.0.6 release? Thanks, Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Code fix for next release
Hi, Can Bug 517 (Patch for radwho to correct time output and IP address outpu) be included in the next release? I've used the supplied patch and find it works quite well. Would be nice not to have to repatch on the next release. Thanks, Tuc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
Chris wrote: > So if possibly improving inherent clarity in the default config nets a > "why bother, nobody'll read it anyway" from you, why should anyone else > care? Nice try. The module configuration is documented in radiusd.conf, in the "modules" section. It explains clearly the syntax and behavior of the module configuration. It is further documented in the files in the "doc" directory, and in the example module configurations (modules/ directory in 2.0.5, or radiusd.conf in other versions.) Your suggestion to duplicate the documentation in *more* places is not helpful. Especially since your original complaint was in response to someone who was told *what* to read, and *where* to read it... and still had issues. Please demonstrate how adding *more* documentation will help people who don't read the existing documentation that they're told to read. Use examples. Please. The real issue is you got caught. You have vocal complaints about a product that until now, you've refused to contribute to... despite profiting from it. When this was pointed out, you searched desperate for some justifaction to "prove" that any contribution wouldn't be accepted and got caught again. Submit a *useful* patch, and it will go in. Until then, please continue to profit from a project that "sucks". A project to which you've contributed nothing. The sheer hypocrisy of that position should be evident to everyone. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
On Jun 22, 2008, at 9:03 AM, Alan DeKok wrote: The people who *do* contribute say things like "this thing annoyed me, so here's the fix." I'll take that any day over empty complaints. And when one does, one gets: (IMHO, the default config could eliminate some of this frequent confusion if it were changed to, say, "ldap ldap-module" instead of just "ldap", "sql sql-module" instead of just "sql". Maybe. But no amount of documentation will help people who get told to read it... and then don't. Alan DeKok. So if possibly improving inherent clarity in the default config nets a "why bother, nobody'll read it anyway" from you, why should anyone else care? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server - some bugs ?
EvilEzh wrote: > i'm not strong with c programming and patching. So i can only suggest :( > in dhcpd.c i think code: > case: RLM_MODULE_UPDATED: > there is some code that sets response type. Hmm... OK. > btw .. i've idea, maybe problem is that eth1 client network is > 10.10.1.0/24 . But i've ip address bind on this interface 10.2.0.15 > (10.2.0.15/24). Will test. Well, yes. If the interface isn't reachable from 10.1.0.3, then the DHCP packets won't reach the interface. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
Arran Cudbard-Bell wrote: > No, the man pages are just fine. The problem here is the documentation > often assumes a knowledge of the protocol / supporting RFCs. Either > people are too stupid/ lazy to go out and find the information > themselves, or they've lost the basic ability to learn things without > being spoon-fed. I don't expect people to understand every RADIUS detail. I *do* expect people to be able to read things... when told what to read. I've given up expecting the complainers to contribute anything. There's a *strong* correlation between people who complain, and people who don't contribute. The people who *do* contribute say things like "this thing annoyed me, so here's the fix." I'll take that any day over empty complaints. > This guys crappy attitude aside, the wiki could use a bit of an > overhaul. All the 1.* stuff needs stripping out or marking as such, > because it's getting confusing. Ubuntu managed to ship 8.04 (LTS) with 1.1.7. This means that 1.1.7 will be included in Ubuntu 8.04 for the next 3 years. > Could each take a few sections? It's a bit much for one person to tackle > by themselves. I'm going to put the ~200 pages of my book up on deployingradius.com. I'll post an announcement later this week. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
sqlippool error
Hello Please Help me sqlippool error select FramedIPAddress,NASIPAddress,CallingStationID,username from radippool; FramedIPAddress| NASIPAddress | CallingStationID | username 172.16.2.1 | 127.0.0.1 | 121.111.111.123 | user1 172.16.2.2 | 127.0.0.1 | 121.111.111.123 | user2 172.16.2.3 | empty | empty | user6 radwho Login Name What TTY When From Location user1 user1 PPP S0 Sat 12:47 127.0.0.1 172.16.2.1 user2 user2 PPP S1 Wed 10:05 127.0.0.1 172.16.2.2 user3 user3 PPP S2 Sun 17:42 127.0.0.1 172.16.2.3 ==> long time connecting 180도 달라진 야후! 메일 - 여러 개의 메시지를 동시에 확인? 새로운 야후! 메일의 탭으로 가능해집니다. http://kr.content.mail.yahoo.com/cgland - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server - some bugs ?
EvilEzh wrote: 1. As i understand responses is hardcoded(preset) to discover and request. DHCP-Message-Type = ... in config file is ignored, It *should* pay attention to DHCP-Message-Type. If not, patches are welcome. i'm not strong with c programming and patching. So i can only suggest :( in dhcpd.c i think code: case: RLM_MODULE_UPDATED: there is some code that sets response type. maybe put before (if (req..) , some code that verify if DHCP-Message-Type from relay is set then request->replay->code = information from update relay ... otherwise as in code. 4. couldn't find out why, but packet incoming from real ip addresses to broadcast are ignored. 0.0.0.0 -> 255.255.255.255 - processed, 10.1.0.3 -> 255.255.255.255 - ignored. I think it's a kernel thing. btw .. i've idea, maybe problem is that eth1 client network is 10.10.1.0/24 . But i've ip address bind on this interface 10.2.0.15 (10.2.0.15/24). Will test. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: dhcp server - some bugs ?
EvilEzh wrote: > 1. As i understand responses is hardcoded(preset) to discover and > request. DHCP-Message-Type = ... in config file is ignored, It *should* pay attention to DHCP-Message-Type. If not, patches are welcome. > so i can't > respond to RELEASE, INFORM, DECLINE. Always is NAK. Response to request > also could be NAK, not always ACK. It is possible respond to request > with NAK if change RLM_UPDATED to rejected or something like this. Would > be nice if dhcp server check for DHCP-Message-Type is set. That would be good, yes. > 2. in dhcp.c ... when checking for know packet type. (packet->data[242] >>=8) should be > 8 so inform messages also be passed to proces. OK. > 3. I'd suggest #define DEFAUL_PACKET_SIZE (300), some clients refuse > large packets silently. Yes. udhcp ignores packets > 300 bytes. > 4. couldn't find out why, but packet incoming from real ip addresses to > broadcast are ignored. 0.0.0.0 -> 255.255.255.255 - processed, 10.1.0.3 > -> 255.255.255.255 - ignored. I think it's a kernel thing. I'm at conferences all this week (yes, multiple), so I'll have less time for looking into these issues. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
dhcp server - some bugs ?
1. As i understand responses is hardcoded(preset) to discover and request. DHCP-Message-Type = ... in config file is ignored, so i can't respond to RELEASE, INFORM, DECLINE. Always is NAK. Response to request also could be NAK, not always ACK. It is possible respond to request with NAK if change RLM_UPDATED to rejected or something like this. Would be nice if dhcp server check for DHCP-Message-Type is set. 2. in dhcp.c ... when checking for know packet type. (packet->data[242] >=8) should be > 8 so inform messages also be passed to proces. 3. I'd suggest #define DEFAUL_PACKET_SIZE (300), some clients refuse large packets silently. 4. couldn't find out why, but packet incoming from real ip addresses to broadcast are ignored. 0.0.0.0 -> 255.255.255.255 - processed, 10.1.0.3 -> 255.255.255.255 - ignored. Harlads - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
On 22 Jun 2008, at 11:46, [EMAIL PROTECTED] wrote: Hi, FreeRADIUS is a gem, to be sure, and it continues to help me make money, but I've configured a lot of services over the years and the FreeRADIUS "documentation," frankly, sucks. No, the man pages are just fine. The problem here is the documentation often assumes a knowledge of the protocol / supporting RFCs. Either people are too stupid/ lazy to go out and find the information themselves, or they've lost the basic ability to learn things without being spoon-fed. hmm, FreeRADIUS makes you moneyand you get all the support from us, this list, and the free wiki etc for free. and yet you are happy to complain about the documentation without contributing to your source of income? nice. This guys crappy attitude aside, the wiki could use a bit of an overhaul. All the 1.* stuff needs stripping out or marking as such, because it's getting confusing. Could each take a few sections? It's a bit much for one person to tackle by themselves. Arran alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
Hi, > FreeRADIUS is a gem, to be sure, and it continues to help me make money, > but I've configured a lot of services over the years and the FreeRADIUS > "documentation," frankly, sucks. hmm, FreeRADIUS makes you moneyand you get all the support from us, this list, and the free wiki etc for free. and yet you are happy to complain about the documentation without contributing to your source of income? nice. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Kicking off billing scipt in accounting block
Chris wrote: > Perhaps users should be expected to go read source code comments to > figure out what's going on, too. Perhaps you should not take extreme positions in order to mock others. > FreeRADIUS is a gem, to be sure, and it continues to help me make money, > but I've configured a lot of services over the years and the FreeRADIUS > "documentation," frankly, sucks. Great! Write some, and submit it. Oh, wait... 99.9% of the people who complain that the documentation is horrible end up solving their problem, DON'T write documentation about it, and therefore DON'T submit anything back to the project. See? It's *your* fault that the documentation sucks. I've held up my end by writing much of the server, by writing reams of documentation in the config files, and by running the project for 10 years. What have *you* contributed? What do you intend to contribute? > This fact is "documented" by the lack of a "Documentation" tab or link > on www.freeradius.org. As always, patches are welcome. People who complain that the server "sucks" and then don't do anything about it can go read section 6 of the top-level README. It's directed at you. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
