[freeside-devel] Configuration of domains

[ivan]

On Fri, Apr 07, 2000 at 10:33:42AM -0500, David Morton wrote:
> I ran into another snag...
> 
> I get errors with this bit of code in svc_domain.pm line 37...
> 
> @nameservers=map {
>     /^\s*\d+\.\d+\.\d+\.\d+\s+([^\s]+)\s*$/
>       or die "Illegal line in $internic/nameservers";
>     $1;
>   } @ns;
>   @nameserver_ips=map {
>     /^\s*(\d+\.\d+\.\d+\.\d+)\s+([^\s]+)\s*$/
>       or die "Illegal line in $internic/nameservers!";
>     $1;
>   } @ns;
> 
> well, duh, because I haven't defined that configuration yet. :)
> Why/when is this callback called?

See the FS::UID manpage.  Callbacks are called at the end of
&adminsuidsetup (which is itself called at the end of cgisuidsetup).  

This is used by library code, such as svc_acct.pm, to load any
configuration values it needs.  Library code can't load configuration
values with regular code at the beginning or a BEGIN {} block, because the
user that determines which configuration to load isn't known until later. 
Thus the provision for libraries to register callbacks with FS::UID to be
run once the user is known.

Currently, you set a value in the %FS::UID::callback hash with a coderef
of the code you want to execute, but this was bad design and will in the
future be changed to a subroutine to which you pass your coderef to
register it. 

> Can its call depend on whether or not a configuration exists? 

Nope.

> I thought I had a new format for configuration files all figured out,
> until I discovered what this callback was doing, with subdirectories in
> the filename.
> I think I can hack around it, but it looks ugly.
> 
> where before you had a filename as such:
> 
> my($internic)="/registries/internic";
> $tech_contact = $conf->config("$internic/tech_contact");
> 
> I put it into a section in my ini file:
> 
> [/registries/internic]
> tech_contact=joedokes at osprey.net

That's supposed to be a NIC handle, not an email address; see
<http://www.sisd.com/freeside/docs/config.html>.

> I think what I'd like to do is add a third parameter to FS::Conf->config
> to support the "section" of configuration.  So then the call above would
> become:
> 
> $tech_contact = $conf->config("tech_contact", $internic)

Hmm; no, that's definatly not right. :/  You don't want sections in the
configuration file each with the name of a registrar.

However, it isn't necessary to preserve strict backwards-compatability for
the domain template submission stuff stuff; the original intent was to
support multiple registries via multiple sets of email templates and
information, but as the new registries all require different registration
methods, it's going to be require the ability to plug in code bits as
well.

-- 
meow
_ivan