Есть ли необходимость каждый раз при смене имени хоста добавлять новую запись в /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, является некоторой проблемой... Собственно вопрос в том, является ли такая настройка корректной и, если нет, это стоит исправить, иначе нужно понять как это обходить...
пока не понятно что с этим делать ибо 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.
