
Der findes mange materialer om installation af WordPress; en Google-søgning på nøgleordene "WordPress install" vil give omkring en halv million resultater. Men der er faktisk meget få gode vejledninger blandt dem, som kan hjælpe med at installere og konfigurere WordPress samt det underliggende operativsystem, så de er i stand til at understøtte det i en længere periode. Måske afhænger de rigtige indstillinger meget af specifikke behov, eller også skyldes det, at en detaljeret forklaring gør artiklen sværere at læse.
I denne artikel vil vi prøve at samle det bedste fra to tilgange ved at give et bash-script til automatisk installation af WordPress på Ubuntu, og vi vil gennemgå det, forklare hvad hver del gør, samt hvilke indbyrdes kompromiser vi gik på kompromis med under udviklingen. Hvis du er en erfaren bruger, kan du springe selve teksten over i artiklen og blot til modifikation og brug i dine miljøer. Udgangen af scriptet resulterer i en konfigurerbar WordPress-installation med Lets Encrypt-support, der kører på NGINX Unit og egner sig til industriel anvendelse.
Den udviklede arkitektur for implementering af WordPress ved brug af NGINX Unit er beskrevet i , nu vil vi også yderligere konfigurere ting, som ikke blev dækket der (som i mange andre vejledninger):
- WordPress CLI
- Let’s Encrypt og TLS/SSL-certifikater
- Automatisk opdatering af certifikater
- NGINX caching
- NGINX kompression
- Support for HTTPS og HTTP/2
- Automatisering af processen
Artiklen vil beskrive installation på en enkelt server, som samtidig vil hoste en statisk server, en PHP-behandlingsserver og en database. Installation med støtte for flere virtuelle værter og tjenester er et potentielt emne til fremtiden. Hvis du ønsker, at vi skal skrive om noget, som ikke er dækket i disse artikler, så skriv i kommentarerne.
Krav
- Container-server ( eller ), en virtuel maskine eller en almindelig dedikeret server med mindst 512 MB RAM og installeret Ubuntu 18.04 eller nyere.
- Tilgængelige porte fra internettet 80 og 443
- Et domænenavn knyttet til den offentlige IP-adresse på denne server
- Adgang med root-rettigheder (sudo).
Oversigt over arkitekturen
Arkitekturen er den samme som beskrevet , en tre-niveau web-applikation. Den består af PHP-scripts, der køres på PHP-fortolkeren, og statiske filer, der behandles af webserveren.

Generelle principper
- Mange kommandoer til konfiguration i scriptet er indkapslet i betingelser (if) for idempotens: scriptet kan køres flere gange uden risiko for at ændre indstillinger, der allerede er klar.
- Scriptet forsøger at installere software fra repositories, så du kan anvende systemopdateringer med en enkelt kommando (
apt upgradetil Ubuntu). - Kommandoerne forsøger at identificere, at de kører i en container, for at ændre deres indstillinger i overensstemmelse hermed.
- For at angive antallet af kørende processer/ tråde i indstillingerne, prøver scriptet at gætte de automatiske konfigurationsparametre til brug i containere, virtuelle maskiner og 'bare metal'-servere.
- Når vi beskriver indstillinger, tænker vi altid først på automatisering, som vi håber vil danne grundlaget for opbygningen af din egen infrastruktur som kode.
- Alle kommandoer køres som bruger root, da de ændrer de grundlæggende systemindstillinger, men WordPress fungerer direkte som en almindelig bruger.
Opsætning af miljøvariabler
Indstil følgende miljøvariabler, før du kører scriptet:
WORDPRESS_DB_PASSWORD— adgangskoden til WordPress-databasenWORDPRESS_ADMIN_USER— brugernavnet til WordPress-administratorenWORDPRESS_ADMIN_PASSWORD— adgangskoden til WordPress-administratorenWORDPRESS_ADMIN_EMAIL— e-mail til WordPress-administratorenWORDPRESS_URL— den fulde URL til WordPress-webstedet, der starter medhttps://.LETS_ENCRYPT_STAGING— tom som standard, men ved at sætte værdien til 1, vil du bruge Let’s Encrypt staging-servere, som er nødvendige for hyppige anmodninger om certifikater, mens du tester dine indstillinger, ellers kan Let’s Encrypt midlertidigt blokere din IP-adresse på grund af et stort antal anmodninger.
Scriptet kontrollerer, at disse WordPress-relaterede variabler er angivet, og afslutter arbejdet, hvis ikke.
Linjerne i scriptet 572-576 kontrollerer værdien LETS_ENCRYPT_STAGING.
Opsætning af afledte miljøvariabler
Scriptet i linjerne 55-61 sætter følgende miljøvariabler, enten til nogle hårdt kodede værdier eller ved at bruge værdier hentet fra variabler, der er angivet i det foregående afsnit:
DEBIAN_FRONTEND="noninteractive"— informerer applikationer om, at de kører i et script, og at der ikke er mulighed for brugerinteraktion.WORDPRESS_CLI_VERSION="2.4.0"— version af WordPress CLI applikationen.WORDPRESS_CLI_MD5="dedd5a662b80cda66e9e25d44c23b25c"— kontrolsum af WordPress CLI 2.4.0 eksekverbar fil (versionen angives i variablenWORDPRESS_CLI_VERSION). Scriptet på linje 162 bruger denne værdi til at kontrollere, at den korrekte WordPress CLI fil er blevet downloadet.UPLOAD_MAX_FILESIZE="16M"— den maksimale filstørrelse, der kan uploads til WordPress. Denne indstilling bruges flere steder, så det er nemmere at definere den ét sted.TLS_HOSTNAME="$(echo ${WORDPRESS_URL} | cut -d'/' -f3)"— systemets hostname, udtrukket fra variablen WORDPRESS_URL. Bruges til at hente de relevante TLS/SSL certifikater fra Let’s Encrypt samt til intern kontrol af WordPress.NGINX_CONF_DIR="/etc/nginx"— stien til NGINX konfigurationskataloget, inklusive hovedfilennginx.conf.CERT_DIR="/etc/letsencrypt/live/${TLS_HOSTNAME}"— stien til Let’s Encrypt certifikaterne for WordPress hjemmesiden, hentet fra variablenTLS_HOSTNAME.
Tildeling af hostname til WordPress serveren
Scriptet indstiller hostname for serveren, så værdien svarer til hjemmesidens domænenavn. Dette er ikke obligatorisk, men gør det nemmere at sende udgående e-mails via SMTP, når man setter en enkelt server op, som scriptet konfigurerer.
scriptkode
# Change the hostname to be the same as the WordPress hostname
if [ ! "$(hostname)" == "${TLS_HOSTNAME}" ]; then
echo " Changing hostname to ${TLS_HOSTNAME}"
hostnamectl set-hostname "${TLS_HOSTNAME}"
fiTilføjelse af hostname til /etc/hosts
Tilføjelse bruges til at køre periodiske opgaver, kræver at WordPress kan tilgå sig selv via HTTP. For at sikre, at WP-Cron fungerer korrekt i alle miljøer, tilføjer scriptet en linje i filen /etc/hosts, så WordPress kan tilgå sig selv gennem loopback interfacet:
scriptkode
# Add the hostname to /etc/hosts
if [ "$(grep -m1 "${TLS_HOSTNAME}" /etc/hosts)" = "" ]; then
echo " Adding hostname ${TLS_HOSTNAME} to /etc/hosts so that WordPress can ping itself"
printf "::1 %sn127.0.0.1 %sn" "${TLS_HOSTNAME}" "${TLS_HOSTNAME}" >> /etc/hosts
fiInstallation af værktøjer, der kræves til de efterfølgende trin
Den resterende del af scriptet har brug for nogle programmer og forudsætter, at repository’er er opdaterede. Vi opdaterer listen over repository’er, hvorefter vi installerer de nødvendige værktøjer:
scriptkode
# Make sure tools needed for install are present
echo " Installing prerequisite tools"
apt-get -qq update
apt-get -qq install -y
bc
ca-certificates
coreutils
curl
gnupg2
lsb-releaseTilføjelse af NGINX Unit og NGINX repositories
Scriptet installerer NGINX Unit og NGINX fra de officielle NGINX repositories for at sikre, at der bruges versioner med de nyeste sikkerhedsopdateringer og fejlrettelser.
Scriptet tilføjer NGINX Unit repository’et, og derefter NGINX repository’et, ved at tilføje repository-nøglen og konfigurationsfilene apt, der definere adgangen til repository’er via internettet.
Den faktiske installation af NGINX Unit og NGINX finder sted i det følgende afsnit. Vi tilføjer først repositories for ikke at opdatere metadata flere gange, hvilket gør installationen hurtigere.
scriptkode
# Install the NGINX Unit repository
if [ ! -f /etc/apt/sources.list.d/unit.list ]; then
echo " Installing NGINX Unit repository"
curl -fsSL https://nginx.org/keys/nginx_signing.key | apt-key add -
echo "deb https://packages.nginx.org/unit/ubuntu/ $(lsb_release -cs) unit" > /etc/apt/sources.list.d/unit.list
fi
# Install the NGINX repository
if [ ! -f /etc/apt/sources.list.d/nginx.list ]; then
echo " Installing NGINX repository"
curl -fsSL https://nginx.org/keys/nginx_signing.key | apt-key add -
echo "deb https://nginx.org/packages/mainline/ubuntu $(lsb_release -cs) nginx" > /etc/apt/sources.list.d/nginx.list
fiInstallation af NGINX, NGINX Unit, PHP, MariaDB, Certbot (Let’s Encrypt) og deres afhængigheder
Når alle repositories er tilføjet, opdaterer vi metadataene og installerer applikationerne. Pakkerne, der installeres af scriptet, inkluderer også PHP-udvidelser, der anbefales ved opsætning af WordPress.org
scriptkode
echo " Opdaterer repository metadata"
apt-get -qq update
# Installerer PHP med afhængigheder og NGINX Unit
echo " Installerer PHP, NGINX Unit, NGINX, Certbot, og MariaDB"
apt-get -qq install -y --no-install-recommends
certbot
python3-certbot-nginx
php-cli
php-common
php-bcmath
php-curl
php-gd
php-imagick
php-mbstring
php-mysql
php-opcache
php-xml
php-zip
ghostscript
nginx
unit
unit-php
mariadb-serverKonfigurering af PHP til brug med NGINX Unit og WordPress
Scriptet opretter en konfigurationsfil i mappen conf.d. Her angives den maksimale størrelse på uploadede filer til PHP, PHP-fejlrapportering aktiveres til STDERR, så de bliver logget i NGINX Unit, og NGINX Unit genstartes.
scriptkode
# Find the major and minor PHP version so that we can write to its conf.d directory
PHP_MAJOR_MINOR_VERSION="$(php -v | head -n1 | cut -d' ' -f2 | cut -d'.' -f1,2)"
if [ ! -f "/etc/php/${PHP_MAJOR_MINOR_VERSION}/embed/conf.d/30-wordpress-overrides.ini" ]; then
echo " Configuring PHP for use with NGINX Unit and WordPress"
# Add PHP configuration overrides
cat > "/etc/php/${PHP_MAJOR_MINOR_VERSION}/embed/conf.d/30-wordpress-overrides.ini" << EOM
; Set a larger maximum upload size so that WordPress can handle
; bigger media files.
upload_max_filesize=${UPLOAD_MAX_FILESIZE}
post_max_size=${UPLOAD_MAX_FILESIZE}
; Write error log to STDERR so that error messages show up in the NGINX Unit log
error_log=/dev/stderr
EOM
fi
# Restart NGINX Unit because we have reconfigured PHP
echo " Restarting NGINX Unit"
service unit restartAngivelse af databaseindstillinger for MariaDB til WordPress
Vi valgte MariaDB frem for MySQL, da den har større samfundsaktivitet, og den tilbyder muligvis (sandsynligvis er det alt sammen enklere: for at installere MySQL skal man tilføje endnu et repository, bemærk fra oversætteren).
Scriptet opretter en ny database og skaber legitimationsoplysninger til adgang for WordPress via loopback-grænsefladen:
scriptkode
# Set up the WordPress database
echo " Configuring MariaDB for WordPress"
mysqladmin create wordpress || echo "Ignoring above error because database may already exist"
mysql -e "GRANT ALL PRIVILEGES ON wordpress.* TO "wordpress"@"localhost" IDENTIFIED BY "$WORDPRESS_DB_PASSWORD"; FLUSH PRIVILEGES;"Installation af WordPress CLI
I dette trin installerer scriptet . Med det kan du installere og administrere WordPress-indstillinger uden at skulle redigere filer manuelt, opdatere databasen eller logge ind på kontrolpanelet. Det kan også bruges til at installere temaer og plugins samt udføre WordPress-opdateringer.
scriptkode
if [ ! -f /usr/local/bin/wp ]; then
# Installerer WordPress CLI
echo " Installerer WordPress CLI-værktøjet"
curl --retry 6 -Ls "https://github.com/wp-cli/wp-cli/releases/download/v${WORDPRESS_CLI_VERSION}/wp-cli-${WORDPRESS_CLI_VERSION}.phar" > /usr/local/bin/wp
echo "$WORDPRESS_CLI_MD5 /usr/local/bin/wp" | md5sum -c -
chmod +x /usr/local/bin/wp
fiInstallation og konfigurering af WordPress
Scriptet installerer den nyeste version af WordPress i mappen /var/www/wordpress, og ændrer også indstillingerne:
- Forbindelsen til databasen fungerer via unix domain socket i stedet for TCP på loopback for at reducere TCP-trafikken.
- WordPress tilføjer et præfiks https:// til URL, når kunderne opretter forbindelse til NGINX via HTTPS-protokollen, og sender det eksterne hostname (som NGINX leverer) til PHP. Vi anvender et stykke kode for at konfigurere dette.
- WordPress kræver HTTPS for login
- Standard URL-struktur er baseret på ressourcer
- De korrekte rettigheder er indstillet på filsystemet for WordPress-mappen.
scriptkode
if [ ! -d /var/www/wordpress ]; then
# Opret WordPress-mapper
mkdir -p /var/www/wordpress
chown -R www-data:www-data /var/www
# Download WordPress med WordPress CLI
echo "Installerer WordPress"
su -s /bin/sh -c 'wp --path=/var/www/wordpress core download' www-data
WP_CONFIG_CREATE_CMD="wp --path=/var/www/wordpress config create --extra-php --dbname=wordpress --dbuser=wordpress --dbhost='localhost:/var/run/mysqld/mysqld.sock' --dbpass='${WORDPRESS_DB_PASSWORD}'"
# Dette snippet bliver indsat i wp-config.php-filen, når den oprettes;
# det informerer WordPress om, at vi er bag en omvendt proxy og derved
# muliggør, at den genererer links ved hjælp af HTTPS
cat > /tmp/wp_forwarded_for.php << 'EOM'
/* Tænd for HTTPS, hvis HTTP_X_FORWARDED_PROTO matcher 'https' */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
$_SERVER['HTTPS'] = 'on';
}
if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
}
EOM
# Opret WordPress-konfiguration
su -s /bin/sh -p -c "cat /tmp/wp_forwarded_for.php | ${WP_CONFIG_CREATE_CMD}" www-data
rm /tmp/wp_forwarded_for.php
su -s /bin/sh -p -c "wp --path=/var/www/wordpress config set 'FORCE_SSL_ADMIN' 'true'" www-data
# Installer WordPress
WP_SITE_INSTALL_CMD="wp --path=/var/www/wordpress core install --url='${WORDPRESS_URL}' --title='${WORDPRESS_SITE_TITLE}' --admin_user='${WORDPRESS_ADMIN_USER}' --admin_password='${WORDPRESS_ADMIN_PASSWORD}' --admin_email='${WORDPRESS_ADMIN_EMAIL}' --skip-email"
su -s /bin/sh -p -c "${WP_SITE_INSTALL_CMD}" www-data
# Sæt permalink-struktur til en fornuftig standard, som ikke er i UI'en
su -s /bin/sh -p -c "wp --path=/var/www/wordpress option update permalink_structure '/%year%/%monthnum%/%postname%/'" www-data
# Fjern eksempel-filen, da den er unødvendig og kan være et sikkerhedsproblem
rm /var/www/wordpress/wp-config-sample.php
# Sørg for, at WordPress-rettighederne er korrekte
find /var/www/wordpress -type d -exec chmod g+s {} ;
chmod g+w /var/www/wordpress/wp-content
chmod -R g+w /var/www/wordpress/wp-content/themes
chmod -R g+w /var/www/wordpress/wp-content/plugins
fiKonfiguration af NGINX Unit
Scriptet konfigurerer NGINX Unit til at køre PHP og håndtere WordPress-stier, isolerende PHP-processernes namespaces og optimerende ydeevneindstillingerne. Der er tre funktioner, som det er værd at bemærke:
- Namespace-support bestemmes ud fra en betingelse, baseret på at kontrollere, om scriptet kører i en container. Dette er nødvendigt, fordi de fleste containerindstillinger ikke understøtter indlejrede containerkørsler.
- Hvis der er support for namespaces, deaktiveres namespaces netværk. Dette er nødvendigt for at tillade WordPress at oprette forbindelse til både endpoints og være tilgængelig på internettet.
- Det maksimale antal processer bestemmes som følger: (Tilgængelig hukommelse til kørende MariaDB og NGINX Uniy) / (grænsen for RAM i PHP + 5)
Denne værdi indstilles i NGINX Units indstillinger.
Denne værdi antager også, at der altid er mindst to kørende PHP-processer, hvilket er vigtigt, da WordPress laver mange asynkrone forespørgsler til sig selv, og uden ekstra processer ville eksempelvis kørsel af WP-Cron fejle. Du ønsker måske at øge eller mindske disse grænser baseret på dine lokale indstillinger, da de indstillede værdier her er konservative. På de fleste produktionssystemer ligger indstillingerne mellem 10 og 100.
scriptkode
if [ "${container:-unknown}" != "lxc" ] && [ "$(grep -m1 -a container=lxc /proc/1/environ | tr -d ' ')" == "" ]; then
NAMESPACES='"namespaces": {
"cgroup": true,
"credential": true,
"mount": true,
"network": false,
"pid": true,
"uname": true
}'
else
NAMESPACES='"namespaces": {}'
fi
PHP_MEM_LIMIT="$(grep 'memory_limit' /etc/php/7.4/embed/php.ini | tr -d ' ' | cut -f2 -d= | numfmt --from=iec)"
AVAIL_MEM="$(grep MemAvailable /proc/meminfo | tr -d ' kB' | cut -f2 -d: | numfmt --from-unit=K)"
MAX_PHP_PROCESSES="$(echo "${AVAIL_MEM}/${PHP_MEM_LIMIT}+5" | bc)"
echo "Beregnet det maksimale antal PHP-processer som ${MAX_PHP_PROCESSES}. Du ønsker måske at justere denne værdi på grund af variationer i din konfiguration. Det er ikke usædvanligt at se værdier mellem 10-100 i produktionskonfigurationer."
echo "Konfigurerer NGINX Unit til at bruge PHP og WordPress"
cat > /tmp/wordpress.json << EOM
{
"settings": {
"http": {
"header_read_timeout": 30,
"body_read_timeout": 30,
"send_timeout": 30,
"idle_timeout": 180,
"max_body_size": $(numfmt --from=iec ${UPLOAD_MAX_FILESIZE})
}
},
"listeners": {
"127.0.0.1:8080": {
"pass": "routes/wordpress"
}
},
"routes": {
"wordpress": [
{
"match": {
"uri": [
"*.php",
"*.php/*",
"/wp-admin/"
]
},
"action": {
"pass": "applications/wordpress/direct"
}
},
{
"action": {
"share": "/var/www/wordpress",
"fallback": {
"pass": "applications/wordpress/index"
}
}
}
]
},
"applications": {
"wordpress": {
"type": "php",
"user": "www-data",
"group": "www-data",
"processes": {
"max": ${MAX_PHP_PROCESSES},
"spare": 1
},
"isolation": {
${NAMESPACES}
},
"targets": {
"direct": {
"root": "/var/www/wordpress/"
},
"index": {
"root": "/var/www/wordpress/",
"script": "index.php"
}
}
}
}
}
EOM
curl -X PUT --data-binary @/tmp/wordpress.json --unix-socket /run/control.unit.sock http://localhost/configKonfiguration af NGINX
Konfiguration af grundlæggende NGINX-parametre
Scriptet opretter et bibliotek til NGINX cache og derefter opretter hovedkonfigurationsfilen nginx.confBemærk antallet af processer-behandlere og angiv den maksimale filstørrelse for uploads. Der er også en linje, hvor konfigurationsfilen for komprimering tilsluttes, som defineres i det følgende afsnit, efterfulgt af cache-indstillinger.
scriptkode
# Make directory for NGINX cache
mkdir -p /var/cache/nginx/proxy
echo " Configuring NGINX"
cat > ${NGINX_CONF_DIR}/nginx.conf << EOM
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include ${NGINX_CONF_DIR}/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
client_max_body_size ${UPLOAD_MAX_FILESIZE};
keepalive_timeout 65;
# gzip settings
include ${NGINX_CONF_DIR}/gzip_compression.conf;
# Cache settings
proxy_cache_path /var/cache/nginx/proxy
levels=1:2
keys_zone=wp_cache:10m
max_size=10g
inactive=60m
use_temp_path=off;
include ${NGINX_CONF_DIR}/conf.d/*.conf;
}
EOMNGINX komprimeringsindstillinger
On-the-fly komprimering af indhold før det sendes til kunderne er en fremragende måde at forbedre websitets ydeevne på, men det kræver korrekt konfiguration. Dette afsnit af scriptet er baseret på indstillingerne. .
scriptkode
cat > ${NGINX_CONF_DIR}\/gzip_compression.conf << 'EOM'
# Credit: https://github.com/h5bp/server-configs-nginx/
# ----------------------------------------------------------------------
# | Komprimering |
# ----------------------------------------------------------------------
# https://nginx.org/en/docs/http/ngx_http_gzip_module.html
# Aktiver gzip kompression.
# Standard: off
gzip on;
# Komprimeringsniveau (1-9).
# 5 er et perfekt kompromis mellem størrelse og CPU-forbrug, der tilbyder cirka 75%
# reduktion for de fleste ASCII-filer (næsten identisk med niveau 9).
# Standard: 1
gzip_comp_level 6;
# Komprimer ikke noget, der allerede er småt, og som næppe vil kunne reduceres meget, hvis overhovedet
# (standarden er 20 bytes, hvilket er dårligt, da det normalt fører til større
# filer efter gzipping).
# Standard: 20
gzip_min_length 256;
# Komprimer data, selv for kunder, der forbinder til os via proxy,
# identificeret af "Via" headeren (påkrævet for CloudFront).
# Standard: off
gzip_proxied any;
# Fortæl proxyer at cache både den gzippede og regulære version af en ressource
# hver gang klientens Accept-Encoding kapaciteter header varierer;
# Undgår problemet, hvor en ikke-gzip komprimeret klient (som er ekstremt sjælden
# i dag) ville vise gibberish, hvis deres proxy gav dem den gzippede version.
# Standard: off
gzip_vary on;
# Komprimer al output mærket med en af de følgende MIME-typer.
# `text/html` komprimeres altid af gzip-modulet.
# Standard: text/html
gzip_types
application/atom+xml
application/geo+json
application/javascript
application/x-javascript
application/json
application/ld+json
application/manifest+json
application/rdf+xml
application/rss+xml
application/vnd.ms-fontobject
application/wasm
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/eot
font/otf
font/ttf
image/bmp
image/svg+xml
text/cache-manifest
text/calendar
text/css
text/javascript
text/markdown
text/plain
text/xml
text/vcard
text/vnd.rim.location.xloc
text/vtt
text/x-component
text/x-cross-domain-policy;
EOMKonfiguration af NGINX til WordPress
Derefter opretter scriptet en konfigurationsfil til WordPress default.conf i katalogen conf.d. Her konfigureres:
- Aktivering af TLS-certifikater fra Let’s Encrypt via Certbot (dens konfiguration vil være i det næste afsnit)
- Konfiguration af TLS-sikkerhedsindstillinger baseret på anbefalinger fra Let’s Encrypt
- Aktivering af caching for forbipasserende forespørgsler i 1 time som standard
- Deaktivering af adgangslogning samt logning af fejl, hvis filen ikke findes, for to ofte anmodede filer: favicon.ico og robots.txt
- Forbud mod adgang til skjulte filer og visse filer .php, for at forhindre uautoriseret adgang eller utilsigtet start
- Deaktivering af adgangslogning for statiske filer og skrifttyper
- Angivelse af header for skrifttyper
- Tilføjelse af routing for index.php og andre statiske filer.
scriptkode
cat > ${NGINX_CONF_DIR}\/conf.d\/default.conf << EOM
upstream unit_php_upstream {
server 127.0.0.1:8080;
keepalive 32;
}
server {
listen 80;
listen [::]:80;
# ACME-challenge brugt af Certbot til Let's Encrypt
location ^~ \/.well-known\/acme-challenge\/ {
root \/var\/www\/certbot;
}
location \/ {
return 301 https:\/${TLS_HOSTNAME}$request_uri;
}
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name ${TLS_HOSTNAME};
root \/var\/www\/wordpress\/;
# Let's Encrypt konfiguration
ssl_certificate ${CERT_DIR}\/fullchain.pem;
ssl_certificate_key ${CERT_DIR}\/privkey.pem;
ssl_trusted_certificate ${CERT_DIR}\/chain.pem;
include ${NGINX_CONF_DIR}\/options-ssl-nginx.conf;
ssl_dhparam ${NGINX_CONF_DIR}\/ssl-dhparams.pem;
# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;
# Proxy caching
proxy_cache wp_cache;
proxy_cache_valid 200 302 1h;
proxy_cache_valid 404 1m;
proxy_cache_revalidate on;
proxy_cache_background_update on;
proxy_cache_lock on;
proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
location = \/favicon.ico {
log_not_found off;
access_log off;
}
location = \/robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Forbyde alle forsøg på at tilgå skjulte filer som .htaccess, .htpasswd,
# .DS_Store (Mac)
# Fortsæt med at logge anmodningerne for at analysere senere (eller overføre til firewall værktøjer
# som fail2ban)
location ~ \/. {
deny all;
}
# Forbyd adgang til alle filer med en .php-udvidelse i upload-mappen;
# fungerer også i installationsmænd i undermappen og i multisite-netværk.
# Fortsæt med at logge anmodningerne for at analysere senere (eller overføre til firewall værktøjer
# som fail2ban).
location ~* \/(?:uploads|files)\/.*.php$ {
deny all;
}
# WordPress: forbyd adgang til wp-content, wp-includes PHP-filer
location ~* ^\/(?:wp-content|wp-includes)\/.*.php$ {
deny all;
}
# Forbyd offentlig adgang til wp-config.php
location ~* wp-config.php {
deny all;
}
# Log ikke adgang for statiske aktiver, medier
location ~* .(?:css(.map)?|js(.map)?|jpe?g|png|gif|ico|cur|heic|webp|tiff?|mp3|m4a|aac|ogg|midi?|wav|mp4|mov|webm|mpe?g|avi|ogv|flv|wmv)$ {
access_log off;
}
location ~* .(?:svgz?|ttf|ttc|otf|eot|woff2?)$ {
add_header Access-Control-Allow-Origin "*";
access_log off;
}
location \/ {
try_files $uri @index_php;
}
location @index_php {
proxy_socket_keepalive on;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
proxy_pass http:\/\/unit_php_upstream;
}
location ~* .php$ {
proxy_socket_keepalive on;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
try_files $uri =404;
proxy_pass http:\/\/unit_php_upstream;
}
}
EOMKonfiguration af Certbot til certificater fra Let’s Encrypt og deres automatiske fornyelse
er et gratis værktøj fra Electronic Frontier Foundation (EFF), der gør det muligt at modtage og automatisk opdatere TLS-certifikater fra Let’s Encrypt. Scriptet udfører følgende handlinger, der fører til konfiguration af Certbot til håndtering af certificater fra Let’s Encrypt i NGINX:
- Stopper NGINX
- Downloader anbefalede TLS-parametre
- Starter Certbot for at få certifikater til websitet
- Genstarter NGINX for at anvende certifikaterne
- Konfigurerer daglig kørsel af Certbot kl. 3:24 om natten for at kontrollere behovet for opdatering af certifikaterne samt, om nødvendigt, download af nye certifikater og genstart af NGINX.
scriptkode
echo " Stopper NGINX for at konfigurere Let's Encrypt"
service nginx stop
mkdir -p /var/www/certbot
chown www-data:www-data /var/www/certbot
chmod g+s /var/www/certbot
if [ ! -f ${NGINX_CONF_DIR}/options-ssl-nginx.conf ]; then
echo " Downloader anbefalede TLS-parametre"
curl --retry 6 -Ls -z "Tue, 14 Apr 2020 16:36:07 GMT"
-o "${NGINX_CONF_DIR}/options-ssl-nginx.conf"
"https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf"
|| echo "Kunne ikke downloade seneste options-ssl-nginx.conf"
fi
if [ ! -f ${NGINX_CONF_DIR}/ssl-dhparams.pem ]; then
echo " Downloader anbefalede TLS DH-parametre"
curl --retry 6 -Ls -z "Tue, 14 Apr 2020 16:49:18 GMT"
-o "${NGINX_CONF_DIR}/ssl-dhparams.pem"
"https://raw.githubusercontent.com/certbot/certbot/master/certbot/certbot/ssl-dhparams.pem"
|| echo "Kunne ikke downloade seneste ssl-dhparams.pem"
fi
# Hvis tls_certs_init.sh ikke er blevet kørt før, fjern de selvsignerede certifikater
if [ ! -d "/etc/letsencrypt/accounts" ]; then
echo " Fjerner selvsignerede certifikater"
rm -rf "${CERT_DIR}"
fi
if [ "" = "${LETS_ENCRYPT_STAGING:-}" ] || [ "0" = "${LETS_ENCRYPT_STAGING}" ]; then
CERTBOT_STAGING_FLAG=""
else
CERTBOT_STAGING_FLAG="--staging"
fi
if [ ! -f "${CERT_DIR}/fullchain.pem" ]; then
echo " Genererer certifikater med Let's Encrypt"
certbot certonly --standalone
-m "${WORDPRESS_ADMIN_EMAIL}"
${CERTBOT_STAGING_FLAG}
--agree-tos --force-renewal --non-interactive
-d "${TLS_HOSTNAME}"
fi
echo " Starter NGINX for at bruge ny konfiguration"
service nginx start
# Skriv crontab for periodisk fornyelse af Let's Encrypt certifikat
if [ "$(crontab -l | grep -m1 'certbot renew')" == "" ]; then
echo " Føjer certbot til crontab for automatisk fornyelse af Let's Encrypt"
(crontab -l 2>/dev/null; echo "24 3 * * * certbot renew --nginx --post-hook 'service nginx reload'") | crontab -
fiYderligere konfiguration af dit website
Vi har tidligere forklaret, hvordan vores script konfigurerer NGINX og NGINX Unit til at betjene et produktionsklart website med aktiveret TLS/SSL. Du kan også, afhængigt af dine behov, fremover tilføje:
- Support , forbedret komprimering on-the-fly via HTTPS
- med , for at forhindre automatiserede angreb på dit website
- for WordPress, der passer til dig
- ved hjælp af (på Ubuntu)
- Postfix eller msmtp, så WordPress kan sende e-mails
- Gennemgange af din hjemmeside, så du forstår, hvor meget trafik den kan klare
For endnu bedre ydeevne på dit website anbefaler vi at opgradere til , vores enterprise-grade kommercielle produkt baseret på NGINX med åben kildekode. Dets abonnenter vil modtage en dynamisk indlæst Brotli-modul, samt (mod ekstra betaling) . Vi tilbyder også , et WAF modul til NGINX Plus, baseret på branchens førende sikkerhedsteknologi fra F5.
N.B. For support af en højbelastet hjemmeside kan du kontakte specialisterne . Vi sikrer hurtig og pålidelig drift af din hjemmeside eller tjeneste under enhver belastning.
Kilde: habr.com
