Bug 17498 - Проблема установки 127.0.0.1 для имени хоста
Summary: Проблема установки 127.0.0.1 для имени хоста
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: alterator-net-eth (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: Mikhail Efremov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 22600 17727
  Show dependency tree
 
Reported: 2008-10-09 16:48 MSD by Evgeny Sinelnikov
Modified: 2021-11-04 14:23 MSK (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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, является некоторой проблемой...

Собственно вопрос в том, является ли такая настройка корректной и, если нет, это стоит исправить, иначе нужно понять как это обходить...
Comment 1 inger@altlinux.org 2008-10-13 14:47:53 MSD
пока не понятно что с этим делать ибо hostname должен резолвится, а искуственного интеллекта не хватает.
Comment 2 Evgeny Sinelnikov 2008-10-20 19:42:11 MSD
Тут жуткая проблема и проявляется она так:
если задать /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 вручную.
Comment 3 inger@altlinux.org 2008-10-21 11:12:44 MSD
(In reply to comment #2)
> Тут жуткая проблема и проявляется она так:
Я знаю что некоторые программы начинает колбасить. Предложите решение.

Спрашивать явно пользователя (особенно пользователя desktop) о том нужно ли ему биндить hostname на 127.0.0.1 бесполезно. Нужна какая-то автоматика.

Comment 4 Ivan A. Melnikov 2008-10-28 19:28:32 MSK
> Я знаю что некоторые программы начинает колбасить. Предложите решение.
>

В Сусе вместо записи
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.
Comment 5 inger@altlinux.org 2008-10-31 15:22:07 MSK
Мысль хорошая. Дима, что скажешь?

(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.
> 

Comment 6 Evgeny Sinelnikov 2008-11-22 01:03:39 MSK
В рамках решения этой проблемы, сегодня родилась идея написать 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
Comment 7 Dmitry V. Levin 2008-11-22 01:50:09 MSK
(In reply to comment #6)
> В рамках решения этой проблемы, сегодня родилась идея написать NSS-модуль
> fallback, который быть ставился последним в цепочке hosts файла nsswitch.conf и разрешал
> бы имя хоста в 127.0.0.1

Предлагаю другую идею: клонировать libnss_files под другим именем с одновременной коррекцией имён конфигурационных файлов.  Тогда этот условный files2 можно добавить в nsswitch после dns.
Comment 8 Evgeny Sinelnikov 2008-11-22 02:09:45 MSK
(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, который я брал за основу.
Comment 9 Konstantin Baev 2009-02-19 18:02:29 MSK
Вот тут: 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, потому что грепание возвращало истину
Comment 10 inger@altlinux.org 2009-02-20 12:03:13 MSK
Если привязываем к 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, потому что грепание возвращало истину
Comment 11 Konstantin Baev 2009-02-20 15:17:39 MSK
(В ответ на комментарий №10)
> Если привязываем к 127.0.0.2, то стоит ли так сложно делать замену?
не совсем понял

> Временные файлы тоже не хорошо, может быть лучше sed -i ?
Вот вариант без временных файлов (менял только ветку master)
http://git.altlinux.org/people/kipruss/packages/?p=alterator-net-eth.git;a=summary
Comment 12 inger@altlinux.org 2009-02-24 11:34:30 MSK
(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@.
Comment 13 Konstantin Baev 2009-02-26 01:15:50 MSK
Как вариант решения:

1. Дополнить пакет libnss-fallback post и postun скриптами, которые после установки пакета добавляют fallback в nsswitch.conf в hosts: а после его удаления - удаляют. То есть аналогичто тому, что есть в libnss-role (кстати, я там пофиксил пару проблем: см. ALT#18984).

2. Устанавливать пакет libnss-fallback по умолчанию в базовую систему.

... и не делать соответствующий installer-feature.
Comment 14 inger@altlinux.org 2009-02-26 10:49:48 MSK
Теперь всё замечательно.

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.
Comment 15 Evgeny Sinelnikov 2011-03-16 17:27:18 MSK
/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? На нём разве есть какие-нибудь не закрытые баги?
Comment 16 Mikhail Efremov 2011-03-16 18:56:39 MSK
(В ответ на комментарий №15)
> В итоге 127.0.0.1 всё так же выставляется и всё также нарушает работу системы.
> В чём проблема сделать хотя бы 127.0.0.2 или воспользоватся libnss-fallback? На
> нём разве есть какие-нибудь не закрытые баги?

К сожалению в changelog не было упоминаний об этом баге.
Я думаю городить аж целый модуль для этих целей - это слишком, вариант с 127.0.0.2 мне нравится больше.
И в любом случае, видимо, надо вынести этот хук в отдельный (под)пакет.
Comment 17 Mikhail Efremov 2011-03-17 16:19:01 MSK
(В ответ на комментарий №16)
> 127.0.0.2 мне нравится больше.

Нет, с этим тоже есть проблемы (см. https://features.opensuse.org/308824, например). Просто вынесу пока хук в подпакет.
Comment 18 Repository Robot 2011-03-17 18:03:45 MSK
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).
Comment 19 Michael Shigorin 2011-03-18 17:00:22 MSK
Наверное, об этом стоит упомянуть в devel-distro@.
Comment 20 Ivan A. Melnikov 2011-03-18 17:41:04 MSK
(In reply to comment #17)
> > 127.0.0.2 мне нравится больше.
> 
> Нет, с этим тоже есть проблемы (см. https://features.opensuse.org/308824,
> например). [...]

Тут стоит уточнить, что ровно те же проблемы возникают и с 127.0.0.1, и связаны они в основном с тем, что FQDN резолвится в локальный ip.