iCal2GW příručka administrátora
ver. 2.5 (9.4.2009)
www.groupwise.cz/ical2gw
O aplikaci Synchronizační služba iCal2GW slouží k synchronizaci událostí, úkolů a milníků z kalendářů ve formátu iCal (portál Novell Teaming) do kalendářů v aplikaci GroupWise. Obsah z jednoho zdroje (jedné složky portálu Teaming), může být synchronizován s kalendáři libovolného počtu uživatelů dokonce i tehdy, pokud jsou jejich schránky na různých serverech GroupWise. Stejně tak může být do schránky jednoho uživatele synchronizován obsah z více složek různých zdrojových serverů Teaming. Úkoly z portálu Teaming lze do GroupWise synchronizovat jako úkoly nebo jako události, podle toho, který typ zobrazení je pro danou příležitost vhodnější. Pro milníky není v kalendáři GroupWise k dispozici odpovídající typ položky, zobrazují se tedy jako celodenní událost ve dni, který je v milníku zadán jako datum v poli Do data. iCal2GW lze vyzkoušet bez rizika i na živém poštovním systému, protože v nejhorším případě může ve schránce na které je zkoušen vytvořit pouze nežádoucí podkalendář jenž jde opět jednoduše odstranit. Pozor! – Pokud se u úkolu v portálu Teaming nenastaví datum, úkol se do GroupWise nepřenese, protože není zahrnut v souboru ics.
Korelační databáze Synchronizace, která probíhá v nastaveném intervalu proběhne u každé položky (kalendářové události, úkolu nebo milníku) vždy jen jednou. Po jejím úspěšném přenesení je proveden záznam do korelační databáze a při další synchronizaci se již pouze kontroluje, zda nebyla u dané položky na zdrojovém serveru provedena změna. Korelační databáze je uložena ve složce s aplikací v podadresáři corr. Pro každého uživatele, který je nastaven v konfiguračním souboru, je zde automaticky vytvořen podadresář nesoucí jeho uživatelské jméno a obsahující příslušné databázové soubory. Pokud dojde k vymazání databázových souborů, budou při nejbližší synchronizaci nejprve z kalendáře GroupWise odstraněny, poté zkontrolovány a znovu do ní přeneseny všechny záznamy.
Schéma činnosti aplikace
1
Pozn. – Synchronizace je jednosměrná tzn. změny provedené v GroupWise se do zdrojového kalendáře nepřenesou. Úpravy nebo odstranění položky ze zdrojového kalendáře se ale v kalendáři GroupWise projeví.
Instalace Systémové požadavky: Java Sun JRE/JDK 1.6.0_11 nebo novější; GroupWise 8.0 s Hot Patch 1 a vyšší; cca 20 MB volného místa na disku. Instalace je velmi jednoduchá. Soubor ical2gw_2.5.bin, který je součástí archivu ve kterém je aplikace distribuována, stačí zkopírovat na server, příkazem chmod +x ical2gw_2.5.bin mu přidat oprávnění ke spouštění a spustit jej. Instalační skript zkontroluje zda je přítomna odpovídající verze Java JRE/JDK a umožní zvolit cestu, kam má být aplikace nainstalována. Pozn. – Aplikaci je možné nainstalovat i manuálně bez použití instalačního skriptu. Pokud se soubor ical2gw_2.5.bin spustí s parametrem -x rozbalí se jeho obsah do aktuálního adresáře. Dále je třeba postupovat podle návodu v kapitole Pokyny pro manuální instalaci. Aby aplikace mohla přistupovat ke kalendářům GroupWise bez zadání přihlašovacích údajů jednotlivých uživatelů, musí být na serveru GW registrovaná jako tzv. Trusted Application. Toho je možné dosáhnout například pomocí utility GWTrustedApp.exe (v adresáři GWTrustedApp). Po jejím spuštění se zadá cesta k adresáři primární doménové databáze a potvrdí. Utilita následně zobrazí tzv. TrustedKey (např. 21A88AA102E50000B18DAD009E00C70021A88AA202E50000B18DAD009E00C700), který je třeba zadat do konfiguračního souboru (viz kapitola Konfigurace) a zároveň je aplikace pro danou doménu zaregistrována, což je možné ověřit například pomocí ConsoleOne. Pozor! – Na straně GroupWise musí být povolena komunikace protokolem SOAP, která je ve výchozím nastavení zakázána!
Licencování Počet potřebných licencí se odvozuje od počtu zdrojových složek portálu Novell Teaming nebo souborů ve formátu ics, ze kterých má synchronizace probíhat – 1zdrojová složka = 1licence. Licenční soubor(y) musí být uloženy v adresáři ve kterém je aplikace nainstalována v podsložce licenses, resp. ve složce definované v konfiguračním souboru (viz kapitola Konfigurace). Pokud po prvním spuštění nebude v příslušné složce nalezen žádný licenční soubor, spustí se aplikace ve zkušebním režimu – Synchronizace bude probíhat, do pole subjekt všech položek přenesených do GroupWise bude však vložen text **TRIAL MODE**. Zkušební režim se ukončí automaticky poté, co aplikace v příslušné složce detekuje jakýkoli platný licenční soubor.
2
Jeden licenční soubor může obsahovat určitý počet licencí. Pokud je ve složce více platných licenčních souborů, počet licencí se sčítá. S rostoucími požadavky lze tedy jednoduše rozšiřovat počet synchronizovaných zdrojových složek, aniž by dříve vydané licence přišly na zmar. počet licencí
100
75 50
25
lic2.key
lic1.key 2009
2010
2011
2012
roky
Na obrázku je zobrazena situace, kdy byl nejprve zakoupen licenční soubor lic1.key, obsahující 25 licencí na dobu 2 let. V průběhu prvního roku se rozšířil počet zdrojových složek, které bylo zapotřebí synchronizovat o dalších 50, byl tedy dokoupen druhý licenční soubor lic2.key obsahující 50 licencí na dobu 3 let. Celkový počet licencí se zvýší na 75, ovšem pouze po dobu platnosti prvního licenčního souboru. V okamžiku kdy jeho platnost skončí, se celkový počet aktivních licencí sníží na 50 (platný bude pouze druhý licenční soubor) – pro zachování synchronizace ze všech zdrojových složek bude zapotřebí opět dokoupit 25 licencí (nebo tolik aby mohl být synchronizován obsah ze všech požadovaných zdrojových složek). Pokud v adresáři není dostatečný počet licencí pro všechny zdrojové složky, nebude se obsah složek, na které licence nezbyly, synchronizovat a jejich názvy budou zapsány do logu. Licence se zdrojovým složkám přidělují postupně, nikoli však nutně v pořadí, ve kterém jsou vyjmenovány v konfiguračním souboru. Pokud je tedy v případě nedostatečného počtu licencí zapotřebí ručně zvolit složky, které nemají být synchronizovány, stačí do konfiguračního souboru doplnit do parametru zdrojové složky možnost disabled="true" např.
Pozn. – Licenční soubory je možné přidávat za chodu aplikace, počet licencí se kontroluje před každou synchronizací. Ve schránce uživatele, který je v konfiguračním souboru nastaven jako adminAccountId se budou automaticky vytvářet zprávy, upozorňující na blížící se vypršení platnosti licenčního souboru (nejprve třicet dní a poté jeden den 3
před vypršením). Varovná zpráva se vytvoří také pokud je v adresáři s licencemi uložen licenční soubor s již prošlou platností nebo zcela neplatný např. poškozený - v těchto případech se zpráva vytvoří každý den (nebo při startu aplikace).
Konfigurace Konfigurace se provádí pomocí konfiguračního xml souboru (viz kapitola Přílohy), jehož název je použit jako parametr při spouštění aplikace. Ve spouštěcím skriptu se počítá s výchozím názvem config.xml. Soubor musí být uložen v adresáři aplikace. V konfiguračním souboru se rozlišují velká a malá písmena v názvech parametrů! (case sensitive) Pozn. – Aby se projevily případné změny v konfiguraci, je třeba po upravení konfiguračního souboru aplikaci restartovat.
Podrobný popis parametrů konfiguračního souboru: <param name="basePath" value="/opt/tdp/ical2gw/"/>
Cesta k umístění ve kterém je aplikace uložena <param name="timeZoneID" value="Europe/Prague"/>
Časová zóna – parametr důležitý pro správné nastavení času celodenních položek přenesených do GroupWise. <param name="workerThreads" value="2"/>
Volitelný, nepovinný parametr umožňující nastavit zpracovávání synchronizace ve více vláknech (hodnota určuje počet vláken) – umožňuje rychlejší zpracování při synchronizaci z mnoha zdrojů na serverech s vícejádrovými procesory. Pokud není nastaven probíhá synchronizace standardně v jednom vlákně. <param name="adminAccountId" value="GWuser1"/>
Parametrem adminAccountId se volí jeden z účtů GroupWise (pro který je nastavena synchronizace - jako hodnota se zadává 'gwAccount id' viz níže), do kterého bude aplikace vytvářet zprávy o případném vypršení platnosti licencí (viz kapitola Licencování) nebo o tom, že synchronizace neprobíhá. Pokud je jedním z účtů na který probíhá synchronizace účet s uživatelským jménem admin, nemusí být parametr adminAccountId nastaven – zprávy se budou automaticky vytvářet v účtu admin. Pokud však bude nastaven jako adminAccountId účet s jiným uživatelským jménem, budou se zprávy vytvářet v něm i přes to, že synchronizace probíhá také do účtu admin. Obsah zpráv lze upravit pomocí šablon (viz kapitola Šablony zpráv). <param name="licensePath" value="/opt/lic"/>
Nepovinný parametr nastavující cestu k adresáři s licenčními soubory. Pokud není cesta nastavena, použije se výchozí cesta z parametru basePath (soubory v takovém případě musí být uloženy v dané cestě v podadresáři licenses).
4
<param name="updateDelay" value="60"/>
Délka intervalu čekání mezi jednotlivými synchronizacemi. Zadává se v sekundách. Pokud není parametr uveden, použije se výchozí hodnota 30 sekund. <param name="watchdogTimeout" value="1800"/>
Délka intervalu, který hlídá zda je aplikace iCal2GW v provozu. Zadává se v sekundách. Pokud během intervalu, který se skládá z této hodnoty a hodnoty nastavené pro updateDelay (zde tedy 1860) synchronizace neproběhne, bude ve schránce administrátora (resp. účtu nastaveného v parametru adminAccountId) vytvořen email, obsahující informaci o tom, že synchronizace neprobíhá (obsah zprávy lze upravit v příslušné šabloně – viz kapitola Šablony zpráv). Pozn. – Sledování se týká pouze činnosti aplikace iCal2GW, nikoli toho zda synchronizace neprobíhá například z důvodu nefunkčnosti portálu Teaming nebo serveru GroupWise!
V sekci connections se nastavují cesty k serverům GroupWise a Teaming. Pro servery GroupWise zde musí být zadán trustedAppKey, který aplikaci umožňuje pracovat s GroupWise jako tzv. trusted application (viz Instalace). Jako parametr trustedAppName se zadává název aplikace použitý při její registraci do doménové databáze (iCal2GW). Pro portál Teaming jsou zde uvedeny přihlašovací údaje k uživatelskému účtu s právy administrátora. Pokud je zdrojových nebo cílových serverů více, odlišují se pomocí id. <sources>
V sekci sources se definují konkrétní zdrojové složky, jejichž obsah má být synchronizován. Hodnota parametru Id se následně uvádí jako hodnota parametru calendar source v sekci nastavení cílových kalendářů v GroupWise. 5
U každé složky může být parametrem connection definováno, ke kterému zdrojovému serveru náleží. Pokud je zdrojový server pouze jeden, nemusí být parametr použit (zároveň ale nesmí být nastaven parametr id u zdrojového serveru v sekci connections). Url adresa v tagu
Pozn. – Url adresa může odkazovat také na kalendář ve formátu ics zveřejněný na některém web serveru (např. Google Calendar). V případě složky milníků, která se přenáší jiným způsobem se místo url adresy zadává tzv. binderId. To je součástí trvalého odkazu na složku, který se zobrazí po klepnutí na možnost Trvalý odkaz na složku.
Pokud je některou zdrojovou složku zapotřebí dočasně vyřadit z procesu synchronizace (např. kvůli nedostatečnému počtu licencí), je možné doplnit do parametru zdrojové složky hodnotu disabled="true" například: Pro obnovení synchronizace pak stačí tuto možnost odstranit nebo změnit hodnotu na disabled="false".
Použití lokálně uloženého souboru ics jako zdroje pro synchronizaci Zdrojem pro synchronizaci může být také soubor kalendáře ve formátu ics uložený lokálně v adresáři in (nachází se v adresáři ve kterém je aplikace nainstalována). Zdrojové soubory se stejně jako kalendáře načítané z web serveru definují v sekci sources.
Parametrem fileName se definuje jméno zdrojového souboru. Pozn. – Kalendář, který má obsahovat data načtená z lokálně uloženého souboru bude vytvořen až v okamžiku, kdy bude soubor s příslušným názvem 6
nalezen aplikací v adresáři in.
Jako gwAccount id se zadává uživatelské jméno pro účet GroupWise. Parametrem connection se pomocí id volí příslušný server GroupWise, definovaný v sekci connections (pokud se používá pouze jeden server, nemusí být parametr použit, nesmí však být nastaveno ani id serveru v sekci connections). Parametrem calendar source se ke zdrojové složce definované v sekci sources (pomocí id) přiřadí kalendář v GroupWise. Hodnotou parametru name se určuje název kalendáře v GroupWise. Pokud kalendář s příslušným názvem ve schránce uživatele neexistuje, bude automaticky vytvořen. Parametrem color se nastavuje hexadecimální kód barvy kalendáře v GroupWise. Barvu lze následně v klientovi libovolně změnit. Nepovinným parametrem tasksAsAppointments="true" lze nastavit, aby se úkoly z portálu Teaming přenášely do příslušného kalendáře GroupWise jako běžné schůzky. Pokud parametr není uveden nebo je jeho hodnota nastavena na "false", budou se úkoly přenášet standardně (jako úkoly se přenáší včetně informace o procentuálním vývoji plnění úkolu a příznaku dokončeno). Dalším volitelným parametrem sync="full" lze nastavit úplnou synchronizaci cílového kalendáře v každém cyklu. Na rozdíl od standardního způsobu, kdy jsou přenášeny pouze změny nalezené ve zdrojové složce resp. souboru, se v takovém případě nejprve obsah cílového kalendáře vymaže a poté je znovu naplněn daty z příslušného zdroje. Pokud není parametr uveden nebo je jeho hodnota nastavena na incremental probíhá synchronizace standardním způsobem. Kolekce kalendářů Pokud je zapotřebí synchronizovat do schránek vždy několik stejných kalendářů, je možné s výhodou využít možnost definovat kolekci zdrojových kalendářů.
7
Kalendáře se do kolekce přidávají stejně, jako v případě kdy se vyjmenovávají jednotlivě u účtu GroupWise. K účtům se následně přiřazují pomocí collection id.
V záhlaví účtu pak stačí uvést parametr collections s názvem příslušné kolekce. Všechny kalendáře, které jsou v ní obsažené, budou s daným účtem synchronizovány. Kolekcí může být k účtu přiřazeno i několik zároveň, jejich názvy se v parametru oddělují čárkou. Zároveň se skupinami mohou být k účtu přiřazeny i jednotlivé zdrojové kalendáře, standardním způsobem jak bylo popsáno výše.
Synchronizace do schránek definovaných distribučními listy, poštovními úřady nebo všem uživatelům systému Zdrojové kalendáře lze synchronizovat také do schránek definovaných distribučními listy, všem uživatelům zvoleného poštovního úřadu nebo dokonce všem uživatelům celého systému GroupWise. Díky tomu není zapotřebí upravovat konfigurační soubor a restartovat aplikaci vždy, když přibude další uživatel, do jehož schránky má synchronizace probíhat. Stejně jako v případě synchronizace do konkrétně vyjmenovaných schránek (gwAccount id) mohou být cílové kalendáře definovány výčtem nebo pomocí kolekce (viz kapitola Kolekce kalendářů).
Název distribučního listu, který má být použit pro definování cílových schránek, se uvede v sekci targets v parametru gwDistributionList id. Jako userId musí být uveden libovolný uživatel, který má k danému distribučnímu listu povolen přístup alespoň pro čtení. Pozor! – Jako connection musí být nastaven gwSoap id poštovního úřadu, který obsahuje příslušný distribuční list. V opačném případě nebude list nalezen a synchronizace do účtů v něm uvedených tak nebude probíhat! 8
Pokud je synchronizaci zapotřebí provádět do všech schránek v rámci poštovního úřadu, uvede se v sekci targets parametr gwPostOffice. Jako hodnotu parametru connection, je třeba nastavit gwSoap id příslušného poštovního úřadu. Jako userId musí být uveden libovolný uživatel, který má v daném poštovním úřadu aktivní účet.
Synchronizaci lze pomocí parametru gwAllUsers provádět i do schránek všech uživatelů v rámci celého systému. Jako userId musí být uveden libovolný uživatel, který má v daném systému aktivní účet.
Spouštění Aplikace běží na serveru jako služba (daemon) a spouští se automaticky při startu serveru. Pokud je zapotřebí spustit, ukončit nebo restartovat ji ručně, lze to provést příkazem /etc/init.d/ical2gw start (resp. stop či restart).
Šablony zpráv Šablony slouží k definování obsahu zpráv, které budou pověřenou osobu informovat o končící platnosti/neplatnosti licenčních souborů a o případné nefunkčnosti aplikace (viz kapitoly Licencování a Konfigurace). Nacházejí se v adresáři aplikace v podadresáři templates. Pro každý typ zprávy je k dispozici jedna šablona: expiringLicense.flt pro informaci o končící platnosti licenčního souboru, expiredLicense.flt pro informaci o prošlé platnosti licenčního souboru, invalidLicense.flt pro informaci o neplatném nebo poškozeném licenčním souboru a watchdogTimeout.flt pro informaci o tom, že synchronizace neprobíhá. Soubory jsou vytvořeny ve formátu UTF-8 bez BOM, upravit je lze v libovolném textovém editoru, který tento formát podporuje.
9
Log Aplikace si vytváří záznam o své činnosti a ukládá ji do souborů v adresáři logs, resp. v adresáři, který je nastaven v souboru logback.xml. (Výchozí nastavení je /opt/tdp/ical2gw/logs.) Pro každý den jsou automaticky vytvořeny dva soubory s názvem obsahujícím datum daného dne (např. ical2gw-2009-01-06) a příponami .log pro záznam běžného chodu aplikace a .err do kterého se zaznamenávají pouze případné chyby nebo problémy, aby je bylo možné snadno nalézt.
10
Přílohy Vzorový konfigurační soubor <param <param <param <param <param <param <param
name="basePath" value="/opt/tdp/ical2gw/"/> name="logbackConfig" value="/opt/tdp/ical2gw/logback.xml"/> name="timeZoneID" value="Europe/Prague"/> name="adminAccountId" value="GWuser1"/> name="licensePath" value="/opt/lic"/> name="updateDelay" value="60"/> name="watchdogTimeout" value="1800"/>
<sources>
11
Příklad použití skupiny kalendářů
Pozn. - Stejnobarevně zvýrazněné hodnoty jsou id souvisejících spojení. Pokud aplikace při startu nenalezne v konfiguračním souboru odpovídající protějšky, vypíše informaci o chybějících spojeních a ukončí se.
12
Pokyny pro manuální instalaci # pro iCal2GW 2.5 na Linuxu (testováno na SLES 10 SP1, ale mělo by být platné i v jiných distribucích) # přihlaste se jako root/superuser # do aktuálního adresáře nakopírujte soubor ical2gw.tar.gz # stáhněte Sun JRE/JDK 1.6_11 nebo novější 'jre-6u13-linux-i586.rpm.bin' # instalace JAVA: chmod +x jre-6u13-linux-i586.rpm.bin ./jre-6u13-linux-i586.rpm.bin # follow the installation instructions (use space bar to scroll through the the license agreement faster) # instalace iCal2GW: chmod +x ical2gw_2.5.bin ./ical2gw_2.5.bin -x # tím se instalační soubory rozbalí do podadresáře 'ical2gw' v aktuálním adresáři. cp -r ical2gw/opt/* /opt/ cp ical2gw/etc/init.d/ical2gw /etc/init.d/ chmod +x /etc/init.d/ical2gw # pokud je zapotřebí upravte soubor /etc/init.d/ical2gw: # # JAVA_HOME – nastavte cestu k umístění ve kterém je jre nainstalováno (obvykle '/usr/java/jre1.6.0_13' nebo '/usr/java/current') # # pokud jste zvolili instalaci do jiného umístění než je výchozí /opt/tdp/ical2gw , zkontrolujte/změňte také: # APP_DIR v souboru /etc/init.d/ical2gw # parametr basePath v souboru config.xml (/opt/tdp/ical2gw/config.xml) # cesty pro logování v souboru logback.xml (součást tagu FileNamePattern – změňte pouze cestu před /logs/ical2gw-%d{... ) # nastavení ical2gw jako služby (daemon) chkconfig ical2gw on # spuštění /etc/init.d/ical2gw start
13
Spouštěcí skript (soubor ical2gw)
#! /bin/sh # # System startup script for the Tomcat servlet container # ### BEGIN INIT INFO # Provides: webmon # Required-Start: $local_fs $remote_fs # X-UnitedLinux-Should-Start: $named $syslog $time # Required-Stop: $local_fs $remote_fs # X-UnitedLinux-Should-Stop: $named $syslog $time # Default-Start: 3 5 # Default-Stop: 0 1 2 6 # Short-Description: WebMon daemon # Description: Start WebMon daemon ### END INIT INFO APP_DIR="/opt/tdp/ical2gw" appIsRunning() { app_ps_log=`mktemp /var/tmp/app-ps.log.XXXXXX` ps aux --cols 1024 >"$app_ps_log" app_is_running="false" if grep "config.xml" "$app_ps_log" >/dev/null 2>/dev/null ; then app_is_running="true" fi rm -f "$app_ps_log" test "$app_is_running" = "true" } #save JAVA_HOME before it gets overwritten OLD_JAVA_HOME=$JAVA_HOME OLD_JAVA_OPTS=$JAVA_OPTS JAVA_HOME=/usr/java/jdk1.6.0_11 # test whether JAVA_HOME and JAVA_OPTS were overwritten ... if empty now, reset to old values test -n "$JAVA_HOME" || JAVA_HOME=$OLD_JAVA_HOME test -n "$JAVA_OPTS" || JAVA_OPTS=$OLD_JAVA_OPTS test -x "$APP_DIR/startup.sh" || { echo "$APP_DIR/startup.sh not installed"; } # pid set? test -n "$APP_PID" || APP_PID="/var/run/ical2gw.pid" # the following variables affects the server export APP_PID APP_DIR JAVA_HOME JAVA_OPTS # Shell functions sourced from /etc/rc.status: # rc_check check and set local and overall rc status # rc_status check and set local and overall rc status # rc_status -v ditto but be verbose in local rc status # rc_status -v -r ditto and clear the local rc status # rc_failed set local and overall rc status to failed # rc_failed set local and overall rc status to # rc_reset clear local rc status (overall remains)
14
# rc_exit . /etc/rc.status
exit appropriate to overall rc status
# First reset status of this service rc_reset # # # # # # # # # # # # # #
Return values acc. to LSB for all commands but status: 0 - success 1 - generic or unspecified error 2 - invalid or excess argument(s) 3 - unimplemented feature (e.g. "reload") 4 - insufficient privilege 5 - program is not installed 6 - program is not configured 7 - program is not running Note that starting an already running service, stopping or restarting a not-running service as well as the restart with force-reload (in case signalling is not supported) are considered a success.
case "$1" in start) echo -n "Starting iCal2GW ($APP_DIR)" ## Start daemon with startproc(8). If this fails ## the echo return value is set appropriate. # NOTE: startproc return 0, even if service is # already running to match LSB spec. if appIsRunning ; then rc_failed 0 else cmd="$JAVA_HOME/bin/java -jar $APP_DIR/iCal2GW.jar $APP_DIR/config.xml" rm -f $APP_PID nohup $cmd >"$APP_DIR/start.log" 2>&1 & echo $! >$APP_PID sleep 1 if appIsRunning ; then rc_failed 0 else rc_failed 7 fi fi rc_status -v ;; stop) echo -n "Shutting down iCal2GW ($APP_DIR)" ## Stop daemon with killproc(8) and if this fails ## set echo the echo return value. if appIsRunning ; then kill `cat $APP_PID` # wait 60 sec for stop at maximum wait_sec=60 while [ "$wait_sec" != "0" ] ; do sleep 1 if ! appIsRunning ; then # the webmon server is stoped, end the loop wait_sec=0 break fi wait_sec=$((wait_sec -1))
15
done fi # if tomcat is __still__ running, try it with kill -9 if appIsRunning ; then kill -9 `cat $APP_PID` # wait 60 sec for stop at maximum wait_sec=60 while [ "$wait_sec" != "0" ] ; do sleep 1 if ! appIsRunning ; then # theTomcat server is stoped, end the loop wait_sec=0 break fi wait_sec=$((wait_sec -1)) done fi # check the final status if appIsRunning ; then rc_failed 1 else rc_failed 0 fi rc_status -v ;; try-restart) ## Stop the service and if this succeeds (i.e. the ## service was running before), start it again. ## Note: try-restart is not (yet) part of LSB (as of 0.7.5) $0 status >/dev/null && $0 restart # Remember status and be quiet rc_status ;; restart) ## Stop the service and regardless of whether it was ## running or not, start it again. $0 stop $0 start # Remember status and be quiet rc_status ;; force-reload) ## Signal the daemon to reload its config. Most daemons ## do this on signal 1 (SIGHUP). ## If it does not support it, restart. echo -n "Reload service iCal2GW $($APP_BASE)" ## if it supports it: #killproc -HUP $TOMCAT_BIN #touch /var/run/FOO.pid #rc_status -v ## Otherwise: $0 stop && $0 start
16
rc_status ;; reload) ## Like force-reload, but if daemon does not support ## signalling, do nothing (!) # If it supports signalling: #echo -n "Reload service FOO" #killproc -HUP $TOMCAT_BIN #touch /var/run/FOO.pid #rc_status -v ## Otherwise if it does not support reload: rc_failed 3 rc_status -v ;; status) echo -n "Checking for iCal2GW ($APP_DIR)" ## Check status with checkproc(8), if process is running ## checkproc will return with exit status 0. # # # # #
Status has a slightly different for the status command: 0 - service running 1 - service dead, but /var/run/ pid file exists 2 - service dead, but /var/lock/ lock file exists 3 - service not running
# NOTE: checkproc returns LSB compliant status values. if appIsRunning ; then rc_failed 0 else rc_failed 3 fi rc_status -v ;; probe) ## Optional: Probe for the necessity of a reload, ## give out the argument which is required for a reload. ;; *) echo "Usage: $0 {start|stop|status}" exit 1 ;; esac rc_exit
17