ArcheRAWG

Intel наконец-то приоткрыла завесу над своей новой серией графических адаптеров для десктопов, опубликовав подробные характеристики моделей Arc A770 и A750. Кроме того, в сети появились и аналогичные сведения о бюджетной игровой видеокарте Arc A580. Компания подтвердила, что модель A770 будет построена на базе графического процессора ACM-G10 (2,1 ГГц) с 32 ядрами Xe и получит 16 ГБ видеопамяти GDDR6 (скорость 17,5 Гбит/с, пропускная способность 560 ГБ/с). Заявленная потребляемая мощность будущей новинки составляет 225 Вт. Intel Arc A750, в свою очередь, будет иметь 28 ядер Xe и 8 ГБ VRAM того же типа (16 Гбит/с, 512 ГБ/с). Тактовая частота GPU этой модели окажется на 50 МГц ниже, чем у флагмана серии, а вот энергопотребление не изменится. Наконец, более доступная Arc A580 обзаведётся 24 ядрами Xe и 8 ГБ видеопамяти, а частота её графического чипа в стоке составит 1,7 ГГц. Точная дата начала продаж, география доступности и рекомендованные розничные цены готовящихся к выпуску новинок компанией пока не объявлены. Открыть запись

Компания Google рассказала в своём блоге о наиболее интересных обновлениях фирменных приложений для Android. Теперь смартфон сможет описывать то, что «слышит», Gboard научится «эмодзифицировать» текст, а YouTube — устраивать совместный просмотр видео на 100 человек. Первое нововведение призвано помочь слабослышащим людям. Функция Live View позволяет Android-смартфону распознавать окружающие звуки и сообщать владельцу о происходящем вокруг. Например, гаджет может оповестить о включении пожарной тревоги, лае собаки или о том, что пицца в микроволновке уже разогрелась. Кроме того, можно добавлять в библиотеку свои звуки и сопоставлять с ними уведомления. А для слабовидящих пользователей Google подготовила библиотеку фильмов в Google TV с аудиоописаниями. Следующая функция под названием Emojify предназначена для Gboard. Она поможет лучше выражать свои эмоции в переписке, автоматически добавляя эмодзи в текст. При желании смайлик можно будет сменить на другой, лучше подходящий по контексту, нажав специальную экранную кнопку. Наконец, в мобильном приложении YouTube для Android появился совместный просмотр роликов через интерфейс сервиса видеоконференций Google Meet. Теперь можно добавить до 100 друзей к совместному просмотру видео, чтобы обсуждать его во время просмотра. Подробнее ознакомиться с новыми возможностями фирменных приложений и сервисов можно в блоге компании. Открыть запись

Со всеми этими ковидами, спец операциями и прочим, совсем упустил из виду то что в декабре прошлого года была статья про анонс centos 9 stream. Вот ее я сейчас и выложу тут Проект CentOS официально объявил о доступности дистрибутива CentOS Stream 9, который используется в качестве основы для формирования дистрибутива Red Hat Enterprise Linux 9 в рамках нового более открытого процесса разработки. CentOS Stream относится к непрерывно обновляемым дистрибутивам и позволяет раньше получить доступ к пакетам, развиваемым для будущего выпуска RHEL. Сборки подготовлены для архитектур x86_64, Aarch64 и ppc64le (IBM Power 9+). Дополнительно заявлена поддержка архитектуры IBM Z (s390x Z14+), но сборки для неё ещё не доступны. CentOS Stream позиционируется как upstream-проект для RHEL, дающий возможность сторонним участникам контролировать подготовку пакетов для RHEL, предлагать свои изменения и влиять на принимаемые решения. Раньше в качестве основы для новой ветки RHEL использовался снапшот одного из выпусков Fedora, который дорабатывался и стабилизировался за закрытыми дверями, без возможности контролировать ход разработки и принимаемые решения. В процессе разработки RHEL 9 на основе снапшота Fedora 34 при участии сообщества сформирована ветка CentOS Stream 9, в которой проводится подготовительная работа и формируется базис для новой значительной ветки RHEL. Отмечается, что для CentOS Stream публикуются те же обновления, что подготовлены для ещё не выпущенного будущего промежуточного выпуска RHEL и основной целью разработчиков является достижение уровня стабильности CentOS Stream идентичного с RHEL. До того как пакет будет предложен в CentOS Stream он проходит через различные системы автоматического и ручного тестирования, и публикуется только если его уровень стабильности признаётся отвечающим стандартам качества пакетов, готовых для публикации в RHEL. Одновременно с CentOS Stream подготовленные обновления помещаются в ночные сборки RHEL. Основные изменения в CentOS Stream 9 по сравнению с прошлой значительной веткой: Обновлено системное окружение и сборочный инструментарий. Для сборки пакетов задействован GCC 11. Стандартная Си-библиотека обновлена до glibc 2.34. Пакет с ядром Linux построен на базе выпуска 5.14. Пакетный менеджер RPM обновлён до версии 4.16 с поддержкой контроля целостности через fapolicyd. Завершена миграция дистрибутива на Python 3. По умолчанию предложена ветка Python 3.9. Поставка Python 2 прекращена. Рабочий стол основан на GNOME 40 (в RHEL 8 поставлялся GNOME 3.28) и библиотеке GTK 4. В GNOME 40 виртуальные рабочие столы в обзорном режиме (Activities Overview) переведены на горизонтальную ориентацию и отображаются в виде непрерывно прокручиваемой слева направо цепочки. На каждом рабочем столе, показываемом в обзорном режиме, наглядно представлены имеющиеся окна, для которых применяется динамическое панорамирование и масштабирование при взаимодействии пользователя. Обеспечен бесшовный переход между списком программ и виртуальными рабочими столами. В GNOME задействован обработчик power-profiles-daemon, предоставляющий возможность переключения на лету между режимом экономии энергии, режимом сбалансированного энергопотребления и режимом максимальной производительности. Все звуковые потоки переведены на мультимедийный сервер PipeWire, который теперь используется по умолчанию вместо PulseAudio и JACK. Использование PipeWire позволяет в обычной настольной редакции предоставить возможности профессиональной обработки звука, избавиться от фрагментации и унифицировать звуковую инфраструктуру для разных применений. По умолчанию скрыто загрузочное меню GRUB, если RHEL является единственным установленным в системе дистрибутивом и если прошлая загрузка прошла без сбоев. Для показа меню во время загрузки достаточно удерживать клавишу Shift или несколько раз нажать клавишу Esc или F8. Из изменений в загрузчике также отмечается размещение файлов конфигурации GRUB для всех архитектур в одном каталоге /boot/grub2/ (файл /boot/efi/EFI/redhat/grub.cfg теперь является символической ссылкой на /boot/grub2/grub.cfg), т.е. одну и ту же установленную систему можно загружать как с использованием EFI, так и BIOS. Компоненты для поддержки различных языков вынесены в пакеты langpacks, позволяющие варьировать уровень устанавливаемой языковой поддержки. Например, в пакете langpacks-core-font предлагаются только шрифты, в langpacks-core - локаль для glibc, базовый шрифт и метод ввода, а в langpacks - переводы, дополнительные шрифты и словари для проверки правописания. Обновлены компоненты для обеспечения безопасности. В дистрибутиве задействована новая ветка криптографической библиотеки OpenSSL 3.0. По молчанию включены более современные и надёжные криптографические алгоритмы (например, запрещено применение SHA-1 в TLS, DTLS, SSH, IKEv2 и Kerberos, отключены TLS 1.0, TLS 1.1, DTLS 1.0, RC4, Camellia, DSA, 3DES и FFDHE-1024). Пакет OpenSSH обновлён до версии 8.6p1. Cyrus SASL переведён на бэкенд GDBM вместо Berkeley DB. В библиотеках NSS (Network Security Services) прекращена поддержка формата DBM (Berkeley DB). GnuTLS обновлён до версии 3.7.2. Значительно повышена производительность SELinux и снижено потребление памяти. В /etc/selinux/config убрана поддержка настройки "SELINUX=disabled" для отключения SELinux (указанная настройка теперь только отключает загрузку политик, а для фактического отключения функциональности SELinux теперь требуется передача ядру параметра "selinux=0"). Добавлена экспериментальная поддержка VPN WireGuard. По умолчанию запрещён вход по SSH под пользователем root. Объявлены устаревшими инструменты управления пакетным фильтром iptables-nft (утилиты iptables, ip6tables, ebtables и arptables) и ipset. Для управления межсетевым экраном теперь рекомендуется использовать nftables. В состав включён новый демон mptcpd для настройки MPTCP (MultiPath TCP), расширения протокола TCP для организации работы TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Использование mptcpd даёт возможность настроить MPTCP без использования утилиты iproute2. Удалён пакет network-scripts, для настройки сетевых соединений следует использовать NetworkManager. Поддержка формата настроек ifcfg сохранена, но NetworkManager по умолчанию использует формат на основе файла keyfile. В состав включены новые версии компиляторов и инструментов для разработчиков: GCC 11.2, LLVM/Clang 12.0.1, Rust 1.54, Go 1.16.6, Node.js 16, OpenJDK 17, Perl 5.32, PHP 8.0, Python 3.9, Ruby 3.0, Git 2.31, Subversion 1.14, binutils 2.35, CMake 3.20.2, Maven 3.6, Ant 1.10. Обновлены серверные пакеты Apache HTTP Server 2.4.48, nginx 1.20, Varnish Cache 6.5, Squid 5.1. Обновлены СУБД MariaDB 10.5, MySQL 8.0, PostgreSQL 13, Redis 6.2. Для сборки эмулятора QEMU по умолчанию задействован Clang, что позволило применить в гипервизоре KVM некоторые дополнительные механизмы защиты, такие как SafeStack для защиты от методов эксплуатации на основе возвратно-ориентированного программирования (ROP - Return-Oriented Programming). В SSSD (System Security Services Daemon) повышена детализация логов, например, к событиям теперь прикрепляется время завершения задачи и отражается поток аутентификации. Добавлены функции поиска для анализа проблем с настройками и производительностью. Расширена поддержка IMA (Integrity Measurement Architecture) для проверки целостности компонентов операционной системы по цифровым подписям и хэшам. По умолчанию задействована единая унифицированная иерархия cgroup (cgroup v2). Сgroups v2 можно использовать, например, для ограничения потребления памяти, ресурсов CPU и ввода/вывода. Ключевым отличием cgroups v2 от v1 является применение общей иерархии cgroups для всех видов ресурсов, вместо раздельных иерархий для распределения ресурсов CPU, для регулирования потребления памяти и для ввода/вывода. Раздельные иерархии приводили к трудностям организации взаимодействия между обработчиками и к дополнительным затратам ресурсов ядра при применении правил для процесса, упоминаемого в разных иерархиях. Добавлена поддержка синхронизации точного времени на базе протокола NTS (Network Time Security), который использует элементы инфраструктуры открытых ключей (PKI) и позволяет использовать TLS и аутентифицированное шифрование AEAD (Authenticated Encryption with Associated Data) для криптографической защиты взаимодействия клиента и сервера по протоколу NTP (Network Time Protocol). NTP-сервер chrony обновлён до версии 4.1. Обеспечена экспериментальная поддержка KTLS (реализация TLS на уровне ядра), Intel SGX (Software Guard Extensions), DAX (Direct Access) для ext4 и XFS, поддержка AMD SEV и SEV-ES в гипервизоре KVM. Параллельно продолжает развиваться ветка CentOS Stream 8, которая используется при подготовке новых выпусков RHEL 8.x и рекомендована для перевода систем, использующих классический дистрибутив CentOS 8.x, сопровождение которого будет прекращено в конце месяца. Для перехода на CentOS Stream достаточно установить пакет centos-release-stream dnf install centos-release-stream и выполнить команду dnf update Сопровождение ветки CentOS Stream 8 будет осуществляться до 31 мая 2024 года, а поддержка классического CentOS 7.x завершится 30 июня 2024 года. В качестве альтернативы пользователи также могут перейти на дистрибутивы, продолжившие развитие ветки CentOS 8: AlmaLinux (скрипт для миграции), Rocky Linux (скрипт для миграции), VzLinux (скрипт для миграции) или Oracle Linux (скрипт для миграции). Кроме того, компания Red Hat предоставила возможность (скрипт для миграции) бесплатного использования RHEL в организациях, развивающих открытое ПО, и в окружениях индивидуальных разработчиков, насчитывающих до 16 виртуальных или физических систем. Открыть запись

После очередного обновления, очередная проблема. В общем перестали открываться офисные документы непосредственно в веб версии облака. Лечится просто, нужно добавить параметр 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 Открыть запись

Если вы увидели такое сообщение на сервере, значит пришло время посмотреть и оценить сетевую нагрузку на сервер. Посмотреть текущее состояние буферов можно так: # 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 Если же после этого тюнинга продолжают появляться такие ошибки — попробуйте либо увеличить значения либо поставить всё же нормальную сетевую карточку. Открыть запись

Ну нельзя обновить 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. Всё теперь ошибка должна уйти. Открыть запись

Ненужные заголовки Посмотреть заголовки веб-сервера можно командой: curl -I https://yandex.ru/ или вы можете протестировать на сайте https://http.itsoft.ru Давайте для начала посмотрим на заголовки Яндекс и Google. [igor@new html]$ curl -I https://yandex.ru/ HTTP/1.1 200 Ok Accept-CH: Viewport-Width, DPR, Device-Memory, RTT, Downlink, ECT Accept-CH-Lifetime: 31536000 Cache-Control: no-cache,no-store,max-age=0,must-revalidate Content-Length: 178283 Content-Security-Policy: report-uri https://csp.yandex.net/csp?project=morda&from=morda.big.ru&showid=1587028014.80097.85411.54444&h=stable-morda-man-yp-628&csp=new&date=20200416&yandexuid=4225126811587028014;script-src 'self' 'unsafe-inline' https://an.yandex.ru https://yastatic.net https://yandex.ru https://mc.yandex.ru;img-src https://yabs.yandex.ru https://favicon.yandex.net https://*.strm.yandex.net https://auto.ru https://an.yandex.ru https://strm.yandex.ru https://www.maximonline.ru 'self' https://thequestion.ru https://www.kinopoisk.ru https://yastatic.net https://awaps.yandex.net https://avatars.mds.yandex.net https://*.verify.yandex.ru https://mc.yandex.ru https://leonardo.edadeal.io data: https://resize.yandex.net https://yandex.ru https://mc.admetrica.ru;frame-src 'self' https://mc.yandex.ru https://yandex.ru https://yastatic.net https://st.yandexadexchange.net https://yandexadexchange.net;font-src data: https://an.yandex.ru https://yastatic.net;object-src https://avatars.mds.yandex.net;connect-src https://mc.yandex.ru https://*.cdn.ngenix.net https://games.yandex.ru https://mc.admetrica.ru https://yandex.ru https://portal-xiva.yandex.net https://auto.ru https://*.strm.yandex.net https://strm.yandex.ru https://an.yandex.ru https://mobile.yandex.net https://frontend.vh.yandex.ru https://yabs.yandex.ru https://thequestion.ru https://yastat.net https://api.market.yandex.ru 'self' https://www.kinopoisk.ru https://yastatic.net https://zen.yandex.ru https://www.maximonline.ru wss://portal-xiva.yandex.net;style-src 'unsafe-inline' https://yastatic.net;media-src https://*.strm.yandex.net https://*.cdn.ngenix.net blob:;default-src https://yastatic.net https://yastat.net Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Apr 2020 09:06:54 GMT Expires: Thu, 16 Apr 2020 09:06:55 GMT Last-Modified: Thu, 16 Apr 2020 09:06:55 GMT P3P: policyref="/w3c/p3p.xml", CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI" Set-Cookie: yp=1589620015.ygu.1; Expires=Sun, 14-Apr-2030 09:06:54 GMT; Domain=.yandex.ru; Path=/ Set-Cookie: mda=0; Expires=Fri, 14-Aug-2020 09:06:54 GMT; Domain=.yandex.ru; Path=/ Set-Cookie: yandex_gid=213; Expires=Sat, 16-May-2020 09:06:54 GMT; Domain=.yandex.ru; Path=/ Set-Cookie: yandexuid=4225126811587028014; Expires=Sun, 14-Apr-2030 09:06:54 GMT; Domain=.yandex.ru; Path=/ Set-Cookie: i=8UHqdTah3NgMTINJMRGysflDelT4++ntHkOo85SGs6jvHhQQwro524Vs41lApmiL/8bGRA1ZejVwI0VKHneCfAPOMrg=; Expires=Sun, 14-Apr-2030 09:06:54 GMT; Domain=.yandex.ru; Path=/; Secure; HttpOnly X-Content-Type-Options: nosniff X-Frame-Options: DENY X-Yandex-Sdch-Disable: 1 [igor@new html]$ curl -I https://google.com/ HTTP/1.1 301 Moved Permanently Location: https://www.google.com/ Content-Type: text/html; charset=UTF-8 Date: Thu, 16 Apr 2020 09:08:18 GMT Expires: Sat, 16 May 2020 09:08:18 GMT Cache-Control: public, max-age=2592000 Server: gws Content-Length: 220 X-XSS-Protection: 0 X-Frame-Options: SAMEORIGIN Alt-Svc: quic=":443"; ma=2592000; v="46,43",h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,h3-T050=":443"; ma=2592000 [igor@new html]$ curl -I https://www.google.com/ HTTP/1.1 200 OK Date: Thu, 16 Apr 2020 09:08:35 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info." Server: gws X-XSS-Protection: 0 X-Frame-Options: SAMEORIGIN Set-Cookie: 1P_JAR=2020-04-16-09; expires=Sat, 16-May-2020 09:08:35 GMT; path=/; domain=.google.com; Secure Set-Cookie: NID=202=QkgyPv5FrpwHWbJGnSC83K1Sw4wysE4IMVNbd3z83iNOheMyVdbxmJJJE0AFbs9eNH9_iKGAzqdSv6iUqfr-erOlOIap7MmRMOkqQr87iS2y_FyII7AlV5Jx-K4JC2_b8F9xyJYxPpOL2hP-81Msp_HndCCDtGSi33l4gYZ3oXU; expires=Fri, 16-Oct-2020 09:08:35 GMT; path=/; domain=.google.com; HttpOnly Transfer-Encoding: chunked Alt-Svc: quic=":443"; ma=2592000; v="46,43",h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-Q048=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,h3-T050=":443"; ma=2592000 Accept-Ranges: none Vary: Accept-Encoding Также вам может пригодиться утилита telnet для просмотра заголовков локального сервера, если при обращении через доменное имя отвечает прокси-сервер nginx. [igor@new html]$ telnet 192.168.29.35 80 Trying 192.168.29.35... Connected to 192.168.29.35. Escape character is '^]'. HEAD / HTTP/1.1 HOST: itsoft.ru HTTP/1.1 200 OK Date: Tue, 05 May 2020 07:37:23 GMT Server: Apache/2.4.6 (CentOS) Cache-Control: max-age=604800, public Last-Modified: Mon, 27 Apr 2020 12:28:01 GMT Etag: 273b847f0f077f7680a9e0d54a43c8a6 Set-Cookie: a=1144943031; expires=Wed, 06-May-2020 07:37:34 GMT; path=/ X-Robots-Tag: noindex X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block; report=/feedback/http-csp-report.php Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Referrer-Policy: strict-origin Feature-Policy: autoplay 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; usb 'none'; vibrate 'none'; Content-Security-Policy-Report-Only: default-src 'self' data: *.googletagmanager.com *.google.com *.google-analytics.com *.googleapis.com *.gstatic.com *.doubleclick.net mc.yandex.ru api-maps.yandex.ru yastatic.net webvisor.com *.calltouch.ru *.usedesk.ru *.youtube.com *.ytimg.com 'nonce-counters' 'report-sample'; img-src https: data: blob: ; report-uri /feedback/http-csp-report.php Content-Type: text/html; charset=utf-8 Connection closed by foreign host. Что мы видим?! Нет у Яндекс никаких Server: ***, X-Powered-By: PHP/5.4.16 У Google есть Server. И у Гугла есть бесполезный редирект на домен третьего уровня www, который в России давно умер. Приятно, что здесь в России больше логики, чем на Западе. Никакого смысла сообщать какой у вас сервер и какое ПО (программное обеспечение) на нём используется нет. Наоборот, это вредно, т.к. если на сайте используется устаревшее ПО, то хакерам, автоматическим сканерам это только поможет во взломе вашего сайта. К таким заголовкам относится ещё Via, который могут добавлять прокси-сервера. Заголовок Server в Apache можно заменить перекомпилировав исходный код. Заголовок находится в файле include/ap_release.h. Но это сложно. Можно сократить информацию до просто Apache с помощью настройки ServerTokens Prod. Можно с помощью mod_security добавить в конфигурацию строку: SecServerSignature "ITSOFT" Чтобы убрать X-Powered-By в php.ini установите set expose_php = Off или в самом php-файле вызовите header_remove("X-Powered-By"); Expires: — лишён давно смысла, т.к. в RFC2616 page-127 записано: "Note: if a response includes a Cache-Control field with the max- age directive (see section 14.9.3), that directive overrides the Expires field." Cache-Control: max-age=0 переопределяет Expires. О кешировании мы поговорим отдельно ниже. Если expires отключён, то браузер отправляет "if-modified-since" и веб-сервер сможет ответить 304 Not Modified. ExpiresActive Off в .htaccess отключает заголовок Expires.' Сжатие контента Не все пользователи Интернет сидят на широполосных каналах. Может барахлить связь за счёт удаления от сотовой вышки, перегрузки каналов, большого расстояние, поэтому необходимо включить сжатие текстовых файлов. Картинки сжимать смысла нет, они и так уже сжаты. <ifModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/css text/javascript application/javascript application/x-javascript </ifModule> Заголовки для безопасности В настройки VirtualHost полезно добавить: Header set X-Frame-Options DENY Этот заголовок указывает браузеру, что сайт запрещено загружать в <frame>, <iframe>, <embed> or <object>. Это должно защитить пользователя от Clickjacking-атак. В настройки VirtualHost полезно ещё добавить: Header set X-Content-Type-Options nosniff Этот заголовок указывает браузеру, что не нужно пытаться понять какой контент пришёл и исполнить его. Например, не нужно выполнять javascript, который пришёл как plain\text. Подробнее см. тут. Следующая опция включит в браузере защиту и блокировку от XSS-атак. Header set X-XSS-Protection "1; mode=block" X-XSS-Protection: 1; report=https://itsoft.ru/r.php можно задать URL куда браузер отправит отчёт в случае обнаружения атаки. Очень важная настройка запрещает браузеру коннектиться к сайту по HTTP, т.е. обязывает использоваться только HTTPS. О важности SSL было рассказано в статье Зачем нужны SSL-сертификаты. Header set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" max-age указывает, что браузер должен запомнить данный заголовок на два года. includeSubDomains говорит, что это правило распространяется и на поддомены. preload — это гугловская фишка, в спецификации отсутствует, домен попадёт в базу, которую используют Chrome, Firefox и Safari. Опция Referrer-Policy указывает браузеру как отправлять HTTP_REFERER. Позволяет скрыть данные QUERY_STRING. Может принимать следующие значения: no-referrer — referer передаваться не будет, наверное, это для интравертов и каких-то секретных закрытых сайтов. no-referrer-when-downgrade — так браузер ведёт по-умолчанию. Полный URL с QUERY_STRING посылается в случаях перехода с HTTP→HTTP, HTTPS→HTTPS, HTTP→HTTPS. И не посылается при переходы из HTTPS→HTTP. origin — посылается только доменное имя. origin-when-cross-origin — посылается полностью при переходе по внутренним ссылкам, в прочих случаях посылается — только доменное имя. same-origin — посылается полностью при переходе по внутренним ссылкам, в прочих случаях не посылается. strict-origin — посылается только доменное имя, но только когда одинаковые протоколы HTTP→HTTP, HTTPS→HTTPS. strict-origin-when-cross-origin — посылается полностью при переходе по внутренним ссылкам, посылается только доменное имя, но только когда одинаковые протоколы HTTP→HTTP, HTTPS→HTTPS. Если в нет никакой секретной информации в QUERY_STRING и вам важно, чтобы другие могли перейти на страницу с параметрами, то пойдёт и значение по-умолчанию. Заголовок Feature-Policy указывает браузеру какими возможностями будет пользоваться сайт. К сожалению, некоторые значения можно переопределить в коде сайта. Например, так <iframe src="https://site.com" allow="vibrate">. Но заголовок сам по себе очень правильный. Мы все испытываем боль с приложениями на смартфоне, которые запрашивают привилегий доступа сильно больше, чем им реально нужно. Боль вызывают и сайты, которые хотят слать нотификации, спрашивают геолокацию, издают звуки и т.п., что нас раздражает. Сайт как и приложение смартфона должен заранее честно предупредить о том, какую информацию он собирается запрашивать, какую точно не будет запрашивать. Заголовок имеет следующий синтакис: Feature-Policy: <directive> <allowlist> allowlist может принимать одно или несколько из следующих значений разделённых пробелом: * — разрешено на данной странице и во всех iframe независимо оттого, какой сайт будет загружен в этих ифреймах; 'self' — разрешено на данной странице и во всех iframe, если в iframe загружена страница с нашего сайта; 'src' — только для iframe, только если в iframe загружена страница с нашего сайта; 'none' — запрещено, наиболее разумное значение для многих опций :), сайт должен по-минимуму раздражать посетителя; <origin(s)> — разрешает directive для определённого сайта или сайтов, сайты разделяются пробелами. Ниже идёт список возможных настроек: accelerometer — разрешено ли использовать документу Accelerometer интерфейс; ambient-light-sensor — может ли документ собирать информацию об освещённости AmbientLightSensor интерфейс$ autoplay — разрешено и автопроигрывание через HTMLMediaElement; battery — Navigator.getBattery(); camera — можно ли использовать камеру; display-capture — можно ли использовать getDisplayMedia(); document-domain — можно ли установить document.domain; encrypted-media — можно ли использовать Encrypted Media Extensions API (EME), Navigator.requestMediaKeySystemAccess(); execution-while-not-rendered — можно ли исполнять задачи в когда iframe невидим или display: none; execution-while-out-of-viewport — выполнять ли задачи для элементов за пределами отображаемой области; fullscreen — разрешено ли использовать Element.requestFullScreen(); geolocation — разрешено ли запрашивать геолокацию getCurrentPosition(); gyroscope — можно ли запрашивать положение устройства (смартфона); layout-animations — можно ли отображать послойную анимацию; legacy-image-formats — разрешено ли отображать изображения в устаревших форматах; magnetometer — Magnetometer интерфейс; microphone — микрофон; midi — Web MIDI API, воспроизведение музыки; navigation-override — https://www.w3.org/TR/css-nav/ oversized-images — можно ли отображать большие изображения, данная опция полезна на стадии отладки и тестирования сайта; payment — Payment Request API; picture-in-picture — можно ли проигрывать видео в режиме Picture-in-Picture; publickey-credentials — можно ли использовать Web Authentication API; sync-xhr — можно ли делать XMLHttpRequest requests; unoptimized-lossy-images — отображать ли неоптимизированные изображения; unsized-media — изображения, видео должны иметь размеры; usb — WebUSB API; vibrate — не поддерживается в браузерах; vr — WebVR API, но на смену ему уже идёт WebXR; wake-lock — можно ли использовать Wake Lock API, должно ли устройство переходить в режим энергосбережения xr-spatial-tracking — WebXR Device API. Некоторые возможности (accelerometer, ambient-light-sensor, battery, display-capture, encrypted-media, execution-while-not-rendered, execution-while-out-of-viewport, fullscreen, gyroscope, layout-animations, magnetometer, navigation-override, picture-in-picture, publickey-credentials, vr, wake-lock, xr-spatial-tracking ) вообще непонятно зачем ограничивать. Следующие опции полезно отключить, чтобы показать, что мы не вторгаемся в личное пространство посетителя и ничего не навязываем ему: autoplay, camera, geolocation, gyroscope, magnetometer, microphone, midi, payment, usb, vibrate. Header set Feature-Policy "autoplay 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; usb 'none'; vibrate 'none';" Для отладки и тестирования сайта полезными могут быть следующие опции: legacy-image-formats, oversized-images, unoptimized-lossy-images, unsized-media. Но на продакшене их не стоит использовать. Header set Feature-Policy "unsized-media 'none'; oversized-images 'none'; unoptimized-lossy-images 'none'; unoptimized-lossless-images 'none';" Заголовок Content Security Policy (CSP) это дополнительный уровень безопасности, который помогает обнаруживать и смягчать некоторые типы атак, включая межсайтовый скриптинг (XSS) и data injection атак. Данный заголовок на самом деле не только защищает от исполнения встроенного JS-кода хакерами, но главным образом дисциплинирует разработчиков не разбрасывать JS-код где попало по тексту HTML-документа, не встраивать его в HTML-теги, не использовать eval(), а хранить javascript упорядоченно в подключаемых библиотеках JS-файлов. Тем самым реализуется полное разделение HTML и javascript, и мы жёстко запрещаем плохие практики разработки. Также мы уменьшаем зависимость нашего сайта от контента на других сайтах. Неприятно же когда на странице на отображается картинка, не исполняется JS, не отображаются шрифты, по причине того, что они была подгружены с другого сайта, а теперь их там удалили. Далее рассмотрим примеры возможных настроек. Content-Security-Policy: default-src 'self' — подгрузка файлов только с домена самого сайта, даже с поддоменов нельзя. Content-Security-Policy: default-src 'self' *.trusted-site.ru — подгрузка файлов только с домена самого сайта и с поддоменов указанного сайта. Content-Security-Policy: default-src 'self'; img-src *; media-src mysite.ru mysite.org; script-src trusted-lib.com — подгрузка файлов с домена самого сайта, картинок с любых сайтов (это уже плохая практика), картинок и видео с сайтов mysite.ru mysite.org, скрипты можно загружать с сайта trusted-lib.com. Content-Security-Policy: default-src https://itsoft.ru — подгрузка файлов только с указанного домена и обязательно по протоколу https. Content-Security-Policy: default-src 'self' *.oursite.ru; img-src * — подгрузка файлов только с домена самого сайта и поддменов *.oursite.ru, картинок откуда угодно. Content-Security-Policy: default-src 'self'; report-uri https://itsoft.ru/report-csp.php — указывается скрипт, куда браузер будет отправлять отчёты о нарушении правил. Отчёт будет отправлен методом POST в формате JSON. В нашем скрипте можно просто перенаправить этот отчёт в почту или Slack разработчикам. На первое время можно задать правила в заголовке Content-Security-Policy-Report-Only, чтобы получать только отчеты. Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://itsoft.ru/report-csp.php Список возможных директив: default-src script-src object-src style-src img-src media-src frame-src font-src connect-src Чтобы запретить использование объектов нужно добавить object-src 'none'. Для script-src можно использовать значение unsafe-inline и unsafe-eval. Это разрешит использование встроенных скриптов, ухудшит дисциплину разработчиков, гарантирует бардак в коде. Для style-src можно использовать unsafe-inline. Лучше эти значения не использовать для новых проектов. Content-Security-Policy: upgrade-insecure-requests — это аналог Strict-Transport-Security. Заголовки Last-Modified и Content-Length Заголовки Last-Modified и Content-Length сообщаю когда документ был изменён последний раз и его размер. Поисковые роботы и браузеры отправляют в запросе заголовок If-Modified-Since, на который веб-сервер может либо выдать новую страницу либо 304 Not Modified. Для статических файлов эти параметры определяются легко. Content-Type: image/png Content-Length: 5922 Last-Modified: Mon, 27 Jan 2020 10:48:16 GMT Сложнее с динамическими файлами, например с php. ETag взаимосвязан с датой последней модификации и размером содержимого. Поэтому всё же определять эти значения придётся. Во всех инструкциях по настройке кеширования сайта, которые нам удалось прочитать, этому вопросу не уделялось внимание. Предполагалось, что дата последней модификации известна. Однако это не так. И это очень непростой вопрос. Проблема в том, что дата последней моификации файла зависит от всех подключаемых php-файлов, от данных в базе данных, от заголовков запроса браузера, кук, IP-адреса посетителя, курсов валют, времени, сторонних сервисов. Для php можно использовать следующий код, который выдаст дату последней модификации всех подключаемых файлов: <?php function getLastModified() { $all = get_included_files(); $all = array_filter($all, "is_file"); $lms = array_map('filemtime', $all); $lm = max($lms); return $lm; } ?> Может изменяться сам код php-файла, а данные и html-код которые он выдаёт могут не измениться. В этом случае неправильно говорить, что Last-Modified изменился. Но для простоты можно считать, что любое изменение файла ведёт к изменению Last-Modified. Для данных мы должны ориентироваться на дату изменения данных в строке таблицы. Эта задача может быть нетривиальной для страниц, где отображается множество данных из разных таблиц. Но если страница отображает одну сущность, например, конкретную новость, статью, счёт, платёж, то там дата последней модификации известна. Для страниц, где собирается множество данных из разных таблиц нужно иметь таблицу в которой lastmodified соответствующей строки будет обновляться триггером. Можно ориентироваться на хеш от выдаваемых данных. Если хеш md5 изменился, то меняем Last-Modified. Эту задачу лучше всего поручить проксирующему серверу Nginx. Для проверки ответов веб-сервер вы можете испоьзовать следующие команды: curl -I --header 'If-Modified-Since: Mon, 30 Apr 2029 18:13:12 GMT' https://itsoft.ru curl -I --header 'If-None-Match: "a49f2da878be351c6c73a1ec0524d8ea"' https://itsoft.ru curl -I --header 'Accept-Encoding: gzip' https://itsoft.ru Заголовки для кеширования Когда веб-сервер отдаёт какой-нибудь файл: картинку, css, js или контент страницы, то он должен сказать сколько можно хранить эти данные в кеше. Картинки можно хранить там вечно, они никогда не изменяются. Многие любят выдавать запрет на кеширование в виде заголовков: Cache-Control: no-cache,no-store,max-age=0,must-revalidate Expires: -1 Expires: Thu, 19 Nov 1981 08:52:00 GMT Pragma: no-cache На самом деле, смысла в этом никакого нет для большинства данных, только нагрузка на сервер. И не надо бояться сказать, что файл или страницу сайта можно закешировать. Во-первых, потому что браузер при следующем обращении к этому контенту при условии, что время хранения кеша просрочено спросит: "а не изменился ли ресурс с момента последнего моего запроса". И если не изменился, то веб-сервер должен вернуть заголовок 304 Not Modified и не отправлять запрашиваемый файл. Во-вторых, пользователь всегда может нажать обновить страницу и принудительно послать запрос к серверу не уточняя изменился ресурс или нет. Важно только правильно определить время хранения кеша. В решение этого вопроса можно исходить из того как часто обновляются данные и насколько это важные данные. Что случится, если посетитель увидит обновление с опозданием. Какое это разумное опоздание? Подавляющее большинство страниц в интернете чаще умирает, чем обновляется. Обновляются ленты новостей, а страница с конкретной новостью живёт вечно. Поэтому для подобных страниц можно смело выставить время жизни веша сутки или неделю, т.е. то разумное время в которое посетитель может вернуться на эту страницу или ваш сайт. Итак, давайте рассмотрим как браузер спросит не изменился ли запрашиваемый ресурс. Для этого есть два варианта. Первый — отправить в запросе If-Modified-Since с датой предыдущего запроса. Второй — отправить в запросе If-None-Match с меткой ETag, которую он получил при предыдущем обращении. При ответе веб-серве посылает следующие заголовки: ETag: "1722-59d1cd83fc41f" Cache-Control: max-age=31536000, public ETag — является уникальной меткой, а Cache-Control сообщает можно ли хранить кеш на промежуточных прокси-сервера и сколько его можно хранить. Итак, самый последний вопрос в который мы упёрлись — это сколько можно хранить кеш. На этот вопрос мы должны ответить в зависимости от контента и конкретных страниц нашего сайта. Для статических файлов max-age=31536000 в один год представляется вполне разумным. При этом сами файлы нужно либо подключать с параметром времени последней модификации либо изменять их имя после модификации. Для вывода параметра последней модификации файла можете использовать функцию: function printFilenameWithTimestamp($filename) { print "$filename?t=" . date('U', filemtime($_SERVER['DOCUMENT_ROOT'] . $filename)); } В .htaccess укажите: Header set Cache-Control "max-age=31536000, public" В заголовой php-скрипта добавьте следующий код если он не обращается к базе и не зависит от других сервисов. $last_modified = gmdate('D, d M Y H:i:s', getlastmod()); $etag = md5($last_modified); if($_SERVER['REQUEST_METHOD']=='GET') { if (isset($_SERVER['HTTP_IF_NONE_MATCH']) && ($_SERVER['HTTP_IF_NONE_MATCH'] == $etag)) { header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified'); exit(); } if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE']) && strtotime(substr($_SERVER['HTTP_IF_MODIFIED_SINCE'], 5))>=strtotime("$last_modified GMT")) { header($_SERVER['SERVER_PROTOCOL'] . ' 304 Not Modified'); exit; } } header('Cache-Control: max-age=604800, public'); header("Last-Modified: $last_modified GMT"); header("Etag: $etag"); Vary: Accept-Encoding Vary: Accept-Encoding по сути обязательный заголовок, т.к. сейчас все веб-серверы поддерживают свжатие контента. Способ сжатия зависит от поддерживаемых браузером способов, которые браузер передаёт в заголовке Accept-Encoding. Но скорее всегого сервер добавит этот заголовок автоматически получив в запросе Accept-Encoding: gzip, deflate, br. Итог [root@localhost ~]# curl -I https://itsoft.ru HTTP/1.1 200 OK Server: nginx/1.16.0 Date: Tue, 05 May 2020 05:57:34 GMT Content-Type: text/html; charset=utf-8 Connection: keep-alive Keep-Alive: timeout=200 Cache-Control: max-age=604800, public Last-Modified: Wed, 01 Apr 2020 18:49:15 GMT Etag: a49f2da878be351c6c73a1ec0524d8ea Set-Cookie: a=1961012078; expires=Wed, 06-May-2020 05:57:34 GMT; path=/; secure; HttpOnly X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block; report=/feedback/http-csp-report.php Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Referrer-Policy: same-origin Feature-Policy: autoplay 'none'; camera 'none'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none'; usb 'none'; vibrate 'none'; Content-Security-Policy-Report-Only: default-src 'self' data: *.googletagmanager.com *.google.com *.google-analytics.com *.googleapis.com *.gstatic.com *.doubleclick.net mc.yandex.ru api-maps.yandex.ru yastatic.net webvisor.com *.calltouch.ru *.usedesk.ru *.youtube.com *.ytimg.com 'nonce-counters' 'report-sample'; img-src https: data: blob: ; report-uri /feedback/http-csp-report.php X-Frame-Options: SAMEORIGIN Источник Открыть запись

Под конец и без того нелегкого 2020 года Red Hat преподнесла всем поклонникам CentOS весьма неожиданный «подарок», объявив о радикальном сокращении EOL восьмой версии дистрибутива и последующем отказе от дальнейшего развития проекта. Пользователи операционной системы, на протяжении многих лет занимавшей третье место по популярности в мире, оказались на распутье. Что выбрать в такой ситуации? Стать «вечным бета-тестером», перейдя на CentOS Stream? Выделить бюджет на покупку лицензии Red Hat Enterprise Linux? Или быть может попробовать одно из конкурирующих решений? Хроника пикирующего дистрибутива: зачем убили CentOS? В июле 2019 года руководство Red Hat объявило об официальном урегулировании всех формальностей, связанных с продажей бизнеса корпорации IBM. Финальная сумма сделки составила около 34 миллиардов долларов США, или $190 за каждую проданную акцию (при том, что на момент объявления о сделке бумаги торговались по $116). Как обычно и бывает в таких случаях, Red Hat клятвенно заверили сообщество, что присоединение к знаменитому IT-гиганту поможет привлечь дополнительные инвестиции и ресурсы, что даст возможность компании достичь новых вершин, и донести технологии Red Hat до еще более широкой аудитории, чем прежде. В свою очередь, лидеры разработки Fedora и CentOS поспешили заявить, что цели и модель управления проектами останутся неизменными, а Red Hat, как и ранее, продолжит активно участвовать в их развитии. И компания действительно сдержала свое слово, но… лишь наполовину. В начале декабря 2020 года компания объявила о прекращении поддержки CentOS — операционной системы, фактически являющейся бесплатной альтернативой Red Hat Enterprise Linux, великодушно предложив всем пользователям данного дистрибутива перейти на CentOS Stream. Больше всего эта новость ошарашила тех, кто уже успел мигрировать на CentOS 8: хотя поддержка восьмой версии операционной системы должна была завершиться лишь 31 мая 2029 года, первоначальный EOL ограничили 31 декабря 2021 года (то есть, обещанные 10 лет волшебным образом превратились в 2 года). Тем, кто использует CentOS 7, повезло значительно больше: сроки поддержки семерки оставили неизменными, так что операционная система продолжит получать критически важные апдейты до 2024 года. Впрочем, кто знает, что придет в голову Red Hat в ближайшем будущем? Согласно официальной позиции компании, модель взаимодействия между пользователями и разработчиками программного обеспечения, которую олицетворяет собой CentOS, в современных реалиях уже не актуальна. И CentOS Stream является на сегодняшний день наиболее оптимальным и сбалансированным дистрибутивом, сочетая в себе инновации Fedora и стабильность Red Hat Enterprise Linux. Именно стремясь удовлетворить потребности сообщества, Red Hat приняли решение всецело сосредоточиться на поддержке данной версии дистрибутива, сделав CentOS Stream «основным центром инноваций экосистемы RHEL». Однако сообщество подобную «заботу» не оценило: на фоне новостей о прекращении дальнейшего развития оригинального дистрибутива CentOS стал стремительно терять позиции, модераторы тематического сабреддита добавили к прежнему названию приписку «Corporate-driven (вместо «community-driven»), Not suitable for Enterprise», закрепив тред «RIP CentOS, 2004–2020», журнал ZDNet, принадлежащий CBS Interactive, открыто высказал мнение, что отказ от поддержки CentOS является ничем иным, как частью продвижения RHEL, в сети появился лэндинг довольно ехидного содержания centos.rip (создание которого, кстати, приписывают Oracle — главному конкуренту Red Hat, разрабатывающему собственный RH-based дистрибутив), а на change.org была опубликована петиция, авторы которой обратились к Red Hat с просьбой продолжить разработку CentOS в прежнем формате. Реакция Red Hat не заставила себя долго ждать: компания прислушалась к мнению сообщества, изменив правила использования Red Hat Enterprise Linux для разработчиков. Ранее в рамках программы Red Hat Developer действовало правило «один разработчик — одна лицензия», а сам дистрибутив можно было разворачивать только в локальном окружении. С 1 февраля 2021 года в программе могут участвовать целые команды, количество лицензий увеличилось с 1 до 16, к тому же новые условия EULA допускают установку ОС в инстансах публичных cloud-сервисов. Но, разумеется, только в целях разработки программного обеспечения: использование дистрибутива в продакшене обновленная лицензия по-прежнему не предусматривает. Таким образом Red Hat прозрачно намекнула, что не намерена отклоняться от ранее избранного курса, чего и следовало ожидать. Вполне очевидно, что несмотря на первоначальное обещание сохранить созданную компанией модель разработки и поддерживать сложившуюся вокруг ее проектов экосистему, IBM увидела в CentOS прямую угрозу продажам RHEL. Отказ же от старой доброй CentOS позволяет убить не то что двух, а сразу трех зайцев: Часть пользователей из числа представителей крупного бизнеса наверняка предпочтет перейти на RHEL, что обеспечит дополнительную прибыль; Те, кто рискнет мигрировать на CentOS Stream, пополнят ряды бета-тестеров, а это поможет эффективнее обкатывать новые технологии и быстрее выявлять уязвимости в новых версиях пакетов; Освободившиеся ресурсы можно использовать для дальнейшего развития Red Hat Enterprise Linux, оставаясь в рамках прежнего бюджета на разработку. Мотивы IBM понятны: даже для такой крупной корпорации 34 миллиарда долларов — очень серьезная сумма, а предпринятые шаги помогут частично компенсировать затраты на покупку Red Hat уже в обозримом будущем за счет крупных корпоративных заказчиков. Но что же делать небольшим компаниям, которые попросту не могут себе позволить приобретение коммерческой лицензии RHEL? Куда пойти, куда податься? Древняя народная мудрость гласит: «Лучший Linux — тот, в котором разбирается ваш системный администратор». И с этим действительно трудно поспорить: хотя в основе UNIX-подобных операционных систем лежат одни и те же принципы, каждый дистрибутив имеет свои особенности, сильные и слабые стороны, знание которых во многом определяет эффективность работы с созданной на их основе IT-инфраструктурой. Если же ваша компания использует определенную операционную систему достаточно долго, у вас наверняка написаны сотни, а то и тысячи скриптов, заточенных под выбранную программную среду и являющихся неотъемлемой частью внутренних корпоративных сервисов, полное переписывание которых чревато серьезными финансовыми и временными затратами, не говоря уже о потенциальных убытках в том случае, если что-то пойдет не так. В свете этого наиболее логичной стратегией становится миграция на дистрибутив, максимально близкий по архитектуре к исходному. И в случае с CentOS выбор оказывается не так уж и мал. CentOS Stream Пользователям CentOS 8 Red Hat предлагает мигрировать на CentOS Stream. Всерьез рассматривать перспективы использования данного дистрибутива в продакшене не получается, ведь если даже в релизные версии операционных систем периодически просачиваются баги и уязвимости, зачастую носящие критический характер, то что говорить о непрерывно обновляемой бете? Хотя чисто технически «влиться в Поток» предельно просто. Для этого достаточно выполнить в терминале всего три команды: Подключаем репозиторий CentOS Stream # dnf install centos-release-stream Указываем новый репозиторий в качестве дефолтного # dnf swap centos-{linux,stream}-repos Синхронизируем установленные пакеты # dnf distro-sync Поскольку отличия пакетной базы CentOS 8 и CentOS Stream на сегодняшний день минимальны, процедура миграции с вероятностью 99% пройдет безболезненно. Тем не менее, если речь идет не о нуждах разработки, а о комплексной IT-инфраструктуре, на которой завязана львиная доля бизнес-процессов предприятия, стоит присмотреться к чему-то более надежному. Например, к тому же Oracle Linux. Oracle Linux Фактически Oracle Linux представляет собой клон RHEL. Данная операционная система полностью совместима с CentOS на уровне двоичного кода. К тому же в декабре 2020 года компания Oracle представила удобный скрипт для миграции продакшн-систем, автоматически заменяющий специфичные для CentOS пакеты на эквивалентные из поставки Oracle Linux, и поддерживающий 6-ю, 7-ю и 8-ю версии ОС. Интересной особенностью данного скрипта является функция резервного копирования затронутых файлов, так что при возникновении любых проблем вы сможете откатить все внесенные изменения. Разумеется, не могло обойтись и без некоторых ограничений: Скрипт обрабатывает только основные репозитории операционной системы. Подключение внешних репозиториев вроде EPEL для получения обновлений ранее установленных пакетов придется производить вручную; Совместимость с пакетами, полученными из сторонних репозиториев, не гарантируется. В частности, Oracle указывает на возможные конфликты, вызванные наличием файла /etc/oracle-release; После миграции могут перестать работать пакеты, использующие сторонние модули ядра и/или модули ядра с закрытым исходным кодом (к таковым относятся, например, коммерческие антивирусные приложения); Скрипт не поддерживает системы, в которых используются сторонние инструменты централизованного управления наподобие Foreman, Spacewalk или Uyni. Впрочем, если сравнивать автоматическую миграцию с помощью готового скрипта на аналогичный дистрибутив с переездом на принципиальную иную ОС в «ручном режиме», все перечисленное покажется не более, чем незначительными неудобствами. Ко всему прочему, Oracle Linux обладает рядом важных преимуществ: Дистрибутив полностью бесплатен и может использоваться в коммерческих проектах без каких-либо ограничений или дополнительного лицензирования; Бесплатная и коммерческая версии Oracle Linux отличаются друг от друга только наличием технической поддержки от специалистов корпорации, сами же дистрибутивы полностью идентичны и используют единый репозиторий, одновременно получая все выходящие обновления; Изменения в ядре Unbreakable Enterprise Kernel публикуются в Git-репозитории с разделением на отдельные патчи и детализацией внесенных изменений, что повышает прозрачность и предсказуемость поведения системы при ее обновлении; Oracle Linux поддерживает высокопроизводительную сетевую файловую систему Oracle Cluster File System 2 (OCFS2), позволяющую создавать разделяемые хранилища, используемые одновременно несколькими Linux-системами, что делает Oracle Linux весьма удобной для построения масштабируемых веб-серверов, кластерных баз данных, виртуализации и других аналогичных сценариев. В свете всего перечисленного переход на Oracle Linux кажется наиболее правильным и логичным шагом. Однако если рассматривать перспективы миграции на данный дистрибутив в историческом контексте, все становится уже совсем не так однозначно. Дело в том, что и Oracle Linux, и CentOS в их современном виде являются плодом ожесточенной конкуренции между Red Hat и Oracle. Еще в октябре 2006 года, на фоне анонса инициативы Unbreakable Linux, в рамках которой Oracle фактически предложила пользователям копию RHEL за вдвое более низкую цену, акции Red Hat упали на 28%, что вынудило компанию перейти к активным действиям. Ответным шагом стал перевод RHEL 6 на монолитное ядро, что фактически блокировало возможность использования наработок компании в сторонних дистрибутивах, сделав анализ примененных патчей излишне трудоемким. Технический директор Red Hat, Брайан Стивенс, тогда заявил: «Данный поступок является вынужденной реакцией на участившиеся случаи недобросовестной конкуренции со стороны предприятий, стремящихся выстроить собственных бизнес на основе простого копирования RHEL». Реакция Oracle не заставила себя долго ждать: компания открыла неограниченный доступ ко всем обновлениям Oracle Linux, включая errata и оперативные патчи безопасности, сформировав Git-репозиторий для отслеживания всех изменений, и начав весьма успешно переманивать пользователей CentOS, агитируя их переходить на бесплатный продукт enterprise-класса. После этого Red Hat не оставалось ничего, кроме как возглавить разработку CentOS: в январе 2014 года компания объявила о начале прямого финансирования проекта, получив права на владение всеми товарными знаками. Данный шаг позволил устранить основной недостаток операционной системы — непредсказуемость процесса разработки. Инциденты вроде неожиданной пропажи Лэнса Дэвиса, одного из основателей проекта, и многомесячные перерывы в выпуске обновлений не добавляли CentOS популярности, заставляя сообщество склоняться в сторону более надежной альтернативы. Устранив перечисленные риски, Red Hat поставила под сомнение целесообразность использования Oracle Linux: и правда, в чем смысл работать с «клоном», если можно получить качественный, полностью бесплатный продукт от создателей оригинальной RHEL, что называется, из первых рук? На протяжении последующих 6 лет в противостоянии Red Hat и Oracle сохранялся паритет. Теперь же, когда столь сильный конкурент сошел с дистанции, дальнейший вектор развития Oracle Linux становится непредсказуем. Можно с уверенностью утверждать, что ближайшие 4–6 лет политика компании в отношении лицензирования операционной системы останется неизменной: сейчас для Oracle куда важнее расширить инсталляционную базу за счет бывших пользователей CentOS, нежели получить сиюминутную прибыль. В отсутствие же сильного конкурента корпорация может начать, по примеру Red Hat, обкатывать обновления на пользователях бесплатной версии ОС. Подобный сценарий вполне реален, если только в ближайшие годы на рынке не появится достойная альтернатива. AlmaLinux И таковой вполне может оказаться AlmaLinux. Появление данного проекта стало ответной реакцией CloudLinux на преждевременное прекращение поддержки CentOS 8. Компания планирует выделять на разработку операционной системы по 1 миллиону долларов в год из собственных доходов. AlmaLinux следует базовым принципам CentOS: дистрибутив формируется путем пересборки пакетной базы RHEL, сохраняя бинарную совместимость с оригинальной операционной системой, что позволяет пользователям CentOS 8 легко и безболезненно перевести IT-инфраструктуру на новые рельсы. В дальнейшем развивать проект планируется с привлечением сообщества, при этом будет использоваться модель управления, аналогичная той, что применяется при разработке Fedora. Для этих целей создана отдельная некоммерческая организация AlmaLinux OS Foundation. Первый стабильный выпуск AlmaLinux увидел свет 30 марта этого года. Дистрибутив бесплатен для всех категорий пользователей, включая корпоративных. В настоящее время для загрузки доступны сборки для архитектуры x86_64, однако в скором времени разработчики обещают подготовить ARM-версии операционной системы. Дистрибутив полностью идентичен по функциональности с RHEL 8.3, которая лежит в его основе, за исключением отсутствия ряда специфических для Red Hat Enterprise Linux пакетов (например, redhat-*, insights-client и subscription-manager-migration*). CloudLinux обещает поддерживать текущую версию AlmaLinux до 2029 года. Как и в случае с Oracle Linux, для простой и прозрачной миграции с CentOS 8 разработчики операционной системы подготовили удобный автоматизированный скрипт. Если рассуждать о перспективах данного проектах, то AlmaLinux имеет неплохие шансы занять вакантное место CentOS, благо команда CloudLinux, насчитывающая на сегодняшний день более сотни IT-специалистов, обладает вполне достаточным опытом разработки и сопровождения RH-based проектов, ведь флагманский продукт компании основан на пакетной базе RHEL. Ребята уже наглядно продемонстрировали, на что способны, представив первый стабильный билд операционной системы спустя всего 4 месяца после анонса, и если так пойдет и дальше, они вполне смогут составить достойную конкуренцию Oracle. Rocky Linux В нашем списке Rocky Linux является наиболее неоднозначным кандидатом на замену CentOS. Хотя бы потому, что сам по себе продукт все еще не добрался до релиза, а значит и судить о его перспективности можно лишь опираясь на факты, известные о самих авторах инициативы и их партнерах. С первого взгляда все выглядит достаточно вкусно: Разработку Rocky Linux возглавляет компания Ctrl IQ — стартап основателя CentOS Грегори Курцера; Компания заручилась поддержкой инвесторов в лице венчурного фонда IAG Capital Partners и одного из крупнейших поставщиков гипермасштабируемых систем хранения данных OpenDrives, по итогам переговоров с которыми на разработку операционной системы удалось привлечь $4 млн; В число ключевых спонсоров проекта входят корпорация Amazon, предоставившая команде Ctrl IQ необходимые для разработки и сборки дистрибутива вычислительные мощности в облаке AWS, и MontaVista Software, имеющая более, чем 20-летний опыт разработки программного обеспечения с открытым исходным кодом, ориентированного на нужды корпоративных клиентов. Rocky Linux позиционируется, как полностью бесплатная RH-based операционная система, демонстрирующая уровень стабильности enterprise-класса и пригодная для использования в рабочих проектах. Согласно заявлению Курцера, новый дистрибутив, основанный на исходном коде RHEL, продолжит традиции оригинального CentOS, а его разработка останется полностью прозрачна для сообщества, которое и будет определять генеральный вектор развития проекта. При этом Ctrl IQ не рассматривает Rocky Linux в качестве источника дохода. Компания планирует зарабатывать на предоставлении корпоративным заказчикам инфраструктуры для высокопроизводительных вычислений «под ключ», направляя часть вырученных средств на базовые расходы по разработке и юридической поддержке проекта. Rocky Linux находится лишь в начале своего пути, поэтому говорить о надежности новой операционной системы пока еще рано. Как рано рассуждать и о том, насколько конкурентоспособным окажется бизнес Ctrl IQ, ведь из четырех компонентов технологического стека HPC в настоящее время можно «пощупать» лишь Warewulf — набор инструментов для управления высокопроизводительными кластерами Linux. Впрочем, ждать осталось совсем недолго: выход первого релиз-кандидата Rocky Linux запланирован на 30 апреля 2021 года. Время для принятия взвешенного решения все еще есть. Даже если вы используете CentOS 8, оставшиеся месяцы — вполне достаточный срок для того, чтобы определиться с выбором дистрибутива и спланировать стратегию миграции IT-инфраструктуры на новую платформу. Те же, кто остался на CentOS 7, имеют отличную возможность оценить, на что в действительности способны команды разработчиков AlmaLinux и Rocky Linux и сделать осознанный выбор в пользу той или иной операционной системы, опираясь не на обещания, а на реальные кейсы. Если же перечень используемого вами программного обеспечения ограничивается стандартными пакетами, входящими в состав практически каждого дистрибутива Linux, возможно есть смысл рассмотреть и иные альтернативы, например разрабатываемую сообществом Debian или Ubuntu, успешно развиваемую частной британской компанией Canonical на протяжении вот уже 16 лет и, на сегодняшний день являющуюся самой популярной UNIX-подобной операционной системой. Наши облачные серверы можно использовать для разработки и хостинга сайтов. Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации! Источник Открыть запись

Статья подойдёт и для 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 игнорирует её и записывает предупреждение в системный журнал, а ваш скрипт даже не срабатывает! Команда 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 Недостаток этого решения очевиден: Нужно всегда помнить эту команду. Если у пользователя нет задач в планировщике то мы получим сообщение «no crontab for vasua» и таких сообщений может быть десятки если у вас много пользователей — это неудобно. Вывод информации неудобно читать. Решение простое — создадим функцию 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 странице справочника есть упоминание, что: Файлы под /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?» Источник Открыть запись

Обновился nextcloud до версии 23. Апдейт вышел уже какое то время назад, но у меня только щас руки дошли до него. И как обычно это бывает после обновления не всё гладко. Nextcloud ошибка: «В базе данных отсутствуют некоторые индексы. Так как создание таких индексов может занять достаточно продолжительное время, оно должно быть запущено вручную. Решается всё просто. Нужно выполнить команду из под пользователя веб сервера. В моём случае это apache В консоли переходим в папку с файлами Nextcloud и прописываем следующее: sudo -u apache php occ db:add-missing-indices Вот и всё Открыть запись

У меня в виртуалке крутится старенький сервер с мускулем на 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 Вот и всё. Открыть запись

аыва

Наткнулся тут на пост о том как сделать из ПК приставку, и решил попробовать. На работе стоит более менее комп, всё думал что из него можно соорудить и для чего можно использовать. Вот кажется и придумал. Надо будет только джойстик прикупить И так. Для начала нам понадобится приложение playnite, которое можно скачать по этой ссылке. Устанавливаем После установки он сразу говорит что может запускать игры из разных сервисов, таких как GOG и Steam. Вот собственно список: Отмечаем нужные и жмём Next. Он автомато подгрузит необходимые плагины. Так же он предложит добавить игры, и авторизоваться сразу. Battle.net у меня почему то не захотел авторизовываться. EGS - тут не много сложнее. при авторизации на сайте, выдаст сообщение, из которого нужно будет скопировать sid {"redirectUrl":"https://epicgames.com/account/personal","authorizationCode":null,"sid":"a26c134da2ab5212m54c1cb37eea8986"} и подставить во всплывающее окно playnite. Только сделать нужно быстро. я так понял sid перестаёт работать через 1-2 минуты. Если не меньше. Для авторизации Steam ещё потребуется Api ключ. Но в приложении все кнопки прекрасно работают, и если нет проблем с вводом логина пароля - то и проблем с остальным не будет. Остальные подключились без проблем. После того как все подключено и авторизовано - запуститься приложение и начнём импортировать игры. Рекоменндую дождаться окончания импорта, т.к. после сохранения настроек, нужно будет перезапустить приложение. Теперь займёмся настройкой. Для начала включим русский язык. Для этого в верхнем левом углу жмакаем на оранжевый значек джойстига, и в низпадающем меню выбираем settings (ну или просто нажимаем F4). Так как этот комп больше ни для чего не будет использоваться то ставим ещё 2 галочки: запуск в полноэкранном режиме, и запуск при старте системы. После этого опять открываем меню (оранжевый джойстик в верхнем левом углу) и выбираем расширения. Если что то не авторизовалось - можно авторизовать, но меня на данный момент интересует внешний вид. Я выбрал xbox. Там есть ещё SteamDeck, PS5, GOG и так далее. В общем выбираем на свой вкус. После выбора - перезапускаем приложение. Вот и всё. Теперь после загрузки системы будет запускаться Playnite. Берём пару джойстиков, покупаем MK, Fifa и так далее и рубимся с друзьями/коллегами