PHPmyadmin działał bez problemu na Debian 8. Jednakże, wsparcie dla Debian 8 zakończyło się, dlatego zaktualizowałem do Debian 9. Wszystko poprawnie działa, jednakże problem pojawił się z PHPmyadmin, gdzie pokazywała się biała strona.

W logach /var/log/apache2/error.log można było odczytać następującą frazę:

[Fri Jul 31 09:39:02.096786 2020] [:error] [pid 31386] [client 192.168.x.1:43198] PHP Warning: require_once(/usr/share/php/php-php-gettext/gettext.inc): failed to open stream: Operation not permitted in /usr/share/phpmyadmin/libraries/common.inc.php on line 77

Rozwiązaniem okazało się stworzenie symlinku:

  • Przechodzimy do folderu /usr/share/php
  • mv php-gettext php-gettext.orig
  • ln -s php-php-gettext php-gettext

W firmie której pracuję, posiadamy serwery www, pocztowe, itp. Dobrą praktyką jest aby serwery posiadały przypisane na stałe adresy ip. W Fortigate robimy to w następujący sposób:

  1. Wchodzimy w Network -> Interfaces -> Port x (VLAN x)
  2. Rozwijamy zakładkę Advenced -> IP Address Assignment Rule i tam przypisujemy stały adres ip podając również mac-adress

W pracy zdarzyło mi się, że użytkownicy zgłaszali problem iż przy próbie zalogowania się do systemu Windows dostają komunikat:

Logowanie usługi Profil użytkownika nie powiodło się. Nie można załadować profilu użytkownika

Poniżej przedstawiam rozwiązanie:

  • logujemy się jako administrator lub w trybie awaryjnym
  • wchodzimy do rejestru (regedit) z uprawnieniami administratora
  • szukamy klucza:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
  • tam znajdujemy ciąg, zaczynający się od S-1-5 a kończący na .bak
  • zmieniamy nazwę z .bak na .bk
  • szukamy ciąg zaczynający się jak powyżej czyli S-1-5 ale bez .bak i tam klikając prawy przycisk myszy na kluczu klikamy na “Zmień nazwę” i dodajemy na końcu .bak
  • następnie w przerobionym ciągu z końcówką .bk usuwamy .bk

Zamykamy rejestr i restartujemy komputer. Powinniśmy bez problemu zalogować się do problematycznego profilu.

W pracy posiadamy dwa łącza od różnych operatorów. Jeden operator (nazwijmy go x) przydziela nam jeden stały adres IP natomiast drugi operator (nazwijmy go y) przydziela nam 4 stałe adresy IP. Całość jest spięta w SD-WAN.

Zaszła potrzeba aby jeden z komputerów był widoczny z adresacji drugiego operatora i z powiedzmy mało technicznie 3 stałego adresu IP. Na fortigate musimy zatem wykonać kilka czynności:

  • Wchodzimy w zakładkę Policy & Objects -> Virtual IP -> Create Virtual IP i tam robimy następujące wpisy:

Interface: wybieramy przez którego operatora ma iść sieć

External IP address/range: wpisujemy publiczny adres ip z np. 3 stałego adresu ip

Mapped IP address/range: wpisujemy adres ip komputera lokalnego

  • Kolejnym punktem który musimy wykonać to w zakładce Policy & Objects -> Firewall Policy -> Create New tworzymy następujące wpisy:

Incoming Interface: w moim przypadku był to SDWAN

Outgoing Interface: VLANx (czyli VLAN w którym znajduje się nasz komputer)

Source: all

Destination: to co stworzyliśmy w VIP powyżej

Service: na moje potrzeby były to HTTP i HTTPS (czyli porty które chciałem odblokować)

NAT odhaczamy aby nie był aktywny

  1. Ostatnim naszym zadaniem jest konfiguracja Network -> Policy Routes -> Create New

Incoming interface: VLANx (czyli VLAN w którym znajduje się nasz komputer)

Addresses: adres ip naszego komputera

Action: Forward Traffic

Outgoing interface: wybieramy operatora y

W pracy posiadamy serwer z OpenVPN postawiony na Debianie oraz Windows Serwer 2019 z Active Directory. Zaszła potrzeba aby kilka komputerów podłączony do Active Directory mogła łączyć się z sieci zewnętrznej. Ustawiłem zatem odpowiedni wpis w pliku *.ovpn który wygląda następująco:

client
dev tun
proto udp
remote xx.xx.xxx.xxx 1194
dhcp-option DNS 10.x.x.x
dhcp-option DOMAIN mojadomena.lokalne
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3

W systemie Ubuntu w połączeniu z Google Authenticator możemy w prosty sposób stworzyć sobie autoryzację dwuskładnikową. Poniżej przedstawiam kroki:

sudo apt-get update && apt-get upgrade
sudo apt-get install libpam-google-authenticator

Dalej z poziomu danego użytkownika, wpisujemy komendę:

google-authenticator

Odpowiadamy na pytania, które pojawią się po wpisaniu powyższej komendy.

W dalszym kroku uzyskamy QR kod oraz tzw. kody ratunkowe. Kod QR skanujemy w aplikacji mobilnej Google Authenticator, którą ściągamy ze sklepu Google Play.

Dalej edytujemy linijkę w naszym systemie Ubuntu:

sudo nano /etc/pam.d/common-auth

#end of pam-auth-update config
auth required pam_google_authenticator.so nullok

Wykonujemy restart systemu i możemy się cieszyć dwustopniową autoryzacją.

Jeżeli chcielibyśmy aby docker współpracował z naszą maszyną wirtualną na Proxmox`ie, musimy wykonać następujące kroki:

  1. Instalujemy maszynę/kontener na Proxmox`ie
  2. Ustawiamy na naszej maszynie w ustawieniach Opcje -> Features na nesting=1
  3. Instalujemy docker komendą apk add docker
  4. Zmieniamy wpisy dla cgroups w Alpine Linux i po wpisach restarujemy maszynę/dockera:
# remove dirs for failed mounts 
rmdir /sys/fs/cgroup/cpu && rmdir /sys/fs/cgroup/cpuacct && rmdir /sys/fs/cgroup/net_cls && rmdir /sys/fs/cgroup/net_prio 
# mount missing cgroups (Ubuntu style) 
mkdir "/sys/fs/cgroup/cpu,cpuacct" 
mount -n -t cgroup -o "nodev,noexec,nosuid,cpu,cpuacct" "cpu,cpuacct" "/sys/fs/cgroup/cpu,cpuacct" 
ln -s "cpu,cpuacct" /sys/fs/cgroup/cpu 
ln -s "cpu,cpuacct" /sys/fs/cgroup/cpuacct 
mkdir "/sys/fs/cgroup/net_cls,net_prio"
mount -n -t cgroup -o nodev,noexec,nosuid,net_cls,net_prio" "net_cls,net_prio" "/sys/fs/cgroup/net_cls,net_prio" 
ln -s "net_cls,net_prio" /sys/fs/cgroup/net_cls
ln -s "net_cls,net_prio" /sys/fs/cgroup/net_prio
# mount systemd cgroup (Alpine mounts openrc, but Docker requires systemd...) # (based on hint at https://k9s.hatenablog.jp/entry/2019/06/16/075741) 
mkdir /sys/fs/cgroup/systemd 
mount -n -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd

W pracy ułatwiamy sobie zadania zgłoszeniowe użytkowników przez system mantisbt. Ostatnio zdarzyło mi się, iż email`e nie dochodziły do użytkowników. Sprawdziłem poprzez PHPMyAdmin iż w tabeli

mantis_email_table

emaile poprawnie się zakolejkowały…jednakże dalej nie chciały wychodzić. Problemem okazał się GMAIL który odpowiadał za wysyłkę email…wystarczyło tylko zmienić hasło na GMAIL`u i poczta zaczęła dochodzić do użytkowników.

P.S.

Logi w mantis`ie można sprawdzić dodając wpis w /var/www/mantis/config_inc.php o następującej treści:

$g_log_destination = 'file:/tmp/mantisbt.log';