10 Jan
2003
10 Jan
'03
12:30 a.m.
On 09-01 23:08, Michael Graff wrote:
Using multiple domains in one server is pretty hard.
Was in 0.8.10, will be not in the next release.
The schema even fights with me. I can't have both
"graff" in the
"isc.org" domain and "graff" in the "flame.org" domain, for
instance,
at least with the same user name. I think the unique field there
should be a <user, domain> tuple. Additionally, all tables should
probably grow a domain column, and lookup() would take that as an
argument (defaulting to the host-portion of the URI, probably)
That also makes things easier on routing rules, and on aliasing, and
on user interfaces, at least IMHO.
Are there any plans to make this sort of thing much easier? If not, I
may decide to hack on it a bit and see what I come up with.
It's done already. The next release will be extended exactly this way.
The reason why we originaly implemented it this way was that it is easy
to compare just usernames. Domain comparision requires unification of
the domain which is slow and hard to do. So, in 0.8.10, you can still
have multiple domains but each domain must be kept in a separate table
(which is doable because save and lookup functions accept table name as
a parameter).
The drawback of this approach is that you must write complicated regexps
to distinguish domains in the script and call save or lookup with
appropriate table name. That means you have to modify the script and
restart ser if you want to add a new domain.
Somebody already complained about it, so we extended the tables and
unique key is now username, domain. That means, it is possible to store
multiple domains in a single table, there will be no need
to add new tables for new domains and adding new domains could be done
on the fly without restarting ser and changing the config file.
Digest authentication was also extended to support better handling of
multiple domains.
Of course, I'd also like to replace the scripting
language with
embedded Perl, but... :)
Why ?
Jan.