Close

Användarmanual – Systemförvaltning (Linux)

Publicerad: 2020-04-22 Skriven av: Stefan de Vries

Systemförvaltning är en driftstjänst för alla typer av webbplatser och applikationer som fungerar på Linux. Grunden i tjänsten är en Linux-baserad VPS eller dedikerad server som levereras färdiginstallerad och förberedd för att köra igång din webbplats. Läs mer om tjänsten systemförvaltning här

Ansluta till servern

För att ansluta till din server och komma åt filer, göra förändringar, läsa loggar eller starta om tjänster – rekommenderar vi att alltid använda Secure Shell (SSH). I vissa fall kan du behöva göra undantag; det finns till exempel affärssystem som endast är kompatibla med FTPS.

Dina inloggningsuppgifter får du i samband med beställningen av tjänsten.

För att hålla en hög nivå av säkerhet och för att vi ska veta vem som har åtkomst till din server så rekommenderar vi personliga SSH-nycklar. Flera olika personer och företag kan kopplas till samma server.

För att läsa hur du genererar en personlig nyckel har vi en guide för det här.

Utöver det låser vi ner SSH och endast vitlistade IP-adresser når din server.

För att lägga till en ny användare vilket ofta sker ihop med att du ska sätta upp en ny webbplats behöver du kontakta vår support. Det samma gäller när du vill ta bort åtkomst.

Administratörsrättigheter

För att vi ska kunna ta ett helhetsansvar och erbjuda en säker och pålitlig driftmiljö delar vi inte ut root- eller administratörsrättigheter.

Anledningen är att alla parter ska känna sig trygga och veta vem som har gjort vad. Vi påverkar aldrig en kunds data; vi varken editerar, raderar eller skapar data i kundens hemkatalog. Du ska alltid vara säker på att vi inte har gjort några manuella ändringar i till exempel .htaccess.

På samma sätt behöver vi vara säkra på att kunden inte gör förändringar på de applikationer som vi tar ansvar för. Vi dokumenterar noggrant allt som görs på applikationsnivå på din server.

Behöver du göra en uppdatering som kräver administratörsrättigheter kontaktar du oss för hjälp.

Struktur på servern

Vi jobbar med en standardiserad struktur på servern för att förenkla dokumentation och felsökning. Katalogstrukturen ser ut så här:

Hemkatalog

Sökvägen till din användares hemkatalog är /home/httpd/<user>.

Filerna till din webbplats

Filerna till din webbplats ligger som standard i katalogen /home/httpd/<user>/<domain>/public_html.

Loggar

Loggarna sparas i katalogen /home/httpd/<user>/logs.

Här sparas både <domain>-error.log och <domain>-access.log som du använder vid felsökning.

Brandväggsrutiner

I tjänsten ingår att vi sätter upp en brandvägg för att begränsa och blockera oönskad trafik till och från din server. För att göra din server så säker som möjligt utgår vi alltid från en restriktiv brandväggsuppsättning:

Inkommande regler

  • SSH: trafik blockeras, men vi vitlistar IP-adresser åt dig för åtkomst
  • FTP(S): trafik tillåts
  • HTTP(S): trafik tillåts

Utgående regler

  • DNS: trafik tillåts
  • NTP: trafik tillåts
  • HTTP: trafik blockeras, men vi vitlistar IP-adresser åt dig för åtkomst
  • HTTPS: trafik tillåts

All annan trafik blockeras som standard.

Om du till exempel behöver nå en FTP-server hör du av dig till oss så löser vi det.

Vi rekommenderar att alltid använda HTTPS när det är möjligt för att ansluta till servern utifrån.

Backuprutiner

Vi ser till att det varje dygn tas backup av din server, som sedan sparas 14 dagar i ett roterande schema. Behöver du återläsa en fil eller databas hör du av dig till vår support som hjälper dig att återläsa filerna.

Backuprutinerna skiljer sig åt beroende på om du har systemförvaltning på en VPS eller dedikerad server:

  • Använder du en VPS tar vi automatiskt backup på hela virtuella disken.
  • Har du en dedikerad server använder vi oss av Bacula – en backuptjänst som bygger på öppen källkod – för att ta hand om backuperna. Vi kommer överens med dig vilka kataloger och filer som är viktiga och tar backup på just dessa.

Uppdateringar

Vi ser till att din server underhålls och alltid är uppdaterad. Enligt ett schemalagt underhållsfönster installerar vi kontinuerligt de senaste funktions- och säkerhetspatcharna.

Underhållsfönster

Underhåll sker en gång i veckan. Som standard sker det varje tisdag, någon gång mellan 02.00–05.00 CET/CEST, och vanligtvis innebär det inte mer än 10–20 minuters nertid under denna period. Det kan bli aktuellt med en omstart av servern eller enskilda tjänster som uppdaterats.

Övervakning

En stor fördel med systemförvaltning är att vi löpande övervakar din server. Om ett fel uppstår i de applikationer som vi hanterar åt dig, går det ett larm till vårt driftteam som då identifierar och åtgärdar problemet.

Vi kollar även av ett specifikt sökresultat på webbplatsen för att kontrollera att den är tillgänglig för dina besökare.

Inställelsetiden avgörs av tecknat SLA som du kan läsa mer om här.

Tjänstebeskrivningar

SSH

Som standard tillåts endast vitlistade IP-adresser i vår brandvägg att ansluta till tjänsten via SSH. Detta för att minimera risken för att obehöriga ska ta sig in.

FTP(S)

Som standard tillåter vi åtkomst via FTP(S). Tjänsten svarar på både krypterad och okrypterad trafik. Du använder samma användare för att ansluta till FTP(S) och dina IP-adresser behöver inte vitlistas. Detta för att förenkla integrationen med externa system som ofta använder sig av FTP-protokollet.

Vi övervakar också tjänsten och blockerar automatiskt IP-adresser som används för intrångsförsök eller annat missbruk.

Om du vill ge en extern tjänst tillgång via FTP men inte ge fulla rättigheter till alla dina filer kan du höra av dig till oss med följande information:

  • Användarnamn
  • Hemkatalog som användaren ska vara låst till
  • Vilka rättigheter användaren ska ha; antingen läs, skriv eller båda

Crontab

För att schemalägga jobb via cron loggar du in på din server med SSH, och använder följande kommando i konsolen.

För att editera/skapa jobb:

:~$ crontab -e

För att lista jobb:

:~$ crontab -l

Om du är nyfiken på hur man kan använda cron-jobb rekommenderar vi den här artikeln.

Apache2

Vi ansvarar för tjänsten Apache2, att konfigurationen som behövs för att sätta upp nya webbplatser är korrekt och att proxy mot valfri backend sätts upp på ett effektivt sätt. Här är proxylösningarna vi använder för:

  • PHP (php-fpm)
  • Python (uwsgi)
  • Node.js (proxy ner mot applikationens port)

Du ansvarar för kodspecifik konfiguration i Apache2, till exempel redirect/rewrites som utförs i .htaccess.

Vi konfigurerar Apache2 så att varje webbplats som läggs upp får unika loggfiler enligt nedan:

  • /home/httpd/<user>/logs/<domain>-error.log
  • /home/httpd/<user>/logs/<domain>-access.log
Sätta upp ny webbplats

Om du får behov av att hosta ytterligare webbplatser på samma server så hjälper vi dig. Kontakta vår support och tala om vilken domän det gäller. Som standard får varje ny webbplats en unik användare med egna rättigheter för att öka säkerheten.

PHP

Debian 10 (Buster) kommer med PHP 7.3 som standard i sitt bibliotek av applikationer, men vi har också möjlighet att erbjuda PHP 7.2 och 7.4 via ett externt bibliotek. De versioner vi erbjuder just nu är alltså:

  • PHP 7.2
  • PHP 7.3
  • PHP 7.4

Vi kör PHP via php-fpm. Det innebär att vi kör din kod som din användare. Det vill säga, PHP exekveras och kommer skapa/ladda upp filer med din användare som ägare. Det gör att du slipper tänka på rättigheter på uploads-kataloger som world writable (chmod 777). Vi rekommenderar att du inte ändrar rättigheterna som vi har satt som standard (chmod 755 för kataloger och chmod 644 för filer).

Om du vill använda php-cli är det alltid den senaste versionen som /usr/bin/php länkar till. Vi rekommenderar att använda de alternativa sökvägarna till den specifika versionen av PHP:

  • /usr/bin/php7.2
  • /usr/bin/php7.3
  • /usr/bin/php7.4

MariaDB

Vi ansvarar för att tjänsten MariaDB är igång och kör. Vi optimerar även databasens egenskaper (historiska my.cnf) ihop med dig. Du får fulla rättigheter att själv skapa både databaser och användare.

Vi dumpar också alla dina databaser till fil varje kväll inför backupkörningen. Detta för att inte databaserna ska ligga öppna i RAM när vi går in och tar backup.

Skapa en ny databas i MariaDB

Här är ett exempel på hur du skapar en ny databas samt en unik användare som har fulla rättigheter till just den databasen. Ersätt new_database med namnet på databasen du vill skapa.

Logga in i MariaDB med kommandot:

mysql -u root -p

Skapa en ny databas med kommandot:

CREATE DATABASE new_database;

Query OK, 1 row affected (0.000 sec)

Skapa en användare för databasen: nånting med lösenord?

CREATE USER 'new_database'@'localhost' IDENTIFIED BY 'YOUR_PASSWORD';

Query OK, 0 rows affected (0.001 sec)

Ge behörigheter till användaren:

GRANT ALL PRIVILEGES ON new_database.* TO 'new_database'@'localhost';

Query OK, 0 rows affected (0.000 sec)

Ladda om behörigheterna för att försäkra dig om att de är sparade i den aktiva sessionen:

FLUSH PRIVILEGES;

Query OK, 0 rows affected (0.000 sec)

Avsluta med kommandot:

quit

Loggar in i databasen gör du med kommandot:

mysql -u new_database -p new_database

Som standard lyssnar MariaDB enbart på localhost. Det vill säga varken du eller någon annan kan nå databasen över internet.

Importera data i databasen

För att importera data till din nya databas kör du (ersätt export.sql med namnet på din dump):

mysql -u new_database -p new_database < export.sql

Utgående mail (Postfix)

Vi sätter som standard upp en SMTP-server för utgående e-post. Det gör att funktioner som mail() i PHP fungerar direkt. Behöver du ändra inställningarna för att ansluta till SMTP-servern gäller:

  • Host: localhost
  • Autentisering: Inget (localhost är redan vitlistad i brandväggen)

Elasticsearch

Vi kan installera den version av Elasticsearch du behöver till dina applikationer. Det vi behöver från dig är vilken vilken major version av Elasticsearch du vill använda, till exempel 6 eller 7.

Då installerar vi den version du vill ha och uppdaterar till nästa patchversion när den blir tillgänglig.

Vi ansvarar för att Elasticsearch är igång och är uppdaterat. I och med att all integration med Elasticsearch sköts via applikationen får du full kontroll och ansvarar därför för innehållet, inklusive Index och all typ av konfiguration som inte sker i fysiska filer.

För att testa om Elasticsearch fungerar som det ska kan du köra:

 curl -X GET "localhost:9200/?pretty"

Du bör få ett resultat liknande detta:

{
  "name" : "managed",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "02CRRmY1QT-_9lNNFcGTdw",
  "version" : {
    "number" : "7.6.2",
    "build_flavor" : "default",
    "build_type" : "deb",
    "build_hash" : "ef48eb35cf30adf4db14086e8aabd07ef6fb113f",
    "build_date" : "2020-03-26T06:34:37.794943Z",
    "build_snapshot" : false,
    "lucene_version" : "8.4.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Redis

Redis är en populär in-memory key-value-databas. Som standard lyssnar Redis enbart på localhost (inte nåbar över internet).

Vi använder standardinställningar för hur data sparas ner på disk. Om du använder Redis enbart för cache och vill spara datan i RAM istället för på disk, så konfigurerar vi det åt dig.

Här nedan ser du hur du ansluter med cli för att tömma cache och se statistik.

redis-cli
127.0.0.1:6379> select 1
OK
127.0.0.1:6379[1]> FLUSHDB
OK
127.0.0.1:6379[1]> select 0
OK
127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> INFO stats
# Stats
total_connections_received:4
total_commands_processed:26
instantaneous_ops_per_sec:0
total_net_input_bytes:574
total_net_output_bytes:49465
...

Memcached

Memcached är ett alternativ till Redis, som också en in-memory key-value-databas. Den är uppsatt på samma sätt som Redis, det vill säga den lyssnar bara på localhost och följer standarduppsättningsen så långt som möjligt.

Hos oss använder du den till exempel enligt följande:

telnet localhost 11211
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

flush_all
OK

quit
Connection closed by foreign host.

Node.js

Du kör med fördel din egna unika installation av Node.js och npm i din hemkatalog. Då är du inte beroende av de ganska gamla versionerna som följer med dagens operativsystem.

Så här sätter du upp din egna miljö på en systemförvaltad server.

Börja med att logga in med SSH. Efter det använder vi nvm för att installera vår miljö:

:~$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.3/install.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 13527  100 13527    0     0  69015      0 --:--:-- --:--:-- --:--:-- 69369
...
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Nu ska vi aktivera sökvägarna till Node.js genom att köra:

:~$ source $HOME/.bashrc
:~$ nvm install 12.16.1
Downloading and installing node v12.16.1...
Downloading https://nodejs.org/dist/v12.16.1/node-v12.16.1-linux-x64.tar.xz...
############################################################################################################################################################################################################ 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v12.16.1 (npm v6.13.4)
Creating default alias: default -> 12.16.1 (-> v12.16.1)
:~$ node -v
v12.16.1
:~$ npm -v
6.13.4

Därefter installerar vi express-ramverket för vår testapp:

:~$ npm install express
...
+ express@4.17.1
added 50 packages from 37 contributors and audited 126 packages in 2.156s
found 0 vulnerabilities

När det är gjort skapar vi en Hello World testapp:

:~$ nano -w app.js

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => res.send('Hello World!'))

app.listen(port, () => console.log(`Example app listening on port ${port}!`))

Node.js-applikationen lyssnar på port 3000, så om du vill testa att den startar korrekt, behöver du tala om för oss att vi ska ska öppna för port 3000 över TCP i brandväggen.

När det är gjort kan du testa att applikationen startar korrekt genom att köra:

:~$ node app.js
Example app listening on port 3000!

För att applikationen ska starta automatiskt vid till exempel omstarter använder vi systemd och en så kallad service-fil.

Skapa en katalog här:

mkdir -p ~/.config/systemd/user/

Skapa din service-fil i katalogen:

nano -w ~/.config/systemd/user/node.service

Klistra in följande i filen:

[Unit]
After=network.target
After=syslog.target

[Service]
WorkingDirectory=/home/httpd/<username>/
ExecStart=/home/httpd/<username>/.nvm/versions/node/v12.16.1/bin/node /home/httpd/<username>/app.js
Restart=always
StandardOutput=file:/home/httpd/<username>/logs/app.js-output.log
StandardError=file:/home/httpd/<username>/logs/app.js-error.log
SyslogIdentifier=username-node
Environment=NODE_ENV=production PORT=3000

[Install]
WantedBy=default.target

Nästa steg är att kontakta vår support så att vi ser till att din användare får korrekta rättigheter och kan köra processer även som utloggad (vi kör: loginctl enable-linger username).

När det är gjort är det dags att aktivera servicen så att den startas automatiskt vid uppstart:

:~$ systemctl --user enable node.service
Created symlink /home/httpd/eriksson/.config/systemd/user/multi-user.target.wants/node.service → /home/httpd/eriksson/.config/systemd/user/node.service.
:~$ systemctl --user start node.service
:~$ systemctl --user status node.service
● node.service
   Loaded: loaded (/home/httpd/eriksson/.config/systemd/user/node.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2020-03-11 12:36:02 UTC; 47s ago
 Main PID: 2230 (node)
   CGroup: /user.slice/user-2000.slice/user@2000.service/node.service
           └─2230 /home/httpd/eriksson/.nvm/versions/node/v12.16.1/bin/node /home/httpd/eriksson/app.js

Mar 11 12:36:02 managed systemd[1549]: Started node.service.
Mar 11 12:36:02 managed eriksson-node[2230]: Example app listening on port 3000!

Avslutningsvis skapar vi en vhost för Apache2 som skickar all trafik vidare till port 3000 som du nu har satt upp.

Python webbapplikation

Vi använder Uwsgi för att köra igång din Python-applikation – som i sin tur skapar en socket som Apache2 skickar alla anslutningar mot. Uwsgi har ett läge emperor mode där du själv hanterar konfigurationsfilen för din applikation och kan starta om den vid till exempel deploy.

Vi börjar med att skapa ett Python Virtual Environment. Fördelen är att du som kund inte är beroende av vad GleSYS har för Python-moduler installerade på din server. Du sköter dig helt själv och har full frihet att installera precis vad du vill innan för din virtuella miljö med python pip.

I vårt exempel kör vi igång en Flask-applikation:

python3 -m venv python3-venv
source python3-venv/bin/activate
pip install flask

Skapa ett simpelt "Hello World" Python-skript. Du kan skapa detta projekt på valfritt ställe men det måste matcha i Uwsgi-konfigurationen sen.

I detta exempel använder vi följande katalog /home/httpd/<username>/<site>. Gå in i den och skapa en fil som innehåller:

nano -w myproject.py

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
    return "<h1 style='color:blue'>Hello There!</h1>"

if __name__ == "__main__":
    app.run(host='0.0.0.0')

Nästa steg är att skapa ett WSGI-startskript som kommer anropas av uWSGI senare.

nano -w wsgi.py

from myproject import app

if __name__ == "__main__":
    app.run()

Nu ska vi titta på din uWSGI-konfigurationsfil.

Förklaringar av viktiga sökvägar:

chdir: sökvägen till wsgi.py-skriptet home: sökvägen till ditt Python Virtual Environment som uWSGI kommer att hämta Python-bibliotek ifrån. socket: sökvägen till socketen som Apache2 använder för att kommunicera med din applikation. logto: sökvägen till loggfilen (den bör inte ändras, men det är bra känna var den finns).

Vi har skapat en katalog åt dig /home/httpd/<username>/vassels som uWSGI kollar i efter konfigurationsfiler.

Skapa din uWSGI-konfigurationsfil i den katalogen:

nano -w /home/httpd/<username>/vassels/myapp.ini

[uwsgi]
plugins=python3,logfile
# the base directory (full path)
chdir           = /home/httpd/<username>/<site>
# Django's wsgi file /home/httpd/<username>/<site>/wsgi.py
wsgi-file          = wsgi.py
# the virtualenv (full path)
home            = /home/httpd/<username>/python3-venv
callable        = app

# process-related settings
# master
master          = true
# maximum number of worker processes
processes       = 10
# the socket (use the full path to be safe
socket          = /home/httpd/<username>/uwsgi.sock
# ... with appropriate permissions - may be needed
# chmod-socket    = 664
# clear environment on exit
vacuum          = true
thunder-lock    = true
enable-threads  = true

logto = /home/httpd/<username>/logs/uwsgi.log

Som vi nämnde tidigare är en fördel med emperor mode; att om du vill göra en ändring eller starta om applikationen vid till exempel ny deploy, är det bara för dig att köra:

touch /home/httpd/<username>/vassels/myapp.ini

uWSGI känner då av att filen är modifierad och triggar en omstart automatiskt.

Varnish

Flera av våra kunder använder sig av Varnish. Varnish fungerar som en reverse proxy och cachar innehåll mellan användaren och webbservern för att snabba upp åtkomsten till din webbplats, särskilt under perioder med hög trafik.

Magento 2 genererar till exempel en färdig varnish.vcl via administrationsgränssnittet.

En anledning till att Varnish är så kraftfullt är att mjukvaran kan anpassas till att fungera bra med vilken kod som helst. Alternativt kan du gå andra hållet och anpassa koden efter hur Varnish fungerar med bland annat cache headers. Vi har självklart stöd för båda alternativen.

Väljer du det första alternativet ställer det höga krav på dig och att du vet hur din webbplats är uppbygd. I det fallet ansvarar du för både Varnish-konfigurationen och din kodbas, eftersom de är så tätt sammanlänkade.

Den Varnish-konfiguration vi installerar är följande:

# Marker to tell the VCL compiler that this VCL has been adapted to the
# new 4.0 format.
vcl 4.0;

# Default backend definition. Set this to point to your content server.
backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    # Happens before we check if we have this in cache already.
    #
    # Typically you clean up the request here, removing cookies you don't need,
    # rewriting the request, etc.
}

sub vcl_backend_response {
    # Happens after we have read the response headers from the backend.
    #
    # Here you clean the response headers, removing silly Set-Cookie headers
    # and other mistakes your backend does.
}

sub vcl_deliver {
    # Happens when we have all the pieces we need, and are about to send the
    # response to the client.
    #
    # You can do accounting or modifying the final object here.
}

Detta är den konfiguration som kommer med Debian, och den är fullt fungerande om webbplatsen är anpassad för Varnish.

Undantag där vi alltid tar ansvar är stycket:

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

Det beror på att det är vi som konfigurerar och ansvarar för webbservern vilket gör det naturligt att vi även anpassar detta.

Vill du frångå vår standard kan du ladda upp en egen varnish.vcl till din server och meddela oss vart den finns, så anpassar vi den med korrekt backend och aktiverar den.

SSL/TLS-certifikat via Let's Encrypt

Vi kan hjälpa dig med SSL/TLS-certifikat för din webbplats. Vi använder oss av Let's Encrypt och ansvarar för övervakning och ser till att certifikatet alltid förnyas och är giltigt.

För att vi ska kunna aktivera ett Let's Encrypt-certifikat måste du peka den domän som du vill använda mot IP-adressen som din systemförvaltade server använder. När det är på plats kan vi generera ett certifikat åt dig.

Själva certifikatet är gratis och vi tar endast betalt för den administrativa hanteringen. Kostnaden för certifikat är:

1 certifikat = 20 kr per månad 2–19 = 10 kr/st per månad 20–99 = 5 kr/st per månad

Hittar du inte det du söker?

Kontakta oss gärna för mer information. Vi hjälper dig att komma fram till den bästa lösningen för dina behov.

Skicka e-post Ring 0200-23 88 00