Configuration files

[keyslapper]

Ok Monks. Go easy on me here, I'm still a wannabe.

Here's my problem: I want a highly flexible, yet secure way to configure a script. One of the requirements is the ability to assign values to arrays and hashes.

Problem: out of the box modules only (Perl versions 5.005_03 - 5.8.5). No installing YAML, Config::Inifiles, whatever.

Naturally, I've searched here and in The Cookbook for suggestions, and the out-of-the-box requirement pretty much shoots down most of the excellent suggestions found here.

The Cookbook suggests using an actual perl script to set configurable vars and suck it in with do().

I'm sensing all kinds of security concerns going off here if these are user configs, so I've ensured the script is not installed with the stickybit set and required within the script that the config NOT be group or world writeable or executable. I've also used strict in the script, and limited only configurables to "our" scope, all others to "my" scope. Defaults are naturally set prior to doing the config, allowing overrides by the user. Anything that should not be modified by the user is set post config read.

Remembering the out-of-the-box requirement, can anyone point out any false sense of security, unfounded concerns, better ways to handle this, etc.?

Thanks all.

[gaal]

YAML and most Config:: modules from CPAN are pure Perl. You can use them from your script private directory (see use lib) without installing anything in a system location.

[keyslapper]

Yes, but as I neglected to mention initially, at least one of the scripts in question will be a widely distributed script under the control of sysadmins with their own concerns. It has to be system only perl or a reinvented wheel.

I will probably check the YAML and Config:: modules to see if any are already used by the projects my other script is geared toward, but I do need the most secure system only method I can get hold of.

[gaal]

How does its being distributed affect this? Presumably the admins have measures to untar a file remotely, yes? Just place the module files in the directory the script is in and have people run from there or set their perl include paths.

But I agree with what other people have said about how not being able to install stuff is based on the wrong reasons. In the general case you *will* eventually want to use other people's module -- or your own, in .pm files -- and it is will cost your employers money not to allow you to do that.

[ambrus]

Well, the YAML module is pure perl, (and it seems to have no AutoLoader business), so it would probably be safe to just copy its source to your script. It's not very big either, the whole YAML module is 33K long, and if you want to read yaml only (not write), a bit fewer might suffice. I haven't tried this, so I can't promise anything.

(Or install ruby, which has yaml out of box.)

[keyslapper]

That might be an option. Of course, the script these requirements were written over is less than 10K, but I'm sure looking at the YAML code will offer some useful methods.

And learning from someone else's code is always a good option :)

[qq]

You could do worse that Config::Tiny. Its INI file format, which is familiar to many, pure perl, and very short. So you include it in the distribution, or copy/paste it in.

[The Mad Hatter]

Why can't you install modules? There are few real reasons for not installing them and instead reinventing the wheel.

[keyslapper]

One of the scripts in question is being run on offsite systems, which have a default perl config (in house Solaris packaged perl build) that has a very limited number of additional modules. The last time we got the package rebuilt with an additional module, it took 6 months from request to distribution - and that was a critical requirement. Anything not considered critical would be more trouble than it's worth from my POV.

I suspect that's one of the few reasons for reinventing the wheel :)

One of the other scripts I'm considering for this may be better to use a different method, since I'm considering contributing it to the SpamAssassin project - meaning it would probably be best to use Config::Inifiles or YAML (XML would be a real learning curve at this point, but not something I'm opposed to).

[keyslapper]

Ok, remembering I'm a newbie here, correct me if reponding to my own post like this is bad form . . .

all responses to date have been very enlightening - and greatly appreciated!

It has become very clear that the inability to install modules is certainly not an obstacle to actually using them, enven in the restrictive environment I am writing for. The only hurdle is actually choosing the best one for the project at hand.

So, what about thoughts on the do() method I described initially? Are there any real reasons NOT to use this method?

Thanks again!

[BUU]

1) Security. Any code placed in the config file will be executed with the same permissions as the script itself. This may or may not be a problem.

2) Ease of use. Perl typically isn't the easiest language to use for simple configuration options, unless you're already fluent in it. Theres no real reason to require the some what complicated ( compared to yaml, config::simple, etc ) syntax of Perl unless you really need it's power. And for a simple config file, it doesn't sound like you do.

[keyslapper]

1) I don't think this is a problem. I'm pretty diligent about checking the permissions of the config to ensure the permissions don't allow anyone other than the intended user to make changes to it. The config must be executed with the same permissions as the calling script, so that's the desired affect.

2) This one comes down to situation. Some of the stuff I've considered this for, I'm only doing because it's my own system and I'm playing admin for those users I wouldn't want to ask to write any config, however simple (no good making Mom learn Perl when she struggles with email :).
In other situations, I expect those installing and configuring the utility to be at least perl initiates if not adepts - and I comment my packaged configs almost to the point of TMI. Regardless, I only use it for tools others have to manage when I'm in an environment where I am justified in my opposition to administration by monkeys. Even then, I try to comment enough to give even a monkey no excuse for screwing it up.

* So, it appears the only real downside is the extra (minor) hoops I have to jump through to ensure the config can't be tampered with by anyone other than the calling userid, and the complexity left on the shoulders of the person actually configuring the tool.

Am I right?

* Another question is one of scope. I mentioned that I always use strict in these scripts, and limit all vars to "my" scope except those intended to be overridden by the config, which are put under "our" scope. This is one thing I'm not terribly confident of my understanding. Can the config modify the values of "my" scoped vars, or is it limited to modifying "our" scoped vars?

Of course, I know that my current technique doesn't prevent the config from running off on its own tangent during the config process.

Thanks again!

[superfrink]

There have been several posts about using perl modules. I fully understand that there are times when it is a pain to get "extra" modules installed. Depending on the situation I might suggest finding another hosting company. I suspect this is not an option for your situation though.

I still really find CPAN to be one of the most compelling reasons to use Perl. I have never worked in a language with so many components at my fingertips. Being able to use HTTP::Proxy and MIME::Entity have saved me hours of development and debugging time. That translates directly into money for my employer.

I really feel that if a system administration department does not have the time to install modules for developers then the sys-admin department is not being given enough resources to provide their service to the parent organization. Or there are other problems such as a lack organization inside the department.

I have been both a sysadmin and a developer. I'm not trying in any way to bash on anybody but sometimes it seems we can forget why we are working where we are. The sysadmins do have the right to protect the systems and keep the systems running and stable. But it is also the primary role of the sysadmins to provide a system that the developers can work in.

I did not start with the intention of ranting but saying "we won't install a module for you to do your job more efficiently" is the same as saying "I know you are my customer and I know you want to buy something to make your life easier/better but I'm not going to sell it to you because it means more work for me". Maybe it's valid and maybe it's not but doing so stresses people all around.

[toma]

Persistence for options? has discussion on many approaches to solve a similar problem.

[chanio]

I understand that you are asking for experience, more than a technical answer.

I remember being scared of installing modules before using CGI::Application. This module makes you create your own module to work with it. You can't use it without calling your own module that is based on CGI::Application.

After loosing my fear on installing modules, I now, see them as a way of saving time in testing it all. And I am able to focus on the results.

I just install them where my script is, and they work the same!

If you rely on a module, you might rely on it's security also.