Evtl. kennt das noch der ein oder andere: Wenn man den ganzen Tag auf einen dieser alten grünen Monochrommonitore geschaut hat, sieht man abends einen rosa Augenhintergrund. - In unserem Projekt hier ist es gerade sehr ähnlich - nur andersherum.
Und so müssen die neuen Dinge von CoreMedia, die richtig Spaß machen und gut zu handhaben sind (natürlich nicht ohne Einarbeitung), auch ein wenig Altlast tragen, denn einige Dinge sollen so bleiben, wie sie seit viele Jahren bewährt laufen.
Z.B. sind die Server immernoch Sparc Maschinen mit Oracle Solaris. Und der der Kunde erwartet, daß das einfach so funktioniert, da es ja auch im Handbuch steht.
Der CoreMedia Blueprint und sein kleiner Bruder verlassen sich aber darauf, daß die damit erstellten Pakete auf einer bestimmten Sorte Linux laufen (eine Frage von LSB, BSD, POSIX usw.). Also haben wir da doch mit einer gewissen Lernkurve Punkte entdeckt, an denen man Änderungen einbauen muß. Die Projektlösung war dabei doch recht speziell, umfangreich - und hatte mehr Klippen zu umschiffen als für eine Blueprint nötig.
Daher wollte ich nun auf Basis des reinen Blueprint Workspaces noch einmal eine saubere, schlanke Neu-Umsetzung durchführen. Bereits bei den Spielereien mit Debian/Ubutunu habe ich gesehen, wie sich einige Skripte doch auf Details verlassen, die nicht einmal unter allen Linux-Distributionen so sind. Bei Solaris war mir aus Jahrzehntelanger Erfahrung klar, daß selbst bei gleicher Shell einige System-Tools sich nicht so verhalten, wie ihre meist erweiterten GNU-Freunde. - Und das ist auch hier wieder relevant.
Der große Skripte-Zoo im CoreMedia Blueprint ist aber gerade ein wichtiger Teil für den Weg vom Entwickler-Rechner in die Produktion. Diese Zusammenstellung wollte ich möglichst minimal anpassen und mit einer Solaris Paketierung zusammenführen.
Schritt eins dabei war natürlich die Herstellung der Pakete selbst. Wegen schlechter Erfahrungen mit entsprechenden Maven-Plugins, die auch seit Jahren nicht mehr gewartet werden und das Alpha-Stadium nicht verlassen haben, kam diesmal der Einsatz der System-Tools auf die Tagesordnung. Solaris-Pakete lassen sich damit auch nur unter Solaris erstellen, sorry.
Dabei integriert mal die Skripte aus dem Workspace oder verpackt. D.h. man holt sich die preinstall.sh und portuninstall.sh als preinstall und postuninstall in das Paket während man die postinstall.sh und preuninstall einfach verpacken kann:
# postinstall
if [ -f ${INSTALL_ROOT}/${APPLICATION_NAME}/INSTALL/postinstall.sh ] ; then
${INSTALL_ROOT}/${APPLICATION_NAME}/INSTALL/postinstall.sh 1
fi
Im Gegensatz zu Linux Varianten kennt hier Solaris anscheinend keine Parameter an diese Skripte. Preinstall und Postuninstall sind also schon einmal anzupassen, da vor dem Installieren und nach dem Entfernen ein Wrapper in's Leere greifen würde:
#!/bin/bash
set -e
# $1 == 1 --> initial installation
# $1 == 2 --> upgrade
SELECTOR=$1
# Solaris
if [ -z $SELECTOR ] ; then
SELECTOR=1
fi
if [ $SELECTOR -eq 1 ] ; then
...
(preinstall.sh)Die Solaris Paketierung stellt man auch gerne wieder generisch als Maven Modul unter packages/ bereit und legt sich hierin Prototypen für die Paketbeschreibung inklusive der Skripte und ein Ant-Script zu Steuerung der Paketierung bereit:
PKG=${APPLICATION_NAME}
NAME=${APPLICATION_NAME}
DESC="CoreMedia 7 Component - ${APPLICATION_NAME}"
VERSION=${project.version}
BASEDIR=${INSTALL_ROOT}
PSTAMP=${timestamp}
CATEGORY=application
ARCH=sparc
CLASSES=none
VENDOR="CoreMedia AG"
HOTLINE="+49-40-325587-777"
EMAIL="support@coremedia.com"
ISTATES=S s 1 2 3
RSTATES=S s 1 2 3
pkginfo
i pkginfo
i preinstall=preinstall
i postinstall=postinstall
i preremove=preuninstall
! postremove=postuninstall
!include generated-prototype
prototype
<?xml version="1.0" encoding="UTF-8" ?>
<project>
<target name="pkg">
<copy file="${project.build.directory}/${PACKAGE_DIR}/INSTALL/preinstall.sh"
tofile="${project.build.directory}/solaris-cooked/preinstall"
overwrite="true" failonerror="false" />
<copy file="${project.build.directory}/${PACKAGE_DIR}/INSTALL/postuninstall.sh"
tofile="${project.build.directory}/solaris-cooked/postuninstall"
overwrite="true" failonerror="false" />
<exec executable="/bin/bash" failonerror="true">
<arg value="-c" />
<arg value="pkgproto ${project.build.directory}/${PACKAGE_DIR}=${APPLICATION_NAME}/ > ${project.build.directory}/solaris-cooked/raw-prototype" /> </exec>
<exec executable="/bin/bash" failonerror="true">
<arg value="-c" />
<arg value="sed -e s/${user.name}/${INSTALL_USER}/g ${project.build.directory}/solaris-cooked/raw-prototype | sed -e s/[a-zA-Z0-9]*$/${INSTALL_GROUP}/g | grep -v dll= | grep -v exe= | grep -v bat= > ${project.build.directory}/solaris-cooked/generated-prototype" /> </exec>
<exec executable="/bin/bash" failonerror="true">
<arg value="-c"/>
<arg value="mkdir ${project.build.directory}/pkg"/> </exec>
<exec executable="/bin/bash" failonerror="true">
<arg value="-c" />
<arg value="pkgmk -f ${project.build.directory}/solaris-cooked/prototype -d ${project.build.directory}/pkg -o -b ./" /> </exec>
<exec executable="/bin/bash" failonerror="true">
<arg value="-c" />
<arg value="pkgtrans ${project.build.directory}/pkg ../${APPLICATION_NAME}-${project.version}.sparc.pkg ${APPLICATION_NAME}" /> </exec>
<exec executable="/bin/bash" failonerror="true">
<arg value="-c" />
<arg value="gzip -9 ${project.build.directory}/${APPLICATION_NAME}-${project.version}.sparc.pkg" />
</exec>
</target>
</project>
(ANT build-pkg.xml)
Wenn man diese Pakete dann installiert, fällt die Installation recht herb auf die Nase. Unter Solaris funktioniert das automatische Anlege der Benutzer doch etwas anders und hat keine impliziten Randbedingungen wie bei Linux.
# Add the "@INSTALL_USER@" user
# This will fail on Solaris
/usr/sbin/useradd -c "system user to run coremedia services and applications" \
-s /bin/bash -m -d @INSTALL_ROOT@ -r @INSTALL_USER@ 2> /dev/null || :
# For Solaris create group manually
/usr/sbin/groupadd @INSTALL_GROUP@ 2> /dev/null || :
# So try it again without -r parameter but group (s.a.) instead
/usr/sbin/useradd -c "system user to run coremedia services and applications" \
-s /bin/bash -m -d @INSTALL_ROOT@ \
-g @INSTALL_GROUP@ @INSTALL_USER@ 2> /dev/null || :
(postinstall.sh)
Wenn man jetzt noch das mktemp in reconfigure.sh umformuliert kommt man schon sehr viel weiter. Und nach einer Anpassung der Service-Integration in /etc/init.d ist man sehr nahe am Ziel.
# Register as service if possible
if [ -x /sbin/chkconfig ] ; then
logger -p syslog.info -t coremedia/rpm \
-s "Enabling the service @APPLICATION_NAME@, ..."
chkconfig @APPLICATION_NAME@ on
else
echo "To start call \"/etc/init.d/@APPLICATION_NAME@ start\""
fi
(z.B. postinstall.sh)
Auch hier wieder ist zur (etwas) besseren Lesbarkeit einiges ausgelassen. Die volle GIT-Patch-Sequence gibt's gerne auf Anfrage.
Keine Kommentare:
Kommentar veröffentlichen