Nextcloud instalēšana uz Ubuntu 24.04 LTS

Lielākā daļa sabojāto Nextcloud instalāciju nav sabojātas nekādā interesantā veidā. Fona uzdevumi nekad nav strādājuši, failu bloķēšana notiek datubāzē, datu direktorija atrodas tīmekļa saknē, un neviens nekad nav pārbaudījis, vai dublējums vispār atjaunojas. Ubuntu 24.04 LTS daļu attaisnojumu atņem: PHP 8.3 un MariaDB 10.11 ir repozitorijā, tāpēc trešo pušu PPA nav vajadzīgs. Tālāk ir instalācija, kā mēs to darām uz tīras 24.04 mašīnas, ar visām vietām, kur parasti kaut kas aizķeras.

Resursi un priekšnosacījumi

Nextcloud neēd procesoru, kamēr nav ieslēgta priekšskatījumu ģenerēšana un pilna teksta meklēšana. 10 līdz 25 cilvēkiem, kas strādā ar dokumentiem, godīgi pietiek ar 2 vCPU un 4 GB RAM; pievienojiet kodolu, pirms vēršat serveri pret fotoarhīvu, jo katrs sīktēls ir ImageMagick izsaukums. Versijas un atkritne glabā vecās kopijas, tāpēc plānojiet aptuveni divreiz vairāk vietas, nekā lietotāji domā, ka viņiem vajag. Parastā vieta šim ir VPS ar paplašināmu disku, bet aiz dažiem terabaitiem nomāts fiziskais serveris ar lokāliem diskiem izmaksā mazāk par gigabaitu.

Vispirms sakārtojiet DNS un sertifikātu. Nextcloud iestatījumu pārbaudes testē HTTPS un galvenes, tāpēc TLS pirmajā vietā ietaupa laiku, ko citādi pavadīsiet, dzenoties pakaļ brīdinājumiem, kas patiesībā nav par Nextcloud.

PHP 8.3 FPM un paplašinājumi, ko Nextcloud pārbauda

apt update
apt install -y php8.3-fpm php8.3-cli php8.3-mysql php8.3-gd php8.3-curl php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl php8.3-bcmath php8.3-gmp php-apcu php-redis php-imagick libmagickcore-6.q16-7-extra unzip

Ubuntu repozitorijā pastāv abi nosaukumu veidi. Katram paplašinājumam ir pakotne ar versiju nosaukumā, ne tikai php8.3-gd, bet arī php8.3-apcu, php8.3-redis un php8.3-imagick. Nosaukumi bez versijas, php-apcu, php-redis un php-imagick, ir plānas atkarību pakotnes, kas seko repozitorija noklusētajai PHP versijai, un 24.04 tā ir 8.3: php-apcu ir atkarīga no php-common un php8.3-apcu. Abi nosaukumi uzstāda vienu un to pašu kodu. Aizķeras tie, kas pakotņu sarakstu pārkopē no pamācības, kura rakstīta ondrej PPA lietotājiem: tur blakus dzīvo vairākas PHP versijas, un nosaukums bez versijas seko noklusējumam, kuru izvēlējāties nevis jūs. Uz tīras 24.04 mašīnas ar vienu PHP rakstiet versiju nosaukumā, ja gribat, lai komanda paliek pareiza arī pēc otras versijas pievienošanas.

libmagickcore-6.q16-7-extra ir tā, kas noklusina brīdinājumu "Module php-imagick has no SVG support". To neviens neievelk automātiski. Pievērsiet uzmanību ciparam: 22.04 kodeku pakotne saucās libmagickcore-6.q16-6-extra, un starp 22.04 un 24.04 bibliotēkas soname mainījās no 6 uz 7. Vecais nosaukums 24.04 palicis tikai kā virtuāla pakotne, tāpēc apt to joprojām atrisina ar rindiņu "Note, selecting ... instead of ..." un kļūdu nemet, bet tā ir pieklājība, kas beidzas, tiklīdz parādās otrs piegādātājs. Pārbaudiet, kas tiešām ielādējās:

php -m | grep -E 'apcu|redis|imagick|intl|gmp|bcmath|zip'
php-fpm8.3 -t
systemctl restart php8.3-fpm

MariaDB ar pareizo kodējumu

apt install -y mariadb-server
mariadb-secure-installation

Root autentificējas caur unix ligzdu, tāpēc sudo mariadb iedod konsoli bez paroles.

CREATE DATABASE nextcloud CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;
CREATE USER 'nextcloud'@'localhost' IDENTIFIED BY 'gara-nejausa-parole';
GRANT ALL PRIVILEGES ON nextcloud.* TO 'nextcloud'@'localhost';
FLUSH PRIVILEGES;

Servera puses iestatījumi iet atsevišķā failā /etc/mysql/mariadb.conf.d/60-nextcloud.cnf:

[mysqld]
character_set_server = utf8mb4
collation_server = utf8mb4_bin
innodb_file_per_table = 1
innodb_default_row_format = dynamic
transaction_isolation = READ-COMMITTED

utf8mb4_bin ir tas, ko prasa Nextcloud administratora rokasgrāmata, un binārā kārtošana jebkurā gadījumā ir drošāka izvēle: tā salīdzina baitu pa baitam, tāpēc virknes, kas atšķiras tikai ar burtu reģistru, tostarp marķieri un identifikatori, klusi nekļūst vienādas. Pats utf8mb4 ir svarīgs pavisam prozaiska iemesla dēļ: bez tā faila nosaukums ar emocijzīmi netiks saglabāts.

Nepārkopējiet innodb_large_prefix vai innodb_file_format no vecām pamācībām, un ņemiet vērā, ka oficiālajā lapā tie joprojām ir uzskaitīti. MariaDB tos izņēma jau sen, un 10.11 ar nezināmu mainīgo vienkārši nepalaidīsies. Noslēpums izgaist tikai tad, kad izlasāt journalctl -u mariadb -n 50.

Ņemiet laidienu no Nextcloud, nevis no repozitorija

Ubuntu 24.04 nav Nextcloud servera pakotnes, ir tikai darbvirsmas klients. Snap versija pastāv un kā gatavs risinājums der, taču tā nes līdzi savu tīmekļa serveri, PHP un datubāzi, un noregulēt var tikai to, ko snap atļauj. Serverim, kuru plānojat uzturēt gadiem, izpakojiet oficiālo arhīvu: jaunināšana notiek tad, kad jūs to izlemjat, un visi ceļi sakrīt ar oficiālo dokumentāciju.

cd /tmp
curl -O https://download.nextcloud.com/server/releases/latest.zip
curl -O https://download.nextcloud.com/server/releases/latest.zip.sha256
sha256sum --ignore-missing -c latest.zip.sha256 && unzip -q latest.zip -d /var/www/
chown -R www-data:www-data /var/www/nextcloud

--ignore-missing šeit nav lieks. Kontrolsummu failā ir divi nosaukumi, latest.zip un latest.metadata, bet mēs lejupielādējam tikai pirmo, tāpēc parasts sha256sum -c izdrukā latest.metadata: FAILED open or read un beidz darbu ar kodu 1, kas integritātes pārbaudes solī izskatās tieši tāpat kā pamainīts arhīvs. Ar šo karogu redzēsiet vienu rindu: latest.zip: OK. Kur vajag, tas joprojām krīt: ja arhīva nav vai kontrolsumma nesakrīt, coreutils 9.4 uz 24.04 izdrukā no file was verified vai FAILED un atgriež kļūdas kodu. Ja gribat palikt pie parastās formas, lejupielādējiet līdzās arhīvam arī latest.metadata. && ir tur tā paša iemesla dēļ: ielīmējot bloku veselu, neizdevusies pārbaude citādi aizskrietu garām un izpakošana notiktu tik un tā.

Kontrolsumma pierāda tikai to, ka lejupielāde nav apraujusies. Ja vajag izcelsmi, paņemiet latest.zip.asc un Nextcloud parakstīšanas atslēgu, tad gpg --verify.

NGINX vai Apache

Der abi. Padoms, kas ietaupa visvairāk laika, ir viens un tas pats: paņemiet parauga konfigurāciju no Nextcloud administratora rokasgrāmatas tādu, kāda tā ir, un nomainiet trīs rindas.

server_name cloud.example.com;
root /var/www/nextcloud;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;

Servera blokam pievienojiet client_max_body_size 16G; un fastcgi_read_timeout 3600;. Paraugā jau ir .well-known apstrāde priekš CalDAV, CardDAV, WebFinger un NodeInfo, kā arī noteikumi, kas atdod 404 uz /config, /data, /lib un /3rdparty. Pašrocīgi rakstītas konfigurācijas ir iemesls, kāpēc cilvēki redz well known brīdinājumu, un sliktākajos gadījumos arī tas, kāpēc datu direktorija ir nolasāma no ārpuses.

Apache ar PHP FPM:

a2enmod rewrite headers env dir mime setenvif proxy_fcgi
a2enconf php8.3-fpm
systemctl reload apache2

Virtuālajam hostam vajag AllowOverride All, citādi komplektā esošais .htaccess tiek ignorēts, bet tieši tas veic well known pāradresācijas un aizsargā datu direktoriju.

Instalējiet ar occ, nevis ar tīmekļa vedni

install -d -o www-data -g www-data -m 0770 /srv/nextcloud-data
cd /var/www/nextcloud
sudo -u www-data php occ maintenance:install --database=mysql --database-name=nextcloud --database-user=nextcloud --database-host=localhost --admin-user=admin --data-dir=/srv/nextcloud-data

Atstājiet --database-pass un --admin-pass nenorādītus. occ tos pajautās interaktīvi, un tad tie nepaliek ne komandu vēsturē, ne ps izvadā komandas darbības laikā. Datu direktorija ir ārpus tīmekļa saknes apzināti, un tas ir tas viens lēmums, ko vēlāk mainīt ir nepatīkami, tāpēc failu sistēmu izvēlieties uzreiz.

sudo -u www-data php occ config:system:set trusted_domains 1 --value=cloud.example.com
sudo -u www-data php occ config:system:set overwrite.cli.url --value=https://cloud.example.com
sudo -u www-data php occ config:system:set default_phone_region --value=LV
sudo -u www-data php occ status

APCu lokālajai kešatmiņai, Redis failu bloķēšanai

Tie ir divi dažādi darbi. Lokālā kešatmiņa dzīvo viena PHP procesa iekšienē, un tur APCu ir īstā izvēle. Failu bloķēšanai jābūt kopīgai starp visiem FPM darbiniekiem un cron procesu, tāpēc tai vajag Redis. Ja to neuzstāda, Nextcloud bloķē caur datubāzi, un lielākas sinhronizācijas laikā lietotāji sāk redzēt "fails ir bloķēts".

apt install -y redis-server
usermod -aG redis www-data

Atkomentējiet ligzdas rindas failā /etc/redis/redis.conf, Debian pakotnē tās ir izslēgtas:

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

systemctl restart redis-server php8.3-fpm

Pēc tam failā config/config.php:

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => ['host' => '/run/redis/redis-server.sock', 'port' => 0, 'timeout' => 1.5],

APCu komandrindai pēc noklusējuma ir izslēgts, tāpēc occ un cron sūdzas par trūkstošu kešatmiņu. Pievienojiet apc.enable_cli=1 failā /etc/php/8.3/mods-available/apcu.ini. FPM pārstartēšana pēc usermod nav pēc izvēles: jau palaists process jaunu grupu nepaņem.

Atmiņa, augšupielādes ierobežojumi un OPcache

Nerediģējiet failus mapē conf.d, tie ir simboliskās saites uz mods-available un ir kopīgi ar komandrindu. Izveidojiet /etc/php/8.3/fpm/conf.d/99-nextcloud.ini:

memory_limit = 512M
upload_max_filesize = 16G
post_max_size = 16G
max_execution_time = 3600
opcache.enable = 1
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 10000
opcache.save_comments = 1
opcache.revalidate_freq = 60

To pašu failu ielieciet arī /etc/php/8.3/cli/conf.d/, jo cron.php un occ lasa komandrindas ini, un jauninājums ar 128M nomirs pusceļā. Nextcloud tīmekļa saknē tur arī .user.ini, ko FPM ņem vērā, tāpēc, ja ierobežojums stūrgalvīgi nemainās, ieskatieties tur. Tīmekļa saskarne augšupielādē pa gabaliem, un rclone arī: tā WebDAV aizmugure pret Nextcloud lieto 10 MiB gabalus un failu vienā pieprasījumā sūta tikai tad, ja uzstādāt --webdav-nextcloud-chunk-size 0. Vienkāršiem WebDAV klientiem gabalu vispār nav: davfs2, skriptots curl -T un Windows Explorer iebūvētais WebDAV disks visu failu sūta vienā PUT pieprasījumā, tāpēc šiem skaitļiem tik un tā jāsedz jūsu lielākais reālais fails.

Fona uzdevumi pieder systemd taimerim

AJAX cron strādā tikai tik ilgi, kamēr kādam ir atvērta pārlūka cilne, tāpēc atkritnes tīrīšana, versiju dzēšana un paziņojumi notiek nejauši vai nekad. Ieraksts crontab strādā, bet taimeris papildus dod žurnālu un statusu, ko var pajautāt. Izveidojiet /etc/systemd/system/nextcloud-cron.service:

[Unit]
Description=Nextcloud cron.php
After=network.target mariadb.service

[Service]
Type=oneshot
User=www-data
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php

Un /etc/systemd/system/nextcloud-cron.timer:

[Unit]
Description=Run Nextcloud cron.php every 5 minutes

[Timer]
OnBootSec=5min
OnUnitActiveSec=5min
Unit=nextcloud-cron.service

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nextcloud-cron.timer
sudo -u www-data php occ background:cron
systemctl list-timers nextcloud-cron.timer
journalctl -u nextcloud-cron.service -n 50

Rinda ar background:cron ir tā, ko aizmirst visbiežāk. Bez tās Nextcloud turpina lietot AJAX, lai cik precīzi jūsu taimeris strādātu.

Brīdinājumu lapa, izskaidrota

Jaunākajos laidienos occ setupchecks izdrukā to pašu sarakstu konsolē, ko pēc jaunināšanas lasīt ir ērtāk.

Brīdinājums	Ko tas patiesībā nozīmē	Ko darīt
Trūkst indeksu, kolonnu vai primāro atslēgu	Jauninājumi tos pievieno vēlāk, lai liels oc_filecache netiktu bloķēts pašā jaunināšanas laikā	occ db:add-missing-indices, pēc tam db:add-missing-columns un db:add-missing-primary-keys. Tie ir ALTER TABLE, tāpēc izvēlieties klusu stundu
Nav konfigurēta atmiņas kešatmiņa	APCu nav uzstādīts vai nav ieslēgts šai SAPI	Uzstādiet php-apcu, iestatiet memcache.local, ieslēdziet arī komandrindai
Failu bloķēšana notiek datubāzē	Bloķēšana iet caur MariaDB: lēni, plus 423 kļūdas lielās sinhronizācijās	Norādiet memcache.locking uz Redis
Nav iestatīts noklusētais telefona reģions	Numuru bez valsts koda nav iespējams nolasīt	occ config:system:set default_phone_region --value=LV
Nav iestatīta Strict-Transport-Security galvene	HSTS ir tīmekļa servera galvene, PHP to nesūtīs	Pievienojiet nginx vai Apache, bet tikai tad, kad visiem apakšdomēniem ir derīgs sertifikāts: pārlūki šo politiku iegaumē
.well-known adreses neatbild	Tīmekļa servera konfigurācija, parasti pašrocīgi rakstīta	Lietojiet oficiālo paraugu vai AllowOverride All
Nepareiza reversā proxy galveņu konfigurācija	Katra sesija izskatās kā no proxy adreses, tāpēc ierobežojumi pret uzlaušanu nostrādā greizi	Iestatiet trusted_proxies un forwarded_for_headers
Pēdējais fona uzdevums izpildīts pirms vairākām stundām	Taimeris nestrādā vai strādā ar nepareizu lietotāju	systemctl list-timers un servisa žurnāls
Nav iestatīts apkopes logs	Smagie darbi var sākties darba dienas vidū	occ config:system:set maintenance_window_start --type=integer --value=1, stunda pēc UTC

Kur glabājas dati un kā tos pārvietot

Ceļi tabulā oc_filecache glabājas relatīvi pret krātuvi, kurai tie pieder, tāpēc lietotāju mājas krātuvēm home::<lietotājs> pēc pārvietošanas atkārtota skenēšana nav vajadzīga. Toties jāpārkopē pilnīgi viss, ieskaitot slēpto marķierfailu, kas Nextcloud pasaka, ka direktorija ir īsta: .ncdata jaunākajos laidienos un .ocdata vecākajos. Ja tas nepārceļas līdzi, instalācija vienkārši nestartēs.

sudo -u www-data php occ maintenance:mode --on
systemctl stop php8.3-fpm
rsync -aAX /var/www/nextcloud/data/ /srv/nextcloud-data/
chown -R www-data:www-data /srv/nextcloud-data
chmod 0770 /srv/nextcloud-data

Nomainiet datadirectory failā config/config.php. Ar to vien nepietiek. Tabulā oc_storages paliek rinda ar veco absolūto ceļu, un tieši šī krātuve tur appdata_<instanceid>: priekšskatījumus, profila attēlus, noformējumu un darbvirsmu. Ja rindu atstāj, Nextcloud jaunajam ceļam reģistrē otru krātuvi, pārkopētie lietotņu dati vairs nesakrīt ar savām oc_filecache rindām, priekšskatījumi un attēli klusi ģenerējas no jauna, bet vecā krātuve paliek karāties. Pārsauciet to, kamēr apkopes režīms vēl ir ieslēgts:

UPDATE oc_storages SET id='local::/srv/nextcloud-data/' WHERE id='local::/var/www/nextcloud/data/';

Pirms šīs komandas izveidojiet datubāzes dublējumu. Slīpsvītra beigās ir daļa no identifikatora, neizlaidiet to, un, ja tabulu prefikss nav noklusētais oc_, izlabojiet arī to. Pēc tam paskatieties, cik rindu mainījās: nulle nozīmē nevis to, ka solis uz jums neattiecas, bet to, ka identifikators ir jaukts. Ja identifikators pārsniegtu 64 rakstzīmes, Nextcloud parastās virknes vietā glabā md5('local::<vecais-cels>/'), un ar local:: priekšā un slīpsvītru beigās tas attiecas uz katru datu direktoriju, kuras ceļš ir garāks par 56 rakstzīmēm. Aprēķiniet md5 tieši par to pašu veco virkni kopā ar slīpsvītru un meklējiet pēc tā. Pēc tam palaidiet FPM, izslēdziet apkopes režīmu un ļaujiet Nextcloud lietotņu datus sasaistīt no jauna:

sudo -u www-data php occ files:scan-app-data

Ja vecajā direktorijā ar absolūtu ceļu bija pievienotas lokālas ārējās krātuves, arī tām jāizlabo ceļš: administratora iestatījumos vai ar occ files_external:list un occ files_external:config. occ files:scan --all vajag tikai tad, ja faili tika pievienoti ārpus Nextcloud. Mērķa failu sistēmai jāsaglabā POSIX īpašnieks un tiesības, tātad SMB un exFAT montējumi atkrīt. Ja dati nonāk zem /home, pārbaudiet, vai FPM serviss nav no tā norobežots: systemctl show php8.3-fpm -p ProtectHome.

Dublējumi, kurus esat tiešām atjaunojuši

Trīs lietas ceļo kopā: datubāze, config/config.php un datu direktorija. Konfigurācijas failā ir instanceid, passwordsalt un secret, tāpēc dati bez tā ir failu kaudze, nevis strādājoša instalācija.

sudo -u www-data php occ maintenance:mode --on
mariadb-dump --single-transaction --default-character-set=utf8mb4 nextcloud > /backup/nextcloud-$(date +%F).sql
rsync -aAX --delete /srv/nextcloud-data/ /backup/data/
cp /var/www/nextcloud/config/config.php /backup/
sudo -u www-data php occ maintenance:mode --off

mariadb-dump ir pašreizējais nosaukums, mysqldump ir saderības simboliskā saite. --single-transaction ir konsekvents tikai InnoDB tabulām, tāpēc pārliecinieties, ka neviena nav palikusi MyISAM formātā, un pievienojiet custom_apps, ja lietotnes uzstādījāt pašrocīgi.

Pēc tam reizi ceturksnī pārbaudiet atjaunošanu uz atsevišķas mašīnas. Izpakojiet tieši to Nextcloud versiju, no kuras dublējums taisīts, nekad jaunāku, ielādējiet SQL, atlieciet config.php, nomainiet trusted_domains, salabojiet tiesības, palaidiet occ maintenance:data-fingerprint, lai darbvirsmas klienti zinātu sinhronizēties no jauna, un tikai tad ielogojieties un atveriet kādu failu. Turiet vienu kopiju, kas vecāka par nedēļu, un vienu ārpus šīs mašīnas: izspiedējvīruss un klusa izdzēšana izskatās tieši tāpat kā veiksmīga sinhronizācija.

Tālāk sākas garlaicīgā daļa. Sekojiet taimerim, pēc katras jaunināšanas izlasiet brīdinājumu lapu, atkārtojiet atjaunošanas testu. Ja šo daļu labāk nodot citam, mūsu inženieri to dara IT atbalsta ietvaros, uz iekārtām mūsu pašu datu centrā Rīgā.