I am trying to install ossec on a centos 6.4 machine but only repo which have .rpm file are from atomicrepo but then installing it require to upgrade my mysql I am reluctant to do it so I have used mock to rebuild and manage to yum install later from the build folder. My concern is that any security issue with regards to this issue or any other known issue and also how much extra space will this take?

Dani AI

Generated

Short answer: using mock to rebuild an OSSEC RPM is a reasonable, common approach and is safer than blindly installing an unsigned third‑party binary — but it shifts the responsibility for vetting, signing, and ongoing maintenance onto you. As is worried (and as hinted), mock gives you an isolated buildroot so the build itself is clean, but it does not magically make the rebuilt package “supported” or automatically track future security patches.

Things to watch for (practical checklist)

  • Verify the SRPM/sources and spec before building (checksum and origin). Don’t rebuild modified SRPMs without understanding changes.
  • Inspect the resulting RPM for scripts and requirements (pre/post install actions, dependencies, setuid files) and for ABI/runtime deps that might not exist on your minimal host.
  • Test the rebuilt RPM in a staging VM that matches production (service start, SELinux context, log paths, signals, file ownership).
  • Sign the RPM with your GPG key and publish to an internal repo so updates and installs are auditable.

Quick commands you can run against a built RPM

rpm -qpR ossec-*.rpm        # shows runtime requirements
rpm -qp --scripts ossec-*.rpm
rpm -qpl ossec-*.rpm       # lists packaged files
rpm -K ossec-*.rpm         # check signature (if present)
du -sh /var/lib/mock/*     # rough disk usage for mock chroots

Disk footprint and cleanup

  • A minimal CentOS 6 mock chroot is typically a few hundred MB; adding buildtools and devel libs can push usage into the 1–3 GB range while building complex packages. The final RPM is usually small (tens of MB). Use mock’s clean options or remove old chroots to reclaim space.

Recommendation for production
If you cannot accept the vendor repo upgrade (MySQL in your case), either run the rebuilt package with strict controls (staging, signing, monitoring) or isolate OSSEC in a container/VM (as suggested) so you avoid touching system libraries while keeping updates manageable.

Recommended Answers

All 5 Replies

Is this for production use, or to test/evaluate? If the latter, then install it on a virtual machine.

No its for a production use. The problem is that I am tring to install ossec which is an intrusion detection system. For centos the only repo which have it is atomicorp and that requires few other upgrade like on the mysql. But I want to avoid all that and that is why I prefer to rebuild via mock and yum install it. I have tested on another machine it works. So I am worried in future will it be a problem ?

Well, you could build from source and install the updated version of MySQL to /usr/local instead of /usr. When you run the new mysqld daemon you can tell it to use a different port from the default. Then you could point ossec to that version of MySQL via the new port (maybe) instead of the default one.

FWIW, I have found that newer versions of MySQL are pretty well backward compatible with older clients. If you want to install the newer version as the default, then make an external backup of your data and system drive so if it does FU, you can restore to a functioning system. Do that anyway... :-)

Dear Rubberman, All my centos machine are minimal installated so there is one with no mysql installed in it to minimise hacking risks. Thus in this case I am not sure as mock worked well. So I would like to know what is the disadvantage of using mock actually?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.