Bug 17498 - Проблема установки 127.0.0.1 для имени хоста
: Проблема установки 127.0.0.1 для имени хоста
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/alterator-net-eth)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
: 17727 22600
  Show dependency tree
 
Reported: 2008-10-09 16:48 by
Modified: 2013-01-24 18:48 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-10-09 16:48:23
Есть ли необходимость каждый раз при смене имени хоста добавлять новую запись в
/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 From 2008-10-13 14:47:53 -------
пока не понятно что с этим делать ибо hostname должен резолвится, а
искуственного интеллекта не хватает.
------- Comment #2 From 2008-10-20 19:42:11 -------
Тут жуткая проблема и проявляется она так:
если задать /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 From 2008-10-21 11:12:44 -------
(In reply to comment #2)
> Тут жуткая проблема и проявляется она так:
Я знаю что некоторые программы начинает колбасить. Предложите решение.

Спрашивать явно пользователя (особенно пользователя desktop) о том нужно ли ему
биндить hostname на 127.0.0.1 бесполезно. Нужна какая-то автоматика.
------- Comment #4 From 2008-10-28 19:28:32 -------
> Я знаю что некоторые программы начинает колбасить. Предложите решение.
>

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

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

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

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

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

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

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

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

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

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

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