Временная ошибка при разрешении deb debian org
Обновлено: 02.07.2024
У меня есть приложение Rails, которое я хочу развернуть с помощью Docker на сервере Ubuntu. У меня уже настроен Dockerfile для приложения, сейчас я хочу просмотреть конфиг nginx в его контейнере.
Я выполнил приведенную ниже команду, чтобы запустить контейнер nginx в интерактивном режиме:
Сейчас я пытаюсь установить редактор nano, чтобы просмотреть конфигурацию nginx ( nginx.conf ), используя следующие команды:
Однако, когда я запускаю первую команду apt-get update , я получаю следующую ошибку:
Я очень хорошо проверил, что это никак не связано с подключением к сети. Мне понадобится помощь. Спасибо.
Пограничный случай (не ваша проблема, но я включаю ее сюда): у меня была та же проблема, и я запускал сервер BIND9 на хосте докера. Это позволяло разрешение локальной сети (192.168.0.0/24), но контейнеры подключались из сети 172 докеров и поэтому не могли разрешить. Добавление 172.0.0.0/8 в BIND ACL для доступа решило эту проблему.
11 ответов 11
Я просто перезапустил Docker, и это сработало для меня.
перезагрузка sudo service docker или sudo /etc/init.d/docker restart
До того, как мы столкнулись с этой проблемой, docker работал нормально. Если у вас никогда не работал докер, у вас, вероятно, другая проблема.
Обычно мне помогает перезапуск службы, но иногда мне нужно перезапустить виртуальную машину, чтобы она снова заработала.
Мне помогло указание DNS-сервера для контейнеров Docker.
Создайте файл /etc/docker/daemon.json со следующим содержимым:
и перезапустите службу Docker:
Если у вас запущен VPN, остановите его и повторите попытку. Это решило для меня!
Возможно, сеть на виртуальной машине не обменивается данными с сетью по умолчанию, созданной докером во время сборки (моста), поэтому попробуйте сеть "хост":
решил это для меня в сентябре 2021 года! Обратите внимание: я не уверен, что это было необходимо, но перед запуском этой команды я отключился от своего VPN.
Вот как я это решил:
Запустите контейнер docker для приложения в интерактивном режиме, в моем случае это контейнер nginx:
Выполните приведенную ниже команду, чтобы предоставить другим пользователям разрешение на чтение файла resolv.conf:
Примечание. Если эта проблема возникла на вашем хост-компьютере (ОС Ubuntu Linux), а не в контейнерах Docker, выполните ту же команду, добавив к ней sudo в терминале хост-компьютера:
Постарайтесь выйти из интерактивного терминала bash после запуска:
Затем откройте новый интерактивный терминал bash и снова запустите команды:
Теперь все должно работать нормально.
Я легко решил это с помощью:
Также подтвердите /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf
Под Debian, как пользователь root, я запускал:
Это решило проблему для меня.
Затем снова создайте и запустите контейнер.
У меня была та же проблема, и в моем случае это был контроль доступа к файлам.
Я использую расширенные списки управления доступом в корневой папке докера и не осознавал этого, потому что они унаследованы от указанной выше папки (глупая идея тестировать докер в «чистом» каталоге, где разрешения устанавливаются с помощью расширенных списков управления доступом).
Это привело к ситуации, когда "/etc/resolv.conf" имел настройку "640" внутри работающего контейнера Docker со знаком "+", обозначающим расширенные списки управления доступом. Но на образ не были установлены расширенные списки управления доступом, и он не мог их обработать.
Странно то, что, насколько я вижу, все остальные сетевые инструменты работали (например, ping ), но только apt не мог получить доступ к преобразователю DNS.
После удаления расширенных ACL-списков из корня докера и установки обычных ACL-списков внутри работающего контейнера все заработало.
Аналогичен ответу "Promise Prestion", но решен навсегда и для новых контейнеров.
Я установил nginx в докере, и мне нужно также установить nano.
Когда я запускаю apt-get update в контейнере, я получаю следующую ошибку:
Я безуспешно пытался обновить серверы имен в resolv.conf.
Не знаю, что делать дальше, поскольку я не могу установить какие-либо пакеты.
ЛарсР
Член
вы не должны устанавливать дополнительные пакеты, так как это не стандартный Debian, а устройство, основанное на Debian.
Apt с выпуском Scale был отключен, потому что слишком много людей. только что использовал apt upgrade и сломал зависимости промежуточного программного обеспечения, что привело к поломке системы.
натепихлер
Неофит
вы не должны устанавливать дополнительные пакеты, так как это не стандартный Debian, а устройство, основанное на Debian.
Apt с выпуском Scale был отключен, потому что слишком много людей. только что использовал apt upgrade и сломал зависимости промежуточного программного обеспечения, что привело к поломке системы.
да, но для truenas. Внутри контейнера вы можете использовать apt. Это работает, если я устанавливаю «официальное» приложение, но не когда я делаю это из командной строки
среталла
Сморщенный мудрец
Мне не совсем понятно, что, по вашему мнению, делает --ip 192.168.0.95.
Почему бы вам не убрать это?
- 4 xSamsung 850 EVO Basic (500 ГБ, 2,5 дюйма) — — виртуальные машины/ячейки
- 1 xASUS Z10PA-D8 (LGA 2011-v3, Intel C612 PCH, ATX) — — Dual Socket MoBo
2 xWD Green 3D NAND (120 ГБ, 2,5 дюйма) -- Загрузочные диски (может быть, повозиться с тредом, чтобы поставить ссылку подкачки сюда тоже)- 1 твердотельный накопитель Kingston UV400 емкостью 120 ГБ — загрузочный диск (столкновение с ошибкой 3D NAND/TRIM при выборе исходного зеленого цвета WD, сбой очистки и отображение поврежденных файлов ОС) Решил обойтись без зеркала и использовать сценарий резервного копирования конфигурации
- 2 xIntel Xeon E5-2620 v4 (LGA 2011-v3, 2,10 ГГц) — — 8 ядер/16 потоков на чип
- 2 xNoctua NH-U9S (12,50 см)
- 1 xCorsair HX1200 (1200 Вт) — блок питания для поддержки 24 жестких дисков + несколько твердотельных накопителей и плат PCI.
- 4 ОЗУ xKingston Value (32 ГБ, DDR4-2400, ECC RDIMM 288)
- 2 вентилятора Noctua NF-A8 PWM Premium 80 мм для корпуса компьютера
3 вентилятора охлаждения Noctua NF-F12 PWM- 3 xNoctua NF-F12 PPC 3000 PWM (120 мм) * позже в ветке Stux было отмечено, что 1500 об/мин недостаточно для охлаждения жестких дисков. Corsair Commander Pro для управления вентиляторами (см. скрипт и код)
- 1 xNORCO 4U для монтажа в стойку 24 отсека для жестких дисков SATA/SAS 6G с возможностью горячей замены Сервер для монтажа в стойку RPC-4224
- 6 внутренних кабелей xCableCreation Mini SAS HD, кабель Mini SAS SFF-8643 — Mini SAS 36-контактный SFF-8087
- 1 плата логического контроллера xLSI 05-25699-00 9305-24i 24-портовый адаптер главной шины SAS 12 Гбит/с PCI-Express 3.0
- TrueNAS Core 12.0-U8
- Использовать существующие диски 8 x 10 ТБ WD Red, 8 x 6 ТБ WD Red, 8 x 4 ТБ WD Purple
КОРПУС: Fractal Node 804
МБ: ASUS x-99M WS
ЦП: Xeon E5-2620v4 + блок охлаждения Corsair H60
ОЗУ: CRUCIAL 64 ГБ DDR4-2133 ECC RDIMM
Жесткий диск: WD RED 3TBx8
SSD: 4 xSamsung 850 EVO Basic (500GB, 2.5") -- ВМ/Jails
HBA: LSI 9300-16i
ОС: 1 x Kingston UV400 120GB SSD - загрузочный диск
БП: Corsair RM1000
Версия: TrueNAS CORE 12.0-U8
ВЕНТИЛЯТОРЫ: 3xFractal R3 120мм - 3 спереди, 1 сзади Corsair Commander Pro для управления вентиляторами (см. скрипт и код )
ВЕНТИЛЯТОР ЦП: 1xCorsair H60 Радиатор ЦП — передняя
Сетевая карта: Intel EXPI9402PTBLK Pro, двухгигабитный адаптер (плюс 2 встроенных сетевых адаптера Intel, 1x 210, 1x 218)
Хост VM/Docker, использующий ESXi и запускающий pfSense вместе с FreeNAS (добавлена отдельная сдвоенная сетевая карта Intel, выделенная для виртуальной машины pfSense)
Система тестирования TrueNAS CORE:
КОРПУС: корпус Old Silverstone HTPC
МБ: ASUS x-99M WS
ЦП: Xeon E5-2620v4 + блок охлаждения Corsair H60
ОЗУ: CRUCIAL 32 ГБ DDR4-2133 ECC RDIMM
/>Жесткий диск: WD RED 8 ТБ x 3
ОС: 1 x Kingston UV400 120 ГБ SSD — загрузочный диск
Блок питания: Corsair RM1000
Версия: TrueNAS CORE 13.0 BETA
2x Intel NUC под управлением TrueNAS SCALE 22.02.0
64 ГБ ОЗУ
Intel i7 10-го поколения
Твердотельный накопитель Samsung NVME 1 ТБ, QVO SSD 1 ТБ
Загрузка с Samsung Portable T7 SSD USBC< /p>
CASE: Fractal Node 304 под управлением TrueNAS SCALE 22.02.0
МБ: ASUS P10S-I Series
ОЗУ: 32 ГБ
ЦП: Intel(R) Xeon(R) CPU E3- 1240L v5 @ 2,10 ГГц
Жесткий диск: 3 диска WD RED и несколько твердотельных накопителей
Блок питания: Fractal ION 2+ 650 Вт
Ошибка «Временный сбой в разрешении имени» возникает, когда система не может преобразовать имя веб-сайта в IP-адрес. Хотя ошибка иногда появляется из-за потери подключения к Интернету, существует несколько причин, по которым она может появиться в вашей системе.
Это руководство поможет вам найти и устранить ошибку "Временный сбой в разрешении имен".
- Права Sudo или root
- Рабочее подключение к Интернету
Эта ошибка появляется, когда пользователь пытается связаться с веб-сайтом с помощью такой команды, как ping:
Система не может связаться с DNS-сервером и возвращает ошибку.
Наиболее распространенной причиной этой ошибки является файл сетевой конфигурации resolv.conf и неправильно настроенный брандмауэр. Шаги по устранению ошибки в обоих случаях приведены ниже.
Способ 1: неправильно настроенный файл resolv.conf
resolv.conf — это файл для настройки DNS-серверов в системах Linux.
Для начала откройте файл в текстовом редакторе, например nano.
Убедитесь, что файл resolv.conf содержит хотя бы один сервер имен. Строки со списком серверов имен должны выглядеть так:
Если в файле нет сервера имен, добавьте хотя бы один. 8.8.8.8 и 8.8.4.4 — это популярные DNS-серверы, принадлежащие Google, но вы можете добавить в этот список любой работающий DNS-сервер.
Сохраните файл и выйдите.
Затем перезапустите службу преобразователя DNS.
В случае успеха приведенная выше команда ничего не возвращает. Проверьте, правильно ли настроены ваши новые серверы имен, проверив связь с веб-сайтом:
Если вы видите, что команда ping передает и получает данные, ваш DNS-сервер работает правильно.
Неправильно настроенные разрешения
Если ваш файл resolv.conf содержит действительные DNS-серверы, но ошибка не устранена, это может быть связано с неправильно настроенными правами доступа к файлу. Измените владельца файла на пользователя root с помощью следующей команды:
Измените права пользователя, чтобы разрешить всем пользователям в системе читать файл:
Повторно проверьте связь с веб-сайтом.
Если ошибка вызвана неправильными правами доступа к файлу, приведенные выше команды успешно устранят ее.
Метод 2: ограничения брандмауэра
Еще одной причиной ошибки "Временный сбой в разрешении имен" может быть брандмауэр, блокирующий один или оба следующих порта:
- порт 43, используемый для поиска в Whois
- порт 53, используемый для разрешения доменного имени
Откройте порты в UFW Firewall
Введите следующую команду, чтобы разрешить трафик через порт 43 с помощью брандмауэра UFW:
UFW подтверждает, что правило успешно обновлено.
Повторите команду для порта 53.
Перезагрузите UFW с помощью следующей команды:
Вывод подтверждает, что операция прошла успешно.
Откройте порты в firewalld
Некоторые дистрибутивы Linux, такие как CentOS, используют firewalld в качестве брандмауэра по умолчанию. Синтаксис для открытия порта 43 в firewalld:
firewalld выводит слово "успех" .
Повторите команду для порта 53.
Перезагрузите брандмауэр.
Проверьте соединение, проверив связь с веб-сайтом.
Примечание. Ознакомьтесь также с нашей статьей об устранении неполадок DNS.
В этой статье приведены способы устранения неполадок и исправления ошибки «Временный сбой при разрешении имен» в Linux. Чтобы узнать больше о диагностике проблем, связанных с DNS, прочитайте «Как использовать команду dig в Linux».
Марко Алексич — технический писатель в phoenixNAP. Его врожденное любопытство ко всему, что связано с ИТ, в сочетании с более чем десятилетним опытом написания, преподавания и работы в областях, связанных с ИТ, привело его к техническому письму, где у него есть возможность применить свои навыки и сделать технологии менее пугающими для всех.
Бывают ситуации, когда администраторам необходимо отключить firewalld для тестирования или переключиться на другой инструмент брандмауэра, например iptables. В этом руководстве показано, как отключить и остановить брандмауэр в CentOS 7.
Брандмауэр UFW — это простое в использовании решение для управления настройками брандмауэра сервера. В этом руководстве показано, как отключить и включить брандмауэр Ubuntu UFW с помощью командной строки.
По умолчанию большинство сетей настроены на работу с DNS-серверами, предоставляемыми интернет-провайдером. В этом руководстве показано, как изменить DNS-серверы имен на вашем компьютере с Ubuntu.
DNS впервые появился в начале 1980-х годов. Он представляет собой систему взаимосвязанных серверов, на которых хранятся зарегистрированные доменные имена и IP-адреса.
Я настраивал сервер Apache, используя образ ubuntu:latest, и во время этого процесса я столкнулся с необычной ошибкой, из-за которой я вообще ничего не мог получить на моем док-компьютере Ubuntu. Я получаю сообщение об ошибке, как показано на снимке экрана ниже.
После трех дней поиска и поиска в Google мне удалось решить эту проблему, и я надеюсь, что это поможет кому-нибудь решить эту проблему и сэкономит вам драгоценные 72 часа.
На данный момент вы, вероятно, перезапустили механизм Docker. возможно, удалил и установил снова, и все равно ничего не работает. Помните, что мы должны сначала понять проблему, прежде чем мы даже начнем ее решать.
Вот фрагмент моего dockerfile
Итак, когда дело доходит до шага 3, который
Причина этой проблемы:
Возможно, что сетевое подключение для Docker не подключено, и это может привести к странным ситуациям. Иногда подключение к Интернету для Docker не работает должным образом и может привести к странным ошибкам по нескольким причинам. чтобы сначала выяснить, не происходит ли сбой поиска DNS в образах докеров.
Как проверить, не является ли проблема DNS:
Если вы видите что-то похожее на изображение ниже, это, очевидно, означает, что он не может разрешить DNS
Почему это происходит?
Дело в том, что если Docker не находит локально определенный DNS-сервер в вашем файле /etc/resolv.conf, контейнеры по умолчанию будут использовать DNS-сервер Google 8.8.8.8 для разрешения DNS.
В некоторых организациях, где общедоступные DNS намеренно заблокированы для использования, эта проблема, скорее всего, возникнет. В этом случае контейнеры Docker, использующие конфигурацию по умолчанию, не смогут разрешить DNS, а это означает, что Интернет из контейнеров полностью недоступен.
Как это исправить?
Для этого есть быстрое и постоянное исправление для всей системы. Я рекомендую быстрое исправление, если вы временно находитесь в сети с ограничениями и вам нужно запускать контейнеры напрямую.
Хотя в большинстве случаев вам может понадобиться, чтобы это работало в вашей системе и для решения любых других проблем, зависящих от Docker. Для этого используйте постоянное исправление.
Нам нужно использовать собственный DNS-сервер (который переопределяет DNS Docker) для запуска контейнера Docker. Самое приятное в этом то, что довольно легко запустить контейнер Docker напрямую с собственным DNS-сервером.
Давайте сначала получим адрес нашего DNS-сервера. Это можно найти в Ubuntu, выполнив эту команду:
Чтобы запустить контейнер Docker с этим DNS-сервером, укажите флаг --dns для команды запуска. Например, давайте запустим команду, которую мы использовали для проверки работы DNS:
В вашей корневой папке, где у вас есть файл Docker, вы можете запустить эту команду, которая указывает докеру использовать ту же сеть, что и ваша локальная сборка докера --network=host -t my-image-name .
Обновить демон Docker
вам необходимо изменить настройки DNS демона Docker. Вы можете установить параметры по умолчанию для демона docker, создав файл конфигурации демона в /etc/docker/daemon.json
Вы должны создать этот файл со следующим содержимым на двух серверах, во-первых, на DNS-сервере вашей сети, а во-вторых, на DNS-сервере Google, чтобы использовать его в случае, если этот сервер недоступен:
Читайте также: