Neue Updates: JIRA, JIRA Service Desk, JIRA Core und Bitbucket Server

jira-software-7-12-3-bugfix-update-internetblogger-de

Hallo Blogleser und Admin der Atlassian Apps! Kürzlich sind zahlreiche Atlassian Apps Updates erschienen, die ich meinen Instanzen bereits spendierte. In diesem Blogpost möchte ich dir die Update-Prozedur etwas näher bringen und gerne schildern.

Es gilt einiges beim Updaten einer Atlassian App zu beachten und wenn man sich noch nicht so sehr einfuchste, kann es zu Problemen führen. Meistens konnte ich mir bisher immer aushelfen, wenn es Probleme gab. Es bedeutet auch, dass du immer mit der Google Suche gut umgehen solltest und du suchst oft auf den Atlassian Seiten nach Problemlösungen. Atlassian Entwickler und Macher verfügen über eine sehr gute Doku auf eigenen Webseiten, sodass in der Regel alle Probleme schon mehrmals angesprochen wurden.

Erschienen sind Updates von JIRA, JIRA Core, JIRA Service Desk und Bitbucket Server und darunter werde ich diese Updates gerne etwas näher betrachten.

JIRA Software auf die neue Version 7.12.3 aktualisieren – wie geht das?

Das jeweilige Update bekam neue Bugfixes, so genannte Fehlerbehebungen, die du bereits heute unter https://confluence.atlassian.com/jirasoftware/issues-resolved-in-7-12-3-959308127.html nachschauen kannst. Mein Update unter https://jira.hro-mv.de war mir gut gelungen.

Gewöhne es dir an, ab und an nach “release notes” einer Atlassian App in Google zu suchen, denn dadurch erfährst vom eigentlichen Update und muss dann eventuell handeln. In der Regel sind es alles geprüfte und stabile Atlassian Apps Updates.

Von den Atlassian Webseiten lädst du dir den Linux-BIN-Installer für JIRA Software Server herunter, lädst es unentpackt ins Verzeichnis /usr/bin in Lunux OS hoch. Danach bist in der Konsole als “root” und navigierst zum Verzeichnis so.

cd /usr/bin

Alle Bin-Installer bei Atlassian-Updates bekommen den CHMOD 755, damit sie ausführbar sind.

Von diesem Verzeichnis aus, was jetzt für JIRA Software gilt, führst du diesen SSH-Befehl in der Konsole aus.

./atlassian-jira-software-7.12.3-x64.bin

Du musst beim Downloaden des Linux-BIN-Installers auf die OS Version achten, denn es kann sein, dass du entweder die 32-oder-64bit-Version bei dir auf dem Rootserver hast. Daher bitte etwas unterscheiden. Der obige SSH-Befehl ist für die 64bit-Version, die mir unter Centos 7.5 vorliegt.

Den Befehl führst du aus und bleibe bitte bei der Konsole, denn du wirst dort nach Sachen gefragt, was gemacht werden muss. Du musst ein Upgrade einer bereits existenten JIRA Installation machen. So steht es in der Konsole dementsprechend das Ganze auf Englisch.

Achte auch darauf, dass du im Installer via SSH den richtigen Pfad zu dem JIRA-Installationsverzeichnis angibst. Es wird dann meistens so sein.

/opt/atlassian/jira

Wenn es anders ist, musst du es dann auch so angeben. Das Home-Verzeichnis bei Atlassian Apps hat diesen Pfad in Server.

/var/atlassian/application-data/jira

/var/atlassian/application-data/bitbucket

/var/atlassian-application-data/confluence

und so weiter.

Ich habe meine JIRA Server Instanz bereits mit https und beim Update der Instanz wird geprüft, ob du lokale Modifizierungen vornahmst. Das wird bei https die Datei server.xml sein. Sie befindet sich unter /opt/atlassian/jira/conf/server.xml.

Sie kannst du vor dem Update bitte backupen. Darin wird nämlich der Connector-Port auf 8080 zurückgesetzt. Wenn du JIRA aber unter SSL hast und noch mehrere Atlassian Apps im Server hast, wird der Port anders sein.

Damit es mit https bei JIRA App klappt, musst du in der server.xml den dafür vorgesehenen Abschnitt aktivieren. Entferne bitte dabei das:

<!--

-->

Der Abschnitt sieht dann meistens derart aus.

 <Connector port="8060" relaxedPathChars="[]|" relaxedQueryChars="[]|{}^&#x5c;&#x60;&quot;&lt;&gt;"
maxThreads="150" minSpareThreads="25" connectionTimeout="20000" enableLookups="false"
maxHttpHeaderSize="8192" protocol="HTTP/1.1" useBodyEncodingForURI="true" redirectPort="8443"
acceptCount="100" disableUploadTimeout="true" bindOnInit="false" secure="true" scheme="https"
proxyName="servicedesk.apps-tools-cms.de" proxyPort="443"/>

Es wird bei diesen Apps immer dasselbe sein, aber dennoch empfehle ich es dir, erst nach dem Update, ohne JIRA zu starten, diesen Abschnitt an den generischen Port und die Domain anzupassen. Ganz zum Schluss beim Aktualisieren, starte JIRA einfach nicht und öffne die server.xml Datei. So kannst du dann arbeiten.

In der Apache-Datei httpd.conf muss es dementsprechend dann in etwa so aussehen.

DocumentRoot "/opt/atlassian/jiradesk"


ProxyRequests On
ProxyVia On
Timeout 2400
ProxyTimeout 2400
ProxyBadHeader Ignore

<Proxy *>
Require all granted
</Proxy>

ProxyPass / http://servicedesk.apps-tools-cms.de:8060/
ProxyPassReverse / https://servicedesk.apps-tools-cms.de/

Das gilt bei mir für https. Diese Datei erstellt Plesk selbst, je nach Aktivierung von Lets Encrypt oder eben nur unter Port 80 mit “http”. So kannst du schauen, wie das Ganze dann hinterlegt werden kann.

Nun kommen wir zum Update von JIRA Core.

JIRA Core aktualisieren auf die neue Version 7.12.3

Im Blogpost unter https://confluence.atlassian.com/jiracore/issues-resolved-in-7-12-3-959308125.html haben die Entwickler einige Issues festgehalten, die das Update ausmachten und so weisst du, was alles verbessert wurde.

Den Linux-BIN-Installer für JIRA Core besorgst du dir von den Atlassian Webseiten, lädst es wiederum ins Verzeichnis /usr/bin hoch und von diesem Verzeichnis aus, führst du den unteren SSH-Befehl aus.

./atlassian-jira-core-7.12.3-x64.bin

Beobachte bitte dabei das Update via Kommandozeile, weil du wieder nach Aktion gefragt wirst. Am Ende JIRA Core entweder starten oder nicht, je nachdem, ob deine JIRA Core Instanz unter SSL oder mit http läuft. Die Datei server.xml im Verzeichnis /conf wird immer editiert, wenn du mit SSL arbeitest und bei neuem Update wird sie überschrieben. Daher bedarf es wiederum neuer Anpassungen an die momentane Situation.

Atlassian Apps werden immer als User der jeweiligen App gestartet.

So kannst du in der Konsole zum User wechseln mit diesen Befehlen.

su jira

su confluence

su jira2

su jira3

etc.pp.

Danach navigierst du zum /bin-Verzeichnis so.

cd /opt/atlassian/jira/bin

Von dort aus startest du deine JIRA, JIRA Core, JIRA Service Desk Instanz derart neu oder stoppst es, wenn du irgendwelche Änderungen vornimmst.

sh stop-jira.sh

sh start-jira.sh

Jetzt kommen wir zum Update von JIRA Service Desk.

JIRA Service Desk auf die neue Version 3.15.3 aktualisieren

Unter https://confluence.atlassian.com/servicedesk/issues-resolved-in-3-15-3-959308126.html gibt es wiederum einen Post mit den erledigten Tickets beim Service Desk in JIRA. Du kannst dir auch hierbei den LINUX-BIN-Installer von den Atlassian Seiten downloaden, lädst es ins Verzeichnis /usr/bin hoch und führst von dort aus diesen SSH-Befehl via Konsole aus.

./atlassian-servicedesk-3.15.3-x64.bin

Atlassian Apps in Server haben unterschiedliche User, sodass dir die Konsole etwas hilft, wenn du zum Beispiel zum Verzeichnis /opt/atlassian/jira/bin navigiert hast und von dort aus JIRA App starten willst. Wenn der User nicht stimmt, tippst du va SSH “exit” ein und wechselst mit “su user” zu dem richtigen User der App. So musst du dir das einprägen.

Falls eine App mit dem alten Prozess läuft und du so JIRA nicht starten kannst, checke es bitte mit dem unteren Befehl via Kommandozeile.

ps -aux | grep jira

ps -aux | grep confluence

ps -aux | grep jiradesk

ps -aux | grep jiracore

und so weiter.

Danach entdeckst du in der obigen Zeile die Prozess-ID. Den Prozess beendest du dann einfach mit diesem Befehl.

kill -9 <pidid>

Die “pidid” steht dann in der Zeile mit dem Verzeichnis, von welchem aus eine JIRA App startet. Das kannst du via Konsole nicht übersehen.

Zum Schluss zeige ich dir noch das Bitbucket Server Update, welches ich gestern Nacht vollbrachte. Meine Bitbucket Instanz ist ebenfalls mit “https” und so musste ich im Verzeichnis /var/atlassian/application-data/bitbucket/shared/bitbucket.properties diese Zeilen eintragen.

server.secure=true
server.scheme=https
server.proxy-port=443
server.proxy-name=bitbucket.apps-tools-cms.de

Das gilt für SSL und wir so gehandhabt.

Updaten einer Bitbucket Server App auf die neue Version 5.15

Hier musst du ebenfalls den LINUX-Bin-Installer von den Atlassian Webseiten downloaden, lädst es unentpackt ins Verzeichnis /usr/bin hoch. Danach musst du den Installer so ausführen.

./atlassian-bitbucket-5.15.0-x64.bin

Bei Bitbucket haben wir keine server.xml-Datei unter /conf. Ich habe SSL via bitbucket.properties-Datei ermöglicht und ebenfalls muss in Plesk die jeweilige Subdomain SSL aktiviert haben.

Die Base-URL bei den Atlassian Apps muss dementsprechend auf https angepasst werden. Wenn du von http zu https umstellst, empfehle ich es dir, dich zuerst im Backend einer App einzuloggen, die Base-URL zu ändern und erst dann Server-Anpassungen vorzunehmen. Andernfalls kommst du nicht mehr ins Backend hinein und kannst nichts mehr machen. Diese Erfahrungen musste ich kürzlich über mich ergehen lassen, habe es dann aber dennoch hinbekommen.

Bitbucket Server kann gerne als “root” in Rootserver so gestartet werden.

service atlbitbucket start

service atlbitbucket restart

service atlbitbucket stop

Beim Bitbucket Server Update entsteht immer eines neues Installations-Verzeichnis wie etwa unter /opt/atlassian/bitbucket/5.15.0. Dies gilt dann als Rootverzeichnis und muss in der Apache Datei httpd.conf so hinterlegt werden.

Erst dann kannst du Apache Service so neu starten.

service httpd restart

service atlbitbucket restart

Auch kannst du nach dem Bitbucket Prozess via SSH so suchen.

ps -aux | grep bitbucket

Das ist sehr hilfreich, wenn alte Prozesse vom alten Installationsverzeichnis laufen und Bitbucket nicht vom neuen Install-Verzeichnis im Browser starten kann. Daher kannst den jeweiligen Prozess beenden und startest Bitbucket als “root” via Konsole einfach neu.

Dieses Tutorial ist für Atlassian Apps Beginner und leicht Fortgeschrittene gedacht, weil die Profis es bereits kennen dürften. Ich bringe halt immer meine Erfahrungswerte mit ein und zeige dir, wie man was machen kann, wenn man ein Server-Admin ist und allerhand Atlassian Apps unter einem Dach hat. Sie müssen verschiedene generische Ports aufweisen, haben unterschiedliche Konfigurationen und den Inhalt von der httpd.conf-Datei.

Aus diesem Grunde muss sehr viel beachtet werden.

Ich hoffe, dass ich dir mit diesem Blogpost etwas helfen konnte und bei Fragen zu den SSH-Updates einer Atlassian App kannst du gern darunter feedbacken.

by Alexander Liebrecht

 

 

 

Neue Updates von Confluence Server und Bitbucket Server

bitbucket-server-5-14-bugfix-features-update-internetblogger-de

Hallo Blogleser! In diesem Blogpost zeige ich dir die neuesten Atlassian Updates von Confluence Server App und des Bitbucket Servers. Confluence ist in der Version 6.11.2 erschienen. Bitbucket Server kam als neue Version 5.14 heraus.

Beide Updates sind herzlich willkommen, denn dabei auch Fehler behoben wurden. Heute hatte ich etwas mehr zu tun mit Confluence Server, denn die Bereiche bzw. die Pages liessen sich nicht bearbeiten. Der Problemlösung kam ich dann recht fix auf die Schliche und konnte das Problem lösen. Dazu etwas weiter unten in diesem Blogpost.

Jetzt zeige ich dir den SSH-Befehl, mit welchem du den Confluence Server dieses Mal aktualisieren kannst. Es wird vom Verzeichnis /usr/bin aus ausgeführt. In der Kommandozeile achtest du bitte darauf, was dich der Installer fragt und reagierst dann dementsprechend.

Es muss ein Upgrade einer bereits existenten Confluence Installation gemacht werden. So in etwa wird es in SSH auf Englisch stehen. Nun zum Befehl.

./atlassian-confluence-6.11.2-x64.bin

Der obige SSH-Befehl gilt für ein 64bit Rootserver-System, weil mein System es hat. Bei 32-Bit-Versionen muss ein anderer BIN-Installer von den Atlassian Webseiten heruntergeladen werden. Das kennst du vermutlich bereits. Aber nur mal so nebenbei gemerkt.

Unter https://confluence.atlassian.com/doc/issues-resolved-in-6-11-1-957494856.html kannst du nachlesen, was gefixt wurde.

Lösen des Problems mit dem unmöglichen Editieren der Pages in Confluence

Um das Problem zu lösen, musst du im Confluence Backend oben rechts die Suchmaske verwenden. Du tippst dort den Begriff “gemeinschaftlich” ein. Es heisst voll ausgesprochen “gemeinschaftliches Bearbeiten” der Inhalte. Das muss dort dann deaktiviert werden. Es ist sicherlich ein Bug, welchen Confluence seit etlichen Versionen mit sich herumschleppt.

Früher hatte ich dieses Problem ebenfalls und löste es auf dieselbe Art und Weise, indem das gemeinschaftliche Bearbeiten deaktiviert wurde. Das ist der ganze Trick bei dem Problem. Danach kannst du wieder deine Seiten in Confluence Server super bearbeiten sowie speichern. Vorher lud der Editor nicht.

Nun etwas zum Bitbucket Server. Dieser erschien als neue Version 5.14, ebenfalls wie Confluence mit Fehlerbehebungen. Hinter dem Linkverweis wie unter https://confluence.atlassian.com/bitbucketserver/bitbucket-server-5-14-release-notes-956720375.html kannst du die Release Notes etwas studieren. Neu war zum Beispiel das Ermöglichen von MySQL 8.0, was noch sehr neu ist.

Auch MariaDB 10.3.7 wurde ermöglicht als Database Engine. Ich hatte beim Update meines MariaDB Servers in der Version 10.2.16 Probleme auf dem Rootserver und daher liess ich es sein. In den englischen Tutorials hiess es, man muss MariaDB ganz löschen, doch das darfst du im Falle von Plesk nicht. Es werden dabei sehr viele Plesk-Komponenten einfach mitgelöscht. Diese Erfahrung machte ich bereits. Aber ich konnte mir aushelfen, weil ich die Verzeichnisse, die dafür zuständig waren, woandershin verschob.

Updaten auf Bitbucket Server v5.14 – wie geht das?

./atlassian-bitbucket-5.14-x64.bin

Diesen Befehl führst du in der Konsole vom Verzeichnis /usr/bin aus. Vergibt bitte dem BIN-Installer vorher CHMOD-Rechte von 755, damit er ausführbar ist. Der Rest geschieht in SSH und zum Schluss kannst du Bitbucket mit dem unteren Befehl neu starten.

service atlbitbucket restart

Denke bitte noch daran, das mysql-Plugin nach /opt/atlassian/bitbucket/5.14.0/app/WEB-INF/lib hochzuladen. Andernfalls wird Bitbucket im Browser nicht starten.

Bitbucket Installer erstellt bei jedem Update ein neues Installationsverzeichnis mit dem neuen Pfad. Dieser muss als Root in der Apache-Datei httpd.conf hinterlegt werden. Danach solltest du Apache so neustarten.

service httpd restart

Auch denkst du an den generischen Port, weil ich weiss, dass es Tomcat Ports sind, an welchen Confluence und Bitbucket laufen. Ich habe es ja bei mir mit den beiden Linux-Apps so realisiert, dass ich mit SSL im Frontend arbeite. Das war ein wenig mehr Arbeit, aber ich hatte es hinbekommen. Dennoch ist der Port in der httpd.conf angegeben. Nur im Browser sind beide Apps so erreichbar.

  1. https://hro-mv.de / Confluence App
  2. https://bitbucket.apps-tools-cms.de / Bitbucket Server App

So viel dieses Mal zu Atlassian Updates und diese kannst du gerne mitnehmen, weil einiges verbessert oder neu eingeführt wurde. Bei Fragen zu SSH-Updates wende dich darunter in den Kommentaren an mich.

by Alexander Liebrecht

OpenProject v7.4.5 Bugfix-Update draussen

openproject-support-foren

Hallo Blogleser! Auch dieses Update werde ich dir nicht vorenthalten, denn es geht um eine weitere Linux App namens OpenProject, die ich unter http://op.apps-tools-cms.de laufen lasse.

 

Zum Update passend gibt es auch den offiziellen Blogpost unter https://www.openproject.org/openproject-7-4-5-released/ , was du dir hinterher mal ansehen kannst. Die neue OpenProject-Version v7.4.5 kam mit etlichen Verbesserungen sowie den Bugfixes, so genannten Fehlerbehebungen, daher. Ich habe gleich das offizielle Repo auf Github unter https://github.com/opf/openproject-ce/releases gecheckt und fand dadurch das neue Update.

Das wird dann gleich im eigenen Rootserver möglich gemacht und du brauchst lediglich das ce-repo nach /etc/yum.repos.d hochzuladen bzw. machtest es bereits bei der Erstinstallation von OpenProject. Das muss in diesem Verzeichnis zu finden sein, eher du mit “yum update” aktualisieren kannst. Das kannst du im Vorfeld checken.

Ich warte alles auf OP 4.8 mit neuem Wysiwyg-Editor

Das wird sehr spannend bis dahin, denn schon im Sommer dieses Jahres kommt OpenProject 4.8 auf den Markt. Dabei ist das eine Feature mit dem Wysiwyg-Editor sehr spannend, denn heute postest du in OP in der Textile-Sprache und kannst damit nicht so gut arbeiten. Entweder Markdown oder HTML, sage ich mir immer. Alle anderen Sprachen sind weniger nutzerfreundlich, zumindest aus meiner Nutzer/Admin-Sicht heraus gesehen.

Beide Linux Apps wie OP und Gitlab lassen sich bequemerweise mit “yum udpate” aktualisieren und damit es so ist, nimm bei der Erstinstallation immer den Package Installer so wie es in der offiziellen Doku steht. Nur so kannst du dann besser installieren und hast im Falle von OpenProject keinerlei Probleme mir rubygems oder rubys oder sonstigem, was du das haben wirst.

[bctt tweet=”#OpenProject #Bugfix #Update v7.4.5 draussen. Das Update kann ohne Probleme installiert werden!” username=”blogsash”]

So viel zu diesem Update und ich mag demnach auch kurze Blogposts schreiben, wenn es sich so anbietet. Diese sind leichter von dir, dem Leser, zu erfassen und solche Posts werden meistens bis zum Ende durchgelesen. Das weiss jeder Blogger. Ich wünsche dir erfolgreiches Upgraden deiner OP-Instanz und bei schwerwiegenden Problemen kannst du dich an das offizielle Support-Forum unter https://community.openproject.com/projects/openproject/boards wenden. Dort bekommst du meistens zeitnahe Hilfestellung bei allen OpenProject-Fragen und Problemen.

by Alexander Liebrecht

31.07.2015 war der System Administrator Appreciation Day

Hallo liebe Leser und Freunde des Feedbacks! Ich bekam da neulich eine interessante Pressmitteilung rein und möchte dieses Artikel darauf basieren und ein paar Infos daraus für hierfür verwenden. Gestern am 31. Juli 2015 war der Tag des System Administrators und ich weiss die Arbeit dieses Personenkreises sehr zu schätzen. Ich will auch meinen Webhostern … Weiterlesen