MySQL table definition for RADIUS accounting data and duplicates
I ended up needing to modify the MySQL table for RADIUS accounting data to mark the AcctSessionId and AcctUniqueId fields as UNIQUE. I was having problems with receiving duplicate accounting records, showing users logged in multiple times who actually were not. Does this seem like a good idea to anyone else? Is there ever a legitimate situation where the AcctSessionId field might end up with the same value twice? -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
checkrad script things
After looking at the checkrad script, I noticed a few minor things. Namely: - For several RAS server types, the script doesn't actually look up username/password (or SNMP community ID) info from anyplace. - The script only looks in the naspasswd file, which I thought was deprecated. Shouldn't it look in (and of course, parse) clients.conf, at least? I'm thinking I'll probably fix these, because I'd like to be able to use checkrad. -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SIGTERM somewhere in SQL accounting (using MySQL)
On Mon, Feb 24, 2003 at 10:40:13AM -0600, Chris Parker wrote: > Use GDB it's much handier at finding the cause of the sigterm than > strace. Actually, it pointed me in the right direction anyway - the checkrad script tried talking to the RAS server via SNMP, and got no response, and died of SIGTERM, for whatever reason knocking radiusd over with it. Anyone have any insight on that? -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
SIGTERM somewhere in SQL accounting (using MySQL)
For some reason, I've started to see FreeRADIUS die of a SIGTERM somewhere in its SQL accounting code. It's going something like this: radius_xlat: 'USERNAME' rlm_sql (sql): sql_set_user escaped user --> 'USERNAME' radius_xlat: 'SELECT COUNT(*) FROM radacct WHERE UserName='USERNAME' AND AcctStopTime = 0' rlm_sql (sql): Reserving sql socket id: 1 radius_xlat: 'SELECT RadAcctId, AcctSessionId, UserName, NASIPAddress, NASPortId, FramedIPAddress, CallingStationId, FramedProtocol FROM radacct WHERE UserName='USERNAME' AND AcctStopTime = 0' Terminated I'm running it now with an strace, to see where it's dying more specifically. I'm using the code from a CVS snap from 10 days ago (20030214), if that helps to narrow it down. -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Patch for LDAP URI support (at least with OpenLDAP libraries)
On Sat, Feb 22, 2003 at 11:40:24AM +0200, Kostas Kalevras wrote:
> Where's the patch?
Heh. Sure enough, I forgot to attach the patch. It's attached this time,
I swear! :)
--
Derrik Pates
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--- /root/radiusd/src/modules/rlm_ldap/rlm_ldap.c Fri Jan 24 08:35:30 2003
+++ radiusd/src/modules/rlm_ldap/rlm_ldap.c Fri Feb 21 20:19:28 2003
@@ -186,6 +186,9 @@
typedef struct {
char *server;
+#ifdef LDAP_API_FEATURE_X_OPENLDAP
+ char *server_uri;
+#endif /* LDAP_API_FEATURE_X_OPENLDAP */
int port;
int timelimit;
struct timeval net_timeout;
@@ -223,6 +226,9 @@
static CONF_PARSER module_config[] = {
{"server", PW_TYPE_STRING_PTR, offsetof(ldap_instance,server), NULL,
"localhost"},
{"port", PW_TYPE_INTEGER, offsetof(ldap_instance,port), NULL, "389"},
+#ifdef LDAP_API_FEATURE_X_OPENLDAP
+ {"server_uri", PW_TYPE_STRING_PTR, offsetof(ldap_instance,server_uri), NULL,
NULL},
+#endif /* LDAP_API_FEATURE_X_OPENLDAP */
/* wait forever on network activity */
{"net_timeout", PW_TYPE_INTEGER, offsetof(ldap_instance,net_timeout.tv_sec),
NULL, "10"},
/* wait forever for search results */
@@ -320,11 +326,17 @@
return -1;
}
- if (inst->server == NULL) {
- radlog(L_ERR, "rlm_ldap: missing 'server' directive.");
- free(inst);
- return -1;
+#ifdef LDAP_API_FEATURE_X_OPENLDAP
+ if (inst->server_uri == NULL) {
+#endif /* LDAP_API_FEATURE_X_OPENLDAP */
+ if (inst->server == NULL) {
+ radlog(L_ERR, "rlm_ldap: missing 'server' directive.");
+ free(inst);
+ return -1;
+ }
+#ifdef LDAP_API_FEATURE_X_OPENLDAP
}
+#endif /* LDAP_API_FEATURE_X_OPENLDAP */
inst->timeout.tv_usec = 0;
inst->net_timeout.tv_usec = 0;
@@ -1352,12 +1364,26 @@
int ldap_errno = 0;
LDAPMessage*res;
- DEBUG("rlm_ldap: (re)connect to %s:%d, authentication %d", inst->server,
inst->port, auth);
- if ((ld = ldap_init(inst->server, inst->port)) == NULL) {
- radlog(L_ERR, "rlm_ldap: ldap_init() failed");
- *result = RLM_MODULE_FAIL;
- return (NULL);
+#ifdef LDAP_API_FEATURE_X_OPENLDAP
+ if (inst->server_uri) {
+ DEBUG("rlm_ldap: (re)connect to %s, authentication %d",
inst->server_uri, auth);
+ if (ldap_initialize(&ld, inst->server_uri) != LDAP_SUCCESS) {
+ radlog(L_ERR, "rlm_ldap: ldap_initialize() failed");
+ *result = RLM_MODULE_FAIL;
+ return (NULL);
+ }
+ }
+ else {
+#endif /* LDAP_API_FEATURE_X_OPENLDAP */
+ DEBUG("rlm_ldap: (re)connect to %s:%d, authentication %d",
inst->server, inst->port, auth);
+ if ((ld = ldap_init(inst->server, inst->port)) == NULL) {
+ radlog(L_ERR, "rlm_ldap: ldap_init() failed");
+ *result = RLM_MODULE_FAIL;
+ return (NULL);
+ }
+#ifdef LDAP_API_FEATURE_X_OPENLDAP
}
+#endif /* LDAP_API_FEATURE_X_OPENLDAP */
if (ldap_set_option(ld, LDAP_OPT_NETWORK_TIMEOUT, (void *)
&(inst->net_timeout)) != LDAP_OPT_SUCCESS) {
radlog(L_ERR, "rlm_ldap: Could not set LDAP_OPT_NETWORK_TIMEOUT
%ld.%ld", inst->net_timeout.tv_sec, inst->net_timeout.tv_usec);
}
Patch for LDAP URI support (at least with OpenLDAP libraries)
I've worked up a small patch that works with OpenLDAP features to support the use of LDAP URIs for referring to LDAP servers instead of specifying by host/port. This will work easily for ldap://, ldaps:// and ldapi:// (LDAP over IPC) URIs. I've plugged this in and tested the module (with CVS code from ~7 days ago), and it's working well. I'm checking out the Netscape/iPlanet LDAP C API documentation, but it doesn't appear to provide the ldap_initialize() call that the OpenLDAP libraries do. To use this module, just patch it in. No makefile changes are necessary. To use an LDAP URI, just add a line like: server_uri = ldap://localhost/ or server_uri = ldapi:/// to the ldap config section in your radiusd.conf. By default, its value will be NULL, so the server and port options will take effect instead. If you specify anything for server_uri, however, it will take precedence. Also, if you wish to use an ldapi:// URI, check to see that your slapd has been started with the -h "URI list" option. If one of the URIs specified points to a particular path for the LDAP socket file, specify it like this: ldapi://%2fvar%2frun%2fldapi/ See the OpenLDAP docs for additional info. -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rlm_ldap URI support?
I'd rather see LDAP URIs used instead of specifying the server hostname and port separately - in no small part because in that case, it's easy to support LDAP over UNIX domain sockets, which (in my experience) provides lower overhead when doing lots of queries (which is hopefully going to be the case with the setup I'm working on). Does anyone have a patch? If not, does anyone know if opening by URI is an OpenLDAP-only feature? If no one has a patch, I can probably sort it out myself. -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Setting Realm attribute based on NAS-IP-Address?
On Fri, Feb 21, 2003 at 12:18:00PM -0600, Chris Parker wrote: > DEFAULT NAS-IP-Address == a.b.c.d, Proxy-To-Realm := "foobar" >Fall-Through = Yes Excellent. And this it correct even though I'm not proxying, but the realm is local? -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Setting Realm attribute based on NAS-IP-Address?
I'm presently responsible for setting up a system using a combination of OpenLDAP, MySQL and FreeRADIUS to provide centralized RADIUS service hosting for some of our customers. The only problem I haven't managed to surmount so far is customers who are unable (or unwilling) to get their customers to use [user]@[realm] as their login name for the RAS servers they are using. If I can figure out how to force the realm to the appropriate one based on the NAS-IP-Address field where the realm would otherwise be NULL, I can work around this. Does anyone know what the best way to do this would be? If this can be done with a stanza in the users file that ends with 'Fall-Through = Yes', how should it be phrased? Thanks for your help. -- Derrik Pates [EMAIL PROTECTED] [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
