[Xymon] vagrant example of xymon-4.3.19 server (rhel6) + 3 clients (rhel6, rhel7, ubuntu14)

[Marcin Dulak]

Hi,

On 05/07/2015 09:40 AM, J.C. Cleaver wrote:
>
> On Sun, May 3, 2015 4:38 pm, Marcin Dulak wrote:
>> Hi,
>>
>> the example is available at
>> https://github.com/marcindulak/vagrant-xymon-tutorial
>> I hope Xymon's beginners will find it useful.
> Hi Marcin,
>
> Thanks for your report! Definitely the more documentation the better :)
>
>> In the process of creating it I noticed some problems with the
>> documentation
>> https://www.xymon.com/help/install.html:
>> 1. RHEL6/7 documentation is missing dependencies: yp-tools c-ares-devel
>> 2. Debian documentation is missing dependencies: libc-ares-dev dpkg-dev
> For c-ares-devel, the default tarball includes a bundled copy of c-ares,
> however since it's generally preferable to use shared libraries when
> possible I agree it should be called out for package installation. It's
> unfortunate that RH placed it into the 'optional' channel, as that makes
> it a bit more difficult to add into a managed environment for building.
i'm actually using CentOS not RHEL. Renamed the docs.
I've added also a Windows client.
>
> I'm curious where the dependency for yp-tools came in, however. On EL6 and
> EL7, that should not be a req.
I guess it would be a requirement if you try to configure the client 
manually:
grep ypmatch -r xymon-4.3.19
xymon-4.3.19/configure.client:        USERDATA=`getent passwd $XYMONUSER 
2>/dev/null || ypmatch "${XYMONUSER}" passwd || grep "^${XYMONUSER}:" 
/etc/passwd`

Best regards,

Marcin
>
>
>> 3. I believe fping is no longer necessary as a dependency when building
>> RPMS or debs
> It's not a dependency in the current build, but it is very strongly
> recommended. fping3 has been available for a while now and is quite
> stable. xymonping should be considered deprecated in favor it.
>
>> 4. The /etc/init.d for xymon-client seems still missing on Debian/Ubuntu
>> as reported here:
>> http://comments.gmane.org/gmane.comp.monitoring.hobbit/30534
>>
>> Best regards,
>>
>> Marcin
>
> Thanks,
>
> Yes, especially for systemd systems, there's a definite gap there. I've
> actually gotten it working, but with some significant runtime
> modifications to the present tarball (some of this was also necessary for
> SELinux compliance).
>
> I'd been working to split these patches apart to allow for an orderly,
> feature-at-a-time commit process into SVN but it's been proving more
> difficult than expected to separate the modifications while still ensuring
> that intermediate stages actually build. It might be easier to simply do a
> mass patch to bring everything in and then enter a stabilization period
> for beta testing of a 4.4 branch.
>
> If I go with that approach, systemd and a more normalized initscript
> approach should be working sooner rather than later.
>
>
> Regards,
>
> -jc
>