Sue D. Nymme has asked for the wisdom of the Perl Monks concerning the following question:

This is not a Perl question, per se... but I need to implement a solution for our company's internal home-grown apps, almost all of which are in Perl.

These programs all need to store configuration information—user preferences, user access restrictions, parameters by which to access this database or that, etc. Currently, these apps store their configuration in a hodgepodge of different ways: Most of them have their config parameters hardcoded into them, or hardcoded into a library; some use config files, some use database tables.

I'd like to unify and simplify this. I'd like to have one place on our network where applications can query and update their configuration settings, and where admins can change settings. But how?

A configuration file in a central location would be simple, but then anyone could read it, could see how to connect to the databases, etc. And where to put it?

But what's the alternative? Some dedicated configuration server that responds to SOAP queries over SSL?

  • Comment on Where to store configuration information?

Replies are listed 'Best First'.
Re: Where to store configuration information?
by CountZero (Bishop) on Aug 15, 2010 at 13:32 UTC
    As always: it depends; there is no single answer that will be "right" in all cases.

    Will everyone load these applications from a single network-based source (then you can have a single network-based configuration) or are these applications run from each user's box (then the configuration should probably be local too, esp. if they should still run without network access)? Perhaps you can implement a central repository with a local fall-back in case of network outage?

    Can you split general configuration settings from user settings, or should they all be in a central repository?

    Does the configuration contain items which must be kept secure or items which must be managed centrally because they are likely to change without prior notice?

    Can you trust your users not to hack their local settings?

    So many questions, so many different answers, so many different solutions. And remember TIMTOWTDI!

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

      Yeah, I figured there's no One True Way :-)

      The applications are run from various network locations, so I can assume that the user will be connected to the internal network. There aren't very many per-user preferences; mostly it's application configuration items, such as "where does this app find its database, and how does it connect?".

      There are definitely secure configuration items, such as database passwords. I can trust that the users aren't going to use network sniffing tools or password crackers (I think!), but I wouldn't want the data to be accessible in plaintext or in an easily-readable database location.

      Perhaps I should use a centrally-located configuration file that has some sort of basic encryption on it...

Re: Where to store configuration information?
by Utilitarian (Vicar) on Aug 15, 2010 at 19:21 UTC
    LDAP is the answer, it's awkward to get the hang of, but it's centralised, optimised for read, can be configured with failover and the user logs in as themselves and retrieves their settings. Also there is the handy Net::LDAP module to ease integration into applications.

    print "Good ",qw(night morning afternoon evening)[(localtime)[2]/6]," fellow monks."
Re: Where to store configuration information?
by shawnhcorey (Friar) on Aug 15, 2010 at 18:28 UTC

    I would set up a data hub. That way the applications would be separated from the servers. You could change the applications or the servers without the other being effected.

Re: Where to store configuration information?
by JavaFan (Canon) on Aug 15, 2010 at 21:37 UTC
    Configuration files, typically in (or under) /etc or /usr/local/etc would be my choice. For packages installing in /opt/package, /opt/etc and /opt/package/etc are acceptable as well. For applications where it make sense, they could first look for a configuration file in the current directory, the users home directory, and /etc, using the first one they find. Or the other ways around, using all the find (with later ones overwriting previous values). Sophisticated apps could allow the use of environment variables and/or command line switches to overrule which configuration file to use.

    I'd generally frown upon using configuration files that need to be retrieved over the network. Not only does that mean that if the service providing the configuration file isn't reachable, your applications cannot start (you're introducing a single point of failure), you'd still need a local configuration file anyway, because at least you need to configure where applications can find their configuration from.

    A configuration file in a central location would be simple, but then anyone could read it, could see how to connect to the databases, etc.
    That's what file permissions/ACLs are for.