26.03.2021
2492
13
0Jira Version 8.4 mit eigener DB in Sandbox geklont kein Login möglich
Hallo zusammen,
kennt sich wer mit Jira aus. Wir haben das installiert und es lauft mit eigener DB in dbconfig.xml ist es auch ein Localhost der angesprochen wird
Das Problem ist , der produktive lauft in einer VMWARE Umgebung . Der lokale Admin User wurde getestet und das Passwort geht.
Nun starte ich einen Clone im VMWARE und kopiere diesen Server in VMWARE in eine Sandbox Umgebung hoch.
Nichtmal das Passwort vom Admin geht, der ja lokal ohne LDAP ist geht. Nun habe ich Dateien geprüft wie server.xml . Da den neuen Proxynamen eingetragen.
Passwort geht nicht.
Dann den Jira in einen Recovery Mode gesetzt.
confluence.atlassian.com/jira/retrieving-the-jira-administrator- ...
Passwort gesetzt. Auch das geht dann nicht. Irgendwo muss ein File oder Eintrag sein, der wohl die DB ins Nirvana sendet.
Auf Original Server habe ich eine Sicherung gestartet und habe XML Dateien. Da ein Search and Replace gemacht.
Aber diese kann ich ja nicht einspielen, da ich nicht einloggen kann im Clone . Weiss hier jemand wie dies zu lösen ist.,
War heute schon 8 Stunden am hin und her schauen.
Gruss
Jonas
kennt sich wer mit Jira aus. Wir haben das installiert und es lauft mit eigener DB in dbconfig.xml ist es auch ein Localhost der angesprochen wird
Das Problem ist , der produktive lauft in einer VMWARE Umgebung . Der lokale Admin User wurde getestet und das Passwort geht.
Nun starte ich einen Clone im VMWARE und kopiere diesen Server in VMWARE in eine Sandbox Umgebung hoch.
Nichtmal das Passwort vom Admin geht, der ja lokal ohne LDAP ist geht. Nun habe ich Dateien geprüft wie server.xml . Da den neuen Proxynamen eingetragen.
Passwort geht nicht.
Dann den Jira in einen Recovery Mode gesetzt.
confluence.atlassian.com/jira/retrieving-the-jira-administrator- ...
Passwort gesetzt. Auch das geht dann nicht. Irgendwo muss ein File oder Eintrag sein, der wohl die DB ins Nirvana sendet.
Auf Original Server habe ich eine Sicherung gestartet und habe XML Dateien. Da ein Search and Replace gemacht.
Aber diese kann ich ja nicht einspielen, da ich nicht einloggen kann im Clone . Weiss hier jemand wie dies zu lösen ist.,
War heute schon 8 Stunden am hin und her schauen.
Gruss
Jonas
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 665182
Url: https://administrator.de/forum/jira-version-8-4-mit-eigener-db-in-sandbox-geklont-kein-login-moeglich-665182.html
Ausgedruckt am: 07.07.2025 um 06:07 Uhr
13 Kommentare
Neuester Kommentar
Moin Jonas,
findet die Authentifizierung in Jira gegen ein LDAP statt?
Dann wird das nicht fkt. solonge der Clone kein Zugriff auf das LDAP hat. Nun hängt es vom LDAP und der Anbindung ab
z.B.
SAML SSO könnte man umgehen (sofern es im SAML Plugin von Jira erlaubt ist) schau mal ob was dabei ist
google.com/search?q=jira+login+nosso&oq=Jira+login+nos&a ...
oder Du deaktivierst die Benutzerverwaltung über LDAP und aktivierst die Jira interne (nur damit fkt. der Paswort Reset) - über die DB
Tabelle cwd_directory - Spalte active (0 oder 1)
ggf. vorher ein Backup der DB/Tabelle ist ja aber eh schon ein Clone
findet die Authentifizierung in Jira gegen ein LDAP statt?
Dann wird das nicht fkt. solonge der Clone kein Zugriff auf das LDAP hat. Nun hängt es vom LDAP und der Anbindung ab
z.B.
SAML SSO könnte man umgehen (sofern es im SAML Plugin von Jira erlaubt ist) schau mal ob was dabei ist
google.com/search?q=jira+login+nosso&oq=Jira+login+nos&a ...
oder Du deaktivierst die Benutzerverwaltung über LDAP und aktivierst die Jira interne (nur damit fkt. der Paswort Reset) - über die DB
Tabelle cwd_directory - Spalte active (0 oder 1)
ggf. vorher ein Backup der DB/Tabelle ist ja aber eh schon ein Clone
Hallo,
ja genau. Der Master, das Original hat LDAP. Darum habe ich ja dem Administrator der scheinbar nicht LDAP ist geprüft
, das das Passwort funktioniert. Bevor ich einen Clone erstellte. Dieser Admin muesste ja gehen, da kein LDAP meiner Meinung nach. Was aber nicht der Fall offensichtlich ist.
Dieser ist ja "Jira Internal Directory". Darum wundert es mich, das dann dieser "Admin" am Clone nicht geht.
Leider kann ich beim Master nicht mal das LDAP mal deaktivieren um zu klonen, da der Server höchst Produktiv ist.
Ich habe ja einen Lokale DB. kann ich das cwd_directory in einen File setzen ?
Der Links ist noch leicht verwirrend, ich schaue das aber an
Gruss
Jonas
ja genau. Der Master, das Original hat LDAP. Darum habe ich ja dem Administrator der scheinbar nicht LDAP ist geprüft
Dieser ist ja "Jira Internal Directory". Darum wundert es mich, das dann dieser "Admin" am Clone nicht geht.
Leider kann ich beim Master nicht mal das LDAP mal deaktivieren um zu klonen, da der Server höchst Produktiv ist.
Ich habe ja einen Lokale DB. kann ich das cwd_directory in einen File setzen ?
Der Links ist noch leicht verwirrend, ich schaue das aber an
Gruss
Jonas
benutzt ihr ein SSO Plugin oder Atlassian Crowd, OpenLDAP, MS AD?
Ein SSO Plugin z.B. mit Anbindung über SAML an Azure könnte man wie folgt umgehen
Jira Server or Jira Data Center: https://<baseurl>/login.jsp?nosso
in irgendwelchen "Files" wirst Du da nichts machen können. Da bleibt nur SQL auf der DB des Clones.
was ergibt denn ein
und ggf.
Ein SSO Plugin z.B. mit Anbindung über SAML an Azure könnte man wie folgt umgehen
Jira Server or Jira Data Center: https://<baseurl>/login.jsp?nosso
in irgendwelchen "Files" wirst Du da nichts machen können. Da bleibt nur SQL auf der DB des Clones.
was ergibt denn ein
SELECT * FROM cwd_directory;SELECT * FROM cwd_directory_attribute;
Die dbconfig.xml enthält vorwiegend Konfigurationselemente zur Datenbank.
Du hast von einem Proxy gesprochen - deshalb stelle bitte auch die server.xml hier rein (VORHER gucken, ob da Passwörter drin sind und diese dann rausnehmen, gelle?
).
Standardort für die Datei ist /opt/atlassian/jira/conf/server.xml
Außerdem schau mal bitte in die Logdatei im Datenverzeichnis, Standardort ist
/var/atlassian/application-data/jira/log/atlassian-jira.log
Interessant wären Einträge mit Fehlern, wo etwas von "PKIX" steht. Dann ist vielleicht ein Proxy mit SSL im Einsatz, dessen Zertifizierungsstelle Jira nicht bekannt ist (selbst signiert). Alternativ wird eventuell auch auf LDAP per SSL zugegriffen. In den meisten Fällen handelst es sich um ein "internes" (eben selbst signiertes) Zertifikat. Sofern man nicht selbst dafür sorgt, dass die Zertfikate im "truststore" bzw. den "cacerts"-Keystores landen, akzeptiert Jira keinen Verbindungsaufbau dazu.
Nichtsdestotrotz müsste eigentlich das Benutzen eines Recovery-Accounts (Option "atlassian.recovery.password") immer funkionieren. Siehe confluence.atlassian.com/jirakb/restore-passwords-to-recover-adm ...
Wenn das auch nicht funktioniert, dann könnte es noch eine arg fehlerhaft Basis URL sein, siehe confluence.atlassian.com/jirakb/change-the-base-url-of-jira-serv ...
Was immer wieder gerne passiert ist auch der "Cookie-Schluckauf". Wenn Du immer im gleichen Webbrowser arbeitest, dann landen dort Cookies bzw. Daten im local storage, die sich bei Original und Klon der VM überschneiden. Am besten in einem privaten Browser-Tab arbeiten oder mal alle Cookies und lokale Browserdaten löschen. Das INSBESONDERE dann, wenn es sich um einen Klon handelt, denn dann kopierst Du auch die "Server ID", die eigentlich immer eindeutig sein soll. Die wird von Atlassian u.a. dafür benutzt, um Application Links (Anwendungsverknüüfungen) zu anderen Atlassian Tools wie Confluence, Crowd oder Bitbucket herzustellen.
Klonen in direktes Inbetriebnehmen ist deshalb eine schlechte Idee. Wenn die Instanz noch relativ klein ist (Daten <= 1-3 GiB), dann reicht eigentlich der interne Backupmechanismus von Jira aus. Die damit erstellte ZIP wird auf einem anderen, frisch eingerichteten Jira importiert. Zusätzlich muss man meist noch die Attachments und die Logos der Instanz manuell kopieren. Damit hättest Du auf jeden Fall eine eigenständige Server ID.
Du hast von einem Proxy gesprochen - deshalb stelle bitte auch die server.xml hier rein (VORHER gucken, ob da Passwörter drin sind und diese dann rausnehmen, gelle?
).Standardort für die Datei ist /opt/atlassian/jira/conf/server.xml
Außerdem schau mal bitte in die Logdatei im Datenverzeichnis, Standardort ist
/var/atlassian/application-data/jira/log/atlassian-jira.log
Interessant wären Einträge mit Fehlern, wo etwas von "PKIX" steht. Dann ist vielleicht ein Proxy mit SSL im Einsatz, dessen Zertifizierungsstelle Jira nicht bekannt ist (selbst signiert). Alternativ wird eventuell auch auf LDAP per SSL zugegriffen. In den meisten Fällen handelst es sich um ein "internes" (eben selbst signiertes) Zertifikat. Sofern man nicht selbst dafür sorgt, dass die Zertfikate im "truststore" bzw. den "cacerts"-Keystores landen, akzeptiert Jira keinen Verbindungsaufbau dazu.
Nichtsdestotrotz müsste eigentlich das Benutzen eines Recovery-Accounts (Option "atlassian.recovery.password") immer funkionieren. Siehe confluence.atlassian.com/jirakb/restore-passwords-to-recover-adm ...
Wenn das auch nicht funktioniert, dann könnte es noch eine arg fehlerhaft Basis URL sein, siehe confluence.atlassian.com/jirakb/change-the-base-url-of-jira-serv ...
Was immer wieder gerne passiert ist auch der "Cookie-Schluckauf". Wenn Du immer im gleichen Webbrowser arbeitest, dann landen dort Cookies bzw. Daten im local storage, die sich bei Original und Klon der VM überschneiden. Am besten in einem privaten Browser-Tab arbeiten oder mal alle Cookies und lokale Browserdaten löschen. Das INSBESONDERE dann, wenn es sich um einen Klon handelt, denn dann kopierst Du auch die "Server ID", die eigentlich immer eindeutig sein soll. Die wird von Atlassian u.a. dafür benutzt, um Application Links (Anwendungsverknüüfungen) zu anderen Atlassian Tools wie Confluence, Crowd oder Bitbucket herzustellen.
Klonen in direktes Inbetriebnehmen ist deshalb eine schlechte Idee. Wenn die Instanz noch relativ klein ist (Daten <= 1-3 GiB), dann reicht eigentlich der interne Backupmechanismus von Jira aus. Die damit erstellte ZIP wird auf einem anderen, frisch eingerichteten Jira importiert. Zusätzlich muss man meist noch die Attachments und die Logos der Instanz manuell kopieren. Damit hättest Du auf jeden Fall eine eigenständige Server ID.
Hallo Kadde,
das SSO Plugin ist glaub nicht drin. Ich muss mich immer neu anmelden. DAs ?.nosso anhängen hatte ich gestern getestet funktionierte nicht.
In dem DB dbconfig File ist Localhost. Ich weiss nicht wie ich die Lokale DB ansprechen. Wo kann ich deise SQL Selects absetzen ?
Gruss
Jonas
das SSO Plugin ist glaub nicht drin. Ich muss mich immer neu anmelden. DAs ?.nosso anhängen hatte ich gestern getestet funktionierte nicht.
In dem DB dbconfig File ist Localhost. Ich weiss nicht wie ich die Lokale DB ansprechen. Wo kann ich deise SQL Selects absetzen ?
Gruss
Jonas
Hallo ,
danke für den Inpit.
Ich habe Server xml
Im Log konnte ich nichts mit PKIK finden.
Der PAsswort Reset geht defininitv nicht. Wurde gestern 2 Stunden hin und her getestet. Das Anmeldfenster war immer gelb.
Und es stand klar RecoverModus da. Hatte es mit einfachen und komplexen PWs probiert in dem File Edit.
Mit ist im Jira noch nicht klar, wo ich die SQL Befehle absetze. Laut dm, DB File wird eine Localhost angesprochen.
Gruss
Jonas
danke für den Inpit.
Ich habe Server xml
Der PAsswort Reset geht defininitv nicht. Wurde gestern 2 Stunden hin und her getestet. Das Anmeldfenster war immer gelb.
Und es stand klar RecoverModus da. Hatte es mit einfachen und komplexen PWs probiert in dem File Edit.
Mit ist im Jira noch nicht klar, wo ich die SQL Befehle absetze. Laut dm, DB File wird eine Localhost angesprochen.
Gruss
Jonas
die DB Verbindungsdaten stehen in der dbconfig.xml die Du oben gepostet hast.
in Deinem Fall eine MySQL DB auf dem Standardport.
Es sollte über die shell bzw. Kommandozeile möglich sein sich mit
anzumelden und dort die SQL Statements abzusetzen
in Deinem Fall eine MySQL DB auf dem Standardport.
Es sollte über die shell bzw. Kommandozeile möglich sein sich mit
mysql -u<username> -p<password> jira
Hallo,
ich bin im Vmware direct auf Server auf Commando Zeile. Leider geht das absetzen so nicht.
Gruss
Ralf
Doch jetzt gehts....
Nach DB connect stand es so da
ich bin im Vmware direct auf Server auf Commando Zeile. Leider geht das absetzen so nicht.
Gruss
Ralf
Doch jetzt gehts....
Nach DB connect stand es so da
der Auszug vom Log ist vom 02.03.2021
in der server.xml die Einträge secure , proxyname und proxyport entfernen - Jira neustarten
mach mal ein tail auf das logfile und versuche dich anzumelden (<ip-des-servers>:8080)
sowie auf das logfile unter /opt/atlassian/jira/logs/catalina.out
ob der Tomcat überhaupt korrekt startet
in der server.xml die Einträge secure , proxyname und proxyport entfernen - Jira neustarten
mach mal ein tail auf das logfile und versuche dich anzumelden (<ip-des-servers>:8080)
sowie auf das logfile unter /opt/atlassian/jira/logs/catalina.out
ob der Tomcat überhaupt korrekt startet
nach -u und -p kein Leezeichen und ohne "<>"
Hallo,
vielen Dank. Nachdem ich die Server.xml wie erwähnt Einträge löschte , ging es. Proxy Eintrag mag er nicht. Aber auch das scheme https nicht etc..
Da es test ist, reicht http.
Vielen DAnk
Gruss
Jonas
vielen Dank. Nachdem ich die Server.xml wie erwähnt Einträge löschte , ging es. Proxy Eintrag mag er nicht. Aber auch das scheme https nicht etc..
Da es test ist, reicht http.
Vielen DAnk
Gruss
Jonas
Unter Settings , musste ich noch Base URL danach anpassen.
Siehe meine Mail vorher - wenn dort ein https-Proxy eingetragen war und das Teil auf "localhost" lief, dann bin ich mir sicher, dass es etwas mit selbst signierten Zertifikaten zu tun hatte. Oder dass der Proxy überhaupt nicht erreichbar ist.
Es wäre hilfreicher, wenn Du statt der Screenshots (wo eine Menge Informationen fehlt) die Logdateien bzw. die Konfigurationsdateien hier postest. Bei den Logdateien dann nicht alles, sondern erst ab da, wo ein Fehler auftritt.
Das Folgende kann ich leider nicht rücksichtsvoller Formulieren - ich probiere es trotzdem:
Es hat den Anschein, dass Du das nicht allzu oft machst bzw. die Admin-Tätigkeit nicht Deine Hauptaufgabe ist. Wenn der Betrieb von Jira für Dich wichtig ist, würde ich Dir raten, dass Du Hilfe bei einem Atlassian-Partner in der Nähe suchst. Du kannst Google dazu benutzen. Alle Atlassian-Partner haben Erfahrung mit den on-premises Produkten von Atlassian. Es ist eventuell auch preiswerter, gleich einen Atlassian-Partner einzuschalten, der solche Probleme in 2-3 Stunden gelöst hat, statt selber Stunden oder sogar Tage damit zu verbringen, erst einmal das Problem zu finden.
Noch etwas zu Testinstanzen: wenn dort personenbezogene Daten verarbeitet werden (was bei Jira automatisch der Fall ist, weil dort Namen und Mailadressen gespeichert werden), dann reicht "HTTP" aus Datenschutzgründen nicht aus. Stand der Technik ist "HTTPS" bzw TLS 1.2. Bei Jira bekommt man das am schnellsten und einfachsten hin, wenn man die in Jira eingebauten SSL-Mechanismen NICHT benutzt, sondern einen einfachen SSL-Endpunkt vorschaltet und statt dessen in der server.xml einen Proxy konfiguriert. Eine Möglichkeit ist, "stunnel" zu benutzen.
Das Problem bei Jira ist, dass wenn man SSL in einem eigenen Keystore auf Port 443 benutzt, man das System umkonfigurieren muss, weil Jira in der Standardinstallation mit einem nicht priviligiertem Useraccount ("jira") läuft. Und der kann keine Prozesse starten, die auf Ports kleiner 1024 laufen. Dazu müsste man Jira dann als "root" laufen lassen oder andere Dinge ändern. Gleiches gilt auch für Port 80 für "HTTP". Deshalb ist "stunnel" oder ein HAproxy oder meinetwegen auch nginx die bessere Lösung. Für stunnel benötigt man allerdings nur eine einzige Konfigurationsdatei mit 2-3 Zeilen.
Es wäre hilfreicher, wenn Du statt der Screenshots (wo eine Menge Informationen fehlt) die Logdateien bzw. die Konfigurationsdateien hier postest. Bei den Logdateien dann nicht alles, sondern erst ab da, wo ein Fehler auftritt.
Das Folgende kann ich leider nicht rücksichtsvoller Formulieren - ich probiere es trotzdem:
Es hat den Anschein, dass Du das nicht allzu oft machst bzw. die Admin-Tätigkeit nicht Deine Hauptaufgabe ist. Wenn der Betrieb von Jira für Dich wichtig ist, würde ich Dir raten, dass Du Hilfe bei einem Atlassian-Partner in der Nähe suchst. Du kannst Google dazu benutzen. Alle Atlassian-Partner haben Erfahrung mit den on-premises Produkten von Atlassian. Es ist eventuell auch preiswerter, gleich einen Atlassian-Partner einzuschalten, der solche Probleme in 2-3 Stunden gelöst hat, statt selber Stunden oder sogar Tage damit zu verbringen, erst einmal das Problem zu finden.
Noch etwas zu Testinstanzen: wenn dort personenbezogene Daten verarbeitet werden (was bei Jira automatisch der Fall ist, weil dort Namen und Mailadressen gespeichert werden), dann reicht "HTTP" aus Datenschutzgründen nicht aus. Stand der Technik ist "HTTPS" bzw TLS 1.2. Bei Jira bekommt man das am schnellsten und einfachsten hin, wenn man die in Jira eingebauten SSL-Mechanismen NICHT benutzt, sondern einen einfachen SSL-Endpunkt vorschaltet und statt dessen in der server.xml einen Proxy konfiguriert. Eine Möglichkeit ist, "stunnel" zu benutzen.
Das Problem bei Jira ist, dass wenn man SSL in einem eigenen Keystore auf Port 443 benutzt, man das System umkonfigurieren muss, weil Jira in der Standardinstallation mit einem nicht priviligiertem Useraccount ("jira") läuft. Und der kann keine Prozesse starten, die auf Ports kleiner 1024 laufen. Dazu müsste man Jira dann als "root" laufen lassen oder andere Dinge ändern. Gleiches gilt auch für Port 80 für "HTTP". Deshalb ist "stunnel" oder ein HAproxy oder meinetwegen auch nginx die bessere Lösung. Für stunnel benötigt man allerdings nur eine einzige Konfigurationsdatei mit 2-3 Zeilen.
