17498 2008-10-09 16:48:23 +0400 Проблема установки 127.0.0.1 для имени хоста 2021-11-04 14:23:52 +0300 1 1 4 Development Sisyphus alterator-net-eth unstable all Linux CLOSED FIXED P2 normal --- 22600 17727 1 sin sem ahmedsayeed1982 boyarsh erthad evg iv kipruss ldv mike rider sem vitty zerg qa-sisyphus oldest_to_newest 79401 0 sin 2008-10-09 16:48:23 +0400 Есть ли необходимость каждый раз при смене имени хоста добавлять новую запись в /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, является некоторой проблемой... Собственно вопрос в том, является ли такая настройка корректной и, если нет, это стоит исправить, иначе нужно понять как это обходить... 79555 1 inger 2008-10-13 14:47:53 +0400 пока не понятно что с этим делать ибо hostname должен резолвится, а искуственного интеллекта не хватает. 79908 2 sin 2008-10-20 19:42:11 +0400 Тут жуткая проблема и проявляется она так: если задать /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 вручную. 79933 3 inger 2008-10-21 11:12:44 +0400 (In reply to comment #2) > Тут жуткая проблема и проявляется она так: Я знаю что некоторые программы начинает колбасить. Предложите решение. Спрашивать явно пользователя (особенно пользователя desktop) о том нужно ли ему биндить hostname на 127.0.0.1 бесполезно. Нужна какая-то автоматика. 80361 4 iv 2008-10-28 19:28:32 +0300 > Я знаю что некоторые программы начинает колбасить. Предложите решение. > В Сусе вместо записи 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. 80518 5 inger 2008-10-31 15:22:07 +0300 Мысль хорошая. Дима, что скажешь? (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. > 81508 6 sin 2008-11-22 01:03:39 +0300 В рамках решения этой проблемы, сегодня родилась идея написать 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 81515 7 ldv 2008-11-22 01:50:09 +0300 (In reply to comment #6) > В рамках решения этой проблемы, сегодня родилась идея написать NSS-модуль > fallback, который быть ставился последним в цепочке hosts файла nsswitch.conf и разрешал > бы имя хоста в 127.0.0.1 Предлагаю другую идею: клонировать libnss_files под другим именем с одновременной коррекцией имён конфигурационных файлов. Тогда этот условный files2 можно добавить в nsswitch после dns. 81517 8 sin 2008-11-22 02:09:45 +0300 (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, который я брал за основу. 86158 9 kipruss 2009-02-19 18:02:29 +0300 Вот тут: 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, потому что грепание возвращало истину 86202 10 inger 2009-02-20 12:03:13 +0300 Если привязываем к 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, потому что грепание возвращало истину 86207 11 kipruss 2009-02-20 15:17:39 +0300 (В ответ на комментарий №10) > Если привязываем к 127.0.0.2, то стоит ли так сложно делать замену? не совсем понял > Временные файлы тоже не хорошо, может быть лучше sed -i ? Вот вариант без временных файлов (менял только ветку master) http://git.altlinux.org/people/kipruss/packages/?p=alterator-net-eth.git;a=summary 86390 12 inger 2009-02-24 11:34:30 +0300 (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@. 86523 13 kipruss 2009-02-26 01:15:50 +0300 Как вариант решения: 1. Дополнить пакет libnss-fallback post и postun скриптами, которые после установки пакета добавляют fallback в nsswitch.conf в hosts: а после его удаления - удаляют. То есть аналогичто тому, что есть в libnss-role (кстати, я там пофиксил пару проблем: см. ALT#18984). 2. Устанавливать пакет libnss-fallback по умолчанию в базовую систему. ... и не делать соответствующий installer-feature. 86538 14 inger 2009-02-26 10:49:48 +0300 Теперь всё замечательно. 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. 119295 15 sin 2011-03-16 17:27:18 +0300 /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? На нём разве есть какие-нибудь не закрытые баги? 119298 16 sem 2011-03-16 18:56:39 +0300 (В ответ на комментарий №15) > В итоге 127.0.0.1 всё так же выставляется и всё также нарушает работу системы. > В чём проблема сделать хотя бы 127.0.0.2 или воспользоватся libnss-fallback? На > нём разве есть какие-нибудь не закрытые баги? К сожалению в changelog не было упоминаний об этом баге. Я думаю городить аж целый модуль для этих целей - это слишком, вариант с 127.0.0.2 мне нравится больше. И в любом случае, видимо, надо вынести этот хук в отдельный (под)пакет. 119327 17 sem 2011-03-17 16:19:01 +0300 (В ответ на комментарий №16) > 127.0.0.2 мне нравится больше. Нет, с этим тоже есть проблемы (см. https://features.opensuse.org/308824, например). Просто вынесу пока хук в подпакет. 119332 18 repository-robot 2011-03-17 18:03:45 +0300 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). 119345 19 mike 2011-03-18 17:00:22 +0300 Наверное, об этом стоит упомянуть в devel-distro@. 119347 20 iv 2011-03-18 17:41:04 +0300 (In reply to comment #17) > > 127.0.0.2 мне нравится больше. > > Нет, с этим тоже есть проблемы (см. https://features.opensuse.org/308824, > например). [...] Тут стоит уточнить, что ровно те же проблемы возникают и с 127.0.0.1, и связаны они в основном с тем, что FQDN резолвится в локальный ip.