Serwer WWW Apache w praktyce. Część 2: nie tylko PHP

[ethanak]

Z poprzedniej części dowiedzieliśmy się, jak w prosty i wygodny sposób skonfigurować serwer Apache. Uruchomiliśmy nawet prosty program w PHP, który działa z uprawnieniami zwykłego użytkownika.

Jednak PHP nie jest jedynym językiem, w którym możemy tworzyć skrypty. Już przed jego powstaniem opracowano znormalizowany interfejs CGI (czyli Common Gateway Interface), który umożliwiał pisanie programów wykonywanych przez serwer w dowolnym języku. PHP zyskał dużą popularność — szczególnie po ukazaniu się wersji 4 — przede wszystkim dlatego, że był zintegrowany z serwerem i interpreter rezydował w pamięci, podczas gdy wykonanie skryptu np. w Perlu wymagało za każdym razem załadowania interpretera, co trochę trwało. Jednak o ile na przełomie tysiącleci, w epoce dość wolnych dysków o niezbyt wielkiej pojemności było to bardzo ważne, dzisiaj traci to znaczenie - musimy pamiętać, że nasza malinka to demon prędkości w porównaniu z serwerami z lat 90-tych. Nawet programy w PHP są czasem z różnych przyczyn wykonywane jako CGI, a duże pojemności pamięci, szybkie dyski oraz (w przypadku niektórych języków) automatyczna kompilacja do kodu pośredniego pozwalają zmniejszyć ten czas do niezauważalnego minimum.

Oprócz CGI powstały inne jeszcze metody komunikacji programów z serwerem, od zarzuconego już dawno SSI, poprzez interfejsy FastCGI, WSGI aż do tworzenia kompletnych serwerów w innych językach programowania i używania głównego serwera jedynie jako reverse proxy. My jednak zajmiemy się najprostszą metodą - czyli właśnie CGI.

Interfejs jest bardzo prosty. W sumie wystarczy wiedzieć kilka rzeczy:

• w czasie wysyłania nagłówków wszystkie pojedyncze znaki '\n' są zamieniane na wymagane przez protokół HTTP pary '\r\n';
• dodatkowy nagłówek Status zamieniany jest na linię odpowiedzi serwera i może być stosowany np. do przekazania kodu błędu lub po prostu innej odpowiedzi serwera niż domyślne (w przypadku jego braku) "200 OK";
• nagłówki zapytania dostępne są w postaci zmiennych środowiskowych.

Program po prostu musi wypisać na wyjście wszystkie potrzebne nagłówki wraz z kończącą je pustą linią, a dopiero wtedy wypisać właściwą odpowiedź (np. kod HTML). Z podobnym zachowaniem spotkaliśmy się zresztą już wcześniej przy tworzeniu serwerów HTTP na Arduino czy ESP, więc nie powinno to sprawiać trudności.

Niestety, serwery nie są domyślnie skonfigurowane do obsługi CGI. Na szczęście w przypadku Raspbiana konfiguracja jest bardzo prosta.

Zaczniemy od tego, że moduł odpowiedzialny za obsługę CGI co prawda został dostarczony razem z serwerem, ale nie jest domyślnie włączony. Musimy więc go włączyć poleceniem:

sudo a2enmod cgi

Co prawda dostaniemy informację o konieczności restartu serwera, ale na razie nie musimy tego robić bo i tak będziemy dopisywać obsługę CGI do naszej donyślnej strony. W tym celu otwieramy w edytorze plik konfiguracyjny, np. przez:

sudo nano /etc/apache2/sites-available/000-default.conf

i dopisujemy dosłownie dwie linijki do części Directory. Linijka AddHandler informuje serwer, że pliki o rozszerzeniu .cgi mają być traktowane jak skrypty, a Options zezwala na wykonywanie skryptów w ogóle w danym katalogu:

AddHandler cgi-script .cgi
Options ExecCGI

Tak więc konfiguracja będzie wyglądać następująco:

Po restarcie serwera możemy już spróbować napisać pierwszy skrypt. Musi mieć on rozszerzenie .cgi i mieć prawo do wykonywania. A więc do dzieła! Napiszmy pierwszy program, robiący dokładnie to samo co poprzedni skrypt w PHP. Ponieważ najbardziej popularnym językiem stosowanym na RPi jest python, będziemy pisać skrypty właśnie w tym języku. Umieśćmy więc w katalogu html plik test.cgi z następującą zawartością:

#!/usr/bin/env python3

print("Content-Type: text/plain; charset=UTF-8\n")
try:
    open("pytest.txt","w").write("Cos tam\n")
    print("Zapisane")
except:
    print("Nie da się zapisać")

Ponieważ funkcja print dodaje nową linię na końcu, znaczek '\n' w nagłówku wymusza po prostu pustą linię za jedynym interesującym nagłówkiem Content-Type.

Teraz musimy nadać plikowi prawa do wykonania:

chmod 755 html/test.cgi

i po skierowaniu przeglądarki na adres http://<ip_malinki>/test.cgi powinniśmy zobaczyć wynik "Zapisane" lub informację, że zapisać się nie dało z jakichś przyczyn (z jakich — o tym później).

Jako że najprawdopodobniej bardziej nas będą interesować zastosowania serwera w IoT czy robotyce — spróbujmy zaprząc Apacza do jakichś bliższych sercu zadań. Ostatnio ktoś pytał o możliwość odczytu kart RFID i pokazywania tego w przeglądarce... spróbujmy! Użyjemy do tego popularnego czytnika RC522, do którego biblioteki są dostępne bez zbytniego szukania.

Zacznijmy od tego, że musimy zainstalować podstawowe biblioteki do Pythona, które umożliwią nam operowanie GPIO oraz magistralą SPI. A więc:

sudo apt install python3-rpi.gpio python3-smbus python3-pip

Biblioteka RPi.GPIO zapewne jest większości znana, smbus pozwala na komunikację właśnie z magistralą SPI, a pip pozwala na instalację pakietów, których nie ma w repozytorium Raspbiana. Upewnijmy się jeszcze, czy mamy włączoną obsługę SPI (w raspi-config), oraz czy użytkownik pi (lub ten, na którego się logujemy) ma dostęp do wszystkiego co potrzebne bez używania sudo. A więc wydajemy polecenie:

groups

Powinno wyświetlić się kilkanaście grup, do których należy użytkownik pi, czyli coś w rodzaju:

pi adm dialout cdrom sudo audio video plugdev games users input netdev bluetooth gpio i2c spi

Nas interesują tylko trzy ostatnie. Jeśli któraś nie występuje, musimy ją dopisać:

sudo usermod -a -G spi,i2c,gpio pi

(oczywiście wpisujemy tylko brakujące) i po przelogowaniu powinniśmy już widzieć użytkownika pi dopisanego do właściwych grup, umożliwiających manipulację pinami GPIO oraz magistralami SPI i I2C.

Niestety, biblioteki obsługi RC522 w repozytorium nie ma, ale możemy ją zainstalować używając polecenia pip3:

sudo pip3 install mfrc522

Kolej na podłączenie czytnika do naszej malinki. Podłączamy tylko siedem z ośmiu pinów, bo nie używamy pinu IRQ, a więc:

• SDA do pinu 24
• SCK do pinu 23
• MOSI do pinu 19
• MISO do pinu 21
• GND do pinu 6
• RST do pinu 22
• 3.3v do pinu 1

Po włączeniu malinki (pamiętajmy, że wszelkie połączenia musimy wykonywać z odłączonym zasilaniem) powinna zapalić się dioda na czytniku. Napiszmy więc prosty program, umożliwiający odczyt kart:

#!/usr/bin/env python3

import RPi.GPIO as GPIO
from mfrc522 import SimpleMFRC522

reader = SimpleMFRC522()
try:
    id=reader.read_id_no_block()
finally:
    GPIO.cleanup()
print("ID=%s" % id)

Użyjemy tu nieblokującej metody, gdyż w przypadku skrypty CGI nie możemy blokować połączenia — przeglądarka przerwie połączenie, jeśli nie doczeka się danych w określonym czasie.

Po uruchomieniu programu (bez sudo oczywiście) powinniśmy móc odczytać numerek zbliżonej karty lub pusty napis, jeśli karty nie ma.

Czyżby to było takie proste? Spróbujmy teraz przerobić nasz program na skrypt CGI. Wystarczy do tego dopisać linijki odpowiadające za wysłanie nagłówków, i powinno działać! Tworzymy więc w katalogu html plik o nazwie (przykładowo) czytnik.cgi i wpisujemy do niego:

#!/usr/bin/env python3

import RPi.GPIO as GPIO
from mfrc522 import SimpleMFRC522

print("Content-Type: text/plain; charset=UTF-8\n")

reader = SimpleMFRC522()
try:
    id=reader.read_id_no_block() or ''
finally:
    GPIO.cleanup()
print("ID=%s" % id)

Nadajemy plikowi prawa do wykonywania:

chmod 755 html/czytnik.cgi

Na wszelki wypadek sprawdźmy, czy działa wydając po prostu polecenie:

html/czytnik.cgi

Powinno działać! A więc przeglądarka w ruch, wpisujemy adres http://<ip_malinki>/czytnik.cgi i...

...i nic. Zaglądając do logu błędów Apacza zobaczymy, że program nie został wykonany. Dlaczego?

Ponieważ ciągłe zaglądanie do logów nie jest zbyt wygodne, zmuśmy nasz skrypt do reakcji na błędy i wyświetlania ich w przeglądarce. Użyjemy do tego modułu cgitb, który pozwala właśnie na takie manipulacje. A więc nowa wersja skryptu będzie wyglądać tak:

#!/usr/bin/env python3

import RPi.GPIO as GPIO
from mfrc522 import SimpleMFRC522
import cgitb

print("Content-Type: text/plain; charset=UTF-8\n")

cgitb.enable(format="text") # włączamy wyświetlanie błędów w formacie tekstowym

reader = SimpleMFRC522()
try:
    id=reader.read_id_no_block() or ''
finally:
    GPIO.cleanup()
print("ID=%s" % id)

Po uruchomieniu możemy zobaczyć, że skrypt nie ma uprawnień do smbusa i gpio! Ale przecież użyliśmy wcześniej modułu ruid2, który powinien uruchomić nasz program jako użytkownik pi! Ki diabeł? Musimy to sprawdzić.

Dodajmy do skryptu linijki, które pokażą nam z jakimi uprawnieniami wykonywany jest nasz program:

#!/usr/bin/env python3

import RPi.GPIO as GPIO
from mfrc522 import SimpleMFRC522
import cgitb, sys, os

print("Content-Type: text/plain; charset=UTF-8\n")
sys.stdout.flush() # aby upewnić się, że nagłówki nie zostaną zbuforowane
os.system("groups")

Po uruchomieniu widzimy, że program uruchomił się z uprawnieniami grupy pi, ewentualnie (zależnie od konfiguracji) dodatkowo www-data. A gdzie nasze gpio? Gdzie spi?

Spójrzmy do konfiguracji modułu ruid2. O właśnie — kazaliśmy uruchomić program z uprawnieniami użytkownika pi i grupy pi, bez żadnych dodatkowych grup. Ale od czego jest linijka RGroups? Właśnie od tego, aby dopisać dodatkowe grupy!

Poprzednio mieliśmy tam wpisane @none. Dopiszmy więc dodatkowe grupy, zmieniając tę linijkę na:

RGroups gpio spi i2c

i zrestartujmy Apacza. Powinno być dobrze...

Ale nie jest. Przeglądarka uparcie pokazuje nam, że Apacz nic nie wie o żadnych dodatkowych grupach... dlaczego?

Po prostu zadziałało zabezpieczenie. Moduł nie pozwala nam na uruchamianie programu z uprawnieniami grup systemowych, czyli w przypadku Raspbiana z numerkami grupy mniejszymi niż 1000. Na szczęście i na to jest sposób. W konfiguracji możemy podać nazwę grupy o najmniejszym ID, który jest dozwolony. Musimy w tym celu przejrzeć plik grup:

cat /etc/groups

lub lepiej, aby ograniczyć wyświetlanie do najbardziej istotnych rzeczy:

egrep '(spi|i2c|gpio)' /etc/group

i znaleźć, która z tych grup ma najniższy numerek. W moim przypadku jest to grupa gpio o numerze 997, a więc dopisujemy dodatkową linię do konfiguracji ruid2:

RMinUidGid pi gpio

W efekcie nasza konfiguracja wygląda tak:

Teraz restartujemy Apacza — i w efekcie po przyłożeniu karty do czytnika i wczytaniu strony do przeglądarki zobaczymy wreszcie odczytany ID!

Ponieważ chcielibyśmy, aby dane były pokazywane na bieżąco, możemy po prostu dopisać odpowiedni nagłówek wymuszający na przeglądarce odświeżenie strony. Tak więc po usunięciu niepotrzebnych już linii i delikatnym "upiększeniu" nasz kod będzie wyglądać tak:

#!/usr/bin/env python3

import RPi.GPIO as GPIO
from mfrc522 import SimpleMFRC522
import cgitb

print("Content-Type: text/plain; charset=UTF-8\nRefresh: 5\n")
cgitb.enable(format="text")

reader = SimpleMFRC522()
try:
    id=reader.read_id_no_block() or 'Brak karty'
finally:
    GPIO.cleanup()
print("ID=%s" % id)

Prawda, jakie to proste?

Tyle na dziś — w następnej części dowiemy się, jak w pythonowym skrypcie CGI możemy dobrać się do przesyłanych danych.

[deshipu]

A co się stanie, jeśli dwie osoby otworzą w przeglądarkach w tym samym momencie naszą stronę i dwa osobne procesy będą próbowały jednocześnie skorzystać z nóżek GPIO?

[ethanak]

Dokładnie to samo co w przypadku, gdy dwóch użytkowników zalogowanych do malinki spróbuje uruchomić program korzystający z GPIO (niekoniecznie ten sam).

[Skroll]

Po pierwsze świetny poradnik!
Po drugie mam pytanie odnośnie phpmyadmin, ponieważ nie ma do niego dostępu po wykonaniu powyższych kroków. Znalazłem gdzieś że żeby zmienić katalog phpmyadmin trzeba wejść /etc/ phpmyadmin/conf.d i tam utworzyć nowy plik konfiguracyjny o treści
 

Alias /phpMyAdmin /usr/share/phpMyAdmin
Alias /phpmyadmin /usr/share/phpMyAdmin


<Directory /usr/share/phpMyAdmin/>
    Options none
    AllowOverride Limit
    Require all granted
</Directory>

<Directory /usr/share/phpMyAdmin/>
    Options none
    AllowOverride Limit
    Require all granted
</Directory>

<Directory /usr/share/phpMyAdmin/libraries/>
    Order Deny,Allow
    Deny from All
    Allow from None
</Directory>

<Directory /usr/share/phpMyAdmin/setup/lib/>
    Order Deny,Allow
    Deny from All
    Allow from None
</Directory>

<Directory /usr/share/phpMyAdmin/setup/frames/>
    Order Deny,Allow
    Deny from All
    Allow from None
</Directory>

Niestety u mnie nie dało to rezultatu żadnego, po wpisaniu ip_maliny/phpmyadmin mam błąd 404. Później sam trochę poszukałem w plikach i znalazłem w etc/phpmyadmin plik apache.config czy po zmianie w nim ścieżek dostępu na /home/pi/... będzie to działać? Trochę boje się zmieniać pliki konfiguracyjne bo po ostatniej zabawie musiałem reinstalować system 😕

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

Nie wiem co tam robiłeś... u mnie działa. A już na pewno nie trzeba zmieniać nic w żadnych plikach konfiguracyjnych, szczególnie według porad znalezionych "gdzieś".

Poza tym nie trzeba reinstalować systemu za każdym razem jak się pomylisz (albo zastosujesz porady od Mistrza Gdziesia), tylko wywalić część która nie działa, np. przez polecenie:

sudo apt purge phpmyadmin

które wywali phpmyadmina w niebyt razem z plikami konfiguracyjnymi.