Howto Install NextCloud 20 on Ubuntu 20.04.1 The classic way [Wiki]

Nice HowTo, many thanks :+1:.

Some notes:

  • While exporting and importing calendars, tasks and contacts is a good additional backup, to quickly reimport all Nextcloud data and configs on a reinstall, best is to do a database dump and reimport it when required or on the fresh instance/database:
    mysqldump nextcloud > nextcloud.sql
    mysql nextcloud < nextcloud.sql
    
    The Nextcloud versions must match, so this is not suitable for an offline upgrade.
  • If os-prober is not needed as you do not aim dual boot, you can simply purge the whole package and update GRUB to not load the now missing executable:
    apt purge os-prober
    update-grub
    
    All it does is checking for other OSes installed on the same or other drives (hence the spin-ups) and in case adds those to the GRUB boot menu. If there is no other OS, or you do not boot it via GRUB (but on BIOS/EFI level or so), it is completely unused.
  • I’d not add third party repository keys via apt-key, as this is deprecated. You can do it like that, into a dedicated file:
    curl -sSfL 'https://webmin.com/jcameron-key.asc' | gpg --dearmor -o /etc/apt/trusted.gpg.d/webmin.gpg
    
    NEVER use plain unauthenticated HTTP when downloading a repository key to your trusted key storage, generally never use plain HTTP, when HTTPS is available, nowadays :wink:.
  • You can also configure hdparm to spin down all rotational drives, when skipping the individual drive blocks. I also add APM here a way that it is the highest level that still permits spin down:
    # cat /etc/hdparm.conf
    apm = 127
    spindown_time = 60
    
  • apache2 depends on apache2-utils, hence no need to install the latter explicitly.
  • I know you want to mute all warnings on the admin panel. But note that not all are correct necessarily or really an “issue” when there. E.g.:
  • Instead of changing php.ini directly (which would then consequently be required for those in e.g. the /cli/ directory and when FPM is used in the /fpm/ directory), I’d recommend to create an overwrite config which is then automatically loaded into all kinds of PHP invocation:
    sudo nano /etc/php/7.4/mods-available/custom.ini
    
    Give it a name and a high priority by using the following two first lines above the actual settings:
    ; Personal PHP overrides
    ; priority=99
    
    Then enable it:
    phpenmod custom
    
  • opcache.enable_cli=1 is not recommended anymore. It means that on every CLI/cron call, a whole OPcache is build and destroyed for usually only a small task. Doing so implies much more overhead than what is saved due to multiple script calls being served from that cache. It is reasonable that this is not enabled by default: OPcache recommendation wrong (opcache.enable_cli=1) · Issue #1439 · nextcloud/documentation · GitHub
    Generally you do not need to define any OPcache setting, since the other ones simply match the PHP defaults anyway. The only difference is that opcache.revalidate_freq is 2 by default, hence scripts are revalidated every 2 seconds instead of every 1, i.e. you need to wait up to two seconds before changes to config.php are respected, which should be fine, especially since it is beneficial for performance and CPU usage reasons to check less often. I personally disabled this validations completely and instead clear the cache manually or restart webserver/PHP in the rare cases where I change any PHP file.
  • The 00-innodb.cnf shouldn’t be required anymore, furthermore should produce database startup warnings as these settings are either defaults or removed already:
  • mysql_secure_installation shouldn’t be required at all. MariaDB is by default setup with only the root account and unix_socket authentication plugin: This mean that only the UNIX root user can login, but without password. This is much more secure than allowing password authentication from every unprivileged UNIX user. As root user you can then call mysql/mariadb/mysqladmin commands without -u root -p. Not sure why mysql_secure_installation is still floating around in guides around the web, it is basically a relic which causes more bad than good nowadays.
  • To download latest (stable) Nextcloud so that the HowTo does not need to be updated regularly:
    curl -fLO 'https://download.nextcloud.com/server/releases/latest.tar.bz2'
    tar xf latest.tar.bz2
    rm latest.tar.bz2
    
    I chose the bzip2 archive here to save some traffic. latest.zip exists as well.
  • In /etc/apache2/sites-available/nextcloud.conf, remove the two SetEnv HOME/HTTP_HOME directives. This are and never were required: Remove obsolete HOME and HTTP_HOME variables from Apache2 config by MichaIng · Pull Request #1800 · nextcloud/documentation · GitHub
  • But much more important: Remove Satisfy Any as long as you do not plan to setup HTTP authentication webserver wise for some reason. It breaks every direct access block, means every file within /var/www/nextcloud can directly be accessed by the webserver/visitor, which is a huge security risk. This is fixed for config and data directory (when even located within the webroot, which is not the case with your setup), but still, this should basically never be added without exactly knowing the impact and doing other precautions in case, and of course not if there is no webserver-wise HTTP authentication (which wouldn’t make sense) done anyway: Data folder accessible if "Satisfy Any" is set · Issue #6449 · nextcloud/server · GitHub
    Reminds me that we need to add a big fat warning to the Nextcloud documentation, which still contains this in a way that sounds like “doesn’t hurt”.
  • You use Redis as well for local caching, while APCu would server better performance. However, it is fine, there are upsides/downsides with both of them. But as long as the Redis server runs on the local machine anyway, connect to it via UNIX socket for little performance benefit:
      'redis' =>
        array (
          'host' => '/run/redis/redis-server.sock',
          'port' => 0,
        ),
    
    In theory Redis can then be configured to not listen on any network port.

Otherwise looks pretty well. It’s great to have a step-by-step guide around for native/plain Nextcloud installs without any container/virtualisation/appliance around. You can theoretically relax the title to on Ubuntu or Debian, since it works on both exactly the same way.


Ah and as of the confusion of @crazytok:

  • By default 000-default.conf is enabled which contains the port 80 vhost already. So either a2dissite 000-default could be added to avoid the conflict, or the Nextcloud vhost simply added to this file which exists already?
  • I’m not sure how Certbot handles it: By default it tries to adjust 000-default.conf and creates 000-default-le-ssl.conf as 443/HTTPS vhost. So when the first is disabled, things like HTTPS redirection might not work? And if you add the Nextcloud vhost directly as 000-default.conf, probably the directives need to be moved into the new 000-default-le-ssl.conf manually afterwards.
  • Most compatible would be to create a dedicated config, like /etc/apache2/conf-available/nextcloud.conf + a2enconf nextcloud to load those into every vhost regardless how Certbot installs HTTPS. Only the DocumentRoot then needs to be adjusted within the vhosts, or removed from them and added to nextcloud.conf as well.
1 Like

I have the the default vhost diasabled and removed on my server. If you have multiple vhosts certbot is looking for the ServerName directives and per default it uses the the name of the first VirtualHost for the common name of the certificate and adds the names of the other VirtualHosts as an alternate name. But you can also issue certificats for only a specific VirtualHost or seperate certificates for each Virtualhost. With the command certbot --apache it will ask you for which VirtualHosts / ServerNames you want to issue a cerificate. You can choose a specic one or all of them. You can also specify the vhost for which you want to get a certificate directly in the command, with the -d option like this: certbot --apache -d cloud.yourdomain.tld, or you can issue the certificates with with the command certbot certonly and do all SSL configuration manually in your Apache VirtualHost config files.

Ah that is good to know and very reasonable. So then a2dissite 000-default or rm /etc/apache2/sites-enabled/000-default.conf is all that may be reasonable to add to the HowTo (about this point) right after enabling the nextcloud.conf, to assure there are no conflicts. And certbot then handles everything gracefully by itself :slightly_smiling_face:.

@MichaIng : Many thanks for your comments. As I have no spare system I cannot test everything on my server in use. When I come to it I will update the wiki.

1 Like