subject:"Правильные демоны \- не демоны\?"

Hello!

On Friday 28 August 2009 06:36:46 Roman S. Gushcha wrote:
Ты все в кучу свалил. init.d и inittab вообще не решают задачу демонизации.
В обсуждаемом контексте (запуск и управление сервисами) они могут
работать только с процессами, которые _сами_по_себе_ запускаются как
демоны, т.е. без управляющего терминала. Задачи у этих двух систем
разные:

Не так. Если нужно запустить пользовательского демона, пишем скрипт в
/etc/init.d/, чтобы запустить пользовательского не-демона - вписываем его в
inittab. В последнем случае логирование отсутствует, в первом случае -
отсутствует контроль за состоянием процесса. В случае inittab некий контроль
состояния наличествует, но весьма странный - определенное число попыток
перезапуска с сообщением об ошибках в syslog, просмотреть состояние иначе
чем через ps ...|grep ... не получится и т.п.

Собственно, накопилось много всего, запускаемого из inittab и init.d, собрался
это задокументировать. Но скрипты inet.d монстрообразные и содержат
бесполезные прослойки (через ps удобнее смотреть, с какими параметрами
сервис запущен, нежели разбираться в таких скриптах, лазить в defaults проч.).
Пришел к выводу, что лучше для пользовательских сервисов сменить систему
запуска на нечто более простое и функциональное, нежели дальше с этим жить.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 09:46:25 Artem Chuprina wrote:
Если сделать в программе функцию log_message(int verbosity_level, const
char *format, ...), то переделывать, когда ты узнаешь о том, какой
вообще бывает логгинг, тебе придется только эту функцию.

И что - любой юзер будет сливать свои логи в /var/log/syslog или
/var/log/messages? А туда по умолчанию все и идет... Рыскать по системным
логам, разыскивая валящийся туда мусор и перенастраивая конфиг сислога
и логротэйта я не считаю полезной деятельностью.

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

AP Кроме того, для того, чтобы вывод пользовательской программы
AP направить в отдельный файл, надо отредактировать конфиг сислога и
AP перезапустить его - и все это с правами рута. А потом еще нужно
AP настроить ротацию этого лога, отредактировав еще один конфиг...

А это ничего, что эти конфиги могут быть на разных машинах? И именно
поэтому они разные?

Какой смысл в syslog и logrotate на _разных_ машинах?

Правда, в винде, помнится, удобных инструментов работы с пайпом вообще
нет :-) tcl, к примеру, на них работать не умеет :-(

Линуксовая работа с пайпами в виндовом тикле есть.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 12:34:26 Alexander Galanin wrote:
  И что - любой юзер будет сливать свои логи в /var/log/syslog или
  /var/log/messages? А туда по умолчанию все и идет... Рыскать по системным 
  логам, разыскивая валящийся туда мусор и перенастраивая конфиг сислога 
  и логротэйта я не считаю полезной деятельностью.
 
 Между прочим, разделение логов по файлам ви сислоге есть. Но читать маны
 тебе неинтересно, тебе интереснее велосипеды изобретать и ломать
 прилично работающую систему.
 
 
Хорошо, скажите, как обеспечить _автоматическое_ разделение по файлам в 
зависимости от того, какой сервис пишет в лог (пусть имя бинаря совпадает
с поддиректорией в /var/log/). Мне вот ручками приходится:

local0.=info -/var/log/haproxy/access.log
local0.=crit;local0.=err;local0.=warn;local0.=notice 
-/var/log/haproxy/haproxy.log

Да еще спрятанные грабли надо убрать - local0 и local1 на какой-то ляд 
пишутся по дефолту в messages:

*.=info;*.=notice;*.=warn;\
--auth,authpriv.none;\
--cron,daemon.none;\
--mail,news.none;\
--!local0.*;!local1.*/var/log/messages

Жду мантры от читающего маны.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Alexey Pechnikov - debian-russian@lists.debian.org @ Fri, 28 Aug 2009
12:15:41 +0400:

Если сделать в программе функцию log_message(int verbosity_level,
const char *format, ...), то переделывать, когда ты узнаешь о том,
какой вообще бывает логгинг, тебе придется только эту функцию.

AP И что - любой юзер будет сливать свои логи в /var/log/syslog или
AP /var/log/messages? А туда по умолчанию все и идет... Рыскать по
AP системным логам, разыскивая валящийся туда мусор и перенастраивая
AP конфиг сислога и логротэйта я не считаю полезной деятельностью.

А вот grep - это как раз unix way... Там при коннекте имя задается.

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

Можно подумать, при любой другой системе на _это_ время тратить не
надо...

А это ничего, что эти конфиги могут быть на разных машинах? И именно
поэтому они разные?

AP Какой смысл в syslog и logrotate на _разных_ машинах?

logrotate осмыслен там, где логи хранятся. А syslog - там, где они
генерируются. Ы?

AP Линуксовая работа с пайпами в виндовом тикле есть.

Это работа с юниксовой эмуляцией пайпов. А я про виндовые пайпы.
Именованные. Которые умеют message passing, в отличие от юниксового
аналога (называемого UNIX socket). С которым tcl, кстати, тоже работать
не умеет.

--
Правки Белявского, сделанные им в рабочей копии головы
-- Из коммитлога.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 14:07:02 Alexander Galanin wrote:
 rsyslog, к примеру (никто ведь не заставляет использовать только одну из
 многочисленных инкарнаций syslogd), умеет составлять имя файла из
 полей сообщения. Вот неизменённый кусок из документации, который, я
 надеюсь, ты осилишь допилить до нужного тебе:
 
 $template DynFile,/var/log/%HOSTNAME%/%programname%.log

Пример процесса:
/usr/sbin/aolserver4-nsd -i -u www-data -g www-data -b 127.0.0.1:8NNN -s main 
-t /var/www/offlineNNN/etc/aolserver4.tcl

Этот процесс клонируется сколько-то раз (в том числе, каждый 
разработчик может для себя один или более экземпляров запустить), при этом
меняется число NNN. Каждый процесс посылает сообщения разного уровня в 
сислог (ошибки, информация, предупреждения, плюс еще нужно разделить
сообщения по имени модуля регекспами). Логи должны писаться с правами 
пользователя, который запустил клон и желательно в ~/log/ Положим, 
NNN можно передать в самих сообщениях, rsyslog в этом случае логи разделит. 
Но пользователя получить не удастся, такая информация в syslog не передается.
И как изменить права на эти лог-файлы? Есть ли какая-то утилита, которая 
умеет с stdout брать лог и пересылать в syslog - чтобы объединять сообщения 
в единый лог-файл?

Запуск и логирование через runit решает все описанные выше задачи, чем он
мне и понравился (в том числе можно разрешить пользователям от их имени
управлять своими сервисами, даже sudo не давая). Правила запуска и 
логирования для runit - отдельные скрипты для каждого сервиса, так что 
клонировать просто. Имхо на стандартном init/syslog подобное нереализуемо.
Вот для каких-то глобальных вещей, например, сбора access log всех серверов,
rsyslog удобен, раз настроил и работает. А для множества динамически 
создаваемых и конфигурируемых сервисов syslog вообще никак не пригоден.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 14:38:42 Artem Chuprina wrote:
AP Вопрос не в том, что технически сложно делать вывод логов в сислог
AP - это-то как раз не проблема. Вопрос в том, что сислог лихо свалит
AP все логи вместе. Десяток-другой пользовательских приложений - и
AP уже можно долго терять время, придумывая, кого на какие уровни
AP распихать и как это все по файлам разделить.

Можно подумать, при любой другой системе на _это_ время тратить не
надо...

В другом сообщении я уже объяснял, что нереально при каждом
клонировании/удалении сервиса править конфиг сислога.

AP Какой смысл в syslog и logrotate на _разных_ машинах?

logrotate осмыслен там, где логи хранятся. А syslog - там, где они
генерируются. Ы?

Раз syslog генерирует логи, то и на запись права имеет. А раз имеет, то может
ротировать. Разумеется, может и не ротировать, если вам так хочется.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 15:02:52 Alexander Galanin wrote:
 On Fri, 28 Aug 2009 14:51:55 +0400
 Alexey Pechnikov pechni...@mobigroup.ru wrote:
 
  Hello!
  
  On Friday 28 August 2009 14:07:02 Alexander Galanin wrote:
   rsyslog, к примеру (никто ведь не заставляет использовать только одну из
   многочисленных инкарнаций syslogd), умеет составлять имя файла из
   полей сообщения. Вот неизменённый кусок из документации, который, я
   надеюсь, ты осилишь допилить до нужного тебе:
   
   $template DynFile,/var/log/%HOSTNAME%/%programname%.log
  
  Этот процесс клонируется сколько-то раз (в том числе, каждый 
  разработчик может для себя один или более экземпляров запустить), при этом
  меняется число NNN. Каждый процесс посылает сообщения разного уровня в 
  сислог (ошибки, информация, предупреждения, плюс еще нужно разделить
  сообщения по имени модуля регекспами). Логи должны писаться с правами 
  пользователя, который запустил клон и желательно в ~/log/ Положим, 
  NNN можно передать в самих сообщениях, rsyslog в этом случае логи разделит. 
  Но пользователя получить не удастся, такая информация в syslog не 
  передается.
 
 А ты передай. Рядом с NNN.

Сервис может быть запущен пользователем X, но от имени www-data. Это только
система init знает, кто же на самом деле запустил.
 
  Есть ли какая-то утилита, которая 
  умеет с stdout брать лог и пересылать в syslog - чтобы объединять сообщения 
  в единый лог-файл?
 
 Наверно я открою тебе великую тайну, но можно сделать ещё и
 $command logfile 2errlogfile
 причём безо всяких проходов через syslog.
 И потом останавливать этот так называемый сервис в том же xterm-е, в
 котором ты его запустил, с помощью Ctrl-C.

Полезнее ctrl+z; bg 1; fg 1 :-) Вот только настроить размеры буферов чтения
из stdout и записи в файл лога уже не так тривиально. Да еще ротировать нужно.
Для того syslog и полезен, что позволяет эффективно писать большие логи и 
ротировать их. Но, к сожалению, на этом его достоинства практически 
заканчиваются.

 А уж если тебе понадобится форвардить stdout и stderr в syslog, написать
 малюсенькую утилиту в 10 строк на си сможет кто угодно, у кого команда
 man 3 syslog не вызывает священного ужаса.

runit/daemontools это и так делают - берут с stdout/stderr и пишут в нужный лог 
от имени пользователя, фильтруют и ротируют. Притом они точно знают, кто же 
запустил данный сервис, даже если он выполняется с правами совсем иного юзера 
и могут логировать в домашнюю директорию с нужными правами. И буферы
ввода-вывода позволяют настроить. 

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Alexey Pechnikov - debian-russian@lists.debian.org @ Fri, 28 Aug 2009
14:59:03 +0400:

Можно подумать, при любой другой системе на _это_ время тратить не
надо...

AP В другом сообщении я уже объяснял, что нереально при каждом
AP клонировании/удалении сервиса править конфиг сислога.

Реально. Непонятно только, на кой.

AP Какой смысл в syslog и logrotate на _разных_ машинах?

logrotate осмыслен там, где логи хранятся. А syslog - там, где они
генерируются. Ы?

AP Раз syslog генерирует логи, то и на запись права имеет. А раз
AP имеет, то может ротировать. Разумеется, может и не ротировать, если
AP вам так хочется.

syslog, принимающий сообщения от приложения, и syslog, записывающий
файлы - это РАЗНЫЕ, вообще говоря, сислоги.

А логи он не ротирует согласно unix way - каждой задаче свой инструмент.
logrotate умеет ротировать не только сислоговские логи - и нафига эту
функциональность еще в сислоге дублировать? Чтоб они подрались?

--
Пользователь юникса перестаёт быть пользователем юникса если после его
пользования пользованный юникс перестаёт быть юниксом. (с)

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Alexander Galanin - debian-russian@lists.debian.org  @ Fri, 28 Aug 2009 
14:43:35 +0400:

  аналога (называемого UNIX socket).  С которым tcl, кстати, тоже работать
  не умеет.

 AG Умеет, только этого в tcl core по понятным причинам нет. Но после
 AG package require ceptcl появляется.

You have searched for filenames that contain ceptcl in suite lenny, all
sections, and all architectures.

Sorry, your search gave no results

-- 
Все события вымышлены, после чего искажены.
 -- lj user=mcdowns


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 15:24:18 Artem Chuprina wrote:
 Alexander Galanin - debian-russian@lists.debian.org  @ Fri, 28 Aug 2009 
 14:43:35 +0400:
 
   аналога (называемого UNIX socket).  С которым tcl, кстати, тоже работать
   не умеет.
 
  AG Умеет, только этого в tcl core по понятным причинам нет. Но после
  AG package require ceptcl появляется.
 
 You have searched for filenames that contain ceptcl in suite lenny, all
 sections, and all architectures.
 
 Sorry, your search gave no results
 
 

$ ls /srv/dload/|grep tcl
ceptcl

=
Ceptcl - Communications EndPoints for Tcl
2004 Stuart Cassoff  s...@telus.net

Ceptcl is a Tcl extension which provides a variety of new
socket types and greater control over socket options.

Domains : local, inet4, inet6
Types   : tcp, udp, raw
Options : many, see cep(n)

...
=

Best regards, Alexey Pechnikov.
http://pechnikov.tel/


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Alexey Pechnikov - debian-russian@lists.debian.org  @ Fri, 28 Aug 2009 
15:32:46 +0400:

аналога (называемого UNIX socket).  С которым tcl, кстати, тоже работать
не умеет.
  
   AG Умеет, только этого в tcl core по понятным причинам нет. Но после
   AG package require ceptcl появляется.
  
  You have searched for filenames that contain ceptcl in suite lenny, all
  sections, and all architectures.
  
  Sorry, your search gave no results

 AP $ ls /srv/dload/|grep tcl
 AP ceptcl

 AP =
 AP Ceptcl - Communications EndPoints for Tcl
 AP 2004 Stuart Cassoff  s...@telus.net

 AP Ceptcl is a Tcl extension which provides a variety of new
 AP socket types and greater control over socket options.

 AP Domains : local, inet4, inet6
 AP Types   : tcp, udp, raw
 AP Options : many, see cep(n)

 AP ...
 AP =

На http://www.tcl.tk я его и сам нашел.  Но у нас тут debian'овская
рассылка...

-- 
Голова не может думать.  Там кальций, а не кремний.
 -- (С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 15:19:43 Artem Chuprina wrote:
AP Какой смысл в syslog и logrotate на _разных_ машинах?

logrotate осмыслен там, где логи хранятся. А syslog - там, где они
генерируются. Ы?

syslog, принимающий сообщения от приложения, и syslog, записывающий
файлы - это РАЗНЫЕ, вообще говоря, сислоги.

Вот это большой плюс, но с глобальным сислогом проблем никаких - один
раз настроил и работает. Вопрос в множестве сервисов, которым нужно
локальное логирование (хотя с помощью socat локальный лог легко раздается
по сети, без каких-либо настроек или правок глобальных конфигов). И вот
эти сервисы часто меняются, причем должны бы по уму перенастраиваться
без редактирования системных конфигов.

logrotate тот же самый гусь, что и syslog - требует изменения глобального
конфига.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Alexey Pechnikov - debian-russian@lists.debian.org  @ Fri, 28 Aug 2009 
15:18:49 +0400:

 AP Сервис может быть запущен пользователем X, но от имени
 AP www-data. Это только система init знает, кто же на самом деле
 AP запустил.

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

-- 
Правки Белявского, сделанные им в рабочей копии головы
 -- Из коммитлога.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 15:44:05 Alexander Galanin wrote:
 Есть некая программа, которая разрабатывается в твоей конторе.
 Есть несколько разработчиков, одновременно на одном сервере её
 запускающих.
 Задача: получить логи от каждого инстанса раздельно и читать их со время
 отладки.
 Усложнение задачи: из-за недодумок в проектировании логгинг не
 абстрагирован от конкретного метода логгинга (через syslog).
 
 Решение:
 Реализовать два метода логгинга.
 Передавать метод логгинга (syslog/файл) и файл, в который писать
 результат, каждому инстансу программы как сейчас передаётся порт для
 ожидания входящих соединений.
 Фильтровать нужные записи из лога с помощью grep.

При работе с сислогом:
Передавать имя файла лога в каждой строке сообщений - криво и неудобно.
Получать логи в домашней директории, созданные с правами другого пользователя, 
еще хуже. Настроить разделение лога на несколько файлов или профильтровать 
при записи и вовсе нельзя (без прав рута и изменения конфига сислога).

Я в чем-то не прав?

  Да, если вам так просто написать эту самую малюсенькую утилиту, которая 
  будет
  через init-систему определять истинного владельца (по имени сервиса можно
  найти скрипт запуска), собирать логи, менять конфигурацию сислога для 
  логирования в нужную директорию и проч., хотелось бы это увидеть :-)
 
 Нет, милый друг, ты подменяешь задачу читать из пайпа и писать в
 syslog на другую.  А задачи, сформулированные через неприличное место,
 я решаю только за материальное вознаграждение.

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Stanislav Maslovski - debian-russian@lists.debian.org  @ Fri, 28 Aug 2009 
15:43:55 +0400:

  На http://www.tcl.tk я его и сам нашел.  Но у нас тут debian'овская
  рассылка...

 SM Да ну? Вспоминая периодические отсылки к шеллу соляриса... ;-)

Это разница между совместимостью и несовместимостью.

-- 
Все дуры - бабы
фольклор


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

2009-08-28 Пенетрантность San_Sanych


Alexey Pechnikov пишет:

Собственно, накопилось много всего, запускаемого из inittab и init.d, собрался
это задокументировать. Но скрипты inet.d монстрообразные и содержат
бесполезные прослойки (через ps удобнее смотреть, с какими параметрами 
сервис запущен, нежели разбираться в таких скриптах, лазить в defaults проч.).
Пришел к выводу, что лучше для пользовательских сервисов сменить систему 
запуска на нечто более простое и функциональное, нежели дальше с этим жить.


  

после таких слов возможно создание очередного форка дистрибутива :)

--
Александр Вайтехович
www: http://sanych.nnov.ru
jabber id: sanych{}sanych.nnov.ru


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Alexey Pechnikov - debian-russian@lists.debian.org @ Fri, 28 Aug 2009
15:45:01 +0400:

AP локальное логирование (хотя с помощью socat локальный лог легко
AP раздается по сети, без каких-либо настроек или правок глобальных
AP конфигов).

... и засирает сеть и затыкает оба логгера. Ты представляешь себе
_настоящие_ требования к логгеру?

AP И вот эти сервисы часто меняются, причем должны бы по уму
AP перенастраиваться без редактирования системных конфигов.
AP
А логи он не ротирует согласно unix way - каждой задаче свой инструмент.
logrotate умеет ротировать не только сислоговские логи - и нафига эту
функциональность еще в сислоге дублировать? Чтоб они подрались?

AP logrotate тот же самый гусь, что и syslog - требует изменения
AP глобального конфига.

Ты спрашивал, чего б сислогу не ротировать заодно, раз уж уже пишет
файлы. Я объяснил.

--
Если ничто уже не помогает, прочтите же, наконец, инструкцию!

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 17:00:33 Alexander Galanin wrote:
 On Fri, 28 Aug 2009 16:36:21 +0400
 Alexey Pechnikov pechni...@mobigroup.ru wrote:
 
  При работе с сислогом:
  Передавать имя файла лога в каждой строке сообщений - криво и неудобно.
  Получать логи в домашней директории, созданные с правами другого 
  пользователя, 
  еще хуже.
 
 Покуда ты не скажешь чем это криво, плохо и неудобно, эти слова
 ничего не значат. Если это только твои эстетические соображения, то
 ничем рассылка помочь не сможет.

Значит, логирование в файлы удовляетворяет как функциональным, так и 
эстетическим требованиям, а сислог не удовлетворяет обоим типам требований :-)

В runit я сделал так:
#!/bin/sh
exec chpst -u postgres:postgres svlogd -tt /var/log/postgresql/8.1

И получил лог с указанными правами в нужном месте. Также пользователи могут
создавать и запускать свои сервисы с нужными правами. А несмотря на все
утверждения о возможностях сислога, никто не предложил приемлемой
конфигурации для этой же задачи.

 Кстати, а на кой тебе при отладке запускать что-то от www-data, а не от
 себя?

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

  Настроить разделение лога на несколько файлов или профильтровать 
  при записи и вовсе нельзя (без прав рута и изменения конфига сислога).
 
 Опять же: зачем тебе это нужно? Только для галочки у меня логи про
 отладке разложились по полочкам?

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 17:15:59 Artem Chuprina wrote:
Alexey Pechnikov - debian-russian@lists.debian.org @ Fri, 28 Aug 2009
15:45:01 +0400:

... и засирает сеть и затыкает оба логгера. Ты представляешь себе
_настоящие_ требования к логгеру?

У меня такие требования только к одному haproxy, который благополучно шлет все
в сислог. А вот всего остального значительно больше, и для этой-то мелочевки
постоянно
подправлять конфиги syslog и logrotate надоело. С другой стороны, часть
мелочевки
тоже может выдавать серьезный трафик, так что приходится и о буферизации записи
подумать.

Ты спрашивал, чего б сислогу не ротировать заодно, раз уж уже пишет
файлы. Я объяснил.

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 17:14:43 San_Sanych wrote:
  Собственно, накопилось много всего, запускаемого из inittab и init.d, 
  собрался
  это задокументировать. Но скрипты inet.d монстрообразные и содержат
  бесполезные прослойки (через ps удобнее смотреть, с какими параметрами 
  сервис запущен, нежели разбираться в таких скриптах, лазить в defaults 
  проч.).
  Пришел к выводу, что лучше для пользовательских сервисов сменить систему 
  запуска на нечто более простое и функциональное, нежели дальше с этим жить.
 

 после таких слов возможно создание очередного форка дистрибутива :)

Речь идет не о системных сервисах, а пользовательских. Вот хочется удобства и 
автоматизации, хотя и так все работает - но требует некоторых манипуляций,
на мой взгляд, излишних. Пока не документировал, особо не задумывался, а тут 
вдруг в глаза бросилось, что не мешало бы упростить. Перевожу на runit, многое
стало проще и удобнее, осталось с логированиемм разобраться, когда какой 
вариант оптимальнее. Хотя, опять же, rsyslog для большого потока сообщений
и файлы для прочих логов в принципе вопрос решают (при условии, что ротация
не нужна или хватает возможностей svlogd и multilog).

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 17:30:10 Alexander Galanin wrote:
On Fri, 28 Aug 2009 17:20:01 +0400
Alexey Pechnikov pechni...@mobigroup.ru wrote:

А несмотря на все
утверждения о возможностях сислога, никто не предложил приемлемой
конфигурации для этой же задачи.

Потому что задача у тебя поставлена непонятно, а все условия для неё
являются результатом крайне странных решений при дизайне.

Не вижу ничего странного - нужно настроить сервер так, чтобы для разработки
и управления текущими сервисами не нужны были права рута (т.е. упразднить
использование sudo), и при этом разработчики, не имеющие понятия о сислоге,
логротэйте и проч. могли комфортно работать. Во избежание флейма позвольте
напомнить, что работа человеческого мозга до сих пор не изучена, но это не
мешает нам им пользоваться; с компьютерами хотелось бы аналогичного.

Кстати, а на кой тебе при отладке запускать что-то от www-data, а не от
себя?

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

Это наталкивает на мысль, что эти скрипты написаны криво.

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

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

Вызов грепа с нужными регекспами можно занести в скрипт. А скрипты
описать в README.

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Stanislav Maslovski - debian-russian@lists.debian.org @ Fri, 28 Aug 2009
17:56:41 +0400:

На http://www.tcl.tk я его и сам нашел. Но у нас тут debian'овская
рассылка...

SM Да ну? Вспоминая периодические отсылки к шеллу соляриса... ;-)

Это разница между совместимостью и несовместимостью.

SM А по-моему в данном случае лишь разница между тем, кто прибег к такому
SM аргументу: Artem Chuprina or not Artem Chuprina ;-)

SM Если опираться на логику не включаем в дистрибутив фич, которые не
SM поддерживаются/могут не заработать на других системах выкинуть
SM придется гораздо больше, чем тот tcl пакет, который ты не нашел в
SM дистрибутиве и теперь пытаешься подвести под этот факт некую
SM логическую базу (если я правильно понял твой последний комментарий).

Ты неправильно понял мой последний комментарий. И предпоследний тоже.

--
kernel bug (англ.) - ядрёна вошь

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 18:25:02 Alexander Galanin wrote:
Для этого достаточно написать приложение, которое отлаживается не через
неприличное место. Остальное само собой приложится.
Да, я считаю, что проблемы, которые ты пытаешься решать, ты создал сам.

Пожалуй. И все же полагаю, что отказ от использования sudo для разработчиков
стоит того, чтобы повозиться. Если работать через sudo, то и логи можно из
/var/log/ читать , и сервисы в init.d запускать - но это большой костыль.

Вот это и криво. Место им в /usr/lib.

Попробуйте работать не от рута. А также настроить неадминистрируемый
сервер, на котором, в случае сбоя системного диска, хостер может этот самый
диск выкинуть, залить на любой винт образ системного диска месячной давности,
причем после запуска сервера автоматически поднимутся все сервисы с рабочего
диска. Как понимаете, конфигурация /usr, /var и проч. должна быть практически
статичной.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 19:24:59 Alexander Galanin wrote:
 Ты меня не понял. То, что тебе приходится возиться с sudo и запускать от
 www-data --- тоже проблема, созданная тобой.

И в самом деле не понял. Вы предлагаете запускать веб-сервер с правами
пользователя, имеющего ssh доступ, неурезанный шелл и проч.? Я-то
говорил о запуске от имени пользователя и переключением на www-data,
вместо запуска пользователем через sudo и сменой юзера/группы на www-data.
Соответственно, домашняя директория www-data урезана в правах только 
на чтение. Делать запуск от имени пользователя  - потенциальная дыра,
а т.к. пользователь имеет право записи в свою домашнюю директорию, то 
принципиально возможно туда нечто закачать через веб-сервер и запустить
(какой-нибудь макрос для ООО, который имхо далеко не доверенное 
приложение).

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 20:04:36 Alexander Galanin wrote:
Каша какая-то. Ты не различаешь разработку и эксплуатацию?

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

Не надо смешивать - хотя разработчик имеет полный доступ к исходникам,
но это не отменяет защиты учетной записи разработчика от взлома! Зачем
создавать ситуацию, когда учетка разработчика может быть взломана
через веб-сервер, опеноффис и проч. ПО? Пусть потенциально опасные
приложения работают от ограниченной учетки, а не от реального
пользователя. Положим, насчет безопасности веб-сервера я более-менее
уверен, а вот за ООО гроша ломаного не дам. Есть и другое внешнее ПО,
которому я предпочитаю априори не доверять.

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

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Alexander Galanin - debian-russian@lists.debian.org  @ Fri, 28 Aug 2009 
20:04:36 +0400:

 AG Соответственно, при разработке программист имеет полный доступ ко
 AG всему коду проекта и запускает его как хочет. О какой защите
 AG веб-сервера можно говорить, если тот, от кого ты взялся его
 AG защищать, имеет полный доступ к исходникам?

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

... тут-то и выясняется, что то, что у разработчика в его разработочной
среде работало, в эксплуатационной работать не хочет...

-- 
Машины пока еще от копирования защищены хитрой немецкой технологией сборка
трезвымAlex Korchmar в bjndsl$1p2...@ddt.demos.su


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 23:22:16 Artem Chuprina wrote:
  AG Во время эксплуатации же действительно надо запускать от
  AG ограниченной учётной записи, с перекрытым доступом на запись и т.д.
 
 ... тут-то и выясняется, что то, что у разработчика в его разработочной
 среде работало, в эксплуатационной работать не хочет...

И админ легкой рукой дает полный доступ на чтение/запись, поскольку 
именно его пинают за то, что не работает - вон, мол, на тестовом-то работает,
значит, разработчики дело сделали. А переписывать под ограниченную 
конфигурацию и тестировать на месяц затянется, сорвет все планы и сроки 
и вообще никому нафиг не надо.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 23:54:54 Alexander Galanin wrote:
Опять паранойя непонятной природы. Ты что, голым девелоперским сервером
в интернет светишь? Или сотрудникам не доверяешь?

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

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

В итоге шаг влево от номинальной конфигурации и всё падает. Потому что в
каком-нибудь занюханном конфиге кто-то поставил таб вместо пробела
(реальный случай).

А у нас разработчики в конфиги не лазят, что я вам давно уже пытаюсь втолковать.
Теперь вот хочу настроить так, чтобы и админу в конфиги не надо было лазить ;-)

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

Hello!

On Friday 28 August 2009 23:44:32 Alexander Galanin wrote:
  ... тут-то и выясняется, что то, что у разработчика в его разработочной
  среде работало, в эксплуатационной работать не хочет...
 
 Выясняется оно когда продукт доходит до тестеров, а не в боевой
 обстановке. Так что ничем это не хуже и не лучше других багов, которые в
 избытке обитают в коде.
 
 Причём я затрудняюсь ответить, однозначно ли хороша ситуация с
 разработкой исключительно в номинальной среде.
 
Лучшие тестеры - сами пользователи. Дайте им доступ к разрабатываемой версии
и узнаете много нового о том, что же им на самом деле надо, что избавит от 
лишней работы и переделок, а также увидите возможные проблемы 
производительности и такие баги, которые при тестирование несколькими
сотрудниками никогда не найти (например, при сотне одновременных 
пользователей могут вылезти затыки по какому-нибудь сценарию работы,
причем такому, тест для которого никому не придет в голову реализовать).
В случае с веб-сервисом есть возможность в реальном времени получать
информацию о работе пользователей и трассировать все подозрительные
моменты, так что странно было бы игнорировать такую возможность.

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

2009-08-27 Пенетрантность Alexey Pechnikov

Alexey Pechnikov - debian-russian@lists.debian.org  @ Sat, 29 Aug 2009 
00:25:38 +0400:

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

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

-- 
An ideal world is left as an exercise to the reader.
Paul Graham, On Lisp


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Правильные демоны - не демоны?

Hello!

Имеем inittab для не-демонов, /etc/init.d/ для демонов всех сортов и inetd.conf
для сетевых не-демонов - целый зоопарк. Вопрос: зачем нужен режим демонизации 
в сервисах, если их прекрасно можно и без этого запустить? Далее, зачем нужна 
встроенная работа с syslog, когда можно передавать в лог stdout  stderr через 
пайп (связку программы с логирующей утилитой могут обеспечить runit, 
daemontools, etc., если не хочется вручную перенапрявлять вывод). 

Изучая документацию на runit, вижу простую и компактную реализацию работы 
init с не-демонизированными программами - может, это и есть true way? 

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

2009-08-27 Пенетрантность Alexey Pechnikov

Hello!

On Thursday 27 August 2009 23:48:30 Иван Лох wrote:
On Thu, Aug 27, 2009 at 11:06:36PM +0400, Alexey Pechnikov wrote:
Hello!

Имеем inittab для не-демонов, /etc/init.d/ для демонов всех сортов и
inetd.conf
для сетевых не-демонов - целый зоопарк. Вопрос: зачем нужен режим
демонизации
в сервисах, если их прекрасно можно и без этого запустить?

Чтобы их быстро и дешево форкать...

А смысл? Как пример, реверс-прокси pound с его форканьем на несколько порядков
по
производительности уступает единственному экземпляру haproxy. Ну, про апач
даже не будем вспоминать, в такое лучше не вляпываться. То есть технически да,
форкать демона - дешевле, но нужно ли это делать, еще вопрос, ответ на который
всегда или почти всегда будет отрицательный.

Далее, зачем нужна встроенная работа с syslog, когда можно передавать в лог
stdout stderr через пайп (связку программы с логирующей утилитой могут
обеспечить runit, daemontools, etc., если не хочется вручную перенапрявлять
вывод).

Куда именно перенаправить? syslog умеет очень быстро фильтровать и сортировать
сообщения, отправляя их куда надо и как надо. Не обязательно в файл.

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

Best regards, Alexey Pechnikov.
http://pechnikov.tel/

Re: Правильные демоны - не демоны?

2009-08-27 Пенетрантность Roman S. Gushcha

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 27 Aug 2009
23:06:36 +0400:

AP Имеем inittab для не-демонов, /etc/init.d/ для демонов всех сортов
AP и inetd.conf для сетевых не-демонов - целый зоопарк. Вопрос: зачем
AP нужен режим демонизации в сервисах, если их прекрасно можно и без
AP этого запустить?

Чтобы можно было, запустив их, отлогиниться. inittab эту проблему не
решает.

AP Далее, зачем нужна встроенная работа с syslog, когда можно
AP передавать в лог stdout stderr через пайп (связку программы с
AP логирующей утилитой могут обеспечить runit, daemontools, etc., если
AP не хочется вручную перенапрявлять вывод).

Между syslog и printf есть две разницы. Одну ты можешь увидеть, сравнив
их сигнатуры. Она небольшая, но довольно важная.

Вторая интереснее. syslog умеет работать по UDP. По пакетному
протоколу без памяти, сиречь. При сетевом логгинге это _весьма_
существенно. А пайп - протокол потоковый. Слить несколько сообщений в
один поток - не проблема. Проблема - разлить их перенаправлялкой
обратно.

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

AP Изучая документацию на runit, вижу простую и компактную реализацию
AP работы init с не-демонизированными программами - может, это и есть
AP true way?

Может, и есть. Подождем, может, история рассудит? runit'у тому, как ты
понимаешь, по сравнению с inittab и даже с SysV init scripts без году
неделя.

У нас вон до сих пор настройка сети идет через кривые врапперы ifconfig и
route. При том, что они действительно кривые (в смысле плохо
соответствуют представлениям ядра о сети), в отличие от инит-скриптов.
Начинать борьбу за светлое будущее явно лучше отсюда :-)

--
Современной называется технология, которую пытаются совать во все дырки
независимо от того, заточена она под них или нет.
Д. Белявский

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

2009-08-27 Пенетрантность Денис

On Fri, 28 Aug 2009 01:10:02 +0400
Artem Chuprina r...@ran.pp.ru wrote:

Alexey Pechnikov - debian-russian@lists.debian.org @ Thu, 27 Aug
2009 23:06:36 +0400:

AP Имеем inittab для не-демонов, /etc/init.d/ для демонов всех
AP сортов и inetd.conf для сетевых не-демонов - целый зоопарк.
AP Вопрос: зачем нужен режим демонизации в сервисах, если их
AP прекрасно можно и без этого запустить?

Чтобы можно было, запустив их, отлогиниться. inittab эту проблему не
решает.

AP Далее, зачем нужна встроенная работа с syslog, когда можно
AP передавать в лог stdout stderr через пайп (связку программы с
AP логирующей утилитой могут обеспечить runit, daemontools, etc.,
AP если не хочется вручную перенапрявлять вывод).

Между syslog и printf есть две разницы. Одну ты можешь увидеть,
сравнив их сигнатуры. Она небольшая, но довольно важная.

Вторая интереснее. syslog умеет работать по UDP. По пакетному
протоколу без памяти, сиречь.

Ничего хорошего в этом нет:
http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

On Thu, Aug 27, 2009 at 11:06:36PM +0400, Alexey Pechnikov wrote:
 Имеем inittab для не-демонов, /etc/init.d/ для демонов всех сортов и 
 inetd.conf
 для сетевых не-демонов - целый зоопарк. Вопрос: зачем нужен режим демонизации 
 в сервисах, если их прекрасно можно и без этого запустить? Далее, зачем нужна 
 встроенная работа с syslog, когда можно передавать в лог stdout  stderr 
 через 
 пайп (связку программы с логирующей утилитой могут обеспечить runit, 
 daemontools, etc., если не хочется вручную перенапрявлять вывод). 

Ты все в кучу свалил. init.d и inittab вообще не решают задачу демонизации.
В обсуждаемом контексте (запуск и управление сервисами) они могут
работать только с процессами, которые _сами_по_себе_ запускаются как
демоны, т.е. без управляющего терминала. Задачи у этих двух систем
разные:

1. inittab обеспечивает постоянную работу демона перезапуская в случае
падения,

2.init.d (sysv-скрипты, хотя в общем и bsd-скрипты) -- это обертка для
того чтобы:
а) иметь общий интерфейс для управления разными демонами
(/etc/init.d/service start|stop|restart|status). В дебе до логического
завершения эту идею пытаются довести разрабатывая слой policy-rc.d, но,
имхо, получается что-то унылое и некрасивое.
б) задать порядок запуска скриптов при инициализации и реализовать
уровни запуска.

runit (и daemontools) решает все эти задачи:

1. обеспечивает общий интерфейс управления службами. не хуже чем init.d
и всяко уж повеселее чем policy-layer, start-stop-daemons etc. (скрипты
запуска куда проще получаются);
2. определяет порядок запуска скриптов. тоже не хуже. изначально
параллельный запуск, простой учет завимостей, порядок запуска не
определяется номерами ссылок, а только зависимости, что, в-общем-то,
true.
3. обеспечивает постоянную работу служб, перезапуская их в случае
падения (чего никак не могут делать скрипты в init.d) без потери
возмоности просто их останавливать (с чем проблемы у inittab).

а также:

4. позволяет демонизировать процессы, которые без управляющего терминала
работать не могут (правда, есть проблемы с запуском процессов, которые
только демонами и могут запускаться :-) )
5. позволяет просто демонизировать пользовательские процессы. тоже true.

runit достаточно хорош даже для того, чтобы быть в busybox (и он там
есть).

А вот inetd тут вроде вообще ни при чем. У него своя работа.
 
--- 
С уважением,
Роман Гуща


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

2009-08-27 Пенетрантность Sergey Korobitsin

Fri, Aug 28, 2009 at 01:10 +0400 Artem Chuprina воздействовал на энтропию:
 У нас вон до сих пор настройка сети идет через кривые врапперы ifconfig и
 route.  При том, что они действительно кривые (в смысле плохо
 соответствуют представлениям ядра о сети), в отличие от инит-скриптов.
 Начинать борьбу за светлое будущее явно лучше отсюда :-)

А на эту тему что, никаких подвижек нет? Дискуссии, я так понимаю,
проходят в d...@?

-- 
Best regards, Sergey Korobitsin
Arta Software, Astana, KZ
mailto:undertaker{at}arta.kz
xmpp:underta...@jabber.arta.kz

--
Re: Конкурс PWN2OWN: Linux выдерживает удар
 Только ноутбук Sony VAIO c Ubuntu Linux оказался неприступным перед атаками 
 хакеров на конкурсе PWN2OWN
На соне поди настройку сети поднять не сумели, а gdm такпросто не отдался.
--anonymous(linux.org.ru)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

2009-08-27 Пенетрантность Roman S. Gushcha

On Fri, Aug 28, 2009 at 01:10:02AM +0400, Artem Chuprina wrote:
Может, и есть. Подождем, может, история рассудит? runit'у тому, как ты
понимаешь, по сравнению с inittab и даже с SysV init scripts без году
неделя.

Талантам надо помогать, бездарности пробьються сами ;-)

Ну, iproute (я так понимаю, что в светлое будущее нам через него?) тоже
не сахарный. Думаю народ бы веселее им пользовался, если бы можно было
написать ip eth0 192.168.0.1/26 и т.д. А то как на циске сидишь. И вроде
утилиты продвинутые, а пользоваться неприятно и неудобно. имхо, конечно.

ip, tc, iptables туда же -- авторы что, людей не любят, раз делают
такие пользовательские интерфейсы в юниксе? Я понимаю что тулзы задачи
сложные решают, но интерфейс может быть и человеческим. Во FreeBSD вон
вполне приятный и функциональный ifconfig (вместо ifconfig, iwconfig,
vconfig и ip у нас). ipfw опять-же, pf, netstat там вполне ничего (это в
пример того, что программы для сложных задач могут иметь простой
и/(или хотя-бы) привычный интерфейс).

Это я не для того чтобы попинать линуксовые утилиты (в конце-концов, не
нравится -- пиши сам, понимаю). Это к тому, почему народ в светлое
будущее через iproute не ломится, а кривыми утилитами пользуется.

Хотя понятно, что вот мне нравится runit, кому-то iproute и т.д.,
а консерваторов в каждом случае большинство. Поэтому и имеем что имеем,
дистрибутив-то один на всех.

---
С уважением,
Роман Гуща

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Roman S. Gushcha - debian-russian@lists.debian.org  @ Fri, 28 Aug 2009 
09:36:46 +0700:

 RSG Ты все в кучу свалил. init.d и inittab вообще не решают задачу
 RSG демонизации.  В обсуждаемом контексте (запуск и управление
 RSG сервисами) они могут работать только с процессами, которые
 RSG _сами_по_себе_ запускаются как демоны, т.е. без управляющего
 RSG терминала.

С каких это пор getty может работать без управляющего терминала, если не
секрет?

-- 
Ходячая энциклопедия - это девушка, которая пытается многознанием
компенсировать отсутствие мыслительных навыков (С)энта


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Денис - debian-russian@lists.debian.org @ Fri, 28 Aug 2009 06:49:53 +0800:

Чтобы можно было, запустив их, отлогиниться. inittab эту проблему не
решает.

AP Далее, зачем нужна встроенная работа с syslog, когда можно
AP передавать в лог stdout stderr через пайп (связку программы с
AP логирующей утилитой могут обеспечить runit, daemontools, etc.,
AP если не хочется вручную перенапрявлять вывод).

Между syslog и printf есть две разницы. Одну ты можешь увидеть,
сравнив их сигнатуры. Она небольшая, но довольно важная.

Вторая интереснее. syslog умеет работать по UDP. По пакетному
протоколу без памяти, сиречь.

Д Ничего хорошего в этом нет:
Д http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html

Не ничего хорошего нет, а есть свои недостатки.

--
Win-юзеры - это типа Win-модемов и Win-принтеров: такие же юзеры, но попроще,
без мозгов и памяти на борту.
http://www.livejournal.com/~dottedmag/158509.html

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?

Feata`lion Nyere`` - debian-russian  @ Thu, 27 Aug 2009 23:21:19 +0300:

 FN форкаются обычно для того, чтобы сменить юзера, от которого запускается
 FN демон.

Это неверно.

-- 
Пользователь юникса перестаёт быть пользователем юникса если после его
пользования пользованный юникс перестаёт быть юниксом. (с)


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Правильные демоны - не демоны?