Gentoo Linux ebuilds for 7.1.1 and 7.1.2

I spent a good part of the day integrating Ignition into a portage overlay. Gentoo uses OpenRC for its initscripts, so the Ubuntu style scripts in the download aren’t compatible. Gentoo also strongly discourages embedding extra copies of system libraries, so the ebuild filters out the private copies of tomcat and javamail, and specifies the dependencies instead.

The 7.1.1 ebuild is marked stable for x86 and amd64, while the 7.1.2 ebuild is marked unstable (~x86 and ~amd64). Note, the stable designation is for Ignition itself… I’m not entirely sure these ebuilds will unmerge cleanly, as the ignition service expands its context gpkg on first run. Portage is therefore left in the dark in regards to the true file list for the application.

(Carl, if you care to supply a bash script that’ll expand a context just shy of configuring it, I can blend that in. Or assemble the linux distribution files with the context pre-expanded.)

The ebuild also creates an ‘ignition-gcu’ script tailored to the gentoo environment, and creates the KDE or Gnome desktop entry for it. Running gcu is limited to members of the ‘ignition’ group, which is automatically created by the ebuild.

In any case, untar the attached file in a local overlay folder, then “emerge ignition”.
ignition-7.1.2.ebuild.tar.gz (11.3 KB)

Whoops! Forgot to mention:

You need to create a plain-text copy of the IA license, place it in ‘/usr/portage/licenses’ with the name ‘Ignition’ (no extension), and add ‘Ignition’ to the list of accepted licenses in ‘/etc/make.conf’.

Cool, thanks for going to the trouble to do this. I know nothing about Gentoo linux. Why would it care about the internal workings of Ignition? Why would it care about the context being archived before 1st install?

Linux package manager tools care about the individual files installed so that un-install operations remove them correctly. This is true of Red Hat and Ubuntu as well, just with different tools (rpm, deb, yum, synaptic, portage, packagekit, etc). All of these tools track what specific files are installed by each package in a local database. Files created “on the run” don’t end up in the database, and are therefore retained when un-installing. This is deliberate on the package managers’ part, as they want to preserve data files when upgrading packages from one version to another.

Obviously, this is precisely the opposite approach from Microsoft Windows, which expects application developers to supply uninstall tools to go with their apps. Linux distributors don’t trust app developers to do this properly in the face of the wide variety of targets, so they handle it themselves.

So, for standard linux distributions to properly uninstall or upgrade ignition using their native package managers, the package installation process must expand its distribution archives to the form needed at runtime. Java JARs don’t need to be expanded, because java uses them as-is.

You have JARs inside the .gpkg, though (among other things). At first run, they are placed appropriately in the contexts folder. Later, when the native package manager is told to un-install, the contexts folder will be left in place, under the presumption that these are data files, not executables and static resources. When the next version is installed, it won’t necessarily overwrite the previous context, unless your runtime is smart enough to verify the contexts folder contents against the versions folder every time the service starts.

The database of installed files typically includes SHA1 or MD5 hashes of every file installed, specifically to identify “initial copies” of app data files that shouldn’t be removed on un-install. (Also used to notice customizations in the /etc folder, to avoid overwriting them on upgrade).

In any case, I’m willing to help prepare the Ubuntu/Debian .deb and Red Hat/CentOS .rpm files after this is all sorted out. By the way, those formats are archives themselves, so they’ll need to include everything you now include in your .tar.bz2 files. In contrast, Gentoo ebuilds only have scripts and metafiles… the install process uses info in the scripts to go fetch the necessary archives on demand.

OK. I just went through the exercise of upgrading from 7.1.1 to 7.1.2 using the ebuilds I offered. Your runtime sees the contexts folder left over from build 5078, and doesn’t pick up the new version.

So, my ebuilds aren’t ready for prime-time. Its going to be next to impossible to create a proper linux package (for any distribution) without unpacking the context.

Further, I went and uninstalled using the package manager, blew away the contexts/main folder, and reinstalled. The new version was now picked up, but I lost all my settings. I’m guessing a license file would’ve gone, too?

The management of the contexts (even their binaries) is part Ignition’s web server, which we call “Catapult”. The original idea with the contexts is that you could have multiple instances of contexts running simultaneously. Currently this feature is is somewhat stealth mode, as we feel that it would simply add confusion without some more GUI work. You can see some hints of how this feature might feel looking at the GCU.

So in a strict sense, you could say that everything under [tt]contexts/[/tt] are user files. You could even have contexts running as different versions, which makes me think that they shouldn’t be under the purview of a linux package manager. If you have an existing context, and put a newer *.gpkg file into the [tt]versions/[/tt] folder, you can use the GCU to upgrade your context to a newer version. We are going to add a command line interface to the GCU as well.

I think a good idea in the near term would be to add an “auto-upgrade” mode to Catapult, where it would notice newer *.gpkg file under [tt]versions/[/tt] and use it to upgrade all existing contexts, which in todays terms simply means the “[tt]main[/tt]” context.

Ah, I understand. It seems there should be two separate packages for distribution under linux: “catapult”, and “ignition”, where “catapult” is everything except the context, and “ignition” is only the context (but with a dependency on “catapult”). If you incorporate the “unpack the context” function in a command line version of gcu, traditional linux package management remains possible, and your linux fans will be happy :wink:

The command line use of gcu is critical, anyways, as it’s very common for linux servers to not have X installed at all.

Related question: can ignition be passed one or more runtime parameters to specify alternate paths for end-user data? Specifically, the server/cluster config files, project files, and/or the license file(s)? I managed to separate the wrapper config, and put it in /etc/ignition, while the balance of the app is in /usr/share/ignition. For consistency, I’d like to also put the cluster config and license in /etc/ignition, and the per-project files in /var/ignition.

The use of a package manager in linux helps distinguish between files that are supplied from trusted upstream sources, files that are locally configured by server admin types, and files that are remotely created/updated by less trusted types. This is vital information when using security software like Tripwire, et al, and is most convenient when the categories are segregated by folder.

If you look at config.xml, that configures what contexts exist, and then if you look at tomcat/webapps/ctxN/WEB-INF/web.xml you’ll find a context-home parameter that specifies where the context lives. It doesn’t need to be under the installation directory.

I’ve had a chance to work out how the context package expands and the xml files that need to be touched to end up with a manageable package. To keep it simple, I didn’t try to create ‘catapult’ and ‘ignition’ as separate packages, and I didn’t include any support for multiple, simultaneous contexts. The installer I ended up with only sets up ‘ctx0’, and will overwrite it if present.

With the ebuild files in an overlay, the standard gentoo ‘emerge ignition’ will go out and grab the right install file for either x86 or amd64, expand it, touch up the config files for the gentoo folder layout, and put all the files in appropriate locations. If you are running a stable system, you’ll get v7.1.1. If unstable, or you keyword ‘www-app/ignition’, you’ll get the v7.1.2 beta.

Use ‘/etc/init.d/ignition start’ and ‘rc-update add ignition default’ to run the service and set it to start on boot.

When you uninstall, the customizations you’ve made, and the projects you’ve created, are left in place. Installing a new version automatically picks up your customizations and projects. One anomaly was noted: sometimes on upgrade projects would lose their ‘default auth profile’ setting.

Also, changes to the listening port made with GCU will be lost on re-install or upgrade. (along with anything else in config.xml.)
ignition-7.1.2-r1.ebuild.tar.gz (5.2 KB)

Hey there is an important piece of information that I forget when we spoke on the phone. If you put a *.gpkg context package file into a subfolder of the install directory called “upgrades” it will extract it and upgrade the context automatically on startup.