Giter VIP home page Giter VIP logo

puppet-nextcloud's Introduction

puppet-nextcloud

Build Status Puppet Forge Puppet Forge

Table of Contents

  1. Overview
  2. Requirements
  3. Usage
  4. Reference
  5. Development
  6. License

Overview

A Puppet module to install and manage Nextcloud. It is highly configurable, supports Nextcloud apps, automated updates and is suited for multi-server setups.

Requirements

This module should work with all officially supported versions of Nextcloud.

The focus of this module is Nextcloud, so you should ensure that all additional components are available and ready to use:

A MySQL/MariaDB/PostgreSQL database.

A webservice like Apache or Nginx, puppetlabs/apache is recommended.

A supported version of PHP (PHP-FPM is strongly recommended). The module is capable of providing a default installation of PHP, if the optional soft dependency puppet/php is available.

A optional Redis installation can also be enabled, provided that the optional soft dependency puppet/redis is available.

Usage

Basic usage

A small number of parameters are required to setup Nextcloud:

class { 'nextcloud':
  admin_password => 'suPeRseCreT',
  db_password    => 'secRetPasSwOrd',
  version        => '20.0.4',
}

If the database service is not running on the same server, then the database settings need to be adjusted:

class { 'nextcloud':
  db_driver      => 'mysql',
  db_host        => 'db.example.com',
  db_name        => 'nextcloud_dbname',
  db_password    => 'secRetPasSwOrd',
  db_user        => 'nextcloud_dbuser',
  ...
}

The folder of the Nextcloud installation is derived from three parameters: $installroot, $symlink_name and $datadir. Using different folders is simple:

class { 'nextcloud':
  datadir      => '/opt/nextcloud-data',
  installroot  => '/opt',
  symlink_name => 'nextcloud',
  ...
}

In this example the Nextcloud installation will live in /opt/nextcloud, and this folder should be used as DocumentRoot for the webservice (and/or PHP-FPM). All user-data will be stored in /opt/nextcloud-data. Note that $datadir MUST NOT be a subdirectory of the installation folder.

Also note that you MUST NOT change these folders after the initial installation of Nextcloud is complete. This is unsupported and will break your installation. However, you can still manually migrate Nextcloud to different folders if you know what you are doing.

A full list of available parameters is available in REFERENCE.md.

All default values can be found in the data/ directory.

Configuring Nextcloud

All entries in $config will be added to Nextcloud's configuration:

class { 'nextcloud':
  config => {
    mail_smtpmode        => 'smtp',
    mail_smtphost        => 'mail.example.com',
    mail_smtpport        => 25,
    memcache.local       => '\OC\Memcache\APCu',
    memcache.distributed => '\OC\Memcache\Redis',
    memcache.locking     => '\OC\Memcache\Redis',
    overwrite.cli.url    => 'https://nextcloud.example.com/',
    overwritehost        => 'nextcloud.example.com',
    trusted_domains      => [ 'nextcloud.example.com', 'cloud.example.com' ],
    trusted_proxies      => [ '10.0.0.1', '10.0.0.2' ],
  },
  ...
}

Every option will be added by using Nextcloud's native config commands. The configuration file will NOT be replaced by this module. This menas that it is still possible to modify Nextcloud's configuration without using Puppet.

Hierarchical settings are also supported:

class { 'nextcloud':
  config => {
    app_paths => [
      {
        path => '/opt/nextcloud/apps',
        url => '/apps',
        writable => false
      },
      {
        path => '/opt/nextcloud-user-apps',
        url => '/user-apps',
        writable => false
      }
    ],
    'redis.cluster' => {
      seeds => [
        'redis1.example.com:6379',
        'redis2.example.com:6379',
        'redis3.example.com:6379',
      ],
      timeout => 60,
    },
    ...
  },
  ...
}

In case an option needs to be completely removed from the configuration, add the DELETE: prefix:

class { 'nextcloud':
  config => {
    'DELETE:memcache.distributed' => '\OC\Memcache\Redis',
  },
  ...
}

This example would remove the memcache.distributed option from the configuration.

Note: All settings are added after performing the initial installation of Nextcloud, hence no setting in $config will have an affect on the installation process.

Managing Apps

Nextcloud apps can be installed, removed, enabled and disabled by using the $apps parameter:

class { 'nextcloud':
  apps => {
    calendar => {
      ensure => present,
      status => disabled,
    },
    contacts => {
      ensure => present,
      status => enabled,
    },
    comments => {
      status => disabled,
    },
    photos => '',
    serverinfo => {},
  },
  ...
}

The parameter ensure specifies whether the app should be present (installed) or absent (removed).

The parameter status specifies whether the app should be disabled or enabled.

Both parameters can be ommitted and replaced with an empty string '' or an empty hash {}. In this case the default values will be used (present/enabled).

Configuring Apps

Nextcloud apps can be configured using the $app_config parameter:

class { 'nextcloud':
  apps => {
    document_community => {
      ensure => present,
      status => enabled,
    },
    onlyoffice => {
      ensure => present,
      status => enabled,
    },
  },
  app_config => {
    onlyoffice => {
      DocumentServerUrl => "https://${$facts['fqdn']}/index.php/apps/documentserver_community/",
      verify_peer_off: 'true',
    },
  },
}

The app name should be the key in the hash and any configuration parameters for that app should be key/value pairs within.

Performing Updates

The module will automatically perform updates of Nextcloud when the value of $version is changed. An optional post-update command can be specified, which will be executed as root:

class { 'nextcloud':
  update_enabled  => true,
  post_update_cmd => 'systemctl restart php-fpm',
  ...
}

Note that the post-update command will run on all servers (up to 30 minutes after the update was installed).

Nextcloud's native upgrade command will also be utilized, but depending on the size of the installation, it may be required to increase the value of $command_timeout. The use of the native upgrade command and the post-update command may be disabled by setting $update_enabled to false, which will allow to perform these steps manually at any time. Note that this does NOT prevent the automatic update, it will only skip the native upgrade and post-update commands. To completely disable all updates, the parameter $update_enabled must be set to none.

The old installation folder will be preserved. In theory, it should be possible to revert to the previous version if no incompatible (database) change was involved. The official Nextcloud documentation should provide more details.

However, it must be ensured that the upgrade path is supported by Nextcloud prior to attempting an update. Besides that performing a full backup periodically is strongly advised.

Multiple Servers

When using more than one server for the same Nextcloud instance, the following parameter should be set to improve overall stability:

class { 'nextcloud':
  update_enabled => true,
  update_host    => 'main-host-fqdn.example.com',
  ...
}

This ensures that all critical operations are only performed on the specified host.

High Performance Backend

The module supports Nextcloud's High Performance Backend that was introduced in Nextcloud 21. To let the module install the "notify_push" app and manage this service, set $manage_hpb to true.

Keep in mind that you have to manually configure your webserver or reverse proxy to actually use the High Performance Backend. In case of Apache HTTPD, just add the following lines to the block used for the Nextcloud server:

  ProxyPass /push/ws ws://127.0.0.1:7867/ws
  ProxyPass /push/ http://127.0.0.1:7867/
  ProxyPassReverse /push/ http://127.0.0.1:7867/

High Availability

The module supports highly available setups where multiple servers are used.

In this case the Nextcloud installation and data directory must be stored on a shared storage like NFS. It is crucial that all servers share these folders. Besides that a highly available instance of Redis should be used as memcache to avoid lock/session contention.

All installation and update tasks of this module use lock files to prevent concurrent execution on multiple servers.

Directory structure

When using the module with default options...

class { 'nextcloud':
  datadir      => '/opt/nextcloud-data',
  installroot  => '/opt',
  symlink_name => 'nextcloud',
  version      => '20.0.4',
}

...the directory structure will look like this:

/
|-- opt/
|   |-- nextcloud@                            # symlink to the current install dir (nextcloud-20.0.4)
|   |-- nextcloud-20.0.3                      # install dir for a previous version (will not be purged)
|   |-- nextcloud-20.0.4                      # install dir for the current version
|   |   |-- nextcloud                         # default application folder (extracted from dist archive)
|   |       |-- config
|   |           |-- config.php@               # symlink to the real config.php in Nextcloud's data dir
|   |-- nextcloud-data                        # Nextcloud's data directory
|       |-- .config.php                       # real config.php (hidden file)
|       |-- .puppet_app.lock                  # indicates that Puppet is currently running a app management command
|       |-- .puppet_convert_filecache.done    # indicates that Puppet completed the "convert filecache" command
|       |-- .puppet_dist_initial_install.done # indicates that the initial install of Nextcloud is done
|       |-- .puppet_missing_indices.done      # indicates that Puppet completed the "missing indices" command
|       |-- .puppet_update_20.0.3.done        # indicates that an update to version 20.0.3 was performed
|       |-- .puppet_update_20.0.4.done        # indicates that an update to version 20.0.4 was performed
|-- var/
|   |-- db/
|       |-- nextcloud_data                    # contains the path to Nextcloud's data dir (used by custom fact)
|       |-- nextcloud_home                    # contains the path to Nextcloud's install/home dir (used by custom fact)

In this example, Nextcloud was initially installed with version 20.0.3 and later updated to version 20.0.4.

The suffix .done indicates that this file is used by the module to identify completed jobs.

The suffix .lock indicates that this file is used by the module to identify currently running jobs.

All files that are prefixed with .puppet_ are required for proper operation of this module and must not be removed.

Reference

Classes and parameters are documented in REFERENCE.md.

Development

Contributing

Please use the GitHub issues functionality to report any bugs or requests for new features. Feel free to fork and submit pull requests for potential contributions.

Acknowledgement

This module was heavily inspired by adullact/nextcloud, which was written by Fabien Combernous. Many features would not be available without his hard work.

License

Copyright 2020 Frank Wall

puppet-nextcloud's People

Contributors

fraenki avatar lightning- avatar jan-win1993 avatar nmaludy avatar

Stargazers

 avatar Oleg Ginzburg avatar Danir Toma avatar

Watchers

Peter Gierl avatar James Cloos avatar  avatar Bernhard Frauendienst avatar

puppet-nextcloud's Issues

Add support for notify_push rust backend

Nextcloud 21 comes with a new "Files High Performance Back-end", packaged in the form of a new notify_push app.

Roughly, the setup works as follows:

  1. Install app in nextcloud. This ships backend binaries for 3 platforms (aarch64, armv7 and x86_64).
  2. Setup a daemon service that starts the backend service
  3. Configure apache/nginx/whatever to proxy requests to /push/ to the new service (the /push/ prefix must be stripped), including /push/ws/ for websockets
  4. Run occ notify_push:setup to verify the connection and enable usage of the new backend

At least the first two steps could be done by this module, behind a new $manage_notify_push flag.

The app comes with a setup-wizard that supports setting this up for systemd+apache/nginx based setups, but I don't think this is a feasible approach for integration into the module. Here is the code that generates the systemd service file. This should probably be done with camptocamp/systemd?

Attached is the rc.d/nextcloud_notify_push I've whipped up for FreeBSD (at least the run user would have to be set by the template)

Support app configs

Currently nextcloud::config only supports system configs. Would be great if you could also add config settings into apps using php occ config:app:set.

Support arrays of hierarchical settings

The $config system supports setting Arrays and Structs (php associative arrays), but for some config keys, an Array of Structs is required.

The most prominent example is perhaps apps_paths:

'apps_paths' => [
        [
                'path'=> '/var/www/nextcloud/apps',
                'url' => '/apps',
                'writable' => true,
        ],
],

I expected to be able to use this from hiera yaml as:

nextcloud::config:
  app_paths:
    - path: /opt/nextcloud/apps
      url: /apps
      writable: false
    - path: /opt/nextcloud-user-apps/
      url: /user-apps/
      writable: true

This fails with:

parameter 'value' expects a value of type Boolean, Integer, or String, got Struct
parameter 'verify_value' expects a value of type Boolean, Integer, or String, got Struct

Currently, this can be worked around by putting the array indices into the key names:

nextcloud::config:
  app_paths 0:
      path: /opt/nextcloud/apps
      url: /apps
      writable: false
  app_paths 1:
      path: /opt/nextcloud-user-apps/
      url: /user-apps/
      writable: true

Perhaps the code from nextcloud::config can be extracted into a recursive function to properly support this?

Error handling on storage loss - aka. disable housekeeping on stateloss

Hey there,
I've been trying out what happens to this module on a partial or total storage loss.
In my testing, the data dir /opt/nextcloud-data is located on a different, network attached storage.

When simulating an outage on said external storage server by turning it off, the fstab mount of course get's wanky.

What's interesting in that is what happens when the puppet client tries to make a run during said outage:
Puppet gets stuck on fact checking and (since the datadir with the current puppet-nextcloud status information is missing) assumes that nextcloud is not installed - and then triggers a complete reinstall.

It would be great to implement a stop command which completely skips the complete install/update and housekeeping process if the state files are missing - something like: skip_on_stateless => true, so that the installation doesn't nuke itself, should storage become available again.

Edit: I know install_enabled can be set to false, but this doesn't completely disables the module module in an error state - also it stops you from using the upgrade functionality, when there is no stateloss.

Support for symlink data dirs

Hey there.
I've been managing a bigger nextcloud instance and stumbled upon a problem while migrating data from the native data folder to a symlink of another folder.

In our exact scenario, we want to use another path (for example /mnt/nextcloud) and make a symlink from /opt/nextcloud-data to /mnt/nextcloud.
The problem in this being, that the puppet module doesn't allow me to define another folder or symlink, since that directory is already a defined object:

file { $nextcloud::datadir:
ensure => directory,
owner => $nextcloud::system_user,
group => $nextcloud::system_group,
before => Nextcloud::Install::Distribution['initial install'],
}

It would be great to have a toggle, that allows me to "skip" the automatic creation of the data folder in order to define my own puppet file element with a toggle like manage_datadir => false.

install_enabled var is ignored / treated as always true

Hello,
it looks like nextcloud::install_enabled is ignored.
I have the following setup in hiera:

---
profile_base::puppetagent::version: 'latest'
nextcloud::install_enabled: false
nextcloud::update_enabled: false
nextcloud::installroot: '/var/www/html/'

However the puppetrun still complains about an error in part of puppet code that should be ignored.
Log from puppet run:

# puppet agent -t
Info: Using environment 'sandbox'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Failed to apply catalog: Could not find dependency File[/var/www/html//nextcloud-26.0.2] for Archive[Extract archive: update to 26.0.2] (file: /etc/puppetlabs/code/environments/sandbox/modules/upstream/nextcloud/manifests/install/distribution.pp, line: 64)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.