diff options
Diffstat (limited to 'nixpkgs/nixos/modules/services/web-apps/nextcloud.xml')
| -rw-r--r-- | nixpkgs/nixos/modules/services/web-apps/nextcloud.xml | 291 |
1 files changed, 0 insertions, 291 deletions
diff --git a/nixpkgs/nixos/modules/services/web-apps/nextcloud.xml b/nixpkgs/nixos/modules/services/web-apps/nextcloud.xml deleted file mode 100644 index b46f34420a70..000000000000 --- a/nixpkgs/nixos/modules/services/web-apps/nextcloud.xml +++ /dev/null @@ -1,291 +0,0 @@ -<chapter xmlns="http://docbook.org/ns/docbook" - xmlns:xlink="http://www.w3.org/1999/xlink" - xmlns:xi="http://www.w3.org/2001/XInclude" - version="5.0" - xml:id="module-services-nextcloud"> - <title>Nextcloud</title> - <para> - <link xlink:href="https://nextcloud.com/">Nextcloud</link> is an open-source, - self-hostable cloud platform. The server setup can be automated using - <link linkend="opt-services.nextcloud.enable">services.nextcloud</link>. A - desktop client is packaged at <literal>pkgs.nextcloud-client</literal>. - </para> - <para> - The current default by NixOS is <package>nextcloud24</package> which is also the latest - major version available. - </para> - <section xml:id="module-services-nextcloud-basic-usage"> - <title>Basic usage</title> - - <para> - Nextcloud is a PHP-based application which requires an HTTP server - (<literal><link linkend="opt-services.nextcloud.enable">services.nextcloud</link></literal> - optionally supports - <literal><link linkend="opt-services.nginx.enable">services.nginx</link></literal>) - and a database (it's recommended to use - <literal><link linkend="opt-services.postgresql.enable">services.postgresql</link></literal>). - </para> - - <para> - A very basic configuration may look like this: -<programlisting>{ pkgs, ... }: -{ - services.nextcloud = { - <link linkend="opt-services.nextcloud.enable">enable</link> = true; - <link linkend="opt-services.nextcloud.hostName">hostName</link> = "nextcloud.tld"; - config = { - <link linkend="opt-services.nextcloud.config.dbtype">dbtype</link> = "pgsql"; - <link linkend="opt-services.nextcloud.config.dbuser">dbuser</link> = "nextcloud"; - <link linkend="opt-services.nextcloud.config.dbhost">dbhost</link> = "/run/postgresql"; # nextcloud will add /.s.PGSQL.5432 by itself - <link linkend="opt-services.nextcloud.config.dbname">dbname</link> = "nextcloud"; - <link linkend="opt-services.nextcloud.config.adminpassFile">adminpassFile</link> = "/path/to/admin-pass-file"; - <link linkend="opt-services.nextcloud.config.adminuser">adminuser</link> = "root"; - }; - }; - - services.postgresql = { - <link linkend="opt-services.postgresql.enable">enable</link> = true; - <link linkend="opt-services.postgresql.ensureDatabases">ensureDatabases</link> = [ "nextcloud" ]; - <link linkend="opt-services.postgresql.ensureUsers">ensureUsers</link> = [ - { name = "nextcloud"; - ensurePermissions."DATABASE nextcloud" = "ALL PRIVILEGES"; - } - ]; - }; - - # ensure that postgres is running *before* running the setup - systemd.services."nextcloud-setup" = { - requires = ["postgresql.service"]; - after = ["postgresql.service"]; - }; - - <link linkend="opt-networking.firewall.allowedTCPPorts">networking.firewall.allowedTCPPorts</link> = [ 80 443 ]; -}</programlisting> - </para> - - <para> - The <literal>hostName</literal> option is used internally to configure an HTTP - server using <literal><link xlink:href="https://php-fpm.org/">PHP-FPM</link></literal> - and <literal>nginx</literal>. The <literal>config</literal> attribute set is - used by the imperative installer and all values are written to an additional file - to ensure that changes can be applied by changing the module's options. - </para> - - <para> - In case the application serves multiple domains (those are checked with - <literal><link xlink:href="http://php.net/manual/en/reserved.variables.server.php">$_SERVER['HTTP_HOST']</link></literal>) - it's needed to add them to - <literal><link linkend="opt-services.nextcloud.config.extraTrustedDomains">services.nextcloud.config.extraTrustedDomains</link></literal>. - </para> - - <para> - Auto updates for Nextcloud apps can be enabled using - <literal><link linkend="opt-services.nextcloud.autoUpdateApps.enable">services.nextcloud.autoUpdateApps</link></literal>. -</para> - - </section> - - <section xml:id="module-services-nextcloud-pitfalls-during-upgrade"> - <title>Common problems</title> - <itemizedlist> - <listitem> - <formalpara> - <title>General notes</title> - <para> - Unfortunately Nextcloud appears to be very stateful when it comes to - managing its own configuration. The config file lives in the home directory - of the <literal>nextcloud</literal> user (by default - <literal>/var/lib/nextcloud/config/config.php</literal>) and is also used to - track several states of the application (e.g., whether installed or not). - </para> - </formalpara> - <para> - All configuration parameters are also stored in - <filename>/var/lib/nextcloud/config/override.config.php</filename> which is generated by - the module and linked from the store to ensure that all values from - <filename>config.php</filename> can be modified by the module. - However <filename>config.php</filename> manages the application's state and shouldn't be - touched manually because of that. - </para> - <warning> - <para>Don't delete <filename>config.php</filename>! This file - tracks the application's state and a deletion can cause unwanted - side-effects!</para> - </warning> - - <warning> - <para>Don't rerun <literal>nextcloud-occ - maintenance:install</literal>! This command tries to install the application - and can cause unwanted side-effects!</para> - </warning> - </listitem> - <listitem> - <formalpara> - <title>Multiple version upgrades</title> - <para> - Nextcloud doesn't allow to move more than one major-version forward. E.g., if you're on - <literal>v16</literal>, you cannot upgrade to <literal>v18</literal>, you need to upgrade to - <literal>v17</literal> first. This is ensured automatically as long as the - <link linkend="opt-system.stateVersion">stateVersion</link> is declared properly. In that case - the oldest version available (one major behind the one from the previous NixOS - release) will be selected by default and the module will generate a warning that reminds - the user to upgrade to latest Nextcloud <emphasis>after</emphasis> that deploy. - </para> - </formalpara> - </listitem> - <listitem> - <formalpara> - <title><literal>Error: Command "upgrade" is not defined.</literal></title> - <para> - This error usually occurs if the initial installation - (<command>nextcloud-occ maintenance:install</command>) has failed. After that, the application - is not installed, but the upgrade is attempted to be executed. Further context can - be found in <link xlink:href="https://github.com/NixOS/nixpkgs/issues/111175">NixOS/nixpkgs#111175</link>. - </para> - </formalpara> - <para> - First of all, it makes sense to find out what went wrong by looking at the logs - of the installation via <command>journalctl -u nextcloud-setup</command> and try to fix - the underlying issue. - </para> - <itemizedlist> - <listitem> - <para> - If this occurs on an <emphasis>existing</emphasis> setup, this is most likely because - the maintenance mode is active. It can be deactivated by running - <command>nextcloud-occ maintenance:mode --off</command>. It's advisable though to - check the logs first on why the maintenance mode was activated. - </para> - </listitem> - <listitem> - <warning><para>Only perform the following measures on - <emphasis>freshly installed instances!</emphasis></para></warning> - <para> - A re-run of the installer can be forced by <emphasis>deleting</emphasis> - <filename>/var/lib/nextcloud/config/config.php</filename>. This is the only time - advisable because the fresh install doesn't have any state that can be lost. - In case that doesn't help, an entire re-creation can be forced via - <command>rm -rf ~nextcloud/</command>. - </para> - </listitem> - </itemizedlist> - </listitem> - </itemizedlist> - </section> - - <section xml:id="module-services-nextcloud-httpd"> - <title>Using an alternative webserver as reverse-proxy (e.g. <literal>httpd</literal>)</title> - <para> - By default, <package>nginx</package> is used as reverse-proxy for <package>nextcloud</package>. - However, it's possible to use e.g. <package>httpd</package> by explicitly disabling - <package>nginx</package> using <xref linkend="opt-services.nginx.enable" /> and fixing the - settings <literal>listen.owner</literal> & <literal>listen.group</literal> in the - <link linkend="opt-services.phpfpm.pools">corresponding <literal>phpfpm</literal> pool</link>. - </para> - <para> - An exemplary configuration may look like this: -<programlisting>{ config, lib, pkgs, ... }: { - <link linkend="opt-services.nginx.enable">services.nginx.enable</link> = false; - services.nextcloud = { - <link linkend="opt-services.nextcloud.enable">enable</link> = true; - <link linkend="opt-services.nextcloud.hostName">hostName</link> = "localhost"; - - /* further, required options */ - }; - <link linkend="opt-services.phpfpm.pools._name_.settings">services.phpfpm.pools.nextcloud.settings</link> = { - "listen.owner" = config.services.httpd.user; - "listen.group" = config.services.httpd.group; - }; - services.httpd = { - <link linkend="opt-services.httpd.enable">enable</link> = true; - <link linkend="opt-services.httpd.adminAddr">adminAddr</link> = "webmaster@localhost"; - <link linkend="opt-services.httpd.extraModules">extraModules</link> = [ "proxy_fcgi" ]; - virtualHosts."localhost" = { - <link linkend="opt-services.httpd.virtualHosts._name_.documentRoot">documentRoot</link> = config.services.nextcloud.package; - <link linkend="opt-services.httpd.virtualHosts._name_.extraConfig">extraConfig</link> = '' - <Directory "${config.services.nextcloud.package}"> - <FilesMatch "\.php$"> - <If "-f %{REQUEST_FILENAME}"> - SetHandler "proxy:unix:${config.services.phpfpm.pools.nextcloud.socket}|fcgi://localhost/" - </If> - </FilesMatch> - <IfModule mod_rewrite.c> - RewriteEngine On - RewriteBase / - RewriteRule ^index\.php$ - [L] - RewriteCond %{REQUEST_FILENAME} !-f - RewriteCond %{REQUEST_FILENAME} !-d - RewriteRule . /index.php [L] - </IfModule> - DirectoryIndex index.php - Require all granted - Options +FollowSymLinks - </Directory> - ''; - }; - }; -}</programlisting> - </para> - </section> - - <section xml:id="installing-apps-php-extensions-nextcloud"> - <title>Installing Apps and PHP extensions</title> - - <para> - Nextcloud apps are installed statefully through the web interface. - - Some apps may require extra PHP extensions to be installed. - This can be configured with the <xref linkend="opt-services.nextcloud.phpExtraExtensions" /> setting. - </para> - - <para> - Alternatively, extra apps can also be declared with the <xref linkend="opt-services.nextcloud.extraApps" /> setting. - When using this setting, apps can no longer be managed statefully because this can lead to Nextcloud updating apps - that are managed by Nix. If you want automatic updates it is recommended that you use web interface to install apps. - </para> - </section> - - <section xml:id="module-services-nextcloud-maintainer-info"> - <title>Maintainer information</title> - - <para> - As stated in the previous paragraph, we must provide a clean upgrade-path for Nextcloud - since it cannot move more than one major version forward on a single upgrade. This chapter - adds some notes how Nextcloud updates should be rolled out in the future. - </para> - - <para> - While minor and patch-level updates are no problem and can be done directly in the - package-expression (and should be backported to supported stable branches after that), - major-releases should be added in a new attribute (e.g. Nextcloud <literal>v19.0.0</literal> - should be available in <literal>nixpkgs</literal> as <literal>pkgs.nextcloud19</literal>). - To provide simple upgrade paths it's generally useful to backport those as well to stable - branches. As long as the package-default isn't altered, this won't break existing setups. - After that, the versioning-warning in the <literal>nextcloud</literal>-module should be - updated to make sure that the - <link linkend="opt-services.nextcloud.package">package</link>-option selects the latest version - on fresh setups. - </para> - - <para> - If major-releases will be abandoned by upstream, we should check first if those are needed - in NixOS for a safe upgrade-path before removing those. In that case we shold keep those - packages, but mark them as insecure in an expression like this (in - <literal><nixpkgs/pkgs/servers/nextcloud/default.nix></literal>): -<programlisting>/* ... */ -{ - nextcloud17 = generic { - version = "17.0.x"; - sha256 = "0000000000000000000000000000000000000000000000000000"; - eol = true; - }; -}</programlisting> - </para> - - <para> - Ideally we should make sure that it's possible to jump two NixOS versions forward: - i.e. the warnings and the logic in the module should guard a user to upgrade from a - Nextcloud on e.g. 19.09 to a Nextcloud on 20.09. - </para> - </section> -</chapter> |