Опубликован релиз HTTP-сервера Apache 2.4.43 (выпуск 2.4.42 был пропущен), в котором представлено 34 изменения и устранено 3 уязвимости:...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52676
Systemd? В моём apache?Интересно, что за интеграция имеется в виду, может кто знающий рассказать?
Может надо документацию почитать? https://httpd.apache.org/docs/trunk/mod/mod_systemd.html
или исходный код? https://github.com/apache/httpd/blob/trunk/modules/arch/unix...
Особо криминала там нет. Кроме того что системд не нужен.
Ну вот смотри, я два раза кликнул по mod_systemd, нажал правой кнопкой, выбрал Search in Google, и перешел по первой же ссылке и прочитал. Попробуй сам, может, тоже получится
Так что за интеграция ?
Вместо того, чтобы своё “оригинальное» кэпство на несколько строк размазывать, можно было бы и ответить.. в комментарии к вопросу то
Socket activation, очевидно.
На странице с описанием модуля написано "This module does not provide support for Systemd socket activation."
Это называется "вместо портянки на баше, надо всего лишь юнит на пару строк"))
> Это называется "вместо портянки на баше, надо всего лишь юнит на пару
> строк"))Всегда можно было и без notify, просто с ним удобнее.
Вангую, что подключение к сокету, открытому systemd, а не самим апачем.
плохая из тебя ванга. Нет, эта фича не реализована.
> Вангую, что подключение к сокету, открытому systemd, а не самим апачем.Ну так системда это давно уже делает почти для всех сетевых демонов, перехватывая на себя все сокеты. Благодаря этому фокусу, не осилившие баш, свято верят, что система стала грузится быстрее, хотя на самом деле, зависимости демонов она не решает, так как невозможно стартануть сеть, не подготовив файловую систему и т.д. и т.п. Эта гидра делает обманку в виде сокетов к которым ПОТОМ по мере старта подключаются демоны. В итоге задача достигнута, - контроль над проходящим трафиком, и люди не осилившие баш видят заветный логин в несколько секунд (не смотря на то, что демоны все еще грузятся в фоне... ) и продолжают скакать "как все", - к простоте, забывая, что за все плюшки надо платить за overengineered прослойку, цель которой проста как мир, - подгребсти всех под себя и иметь власть и профит
Дак вот почему у системды так неустойчиво сетка работает...
этот юнит обычно выключен по-умолчанию ;-)Потому что он вообще никак не работает, только блокирует загрузку намертво.
это ты еще не напарывался на systemd-networkd-wait-online и связанные с ним глюки. Мы ж из себя все такие суперпараллельные, что теперь нельзя просто дождаться завершения работы ifup-скрипта, надо череззадничным способом пытаться _угадать_ - online мы, или еще совсем немного не совсем.(это я его _по_делу_ пытался употребить - мне на самом деле надо было НЕ запускать демон, пока нужный ему интерфейс не поднялся, и это не eth0, поэтому он не поднимется быстро)
> люди не осилившие баш видят заветный логин в несколько секунд
это им и раньше видеть ничто не мешало. Он, как и тогда, правда, не работает, поскольку пол-системы еще не стартовало, но пока они свой пароль набирают одним пальчиком - скорее всего, успеет.
>и продолжают скакать "как все", - к простотеКто нэ скаче, тот ...
Нет это модуль чтобы системд мог запустить сервис с апачем в режиме Type=notify. А нужен этот тип сервиса чтобы апач мог сообщить системд что он запустился. И чтобы это сделать надо писать низкоуровневый модуль и подключать заголовочные файлы из системд (привязка, зависимости, вендоринг, тевоизация).
не было печали, купила баба петуха...
Просто из интереса. Для чего в 2020 году кому-то использовать апач? Какие причины есть для этого?
Не троллинг, просто хочу услышать мнение людей. Есть же более надёжные альтернативы, например nginx.
Потому что твои "надежные" альтернативы не являются надежными. И уж что автор нжинкса вложил в своё поделие и с какой целью это ему одному известно. А если он еще раз откажется делать что ему сказали на него еще раз Рамблер наедет или не Рамблер.
А апач сделан добрыми людьми с добрейшими намерениями?
Да.
Чтобы не трогать то, что работает. Удивишься, но на том же mod_perl дофига чего работает до сих пор.Для новых проектов смысла не вижу.
Хм, а я для своего сайта на php взял apache. Думал это вроде как стандарт веб-серверов, а с ним что-то не так, оказывается, не пойму, однако. А все ведь работает, эх
пхп итак медленный и выбор любого другого вебсервера ему никак не поможет(в плане производительности), так что можно расслабится и получать удовольствие.
А кто быстрый и кому выбор поможет?
Го быстрый и ему апач может помешать. Го можно просто оставить со своим встроенным вебсервером.
Встроенные говносерверы в разных хипстерских недоязычках на практике под нагрузкой оказываются намного хуже апача - если последний уметь готовить.
как раз главное преимущество апача - что уметь готовить там особо нечего, не nginx чай, требующий ненужных знаний о внутреннем устройстве - ну разьве что уметь НЕ выбрать какой-нибудь васян-вокер, обещающий заживление шрамов и рассасывание трупных пятен.А тесты игогошечной поделочки мы тут, помнитсо, обсуждали уже - в сферическом вакууме, если не пытаться действительно отдавать какой-то контент, да еще ж, б-же упаси, с диска, а сразу захлопывать сессию - рвет всех. Жаль что нах не нужно никому.
> б-же упаси, с диска, а сразу захлопывать сессию - рвет всех.А, вечная проблема всех этих гошечек и прочей "классики" по сравнению с префорком в том, что падение процесса рвёт всех, да. Но это скорее проблема менталитета, модель изолированных запросов в эти головы не ложится.
Поможет, если кроме php есть еще хотя бы статика.
Если это не нагруженный кинотеатр то нет.
если это не васянский "кенотеатр" с локалхоста - то там, увы, не совсем статика.
Медленный - это питон.
Пых вполне шустрый, особенно, последних версий и с некоторыми “добавками”
Если у тебя посещаемость в полтора анонима, то, конечно, разницы никакой.А если много, и среди них далеко не все с гигабитными каналами - то смотри: пхп нужно по процессу на запрос. Процесс - штука тяжелая, много процессов - много контекст-свитчей, мало процессов - не успеют обработать все запросы. Ходят к тебе 100 пользователей в секунду с медленных 3g/edge соединений. Апач будет держать процесс, пока они медленно и печально не получат ответ. А nginx - это 1-2-3-4... воркеров (больше, чем ядер, запускать бессмысленно), быстренько прочитает ответ от php-fpm в память, а потом эффективненько отдаст всем сразу в рамках epoll based fsm.
Вместо php-fpm можно и апач с mod-php запустить слушать юникс-сокет, а на него проксировать nginx-ом. Принцип ничего не изменится, разве что апач памяти больше жрет.
открою вам страшную тайну: "процесс штука тяжелая" - это только в вашей б-жественной десяточке.
В современных (~2000+ года издания) юникс-лайк системах процесс сам по себе - примерно так же "тяжел", как и userspace реализация "epoll based fsm". Разница в реальном мире есть, но не на порядки, а максимум в разы.
И если процесс висит на синхронном socket write - твое "3g" никаких контекст-свитчей не вызывает, пока весь буфер не уедет на ту сторону.А проблемы обычно возникают (на современном железе и на современных задачах) как раз с быстрыми юзерами на быстром канале, запросы которых просто не успевает обрабатывать сам php. nginx тут может ограничено помочь, кэшируя его выхлоп, но это очередная область магии, доступная (без последствий в виде залипшей в кэше устаревшей информации) немногим.
В свое время кое-кто делал замены на bitrix + memcache + nginx в разных комбинациях. Получилось что собственное кэширование битрикса (а ведь сложно найти большее уродство) - эффективнее любого внешнего, не знающего, что можно кэшировать, а что бессмысленно.
Для сотен процессов (а больше с пхп без кэша в статику и не выйдет) действительно в разы. А для статики - на порядки (раздай префорком c10k, я посмотрю).Кэшировать html в мемкеше - это вообще затея дурная, кэшировать надо в фс и отдавать статикой. В современных ОС, а не в вашей десяточке, вся свободная память используется под кэш фс. Соответственно, задача в случае cache hit сводится к отдаче статики, см. выше.
я не очень понимаю, кому и что за статику такую (не помещающуюся целиком в буфер, и досвидос) ты раздаешь, что оно у тебя "порядки". Если рекламные баннеры - там да, есть ньюансы, еще с 90х годов.У меня получалось именно в разы, но я от рекламы далек нынче.
> Кэшировать html в мемкеше - это вообще затея дурная
это нормальная затея, когда у тебя быстрый канал и лишние лаги совсем и не нужны.
Как не нужна и пилежка диска ненужными операциями. Кэш фс в твоей современной ос - г-но разработки 98го года, вымываемое первым же 180G.avi
А в несовременной свои приколы, там тоже лучше лишних файловых операций не делать, когда результат по определению неперсистентен.
Идет удаление файлов кеша.
Обработано: 2982
Размер обработанных файлов: 4.26 МБ
Удалено: 2897
Размер удаленных файлов: 3.73 МБ
(мне ждать надоело, дальше будут цифры и похуже) вот и зачем этим мусором насиловать диск?Но там вывод был не в том что мекэш плохо - мемкэш хорошо. bitrix cache оказался лучше nginx - что с мемкэшом, что с on-disk.
Хотя из общих соображений и казалось, что должно быть наоборот, и сборка на ходу из кэшированных кусочков проклятым пехепе должна быть в разы медленнее. Она и медленней. Но зато не вымывается и не протухает без необходимости.
И это не статика, ага.
> ньюансыдальше не читал
Видосы это отдельная история, их надо раздавать через aio, с этим в линуксе все было плохо до последнего времени, а новое api еще нигде не внедрено.На freebsd же nginx+aio работает шикарнейше как сейчас так и 10 лет назад.
Зачем раздавать статику префорком? Её можно раздавать чем угодно, хоть тем же апачем с эвентом и mod_proxy в отдельной инстанции, хоть haproxy, хоть чёртом лысым (тем же nginx'ом). Апач и хорош как раз тем, что у него есть десяток областей применения, в отличие от.
затем что если у тебя не свалка порно - то статику вполне можно раздавать префорком. Который понятен и ведет себя предсказуемо. А упрешься ты все равно не в favicon.ico, а в динамику.
> можно раздавать префорком. Который понятен и ведет себя предсказуемо. А упрешьсяА нахрена? Для раздачи статики и проксирования есть mpm_event, который в этом плане не хуже нгинха.
Хуже.В nginx все через евенты. А mpm_event - это тредпул, управляемый евентами.
Сравнимо с тредами для раздачи крупной статики в nginx, которые суть костыль из-за неработоспособного линуксового AIO.
У всех AIO рабочее, кроме nginx. Ни на что не намекает, не.
Настолько рабочее, что в ядре запилили новое AIO. Вместо того, которое у всех рабочее, да.
> Настолько рабочее, что в ядре запилили новое AIO. Вместо того, которое у всех рабочее, да.Интерфейс у AIO угрёбищный, да, но вот за не рабочесть... Просто кто-то конкретный не осилил :)
> В современных (~2000+ года издания) юникс-лайк системах процесс сам по себе - примерно так же "тяжел", как и userspace реализация "epoll based fsm". Разница в реальном мире есть, но не на порядки, а максимум в разы.Не совсем. Всё зависит от нагруженности сервера. Я нашёл-таки хороший обзор[1] с графиками, чтобы не совсем голословно излагать. До ~1000 конкурентных соединений к серверу подходы prethreaded, preforked и epoll различаются несущественно, в то время как threaded, poll и особенно forking подходы заметно отстают (в разы, как ты и говоришь). А при дальнейшем наращивании количества соединений начинаются интересности, сначала forking резко теряет производительность, потом poll. Threaded подход не столь резко, но тоже теряет. preforked сопротивляется лучше, и его протестировали поэтому аж до 8k конкурентных соединений. А когда мы переваливаем за 10k соединений, оба остающихся подхода (prethreaded и epoll) показывают резкий провал производительности.
В сравнении с вендой *nix'овый процесс может и легче, но это не значит, что он лёгкий. Это довольно крупная штука, и использовать столь крупную штуку для обработки http-запроса -- это очень часто равносильно стрельбе из пушки по воробьям: это накладные расходы на переключения контекстов. Кроме того, в ядерном шедулере есть алгоритмы рассчитывающие приоритет задач, и эти алгоритмы имеют сложность O(n) от количества задач, а это значит, что само по себе количество запущенных процессов начинает влиять на общую производительность системы. С этим можно справляться, наверное: можно пореже переключать задачи, а может быть можно какой-нибудь особо тупой вариант шедулера использовать, который с приоритетами справляется за время O(1) -- я не вдавался в подробности, даже не знаю, если честно, возможно ли это. Но такие решения будут влиять на поведение _всей_ системы, а не только веб-сервера, и поэтому они не всегда применимы.
Когда же мы засовываем всю асинхронность в юзерспейс, то, во-первых, мы можем подобрать такую реализацию, которая лучше ложится на задачу, не затрагивая при этом других частей системы (забив на приоритеты запросов, например, и обслуживая их по мере завершения блокирующихся вызовов, которые выполняются в процессе обработки запроса), и, во-вторых, мы можем избежать переключений контекстов: если какая-то неблокирующаяся часть обработки запроса выполняется микросекунды, то тогда мы можем выполнить много таких неблокирующихся частей обработки разных запросов без единого переключения контекста. То есть, техническая реализация всё равно может использовать переключения контекстов, но это софтварные переключения софтварных контекстов, которые сводятся к тому, чтобы сохранить регистры в текущем стеке, переключить стек, восстановить регистры из стека -- это на порядок (а после всех этих meltdown'ов, возможно и на два порядка) быстрее переключения контекстов между процессами через ядро. На многопроцессорной системе, эти маленькие софтварные неблокирующиеся куски тоже можно перекидывать между процессорами, точнее позволить процессам вытаскивать разблокировавшиеся куски из общей очереди и выполнять, и таким образом забивать полезной работой _все_ процессоры. Полезной работой -- это в смысле не расчётом приоритетов задач и переключением контекстов, а обработкой запросов.
Но всё это становится возможным, только если мы запускаем потоков столько, сколько есть процессоров, и разруливаем блокирования при выполнении запросов серверу в юзерспейсе, а это значит, что мы используем epoll.
С другой стороны, возможно, это не имеет отношения к php. Я в него очень давно заглядывал, он мне не понравился идеологически, и больше я не обращал на него внимания. Если я чего-то ещё и помню о нём, то это всё, я подозреваю, устарело лет на десять. Может быть php настолько тормозной, что ему начинает не хватать CPU гораздо раньше, чем ядру, даже при подходе "по fork'у на запрос".
[1] https://unixism.net/2019/04/linux-applications-performance-i.../
Про ПХП не знаю, но перлу по процессу на запрос не нужно. Один FastCGI-процесс обрабатывает много запросов.
С пыхом аналогично. Но и там, и там - процесс на запрос. Просто (кроме специальных кейсов) процесс не умирает после запроса, а обрабатывает следующий.
Имеется в виду не то, что на каждый запрос создается новый процесс, а то, что один процесс одновременно может обрабатывать только один запрос. Это называется префорк-модель. И в перле, и в пхп оно. (Да, в перле есть еще треды, но это отдельное минное поле).
Для веб разработки на пэхэпэ
Пока ввиларибо разворачивают окружение на докер
В вилабаджо пушат вопросы с фичами
Коммиты с фичами*
а код для комита берется из вопроса на stackoverflow, да, мы поняли твою опечатку ;-)
Хуже. Пока в вилы-рибы **утся с развёрнутым на докере и убирают голую задницу из сети, в вилы-баджо уже вовсю насилуют композер.
> Просто из интереса. Для чего в 2020 году кому-то использовать апач?адекватная система конфигурирования, вообще лишенная arcane magic (rewrite отделен от всей остальной конфигурации, используется ограниченно и легко отлаживаем - тоже отдельно от всего остального), а не "if is evil", но вот вам шесть костылей и четыре подпорки вместо двух частных случаев его использования, вложенные конфигурации работают не так как кажется, поэтому используйте уродливый include везде где надо один и тот же набор параметров.
Простой и понятный mod_php, вместо танцев с граблями вокруг fastcgi_params и fastcgi.conf и отдельными вокруг fpm-враппера.
Поддержка изоляции виртуальных хостов по разным userid, полезная далеко не только shared hosting.
А единственный, в общем-то, непонятно даже, минус ли - некоторые пережитки юникс-идеологии, немодные в эпоху новых стандартов.
То есть непонятно скорее для чего в 2020м году нужен геморрой с nginx, автор которого таки да, еще и русский. В 2010м было понятно, полуработающий апач2 и никакой другой альтернативы.
Вот не могу не согласиться.
Причины две: это лень учится новому и вторая это использование апача на шаред хостингах, где у юзеров нет доступа к файлам конфигурации сервера но есть .htaccess
типичный снобизм модных-современных "быстрообучаемых", которые на самом деле ни нового не умеют, ни старого.И да, .htaccess полезен не только и не столько на shared.
Аргументы типичных анонимов опеннета
нет, типичный аноним тут вякает про "лень учиться".Ну разумеется, он чувствует себя офигенно умным, зазубрив полсотни бесполезных заклинаний.
1) Чему там учиться-то? Любой знающий нормально конфиги Apache nginx настроит с полпинка за полтора часа чтения мануала. Потому что уровень сложности и ограниченность применения у этих двух софтин немножко отличается, примерно на порядок.
2) Смысл учиться тому, что потенциально мертво? После нескольких перемен с владением и разработкой nginx я бы на него не лочился, честно говоря, а наоборот делал phaseout, потому что этот коврик может быть выдернут в любой момент.
> Чему там учиться-то? Любой знающий нормально конфиги Apache nginx настроит с полпинка за полтора
> часа чтения мануала.не настроит. Если конфиг апача был не на одну страничку с единственным блоком.
Начните с рассказа о том, в каком месте "документации" (которой у nginx по факту нет, есть записки углем на манжетах, сделанные в процессе быстроляпания фич) описаны занятные события, приведшие к появлению fastcgi.conf рядом с fastcgi_params.
А заодно покажите мне подобный кусок ненужного дерьма на два экрана в конфигурации апача.
> Смысл учиться тому, что потенциально мертво?
зарплата.
К сожалению, еще лет десять будем в требованиях к вакансии читать "nginx".
> К сожалению, еще лет десять будем в требованиях к вакансии читать "nginx".Ну если совсем не жмёт и не студент, то лучше такие сразу пропускать, это значит, что всё слепили из того, что было, не задумываясь. Желания это разгребать как-то 0.00.
Необязательно. Есть еще пожелания технических руководителей - которые про nginx "знают" (а может даже и в самом деле знают и руками когда-то рулили) а про апач - только слышали, что это немодно, и "а нам после тебя кто это все поддерживать будет".То есть и новые проекты, к сожалению, тоже будут ляпаться не на том чем надо, а на том что модно.
В конце-концов, большинству из них и правда пох.
> Необязательно. Есть еще пожелания технических руководителей - которые про nginx "знают"
> (а может даже и в самом деле знают...Вот именно про это и речь, такое надо стороной обходить.
> Для чего в 2020 году кому-то использовать апач?У 1С есть модуль для апача и iis и нету для nginx (по крайней мере раньше так было)
А его и быть не может, потому что там придётся либо (Fast)CGI городить, либо свой web-сервер. То есть nginx это таки не web-сервер, это скорее proxy с некоторой функциональностью web-сервера (static files).
>Для чего в 2020 году кому-то использовать апач?Среди веб серверов Apache то-же самое, что BIND среди name servers
Например то, что nginx не умеет нормально в динамику без прослоечек. Когда для nginx появится тот же mod_perl или mod_php - поговорим.
Когда апач научится проксировать запросы не отдельными процессами/потоками, тогда и поговорим. Когда апач начнёт буферизовать вывод приложений, уже отработавших в процессе/потоке, тогда поговорим. Когда апач научится проксировать IMAP, POP3, TCP, UDP, тогда поговорим.Знаете, не надо гоночный болид сравнивать с карьерным самосвалом. Если одно превратится в другое, то образуется пустующая ниша, которую быстро займут другие.
> Когда апач научится проксировать IMAP, POP3, TCP, UDP, тогда поговорим.Извини, родной, но апач - это не прокси с доп. функцией отдачи статических файлов, а таки web-сервер. Смотрю, многие путают.
Ну и да, когда мне всерьёз надо что-то проксировать, я беру haproxy например, или специфику, а не непонятное полупроприетарное поделие с непонятным статусом.
в котором, кстати, еще и HA откушен начисто, оставлен только в коммерческом ненужно за тысячи зеленых бумажков. Не смотря на клятвенные заверения десять лет назад, что фичи хоть и с задержкой но будут переноситься в шва6одную версию.Кому, нахрен, сегодня нужен прокси - без HA, и зачем он такой сдался-то? Я вот вынужден был эти чудопрокси прятать за коммерческим прокси-сервером. Нет, хрен вам, не nginx ни разу. Он и дороже, и всем хуже.
> Кому, нахрен, сегодня нужен прокси - без HA, и зачем он такойЕсли вам внезапно нужен какой-то специфичный HA для прокси, задачей которого в т.ч. может быть обеспечение HA... либо у вас очень-очень специфичная задача, либо что-то пошло не так. Чем keepalived не устроил?
тем что мне не нужен лишний набор костылей и подпорок под прокси, "задача которого - в обеспечении HA", чтобы еще их теперь отдельно тамагочить и отдельно за каждым горшок выносить.
Не говоря уже о том что происходит в таком случае при падении одного из хостов.Если бы под рукой не было ентер-прайс решения, умеющего state sync (и дешевле, между прочим, nginx/pro) - я бы, возможно, заменил те nginx'ы на haproxy, поскольку в замороченной rewrite engine не нуждаюсь совершенно.
Теоретически, то же самое можно обеспечить на сетевом железе, оно умеет track, но, опять же - а смысл?
> Когда апач научится проксировать IMAP, POP3, TCP, UDP, тогда поговорим.А еще винт форматировать в ext4, это ведь тоже задача HTTP-сервера.
> А еще винт форматировать в ext4, это ведь тоже задача HTTP-сервера.Ну зачем же в ext4, сразу в APFS. Стильно, модно, молодёжно.
Поподробнее. Что именно он не умеет?
> Поподробнее. Что именно он не умеет?Покажи модуль динамики для нгинха, который не прокси к стороннему серверу.
Что ты имеешь в виду? Что бы nginx рендерил страницы?
> Что ты имеешь в виду? Что бы nginx рендерил страницы?Уже ничего. Рендерит страницы таки браузер.
Серверы рендерят html страницы и отдают их браузеру, браузер рендерит изображение из этого html
Генерят, а не рендерят, школоло.
Ну то есть замечаний к nginx у тебя нет? Только желание обсуждать что рендер - это не корректный термин для описания сборки страницы?
А ты похоже ещё и читать не умеешь. Ладно, забей.
> Просто из интереса. Для чего в 2020 году кому-то использовать апач?Практика показала, что в условиях отдачи статических файлов, размером ~1GB
апач выигрывает у nginx'а как по скорости отдачи, так и по нагрузке на систему.
Сервера на CentOS. Профилирование и всевозможный тюнинг нджинкса, консультации
с "лучшими нджинксоводами" на протяжении многих месяцев не позволили
приблизиться к показаниям производительности, котрые демонстрировал apache.
И, тем не менее, к 2013-му году, я, втихаря, ничего не говоря начальству, потихоньку изжил
apache в нашем production'е лишь по причине того, что nginx удобнее в настройке.
покажите, ЧТО вы там такое понанастраивали, что невменяемая конфигурация nginx оказалась "удобнее в настройке". Я не могу в это поверить.
>Добавлен новый модуль mod_systemd, обеспечивающий интеграцию с системным менеджером systemd.Следующий шаг, включить Apache в состав Systemd
systemd-apached
systemd-httpd
погодите, вроде ж уже был давно?
>>Добавлен новый модуль mod_systemd, обеспечивающий интеграцию с системным менеджером systemd.
> Следующий шаг, включить Apache в состав Systemd
> systemd-apachedЭтому модулю 100 лет в обед в том же рхеле/центосе, ничего нового не случилось, просто теперь в апстриме.
> Добавлен новый модуль mod_systemd, обеспечивающий интеграцию с системным менеджером systemdПри init/upstart такой χеρни не было
тебе вот в этот тредик: https://www.opennet.me/openforum/vsluhforumID3/120248.html#8
> Travis CIДевляпсы добрались и до Apache httpd? Очень сочувствую проекту, что-то изменится...
А чем плох? Везде пишут, что CI тип удобно
>интеграция с системным менеджером systemdБольше интеграций богу интеграций!
Все Апач загадил себя системдом.
Не включай в конфигурацию сборки этот модуль.