понедельник, 14 октября 2019 г.

установка OnlyOffice

OnlyOffice

Онлайн-редактор документов. Ставится для использования с Nextcloud на отдельный сервер в Docker.
Для работы с внешними пользователями документ-сервер должен быть опубликован в интернете и иметь действительный сертификат SSL, иначе при обращении к документ-серверу через интерфейс Nextcloud будет ошибка «OnlyOffice cannot be reached, please contact admin» из-за того, что браузер не доверяет самоподписанному сертификату и не откроет фрейм документа.
Хост-сервер, где крутится OnlyOffice, должен иметь открытые порты 80 и 443 в интернет.

Установка

Подготовительные действия:
# создать папки
mkdir onlyoffice
cd onlyoffice
mkdir logs data lib db data/certs
# файл с переменными
echo "JWT_ENABLED=true" >> env.list
# secretword - это пароль доступа к документ-серверу
echo "JWT_SECRET=secretword" >> env.list
Установка Docker (для Debian):
sudo apt-get install apt-transport-https ca-certificates curl gnupg2 software-properties-common
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo apt-key add -
add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/debian \
   $(lsb_release -cs) \
   stable"
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io
Выпуск сертификата:
certbot certonly -d oo.domain.com
 
Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/oo.domain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/oo.domain.com/privkey.pem
 
# Копировать сертификаты в каталог их забора при запуске контейнера
cp /etc/letsencrypt/live/oo.domain.com/fullchain.pem ~/onlyoffice/data/certs/onlyoffice.crt
cp /etc/letsencrypt/live/oo.domain.com/privkey.pem ~/onlyoffice/data/certs/onlyoffice.key
chmod 400 ~/onlyoffice/data/certs/onlyoffice.key
 
# Сгенерировать параметры Диффи-Хеллмана (DHE), обеспечивающие более высокую стойкость
openssl dhparam -out ~/onlyoffice/data/certs/dhparam.pem 2048
Запуск:
sudo docker run -i -t -d -p 443:443 --restart=always \
-v ~/onlyoffice/logs:/var/log/onlyoffice  \
-v ~/onlyoffice/data:/var/www/onlyoffice/Data  \
-v ~/onlyoffice/lib:/var/lib/onlyoffice \
-v ~/onlyoffice/db:/var/lib/postgresql \
--env-file ~/onlyoffice/env.list onlyoffice/documentserver
Далее ставится плагин OnlyOffice в Nextcloud и настраивается через веб-интерфейс. Ключ доступа, прописанный ранее в переменной JWT_SECRET, прописывается в доп. настройках.

Дополнительно

# Список контейнеров
sudo docker ps
# Запустить консоль внутри контейнера:
sudo docker exec -it CONTAINER_ID bash
# Перезапуск всех служб OnlyOffice (внутри контейнера)
supervisorctl restart all
Костыль, чтобы заставить Nextcloud не проверять подлинность сертификата для взаимодействия с OnlyOffice. Прописывается в config.php Nextcloud. В нормальной ситуации не нужен.
'onlyoffice' =>
array (
'verify_peer_off' => TRUE,
),

Отключить проверку сертификата в OnlyOffice

Нужно в случае, когда Nextcloud и OnlyOffice стоят в одной подсети и внутренние запросы (в настройках плагина Онлиофиса в Некстклауде) идут через внутренние имена или IP-адреса, отсутствующие в SSL-сертификате. Если не отключить проверку, то при настройке плагина будет выдаваться ошибка: Error while downloading the document file to be converted
Решение:
When you use self-signed certificates they should be added to ca-certificate bundle of the OS of both servers (the one you use on Nextcloud should be added to the server with ONLYOFFICE Document Server and vice versa). The problem is that the certificate of Nextcloud should be also added to nodejs ca-certificate bundle, so the Document Server can verify it. But it is impossible for nodejs version 6, which is required for the Document Server at the moment.
We are working on the possibility to install Document Server with the later versions of nodejs, where it is possible to add self-signed certificates.
As a temporary solution you can disable verification of the certs by the Document Server. It should help. Please change the value of the parameter `"rejectUnauthorized":` from `true` to `false` in /etc/onlyoffice/documentserver/default.json. After that restart all the services of the Document Server:
supervisorctl restart all
sed -ie 's/"rejectUnauthorized": true/"rejectUnauthorized": false/g' /etc/onlyoffice/documentserver/default.json
supervisorctl restart all
Источник:
https://bva.dyndns.info/wiki/service/onlyoffice

Как редактировать файлы контейнера Docker с хоста


Если действительно нужно просто быстро отредактировать файл для проверки чего-либо, либо используйте docker exec, чтобы получить оболочку в контейнере и отредактировать напрямую, либо используйте docker cp, чтобы скопировать файл, отредактировать на хост и копировать обратно.

$ docker cp CONTAINER:FILEPATH LOCALFILEPATH $ vi LOCALFILEPATH $ docker cp LOCALFILEPATH CONTAINER:FILEPATH

Источник:
http://qaru.site/questions/188483/how-to-edit-docker-container-files-from-the-host

сертификаты Let's Encrypt при помощи Certbot

ubuntu
установим необходимое для работы с PPA программное обеспечение:

apt-get install software-properties-common
Затем добавим нужный PPA:

add-apt-repository ppa:certbot/certbot
Обновим список пакетов:

apt-get update
и установим Certbot:

apt-get install certbot

В доступной для веб-сервера директории создадим отдельную папку, скажем, letsencrypt, которую затем мы будем использовать для всех обслуживаемых доменов и установим ее владельцем веб-сервер:
 mkdir /var/www/letsencrypt
chown www-data:www-data /var/www/letsencrypt
Теперь нам нужно сделать так, чтобы любой запрос вида:
http://example.com/.well-known/acme-challenge
приводил к физическому размещению:
/var/www/letsencrypt/.well-known/acme-challenge
Это несложно, но для каждого из веб-серверов делается по-разному, ниже мы рассмотрим самые популярные из них.

Apache 2.x

Apache является самым распространенным и популярным веб-сервером, актуальной версией является 2.4.x, для его подготовки к работе с Certbot добавьте в основной конфигурационный файл /etc/apache2/apache2.conf следующую секцию:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/


    Options None
    AllowOverride None
    ForceType text/plain
    Require all granted
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
Для устаревшей версии Apache 2.2 данный блок должен выглядеть следующим образом:
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/


    Options None
    AllowOverride None
    ForceType text/plain
    Order allow,deny
    Allow from all
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
Данная секция создает для любого запроса к /.well-known/acme-challenge алиас (псевдоним), указывающий на физическую директорию /var/www/letsencrypt/.well-known/acme-challenge, а ее расположение в основном конфигурационном файле позволит распространить действие директив для любого обслуживаемого домена. Остальные параметры задают необходимые параметры безопасности.

Nginx

Nginx - второй по популярности веб-сервер (и первый среди продвинутых пользователей) предполагает несколько иной подход к настройке. Для каждого виртуального хоста в секцию server следует добавить блок:
location ^~ /.well-known/acme-challenge/ {
   default_type "text/plain";
   root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
   return 404;
}
Если вы настраивали сервер по нашей инструкции, то мы рекомендуем вынести указанный блок в отдельный шаблон, например, /etc/nginx/templates/letsencrypt.conf и впоследствии подключать в конфигурацию виртуального хоста именно его и в общих чертах это должно выглядеть так:
server {
   server_name example.com
   ..
   include /etc/nginx/templates/letsencrypt.conf;
}
Данный подход является хорошей практикой, так как в случае внесения каких-либо изменений их придется делать только в одном месте, вне зависимости от числа обслуживаемых виртуальных хостов.

Получение сертификата

Наконец-то мы подошли к самому главному - получению сертификата, но не стоит спешить, количество запросов на сертификат в единицу времени ограничено (20 запросов на регистрацию в неделю и 5 неудачных запросов в час), поэтому следует убедиться, что все сделано правильно. Для этого следует использовать возможность тестового запуска Certbot, наберем в консоли:
certbot certonly --dry-run --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Ключ --dry-run включает тестовый режим, при котором производится симуляция получения сертификата, --webroot - указывает используемый плагин, после ключа -w указываем путь к директории для letsencrypt, а затем через ключ -d указываем домены для которых мы получаем сертификат. Как минимум это должно быть основное имя сайта и имя c www, хотя никто не мешает включить вам в сертификат все нужные поддомены или вообще разные домены. Лимит на количество доменов в сертификате равен 100.
После того как тестовый запуск увенчался успехом можно переходить к получению сертификата:
certbot certonly --webroot -w /var/www/letsencrypt -d example.com -d www.example.com
Сертификат получен, отлично! Но где нам его искать? Перейдем в /etc/letsencrypt/live где для каждого полученного сертификата будет создана папка с именем первого указанного в запросе домена, т.е. для нашего примера - example.com. Внутри будут находиться четыре файла:
  • cert.pem - собственно сертификат
  • chain.pem - цепочка доверия, включает корневой и промежуточный сертификаты Let's Encrypt
  • fullchain.pem - полная цепочка, включающая кроме содержимого chain.pem сам сертификат
  • privkey.pem - закрытый ключ сертификата, данный файл является секретным.
Именно эти файлы следует использовать в конфигурационных файлах служб при настройке SSL, конкретные реализации выходят за рамки данной статьи и это будет сделано в отдельных материалах, мы же заглянем еще глубже под капот.
При внимательном рассмотрении выяснится, что файлы в директории live являются символьными ссылками на аналогичные файлы в /etc/letsencrypt/archive:

Источник:

напоминалка по netstat

sudo netstat -ltup

Флаг -l указывает netstat вывести все прослушивающие сокеты (сокет это ip + порт), -t показывает все TCP-соединения, -u отображает все соединения UDP, а -p позволяет выводить имя приложения/программы, прослушивающее порт.

Чтобы выводить числовые значения (номер порта), а не имена служб, добавьте флаг -n.

$ sudo netstat -lntup
-------------------------------------------------------------------
s — еще один полезный инструмент для отображения информации о сокетах. Он в своём использовании похож на netstat. Следующая команда выведет все порты прослушивающие соединения TCP и UDP в числовом формате.

$ sudo ss -lntu

Оригинал:
http://blog.sedicomm.com/2019/02/27/4-sposoba-uznat-kakie-porty-proslushivayutsya-v-linux/


1С-Битрикс: Низкие показатели MySQL в мониторе производительности (Решение)


Хочу поделится радостью: удалось оптимизировать работу MySQL.
В БУС монитор производительности на мощном сервере показывал следуюшее:
База данных MySQL (запись)      72      5 600      количество запросов на запись в секунду
База данных MySQL (чтение)      5 869   7 800      количество запросов на чтение в секунду
База данных MySQL (изменение)   4 251   5 800      количество запросов на изменение в секунду
Но нашлась все-таки одна настроечка, которая ну очень сильно меня обрадовала: innodb_flush_log_at_trx_commit=2
После того как я ее прописал, получил следующие циферки:
База данных MySQL (запись)     4 395     5 600     количество запросов на запись в секунду
База данных MySQL (чтение)    6 220    7 800    количество запросов на чтение в секунду
База данных MySQL (изменение)    4 643    5 800    количество запросов на изменение в секунду
Увелечение скорости записи в 60 раз меня ну очень обрадовало.
innodb_flush_log_at_trx_commit — Вам кажется, что InnoDB в сто раз медленнее MyISAM? Вероятно, вы забыли изменить значение этого параметра. Значение по умолчанию 1 означает, что после каждой завершенной транзакции (или после изменения состояния транзакции) лог должен быть сброшен на диск. Это достаточно дорогая операция, особенно если у вас нет Battery backed up cache. Многие приложения, особенно те, в которых раньше использовался MyISAM будут хорошо работать при значении 2, который означает, что не надо сбрасывать буфер на диск, а следует отправить его в кэш операционной системы. Лог по-прежнему будет сбрасываться на диск каждую секунду и максимум, что вы можете потерять — это 1-2 секунды записей. Значение 0 обеспечивает более высокую скорость, но и более низкую надежность. Есть вероятность потерять транзакции даже при падении mysql-сервера. При значении равном 2 единственная возможность потерять данные — это фатальный сбой операционной системы.

Оригинал статьи - в интернете

подсказки по работе с docker

Docker: Удалить Контейнер — Удалить Все Контейнеры

Список Docker-контейнеров
Список запущенных Docker-контейнеров:

$ docker ps
Список всех Docker-контейнеров:

$ docker ps -a
Удалить Docker-контейнер
Удалить Docker-контейнер по CONTAINER ID или NAME:

$ docker rm
Принудительно удалить запущенный Docker-контейнер:

$ docker rm -f
Удалить Все Docker-контейнеры
Удалить все остановленные (неиспользуемые) Docker-контейнеры:

$ docker container prune -f
Принудительно удалить все Docker-контейнеры, включая запущенные контейнеры:

$ docker rm -f $(docker ps -a -q)

Docker: Удалить Образ — Удалить Все Образы — Удалить Неиспользуемые

Список Docker-образов
Список всех локальных Docker-образов:

$ docker images
Удалить Docker-образ
Удалить Docker-образ по IMAGE ID:

$ docker rmi
Принудительно удалить Docker-образ:

$ docker rmi -f
Удалить Неиспользуемые Docker-образы
Удалить все неиспользуемые Docker-образы:

$ docker image prune -a -f
Удалить Все Docker-образы
Принудительно удалить все Docker-образы:

$ docker rmi -f $(docker images -q)

оригинал:

четверг, 13 сентября 2018 г.

Прерывание проверки дискового массива в mdadm

MDADM, поставляемый вместе с дистрибутивом Debian, содержит задание CRON, которое раз в месяц запускает проверку целостности массива. На больших массивах, размер которых превышает несколько терабайт, такая проверка может занять слишком много времени. Прогресс выполнения проверки можно узнать в /proc/mdstat

# cat /proc/mdstat
Personalities : [raid1] 
md1 : active raid1 sdb2[0] sda2[1]
      1911569360 blocks super 1.2 [2/2] [UU]
      [>....................]  check =  0.0% (8832/1911569360) finish=7201.4min speed=4416K/sec
      
md0 : active raid1 sdb1[0] sda1[1]
      41941944 blocks super 1.2 [2/2] [UU]
      
unused devices: 

Прервать такую проверку можно так:

# echo idle > /sys/block/md1/md/sync_action

После чего можно проверить, что массив действительно перестал проверяться:
# cat /proc/mdadm
Personalities : [raid1] 
md1 : active raid1 sdb2[0] sda2[1]
      1911569360 blocks super 1.2 [2/2] [UU]
      
md0 : active raid1 sdb1[0] sda1[1]
      41941944 blocks super 1.2 [2/2] [UU]
      
unused devices:  

Чтобы отменить такую проверку в будущем, нужно установить параметр AUTOCHECK=false в /etc/default/mdadm

Оригинал статьи:
https://blog.tataranovich.com/2012/04/mdadm.html