The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Релиз FreeBSD 10.4, opennews (?), 03-Окт-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


86. "Релиз FreeBSD 10.4"  +1 +/
Сообщение от Onanon (?), 04-Окт-17, 02:33 
> заведомо вредных *.d (как бы вот это выпилить хотя бы ненадолго?)

Почему "заведомо вредных"? Деплоить настройки syslogd/crond для независимых программ отдельными файлами всяко удобнее же?

Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз FreeBSD 10.4"  –2 +/
Сообщение от пох (?), 04-Окт-17, 09:15 
>> заведомо вредных *.d (как бы вот это выпилить хотя бы ненадолго?)
> Почему "заведомо вредных"? Деплоить настройки syslogd/crond для независимых программ
> отдельными файлами всяко удобнее же?

нет. Потому что это настройки одной программы - syslogd.
А вот возможность окинуть их взглядом и быстро заметить, где что-то не так - на этом кончилась.
Трудами неосиляторов sed, пришедших из линукса со своим кривым уставом.

Ответить | Правка | Наверх | Cообщить модератору

111. "Релиз FreeBSD 10.4"  +2 +/
Сообщение от Аноним (-), 04-Окт-17, 09:43 
>А вот возможность окинуть их взглядом и быстро заметить, где что-то не так - на этом кончилась.
>Трудами неосиляторов sed, пришедших из линукса со своим кривым уставом.

Осилятор выдумал себе проблему, забыв про concatenate. Или просто не знал про cat.

Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз FreeBSD 10.4"  +/
Сообщение от пох (?), 04-Окт-17, 09:56 
> Осилятор выдумал себе проблему, забыв про concatenate. Или просто не знал про
> cat.

я же говорю - понаехавшие из линукса и сами работать не умеют, и другим все портят.
cat они знают, надо же... (видимо, ЭТУ утилиту осилили, ага)

Ответить | Правка | Наверх | Cообщить модератору

115. "Релиз FreeBSD 10.4"  –1 +/
Сообщение от Аноним (-), 04-Окт-17, 10:09 
кудах, пок.
По существу есть возражения?
Ответить | Правка | Наверх | Cообщить модератору

189. "Релиз FreeBSD 10.4"  +2 +/
Сообщение от DeadLoco (ok), 04-Окт-17, 17:00 
> По существу есть возражения?

Это и есть "по существу".

Пока кpaснoглaзик "конфигурирует" сервисы, мышкуя по гую - это ему удобно. Но как только возникает необходимость сделать в конфиге нечто, не предусмотреное гуем - вот тут начинаются лютые проблемы. Кpaснoглaзик может и не догадывается, что за фронтендом гуя есть чисто текстовый бекенд. У него никогда не возникает потребностей вне гуя, потому что это за гранью его понимания. В таком случае конфиг, порубанный в мелкий винегрет и раскиданый по множеству каталогов, не есть проблема. Но когда нужно конфигурить нечто нетривиальное, непредусмотренное гуем, то монолитный конфиг, лежащий в /etc или /usr/local/etc - намного предпочтительнее.

Ответить | Правка | Наверх | Cообщить модератору

192. "Релиз FreeBSD 10.4"  –1 +/
Сообщение от пох (?), 04-Окт-17, 17:18 
> Пока кpaснoглaзик "конфигурирует" сервисы, мышкуя по гую - это ему удобно. Но

ему мой ник. Лишь бы мышка кликала.
Не мой ник - пейсателю того гуя, который сед ниасилил, умеет только файлики двигать.
Он такой еще много чего ниасилит, и то, что это неосиляторство потащили в BASE - это очень фиговый признак, какие именно программисты примазались к грантам freebsd foundation.

И это уже выливается не (только) в мелкие диверсии типа описанной, а в ту историю с zfs, которая уже два года разрешиться не может, и ни один, ни один, сцуко, грантопил в ней не поучаствовал - слишком заняты подсчетами, в какие акции вложить свои бабки, ну а на досуге - вот такую херню с .d/* вам запиливают, чтобы было что написать потом в release notes для отчетности спонсорам.

К сожалению, это означает что очень скоро, фактически уже сейчас, мы получим "конкурент линуксу", а не хорошую юникс-систему.

Ответить | Правка | Наверх | Cообщить модератору

193. "Релиз FreeBSD 10.4"  –1 +/
Сообщение от Аноним (-), 04-Окт-17, 17:22 
Тебя маны по cat послать читать? Или сам сообразишь как слить несколько текстовых файлов и почитать stdout?
Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

118. "Релиз FreeBSD 10.4"  +/
Сообщение от забыл_пароль_от_тигар (?), 04-Окт-17, 11:06 
>>> заведомо вредных *.d (как бы вот это выпилить хотя бы ненадолго?)
>> Почему "заведомо вредных"? Деплоить настройки syslogd/crond для независимых программ
>> отдельными файлами всяко удобнее же?
> нет. Потому что это настройки одной программы - syslogd.
> А вот возможность окинуть их взглядом и быстро заметить, где что-то не
> так - на этом кончилась.
> Трудами неосиляторов sed, пришедших из линукса со своим кривым уставом.

по этой же причине разные дубы лезут в /etc/crontab вместо юзерских кронтабов? ну, чтобы "окинуть их взглядом и быстро заметить" ?

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

139. "Релиз FreeBSD 10.4"  –4 +/
Сообщение от пох (?), 04-Окт-17, 12:54 
> по этой же причине разные дубы лезут в /etc/crontab вместо юзерских кронтабов?
> ну, чтобы "окинуть их взглядом и быстро заметить" ?

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

А теперь расскажи, почему у тебя лопается пукан от правок в /etc/crontab - тоже сед не умеешь, каждый раз мучаешься с ee? [вот тебя на моих-то системах облом так облом ждет]

Ответить | Правка | Наверх | Cообщить модератору

266. "Релиз FreeBSD 10.4"  +3 +/
Сообщение от Onanon (?), 05-Окт-17, 03:46 
> и чтобы меньше было шансов нечаянно просрать/поломать при переносе сервиса или апгрейде - потому что конфиги в /etc ты точно не забудешь, а вот "юзерские кронтабы" на машине где нет никаких настоящих юзеров на раз.
> Впрочем, некоторые и на машине с юзерами ухитряются - "ой, а у юзера есть еще что-то кроме хомяка, надо же?!"

facepalm.jpg
Но с оратором согласен, несмотря на "офигительную" аргументацию, использовать юзерские кронтабы для псевдопользователй - абсурд.

> А теперь расскажи, почему у тебя лопается пукан от правок в /etc/crontab - тоже сед не умеешь, каждый раз мучаешься с ee? [вот тебя на моих-то системах облом так облом ждет]

Я не Тигар, но можно я отвечу? У меня просто лопается пукан от правок /etc/crontab sed'ом, не могу молчать. И я сейчас не про "single file vs conf.d/".
1) ee - это типа как nano, да? Сорян, за всё время использования bsd запускал это ужос раза 2 примерно. А nano-юзерам я, будучи аутсорсером, прописывал в .bashrc что-то типа alias nano="rm -f". Если бы не WITHOUT_EE, я бы поступал с ним так же. vim - наше всё, vi тоже сойдёт, если почему-то порты/пакеты ставить нет возможности.
2) Что понимается под правкой crontab sed'ом? Почему именно им вообще? Это типа Ъ и по-какерски? А если я, например, python'ом или perl'ом, или awk'ом - это Ъ или нет?.. Отвлёкся, простите. Так что под этим понимается? Обновление конфигов в продакшене, на боевых серверах? Использование sed'а вместо интерактивного текстового редактора на локалхосте? Что?
3) Какой вообще критерий оценки трушности подхода?

> вот тебя на моих-то системах облом так облом ждет

А тебя на моих. Потому что через ~3-7min после того, как поправишь своим ненаглядным sed'ом crontab или что-то типа того, придёт salt и откатит всё исходному состоянию. Потому что нефиг руками редактировать конфигурацию боевых серверов.

Ответить | Правка | Наверх | Cообщить модератору

283. "Релиз FreeBSD 10.4"  +1 +/
Сообщение от пох (?), 05-Окт-17, 15:37 
> 1) ee - это типа как nano, да? Сорян, за всё время

да - в смысле, я нихрена не знаю, как из него выйти, не испортив файл (quit и exit, ага, найдите два отличия), если нечаянно запустилось.
Поэтому мои системы собраны WITHOUT_этанёх, что гарантирует массу лулзов, если забрел индивидуум, не умеющий выйти из vi.

> 2) Что понимается под правкой crontab sed'ом? Почему именно им вообще? Это

ну хочешь ты снабдить свою ценную программу автодобавлялкой чего-то в кронтаб и еще пару линейных конфигов, почему бы и нет?

> типа Ъ и по-какерски? А если я, например, python'ом или perl'ом,

если ты пользуешься фрей, то должен знать, почему нет. awk - пожалуйста, только надо все время помнить, что это не gnu awk, мне проще помнить что лучше им на фре не пользоваться вообще ;-)

> своим ненаглядным sed'ом crontab или что-то типа того, придёт salt и

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

> откатит всё исходному состоянию. Потому что нефиг руками редактировать конфигурацию
> боевых серверов.

не вижу проблемы. Если серверов тыща штук и отличаются они толко по uuid'ам-хрен-запомнишь, то, конечно, руками там делать нечего (а скриптами - берущимися из пакета - почему бы и нет, не вижу чем это хуже бранья из пакета мусора для добавления в .d)
Если сервер специфический, существует, в силу особенностей сервиса, в единственном экземпляре - не вижу необходимости в умножении сущностей и редактирования его конфигов через десять прослоек, не видя результата немедленно. Автоматизировать надо рутинную и отнимающую время работу, а не "чтоб было".

Ответить | Правка | Наверх | Cообщить модератору

291. "Релиз FreeBSD 10.4"  +2 +/
Сообщение от Onanon (?), 05-Окт-17, 17:40 
>> 2) Что понимается под правкой crontab sed'ом? Почему именно им вообще? Это
> ну хочешь ты снабдить свою ценную программу автодобавлялкой чего-то в кронтаб и еще пару линейных конфигов, почему бы и нет?

Ну вот и как ты потом поймёшь, какой пакет попатчил тебе crontab? Что будешь делать, если в crontab кто-то сходит, поправит твою строку и автоудалялка не удалит нужное при удалении пакета? Как защитишься от того, что другие пакеты тем же sed'ом не распотрошат твои настройки из-за ошибки или вредоносных намерений их авторов?
Что будет, если в sed прилетит -9 от системы во время автодобавления?
rename (2) или symlink (2) атомарны, например, в отличие от.

>> типа Ъ и по-какерски? А если я, например, python'ом или perl'ом,
> если ты пользуешься фрей, то должен знать, почему нет. awk - пожалуйста, только надо все время помнить, что это не gnu awk, мне проще помнить что лучше им на фре не пользоваться вообще ;-)

Аргумент про базовую систему принимается, ок. Мне правда религия позволяет ставить условный python на машины, если нужно (обычно да).
Почему bsd awk лучше не использовать? Я правда не знаю. Я знаю, что он отличается от gnu awk, но не настолько владею обоими, чтобы знать, чем бсдшный фундаментально хуже.
Bsd sed, кстати, от гнутого тоже отличается. Поэтому за то время, что я админил и linux и freebsd в один период времени и в примерно равной пропорции, я приучил себя использовать однострочники на perl для замены ~80% кейсов, когда я использовал sed. Да, perl у нас был установлен везде. Да и сейчас кстати, но это уже не про freebsd, к сожалению =(

>> своим ненаглядным sed'ом crontab или что-то типа того, придёт salt и
> и что ты делаешь с установкой пакетов, которые приносят свои конфиги? Особенно в тех случаях, когда они тривиальны, и трогать там в общем-то ничего не надо.

Ничего не делаю, потому что у меня сейчас по работе linux в основном, причём, наиболее фекальный - ubuntu. Увы.
Salt защищает не все файлы, а лишь их часть, те, что новые приезжают в cron.d (обычно с пакетами) так и остаются.
Но я, кстати, считаю, что это в принципе плохая практика для серверов в большом кластере, как приносить с пакетом кронтабы так и патчить их чем либо.
Правильный способ - иметь свой планировщик и запускать его рядом с инстансом приложения или перенести логику в само приложение. А crond использовать для системных тасков и только.
В "волшебном linux-мире" этот подход вылился в контейнеры, жирные причём( Я не против контейнеров, но в данном случае это оверкилл.

>> откатит всё исходному состоянию. Потому что нефиг руками редактировать конфигурацию боевых серверов.
> не вижу проблемы. Если серверов тыща штук и отличаются они толко по uuid'ам-хрен-запомнишь, то, конечно, руками там делать нечего (а скриптами - берущимися из пакета - почему бы и нет, не вижу чем это хуже бранья из пакета мусора для добавления в .d)

Это хуже, но conf.d тоже плохо, да. Чем хуже - я уже много букв написал про то, почему я так считаю, в т.ч. в начале этого сообщения.

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

Согласен. У меня просто уникальных серверов уже очень давно нет, ибо требуют наличия реплик в количестве не менее 3х штук.

Ответить | Правка | Наверх | Cообщить модератору

295. "Релиз FreeBSD 10.4"  –2 +/
Сообщение от Anonymoustus (ok), 05-Окт-17, 18:40 
> alias nano="rm -f"

Жестоко.

Ответить | Правка | К родителю #266 | Наверх | Cообщить модератору

296. "Релиз FreeBSD 10.4"  +2 +/
Сообщение от Onanon (?), 05-Окт-17, 19:02 
>> alias nano="rm -f"
> Жестоко.

Справедливо.

Ответить | Правка | Наверх | Cообщить модератору

142. "Релиз FreeBSD 10.4"  +1 +/
Сообщение от Onanon (?), 04-Окт-17, 13:04 
>>> заведомо вредных *.d (как бы вот это выпилить хотя бы ненадолго?)
>> Почему "заведомо вредных"? Деплоить настройки syslogd/crond для независимых программ
>> отдельными файлами всяко удобнее же?
> нет. Потому что это настройки одной программы - syslogd.

Ну как же нет, когда да. Вот я хочу вместе со своей программой приносить на машину отдельные настройки crond или syslog.
Что проще - патчить единственный файл или подложить ещё один файл в директорию?

А если чьё-то ПО уже поставляется с какими-то настройками syslogd/crond, а я хочу деплоить ещё какие-то свои дополнительные (актуально скорее для cron), то вариант с единственным файлом совсем уж неадекватен по сравнению с *.d-вариантом.

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

Условный "cat /usr/local/etc/cron.d/* | less" не поможет?

Ну и, как по мне, аргумент странный. А если в конфиге 70+ строчек - это тоже что ли удобнее читать в единственном файле?
В случае с раздельными файлами, можно будет разделить настройки по какому-то признаку и разложить в разные файлы, и потом удобно смотреть их независимо. Это гораздо лучше читается и нагляднее, чем большая простыня.

И да, crontab на 70+ строк я видел вживую и не раз. Как раз таки на фряхе. Т.е. я сейчас не о сферическом коне в вакууме.

> Трудами неосиляторов sed, пришедших из линукса со своим кривым уставом.

При чём тут sed? Причём тут linux и "его кривой устав"? Я использую и freebsd и linux, и админить приходилось обе ОС, при всей моей любви к фряхе, отсутствие *.d - недостаток.
Возможность инклудить конфиги и "*.d" вместо одного файла - это также логично и правильно, как существование /usr/local/ или rc.conf.local в той же bsd.

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

147. "Релиз FreeBSD 10.4"  –5 +/
Сообщение от пох (?), 04-Окт-17, 13:31 
> Ну как же нет, когда да. Вот я хочу вместе со своей
> программой приносить на машину отдельные настройки crond или syslog.
> Что проще - патчить единственный файл или подложить ещё один файл в

_тебе_ конечно проще. А мне потом этот зоопарк тамагочей кормить - нифига не проще, потому что я держу там не твою программу, а систему.  И вот это программистам, похоже, никак не понять.

> Условный "cat /usr/local/etc/cron.d/* | less" не поможет?

нет, не поможет, особенно если уже понадобилось ТАК в этом разбираться.

> Ну и, как по мне, аргумент странный. А если в конфиге 70+
> строчек - это тоже что ли удобнее читать в единственном файле?

не знаю. смотря что за строчки, если это реальные 70+ независимых задач, зачем-то понадобившиеся на одной системе (я бы подумал как ее попилить на независимые виртуалки), то да, удобнее, ты хотя бы будешь в одном месте видеть, что за чем выполняется (и не запустишь два тяжелых процесса одновременно).
Чаще всего это все же означает, что  надо было написать скрипты, выполняющие это все в правильном порядке, а в кроне оставить десяток вызовов этих скриптов, или вообще предоставить этим заниматься periodic (не забыв что у него есть _настройки_, или во всяком случае, были задуманы когда-то, чтобы ни при каких обстоятельствах не лазить в сами скрипты)

> И да, crontab на 70+ строк я видел вживую и не раз. Как раз таки на фряхе.

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

> При чём тут sed? Причём тут linux и "его кривой устав"? Я

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

А .d/* вместо явных include (которые как раз полезны) - это диверсия, она тебе еще выйдет боком, и не раз.

Ответить | Правка | Наверх | Cообщить модератору

195. "Релиз FreeBSD 10.4"  +2 +/
Сообщение от Onanon (?), 04-Окт-17, 17:23 
>> Ну как же нет, когда да. Вот я хочу вместе со своей
>> программой приносить на машину отдельные настройки crond или syslog.
>> Что проще - патчить единственный файл или подложить ещё один файл в
> _тебе_ конечно проще. А мне потом этот зоопарк тамагочей кормить - нифига
> не проще, потому что я держу там не твою программу, а
> систему.  И вот это программистам, похоже, никак не понять.

В смысле _мне_ проще? Объясни в чём разница между мной и тобой.
И при чём тут программисты?

>> Условный "cat /usr/local/etc/cron.d/* | less" не поможет?
> нет, не поможет, особенно если уже понадобилось ТАК в этом разбираться.

Не буду спорить, обычно по имени файла понятно, куда смотреть, делать cat * | less для поиска чего-то в конфигах мне не приходилось.
Ну это как, я не знаю, вот в /etc/ лежат разные файлы с разными названиями, и по их названиям понятно, что за что отвечает. Было бы это в одном файле - была бы помойка.
Тут точно также, кмк.

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

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

> Чаще всего это все же означает, что  надо было написать скрипты,
> выполняющие это все в правильном порядке, а в кроне оставить десяток
> вызовов этих скриптов, или вообще предоставить этим заниматься periodic (не забыв
> что у него есть _настройки_, или во всяком случае, были задуманы
> когда-то, чтобы ни при каких обстоятельствах не лазить в сами скрипты)

Есть кластер, чуть больше 1000 машин. Есть задача деплоить на него ПО, написанное разными (в общем случае) командами программистов. Некоторые программы таскают с собой cron-таски, некоторые по cron'у запускаются на каком-то срезе хостов, некоторые не чистят за собой временные данные и приходится лепить костыли в cron'е и т.п. - мрак, в общем.
Утверждается, что принудить всех "делать правильно" и не таскать с собой всякое г вот прям сразу невозможно. Т.е. все к этому идут, но бардак уже исторически сложился и надо с ним как-то жить.
И удобнее жить с возможностью раскладывать костыли в разные места, а не перезаписывать файл, в надежде, что его не потрогали ничьи шаловливые ручки или ещё какая оказия не приключилась.

>> И да, crontab на 70+ строк я видел вживую и не раз. Как раз таки на фряхе.
> я их на всем видел, и иногда даже не в силу коекакерства
> сделанных, но это были очень старые системы, до эпохи доступной виртуализации,
> и в них, действительно, было напихано прорву вещей, "процессор же потянет,
> если не в пиковые часы?"(вот оно и лопнет часа в четыре
> утра, вот щастье-то) которые сейчас никто в одну банку не пихает.

На линуксе я не видел исключительно потому, что простыни были разложены по файлам в *.d. Ну и контейнеры, да.
Повторюсь: я не считаю, что 70+ строк в кронтабе - это хорошо. Но иногда это реалии, с которыми приходится жить.
Коекакерство - да. Старые инсталляции - да.
Как я считаю, если есть инструмент, с которым удобнее упорядочивать бардак, не имя возможности радикально искоренить его, то это плюс, а не минус. В конце концов, ничего не мешает фигачить всё одним файлом, если твои задачи это решает.

>> При чём тут sed? Причём тут linux и "его кривой устав"? Я
> потому что они на самом деле разучились - для них реально невыполнимая
> задача добавить строку в неструктурированный построчный конфиг (а потом еще ее
> и найти там, если понадобилось удалить или поменять).
> В основном эта публика тусуется в линуксных системах (потому что ничего другого
> не умеет и не хочет), но иногда прорывается на новые горизонты.

Просто при обновлении существующего файла может больше всего пойти не так, как хотелось, чем при подкладывании дополнительного, линукс тут ни при чём.
И чем больше у тебя парк машин, тем сильнее это ощущается. Как по мне, плохо и приносить 100500 файлов в *.d и деплоить один огромный конфиг, такие задачи должны решаться каким-нибудь etcd/zookeeper или чем-то типа salt/puppet.
Но приходится работать с тем, что имеем, мир не идеален.

> А .d/* вместо явных include (которые как раз полезны) - это диверсия,
> она тебе еще выйдет боком, и не раз.

Да почему же? Это же не принудиловка: не нравится, не клади ничего в .d/*. Это возможность, а использовать её или нет - нужно решать исходя из задач. И хорошо, что теперь есть больше вариантов для выбора. Я рассуждаю так.

Ответить | Правка | Наверх | Cообщить модератору

198. "Релиз FreeBSD 10.4"  –5 +/
Сообщение от пох (?), 04-Окт-17, 18:20 
> В смысле _мне_ проще? Объясни в чём разница между мной и тобой.

потому что у тебя - "своя программа". А у меня - "cвоя система", единое целое, а программы в ней бывают в количестве энцать штук.

> Не буду спорить, обычно по имени файла понятно, куда смотреть

ты точно-точно админ?

что тебе по имени файла будет понятно, когда по данным мониторинга в системе охрененная нагрузка  с 3:25 по 4:30 с перерывами на полежать?
В какой, мля, файл из тыщи смотреть и что в нем искать? С какого прохода ты наконец заметишь нужную строчку в миллионе мусора? Уверен ли ты, что нашел нужную, а не похожую, потому что забыл еще один стопятый вариант того, откуда, БЕЗ явного указания этого в конфигах, шибкоумно хакнутый крон берет себе задания?

> Не буду спорить, обычно по имени файла понятно, куда смотреть

по имени файла сrontab, понятно, что туда надо смотреть, когда речь о периодических задачах.

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

> Повторюсь: я не считаю, что 70+ строк в кронтабе - это хорошо.

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

> Просто при обновлении существующего файла может больше всего пойти не так, как
> хотелось, чем при подкладывании дополнительного

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

> Это же не принудиловка

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

С единственным аргументом "хотим как в линукс". Вот уж что-что, а еще один линукс мне нафиг не сдался.

Ответить | Правка | Наверх | Cообщить модератору

237. "Релиз FreeBSD 10.4"  +3 +/
Сообщение от Onanon (?), 04-Окт-17, 21:00 
>> В смысле _мне_ проще? Объясни в чём разница между мной и тобой.
> потому что у тебя - "своя программа". А у меня - "cвоя
> система", единое целое, а программы в ней бывают в количестве энцать
> штук.

Я ничего не понял. Причём тут "моя программа - твоя система"? Как нарушается целостность системы от того, что я могу складывать конфиги для crond/syslogd/something в отдельные директории?
Или ты про то, что устанавливаемое ПО не должно менять персистентную систему, иначе кластер превратится в зоопарк со временем? Ну так с этой позиции нововведение лишь пользу приносит - я могу монтировать /etc, или вообще корень + /usr (не /usr/local/ !) в ro и все сторонние конфиги складывать в /usr/local/etc/*.d/. Кажется, это куда надёжнее, чем перезаписывать единственный файл?

>> Не буду спорить, обычно по имени файла понятно, куда смотреть
> ты точно-точно админ?

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

> что тебе по имени файла будет понятно, когда по данным мониторинга в
> системе охрененная нагрузка  с 3:25 по 4:30 с перерывами на
> полежать?

Что мне будет понятно из /etc/crontab, когда по данным мониторинга в системе охрененная нагрузка  с 3:25 по 4:30 с перерывами на полежать?
Кажется, вопрос учёта и ограничения ресурсов несколько выходит за рамки обсуждаемого?
Можно настроить логин-классы, аккаунтинг, мониторинг и пр. - это про поиск злодея, сожравшего все ресурсы на хосте.
При чём тут способ доставки конфигов на кластер?

> В какой, мля, файл из тыщи смотреть и что в нем искать?
> С какого прохода ты наконец заметишь нужную строчку в миллионе мусора?
> Уверен ли ты, что нашел нужную, а не похожую, потому что
> забыл еще один стопятый вариант того, откуда, БЕЗ явного указания этого
> в конфигах, шибкоумно хакнутый крон берет себе задания?

Никогда не искал в кронтабе программу, которая ушатала машину, честно. Это даже звучит как абсурд =).
Имя программы/пользователя обычно не сложно найти более прямыми способами, далее найти файл, из которого запустился cron-таск - это секунды грепанья.

>> Не буду спорить, обычно по имени файла понятно, куда смотреть
> по имени файла сrontab, понятно, что туда надо смотреть, когда речь о
> периодических задачах.

По имени файла, содержащего "(cron|syslog|something).d/" всё также понятно. И?

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

Т.е. вместо того, чтобы принести +N файлов ты предлагаешь принести +N файлов и в довесок добавить +N инклюдов в основной конфиг?
И считаешь это улучшением? В чём тогда оно? Тогда уж проще в самом деле один файл таскать, ей богу.

>> Повторюсь: я не считаю, что 70+ строк в кронтабе - это хорошо.
> это приемлемо, и совершенно не является проблемой для прочитать и разобраться -
> если ты все же админ.

Админ, админ. И именно поэтому я хочу не читать простыни по 70+ строк, а автоматизировать процессы так, чтобы мне не нужно было этого делать. Я хочу, чтобы ОС работала на меня, а не я на неё. И, кмк, в этом вообще смысл вычислительной техники.
Ревьюить простыню, которая изменяется иногда по N раз в день или дать возможность запускать своё Г без вмешательства администратора...
Даже не знаю, что выбрать =) *ИРОНИЯ*

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

Учёт ресурсов, для тасков, запущеных в cgroups+namespaces/jail (да, я знаю, что их возможности не всецело эквивалентны), проще же.
Какие нужны приседания? Окей, линуксовый зоопарк/изобилие решений действительно может заставить тупить и путаться по первым порам, но в bsd, где jail'ы и только - какие там проблемы с этим?
Но это, опять же, не про доставку конфигов на машину и их хранение на диске, правда?

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

1) С каких пор править конфиги sed'ом в продакшене - это хорошая идея? Если уж мы говорим про один файл, то правильный подход - поправить (хоть бы и sed'ом, ага) его в безопасном месте (один раз), проверить, раскатить на кластер, поэтапно.
2) С каких пор правка конфига sed'ом атомарна? А если на 1 из 1000 машин в тот момент, когда твоя автоматика запустит sed кончится память посреди процесса и процесс sed'а будет принудительно завершён?
3) А если на куске кластера crontab отличается, или его даже потрогали чьи-то шаловливые ручки, у которых есть root, и теперь регулярка не работает?
Можно ещё придумать много аналогичных по смыслу примеров.
А можно даже не пытаться решить искусственно созданные проблемы и позволить приносить конфиги в /usr/local/etc/cron.d/ и не париться. Принёс некорректный файл? Отлично, ССЗБ. Твои таски не запустятся, у всех остальных работают как и ранее.
Не успех ли это?

>> Это же не принудиловка
> это принудиловка - я не могу это выключить и быть уверен, что
> коекакерский скрипт не нагадит в каталог хз где, который я забуду
> проверить.
> Более того, очевидно что это не было бы сделано в релизе с
> номером, предполагающим только критические исправления, если бы толпы коекакеров не занесли
> уже руку над комитом подобных скриптов.

Не давай права на запись в /usr/local/etc/cron.d/ пользователям, из под которых будет организована доставка файлов в эту директорию?
Кошмар, принудиловка уровня "bind в базовой системе, я принуждён использовать bind!11".
Откуда растёт противоестественное желание глазами валидировать все конфиги мне также не понятно. Эдак можно целый день только конфиги читать.
Не, если у тебя небольшой кластер, мало cron-тасков и редактируешь crontab только ты и не очень часто, то один файл - это самое то, да.
При несоблюдении хотя бы одного условия это мазохизм, извините.

> С единственным аргументом "хотим как в линукс". Вот уж что-что, а еще
> один линукс мне нафиг не сдался.

Истерика на пустом месте. Хотим не как в линукс, а как удобнее/практичнее. А то, что в линуксе также - не повод отказываться от решения.
И уж точно это изменение (минорное, к слову), не сделает freebsd "опасно похожей на linux". Бред.

PS: Таскать вагон настроек для cron/syslog/etc, которые нужны каким-то сторонним боевым программам в любом случае ЗЛО и так делать не надо, не важно, сколько файлов и где их по дефолту ищут системные сервисы. Я лишь попытался сравнить подходы, помня, что они оба плохие, исходя из имеющегося опыта.

Ответить | Правка | Наверх | Cообщить модератору

297. "Релиз FreeBSD 10.4"  –1 +/
Сообщение от Anonymoustus (ok), 05-Окт-17, 19:14 
> И при чём тут программисты?

Не ко мне был этот вопрос, но есть два-три слова по теме. Программисты конкретно при том, что подчас они делают проще жизнь самим себе, а не остальным людям (юзерам ли, админам ли, отделам продаж ли и пр.). Системду, например, придумали программисты для упрощения себе написания какого-то околосистемного софта и избавления себя же от зависимости от специфики разных дистрибутивов. Вот эти самые поттеринги-сиверсы и подобные им недоумки постоянно при покровительстве RH внедряют какие-то дрянные поделки — в интересах, разумеется, кормящей компании. Ни одной, ни даже половиной мысли эти ребята о нас не думали. Вообще. Им на весь остальной мир тупо плевать, а их стиль работы уже в анекдотах. Они строят системду исключительно для того, чтобы их непыльная хипсторская работа стала для них еще легче. Причем это они делают с наглостью неповторимой. Ну а юзерам (собирательным «нам») приходится потом эту дрянь как-то использовать, утратив при этом контроль и понимание системы.

Ответить | Правка | К родителю #195 | Наверх | Cообщить модератору

310. "Релиз FreeBSD 10.4"  –1 +/
Сообщение от лютый жабист__ (?), 06-Окт-17, 16:03 
> Программисты конкретно при том, что подчас они делают проще жизнь самим
> себе, а не остальным людям (юзерам ли, админам ли, отделам продаж
> ли и пр.). Системду, например, придумали программисты

Открою тайну - линух это ОСь от программистов для программистов, только поэтому он и рулит.

Соответственно, к вам вопрос - а вы собсно хто? и какой у вас лично вклад в линух?

Ответить | Правка | Наверх | Cообщить модератору

311. "Релиз FreeBSD 10.4"  +2 +/
Сообщение от Анонимный Аналитек (?), 06-Окт-17, 16:21 
> Открою тайну - линух это ОСь от программистов для программистов,

Добавлю: на Си.
> Соответственно, к вам вопрос - а вы собсно хто? и какой у вас лично вклад в линух?

Поэтому тоже возникает вопрос - а каким боком тут жабисты?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру