В pacman 3.6 запилят подписи пакетов.

>Ой не всегда, не всегда

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

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

>У арчеводов излишне раздутое ЧСВ. Пользуются бинарным дистрибутивом с неподписанными пакетами

Только трояны почему-то подсовывают дебианщикам, а не арчеводам. :)

>Трололо. У гнома конфиг XML-ный.

У третьего будет бинарный. man dconf

В ряде дистрибутивов после апдейта приходится всего лишь переустанавливать систему:)

я понял, что затронул больную для пользователей арча тему

Ну на самом деле ты отчасти прав. Примерно 70-80% вопросов по арчу в arch@c.j.r была вида 'ОБОЖЕМОЙГНОМУПАЛФЛЭШКАНЕМОНТИРУЕТСЯЧТОТАКОЕЛОГИ111111".

Трололо. У гнома конфиг XML-ный.

Есть сообщения, шо уже нет. В 3.0 все в бинарном конфиге, который будет редактироваться regedi^W dconf.exe.

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

> Только трояны почему-то подсовывают дебианщикам, а не арчеводам. :)

арчеводам

Да кому нужна эта красноглазая молодежь? Что у них красть? Серии Наруто?

>Что у них красть? Серии Наруто?

Ви таки всерьёз полагаете, что трояны пишут только для того, чтобы что-то украсть? :)

А что еще? Этих дуалбутчиков все равно в ботнет не возьмешь, да и бота-то подсадить трудновато: обычно там ничего не работает толком.

Круто.

А вы наивно полагаете, что вы один администратор в системе? Что произойдёт, если этой вашей наной два администратора одновременно отредактируют какой-нибудь /etc/passwd? Ну или вспомните волшебную фишку то ли XFS, то ли ext4 в раннем этапе, когда при сбое все файлы, открытые на rw, обнулялись

администратор в системе у меня один - я. больше никто от рута пароля не знает и знать не должен, у нас тут серьёзные *nix а не бордель. держите рут на тестовых ФС? ССЗБ. что тут ещё сказать?

>В ряде дистрибутивов после апдейта приходится всего лишь переустанавливать систему:)

Каких, например? Debian, Ubuntu, Fedora, PCLinuxOS...Почаще арча приходилось. Единственное, с чем не было проблем - Pardus, но он настолько ущербен, что там вроде как нельзя обновить версию дистрибутива (я не нашел, по крайней мере).

А причем здесь рут? В курсе, что бывает role-based access? Под рутом в общем случае вообще входить не надо

В общем, дядя. Сдаётся мне, что «серьёзных *nix» вы не нюхали. Предлагаю закрыть тему

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

> Ну или вспомните волшебную фишку то ли XFS, то ли ext4 в раннем этапе, когда при сбое все файлы, открытые на rw, обнулялись

1. Используемый вами редактор до сих пор не осилил создание резервных копий?
2. Какой недоумок станет держать боевой сервер или даже просто рабочую машину на экспериментальной ФС?

> В курсе, что бывает role-based access?

А вы в курсе, для чего существуют *.d каталоги?

Под рутом в общем случае вообще входить не надо

Ололо. Чтобы изменить файл, на который права записи есть только у рута, необходим процесс с EUID рута. Каким образом этот EUID получен, вообще не важно. Или вы думаете, что права на запись система через астрал определяет?

Эт да, сделай мне зашибись

Болдженосы рулят пока. Пока человек не поймёт, что преимущество *nix в shell, говорить с ним не о чем. Все беды популяризаторов опенсорца идут от заигрывания с адептами-мышевозами. Ах, как просто, нажми на кнопку, получишь...

Гхммм

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

То есть вы не сталкивались с ситуациями, когда некоторой системой управляет 2 и более администраторов, причём у некоторых есть заместители?

Предохранение от нехороших ситуаций, даже от тех, шанс возникновения которых мал - признак хорошего тона

1. Как резервная копия спасёт от обнулённого /etc/passwd? Загрузка с livecd не считается, прострел в ноге я тоже могу скотчем заклеить

2. ext4 вполне себе production-ready. Об этом заявили разработчики, даже redhat в 5.4 (кажется) из статуса TP её вывел

А какое отношение каталоги *.d имеют к созданию копии файла и предотвращению множественного доступа? Или уже появился /etc/passwd.d?

И одно дело, когда EUID получен для выполнения одного действия, и совсем другое, когда этот EUID сохраняется на всём протяжении сеанса работы с системой

В винде есть powershell который может очень многое из того, что в bash будет делаться феерическими костылями. И зачем ваш этот *nix теперь нужен, кроме как для бесплатного запускания компиза и апача с похапе?

таблетки от счастья

mplayer http://tempfile.ru/download/fde4154064f0489a0af2a1865cafec65

Ну или вспомните волшебную фишку то ли XFS, то ли ext4 в раннем этапе, когда при сбое все файлы, открытые на rw, обнулялись

ext4 вполне себе production-ready. Об этом заявили разработчики, даже redhat в 5.4 (кажется) из статуса TP её вывел

Дели на ноль дальше.

Ты сам невменяемый. visudo, vipw, vigr - утилиты, которые с помощью того, что у тебя в $EDITOR, откроют тебе КОПИЮ соответствующего файла для редактирования, и после редактирования сохранят её в качестве основного. Эти утилиты позволяют обеспечить консистентность системных файлов, без которых твоя система не загрузится, на случай сбоя (например, пропажи питания).

Ну или вспомните волшебную фишку то ли XFS, то ли ext4 в раннем этапе, когда при сбое все файлы, открытые на rw, обнулялись

Как резервная копия спасёт от обнулённого /etc/passwd?

Лучше расскажи, как «специальные утилиты, позволяющие обеспечить консистентность системных файлов» спасут тебя от обнуленного /etc/passwd. Мы послушаем внимательно.

Давай рассмотрим 2 сценария:

vipw:

0. создание блокировки на файл

1. создание копии файла

2. открытие копии на rw

3. изменение в копии

4. переименование копии в оригинал

vim действует практически аналогично, только у него копия называется swap-файлом

А вот как в случае nano:

1. открытие оригинала на rw

2. изменение в оригинале

3. сохранение оригинала

В vipw сбой может повредить оригинал в течение только последнего действия. В nano - обнулить в любой момент. Разница ясна? Кроме того, nano не блокирует повторный доступ к файлу. Насколько невероятной является ситуация, когда один пользователь редактирует /etc/passwd (хотя какого хрена он это вообще руками делает?), а второму пользователю приспичило открыть /etc/passwd на чтение?

Так что поумерь сарказм. В man не просто так написано «лучше использовать vipw»

Шлангование заканчиваем.

Ну или вспомните волшебную фишку то ли XFS, то ли ext4 в раннем этапе, когда при сбое все файлы, открытые на rw, обнулялись

Ваши слова? Ваши. Вот и рассказывайте, чем ext4 в «специальных утилитах» отличается от ext4 в nano.

открытие оригинала на rw

изменение в оригинале

В vipw сбой может повредить оригинал в течение только последнего действия. В nano - обнулить в любой момент.

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

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

Где ты вычитал, мудрец, чтобы я говорил о том, что все изменения сразу фиксируются на диске?

Ещё раз, для особо упорных:

vim:

copy(«/etc/passwd»,«/etc/passwd.swap»);

open(«/etc/passwd.swap»,«w»);

write(«/etc/passwd.swap»);

move(«/etc/passwd.swap»,«/etc/passwd»);

unlink(«/etc/passwd.swap»);

nano:

open(«/etc/passwd»,«w»);

write(«/etc/passwd»);

close(«/etc/passwd»);

В виме файл-оригинал уязвим для всевозможных проблем только в момент move. В нане - от момента open до момента close. Окно уязвимости шире. Ты это понимаешь?

И не забывай, не забывай про организацию монопольного доступа при использовании vi{pw,gr,sudo}

Хм, заглянул в /proc/ХХХХ/fd. Похоже, нана поумнела и работает с содержимым файла в памяти. Правда, тогда непонятно, как она работает с громадными файлами.

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

Создаю файл размером в 10G. Памяти 2G. Посмотрим, как тут поступит нана

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

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

vim, похоже, делает mmap. VIRT растёт, а RSS нет

В fd:

lr-x------ 1 hc hc 64 Апр 3 18:15 3 -> /home/hc/zero

lrwx------ 1 hc hc 64 Апр 3 18:15 4 -> /home/hc/.zero.swp

vim не открывает файл на запись при открытии. Точка. Вот и разница между ними

lr-x------ 1 hc hc 64 Апр 3 18:17 3 -> /home/hc/zero

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

Но обеспечение монопольного доступа никуда не делось

> Наблюдаю дальше

Вот и еще один человек, не знающий, что существуют исходники.

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

vim не открывает файл на запись при открытии. Точка. Вот и разница между ними

Нано, оказывается, тоже не открывает файл на запись.

Я даже говорить ничего не буду.

Я администратор, а не программист. Мне намного быстрее залезть в /proc, чем качать исходники и разбираться в них. Применяемый инструмент в данном случае дела не меняет.

Потому что ты по-прежнему ничего не можешь сказать про обеспечение монопольного доступа. Можешь и не говорить - vim и vi{pw,gr,sudo} проверяют открытость файла, nano - нет. Я проверял, да и, собственно, обследование /proc о том же говорит

> Я администратор

vim и vi{pw,gr,sudo} проверяют открытость файла

Администратор, смешивающий в кучу блокировки, «открытость файла» и swp-файлы вима.

Интересно, что помешает тому «второму админу с правами рута» править в этот же момент файл в nano или просто сделать bla-bla > filename. Не говоря уж, что файл не обязательно доступен в системе по одному имени, и спокойно можно открыть файл в двух копиях vim по разным путям.

Мне намного быстрее залезть в /proc

Администратор, не знающий о существовании ltrace.

Вот такие нынче администраторы.

Зачем, если есть yast?

Смешно:)

То есть ты по-прежнему сомневаешься, что nano не проверяет файл на открытость? Ради интереса открой файл в виме, а потом открой его ещё раз в виме. Посмотри на результат. После этого сделай export $EDITOR=vim; vipw а из другого места - vim /etc/passwd. И удивись ещё раз.

И эта: у тебя /etc/passwd доступен в системе более, чем по одному имени? Если не секрет, зачем? Мне в голову только chroot приходит. В случае /etc/sudoers всё ещё более непонятно.

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

И ответь на вопрос: если у твоих администраторов принято редактировать /etc/passwd в nano - как они отслеживают, что их коллега тоже открыл /etc/passwd?

Ну или можешь продолжать картинно разводить руками, призывая «людей добрых»

> Ради интереса открой файл в виме, а потом открой его ещё раз в виме.

Открой файл в виме, а потом запусти еще один терминал и открой файл в nano.

А чтобы тебя окончательно добить: я ещё и курс ОС веду у себя на кафедре.

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

И прекрасно понимаю разницу между блокировкой, открытием файла с своп-файлом вима.

Так же прекрасно, как разбираетесь в прочей работе с файлами?

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

vim не открывает файл на запись при открытии. Точка. Вот и разница между ними

Нано, оказывается, тоже не открывает файл на запись.