Bug 17498
| Summary: | Проблема установки 127.0.0.1 для имени хоста | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Evgeny Sinelnikov <sin> |
| Component: | alterator-net-eth | Assignee: | Mikhail Efremov <sem> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P2 | CC: | ahmedsayeed1982, boyarsh, erthad, evg, iv, kipruss, ldv, mike, rider, sem, vitty, zerg |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
| Bug Depends on: | |||
| Bug Blocks: | 17727, 22600 | ||
пока не понятно что с этим делать ибо hostname должен резолвится, а искуственного интеллекта не хватает. Тут жуткая проблема и проявляется она так:
если задать /etc/hosts вида:
127.0.0.1 localhost.localdomain localhost
127.0.0.1 server.saratov.etersoft.ru server
то ряд программ, которые проводят поиск имени хоста, даже притом, что выставлен правильный hostname находят localhost.localdomain.
Так себя ведут сервер KDC из krb5-kdc (после чего он перестаёт нормально обрабатывать запросы с самого себя), а также python:
>>> socket.getfqdn()
'localhost.localdomain'
Хотя если задать список хостов наоборот
127.0.0.1 server.saratov.etersoft.ru server
127.0.0.1 localhost.localdomain localhost
то питон лечится, а вот сервер KDC продолжает не узнавать своего IP. Дело в том, что он стартует на фиксированном интерфейсе, а хоть имя у нас и становится нормальным, но первый IP хоста всё равно идёт как 127.0.0.1
В итоге, после перенастройки имени хоста альтератором необходимо чинить /etc/hosts вручную.
(In reply to comment #2) > Тут жуткая проблема и проявляется она так: Я знаю что некоторые программы начинает колбасить. Предложите решение. Спрашивать явно пользователя (особенно пользователя desktop) о том нужно ли ему биндить hostname на 127.0.0.1 бесполезно. Нужна какая-то автоматика. > Я знаю что некоторые программы начинает колбасить. Предложите решение. > В Сусе вместо записи 127.0.0.1 host.f.q.d.n host делают запись 127.0.0.2 host.f.q.d.n host Конечно не идеальное решение, однако помогает от большей части проблем связаных с тем, что многие программы (см. выше пример python) начинают считать каноническим именем машины localhost.localdomain. По крайней мере практически всё, что я тестировал, заработало, и я не вижу, как могло бы что-то сломаться. Предлагаю и у нас сделать так же, благо требуемые изменения минимальны. > > Спрашивать явно пользователя (особенно пользователя desktop) о том нужно ли ему > биндить hostname на 127.0.0.1 бесполезно. Нужна какая-то автоматика. > Полноценная автоматика ("совершенное решение"), мне кажется, выйдет слишком сложной и никому не нужной. А насчет бесполезности спрашивать пользователя я бы поспорил. Администратор сети, уверенный в своём DNS-сервере, может иметь желание снять соответсвующую галочку, особенно если это поможет легко, просто и правильно работать некоторым совсем требовательным приложениям (мне попалось одно такое). В том числе и на машинах пользователей, где установлен desktop. Мысль хорошая. Дима, что скажешь? (In reply to comment #4) > > Я знаю что некоторые программы начинает колбасить. Предложите решение. > > > > В Сусе вместо записи > 127.0.0.1 host.f.q.d.n host > > делают запись > 127.0.0.2 host.f.q.d.n host > > Конечно не идеальное решение, однако помогает от большей части проблем > связаных с тем, что многие программы (см. выше пример python) начинают считать > каноническим именем машины localhost.localdomain. По крайней мере практически всё, > что я тестировал, заработало, и я не вижу, как могло бы что-то сломаться. > Предлагаю и у нас сделать так же, благо требуемые изменения минимальны. > > > > > Спрашивать явно пользователя (особенно пользователя desktop) о том нужно ли ему > > биндить hostname на 127.0.0.1 бесполезно. Нужна какая-то автоматика. > > > > Полноценная автоматика ("совершенное решение"), мне кажется, выйдет слишком > сложной и никому не нужной. А насчет бесполезности спрашивать пользователя > я бы поспорил. Администратор сети, уверенный в своём DNS-сервере, может иметь > желание снять соответсвующую галочку, особенно если это поможет легко, > просто и правильно работать некоторым совсем требовательным приложениям > (мне попалось одно такое). В том числе и на машинах пользователей, где > установлен desktop. > В рамках решения этой проблемы, сегодня родилась идея написать NSS-модуль fallback, который быть ставился последним в цепочке hosts файла nsswitch.conf и разрешал бы имя хоста в 127.0.0.1 Тем самым вопрос об установке имени хоста разрешился бы динмически, без необходимости при смене хоста править /etc/hosts. В нашем же случае устранялся бы ещё один неприятный момент, связанный с тем что записи вида 127.0.0.1 у нас добавляются, а это приводит к накоплению ненужного мусора, который кроме как вручную почисить не удасться. Смена записи c 127.0.0.1 на 127.0.0.2 решила бы эту проблему и ряд проблем для клиентов но не все... Я бы оставил это на случай минималистического варианта, коорый всё равно лучше, чем текущий... Сейчас же я предлагаю проверить модуль libnss_fallback, который я успел сделать за сегодняшний вечер... Думаю его нужно оттестировать, хотя основую часть баго я уже отловил... http://git.altlinux.org/people/sin/packages/libnss-fallback.git (In reply to comment #6) > В рамках решения этой проблемы, сегодня родилась идея написать NSS-модуль > fallback, который быть ставился последним в цепочке hosts файла nsswitch.conf и разрешал > бы имя хоста в 127.0.0.1 Предлагаю другую идею: клонировать libnss_files под другим именем с одновременной коррекцией имён конфигурационных файлов. Тогда этот условный files2 можно добавить в nsswitch после dns. (In reply to comment #7) > (In reply to comment #6) > > В рамках решения этой проблемы, сегодня родилась идея написать NSS-модуль > > fallback, который быть ставился последним в цепочке hosts файла nsswitch.conf и разрешал > > бы имя хоста в 127.0.0.1 > > Предлагаю другую идею: клонировать libnss_files под другим именем с > одновременной коррекцией имён конфигурационных файлов. Тогда этот > условный files2 можно добавить в nsswitch после dns. > У этого варианта есть недостаток связанный с необходимостью прописывать записи в другой файл... Исчезает та самая динамика, которая бы позволила избавиться от необходимости прописывать записи для хоста при смене его имени... Причём такой механизм на файлах будет жёстко привязан к нашей утилите, которая будет знать про дополнительный файл настроек... Я пока не вижу преимуществ у этого варианта кроме вохможности пробить имена для разных хостов, но для этого и обычный /etc/hosts годится. Итого я вижу следующие недостатки: 1) Лишаемся динамики, что потенциально грозит тем же мусором и костылями; 2) Привязываемся в одной утилите (или бэкенду), которая будет изменять имя хоста, и которая будет вносить записи в новый конфиг; 3) Это сложнее писать, поскльку выковыривать код из nss_files будет не просто, да и весь код не перенести... Там шаблоны на макросах, встроенные функции недоступные сторонним модулям и необходимость синхрониации на открытых файлах... А чем вам мой вариант не понравился? Я могу сказать, что там непонятно как быть c ipv6, который я пока отключил, ибо не на не особо пока нужен... Если его включить, то, поскольку у нас проверка ipv6 идёт вперёд ipv4, хост будет разрешаться в ::1. Это можно обойти двумя сборками libnss_fallback4 и libnss_fallback6. Именно так и сделано в nss-mdns, который я брал за основу. Вот тут: http://git.altlinux.org/people/kipruss/packages/?p=alterator-net-eth.git;a=summary вариант решения данной проблемы. 1. вместо 127.0.0.1 ставится 127.0.0.2) 2. При обновлении хоста старые бы выносятся (подразумевается, что старые - это с 127.0.0.2, то есть добавленные автоматом) 3. Пофикшена бага, которая при наличии хоста aaa.bbb.ccc не давало завести новый хост bbb.ccc, потому что грепание возвращало истину Если привязываем к 127.0.0.2, то стоит ли так сложно делать замену? Временные файлы тоже не хорошо, может быть лучше sed -i ? (In reply to comment #9) > Вот тут: > http://git.altlinux.org/people/kipruss/packages/?p=alterator-net-eth.git;a=summary > > вариант решения данной проблемы. > > 1. вместо 127.0.0.1 ставится 127.0.0.2) > > 2. При обновлении хоста старые бы выносятся (подразумевается, что старые - > это с 127.0.0.2, то есть добавленные автоматом) > > 3. Пофикшена бага, которая при наличии хоста aaa.bbb.ccc не давало завести > новый хост bbb.ccc, потому что грепание возвращало истину (В ответ на комментарий №10) > Если привязываем к 127.0.0.2, то стоит ли так сложно делать замену? не совсем понял > Временные файлы тоже не хорошо, может быть лучше sed -i ? Вот вариант без временных файлов (менял только ветку master) http://git.altlinux.org/people/kipruss/packages/?p=alterator-net-eth.git;a=summary (In reply to comment #11) > (В ответ на комментарий №10) > > Если привязываем к 127.0.0.2, то стоит ли так сложно делать замену? > не совсем понял > > > Временные файлы тоже не хорошо, может быть лучше sed -i ? > Вот вариант без временных файлов (менял только ветку master) > http://git.altlinux.org/people/kipruss/packages/?p=alterator-net-eth.git;a=summary Кажется я понял как надо решить эту проблему с привязкой hostname чтобы всех устроило ... в течении пары дней озвучу в devel@. Как вариант решения: 1. Дополнить пакет libnss-fallback post и postun скриптами, которые после установки пакета добавляют fallback в nsswitch.conf в hosts: а после его удаления - удаляют. То есть аналогичто тому, что есть в libnss-role (кстати, я там пофиксил пару проблем: см. ALT#18984). 2. Устанавливать пакет libnss-fallback по умолчанию в базовую систему. ... и не делать соответствующий installer-feature. Теперь всё замечательно. alterator-net-eth-0.4-alt3 больше не занимается биндингом hostname куда-либо. Теперь он вызывает хуки из /etc/hooks/hostname.d ... так что куда привязывать hostname и привязывать ли вообще каждый решает как ему удобнее ;) (In reply to comment #13) > Как вариант решения: > > 1. Дополнить пакет libnss-fallback post и postun скриптами, которые после > установки пакета добавляют fallback в nsswitch.conf в hosts: а после его > удаления - удаляют. То есть аналогичто тому, что есть в libnss-role (кстати, я > там пофиксил пару проблем: см. ALT#18984). > > 2. Устанавливать пакет libnss-fallback по умолчанию в базовую систему. > > ... и не делать соответствующий installer-feature. /etc/hooks/hostname.d - это отлично. Но что мы имеем теперь?
$ rpm -qf /etc/hooks/hostname.d/05-hosts
alterator-net-eth-4.11-alt3
$ cat /etc/hooks/hostname.d/05-hosts
#!/bin/sh -eu
old_hostname="$1"
new_hostname="$2"
[ -n "$new_hostname" ] || exit 1
grep -qs "^[^#]*\<$new_hostname\>" /etc/hosts ||
printf '127.0.0.1\t%s %s\n' "$new_hostname" "${new_hostname%%.*}" >> /etc/hosts
short_old_hostname="${old_hostname%%.*}"
[ -z "$old_hostname" -o "$old_hostname" = "$new_hostname" \
-o "$short_old_hostname" = 'localhost' ] ||
sed -ri "/^127\.0\.0\.1[[:blank:]]+$old_hostname[[:blank:]]+$short_old_hostname/d" /etc/hosts
В итоге 127.0.0.1 всё так же выставляется и всё также нарушает работу системы. В чём проблема сделать хотя бы 127.0.0.2 или воспользоватся libnss-fallback? На нём разве есть какие-нибудь не закрытые баги?
(В ответ на комментарий №15) > В итоге 127.0.0.1 всё так же выставляется и всё также нарушает работу системы. > В чём проблема сделать хотя бы 127.0.0.2 или воспользоватся libnss-fallback? На > нём разве есть какие-нибудь не закрытые баги? К сожалению в changelog не было упоминаний об этом баге. Я думаю городить аж целый модуль для этих целей - это слишком, вариант с 127.0.0.2 мне нравится больше. И в любом случае, видимо, надо вынести этот хук в отдельный (под)пакет. (В ответ на комментарий №16) > 127.0.0.2 мне нравится больше. Нет, с этим тоже есть проблемы (см. https://features.opensuse.org/308824, например). Просто вынесу пока хук в подпакет. alterator-net-eth-4.11-alt4 -> sisyphus: * Thu Mar 17 2011 Mikhail Efremov <sem@altlinux> 4.11-alt4 - Move hook for /etc/hosts to subpackage (closes: #17498). Наверное, об этом стоит упомянуть в devel-distro@. (In reply to comment #17) > > 127.0.0.2 мне нравится больше. > > Нет, с этим тоже есть проблемы (см. https://features.opensuse.org/308824, > например). [...] Тут стоит уточнить, что ровно те же проблемы возникают и с 127.0.0.1, и связаны они в основном с тем, что FQDN резолвится в локальный ip. |
Description
Evgeny Sinelnikov 2008-10-09 16:48:23 MSDЕсть ли необходимость каждый раз при смене имени хоста добавлять новую запись в /etc/host с новым именем для 127.0.0.1? $ grep 127.0.0.1 /usr/lib/alterator/backend3/net-eth printf '127.0.0.1\t%s %s\n' "$value" "${value%%.*}" >> /etc/hosts Дело в том, что это приводит к некоторым проблемам, поскольку в /etc/nsswitch.conf обычно прописано что-то вроде: $ grep ^hosts /etc/nsswitch.conf hosts: files nisplus nis dns то соответственно при поиске обратной зоны для имени хоста первой записью находится 127.0.0.1, является некоторой проблемой... Собственно вопрос в том, является ли такая настройка корректной и, если нет, это стоит исправить, иначе нужно понять как это обходить...