rfc2865 and RADIUS-LDAPv3.schema inconsistencies?
hi developers! i had a closer look at RADIUS-LDAPv3.schema (rev.1.9.6.1) and compared it with rfc2865 and there seem to be some "inconsistencies": some attributes which may contain zero or more values according to rfc2865 (http://rfc.net/rfc2865.html) are defined as SINGLE-VALUE in the schema file. as far as i understand the rfc the following values (the numbers in brackets refer to the section nr. and page) may contain more values: Filter-Id <-> radiusFilterId (5.11, p.36) Framed-AppleTalk-Network <-> radiusFramedAppleTalkNetwork (5.38, p.58) Framed-Compresion <-> radiusFramedCompression (5.13, p.37) Login-IP-Host <-> radiusLoginIPHost (5.15, p.38) the attribute NAS-IP-Address (radiusNASIpAddress) is described (in rfc) to be allowed to be present zero or one time (see 5.4, p.29, and 5.44: table of attributes, p.63), but is not defined as SINGLE-VALUE in the schema file. i am not using these values right now so i don't know if this differences can cause problems, i just came across this by testing nicolas' patch for bug 261 some time ago and finally had some time and mood to read the rfc. of course i also do not know if these differences are intended, i am just wondering about them! ;-) with best regards, markus -- Markus Krause email: krause@biochem.mpg.de Computing Center Tel.: 089 - 89 40 85 99 Group Lottspeich / Proteomics Fax.: 089 - 89 40 85 98 --------------------------------------------------------------------- This message was sent using https://webmail.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de
Markus Krause wrote:
i had a closer look at RADIUS-LDAPv3.schema (rev.1.9.6.1) and compared it with rfc2865 and there seem to be some "inconsistencies": some attributes which may contain zero or more values according to rfc2865 (http://rfc.net/rfc2865.html) are defined as SINGLE-VALUE in the schema file.
Indeed. I also think it's weird.
of course i also do not know if these differences are intended, i am just wondering about them! ;-)
I wonder about them, too ;-) I've made a pass on all files under the doc/ directory, and pulled the changes exactly like they were in CVS head. That's why the file has been modified two days ago. If nobody is against the idea, I'll commit in CVS the list of changes you suggested to match with RFC 2865. I also note there are four different LDAP schemas in CVS head. I have no idea why we need so many of them. RADIUS-LDAP.schema RADIUS-LDAPv3.schema RADIUS-LDAP-iPlanet.schema ldapv3-iplanet-schema.ldif -- Nicolas Baradakis
Zitat von Nicolas Baradakis <nbk@sitadelle.com> [snipped]:
I also note there are four different LDAP schemas in CVS head. I have no idea why we need so many of them.
[sequence changed] RADIUS-LDAPv3.schema this seems to be used for recent openldap versions ...
RADIUS-LDAP.schema as far as i know this one is to be used for netscape directory server e.g. with solaris or some older linux distros (found one on an old redhat server).
RADIUS-LDAP-iPlanet.schema for suns version of an ldap server (called sun one directory server, the former iplanet directory server)
ldapv3-iplanet-schema.ldif this is for suns version of an ldap server which supports loading of schema files as ldif files while running
the later three file also contain the same "inconsistencies", except that radiusNASIpAddress seems to be missing ... so it seems that at least the last two files are needed as there may be someone who uses freeradius with sun-os/direcrory servers the file RADIUS-LDAP.schema looks more weired to me, the formatting is quite strange (just pulled from cvs): * a lot whitespaces before "single" in many lines (or single in seperate line starting with different numbers of spaces) * round line 119 there is no whitespace between "single" and "attribute". * a lonely "e" in line 124 i really wonder if this file does work! but i am not used to the format so can't say more about it, sorry ... with best regards, markus
-- Nicolas Baradakis
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Markus Krause email: krause@biochem.mpg.de Computing Center Tel.: 089 - 89 40 85 99 Group Lottspeich / Proteomics Fax.: 089 - 89 40 85 98 --------------------------------------------------------------------- This message was sent using https://webmail.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de
Markus Krause wrote:
the file RADIUS-LDAP.schema looks more weired to me, the formatting is quite strange (just pulled from cvs):
* a lot whitespaces before "single" in many lines (or single in seperate line starting with different numbers of spaces)
* round line 119 there is no whitespace between "single" and "attribute".
* a lonely "e" in line 124
Indeed. It's a mess.
i really wonder if this file does work! but i am not used to the format so can't say more about it, sorry ...
If this file is (1) obviously broken, (2) designed for an obsolete LDAP server and (3) nobody on this list know how to fix it, I'd vote to just delete it from the CVS. (only if nobody is against the idea, of course) -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
If nobody is against the idea, I'll commit in CVS the list of changes you suggested to match with RFC 2865.
Consistency is good.
I also note there are four different LDAP schemas in CVS head. I have no idea why we need so many of them.
At the minimum, we should probably document what they are. Since we have a number of SQL schemas too, maybe we want to put all of the schemas under doc/? Maybe doc/schema? They can then be installed in ...share/freeradius/schema? Just throwing out ideas. Alan DeKok.
Alan DeKok wrote:
Since we have a number of SQL schemas too, maybe we want to put all of the schemas under doc/? Maybe doc/schema? They can then be installed in ...share/freeradius/schema?
Just throwing out ideas.
I think it would be nice. For now the SQL schemas are not installed at all by the makefiles. In the Debian package for example, Paul has gathered all these orphan files under /usr/share/doc/freeradius/examples. We might have a subdirectory doc/schema or doc/something in the source tree, and move the files here with simpler names: doc/ldapv3-iplanet-schema.ldif -> doc/schema/iplanet.ldif doc/RADIUS-LDAP-iPlanet.schema -> doc/schema/iplanet.schema doc/RADIUS-LDAP.schema -> /dev/null doc/RADIUS-LDAPv3.schema -> doc/schema/openldap.schema src/modules/rlm_sql/drivers/rlm_sql_mysql/db_mysql.sql -> doc/schema/mysql.sql src/modules/rlm_sql/drivers/rlm_sql_oracle/db_oracle.sql -> doc/schema/oracle.sql src/modules/rlm_sql/drivers/rlm_sql_postgresql/db_postgresql.sql -> doc/schema/opstgresql.sql /dev/null -> doc/schema/mssql.sql It's only a suggestion... any other idea? -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I think it would be nice. For now the SQL schemas are not installed at all by the makefiles. In the Debian package for example, Paul has gathered all these orphan files under /usr/share/doc/freeradius/examples.
That's OK. Technically they're not examples if they're required, but if/when we make the SQL queries more configurable, the existing schemas can be examples.
We might have a subdirectory doc/schema or doc/something in the source tree, and move the files here with simpler names:
Maybe just doc/examples. We can put examples of the configuration files there, too. i.e. examples of how to configure X, rather than text describing how to do X. Alan DeKok.
On Sun, Jan 29, 2006 at 08:05:51PM -0500, Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I think it would be nice. For now the SQL schemas are not installed at all by the makefiles. In the Debian package for example, Paul has gathered all these orphan files under /usr/share/doc/freeradius/examples.
That's OK. Technically they're not examples if they're required, but if/when we make the SQL queries more configurable, the existing schemas can be examples.
I figure they're examples because you get things like the pg voip billing stuff (that I've just noticed isn't being shipped in that directory); and because you don't _need_ to use them. I doubt anyone's _actually_ going to start without them, but I myself have pretty much emptied the supplied rad* (except radacct) tables because I kept running out of space in my %{sql:} translations, and wasn't yet a member of the stored-procedure elite. (I realise it won't scale well. If I wanted to scale, I'd migrate off mysql anyway... some kind of caching LDAP setup maybe?)
We might have a subdirectory doc/schema or doc/something in the source tree, and move the files here with simpler names:
Maybe just doc/examples. We can put examples of the configuration files there, too. i.e. examples of how to configure X, rather than text describing how to do X.
I'd have thought those should be one and the same, largely...? -- ----------------------------------------------------------- Paul "TBBle" Hampson, Bsc, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
participants (4)
-
Alan DeKok -
Markus Krause -
Nicolas Baradakis -
Paul TBBle Hampson