owncloud config php где найти

Configuration File

Introduction

The ownCloud Client uses a configuration file. It has several sections for particular settings. You will find more sections in the configuration file than described here. Do not change any of those settings except support advises you to do so.

Location of the Configuration File

The location of the configuration file depends on the operating system used. You can locate this configuration file as follows:

Linux

Microsoft Windows

macOS

Section [ownCloud]

Specifies the poll time for the remote repository in milliseconds.

The duration of no activity after which a synchronization run shall be triggered automatically.

The interval after which the next synchronization will perform a full local discovery.

Specifies the default interval of checking for new server notifications in milliseconds.

Section [General]

Specifies the initial chunk size of uploaded files in bytes. The client will dynamically adjust this size within the maximum and minimum bounds (see below).

100000000
(or 100 MB)

Specifies the maximum chunk size of uploaded files in bytes.

Specifies the minimum chunk size of uploaded files in bytes.

Target duration in milliseconds for chunk uploads. The client adjusts the chunk size until each chunk upload takes approximately this long. Set to 0 to disable dynamic chunk sizing.

If a UI prompt should ask for confirmation if it was detected that all files and folders were deleted.

Whether to show the crash reporter when a crash occurs.

The timeout for network connections in seconds.

If non-locally deleted files should be moved to trash instead of deleting them completely. This option only works on linux

Whether to show experimental options that are still undergoing testing in the user interface. Turning this on does not enable experimental behavior on its own. It does enable user interface options that can be used to opt in to experimental features.

Источник

Облака — белогривые лошадки или безопасный ownCloud для «маленьких» в FreeNAS

ownCloud, как утверждает Википедия — это Свободное и открытое веб-приложение для синхронизации данных, расшаривания файлов и удалённого хранения документов в «облаке». И, как мне кажется, довольно интересное решение для организации собственного домашнего облака.

Все настройки будем делать из консоли, ручками, максимально приближено к тому, как это, как мне видится, делают «взрослые» айтишники.

1 Подготовка Jail для ownCloud

1.1 Создаём Jail

Данный шаг описывать не буду. Если у вас получилось установить FreeNAS и он у вас работает, то проблем с данным шагом у вас быть не должно. Создание первого Jail может занять довольно продолжительное время.

1.2 Открываем доступ по SSH к данному Jail

Удобнее всего дальнейшую настройку выполнять не через web-терминал, а через полноценную программу-терминал. Например, putty. Для этого откроем доступ по SSH к нашему Jail и создадим нового пользователя, от которого и будем проводить дальнейшую настройку.

Выбираем в web-интерфейсе FreeNAS созданный нами Jail и нажимаем внизу кнопку Shell.

В веб-консоли Jail вводим:

Запускаем демон для работы ssh:

Создаём пользователя от имени которого будем потом настраивать нашу систему. Пользователь будет иметь привилегии superuser, для чего мы включим его в группу wheel.

Usrname: Новый пользователь от имени которого мы будем производить все манипуляции в терминале. Вводим, например, superstepa.
Full name: Полное имя этого пользователя. Вводим, например, Dyadya Stepa Policeman.
Uid (Leave empty for default): Ну раз просят оставить пустым, то так и сделаем. Смело жмём Enter.
Login group [superstepa]: Мы хотим чтобы наш пользователь обладал всеми правами местного администратора — superuser, а следовательно включаем его в группу wheel.
Login group is wheel. Invite superstepa into other groups? []: Нажимаем Enter.
Login class [default]: Жмём Enter.
Shell (sh csh tcsh git-shell nologin) [sh]: Оставляем по-умолчанию sh. Просто жмём Enter.
Home directory [/home/superstepa]: И опять Enter.
Home directory permissions (Leave empty for default): И снова Enter.
Use password-based athentications? [yes]: Хотим чтобы аутентификация этого пользователя проходила по паролю? Конечно да! Жмём Enter.
Use an empty password? (yes/no) [no]: Мы же за безопасность и не хотим чтобы у нового пользователя с правами superuser был пустой пароль. А значит очередной раз жмём Enter.
Use a random password? (yes/no) [no]: Я просто уверен, что придуманный нами пароль самый надежный. И мы хотим использовать именно его. А следовательно Enter.
Enter password: Ага, а вот и он. Вводим свой пароль.
Enter password again: Вводим его снова.
Lock out the account after creation? [no]: Нет, блокировать этот аккаунт не нужно. Просто Enter.
OK? (yes/no): Проверяем всё ли верно и если да, то пешем yes.
Add another user? (yes/no): Других пользователей нам не надо. No.

2 Установка и подготовка к работе ownCloud

Присоединяемся с помощью программы-терминала к нашему Jail.
Вводим имя созданного нами пользователя и его пароль.
На приглашение командной строки $ пишем su. Теперь приглашение командной строки сменится на что-то типа root@ownCloud:/usr/home/superstepa #, а все наши команды будут выполняться от имени superuser.
Для упрощения, приглашение командной строки я буду обозначать символом #, а мои комментарии, которые вводить не надо, буду начинать с //.

2.1 Устанавливаем необходимые пакеты

Сначала обновляем текущие пакеты:

Затем устанавливаем необходимые для работы ownCloud пакеты (на все возникающие вопросы отвечаем yes):

Для того, чтобы включить работу по https, собираем с нужными нам пакетами, а затем и устанавливаем из портов, web-сервер nginx:

В процессе сборки убеждаемся, что выбраны следующие пакеты:

IPV6
HTTP
HTTP_CACHE
HTTP_DAV
HTTP_FLV
HTTP_GZIP_STATIC
HTTP_PERL
HTTP_REWRITE
HTTP_SSL
HTTP_STATUS
WWW

2.2 Создаём самоподписанные ключи и сертификаты

Создаём корневой ключ server.key (алгоритм шифрования des3, длиной 1024 bit):

Для этого система дважды попросит ввести парольную фразу. Придумываем её и вводим.

Создаём корневой сертификат:

Отвечать на вопросы можно как угодно. Главное:
— на первый запрос Enter pass phrase for server.key ввести правильный пароль от корневого ключа созданного ранее,
— обязательно ответить на все вопросы, иначе клиент ownCloud в дальнейшем может отказаться от синхронизации файлов,
— запомнить введённые данные, чтобы в дальнейшем можно было легко вспомнить, что сертификат именно Ваш,
— запомнить пароль введённый на вопросе A challenge password []:.
Можно изменить срок действия нашего сертификата, например до 10000 дней, добавив в команду выше аргумент -days 10000.

2.3 Включаем автозапуск web-сервера, PHP и базы данных

2.4 Устанавливаем редактор для удобного редактирования конфигов

Всё-таки мы еще «маленькие» и пользоваться предустановленным редактором vi нам еще сложновато, поэтому поставим простенький редактор nano (на все возникающие вопросы отвечаем yes).

Shared object «libiconv.so.2» not found, required «libgmoudle-2.0.so.0

Для того чтобы это исправить выполним всего 2 команды:

2.5 Корректируем конфиг веб-сервера nginx

Как настоящие администраторы, всегда перед корректировкой конфига делаем его копию, чтобы в случае возникновения проблем всегда можно было откатиться назад:

И редактируем файл конфига:

Выход из редактора по нажатию Ctrl+X. Не забываем при выходе сохранять изменения.

2.6 Корректируем конфиг php

2.7 Корректируем php-fpm.conf:

2.8 Корректируем /var/db/mysql/my.cnf:

2.9 Запускаем веб-сервер nginx, PHP, MariaDB и настраиваем базу данных:

Настраиваем базу данных MariaDB:

Настраиваем базу данных ownСloud введя свои значения, где owncloud — название базы, ownclouduserdb — имя пользователя для работы с базой, а passwordownclouddb — пароль этого пользователя:

2.10 Скачиваем и устанавливаем актуальную версию OwnCloud

По ссылке смотрим текущую актуальную версию ownCloud. На момент написания статьи это была версия 8.0.2.

Скачиваем архив, где вместо 8.0.2 указываем текущую актуальную версию:

Удаляем ненужный теперь нам архив:

Назначаем системных владельцев (пользователя и группу) ownCloud:

2.11 Создаём задание в crone:

Если всё было прописано верно, то мы получим следующее системное сообщение:

crontab: installing new crontab

Идём теперь в браузере по адресу https:// /owncloud и производим там последние настройки. Не забываем, что нам надо изменить тип применяемой базы данных, а для этого нажмём Хранилище и база данных и выберем наш тип базы: MySQL/MariaDB.

Имя пользователя: Имя администратора нашего облака. Например, Stepanadministratovich.
Пароль: Пароль администратора.
Каталог с данными: Я предпочитаю /mnt/files/. В этот каталог я потом монтирую существующие у меня Volumes хранилища FreeNAS. Если надо объяснить как, то пишите в комментариях.
Пользователь базы данных: Мы его создавали ранее на шаге 2.9 ownclouduserdb.
Пароль базы данных: Также назначали ранее на шаге 2.9 passwordownclouddb.
Название базы данных: Всё тот-же шаг 2.9 owncloud.

Источник

Установка и настройка OwnCloud на CentOS

Данная инструкция протестирована для установки OwnCloud на CentOS версий 7 и 8.

Подготовка системы

Синхронизируем время.

Устанавливаем утилиту chrony:

yum install chrony

Запускаем ее службу:

Выставляем нужный часовой пояс:

\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в данном примере московское время.

Настройка брандмауэра.

Выполняется следующими командами:

Отключение SELinux.

Для отключения SELinux вводим две команды:

* первая команда отключает SELinux до перезагрузки, вторая — навсегда.
* подробнее об отключении SELinux. Подробнее о настройке SELinux.

Настройка сервера баз данных

В качестве СУБД используем MariaDB.

yum install mariadb-server

Разрешаем автозапуск и стартуем сервис:

Задаем пароль для суперпользователя mysql:

Подключаемся к MariaDB, создаем базу данных и пользователя:

> CREATE DATABASE owncloud DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

> GRANT ALL PRIVILEGES ON owncloud.* TO owncloud@localhost IDENTIFIED BY ‘owncloud’;

* данными командами мы создали базу данных owncloud, затем с таким же названием мы создали пользователя и задали ему пароль owncloud.

Установка и настройка веб-сервера

Установка на CentOS 7 и 8 немного происходит по-разному. Рассмотрим оба варианта в отдельности.

а) На CentOS 7:

В репозитории CentOS 7 находится PHP версии 5.4. Для Owncloud требуется более новая версия php. Для этого установим репозиторий REMI.

Сначала устанавливаем репозиторий EPEL:

yum install epel-release

Устанавливаем PHP, PHP-FPM и необходимые для работы owncloud модули:

б) На CentOS 8:

В репозитории CentOS 8 есть требуемая версия пакета php. Просто вводим команду:

dnf install php php-fpm php-pdo php-zip php-dom php-intl php-gd php-mysqli php-mbstring php-json php-process

PHP-FPM

Сам пакет php-fpm мы установили на предыдущем шаге. Поэтому на данном этапе необходимо его настроить.

Открываем конфигурационный файл:

Находим опции listen и listen.owner. Задаем им значения:

listen = /run/php-fpm/www.sock
.
listen.owner = nginx

Разрешаем автозапуск php-fpm и запускаем его:

NGINX

Owncloud можно развернуть на NGINX или Apache. В данной инструкции будем использовать первый.

* подробнее процесс установки описан в инструкции Установка NGINX на CentOS.

Новые версии owncloud работают по https — для правильной работы протокола создаем виртуальный домен и настраиваем его для работы с облачным сервисом в NGINX:

server <
listen 80;
server_name owncloud.dmosk.ru;
return 301 https://$server_name$request_uri;
>

server <
listen 443 ssl;
server_name owncloud.dmosk.ru;

ssl_certificate /etc/nginx/ssl/cert.pem;
ssl_certificate_key /etc/nginx/ssl/cert.key;

add_header Strict-Transport-Security «max-age=31536000; includeSubDomains» always;
client_max_body_size 10G;
fastcgi_buffers 64 4K;

rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;

index index.php;
error_page 403 = /core/templates/403.php;
error_page 404 = /core/templates/404.php;

location = /robots.txt <
allow all;
log_not_found off;
access_log off;
>

^/(data|config|\.ht|db_structure\.xml|README) <
deny all;
>

* ^.+\.(jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ <
expires modified +30d;
access_log off;
>
>

* где dmosk.ru — домен, на котором будет работать сервис; owncloud.dmosk.ru — имя сервера, на котором будет работать owncloud; /etc/nginx/ssl — каталог, в котором будут храниться сертификаты; /var/www/owncloud — каталог с порталом.

Создаем каталог для хранения сертификатов и переходим в него:

* данная команда создаст сертификат на 4 года для URL owncloud.dmosk.ru или owncloud.
* в данном примере мы, всего лишь, создали самоподписанный сертификат, который не будет приниматься браузером и нужно будет пропускать предупреждение. Данный метод подходит для тестирования, а для продуктивной среды стоит купить сертификат или получить его бесплатно от Let’s Encrypt.

Проверяем конфигурацию nginx, разрешаем его автозапуск и перезапускаем сервис:

Установка Owncloud

Для загрузки и распаковки архива на нужны следующие пакеты:

yum install wget bzip2

Заходим на страницу owncloud и копируем ссылку на скачивание последней версии программы:

Переходим во временную папку и скачиваем исходник для установки:

Распаковываем скачанный архив:

Задаем права доступа:

Открываем браузер и переходим по адресу https://owncloud.dmosk.ru, где owncloud.dmosk.ru — адрес облачного сервиса. Так как мы используем самоподписанный сертификат, браузер выдаст предупреждение безопасности — игнорируем его и переходим на страницу.

* так как мы настроили виртуальный домен, важно обратиться к серверу, именно, по имени. Таким образом, настроенный узел (в моем случае, owncloud.dmosk.ru) должен разрешаться в DNS или внесен в локальный файл hosts.

В качестве базы данных выбираем MySQL/MariaDB и вводим в качестве логина, пароля и базы owncloud.

Завершаем установку. После входим в панель программы под созданным пользователем.

Предупреждения безопасности и установки

После входа в owncloud под администратором, переходим в настройки для пользователя:

В разделе «Администрирование» переходим в Основные:

В разделе «Предупреждения безопасности и установки» мы можем увидеть список проблем:

Рассмотрим процесс решения некоторых из них.

Источник

Поднимаем Owncloud с нуля с динамическим IP и Let’s Encrypt. Тысяча слонов!*

Давно хотел написать целостный туториал по поднятию Owncloud в условиях домашнего сервера или небольшой компании до 500 пользователей. Owncloud — это прекрасный open-source проект, который позволяет на собственной инфраструктуре поднять свой вариант сервера синхронизации. По возможностям очень похож на Dropbox, а в чем-то его и превосходит. Огромный плюс — отсутствие ограничений по объемам хранения, полный контроль над сервером. Минусы тоже очевидны: вам самим придется следить за всем этим безобразием и беспокоиться о надежности сервера, валяющегося на антресолях или в шкафу.

Совсем недавно мне подвернулась задача по развертыванию Owncloud в домашне-боевых условиях. Я честно отработал свои два литра кошерного русского имперского стаута и решил поделиться своим опытом, собрав все воедино. Итак, сегодня мы рассмотрим:

Стартовый комплект

Операционная система под наш сервер — Ubuntu 16.04.1 Server (torrent). Оптимальный вариант — виртуальная машина. Это довольно удачное решение благодаря легкости миграции, возможности динамического выделения ресурсов, снапшотов и прочих плюшек. Размер виртуальной машины — 10-15 ГБ. Этого более чем достаточно под систему.

Внешнее хранилище (каталог data для owncloud), где будут храниться все ваши данные. Размер — в зависимости от ваших потребностей. Я бы рекомендовал рассматривать вариант от 100 ГБ. Разделение хранилища и основной логики сервера дает большую гибкость конфигурации. В данном случае — SSD для системы и HDD от NAS для данных. При подключении внешнего раздела с данными появляется гибкость в плане миграции и возможность нарастить скорость или объем, если вдруг потребуется.

Домен и внешний ip-адрес — в условиях умирающего пула свободных ipv4 адресов провайдеры все реже отдают просто так белый внешний адрес. Если у вас серый адрес, то тут уже мало, что можно сделать. Только пробрасывать VPN-туннель на свою VPS с белым IP и плясать оттуда. Но иногда провайдеры отдают вполне белые адреса, но не статику, а динамику. Причем адрес может меняться просто по велению левой пятки, сессия рваться в полночь, и абонент получает новый IP. В текущем кейсе стоит роутер MikroTik, который умеет бесплатный динамический DNS, начиная с RouterOS v6.14. Находится эта радость в разделе IP/Cloud. После подключения функции роутер получает доменное имя вида 123456b7890f.sn.mynetname.net. Домен этот всегда указывает на ipv4 адрес, выданный провайдером.

Домен отдают 4-го уровня. Обычный StartSSL и другие сертификационные центры не станут с вами работать, если вы не владеете 2 уровнем. Раньше это приводило к использованию самоподписанного сертификата, на который ругался браузер. Теперь появился Let’s Encrypt, который проблему решает.

Есть и альтернативные варианты, которые хорошо описаны в публикации Домашний хостинг сайтов с динамическим IP пользователем spectreob.

Развертываем LEMP

Начинать, пожалуй, стоит с установки наиболее привычных утилит для работы: htop, iotop, iftop, mc. Затем приступаем к самому LEMP — Linux, Nginx (его произносят как Engine X), MySQL/MariaDB и PHP. Linux у нас уже есть. Почему Ubuntu 16.04, а не, скажем, Debian или CentOS? Я не люблю rpm, и с Ubuntu проще в плане репозиториев со свежими версиями софта. Очень не люблю практику «make install» на боевых серверах. Все же более оптимальным является путь использования пакетного менеджера. Этого принципа и будем придерживаться.

UPD Вначале сделайте обычный sudo apt install nginx, чтобы после обновления на свежий репозиторий все конфиги остались на прежних привычных местах.

Добавляем репозиторий с более свежими версиями nginx. Там были закрыты некоторые баги и уязвимости. Копируем GPG ключ разработчиков Nginx и создаем новый источник-репозиторий для apt:

В файл добавляем ссылки на репозиторий для Ubuntu 16.04 Xenial:
deb http://nginx.org/packages/mainline/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ xenial nginx

Устанавливаем nginx, сконфигурируем позже:

Развертываем MariDB (актуальный форк MySQL) и проверяем работоспособность сервиса:

Выполняем hardening-процедуру, отключая тестовые базы и прочие потенциальные дыры в защите:

Будет запущен диалог, в котором надо будет ответить на серию вопросов. В этом же диалоге мы задаем пароль для root. Он потребуется позже, когда будем создавать базу для owncloud.

Устанавливаем PHP7.0, php-fpm и модули, необходимые для работы owncloud, с сопутствующими сервисами:

Также для работы Owncloud требуется отредактировать переменные окружения:

Необходимо раскомментировать следующие строки:

Настраиваем Let’s Encrypt и конфигурируем Nginx

Let’s Encrypt — это некоммерческая инициатива, предоставляющая бесплатный, автоматизированный и открытый центр сертификации. За что им огромное спасибо. Вероятно, сертификационные центры, которые торгуют, по сути, своей репутацией, теперь будут вынуждены получать основную прибыль из сертификатов высокого класса — Organization Validation (OV) или Extended Validation (EV). Такой тип сертификата доступен только для юридических лиц и подтверждает факт существования условного ООО «Рога и Копыта». При этом проверяется владение доменом, сама компания, нотариально заверенные документы и другие нюансы.

Для личного использования нам вполне будет достаточно Domain Validation сертификата от Let’s Encrypt. Этот вариант по сути лишь удостоверяет тот факт, что вы соединились именно с доменом example.com. И заодно защитит нас от Man-in-the-Middle атак, инжекции всякой дряни на целевую страницу (передаю привет MosMetro Wi-Fi и сотовым операторам) и перехвата паролей при использовании общественных сетей. Идеальный вариант для собственного Owncloud. Почему не использовать самоподписанный сертификат?

В Owncloud есть отличная функция «share link», которая позволяет передать человеку ссылку на файл или каталог. Очень удобно, когда внезапно нужно передать что-то весом в 50 ГБ, а более привычные Dropbox и Google Drive бесплатно такое не позволяют. Вы точно не хотите объяснять бухгалтеру Олимпиаде Сигизмундовне, почему ее браузер пылает красным и кричит, что ее взломали пакистанские хакеры все плохо из-за невалидного сертификата. Тем более, что все весьма просто.

Основная идея Let’s Encrypt — выдача автоматически сертификаты с коротким сроком действия — 90 дней. По мнению авторов проекта, это увеличит безопасность благодаря автоматическому выведению из оборота скомпрометированых сертификатов. Для валидации домена сервис предлагает certbot-auto с несколькими сценариями работы:

Для начала выкачаем и установим последнюю версию certbot:

Редактируем конфиг nginx и разрешаем доступ к тому каталогу, в который будет писать webroot вариант certbot’а:

Перезапускаем сервис nginx:

Теперь можно запустить certbot и сгенерировать сертификаты для нашего домена. В нашем конкретном случае это домен аж четвертого уровня от Mikrotik DDNS. Никто другой валидные для браузеров сертификаты вам не подпишет даже для третьего. UPD: я ошибся с путем webroot по дефолту. В Ubuntu 16.04 не /usr/share/nginx/html, а /var/www/html. На всякий случай проверьте то, что написано в /etc/nginx/sites-available/default после директивы root. Например root /var/www/html;

В диалоговом окне нужно будет ввести адрес электронной почты и согласиться с условиями использования:

Certbot складывает актуальные версии сертификатов в каталог /etc/letsencrypt/live/, создавая симлинки. Внутри будут лежать файлы:

Отлично. Теперь, прописав в конфиге Nginx ссылку на /etc/letsencrypt/live/, мы будем иметь всегда актуальную версию. Создаем новый конфиг для нашего домена:

Готовый конфиг с оптимизациями, которые рекомендует мануал owncloud. 80 порт автоматически редиректит на 443
Конфигурационный файл был переписан с учетом замечаний, отдельное спасибо grozaman. Теперь ценой отказа от поддержки Windows XP и некоторых устарвеших систем, мы повысили уровень безопасности. Также увеличен ключ Диффи — Хеллмана до 4096. Это немного увеличит время хендшейка, но не должно быть существенным. Впрочем вы можете использовать 2048 бит. Добавлен ssl_stapling и ряд дополнительных заголовков для увеличения безопасности.

С этим вариантом конфигурации сайт набирает А+ на https://www.ssllabs.com.
Также с данным конфигом получаем A-grade на https://securityheaders.io.

Конечно, если вам нужна совместимость со старыми версиями Java, Windows XP и тому подобным, придется разрешить некоторые потенциально небезопасные протоколы.

Автоматизируем обновление сертификата

При запуске этой команды certbot свяжется с серверами EFF и попытается обновить свою версию, если это возможно, а затем и сертификаты. Причем не только на все доступные домены. Очень удобно. Если срок смены сертификата не подошел, то ничего не произойдет, и скрипт об этом сообщит.

Теперь можно добавить регулярный запуск скрипта crontab:

Внутрь добавляем регулярную задачу по обновлению сертификатов и их перезаливке в nginx:

Активируем наш сайт:

Установка Owncloud

Есть несколько вариантов, но наиболее предпочтительным в большинстве случаев является установка из репозитория. Пусть у пакетного менеджера голова болит по поводу обновлений. Главное, не забывать делать backup перед накатыванием новых пакетов. Иногда бывают неприятные сюрпризы. Для начала необходимо добавить GPG-ключ:

После этого добавляем репозиторий и устанавливаем пакет owncloud-files. Обычный пакет owncloud притянет по зависимости еще и Apache, а он нам не нужен.

В результате, в /var/www/owncloud у вас развернется все необходимое. Так как Nginx считает корневым каталог /var/www, то доступ к сервису будет выглядеть примерно так: example.com/owncloud

Настраиваем MariaDB

Так как инсталляция у нас маленькая, то в тонкости оптимизации мы вдаваться не будем. Поэтому разворачиваем с более или менее дефолтным конфигом. Username и password подставьте те, которые будет использовать owncloud для доступа к своей базе данных.

Подключаем внешнее хранилище

Как я уже говорил раньше, мне кажется хорошей идеей разделять виртуальную машину с самой логикой сервиса и хранилище, куда будут падать синхронизированные данные. Здесь вы уже можете поступить по своему разумению. Можно не делать ничего, и тогда дефолтным хранилищем будет /var/www/owncloud/data. Можно поступить как я и создать каталог /mnt/data, куда через fstab будет монтироваться внешний том. Это может быть SSD/HDD, он может лежать локально, а может находиться на NAS-storage в этой же локальной сети. Не забудьте только протестировать скорость полученного гибрида. Это потенциально узкое место. В моем домашнем варианте это samba-сервер на хост-машине, кто-то может предпочесть NFS.

Дополнительное удобство такой гибридной конструкции — легкость переезда на более быстрые или емкие варианты при необходимости. Достаточно остановить сервисы и залить на новый подключаемый том все файлы из старого /mnt/data, после чего изменить точку монтирования в fstab и перезапустить сервис вновь. Вдруг вы решите перенести данные со старого HDD на SSD RAID?

Кэширование

Важный момент. Без memory caching owncloud может работать ощутимо задумчивее. Причем он непременно напомнит вам об этом на странице администратора. Выбор способа кэширования зависит от архитектуры системы. С рекомендациями от разработчиков вы можете ознакомиться тут. Если коротко, то для личного использования и небольших инсталляций рекомендуется использовать только APCu. Для малых организаций, при установке на один сервер — APCu для локального кэширования и Redis для file locking. Для установки на кластер в большой организации: Redis для всего, кроме локального кэширования.

Разработчики считают APCu наиболее быстрым вариантом для локального кэша. Если хватает оперативной памяти, то лучше использовать APCu для локального кэширования и Redis для file locking. Если памяти недостаточно, то рекомендуется использовать Redis и для того и другого.

В нашем варианте мы будем использовать только APCu. Установим соответствующий модуль для php:

Теперь будет достаточно просто добавить их в конфигурационный файл owncloud — config.php:

Первый запуск нашего детища

Перезагружаем машину на всякий случай, чтобы перезапустить все сервисы. Заходим на example.com/owncloud и внимательно жмем все кнопки без разбора заполняем строки админского аккаунта, паролей, расположения data католога (/mnt/data, как в этом руководстве), логина и пароля от owncloud-пользователя базы данных. Если все прошло нормально, то скоро вы загрузитесь в основное меню сервиса и сможете убедиться, что все нахрен сломано в порядке.

*Тысяча слонов

Но Достабль уже не слушал. Он указал на несколько прислоненных к стене дощечек.

— Что это такое? — спросил он.

— А это моя идея, — сказал Зильберкит. — Мы подумали, было бы проявлением… э-э… делового чутья, — он явно смаковал эти слова, как непривычное, но изысканное лакомство, — рассказывать людям о новых движущихся картинках, которые мы здесь производим.

Достабль подобрал одну из дощечек и, держа ее в вытянутой руке, осмотрел критическим оком. На ней значилось:

На будуюсчей ниделе мы пакажем

«ПЕЛИАС И МЕЛИСАНДРА»

Рамантическая Трогедия в 2 частях

Спасибо за внимание

— Угу, — произнес он без всякого выражения.

— Разве плохо? — глухо выговорил раздавленный Зильберкит. — Ну, это, ведь тут есть все, что необходимо знать зрителям.

— Разреши, — сказал Достабль, беря со стола Зильберкита кусочек мела.

Некоторое время он что-то торопливо царапал на обороте доски, а потом позволил прочитать написанное:

БОГИ И ЛЮДИ СКАЗАЛИ ЭТАМУ НИ БЫВАТЬ НО ОНИ НИЧИГО НИ ХАТЕЛИ СЛУШАТЬ

«ПЕЛИАС И МЕЛИСАНДРА»,

Истерия Запретной Люпви

Страсть Пабеждаит Прасранство и Время!

При Участии 1000 сланов!

Виктор и Зильберкит читали текст с настороженным вниманием. Так изучают обеденное меню на чужом языке. А язык и впрямь был чужим. Но что самое скверное, на вид он был прежним, родным.

— Ну, не знаю… — осторожно высказался Зильберкит. — Собственно говоря… Что уж там такого запретного… Э-э… Все это основано на реальной истории, только имена изменены. Я полагал, что картина будет полезна, так сказать, подрастающему поколению. Герои, извольте видеть, так никогда и не встретились — вот ведь в чем трагедия. Все это, э-э… очень-очень грустно. — Он посмотрел на дощечку. — Хотя, с другой стороны, в этом несомненно что-то есть. Э-э… — Он явно был чем-то обеспокоен. — Но я, по правде сказать, не помню никаких слонов. — Голос его прозвучал крайне виновато. — В день кликов я был на работе целый день, но совершенно не помню тысячи слонов, хотя наверняка заметил бы их.

Достабль сверлил его немигающим взором. Откуда взялись слоны, он и сам не знал, однако каждое новое мыслительное усилие одаривало его очередным, весьма определенным представлением о том, как следует производить картины. Тысяча слонов — для начала это совсем неплохо.

Спасибо всем дочитавшим до конца эту простыню. Мне хотелось описать максимально полно все детали, чтобы не приходилось рыться по разным, часто противоречивым источникам. Я не исключаю, что мог где-то допустить опечатки или неточности, хотя и проверил все дважды. Буду очень благодарен тыканью носом в ошибки.

Как мне правильно указали — надо переходить на Nextcloud, куда сбежали все разработчики. Я упустил этот момент в силу того, что уже довольно давно сижу на этой системе.

Со мной связался пользователь grozaman и указал на некоторые неоптимальные настройки nginx, связанные со стойкостью шифрования и другими нюансами. Хороший дополнительный мануал можно взять здесь:Настройка Nextcloud на базе NGINX

Мне уже несколько раз указали на то, что certbot/letsencrypt лежит в репозиториях и нет смысла тащить его отдельно. Для Ubuntu это:

Источник