Nextcloud Self-Hosting: Default'lardan Farklı Ayarladığım Şeyler

Nextcloud, Dropbox ya da Google Drive'a self-hosted bir alternatif isteyen client'larla düzenli olarak gündeme geliyor, genelde cost (per-seat cloud storage pricing bir team'le birikiyor) ve data residency sebeplerinin (company file'larını kontrol ettikleri infrastructure'da tutmak) bir karışımı için. Install'ın kendisi straightforward, bir web installer'ı işin çoğunu hallediyor. Çalışan bir Nextcloud instance'ı ile, insanların sessizce öncesinde kullandıkları şeye geri dönmek yerine gerçekten kullanmaya devam ettiği bir instance arasındaki farkı belirleyen, default'ta yanlış olmayan ama gerçek kullanım için tuned olmayan bir avuç setting.

AJAX değil, Cron

Varsayılan olarak, Nextcloud'un background job'ları (file scanning, notification'lar, cleanup task'ları) browser'daki page load'lar tarafından trigger edilen AJAX üzerinden çalışıyor. Bu, teknik olarak işliyor, ama background job'ların sadece birinin web UI'ı açıkken çalışması demek, ve page load'ları, ekstra iş yaptıkları için sluggish hissettirebiliyor. Her beş dakikada çalışan bir system cron job'a (ya da daha iyisi, bir systemd timer'a) geçmek, admin setting'lerinde bir config değişikliği plus bir satır:

# crontab for the web server user
*/5 * * * * php -f /var/www/nextcloud/cron.php

Bu değişiklikten sonra, background job'lar, kimsenin web interface'i kullanıp kullanmadığından bağımsız olarak güvenilir şekilde schedule'a göre çalışıyor, ve page load'lar artık bu ekstra işi taşımıyor.

Memory caching: APCu ve Redis

Nextcloud'un performance'ı, özellikle web UI için ve birçok small file sync eden client'lar için, caching'in configure edilmiş olmasına ağır şekilde bağlı. Onsuz, her request configuration'ı ve file-locking state'ini database'den yeniden okuyor. Önerilen setup ikisini birden kullanıyor: local memory caching için APCu, ve file locking için Redis (bu, request'ler arasında, ve birden fazla app server varsa onlar arasında da shared olması gereken bir şey):

// config/config.php
'memcache.local' => '\OC\Memcache\APCu',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => '127.0.0.1',
    'port' => 6379,
],

Bunun yarattığı fark en çok web UI'da fark ediliyor, folder navigation ve file listing, "noticeably waiting"ten near-instant'a geçiyor, çünkü Nextcloud'un ihtiyaç duyduğu metadata, her request'te database ve filesystem'e round-trip yapmak yerine memory'den geliyor.

Upload limit'leri üç yerde yaşıyor

"X'ten daha büyük dosya upload edemiyorum", en yaygın Nextcloud problemlerinden biri, ve sebebi, upload size limit'inin PHP, web server, ve Nextcloud'un kendi setting'i arasında uyuşması gerekmesi, hangisi daha küçükse o kazanıyor:

; php.ini
upload_max_filesize = 16G
post_max_size = 16G

# nginx
client_max_body_size 16G;

// config/config.php
'upload_max_filesize' => '16G',

Bunlardan herhangi birinin eksik olması, upload'ların her ne olursa olsun en düşük limit'te fail etmesi demek, genelde üç layer'dan hangisinin asıl culprit olduğunu obvious yapmayan bir error mesajıyla. Üçünü de consistently, hatta generously set etmek, biri ilk kez büyük bir video file upload etmeye çalıştığında confusing bir troubleshooting session'dan kurtarıyor.

Trusted domain'ler, kimse duvara çarpmadan önce

Nextcloud, trusted_domains listesinde olmayan bir hostname üzerinden erişilirse load olmayı reddediyor, bir security measure, ama "yanlış" URL'yi (bir internal hostname, bir IP adresi, bir migration'dan sonra yeni bir domain) deneyen ilk kişi için confusing bir error üretiyor:

// config/config.php
'trusted_domains' => [
  'cloud.example.com',
  '10.0.0.5',
],

Instance'a reasonably erişmesi gereken her hostname ya da IP'yi, health check'ler ya da admin access için kullanılan internal'ler dahil, önceden eklemek, bunun herkesin debug etmesi gereken ilk şey olmasını önlüyor.

Sizing beklentileri ve backup'lar

Küçük bir team için (bir avuçtan birkaç düzine user'a), Nextcloud, küçük bir WordPress sitesini çalıştıran aynı türden bir VPS'te rahatça çalışıyor, insanlar aynı anda çok fazla büyük file operation'ı yapmıyorsa user başına yük modest. Büyüyen şey, açıkçası, storage, ve planlamaya değer kısım bu: data directory'si, bir database'in ihtiyaç duyduğu gibi backup'a ihtiyaç duyuyor, ve tüm amacı "file'ların yaşadığı yer" olan bir service için, onu doğru restore etmek (file permission'lar, data directory structure'ı, database, ve config'in hepsi eşleşmeli), bir database backup'ını restore etmenin gerçekten ihtiyaç olduğu güne kadar bir kere test edilmeye değmesi gibi, bir kere test edilmeye değer.

Bu değişikliklerin hiçbiri zor değil, ve hiçbiri installer'ın tam olarak yanlış yaptığı şeyler değil. Bunlar sadece, day one'da teknik olarak çalışan bir Nextcloud instance'ı ile, real usage, real file volume'ları, ve real upload size'larının onlar için tam tuned olmayan her default'u bulma şansı bulduğu bir yıl sonra hâlâ fast ve reliable hissettiren bir instance arasındaki fark.