И так. Первое что следует понимать: ESXi у меня стоит на флешке. При установке туда, установшик делает разметку. По итогу большая часть флешки не используется, а для всего остального места может и не хватать. Поэтому расширить раздел на флешке, довольно муторный процесс, и для этого в любом случае придётся останавливать сервер, что не является возможным. К тому же в стандартных средствах ESXi я не смог найти как это сделать без остановки сервера.

Поэтому было принято решение просто перенести хранение логов в другое место. Я решил использовать внешнюю NFS шару. Как прицепить к яслям NFS шару - это отдельная статья. Но там ничего сложного нет. На прицепленной к ESXi NFS шаре создал папки для каждого ESXi сервера. 

Для смены папки для хранения логов идём в Manage - System - Advanced Settings и ищем там параметр 

Syslog.global.logDir

и меняем его значение на нужное нам. Там же можно настроить ротацию логов

У меня было несколько сайтов/проектов которые крутились где попало. Например сайт крутился на OpenServer, облако в виртуалке, pma вообще небыло, пользовался HeidySQL который поставлялся вместе с OpenServer. И в один прекрасный момент мне это всё надоело, и я решил объединить всё на одном сервере. Почему именно на Centos8? Да просто мне нравится эта система. Да, я вкурсе что 31.12.2021 - прекращается её поддержка, поэтому я выбрал Centos8 Stream. 

В этой статье я не буду касаться установки и настройки системы. Так не буду затрагивать безопасность, т.е. настройку selinux и собственно firewall. Безопасность это дело сугубо индивидуальное, и настраивать его нужно под свои возможности и потребности. Поэтому после запуска системы, сразу отключаем selinux и firewall

setenforce 0
systemctl stop firewalld
systemctl disable firewalld

Установка и настройка Apache

Начнём с установки Apache. 

dnf install httpd

добавляем его в автозагрузку

systemctl enable httpd

и запускаем его

systemctl start httpd

Собственно установка на этом закончена. Уже сейчас если перейти в браузере на ip адрес вашего сервера, то можно увидеть тестовую страницу Apache. Конечно если у вас отключен firewall. Так же работу можно проверить следующей командой

netstat -tulnp | grep httpd

Вывод будет примерно следующий: 

tcp6       0      0 :::80                   :::*                    LISTEN      1205/httpd

Теперь можно приступать к непосредственной настройке Apache. У Centos есть фишка. Если не уделить внимания разметке жесткого диска, он сделает разметку примерно следующего вида: 

т.е. раздел /home - будет самым большим. Я несколько раз подъёбывался на этот счёт. Вы можете разметку сделать самостоятельно, т.к. вам нужно, или оставить как есть. В этой статье мы этого касаться не будем. Поэтому все файлы веб-сервера будут лежать в директории /home. Я использую примерно следующую структуру: 

/home/sites - тут лежат все сайты

/home/sites/site1 - папка с сайтом

/home/sites/site1/www - собственно файлы сайта

/home/sites/site1/log - логи сайта

Создаём все нужные директории одной командой и назначаем владельцем директорий apache

mkdir -p /home/sites/site1.ru/{www,log}
chown -R apache. /home/sites/

Дальше нам нужно посмотреть раскоменчена ли строчка в конце файла /etc/httpd/conf/httpd.conf

IncludeOptional conf.d/*.conf

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

nano /etc/httpd/conf.d/site1.ru.conf

следующего содержания

<VirtualHost *:80>

    ServerName site1.ru
    ServerAlias www.site1.ru
    DocumentRoot /home/sites/site1.ru/www

    ErrorLog /home/sites/site1.ru/log/error.log
    CustomLog /home/sites/site1.ru/log/access.log common

    <Directory /home/sites/site1.ru/www>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

</VirtualHost>

Проверим конфигурацию

apachectl -t

Apache может ругнуться

AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::95:c6f3:e49f:7204. Set the 'ServerName' directive globally to suppress this message

Это просто предупреждение, и его можно игнорировать. А можно отредактировать файл /etc/hostname и указать там имя своего сервера. В любом случае, если всё сделано правильно, Apache должен написать 

Syntax OK

После этого можно перезапуститься Apache

systemctl restart httpd

или

apachectl restart

Если Apache не стартанул, то смотрил логи

tail -f /var/log/httpd/error_log

но в текущей конфигурации проблем быть не должно. Для полноценной проверки того что всё работает как надо, создадим файл index.html в директории нашего нового сайта /home/sites/site1.ru/www. Напомню, что по умолчанию директория для файлов сайта /var/www/html. Но мы ей пользоваться не будем. 

nano /home/sites/site1.ru/www/index.html

Содержание файла

<center><font color=red size=7>Hello World</font></center>

Сделаем владельцем файла apache

chown apache. /home/sites/site1.ru/www/index.html

Теперь если перейти по адресу вашего сервера, вы увидите не тестовую страницу, а эту страничку которую мы только что создали, а именно: белый фон, и по центру большими красными буквами hello world. Это означает что сам веб сервер уже прекрасно работает, и можно двигаться дальше. 

Установка php с последующим обновлением

Одна из причин почему Centos8 а не Centos7, хотя у последнего поддержка до 2024 года, это то что установка php упростилась, т.к. в репозиториях уже есть версия 7.2 и обновить её, не составит большого труда. Можно конечно сразу поставить 7.4, но я хочу всё таки рассказать про процесс обновления. Поэтому вначала устанавливаем php 7.2 и наверно всё что может понадобится для полноценной CMS или того же Nextcloud

dnf install php php-cli php-mysqlnd php-json php-gd php-ldap php-odbc php-pdo php-opcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap php-zip

после чего перезапускаем apache

systemctl restart httpd

и для проверки работоспособности создадим info файл. Он нам ещё может пригодиться. 

nano /home/sites/site1.ru/www/info.php

со следующим содержимым

<?php phpinfo(); ?>

И выдадим права на файл

chown apache. /home/sites/site1.ru/www/info.php

Теперь заходим через браузер на наш сайт с указанием к какому файлу обратиться, а именно info.php и мы увидем тестовую страницу php с номером версии и со всеми параметрами и настройками. 

Посмотрели? А теперь обновим версию php до 7.4. Для этого подключим репозиторий

dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm

отключим 7.2

dnf module reset php:7.2

подключим 7.4

dnf module enable php:remi-7.4

и запускаем обновление

dnf update

перезапустим на всякий случай apache

systemctl restart apache

и проверим ранее созданый файл info.php. Теперь он должен выглядеть примерно так: 

Так же для работы некоторых CMS рекомендую изменить некоторые значения файла /etc/php.ini

max_execution_time 60
max_file_uploads 200
post_max_size 100
upload_max_filesize 100

думаю что за что отвечает и так понятно. Можно конечно оставить как есть, но тогда вы столкнётесь с проблемой загрузки файлов через сайт, т.к. ограничение 2мб.

Установка mariadb

Теперь установим БД. Я, как и многие наверно, предпочитаю форк mysql - mariadb. Вот его ставить и будем

dnf install mariadb mariadb-server

сразу после установки запускаем и добавляем в автозагрузку

systemctl start mariadb
systemctl enable mariadb

и запускаем скрипт начальной конфигурации

/usr/bin/mysql_secure_installation

скрипт простой и интуитивно понятный, поэтому на нём останавливаться не буду. После того как с ним закончили, перезапускаем mariadb

systemctl restart mariadb

Установка ssl сертификата Lets Encrypt

Процедура так же проста, и не требует особых навыков. Для начала установим пакет certbot

dnf install epel-release
dnf install certbot

Сразу запустить certbot не получится, будет ругаться. Поэтому создадим самоподписанный сертификат

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/pki/tls/private/localhost.key -out /etc/ssl/certs/localhost.crt

и перезапустим apache

apachectl restart

и запустим certbot

certbot certonly

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

После запуска выбирайте способ аутентификации

Apache Web Server plugin (apache)

если он не доступен то тогда 

Place files in webroot directory (webroot)

Во втором случае, нужно на всякий выдать права 777 на директорую с сайтом. После того как сертификат будет получен, можно вернуть всё обратно. 

Теперь отредактируем конфиг нашего сайта, чтобы он работал по https. Приведём его к такому виду

<VirtualHost *:80>

    ServerName site1.ru
    ServerAlias www.site1.ru
    Redirect permanent / https://site1.ru

</VirtualHost>

<VirtualHost *:443>

    ServerName site1.ru
    ServerAlias www.site1.ru
    DocumentRoot /home/sites/site1.ru/www

    ErrorLog /home/sites/site1.ru/log/error.log
    CustomLog /home/sites/site1.ru/log/access.log common

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/site1.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/site1.ru/privkey.pem

    <Directory /home/sites/site1.ru/www>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
  
</VirtualHost>

Проверяем конфиг на то что в нём нет ошибок

apachectl -t

и перезапускаем apache

systemctl restart httpd

Готово. Сертификат выдан на 3 месяца, и чтобы не забыть его обновить - процесс перевыпуска можно добавить в cron

30 4 * * * root /usr/bin/certbot renew --post-hook "/usr/sbin/apachectl restart" >> /var/log/le-renew.log

каждый день в 4-30 будет запускаться попытка перевыпустить сертификат, и до тех пор пока он будет считаться новым (если не ошибаюсь 2 месяца) то ничего не будет происходить и в логах вы будет видеть примерно следующее с ообщение

[root@web ~]# tail -f /var/log/le-renew.log
Certificate not yet due for renewal

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificates are not due for renewal yet:
  /etc/letsencrypt/live/site1/fullchain.pem expires on 2022-01-11 (skipped)
  /etc/letsencrypt/live/site2/fullchain.pem expires on 2022-01-11 (skipped)
  /etc/letsencrypt/live/site3/fullchain.pem expires on 2022-01-11 (skipped)
No renewals were attempted.
No hooks were run.

Вот на этом всё. Это полноценный сервер который позволит держать несколько сайтов, нужно только создать для них директории в /home/sites и конфиги в /etc/httpd/conf.d/. У меня на это веб-сервере крутиться собственно данный сайт, а так же облако, и pma. Для облака нужно было ещё пару модулей доставить и настроить cron, но это уже совсем отдельная статья. 

После очередного обновления Nextcloud столкнулся с проблемой

Заголовок HTTP «Strict-Transport-Security» должен быть настроен как минимум на «15552000» секунд

Заголовок HTTP «Strict-Transport-Security» должен быть настроен как минимум на «15552000» секунд

Точнее даже не проблема, а рекомендация от разработчиков. Т.к. я люблю зелёную галочку, то нужно это исправить. Для этого в вайле .htaccess в корневой папке вашего облака, в отсеке с портом :443 нужно прописать следующее: 

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"
</IfModule>

Но я это сделал в конфиге апача для виртуального хоста с облаком. Тоже пойдёт. В общем выбирайте любой способ и радуйтесь зелёной галочке как я

У меня в виртуалке крутится старенький сервер с мускулем на FreeBSD. Он в работе постоянно, и там постоянно заканчивается место. Я переодически его увеличию, благо это не так сложно. Вот решил поделиться способом. Ясли у меня 6.5 а FreeBSD 11.1. Но не думаю что на других версиях будет как то отличаться.

И так первое что мы делаем это бекапим сервер. Обычно делаю снапшот средствами ESXi, но можно и просто склонировать сервак. Можно стопнуть его, и скопировать. В общем сами решайте

После того как сделали бекап - добавим не много места жесткому диску серверу, увеличив дисковое пространство в яслях.

Перезагрузим сервер 

reboot

После ребута проверим что у нас там с дисковым пространством

gpart show da1

Вывод будет примерно следующий: 

34  16777149  da1  GPT  (16G) [CORRUPT]
34  16777149    1  freebsd-ufs  (8G)

Коррупт! Аяяяй, Но ничего страшного. Запускаем рековер

gpart recover da1

смотрим починилось ли

gpart show da1

вывод будет примерно следующий

34  33554365  da1  GPT  (16G)
34  16777149    1  freebsd-ufs  (8G)
16777183  16777216       — free —  (8.0G)

Всё пачинилось! Теперь расширяем

gpart resize -i 1 da1

ну и расширяем саму ФС

growfs /dev/da1p1

Вот и всё. 

Обновился nextcloud до версии 23. Апдейт вышел уже какое то время назад, но у меня только щас руки дошли до него. И как обычно это бывает после обновления не всё гладко. 

Nextcloud ошибка: «В базе данных отсутствуют некоторые индексы. Так как создание таких индексов может занять достаточно продолжительное время, оно должно быть запущено вручную.

Решается всё просто. Нужно выполнить команду из под пользователя веб сервера. В моём случае это apache

В консоли переходим в папку с файлами Nextcloud и прописываем следующее: 

sudo -u apache php occ db:add-missing-indices

Вот и всё

Статья подойдёт и для Centos 8. 

Cron — классический демон, использующийся для периодического выполнения заданий в определённое время. Регулярные действия описываются инструкциями, помещенными в файлы crontab и в специальные каталоги.

Системный демон crond предназначен для выполнения регулярно повторяющихся заданий. Обычно crond запускается как системный сервис в процессе начальной загрузки системы и остается активным пока система не выключена. Сразу после старта он просматривает каталоги /var/spool/cron и /etc/cron.d, а также файл /etc/crontab в поисках заданий, которые нужно выполнять. Затем crond просыпается каждую минуту, выполняет предписанные ему задания и снова засыпает до начала следующей минуты.

Посмотреть версию своего cron можно с помощью команды:

sudo rpm -q cronie

Если он не установлен, вы можете использовать yum, чтобы установить его.

sudo yum -y install cronie

Задания cron выбраны службой crond.

Для того, чтобы проверить, работает ли служба crond на вашем CentOS 7, вы можете использовать следующую команду:

sudo systemctl status crond.service -l

Для реализации данного способа требуется внести задачу скрипта skript.sh в каталоге /sh/skriptiki/ на исполнение в программу cron на сервере CentOS 7.

Проверим, работает ли у нас вообще cron в фоновом режиме?

ps -ef | grep cron

Открываем файл заданий cron:

nano /etc/crontab

Добавляем строки по смыслу общего синтаксиса в файле.

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

sudo systemctl restart crond.service

Шаблоны задания.

Файлы crontab, создаваемые для отдельных пользователей, находятся в каталоге /usr/spool/cron/crontabs/ или /var/spool/cron/tabs/. Редактировать их вручную не рекомендуется, для этого используют команду crontab -e. Файлы crontab, используемые для управления всей системой, располагаются в каталоге /etc/cron.d/. Кроме того, в каталогах /etc/cron.daily/, /etc/cron.weekly/ и /etc/cron.monthly/ размещаются автоматически запускаемые программы (ежедневно, еженедельно или ежемесячно).

Каждый пользователь системы имеет свой файл заданный crontab, в котором описано, в какое время и какие программы запускать от имени этого пользователя. Для редактирования файла crontab используется специальная одноимённая программа crontab, позволяющая не прерывать процесс cron на время редактирования.

Чтобы задать cron‘у задачу лучше всего воспользоваться командой crontab, если выполнить ее с опцией -l.

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

crontab -l

Будет выведен текущий список заданий. Если вы еще никаких заданий cron‘у не давали, вы увидите в ответ сообщение «no crontab for user«.

Сформулировать cron‘у задачу довольно просто, но, прежде чем пытаться задать ему работу, установите в качестве значения переменной окружения EDITOR указание на любимый (или привычный) текстовый редактор. В противном случае будет вызван редактор vi, с которым я, например, не привык работать.

Поэтому я обычно выполняю команду:

export EDITOR=mcedit

Необязательно использовать mcedit. Можно то что удобнее, например тот же nano

После чего получаю возможность использовать для редактирования списка заданий привычный CoolEdit из пакета Midnight Commander.

После задания значения переменной EDITOR можно выполнить команду для редактирования заданий пользователя:

crontab -e

Будет вызван указанный вами редактор, причем при первом запуске такой команды откроется пустое окно, в котором вы должны сформулировать задание cron‘у. Возникает вопрос: а что мешает нам просто запустить любимый редактор, открыть для редактирования нужный файл и внести в него необходимые команды? Этому существует две причины.

Во-первых, файлы, которые хранят задания для cron‘а (crontab-файлы), принадлежат root-у и защищены от модификации простыми пользователями. Команда же crontab запускается от имени root‘а (для нее установлен так называемый setuid-бит) и имеет доступ к этим файлам. Конечно, если речь идет о вашем персональном компьютере, где вы имеете все права, вам законы не писаны, но лучше все же придерживаться принятых правил игры.

Вторая причина состоит в том, что записи в crontab-файлах должны подчиняться определенным стандартам, быть формализованы, чтобы crond мог их правильно интерпретировать. Команда crontab после того, как вы сохранили вновь отредактированный файл, производит его синтаксический анализ, и, если вы сделали какую-то ошибку, предлагает вам вернуться к его редактированию. Конечно, crontab не может сформулировать за вас задание cron‘у, так что правила написания заданий вам необходимо знать.

Давайте их рассмотрим.

Каждая строка crontab-файла (кроме строк комментариев, которые обозначаются знаком # в первой позиции) либо устанавливает значение некоторой переменной, либо представляет отдельное задание (ниже приведен пример crontab-файла, можете просмотреть его, чтоб составить первое впечатление).

Строка задания состоит из шести полей, разделяемых пробелами (по крайней мере одним). Первые пять полей отведены для указания времени выполнения задания. В следующей табличке представлены значения, которые можно придавать этим полям.

Шаблон задания для cron выглядит примерно так:

• Минуты (0-59);
• Часы (0-24);
• День месяца (1-31);
• Месяц (1-12) — или три первых буквы английского названия месяца (регистр не имеет значения);
• День недели (0-7) — или три первых буквы английского названия дня недели (регистр не имеет значения, а числа 0 и 7 оба обозначают воскресенье);

Команда.

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

• список возможных значений, разделенных запятыми (в списках можно использовать только числа, имена не допускаются);
• интервал значений (например, 1-3);
• или звездочку (*), обозначающую любое из допустимых значений для данного поля.

Существует также возможность указать, что данное задание должно выполняться только в каждый n-ый час (минуту, день или месяц), для чего в нужном поле записывают примерно такую комбинацию: «*/n» (кавычки, конечно, нужно опустить, а вместо n поставить конкретное число). Эти варианты записи времени выполнения заданий можно комбинировать, но об этом лучше прочитайте на man-странице crontab.

Обратите внимание на то, что для указания дня отведено 2 поля: третье и пятое. Если в обоих полях заданы значения, отличные от *, то задание будет выполняться в те дни, когда хотя бы одно из значений дня совпадает с текущим. Например, если в третьем поле стоит 1,15, а в пятом поле — 5 (или FRI), то задание будет выполняться по первым и пятнадцатым числам каждого месяца, а также каждую пятницу (конечно, если в поле месяцев будет стоять *).

Следующее поле (шестое) содержит подлежащую выполнению командную строку оболочки shell. Считается, что поле команда продолжается до конца строки и может содержать пробелы и символы табуляции. Причем заключать эту командную строку в кавычки не требуется. Как и в обычной командной строке shell, можно указать в этом поле несколько команд, разделенных точкой с запятой (хотя, наверное, лучше написать командный файл и указать в crontab-файле его имя).

Задание переменных окружения для cron рассмотрим на примере переменной MAILTO. Надо сказать, что по умолчанию после выполнения каждой строки crontab-файла cron отсылает рапорт о выполнении задания. Содержанием такого рапорта является вывод исполнявшихся команд. Если не задавать переменную MAILTO, то сообщение отправляется тому пользователю, который задал ему данную задачу. Если вы хотите, чтобы сообщения отправлялись не вам, а, скажем, пользователю с именем fred, то в crontab-файле надо записать строку вида:

MAILTO="fred"

Боюсь только, что fred не обрадуется, если его почтовый ящик будет заполняться сообщениями от cron. Если они не нужны и вам, то установите переменную MAILTO в нуль:

MAILTO=""

После чего cron не будет загружать вас лишними письмами. Несколько переменных окружения cron устанавливает автоматически при его запуске.

После завершения редактирования вы, как обычно, сохраняете результаты и выходите из редакторской программы.

Если вы сделали ошибки, то увидите такое сообщение:

crontab -e

Ответ:

crontab: installing new crontab
"/tmp/crontab.10348":0: bad day-of-week
errors in crontab file, can't install.
Do you want to retry the same edit? y

Естественно, придется ответить y.

Если же ошибок не было (или вы их исправили), вы увидите только одну строку:

crontab -e

Ответ:

crontab: installing new crontab

В отличие от других процессов-демонов, которые требуют перезапуска после редактирования их конфигурационных файлов, перезапускать процесс crond после того, как пользователь задал новое задание, не требуется. Дело в том, что просыпаясь ежеминутно, cron проверяет время модификации crontab-файлов и перечитывает те файлы заданий, которые изменялись в последнее время. Поэтому не более чем через минуту ваши задания будут «приняты к исполнению«.

Пользоваться услугами crond могут все пользователи, зарегистрированные в системе. Правда, суперпользователь может закрыть эту возможность для некоторых пользователей, прописав их имена в специальный файл /etc/cron.deny, либо же разрешив использовать cron только ограниченному числу пользователей, имена которых перечислены в файле /etc/cron.allow.

Подробнее об этом вы можете прочитать на man-странице crontab, а пока будем считать, что вам такое право предоставлено.

Чтобы изменить crontab-файл другого пользователя (например, bitrix):

crontab -u bitrix -e

Команда для очистки всех заданий текущего пользователя:

crontab -r

Команда для просмотра краткой справки по установленным таймерам:

systemctl list-timers

Команда чтобы увидеть загруженные, но неактивные таймеры:

systemctl list-timers --all

Где хранятся crontab-файлы?

Дело в том, что одного такого файла нет. В GNU/Linux имеется целый каталог /var/spool/cron, в котором хранятся crontab-файлы для всех пользователей, включая root-а. Каждый такой файл имеет имя, совпадающее с регистрационным именем пользователя, по которому процесс cron определяет, какой UID надо использовать при выполнении команд из этого файла. Владельцем всех этих файлов является пользователь root.

Кроме личных crontab-файлов отдельных пользователей существует также общесистемные crontab-файлы. Один из них, /etc/crontab, находится в каталоге /etc, а остальные — в каталоге /etc/cron.d. Эти файлы не доступны через команду crontab, редактировать их может только суперпользователь. Структура записей в таких файлах тоже несколько отличается от описанной выше: в строках заданий используется дополнительное поле, расположенное перед полем команды. В этом дополнительном поле суперпользователь задает имя пользователя, чей идентификатор (UID) будет использоваться при запуске данного задания.

При инсталляции дистрибутива CentOS 7 создается основной файл конфигурации cron, /etc/crontab, и выглядит примерно так — формат cronjob-выражения:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

, где

минута час день месяц день_недели /путь/к/исполняемому/файлу

и звёздочками обозначены конкретные блоки времени.

Внимание! Каждая запись в файле crontab должна оканчиваться символом перевода строки, в том числе и последняя. В противном случае cron игнорирует её и записывает предупреждение в системный журнал, а ваш скрипт даже не срабатывает!

1 * * * * root /usr/bin/bash /root/mpstat.sh > /dev/null 2>&1
[перевод строки]
[перевод строки]

Команда run-parts в нем служит для запуска всех скриптов из каталога, указанного в виде параметра этой команды.

По большей части эти скрипты выполняют функции по обслуживанию системы: удаляют ненужные временные файлы, присматривают за быстро растущими файлами протоколов в каталоге /var/log и, при необходимости, очищают их, и тому подобное.

Обратите внимание на то, что все эти работы, кроме ежечасных, выполняются в 4 часа ночи. Разработчики дистрибутива, по-видимому, имели в виду в первую очередь круглосуточно работающие сервера и установили время выполнения заданий на тот период, когда активность системы минимальна. Ведь большинство этих скриптов интенсивно работают с диском, что может существенно затормозить работу пользователей. Однако такое решение скорее всего непригодно для персонального компьютера, который пока что принято выключать на ночь. Однако, оказывается, что разработчики дистрибутива предусмотрели возможность выключения компьютера на ночь и поручили выполнение некоторых необходимых работ еще и демону anacron.

Невыполненные задания и утилита anacron.

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

Эту проблему позволяет решить другой системный демон, имя которого anacron.

В отличие от cron, он работает по следующему принципу:

• При запуске, а запускается он во время старта системы из инициализационных скриптов, он просматривает свой конфигурационный файл, обычно /etc/anacrontab, в котором для каждого задания указывается периодичность, в сутках, с которой должно повторяться выполнение этого задания.
• Далее anacron проверяет, выполнялось ли данное задание в течение последних n дней. Если нет, anacron запускает на выполнение команду, указанную в строке задания. При этом выполнение команды может осуществляться с некоторой задержкой, величина которой, в минутах, должна быть указана в строке задания.
• После выполнения задания anacron записывает дату выполнения в специальный файл, содержащий записи о времени последнего выполнения данного задания, чтобы знать, когда надо выполнять это задание снова. Эти файлы сохраняются в каталоге /var/spool/anacron. В файл записывается только дата, часы и минуты не запоминаются.
• После выполнения каждого задания anacron посылает сообщение о его выполнении системному демону протоколирования syslogd, а после выполнения всех заданий из конфигурационного файла заканчивает работу.

Конфигурационный файл /etc/anacrontab может содержать строки трех типов:

• строки описания заданий,
• строки задания переменных окружения,
• строки комментариев.

Строка описания заданий имеет следующий формат:

период задержка идентификатор_задания команда

Как уже говорилось, период задается в днях, а задержка — в минутах. Идентификатор задания может содержать любые символы, кроме пробелов и слэшей. Он используется для идентификации задания при формировании сообщений демону протоколирования и при запоминании времени выполнения задания. В качестве команды может использоваться любая команда оболочки.

Строки задания переменных имеют стандартный формат:

ИМЯ_ПЕРЕМЕННОЙ = ЗНАЧЕНИЕ

В качестве строк комментария может выступать пустая строка, строка состоящая только из пробелов или строка, содержащая произвольную последовательность символов, начинающуюся символом ‘#‘, перед которым может стоять любое количество пробелов.

Приведу в качестве примера файл /etc/anacrontab из стандартной установки дистрибутива CentOS 7:

cat /etc/anacrontab

Как видно, в CentOS 7 утилита anacron «подстраховывает» демон cron, запуская периодические задания cron‘а, если последний почему-либо их не запускал. Благодаря этому, в частности, скрипт logrotate регулярно, точнее, при каждом запуске компьютера, выполняется, несмотря на то, что демоном crond он не запускается из-за выключения компьютера на ночь.

Среди регулярно запускаемых cron‘ом скриптов, в каталогах /etc/cron.daily, /etc/cron.weekly и /etc/cron.monthly, вы найдете скрипт 0anacron, который заботится о том, чтобы обновить записи о времени последнего выполнения тех заданий, которые поручены обеим демонам, чтобы исключить их повторное выполнение anacron‘ом.

При желании можно, очевидно, сделать так, чтобы cron, в свою очередь, «подстраховывал» anacron, периодически запуская его, хотя проще просто поручить периодические задания cron‘у.

Демон anacron запускается при старте системы и, выполнив предписанные ему задания, завершает работу. Наверное поэтому нет никаких утилит, специально предназначенных для ввода новых заданий демону anacron. Такие задания может давать только суперпользователь путем прямого редактирования файла /etc/anacrontab. По-видимому, основное назначение этого демона — выполнять какие-то работы по обслуживанию системы после периодов долгого простоя.

Примеры cron-заданий.

Ниже приведены несколько примеров cron-заданий:

• Чтобы выполнять команду каждую минуту, задание должно быть такое:

* * * * * <исполняемая-команда>

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

*/5 * * * * <исполняемая-команда>

• Вызывать команду 4 раза в час (каждые 15 минут):

*/15 * * * * <исполняемая-команда>

• Чтобы выполнить команду каждый час в 30 минут, пишем:

30 * * * * <исполняемая-команда>

То есть команда будет выполняться не каждые 30 минут, а тогда, когда значение минут будет равно 30 (например, 10:30, 11:30, 12:30 и так далее).

• Значения времени можно комбинировать, перечислив их через запятую. Следующий код будет выполнять команду три раза в час: в 0, 5 и 10 минут.

0,5,10 * * * * <исполняемая-команда>

• Выполнять команду каждый час будет следующее задание:

0 * * * * <исполняемая-команда>

• Выполнение команды каждые два часа:

0 */2 * * * <исполняемая-команда>

• Чтобы выполнять команду каждый день (в 00:00):

0 0 * * * <исполняемая-команда>

• Выполнение команды каждый день в 03:00:

0 3 * * * <исполняемая-команда>

• Выполнение команды каждое воскресенье (sunday):

0 0 * * SUN <исполняемая-команда>

• Другой вариант задания, которое будет выполнять команду каждое воскресенье (естественно, тоже в 00:00):

0 0 * * 0 <исполняемая-команда>

• Выполнение команды каждый день с понедельника по пятницу:

0 0 * * 1-5 <исполняемая-команда>

• Следующее задание будет выполнять команду каждый месяц, 1-го числа в 00:00:

0 0 1 * * <исполняемая-команда>

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

15 16 1 * * <исполняемая-команда>

• Выполнение команды каждые три месяца:

0 0 1 */3 * <исполняемая-команда>

• Выполнение команды в строго определённое время и месяц:

5 0 * 4 * <исполняемая-команда>

• Задание будет вызывать команду в начале каждого полугодия (в 00:00 1-го дня):

0 0 1 */6 * <исполняемая-команда>

• Выполнение команды каждый год 1-го января в 00:00:

0 0 1 1 * <исполняемая-команда>

Готовые cron-задания.

• @reboot запускать при начальной загрузке сервера;
• @yearly заменяет ‘0 0 1 1 *‘, то есть ‘ежегодно в 00:00 1 января‘;
• @annually тоже что и yearly>;
• @monthly заменяет ‘0 0 1 * *‘ то есть ‘ежемесячно в 00:00 1 числа‘;
• @weekly заменяет ‘0 0 * * 0‘ то есть ‘еженедельно в 00:00 воскресенье‘;
• @daily заменяет ‘0 0 * * *‘ то есть ‘ежедневно в 00:00‘;
• @midnight тоже что и daily;
• @hourly заменяет ‘0 * * * *‘ то есть ‘ежечасно в 00 минут‘.

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

@reboot <исполняемая-команда>

Настройка cron для web-программистов.

Добавляем в cron задачу, которая будет выполнятся каждую минуту.

Набираем:

crontab -e

И добавляем (будет выполняться под тем пользователем под кем вы зашли в SSH):

*/1 * * * * /usr/bin/php -q /server/cron/cron.php > /dev/null 2>&1

Сохраняемся, 

Где:

• */1 * * * * — означает что скрипт будет запускаться каждую минуту;
• > /dev/null — означает отправку результатов, которые выдаст скрипт, в никуда;
• 2>&1 — избавляет администратора сервера от писем, если скрипт закончит работу с ошибками.

Для отправки на почту воспользуемся postfix.

Как сделать возможность получать письма с сервера описано в статье: «CentOS 7: Postfix 3 для отправки электронной почты с внутреннего системного «почтового ящика».

Набираем:

crontab -e

И добавляем (будет выполняться под тем пользователем под кем вы зашли в SSH):

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

0 0 * * 1-5 /usr/bin/bash /sh/directory.ru-backup-day.sh > /tmp/backup-day.txt && mail -s "Site directory.ru day rotate" admin@yandex.ru < /tmp/backup-day.txt

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

0 0 * * SUN nmap -T4 -A -v 192.168.0.31 > /tmp/nmap.txt && mail -s "Nmap usage" admin@yandex.ru < /tmp/nmap.txt

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

0 0 * * * df -h | mail -s "Disk usage" admin@mail.ru

Сохраняемся, 

Добавляем в cron задачу, которая будет выполнятся, сохранит результат выполнения скрипта в файл и отправит его на почту с темой, в нашем случае в теле письма, но можно и приложением.

Иногда надо запускать по cron скрипт который лежит уже на сайте и использует окружение сайта.

Установим менеджер загрузок wget:

yum -y install wget

Набираем:

crontab -e

И добавляем (будет выполняться под тем пользователем под кем вы зашли в SSH):

*/5 * * * * /usr/bin/wget --no-check-certificate -O /dev/null https://www.linuxshop.ru/cronit.sh

Сохраняемся, 

Где:

• wget — как бы выкачивает скрипт (что нам и нужно web-сервер его исполняет);
• --no-check-certificate не проверять сертификат https;
• -O /dev/null — не сохранять выкаченный файл на жесткий диск.

Настройка cron для системных администраторов.

Фактически, cron — это сервис, как и большинство других сервисов CentOS 7, он запускается при старте системы и работает в фоновом режиме. Его основная задача выполнять нужные процессы в нужное время. Существует несколько конфигурационных файлов, из которых он берет из них информацию о том что и когда нужно выполнять. Сервис открывает файл /etc/crontab (тут могут быть тоже прописаны задачи) и они не будут отображаться по команде crontab –l.

Так же существует anacron (anachronistic cron или асинхронный (анахроничный) cron) и его запуск и его задания тоже нужно учитывать, смотрите файл /etc/anacrontab и каталоги /etc/cron.daily/, /etc/cron.hourly/, /etc/cron.monthly/ и /etc/cron.weekly/.

Часто, в современных дистрибутивах там прописан запуск утилиты run-parts, которая запускает нужные скрипты из следующих папок:

• /etc/cron.minutely — каждую минуту;
• /etc/cron.hourly — каждый час ещё cat /etc/cron.d/0hourly — тут настроен;
• /etc/cron.daily — каждый день;
• /etc/cron.weekly — каждую неделю;
• /etc/cron.monthly — каждый месяц.

Список всех задач cron у всех пользователей.

К сожалению для системного администратора нет такого инструмента, так как задачи в CentOS 7 могут храниться в нескольких местах:

Клиентский crontab (# crontab -u user -l)

• /etc/crontab — можно посмотреть cat /etc/crontab;
• /etc/anacrontab — можно посмотреть cat /etc/anacrontab;
• /etc/cron.d/ — cron считывает файлы в каталоге /etc/cron.d/;
• /etc/cron.daily/ — запуск всех скриптов один раз в день;
• /etc/cron.hourly/ — запуск всех скриптов один раз в час;
• /etc/cron.monthly/ — запуск всех скриптов один раз в месяц;
• /etc/cron.weekly/ — запуск всех скриптов один раз в неделю.

Иногда конкретные пользователи могут создавать задачи тоже, как описано в общих методах. Задания cron для конкретных пользователей расположены в /var/spool/cron/username. При создании задач для конкретных пользователей, вам не нужно указать имя пользователя в cron.

Для того чтобы пройти руками все клиентские crontab (# crontab -u user -l), можно автоматизировать для всех пользователей очевидно нужно взять список пользователей в системе из /etc/passwd и сделать для каждого пользователя:

crontab -u USERNAME -l

, то есть:

for user in $(cut -d':' -f1 /etc/passwd); do crontab -u $user -l; done

Недостаток этого решения очевиден:

1. Нужно всегда помнить эту команду.
2. Если у пользователя нет задач в планировщике то мы получим сообщение «no crontab for vasua» и таких сообщений может быть десятки если у вас много пользователей — это неудобно.
3. Вывод информации неудобно читать.

Решение простое — создадим функцию allcrontab в файле ~/.bashrc для ввода информации в более удобном виде:

# Определим цвета вывода
red='\e[0;31m'
RED='\e[1;31m'
green='\e[0;32m'
GREEN='\e[1;32m'
NC='\e[0m'

# Определим нашу функцию вывода списка всех задач cron у всех пользователей
function allcrontab() {
  for user in $(cut -d':' -f1 /etc/passwd); do
   usercrontab=$(crontab -l -u ${user} 2>/dev/null)
   if [ -n "${usercrontab}" ]; then
      echo -e "${RED}====== Start crontab for user ${NC}${GREEN}${user}${NC} ${RED}======${NC}"
      crontab -l -u ${user} | sed '/ *#/d; /^ *$/d'
      echo -e "${RED}====== End crontab for user ${NC}${GREEN}${user}${NC} ${RED}========${NC}\n"
   fi
  done
}

Выполняем source ~/.bashrc или перелогиниваемся и выполняем в консоли allcrontab и видим красивый вывод списка всех задач cron у всех пользователей.

Но это не финишная прямая, а только начало, ведь опытный системный администратор знает, что кроме вывода списка заданий командой # crontab -u user -l есть еще задания планировщика в каталоге /etc/cron.d/ и это тоже нужно учитывать, потому что например панель хостинга ISPConfig сохраняет задания cron в каталоге /etc/cron.d/ с именами ispc_webXXX, где webXXX — это логин системного пользователя, например web30 и вывод # crontab -u web30 -l нам скажет «no crontab for web30», а на самом деле в файле /etc/cron.d/ispc_web30 может быть такая картина:

SHELL='/bin/sh'
*/2 * * * * web30 /usr/bin/php -f /var/www/mysite.ru/web/yii cron-origin/index

Чтобы вывести список всех заданий cron от всех пользователей вашей системы создайте скрипт:

#!/bin/bash
for user in $(cut -f1 -d: /etc/passwd)
do
  echo $user
  crontab -u $user -l
done

Альтернативой вашей проблеме может быть размещение их в папке cron.d и указание соответствующего пользователя для каждого cron, как в примере:

0 1 * * * user /home/user/user-script.sh

Отладка работы cron.

После того как вы настроили правила, еще хотелось бы проверить работают ли они. Для этого ждем того времени, когда скрипт уже должен быть выполнен и смотрим log cron. Обычно он находится в /var/log/cron.

Если нужно проверить скрипт, который находится в одной из специализированных папок, то тут еще проще, просто запустите run-paths, передав ей в параметр нужную папку или даже сам скрипт:

sudo run-paths /etc/cron.daily/

Примерно вот так:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed

37 * * * * root run-parts /etc/cron.hourly
23 5 * * * root run-parts /etc/cron.daily
19 3 * * 0 root run-parts /etc/cron.weekly
23 0 6 * * root run-parts /etc/cron.monthly

Файлы справки и помощи по cron.

Для получения дополнительной информации вы можете проверить страницу man:

man cron

, а также:

man crontab

Cron калькуляторы.

Если трудно установить правильную задачу в начале, вы можете использовать cron калькулятор, чтобы сгенерировать выражение требуемой задачи. Можно найти несколько хороших калькуляторов cron в Интернете.

freeformatter.com — сайт с анкетой запуска заданий, заполняете анкету и получаете строку для cron.

crontab.guru — сайт для генерации случайного времени исполнения задания, нажали кнопочку — получили рандомную строку для cron.

sysmasters.net — обратный калькулятор, вводим в поле строку из cron и получаем расшифровку, что и когда будет исполняться.

Как можно получить «копию» crontab?

Внимание! На самом деле не рекомендуется обработать те файлы вручную!

На crontab странице справочника есть упоминание, что:

Цитата

У каждого пользователя может быть их собственный crontab, и хотя это файлы в /var/spool/cron/crontabs, они не предназначены для непосредственного редактирования.

Файлы под /var/spool считаются временными/рабочими, вот почему они, вероятно, будут удалены во время обновления, хотя если более внимательно рассмотреть cron сценарии обновления пакета, то можно понять некоторые интересные детали.

Так или иначе это, всегда хорошо, создать резервную копию записей крона или сохранить их в файле в корневом каталоге.

Я предполагаю, что вы используете crontab -e создать crontab файлы на лету. Если так, можно получить «копию» crontab файла путем выполнения crontab -l.

Выводим информацию в файл для получения эффекта «резервного копирования»:

crontab -l > my-crontab

Затем можно отредактировать это мой-crontab файл, чтобы добавить или изменить записи и затем «установить» его путем предоставления его crontab:

crontab my-crontab

Это делает тот же эффект, как проверяющая команда crontab -e.

Житейские примеры из практики.

Вариант записи в crontab:

# как обычно, с символа '#' начинаются комментарии
# в качестве командного интерпретатора использовать /bin/sh
SHELL=/bin/sh
# результаты работы можно отправлять по этому адресу
MAILTO=paul@example.org
# добавить в PATH домашний каталог пользователя
PATH=/bin:/usr/bin:/home/paul/bin

#### Здесь начинаются задания
# выполнять каждый день в 0 часов 5 минут, результат складывать в log/daily
5 0 * * * $HOME/bin/daily.job >> $HOME/log/daily 2>&1
# выполнять 1 числа каждого месяца в 14 часов 15 минут
15 14 1 * * $HOME/bin/monthly
# каждый рабочий день в 22:00
0 22 * * 1-5 echo "Пора домой" | mail -s "Уже 22:00" john

23 */2 * * * echo "Выполняется в 0:23, 2:23, 4:23 и т. д."
5 4 * * sun echo "Выполняется в 4:05 в воскресенье"
0 0 1 1 * echo "С новым годом!"
15 10,13 * * 1,4 echo "Эта надпись выводится в понедельник и четверг в 10:15 и 13:15"
0-59 * * * * echo "Выполняется ежеминутно"
0-59/2 * * * * echo "Выполняется по чётным минутам"
1-59/2 * * * * echo "Выполняется по нечётным минутам"
# каждые 5 минут
*/5 * * * * echo "Прошло пять минут"
# каждое первое воскресенье каждого месяца. -eq 7 это код дня недели, т. е. 1 -> понедельник , 2 -> вторник и т. д.
0 1 1-7 * * [ "$(date '+\%u')" -eq 7 ] && echo "Эта надпись выводится каждое первое воскресенье каждого месяца в 1:00"

# Cert Renewal
30 6 1 * * root /usr/local/bin/certbot-auto renew --post-hook "nginx -s reload" >> /var/log/le-renew.log

# Site hamsterden.ru day rotate
10 4 * * * root /usr/bin/bash /sh/hamsterden.ru-backup-day.sh > /dev/null 2>&1

# Clean Trash Yandex.Disk
0 5 * * * root /usr/bin/bash /sh/mycleantrash.sh > /dev/null 2>&1

# для принудительного "сброса" содержимого временных буферов памяти на диск
0,30 * * * * date; sync; echo "запись данных на диск"

# прочие примеры
/5 * * * * /misc/git_ansible_update.sh > /misc/last_update.log 2>&1
11 * * * * /usr/bin/find /etc/ansible -name "*.retry" -type f -delete 2>&1
*/5 * * * * cd ~/.ssh && eval `ssh-agent -s` && $(cat /home/username/.ssh/someway | ssh-add -) && git pull &> ~/last_udpate.log
*/5 * * * * cd ~/.ssh/config.d/ && git pull &> ~/last_udpate.log

# запустить скрипт после перезагрузки сервера, через 600 секунд
@reboot sleep 600; find ${HOME}/my_app/check_conn.sh

Оригиналы источников информации.

ru.wikipedia.org «cron».

linuxshop.ru «Настройка cron».

andreyex.ru «Автоматизация системных задач с использованием cron на CentOS 7».

rus-linux.net «Домашнее задание для компьютера».

askubuntu.ru «Где хранится пользовательский crontab?»

Источник

Ну нельзя обновить nectcloud так чтобы всё работало. И вот в очередной раз проблемы. По мимо индексов баз, решение которое мы уже обсуждали по ссылке ниже

появилась новая проблема. Мол OPcache не правильно настроен. И указывает параметр который не правильно настроен

opcache.interned_strings_buffer

этот параметр должен быть 8. 

У меня система Centos 8 Stream, поэтому я буду приводить команды для неё.

nano /etc/php.d/10-opcache.ini

и меняем параметры на следующие значение ( если вдруг они ещё не поменяны)

opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

самое важное здесь это opcache.interned_strings_buffer=8. Сохраняем и ребутим php-fpm

systemctl restart php-fpm

заходим в облако и видим что ошибка не исчезла. Не беда! Снова редактируем файл /etc/php.d/10-opcache.ini

nano /etc/php.d/10-opcache.ini

и выключаем opcache

opcache.enable=0

и увеличиваем на всякий случай параметр opcache.interned_strings_buffer до 24 

opcache.interned_strings_buffer=24

после чего ребутим php-fpm 

systemctl restart php-fpm

и редактируя всё тот же файл включаем opcache обратно

opcache.enable=1

и снова ребутим php-fpm. Всё теперь ошибка должна уйти. 

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

# netstat -m
1026/2709/3735 mbufs in use (current/cache/total)
1024/1766/2790/132096 mbuf clusters in use (current/cache/total/max)
1024/768 mbuf+clusters out of packet secondary zone in use (current/cache)
0/802/802/66048 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/33024 9k jumbo clusters in use (current/cache/total/max)
0/0/0/16512 16k jumbo clusters in use (current/cache/total/max)
2304K/7417K/9721K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
15 requests for I/O initiated by sendfile
0 calls to protocol drain routines

или

# vmstat -z | grep mbuf
mbuf_packet: 256, 0, 1024, 768, 9163111497, 0
mbuf: 256, 0, 2, 1941, 6166886673, 0
mbuf_cluster: 2048, 132096, 1792, 998, 14208, 0
mbuf_jumbo_page: 4096, 66048, 0, 802, 166262704, 0
mbuf_jumbo_9k: 9216, 33024, 0, 0, 0, 0
mbuf_jumbo_16k: 16384, 16512, 0, 0, 0, 0
mbuf_ext_refcnt: 4, 0, 0, 672, 11055, 0

Так же можно ещё посмотреть количество коллизий на интерфейсах:

# netstat -id

Если кратко объяснить, что оно такое: нехватка системных буферов для выполнения операций. Как правило такая проблема появляться на плохих сетевых карточках и не всегда зависит от большой нагрузки. К примеру, я наблюдал такую ситуацию, когда в кроне выставлен пинг (8 пакетов) на хост каждый 5 минут и за сутки появлялось такое сообщение на шлюзе, который обслуживает 20 человек с каналом загрузки до 10мбит.

Но что же сделать, что бы избавиться от этого раз и навсегда? Самый правильный способ — поставить хорошие сетевые карточки, например, Intel (igb). Второй вариант даёт результат с вероятностью 50%. Он представляет собой небольшой тюниг переменных системы и ядра. Опишу его ниже.

— увеличиваем количество nmbclusters и буферов:

echo 'kern.ipc.nmbclusters=524288' >> /boot/loader.conf
echo 'kern.ipc.maxsockbuf=1048576' >> /boot/loader.conf
echo 'hw.igb.rxd=4096' >> /boot/loader.conf
echo 'hw.igb.txd=4096' >> /boot/loader.conf

где igb — имя сетевой карты, на которой возникают проблемы (если у вас другая — замените соответственно на другое имя)

Примечание.

На 64-битных системах с большим объёмом памяти можно выставить значения kern.ipc.nmbclusters=1000000

— увеличиваем размер буфера

net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.sendbuf_inc=16384
net.inet.tcp.recvbuf_inc=524288

— увеличиваем количество пользователей и значение буферов

пересобираем ядро с такими параметрами
 

maxusers        512
options         NBUF=4096

Если вы используете netgraph, можно ещё увеличить такие значения:

net.graph.maxdgram=524288
net.graph.recvspace=524288

Если же после этого тюнинга продолжают появляться такие ошибки — попробуйте либо увеличить значения либо поставить всё же нормальную сетевую карточку.

После очередного обновления, очередная проблема. В общем перестали открываться офисные документы непосредственно в веб версии облака. Лечится просто, нужно добавить параметр allow_local_remote_servers. для этого выполняем следующую команду 
 

sudo -u apache php occ config:system:set allow_local_remote_servers --value true --type bool

Вот другие статьи на тему ошибок nextcloud

В базе данных отсутствуют некоторые индексы

Заголовок HTTP «Strict-Transport-Security»

Warning: PHP Opcache not properly configured

Давеча столкнулся с проблемой. Кончилось место на диске. Причем в корне. Скринов не наделал, т.к. нужно было решать проблему быстро. В общем что же произошло

Получил сообщение о том что сайт не работает. Первым дело проверяю виртуалку - с ней всё впорядке. Начинаю тыкать сервисы - тоже. Но при открытии сайта - вылазит ошибка. Пытаюсь прочитать логи - в логах ничего. Странно. Ну и решил глянуть на место, может logrotate сломался. Как оказалось место кончилось. Ну я полез в логи и поудалял. На самом деле логов было не много, значит logrotate работал исправно. В чем же дело. Запускаю ncdu и смотрю по папкам. Папка /var весит 500 гигов. Но это нормально, ведь в ней есть папка /var/mnt/bck - которая прицеплена по NFS, и она как раз почти столько и вешает. В общем ковырялся смотрел, и решил отцепить NFS, на всякий случай. Заодно почистить бекапы если потребуется. И что вы думаете? Отцепив NFS - папка /var всё равно весила много и как раз занимала всё место. Посмотрев что же в ней занимаете место я удивился: т.к. при отцепленой шаре NFS папка всё равно присутствовала. И тогда до меня дошло: 
Как то раз у меня накрылся FreeNAS. Встал колом. Я его ребутнул. Вот видимо тогда и папка отвалилась, но продолжила делать бекапы в указанную папку. После ребута, NFS шара подцепилась заного, но файлы то остались. В итоге современем логи добили оставшееся место - и вуаля. Место в корне кончилось. Так что будьте внимательны при NFS шарах  

Давеча после обновления nextcloud до версии 31.0.0 в админке столкнулся вновь с кучей ошибок. То что там проблемы с индексами после обновления - это уже стандартная тема, а вот ошибка из сабжа - что-то новенькое. И так как же её решить. А очень и очень просто. 

Цепляемся к своему серверу по ссх. заходим в мускуль командой

mysql -u root -p

прописываем 

SET GLOBAL innodb_default_row_format=DYNAMIC;

после чего прописываем

SELECT CONCAT('ALTER TABLE `', table_name, '` ROW_FORMAT=DYNAMIC;') AS sql_statements
FROM information_schema.tables
WHERE table_schema = 'nextcloud'
AND ROW_FORMAT != 'Dynamic';

Обратите внимание на то как называется схема, у меня это nextcloud

Он выдаст портянку текста. Её нужно скопировать и выполнить как sql скрипт. Портянка примерно такого содержания

| ALTER TABLE `oc_ex_task_processing` ROW_FORMAT=DYNAMIC;        |
| ALTER TABLE `oc_collres_resources` ROW_FORMAT=DYNAMIC;         |
| ALTER TABLE `oc_user_status` ROW_FORMAT=DYNAMIC;               |
| ALTER TABLE `oc_flow_checks` ROW_FORMAT=DYNAMIC;               |
| ALTER TABLE `oc_privacy_admins` ROW_FORMAT=DYNAMIC;            |
| ALTER TABLE `oc_cards` ROW_FORMAT=DYNAMIC;                     |

Что я сделал. Скопировал это всё, вставил в текстовый документ. удалил лишние символы |, зашел в PMA. Выбрал нужную схему и просто выполнил его в SQL

И вуаля. Ошибка пропала За подсказку спасибо передавать вот сюда

На новой работе встал вопрос поднялся вопрос о том что все пароли хранятся у нашей команды у кого как. У кого в текстовых документах, у кого на облаке OneDrive в таблице, у кого вообще во всех местах подряд. Я же для своих паролей использую KeePassXC. Файл базы лежит на моём облаке Nextcloud и на телефоне установлено приложение KeePass for Android. Но когда встал а где мне взять пароль от чего-то - мне сообщили пароль у Васи. А Вася в отпуске и трубку не берёт. Вот собственно тогда и встал вопрос о том чтобы рабочие пароли как-то хранить централизованно, что бы у каждого из сотрудников был доступ и можно было в любой момент найти нужный пароль в независимости от того от чего он и кто за него отвечает. 
Выбор того как хранить пароли, на самом деле достаточно велик: форков тогоже KeePass достаточно много. Посути KeePassXC сам является форком KeePass Save, если мне не изменяет память. Но у меня стояли конкретные цели: 
1. Удобство хранения
2. Запуск на любом устройстве
3. Мобильная версия
4. Шифрование
5. Генератор паролей
6. Проверка на то что пароль слит
7. Бесплатен
Были ещё требования, но они не критичны, и каждый из команды был готов от них отказаться, если приложение его устроит по параметрам указанным выше. Собственно выбор пал на два решения: Passbolt и BearPass. Толи из-за того что второй вариант был созвучен с beerpass, толи из-за того что это российская разработка, выбрали первым для тестирования его. Вот в этой статье я и расскажу как его установить. На самом деле ничего сложного в этом нет, и все делается просто. 
 

Для установки "коробочного" решения на сервер Вам потребуется:

1. PHP 8.4
2. PostgreSQL 13 и выше
3.Пакетный менеджер Composer

Всё. Ну и конечно 2 ядра 2 гига на борту (рекомендуют 4 но нам хватает и 2)

Предположим что у нас уже есть установленная Debian 12 и настроенная на удаленный доступ по SSH под root пользователем. Как это сделать я думаю найти не составит труда. А скачать саму ОС можно у меня в файлах

Первым делом конечно же обновляем систему
 

apt-get update && apt-get -y upgrade

после чего перегружаемся 

reboot

далее добавляем пользователя из под которого будет всё работать, и в процессе из под него же мы будем всё настраивать, например www-data

mkdir -p /var/www
adduser --home /var/www/ www-data
cp /etc/skel/.bashrc /var/www
cp /etc/skel/.profile /var/www
chown -R www-data:www-data /var/www
usermod -s /bin/bash www-data

Далее ставим мной ненавистный Git. Не люблю я его хоть это и прекрасная вещь

apt install git

Чтобы протестировать что всё установилось, т.к. git бывает что не работает, по крайней мере у меня, проверим его версию

git --version

Примерно должны получить следующее: 

Цитата

git version 2.39.5

Далее установим php. Для этого подключим репозиторий

apt install apt-transport-https lsb-release ca-certificates wget -y
wget -O /etc/apt/trusted.gpg.d/php.gpg https://mirror.yandex.ru/mirrors/packages.sury.org/php/apt.gpg
sh -c 'echo "deb https://mirror.yandex.ru/mirrors/packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
apt update

Ставим OpenSSL

apt-get install openssl

Ставим php версии 8.4. 

Вот тут у меня кстати была ошибка. Толи РКН вновь дурковал, толи яндекс. Но в общем у меня не хотелось ничего ставиться. Мне пришлось прописывать ключ "-y" вконце и повторять установку несколько раз, по итогу всё удалось

apt install php8.4 php8.4-{cli,curl,fpm,intl,mbstring,pgsql,zip,xml,bcmath,ldap}

Установится всё что требуется для минимальной работы bearpass. Если необходимы будут какие-то тюненги, тут уже ставьте дополнительные модули сами. Мне достаточно было стандартной установки

Дальше необходимо отредачить файлы конфигов, рекомендую редактировать оба: /etc/php/8.4/fpm/php.ini и /etc/php/8.4/cli/php.ini
 

date.timezone = "Europe/Moscow" ; Или любая другая, необходимая для сервера
include_path = "."
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off

Если используем nano для редактирования, то просто ищем через "Ctrl + W", если какой-другой - то уже сами. Вообще, если я правильно помню, все параметры закомментированы, и достаточно просто в конец файлов добавить эти строки.

Далее на необходимо в файле /etc/php/8.4/fpm/pool.d/www.conf проверить, что php-fpm запускается от ранее созданного пользователя (в нашем примере www-data)

user = www-data
group = www-data

listen.owner = www-data
listen.group = www-data

После чего рестартим php-fpm

service php8.4-fpm restart

После устанавливаем composer. Его я тоже не люблю еще со времен roundcube, но не смотря на всё он удобен. 

apt install wget
wget -O composer-setup.php https://getcomposer.org/installer
php composer-setup.php --install-dir=/usr/local/bin --filename=composer
chmod +x /usr/local/bin/composer

Теперь собственно переходим к установке nginx

apt-get install nginx nginx-full

И сразу после установки удаляем его дефолтные конфиги

rm /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Далее в файле /etc/nginx/nginx.conf в секции раскомментировать) строку

server_tokens off;

Далее в файл /etc/nginx/sites-available/bearpass поместить содержимое

upstream bp_fastcgi_backend {
  server unix:/run/php/php8.4-fpm.sock;
}

server {
  listen 80;
  
  server_name bearpass.ru;
  
  set $BP_ROOT /var/www/bearpass;
  
  include /var/www/bearpass/nginx.conf;
}

этого достаточно для работы. Изменить обязательно стоит только server_name. Остальное по желанию

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

ln -s /etc/nginx/sites-available/bearpass /etc/nginx/sites-enabled/bearpass

Далее ставим PostgreSQL

apt-get install postgresql

и сразу же заходим под админом: по умолчанию это postgres

su postgres

после чего подключаемся к нему 

psql

и создаем пользователя с базой данных

CREATE USER <username> WITH encrypted password '<password>';
CREATE DATABASE <db_name> OWNER <username> ENCODING 'UNICODE';

Прошу обратить внимание что имя пользователя, как и имя базы идёт без одинарных ковычек, а вот пароль с одинарными ковычками

Далее можно установить Exim4, но для его нормальной работы потребуется DKIM и SPF. А это уже больше по настройке почтового сервера, поэтому в рамках этой статьи мы это не будет рассматривать. 
В целом мы с окружением закончили. Этого достаточно для минимальной работы bearpass (так и подмывает его называть beerpass). Теперь перейдём непосредственно к установке самого приложения.

Дальше настройка и установка будет производиться из под пользователя которого мы создали ранее а именно www-data

su www-data

далее клонируем репу с git с парольным менеджером

git clone https://git.bearpass.ru/bear-pass /var/www/bearpass

переходим в директорию 

cd /var/www/bearpass

копируем переменные окружения

cp .env.example .env

редактируем .env

nano .env

заполняем следующие параметры

APP_URL - URL по которому будет открываться парольный менеджер
DB_DATABASE - название базы данных
DB_USERNAME - пользователь с доступом к базе данных
DB_PASSWORD - пароль пользователя

устанавливаем необходимые пакеты с помощью composer

composer install --no-dev -q --no-ansi --no-interaction --no-scripts --no-progress --prefer-dist
composer dump-autoload

генерируем ключи

php artisan key:generate
php artisan encryption-key:generate

выполняем миграции

php artisan migrate --seed --no-interaction --force &&
php artisan optimize:clear

теперь нам нужно добавить записи в crontab, но так как мы сейчас находимся под пользователем www-data, нам это не удастся сделать, поэтому заходим под root

su root

редактируем crontab

nano /etc/crontab

добавив в него строчку

* * * * * /usr/bin/php8.4 /var/www/bearpass/artisan schedule:run > /dev/null 2>&1

теперь вновь возвращаемся под пользователя www-data

su www-data

и создаем пользователя с админскими правами

php artisan make:username

В ответ должен придти запрос на ввод почты и пароля. Они требуются для авторизации

Дальше требуется настроить SSL сертификат, но мне для тестов он не нужен, поэтому я пропустил данный параметр. А вообще он так же необходим для нормальной работы менеджера. Почитать про установку и настройку SSL сертификата можно на сайте разработчиков.

На этом собственно всё. Далее заходим под root

su root

на всякий случай рестартим nginx

service nginx restart

и можем пользоваться. 
Да, для полноценной работы необходимо настроить и почту, и SSL и желательно бы прикупить лицензию, но для тестов этого вполне достаточно. Посмотреть, прикинуть, пощупать. И если приглянулось, то можно накатывать SSL и уже тогда можно полноценно пользоваться. 
В общем как-то так. 

Всем доброго суток. У меня крутится веб сервер для личных нужд (в частности на нём этот блог, облако, еще пара сайтов). Он довольно многострадальный, т.к. ему уже лет 7-8. Я его не раз перетаскивал с винта на винт, ну и соответственно т.к. время идет - то и версию я ему обновлял. Изначально там был Centos 7. После я его обновил до Centos 8. Далее был Centos Stream. После того как мне надоело что у меня мускуль по непонятным причинам после перезагрузки запускается через раз - решил мигрировать на Rocky, что я успешно и сделал. И вот теперь пришло время обновить до 9 версии, а точнее до 9.6. Летом вышла 10 версия, но я пока не готов шагнуть на неё. 
В обновлении ничего сложного нет, по крайней мере когда у тебя установлен только LAMP. Проблем с зависимостями у меня небыло. 
Единственная сложность была в инструкциях. DeepSeek упорно пытался меня заставить обновиться через leapp-data-rocky или leapp-data-flow, но как оказалось это неверное решение. Оно может быть и работало, но когда то давно. Поэтому порыскав по инету, нашел одну инструкцию и не много поковырявшись адаптировать её под актулальные версии на данный момент (а именно 9.6). И так, приступим: 
Естественно первое что следует сделать - это бекап. Делайте так как вам удобно, хоть через DD. Т.к. у меня на виртуалке - я просто сделал snapshot. 

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

sudo dnf upgrade --refresh

После этого нам необходимо добавить репозитории актуальной версии rocky. Посмотреть это можно на офф репе rocky. Нам необходимы версии вот этих файлов: rocky-release, rocky-repos, and rocky-gpg-keys. Копируя имена файлов, сделаем несколько переменных (на 04.11.2025 актуальная версия 9.6):

 Ссылка на официальный репозиторий, тут как бы ничего не меняется

REPO_URL="https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/r"

А вот дальше будьте внимательны и добавляйте именая файлов для актуальной версии. На момент написания это 9.6

RELEASE_PKG="rocky-release-9.6-1.3.el9.noarch.rpm"
REPOS_PKG="rocky-repos-9.6-1.3.el9.noarch.rpm"
GPG_KEYS_PKG="rocky-gpg-keys-9.6-1.3.el9.noarch.rpm"

После этого запускаем нехитрую команду для установки

sudo dnf install $REPO_URL/$RELEASE_PKG $REPO_URL/$REPOS_PKG $REPO_URL/$GPG_KEYS_PKG

У меня устанавливалось/обновлялось 961 элементов. Но всё прошло достаточно быстро. После того как установка закончена, необходимо удалить то что уже не понадобится

dnf -y remove rpmconf yum-utils epel-release
rm -rf /usr/share/redhat-logos

доставляем необходимые зависимости

sudo dnf -y --releasever=9 --allowerasing --setopt=deltarpm=false distro-sync

ребилдим базу

sudo rpm --rebuilddb

после чего перезагружаемся

reboot

и радуемся новой установленной версии rocky linux

cat /etc/os-release

Вот и всё.