subject:"etc\/\*"


Столкнулся с проблемой описанной:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679479

В кратце: не стартует сервис bacula-fd только при старте компьютера:

 cat /var/log/bacula-fd-initd.log
23-Oct 11:30 bacula-fd: ERROR TERMINATION at address_conf.c:521
Config error: can't add port (server.example.lab) to (can't resolve 
hostname(server.exmaple.lab) Connection timed out)

: line 8, col 30 of file /etc/bacula/bacula-fd.conf
  FDAddress = server.example.lab

Причем такое на нескольких компьютерх в сети и не только с File Daemon 
но и Storage Daemon, Director как то обходится без hosts.


Видимо потому, что стартует позже всех, это видно из /etc/rc2.d/*

Это предистория. А теперь вопрос:

Я могут использовать /etc/hosts файл и задать там АДРЕС ИМЯ вручную. Но 
тогда мне придется за этим файлом следить.

Тем более что сервера у меня используют статические IP.

А если например мне нужно будет запускать bacula-fd на компьютерах с 
DHCP а таких большинство, поддерживать hosts файл будет не совсем правильно.


Можно конечно решить эту проблему другими способами, но меня больше 
интересует именно /etc/hosts и его use cases


Или лучше следить за hosts и в будущем не наступать на такие грабли (на 
компах со статическим IP)?


Тем более, что это возможно актуально и для других служб.

Вообщем best-practic ?


--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

Vladimir Skubriev - Debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
12:26:32 +0400:

 VS Столкнулся с проблемой описанной:
 VS http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679479

 VS В кратце: не стартует сервис bacula-fd только при старте компьютера:

 VS  cat /var/log/bacula-fd-initd.log
 VS 23-Oct 11:30 bacula-fd: ERROR TERMINATION at address_conf.c:521
 VS Config error: can't add port (server.example.lab) to (can't resolve
 VS hostname(server.exmaple.lab) Connection timed out)
 VS : line 8, col 30 of file /etc/bacula/bacula-fd.conf
 VS   FDAddress = server.example.lab

 VS Причем такое на нескольких компьютерх в сети и не только с File Daemon но и
 VS Storage Daemon, Director как то обходится без hosts.

 VS Видимо потому, что стартует позже всех, это видно из /etc/rc2.d/*

 VS Это предистория. А теперь вопрос:

 VS Я могут использовать /etc/hosts файл и задать там АДРЕС ИМЯ вручную. Но 
тогда
 VS мне придется за этим файлом следить.
 VS Тем более что сервера у меня используют статические IP.

 VS А если например мне нужно будет запускать bacula-fd на компьютерах с DHCP а
 VS таких большинство, поддерживать hosts файл будет не совсем правильно.

 VS Можно конечно решить эту проблему другими способами, но меня больше 
интересует
 VS именно /etc/hosts и его use cases

 VS Или лучше следить за hosts и в будущем не наступать на такие грабли (на 
компах
 VS со статическим IP)?

 VS Тем более, что это возможно актуально и для других служб.

 VS Вообщем best-practic ?

Я подозреваю, что лучше всего будет ему объяснить, чтобы он поднимался
после полного подъема сети.  (В смысле, если DNS-сервер локальный, то и
после него тоже.)  У нас же dependency-based загрузка нынче.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vc0ocrqs@wizzle.ran.pp.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?


On 10/23/2013 12:32 PM, Artem Chuprina wrote:

Vladimir Skubriev - Debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
12:26:32 +0400:

  VS Столкнулся с проблемой описанной:
  VS http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679479

  VS В кратце: не стартует сервис bacula-fd только при старте компьютера:

  VS  cat /var/log/bacula-fd-initd.log
  VS 23-Oct 11:30 bacula-fd: ERROR TERMINATION at address_conf.c:521
  VS Config error: can't add port (server.example.lab) to (can't resolve
  VS hostname(server.exmaple.lab) Connection timed out)
  VS : line 8, col 30 of file /etc/bacula/bacula-fd.conf
  VS   FDAddress = server.example.lab

  VS Причем такое на нескольких компьютерх в сети и не только с File Daemon но 
и
  VS Storage Daemon, Director как то обходится без hosts.

  VS Видимо потому, что стартует позже всех, это видно из /etc/rc2.d/*

  VS Это предистория. А теперь вопрос:

  VS Я могут использовать /etc/hosts файл и задать там АДРЕС ИМЯ вручную. Но 
тогда
  VS мне придется за этим файлом следить.
  VS Тем более что сервера у меня используют статические IP.

  VS А если например мне нужно будет запускать bacula-fd на компьютерах с DHCP 
а
  VS таких большинство, поддерживать hosts файл будет не совсем правильно.

  VS Можно конечно решить эту проблему другими способами, но меня больше 
интересует
  VS именно /etc/hosts и его use cases

  VS Или лучше следить за hosts и в будущем не наступать на такие грабли (на 
компах
  VS со статическим IP)?

  VS Тем более, что это возможно актуально и для других служб.

  VS Вообщем best-practic ?

Я подозреваю, что лучше всего будет ему объяснить, чтобы он поднимался
после полного подъема сети.  (В смысле, если DNS-сервер локальный, то и
после него тоже.)  У нас же dependency-based загрузка нынче.



вопрос больше не в этом а в том, использововть /etc/hosts или нет )

это я и сам понимаю, я пробовал, но например там где стоят bacula-sd и 
bacula-fd это действует только только на одни сервис, другой почему то 
все равно запускаеться или до или видимо во время инициализации сети )


--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52678d1e.4000...@skubriev.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Andrey Rahmatullin

Vladimir Skubriev - Debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
12:47:26 +0400:

VS Столкнулся с проблемой описанной:
VS http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679479
 
VS В кратце: не стартует сервис bacula-fd только при старте компьютера:
 
VS  cat /var/log/bacula-fd-initd.log
VS 23-Oct 11:30 bacula-fd: ERROR TERMINATION at address_conf.c:521
VS Config error: can't add port (server.example.lab) to (can't resolve
VS hostname(server.exmaple.lab) Connection timed out)
VS : line 8, col 30 of file /etc/bacula/bacula-fd.conf
VS   FDAddress = server.example.lab
 
VS Причем такое на нескольких компьютерх в сети и не только с File 
  Daemon но и
VS Storage Daemon, Director как то обходится без hosts.
 
VS Видимо потому, что стартует позже всех, это видно из /etc/rc2.d/*
 
VS Это предистория. А теперь вопрос:
 
VS Я могут использовать /etc/hosts файл и задать там АДРЕС ИМЯ вручную. 
  Но тогда
VS мне придется за этим файлом следить.
VS Тем более что сервера у меня используют статические IP.
 
VS А если например мне нужно будет запускать bacula-fd на компьютерах с 
  DHCP а
VS таких большинство, поддерживать hosts файл будет не совсем правильно.
 
VS Можно конечно решить эту проблему другими способами, но меня больше 
  интересует
VS именно /etc/hosts и его use cases
 
VS Или лучше следить за hosts и в будущем не наступать на такие грабли 
  (на компах
VS со статическим IP)?
 
VS Тем более, что это возможно актуально и для других служб.
 
VS Вообщем best-practic ?
 
  Я подозреваю, что лучше всего будет ему объяснить, чтобы он поднимался
  после полного подъема сети.  (В смысле, если DNS-сервер локальный, то и
  после него тоже.)  У нас же dependency-based загрузка нынче.
 
 
 VS вопрос больше не в этом а в том, использововть /etc/hosts или нет )

Мое мнение: на хостах с DHCP точно не стоит.  На серверах со статикой
может иметь смысл, но по минимуму.  Себя надо вписывать, а остальных без
крайней необходимости - нет.

Ну, или альтернативный вариант: сделать централизованный hosts,
содержащий всю статику сети, и раскидывать его скриптом по всем серверам
сразу после изменений.

 VS это я и сам понимаю, я пробовал, но например там где стоят bacula-sd и
 VS bacula-fd это действует только только на одни сервис, другой почему то все
 VS равно запускаеться или до или видимо во время инициализации сети )

Странно.  Если зависимость прописана, то уж для сети-то она должна
срабатывать.  Подъем сети уж должен быть устроен так, чтобы не считаться
завершенным, пока сеть действительно не поднялась.

Вот в то, что скрипт запуска DNS-сервера забывает дождаться, пока оный
сервер успешно поднимется и будет готов к работе, я легче поверю.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4bccn2r@wizzle.ran.pp.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

On Wed, Oct 23, 2013 at 02:13:00PM +0400, Artem Chuprina wrote:
 Ну, или альтернативный вариант: сделать централизованный hosts,
 содержащий всю статику сети, и раскидывать его скриптом по всем серверам
 сразу после изменений.
Я так понимаю, до DNS так и делали?

-- 
WBR, wRAR


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131023101539.ga32...@belkar.wrar.name

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?


On 10/23/2013 02:15 PM, Andrey Rahmatullin wrote:

On Wed, Oct 23, 2013 at 02:13:00PM +0400, Artem Chuprina wrote:

Ну, или альтернативный вариант: сделать централизованный hosts,
содержащий всю статику сети, и раскидывать его скриптом по всем серверам
сразу после изменений.

Я так понимаю, до DNS так и делали?


до DNS не было bacula

просто так получилось, что я забыл вообще про hosts после настройки DNS 
почти на всех серверах, ну работает все и хорошо.


Потом не сразу заметил, что бакула не подымается иногда, постепенно 
выяснил в чем дело и вот опять вернулся с чего начинал ) Т.е. к hosts


Вообщем то я для себя решил пока буду юзать hosts на статике

А если будет dhcp буду вешать рестарт бакулы после старта сети как нибудь

Вообще хотел услышать практику по hosts если есть свой DNS )

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5267a7a0.2010...@skubriev.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Andrey Rahmatullin

Andrey Rahmatullin - debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
16:15:39 +0600:

  Ну, или альтернативный вариант: сделать централизованный hosts,
  содержащий всю статику сети, и раскидывать его скриптом по всем серверам
  сразу после изменений.
 AR Я так понимаю, до DNS так и делали?

Собственно, DNS изобрели оттого, что делать так в рамках целого
интернета стало не алё.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwm0ckhj@wizzle.ran.pp.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

On Wed, Oct 23, 2013 at 03:08:56PM +0400, Artem Chuprina wrote:
   Ну, или альтернативный вариант: сделать централизованный hosts,
   содержащий всю статику сети, и раскидывать его скриптом по всем серверам
   сразу после изменений.
  AR Я так понимаю, до DNS так и делали?
 Собственно, DNS изобрели оттого, что делать так в рамках целого
 интернета стало не алё.
Ну я догадываюсь, да.

-- 
WBR, wRAR


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131023114007.gb32...@belkar.wrar.name

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Andrey Tataranovich

В Wed, 23 Oct 2013 14:13:00 +0400
Artem Chuprina r...@ran.pp.ru пишет:
 Странно.  Если зависимость прописана, то уж для сети-то она должна
 срабатывать.  Подъем сети уж должен быть устроен так, чтобы не
 считаться завершенным, пока сеть действительно не поднялась.
 
 Вот в то, что скрипт запуска DNS-сервера забывает дождаться, пока оный
 сервер успешно поднимется и будет готов к работе, я легче поверю.

Зависимость можно прописать только на машине, где стоит DNS сервер(а). А
другие сервера (которые используют локальный DNS по сети) вполне могут
загрузиться раньше, чем сервер(а) с локальным DNS.

-- 
WBR, Andrey Tataranovich


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131023145422.4bf2ed10@dragoncore.local

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Andrey Lyubimets

On 10/23/2013 03:54 PM, Andrey Tataranovich wrote:

В Wed, 23 Oct 2013 14:13:00 +0400
Artem Chuprina r...@ran.pp.ru пишет:

Странно. Если зависимость прописана, то уж для сети-то она должна
срабатывать. Подъем сети уж должен быть устроен так, чтобы не
считаться завершенным, пока сеть действительно не поднялась.

Вот в то, что скрипт запуска DNS-сервера забывает дождаться, пока оный
сервер успешно поднимется и будет готов к работе, я легче поверю.

Зависимость можно прописать только на машине, где стоит DNS сервер(а). А
другие сервера (которые используют локальный DNS по сети) вполне могут
загрузиться раньше, чем сервер(а) с локальным DNS.

Да дело в том, что bacula службы не должны зависеть от DNS, точнее их
загрузка не должна зависеть от DNS.

Работа должна, точнее у меня она полностью зависит от DNS.

Но блин мне было совсем не очевидно когда я копал в сторну почему не они
не запускаются и в итоге наткнулся на DNS )

Хотя может и опыта не хватает.

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5267bad7.4070...@skubriev.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

23.10.2013 15:26, Vladimir Skubriev пишет:
 Столкнулся с проблемой описанной:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679479
 
 В кратце: не стартует сервис bacula-fd только при старте компьютера:
 
  cat /var/log/bacula-fd-initd.log
 23-Oct 11:30 bacula-fd: ERROR TERMINATION at address_conf.c:521
 Config error: can't add port (server.example.lab) to (can't resolve
 hostname(server.exmaple.lab) Connection timed out)
 : line 8, col 30 of file /etc/bacula/bacula-fd.conf
   FDAddress = server.example.lab
 
 Причем такое на нескольких компьютерх в сети и не только с File Daemon но и
 Storage Daemon, Director как то обходится без hosts.
 
 Видимо потому, что стартует позже всех, это видно из /etc/rc2.d/*
 
 Это предистория. А теперь вопрос:
 
 Я могут использовать /etc/hosts файл и задать там АДРЕС ИМЯ вручную. Но тогда
 мне придется за этим файлом следить.
 Тем более что сервера у меня используют статические IP.
 
 А если например мне нужно будет запускать bacula-fd на компьютерах с DHCP а
 таких большинство, поддерживать hosts файл будет не совсем правильно.
 
 Можно конечно решить эту проблему другими способами, но меня больше
 интересует именно /etc/hosts и его use cases
 
 Или лучше следить за hosts и в будущем не наступать на такие грабли (на
 компах со статическим IP)?
 
 Тем более, что это возможно актуально и для других служб.
 
 Вообщем best-practic ?
Если есть DNS-сервер, то hosts использовать не нужно!
В качестве подпорки используй что-нибудь типа /etc/init.d/bacula restart в
/etc/rc.local, или  в файлик в /etc/cron.d/ . По крайней мере за ним  не
нужно следить.

-- 
С уважением, Любимец Андрей Алексеевич


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5267b26e@nskes.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Konstantin Matyukhin

Ну так обычно нейм серверов-то ставят чуть больше одного.

-- 
С уважением,
Константин Матюхин

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

Andrey Rahmatullin - debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
17:40:07 +0600:

Ну, или альтернативный вариант: сделать централизованный hosts,
содержащий всю статику сети, и раскидывать его скриптом по всем серверам
сразу после изменений.
   AR Я так понимаю, до DNS так и делали?
  Собственно, DNS изобрели оттого, что делать так в рамках целого
  интернета стало не алё.
 AR Ну я догадываюсь, да.

Я это к тому, что в рамках отдельно взятой локальной сети вполне может
быть и алё.  Размер имеет значение.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87iowochbe@wizzle.ran.pp.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

Vladimir Skubriev - Debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
16:02:31 +0400:

  Странно.  Если зависимость прописана, то уж для сети-то она должна
  срабатывать.  Подъем сети уж должен быть устроен так, чтобы не
  считаться завершенным, пока сеть действительно не поднялась.
 
  Вот в то, что скрипт запуска DNS-сервера забывает дождаться, пока оный
  сервер успешно поднимется и будет готов к работе, я легче поверю.
  Зависимость можно прописать только на машине, где стоит DNS сервер(а). А
  другие сервера (которые используют локальный DNS по сети) вполне могут
  загрузиться раньше, чем сервер(а) с локальным DNS.
 
 VS Да дело в том, что bacula службы не должны зависеть от DNS, точнее их 
загрузка
 VS не должна зависеть от DNS.

 VS Работа должна, точнее у меня она полностью зависит от DNS.

Вообще говоря, считается, что если работа зависит от DNS, то и загрузка
может иметь право от него зависеть.  Ну, то есть никто или почти никто
не заботится отдельно о том, чтобы без DNS можно было загрузиться, если
без него нельзя работать.

И в целом это правильно.  Если ты уже при старте демона знаешь имя
сервера, этот сервер тебе критичен для работы, и он не найден или даже
найден, но недоступен, обычно лучше по этому поводу отказаться
стартовать, желательно с внятным сообщением об ошибке, чтобы админ не
подумал, что твой демон будет работать, в то время как работать он не
будет.

Обычно такая ситуация означает, что в конфиге ошибка, или что сервер на
том конце действительно сломан, реже - что DNS сломан, а вовсе не то,
что DNS просто не успел подняться, но вот щас поднимется, и щас все
будет.

Хотя, конечно, в каждой конкретной ситуации может оказаться, что лучше
было бы запуститься и подождать, но...  Лучше уж тогда наоборот,
подождать и запуститься :)

 VS Но блин мне было совсем не очевидно когда я копал в сторну почему не они не
 VS запускаются и в итоге наткнулся на DNS )

 VS Хотя может и опыта не хватает.

А вот если он при обломе старта забыл положить в лог внятное сообщение
об ошибке, то это он зря.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87eh7ccgwm@wizzle.ran.pp.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?


On 10/23/2013 03:26 PM, Andrey Lyubimets wrote:


Если есть DNS-сервер, то hosts использовать не нужно!
В качестве подпорки используй что-нибудь типа /etc/init.d/bacula restart в
/etc/rc.local, или  в файлик в /etc/cron.d/ . По крайней мере за ним  не
нужно следить.

спасибо, я что то подобное прежполагаю - хук к скриптам запуска может 
сетевым может другим


--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5267c10c.5090...@skubriev.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Sergey Korobitsin


On 10/23/2013 04:26 PM, Artem Chuprina wrote:

Вообще говоря, считается, что если работа зависит от DNS, то и загрузка
может иметь право от него зависеть.  Ну, то есть никто или почти никто
не заботится отдельно о том, чтобы без DNS можно было загрузиться, если
без него нельзя работать.

И в целом это правильно.  Если ты уже при старте демона знаешь имя
сервера, этот сервер тебе критичен для работы, и он не найден или даже
найден, но недоступен, обычно лучше по этому поводу отказаться
стартовать, желательно с внятным сообщением об ошибке, чтобы админ не
подумал, что твой демон будет работать, в то время как работать он не
будет.
Внятное сообщение об ошибке я е видел сколько раз перегружал сервант, а 
был я на месте только пару раз


В остальном удаленно

В а логах она ни чего не оставляет, такая вот уже штучка. пришлось юзать

ARGS=-d20 -dt -c /etc/bacula/bacula-fd.conf

do_start()
{
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--exec $DAEMON -- $ARGS  /var/log/bacula-fd-initd.log 21
}

в init.d script'e

Вопрос в другом как сделать чтобы то, что выводиться при загрузки еще 
куда нибудь сохранялось в отдельный лог )



Обычно такая ситуация означает, что в конфиге ошибка, или что сервер на
том конце действительно сломан, реже - что DNS сломан, а вовсе не то,
что DNS просто не успел подняться, но вот щас поднимется, и щас все
будет.

Хотя, конечно, в каждой конкретной ситуации может оказаться, что лучше
было бы запуститься и подождать, но...  Лучше уж тогда наоборот,
подождать и запуститься :)

  VS Но блин мне было совсем не очевидно когда я копал в сторну почему не они 
не
  VS запускаются и в итоге наткнулся на DNS )

  VS Хотя может и опыта не хватает.

А вот если он при обломе старта забыл положить в лог внятное сообщение
об ошибке, то это он зря.





--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

Artem Chuprina ☫ → To debian-russian@lists.debian.org @ Wed, Oct 23, 2013 16:17
+0400

Andrey Rahmatullin - debian-russian@lists.debian.org @ Wed, 23 Oct 2013
17:40:07 +0600:

Ну, или альтернативный вариант: сделать централизованный hosts,
содержащий всю статику сети, и раскидывать его скриптом по всем
серверам
сразу после изменений.
AR Я так понимаю, до DNS так и делали?
Собственно, DNS изобрели оттого, что делать так в рамках целого
интернета стало не алё.
AR Ну я догадываюсь, да.

Я это к тому, что в рамках отдельно взятой локальной сети вполне может
быть и алё. Размер имеет значение.

Я, кстати, видел такое, но на ручном приводе - т.е. админ каждый раз
ручками копировал hosts с мастер-сервера по всем машинам. Имхо, это
ужасно криво (даже если автоматизировать процесс) - если уж совсем не
хочется заморачиваться с полноценным DNS-сервером, то можно сделать, как
я: использовать pdns-recursor экспортом /etc/hosts как зоны и прикрутить
forward DNS-запросов для всего остального.

--
Bright regards, Sergey Korobitsin,
Chief Research Officer
Arta Software, http://arta.kz/
xmpp:underta...@jabber.arta.kz

--
...Когда я увидел перед собой перспективу жизни, прожитой так же,
как живет весь мир, я решил - ни за что, это отвратительно,
мне будет стыдно самого себя. Если бы я участвовал в поддержке
этой системы отчужденного, собственнического программирования,
мне казалось бы, что я делаю мир хуже ради денег.
-- Ричард М. Столлман (из интервью)

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20131023124723.gf5...@undertaker.dev.lan.arta.kz

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность dimas

помимо зависимостей в хедерах инит-скрпита можно в оный скрипт добавить при
старте что-то типа
until ping -c1 hostname; do sleep 1; done
ну или dig. или еще как-нибудь. через разумное время попытки прекращаем,
ругаемся в лог, что сервер че-то ну никак не доступен


2013-296 14:54 Andrey Tataranovich tataranov...@gmail.com wrote:
 Зависимость можно прописать только на машине, где стоит DNS сервер(а). А
 другие сервера (которые используют локальный DNS по сети) вполне могут
 загрузиться раньше, чем сервер(а) с локальным DNS.
 


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131023175629.5c94e...@ulf.tvoe.tv

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Eugene Berdnikov

On Wed, Oct 23, 2013 at 04:26:17PM +0400, Artem Chuprina wrote:
 Vladimir Skubriev - Debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
 16:02:31 +0400:
  VS Да дело в том, что bacula службы не должны зависеть от DNS, точнее их 
 загрузка
  VS не должна зависеть от DNS.
 
  VS Работа должна, точнее у меня она полностью зависит от DNS.
 
 Вообще говоря, считается, что если работа зависит от DNS, то и загрузка
 может иметь право от него зависеть.  Ну, то есть никто или почти никто
 не заботится отдельно о том, чтобы без DNS можно было загрузиться, если
 без него нельзя работать.

 Вообще говоря, для правильно построенной системы отказ dns -- не повод
 не стартовать сервис и/или не работать. К тому же совершенно непонятно,
 нахрена бакуле dns.
-- 
 Eugene Berdnikov


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131023135853.gb3...@cio.protva.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Andrey Lyubimets

23.10.2013 15:26, Vladimir Skubriev пишет:
 Столкнулся с проблемой описанной:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679479

   FDAddress = server.example.lab
 

 Это предистория. А теперь вопрос:

 Можно конечно решить эту проблему другими способами, но меня больше
 интересует именно /etc/hosts и его use cases
 
 Или лучше следить за hosts и в будущем не наступать на такие грабли (на
 компах со статическим IP)?
 
 Тем более, что это возможно актуально и для других служб.
 
 Вообщем best-practic ?

Владимир! Что бы не наступать на грабли -- не нужно их разбрасывать!
Прочитай приведённую тобой ссылку  -  там dns ни разу не упоминается!
Правильное решение между тем - первым пунктом:

1. Allow bacula-fd to listen on all addresses - remove line FDAddress
= .. or change it to FDAddress = 0.0.0.0


С уважением, Любимец Андрей Алексеевич


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52688e38.1060...@nskes.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-23 Пенетрантность Andrey Lyubimets

23.10.2013 20:58, Eugene Berdnikov пишет:
On Wed, Oct 23, 2013 at 04:26:17PM +0400, Artem Chuprina wrote:
Vladimir Skubriev - Debian-russian@lists.debian.org @ Wed, 23 Oct 2013
16:02:31 +0400:
VS Да дело в том, что bacula службы не должны зависеть от DNS, точнее их
загрузка
VS не должна зависеть от DNS.

VS Работа должна, точнее у меня она полностью зависит от DNS.

Вообще говоря, считается, что если работа зависит от DNS, то и загрузка
может иметь право от него зависеть. Ну, то есть никто или почти никто
не заботится отдельно о том, чтобы без DNS можно было загрузиться, если
без него нельзя работать.

Вообще говоря, для правильно построенной системы отказ dns -- не повод
не стартовать сервис и/или не работать. К тому же совершенно непонятно,
нахрена бакуле dns.
Так и рождаются мифы и легенды. У топикстартера бакула не может отресолвить
адрес интерфейса, который должна слушать, потому что сетевой интерфейс ещё не
поднялся.

--
С уважением, Любимец Андрей Алексеевич

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?


On 10/23/2013 05:58 PM, Eugene Berdnikov wrote:

On Wed, Oct 23, 2013 at 04:26:17PM +0400, Artem Chuprina wrote:

Vladimir Skubriev - Debian-russian@lists.debian.org  @ Wed, 23 Oct 2013 
16:02:31 +0400:
  VS Да дело в том, что bacula службы не должны зависеть от DNS, точнее их 
загрузка
  VS не должна зависеть от DNS.

  VS Работа должна, точнее у меня она полностью зависит от DNS.

Вообще говоря, считается, что если работа зависит от DNS, то и загрузка
может иметь право от него зависеть.  Ну, то есть никто или почти никто
не заботится отдельно о том, чтобы без DNS можно было загрузиться, если
без него нельзя работать.

  Вообще говоря, для правильно построенной системы отказ dns -- не повод
  не стартовать сервис и/или не работать. К тому же совершенно непонятно,
  нахрена бакуле dns.

вот конфиг бакулы файл демона создаваемой автоматом через chef:

# Managed by chef for %= node['fqdn'] %

FileDaemon {
  Name = %= node['hostname'] %
  WorkingDirectory = /var/lib/bacula
  Pid Directory = /var/run/bacula
  Maximum Concurrent Jobs = 10
  FDAddress = %= node['fqdn'] %
}

#
# List Directors who are permitted to contact this File daemon
#
Director {
  Name = %=  node['bacula']['director']['name'] %
  Password = %= @password %
}

# Send all to director
Messages {
  Name = Daemon
  Director = %= node['bacula']['director']['name'] % = all
  syslog = all, !skipped, !saved
  append = %=  #{node['bacula']['storage']['log_dir']}/log-fd % = all
}

Спору нет можно указать и

  FDAddress = 0.0.0.0

Тогда поидее будет слушать на всем чем угодно. Оно и так и так верно, но 
0.0.0.0 более универсально конечно.


И в случае если оно настраивает сервер с Интернет IP, то нужно быть 100 
% уверенным в firewall'е.


А это потенциальная дыра в случае, если FW не настроен или еще что.

Но я все же остановлюсь на своем варианте т.е. буду править hosts на 
машинах со статическим IP.


В дальнейшем можно будет подумать над этим вопросом и его более 
элегантным решением.


--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5268a71c.3010...@skubriev.ru

Re: использовать или нет /etc/hosts, если есть собственный DNS для локальной зоны?

2013-10-14 Пенетрантность Vladimir Skubriev

On 10/24/2013 07:04 AM, Andrey Lyubimets wrote:

23.10.2013 15:26, Vladimir Skubriev пишет:

Столкнулся с проблемой описанной:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679479
FDAddress = server.example.lab

Это предистория. А теперь вопрос:
Можно конечно решить эту проблему другими способами, но меня больше
интересует именно /etc/hosts и его use cases

Или лучше следить за hosts и в будущем не наступать на такие грабли (на
компах со статическим IP)?

Тем более, что это возможно актуально и для других служб.

Вообщем best-practic ?

Владимир! Что бы не наступать на грабли -- не нужно их разбрасывать!

Золотые слова! Но куда же без них - разве чему нибудь научишься )

Прочитай приведённую тобой ссылку - там dns ни разу не упоминается!
Правильное решение между тем - первым пунктом:

1. Allow bacula-fd to listen on all addresses - remove line FDAddress
= .. or change it to FDAddress = 0.0.0.0

С уважением, Любимец Андрей Алексеевич

Согласен, как вариант. Но тогда нужны быть уверенным в FW, если
подымаешь на шлюзе. А bacula исключительно у меня внутренний сервис.

Да у меня шлюз и другие сервисы частенько на одной машине.

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt


Куда должна указывать директива

SSLCACertificateFile

если я планирую использовать(приобрести) сертификаты например у 
провайдера godaddy


на системный файл, в котором собрано все дистрибутивом 
(/etc/ssl/certs/ca-certificates.crt)?


на файл CA моего провайдера сертификатов ?

что то еще.

Спасибо.

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525bd4d0.2030...@skubriev.ru

Re: SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

2013-10-14 Пенетрантность alexander barakin (aka sash-kan)

14.10.2013, 15:26, Vladimir Skubriev vladi...@skubriev.ru:
 Куда должна указывать директива

 SSLCACertificateFile

 если я планирую использовать(приобрести) сертификаты например у
 провайдера godaddy

 на системный файл, в котором собрано все дистрибутивом
 (/etc/ssl/certs/ca-certificates.crt)?

 на файл CA моего провайдера сертификатов ?

судя по:
http://stackoverflow.com/questions/14449071/installing-an-ssl-certificate-with-godaddy
надо указать файл gd_bundle.crt, который следует брать отсюда:
https://certs.godaddy.com/anonymous/repository.pki


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/30551381755...@web6j.yandex.ru

Re: SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

2013-10-14 Пенетрантность Vladimir Skubriev


On 10/14/2013 04:54 PM, alexander barakin (aka sash-kan) wrote:

14.10.2013, 15:26, Vladimir Skubriev vladi...@skubriev.ru:

Куда должна указывать директива

SSLCACertificateFile

если я планирую использовать(приобрести) сертификаты например у
провайдера godaddy

на системный файл, в котором собрано все дистрибутивом
(/etc/ssl/certs/ca-certificates.crt)?

на файл CA моего провайдера сертификатов ?

судя по:
http://stackoverflow.com/questions/14449071/installing-an-ssl-certificate-with-godaddy
надо указать файл gd_bundle.crt, который следует брать отсюда:
https://certs.godaddy.com/anonymous/repository.pki



Спасибо.

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/525becf1.8040...@skubriev.ru

nging http section configuration and /etc/nginx/conf.d

2013-10-08 Пенетрантность Vladimir Skubriev


Мне нужно добавить дополнительные настройки в секцию

http {

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_stapling on;
resolver 8.8.8.8;
}

которые отствуют в основном конфиг файле nginx: /etc/nginx/nginx.conf

1. Могу ли я добавить это не в /etc/nginx/nginx.conf а а 
/etc/nginx/conf.d/http_addition


2. Что произойдет, если и в /etc/nginx/nginx.conf и в 
/etc/nginx/conf.d/http_addition будут заданы одни и те же параметры, но 
с разными значениями ? Какой у кого будет приоритет.


Спасибо.


--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5253d1f1.3060...@skubriev.ru

Re: nging http section configuration and /etc/nginx/conf.d

2013-10-08 Пенетрантность Alexander Wiedergold WIEDERGOLD.NET


Am 08.10.2013 11:40, schrieb Vladimir Skubriev:

Мне нужно добавить дополнительные настройки в секцию

http {

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 5m;
ssl_prefer_server_ciphers on;
ssl_stapling on;
resolver 8.8.8.8;
}

которые отствуют в основном конфиг файле nginx: /etc/nginx/nginx.conf

1. Могу ли я добавить это не в /etc/nginx/nginx.conf а а
/etc/nginx/conf.d/http_addition

2. Что произойдет, если и в /etc/nginx/nginx.conf и в
/etc/nginx/conf.d/http_addition будут заданы одни и те же параметры, но
с разными значениями ? Какой у кого будет приоритет.

Спасибо.



если в nginx.conf стоит include /etc/nginx/conf.d/* у всех в коце конфига
будет ругаться что-то вроде уже задано. скажит при старте демона

--
..
http://wiedergold.net/


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/l31e02$m7a$1...@online.de

Re: nging http section configuration and /etc/nginx/conf.d

2013-10-08 Пенетрантность Aleksandr Sytar

8 октября 2013 г., 13:35 пользователь Vladimir Skubriev 
vladi...@skubriev.ru написал:

 Мне нужно добавить дополнительные настройки в секцию

 http {

 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 5m;
 ssl_prefer_server_ciphers on;
 ssl_stapling on;
 resolver 8.8.8.8;
 }

 которые отствуют в основном конфиг файле nginx: /etc/nginx/nginx.conf

 1. Могу ли я добавить это не в /etc/nginx/nginx.conf а а
 /etc/nginx/conf.d/http_**addition


Смотря в какую секцию конфига будут подключаться файла. Обычно там
определяются различные сервера которые уже входят в состав http.

Наверно лучше положить этот файл в другую папку и инклюдить оттуда в
соотвествующее место



 2. Что произойдет, если и в /etc/nginx/nginx.conf и в
 /etc/nginx/conf.d/http_**addition будут заданы одни и те же параметры, но
 с разными значениями ? Какой у кого будет приоритет.


Лучше этот вопрос уточнить в рассылке nginx.

что написать в /etc/hosts ?

2013-07-29 Пенетрантность Андрей Михалёв



Если в /etc/hosts не написать ничего, то при опущенной сети
1) нельзя сказать ping hostname
2) судо (и не только) начинает ругаться:
sudo: unable to resolve host hostname

Если в /etc/hosts написать: 127.0.0.1 hostname, то хост лишается домена:
% hostname -f
hostname

Если в /etc/hosts написать: 127.0.0.1 hostname hostname.domain, 
то придя в другое место домен остаётся тот же:

% hostname -f
hostname.domain


А хочется что бы:

0) всегда
hostname - 127.0.0.1

1) при опущенной сети
%hostname -f
hostname
или
hostname.default_domain

2) при поднятой сети в знакомом домене
% hostname -f
hostname.domain

--
sergio.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f65254.9070...@sergio.spb.ru

Re: что написать в /etc/hosts ?

127.0.0.1   localhost
127.0.1.1   servername.domain   servername



29 июля 2013 г., 18:30 пользователь sergio mail...@sergio.spb.ru написал:


 Если в /etc/hosts не написать ничего, то при опущенной сети
 1) нельзя сказать ping hostname
 2) судо (и не только) начинает ругаться:
 sudo: unable to resolve host hostname

 Если в /etc/hosts написать: 127.0.0.1 hostname, то хост лишается
 домена:
 % hostname -f
 hostname

 Если в /etc/hosts написать: 127.0.0.1 hostname hostname.domain, то
 придя в другое место домен остаётся тот же:
 % hostname -f
 hostname.domain


 А хочется что бы:

 0) всегда
 hostname - 127.0.0.1

 1) при опущенной сети
 %hostname -f
 hostname
 или
 hostname.default_domain

 2) при поднятой сети в знакомом домене
 % hostname -f
 hostname.domain

 --
 sergio.


 --
 To UNSUBSCRIBE, email to 
 debian-russian-REQUEST@lists.**debian.orgdebian-russian-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/**51f65254.9070...@sergio.spb.ruhttp://lists.debian.org/51f65254.9070...@sergio.spb.ru





-- 
С уважением, Андрей Михалёв
Системный администратор
 451-023-713
 endru.mihalev

Re: что написать в /etc/hosts ?

2013-07-29 Пенетрантность Dmitry Fedorov

29 июля 2013 г., 18:30 пользователь sergio mail...@sergio.spb.ru написал:

 Если в /etc/hosts написать: 127.0.0.1 hostname, то хост лишается домена:
 % hostname -f
 hostname

Не лишается - hostname вообще никаким образом не связано с доменным именем.

Читать раздел THE FQDN из man hostname.

Более того, hostname это вообще не про сеть.

То, что в команду hostname запихнули поддержку fqdn,
это уже для удобства и неправильно.

Re: что написать в /etc/hosts ?

2013-07-29 Пенетрантность Hleb Valoshka

On 7/29/13, sergio mail...@sergio.spb.ru wrote:

 А хочется что бы:

 0) всегда
 hostname - 127.0.0.1

 1) при опущенной сети
 %hostname -f
 hostname
 или
 hostname.default_domain

 2) при поднятой сети в знакомом домене
 % hostname -f
 hostname.domain

Обычно 1) делается так:
127.0.0.1   localhost
127.0.1.1   hostnamehostname.domain

Насчёт 2) не скажу. А 0) неправильно.

Re: что написать в /etc/hosts ?

2013-07-29 Пенетрантность Петр Бондаренко


29.07.2013 17:30, sergio пишет:


Если в /etc/hosts не написать ничего, то при опущенной сети
1) нельзя сказать ping hostname
2) судо (и не только) начинает ругаться:
sudo: unable to resolve host hostname

Если в /etc/hosts написать: 127.0.0.1 hostname, то хост лишается 
домена:

% hostname -f
hostname

Если в /etc/hosts написать: 127.0.0.1 hostname 
hostname.domain, то придя в другое место домен остаётся тот же:

% hostname -f
hostname.domain


А хочется что бы:

0) всегда
hostname - 127.0.0.1

1) при опущенной сети
%hostname -f
hostname
или
hostname.default_domain

2) при поднятой сети в знакомом домене
% hostname -f
hostname.domain


вообще по-дефолту должно быть так:
127.0.0.1   localhost
127.0.1.1   sid.ntd.local   sid
И ни каких извращений.

--
С уважением,
Петр Бондаренко
Jabber: p...@xmpp.ru
ICQ: 5279414


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f65617.6040...@02rus.com

Re: что написать в /etc/hosts ?


On 29/07/13 15:44, Андрей Михалёв wrote:

127.0.0.1   localhost
127.0.1.1   servername.domain   servername


Если в /etc/hosts написать: 127.0.0.1 hostname hostname.domain, 
то придя в другое место домен остаётся тот же:

% hostname -f
hostname.domain

--
sergio.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f65a46.5020...@sergio.spb.ru

Re: что написать в /etc/hosts ?


On 29/07/13 15:46, Петр Бондаренко wrote:


вообще по-дефолту должно быть так:
127.0.0.1   localhost
127.0.1.1   sid.ntd.local   sid
И ни каких извращений.


Если в /etc/hosts написать: 127.0.0.1 hostname hostname.domain, 
то придя в другое место домен остаётся тот же:

% hostname -f
hostname.domain

--
sergio.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f65a99.2010...@sergio.spb.ru

Re: что написать в /etc/hosts ?

2013-04-23 Пенетрантность Кубашин Александр Сергеевич


On 29/07/13 15:50, Hleb Valoshka wrote:


0) всегда
hostname - 127.0.0.1



А 0) неправильно.



127.0.1.1   hostnamehostname.domain


А что это если не 0) ?



--
sergio.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51f65b4b.6030...@sergio.spb.ru

Re: что написать в /etc/hosts ?

2013-07-29 Пенетрантность Dmitrii Kashin

At Mon, 29 Jul 2013 15:30:28 +0400,
sergio wrote:
 
 А хочется что бы:
 
 0) всегда
 hostname - 127.0.0.1
 
 1) при опущенной сети
 %hostname -f
 hostname
 или
 hostname.default_domain
 
 2) при поднятой сети в знакомом домене
 % hostname -f
 hostname.domain

Для соблюдения 1) и 2) надо обёртку на bash написать.

 что написать в /etc/hosts ?

Не поможет, очевидно.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwp589w2.wl%free...@gmail.com

Re: как правильно конфигурировать системы при помощи chef,puppet, etc

17.04.2013 18:34, Владимир Скубриев пишет:

Изучаю chef уже целую неделю.

В процессе изучения способов конфигурации пакетов пришел к выводу, что
это можно делать разными способами.

Первый и самый простой вариант - это поддержка нужных конфигурационных
файлов пакетов с использованием шаблонов и переменных.

Второй способ это конфигурирование пакетов при помощи стандартных
средств конфигурации системы. Например debconf:
debconf-get-selections, debconf-set-selections.

Третий и видимо - это совместное использование обоих способов.

В связи с этим возникает вопрос а как правильно сочетать данные методы
или не сочетать?

Простой пример с которым я столкнулся.

Например мы хотим установить на клиенте libnss-ldapd. Но при этом на
клиенте:

1. Она может быть не установлена
2. Она может быть установлена - но не правильно сконфигурирована
3. Нам может понадобится изменить какие-то дополнительные параметры
этой библиотеки, конфигурирование которых не доступно через debconf.

Мы можем описать наш рецепт следующим образом:

1. Чтобы при установке использовался наш конфигурационный файл debconf
2. Чтобы при переустановке использовался наш конфигурационный файл
debconf
3. Дописывать скриптами в нужные нам конфигурационные файлы нужные
парамтеры.

Насколько я понимаю смысл использования chef, puppet - достижения
идемпотентности конфигурации настраиваемых машин. Насколько я понимаю
мне необходимо учитывать все возможные факторы, описывать решения для
них в рецептах и в дальнейшем совершенствовать свои рецепты, с целью
чтобы они соответствовали максимально той конфигурации, которую я хочу
получить.

Еще возникает вопрос про обновление системы.

В этом отношении у меня полная каша в голове. Проясните пожалуйста как
все должно быть. Что-то я совсем запутался.

Еще возникает вопрос чисто по системе debconf.

Где посмотреть в системе какие именно скрипты изменяют
конфигурационные файлы и вообще занимаются обработкой параметров базы
данных debconf.

Как данные скрипты относятся к ручной правке конфигурационных файлов
из практики ?

И как вообще принято администрировать систему debian в рамках моего
вопроса?

Я конечно понимаю, что очень много всего спросил. Увы подсказать не кому.

Надеюсь на понимание. Спасибо!

Поведение Puppet здесь очень простое, клиент (конечная машина) раз в пол
часа опрашивает сервер о своей конфигурации и каждый раз при этом
проверяет, что данная машина этой конфигурации соответствует.

Т.е.: Предположим, что за эти пол часа конфигурация на сервере не
изменилась, но на машине был удалён пакет или изменён конфигурационный
файл, за который отвечает Puppet. В этом случае Puppet переустановит
нужный пакет и вернёт файл конфигурации в то состояние, в котором он
находится на сервере.

Т.к. через Puppet у нас управляются не все сервисы, то периодически
возникают ситуации, что конфиг на конечной машине поправили, а puppet
это изменение отменил, т.к. на сервере puppet этот файл хранится в
предыдущей версии.

--
С уважением,
Кубашин Александр

Re: как правильно конфигурировать системы при помощи chef,puppet, etc

2013-04-18 Пенетрантность Alex Mestiashvili

On 04/17/2013 04:34 PM, Владимир Скубриев wrote:
Изучаю chef уже целую неделю.

В процессе изучения способов конфигурации пакетов пришел к выводу, что
это можно делать разными способами.

Третий и видимо - это совместное использование обоих способов.

В связи с этим возникает вопрос а как правильно сочетать данные методы
или не сочетать?

Простой пример с которым я столкнулся.

Например мы хотим установить на клиенте libnss-ldapd. Но при этом на
клиенте:

1. Она может быть не установлена
2. Она может быть установлена - но не правильно сконфигурирована
3. Нам может понадобится изменить какие-то дополнительные параметры этой
библиотеки, конфигурирование которых не доступно через debconf.

Мы можем описать наш рецепт следующим образом:

1. Чтобы при установке использовался наш конфигурационный файл debconf
2. Чтобы при переустановке использовался наш конфигурационный файл debconf
3. Дописывать скриптами в нужные нам конфигурационные файлы нужные
парамтеры.

Еще возникает вопрос про обновление системы.

Что будет в случае, если пакет был сконфигурирован через копирование
конфигурационного файла . Пользователь выполнил обновление системы.
Сработала пере конфигурация обновленного пакета и изменились
конфигурационные файлы.
если конфиг был изменен вручную, то по умолчанию dpkg спросит - а менять
ли конфиг или оставить как было.

у юзера есть root ? или sudo на aptitude update/upgrade ?

Еще возникает вопрос чисто по системе debconf.

Где посмотреть в системе какие именно скрипты изменяют конфигурационные
файлы и вообще занимаются обработкой параметров базы данных debconf.

man debconf
It's more typical for debconf to be used via dpkg-preconfigure(8) or
dpkg-reconfigure(8).

а так preinst/postinst и т.д. скрипты лежат в /var/lib/dpkg/info/

Как данные скрипты относятся к ручной правке конфигурационных файлов из
практики ?

в зависимости от того как они написаны :) .

И как вообще принято администрировать систему debian в рамках моего
вопроса?

админ - хозяин. какой конфиг он установил такой и должен стоять.

в крайнем случае Debian это конструктор в которым можно переставить
пакет как надо.

главное не забывать бекапы важных, рабочих конфигов.
Я конечно понимаю, что очень много всего спросил. Увы подсказать не кому.

Надеюсь на понимание. Спасибо!

Удачи,
Alex

как правильно конфигурировать системы при помощи chef,puppet, etc

2013-04-17 Пенетрантность Владимир Скубриев

Изучаю chef уже целую неделю.

В процессе изучения способов конфигурации пакетов пришел к выводу, что
это можно делать разными способами.

Третий и видимо - это совместное использование обоих способов.

В связи с этим возникает вопрос а как правильно сочетать данные методы
или не сочетать?

Простой пример с которым я столкнулся.

Например мы хотим установить на клиенте libnss-ldapd. Но при этом на
клиенте:

1. Она может быть не установлена
2. Она может быть установлена - но не правильно сконфигурирована
3. Нам может понадобится изменить какие-то дополнительные параметры этой
библиотеки, конфигурирование которых не доступно через debconf.

Мы можем описать наш рецепт следующим образом:

1. Чтобы при установке использовался наш конфигурационный файл debconf
2. Чтобы при переустановке использовался наш конфигурационный файл debconf
3. Дописывать скриптами в нужные нам конфигурационные файлы нужные
парамтеры.

Еще возникает вопрос про обновление системы.

Еще возникает вопрос чисто по системе debconf.

Где посмотреть в системе какие именно скрипты изменяют конфигурационные
файлы и вообще занимаются обработкой параметров базы данных debconf.

Как данные скрипты относятся к ручной правке конфигурационных файлов из
практики ?

И как вообще принято администрировать систему debian в рамках моего вопроса?

Я конечно понимаю, что очень много всего спросил. Увы подсказать не кому.

Надеюсь на понимание. Спасибо!

--
С Уважением,
специалист по техническому и программному обеспечению,
системный администратор

Скубриев Владимир
~~~
Россия, Ростовская область, г. Таганрог

тел. моб: +7 (918) 504 38 20
skype: v.skubriev
icq: 214-800-502
www: skubriev.ru

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-10-14 Пенетрантность Oleksandr Gavenko

On 2012-09-27, Artem Chuprina wrote:

  EB  Мне никогда и до половины этого ограничения подниматься не удавалось.
  EB  Какие есть практические примеры кроме fuse/cdrom/audio/video?

 zsh% groups
 ran root adm dialout cdrom floppy sudo audio dip video plugdev staff netdev 
 wireshark scanner bluetooth vboxusers
 zsh% groups|wc
   1  17 114

 (откуда, впрочем, следует, что ограничение таки подняли.  До 32?)

Запуская:

  #include stdlib.h
  #include stdio.h

  #include unistd.h

  #define PRINT_SYSINFO(id) printf(#id : %ld\n, sysconf(id))

  int main()
  {
  PRINT_SYSINFO(_SC_NGROUPS_MAX);
  return EXIT_SUCCESS;
  }

получил:

  _SC_NGROUPS_MAX: 65536

Artem Chuprina привел данные (ограничение в 32 группы) для старых ядер Linux.
Список ограничений по платформам:

  http://www.j3e.de/ngroups.html

В основном таки ограничение на 16/32 группы для вендорных UNIX и 1000 и более
для пользовательских ОС (Linux, BSD, Windows).

-- 
Best regards!


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87a9voc1ug@gavenkoa.example.com

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-28 Пенетрантность Artem Chuprina

Eugene Berdnikov - debian-russian@lists.debian.org @ Fri, 28 Sep 2012
00:02:12 +0400:

EB Не в postinst, а в preinst -- по статус-коду от groupadd.

... который будет точно таким же, если это ты сам при прошлой установке
ее добавил.

EB Я немного знаю борновский шелл и потому умею комбинировать разные условия
EB в предикаты. :-) В данном случае нужно скомбинировать статус от groupadd
EB с параметром $1, в который dpkg передаёт install, upgrade, etc.

Цикл установка-снос-установка эта система либо не переживает, либо
сносит группу при сносе. Подразумевая, что она ТОЧНО никому больше не
нужна, и юзеров в нее не добавляют (то есть информацию о членстве в
группе при сносе сохранять ТОЧНО не надо). При таком предположении
проще взять заведомо уникальное имя группы, сгенерированное путем
хэширования вывода /dev/random в момент сборки пакета, и не париться.

А в заданных мною условиях так делать нельзя.

EB К слову, это можно сделать и без помощи dpkg, но смысла в этом нет.

И какой?

EB Неважно. Скрипт должен обнаружить конфликт, а дальше требуются мозги.

У тебя уже false positive. На ровном, в общем, месте.

EB Лишь если я скрипт напишу неправильно. Вся нужная информация доступна.

Отнюдь. Тебе вроде даже должно бы хватать опыта, чтобы это увидеть.

Остальное, в общем, справедливо.

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-28 Пенетрантность Eugene Berdnikov

On Fri, Sep 28, 2012 at 10:01:08AM +0400, Artem Chuprina wrote:
Eugene Berdnikov - debian-russian@lists.debian.org @ Fri, 28 Sep 2012
00:02:12 +0400:

EB Не в postinst, а в preinst -- по статус-коду от groupadd.

... который будет точно таким же, если это ты сам при прошлой установке
ее добавил.

EB Я немного знаю борновский шелл и потому умею комбинировать разные
условия
EB в предикаты. :-) В данном случае нужно скомбинировать статус от groupadd
EB с параметром $1, в который dpkg передаёт install, upgrade, etc.

Ну да, изначально к рассмотрению была предложена ситуация, когда пакет
считает свою группу уникальной, тогда обнаружение группы с идентичным
именем при установке означает конфликт. Самая верхняя твоя цитата:
то же имя группы с другими целями использует какой-то другой пакет.

При таком предположении
проще взять заведомо уникальное имя группы, сгенерированное путем
хэширования вывода /dev/random в момент сборки пакета, и не париться.

Хэш плох тем, что имя группы будет длинным и/или лишённым смысловой нагрузки.
При этом от софтины требуется возможность менять имя своей рабочей группы.
--
Eugene Berdnikov

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-28 Пенетрантность Artem Chuprina

Eugene Berdnikov - debian-russian@lists.debian.org  @ Fri, 28 Sep 2012 
11:19:24 +0400:

  Ну, ты хотя бы эти три раскрой.  Вот у тебя пакет, который
  внутри кода использует имя группы, допустим, remote-dev.  Начнем
  с вопроса как ты в postinst обнаруживаешь, что то же имя группы
  с другими целями использует какой-то другой пакет?

 EB  Не в postinst, а в preinst -- по статус-коду от groupadd.

... который будет точно таким же, если это ты сам при прошлой установке
ее добавил.
  
   EB  Я немного знаю борновский шелл и потому умею комбинировать разные 
  условия
   EB  в предикаты. :-) В данном случае нужно скомбинировать статус от 
  groupadd
   EB  с параметром $1, в который dpkg передаёт install, upgrade, etc.
  
  Цикл установка-снос-установка эта система либо не переживает, либо
  сносит группу при сносе.  Подразумевая, что она ТОЧНО никому больше не
  нужна, и юзеров в нее не добавляют (то есть информацию о членстве в
  группе при сносе сохранять ТОЧНО не надо).

 EB  Ну да, изначально к рассмотрению была предложена ситуация, когда пакет
 EB  считает свою группу уникальной, тогда обнаружение группы с идентичным
 EB  именем при установке означает конфликт. Самая верхняя твоя цитата:
 EB  то же имя группы с другими целями использует какой-то другой пакет.

Изначально - в смысле Олександром - как раз нет.  Он как раз писал (в
том числе) о группах потенциально общего пользования.  И в моей цитате
существенно с другими целями.  Если с теми же целями - то это как раз
нормально.

Впрочем, даже в случае уникальности, если в группу надо добавлять
реальных юзеров, то сносить ее при remove нельзя, можно только при
purge.  А значит, цикл установка-снос-установка все равно приводит тебя
к false positive.  Нет, опять же можно делать разделение есть
заполненный конфиг - нет заполненного конфига для различения ситуации
был remove или не было, но тут ты немедленно станешь недружелюбным по
отношению к пресидам debconf.  Это тоже можно учесть и обработать, но
сложность задачи и количество информации, которую нужно добыть и учесть,
растет на глазах.

Как раз в случае уникальности при грамотном выборе имени группы можно
рассчитывать на то, что наличие ее в системе НЕ является признаком
конфликта, а является вот ровно следом от прошлой установки, и надо
молча использовать готовое, а не подскакивать нервно.

   При таком предположении
  проще взять заведомо уникальное имя группы, сгенерированное путем
  хэширования вывода /dev/random в момент сборки пакета, и не париться.

 EB  Хэш плох тем, что имя группы будет длинным и/или лишённым
 EB  смысловой нагрузки.  При этом от софтины требуется возможность
 EB  менять имя своей рабочей группы.

Осмысленный префикс и часть хэша.  git вон сокращает в норме до первых 7
символов свой sha1, на практике хватает.  (Он, правда, умеет работать и
с полным, и возможно, даже каждый раз проверяет на уникальность
сокращенный прежде чем выбрать ОДИН коммит - но на коллизию по полному
он уже явно не рассчитан.  Но это детали, а на практике семи хватает.)
exim-d25caac вряд ли так уж сильно уступает в осмысленности Debian-exim
и всего на 1 символ длиннее, и при этом шансы нарваться на то, что
кто-то другой случайно получит со своего /dev/random такой же результат,
куда ближе к нулю, чем вероятность допустить ошибку в решении
вышеобсуждаемой задачи.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87obkq36fg@wizzle.ran.pp.ru

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-28 Пенетрантность Ivan Shmakov

 Artem Chuprina r...@ran.pp.ru writes:

[…]

  exim-d25caac вряд ли так уж сильно уступает в осмысленности
  Debian-exim и всего на 1 символ длиннее,

А если использовать новомодный Base32 вместо традиционного Hex,
то даже и не длиннее…

  и при этом шансы нарваться на то, что кто-то другой случайно получит
  со своего /dev/random такой же результат, куда ближе к нулю, чем
  вероятность допустить ошибку в решении вышеобсуждаемой задачи.

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/864nmitbst@gray.siamics.net

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

On Thu, Sep 27, 2012 at 09:56:23AM +0400, Artem Chuprina wrote:
Eugene Berdnikov - debian-russian@lists.debian.org @ Thu, 27 Sep 2012
09:39:36 +0400:

EB P.S. Если бы я был автором и/или мейнтейнером пакета, мне совсем
EB не хотелось бы иметь геморрой с центральным репозиторием имён групп.
EB Конфликты можно выявлять тем же скриптом, который вызывает addgroup.
EB См. /var/lib/dpkg/info/openssh-client.postinst например.

Конфликты по _именам_ групп, боюсь, поздновато разрешать на стадии
postinst. И даже на стадии preinst тоже поздновато.

Разрешение конфликтов -- другая песня, я писал выявлять...

Их надо разрешать на стадии написания debian/rules.

Не думаю, что проблема столь остра, что для её решения нужна централизация.
Тот, кто особо озабочен, может включить в имя группы имя пакета в качестве
префикса или суффикса. Есть же у нас, к примеру, Debian-exim.
--
Eugene Berdnikov

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-27 Пенетрантность Artem Chuprina

Eugene Berdnikov - debian-russian@lists.debian.org @ Thu, 27 Sep 2012
10:31:51 +0400:

Конфликты по _именам_ групп, боюсь, поздновато разрешать на стадии
postinst. И даже на стадии preinst тоже поздновато.

EB Разрешение конфликтов -- другая песня, я писал выявлять...

Тем более - выявлять :) Ну, выявил ты (кстати, как? приведенный в пример
postinst от openssh-client делает совсем другое, и никаких конфликтов не
выявляет), что твое любимое имя группы кто-то заюзал совершенно для
других целей. Что дальше?

Их надо разрешать на стадии написания debian/rules.

EB Не думаю, что проблема столь остра, что для её решения нужна
EB централизация. Тот, кто особо озабочен, может включить в имя
EB группы имя пакета в качестве префикса или суффикса. Есть же у нас,
EB к примеру, Debian-exim.

Ну вот это другой вопрос. И с этим я согласен. Хотя Олександр, в
общем, задал здравый вопрос: как договариваться, если есть несколько
пакетов, предоставляющих одну функциональность? Ответ на него есть, но
другой - use the brain, Luke :)

source тут, в общем, ни при чем.

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-27 Пенетрантность Andrey Rahmatullin

On Thu, Sep 27, 2012 at 12:03:32PM +0400, Artem Chuprina wrote:
твое любимое имя группы кто-то заюзал совершенно для
других целей. Что дальше?

1. Вступить в переписку с нарушителем спокойствия и договориться.
2. Забить и сделать себе заведомо уникальное имя группы.
3. Выкинуть в pre/post-install-script диалоговое окошко и предложить
чесать репу юзеру.

+ наверное, ещё 100500 вариантов в зависимости от обстановки.

Хотя Олександр, в
общем, задал здравый вопрос: как договариваться, если есть несколько
пакетов, предоставляющих одну функциональность? Ответ на него есть, но
другой - use the brain, Luke :)

Для идентичной функциональности вопрос звучит так: что делать, если
договориться не удастся? Тогда только поменять содержимое provides,
скажем, с mail-transport-agent на MTA, и таким образом отмежеваться.
--
Eugene Berdnikov

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

On Thu, Sep 27, 2012 at 01:21:14AM +0300, Oleksandr Gavenko wrote:
Полиси детально еще не читал. Простые вопросы:
Вы хотите, чтобы за вас прочитали полиси и вам бесплатно пересказали. Не
делайте так больше.

*детально*
Какая разница?

На вскидку, *как я писал выше*, в

/usr/share/doc/debian-reference-common/html/debian-reference.en.txt.gz

описано назначение 10 групп.
Я это читал, но при чём тут?

У меня в /etc/group их 76, все пакеты из официальных репозиториев.

Например, для группы colord я смогу выяснить что за X:

$ apt-cache search colord
colord - system service to manage device colour profiles -- system daemon
Не сможете, как вам уже сказали рядом.

а вот о происхождении ничего не известно:

$ apt-cache search stapdev
$ apt-file search stapdev
$ dhelp stapdev

И таких групп много.
А тут вам никакое полиси и не поможет, вы бы с таким же успехом могли
пойти в рассылку спрашивать, кто вам файл в $HOME создал.

Я уже отмечал в этой группе, что вы тролите.
Мне до ваших отмечаний дела нет, я лишь заметил, что полиси содержит
ответы на часть ваших вопросов, но вы не просто не удосужились их там
прочитать, но ещё и нагло заявили об этом в письме, в котором просите
других вам это пересказать.

Одно дело когда вы отвечаете, другое - когда посылаете RTFM.
Ага, т.е. отправку в документацию вы ответом не считаете? Хорошо, я могу и
вас в киллфайл сунуть.

--
WBR, wRAR

signature.asc
Description: Digital signature

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-27 Пенетрантность Artem Chuprina

Eugene Berdnikov - debian-russian@lists.debian.org @ Thu, 27 Sep 2012
12:31:00 +0400:

твое любимое имя группы кто-то заюзал совершенно для
других целей. Что дальше?

EB 1. Вступить в переписку с нарушителем спокойствия и договориться.
EB 2. Забить и сделать себе заведомо уникальное имя группы.
EB 3. Выкинуть в pre/post-install-script диалоговое окошко и предложить
EB чесать репу юзеру.

EB + наверное, ещё 100500 вариантов в зависимости от обстановки.

Ну, ты хотя бы эти три раскрой. Вот у тебя пакет, который внутри кода
использует имя группы, допустим, remote-dev. Начнем с вопроса как ты в
postinst обнаруживаешь, что то же имя группы с другими целями использует
какой-то другой пакет? И какой? Грепом по чужим постинстам? А если
его ставят после тебя? А что цели другие, ты откуда узнаешь? Может, он
использует твою группу, потому что цели у него те же, а может, нет...
Хорошо, допустим, ты на него ответил положительно. Твой скрипт на
юзерской системе узнал, с кем он конфликтует по имени группы. Кто будет
вступать в переписку с нарушителем спокойствия?

Делать заведомо уникальное имя можно пытаться, но только в случае, если
тебе не надо включать в эту группу реальных юзеров. Ибо в скольких
группах у нас одновременно может быть юзер без специальных телодвижений,
сводящихся как минимум к перекомпиляции ядра? 16, кажется?

Вариант предложить юзеру чесать репу подразумевает как минимум, что твоя
софтина может жить с другим именем группы без пересборки, как максимум
на уровне конфигурации. Ты майнтейнер, не апстрим-автор. Ты уверен,
что эта штука сможет?

В общем, твои предложения вызывают больше вопросов, чем дают ответов...

EB Для идентичной функциональности вопрос звучит так: что делать, если
EB договориться не удастся? Тогда только поменять содержимое provides,
EB скажем, с mail-transport-agent на MTA, и таким образом отмежеваться.

Речь не шла, насколько я понимаю, о том, что договориться не удастся.
Речь шла о том, какова процедура договаривания.

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

On Thu, Sep 27, 2012 at 04:12:34PM +0400, Artem Chuprina wrote:
Eugene Berdnikov - debian-russian@lists.debian.org @ Thu, 27 Sep 2012
12:31:00 +0400:

твое любимое имя группы кто-то заюзал совершенно для
других целей. Что дальше?

EB + наверное, ещё 100500 вариантов в зависимости от обстановки.

Не в postinst, а в preinst -- по статус-коду от groupadd.

И какой?

Неважно. Скрипт должен обнаружить конфликт, а дальше требуются мозги.

Грепом по чужим постинстам? А если его ставят после тебя?

После нас -- хоть потоп! :)

Пусть тормозят те, кто позади. Да, всегда кто-то может въехать в зад,
идеального средства от кретинов нет, но подбор уникального имени для
группы снижает риск возможного клинча.

А что цели другие, ты откуда узнаешь? Может, он
использует твою группу, потому что цели у него те же, а может, нет...
Хорошо, допустим, ты на него ответил положительно. Твой скрипт на
юзерской системе узнал, с кем он конфликтует по имени группы. Кто будет
вступать в переписку с нарушителем спокойствия?

В переписку вступит тот, кто пакетирует софт -- это его работа.

Если софт не умеет скушать алтернативное имя группы, то может потребоваться
переписка с автором. Это тоже работа мейнтейнера.

Если автор невменям, и без патчей не обойтись -- их придётся сделать
мейнтейнеру. Это тоже его работа. :)

Мне никогда и до половины этого ограничения подниматься не удавалось.
Какие есть практические примеры кроме fuse/cdrom/audio/video?
Я посмотрел свой /etc/group и нашёл ещё fax и scanner, всё остальное
либо для системных процессов, либо слегка надуманное (вроде vboxusers).

См. выше.

В общем, твои предложения вызывают больше вопросов, чем дают ответов...
...
Речь не шла, насколько я понимаю, о том, что договориться не удастся.
Речь шла о том, какова процедура договаривания.

Процедура обычная: по e-mail. Но если кто-то хочет порулить глобальным
распределением имён групп, и комьюнити его поддержит -- пожалуйста.
Я не против, просто думаю что это излишне.
--
Eugene Berdnikov

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.

2012-09-27 Пенетрантность Artem Chuprina

Eugene Berdnikov - debian-russian@lists.debian.org @ Thu, 27 Sep 2012
16:59:39 +0400:

твое любимое имя группы кто-то заюзал совершенно для
других целей. Что дальше?

EB + наверное, ещё 100500 вариантов в зависимости от обстановки.

EB Не в postinst, а в preinst -- по статус-коду от groupadd.

... который будет точно таким же, если это ты сам при прошлой установке
ее добавил.

И какой?

EB Неважно. Скрипт должен обнаружить конфликт, а дальше требуются мозги.

У тебя уже false positive. На ровном, в общем, месте.

Грепом по чужим постинстам? А если его ставят после тебя?

EB После нас -- хоть потоп! :)

EB Пусть тормозят те, кто позади. Да, всегда кто-то может въехать в зад,
EB идеального средства от кретинов нет, но подбор уникального имени для
EB группы снижает риск возможного клинча.

Про уникальное имя понятно, я как раз нарочно предложил группу, которую
потенциально несколько пакетов могут использовать как с одной, так и с
разными целями.

EB В переписку вступит тот, кто пакетирует софт -- это его работа.

Вот мне странно. Конфликт обнаружил скрипт, у юзера, когда оба пакета
уже давно в дистрибутиве. И тут каким-то магическим образом вступает в
переписку пакетировщик... Нет, магия, в общем, понятна - man reportbug.
Но мой point в том, что мне здравый смысл подсказывает: если ты хочешь
работать с потенциально не тебе одному нужной группой, стоит задать
вопрос до того, как ты выложишь пакет, а не после того, как на эти
грабли встанет кто-то из пользователей.

Что Олександр и попытался начать делать. А ты на него наехал.

EB Мне никогда и до половины этого ограничения подниматься не удавалось.
EB Какие есть практические примеры кроме fuse/cdrom/audio/video?

zsh% groups
ran root adm dialout cdrom floppy sudo audio dip video plugdev staff netdev
wireshark scanner bluetooth vboxusers
zsh% groups|wc
1 17 114

(откуда, впрочем, следует, что ограничение таки подняли. До 32?)

EB Я посмотрел свой /etc/group и нашёл ещё fax и scanner, всё остальное
EB либо для системных процессов, либо слегка надуманное (вроде vboxusers).

Надуманное или нет, а это как раз то самое уникальное имя. Проблему с
больной головы авторов и пакетировщиков успешно спихнули на здоровую
голову юзеров. Или вон там выше в списке есть wireshark. Ну накойхер
ему отдельная группа? С точки зрения прав доступа тем, кому нужен
wireshark, нужны также tcpdump, nmap etc.

В общем, твои предложения вызывают больше вопросов, чем дают ответов...
EB ...
Речь не шла, насколько я понимаю, о том, что договориться не удастся.
Речь шла о том, какова процедура договаривания.

EB Процедура обычная: по e-mail.

Вот, это уже ответ ближе к правильному. Только он почти бессмысленный.
Осмысленным был бы ответ выяснить, какие еще есть в дистрибутиве пакеты
с релевантной функциональностью и списаться с их авторами.

Re: Известные группы в /etc/group. Ищу официальное описание и полиси.