По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Это подробное руководство предоставит вам информацию для эффективного сравнения лицензий Open Source, что должно помочь вам при выборе лицензии Open Source, подходящей для Вашего проекта.
Итак, вы уже некоторое время работаете над крутым проектом – и вот вы готовы сделать важный шаг и превратить ваш закрытый код в открытый.
Эта задача кажется несложной – просто почистить исходники и историю версий перед тем, как залить свой репозиторий на GitHub или Bitbucket... пока не всплывает вопрос о лицензии. Оказывается, выбор такой широкий. Какую лицензию выбрать? И нужна ли она вам вообще на самом деле?
Можно коротко ответить на последний вопрос: да, вам действительно нужна лицензия. А на вопрос о том, какая лицензия вам нужна, мой ответ ещё короче: когда как. Но если вы серьёзно относитесь к своему проекту, вам, вероятно, потребуется немного больше деталей. Что ж, читайте дальше – и помните: вы вступаете на территорию бесконечных споров!
Нужна ли мне лицензия? И что вообще такое лицензия?
Лицензия – это официальное разрешение, предоставленное автором какой-либо работы («Лицензиаром») сторонним лицам («Лицензиатам») и регулирующее использование лицензиатом работы лицензиара. Она имеет форму договора, с которым должны согласиться обе стороны. В наше время - это согласие бывает неявным: подразумевается, что, просто используя какую-либо работу, вы соглашаетесь с условиями её лицензии на использование.
Поясню: выпуская свою собственную работу, лицензиаром являетесь именно вы. А лицензиатом – любое лицо, использующее ваш код. Проще говоря, речь идёт о двух главных категориях: разработчиках и конечных пользователях.
И для закрепления ещё некоторых терминов: модифицируя вашу работу, лицензиат создаёт то, что называется производной работой (производным произведением). Не все лицензии одинаково трактуют то, становится ли более масштабный по сравнению с вашей работой проект производным произведением, если она была использована в этом проекте. Как вы увидите ниже, некоторые лицензии отдельно прописывают такие случаи.
Какова цель лицензии?
В целом, лицензия – это способ договориться о правах и обязанностях сторон для лицензиара и лицензиата. Эти права и обязанности могут быть любыми – в рамках законодательства. К примеру, лицензиар может потребовать обязательного указания имени правообладателя при использовании работы лицензиатом. Или разрешить копирование своей работы, но запретить любую её модификацию. Или даже потребовать, чтобы производная работа выпускалась на тех же условиях, что и оригинальная.
С другой стороны, лицензия защищает и лицензиата. Поскольку в ней явно прописаны условия использования работы, ему не угрожает то, что вы внезапно потребуете лицензионные отчисления или любые другие виды компенсации за использование своей работы. Это важно для распространения вашей работы.
Итак, лицензия защитит вашу работу. Защитит лицензиата. Но помимо этого она защитит и вас – и я имею в виду вас лично. К примеру, ограничивая ответственность лицензиара за потенциальный вред, причиной которого стала его работа.
А что, если я не буду использовать лицензию?
При отсутствии лицензии, ассоциированной с работой, «по умолчанию» действуют авторские права в соответствии с юрисдикцией страны автора. Другими словами, никогда не считайте, что «отсутствие лицензии» подразумевает, что другие люди могут делать с вашей работой что угодно. Всё как раз наоборот: без определенной лицензии вы, автор, не отказываетесь ни от каких прав, предоставленных законом.
Но всегда помните, что лицензия регулирует права и обязанности. Вы когда-нибудь задумывались, почему в тексте многих лицензий содержится написанное БУКВАМИ В ВЕРХНЕМ РЕГИСТРЕ предупреждение о гарантиях, предоставляемых вместе с продуктом – или, куда чаще, об отсутствии таковых? Это делается для того, чтобы защитить владельца работы от пользовательских ожиданий и того, что подразумевается какая-либо гарантия. Последнее, что вам нужно – это чтобы на ваш открытый код подали в суд!
Могу ли я использовать кастомную (собственную) лицензию?
Да, можете. Но, вероятно, не стоит этого делать.
Являясь договором, лицензия не может иметь приоритет над территориальными законами. Отсюда возникает сложность соблюдения лицензионных прав в глобализированном мире. Скорее всего, будет проще (я имею в виду, менее сложно) защитить в суде «стандартную» лицензию. Собственно, такие дела уже защищались в некоторых юрисдикциях и на них можно ссылаться в качестве прецедента. Очевидно, что нельзя сказать то же про кастомную лицензию.
К тому же, кастомные лицензии (прозванные «лицензиями для тщеславных») могут оказаться несовместимыми с другими лицензиями, результатом чего станет плохая совместимость вашей работы.
Могу ли я использовать несколько лицензий?
Да. Мульти-лицензирование – и в особенности двойное лицензирование – встречается нередко. Это особенно верно, если вы хотите создать бизнес на основе своего бесплатного произведения. В этом случае ваш проект, скорее всего, будет выпушен одновременно и под лицензией FOSS (Free And Open Source Software - Свободное и открытое программное обеспечение), и под коммерческой лицензией.
Другое применение мульти-лицензирования – для улучшения совместимости, чтобы ваша работа была сочетаема с работами, опубликованными под другими условиями, или для удовлетворения иных потребностей и запросов пользователей. По этой причине некоторые проекты выпускаются под несколькими лицензиями FOSS.
Но предупреждаю: не все лицензии совместимы между собой! Опять же, я рекомендую не переизобретать колесо и использовать лицензии, совместимость которых широко известна, если вы хотите пойти этим путём.
Могу ли я поменять лицензию «позже»?
Да. Держатель авторских прав отвечает за условия лицензирования. Довольно просто поменять лицензию, если вы – единственный автор. Но если, в качестве яркого примера, Линус Торвальдс захочет выпустить ядро Линукс под другой лицензией, ему, вероятно, сначала потребуется согласие нескольких тысяч других участников этого проекта. Это невозможно в действительности.
Для проекта средней величины это реально. И на самом деле делалось, как вы увидите в некоторых примерах ниже.
Какую лицензию Open Source мне следует использовать?
Хорошо, допустим, мне удалось убедить вас в том, что вам нужна стандартная лицензия. Но какую выбрать? Окончательный выбор за вами. И в сети достаточно хороших компараторов, которые помогут вам в этом выборе. Вот некоторые их них:
http://oss.ly/licdif
https://choosealicense.com/ или https://choosealicense.com/appendix/
https://opensource.org/licenses
https://tldrlegal.com/
Но как всегда в юридических вопросах, надежнее всего будет прочитать – и понять – официальный текст самих лицензий. Для этого может потребоваться помощь профессионального юриста.
Рассмотрим некоторые общие сведения о наиболее распространённых лицензий, чтобы помочь вам сделать первые шаги в нужном направлении.
Стандартная общественная лицензия GNU (GPL - GNU General Public License)
GPL – одна из наиболее популярных лицензий Open Source. У неё есть несколько версий – но для нового проекта вам лучше рассматривать последнюю из них, на момент написания этой статьи ей является GPL 3.
Поддерживая сильный копилефт, GPL, пожалуй, защищает больше всех остальных свободных лицензий. Что может быть, как плюсом, так и минусом, в зависимости от вашей точки зрения. Основной концепт GPL – что любые производные работы должны также выпускаться под этой лицензией.
Copyleft - это практика предоставления людям права свободно распространять копии и измененные версии произведения с условием сохранения тех же прав в производных работах, созданных позже.
Сильный копилефт;
Лицензиаты могут модифицировать работу;
Лицензиаты могут распространять исходный код вместе с производной работой;
Производная работа должна выпускаться на тех же условиях.
Популярные проекты
GPL – лицензия, наилучшим образом подходящая для проектов Фонда свободного программного обеспечения (Free Software Foundation - FSF), в том числе за счёт инструментов GNU в основе любой системы Linux. Большие проекты – заведомо коммерческие – часто используют GPL вместе с одной или несколькими другими лицензиями.
Inkscape (векторный графический редактор): GPLv2
Drupal (система управления веб-контентом): GPLv2
MariaDB (базы данных): GPL v2
MySQL (базы данных): GPL и коммерческая лицензия
Qt (кроссплатформенный фреймворк для разработки приложений): LGPL, GPL и коммерческая лицензия— в зависимости от модулей и соглашения об уровне обслуживания (SLA).
Меньшая стандартная общественная лицензия GNU (LGPL - GNU Lesser General Public License)
GPL – лицензия, очень строгая к тому, чтобы каждая производная работа публиковалась на тех же условиях, что и исходная, и с открытым исходным кодом. Это особенно неудобно в случае с библиотеками, которые служат «кирпичами» для крупных программных продуктов: если библиотека выпущена под GPL, то любое использующее её приложение должно также выпускаться под GPL. Эту сложность адресует LGPL.
В отношении библиотек Фонд свободного программного обеспечения (FSF) выделяет три случая:
Ваша библиотека реализует стандарт, который конкурирует с несвободным стандартом. В таком случае широкое распространение вашей библиотеки поможет продвижению свободного ПО. В этой ситуации FSF рекомендует использование довольно либеральной (разрешительной) лицензии Apache (она описана в статье далее).
Ваша библиотека реализует стандарт, уже реализованный другими библиотеками. В этом случае, полный отказ от копилефта никак не послужит продвижению свободного ПО. Для этого случая FSF рекомендует LGPL.
Наконец, если ваша библиотека не конкурирует ни с какими другими библиотеками или стандартами, FSF рекомендует GPL.
Рекомендации FSF имеют преимущественно этические и идеологические основания. В жизни у разработчиков могут быть иные заботы. Особенно если они планирует развивать дело на базе своей лицензированной работы. Ещё раз, возможно, в таком случае стоит присмотреться к двойному лицензированию.
Слабый копилефт (из-за динамического связывания с библиотеками);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты могут выпускать исходный код вместе с производной работой;
Если вы модифицируете работу, её необходимо выпускать на тех же условиях;
Если вы просто используете работу (в качестве библиотеки), нет необходимости выпускать производную работу на тех же условиях.
Популярные проекты
OpenOffice.org 3 (пакет офисных приложений): LGPLv3 — но Apache OpenOffice 4 перешёл на лицензию Apache 2.0.
GTK+, the GIMP Toolkit (библиотека элементов графического интерфейса): LGPLv2.1
CUPS (кроссплатформенная система печати): GPL or LGPLv2, за исключением ОС Apple, — в зависимости от компонентов.
WineHQ (слой совместимости с Windows): LGPLv2.1
GNU Aspell (проверка орфографии): LGPLv2.1
Eclipse Public License (EPL 1.0)
С более слабым копилефтом, чем в LGPL, лицензия Eclipse больше подходит для бизнеса и допускает сублицензирование и создание программного обеспечения (ПО) на основе кода как под EPL, так и под другими лицензиями (даже проприетарными), с условием, что код под другой лицензией вынесен в отдельный модель программного продукта.
Кроме того, EPL предоставляет дополнительную защиту соавторам кода под EPL в случае судебных исков/ущерба, вызванного коммерческой деятельностью, связанной с этой работой.
Слабый копилефт (из-за связанных подключаемых в продукт модулей);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Если вы модифицируете работу, её необходимо выпускать на тех же условиях;
Если вы просто используете работу, нет необходимости выпускать производную работу на тех же условиях
При коммерческом распространении продукта распространители обязаны защитить или выплатить компенсацию оригинальным авторам (под EPL) в случае судебных исков/ущерба в результате коммерческого использования продукта.
Популярные проекты
Очевидно, что EPL – наиболее подходящая лицензия для проектов Eclipse Foundation, в том числе Eclipse IDE. Но она прибрела некоторую популярность и за пределами этого – особенно в мире разработки на Java:
Clojure (язык программирования)
Graphviz (пакет утилит по визуализации графов)
Jetty (сервер для приложений): двойная лицензия EPL1.0/Apache 2.0 с версии Jetty 7
JUnit (фреймворк для модульного тестирования ПО на Java)
Mozilla Public License (MPL)
MPL – лицензия, которая используется для ПО, созданного Mozilla Foundation. Но её применение этим не ограничено. MPL пытается достичь компромисса между строгими лицензиями (такими как GPL) и либеральными лицензиями (такими как лицензия MIT).
«Лицензионной единицей» в MPL является исходный файл. Лицензиарам запрещено ограничивать права пользователей и доступ к любому файлу, на который распространяется MPL. Но один и тот же проект может содержать как файлы под MPL, так и файлы под проприетарной лицензией. Полученный в результате проект может быть опубликован под любой лицензией, при условии, что предоставляется доступ к файлам под MPL.
Слабый копилефт (в связи с отдельными файлами);
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не могут заново лицензировать исходный код под MPL;
Лицензиаты обязаны выпускать исходный код под MPL вместе со своей производной работой.
Популярные проекты
Mozilla Firefox (веб-браузер), Mozilla Thunderbird (почтовый клиент): MPL
LibreOffice (пакет офисных приложений): MPL 2.0
H2 Database Engine (база данных): MPL2.0 и Eclipse License 1.0
Cairo (2D графическая библиотека) MPL 1.1 или LGPLv2.1
Apache License 2.0 (ASL 2.0)
С ASL мы попадаем в мир либеральных свободных лицензий. Но даже FSF в некоторых случаях рекомендует лицензию Apache. Лицензия Apache считается либеральной, поскольку не требует того, чтобы какие-либо производные работы выпускались на тех же условиях. Другими словами, это «не-копилефт» лицензия.
ASL – единственная лицензия, которая используется для проектов Apache Software Foundation. Считающаяся удобной для бизнеса, она получила широкое распространение за пределами этой организации. Можно нередко увидеть проекты корпоративного уровня, выпущенные под этой лицензией.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой.
Популярные проекты
Android (операционная система): ASL 2.0 с некоторыми исключениями (особенно касательно ядра Linux)
Apache httpd (веб-сервер): ASL 2.0
Apache Spark (кластерная вычислительная система): ASL 2.0
Spring Framework (фреймворк для создания корпоративных приложений на Java): ASL 2.0
MIT License
Ещё одна очень популярная лицензия. Возможно, даже самая популярная. Устанавливая совсем немного ограничений на повторное использование, лицензия MIT может быть легко связана с другими лицензиями, будь то GPL или проприетарные лицензии.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой.
Популярные проекты
node.js (среда выполнения для JavaScript): MIT License
jQuery (клиентская библиотека JavaScript): MIT License (до 2012, двойная лицензия MIT/GPL)
Atom (текстовый редактор): MIT License
AngularJS (JavaScript- фреймворк): MIT License
SQLAlchemy (инструментарий SQL и объектно-реляционное отображение для Python): MIT License
Лицензии BSD
Лицензии BSD бывают трёх видов. Оригинальная лицензия «4-х пунктов», «пересмотренная» лицензия, состоящая из 3-х пунктов и «упрощённая» лицензия из 2-х пунктов. По духу все три очень близки к лицензии MIT. И действительно, между упрощенной лицензией BSD и лицензией MIT нет существенных различий.
Лицензии BSD, состоящие из 3-х и 4-х пунктов, содержат больше требований в отношении повторного использования наименований и рекламы. Это полезно учесть, если вы хотите защитить название вашего продукта или марки.
Не-копилефт;
Разрешено коммерческое использование работы;
Лицензиаты могут модифицировать работу;
Лицензиаты должны упоминать соответствующее авторство работы;
Лицензиаты могут распространять производную работу на других условиях;
Лицензиаты не обязаны выпускать исходный код вместе со своей производной работой;
Лицензиаты не могут использовать название продукта или торговую марку оригинального автора для продвижения своей производной работы (лицензии BSD из 3-х и 4-х пунктов);
Лицензиаты обязаны упоминать оригинального автора работы во всех рекламных материалах, ссылающихся на функции или использование этой работы (лицензия BSD из 4-х пунктов).
Популярные проекты
Django (фреймворк для веб-приложений): лицензия BSD из 3-х пунктов
Redis (хранилище данных): лицензия BSD из 3-х пунктов
Ruby (язык программирования): лицензия BSD из 2-х пунктов и кастомная лицензия
Nginx (веб-сервер): лицензия BSD из 2-х пунктов
NetBSD (операционная система): лицензия BSD из 2-х пунктов — лицензия BSD «4-х пунктов» до 2008
В заключение о лицензиях Open Source
Вы дочитали до этого места, поздравляю! Теперь вы понимаете, что лицензирование – это обширная и сложная тема. Но потратить время на то, чтобы выбрать подходящую лицензию для вашего проекта – стоит того, и лучше сделать этот выбор как можно раньше. Это убережёт вас от множества проблем в дальнейшем, и вы сможете направить ваше время и энергию на работу над проектом вместо того, чтобы тратить силы на разборки с авторским правом и юридической совместимостью лицензий.
И помимо нескольких известных лицензий, о которых вкратце рассказано здесь, существует ещё множество других, используемых более или менее широко. Поэтому, не стесняйтесь писать в комментариях о том, какую лицензию вы предпочитаете и почему.
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и Nginx. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент Nginx (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины, Nginx был введен для преодоления ограничений производительности веб-серверов Apache. Nginx, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут в качестве автономного веб-сервера и в качестве внешнего прокси-сервера для Apache и других веб-серверов. Прочитать про установку и настойку этих серверов можно в этой статье
Кстати! Еще у нас есть статья по сравнению Apache против IIS. Welcome 🤓
Краткий обзор Apache
Apache был разработан для доставки веб-контента, доступ к которому осуществляется через Интернет. Он известен тем, что играл ключевую роль в начальном росте интернета. Apache - это программное обеспечение с открытым исходным кодом, разработанное и поддерживаемое открытым сообществом разработчиков и работающее в самых разных операционных системах. Архитектура включает в себя ядро Apache и модули. Основной компонент предоставляет базовую серверную функцию, поэтому он принимает соединения и управляет параллелизмом. Различные модули соответствуют различным функциям, которые выполняются по каждому запросу. Конкретное развертывание Apache может быть сконфигурировано для включения различных модулей, таких как функции безопасности, управление динамическим контентом или для базовой обработки HTTP-запросов.
Модель «один сервер делает все» стала ключом к раннему успеху Apache. Однако по мере увеличения уровня трафика и увеличения количества веб-страниц и ограничения производительности настройка Apache на работу с реальным трафиком усложнялась.
Краткий обзор Nginx
Nginx был разработан специально для устранения ограничений производительности веб-серверов Apache. Производительность и масштабируемость Nginx обусловлены архитектурой, управляемой событиями. Он значительно отличается от подхода Apache. В Nginx каждый рабочий процесс может одновременно обрабатывать тысячи HTTP-соединений. Следовательно, Nginx - это легковесная, масштабируемая и высокопроизводительная реализация. Эта архитектура делает обработку больших и флуктуирующих нагрузок на данные гораздо более предсказуемой с точки зрения использования ОЗУ, использования ЦП и задержки.
Nginx также имеет богатый набор функций и может выполнять различные роли сервера:
Обратный прокси-сервер для протоколов HTTP, HTTPS, SMTP, POP3 и IMAP
Балансировщик нагрузки и HTTP-кеш
Интерфейсный прокси для Apache и других веб-серверов, сочетающий гибкость Apache с хорошей производительностью статического контента Nginx
Apache против Nginx: сравнение их богатых наборов функций
Простота
Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех.
Nginx, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей Nginx должны быть очень осторожны, чтобы создавать эффективный и точный код, без сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций.
Производительность
Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим. Давайте посмотрим статистику по этому вопросу.
Статический контент
Nginx работает в 2,5 раза быстрее, чем Apache, согласно тесту производительности, выполняемому до 1000 одновременных подключений. Другой тест с 512 одновременными подключениями показал, что Nginx примерно в два раза быстрее и потребляет меньше памяти. Несомненно, Nginx имеет преимущество перед Apache со статическим контентом. Поэтому, если вам нужно обслуживать одновременный статический контент, Nginx является предпочтительным выбором.
Динамический контент
Результаты тестов Speedemy показали, что для динамического контента производительность серверов Apache и Nginx была одинаковой. Вероятная причина этого заключается в том, что почти все время обработки запросов расходуется в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов.
Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере, не полагаясь на внешние компоненты. Эти динамические процессоры могут быть включены с помощью динамически загружаемых модулей.
Nginx не имеет возможности обрабатывать динамический контент изначально. Чтобы обрабатывать PHP и другие запросы на динамический контент, Nginx должен перейти на внешний процессор для выполнения и дождаться отправки визуализированного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его издержки будут присутствовать только для динамического содержимого.
Поддержка ОС
Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. Nginx также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX.
Безопасность
И Apache, и Nginx являются безопасными веб-серверами. Apache Security Team существует, чтобы предоставить помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках.
Гибкость
Веб-серверы могут быть настроены путем добавления модулей. Apache долго загружал динамические модули, поэтому все модули Apache поддерживают это.
Nginx Plus (Nginx Plus - это программный балансировщик нагрузки, веб-сервер и кэш контента, построенный на основе открытого исходного кода Nginx) также использует модульную архитектуру. Новые функции и возможности могут быть добавлены с программными модулями, которые могут быть подключены к работающему экземпляру Nginx Plus по требованию. Динамические модули добавляют в Nginx Plus такие функции, как геолокация пользователей по IP-адресу, изменение размеров изображений и встраивание сценариев Lua в модель обработки событий Nginx Plus. Модули создаются как Nginx, Inc., так и сторонними разработчиками.
Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживаются обоими веб-серверами.
Поддержка и документация
Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был популярен так долго, поддержка сервера довольно распространена повсеместно. Для главного сервера и для основанных на задачах сценариев, связанных с подключением Apache к другому программному обеспечению, имеется большая библиотека документации первого и стороннего производителя.
Наряду с документацией многие инструменты и веб-проекты содержат инструменты для начальной загрузки в среде Apache. Это может быть включено в сами проекты или в пакеты, поддерживаемые отделом упаковки вашего дистрибутива.
Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности времени, в течение которого он был доступен.
В прошлом для Nginx было трудно найти исчерпывающую англоязычную документацию из-за того, что большая часть ранней разработки и документации была на русском языке. Однако на сегодняшний день документация заполнена, и на сайте Nginx имеется множество ресурсов для администрирования и доступной документации от третьих лиц.
Ngnix против Apache: Сравнение лицом к лицу
Подводя итог, вот табличное представление наборов функций:
ОсобенностьApacheNginxПростотаЛегко разрабатывать и внедрять инновации благодаря своей модели «одно соединение на процесс»Сложный в разработке, поскольку он имеет сложную архитектуру для одновременной обработки нескольких соединений.Производительность - Статический контентМедленно в отображении статического контентаВ 2,5 раза быстрее чем Apache и потребляет меньше памятиПроизводительность - Динамический контентОтличная производительность для динамического контентаОтличная производительность для динамического контентаПоддержка операционной системыПоддерживает все ОС - Unix, как и WindowsПоддерживает все ОС - как Unix, так и Windows, однако производительность в Windows сравнительно менее стабильна.БезопасностьЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныГибкостьМожно настроить, добавив модули. Apache имел динамическую загрузку модулей дольше всего.Nginx версии 1.11.5 и Nginx Plus Release R11 представили совместимость для динамических модулей.Поддержка и документацияОтличная поддержка и документация доступны, как это было на рынке в течение очень долгого времени.Несмотря на слабое начало поддержки и документации для Nginx, он быстро рос, поэтому теперь у него есть отличная поддержка ресурсов и доступная документация.
Nginx и Apache - Совместная работа
Для многих приложений Nginx и Apache хорошо дополняют друг друга. Очень распространенным начальным шаблоном является развертывание программного обеспечения Nginx с открытым исходным кодом в качестве прокси-сервера (или Nginx Plus в качестве платформы доставки приложений) перед веб-приложением на основе Apache. Nginx выполняет тяжелую работу, связанную с HTTP - обслуживает статические файлы, кэширует содержимое и разряжает медленные HTTP-соединения - так что сервер Apache может выполнять код приложения в безопасной и защищенной среде.
Итак, что выберите? Apache или Nginx?
Как видно, Apache и Nginx являются мощными, гибкими и способными. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.
YUM (Yellowdog Updater, Modified) это менеджер пакетов, используемый в Red Hat, CentOS и других дистрибутивах Linux, использующих RPM Package Manager. Yum используется для установки, обновления, удаления или других манипуляций с пакетами, установленными на этих Linux-системах.
В этом руководстве мы расскажем вам о команде yum update - что она собой представляет, как ее использовать, и о различных командах, которые могут вам пригодиться, для обновления установленных пакетов в вашей системе.
Как работает команда Yum Update?
Yum update - это команда, используемая для обновления приложений, установленных в системе. Если команда выполняется без указания имён пакетов, она обновит все установленные в системе пакеты.
$ yum update
При выполнении этой команды, yum начнёт с проверки своих репозиториев на наличие обновленных версий программного обеспечения, установленных в вашей системе на данный момент. На приведенном ниже Рисунке А показан тип вывода, который вы обычно видите при первом запуске команды yum update.
Как вы можете увидеть,на выводе yum сначала перечисляет запрашиваемые репозитории, которые являются стандартными репозиториями по умолчанию для CentOS: AppStream, Base и Extras.Ниже, приводится список различных пакетов, для которых были найдены обновления.
В конце этого вывода yum отобразит "Сводку транзакций", которая показывает общее количество пакетов, которые должны быть установлены и обновлены.
В данном примере на Рисунке Б, идёт обновление 166 пакетов и установка 6 новых пакетов.
На случай, если вам интересно почему устанавливаются новые пакеты, когда мы должны были только обновить приложения, некоторые новые пакеты программного обеспечения могли стать частью этого дистрибутива Linux, или некоторые обновленные приложения могут полагаться на дополнительные пакеты, которые еще не установлены.
После просмотра списка программного обеспечения, которое yum планирует обновить, вы можете подтвердить эти изменения, набрав "y" и нажав клавишу Enter.
Затем Yum начнёт выполнять обновления, которые могут занять некоторое время в зависимости от скорости вашего соединения и самой системы.
После его завершения вы получите итоговую сводку, как показано на рисунке В, в которой будут перечислены все пакеты, которые были успешно обновлены, а также все ошибки, которые могли возникнуть.
Обновление без проверки gpg
В Linux для проверки подлинности RPM пакетов используются GPG ключи. Если при запуске обычной команды обновления yum вы столкнётесь с ошибкой типа "Package NameOfPackage.rpm is not signed .. install failed!", вы можете с лёгкостью пропустить проверку подлинности RPM пакетов с помощью опции -nogpgcheck.
$ yum update --nogpgcheck
Данный параметр указывает команде yum игнорировать проверку GPG подписей пакетов. И будет полезен в тех случаях, когда у вас есть неподписанный пакет или просто нет ключа GPG.
Обновление из локального репозитория
Можно настроить локальные репозитории для команды yum при выполнении обновлений. Это зачастую делается, если вам нужно использовать yum для обновления пакетов, которые не включены в репозитории по умолчанию, или если вам нужно обновить автономную систему.
Прежде всего, поместите все ваши обновленные RPM-файлы в новую папку. В этом примере мы будем использовать /root/rpms. Затем перейдите в следующую директорию, где вы можете увидеть все файлы репозитория для yum:
$ cd /etc/yum.repos.d
Чтобы настроить собственный репозиторий, создадим новый файл в этом каталоге.
$ vi MyRepo.repo
Непосредственно в вашем repo-файле задайте параметры в указанном формате, меняя строки по мере необходимости:
[MyRepo]
name=My Local Repo
baseurl=file:///root/rpms
enabled=1
gpgcheck=0
Большая разница между локальным и удаленным repo заключается в строке "baseurl", где протокол file:// указывает на локальный файл, в то время как удаленный на протоколы http:// или ftp://.
Как только файл будет сохранен, примените правильные права доступа как показано ниже:
$ chmod 644 MyRepo.repo
Теперь репозиторий может быть готов к использованию. Перед тем, как пытаться выполнить команду yum update убедитесь, что вы очистили кэш yum использую команду:
$ yum clean all
Просмотр обновлений
Yum может отображать доступные обновления безопасности без их установки, с помощью этой команды:
$ yum updateinfo list security
Если в результатах данные не возвращаются, как на рисунке выше, это означает отсутствие обновлений безопасности для всех установленных в вашей системе программных продуктов.
Обновление конкретного пакета
Если вам нужно обновить определенный пакет без запуска обновления для каждого установленного приложения, просто укажите имя пакета в вашей команде yum update.
$ yum update name-of-package
Можно указать несколько пакетов, разделенных пробелом. Вам нужно, чтобы название пакета было указано идеально, чтобы yum смог найти его в своих репозиториях; если вы не уверены в наименовании пакета, сначала проверьте, какие пакеты в настоящее время доступны для обновлений:
$ yum check-update
Обновить все, кроме одного пакета
Если вам нужно выполнить команду yum update, но вы хотите исключить какой-либо пакет из списка обновляемых, вы можете указать опцию -exclude.
Распространённая ситуация, когда администраторы могут счесть это необходимым, связана с обновлениями ядра, так как это основные обновления, которые могут привести к непредсказуемым ошибкам на рабочем сервере. Однако, они всё же могут выполнить команду для обновления менее критичных приложений.
Чтобы исключить пакет (в данном примере связанные с ядром):
$ yum update --exclude=kernel*
Звездочка действует как подстановочный знак, в случае, если существует несколько взаимосвязанных пакетов или вы не знаете полного имени пакета.
В качестве альтернативы:
$ yum update -x 'kernel*'
Исключение нескольких пакетов
Вы можете исключить несколько пакетов с большим количеством опций -exclude.
$ yum update --exclude=kernel* --exclude=httpd
Используйте этот символ, как в примере выше, или же символ -x, столько раз, сколько потребуется.
Проверить, когда было запущено последнее обновление
Для того чтобы увидеть список транзакций с датой и временем их выполнения, воспользуйтесь командой yum history.
$ yum history
На приведенном выше скриншоте, вы можете видеть, что последний раз обновление программного обеспечения yum было 4 января.
Откатить (отменить) обновления
Отличительной особенностью "yum" является то, что она позволяет отменить последнее обновление, тем самым восстанавливая обновленные пакеты до их предыдущих версий.
Каждому действию yum (установка, обновление, удаление и т.д.) присваивается идентификатор транзакции, и этот идентификатор следует указывать при отмене обновления yum.Чтобы посмотреть список идентификаторов операций для недавних действий Yum, воспользуйтесь этой командой:
$ yum history
На скриншоте выше вы можете видеть, что последней операцией, выполненной с помощью yum, была установка пакета httpd. Отмена установки или обновления работает таким же образом, поэтому в этом примере мы отменим последнюю установку httpd. Как показано на скриншоте, эта операция имеет ID 7.
Чтобы отменить это изменение и откатить программу на предыдущую версию, выполните эту команду:
$ yum history undo 7
Как обычно, yum подведёт итоги внесённых изменений и спросит, хотите ли вы продолжить с помощью подсказки Y/N.Если ввести Y, то указанная транзакция будет отменена.
Чистка неудачного обновления Yum
Если не удалось успешно обновить один или несколько пакетов при выполнении команды "yum update", в систему могут быть установлены дубликаты пакетов (2 версии одной и той же программы). Иногда, следуя вышеописанным инструкциям по откату, можно устранить проблему.
Если это не сработает, вы можете удалить дубликаты пакетов вашей системы с помощью данной команды:
$ package-cleanup --dupes
Yum хранит в кэше информацию для пакетов, метаданных и заголовков. Если вы столкнулись с ошибкой,очистка кэш-памяти yum является хорошим первым шагом в устранении неполадок. Для этого используйте следующую команду:
$ yum clean all
Игнорирование ошибок
При обновлении или установке пакета для его корректной работы может потребоваться дополнительное программное обеспечение. Yum знает об этих зависимостях и попытается разрешить их во время обновления, устанавливая или обновляя необходимые дополнительные пакеты.
Если у вас возникнут проблемы с установкой необходимых компонентов, это приведёт к ошибке и не позволит продолжить работу. Это может стать проблемой, если у вас есть другие пакеты, которые необходимо обновить.
Чтобы дать инструкции yum продолжить обновление других пакетов и пропустить пакеты с поврежденными зависимостями, вам следует указать параметр -skip-broken в команде yum update.
$ yum update --skip-broken
Вывести список пакетов, которые нужно обновить.
Выполнение команды Yum update в обычном режиме без дополнительных опций выведет список всех доступных обновлений.
$ yum update
Если вы хотите посмотреть дополнительную информацию о доступных обновлениях пакета, введите эту команду:
$ yum updateinfo
Чтобы посмотреть информацию касательно обновлений безопасности, которые доступны для системы, введите эту команду:
$ yum updateinfo security
Разница между командами yum check update и yum list update
Хотя эти две команды звучат одинаково, но есть разница между проверкой обновлений и списком обновлений в yum.
$ yum list updates
Команда list updates, показанная выше, перечислит все пакеты в репозиториях, для которых доступны обновления. Имейте в виду, что некоторые пакеты в репозиториях могут быть вообще не установлены в вашей системе.
$ yum check-update
Указанная выше команда check-update позволяет проверять наличие обновлений без вмешательства пользователя. Это команда подойдёт в тех случаях, если вы пишите скрипт для проверки обновлений.
Если есть пакеты с доступными обновлениями, команда check-update вернёт значение 100, а если нет доступных обновлений, то значение 0. При обнаружении ошибки возвращается значение 1. Используйте эти значение чтобы надлежащим способом написать свой скрипт.
Уведомление о наличии доступных обновлений
Есть несколько пакетов, которые могут помочь управлять обновлениями yum в вашей системе.Некоторые из них могут даже уведомлять администраторов, если есть обновления, которые можно установить.Один из таких сервисов называется yum-cron.
Для начала установите yum-cron используя yum:
$ yum install yum-cron
Установите службу yum-cron для запуска при загрузке:
$ systemctl enable yum-cron.service
$ systemctl start yum-cron.service
Настройте параметры yum-cron внутри конфигурационного файла с помощью vi или предпочитаемого вами текстового редактора:
$ vi /etc/yum/yum-cron.conf
В этом файле вы можете указать, должны ли обновления применяться автоматически или нет. Если вы хотите только получать уведомления, введите данные электронной почты в файле конфигурации. В любое время, когда появятся обновления для вашей системы, yum-cron отправит вам электронное письмо.
apply_updates = no #don’t apply updates automatically
email_from = root@localhost
email_to = admin@example.com
email_host = localhost
Какой порт использует yum update
При проверке обновлений yum использует порт 80. Если вы загляните внутрь файлов репозитория в вашей системе, то вы увидите, что все ссылки внутри начинаются с http. Таким образом, для нормального функционирования yum на брандмауэре нужно прописать правило и открыть порт 80.
Yum update против upgrade
До сих пор в этом руководстве мы говорили только о команде yum update, но есть и другая очень похожая команда: yum upgrade.
$ yum upgrade
Существует небольшая разница между этими двумя командами. Yum update обновит пакеты в системе, но пропустит удаление устаревших пакетов. Yum upgrade тоже обновит все пакеты в вашей системе, но также удалит устаревшие пакеты.
Это по своей сути более безопасный вариант команды yum update, поскольку вам не нужно беспокоиться о случайном удалении необходимого пакета при обновлении программного обеспечения.
Будьте внимательны при вводе команды yum upgrade, так как она может не сохранить некоторые пакеты, которые вы всё ещё используете. Я надеюсь, что вы найдете это руководство полезным при работе с утилитой yum.