Using multiple domains in one server is pretty hard.
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.
Of course, I'd also like to replace the scripting language with embedded Perl, but... :)
--Michael
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.
Jan Janak J.Janak@sh.cvut.cz writes:
It's done already. The next release will be extended exactly this way.
Cool, can I find this in the cvs repository?
Of course, I'd also like to replace the scripting language with embedded Perl, but... :)
Why ?
Because Perl is pretty good at pattern matching, and is a much more powerful language, and I don't like creating Yet Another Language.
--Michael
On 09-01 23:57, Michael Graff wrote:
Jan Janak J.Janak@sh.cvut.cz writes:
It's done already. The next release will be extended exactly this way.
Cool, can I find this in the cvs repository?
Not everything yet. Some changes are in my local snapshot only and I will commit them once I test them. Using CVS snapshot is not a good idea right now, many changes have been done recently.
It would be cool if you could help us with testing, do you want me to send you a message when all the changes are in the CVS and considered working ?
Of course, I'd also like to replace the scripting language with embedded Perl, but... :)
Why ?
Because Perl is pretty good at pattern matching, and is a much more powerful language, and I don't like creating Yet Another Language.
ser has been optimized for speed. Embedding perl would slow it down a lot. The language provided with ser is not powerful because it is used to glue things together only. If you need something complex, it should be implemented as a module.
Jan.
At 12:08 AM 1/10/2003, Michael Graff wrote:
Using multiple domains in one server is pretty hard.
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.
You need to maintain multiple user tables, one for each domain. Just copy "location" in mysql to "location_otherdomain" and use
if (uri=~"...otherdomain...") lookup("location_otherdomain");
I admit it is too manual -- the next ser release will have one table keyed by pair username-domain.
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)
We will have the domain name as part of the mysql table. and lookuop will search by both username and the domain name. The domain name will have to be canonized first, as for example some UAC put IP address in URI, which would not match then.
-Jiri
-
Jan Janak -
Jiri Kuthan -
Michael Graff