Hmmm, jaki dziwny błąd! W tłumaczeniu przy pomocy translatora dostaję: „nie można stworzyć zajezdni komunikacji międzyprocesowej„. Brawo Cisco! Na pewno każdy, kto przeczyta ten komunikat będzie wiedział o co chodzi.

Na szczęście istnieją na świecie ludzie, którzy potrafią wytłumaczyć, co należy zrobić, żeby zajezdnia komunikacji międzyprocesowej zaczęła działać: Why do I get a VPN client „unable to create the interprocess communication depot” error? (force.com)

Jeśli na swoim komputerze udostępniasz połączenie sieciowe (np. sieć lokalna może wykorzystywać Twoje połączenie internetowe, albo np. sieć wirtualna Hyper-V może łączyć się z internetem), to podobno ten komunikat jest typowy. Co zrobić?

• Odszukaj w  panelu sterowania „Network Sharing Center (Centrum sieci i udostępniania)”
• Wybierz połączenie, które udostępnia sieć i przejdź do właściwości
• Na karcie Sharing/Udostępnianie odznacz opcję [x] Allow other network users to connect throug this computer’s Internet connection

Co ciekawe, po instalacji, kiedy zajezdnia komunikacji międzyprocesowej już działa, można spowrotem włączyć udostępnianie sieci i wygląda na to, że procesy mogą mimo wszystko nadal wjeżdżać do zajezdni 🙂

Objaw:

Połączenie ssh jest nawiązywane z komputera z Linux do innego komputera Linux. Po pewnym czasie nieaktywności sesja sie „blokuje”, a po pewnym czasie pojawia się komunikat o rozłączeniu.

Timeout, server 18.184.154.201 not responding.

Przyczyna:

Kiedy w połączeniu ssh nic się nie dzieje, to jedna ze stron (klient lub serwer) może takie połączenie po swojej stronie zakończyć. Jeśli do rozłączenia dochodzi po stronie serwera, to nieświadomy klient przez pewien czas może próbować nawiązać to połączenie spowrotem. To właśnie obserwowane „zablokowanie” sesji. Kiedy tego połączenia nie udaje się nawiązać przez dłuższy czas, to klient się poddaje i zwraca wspomniany błąd.

Naprawa:

Na serwerze należy wyedytować plik /etc/ssh/sshd_config

W nim należy włączyć nastęþujące linie:

ClientAliveInterval 60
TCPKeepAlive yes
ClientAliveCountMax 10000

• ClientAliveInterval – określa, co ile sekund należy wysłać do klienta pusty pakiet
• TCPKeepAlive – powoduje przesłanie informacji o podtrzymywaniu połączenia do firewalli przez które mogą przechodzić pakiety między klientem i serwerem
• ClientAliveCountMax – ile razy ponowić wysyłkię pustego pakiety mimo braku odpowiedzi ze strony klienta.

Po zmianach w pliku konfiguracyjnym należy zrestartować usługę ssh:

sudo systemctl restart sshd

Na kliencie należy z kolei w tym samym pliku wykonać następujące zmiany:

Host *
ServerAliveInterval 100

• ServerAliveInterval – co jaki czas klient ma wysyłać do serwera pusty pakiet

W moim przypadku problem udało się rozwiązać 🙂

W Linuxach jest ciekawie i różnorodnie… dzięki temu się nie nudzimy. Jeśli chcesz doinstalowywać do swojej instlacji Pythona dodatkowe pakiety, to miło byłoby mieć pip (podobno jego nazwę należy rekurencyjnie rozwinąć do pip installs python)

Co jeśli pip nie jest zainstalowany? Zakładam, że mamy na systemie Pythona 3. W takim przypadku zaczynamy od instalacji pakietu python3-pip:

sudo apt update
sudo apt install python3-pip

Od tej pory pip powinien już być dostępny i lepiej jest korzystać z polecenia pip3, co wyraźnie wskazuje, że chodzi o 3-cią wersję Pythona i stowarzyszonych narzędzi:

pip3 --version

Teraz, jeśli chcesz zainstalować bibliotekę scrapy, wystarczy, że użyjesz:

pip3 install scapy

a aby wylistować dostępne i zainstalowane pakiety

pip3 list

Jeśli jakiś pakiet chcesz zaktualizować użyj:

pip3 install --upgrade nazwa_pakietu

A jak zabawki Ci się znudzą i chcesz je odinstalować to z pomocą przyjdzie:

pip3 uninstall nazwa_pakietu

A czemu by nie? Czemu by nie zadbać o potwierdzony i ciągle wymuszany stan firewalla na swoich serwerach?

Nim jednak włączymy ufw, upewnijmy się, że firewall będzie akceptował połączenia na port 22 SSH. W tym przypadku zezwalamy tez na połączenie na port 80. Dopiero ostatni krok, to rzeczywiste włączenie firewalla:

  - name: Add role for OpenSSH
    community.general.ufw:
      rule: allow
       port: 22
       proto: tcp
  - name: Create firewall exception for WWW
    community.general.ufw:
      rule: allow
      port: 80
      proto: tcp
      #delete: yes
  - name: Activate UFW
    community.general.ufw:
      state: enabled

Jeśli z kolei chcielibyśmy regułę dotyczącą http wykluczyć (ale jej jawnie nie zabraniać, bo do zabronienia należałoby skorzystać z reject), to wystarczy odkomentować linijkę delete:yes

Definiując w playbooku instalację pakietu przez ansible można to zrobić na RedHat, Centos, Fedora o tak:

  tasks:
  - name: install nginx
    yum: 
      name: vsftpd 
      state: present

no ale, jeśli masz Ubuntu, to należałoby użyć apt:

  tasks:
  - name: install vsftpd
    apt: 
      name: nginx 
      state: present

Co kraj to obyczaj, co edycja to inna instalacja… ale można również skorzystać z modułu packages – jedna uniwersalna metoda:

  tasks:
  - name: Install nginx
    package:
      name: nginx
      state: present

nginx na dobre wyparł już ze świata Linuxa starego poczciwego httpd/Apache (zdanie z przymróżeniem oka). Oto krótki przewodnik instalacji nginx na Ubuntu

Zaczynamy od instalacji samego pakietu:

sudo apt update
sudo apt install nginx

Podczas instalacji pakietu dzieje się jedna fajna rzecz. Nginx dodaje reguły aplikacyjne do firewalla ufw. Można je wylistować korzystając z:

sudo ufw app list

Są trzy domyślne zestawy: HTTP, HTTPS i Full (zawierający zarówno http jak i https). Można je włączyć uruchamiając np:

sudo ufw allow 'Nginx Full'

Jeśli chcesz zachować kontrolę nad zmianami w firewall możesz też otwierać zamykać porty samodzielnie korzystając z nazw protokołów lub nawet numerów portów:

sudo ufw allow https 
sudo ufw allow 443

Status firewalla można sprawdzić poleceniem

sudo ufw status

a spodziewany wynik to np coś w tym stylu:

Status: active

To Action From
-- ------ ----
443/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
Nginx Full ALLOW Anywhere
443/tcp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
Nginx Full (v6) ALLOW Anywhere (v6)

Gdyby status ufw był inactive, to włączenie firewalla wykonasz przez

sudo ufw enable

Jednak przed włączeniem ufw, warto sprawdzić, czy np. zezwalamy na połączenia na porcie 22 (ssh). Niestety nie ma komendy, która by pozwoliła to zzrobić za prośrednictem ufw. Można za to wszystkie reguły podejrzeć w pliku:

sudo cat /etc/ufw/user.rules

Wróćmy do konfiguracji nginx. Warto by było, żeby usługa startowała automatycznie po uruchomieniu systemu:

systemctl enable nginx
systemctl start nginx
systemctl status nginx

Domyślna konfiguracja nginx znajduje się w /etc/nginx/nginx.conf. Domyślnie serwer nasłuchuje tylko na porcie 80 i root wskazuje na pliki w katalogu /var/www/html

Konfigurację można (i należy) docelowo zmienić tak, aby mogła obsługiwać multi-site.

Całkiem ładny opis instalacji ingx jest też tu

https://www.digitalocean.com/community/tutorials/how-to-install-nginx-on-ubuntu-20-04

Manual do ufw tutaj:

https://ubuntu.com/server/docs/security-firewall

i tu:

How To Setup a Firewall with UFW on an Ubuntu and Debian Cloud Server | DigitalOcean

Jest wiele sytuacji, w których w bazie danych trzeba zapisać unikalne informacje, oznaczone unikalnym identyfikatorem. Tak jest zresztą nie tylko w bazach danych. Idziesz do urzędu, a na wejściu musisz pobrać numerek, dzięki czemu od razu jesteś zakolejkowany 🙂

Obiektem, który w bazie danych generuje kolejne wartości jest tzw. SEQUENCE. Bardzo podstawowa definicja sequence może wyglądać tak:

CREATE SEQUENCE ticket_id INCREMENT 1 START 101;

Ilekroć będziesz odwoływać się do ticket_id, z wykorzystaniem funkcji nextvalue, będziesz otrzymywać kolejne numerki począwszy od 101. Sqeunce ma mnóstwo parametrów dotyczących tego, jak ma wyglądać generowanie kolejnych wartości i znajdziesz je w helpie.

Załóżmy, że została utworzona taka oto tabela:

create table tickets(id integer, title text);

Typowe wykorzystanie sequence wygląda tak:

insert into tickets(id, title) values(nextval('ticket_id'),'issue1'), (nextval('ticket_id'),'issue2');

W efekcie, w tabeli znajdują się teraz następujące rekordy:

 select * from tickets;
 id  | title 
-----+--------
 101 | issue1
 102 | issue2

Pięknie… ale…. dla danego sequence nie wiadomo, gdzie on jest wykorzystywany. Można by było oczywiście dochodzić do tego po nazwie. Skoro ktoś nazwał sequence ticket_id, to może jest jakaś tabela z ticket-ami?

Tabele można też zdefiniować tak:

CREATE TABLE color (
 color_id INT GENERATED BY DEFAULT AS IDENTITY (START WITH 10 INCREMENT BY 10),
 color_name VARCHAR NOT NULL
 );

Zasada pracy tej tabeli jest podobna, jak w przpadku sequence, a gdyby słowo DEFAULT zamienić na ALWAYS, to wartości dla color_id nie tylko, że nie trzeba by podawać – nie można jej podać, bo będzie ona generowana przez PostgreSQL samodzielnie.

insert into color (color_name) values ('pink'), ('green'), ('yellow');
INSERT 0 3

select * from color;
 color_id | color_name 
----------+------------
 10       | pink
 20       | green
 30       | yellow

Jest jednak pewna różnica. Jeśli zajrzymy do widoku  information_schema.sequences, to znajdziemy tam tylko informacje o pierwszym sequence (tym stworzonym jawnie i osobno). Jeśli jednak zajrzymy do tabeli systemowej  pg_sequences, to będą tam już obie!

No ale skoro utworzenie sequence nastąpiło automatycznie podczas tworzenia tabeli – to nie ma siły. Gdzieś musiał zostać ślad po tym, z jakim sequence jest powiązana kolumna color_id. Rzeczywiście:

 select pg_get_serial_sequence('public.color', 'color_id');

W efekcie dostaniemy:

 pg_get_serial_sequence 
---------------------------
 public.color_color_id_seq

A jak zidentyfikować, te ręcznie tworzone sequence? Niestety – chyba odkryliśmy regułę, jak nie należy korzystać z sequence. Jeśli sequence jest obiektem „na boku” i nie podlega przypisaniu do tabeli, jest to tylko maszyna wydająca numerki, stojąca gdzieś w  portierni naszej bazy danych, to po prostu nie jest przypisana do żadnej tabeli/kolumny w tabeli. Logikę generowania wartości id w tabeli tickets, zna w tym przypadku tylko programista aplikacji.

Co ciekawe, jeśli tabela została utworzona poleceniem:

CREATE TABLE Towns (
 id SERIAL UNIQUE NOT NULL,
 code VARCHAR(10) NOT NULL, -- not unique
 article TEXT,
 name TEXT NOT NULL, -- not unique
 department VARCHAR(4) NOT NULL,
 UNIQUE (code, department)
);

to poniższe zapytanie również wykryje relację między kolumną id, a automatycznie utworzonym sequence:

SELECT d.refobjid::regclass, a.attname
FROM pg_sequences s
JOIN pg_depend d ON d.objid = CONCAT(s.schemaname,'.', s.sequencename)::regclass
JOIN pg_attribute a ON a.attrelid = d.refobjid AND a.attnum = d.refobjsubid;

A tak BTW, skąd PostgreSQL wie, jak się ze sobą te obiekty wiążą? Jest jeszcze jedna tabela systemowa o nazwie pg_sequence, gdzie dla każdego sequence można odnaleźć jego identyfikator. Dzięki temu, działa następujące zapytanie, które – przyjmijmy – odpowiada na pytanie – gdzie jest używany obiekt sequence:

SELECT seqclass.relname AS sequence_name,
     seqclass.relfilenode AS sequenceref,
     dep.refobjid AS depobjref,
     depclass.relname AS table_name
FROM pg_class AS seqclass
 JOIN pg_sequence AS seq ON seq.seqrelid = seqclass.relfilenode
 JOIN pg_depend AS dep ON seq.seqrelid = dep.objid
 JOIN pg_class AS depclass ON dep.refobjid = depclass.relfilenode;

[ Referece: https://sadique.io/blog/2019/05/07/viewing-sequence-ownership-information-in-postgres/ ]