Mailcow-dockerized: NextCloud Helper Script

[ghost]

Hello,

i tried to install NextCloud using /helper-scripts/nextcloud.sh

The installation fails and the following error is shown:

./helper-scripts/nextcloud.sh --install
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'NULL' at line 1
(error) ERR wrong number of arguments for 'del' command
37dbeb4f34ad
./helper-scripts/nextcloud.sh: Zeile 36: Syntaxfehler beim unerwarteten Wort elif' ./helper-scripts/nextcloud.sh: Zeile 36:elif [[ ${NC_INSTALL} == "y" ]]; then'

Did i do something wrong?

Feuernatter

[Braintelligence]

It was not meant to be used on production a while ago. Is it officially finished now?

[andryyy]

Nah, needs a little bit more testing, but will be documented very soon.

Edit: Fixed it, sorry.

[Braintelligence]

@andryyy Looking forward to it 👍 . Thank you for your hard work, we love you ❤️ .

[andryyy]

Aww. 😍 :-D

[ghost]

Exactly :-) 👍

[ghost]

@andryyy
Thanks for pushing the fixes.
The installation now works perfectly und finishes without errors.
I noticed that the host variable isn't set correctly.

System config value overwritehost set to string nextcloud.develcow.de

I updated /mailcow-dockerized/data/web/nextcloud/config/config.php with correct hostname and NextCloud works :-)

Great work! 🥇

[andryyy]

Thanks, that's fixed now. 👍

[lavdnone]

Nextcloud has it's own php-fpm and suggested deployment way:
https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/insecure/mariadb-cron-redis/fpm

I admire scripting - great job, but it is too much of it and it is not the recommended official Nextcloud way.
Beside that - no one want some trash from Nextcloud to kill php and/or nginx for sogo etc.

Lets revert to proper docker install.

Nextcloud optional can be as setting in mailcow.conf. Docker constraints can be used to stop those containers from funning by default, picking settings from conf
https://docs.docker.com/engine/reference/commandline/service_create/#specify-service-constraints-constraint

Ideally option of two separate instances of Nextcoud - user one and one for webdav which kills php and docker with heavy network traffic. With some HAproxy in front to handle https and sort out web traffic between those nginx nodes and mailcow

Dockerfile with imap auth;

 FROM nextcloud:12.0.5-fpm

 RUN apt-get update \
  && apt-get install -y libc-client-dev libkrb5-dev \
  && rm -rf /var/lib/apt/lists/* \
  && docker-php-ext-configure imap --with-kerberos --with-imap-ssl \
  && docker-php-ext-install imap

nextcloud/config/config.php

     'memcache.locking' => '\\OC\\Memcache\\Redis',
     'memcache.local' => '\\OC\\Memcache\\Redis',
     'memcache.distributed' => '\\OC\\Memcache\\Redis',
     'redis' => 
     array (
       'host' => 'redis',
       'port' => 6379,
     ),
     'trusted_proxies' => 
     array (
       0 => 'fd4d:6169:6c63:6f77::1',
       1 => '172.22.1.0/24',
     ),
     'user_backends' => 
     array (
       0 => 
       array (
         'arguments' => 
         array (
           0 => '{dovecot:143/imap/tls/novalidate-cert}',
         ),
         'class' => 'OC_User_IMAP',
       ),
     ),
     'app.mail.accounts.default' => 
     array (
       'email' => '%USERID%',
       'imapHost' => 'dovecot',
       'imapPort' => 993,
       'imapUser' => '%USERID%',
       'imapSslMode' => 'ssl',
       'smtpHost' => 'postfix',
       'smtpPort' => 465,
       'smtpUser' => '%USERID%',
       'smtpSslMode' => 'ssl',
     ),

[andryyy]

They never recommend to use their own stack instead of mailcows... there simply is no recommended way for mailcow... a recommended Docker-way does not apply here! We already have all it needs to run properly.

We don't want a new stack of everything to run Nextcloud on top of mailcow.

We could setup a third php-fpm pool for Nextcloud, yes. But the pool we use for Nextcloud is only shared with the mailcow UI and setup "ondemand". Same applies to Nextclouds dav interface. I don't see a problem sharing the mailcow UI pool here. We also use SOGo for dav, so... that's another point.

I disagree with starting a new LAMP stack with Redis to run Nextcloud on top of mailcow. Or even adding HAProxy to the stack to proxy to 2 new LAMP stacks... that's just overkill³. Just add a new pool for DAV if you really want AND need to.

[tkorves]

@lavdnone : Why the hell we should fire up a new Docker container with an additional Webserver, PHP etc process? This would consume resources, which are not needed to be wasted ... Can you tell me one real advantage?

[lavdnone]

@andryyy sorry for vague description - as you said - no need for separate stack for Nextcloud - just fpm and, maybe separate nginx*. Mailcow's redis mysql should be enough - those guys have different level of fail tolerance. I actually have it setup exactly this way and no issues with those, even with it bootstrapping geographically distributed Galera on mysql.
As you mentioned, I am actually thinking of attaching one separate webdav container with imap auth, but don't want to leave Nextcloud desktop sync client connections on the same one with users web Nextcloud - so I am hesitant. And also, can't find good/recommended docker sabredav solution. Would appreciate advice.
Best what I found is to cut skeal/docker-sabre-dav as it uses tiny 77Mb Ubuntu image from phusion

@tkorves that is the point of docker - those containers are super tiny, like fpm with it's max number of children and memory restriction settings is no where out of hand; you can almost say that 10 children on two fpm docker containers are the same as 20 on one. Beauty comes from ability to setup different settings for those like I mentioned*. One nginx (which is also tiny) can handle - but it is better to have separate timeout (and other) settings for SOGo, separate for Nextcloud, and webdav, and SOGo Active Sync (which SOGo recommends to do) ...
You can shoot it all in one amazon tiny instance just fine - separate containers (as a whole idea of Docker) give flexibility and scalability