В поставляемом в составе тестового выпуска Red Hat Enterprise Linux 6.7 скрипте инициализации прокси сервера Squid выявлена (https://bugzilla.redhat.com/show_bug.cgi?id=1202858) проблема, которая приводит к удалению всех файлов в системе при перезапуске squid. По своей сути ошибка напоминает недавний инцидент (https://www.opennet.ru/opennews/art.shtml?num=41469) с удалением всех файлов пользователя в клиенте Steam и также приводит к выполнению команды "rm -rf /*" в случае незаполнения формирующей путь переменной.Pavel Šimerda, мэйнтейнер пакета squid из компании Red Hat, смог повторить эксперимент в виртуальной машине с тестовой веткой RHEL 6.7 и установленным пакетом squid-3.1.23-4.el6. Достаточно запустить squid командой "service squid start", после чего инициировать его перезапуск командой "service squid restart", в результате чего начнётся удаления всех файлов на диске.
В пакете squid-3.1.23-5.el6 проблема отмечена как решённая и связанная с регрессивным изменением кода.
Судя по всему, проблема вызвана патчем на основе предложенного (https://bugzilla.redhat.com/show_bug.cgi?id=1102343) ранее кода для контроля за полным завершением ранее работающего экземпляра squid в процессе перезапуска. В предоставляемом разработчиками Squid скрипте инициализации squid.init (https://github.com/mozilla-services/squid-rpm/blob/master/SO...) операция "rm -rf $SQUID_PIDFILE_DIR/*" используется дважды - в блоках stop и restart, при этом в restart удаление выполняется сразу после выполнения блока stop:
<font color="#461b7e">
stop
rm -rf $SQUID_PIDFILE_DIR/*
start
</font>Т.е. при запуске "service squid restart" команда "rm -rf $SQUID_PIDFILE_DIR/*" запускается два раза. Переменная SQUID_PIDFILE_DIR определяется статически вначале файла и, кроме вышеотмеченных команд rm, в дальнейшем используется только в проверках. Подобная чистка содержимого директории $SQUID_PIDFILE_DIR убрана из скрипта инициализации RHEL из-за потенциальных проблем. Патч для решения проблемы (https://bugzilla.redhat.com/show_bug.cgi?id=1102343) с дублированием был подготовлен на основе оригинального скрипта инициализации squid и содержал типовую строку для чистки ("rm -rf $SQUID_PIDFILE_DIR/*"). С учётом отсутствия переменной SQUID_PIDFILE_DIR в варианте скрипта из состава RHEL 6, подобная чистка приводила выполнению команды "rm -rf /*".
URL: https://news.ycombinator.com/item?id=9254876
Новость: https://www.opennet.ru/opennews/art.shtml?num=41897
А вот был бы у него systemd...
> А вот был бы у него systemd...и RemoveAllFilesInDir= в настройках юнита...
> и RemoveAllFilesInDir= в настройках юнита...http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/...
> if (path_equal(path, "/")) {
> log_error("Attempted to remove entire root file system, and we can't allow that.");Вот гадский Поцтеринг, даже прострелить свою ногу не дает!
> Вот гадский Поцтеринг, даже прострелить свою ногу не дает!Это он просто кусок кода у GNU rm слямзил. man rm, малыш.
> Это он просто кусок кода у GNU rm слямзил. man rm, малыш.Тем не менее, в данном случае, в rm этот код оказался бесполезен, а в systemd - вполне себе годен.
>> Это он просто кусок кода у GNU rm слямзил. man rm, малыш.
> Тем не менее, в данном случае, в rm этот код оказался бесполезенВы идиот? Как может один и тот же кусок кода, использующийся
одинаково быть полезным и бесполезным?Объясняю, проблема не в
rm -rf /
а в
rm -rf /*Детишкам нужно объяснять разницу? И почему защиты от эквивалента второй
команды (т.е. rm -rf /bin /dev ... после pathname expansion) - в systemd, естественно, нет?> а в systemd - вполне себе годен.
Да нету в systemd вообще директивы RemoveAllFilesInDir, дурашка.
Вот как будет что-то подобное, да с поддержкой shell globbing - тогда и поговорим.
> Как может один и тот же кусок кодаНу, во-первых, не один и тот же.
> Детишкам нужно объяснять разницу?
Тут внизу есть один борцун с Поттерингом, вот ему это объясните :)
> Вот как будет что-то подобное,
RuntimeDirectory= уже сто лет в обед. И защита от дурака там еще более суровая.
> да с поддержкой shell globbing - тогда и поговорим.
А зачем там shell globbing? В директиве ini-файла указывается только имя самого каталога, безо всяких звездочек.
Конструкция $DIRNAME/* - это костыль, имманентно присущий shell-скриптам, но не специализированным директивам.
>> Как может один и тот же кусок кода
> Ну, во-первых, не один и тот же.Да, coreutils не писали обезъяны с избытком ЧСВ. В частности, это
означает что получившийся там код не Windows^WLinux-only.Ну а больше технических отличий - нет.
>> Детишкам нужно объяснять разницу?
> Тут внизу есть один борцун с Поттерингом, вот ему это объясните :)Т.е. вы понимаете, но продолжаете городить чушь из принципа?
>> Вот как будет что-то подобное,
> RuntimeDirectory= уже сто лет в обед.А у нас в квартире газ. Ну и причем тут все это?
>> да с поддержкой shell globbing - тогда и поговорим.
> А зачем там shell globbing?Затем что проблема появляется только в сценарии с ним. Я же объяснил,
причем на простейшем примере. А вы отказываетесь учиться.> В директиве ini-файла указывается только имя самого
> каталога, безо всяких звездочек.Ну а как быть, если вы не знаете имени каталога? Напр., temp-1245734242. Ну вот хочу я странного, удалить подобные каталоги, вот как-то так: "rm -rf /var/tmp/mysuperserver/temp-[0-9]*".
> Конструкция $DIRNAME/* - это костыль, имманентно присущий shell-скриптам
Знаем, знаем. "Вы все дураки и не лечитесь".
> Да, coreutils не писали обезъяны с избытком ЧСВ.Да, очень интересно получается: в coreutils значит это "нормальный код, так держать". А у поттера "во гад, прострелить пятку не дает!". Сразу видно двойные стандарты :)
> Да, очень интересно получается: в coreutils значит это "нормальный код, так держать".
> А у поттера "во гад, прострелить пятку не дает!".
> Сразу видно двойные стандарты :)Кто с чем к нам, тому того и на лопате. Последовательнее некуда.
>> Да, coreutils не писали обезъяны с избытком ЧСВ.
> Да, очень интересно получается: в coreutils значит это "нормальный код, так держать".
> А у поттера "во гад, прострелить пятку не дает!".Я подчеркнул, что это не одинаковый код. Разница на данном конкретном примере, конечно, невелика чтобы судить о сравнении качества кода. Но есть еще over 100500 строк, если вам вдруг интересно.
> Сразу видно двойные стандарты :)
Двойные стандарты - у того кто делает провокационное заявление и жалуется модераторам на ответы оппонента.
> Это он просто кусок кода у GNU rm слямзил. man rm,
> малыш.Это как-то отменяет тот факт, что "RemoveAllFilesInDir=" не удаляет корень, в отличие от "rm -rf /*"?
> Это как-то отменяет тот факт, что "RemoveAllFilesInDir=" не удаляет корень, в отличие
> от "rm -rf /*"?У криворуких пользователей системд даже rm -rf /* корень удаляет. Хотя по умолчанию этого делать не должна. Ну понятно почему их стандартное положение вещей не устраивало - руки из другого места.
> У криворуких пользователей системд даже rm -rf /* корень удаляет. Хотя по умолчанию этого делать не должна.Вообще-то должна. Но не-криворукие борцуны с systemd не знают, что такое глоббинг, и кто его делает, и какие параметры в итоге получает rm :)
> Вообще-то должна. Но не-криворукие борцуны с systemd не знают, что такое глоббинг,
> и кто его делает, и какие параметры в итоге получает rm
> :)Ааа, я там пробельчик забыл вставить. Ну молодец малыш, можешь засчитать себе заслуженную перемогу.
> Ааа, я там пробельчик забыл вставить.
> rm -rf $SQUID_PIDFILE_DIR/*В сабжевом баге, пробельчика не было :)
А я не за сабжевый текст говорил в данном случае.
> А я не за сабжевый текст говорил в данном случае."и не жопой, и не в лужу, и совсем-совсем не я"
>> А я не за сабжевый текст говорил в данном случае.
> "и не жопой, и не в лужу, и совсем-совсем не я"По крайней мере за то что лично я написал лично отвечаю. А не как ваш брат.
Ему ссылки здесь десяток раз на сравнение поиска текст/бд - он в кусты. На лоре обсуждение журналд и рассказы про "только на локалхосте, иначе другой софт использовать". Им ссылку на прошлые выступления как они делают "распределенную" "серверную" "скоростную" систему логгирования - они растворяются. Начинают рассказывать за мониторинг демонов, их просишь нагиос-стайл сделать - они вилять и рассказывать что это не это. Им говоришь нет такой хни в системд - используйте новую версию. Им в новой версии такие-то глюк - они, пискнув используйте стабильное старье, сваливают. А уж в каждой новости на "добавлено ХХХ новых ключей в юниты" кипятком исходят - это 146% что надо в продакшене серверном. Как-то забывая про подобный кипяток и в прошлом обсуждении, и в позапрошлом.
А пользователи системд все такие обезьяны?Certain commands can operate destructively on entire hierarchies. For example, if a user with appropriate privileges mistakenly runs ‘rm -rf / tmp/junk’, that may remove all files on the entire system. Since there are so few legitimate uses for such a command, GNU rm normally declines to operate on any directory that resolves to /. If you really want to try to remove all the files on your system, you can use the --no-preserve-root option, but the default behavior, specified by the --preserve-root option, is safer for most purposes.
> А пользователи системд все такие обезьяны?Андрюшка! Мирофанов! Ты сменил логин, но тебя все равно узнали, по неспособности сформулировать мысль)))
И фапатель на системд умудрился дважды в глинку лицом упасть. Первый раз подумав про Мирофанова(спишем на синтаксическую ошибку). Это твои фантазии какие-то?
Второй раз не поняв простой английский текст, про rm. Где написано, что всё уже было сделано до Поттеринга. И ничего он там предусмотреть не мог. Только тупо копи-пастинг делать.
> Второй раз не поняв простой английский текст, про rm. Где написано, что всё уже было сделано до Поттеринга.Вот только почему-то это сделанное до него не помогло предотвратить проблему.
> И ничего он там предусмотреть не мог. Только тупо копи-пастинг делать.
http://sources.debian.net/src/coreutils/8.23-4/lib/root-dev-...
И в процессе художественно переписать, ага. С тем же успехом можно утверждать, что любая программа на сях - копипаст моего приветмира школьных времен. Нуачо, "int main (int argc, char **argv)" есть же!
>> Второй раз не поняв простой английский текст, про rm. Где написано, что всё уже было сделано до Поттеринга.
> Вот только почему-то это сделанное до него не помогло предотвратить проблему.Ты сопоставить два события можешь?
Первое: по умолчанию рмрф корень не трогает. Вот никогда и никак.
Второе: корень потерся от рмрф.Где криворукие дэбилы? Да в твоем любимом инкубаторе системд. Точно также можно было системд с патчиком собрать и убрать все проверки. А потом плести про: нуачо - не работает же.
> И в процессе художественно переписать, ага.
Такой художественный прием как гипербола тебе известен? Приходится так и никак иначе объясняться Потому что обычный текст про рм ваш брат совершенно воспринимать не способен.
> Ты сопоставить два события можешь?
> Первое: по умолчанию рмрф корень не трогает. Вот никогда и никак.Про старинную, бородатую модификацию патча Бармина (rm -rf /*), обходящую preserve-root, мудрые борцы с системд, очевидно, не в курсе :)
> Такой художественный прием как гипербола тебе известен? Приходится так и никак иначе
> объясняться Потому что обычный текст про рм ваш брат совершенно воспринимать
> не способен.Да, ведь в из этого текста не понятно, что вы там придумали, читая его. Про ворованный код, в котором из общего только if - это сугубо ваши личные тараканы, и обычные люди предсказывать их не обязаны.
> Да, ведь в из этого текста не понятно, что вы там придумали,
> читая его. Про ворованный код, в котором из общего только if
> - это сугубо ваши личные тараканы, и обычные люди предсказывать их
> не обязаны.Ну ты то придумал офигенную проблему в данном тексте не глядя на this bug was found in an *UNRELEASED* update to squid.
Надеюсь, где-то там снаружи этот путь таки нормализуется, ибо "//" - это тот же "/", а проверка уже не работает.
> Надеюсь, где-то там снаружи этот путь таки нормализуется, ибо "//" - это тот же "/", а проверка уже не работает.В rm проверка осуществляется по номеру inode.
Для сомневающихся параноиков:
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/rm.c...
http://git.savannah.gnu.org/cgit/coreutils.git/tree/gl/lib/r...
http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/remo...
http://git.savannah.gnu.org/cgit/coreutils.git/tree/gl/lib/r...
>> А вот был бы у него systemd...
> и RemoveAllFilesInDir= в настройках юнита...Даже если не обращать внимание, что всякие Remove-директивы в systemd содержат проверки для защиты от случайного удаления корня...
Начнем с того, что в systemd вообще нет проблемы, с которой все началось - для отслеживания процессов используются контрольные группы, и костыль в виде PID-файлов там нафиг не уперся (ходя и поддерживается для совместимости с "юниксвейными" жертвами костылизма). Соответственно, раз PID-файлов нет, то и каталог с ними очищать не надо.
вот вот. Ретрограды с инитскриптами идут на х...
в смысле идут за extundelete
В ext* - без шансов при сколько-нибудь активной записи. Даже если немедленно дёрнуть питание или "xl destroy".
> В ext* - без шансов при сколько-нибудь активной записи. Даже если немедленно дёрнуть питание или "xl destroy".Как насчет photorec?
> Как насчет photorec?Получишь свои фоты. Половинками.
systemd не освобождает от писания скриптов.
Просто теперь они не лежат в папке /etc/init.d (что правда и раньше было не обязательным), а размазаны равномерным слоем по всем файловым системам.
Посмотрев на эволюцию того как их перефигачивают и перекладывают по желанию левой пятки мантейнера дистрибутива.
На примера запуска того же tomcat в rhel7 и 7.1 понял смысл слова инновация.
> На примера запуска того же tomcat в rhel7 и 7.1 понял смысл слова инновация.просветите? :) аж интересно стало
> systemd не освобождает от писания скриптов.Ещё как освобождает, более того - можно выкинуть не только скрипты, но и часть старого кода, отвечавшего за инициализацию сокетов, двойной форк и прочий онанизм для демонов.
>> systemd не освобождает
> Ещё как освобождает, более того - можно выкинуть не только скрипты, но
> и часть старого кода, отвечавшего за инициализацию сокетов, двойной форк и
> прочий онанизм для демонов.http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/uni...
Спасибо, Лёня!
> Спасибо, Лёня!Казалось бы, при чем тут Леня?
>> Спасибо, Лёня!
> Казалось бы, при чем тут Леня?Купил-жене-сапоги почему-то считает вышеуказанное заслугой s-d. ++Место в профессии!!
> Купил-жене-сапоги почему-то считает вышеуказанное заслугой s-d. ++Место в профессии!!Хм. А более связно изъясняться вы можете?
>> Купил-жене-сапоги почему-то считает вышеуказанное заслугой s-d. ++Место в профессии!!
> Хм. А более связно изъясняться вы можете?Видеоурок что ли "написать"??
>>> Купил-жене-сапоги почему-то считает вышеуказанное заслугой s-d. ++Место в профессии!!
>> Хм. А более связно изъясняться вы можете?
> Видеоурок что ли "написать"??Да, по несвязности речи вы этих "дикторов" без труда за пояс заткнете ;)
А может это у тебя проблемы с пониманием?
Вы строите утверждение на основе теории или посмотрели, как у адептов из RH все сделано?
>Ещё как освобождает, более того - можно выкинуть не только скрипты, но и часть старого кода, отвечавшего за инициализацию сокетов, двойной форк и прочий онанизм для демонов.вот за одно это поттера можно и нужно казнить!!!
Более того, он добавляет онанизма, но уже с сишным кодом. Взгляните например на херовы дебри БИНАРНЫХ генераторов юнитов.Или вот на это: https://www.linux.org.ru/news/opensource/11344526/page2?last...
stpcpy(stpcpy(stpcpy(mempcpy(ret, slice, e - slice), "-"), name), ".slice");"и эти люди запрещают мне ковыряться в носу!"(с)
Мать, как такое вообще пропустили? Голову же отбивать надо
Глупым одминам, которые ничего кроме баша не видели в жизни - да, отбивает голову. Но по факту все правильно написано.
> Глупым одминам, которые ничего кроме баша не видели в жизни - да,
> отбивает голову. Но по факту все правильно написано.Crazy Alex неоднократно говорил, что он не программист, но мнение по ряду вопросов coding style имеет :)
... и тут я понял, что двух рук для facepalm-а мне мало
http://www.facepalm.su/wp-content/gallery/double-facepalm-1/...
> "и эти люди запрещают мне ковыряться в носу!"(с)А ты посмотри на исходники шелл портянок. Вон одни уже посмотрели. А на самом деле такого г-на по чуланам довольно много.
Скрипткидозники принципиально не проверяют ошибки, забивают на коды возврата и не могут себе вообразить что какая-то переменная может быть не установлена. А потом их скриптовая дрянь выносит полсистемы или что-нибудь ломает. Но свое же не пахнет, поэтому себе - скидки. Это ж не поттера за баги поливать. Себя то поливать не прикольно. Между тем, квалификация большинства скриптеров - ниже плинтуса.
>> "и эти люди запрещают мне ковыряться в носу!"(с)
> А ты посмотри на исходники шелл портянок. Вон одни уже посмотрели. А
> на самом деле такого г-на по чуланам довольно много.
> Скрипткидозники принципиально не проверяют ошибки, забивают на коды возврата и не могут
> себе вообразить что какая-то переменная может быть не установлена. А потом
> их скриптовая дрянь выносит полсистемы или что-нибудь ломает. Но свое же
> не пахнет, поэтому себе - скидки. Это ж не поттера за
> баги поливать. Себя то поливать не прикольно. Между тем, квалификация большинства
> скриптеров - ниже плинтуса.Здесь, к сожалению, всё правда. Про тот же set -u вообще мало кто слышал, а ведь в описанной в новости ситуации спасло бы...
> Более того, он добавляет онанизма, но уже с сишным кодом. Взгляните например
> на херовы дебри БИНАРНЫХ генераторов юнитов.Если не знаешь сишки, работа со строками и указателями может показаться пугающей. Но на самом деле, никакой магии там нет.
> Если не знаешь сишки, работа со строками и указателями может показаться пугающей.
> Но на самом деле, никакой магии там нет.Разумеется нет, там сплошной идиотизм. За использование магических чисел - предварительно вычисленных длин строк должна полагаться смерть через матумбу.
> За использование магических чисел - предварительно вычисленных длин строк должна полагаться смерть через матумбу.Сначала придется убить gcc, и заодно clang вместе с их авторами :)
Смерти через матумбу достойны очень многие. И наличие конкретного идиотизма в clang'е никак не оправдывает авторов systemd.
> Смерти через матумбу достойны очень многие. И наличие конкретного идиотизма в clang'е
> никак не оправдывает авторов systemd.И что характерно, умники типа Vkni отнюдь не собираются писать софт вместо тех, которым смерти желают. А если некоторые особо ушлые все-таки рискуют - оказывается что их рафинированные концепты с расово верным кодом, но погаными эксплуатационными параметрами, кодом в который никто кроме автора вдуплить не может и прочая - даром никому не упали. И вот бубнят эти теоретики. Уже несколько десятилетий. А остальной мир плевать на них хотел и идет своей дорогой.
> И что характерно, умники типа Vkni отнюдь не собираются писать софт вместо
> тех, которым смерти желают.1. В clang'е мне не нравятся файлы toolchain и т.д. Они определяют расположение исполняемого файла gcc с помощью эвристик. Поскольку я не являюсь запаковщиком clang'а, я не исправляю эти куски (их нужно просто выбросить). Я предложил вариант в рассылке Alt'а, но он не заинтересовал запаковщика clang'а.
2. По-поводу systemd моё мнение просто - я не вижу смысла ещё один раз писать init. А уж тем более, собственноручно. Т.е. отличная альтернатива systemd уже написана, отлажена и прекрасно работает на моём компьютере. Её улучшать - только портить.
> 1. В clang'е мне не нравятся файлы toolchain и т.д.Мне в clang да и gcc много чего не нравится. Но если быть реалистом - тулчейн на коленке не сделаешь, т.к. чтобы оно стало вместо наколенной пoдeлки чем-то реально юзабельным - надо годы работы толпы народа. И некоторые вещи нормально могут только они.
А эти ваши хаскелисты обычно занимаются рафинированным концептодрoчерством. Из разряда "во как я могу!". Примерно как мужик тянущий тепловоз, только применительно к мозгам. Ну да, как шоу - выглядит круто. Но бесполезно для организации регулярных рейсов по магистрали.
Когда у народа большой дистр на 40К пакетов, последнее что им всем хочется - колупаться в этом вашем "во как я могу!", пытаясь неделю вдуплить что там за лямбда-функции в системе инициализации и нафига они там вообще сдались. И зачем там вообще такие навороты.
Вот поттер молодец именно тем что сделал все эти художества несколько неудобными и ими будут пользоваться только когда иначе - вообще совсем никак. По поводу чего жизнь майнтайнеров и админов станет сильно проще и им не придется лишний раз тратить время на декодирование чужого "во как я могу!".
> Я предложил вариант в рассылке Alt'а, но он не заинтересовал запаковщика clang'а.
Ну это уже дело хозяйское.
> альтернатива systemd уже написана, отлажена и прекрасно работает на моём компьютере.
А мне не нравится как работает init. По моему мнению, он не решает уйму моих проблем, провоцирует неудачные административные практики и создает лишнюю нагрузку на майнтайнеров. На мой вкус он свое отлетал и я не буду расстраиваться, расставшись с этим крапом. В systemd намного менее криво сделаны даже самые базовые вещи, типа disable старта сервиса, boot ordering и прочая. Он не кладет на ошибки и нормально логгит вывод программ при старте и коды возврата, так что в случае факапа по крайней мере можно понять что и почему. А если уж мы про логгинге - в отличие от инита не получится так что половина логов ушло в /dev/null, потому что дескать на момент написания лога - логгер еще вообще не взлетел.
> Мне в clang да и gcc много чего не нравится. Но если
> быть реалистом - тулчейн на коленке не сделаешь, т.к. чтобы оно
> стало вместо наколенной пoдeлки чем-то реально юзабельным - надо годы работы
> толпы народа. И некоторые вещи нормально могут только они.Да, но это не подразумевает, что нужно плодить заведомое говно и хвалиться этим.
> А эти ваши хаскелисты обычно занимаются рафинированным концептодрoчерством. Из разряда
> "во как я могу!".Бывает такое. Но Хаскел - это довольно специфическая штука. Я, например, задавал вопрос вполне квалифицированным людям насчёт ассимптотической скорости алгоритмов под Хаскеллем. Не секрет, ведь, что в подходе "переменные отменяются" очень многое зависит от оптимизатора. Увы, это "серая зона" - часть алгоритмов точно оптимизируется нормально, но в целом, надо читать статьи.
> Когда у народа большой дистр на 40К пакетов, последнее что им всем
> хочется - колупаться в этом вашем "во как я могу!", пытаясь
> неделю вдуплить что там за лямбда-функции в системе инициализации и нафига
> они там вообще сдались. И зачем там вообще такие навороты.Нужны не лямбда-функции (вещь совершенно прозрачная и простая - указатель на функцию без имени), а типы и строгая проверка типов.
> Вот поттер молодец именно тем что сделал все эти художества несколько неудобными
> и ими будут пользоваться только когда иначе - вообще совсем никак.Он эти художества сделал сам. За тот Сшный код, который он наваял, нужно выдирать руки из задницы.
> А мне не нравится как работает init. По моему мнению, он не
> решает уйму моих проблем, провоцирует неудачные административные практики и создает лишнюю
> нагрузку на майнтайнеров.Это должна делать обвязка к initу - аналог sysVinit или bsd init. Она должна быть написана на лёгком, удобном скриптовом языке для удобства поддержки и заточки под собственные нужды.
Вообще, освобождает. Но для этого надо изменить мышление с императивного на декларативное, делать пачку простых юнитов, зависящих друг от друга. Мейнтенерам же проще идти привычным путем, потому и получается шило на мыло. В дебиане такой же маразм, притом что стало даже хуже, чем в убунте с upstart.Более-менее правильное использование systemd я видел только в Arch.
> Вообще, освобождает. Но для этого надо изменить мышление с императивного на декларативное, делать пачку простых юнитов, зависящих друг от друга.Чем это лучше пачки инитскриптов зависящих друг от друга? Ничем. Чем это хуже? А тем, что инитскипт можно собрать в один файл, и весь скрипт, все его действия, будут перед глазами. В шелле нет сотни скрытых параметров, как в systemd, и те команды которых нет в файле не влияют на его исполнение.
В остальном юниты systemd - очередной маргинальный скриптовый nih-язык, по всем параметрам хуже шелла. Но если шелл уже итак знают все, и его знание полезно в повседневной работе, то cинтаксис systemd знают единицы, и в обычной жизни это знание абсолютно бесполезно.
Не вижу ни в его использовании ни в продвижении никакого смысла.
> В остальном юниты systemd - очередной маргинальный скриптовый nih-языкДальше можно не читать. Кому интересно мнение человека, который демонстрирует вопиющую неграмотность в тех вопросах, о которых рассуждает?
> Дальше можно не читать. Кому интересно мнение человека, который демонстрирует вопиющую
> неграмотность в тех вопросах, о которых рассуждает?Что поделаешь, не все люди знают всё. Вот и приходится мне общаться с неграмотными, поднимать уровень знаний, чтобы люди учились на чужих ошибках, и не изобретали свои грабли заново.
А что, вы не считаете синтаксис systemd скриптовым языком? А каким? Компилируемым? Или вы не считаете его языком? ;)
В systemd язык конфигурации, а не язык программирования. Языком программирования он не является хотя бы по причине неполноты по Тьюрингу.
> В systemd язык конфигурации, а не язык программирования. Языком программирования он не является хотя бы по причине неполноты по Тьюрингу.Пожалуйста, перестаньте употреблять термины, неизвестные ветеранам юникс-администрирования.
Ветеран юникс-администрирования всезнающ по определению. Если он чего-то не знает - значит, это выдумка поцтерингофанов.
Хахаха :-)С "ветеранами" вообще разговор отдельный. Моя практика показывает, что люди, занимающиеся подобным самовосхвалением, и люди, имеющие базовые знания Computer Science - два непересекающихся множества.
Вот недавно такой "ветеран", ежедневно понтующийся своей крутостью в фейсбуке, при небольшом DDos-е быстро поднял лапки и отправил работодателя покупать дорогущий anti-ddos. Я случайно рядом был, решил все за 10 минут тюнингом ядра и парочкой iptables-правил. Хотя я вообще программист, а администрированием занимаюсь только на личных проектах. :-)
> Вот недавно такой "ветеран", ежедневно понтующийся своей крутостью в фейсбуке, при небольшом DDos-е быстро поднял лапки и отправил работодателя покупать дорогущий anti-ddos.Я даже знаю, как он это оправдал :)
"Каждый компонент должен решать только одну задачу, веб-сервер - отвечать на HTTP-запросы, роутер - передавать данные, а с ddos бороться - это не их задача".
Я не спрашивал. :-)Но через месяц он там уже не работал.
К сожалению, в большинстве случаев ddos тюнингом ядра не лечится, а надо именно что покупать дорогостоящий anti-ddos.
Когда не лечится - тогда и покупается. Ту пукалку DDos-ом-то назвать - большая похвала.
> К сожалению, в большинстве случаев ddos тюнингом ядра не лечится, а надо
> именно что покупать дорогостоящий anti-ddos.Смотря что под DDoS понимать. Если крутой флуд, когда тебе забили канал в полку - тут да, только аренда распределенного фильтрующего фронтэнда и поможет, просто потому что мощность этой структуры такая, что все и сразу боты из ботнета перефлудить не смогут, а дальше фильтр убьет лишнее и до вас это не долетит.
А от всяких дешевых пЫонерских фокусов "а я тоже освоил генератор пакетов!" тюнинг вполне может помочь.
> Что поделаешь, не все люди знают всё. Вот и приходится мне общаться с неграмотными, поднимать уровень знаний,Знание уровня вашей некомпетентности - это тоже знание, да :)
> А что, вы не считаете синтаксис systemd скриптовым языком? А каким? Компилируемым? Или вы не считаете его языком? ;)
Начнем с того, что синтаксис конфигов systemd не является тьюринг-полным языком программирования.
А теперь бегом отправляйтесь в википедию, поднимать уровень знаний!
Смысл примерно в том же, в чем преимущество ООП/ООД перед простынями последовательного кода в крупных проектах.Нужно это далеко не всем, наверное, даже меньшинству, и мне непонятно, зачем systemd насильно запихивают во все дыры. Но вот в CoreOS, совместно с fleet, получается прекрасный инструмент работы с кластером.
> Нужно это далеко не всем, наверное, даже меньшинству, и мне непонятно, зачем
> systemd насильно запихивают во все дыры.Наверное, потому что все, кроме этого меньшинства, глубоко параллельно, что там внутри инита.
Незаметно, чтобы было параллельно - каждое упоминание systemd порождает очередную порцию флейма. :-)Притом, что самое удивительное - и в RHEL, и в Debian systemd используют вполсилы, вперемешку с инит-скриптами. А наиболее "каноничное" его использование - в ArchLinux, который в крупном продакшене гость нечастый.
> Незаметно, чтобы было параллельно - каждое упоминание systemd порождает очередную порцию флейма. :-)Я вам скажу по секрету, что человек может спокойно использовать дистрибутив с systemd (нуачо, работает и есть не просит), но при этом в дискуссиях быть ярым борцом с Поттером (потому что нынче это в тренде).
> Притом, что самое удивительное - и в RHEL, и в Debian systemd используют вполсилы, вперемешку с инит-скриптами.
Следствие инертности мышления, увы.
А вообще, вы правы - под грудой кривых скриптов действительно не видно и не важно, какой там инит. Все равно в случае каких-то косяков (типа сабжа) придется копаться в этой груде.
> хуже? А тем, что инитскипт можно собрать в один файл, и
> весь скрипт, все его действия, будут перед глазами. В шелле нет
> сотни скрытых параметров, как в systemd,Конечно, поэтому в портянке на 5 кило кода такие упыри пропишут параметры "по всей площади". Очень удобно выколупывать пути и прочая по всем пяти килобайтам...
> В дебиане такой же маразм, притом что стало даже хуже, чем в убунте с upstart.Любовь к костылям не проходит за полгода. Это нужно полностью перестраивать систему мышления, отказываться от квази-"юниксовой" идеологии "зачем думать, читать маны, это же можно решить добавлением очередного скрипта". Может, лет эдак через пять пойдут какие-то положительные изменения.
>> В дебиане такой же маразм, притом что стало даже хуже, чем в убунте с upstart.
>Это нужно полностью перестраивать систему
> мышления, отказываться от квази-"юниксовой" идеологии "зачем думать, читать маны, это
> же можно решить добавлением очередного скрипта".""Решим все Ваши проблемы. Промыванием мозгов клизмой."" --Секта s-d.
> Может, лет эдак через пять пойдут какие-то положительные изменения.
> ""Решим все Ваши проблемы. Промыванием мозгов клизмой."" --Секта s-d.Нет, простите, Ваших проблем никто не решит. Нельзя промыть то, чего нет))
У языков 4го поколения тоже есть свои недостатки.
Да декларативное программирование проще - ибо за все отвечает думатель, который внутре.
Но порой оказывается, что он тоже не идеален и не всемогущ.
И если задачи чуть выходят за ограниченный заранее круг, то все приходится возвращаться к предыдущему поколению.
> вот вот. Ретрограды с инитскриптами идут на х...Просто программист - не профессия а сексуальная ориентация. Противоестественная. Кто бы болванов научил простейшему скрипт-программированию. Но нет, это же мааааааагия!
> Просто программист - не профессия а сексуальная ориентация. Противоестественная. Кто бы
> болванов научил простейшему скрипт-программированию. Но нет, это же мааааааагия!А уж если человек с трудом освоил костыляние на шелле - все, он мегахакер, супер-программер и вообще элита, осваивать нормальные ЯП считает ниже своего достоинства. При виде работы с указателями в сях впадает в истерику и, аки Милонов, требует срочно запретить "блобы" (при то, что без блобоядра и блобоинтерпретатора его мега-скрипты не запустятся, он, очевидно, не в курсе).
> Просто программист - не профессия а сексуальная ориентация. Противоестественная. Кто бы
> болванов научил простейшему скрипт-программированию. Но нет, это же мааааааагия!Простите, но скрипткидисы всегда и считались самыми болванистыми из всех программистов. Поэтому то что эти пипетки пытаются из себя корчить целую гордую клизму - ни на бит не улучшает их кривой и бажный код, которым можно пугать детей. Да-да, большинство инит скриптов являются наглядным пособием по теме "как не надо писать программы". То что из-за поттера такие орлы пойдут теперь подметать улицы и ползать в админской позе под столами, протягивая витуху - это вообще фича а не баг.
>> Просто программист - не профессия а сексуальная ориентация. Противоестественная. Кто бы
>> болванов научил простейшему скрипт-программированию. Но нет, это же мааааааагия!
> Простите, но скрипткидисы всегда и считались самыми болванистыми из всех программистов.
> Поэтому то что эти пипетки пытаются из себя корчить целую гордую
> клизму - ни на бит не улучшает их кривой и бажный
> код, которым можно пугать детей. Да-да, большинство инит скриптов являются наглядным
> пособием по теме "как не надо писать программы". То что из-за
> поттера такие орлы пойдут теперь подметать улицы и ползать в админской
> позе под столами, протягивая витуху - это вообще фича а не
> баг.Не пойдут ни разу. Вместо кривых скриптов будут непродуманные юниты, вот и вся разница. Не верите? А вы сравните, скажем, ситуацию в другой области с похожей разницей в подходах, например, ipfw vs. PF. Второй куда декларативнее, но точно так же позволяет заблокировать себе самому SSH. Кстати, входной порог у PF, пожалуй, даже ниже будет. Как и бинты писать проще, чем хорошие скрипты. То есть юниты станут, возможно, массовыми. А результат будет — угадайте, какой. Именно противоположный тому, о чём Вы мечтаете.
Я думаю, systemd тоже полон сюрпрайзов, о которых только предстоит узнать
> Я думаю, systemd тоже полон сюрпрайзов, о которых только предстоит узнатьУже скоро. Релиз Debian-а близится. Ждём оползней и обрушений...
> Уже скоро. Релиз Debian-а близится. Ждём оползней и обрушений...А, вот кто виноват в разрушении пятиэтажки! Ну все, не отвертитесь, канальи. Вы знали о том что поттеринг замышляет, но не сообщили. Теперь вы попали!
Не удивлюсь если ошибку специально добавили пару месяцев назад, чтобы после обнаружения заявить "вот видите какй sysvinit плохой! А вы ещё не хотите переходить на RHEL/CentOS 7!".
Там вообще-то upstart.
> Там вообще-то upstart.А толку от этого upstart, если все равно все через скрипты работает?
Такие инциденты наводят на мысль, что более правилен подход OpenRC - полный отказ от совместимости с init-скриптами (правда, это стало одной из основных причин его провала в дебиане).
> Такие инциденты наводят на мысль, что более правилен подход OpenRC - полный
> отказ от совместимости с init-скриптамиOpenRC - это те же скрипты, только еще более навороченные. По поводу чего оно не решает ни одной проблемы и создает много новых. Нафиг нужно.
> Там вообще-то upstart.Да дрогнула у них рука в свое время полноценно апстарт впилить
> Там вообще-то upstart.Ну, понимаете, у некоторых людей всегда во всех бедах жи^W либера^W аген^W, пардон, Поттеринг виноват :). Совок всегда остается совком.
В 7ке Systemd, а вот в 6ке Upstart. Вам и написали, что это была рекламная акция демонстрирующая преимущества systemd. Вот если бы там написали
ExecStartPost=-/bin/bash -c "rm -rf %I/*"
Этого все бы сработало на ура.
Дык! А сколько баттхёрта было, когда у идиотов даже не отняли, а лишь серьёзно затруднили возможность прострелить себе ногу...
> Дык! А сколько баттхёрта было, когда у идиотов даже не отняли, а лишь серьёзно затруднили возможность прострелить себе ногу...У многих баттхертящих вообще инитом svchost.exe :)
> У многих баттхертящих вообще инитом svchost.exe :)Вам бы так хотелось думать, но как видим - придется обломаться.
Wininit.exe же!
> Wininit.exe же!Про SMSS.EXE как-то даже упоминать неудобно.
>А вот был бы у него systemd...У всех бы похерилось? )
> А вот был бы у него systemd...Да, это еще один хитрый пиар-ход Systemd. Мол "в системд такого бы не произошло".
> Да, это еще один хитрый пиар-ход Systemd. Мол "в системд такого бы не произошло".Ждем на бис в дебиане и генте!
Facepalm. Уныние и безысходность...
Надо было переходить на systemd еще в шестерке!
Если есть платная поддержка, то наверно можно обратиться и они будут обязаны хоть из параллельной вселенной похеренные данные достать.
Это тестовый релиз.
ничего тебе RH не должен, почитай их условия представления услуг.
архисекурный редхат. только с rm это они зря, нужно dd из рандома юзать.
Причём тут RHEL?
Так ошибка в том патче, что они накатили.
При том, что какой-то негодяй тока что своё сообщение стёр
dd из рандома - это кустарщина и радиолюбительство. солидные люди пользуются wipe.
> архисекурный редхат.А вот и эксперты по балабо^W безопасности подоспели. Крутой гуру-безопасник - Тигар. Получил 100500 долларов на pwn2own, по любому.
>> архисекурный редхат.
> А вот и эксперты по балабо^W безопасности подоспели. Крутой гуру-безопасник - Тигар.
> Получил 100500 долларов на pwn2own, по любому.сильно комплексуешь по этому поводу, детка? хочешь об этом поговорить, пупсик?;)
> сильно комплексуешь по этому поводу, детка? хочешь об этом поговорить, пупсик?;)Да не, просто что-то никак не могу найти тебя в списке призеров, наверное я что-то делаю не так. Наверное надо другой список изучать - например, участников Специальной олимпиады :). Вот там ты точно будешь на призовых местах.
>> сильно комплексуешь по этому поводу, детка? хочешь об этом поговорить, пупсик?;)
> Да не, просто что-то никак не могу найти тебя в списке призеров,
> наверное я что-то делаю не так. Наверное надо другой список изучать
> - например, участников Специальной олимпиады :). Вот там ты точно будешь
> на призовых местах.а до тебя, детонька, или сразу после? ответь, это очень важно.
А вот в fish shell так не сработало бы. И это хорошо.
Я тоже пользователь fish. Но ни разу не видел скрипты на нем, по-моему, писать инит-скрипт на fish чуть менее бесперспективно, чем на csh, т.е. всё-таки плохая идея.Другой вопрос -- то, что systemd, да и апстарт, должны были избавить от sh-портянок в инит-файлах. Во-первых, в rh6 этого всего ещё нет (я в курсе про апстарт унутре, но апстарт-скрипт ему не скормить). Ну, а во-вторых, программисты на шелле таки не освоили systemd и теперь дергают свои шелл-портянки оттуда.
Да, и в-третьих. Пару лет назад использовали мы в продакшне сквид на centos в довольно объёмных инсталляциях. Упёрлись в то, что родной из родных реп -- использовать нельзя. Так что ошибка эпичная, но что всех в реальности затрагивает родной сквид из беты прошлой мажорной ветки rhel -- тоже история сомнительная.
Скажите нубу, вот зачем нужно было дописывать после переменной /* ?
Затем, чтобы удалить все файлы в директории, но не саму директорию
не хочу показаться занудой, но если нужно было удалить только все файлы, то ключ -r лишний
> не хочу показаться занудой, но если нужно было удалить только все файлы,
> то ключ -r лишнийфайлы и директории удалить. Думал и так понятно
> файлы и директории удалить. Думал и так понятноНо зачем удалять подкаталоги? Там же их быть не должно, по определению. А если и есть - значит, не просто так, а потому, что кто-то их специально создал. Вот пусть он и удаляет.
А какой смысл в пустой директории?
А если подумать?
> Затем, чтобы удалить все файлы в директории, но не саму директориюТ.е. оставлять пустую директорию архиважно? Как надпись "здесь был вася"?
>> Затем, чтобы удалить все файлы в директории, но не саму директорию
> Т.е. оставлять пустую директорию архиважно? Как надпись "здесь был вася"?А ты предлагаешь каждый раз перед записью в файл проверять существует ли путь до нег?Или удалять директорию, а потом сразу создавать ее и выставлять права?
>>> Затем, чтобы удалить все файлы в директории, но не саму директорию
>> Т.е. оставлять пустую директорию архиважно? Как надпись "здесь был вася"?
> А ты предлагаешь каждый раз перед записью в файл проверять существует ли
> путь до нег?Или удалять директорию, а потом сразу создавать ее и
> выставлять права?А лучше надеяться на правильное содержимое критической переменной?
В данном случае они просто тупо скопипастили кусок кода не проверив ничего, в этом вся проблема. К вопросу удаления содержимого папки это вообще не имеет отношения.
> В данном случае они просто тупо скопипастили кусок кода не проверив ничего,
> в этом вся проблема. К вопросу удаления содержимого папки это вообще
> не имеет отношения.Отсюда делаю вывод - лучше "rm -fr $VAR/*" не писать.
>> В данном случае они просто тупо скопипастили кусок кода не проверив ничего,
>> в этом вся проблема. К вопросу удаления содержимого папки это вообще
>> не имеет отношения.
> Отсюда делаю вывод - лучше "rm -fr $VAR/*" не писать.А лучше бы понял, что если уж копипастишь, то проверяй 7 раз, прежде, чем в релиз пускать. А если сам написал такое и забыл про переменную, то где гарантия, что в другом месте не накосячишь, как, например, в уже упоминавшимся bumblebee было или ещё что поумнее придумаешь? Везде соломки не подстелишь.
>>> В данном случае они просто тупо скопипастили кусок кода не проверив ничего,
>>> в этом вся проблема. К вопросу удаления содержимого папки это вообще
>>> не имеет отношения.
>> Отсюда делаю вывод - лучше "rm -fr $VAR/*" не писать.
> А лучше бы понял, что если уж копипастишь, то проверяй 7 раз,
> прежде, чем в релиз пускать. А если сам написал такое и
> забыл про переменную, то где гарантия, что в другом месте не
> накосячишь, как, например, в уже упоминавшимся bumblebee было или ещё что
> поумнее придумаешь? Везде соломки не подстелишь.Надо к этому стремиться, ёбто. Тесты проводить и программить с умом. А не как бык посцал.
> А лучше надеяться на правильное содержимое критической переменной?Скрипткидозники всегда так и делают. А потом если что-то не работает - даже логгинг пиши себе сам, чувак! А скриптодрянь даже и не икнет никуда сообщением что что-то не так. Скажет что все отработало, и досвидания. А ты если хочешь, можешь логгинг и обработку ошибок сам дописать за скрипткидозниками.
> зачем нужно было дописывать после переменной /*Чтобы удалить все файлы в данном каталоге.
КО
Эх, Семен Семеныч..
Я смотрю, удаление всех файлов на диске при перезапуске программы становится всё более модным.
> Я смотрю, удаление всех файлов на диске при перезапуске программы становится всё
> более модным.Да не сцы, я видел виндовую программу, рекурсивно выносившую весь C:\ еще 10 лет назад. Правда почему-то никто из юзеров не жаловался.
bumblebee #2 :DНа внимательность:
"rm -rf /usr /lib/nvidia-current/xorg/xorg"https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi...
Это уже №3.
Что пропустил?
steam
> steamЯндекс тоже отличился в этом плане, хоть и под оффтопиком.
rm -rf злейший враг линуксоидов.
> rm -rf злейший враг линуксоидов.rm -rf /*
нет.
есть и другие способы "выстрелить себе в ногу".
но это всё внешние по отношению к линуксоидам факторы.а злейший враг - он, как обычно, в голове.
злейший враг линуксоида - идиотизм. в данном случае других "знатных линуксоидов"
почему нет команды удаления показывающей сколько файлов и каталогов удаляется и спрашивающей подтверждение? Понятно что в этом случае она бесполезна, хотя бы от ошибок в консоли уберегла бы.
rm -Iv
Потому, что опция -f команды rm предназначена для того, чтобы удалять файлы ничего не спрашивая. Без неё всё спрашивается.Всегда ваш Капитан.
> Потому, что опция -f команды rm предназначена для того, чтобы удалять файлы
> ничего не спрашивая. Без неё всё спрашивается.
> Всегда ваш Капитан.Товарищ Капитан, это не Windows, здесь удаление по умолчанию работает по-другому!
(если, конечно, заботливый дистростроитель не включил rm -i в качестве алиаса для rm по умолчанию — привет, Красная Шапочка!)
https://bugzilla.redhat.com/show_activity.cgi?id=1102343
отличная строчка в резюме ящетаю.
bash-4.1$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.6 (Santiago)
bash-4.1$ rpm -q squid
squid-3.1.10-29.el6.x86_64
bash-4.1$ grep -i squid_pidfile_dir /etc/rc.d/init.d/squid
bash-4.1$ grep -A3 -i restart\(\) /etc/rc.d/init.d/squid
restart() {
stop
start
}
--
condrestart() {
[ -e /var/lock/subsys/squid ] && restart || :
}откуда эти инициативные идиоты вообще взяли етот $SQUID_PIDFILE_DIR???
>> В поставляемом в составе тестового выпуска Red Hat Enterprise Linux 6.7..
>> bash-4.1$ cat /etc/redhat-release
>> Red Hat Enterprise Linux Server release 6.6 (Santiago)
>>> В поставляемом в составе тестового выпуска Red Hat Enterprise Linux 6.7..
>>> bash-4.1$ cat /etc/redhat-release
>>> Red Hat Enterprise Linux Server release 6.6 (Santiago)я тебе гарантирую, что и в 6.7 инит скрипт сквида тоже не предусматривал $SQUID_PIDFILE_DIR, пока этот ретивый чех его туда не вставил.
Имя репортера - испаноязычное, ты с мейнтейнерам путаешь.
> Имя репортера - испаноязычное, ты с мейнтейнерам путаешь.Не, а кто реально этот rm вставил, если даже мейнтейнер правильный патч сразу нарисовал?
Грабли rm давно пора снабдить более удобной ручкой.
В смысле, настройками области видимости (типа --one-file-system), владельца и глубины сверху/снизу. И не надо тыкать в find - ну не будут так выписывать в большинстве случаев.Иначе грабли так и продолжат бить даже сравнительно осторожных, типа эпичного "rm -rf /usr /lib/nvidia-current/xorg/xorg". Ну и вспомнить сюрприз в старых фрюхах, когда "rm *" захватывал '.' и '..'. А чо? WildCard же...
>Грабли rm давно пора снабдить более удобной ручкой.в руках идиота даже палочка от эскимо смертельно опасна
> в руках идиота даже палочка от эскимо смертельно опаснаА в руках некоторых идиотов опасность может представлять даже само эскимо.
> А в руках некоторых идиотов опасность может представлять даже само эскимо.Так, блин, у програмеров написание скриптов сроду считалось непочетной и грязной работой для субъектов с низким IQ. Ну вот и достается всем это стремное эскимо...
Грабли здесь в проверке наличия уже запущенного экземпляра приложения. В Линукс это принято делать, создавая пустой временный файл. Следуя этой логике дальше, протоколирование хода работы программы также осуществляется созданием и удалением пустых временных файлов. При перезапуске программы всех эти файлы нужно удалить. Небольшая ошибка - и удаляется ЗНАЧИТЕЛЬНО больше запланированного.В 60-е (когда Торвальдс учился в ВУЗе) это казалось передовой практикой (всё есть файл), но не сегодня. Старую собаку не научишь новым приёмам. Поэтому так важно, чтобы ничто и никогда не замыкалось на одного человека.
А какая есть лучшая практика? Реестр от укуренных индусов из M$? И если понимать, как устроен компьютер, то да, всё, что содержит информацию есть файл.Торвальдс 69 года рождения, если он ухитрился в 60-е учиться в вузе, то его гениальность неоспорима - подтверждается даже ботом из M$.
Задача решается с использованием примитивов синхронизации межпроцессного взаимодействия, которые должны быть частью API. Примитивов.
> Задача решается с использованием примитивов синхронизации межпроцессного взаимодействия, которые должны быть частью API. Примитивов.При таком решении теряется главное преимущество концепции "всё есть файл" — универсальность. В данном случае под этим следует подразумевать возможность получения информации [о наличии запущенного экземпляра программы] из скриптов и прочего ненативного кода.
Иными словами, вы считаете необходимым в угоду концепции "всё есть файл" заменить все функции API на 4 функции работы с файловой системой (read, write, open, close), так?Постебусь, пожалуй, немного:
file.open("api_query");
file.write("GetDMAChannel := 1")
file.close()file.open("api_wait");
file.write();
file.close();
while(1)
{
if(!file.open("api_wait"))break;
file.close();
}file.create("api_result");
file.read();
file.close();Программа в любом случае обращается к API. Логично, если она будет сразу запрашивать то, что ей нужно, а не создавать ещё один уровень абстракций в виде файлов, наличие и отсутствие которых будет как то интерпретироваться.
> При таком решении теряется главное преимущество концепции "всё есть файл" — универсальность.Иди поработай с ioctl'овыми апи универсально, ога :)
> Реестр от укуренных индусов из M$?Хранение конфигов в иерархической базе ключ-значение - сама по себе вполне здравая идея. А только ничто не может помешать неосторожному мантейнеру пакета вписать команду, которая снесёт всё содержимое реестра, и запихнуть её он может как в простыню на bash, так и юнит-файл systemd.
> как в простыню на bash, так и юнит-файл systemd.Но поскольку системдэ умеет уйму всего сам - у нас будет относительно отлаженное core, которое скриптокидозники с руками из ж...ы не переизобретают в очередной раз. И позвать это core будет относительно безопасно, в отличие от кода писаной левой пяткой какого-то укурившегося упыря, считающего что кто-то всенепременно гарантирует наличие правильной переменой, а думать что будет если там ничего нет - не для него. Поттер и то не такой дуб.
> Хранение конфигов в иерархической базе ключ-значение - сама по себе вполне здравая идея.А ничего что ФС уже и есть такая "БД"? :)
Торвальдс родился в 1969 и учился в конце 80-ых - начале 90-ых.
> Торвальдс родился в 1969 и учился в конце 80-ых - начале 90-ых.По вашим собственным меркам, он старый пeрдун.
> Грабли здесь в проверке наличия уже запущенного экземпляра приложения. В Линукс это
> принято делать, создавая пустой временный файл. Следуя этой логике дальше, протоколирование
> хода работы программы также осуществляется созданием и удалением пустых временных файлов.
> При перезапуске программы всех эти файлы нужно удалить. Небольшая ошибка -
> и удаляется ЗНАЧИТЕЛЬНО больше запланированного.[/var]/run — вполне себе неплохое соглашение, ещё со времён SysV.
Грабли подстерегали желающих управлять сервисами таким вот простым способом, но при чём тут ядро?Вопрос однозначно юзер-спейса. Его с переменным успехом решают в винде/соляре, построив целые минные поля /попробуйте настроить автоснапшоты с соляре/. Теперь вот и для Linux (systemd). И оно — пострашнее солярного, т.к. ломится в кернел. Ну хоть без xml пока (трижды сплёвываем).
>попробуйте настроить автоснапшоты с соляреОдна команда. Не понял в чём проблема?
> Одна команда. Не понял в чём проблема?В xml'ном расписании. Ниже - выдержка из небольшого конфига на 96 строк. Правда, легко читать </sarcasm>
<instance name='hourly' enabled='false' complete='true'>
<property_group name='zfs' type='application'>
<propval name='interval' type='astring' value='hours'/>
<propval name='keep' type='astring' value='23'/>
<propval name='period' type='astring' value='1'/>
</property_group>
<property_group name='general' type='framework'>
<propval name='action_authorization' type='astring' value='solaris.smf.manage.zfs-auto-snapshot'/>
<propval name='value_authorization' type='astring' value='solaris.smf.manage.zfs-auto-snapshot'/>
</property_group>
</instance>
К счастью, Поттеринг не любит XML, в отличие от санок и прочих огрызкопи...сов.
>но не сегодняPlan9? Не, не слышал!
> Грабли здесь в проверке наличия уже запущенного экземпляра приложения. В Линукс это принято делать, создавая пустой временный файл.Файл нужен чтобы знать, какому процессу посылать сигнал остановки. Начхать юниксам на запущенность приложения. Это чушь, придуманная леннартом, которую он с помпой выкатил в systemd. А когда его ткнули фейсом в лужу он начал помечать свои же эпичные изобретения как not recommended, и вроде даже посты на эту тему из своего блога убрал.
Есть две базовые операции: start и stop. Операция start проста - запустить прогу (хотя леннарт и тут умудрился накостылять). Со stop-ом сложнее - надо послать сигнал, но кому? Если у тебя БД и ты пошлёшь сигнал не тому процессу - можешь остаться без базы. И никто кроме самого приложения не знает, кому надо посылать сигнал. Пол века назад в юниксах нашли выход: приложение само записывает в файл pid процесса, которому надо посылать сигнал остановки. Всё.
Леннарт бы и сам понял, если бы не был таким дремучим nihовцем. Но теперь уже поздно, весь проект - коллекция костылей и подпорок ошибок леннарта. И что самое странное - даже после этого у него есть приспешники.
В наше время всегда побеждает наихудшее решение. ВСЕГДА.
> И что самое странное - даже после этого у него есть приспешники.Эксперимент третья волна, вот и все дела.
Грабли в том, что в операциях с FS нет DELETE_ON_EXIT без разыменования файла (что примечательно, в IPC всё точно наоборот).
Извините, а в редхате не принято запускать сервисы от непривилегированых пользователей? Достаточно же воткнуть в начале скриптаsu squidи проблема рассосется, как класс...
Не, не получится! Будет еррор тогда при рестарте в лог сыпаться, что пермишен денайд :)
Скакова?
> Не, не получится! Будет еррор тогда при рестарте в лог сыпаться, что
> пермишен денайд :)здрасьте, приехали. даже к портам <1024 можно привязывать процессы с non-root привилегиями, а уж отстроить разрешения на каталог - и вовсе как два пальца.
Сам сервис запускается от пользователя squid. Но в данном случае речь про обвязочный код; если вы не заметили, то раньше pid-файлы в /var/run можно было создавать и удалять только с правами рута, т.к. владелец /var/run - рут. Либо иметь там каталог от нужного пользователя, созданный при инсталляции пакета, но это требует специальной поддержки после переезда /var/run в tmpfs.И - знаю, меня жестко заминусуют за этот комментарий - но не могу отметить, что systemd решает *и эту* проблему. Концепция systemd-tmpfiles обеспечивает чтение конфига в /etc/tmpfiles.d/сервис и создание временных каталогов с нужными правами до запуска сервиса. Т.е. в таком случае при запуске сервиса автоматически был бы создан /var/run/squid с правами squid и тогда уже весь дальнейший код инициализации можно было бы выполнять с правами squid.
а что скрипт старта сервиса это не мог бы сделать ? так и было сделано всегда.
странно говорить о достижении systemd которое они подсмотрели в обычном sysv init..
> а что скрипт старта сервиса это не мог бы сделать ? так и было сделано всегда.Так он тут как раз так и делает :) С правами рута. Стирает pid-файл. С непредсказуемым эффектом.
В случае же systemd код с правами рута только создает стандартные каталоги/файлы согласно инструкциям из tmpfiles.d, а дальше код сервиса уже можно запускать от пользователя.
Впрочем, в случае сквида даже из systemd он запускается из под рута и меняет пользователя уже сам. Но тут уж ничего не поделаешь. Видимо, сам squid не рассчитан на запуск сразу из под непривилегированного пользователя.
>> а что скрипт старта сервиса это не мог бы сделать ? так и было сделано всегда.
> Так он тут как раз так и делает :) С правами рута.
> Стирает pid-файл. С непредсказуемым эффектом.
> В случае же systemd код с правами рута только создает стандартные каталоги/файлы
> согласно инструкциям из tmpfiles.d, а дальше код сервиса уже можно запускать
> от пользователя.еще раз - считается что так сделать нельзя? удивлю - так всегда и делали в приличном обществе.
скрипт запуска создавал каталоги - где вручную где используя mtree (?), после чего запускался демон и создавал нужные файлы.
Так делали, но это приводит к потенциальным проблемам типа возникшей тут.В случае systemd это больше не требуется, т.к. механизм tmpfiles позволяет создавать каталоги и прочее в момент запуска сервиса средствами systemd по декларативному описанию в конфиге. Напр.
$ cat /etc/tmpfiles.d/named.conf
d /run/named 0755 named named -Что, очевидно, безопаснее и меньше риска допустить ошибку.
> $ cat /etc/tmpfiles.d/named.conf
> d /run/named 0755 named named -
> Что, очевидно, безопаснее и меньше риска допустить ошибку.И кто помешает написать там:
> d $SQUID_PIDFILE_DIR 0755 named named -и получить те же грабли только в профиль?
Очевидно, что при декларативном синтаксисе - в отличии от bash-скрипта - очень просто проверить на ошибки и другие глупости. В tmpfiles.d глупости игнорируются (с логированием ошибки).http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html
Посмотрите http://fedoraproject.org/wiki/Packaging:Tmpfiles.d#Why_not_c... - причины перехода на единый механизм вполне понятны.
А для su требуется рутовый пароль. И при рестарте сервера он не загрузится, ибо "su же".
В общем, бред какой-то. И да, для управления сервисами нужен рут.
> А для su требуется рутовый парольВы, вероятно, удивитесь, но если скрипт запустить от рута, то выполнение в нем `su squid` не потребует никаких паролей.
Репортер предложил кривой патч, при этом он врёт, что
> > The "rm -rf $SQUID_PIDFILE_DIR/*" was already part if the original upstream script.И ответ мейнтейнера:
> As far as I see not anywhere in the git history, that means since 2004. I suspect you are using different sources than those from RHEL6.
Выводы?
>>are using different sources than those from RHEL6.
> Выводы?""Блу-алерт! В багзтле рх замечена контрафактная el6.7. рх пердуперждает: только аутентиная 7.1, только хардкор. Проверяйте цифровые подписи, чеки сохраняйте.""
Просто ещё одна иллюстрация почему systemd и декларативное описание инициализации рулят.
Его гнобят не за это.
И за это тоже, и за все, что "не так". Просто некоторые разработчики и админы чувствуют в нем угрозу обесценивания некоторых накопленных ими ранее знаний и опыта, воспринимая таким образом внедрение systemd, как атаку на себя лично.
Я тебе сейчас поведаю страшную тайну. Возня с инит скриптами это в среднем даже не 1% от времени сисадмина. Так что угроза существует разве что в воспаленном воображении детишек, мнящих себя умными только по причине следования за модой.
Даже если непосредственной возни 0.01%, понимание того, как это работает, нужно постоянно.Я не пытаюсь сказать, что все критики systemd неадекватны. Речь была о "некоторых", их отличает агрессивно-неконструктивный стиль комментариев, что явно указывает на личную задетость.
> Я тебе сейчас поведаю страшную тайну. Возня с инит скриптами это в
> среднем даже не 1% от времени сисадмина.А вот это очень зависит от админов и прочая. Какой нибудь аутсорсер или фрилансер может и не заниматься протягиванием витухи в ДЦ, а вот настройку серверов делать поточно-конвейерным методом. И вот там все эти заморочки с кучей левого кода, 10 лет назад написанного кулсисопом, после возлияний, на одном дыхании - даром не упали. Потому что окажется что кулсисоп 3 года назад уволился, а если б и не уволился - понятия не имеет что он там 10 лет назад написал, как следует буханув. Зато остальным когда встает вопрос понять что и почему не работает или где это переконфигурируется - совсем не прикольно.
> Зато остальным когда встает вопрос понять что
> и почему не работает или где это переконфигурируется - совсем не прикольно.И что, systemd еще и проблему с пьянством решает? Или с жадностью
работодателей и наймом школоты, не слыхавшей о документации работы?Бардак можно устроить и на реально декларативном языке, а уж на
той лапше что своим фанатам Леня навешал на уши - просто за милую душу.
> И что, systemd еще и проблему с пьянством решает? Или с жадностьюНет, конечно. Но он сделает все эти художества неудобными и нафигнужными. По поводу чего с ними сталкиваться придется сильно реже и только по делу. А это хорошо и правильно.
> работодателей и наймом шкoлоты, не слыхавшей о документации работы?
Удачи тебе в поиске документации на хотя-бы инит скрипты из состава дебиана.
> Бардак можно устроить и на реально декларативном языке
Можно все. Даже написать пухлый и тормозной код на ассемблере. Но это будет неудобно.
>> И что, systemd еще и проблему с пьянством решает? Или с жадностью
> Нет, конечно. Но он сделает все эти художества неудобными и нафигнужными.Так Вы все более напоминаете мне клоунов, которые разные "светозвзоры" рекламируют
бабулькам по проводному радио. Послушайте разок.Апологетов systemd конечно не так хочется придушить, как
этих, но... Имейте, в общем, меру. There is no one silver bullet.>> работодателей и наймом шкoлоты, не слыхавшей о документации работы?
> Удачи тебе в поиске документации на хотя-бы инит скрипты из состава дебиана.Я был удачлив, отыскав Debian Policy, LSB, man init и man sh для чтения
скриптов. Что помешало вам?>> Бардак можно устроить и на реально декларативном языке
> Можно все. Даже написать пухлый и тормозной код на ассемблере. Но это будет неудобно.Я фактически уверен, что именно на ассемблере вы сами напишете
именно пухлый и тормозной код. Или не напишете вовсе.Речь же была о другом - работа systemd ничуть не менее прозрачна для парней с улицы,
чем shell-скрипты. И то и другое требует обучения, причем еще неизвестно что
большего (я имею основания полагать что systemd).
> этих, но... Имейте, в общем, меру. There is no one silver bullet.Так я и не настаиваю на полном геноциде староверов. Сослать на Колыму^W какое-нибудь бояздэ и прочие свалки истории - и порядок. А лично меня задолбало костылить типовые грабли и операции которые давно должны были стать частью системы инициализации по моему мнению. Системд хорош тем что берет на себя туеву хучу не самых простых системных моментов, которые скриптами делать может быть криво, сложно и неудобно. И делает ряд вещей намного более логчино и менее коряво чем это делали в sysv init. Не говоря уж о избавлении меня от нужды смотреть в (чаще всего низкопробный) код, писаный по укурке, для всего лишь конфигурации.
> Я был удачлив, отыскав Debian Policy, LSB, man init и man sh
> для чтения скриптов. Что помешало вам?Нежелание копаться в низкопробном коде писаном левой пяткой, прежде всего. Кстати, LSB и прочие Debian Policy - поправят со временем, не сцы. А читать man init - затея бесполезная. Этот урезок нифига не умеет, даже многие вещи нужные в повседневном запиливании тривиальных сервисов в систему.
> Я фактически уверен, что именно на ассемблере вы сами напишете
> именно пухлый и тормозной код. Или не напишете вовсе.Обломись, я как раз умею довольно неплохо шпарить на ассемблере нескольких архитектур (но не х86). Кроме всего прочего - я как-то втискивался в 256 байтов кода на все и вся. Когда сможешь так же - мы так и быть вернемся к разговору о твоих убеждениях.
> Речь же была о другом - работа systemd ничуть не менее прозрачна
> для парней с улицы, чем shell-скрипты.Хорошая опечатка - доставляет. Тем что со мной не пытается спорить, в силу логической ошибки :). Она не только не менее прозрачна, но и более прозрачно. Потому что компактный конфиг на несколько строк изучить проще чем черти-какой код на три страницы, с хзкакой логикой впиханой неизвестно зачем, just because they can. Теперь "can" будет несколько менее комфортно и чуть более костыльно. Какой-никакой барьер на пути ж@поруких скриптокидозников и вообще, они будут в два счета обнаруживать себя и из нормальных мест типа репок дистров, больших инсталляций и прочая - их как раз уйдут.
> И то и другое требует обучения, причем еще неизвестно что
> большего (я имею основания полагать что systemd).Хз, мне он нравится - весьма логично маппится на мои типовые задачи и хотелки, а когда мне что-то надо, есть 99% вероятности что он это умеет и мне не придется колхозить костыли из соплей из скотча на очередную казалось бы такую очевидную фичу. По поводу чего я запилю типовой сервис в систему за пару минут. А если что пойдет не так - у меня будет по крайней мере вывод программы и какой-никакой логгинг. И в самих прогрмамах будет меньше левых приседаний типа извращений с несколькими форками и что там еще.
>> этих, но... Имейте, в общем, меру. There is no one silver bullet.
> Так я и не настаиваю на полном геноциде староверов.Ну еще-б впариватели разной "живой воды" на геноциде настаивали.
>> Я был удачлив, отыскав Debian Policy, LSB, man init и man sh
>> для чтения скриптов. Что помешало вам?
> Нежелание копаться в низкопробном коде писаном левой пяткойЦитированное выше - вполне прилично написанная документация, а не низкопробный
код. Что касается качества кода скриптов - ведь что-то мне подсказывает, что
в багтрекере Debian вы по этому поводу не наследили, нет?>> Я фактически уверен, что именно на ассемблере вы сами напишете
>> именно пухлый и тормозной код. Или не напишете вовсе.
> Обломись, я как раз умею довольно неплохо шпарить на ассемблереНу нашпарьте мне Mathematica на ассемблере, а я погляжу.
>> Речь же была о другом - работа systemd ничуть не менее прозрачна
>> для парней с улицы, чем shell-скрипты.
> Хорошая опечатка - доставляет. Тем что со мной не пытается спорить, в
> силу логической ошибки :). Она не только не менее прозрачна, но
> и более прозрачно.Она не опечатка, она ирония;)
Я про то, что для "парней с улицы" - разницы нет. Разве для работодателя будет только
хуже, если у них еще и появятся иллюзии на тему собственной крутости.> Потому что компактный конфиг на несколько строк изучить
> проще чем черти-какой код на три страницы, с хзкакой логикой впиханой
> неизвестно зачем, just because they can.Отнюдь. Когда понадобится залезть немножко под капот и понять как работают
эти самые "несколько строк" - тремя страницами документации дело не ограничится.Systemd умеет несколько больше sysvinit, далеко не самым самоочевидным, простым
и структурированным образом. Логику среднего дебиановского init-скрипта - на самом
деле как раз куда проще понять постороннему.> Какой-никакой барьер на пути ж@поруких скриптокидозников
> и вообще, они будут в два счета обнаруживать себя и из
> нормальных мест типа репок дистров, больших инсталляций и прочая - их
> как раз уйдут.Напротив, как раз они и останутся.
>> И то и другое требует обучения, причем еще неизвестно что
>> большего (я имею основания полагать что systemd).
> Хз, мне он нравится - весьма логично маппится на мои типовые задачи и хотелкиНу вот. Вам нравится, а мне для отладки процесса загрузки до недавнего
времени вспоминать про gdb не приходилось.> И в самих прогрмамах будет
> меньше левых приседаний типа извращений с несколькими форками и что там еще.Потому что Леня сказал что писать кроссплатформенный софт - не кулл?
> Просто ещё одна иллюстрация..на тему, что продажи 7го EL-а не идут.
> почему systemd и
Декларативное описание - рулит (как минимум, пока не объявляется единственно верным и даёт легко отскочить на императив где надо). Но вот его реализация в systemd - не рулит ни разу - ни в алне архитектурных решений, ни в плане кода (см. пример с strcpy выше).А вообще - полагаю, что всерьёз рулил бы как раз императив на более вменяемом языке, чем шелл, и с хорошей библиотекой функций для этого дела. Собственно, для пльзователя могло бы быть всё так же просто, как и сейчас, просто 9/10 обработки директив из юните выполнялось бы доступными администратору и отлаживаемыми скриптами на каком-нибудь Lua, лежащими в /lib/XXX. Заодно была бы возможность смотреть, что люди пишут дополнительно и востребованное вносить в состав софтины. В общем, одни плюсы. Плагинная архитектура - она всегда рулит.
А что SysV как-то запрещает писать init скрипты на любом языке?
Ну вот например модуль для их создания на perl: https://metacpan.org/pod/Daemon::Control
Конечно не запрещает. Но по факту используется только шелл. Что логично - зоопарк здесь не нужен, но, с другой стороны, шелл уж больно уродлив и провоцирует кучу ошибок (что мы здесь и видим). Это во-первых.Во-вторых - инит должен предоставлять скриптам некий стандартный сервис - хоть работу с PID ту же, хоть события/зависимости, хоть ещё что. Это довольно неудобно делать, если движок скриптов не встроен в сам инит и практически невозможно - если таки использовать много языков.
В-третьих - базовыые вещи вроде start/stop/restart со статически забитыми параметрами, зависимостей и т.п. всё-таки не должны требовать скриптов, здесь деклараций - более чем достаточно.
> Конечно не запрещает. Но по факту используется только шелл. Что логично -
> зоопарк здесь не нужен, но, с другой стороны, шелл уж больно
> уродлив и провоцирует кучу ошибок (что мы здесь и видим). Это
> во-первых.Уродлив не шелл, а такие писаки - вроде тебя - которые всех тонкостей не знают, но лезут писать скрипты.
> Во-вторых - инит должен предоставлять скриптам некий стандартный сервис - хоть работу
> с PID ту же, хоть события/зависимости, хоть ещё что. Это довольно
> неудобно делать, если движок скриптов не встроен в сам инит и
> практически невозможно - если таки использовать много языков.Ты не поверишь - в нормальных системах так и есть.
> В-третьих - базовыые вещи вроде start/stop/restart со статически забитыми параметрами,
> зависимостей и т.п. всё-таки не должны требовать скриптов, здесь деклараций -
> более чем достаточно.Тю? И разные таймауты, и отработка депендентов, и рестарты, и мэйнтайненс сервисов? Ты, случайно, не видел, как оно в нормальных системах нормальными разработчиками сделано?
> Уродлив не шелл, а такие писаки - вроде тебя - которые всех
> тонкостей не знают, но лезут писать скрипты.1. Shell устарел - в нём нет простой арифметики, проверки типов, алгебраических типов. С другой стороны, есть совершенно необходимая фича, присущая только Haskell'у и подобным - ленивость исполнения конвееров.
2. Как несложно заметить, чем меньше тонкостей в языке, тем лучше - очередной C++ нам не нужен.
> 1. Shell устарел - в нём нет простой арифметики, проверки типов, алгебраических
> типов. С другой стороны, есть совершенно необходимая фича, присущая только Haskell'у
> и подобным - ленивость исполнения конвееров.Да, все это крайне необходимо в системе инициализации. Чтобы Вася мог с перепоя такого накодить что потом даже академики из РАН не смогут понять где он параметры для запуска прописал.
> очередной C++ нам не нужен.
Вот именно поэтому там и будут конфиги, из которых скрипты будут звать только если ну очень надо. Вызывать на каждый сцаный сервер академиков из РАН - дурь несусветная.
> Да, все это крайне необходимо в системе инициализации.Это нужно для замены bash'а.
> Это нужно для замены bash'а.Bash изначально - инструмент для генерации примитивного glue code между сишными тулсами, когда надо "чуть больше чем просто пайп". Это не средство наворачивания бизнес-аналитики, серьезного программирования и что там еще.
> и мэйнтайненс сервисов?Про мейнатансе сервизов охота услышать. Можно поподробнее как там нагрузку базы определяете и если что переезжаете на амазоновское облако. Ключики какие в системд на этот счёт? Ну или попроще что - на манер забикса-нагиоса там есть в системд?
> Ключики какие в системд на этот счёт?<sarcasm>Всё, чего нет в systemd, не нужно.</sarcasm>
> <sarcasm>Всё, чего нет в systemd, не нужно.</sarcasm>Не, не так. Вот пусть такое и кодят под кастомные требования. А запуск какого-нибудь мелкого проксика скриптом весом в половину исходников оного - нафин надо!
> А что SysV как-то запрещает писать init скрипты на любом языке?
> Ну вот например модуль для их создания на perl: https://metacpan.org/pod/Daemon::ControlДа, зашибись. А потом надо вон тот сервер перенастроить - ОПА! А там возьми и окажись брейнфак. Потому что прошлый админ любил лулзы и хотел проучить работодателя и вообще, не считал что в его творчестве должно быть просто разобраться. Теперь такое художество придется внятно обосновывать, а не лепить что попало где не надо.
В системд можно скрипт исполнить из юнита?
> В системд можно скрипт исполнить из юнита?Из юнита можно выполнять программы. В том числе можно и ваш внешний скрипт позвать, разумеется. Только в случае systemd - это на правах костыля, если очень надо. А не как дефолтное вбивание гвоздей микроскопом.
То есть в сисвинит можно скрипты писать на любом языке. И админ обязательно напишет на брейнфаке 5 кило портянок назло руководству. А в системд можно выполнить любую программу, но никто и никогда не будет ничего писать на брейнфаке и вызывать из юнитов.
Я правильно всё понял, ничего не упустил?
> А вообще - полагаю, что всерьёз рулил бы как раз императив
> на более вменяемом языке, чем шелл, и с хорошей библиотекой функций
> для этого дела.Я не знаю такого языка. :-( Реально нужен микс из OCaml'а и Haskell'а - статическая типизация, максимально простая, лёгкая императивщина + модульность + возможность лёгкой ленивости (вместо конвееров). Плюс, возможность предварительной компиляции (если скорость нужна).
> Реально нужен микс из OCaml'а и Haskell'аКому нужен - тот пусть этим и занимается. Флаг ему в руки и барабан на шею.
такого рода косяки - обычное дело для тестовых сборок. где-то они мелкие, где-то катастрофичные. ничего такого, из-за чего анонимам стоит биться в истерике
> rm -rf $SQUID_PIDFILE_DIR/*Такая строчка — бомба замедленного действия. Все-таки sh страшный язык. Удобный, но страшный.
> Такая строчка — бомба замедленного действия. Все-таки sh страшный язык. Удобный, но страшный.Будто бы написанная в systemd-блобе в виде strcpy(stpcpy(stpcpy(execcmd, "rm -rf "), getenv("SQUID_PIDFILE_DIR")), "/*") или где угодно на другом языке она была бы безопаснее...
Не знаю, как это написано в systemd (не о нем речь), но конструировать сложные объекты (будь то пути, запросы, веб-страницы или что-то еще) путем конкатенации или подстановки строк неправильно и опасно (по крайней мере, когда речь идет не о сиюминутных скриптах, а о коде, который поддерживается долго). Язык должен предоставлять необходимые абстракции (в этом и заключается смысл ЯП: предоставление абстракций и средств для их построения).Ну вот пример (Racket):
(build-path "a" "b" "c")
#<path:a/b/c>(build-path "a" "/b" "c")
build-path: absolute path cannot be added to a path(build-path "" "b" "c")
build-path: path element is an empty string
>> rm -rf $SQUID_PIDFILE_DIR/*
> Такая строчка — бомба замедленного действия. Все-таки sh страшный язык. Удобный,
> но страшный.Страшен не шелл. Страшны недоучки и недоумки, которые со встроенным в башке noscript родились.
Практически невозможно никогда не допускать ошибок в коде. А вот своевременное выявление ошибок и ограничение их последствий должно обеспечиваться языком, системой и процедурами тестирования (здесь последние сработало, т. к. ошибка выявлена в тестовом выпуске).
> Страшен не шелл. Страшны недоучки и недоумки, которые со встроенным в башке
> noscript родились.Так скрипты инициализации какие-то такие и пишут в основном. Так. если на код глянуть.
Тесты интеграции не проводят чуть более, чем совсем. Любой залетевший дятел сможет учинить армагеддон в данном дистрибутиве. Теперь нет никаких сомнений в полезности раздробленности GNU/Linux и в экосистеме отличающихся дистрибутивов - локальные армагеддоны страшны только их почитателям.
> Тесты интеграции не проводят чуть более, чем совсем.Проблему отловили *в тестовом выпуске* до релиза, попрошу заметить.
>> Тесты интеграции не проводят чуть более, чем совсем.
> Проблему отловили *в тестовом выпуске* до релиза, попрошу заметить.Настоящие чукчи новость не читают :)
так этоже ентерпрайз, и деньги улители и файлы с ними
Можно подумать, что бsdуны их проводят.В портах три месяца лежала квагга, с поломанными правами на директорию логов - и после перезапуска, роутер превращался в тыкву, несмотря на ватчдог самой квагги.
Аналогично - для кеша того же сквида. Проблема усугубляется тем, что он не уходит в бэкграунд до полной инициализации своего кэша и вешает наxер ВЕСЬ процесс загрузки. и притом он стартует ДО ssh.
И не надо пенять на инит - это конкретно рукожопие мейнтейнеров.
Ну ты и врун 8-) Детская ещё еравма видимо ...
А канделябром не желаете?http://svnweb.freebsd.org/ports/head/net/quagga/pkg-plist?r1...
Я знал, я знал )))
что бздя кривая, но чтоб настолько o_O
А мне ещё не верили, что она в консоль вываливается после 2-3 миганий света и требует руками фиксить ФС.
Кстати, кэш у сквида тогда тоже побился, спасибо что напомнили. Ждать пока он его проинициализирует надо было несколько минут.
> раздробленности GNU/LinuxНичего страшного, Леннарт и Ко. работают над устранением этой "проблемы".
>>GNU/Linux
>Леннарт и Ко. работают над устранением этой "проблемы".Только одной из двух??
а это не проделки того-кого-нальзя-называть-в-приличном-обществе?
Да похоже на то. Придумал себе псевдоним Fernando Lozano и запостил патчик, чтобы дискредитировать sysv. Я не совсем понял только как он смог преодалеть возражение мейнтейнера на то, что там такой переменной никогда не было.
запилят rmrfd ?
> запилят rmrfd ?модулем ядра
Сначала по заголовку думал что труба, но из содержимого все стало ясно. С одной стороны - в продакшене не будешь рисковать и ставить тестинг, а с другой - очень тупая ошибка для рхел.
Вообще - весьма круто. Достойно "поколения UnDo" - не проверять, не думать - только пробовать...
Неужели это за пределами человеческого разума предугадать что будет происходить при отсутствии переменной?
Или просто не модно стало думать прежде, чем запускать?
У меня / ro, правда /home я теряю в этом случае :-)
> У меня / ro, правда /home я теряю в этом случае :-)А я откачу снапшот за 20 секунд и как будто ничего и не бывало. Мне так больше нравится.
А кто может сказать что хранится в /var/run/squid?
Никогда не пользовался squid и нет возможности глянуть.
Потому как такое удаление вызывает недоумение.При запуске проверяется, что эта директория существует и создается при необходимости. При остановке же видим что удаляется ее все содержимое.
Почему просто не удалить всю папку при остановке и создать заново при запуске.
Зачем закладывать такие мины? Даже если бы это было просто rm -rf $SQUID_PIDFILE_DIR, то при запуске скрипт ее все равно создал.Более того не понятно зачем вообще использовать эту переменную? Неужели кому-то понадобится перенести эту директорию в другое место?
В том же скрипте видим что файл вывода /var/log/squid/squid.out задан явно без всяких переменных. Но вынести это в переменную было бы куда логичнее, потому как встречается там 3 раза, в отличие от /var/run/squid.
Да они там укуренные просто. Ему говорят - нету в нашем скрипте такого! А он - есть, есть, сам видел, давайте в продакшн!
> Да они там укуренные просто.Так другие скрипты почти и не пишут - считают ниже своего достоинства.
> А кто может сказать что хранится в /var/run/squid?
> Никогда не пользовался squid и нет возможности глянуть.
> Потому как такое удаление вызывает недоумение.Ничего, нет такого каталога. Это ошибка. В RHEL squid хранит свой pid в /var/run/squid.pid (во всяком случае, в EL6 и EL7).
Раз любители системд уже непонятные баги притаскивают из нерелизнутых пакетов, то можно и им шпилю воткнуть. Вот у человека проблема с обсуждением vitus-wagner.livejournal.com/1071323.html . И системд тут конечно не при чём.
А что политики SELinux для Squida никакой нет что-ли?
> А что политики SELinux для Squida никакой нет что-ли?Так это не Squid. Это "запуск Squid". Делается системой инициализации, под рутом. И прописывать системе инициализации политики за...шься, потому что там настройки меняют относительно часто и каждый раз еще и политики SELinux переписывать - большинство админов труба шатали.
На самом деле, нет явной проблемы с таким прописыванием (почему это нельзя ограничить то, что может скрипт запуска *конкретного* сервиса?). Просто раньше это было бы неудобно делать, т.к. при запуске bash-скрипта устанавливать контекст selinux несколько проблематично: в случае запуска /etc/init.d/squid, /usr/sbin/service squid и запуска этого скрипта из начального init'а контексты на сам скрипт были бы разные.В 7-ке systemd решил эту проблему, он знает про контексты selinux и устанавливает их для конкретного сервиса, выполняя команды из unit-файла в этом контексте. И теперь есть возможность ограничить то, что может делать инициализация конкретного сервиса.
См. https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
Да ладно, в линуксах это норма, взять хотя бы xargs:find / -type d -iname '*tmp' | xargs rm -rf
Что будет, если ни одной директории найдено не будет :) ?
> Да ладно, в линуксах это норма, взять хотя бы xargs:
> find / -type d -iname '*tmp' | xargs rm -rf
> Что будет, если ни одной директории найдено не будет :) ?Надо для ключа -rf требовать ввод пароля руками, да всего делов. Но это не труЪ, поэтому софтостроители будут наступать на грабли года так до 2050го.
А ещё лучше всё, что удалено через rf складывать в снапшот и по команде undelete откатывать всё обратно.
> Надо для ключа -rf требовать ввод пароля руками, да всего делов. НоИ на shell-globbing, обязательно! А rm _вообще только по паспорту.
> до 2050го.
> А ещё лучше всё, что удалено через rf складывать в снапшот и
> Надо для ключа -rf требовать ввод пароля руками, да всего делов. НоВообще-то претензии были именно к xargs, поскольку у нее есть опция
--no-run-if-empty
-r If the standard input does not contain any nonblanks, do not run the command. Nor‐
mally, the command is run once even if there is no input. This option is a GNU ex‐
tension.Но по логике вещей она должна быть по умолчанию, вернее по умолчаню если на xargs ничего не подается, то он ничего не должен запускать, но при этом, для извращенцев должна быть опция --run-if-empty
>[оверквотинг удален]
> run the command. Nor‐
>
> mally, the command is run once even if there
> is no input. This option is a GNU ex‐
>
> tension.
>
Безотносительно этого зловещего флага, ты своей командой 'find / -type d -iname '*tmp' | xargs rm -rf' можешь снести любые файлы при благоприятных обстоятельствах.
> Да ладно, в линуксах это норма, взять хотя бы xargs:
> find / -type d -iname '*tmp' | xargs rm -rf
> Что будет, если ни одной директории найдено не будет :) ?В этом случае ничего не будет, попробуй еще.
Команда рискованная, но по другой причине.
Думаю, сначала надо cd $SQUID_PIDFILE_DIR делать, а потом, по коду возврата, принимать решение насчет rm.