Chapeau bas Certbot!

nginx, , , , , ,

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

JIRA, nginx, tomcat, , , , ,

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

Linux, , , , , ,

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

nginx,

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

nginx, , ,

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

Windows, , , ,

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

Linux, , ,

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)

MD5 i inne hasze – generowanie z command line pod Windows 7

Aplikacje, Windows, , , , , , , ,

Windows 7 posiada wbudowane narzędzie, które można zmusić do wygenerowania MD5.
Rozwiązanie nie na wprost, ale działa 🙂

certUtil -hashfile pathToFileToCheck [HashAlgorithm]

HashAlgorithm przyjmuje parametry: MD2 MD4 MD5 SHA1 SHA256 SHA384 SHA512

Przykładowo generowanie MD5 dla pliku C:\TEMP\MyDataFile.img:

CertUtil -hashfile C:\TEMP\MyDataFile.img MD5

Original solution by Laisvis Lingvevicius

setfacl czyli ACLe w akcji. Dostęp do logów.

Linux, , , , ,

Setfacl to jedno z narzędzi do zarządzania ACL’ami pod Linuxem. Notatka praktyczna pokazująca jak można je zastosować w realnym świecie.

Czasami istnieje konieczność przyznania komuś dostępu do logów. Dostępu stałego, uwzględniającego logrotate i ewentualne fanaberie niektórych aplikacji (zmień ownera po stworzeniu pliku – patrz Apache).

Najskuteczniejszą moim zdaniem metodą jest skorzystanie z ACL’a nałożonego na katalog.
Przykładowo. Chcemy dodać członkom grupy www dostęp read do logów nginxa:

setfacl -d -m g:www:r nginx/    # to załatwia sprawę dla przyszłych plików (można też pojechać rekurencyjnie -R)

wydanie komendy spodowowało:

[root@linux log]# getfacl nginx/
# file: nginx/
# owner: root
# group: root
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:www:r--
default:mask::r-x
default:other::r-x

setfacl -m g:www:r nginx/* # a tak dorzucamy +r do wszystkich obecnych.

Jeżeli uprawnienia miałyby być nadane nie na grupę tylko konkretnego usera to:

setfacl -d -m u:login:r nginx/

Usunięcie acla:

setfacl -x g:www nginx/
setfacl -x u:login nginx/