[dev.icinga.com #2613] enhance solaris packaging

[icinga-migration]

This issue has been migrated from Redmine: https://dev.icinga.com/issues/2613

Created by Tommi on 2012-05-16 06:08:05 +00:00

Assignee: crfriend
Status: Assigned
Target Version: Backlog
Last Update: 2015-05-18 12:17:33 +00:00 (in Redmine)

---

packaging for solaris needs to be enhanced in several points, esp full support for all configure options and solaris specific configs like zones, creating a package for idoutils, maybe additional an adopted package for nagios plugins and finaly upstream to a common distributor (i suggest www.opencsw.org)

Changesets

2013-07-21 18:36:25 +00:00 by crfriend 5ac67c3

Issue #2613 -- Enhance Solaris Packaging

   This commit represents changes made to the Solaris packaging
routine to ensure proper install/removal of packages and files
from /etc/icinga (configuration), /var/icinga (state and logs),
and /usr/local/icinga (executables, HTML, and libraries).

   The change to Makefile.in is to ensure that the installation
script can be found as the Solaris package is generated; a Solaris
"preinstall" file is now used to make sure that the "icinga" user
and group is present, and the postinstall now makes sure that
permissions, UIDs and GIDs are icinga:icinga for configuration
and state data.

refs #2613

2013-08-24 17:04:31 +00:00 by crfriend c20159937534b091cd12a76343234808d08a8cb2

Enhance Solaris Packaging -- #2613

The commit furthers the work on #2613 by clarifying the behaviour of
the shell-script installer on systems where a GNU-style install facility
(e.g. "ginstall") exists.  Previously the Makefile.in was not good at
properly locating the installer during the "gmake Prototype" phase of
the package build; this fixes it for any detected installer.

refs #2613

2013-08-25 12:59:39 +00:00 by crfriend d83f3f8

Update Makefile.in to properly deal with GNU installers -- 2613

This update creates a new-style branch in "feature" for the Solaris
Package Enhancment task and checks in the new Makefile.in which
solves problems with either the presence or absence of GNU-style
installers.  All installers, including the locally-supplied script
now work.

refs #2613

2013-08-25 13:02:24 +00:00 by crfriend 58f713b

Enhance Solaris Packaging - 2613

This puts some intelligence into the preremove script to not
delete the "icinga" entries in /etc/passwd and /etc/group in
case the removal preceds an immediate reinstallation to upgrade
Icinga.  The flag is a valid /etc/icinga/icinga.cfg file.

refs #2613

2013-08-25 16:02:19 +00:00 by crfriend 08e8ac9

Enhance Solaris Packaging -- #2613

This is the beginning of splitting out the IDO facility from the
base Icinga component to facilitate packaging for Solaris.  This
will allow folks who cannot get over the "dependency hump" to
install an IDO-free instance and at least get the benefit of the
classic CGIs and monitoring.

The new Makefile.in is smart enough to suppress the installation
of the IDO bits into Solaris package if IDO is not in use and to
provide it if it is.

I'm committing at the moment so I don't forget and check something
else out and blow away my changes.

refs #2613

2013-08-25 18:24:59 +00:00 by crfriend 4ea13c7

Enhance Solaris Packaging -- 2613

This one fixes some stupidity and fat-finger bits.  I get
those from time to time.

refs #2613

---

Relations:

• relates #2609
• relates #2613
• relates #9020

[icinga-migration]

Updated by crfriend on 2012-05-16 11:13:08 +00:00

This is related to, and an outcome of, #2609, in which I described the results of generating an Icinga package for Solaris-10, and the gyrations it took.

I am not particularly worried about the need to generate the package as root as I own the system; however, other facets encountered include:

1. The installed package is almost completely owned by root in the final location, and this runs counter to the modern notion of role-based activities,

2. There are no plugins delivered at all with Icinga Core which makes the installation rather useless "out of the box" (Question: "Should we include a simple 'ping' plugin and a configuration stub that includes 'localhost' that pings 127.0.0.1?"),

3. IDOUtils are not part of the package -- should they be built into the base package or packaged separately, and

4. Open discussion on what would be useful for packages in general going forward.

I know nothing of www.opencsw.org, so cannot cogently comment on it, but it would be nice to have a binary package someplace available for Solaris folks who do not like to build from source.

[icinga-migration]

Updated by Tommi on 2012-05-16 11:57:13 +00:00

1)this should be aligned with the other distributions. Usually, packages can only be installed as root, but should not nessesary run as root
2)usually, the original nagios-plugins are required. Its a more general question to the project, if icinga should provide his own plugin package. I vote for a seperate full package installing into the icinga file tree
3) for RHEL there are seperate packages for libdbi-mysql/pgsql. I build my own oracle package set.
4) to be complete also irpe and icinga web and the plugins as mentioned in 2) should be considered as candidates to package

regarding opencsw.org. Maybe you are aware of the new commercial approach of sunfreeware.com, there will be no new packages without spending money. But some ppl created opencsw.org to be a full replacement. Check it out, i got most of tools from there and it is much faster than the old one.
Another point:nagios has its opencsw packages ready . At least for this reason we should place our packages as the alternative to nagios. There are more monitoring supporter for this format. See http://labs.consol.de/lang/en/opencsw/.

[icinga-migration]

Updated by crfriend on 2012-05-16 13:06:21 +00:00

Tommi wrote:

1)this should be aligned with the other distributions. Usually, packages can only be installed as root, but should not nessesary run as root

Correct, and I strongly advocate for running as many services and facilities as something other than root, and have done so for a number of years. In the Icinga setups I use, which don't particularly resemble default installs, nothing runs as root -- it all runs as "icinga"; this has the benefit of allowing the Icinga administrator to restart the core process at will without requiring root.

2)usually, the original nagios-plugins are required. Its a more general question to the project, if icinga should provide his own plugin package. I vote for a seperate full package installing into the icinga file tree

I don't believe that providing the full plugins package with core is necessarily a good idea, but think that a minimum subset is, at least to get a running install that a "newbie" can see in action with a fresh install. Full plugins thematically belong in a separate package.

3. for RHEL there are seperate packages for libdbi-mysql/pgsql. I build my own oracle package set.

Is there a Solaris package for libdbi and its drivers? If not, that may be a bit of a hill to climb for the first-timer. At the very least, there should be an interlock in the installer to call this out.

4. to be complete also irpe and icinga web and the plugins as mentioned in 2) should be considered as candidates to package

Concur. What of N/ISCA?

I was aware of the new commercial approach from sunfreeware, and didn't much like it. Thanks for the alternative!

Another point:nagios has its opencsw packages ready . At least for this reason we should place our packages as the alternative to nagios. There are more monitoring supporter for this format. See http://labs.consol.de/lang/en/opencsw/.

Concur again. Much of this is marketing, and pre-packaged bits are a powerful tool in that end.

Before publishing a formal package, however, we -- the entire team -- should come to a consensus as to what options should be enabled/disabled in the configuration. The one I generated the other night -- and successfully installed from the package -- was tailored to my needs: IDO, embedded perl, and cached perl plugins enabled; this may not be optimal for most folks.

[icinga-migration]

Updated by mfriedrich on 2012-05-16 13:11:16 +00:00

if you are trying to package nagios-plugins, please do it as a seperate package of not yet done. or create your own, seperated. i (and i cordially speak for the team) have no interest in supporting icinga plus whateverpackage-we-don't-develop as once. easying the setup should be done with detailed documentation on the seperated packages imho.

[icinga-migration]

Updated by crfriend on 2012-05-16 13:51:27 +00:00

dnsmichi wrote:

if you are trying to package nagios-plugins, please do it as a seperate package of not yet done. or create your own, seperated.

Concur. The full set of plugins is outside the scope of Icinga Core, and I believe that we should leverage the good work of the Plugins team; Core provides the framework within which the plugins operate.

My thrust here was to provide a freshly-installed Core package with just enough surrounding logic to produce a working display and nothing else.

i (and i cordially speak for the team) have no interest in supporting icinga plus whateverpackage-we-don't-develop as once.

Indeed, we already have enough on our plate, so why take on more?

[icinga-migration]

Updated by crfriend on 2012-05-17 22:15:34 +00:00

Pointed question: What is the team's best-practise ./configure syntax for generating packages (e.g. RPMs)? I would very much like to mirror that for Solaris packages, and to develop the proper documentation and dependency-hierarchy to keep an Icinga package from loading -- or at the very least warn the user.

[icinga-migration]

Updated by Tommi on 2012-05-18 18:38:10 +00:00

For my opinion you can follow the options in icinga.spec for rpms to give the user the same experience. But for an opencsw build you need to review all of the path settings according there rules.

[icinga-migration]

Updated by crfriend on 2012-11-10 00:56:20 +00:00

Tommi wrote:

For my opinion you can follow the options in icinga.spec for rpms to give the user the same experience. But for an opencsw build you need to review all of the path settings according there rules.

I got a block of time yesterday and this morning and started work on using the "icinga.spec" as a configuration basis for Solaris, and am working some new experience with zones into the mix and hope to have something in a few days' time so long as I can still devote time to it.

The base install I'm using for Icinga in /usr/local/icinga works nicely in non-global zones so long as I relocate stuff that needs to be written into the zone-local /etc and /var hierarchies (I'm using this now in an attempt to reproduce lost data in some of the classic CGIs). I've also been using the packages I generate at home to provision a system at work with very good results save for the embedded Perl interpreter which has been vexing, to put it mildly.

[icinga-migration]

Updated by mfriedrich on 2013-06-29 14:57:42 +00:00

• Status changed from New to Assigned
• Assigned to set to crfriend

please evaluate if this issue can be closed.

[icinga-migration]

Updated by crfriend on 2013-06-29 15:49:10 +00:00

dnsmichi wrote:

please evaluate if this issue can be closed.

The current status on this is that I can happily build Solaris packages based on any set of configuration options and install them on systems at work and have started to use the generated packages on my production Solaris system at home. I recently laid in a couple of other Solaris 10 systems and am in the process of commissioning one as a test-bed; this will be the dev/test system so I'm not constantly tweaking my production monitoring system.

The number of dependencies concerns me, and will require multiple different packages to accommodate, e.g. IDOutils (libdbi/drivers), embedded Perl (based on experience, probably a bad idea as there are so many variables), and plugins.

A minimally-configured (no IDO/perl) packaged version works now with the caveat that I haven't tried installing into multiple zones. Executables and HTML get installed into /usr/local/icinga, configuration into /etc/icinga, and status/run-time bits into /var/icinga so it's portable across zones and conforms to standard modern practice.

The newest round of source from the git repository has a dependency on gmake for everything so that'll come into play for Solaris administrators who build from source, and the "gmake pkgset" invocation needs to be done as root, but since one needs root access to install packages, that's probably not a show-stopper.

[icinga-migration]

Updated by crfriend on 2013-07-21 18:40:44 +00:00

A new commit for this issue has been added that moves some of the icinga user/group logic around, ensures proper permissions on the configuration and state hierarchies, and improves basic compatibility with Solaris' package mechanism in general. The pkgadd and pkgrm scripts now do the proper things when called and the package installs on a "plain vanilla" Solaris system.

[icinga-migration]

Updated by mfriedrich on 2013-07-27 19:04:17 +00:00

thanks, merged to next. once you feel this issue is completed, please add a Changelog entry too then.

[icinga-migration]

Updated by crfriend on 2014-08-17 23:36:42 +00:00

dnsmichi wrote:

thanks, merged to next. once you feel this issue is completed, please add a Changelog entry too then.

This, despite seeming rather geriatric, is still alive and well. I was fiddling with it just today on a couple of different versions of Solaris 10 of different updates and OpenCSW configurations. I ran into a difference between the two installs I have using the latest release of Icings which I'll nail down in the next few days; this will likely be a change to Makefile.in and, just possibly, configure.

The worst of the problems I ran into had to do with the "ginstall" facility.

[icinga-migration]

Updated by crfriend on 2014-08-23 00:35:47 +00:00

• Status changed from Assigned to Feedback

Guidance requested.

I have found that with a decent GNU-compatible installer (e.g. "ginstall") -- that's in the path of the package builder -- Solaris packaging now works as well as can be expected given the rather large number of dependencies. I've been using this trick for some time in my environment here, and have built Solaris packages for another chap whose name escapes me at the moment.

Is it OK to just declare that a GNU-compatible install facility is a prerequisite, or do I need to solve the path issue for the "install-sh" that ships with Icinga. Open CSW has a good one, and there's even one that's typically installed now with a base Solaris-10 load.

My personal preference at this time is to declare a dependency on it and be done with. There are enough of those already, and even more if the builder/packager wants IDOutils.

[icinga-migration]

Updated by Tommi on 2014-08-24 06:53:21 +00:00

from my opinion you can add this as build requirement to create the package and where to find. But it should not be a dependency for installing the package on the target server

[icinga-migration]

Updated by crfriend on 2014-09-04 00:27:24 +00:00

Tommi wrote:

from my opinion you can add this as build requirement to create the package and where to find. But it should not be a dependency for installing the package on the target server

It's absolutely not an operational requirement and is only applicable to those creating packages. I suspect much of this is going to come down to a documentation rewrite of the Wiki page I put up a while ago to better take into account slightly more "modern" practices with OpenCSW packages serving as a baseline for the Icinga dependencies. Perhaps there'll be one or two changes to the Makefile.in file in the Solaris packaging section.

I need several round tuits, however, and those seem to be in short supply at the moment.

[icinga-migration]

Updated by crfriend on 2014-10-26 16:09:21 +00:00

• Relates set to 7450

[icinga-migration]

Updated by mfriedrich on 2015-05-01 12:20:36 +00:00

• Status changed from Feedback to Assigned
• Target Version set to 1.13.3

[icinga-migration]

Updated by mfriedrich on 2015-05-01 12:23:36 +00:00

• Target Version deleted 1.13.3

[icinga-migration]

Updated by mfriedrich on 2015-05-01 12:23:42 +00:00

• Relates set to 9020

[icinga-migration]

Updated by berk on 2015-05-18 12:17:33 +00:00

• Target Version set to Backlog

[dnsmichi]

This won't happen anymore.