Superenkel webserver for systemovervåkning
Fri 2024-10-18 Linux
VIKTIG: Det anbefales ikke å kjøre http.server i produksjonsmiljøer da den ikke støtter noen form for autentisering, sikkerhet, ratelimiting eller andre sikkerhetsfunksjoner. http.server er i utgangspunktet kun ment for testing. Trenger man mer avansert funksjonalitet, anbefales det på det sterkeste å implementere en "ekte" webserver som Apache, NGINX eller lighttpd (eller andre alternativer, avhengig av hvilke behov man har).
http.server kan fungere for formålet som beskrevet her, dvs. å servere én statisk fil, men det bør være begrenset i brannmur hvilke IP-adresser som har lov å kontakte serveren på den angitte porten. Det er ikke tilrådelig å la den svare på forespørsler fra det åpne Internettet, men om så gjøres likevel er det sterkt anbefalt å implementere en dynamisk brannmurløsning som fail2ban for å begrense angrepsforsøkene og stoppe dem før de blir et problem. Igjen, implementer en ekte webserver om du har slike behov.
Jeg befant meg selv i en situasjon der jeg holdt på å sette opp noe kult (Cachet+cachet-url-monitor) og trengte en superenkel webtjeneste på en server. Jeg hadde ikke lyst å starte på noe prosjekt med Apache, NGINX eller lighttpd, så jeg gnagde litt på saken og kom på at Python har mulighet til å spinne opp en webserver fra kommandolinjen.
Det var så enkelt som:
/usr/bin/python3 -m http.server 8080
Jeg satt den opp til å kjøre på port 8080 fordi Let's Encrypt også kjører på serveren og fornyer sertifikater i ny og ne. Hvis man ikke har certbot i gang eller ikke ønsker å bruke vanlige porter, kan man selvsagt endre portnummeret til hva som helst.
Alt funket som forventet. Men - hvordan kjører jeg denne permanent og ved oppstart av systemet?
Systemd. Systemd får mye hat, og jeg har hatet en del selv, men har innsett at det var mest på grunn av manglende vilje til å sette meg inn i det. Jeg er fremdeles ikke noen fan av binære logger eller at det vil ta over hele systemet og det der, men det har absolutt sine fordeler også.
Uansett, for å kjøre Python http.server som en Systemd-service, gjør følgende:
Opprett /lib/systemd/system/python-web-server.service med følgende innhold:
[Unit] Description=Python Web Server After=network.target [Service] Type=simple Restart=always
# bør kjøres som en ikke-priviligert bruker med minimale rettigheter til noe som helst User=root
# bør kjøres fra en lokasjon som har begrensede rettigheter og ikke gir mulighet for directory traversal WorkingDirectory=/opt/python-web-service
# bør kjøres på en port over 1024 slik at ikke-priviligerte brukere kan binde porten ExecStart=/usr/bin/python3 -m http.server 8080 [Install] WantedBy=multi-user.target
Link den til /etc/systemd/system/multi-user.target.wants/python-webserver.service.
Opprett WorkingDirectory som angitt i unit-filen:
mkdir -p /opt/python-web-server
Opprett en fil den kan servere klienter:
echo "Success" > /opt/python-web-server/index.html
Enable tjenesten:
sudo systemctl enable python-web-server.service
Start tjenesten:
sudo systemctl start python-web-server.service
Åpne siden i en nettleser for å verifisere at den funker.
For overvåkningsformål har dette både fordeler og ulemper.
Fordelen er at man ser om systemet er oppe eller ikke og det kan da automatisk reflekteres i Cachet. Ulempen er at man ikke vet om tjenesten(e) systemet egentlig betjener er nede eller om de nødvendige tjenestene man faktisk kjører på systemet fungerer som de skal. For eksempel, hvis dette implementeres på en backup-mailserver som egentlig ikke gjør annet enn å spoole mail hvis primær-mailserver av en eller annen grunn ikke får tatt imot mail, så overvåker ikke dette Postfix som er tjenesten man egentlig burde overvåket.
Uptime Kuma støtter overvåkning av en hvilken som helst TCP-port samt ping og en rekke spesifikke tjenester, har også mulighet for statussider og kan således være et bedre alternativ, men det var ikke det denne artikkelen handlet om.