Nie, na szczęście nie na produkcji… Wyciągnąłem z szuflady starego laptopa z zainstalowanym Linuxem, ot tak żeby coś sprawdzić. Po tym jak zrobiłem co miałem zrobić przypomniało mi się, że przecież chyba kiedyś instalowałem na nim Jirę. Szybkie sprawdzenie w konsoli i tak! Okazało się, że jest! Moja radość nie trwała jednak długo.
Otworzyłem przeglądarkę, wszedłem na http://localhost:8080/ i oczom moim ukazał się znajomy widok. Login: admin, hasło: eeeee… No właśnie. Sprawdziłem wszystkie swoje „standardowe” i nic. Przejrzałem notatki, również bez skutku. Zapewne na szybko wybrałem jakieś łatwe do zapamiętania i oczywiste hasło… Tia, oczywiste.
Cóż. Pozostało mi dowiedzieć się jak odzyskać, a raczej pewnie zresetować hasło i przećwiczyć tą operację w praktyce. Czy się udało? Zaraz się dowiesz. Jak zapewne się domyślasz opisywał będę proces odzyskiwania hasła dla Jira w wersji serwer.
Nie taki diabeł straszny
Spodziewałem się, że będzie to coś zbliżonego do rocket science, że czeka mnie dłubanie w bazie danych, czy inne kombinacje, które zajmą sporo czasu. Okazało się jednak, że nie było to zbytnio skomplikowane i całość załatwiłem w czasie nie dłuższym niż 15 minut. Wszytko dzięki temu, że Atlassian dla Jira w wersji 7.0 wzwyż przygotował tryb recovery, znacznie ułatwiający zadanie.
Żeby móc skorzystać z tego trybu, trzeba mieć mieć dostęp do serwera, na którym jest zainstalowana aplikacja a największym minusem jest konieczność dwukrotnego restartu instancji. Z tego powodu jest to operacja do wykonania raczej po godzinach pracy, jeśli odzyskujesz hasło na środowisku produkcyjnym.
Tryb recovery działa na zasadzie stworzenia wirtualnego użytkownika o nazwie recovery_admin, do którego hasło ustawiasz w konfiguracji serwera Tomcat w jego zmiennych środowiskowych. Co ważne, kiedy Jira jest w trybie recovery użytkownicy mogą z niej korzystać tak jakby nic się nie działo.
Tylko uwaga – wspominam o tym na początku artykułu, w przypadku gdyby nie każdy doczytał do końca 😉 Po pierwsze pamiętaj, żeby nie zostawiać Jiry w recovery mode. Jak tylko odzyskasz hasło, skasuj zmienną środowiskową, o której mowa poniżej. Nie zostawiaj konta recovery_admin w systemie. Chociażby z tego powodu, że hasło do tego konta jest zapisane plain textem w plikach konfiguracyjnych. To niezdrowe podejście.
Po drugie, zawsze dobrze jest, żeby był więcej niż jeden user z uprawnieniami Jira Systam Administrator, żeby uniknąć zamieszania. W dużych instancjach produkcyjnych jest to raczej powszechne i wierzę, że tak jest i w Twoim przypadku 🙂
Zmiany w system properties
Tak jak napisałem wyżej, moja Jira jest postawiona na Linuxie. Z tego też powodu dalsze instrukcje będą dotyczyć tego właśnie systemu. Jeśli korzystasz w Windowsa to oczywiście też możesz skorzystać z trybu recovery, jednak operacje po stronie serwera wykonuje się, jak zapewne się domyślasz, trochę inaczej. Niestety nie opisałem tutaj co trzeba zrobić z Windowsem. Będziesz musiał pogooglać… Sorry…
Dobra, dość gadania, teraz konkrety co zrobiłem. Po pierwsze zatrzymałem aplikację:
# /etc/init.d/jira stop
Następnie w Jira installation directory odszukałem katalog /bin a w nim plik setenv.sh Jeśli zainstalowałeś Jirę w domyślnym katalogu to installation directory jest taka: /opt/atlassian/jira. Ja do edycji pliku korzystam z vim. Czyli całość w moim przypadku wyglądała tak:
# vim /opt/atlassian/jira/bin/setenv.sh
W pliku znalazłem fragment (powinien być gdzieś w okolicach początku):
# # Occasionally Atlassian Support may recommend that you set some specific JVM arguments. You can use this variable below to do that. # JVM_SUPPORT_RECOMMENDED_ARGS=""
Do JVM_SUPPORT_RECOMMENDED_ARGS pomiędzy "" dodałem -Datlassian.recovery.password=tu-wstaw-haslo Wyglądało to tak:
# # Occasionally Atlassian Support may recommend that you set some specific JVM arguments. You can use this variable below to do that. # JVM_SUPPORT_RECOMMENDED_ARGS="-Datlassian.recovery.password=dupa.8"
Przy okazji, słyszałeś kiedyś określenie „hasło lubelskie”? 🙂 dupa.8 to właśnie to hasło. Więcej o jego historii możesz poczytać chociażby tutaj: https://www.i-slownik.pl/2358,dupa-8/
Teraz uruchomiłem Jira:
# /etc/init.d/jira start
Po stronie serwera to na razie wszystko.
Logowanie do aplikacji
Po wprowadzeniu zmian po stronie serwera i odpaleniu aplikacji reszta jest prosta. Odpaliłem przeglądarkę i ponownie wszedłem na http://localhost:8080/ Zobaczyłem klasyczny ekran logowania z tą różnicą, że została dodana informacja o tym, że Jira pracuje w trybie recovery. Pozostało mi się zalogować na usera recovery_admin za pomocą hasła, które ustawiłem wyżej:
Po udanym logowaniu postępowałem już w zwykły sposób „trybik” > User management żeby dostać się do listy userów:
Jak widać okazało się, że username to jednak nie był admin więc hasło mogłem zgadywać długo i namiętnie. Musiałem wpaść na pomysł, żeby użytkownika admin nazwać inaczej 😉 Pozostało mi zmienić hasło. Tutaj też nie ma żadnej filozofii. Kliknąłem na Seweryn:
Potem po prawej na górze Actions i zmieniłem hasło:
I w zasadzie to wszystko. Dla sprawdzenia czy jest OK, wylogowałem się z recovery_admin i zalogowałem na seweryn. Tadam! Wszystko działa. Pozostało posprzątać.
Sprzątanie
Tak jak napisałem wyżej nie powinno się zostawiać Jiry w trybie recovery więc musiałem przywrócić poprzednie ustawienia w plikach.
Zatrzymałem Jirę:
# /etc/init.d/jira stop
Wyedytowałem setenv.sh:
# vim /opt/atlassian/jira/bin/setenv.sh
Usunąłem to co dodałem. Więc fragment konfiguracji powinien wyglądać tak:
# # Occasionally Atlassian Support may recommend that you set some specific JVM arguments. You can use this variable below to do that. # JVM_SUPPORT_RECOMMENDED_ARGS=""
Zapisałem plik, wystartowałem Jirę:
# /etc/init.d/jira start
I tyle 🙂 Po uruchomieniu aplikacji mogłem spokojnie logować się na swoje konto admina. Jak widzisz cała operacja nie była zbyt skomplikowana. Mimo wszystko życzę Ci żebyś nigdy nie musiał jej wykonywać 😉
