ZoneMinder Forums

Hi,

I'm just wondering why the settings are done during compilation, and not post-install in a config file such as /etc/zoneminder.conf ?

I ask, because the during-install configuration is an arse when it comes to package managers. I could provide a dummy conf, but why do is this way at all? Are some of the configs hard coded into the zoneminder binary? If so, why?

Cheers

It's primarily for speed, as the same configuration gets used in C++, perl and php files and having to go through and parse a file for settings each time would probably not be as quick, there's also in place substitution done in various places such as database schemas and having help etc.

Having said that the only options you need to specify at build time (and are thus hardcoded) are the database details, especially since parsing a .conf was a pain in the arse in C++ (before I discovered the regexp library). Everything else is read from the DB and you can fill in from the Options page on the web interface. A lot of it is evolutionary though rather than any grand plan. As ZM runs as an unpriveliged user the database seemed a good place to keep everything.

You can build everything with default options without intervention if you just run

zmconfig.pl -noi # This uses all default options and substitutes DB stuff into the schema
mysql mysql < db/zmschema.sql # Create the database
zmconfig.pl -noi # Import the config into the database
make etc

The only other thing you'd need to do would be to 'grant' access to your DB users if you decided to keep the defaults though that could easily be scripted.

I'm pretty keen on getting ZM into a package so if you have any suggestions I'd be pleased to hear them. I don't have any particular objection to a .conf file but it's not likely to be a priority so if I can get ZM packaged as it is for now it would be useful.

Phil,

Hi Phil,
I've pondered the idea of a ZM package quite a bit. It seems to me that the biggest hurdles involve the need to create a database and grant privileges when a target system my have the MySQL server already locked down with a root password.

Have you ever considered switching to SQLite? The sqlite database is simply a file, and there is no need for a server. The database file could be preconfigured with defaults and included in the package. This may be a step toward lightening up the whole system as well.

This may be far more complicated than I realize. Just thought I would mention it.

Best regards,
Ross

I've spent quite a lot of time playing with a migration to PostgreSQL and hit quite a few places where there are dependencies on particular MySQL features (that I didn't know were MYSQL specific at the time) like enums and sets etc. That's been a bit tricky to get around and I suspect I'll have the same issues with SQLite.

The other thing is that it took me quite a while to get the indexing on the tables optimised so queries on the events table for instance didn't take hours to run. If SQLite has good indexing support then that might not be a problem but if not then it will be. I wrote an app for a client of mine a while back in perl. Originally I used a perl database module based on CSV files for convenience but that gradually bogged down as the tables grew and I moved it to MySQL which cut 95% off the runtime. I want to make sure I don't go the other way with ZM!

Phil,

Makes sense...

Is there any way I can "install" zmconfig.pl on the user's system, for them to run after the package installs - to set up the database parameters again. I'm guessing not, if the parameters are hardcoded into the binaries.

This is for a Gentoo ebuild, which absolutely must be non-interactive during install, but may have a user-runnable interactive configuration step, post-install.
Basically - is there any way to change database options after compiling?

Cheers,
MAL

I'm going to have a serious look at this today, it's possible that things like the DB parms could be moved out of the compilation stage and into a config file.

By the way I know there was an eBuild of ZM done a while back but I can't remember who did it or how they got around this.

Phil,

It was me :)

The way it was avoided was to provide some external variables that a user could set with database username and password in, that in turn the ebuild used during compilation.

Too many users simply didn't know about them, and then complained when they had to re-install the package after setting them. That method doesn't follow the ethos of the Gentoo package system anyway, so I'm looking for something better.

If you can update here with any thoughts/ideas you have, that'd be great.

Thanks,
MAL