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).

bash extglob odkrycie tygodnia :)

extglob czyli odpalenie „regexów” wewnątrz basha. Przykładowo proste kasowanie z excludem

[szydell@example test]$ ls
aaa1.txt aaa2.txt aaa3.txt aaa4.txt aaa5.txt aaa6.txt aaa7.txt aaa8.txt aaa9.txt bbb1.txt bbb2.txt bbb3.txt bbb4.txt bbb5.txt bbb6.txt bbb7.txt bbb8.txt bbb9.txt test1.txt test2.txt test3.txt test4.txt test5.txt

Chcemy wywalić *.txt z pominięciem aaa5.txt

[szydell@example test]$ shopt -s extglob
[szydell@example test]$ rm !(aaa5).txt
[szydell@example test]$ ls
aaa5.txt

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"

Wielowątkowe pakowanie w Centos 7

Red Hat / CentOS niestety nie rozpieszczają pod względem dostępności fajnych zabawek w standardowym repozytorium
Jedyne co znalazłem to ‚pigz’ czyli rozwiązanie dające tę samą funkcjonalność co gzip, ale na wielu core’ach.

Trzeba oczywiście doinstalować:

yum install pigz

Niestety nie da się prosto odinstalować gzip’a i zastąpić go pigz’em. Ale zawsze można pokombinować 🙂

  1. Sprawdź jak wygląda twoja zmienna środowiskowa $PATH. Z root’a powinno to być coś w ten deseń:

    echo $PATH
    /usr/local/sbin:/sbin:/bin/:/usr/sbin:/usr/bin:/root/bin
  2. Zlokalizuj gdzie masz gzip’a. Standardowo jest w lokalizacji: /usr/bin/gzip
  3. Jak widać mamy niewielkie możliwości do podmienienia sobie gzipa z wykorzystaniem dowiązania symbolicznego, także zróbmy sobie linka w /sbin

    sudo ln -s /usr/bin/pigz /sbin/gzip
  4. Teraz jeżeli uruchomienie komendy ‚gzip’ bez ścieżki, odpali pigz’a.

Dla leniwców (albo kogoś kto nie ma roota) – można podmienić sobie komendę np. w menu Midnight Commandera.

W pliku: /etc/mc/mc.menu zamieniamy komendę ‚gzip’ na ‚pigz’:
Linia:

tar cf - "$Pwd" | gzip -f9 > "$tar.tar.gz" && \

po zmianie:

tar cf - "$Pwd" | pigz -f9 > "$tar.tar.gz" && \

voila

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;

NGINX kompresja

Google udostępnia całkiem sympatyczne narzędzie do analizowania jakości strony – PageSpeed. Ciągle dostawałem tam informację, że moje serwery nie kompresują zawartości. Kombinowałem i kombinowałem…
Okazało się, że w ‚gzip_types’ brakowało typu ‚application/javascript’. W dokumentacji nginx’a tego nie ma…

Cały wpis odpowiadający za włączenie kompresji w nginx’ie:

gzip on;
gzip_comp_level 2;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 1100;
gzip_buffers 16 8k;
gzip_types text/plain text/html text/css application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_disable "MSIE [1-6].(?!.*SV1)";
gzip_vary on;

Problemy z pendrive pod windows 10

Po repartycjonowaniu pendrive nie mogłem z niego korzystać. Partycjonowanie przez ‚Zarządzanie dyskami’ nie działa – zwraca wynik: ‚menedżer dysków wirtualnych nie można odnaleźć określonego pliku’, ale zadziałało to:

diskpart
list disk     #pokaże się lista dysków
select disk X #X - nr z listy
clean
create partition primary
select partition 1
format quick fs=fat32
assign
exit

chmod -x chmod

Jak naprawić system gdy się jest geniuszem zła i wyda się komendę chmod -x chmod?

64bit:
/lib64/ld-linux-x86-64.so.2 /bin/chmod +x /bin/chmod
32bit:
/lib/ld-linux.so.2 /bin/chmod +x /bin/chmod

Brak pewności które użyć?
Sprawdź:

[user@linux katalog]$ ldd /bin/chmod
        linux-vdso.so.1 =>  (0x00007ffd263fd000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003f7c400000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003f7c000000)