Re: ispman.conf - proposal to split in two files

Joerg Delker <[email protected]> Thu, 01 Jun 2006 00:23:21 +0200
Newsgroups gmane.comp.isp.ispman.devel
Message-ID <[email protected]>
Andreas John wrote:
> Hello!
> 
> After Upgrading ISPMan I recently was plagued by the annoyance that the
> last lines of ispman.conf (the only file I didnt upgrade) changed with
> the version (I mean the stuff beginning from
> $Config->{'ispmanUserObjectclasses' ...)
> 
> So avoid hassles when upgrading I would like to propose to split the
> config file:
> 
> I tried that like this:
> 
> ispman.conf:
> [....]
> # Objectclasses for different objects
> do 'ispman.versiondependentvars';
> 1;
> 
> And 'ispman.versiondependentvars';
> # Objectclasses for different objects
> $Config->{'ispmanUserObjectclasses'}=["posixAccount",
> "ispmanDomainUser", "radiusprofile"];
> $Config->{'ispmanGroupObjectclasses'}=["posixGroup",
> "ispmanDomainUserGroup"];
> .....
> 
> I dont see a reason why those vars should be in the conf file - does
> anyone change that?

Hi Andreas,

after thinking this over, I need to answer YES to that.

Especially the *Objectclasses are of great value to those who have 
extended their LDAP with additional classes, which ISPMan should be 
aware of (like me for example ;-)

One could argue about the ispmanVarSort hashes, because there a 
potential other ways to handle this (like in LDAP), but currently that's 
no option (for me) to implement as this would require some in-depth code 
changes.
So for now, I consider them valid config options, too. They allow you to 
sort and extend your LDAP stored configs.

I agree that it is a bit awkward when applying updates, but that's very 
much the same with so many other software packages, and can not really 
avoided.

So I would rather leave the ispman.config as it is.

Joerg
smime.p7s (application/x-pkcs7-signature, 3.2 KB) - not displayed