On 23 Jan 2014, at 17:24, Alan DeKok <aland@deployingradius.com> wrote:

Phil Mayers wrote:

...

And the dictionaries. Maybe a special comment:

# dict version=x.x

That's possible. The simplest thing is to update a special value in the dictionary files. It's awkward, but really only necessary for every release.

Probably easiest just to add a VERSION keyword and check it's value against RADIUS_VERSION any time it's found in a dictionary. Just adding VERSION to share/dictionary will solve most versioning issues.

...

The answer is probably "no that's crazy" but I don't suppose ABI / symbol versioning helps here?

Some. The issue is that we make changes to internal data structures. So the old libraries aren't really compatible with the new binaries. The typical library versioning approach isn't fine-grained enough. And symbol versioning doesn't deal with changes to data structures.

Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On 23 Jan 2014, at 18:14, Alan DeKok <aland@deployingradius.com> wrote:

Arran Cudbard-Bell wrote:

...

Probably easiest just to add a VERSION keyword and check it's value against RADIUS_VERSION any time it's found in a dictionary.

Just adding VERSION to share/dictionary will solve most versioning issues.

Ugh. I'm not completely opposed to that solution, but it looks ugly to me.

The dict.c code shouldn't care much about the dictionaries, so long as they parse correctly. It's about separation of responsibilities.

If there's a parse error, well... it's always because someone screwed up the dictionary versions. Adding a more descriptive error won't help much here. The people who screw that up are likely to be the same people who don't read error messages.

Now the dictionary path is hardcoded there's probably not much point in doing this. I'm guessing the majority of versioning issues before were caused by people copying over old raddb/dictionary files into a new 3.0.0 config so it picked up the wrong dictionaries. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

Bjørn Mork wrote:

I'd say supporting old dictionaries is crucial, given that you do mass attribute renaming like this:

https://github.com/FreeRADIUS/freeradius-server/commit/a5ad82aecc194f5f55153...

Hmm... I'm generally against re-naming attributes. It breaks configurations, which is a bad thing. That being said, the dictionary format in 3.0 is largely compatible with the dictionary format in 0.1, and earlier Livingston. The only incompatibilities are new data types (integer64) and formats (TLVs, weird VSAs). So you can use older dictionaries with the new server. The problem is that some of the dictionaries are version-specific. We tweak them occasionally to fix data types, add new features, or new server-side attributes. It's a problem when people use old dictionaries with the new server.

The alternatives would be forcing simultanoues server upgrades or duplicated user databases.

Yes. Alan DeKok.

Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:

On 29 Jan 2014, at 13:35, Bjørn Mork <bjorn@mork.no> wrote:

...

Arran Cudbard-Bell <a.cudbardb@freeradius.org> writes:

...

I'm guessing the majority of versioning issues before were caused by people copying over old raddb/dictionary files into a new 3.0.0 config so it picked up the wrong dictionaries.

I'd say supporting old dictionaries is crucial, given that you do mass attribute renaming like this

Changes on that scale are only done during major releases, which occur once every 4-5 years.

I could be wrong, but I don't think renaming on that scale has ever been done before?

That change was made to master. master (the next major release branch) != v3.0.x (the current major release branch)

There was a less disruptive commit made for the erx/unisphere to v3.0.x which did not break compatibility.

Yes, I know.

I believe i've mentioned this already, in which case you're being an ass.

Didn't mean to be... It was just a striking example of why you should both expect and support copying over old raddb/dictionary files.

...

https://github.com/FreeRADIUS/freeradius-server/commit/a5ad82aecc194f5f55153...

The alternative is that vendor documentation moves away from the dictionaries. This makes it harder for new users to create working configurations.

Yes, this has become more and more clear as time went by and the ERX platform evolved. And then, when we thought that it had finally reached it's end-of-life, the vendor-id and VSAs were reused for BRAS services running on JUNOS... In retrospect, there is no doubt that the initial renaming of the "Unisphere-" attributes to "ERX-" was a big mistake. But at that point we had just seen Redstone become Unisphere, and further company and marketing name changes were not unlikely at all (and as you know, Juniper bought Unisphere less than a year later). The "ERX" name seemed more likely to stick than anything else. But who imagined that we would be using ERXes 13 years later, and that the JUNOS boxes we're replacing the ERXes with are using the same "ERX" VSAs? Not me, at least... Anyway, I don't object to the renaming at all. It's good to finally have this cleaned up, as long as we can choose *when* we want to switch dictionaries independently of switching FreeRADIUS versions. But I will object if you make incompatible dictionary format changes at the same time.

If there was a major change in the format, a tool would be included to automate conversion.

Such a tool will of course be necessary to migrate private dictionaries. But please don't mix attribute renaming with format changes. That's just not necessary. Bjørn