Vano01rus, срочно отучаемся от Ctrl-Z. Эта комбинация не завершает приложение, а прерывает его выполнение, оставляя в памяти (см. команды jobs, fg и bg в bash). Прерывать их надо с помощью Ctrl-C.
Для проверки DNS следует использовать host и dig из пакета bind-utils (в нём же есть nslookup для тех, кто привык к Windows).
DNS-сервера выбираются или по порядку, или в режиме round robin. Чтобы работало всё, надо обеспечить, чтобы оба сервера отдавали обе зоны. Например, прописать в каждом из них вторую зону через forward на другой DNS-сервер. Или сделать из каждого из них slave на другую зону (тогда они не запросы будут перенаправлять, а иметь у себя актуальную копию зоны с мастер-сервера). В общем-то, это правильно и удобно, когда оба сервера умеют отвечать на запросы по всем зонам.
В пределах уютного localhost можно поставить локальный DNS, которым раскидать зоны. Например, можно поставить dnsmasq, в конфиге которого описать, какие зоны на какой сервер:
Также, поскольку одна из зон включена в другую, можно в demo.wsr добавить запись:
int NS srv.int.demo.wsr.
srv.int A 192.168.100.200
И тогда этот DNS-сервер будет корректно отдавать NS-запись домена int.demo.wsr, позволяя с этого DNS получать запросы по обоим зонам.
Вообще, я бы посоветовал более конкретно формулировать именно имеющуюся проблему, а не свои неудачные попытки её решить. А то в процессе обсуждения выясняется, что вопрос совсем не про то, что написано в вопросе. См. также, что такое XY problem.
Starvings, для того, чтобы пользователь получил что-то на текущей странице в ответ на свои действия, надо реализовать реакцию на его действия на js (в виде, допустим, обработчика события onClick на каком-то элементе), php для этого не нужен.
Можно в php вывести что-то типа:
<script>alert('Ляля тополя');</script>
и пользователь при закрытии выскочившего сообщения останется на той же странице. Но на неё он всё равно попадёт с переходом.
Современный способ состоит в том, что обработчик запроса пользователя вызывается javascript через fetch на URL, который представляет API (к примеру, RESTful-сервис) для обработки этого запроса и возвращает машиночитаемый ответ, который js разбирает и использует для обновления html (точнее, DOM) на фронте. Пользователь остаётся в пределах одной страницы, его действия (нажатия на кнопки и ссылки) приводят к вызову javascript-кода, который без перезагрузки страницы дёргает нужные вызовы API. На js пишут так называемый frontend, а на любом другом языке серверный API-интерфейс - так называемый backend. Сайт фактически превращается в так называемый SPA - Single Page Application.
Если хочется изучать именно php и не загружать себе голову излишне раньше времени, я бы посоветовал пока обойтись без js и не париться с перезагрузками страницы. В конце концов, тридцать лет с этим прекрасно люди жили и до сих пор живут. Изучать современные подходы к web всё равно придётся, но это сродни изучение математики, начиная сразу с дифференциальных уравнений, пропустив изучение арифметики.
yotonick, это всё говорит о том, что не надо копировать чужой код без понимания, что именно он делает (да, именно так, каждую строчку до последнего символа надо понимать).
При выполнении запроса надо проверить, что он что-то вернул, и уж потом из его результата что-то брать. Это может вполне даже не быть внештатной ситуацией. Например, пользователь обращается к боту в первый раз, бот обнаруживает, что по пользователю нет данных и явным образом создаёт для него запись в базе, заполняя её значениями по умолчанию. А если запись есть - возвращает данные из неё.
Vano01rus, resolv.conf - это конфигурация штатного функционала ресолвинга имён в IP. Где и как находятся эти IP, какие у них имена и как они разделены на зоны - неважно. Причём в этом файле можно указать только DNS-сервер (nameserver) и не указывать больше ничего - и всё будет работать.
Отдельно можно указать в search до 6 (да, есть лимит) суффиксов, которые будут дописываются к имени при поиске. Например, если в search указано foo bar local ru, то ресолвинг имени yandex будет пытаться перебирать yandex.foo, yandex.bar, yandex.local, yandex.ru по очереди.
Всё это не надо путать с системным hostname, который может быть только один и который к resolv.conf никакого отношения не имеет.
В сухом остатке: можно сделать какие угодно IP на интерфейсах и как угодно обозвать их в DNS (или даже в /etc/hosts, но это будет работать только в пределах этого хоста), для этого в resolv.conf ничего вообще делать не нужно.
TosterIQ, для начала надо вернуть /usr/bin/perl на штатный perl и никогда больше так не делать. В /usr/bin всё должно быть из пакетов и консистентно, если злоупотреблять ковырянием того, что стоит из пакетов, то обновление системы может превратиться в сложный квест (тут советую обратить внимание на rpm -V, который проверяет контрольные суммы файлов в пакете, правда, не уверен, что для symlink он что-то проверит). Устанавливаемый из исходников софт следует или прописывать в PATH, или в /usr/local/bin (как вариант, в $HOME/bin, если это нужно одному пользователю), или, в конце концов, пользоваться полным путём.
В данном случае можно удалить просто весь prefix (только отдельно /usr/bin/perl починить не забыть). Просто многие не указывают его, и используется по умолчанию /usr/local, после чего вычистить софт становится сложнее, так как он вперемешку с другим вручную установленным. Установка в отдельный префикс - это неплохая практика - пусть она и создаёт некоторые свои проблемы (необходимость включать много разных каталогов в PATH, необходимость передавать кастомные ключи сборки при использовании самосборных библиотек итд итп).
kaktak255, гугл регулярно ломает скорость в yt-dlp и в нём регулярно пытаются это починить. Поэтому первый очень важный совет - время от времени его надо обновлять.
bengur2, это в любом случае плохое решение. Всё настраивать надо при сборке образа или в инициализирующем сервис скрипте. Все данные, которые нужны скрипту, хранить в локальном каталоге, который через volume прокидывать внутрь. Тогда перенос будет заключаться в копировании данных и запуске нового контейнера в новом месте.
Собственно, нужно сразу это выучить: docker принципиально предполагает, что контейнер может быть пересоздан в любой момент. Тот же docker-compose пересоздаёт контейнеры при любом изменении параметров безо всяких вопросов. Поэтому проектировать работу с docker надо с учётом этого важного обстоятельства.
Насколько я понимаю, при редактировании нельзя добавить к сообщению обычную клавиатуру. Следует удалить inline-клавиатуру, а потом отправить новое сообщение с обычной.
Все мечтают открывать рекламные и вирусные ссылки так, чтобы пользователь этого не увидел. Разумеется, это нельзя сделать так просто. Это действие квалифицируется как стопроцентно зловредное.
Atlant-19, MediaWiki имеет некоторые настройки в своём конфиге, но в основном идея состоит в том, что там всё управляется через Wiki-движок. В частности, можно кастомизировать движок в целом или персональный пользовательский профиль с помощью специальной страницы, содержащей js (см. https://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D... ).
Таким образом, потенциально можно сделать так, что js будет при наличии каких-то элементов на странице с координатами автоматически добавлять div с картой и нужными маркерами в окрестностях необходимой локации.
Точно так же можно сделать, чтобы слайдер добавлялся с помощью js. В том числе он может выгружать список данных из какой-нибудь специальной станицы или даже из категории (возможно, это не самое эффективное решение, но само то, что такое можно делать и даже не одним способом, уже само по себе интересно).
Для Википедии за 20 лет много чего понаписали, что может быть само по себе интересно. Например, wikidata.org с возможностью получения данных через SPARQL-запросы. Вообще, в мире нет другого вики-проекта и вики-движка такого масштаба и такой пользовательской базы.
Другие вики-движки в основном нацелены на другие задачи и другие масштабы. Например, есть свои движки в trac или redmine, они нужны для ведения документации проектов (там заодно есть возможность вести таски, прицеплять репозитории исходного кода и всё такое). Есть xwiki, который бесплатный конкурент confluence и также в своей основной идеологии призван вести документацию в пределах проектов или организаций/структурных подразделений. Есть всякие dokuwiki и ещё много чего. Все они не так заточены под мультиязычность в википедийном стиле через interwiki, так что придётся что-то ещё пилить. Например, самому писать скрипты, которые будут через API доставать данные из разных языковых проектов и проставлять недостающие перекрёстные ссылки. А в Википедии это есть прям из коробки. Но придётся привыкать к специфическому подходу к представлению информации и её редактированию.
Данил Тунев, да, захудалый сайт может сам заморочиться, настроить fail2ban и всё такое. Но многим проще один раз подключить готовый бесплатный сервис и не заморачиваться больше.
GNOME - это НЕ X-сервер, это Desktop Environment, состоящий из большого количества приложений, включая WM (windows manager). Его можно использовать с разными X-серверами, в том числе и с Xvfb. Но поскольку это не для человека, а только для запуска браузера, лучше поставить что-то особенно лёгкое, типа openbox.
Для проверки DNS следует использовать host и dig из пакета bind-utils (в нём же есть nslookup для тех, кто привык к Windows).
DNS-сервера выбираются или по порядку, или в режиме round robin. Чтобы работало всё, надо обеспечить, чтобы оба сервера отдавали обе зоны. Например, прописать в каждом из них вторую зону через forward на другой DNS-сервер. Или сделать из каждого из них slave на другую зону (тогда они не запросы будут перенаправлять, а иметь у себя актуальную копию зоны с мастер-сервера). В общем-то, это правильно и удобно, когда оба сервера умеют отвечать на запросы по всем зонам.
В пределах уютного localhost можно поставить локальный DNS, которым раскидать зоны. Например, можно поставить dnsmasq, в конфиге которого описать, какие зоны на какой сервер:
А в resolv.conf написать просто 127.0.0.1.
Также, поскольку одна из зон включена в другую, можно в demo.wsr добавить запись:
int NS srv.int.demo.wsr.
srv.int A 192.168.100.200
И тогда этот DNS-сервер будет корректно отдавать NS-запись домена int.demo.wsr, позволяя с этого DNS получать запросы по обоим зонам.
Вообще, я бы посоветовал более конкретно формулировать именно имеющуюся проблему, а не свои неудачные попытки её решить. А то в процессе обсуждения выясняется, что вопрос совсем не про то, что написано в вопросе. См. также, что такое XY problem.