ZoneMinder Forums

tibetfreedom wrote:is your performance patch rolled into the new release ?

mastertheknife wrote: I also used to use Ubuntu as my desktop OS, but i am much more familiar with RHEL\Centos (especially with yum\rpm over apt\deb) so i am now a Fedora 19 user
You should give that a try, its great!

RHEL\CentOS\Fedora by default ship with selinux enabled, and it pretty much just works. Now and then need to change the default contexts for certain paths with semanage but other than that, its very good and there should be no reason to disable it just for ZM. We will just create a policy module for ZM. A policy module basically defines what our service is allowed to access (assuming it has the correct permissions to access in the first place) and what default access we would like to deny. Pretty much all policy modules in RHEL\CentOS for services at this moment only use the "type" field for controlling access, by having the services run on a special type that can only access what its allowed to access.

The first thing we need is to define types. I thought of least access model where we have type for everything, e.g. zm_exec_t for zm processes and scripts, zm_conf_t for config files such as zm.conf, zm_log_t for files in /var/log/zm, etc, but i believe that wont be possible because the CGI scripts won't be able to access those types because CGI scripts run as httpd_sys_script_exec_t. If we use another type for CGI scripts, apache won't be able to access those CGI files. And if we permit in the policy to allow access from httpd_sys_script_exec_t, every cgi script will be able to access ZM specific stuff, so no point.
So, we can use a minimal approach for now, just to be able to keep selinux in enforcing mode.
Types:
- All executables, including cgi scripts, should their default types. Same goes for logs and everything else.
- Events folder and other zm dynamic content that should be shared between multiple services (such as images/ folder which contains previews for zone editing) - should use public_content_rw_t because i can't think of any easy way of providing access to both ZM and apache.
Access:
- By default, all the default types already have access to other default types.
Ports:
- As far as i remember, ZM doesn't listen on any port, so no need for ports in the policy
Booleans:
- Cant think of any that we might want right now.

Not too difficult it seems

knnniggett wrote: UPDATE: OK, you got me interested in solving this. Looks like someone posted a basic policy here:
http://www.zoneminder.com/wiki/index.ph ... nux_Policy

I added local_zoneminder.te to the rpm package and then configured the rpm %post script to generate and install the selinux policy when the rpm is installed on the target machine. Done!

tibetfreedom wrote:I wish to install the FFMPeg library etc is all this as difficult as it was ? or is it easier now ?

knnniggett wrote:

tibetfreedom wrote:I wish to install the FFMPeg library etc is all this as difficult as it was ? or is it easier now ?

Well, that depends on how you plan to do the installation.
If you wish to make install from source the traditional way, the installation process is the same as it always has been.
ffmpeg will always be tricky due to the rate at which the source code changes.

However, depending on what distro you choose to run on, you have RPM/SRPM options and Ubuntu users have the option of Kylejohnson's puppet module.

tibetfreedom wrote:

knnniggett wrote:

tibetfreedom wrote:I wish to install the FFMPeg library etc is all this as difficult as it was ? or is it easier now ?

Well, that depends on how you plan to do the installation.
If you wish to make install from source the traditional way, the installation process is the same as it always has been.
ffmpeg will always be tricky due to the rate at which the source code changes.

However, depending on what distro you choose to run on, you have RPM/SRPM options and Ubuntu users have the option of Kylejohnson's puppet module.

Is the puppet module good ?
currently using Mageia which installs FFMPeg by default with zone minder… but it seems unstable with BTTV cards specifically the cloned BTTV 8 chip 8 channel card...

jimm01 wrote:Great work on the performance improvements, testing on 1.26 so far indicates the figures obtained are a positive step forward.
It would be great to be able to limit the capture size to a particular size and then scale to whatever in the monitor. Lots of work, but overheads may not be wothwhile,or limit the capture size dependant on
monitor size and give a sensible default. With the present monitor coding your options maybe be limited to what can be done without refactoring large amounts of code.

jimm01 wrote:Sounds interesting but I agree that it needs community involvement to truly move forward and get some of the problems solved that make it hard to setup, compile, configure and package for distributions, and helps spread the load and ideas to come up with the best solutions. Unfortunately their are many as always that use the package but do not want to give back anything in return. I think it grew to large for most single developers and their are numerous improvements that can be made but a complete ground up rebuild will be a long way off as the development time alone would stop most in their tracks. Most people want the highest quality of any product but very few are willing to pay the price for it, this is true for FOSS and in the commercial sector.