Archiwum kategorii: Aplikacje

Centos 7 + apache httpd >=2.4 + mod_wsgi + Python 3 + falcon

Odpalałem ostatnio prostą aplikacyjkę napisaną w pythonie 3 z wykorzystaniem frameworka falcon. Troszkę było kombinowania.
Nie poruszam tutaj kompletnie kwestii uprawnień, selinuxa itd. Zakładam też działające apache httpd i skonfigurowanego vhosta.

  1. Dodaj repozytorium IUS do Centosa 7

    yum install https://centos7.iuscommunity.org/ius-release.rpm
  2. Zainstaluj Python 3.6, mod_wsgi i pip.

    yum install python36u-mod_wsgi python36u-pip
  3. Stwórz środowisko wirtualne ‚app1’ potrzebne do uruchomienia aplikacji. Ścieżka przykładowa.

    sudo mkdir -p /srv/pythonenvs
    cd /srv/pythonenvs
    python3.6 -m venv app1
  4. Aktywuj venv dla swojej sesji

    source app1/bin/activate
  5. Zainstaluj falcona i wszystkie inne zależności

    (app1)$ pip install falcon
  6. Zakładam, że aplikację masz w katalogu /srv/app1/www, a ‚entry point’ to main.py. Bardzo ważne! Aplikacja musi się przedstawiać serwerowi wsgi jako ‚application’. To znaczy, że w kodzie falcon musi być odpalony w następujący sposób:

    api = application = falcon.API()
  7. Dodaj do konfiguracji vhosta:

    WSGIDaemonProcess app1 python-path=/srv/app1/www/ python-home=/srv/pythonenvs/app1
    WSGIProcessGroup app1
    WSGIScriptAlias / /srv/app1/www/main.py
    <Directory /srv/app1/www/>
    Require all granted
    </Directory>
  8. Teraz tylko restart httpd:

    systemctl restart httpd

Ochłap zaginął, Fallout 4

Może trochę nie na temat, ale… takie drobne ułatwienie dla graczy.

  1. Odpal konsolę (~)
  2. Wpisz ‚prid 0001d162’, enter
  3. Wpisz ‚moveto player’, enter
  4. Wyjdź z konsoli (~)

Ochłap powinien stać tuż obok 😉

Lista pozostałych towarzyszy, których można odzyskać w ten sam sposób:

  1. Cait: Human, Trigger Rush, Combat Zone, ID: 00079305
  2. Codsworth: Mister Handy (Robot), Robot Sympathy, Sanctuary Hills, ID: 0001ca7d
  3. Curie: Miss Nanny/Synth, Combat Medic, Vault81, ID: 00102249
  4. Paladin Danse: Human, Know Your Enemy, Cambridge Police Station, ID: 0005de4d
  5. Deacon: Human, Cloak & Dagger, Old North Church, ID: 00045ac9
  6. Dogmeat: Dog, Attack Dog, Red Rocket Truck Stop, ID: 0001d162
  7. John Hancock: Ghoul, Isodoped, Goodneighbor, ID: 00022615
  8. Robert MacCready: Human, Killshot, Goodneighbor, ID: 0002a8a7
  9. Nick Valentine: Synth, Close to Metal, Valut 114, ID: 00002f25
  10. Piper: Human, Gift of Gab, Diamond City, ID: 0002f1f
  11. Preston Garvey: Human, United We Stand, Concord, ID: 0001a4d7
  12. Strong: Super Mutant, Berserk, Trinity Tower, ID: 0003f2bb
  13. X6-88: Synth, Shield Harmonics, The Institute, ID: 0002e210a

 

Skradzione stąd: https://www.gameskinny.com/03cw4/fallout-4-companion-list-perks-locations-ids/

Zdalna edycja kodu

Zazwyczaj pracuję na Windowsie. A piszę programiki i skrypty stricte dla Linuxa.
VIMa kocham niezmiernie, ale są fajniejsze zabawki do takiej pracy. Na przykład Visual Studio Code, które mi wyjątkowo podpasowało.
VSCode ma fajną wtyczkę, dzięki której można po ssh edytować pliki na zdalnej maszynie ‚w locie’. Nie jest to może najwygodniejsza w konfiguracji metoda, ale z pomocą putty da się ogarnąć temat dość prosto 🙂
Wtyczka korzysta z rmate. Najrozsądniejsza wydaje mi się implementacja w bashu (ale jak ktoś lubi to jest też w RUBY, Pythonie, C i pewnie w kilku innych językach)

  1. Zainstaluj w VSCode dodatek Remote VSCode:
    ctrl+p wklej ext install remote-vscode
  2. Na zdalnej maszynie instalujemy ‚rmate’:
    sudo wget -O /usr/local/bin/rmate https://raw.github.com/aurora/rmate/master/rmate
    chmod a+x /usr/local/bin/rmate

    Wydaje mi się, że można bez żadnego uszczerbku na fajności, zaciągnąć sobie skrypt na lokalnego usera. System wide nie powinno być konieczne (aczkolwiek nie testowałem).
  3. Zestaw w putty tunel do maszyny na której chcesz edytować pliki. ‚Główna’ strona standardowo, natomiast Connection->SSH->Tunnels ustaw tak:
  4. CTRL-C „Remote: Start server”, następnie w VSCode -> Naciśnij F1, wklej i ENTER
  5. Na zdalnej maszynie wydaj komendę ‚rmate <plik_do_edycji>’. Pliczek powinien się automagicznie otworzyć w VSCode

W codziennej pracy odpalamy tylko punkty 3,4,5.

Plusy? Chyba widać. Da się ładnie edytować zdalnie zlokalizowane pliki ‚on-line’.

Minusy? Jeszcze nie rozgryzłem jak odpalać zdalnie zabawki typu golint. Na razie walidacja kodu robi mi się w pełni lokalnie (a to mi się nie do końca podoba).

Chapeau bas Certbot!

Skończył mi się certyfikat SSL dla tego bloga. StartSSL podpadł wszystkim dookoła, trzeba było zrobić z tym porządek.
Z pomocą przyszła inicjatywa Let’s Encrypt, Electronic Frontier Foundation i rewelacyjny skrypt certbot 🙂

Co zrobiłem, żeby mieć nowy certyfikat:

# cd /opt
# mkdir certbot
# chmod 700 certbot
# cd certbot/
# wget https://dl.eff.org/certbot-auto
# chmod 700 certbot-auto
# ./certbot-auto --nginx

Certbot wyświetlił mi wszystkie skonfigurowane na nginxie domeny i poprosił o wybranie tej odpowiedniej.
Podałem maila, zgodziłem się na otrzymanie wiadomości w momencie gdy certyfikat się będzie miał ku końcowi.
Certbot poprawił config dla podanej domeny, wygenerował podpisany przez Let’s Encrypt certyfikat, zrobił reload nginxa.
Koniec.

Wow?!

PS
Certbot dostępny jest też w repozytorium EPEL ale jest tam starsza wersja, która jeszcze nie kuma nginxa. Za to dla fanów Apache – polecam 🙂

PS2
Pisałem już, że certbot i generowane przez Let’s Encrypt certyfikaty są darmowe?

PS3
Co do jakości samego certyfikatu:
https://www.ssllabs.com/ssltest/analyze.html?d=marcin.szydelscy.pl

Problem z HTTPS po upgrade JIRA z 7.2 do 7.3

W mojej konfiguracji używam JIRA za proxy postawionym na nginxie. Po upgrade do wersji 7.3 (a co za tym idzie też podniesieniu wersji tomcata do wersji 8.5) JIRA przestała działać z ustawionym parametrem connectora:

proxyName="jira.example.com" proxyPort="443" scheme="https" secure="true"

Jak to zwykle bywa okazało się, że to known issue 😉 Jak to jeszcze częściej bywa known issue nie wprost odwołuje się do tego co miałem w konfigu, ale workaround zadziałał.

Rozwiązanie problemu to zmiana parametru protocol na:

protocol="org.apache.coyote.http11.Http11NioProtocol"

NGINX spdy invalid parameter

Przejrzałem sobie logi z nginxa i zastanowiły mnie poniższe wpisy pojawiające się przy wszystkich moich domenach z ssl.

invalid parameter "spdy": ngx_http_spdy_module was superseded by ngx_http_v2_module in

Rozwiązanie oczywiście banalne, wszystkie linie:

listen twojeip:443 ssl spdy;

zmieniamy na:

listen twojeip:443 ssl http2;