[dev.icinga.com #2609] icinga.xml for solaris pkg not updated

[icinga-migration]

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

Created by Tommi on 2012-05-14 19:35:44 +00:00

Assignee: crfriend
Status: Resolved (closed on 2012-09-10 11:38:57 +00:00)
Target Version: 1.8
Last Update: 2012-09-10 11:38:57 +00:00 (in Redmine)

Icinga Version: 1.7.1
OS Version: Solaris

---

If icinga prefix is configured to a different one, the location of the icinga.cfg is not updated. finally the package installs the service in with wrong icinga.cfg location and cannot be started with svcadm because of the errornous recorded dependency

Attachments

• bug2609.git crfriend - 2012-09-06 23:03:57 +00:00
• icinga.xml.tpl crfriend - 2012-09-08 00:39:21 +00:00 - The "template" file

Changesets

2012-05-15 19:46:38 +00:00 by Tommi 5a5441c05e46fc1335b7ca4192fb59865d6e03c7

core: use prefix in solaris service definition #2609
refs #2609

2012-05-15 19:51:37 +00:00 by Tommi f6331297d4453e85703274c05d3ff5c5df2eaf96

core: take use of prefix macro in icinga.xml.in and add this file to configure.in #2609
refs #2609

2012-05-15 19:53:44 +00:00 by Tommi 835dc330b487abb88cec0700ed6427a6a8dd516a

core: changed configure file after autoreconf with chances for #2609
refs #2609

2012-06-12 15:46:45 +00:00 by Tommi 120e88e

core: use prefix in solaris service definition #2609
refs #2609

2012-06-12 15:47:23 +00:00 by Tommi b134975

core: take use of prefix macro in icinga.xml.in and add this file to configure.in #2609
refs #2609

2012-09-10 11:36:13 +00:00 by mfriedrich 3f2d285

install: fix icinga.xml for solaris pkg not updated #2609 - CF

refs #2609

---

Relations:

• relates #2609

[icinga-migration]

Updated by mfriedrich on 2012-05-14 19:38:22 +00:00

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

oh, you meant the core solaris pkg. i thought you were talking about -web ...

well then, assigned to carl, and a short note - that file is not generated from configure.

[icinga-migration]

Updated by crfriend on 2012-05-14 20:30:42 +00:00

• Category set to Packaging

Given that this is "low" priority, when does it need to be done? I'm going to need to bone up on my "make" syntax and Solaris packaging skills (what there are of them).

I've already got a few ideas on the matter....

[icinga-migration]

Updated by mfriedrich on 2012-05-14 20:33:05 +00:00

when you get time and pleasure doing it ... but please after the release things are sorted. therefore low priority, as solaris packaging is not the common practice anymore. at least i can see more linux users out there ...

[icinga-migration]

Updated by crfriend on 2012-05-14 21:50:26 +00:00

It turns out that this was a bit of a trivial one, solved by moving the original XML file aside, turning it into a template, and then sed'ding the template to produce the formal XML.

I'm now down to bashing heads with git (at least until I get used to it). Which tree should I pull the reference from? I'll do that, then apply my changes to it and submit the results.

[icinga-migration]

Updated by crfriend on 2012-05-14 21:51:46 +00:00

• Done % changed from 0 to 50

[icinga-migration]

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

• File added git-patch-bug-2609.git
• Target Version set to 1.8
• Done % changed from 50 to 80

The attached patch moves the creation of the icinga.xml file to a "sed" call in the Makefile (by way of makefile.in") which will inject the proper configuration-path for the "file://" dependency.

It successfully generated a package on my system, but I have, as yet, not tried installing it. Would someone with a Solaris-10 system please take a moment to test this for sanity? The only changes were to Makefile.in and the creation of a template file for the XML.

[icinga-migration]

Updated by Tommi on 2012-05-15 19:58:33 +00:00

Hi Carl,
autotools will do all this stuff for you. You only need to rename icinga.xml to icinga.xml.in, replace hardcoded prefix with prefix macro (sysconfdir macro cannot be used here) and add this file to the AC_OUTPUT file lists in configure.in. Than autoreconf, configure as usual, thats it. icinga.xml is rerecrate with the macro replaced with the actual setting

 diff --git a/configure.in b/configure.in
index 585f400..a406982 100644
--- a/configure.in
+++ b/configure.in
@@ -1324,7 +1324,7 @@ AC_MSG_CHECKING(for -Wall based on os/compiler)


 dnl OUTPUT
-AC_OUTPUT(Makefile subst solaris/pkginfo base/Makefile common/Makefile contrib/Makefile cgi/Makefile html/Makefile module/Makefile module/idoutils/Makefilexdata/Makefile daemon-init daemon-init-redhat rc.ido2db module/idoutils/src/Makefile t-tap/Makefile t/Makefile module/idoutils/db/scripts/installdb module/idoutils/db/scripts/upgradedb module/idoutils/db/scripts/prepsql p1.pl)
+AC_OUTPUT(Makefile subst solaris/pkginfo solaris/icinga.xml base/Makefile common/Makefile contrib/Makefile cgi/Makefile html/Makefile module/Makefile module/idoutils/Makefile xdata/Makefile daemon-init daemon-init-redhat rc.ido2db module/idoutils/src/Makefile t-tap/Makefile t/Makefile module/idoutils/db/scripts/installdb module/idoutils/db/scripts/upgradedb module/idoutils/db/scripts/prepsql p1.pl)

 perl subst $srcdir/include/locations.h

diff --git a/solaris/icinga.xml.in b/solaris/icinga.xml.in
index 99681f3..b4cf3f9 100644
--- a/solaris/icinga.xml.in
+++ b/solaris/icinga.xml.in
@@ -10,7 +10,7 @@
                 

                 
-                        
+                        

commited this in my tree tdressler/ido

[icinga-migration]

Updated by mfriedrich on 2012-05-15 20:01:41 +00:00

please use autoconf greater than 2.65! otherwise various macros could fail. current debian ones are 2.68 or 2.69 - manual builds are described in the wiki (as i do on rhel5).

[icinga-migration]

Updated by crfriend on 2012-05-15 20:53:50 +00:00

Tommi wrote:

Hi Carl,
autotools will do all this stuff for you. You only need to rename icinga.xml to icinga.xml.in, replace hardcoded prefix with prefix macro (sysconfdir macro cannot be used here) and add this file to the AC_OUTPUT file lists in configure.in.

I thank you for that, and it's certainly something worth contemplating going forward.

I took my lead from sed tricks that are already being played in the (generated) Makefile, and in looking at the autoconf idea I find the option of having CFGDIR available at the icinga.xml-generation time very convenient, if not compelling. The other useful facet is that by tweaking the Makefile.in (which configure uses to build the Makefile) one does not need to have the autotools suite (and its dependencies) loaded on a baseline Solaris system.

I do not know what percentage of Solaris systems have the autotools suite loaded on them, but the one I'm using in this effort is the very first one that I've seen.

And I still need to get git loaded on the zone I'm using for development... Not to mention that my SPARC box is making unpleasant clicking noises at the moment (which is most likely a fan on its way out; I have a spare a few feet away).

The other thing that doesn't particularly thrill me is that one needs to run the package-make as root, but I'll get over that.

At the moment, I'm gearing up for a 1.7.0 (released) build to complete so I can build the package, install it, and see how it goes. If that works, I'll flag the issue as "Feedback" and see what I get back.

I'm at autoconf 2.67.

[icinga-migration]

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

• Status changed from Assigned to Feedback

Here's the latest and greatest

1. The package generated by a root-issued "gmake icinga.sun.pkg" (Yes, it has a dependency on GNU make for the "shell" calls.) installed properly, the smf bits for core (sans IDO) were correctly instantiated, and all the executables were installed.

2. None of the plugins were installed (hardly a surprise)

3. The database bits (ido2db) were not instantiated properly in smf

4. Some of the $PREFIX/${foo} hierarchy was not installed (e.g. var/rw or even a stub libexec)

5. Everything's owned by root

In short, the generated package, whilst for the most part is technically valid is completely and totally inoperable when installed. We have a rocket that starts its engines, lifts about a foot off the pad, and crashed Earthward in a large explosion of flame.

Ideas on this, and why I'm asking for feedback, include the following:

1. Disable IDOUtils outright, and state that during install time -- generate a separate package for IDOUtils

2. Put just enough stuff in the configuration tree and the libexec area to at least try to do something sane immediately after install to prove to the installer that there's some level of sanity. "ping 127.0.0.1", perhaps?

3. Make the entire ${prefix} tree owned by the Icinga user. This allows manipulation of the configs and plugins possible by the Icinga admin as well as testing of same. (For the sake of argument at this point, we shall omit restarts of the instance.)

4. Make sure that the entire directory-hierarchy -- at least as far as we can divine it at install-time -- is in the package.

Feedback?

[icinga-migration]

Updated by Tommi on 2012-05-16 06:20:24 +00:00

i am with you. The root issue i ran into too, but after changing the rights the process started fine via svcadm with my patch included. plugins are never included in any of icinga packages(up to now, maybe we should also think about this) und the idoutils are complete out in the current solaris make pkgset. I opened a new feature request for to diskuss these topics : https://dev.icinga.org/issues/2613
Using very fresh features on development tool side is always a problem in solaris. Fortunally, Solaris Studio is free for developers and most of the other tools are available on opencsw.org. There is a problem with the gcc there, it dont understand the -wl,xyz switch, but the sun compiler works.

[icinga-migration]

Updated by mfriedrich on 2012-07-31 19:33:06 +00:00

is this done/not done/requires more input?

[icinga-migration]

Updated by crfriend on 2012-07-31 20:21:30 +00:00

The attachment to this issue solves the problem of applying the prefix to the smf descriptor, but does so using a template file for the XML that gets transformed via sed to inject the prefix based on the "CFGDIR" variable that is present at the package-make time.

There was some minor disagreement as to whether it was best to wait until the CFGDIR variable is present (e.g. very late in the build/package cycle) or to to so via the autoconf facility. I opted for the former as (1) I am not particularly familiar with autoconf/autotools and (2) most of the Solaris systems I've seen do not have the autoconf/autotools suite loaded on them.

Using the attached patch, I was able to generate a proper smf file and to import it and have it work. It's not seamless, by any measure, but any reasonably experienced Solaris admin should have no problems understanding what's going on. I anticipate that we are not interested in Solaris versions below 10 which do not use smf.

[icinga-migration]

Updated by Tommi on 2012-08-01 16:34:07 +00:00

i attached a sample patch for autoconf. This was working for me. I would prefere this version because most of the configure stuff rely on autoconf features. But often its very hard to convince solaris to work with such tools even the compilers are sometimes a real pain. To prevent this from our customers we dicussed to offer binary packages. means most of the work we spend here is only to make our own live easier.

After some month living with my other solaris "feature"/problems and seeing the very small user base for solaris i am going to use linux as core and attach existing solaris servers only as targets with nrpe or similar. At least with the upcomming ZeroMQ based core i suspect serious build problems on solaris and will not spend this amount of time as before with blind tries to fix it for myself. Means i will reduce my development activities for solaris in general and leave it to carl.
Back to this issue: for reason above i will not vote which solution should go to upstream

[icinga-migration]

Updated by crfriend on 2012-08-02 00:21:38 +00:00

OK, guidance requested.

In keeping with the best practises of the development group, and the apparent increasing marginalisation of Solaris as a platform, what is the best course of action on this issue?

We have two possibilities:

1. Hack the Makefile (and by extension, Makefile.in -- to be done) to use "sed" to plug the CFGDIR value into the target XML for smf, and
2. Use the autoconf/autoutils to make the change, possibly before the final value of CFGDIR is concretely known (in the case where autoconf is not loaded on the build system in question).

I am not wedded to either one, but my experience indicates that most Solaris systems don't have the autoconf suite loaded on them and, hence, their admins, if building from source, likely use the provided Makefile in lieu of creating a new one.

Too, if a Solaris binary package is to be provided, somehow, somewhere, for download, what should be included in it? The dependency-tree for Icinga proper is small enough, mainly the GD libraries and their dependencies, but once IDO comes into the picture the landscape is vastly different -- and packages may not exist for those facilities.

Finally, and I suppose it's worth asking: "Is it worth worrying about a marginal environment other than as a porting exercise to ferret out bugs that don't manifest in Linux?"

[icinga-migration]

Updated by mfriedrich on 2012-08-31 11:11:49 +00:00

• Icinga Version set to 1
• OS Version set to Solaris

is this something for 1.8 or can we remove the target version for now?

[icinga-migration]

Updated by crfriend on 2012-08-31 12:23:12 +00:00

dnsmichi wrote:

is this something for 1.8 or can we remove the target version for now?

My full intent is to have this done, with changes submitted for both the delivered "Makefile" as well as the "Makefile.in" within the next week or
two. I'll grab the latest git version next week (I'm going away for the weekend) and make the modifications (and patches) based on that instead of the likele now-stale one I have working here.

Thanks for the prod.

[icinga-migration]

Updated by mfriedrich on 2012-08-31 13:08:06 +00:00

• Status changed from Feedback to Assigned

ok, thanks for the update.

[icinga-migration]

Updated by mfriedrich on 2012-09-03 17:44:49 +00:00

• Priority changed from Low to Normal

[icinga-migration]

Updated by crfriend on 2012-09-06 22:56:54 +00:00

• File deleted git-patch-bug-2609.git

[icinga-migration]

Updated by crfriend on 2012-09-06 23:03:58 +00:00

• File added bug2609.git

Here's what I think to be the final patch to make Solaris packaging work. There are "gotchas" all over the place, but so long as the builder is not doing anything really "fancy" this should work. The big bugbears are the dependency on GNU make and the necessity to run the "gmake pkgset" as root -- the former can be an annoyance for Solaris package-makers and the latter will require them to "own" the system they're building on.

My rationale for waiting until after the original "autoconf" bits was primarily if an addvanced packager set the configuration space to something other than the basic default of ${PREFIX}/etc (and I have done this in the past) and secondarily a level of cleanliness in the setup that would allow for more precise location of the configs.

The git patch assumes the presence of the icinga.xml.tpl file. If that is not already in the repository please indicate and I shall provide my latest copy which has provided sane results for several test-cases of ${PREFIX} values.

[icinga-migration]

Updated by crfriend on 2012-09-08 00:39:21 +00:00

• File added icinga.xml.tpl

Just so it doesn't get lost, I'm attaching the "template" file for the icinga.xml SMF-descriptor for Solaris. This one differs from the last one I used in that I omitted the "/etc/" portion of the file-dependency which was causing problems with the $CFGDIR definition which included the /etc/ portion.

[icinga-migration]

Updated by mfriedrich on 2012-09-10 11:38:57 +00:00

• Status changed from Assigned to Resolved
• Done % changed from 80 to 100

the tpl file was never added to git, so thanks. i've now merged those.

for the future - you should have gotten your git pub key already on git.icinga.org, as well as you should be able to push to your cfriend/* branches.