All Activity - YA-HZ Jump to content

All Activity

This stream auto-updates

  1. Last week
  2. Под конец и без того нелегкого 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% скидку на первый месяц аренды сервера любой конфигурации! Источник
  3. Под конец и без того нелегкого 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% скидку на первый месяц аренды сервера любой конфигурации! Источник Открыть запись
  4. Earlier
  5. Статья подойдёт и для 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?» Источник
  6. Статья подойдёт и для 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?» Источник Открыть запись
  7. Обновился nextcloud до версии 23. Апдейт вышел уже какое то время назад, но у меня только щас руки дошли до него. И как обычно это бывает после обновления не всё гладко. Nextcloud ошибка: «В базе данных отсутствуют некоторые индексы. Так как создание таких индексов может занять достаточно продолжительное время, оно должно быть запущено вручную. Решается всё просто. Нужно выполнить команду из под пользователя веб сервера. В моём случае это apache В консоли переходим в папку с файлами Nextcloud и прописываем следующее: sudo -u apache php occ db:add-missing-indices Вот и всё
  8. Обновился nextcloud до версии 23. Апдейт вышел уже какое то время назад, но у меня только щас руки дошли до него. И как обычно это бывает после обновления не всё гладко. Nextcloud ошибка: «В базе данных отсутствуют некоторые индексы. Так как создание таких индексов может занять достаточно продолжительное время, оно должно быть запущено вручную. Решается всё просто. Нужно выполнить команду из под пользователя веб сервера. В моём случае это apache В консоли переходим в папку с файлами Nextcloud и прописываем следующее: sudo -u apache php occ db:add-missing-indices Вот и всё Открыть запись
  9. У меня в виртуалке крутится старенький сервер с мускулем на 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 Вот и всё.
  10. У меня в виртуалке крутится старенький сервер с мускулем на 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 Вот и всё. Открыть запись
  11. Наткнулся тут на пост о том как сделать из ПК приставку, и решил попробовать. На работе стоит более менее комп, всё думал что из него можно соорудить и для чего можно использовать. Вот кажется и придумал. Надо будет только джойстик прикупить И так. Для начала нам понадобится приложение 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 и так далее и рубимся с друзьями/коллегами
  12. ArcheRAWG

    Playnite

  13. Агенты! Добро пожаловать в нашу «Разведсводку» – серию самых свежих донесений о том, какие возможности и новшества появятся в The Division®2. Сегодня мы с удовольствием представляем вам совершенно новую возможность для развития вашего агента: богатый опыт. Ни для кого не секрет, что каждый агент хочет извлечь максимум из своего снаряжения. Для тщательной подготовки к бою порой требуется потратить немало времени и даже принять непростые решения. Новая игровая возможность станет гораздо понятнее, когда вы увидите ее в деле, а пока что мы постараемся объяснить в общих чертах, как она работает. ЧТО ТАКОЕ БОГАТЫЙ ОПЫТ? Богатый опыт – это новый способ повысить эффективность оружия, снаряжения и модулей навыков. Он позволит вам повышать класс снаряжения и напрямую увеличивать его базовые характеристики. Конечно, этот способ появится в дополнение к уже существующей системе создания и оптимизации предметов. Он просто даст вам еще одну возможность усилить ваше снаряжение. В ваш богатый опыт можно будет заглянуть на станции перекалибровки на операционной базе или в Гавани. Для него будет выделена отдельная вкладка. Как работает механика богатого опыта? Богатый опыт позволит вам повысить класс предмета, бренда или комплекта экипировки, тем самым увеличив его базовые характеристики – например, для оружия это будет урон. Вы сможете повысить класс предметов столько раз, сколько уровней богатого опыта у вас есть. Чтобы набирать уровни богатого опыта, вам нужно будет повышать свой рейтинг опытности, используя в бою предмет, бренд или комплект экипировки – или вкладывая ресурсы в их развитие. Получив максимальный рейтинг опытности для данного снаряжения, вы станете его знатоком. Важно отметить, что вы сможете повышать класс только тех предметов, брендов и комплектов экипировки, в которых вы знаток. С помощью этой механики мы хотим стимулировать игроков к экспериментам с различными версиями сборок и стилей игры, при этом не ущемляя тех, кто придерживается своих излюбленных вариантов. Теперь мы расскажем чуть более подробно об этой механике, а также о том, как ее применять. СОВМЕСТИМЫЕ ТИПЫ ПРЕДМЕТОВ Богатый опыт будет доступен для следующих типов предметов: Оружие (контрабандный АКМ, P416, Mk20 SSR спецназа США и т.д.) Бренды (Gila Guard, Alps Summit Armament, Walker, Harris & Co. и т.д.) Комплекты экипировки («Боевик», «Восьмерки и тузы», «Ярость охотника» и т.д.) Именные предметы («Окопная молитва», «Белая смерть», «Полый человек» и т.д.) Экзотические предметы («Госпожа Свобода», «Гремучник», система брони «Тихоходка» и т.д.) Модули навыков («Осколочная бомба-липучка», «Огнеметная турель», «Дрон-защитник» и т.д.) Фирменное оружие (арбалет эксперта по выживанию, огнемет K8-JetStream, реактивный гранатомет P-017 и т.д.) Развивая опытность для брендов или комплектов экипировки, вы одновременно развиваете опытность для всего совместимого снаряжения из этих брендов и комплектов. Важно отметить: чтобы начать развивать опытность в использовании того или иного предмета, сам этот предмет не нужен. На вкладке «Богатый опыт» на станции перекалибровки показаны все предметы, которые можно исследовать. После того как при обновлении игры будет добавлен новый контент, пул совместимых предметов станет больше, и вы сможете еще сильнее развить свой богатый опыт! Чем не причина искать новое снаряжение, введенное в новом сезоне, и пользоваться им? РАЗВИТИЕ ОПЫТНОСТИ В ИСПОЛЬЗОВАНИИ ПРЕДМЕТОВ Число очков, необходимое для получения максимального рейтинга опытности (10), зависит от качества и типа предмета. Повысить опытность можно тремя способами. Использовать предметы в бою и получать опыт за убийства врагов с помощью этих предметов. Получать опыт за убийства врагов с помощью совместимых предметов. Используя несколько предметов одного и того же бренда (или набора), вы сможете получить дополнительные очков опытности для этого бренда (набора). Дарить совместимые предметы. Можно будет дарить любые предметы, совместимые с тем предметом, для которого вы хотите развить опытность, – например, из того же бренда или того же комплекта экипировки. Дарить материалы. Для повышении опытности также можно будет использовать свои запасы материалов и валют. Пожертвовав редкие элементы, получите больше очков. Дарить предметы или материалы – хороший способ быстро набирать очки опытности, но развивать ее можно и пассивным способом: просто используя совместимые предметы при любой игровой активности. Проверить текущий рейтинг опытности для тех или иных предметов можно в любой момент в меню. Чтобы просмотреть все и узнать, каких предметов вам не хватает, загляните на станцию перекалибровки. УРОВЕНЬ БОГАТОГО ОПЫТА И ИСПОЛЬЗОВАНИЕ ПРЕДМЕТОВ Повышая рейтинг опытности использования различных предметов, вы также увеличиваете уровень богатого опыта агента. Чтобы получить новый уровень, вам потребуется набрать определенную сумму рейтингов опытности. Все данные о богатом опыте и опытности распространяются на всех персонажей учетной записи. На каждом новом уровне богатого опыта у игрока становится больше возможностей улучшить предмет с помощью материалов. Это работает почти как оптимизация, но вместо того чтобы увеличивать одну из характеристик до максимального значения, вы повышаете одну из базовых характеристик предмета. При этом повышается «класс» предмета. Однако обратите внимание, что улучшить таким образом предмет можно только в том случае, если вы достигли максимального рейтинга опытности в его использовании. Количество улучшений предмета равно уровню вашего богатого опыта. Улучшение предмета влияет на предметы, относящиеся к той же категории, что и он: Оружие - 1% для увеличения базового значения урона. Снаряжение - 1% для увеличения базового значения брони. Навыки - 1% для увеличения базового значения урона/лечения/длительности эффекта. Важная информация Текущие значения являются временными и в дальнейшем могут измениться в зависимости от общего баланса игры и результатов тестирования. Агенты могут и дальше набирать уровни богатого опыта, повышая опытность для всех доступных предметов. Когда в игре появляются новые предметы, максимальный уровень «Богатого опыта» тоже повышается.
  14. Агенты! Добро пожаловать в нашу «Разведсводку» – серию самых свежих донесений о том, какие возможности и новшества появятся в The Division®2. Сегодня мы с удовольствием представляем вам совершенно новую возможность для развития вашего агента: богатый опыт. Ни для кого не секрет, что каждый агент хочет извлечь максимум из своего снаряжения. Для тщательной подготовки к бою порой требуется потратить немало времени и даже принять непростые решения. Новая игровая возможность станет гораздо понятнее, когда вы увидите ее в деле, а пока что мы постараемся объяснить в общих чертах, как она работает. ЧТО ТАКОЕ БОГАТЫЙ ОПЫТ? Богатый опыт – это новый способ повысить эффективность оружия, снаряжения и модулей навыков. Он позволит вам повышать класс снаряжения и напрямую увеличивать его базовые характеристики. Конечно, этот способ появится в дополнение к уже существующей системе создания и оптимизации предметов. Он просто даст вам еще одну возможность усилить ваше снаряжение. В ваш богатый опыт можно будет заглянуть на станции перекалибровки на операционной базе или в Гавани. Для него будет выделена отдельная вкладка. Как работает механика богатого опыта? Богатый опыт позволит вам повысить класс предмета, бренда или комплекта экипировки, тем самым увеличив его базовые характеристики – например, для оружия это будет урон. Вы сможете повысить класс предметов столько раз, сколько уровней богатого опыта у вас есть. Чтобы набирать уровни богатого опыта, вам нужно будет повышать свой рейтинг опытности, используя в бою предмет, бренд или комплект экипировки – или вкладывая ресурсы в их развитие. Получив максимальный рейтинг опытности для данного снаряжения, вы станете его знатоком. Важно отметить, что вы сможете повышать класс только тех предметов, брендов и комплектов экипировки, в которых вы знаток. С помощью этой механики мы хотим стимулировать игроков к экспериментам с различными версиями сборок и стилей игры, при этом не ущемляя тех, кто придерживается своих излюбленных вариантов. Теперь мы расскажем чуть более подробно об этой механике, а также о том, как ее применять. СОВМЕСТИМЫЕ ТИПЫ ПРЕДМЕТОВ Богатый опыт будет доступен для следующих типов предметов: Оружие (контрабандный АКМ, P416, Mk20 SSR спецназа США и т.д.) Бренды (Gila Guard, Alps Summit Armament, Walker, Harris & Co. и т.д.) Комплекты экипировки («Боевик», «Восьмерки и тузы», «Ярость охотника» и т.д.) Именные предметы («Окопная молитва», «Белая смерть», «Полый человек» и т.д.) Экзотические предметы («Госпожа Свобода», «Гремучник», система брони «Тихоходка» и т.д.) Модули навыков («Осколочная бомба-липучка», «Огнеметная турель», «Дрон-защитник» и т.д.) Фирменное оружие (арбалет эксперта по выживанию, огнемет K8-JetStream, реактивный гранатомет P-017 и т.д.) Развивая опытность для брендов или комплектов экипировки, вы одновременно развиваете опытность для всего совместимого снаряжения из этих брендов и комплектов. Важно отметить: чтобы начать развивать опытность в использовании того или иного предмета, сам этот предмет не нужен. На вкладке «Богатый опыт» на станции перекалибровки показаны все предметы, которые можно исследовать. После того как при обновлении игры будет добавлен новый контент, пул совместимых предметов станет больше, и вы сможете еще сильнее развить свой богатый опыт! Чем не причина искать новое снаряжение, введенное в новом сезоне, и пользоваться им? РАЗВИТИЕ ОПЫТНОСТИ В ИСПОЛЬЗОВАНИИ ПРЕДМЕТОВ Число очков, необходимое для получения максимального рейтинга опытности (10), зависит от качества и типа предмета. Повысить опытность можно тремя способами. Использовать предметы в бою и получать опыт за убийства врагов с помощью этих предметов. Получать опыт за убийства врагов с помощью совместимых предметов. Используя несколько предметов одного и того же бренда (или набора), вы сможете получить дополнительные очков опытности для этого бренда (набора). Дарить совместимые предметы. Можно будет дарить любые предметы, совместимые с тем предметом, для которого вы хотите развить опытность, – например, из того же бренда или того же комплекта экипировки. Дарить материалы. Для повышении опытности также можно будет использовать свои запасы материалов и валют. Пожертвовав редкие элементы, получите больше очков. Дарить предметы или материалы – хороший способ быстро набирать очки опытности, но развивать ее можно и пассивным способом: просто используя совместимые предметы при любой игровой активности. Проверить текущий рейтинг опытности для тех или иных предметов можно в любой момент в меню. Чтобы просмотреть все и узнать, каких предметов вам не хватает, загляните на станцию перекалибровки. УРОВЕНЬ БОГАТОГО ОПЫТА И ИСПОЛЬЗОВАНИЕ ПРЕДМЕТОВ Повышая рейтинг опытности использования различных предметов, вы также увеличиваете уровень богатого опыта агента. Чтобы получить новый уровень, вам потребуется набрать определенную сумму рейтингов опытности. Все данные о богатом опыте и опытности распространяются на всех персонажей учетной записи. На каждом новом уровне богатого опыта у игрока становится больше возможностей улучшить предмет с помощью материалов. Это работает почти как оптимизация, но вместо того чтобы увеличивать одну из характеристик до максимального значения, вы повышаете одну из базовых характеристик предмета. При этом повышается «класс» предмета. Однако обратите внимание, что улучшить таким образом предмет можно только в том случае, если вы достигли максимального рейтинга опытности в его использовании. Количество улучшений предмета равно уровню вашего богатого опыта. Улучшение предмета влияет на предметы, относящиеся к той же категории, что и он: Оружие - 1% для увеличения базового значения урона. Снаряжение - 1% для увеличения базового значения брони. Навыки - 1% для увеличения базового значения урона/лечения/длительности эффекта. Важная информация Текущие значения являются временными и в дальнейшем могут измениться в зависимости от общего баланса игры и результатов тестирования. Агенты могут и дальше набирать уровни богатого опыта, повышая опытность для всех доступных предметов. Когда в игре появляются новые предметы, максимальный уровень «Богатого опыта» тоже повышается. Открыть запись
  15. Мы почти на пороге Новой Войны, Тэнно. Готовы ли вы к всепоглощающей битве? В декабре этого года Новая Война будет выпущена одновременно на всех платформах. После краха Империи Орокин и бесчисленных лет ожидания восстания, Владеющие Разумом собрали силы для полномасштабного вторжения и готовы завоевать разрушенную и разделенную Изначальную Систему. Раскройте свою внутреннюю силу и овладейте новыми персонажами, оружием и совершенно новый Варфреймом, ведя борьбу среди звезд. Соберите свой отряд и приготовьтесь к крупнейшему до сегодняшнего дня моменту расширения повествования о вселенной Warframe. После него Изначальная Систему уже никогда не будет прежней.
  16. Мы почти на пороге Новой Войны, Тэнно. Готовы ли вы к всепоглощающей битве? В декабре этого года Новая Война будет выпущена одновременно на всех платформах. После краха Империи Орокин и бесчисленных лет ожидания восстания, Владеющие Разумом собрали силы для полномасштабного вторжения и готовы завоевать разрушенную и разделенную Изначальную Систему. Раскройте свою внутреннюю силу и овладейте новыми персонажами, оружием и совершенно новый Варфреймом, ведя борьбу среди звезд. Соберите свой отряд и приготовьтесь к крупнейшему до сегодняшнего дня моменту расширения повествования о вселенной Warframe. После него Изначальная Систему уже никогда не будет прежней. Открыть запись
  17. Новое исследование объединённой группы учёных из Британии и Словении позволило открыть новый способ передачи информации по беспроводной связи. Для этого используются нейтроны, которые выделяются в результате распада радиоактивных ядер. Такой метод имеет ряд преимуществ по сравнению с привычной технологией Wi-Fi. Современные мобильные устройства для соединения по беспроводной связи используют электромагнитное излучение, однако уровень сигнала значительно ослабляется, когда проходит через различные материалы, особенно через металлы. Авторы исследования решили измерить спонтанное излучение быстрых нейтронов, которое происходит при распаде радиоактивного изотопа калифорния-252. Затем было последовательно закодировано несколько различных примеров информации: слово, буква и случайное число. Для этого данные перевели в модуляцию нейтронного поля, а затем попробовали декодировать полученный сигнал на ноутбуке. Тест был сделан таким образом, чтобы максимально исключить человеческий фактор. Учёные не знали, какое число будет закодировано и передано, поскольку оно было выбрано с помощью генератора случайных чисел. Когда сведения передали по новой нейтронной связи на ноутбук, то в результате декодировки все тесты передачи информации показали стопроцентную успешность. Предполагается, что новая технология может найти применение в морских сооружениях, а также системах безопасности ядерных реакторов. Любым местам, где нужно свести к минимуму количество отверстий для прокладки кабелей связи, будет полезна новая технология. Использование нейтронов может привести к тому, что отверстия для кабелей связи и вовсе не понадобятся. Новый метод также позволит организовать коммуникацию в аварийной ситуации, когда нужно контактировать с объектом, куда не проникают электромагнитные волны.
  18. Новое исследование объединённой группы учёных из Британии и Словении позволило открыть новый способ передачи информации по беспроводной связи. Для этого используются нейтроны, которые выделяются в результате распада радиоактивных ядер. Такой метод имеет ряд преимуществ по сравнению с привычной технологией Wi-Fi. Современные мобильные устройства для соединения по беспроводной связи используют электромагнитное излучение, однако уровень сигнала значительно ослабляется, когда проходит через различные материалы, особенно через металлы. Авторы исследования решили измерить спонтанное излучение быстрых нейтронов, которое происходит при распаде радиоактивного изотопа калифорния-252. Затем было последовательно закодировано несколько различных примеров информации: слово, буква и случайное число. Для этого данные перевели в модуляцию нейтронного поля, а затем попробовали декодировать полученный сигнал на ноутбуке. Тест был сделан таким образом, чтобы максимально исключить человеческий фактор. Учёные не знали, какое число будет закодировано и передано, поскольку оно было выбрано с помощью генератора случайных чисел. Когда сведения передали по новой нейтронной связи на ноутбук, то в результате декодировки все тесты передачи информации показали стопроцентную успешность. Предполагается, что новая технология может найти применение в морских сооружениях, а также системах безопасности ядерных реакторов. Любым местам, где нужно свести к минимуму количество отверстий для прокладки кабелей связи, будет полезна новая технология. Использование нейтронов может привести к тому, что отверстия для кабелей связи и вовсе не понадобятся. Новый метод также позволит организовать коммуникацию в аварийной ситуации, когда нужно контактировать с объектом, куда не проникают электромагнитные волны. Открыть запись
  19. По слухам, AMD готовится немного сгладить ситуацию на рынке игровых видеокарт. Согласно новому инсайдерскому отчёту, компания вскоре представит сразу два недорогих решения для геймерского сегмента — Radeon RX 6500 XT и ещё более доступную модель RX 6400. Судя по публикации японского сетевого информатора @KOMACHI_ENSAKA в Twitter, обе новинки будут оснащены 4 ГБ видеопамяти GDDR6. Ожидается, что AMD Radeon RX 6500XT и RX 6400 оснастят графическим процессором начального уровня Navi 24 на архитектуре RDNA 2. Ранее этот чип отметился в коде Linux под рабочим названием Beige Goby. Navi 24 приписывают 16 вычислительных блоков и 1024 потоковых процессоров — в два раза меньше, чем у Navi 23. По слухам, GPU, который ляжет в основу новинок, имеет 64-битную шину памяти. Остальные характеристики видеокарт пока не сообщаются — указывается только, что они предположительно дебютируют в ноутбуках. Ожидается, что первые геймерские лэптопы с бюджетными игровыми видеокартами Radeon появятся на рынке в январе следующего года.
  20. По слухам, AMD готовится немного сгладить ситуацию на рынке игровых видеокарт. Согласно новому инсайдерскому отчёту, компания вскоре представит сразу два недорогих решения для геймерского сегмента — Radeon RX 6500 XT и ещё более доступную модель RX 6400. Судя по публикации японского сетевого информатора @KOMACHI_ENSAKA в Twitter, обе новинки будут оснащены 4 ГБ видеопамяти GDDR6. Ожидается, что AMD Radeon RX 6500XT и RX 6400 оснастят графическим процессором начального уровня Navi 24 на архитектуре RDNA 2. Ранее этот чип отметился в коде Linux под рабочим названием Beige Goby. Navi 24 приписывают 16 вычислительных блоков и 1024 потоковых процессоров — в два раза меньше, чем у Navi 23. По слухам, GPU, который ляжет в основу новинок, имеет 64-битную шину памяти. Остальные характеристики видеокарт пока не сообщаются — указывается только, что они предположительно дебютируют в ноутбуках. Ожидается, что первые геймерские лэптопы с бюджетными игровыми видеокартами Radeon появятся на рынке в январе следующего года. Открыть запись
  21. После очередного обновления Nextcloud столкнулся с проблемой Заголовок HTTP «Strict-Transport-Security» должен быть настроен как минимум на «15552000» секунд Заголовок HTTP «Strict-Transport-Security» должен быть настроен как минимум на «15552000» секунд Точнее даже не проблема, а рекомендация от разработчиков. Т.к. я люблю зелёную галочку, то нужно это исправить. Для этого в вайле .htaccess в корневой папке вашего облака, в отсеке с портом :443 нужно прописать следующее: <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" </IfModule> Но я это сделал в конфиге апача для виртуального хоста с облаком. Тоже пойдёт. В общем выбирайте любой способ и радуйтесь зелёной галочке как я
  22. После очередного обновления Nextcloud столкнулся с проблемой Заголовок HTTP «Strict-Transport-Security» должен быть настроен как минимум на «15552000» секунд Заголовок HTTP «Strict-Transport-Security» должен быть настроен как минимум на «15552000» секунд Точнее даже не проблема, а рекомендация от разработчиков. Т.к. я люблю зелёную галочку, то нужно это исправить. Для этого в вайле .htaccess в корневой папке вашего облака, в отсеке с портом :443 нужно прописать следующее: <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" </IfModule> Но я это сделал в конфиге апача для виртуального хоста с облаком. Тоже пойдёт. В общем выбирайте любой способ и радуйтесь зелёной галочке как я Открыть запись
  23. Встречайте обновление New Horizon! Это бесплатное обновление стало результатом нескольких месяцев постоянной работы над улучшением Outriders, изучением обратной связи от сообщества и внесением в игру изменений, о которых вы просили. В этой заметке мы перечислим основные изменения и нововведения New Horizon. Если вы интересуетесь подробностями обо всем, что изменилось в Outriders со дня выхода игры, рекомендуем прочитать огромную статью в нашем блоге. В честь выхода этого обновления мы подготовили специальный праздничный подарок для всех игроков, в том числе новичков, играющих в демоверсию! Просто запустите или загрузите Outriders и сыграйте в период с 18:00 по московскому времени 16 ноября до 18:00 по московскому времени 30 ноября. Ваш самый опытный персонаж получит в подарок элемент легендарной брони. Он появится среди предметов персонажа или в хранилище в течение 24 – 48 часов. Спасибо за то, что вы опробовали обновление New Horizon для Outriders. До встречи на планете Енох! ОПИСАНИЕ ИЗМЕНЕНИЙ ОСНОВНЫЕ ИЗМЕНЕНИЯ Чтобы узнать больше о каждом из этих изменений, прокрутите страницу вниз, к разделу «ПОДРОБНОСТИ ОБ ИЗМЕНЕНИЯХ». Список исправленных ошибок находится в самом низу заметки, в разделе «ИСПРАВЛЕНИЯ ОШИБОК». Удалены таймеры в экспедициях. Добавлены четыре новые экспедиции. Добавлена система трансмогрификации. Обновлен магазин Тьяго. Переработан ряд легендарных комплектов снаряжения. Изменены и усилены некоторые модификации. Изменены и усилены некоторые узлы на древах навыков. Изменены и усилены некоторые навыки. ПОДРОБНОСТИ ОБ ИЗМЕНЕНИЯХ ОБЩИЕ ИЗМЕНЕНИЯ Вступительный ролик при запуске Outriders теперь можно пропустить. По завершении задания «Око бури» теперь можно выбрать легендарный предмет в качестве награды. У торговцев появилась функция «Быстро отметить». Описания модификаций стали более читаемыми, особенно при игре на большом телеэкране или мониторе. Это означает, что часть информации вынесена из окна быстрого просмотра в окно «Информация». Снижена громкость фоновых звуков у некоторых меню и экранов загрузки. У способности матери выводка «Перфорация» появился минимальный предел урона. Благодаря этому у способности не будет слишком большого разрыва между минимумом и максимумом наносимого урона. Изменена конфигурация «Наследника пустыни», чтобы это оружие вело себя как штурмовая винтовка (как это задумано и указано в описании), а не как пистолет-пулемет. УДАЛЕНЫ ТАЙМЕРЫ В ЭКСПЕДИЦИЯХ Экспедиции больше не ограничены по времени, при этом таймер можно включить по желанию. В новой системе вы получите награду за завершение экспедиции независимо от того, сколько времени потратите. Подробности читайте в статье нашего мегаблога. ДОБАВЛЕНЫ ЧЕТЫРЕ НОВЫЕ ЭКСПЕДИЦИИ Мы добавили четыре новые масштабные экспедиции, которые отправят вас в ранее неизведанные уголки Еноха. У каждой экспедиции есть свой мини-сюжет, связанный с персонажами и событиями основной кампании. Даже те, кто еще не участвовал в экспедициях, получат доступ к первой из четырех. Остальные откроются на уровнях испытаний 4, 8 и 12. Экспедиция «Выжженные недра» Вернет вас в Орлиные пики. После включения сигнала капсулы Данэм отправилась на поиски и нашла тайную электростанцию. Чтобы перезапустить ее, она попросила вас зачистить станцию от непрошеных гостей – независимо от их размеров и формы. В экспедиции «Город Странников» Вы встретите персонажа, которого терзают грехи прошлого. Узнав его мрачную историю, вы решаете помочь ему защитить старую деревню паксов Укету Атара. В «Комплексе Маршала» Грандмаршал Корриган лично поручит вам отбить у мятежников комплекс около Пустопорожнего перевала. Но вскоре вы обнаружите, что этот комплекс – отнюдь не очередной лагерь мятежников... «Источник» Тьяго рассказал вам легенду паксов про священное место Атума-Итару, куда издалека приходят паломники и приносят в жертву свои богатства, сбрасывая их в глубокие колодцы. Вы и ваш отряд отправитесь на поиски этих забытых сокровищ, но попадете в мощную бурю, которая становится все сильнее... Подробности читайте в статье нашего мегаблога. ОБНОВЛЕН МАГАЗИН ТЬЯГО Мы изменили магазин Тьяго. Там по-прежнему продается легендарное снаряжение, но теперь есть две дополнительные возможности: заменить ассортимент доступного легендарного снаряжения; купить предмет неизвестного легендарного снаряжения. Оба эти действия тратят ресурсы из капсул. Подробности читайте в статье нашего мегаблога. ДОБАВЛЕНА СИСТЕМА ТРАНСМОГРИФИКАЦИИ Мы добавили в Outriders новую систему трансмогрификации. Она позволяет заменить облик одного предмета на облик другого, при этом сохраняя его оригинальные модификации и характеристики. Трансмогрификация оружия также позволяет заменить все звуки. Трансмогрификация является бесплатной, ее можно выполнить в любой момент. Никаких сложных систем. Никаких микротранзакций. Внутриигровые ресурсы не требуются. Подробности читайте в статье нашего мегаблога. ИЗМЕНЕНИЯ В СНАРЯЖЕНИИ И ЛЕГЕНДАРНЫХ КОМПЛЕКТАХ ТРИКСТЕР Комплект «Нарушитель» К текущему бонусу добавлен новый бонус за комплект. Текущий бонус: пока игрок находится в зоне действия «Замедляющей ловушки», он не может умереть. Дополнительный новый бонус: за каждого врага, на которого действует навык обмана, урон увеличивается на 6%. Кроме того, пока игрок находится в зоне действия «Замедляющей ловушки», он не может умереть. Примечание: к навыкам обмана относятся «Замедляющая ловушка», «Охотничий нож» и «Искажение времени». ТЕХНОМАНТ Комплект «Ливень» У дополнительных бомб, появляющихся в виде бонуса за комплект «Ливень», сокращено время запуска. Мы также исправили ошибку, мешавшую запустить дополнительную мину после прямого попадания. Комплект «Жуткий изобретатель» Бонус за комплект «Жуткий изобретатель» изменен таким образом, чтобы «Орудие разрушения» пополнялось несколько раз в ходе своего действия.Прежний бонус за комплект: пока действует «Орудие разрушения», подтвержденное попадание из «Реактивной боли» восстанавливает 20% боеприпасов для мини-пушки и гранатомета. Это происходит только один раз за каждое использование «Орудия разрушения». Новый бонус за комплект: пока действует «Орудие разрушения», подтвержденное попадание из «Реактивной боли» восстанавливает 20% боеприпасов для мини-пушки и гранатомета. ПИРОМАНТ Комплект «Огненный лич» Бонус за комплект «Огненный лич» теперь ускоряет восстановление на 30% (раньше было 10%). Комплект «Перекованный» Первоначально планировалось, что «Перекованный» будет усиливать огневую мощь в дальнем бою. Однако игроки в основном его использовали с навыками Аномальной силы. Поэтому мы изменили свойства этого комплекта, чтобы он лучше поддерживал навыки, связанные с Аномальным уроном. Вместо свойств дальнего боя на всех его элементах теперь используются ускоренное восстановление или выкачивание жизни с помощью навыков. У «Капюшона перекованных», являющегося головной броней в комплекте «Перекованный», заменены свойства: вместо свойства «Здоровье» используется «Аномальная сила», вместо свойства «Дальний бой» используется «Ускоренное восстановление» или «Выкачивание жизни с помощью навыков». Благодаря этим изменениям капюшон лучше сочетается с новыми возможностями комплекта, ориентированного на Аномальную силу. У «Брони перекованных», являющейся нагрудной броней в комплекте «Перекованный», заменена модификация: вместо модификации «Поглощение пуль» используется «Пепельная хватка», которая накладывает Пепел на всех противников в зоне поражения термальной бомбы до взрыва. Это значительно упростит применение термальной бомбы с данным комплектом. У «Набедренной повязки перекованных», являющейся нижней броней в комплекте «Перекованный», заменена модификация: вместо модификации «Пожар» используется «Неистовство огня», позволяющее еще раз использовать термальную бомбу. У «Сапогов перекованных», являющихся броней для ног в комплекте «Перекованный», заменена модификация: вместо модификации «Новая звезда» используется «Аномальный голод». Внося эти изменения, мы ожидаем, что навык «Раздувание пламени» будет наносить больше урона и станет более полезным для детонации термальных бомб. У бонуса за комплект «Перекованный» увеличен бонус к урону. При использовании «Термальной бомбы» следующее применение навыка «Раздувание пламени» наносит на 75% больше урона (раньше было 50%). После применения навыка «Раздувание пламени» следующая «Термальная бомба» наносит на 75% больше урона (раньше было 50%). РАЗРУШИТЕЛЬ Комплект «Защита от смерти» К текущему бонусу добавлен новый бонус за комплект. Текущий бонус: сокращает время восстановления навыка «Напролом» на 90%. Дополнительный новый бонус за комплект: сокращает время восстановления навыка «Напролом» на 90% и повышает огневую мощь на 15% от уровня брони. У «Перчаток защиты от смерти», входящих в комплект «Защита от смерти», заменена модификация: вместо модификации «Убийца королей» используется «На пороге смерти». Комплект «Маршал» У бонуса за комплект «Маршал» увеличен общий бонус, получаемый за Аномальный урон, до 40% (раньше было 10%). У «Перчаток маршала», входящих в комплект «Маршал», заменена модификация: вместо модификации «Разбитая броня» используется «Замес». Модификация «Разбитая броня» отнимала броню у врагов, а модификация «Замес» накладывает состояние уязвимости. Поскольку комплект «Маршал» ориентирован в основном на Аномальную силу, мы решили, что будет логичнее увеличить урон, наносимый всеми источниками, нежели ослаблять вражескую броню. Комплект «Статуя» У комплекта «Статуя» заменено свойство: вместо свойства «Выкачивание жизни с помощью навыков» используется «Урон в ближнем бою». ИЗМЕНЕНИЯ В МОДИФИКАЦИЯХ Изменен принцип действия «Крепости». Новое описание и действие звучат так: выстрелы увеличивают прочность брони и устойчивость на 5%; эффект суммируется до 3 раз. На максимальном уровне бонус удваивается и дополнительно увеличивает наносимый урон на 30% в течение 10 с. Время восстановления между уровнями составляет 0,25 с. Чтобы подробнее узнать о том, почему мы внесли это изменение, прочтите обсуждение в этой ветке. Таймеры восстановления всех модификаций теперь являются универсальными. Это означает, что время восстановления модификаций является общим для персонажа, а не для каждого применения конкретной модификации. Теперь игроки не смогут переключаться и активировать одну и ту же модификацию в течение очень короткого периода времени. Чтобы компенсировать возможное снижение наносимого урона, мы усилили нижеперечисленные модификации. Чтобы подробнее узнать о том, почему мы внесли это изменение, прочтите обсуждение в этой ветке. «Воющий ветер» наносит на 60% больше урона (базовое значение возросло со 120 до 191 ед.). «Концентрированный взрыв» наносит на 27% больше урона (базовое значение возросло с 35 до 48,3 ед.). Максимальное количество целей «Концентрированного взрыва» сокращено до 4 (раньше было 6). «Идеальная шрапнель из костей» наносит на 14% больше урона (базовое значение возросло с 63 до 71,82 ед.). «Бомбы сброшены» наносит на 14% больше урона (базовое значение возросло с 62 до 71 ед.). «Легендарное минное поле» наносит на 11% больше урона (базовое значение возросло с 20 до 22,3 ед.). «Кинетический топот» наносит на 34% больше урона (базовое значение возросло с 72 до 96,48 ед.). «Ослабляющая ловушка» наносит на 237% больше урона (базовое значение возросло с 18 до 60,6 ед.). «Песчаная буря» наносит на 42% больше урона (базовое значение возросло с 7,2 до 10,25 ед.). «Гнев Молоха» наносит на 37% больше урона (базовое значение возросло с 50 до 68,5 ед.). «Граната из лома» наносит на 17% больше урона (базовое значение возросло с 70 до 91,9 ед.). «Смертельный дисбаланс» наносит на 27% больше урона (базовое значение возросло с 69 до 87,3 ед.). «Хищная саранча» наносит на 50% больше урона (базовое значение постоянного урона за такт возросло с 4 до 6 ед.). Длительность действия «Хищной саранчи» сокращена на 4 с. до 4 с. (раньше было 8 с.) «Радиационный взрыв» наносит на 208% больше урона (базовое значение возросло с 38 до 114 ед.). ИЗМЕНЕНИЯ В ДРЕВАХ НАВЫКОВ Бонус к АС от дающих его узлов древа навыков увеличен до 10% (было 6%). ТРИКСТЕР «Дестабилизирующий щит» Прочность щита, возникающего при использовании навыков ОБМАНА, увеличена с 20% до 50%. «Польза в квадрате» Эффект лечения, который обеспечивает этот узел, увеличен с 5% до 10% за каждый подобранный комплект боеприпасов. ТЕХНОМАНТ «Знаток по части пистолетов» Дополнительный урон от оружия, который обеспечивает этот узел, увеличен с 12% до 20%. ПИРОМАНТ «Надежный хват» Снижение отдачи при стрельбе, которое обеспечивает этот узел, увеличено с 30% до 40%. «Знаток по части пистолетов» Дополнительный урон от оружия, который обеспечивает этот узел, увеличен с 12% до 20%. РАЗРУШИТЕЛЬ «Польза в квадрате» Эффект лечения, который обеспечивает этот узел, увеличен с 5% до 10% за каждый подобранный комплект боеприпасов. «Твердая рука» Снижение отдачи при стрельбе, которое обеспечивает этот узел, увеличено с 30% до 40%. ИСПРАВЛЕННЫЕ ОШИБКИ Исправление общих ошибок Исправлена ошибка, мешавшая выполнить основное задание «Наставник», поскольку из-за нее не активировалась заставка. Исправлена ошибка, из-за которой перфоро-вожак освобождался от эффектов сдерживания (например, заморозки или пепла) при отбрасывании. Исправлена ошибка, мешавшая завершить экспедицию «Сердце дебрей», если ядовитый перфоро был последним врагом, убитым во время одного из сражений. Исправлена ошибка в экспедиции «Химический завод», из-за которой основное оружие игрока могло использовать модификации дополнительного, если игрок менял оружие во время активации рычага. Исправлена ошибка, из-за которой в конце описания экспедиции отображалось неправильное значение заблокированного урона. Исправлена ошибка, из-за которой угол обзора камеры автоматически сбрасывался при определенных условиях на ПК. Устранены проблемы, мешавшие получить приглашения в игре при определенных условиях. Исправлены другие ошибки и причины вылетов. Исправления ошибок в модификациях Исправлена ошибка, из-за которой урон, наносимый модификацией «Воющий ветер», был разным у хоста и клиентов. Раньше он засчитывался дважды у игроков-клиентов. Теперь наносимый урон совпадает у хоста и клиентов. Исправлена ошибка, не позволявшая установленным в броне модификациям масштабироваться вместе с уровнем брони, когда броню улучшали с помощью Захеди. Раньше эта ошибка исчезала автоматически при переходе в другую область. Исправлена ошибка, из-за которой эффект модификации «Сравнять шансы» суммировался 5 раз вместо заявленных 3. Изменено поведение модификации «Усиление брони», чтобы она масштабировалась вместе с уровнем брони, в которую ее вставили. Раньше она масштабировалась с уровнем игрока и прекращала рост на 30-м уровне. Исправлена ошибка, из-за которой модификация «Защитная стойка» не срабатывала, если урон, который должен ее активировать, также отбрасывал игрока. Исправлена ошибка, из-за которой модификация «Аномальная мутация» не вызывала ожидаемый эффект горения или замедления. Исправлена ошибка, из-за которой модификация «Поглощение пуль» восполняла 80% боезапаса вместо 40%. Исправлена ошибка, иногда вызывавшая падение частоты кадров, когда модификацию «Цепочка повреждений» использовали в сочетании с модификацией «Обмен болью». Исправления ошибок в навыках В описании навыка «Бесконечная масса» теперь упоминается накладываемый им эффект замедления. Исправлена ошибка, мешавшая навыку техноманта «Похолодание» замораживать врагов, если его активировали, когда игрок съезжал с края. Исправлена ошибка, из-за которой турели техноманта могли провалиться под землю, когда их бросали слишком высоко или низко. Добавлен значок навыка «Криотурель» в узлы техноманта «Инженер» и «Старший инженер». Эти узлы в любом случае уже влияли на навык «Криотурель». Исправления ошибок в узлах классов Исправлена ошибка, из-за которой узел пироманта «Выдающиеся способности» не давал бонусы как положено. Еще раз спасибо за то, что опробовали обновление New Horizon. До встречи на Енохе, Первопроходец!
  24. Встречайте обновление New Horizon! Это бесплатное обновление стало результатом нескольких месяцев постоянной работы над улучшением Outriders, изучением обратной связи от сообщества и внесением в игру изменений, о которых вы просили. В этой заметке мы перечислим основные изменения и нововведения New Horizon. Если вы интересуетесь подробностями обо всем, что изменилось в Outriders со дня выхода игры, рекомендуем прочитать огромную статью в нашем блоге. В честь выхода этого обновления мы подготовили специальный праздничный подарок для всех игроков, в том числе новичков, играющих в демоверсию! Просто запустите или загрузите Outriders и сыграйте в период с 18:00 по московскому времени 16 ноября до 18:00 по московскому времени 30 ноября. Ваш самый опытный персонаж получит в подарок элемент легендарной брони. Он появится среди предметов персонажа или в хранилище в течение 24 – 48 часов. Спасибо за то, что вы опробовали обновление New Horizon для Outriders. До встречи на планете Енох! ОПИСАНИЕ ИЗМЕНЕНИЙ ОСНОВНЫЕ ИЗМЕНЕНИЯ Чтобы узнать больше о каждом из этих изменений, прокрутите страницу вниз, к разделу «ПОДРОБНОСТИ ОБ ИЗМЕНЕНИЯХ». Список исправленных ошибок находится в самом низу заметки, в разделе «ИСПРАВЛЕНИЯ ОШИБОК». Удалены таймеры в экспедициях. Добавлены четыре новые экспедиции. Добавлена система трансмогрификации. Обновлен магазин Тьяго. Переработан ряд легендарных комплектов снаряжения. Изменены и усилены некоторые модификации. Изменены и усилены некоторые узлы на древах навыков. Изменены и усилены некоторые навыки. ПОДРОБНОСТИ ОБ ИЗМЕНЕНИЯХ ОБЩИЕ ИЗМЕНЕНИЯ Вступительный ролик при запуске Outriders теперь можно пропустить. По завершении задания «Око бури» теперь можно выбрать легендарный предмет в качестве награды. У торговцев появилась функция «Быстро отметить». Описания модификаций стали более читаемыми, особенно при игре на большом телеэкране или мониторе. Это означает, что часть информации вынесена из окна быстрого просмотра в окно «Информация». Снижена громкость фоновых звуков у некоторых меню и экранов загрузки. У способности матери выводка «Перфорация» появился минимальный предел урона. Благодаря этому у способности не будет слишком большого разрыва между минимумом и максимумом наносимого урона. Изменена конфигурация «Наследника пустыни», чтобы это оружие вело себя как штурмовая винтовка (как это задумано и указано в описании), а не как пистолет-пулемет. УДАЛЕНЫ ТАЙМЕРЫ В ЭКСПЕДИЦИЯХ Экспедиции больше не ограничены по времени, при этом таймер можно включить по желанию. В новой системе вы получите награду за завершение экспедиции независимо от того, сколько времени потратите. Подробности читайте в статье нашего мегаблога. ДОБАВЛЕНЫ ЧЕТЫРЕ НОВЫЕ ЭКСПЕДИЦИИ Мы добавили четыре новые масштабные экспедиции, которые отправят вас в ранее неизведанные уголки Еноха. У каждой экспедиции есть свой мини-сюжет, связанный с персонажами и событиями основной кампании. Даже те, кто еще не участвовал в экспедициях, получат доступ к первой из четырех. Остальные откроются на уровнях испытаний 4, 8 и 12. Экспедиция «Выжженные недра» Вернет вас в Орлиные пики. После включения сигнала капсулы Данэм отправилась на поиски и нашла тайную электростанцию. Чтобы перезапустить ее, она попросила вас зачистить станцию от непрошеных гостей – независимо от их размеров и формы. В экспедиции «Город Странников» Вы встретите персонажа, которого терзают грехи прошлого. Узнав его мрачную историю, вы решаете помочь ему защитить старую деревню паксов Укету Атара. В «Комплексе Маршала» Грандмаршал Корриган лично поручит вам отбить у мятежников комплекс около Пустопорожнего перевала. Но вскоре вы обнаружите, что этот комплекс – отнюдь не очередной лагерь мятежников... «Источник» Тьяго рассказал вам легенду паксов про священное место Атума-Итару, куда издалека приходят паломники и приносят в жертву свои богатства, сбрасывая их в глубокие колодцы. Вы и ваш отряд отправитесь на поиски этих забытых сокровищ, но попадете в мощную бурю, которая становится все сильнее... Подробности читайте в статье нашего мегаблога. ОБНОВЛЕН МАГАЗИН ТЬЯГО Мы изменили магазин Тьяго. Там по-прежнему продается легендарное снаряжение, но теперь есть две дополнительные возможности: заменить ассортимент доступного легендарного снаряжения; купить предмет неизвестного легендарного снаряжения. Оба эти действия тратят ресурсы из капсул. Подробности читайте в статье нашего мегаблога. ДОБАВЛЕНА СИСТЕМА ТРАНСМОГРИФИКАЦИИ Мы добавили в Outriders новую систему трансмогрификации. Она позволяет заменить облик одного предмета на облик другого, при этом сохраняя его оригинальные модификации и характеристики. Трансмогрификация оружия также позволяет заменить все звуки. Трансмогрификация является бесплатной, ее можно выполнить в любой момент. Никаких сложных систем. Никаких микротранзакций. Внутриигровые ресурсы не требуются. Подробности читайте в статье нашего мегаблога. ИЗМЕНЕНИЯ В СНАРЯЖЕНИИ И ЛЕГЕНДАРНЫХ КОМПЛЕКТАХ ТРИКСТЕР Комплект «Нарушитель» К текущему бонусу добавлен новый бонус за комплект. Текущий бонус: пока игрок находится в зоне действия «Замедляющей ловушки», он не может умереть. Дополнительный новый бонус: за каждого врага, на которого действует навык обмана, урон увеличивается на 6%. Кроме того, пока игрок находится в зоне действия «Замедляющей ловушки», он не может умереть. Примечание: к навыкам обмана относятся «Замедляющая ловушка», «Охотничий нож» и «Искажение времени». ТЕХНОМАНТ Комплект «Ливень» У дополнительных бомб, появляющихся в виде бонуса за комплект «Ливень», сокращено время запуска. Мы также исправили ошибку, мешавшую запустить дополнительную мину после прямого попадания. Комплект «Жуткий изобретатель» Бонус за комплект «Жуткий изобретатель» изменен таким образом, чтобы «Орудие разрушения» пополнялось несколько раз в ходе своего действия.Прежний бонус за комплект: пока действует «Орудие разрушения», подтвержденное попадание из «Реактивной боли» восстанавливает 20% боеприпасов для мини-пушки и гранатомета. Это происходит только один раз за каждое использование «Орудия разрушения». Новый бонус за комплект: пока действует «Орудие разрушения», подтвержденное попадание из «Реактивной боли» восстанавливает 20% боеприпасов для мини-пушки и гранатомета. ПИРОМАНТ Комплект «Огненный лич» Бонус за комплект «Огненный лич» теперь ускоряет восстановление на 30% (раньше было 10%). Комплект «Перекованный» Первоначально планировалось, что «Перекованный» будет усиливать огневую мощь в дальнем бою. Однако игроки в основном его использовали с навыками Аномальной силы. Поэтому мы изменили свойства этого комплекта, чтобы он лучше поддерживал навыки, связанные с Аномальным уроном. Вместо свойств дальнего боя на всех его элементах теперь используются ускоренное восстановление или выкачивание жизни с помощью навыков. У «Капюшона перекованных», являющегося головной броней в комплекте «Перекованный», заменены свойства: вместо свойства «Здоровье» используется «Аномальная сила», вместо свойства «Дальний бой» используется «Ускоренное восстановление» или «Выкачивание жизни с помощью навыков». Благодаря этим изменениям капюшон лучше сочетается с новыми возможностями комплекта, ориентированного на Аномальную силу. У «Брони перекованных», являющейся нагрудной броней в комплекте «Перекованный», заменена модификация: вместо модификации «Поглощение пуль» используется «Пепельная хватка», которая накладывает Пепел на всех противников в зоне поражения термальной бомбы до взрыва. Это значительно упростит применение термальной бомбы с данным комплектом. У «Набедренной повязки перекованных», являющейся нижней броней в комплекте «Перекованный», заменена модификация: вместо модификации «Пожар» используется «Неистовство огня», позволяющее еще раз использовать термальную бомбу. У «Сапогов перекованных», являющихся броней для ног в комплекте «Перекованный», заменена модификация: вместо модификации «Новая звезда» используется «Аномальный голод». Внося эти изменения, мы ожидаем, что навык «Раздувание пламени» будет наносить больше урона и станет более полезным для детонации термальных бомб. У бонуса за комплект «Перекованный» увеличен бонус к урону. При использовании «Термальной бомбы» следующее применение навыка «Раздувание пламени» наносит на 75% больше урона (раньше было 50%). После применения навыка «Раздувание пламени» следующая «Термальная бомба» наносит на 75% больше урона (раньше было 50%). РАЗРУШИТЕЛЬ Комплект «Защита от смерти» К текущему бонусу добавлен новый бонус за комплект. Текущий бонус: сокращает время восстановления навыка «Напролом» на 90%. Дополнительный новый бонус за комплект: сокращает время восстановления навыка «Напролом» на 90% и повышает огневую мощь на 15% от уровня брони. У «Перчаток защиты от смерти», входящих в комплект «Защита от смерти», заменена модификация: вместо модификации «Убийца королей» используется «На пороге смерти». Комплект «Маршал» У бонуса за комплект «Маршал» увеличен общий бонус, получаемый за Аномальный урон, до 40% (раньше было 10%). У «Перчаток маршала», входящих в комплект «Маршал», заменена модификация: вместо модификации «Разбитая броня» используется «Замес». Модификация «Разбитая броня» отнимала броню у врагов, а модификация «Замес» накладывает состояние уязвимости. Поскольку комплект «Маршал» ориентирован в основном на Аномальную силу, мы решили, что будет логичнее увеличить урон, наносимый всеми источниками, нежели ослаблять вражескую броню. Комплект «Статуя» У комплекта «Статуя» заменено свойство: вместо свойства «Выкачивание жизни с помощью навыков» используется «Урон в ближнем бою». ИЗМЕНЕНИЯ В МОДИФИКАЦИЯХ Изменен принцип действия «Крепости». Новое описание и действие звучат так: выстрелы увеличивают прочность брони и устойчивость на 5%; эффект суммируется до 3 раз. На максимальном уровне бонус удваивается и дополнительно увеличивает наносимый урон на 30% в течение 10 с. Время восстановления между уровнями составляет 0,25 с. Чтобы подробнее узнать о том, почему мы внесли это изменение, прочтите обсуждение в этой ветке. Таймеры восстановления всех модификаций теперь являются универсальными. Это означает, что время восстановления модификаций является общим для персонажа, а не для каждого применения конкретной модификации. Теперь игроки не смогут переключаться и активировать одну и ту же модификацию в течение очень короткого периода времени. Чтобы компенсировать возможное снижение наносимого урона, мы усилили нижеперечисленные модификации. Чтобы подробнее узнать о том, почему мы внесли это изменение, прочтите обсуждение в этой ветке. «Воющий ветер» наносит на 60% больше урона (базовое значение возросло со 120 до 191 ед.). «Концентрированный взрыв» наносит на 27% больше урона (базовое значение возросло с 35 до 48,3 ед.). Максимальное количество целей «Концентрированного взрыва» сокращено до 4 (раньше было 6). «Идеальная шрапнель из костей» наносит на 14% больше урона (базовое значение возросло с 63 до 71,82 ед.). «Бомбы сброшены» наносит на 14% больше урона (базовое значение возросло с 62 до 71 ед.). «Легендарное минное поле» наносит на 11% больше урона (базовое значение возросло с 20 до 22,3 ед.). «Кинетический топот» наносит на 34% больше урона (базовое значение возросло с 72 до 96,48 ед.). «Ослабляющая ловушка» наносит на 237% больше урона (базовое значение возросло с 18 до 60,6 ед.). «Песчаная буря» наносит на 42% больше урона (базовое значение возросло с 7,2 до 10,25 ед.). «Гнев Молоха» наносит на 37% больше урона (базовое значение возросло с 50 до 68,5 ед.). «Граната из лома» наносит на 17% больше урона (базовое значение возросло с 70 до 91,9 ед.). «Смертельный дисбаланс» наносит на 27% больше урона (базовое значение возросло с 69 до 87,3 ед.). «Хищная саранча» наносит на 50% больше урона (базовое значение постоянного урона за такт возросло с 4 до 6 ед.). Длительность действия «Хищной саранчи» сокращена на 4 с. до 4 с. (раньше было 8 с.) «Радиационный взрыв» наносит на 208% больше урона (базовое значение возросло с 38 до 114 ед.). ИЗМЕНЕНИЯ В ДРЕВАХ НАВЫКОВ Бонус к АС от дающих его узлов древа навыков увеличен до 10% (было 6%). ТРИКСТЕР «Дестабилизирующий щит» Прочность щита, возникающего при использовании навыков ОБМАНА, увеличена с 20% до 50%. «Польза в квадрате» Эффект лечения, который обеспечивает этот узел, увеличен с 5% до 10% за каждый подобранный комплект боеприпасов. ТЕХНОМАНТ «Знаток по части пистолетов» Дополнительный урон от оружия, который обеспечивает этот узел, увеличен с 12% до 20%. ПИРОМАНТ «Надежный хват» Снижение отдачи при стрельбе, которое обеспечивает этот узел, увеличено с 30% до 40%. «Знаток по части пистолетов» Дополнительный урон от оружия, который обеспечивает этот узел, увеличен с 12% до 20%. РАЗРУШИТЕЛЬ «Польза в квадрате» Эффект лечения, который обеспечивает этот узел, увеличен с 5% до 10% за каждый подобранный комплект боеприпасов. «Твердая рука» Снижение отдачи при стрельбе, которое обеспечивает этот узел, увеличено с 30% до 40%. ИСПРАВЛЕННЫЕ ОШИБКИ Исправление общих ошибок Исправлена ошибка, мешавшая выполнить основное задание «Наставник», поскольку из-за нее не активировалась заставка. Исправлена ошибка, из-за которой перфоро-вожак освобождался от эффектов сдерживания (например, заморозки или пепла) при отбрасывании. Исправлена ошибка, мешавшая завершить экспедицию «Сердце дебрей», если ядовитый перфоро был последним врагом, убитым во время одного из сражений. Исправлена ошибка в экспедиции «Химический завод», из-за которой основное оружие игрока могло использовать модификации дополнительного, если игрок менял оружие во время активации рычага. Исправлена ошибка, из-за которой в конце описания экспедиции отображалось неправильное значение заблокированного урона. Исправлена ошибка, из-за которой угол обзора камеры автоматически сбрасывался при определенных условиях на ПК. Устранены проблемы, мешавшие получить приглашения в игре при определенных условиях. Исправлены другие ошибки и причины вылетов. Исправления ошибок в модификациях Исправлена ошибка, из-за которой урон, наносимый модификацией «Воющий ветер», был разным у хоста и клиентов. Раньше он засчитывался дважды у игроков-клиентов. Теперь наносимый урон совпадает у хоста и клиентов. Исправлена ошибка, не позволявшая установленным в броне модификациям масштабироваться вместе с уровнем брони, когда броню улучшали с помощью Захеди. Раньше эта ошибка исчезала автоматически при переходе в другую область. Исправлена ошибка, из-за которой эффект модификации «Сравнять шансы» суммировался 5 раз вместо заявленных 3. Изменено поведение модификации «Усиление брони», чтобы она масштабировалась вместе с уровнем брони, в которую ее вставили. Раньше она масштабировалась с уровнем игрока и прекращала рост на 30-м уровне. Исправлена ошибка, из-за которой модификация «Защитная стойка» не срабатывала, если урон, который должен ее активировать, также отбрасывал игрока. Исправлена ошибка, из-за которой модификация «Аномальная мутация» не вызывала ожидаемый эффект горения или замедления. Исправлена ошибка, из-за которой модификация «Поглощение пуль» восполняла 80% боезапаса вместо 40%. Исправлена ошибка, иногда вызывавшая падение частоты кадров, когда модификацию «Цепочка повреждений» использовали в сочетании с модификацией «Обмен болью». Исправления ошибок в навыках В описании навыка «Бесконечная масса» теперь упоминается накладываемый им эффект замедления. Исправлена ошибка, мешавшая навыку техноманта «Похолодание» замораживать врагов, если его активировали, когда игрок съезжал с края. Исправлена ошибка, из-за которой турели техноманта могли провалиться под землю, когда их бросали слишком высоко или низко. Добавлен значок навыка «Криотурель» в узлы техноманта «Инженер» и «Старший инженер». Эти узлы в любом случае уже влияли на навык «Криотурель». Исправления ошибок в узлах классов Исправлена ошибка, из-за которой узел пироманта «Выдающиеся способности» не давал бонусы как положено. Еще раз спасибо за то, что опробовали обновление New Horizon. До встречи на Енохе, Первопроходец! Открыть запись
  1. Load more activity
×
×
  • Create New...