Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 192
О да, я суровый unix-админ, хотя не админю уже много лет :)
Программеры — они толстые. Потому что они сидят. А админы — они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Hо не надо думать, что это исключение из правил — это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры.
Программеры курят быстро, потому что мысль. Потому что она уйдет и придется думать ее снова. У админов мыслей нет, поэтому они курят медленно. Они делают это в те моменты, когда все работает и ничего не падает. Поэтому они курят редко.
Программеры ходят на обед сами. Они приносят много еды в офис и вкусно ей пахнут. Они едят ее прямо на клаве. Потому что мысль. Админы заказывают еду в офис. Потому что если они за ней пойдут, что-нибудь упадет. И придется бежать в офис с недоеденным гамбургером. Потому что админы любят питаться от Макдональдса. Потому что вкусно, а потолстеть им не грозит. Если они не обленившиеся программеры.
Программеры уходят с работы ночью. Потому что мысль. Hекоторые из них уходят вечером и думают мысль дома. Hекоторые, у которых есть ноутбук, думают ее в метро. Админы домой не ходят. Потому что если они пойдут домой, что-нибудь упадет. И придется идти на работу. А на работу они ходить не любят. И не ходят. Они там живут. У них обычно есть отдельное гнездо за отдельной дверью, часто запираемой на отдельный замок.
Программеры спят в выходной. Обычно это среда или понедельник. Потому что мысль. В понедельник мысли еще нет. А в среду идет переход от одной мысли к другой. Админы спят в гнезде. Из-за отдельтного замка в это время иногда раздается храп. Админы редко спят больше десяти минут. Потому что если проспать больше, что-нибудь упадет. И придется просыпаться по необходимости. А админы любят просыпаться сами, пусть и через десять минут.
Программеры пьют пиво. В основном светлое и много. Потому что мысль. Пока она плавает — ее можно думать. Главное, чтобы не утонула. Админы тоже пьют пиво. Потому что если что-нибудь упадет, им будет пофиг. Админы любят когда им пофиг. И программеры любят, когда им пофиг. Поэтому часто они пьют пиво вместе. И им вместе пофиг. После этого они спят. Hо не вместе. Админы спят в гнезде, а программеры — на клаве. Когда они просыпаются, они снова пьют пиво. Потому что хочется. Потому что они админы. И программеры.
Программеры курят быстро, потому что мысль. Потому что она уйдет и придется думать ее снова. У админов мыслей нет, поэтому они курят медленно. Они делают это в те моменты, когда все работает и ничего не падает. Поэтому они курят редко.
Программеры ходят на обед сами. Они приносят много еды в офис и вкусно ей пахнут. Они едят ее прямо на клаве. Потому что мысль. Админы заказывают еду в офис. Потому что если они за ней пойдут, что-нибудь упадет. И придется бежать в офис с недоеденным гамбургером. Потому что админы любят питаться от Макдональдса. Потому что вкусно, а потолстеть им не грозит. Если они не обленившиеся программеры.
Программеры уходят с работы ночью. Потому что мысль. Hекоторые из них уходят вечером и думают мысль дома. Hекоторые, у которых есть ноутбук, думают ее в метро. Админы домой не ходят. Потому что если они пойдут домой, что-нибудь упадет. И придется идти на работу. А на работу они ходить не любят. И не ходят. Они там живут. У них обычно есть отдельное гнездо за отдельной дверью, часто запираемой на отдельный замок.
Программеры спят в выходной. Обычно это среда или понедельник. Потому что мысль. В понедельник мысли еще нет. А в среду идет переход от одной мысли к другой. Админы спят в гнезде. Из-за отдельтного замка в это время иногда раздается храп. Админы редко спят больше десяти минут. Потому что если проспать больше, что-нибудь упадет. И придется просыпаться по необходимости. А админы любят просыпаться сами, пусть и через десять минут.
Программеры пьют пиво. В основном светлое и много. Потому что мысль. Пока она плавает — ее можно думать. Главное, чтобы не утонула. Админы тоже пьют пиво. Потому что если что-нибудь упадет, им будет пофиг. Админы любят когда им пофиг. И программеры любят, когда им пофиг. Поэтому часто они пьют пиво вместе. И им вместе пофиг. После этого они спят. Hо не вместе. Админы спят в гнезде, а программеры — на клаве. Когда они просыпаются, они снова пьют пиво. Потому что хочется. Потому что они админы. И программеры.
удалено
По поводу толщины админов
Это лучший коммент, который я читал на хабре.Да, я когда это лет 15 назад прочитал тоже хохотал)
Ага. И хотя шутка весьма плоская, но как же хорошо она подана стилистически!
Ведь и даже этот топик можно же было перевести по-сути, а не по содержанию:
> Когда решение проблемы требует от нас множества повторяющихся рутинных действий, то мы всегда предпочтем написать код, который это сделает. Обычно это занимает меньше времени, нежели рукопашный метод, но не всегда. Все равно, мы скорее займемся созданием того, что мы можем использовать повторно потом, нежели будем решать проблему здесь и сейчас. Обычно это пригождается потом, через несколько лет, когда мы встречаем схожую проблему и можем вытащить из рукава несколько сотен строчек кода на Perl, лежащих в нашей домашней директории, решить проблему за несколько минут и вернуться к улучшению нашего кода. Или к незаконченному на три звезды уровню в Angry Birds.
Админ не делает рутину. Рутину делает скрипт. И даже если написание скрипта займет больше времени, чем нужно на рутину, админ все равно будет делать скрипт. Потому что админ не делает рутину. Свои скрипты админы хранят годами, даже кривые, даже неработающие. Особенно бережно каждый админ хранит свой Самый Первый Скрипт, ну или то, что он считает таковым. И каждый админ верит, что однажды он сможет, как волшебной палочкой, махнуть своим сприптом, во всю его двухсотстрочную perl'овую длину, и за секунду выполнить то, на что должно было бы уйти сутки. И тогда он снова вернется к отладке кода своего скрипта, который делает скрипты для рутины. Этот скрипт очень нужен, потому что админ любит спать, и любит играть, и очень не любит работу, особенно рутину.
Ведь и даже этот топик можно же было перевести по-сути, а не по содержанию:
> Когда решение проблемы требует от нас множества повторяющихся рутинных действий, то мы всегда предпочтем написать код, который это сделает. Обычно это занимает меньше времени, нежели рукопашный метод, но не всегда. Все равно, мы скорее займемся созданием того, что мы можем использовать повторно потом, нежели будем решать проблему здесь и сейчас. Обычно это пригождается потом, через несколько лет, когда мы встречаем схожую проблему и можем вытащить из рукава несколько сотен строчек кода на Perl, лежащих в нашей домашней директории, решить проблему за несколько минут и вернуться к улучшению нашего кода. Или к незаконченному на три звезды уровню в Angry Birds.
Админ не делает рутину. Рутину делает скрипт. И даже если написание скрипта займет больше времени, чем нужно на рутину, админ все равно будет делать скрипт. Потому что админ не делает рутину. Свои скрипты админы хранят годами, даже кривые, даже неработающие. Особенно бережно каждый админ хранит свой Самый Первый Скрипт, ну или то, что он считает таковым. И каждый админ верит, что однажды он сможет, как волшебной палочкой, махнуть своим сприптом, во всю его двухсотстрочную perl'овую длину, и за секунду выполнить то, на что должно было бы уйти сутки. И тогда он снова вернется к отладке кода своего скрипта, который делает скрипты для рутины. Этот скрипт очень нужен, потому что админ любит спать, и любит играть, и очень не любит работу, особенно рутину.
то первое что мы делаем — sudo su
Ну почему? Почему не sudo -s?
Проще набирать?
Рискую получить по шапке за трудолюбие, но всё равно:
Upd: насколько я помню, так правильно запускается процедура входа в систему как root — сиречь, с правильными переменными окружения, запуском .bashrc, .profile, et cetera.
sudo su -Upd: насколько я помню, так правильно запускается процедура входа в систему как root — сиречь, с правильными переменными окружения, запуском .bashrc, .profile, et cetera.
Я тоже так всегда делаю. Черточка — важная деталь при использовании su.
Ещё есть sudo -i.
Это и использую.
Извините, но почему бы просто не использовать «su -», без sudo?
в убунте не пройдёт по дефолту.
Сам su там есть, как говорят, «искаропки», и все что нужно однократно сделать — это sudo passwd.
Знаю, знаю, но меня не напрягает. Мне кажется легче на всех серверах писать sudo -i, нежели помнить где пароль на рута уже стоит, а где нет… Помнить пароли ещё нужно, а это совсем не то же самое, если назначить руту такой же пароль, что и у локального пользователя. Для локального пользователя иметь менее строгий пароль намного менее опаснее, чем для рута.
Это, конечно, всё может свестить к холивару, поэтому просто остановлюсь на «мне почти всё равно, привык к sudo -i и меня не напрягает».
Это, конечно, всё может свестить к холивару, поэтому просто остановлюсь на «мне почти всё равно, привык к sudo -i и меня не напрягает».
Для локального пользователя иметь менее строгий пароль намного менее опаснее, чем для рута.
Поделили на ноль. Если после дефейса будет скомпрометирован пароль пользователя, то никто не помешает зайти под этим пользователем и ввести «sudo -i». Пароль то запросится не рутовский, а пользовательский.
Ну, как вариант, можно запретить ssh по паролю, и использовать только ключи.
Хотя все равно, рутовый пароль и запрет sudo выглядят более безопасно, особенно если еще и MFA прикрутить.
Хотя все равно, рутовый пароль и запрет sudo выглядят более безопасно, особенно если еще и MFA прикрутить.
убунтупривычки, в моём debian sudo по дефолту не установлен, а если его устанавливатт так он ещё и настройки требует…
sudo спрашивает пароль текущего пользователя. Для использования su нужно знать пароль root. Ну, как минимум, так по дефолту.
sudo -i делает тоже самое.
Это удобно ровно до того момента, когда узнаёшь про ForwardAgent в ssh или хочешь вести history «судохнутых» пользователей
sudo -s
HOME=/home/applic
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
reads $USER's ~/.bashrc
sudo su
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
reads /etc/environment
reads /root/.bashrc
Отсюда
HOME=/home/applic
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
reads $USER's ~/.bashrc
sudo su
HOME=/root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
reads /etc/environment
reads /root/.bashrc
Отсюда
Тогда уж -i. -s не выставляет переменные окружения как надо.
У меня -i
Я обычно делаю:
чтобы сходу задать пароль рута :)
sudo passwdчтобы сходу задать пароль рута :)
sudo -i на самом деле
Потому что речь про Unix, а не про ваш хипстерский Linux с его хипстерским sudo. В 90-х на AIX у sudo не было всех этих хипстерских флагов!
Суровый — не значит «лучше всех».
Это проблема личности конкретного человека. Не стоит обобщать.
Или как говорит один мой знакомый, «это их личные половые трудности».)
Или как говорит один мой знакомый, «это их личные половые трудности».)
Вы ошибаетесь, сударь. Сейчас поясню.
Если взять абсолютно любое количество человек с какой-то одной общей характеристикой (пусть специальность, место работы, что хотите). Затем как-то эту характеристику измерить (достаточно даже «нравится/не нравится», допустим нам интересно «нравится»), то полученный опыт говорит только о том, что большинство человек из этой выборки вам нравится. Но это абсолютно ничего не говорит о человеке, который только что присоединился к этой выборке, потому что вы о нем сейчас ничего не знаете. Вы можете предположить, однако это и останется предположением до тех пор, пока вы не проверите «нравится/не нравится».
В этом случае, корректно говорить, что «большинство людей с такой-то характеристикой вам нравятся». Но не очень корректно говорить «все люди с такой характеристикой мне нравятся». Ошибка как раз в слове «все».
Эти довольно простые выводы следуют из простых понятий теории вероятности.
Дак вот, чтобы с уверенностью говорить про всех, нужно посмотреть всех.
По поводу ваших вопросов.
Да, чем больше людей я знаю, тем объективнее оценка. Однако моя оценка никак не влияет на мое мнение о человеке, которого я вижу в первый раз. Максимум что я могу делать в этом случае — предполагать. Но, опять же, мой опыт предположений говорит, что лучше не стоит ибо каждый человек — отдельная личность.
ЗЫ: извините за занудство если что…
Если взять абсолютно любое количество человек с какой-то одной общей характеристикой (пусть специальность, место работы, что хотите). Затем как-то эту характеристику измерить (достаточно даже «нравится/не нравится», допустим нам интересно «нравится»), то полученный опыт говорит только о том, что большинство человек из этой выборки вам нравится. Но это абсолютно ничего не говорит о человеке, который только что присоединился к этой выборке, потому что вы о нем сейчас ничего не знаете. Вы можете предположить, однако это и останется предположением до тех пор, пока вы не проверите «нравится/не нравится».
В этом случае, корректно говорить, что «большинство людей с такой-то характеристикой вам нравятся». Но не очень корректно говорить «все люди с такой характеристикой мне нравятся». Ошибка как раз в слове «все».
Эти довольно простые выводы следуют из простых понятий теории вероятности.
Если она вам знакома, то я поясню.
Берем N повторений какого-то опыта (можно взять N объектов, любых) проверим выполнение какого-то события в этой выборке (для объектов это будет скажем наличие какого-нибудь свойства). Пусть у K объектов выполнилось.
Дак вот после проверки мы получим вероятность p = K / N — это вероятность возникновения данного события в этой выборке.
Предположим, что p=1, т.е. все повторения дали одинаковый результат (объекты из данной выборки обладают выбранным свойством).
Если мы повторим опыт (возьмем еще один объект), то вероятность p с уверенностью позволяет только предположить, что произойдет выбранное событие (объект будет обладать нужным свойством).
Дак вот после проверки мы получим вероятность p = K / N — это вероятность возникновения данного события в этой выборке.
Предположим, что p=1, т.е. все повторения дали одинаковый результат (объекты из данной выборки обладают выбранным свойством).
Если мы повторим опыт (возьмем еще один объект), то вероятность p с уверенностью позволяет только предположить, что произойдет выбранное событие (объект будет обладать нужным свойством).
Дак вот, чтобы с уверенностью говорить про всех, нужно посмотреть всех.
По поводу ваших вопросов.
Да, чем больше людей я знаю, тем объективнее оценка. Однако моя оценка никак не влияет на мое мнение о человеке, которого я вижу в первый раз. Максимум что я могу делать в этом случае — предполагать. Но, опять же, мой опыт предположений говорит, что лучше не стоит ибо каждый человек — отдельная личность.
ЗЫ: извините за занудство если что…
Не воспринимайте этот список буквально. В нем очень много такого, что сложно понять со стороны. Тут не сколько «юниксойд/линуксойд», нежели понимание природы вещей и гармония этих самых вещей с операционной системой.
Особенно это хорошо раскрыто в пункте про регулярные выражения.
Особенно это хорошо раскрыто в пункте про регулярные выражения.
Я вот кстати люблю nano, хотя могу, пожалуй, себя отнести к «суровым админам»
> потратить 1-10 часов
Какие часы? Базовые знания (как редактировать/сохранить/выйти) можно получить за 5 минут. Остальное потихоньку набирается в дальнейшем, и времени почти не занимает.
Какие часы? Базовые знания (как редактировать/сохранить/выйти) можно получить за 5 минут. Остальное потихоньку набирается в дальнейшем, и времени почти не занимает.
Набирается если уделять время набору.
Точно так же набирается и с nano/etc.
Я вот, например, не знаю как там включить и использовать работу с блоками (visual mode в vim) или поиск/замену по регекспам.
Если мне приспичит это узнать — мне нужно будет воскурить маны или гуглить (и соотв. тратить время).
Так с любым более-менее сложным инструментом, не нужно тут vi(m) выделять в какую-то особую категорию.
Знаний для «просто поправить конфиг» там нужен самый минимум, те самые 5 минут.
Я вот, например, не знаю как там включить и использовать работу с блоками (visual mode в vim) или поиск/замену по регекспам.
Если мне приспичит это узнать — мне нужно будет воскурить маны или гуглить (и соотв. тратить время).
Так с любым более-менее сложным инструментом, не нужно тут vi(m) выделять в какую-то особую категорию.
Знаний для «просто поправить конфиг» там нужен самый минимум, те самые 5 минут.
Нано тоже раньше пользовался, но эти неочевидные и разрывающие шаблон клавиатурные сочетания сохранить и закрыть… В общем, в какой-то момент vim для меня стал удобнее nano.
Раньше даже в резюме писали — «верстаю только в Notepad.exe».
Спасибо, да. Именно так. Насчёт sudo -s уже написали выше, и главная причина — нетранзитивность sudo на пайпы/перенаправления ввода. Я знаю про tee, но он не работает для '>>' или для '<'.
Можете дописать ещё один признак суровости — переход с однострочника (пусть и 1000 байт в размере) на многострочный код воспринимается как маленькое личное поражение.
echo -n `for a in $(seq 1 20)`;do ./foo $a; read x; ( (aux x;aux x)&);done < /etc/myconf`|xargs --verbose -I X -P3 sh -c «seq 1 100|xargs -I Y -P 2 process X Y||echo X not `which Y`».
Как-то так.
Можете дописать ещё один признак суровости — переход с однострочника (пусть и 1000 байт в размере) на многострочный код воспринимается как маленькое личное поражение.
echo -n `for a in $(seq 1 20)`;do ./foo $a; read x; ( (aux x;aux x)&);done < /etc/myconf`|xargs --verbose -I X -P3 sh -c «seq 1 100|xargs -I Y -P 2 process X Y||echo X not `which Y`».
Как-то так.
tee частично работает для '>>', его можно звать через |&
Приму удар на себя:
Имхо переход с однострочника на многострочный код это не личное поражение, а победа команды людей в которой закрался такой вот любитель писать что-то вроде этого:)
Имхо переход с однострочника на многострочный код это не личное поражение, а победа команды людей в которой закрался такой вот любитель писать что-то вроде этого:)
Если не секрет, что делает эта команда? Мой парсер сломался, насчитав нечётное количество символов " ` ".
но он не работает для '>>'
tee -a
или для '<'
sudo cat
Признак 10: борода.
Это клеше и штампы.
Все настоящие профессионалы которых я знаю и с которыми довелось работать не имеют этих фрик атрибутов, а очень опрятны и вежливы в общении.
PS: настоящие ПРО(10-15 лет опыта в крупных системах) большую часть времени работают под su, иначе считай сидят под рутом.
Все настоящие профессионалы которых я знаю и с которыми довелось работать не имеют этих фрик атрибутов, а очень опрятны и вежливы в общении.
PS: настоящие ПРО(10-15 лет опыта в крупных системах) большую часть времени работают под su, иначе считай сидят под рутом.
Всё зависит от ситуации.
На сервере где админит несколько человек требование выполнять все команды через
Дома у не очень опытного пользователя запуск через
Я админю линух уже лет 20, и у меня дома постоянно открыта пара
На сервере где админит несколько человек требование выполнять все команды через
sudo и запрет на запуск su/bash через sudo — имеет смысл хотя бы ради ведения логов команд.Дома у не очень опытного пользователя запуск через
sudo — имеет смысл хотя бы ради того, чтобы он не делал от рута то, что можно сделать от пользователя.Я админю линух уже лет 20, и у меня дома постоянно открыта пара
rxvt с su -, несколько c ssh root@сервера, и штук 15 терминалов под обычным пользователем (по одному с mc, mutt, mysql, rtorrent и остальные с bash). Все эти терминалы открыты каждый в своём виртуальном рабочем столе (с переключением между столами по Alt-Fx и Alt-Shift-Fx, да, у меня 24 рабочих стола :)). И если я иногда под рутом запускаю ls или man или ещё какие-то команды, которые, в принципе, можно было бы выполнить и без рутовых полномочий, то никакой трагедии в этом нет. А sudo я дома использую исключительно в скриптах.
Sudo очень полезен для запуска отдельных команд под рутом, для скриптов, в частности. :)
Дома у не очень опытного пользователя запуск через sudo — имеет смысл хотя бы ради того, чтобы он не делал от рута то, что можно сделать от пользователя.
Кого вы обманываете? На sudo стоит суидный бит и овнер рут, и никакого обычного пользователя в этом случае нет.
Я админю линух уже лет 20Ядру Linux исполнилось 22 года ;)
Не холивара ради, но из любопытства: почему именно много терминалов, а не один со screen в нём?
Переключаться мышкой? Или, хотя бы, видя визуальное представление.
Одна из причин — в тех терминалах, в которых запущена ssh на сервера запущен и screen (на сервере). Другая — screen всё-таки не идеален, он не является полноценным аналогом терминала, некоторые приложения использовать в screen не так удобно (например из-за конфликтов по горячим клавишам), плюс моя рабочая среда сложилась очень много лет назад, когда screen работал не так хорошо, как сейчас. Третья — используя виртуальные рабочие столы вместо screen я получаю единообразный способ переключения между всеми приложениями (включая графические: pidgin/opera/etc.) и возможность запускать рядом (на том же рабочем столе) с конкретным терминалом связанные с решаемой в нём задачей приложения.
А зачем «постоянно открыта пара rxvt с su -»? В штатной работе, если система нормально настроена, то нет никакой необходимости в постоянно открытом root'е. Достаточно прописать себя в операторские группы…
Для меня постоянное сидение под root'ом — это признак непрофессионализма Unix-администратора. Ну, кроме случаев когда админ занимается вводом в эксплуатацию новых систем
Я использую sudo для запуска пакетного менеджера для обновления системы, реже для манипуляций процессами init.d|systemd, ну изредка что-то поправить в /etc…
Для меня постоянное сидение под root'ом — это признак непрофессионализма Unix-администратора. Ну, кроме случаев когда админ занимается вводом в эксплуатацию новых систем
Я использую sudo для запуска пакетного менеджера для обновления системы, реже для манипуляций процессами init.d|systemd, ну изредка что-то поправить в /etc…
А я вместо использования для этого sudo просто нажимаю одну кнопку (из дополнительных user-defined кнопок) и попадаю в рутовый терминал, где все эти команды набирать значительно удобнее.
Что касается «постоянного сидения под root». Если под рутом делать обычную работу (запускать X-ы, писать скрипты и документы, смотреть фильмы) — да, это признак непрофессионализма. А если где-то там, в фоне, в неиспользуемом виртуальном рабочем столе заранее открыт рутовый терминал, который используется только когда надо обновить систему или что-то настроить — в чём же тут непрофессионализм?
Что касается «постоянного сидения под root». Если под рутом делать обычную работу (запускать X-ы, писать скрипты и документы, смотреть фильмы) — да, это признак непрофессионализма. А если где-то там, в фоне, в неиспользуемом виртуальном рабочем столе заранее открыт рутовый терминал, который используется только когда надо обновить систему или что-то настроить — в чём же тут непрофессионализм?
Это что же, борода теперь считается признаком неопрятности? Посыпаю голову пеплом тогда.
я просто оставлю это тут дабы порадовать собратьев с растительностью на лице www.youtube.com/watch?v=KlgbKIswpzI
Пепел на голове — это уж точно признак неопрятности.
Ну, скажем так, если система не слишком бизнес-критичная, то можно и под рутом работать независимо от квалификации, достаточно уметь думать головой, не торопиться и быть внимательным. Когда речь идёт о живом продакшне… а собственно туда и лезть не нужно, если он работает. Для мониторинга статуса можно использовать любимую систему, а в случае серьезных проблем уже не так важно под кем вы сидите.
Ога. Я когда в начале 2000 начал работать в одной провайдерской конторе, где линукс и фря были наше фсе увидел такую же картину. Сидят постоянно под рутом. Если не нужен рут, то зачем вообще запущена консоль, нефик там делать.
Причем ламерами ну никак их назвать было нельзя, олдскульные товарищи.
Причем ламерами ну никак их назвать было нельзя, олдскульные товарищи.
Стыдно признать, но использую mcedit для лёгкой правки конфигов. Привычка наверное. Хотя без проблем владею vi или странным nano, если нет mcedit. А если уж и этого нет, то cat | sed — вполне себе редактор файлов.
В остальном всё совпало по пунктам. Хороший пост.
И кстати согласен с amarao по поводу однострочных скриптов.
В остальном всё совпало по пунктам. Хороший пост.
И кстати согласен с amarao по поводу однострочных скриптов.
Я, наверно, совсем странный: редактирую файлы локально в системе контроля версий редактором Sublime Text, а потом даю команду на pull изменений на сервера.
И даже команды, если они нетривиальные, подготавливаю в этом же редакторе, потом копирую-вставляю их в шелл. Делаю так, потому что удобно писать многострочный код, и файл с историей команд и комментариями можно сохранить себе на будущее, дав ему красивое имя.
И даже команды, если они нетривиальные, подготавливаю в этом же редакторе, потом копирую-вставляю их в шелл. Делаю так, потому что удобно писать многострочный код, и файл с историей команд и комментариями можно сохранить себе на будущее, дав ему красивое имя.
У меня 8 из 9. Пока только начинаю познавать дао регэкспов.
Можно добавить 11: мы всегда делаем бекапы конфигов перед правкой.
Можно добавить 11: мы всегда делаем бекапы конфигов перед правкой.
Бекапы? Только реал-тайм, только хардкор :)
Что сломалось все в scrollback buffer.
Или курить маны и понимать конфиги.
Короче говоря, если что сломал, то значит хреново конфиги знаешь.
Что сломалось все в scrollback buffer.
Или курить маны и понимать конфиги.
Короче говоря, если что сломал, то значит хреново конфиги знаешь.
В vim недавно появилась фича «постоянный undo» — т.е. возможность сделать undo даже после того, как ты записался и вышел из редактора. Она вполне заменила необходимость бэкапить конфиги перед правкой.
Аналогично с вами у меня 8/9, хоть и не админ вовсе по профессии, но к регуляркам отношусь крайне отрицательно, но пользоваться научусь, нужно знать врага в лицо.
> Можно добавить 11: мы всегда делаем бекапы конфигов перед правкой.
git init; git commit -a -m «initial commit»
Нет, правда. Программы должны лежать в пакетах, а конфиги — в репозиториях.
git init; git commit -a -m «initial commit»
Нет, правда. Программы должны лежать в пакетах, а конфиги — в репозиториях.
В теории — да. А на практике от использования git/hg получается значительный оверхед без заметной отдачи. При наличии ежедневных бэкапов в облако и persistent undo в vim у меня на куче машин за много лет было всего несколько случаев, когда очень хотелось узнать, когда и зачем именно были внесены какие-то изменения в конфиги. И во всех этих случаях в результате выяснялось, что сейчас, спустя много времени, эти изменения уже неактуальны. Что характерно, и бэкапы и undo работают автоматически, не требуя от меня ни выполнения дополнительных команд после каждого изменения конфигов ни введения описаний сделанных изменений.
svn и git — и не надо мусорить бэкапами. Так и делаю.
Без дао sed, nc и awk, а еще shell script на legacy sh список слабоват.
Насчет sudo vs. su — не совсем согласен. Должно быть и то и другое. Например, в «sudo apt-get install...» su явно лишнее.
apt-get тоже лишнее, когда есть aptitude.
Что-что?
Может так:
sudo su apt-get install
Может так:
sudo su
apt-get install
Ну вот банальная ситуация: сижу под пользователем, понадобилась какая-то утилитка, а ее нет, нужно установить. 2 варианта:
1.
2.
Вопрос: зачем использовать более длинный способ, если есть возможность использовать более короткий?
1.
$ sudo su (ввести пароль) # aptitude install blahblah # exit (да, возвращаемся из рута обратно)
2.
$ sudo aptitude install blahblah (ввести пароль)
Вопрос: зачем использовать более длинный способ, если есть возможность использовать более короткий?
И это вполне в духе юниксоида. Иначе лишний раз нажимать на кнопки… ;)
у меня обычно aptitude install blahblah, потом мат, потом sudo!!!
Потому что su -c
спасибо. потешил самолюбие :D
Я понимаю что текст намеренно «сенсационный» и «просветляющий» (тонкий юмор, да), но тем не менее немного раздражает когда личное мнение подается под соусом единственно верного пути гуру. Это я про пункты 1, 2. Думаю все понимают что однозначного ответа на вопрос «sudo vs su» и «Emacs vs vim» нет. Кому как удобно.
Остальное — да, прописные истины.
* Здесь должен быть комикс XKCD о текстовых редакторах, но так как он всем уже порядком поднадоел — гуглите сами *
Остальное — да, прописные истины.
* Здесь должен быть комикс XKCD о текстовых редакторах, но так как он всем уже порядком поднадоел — гуглите сами *
Регекспы, конечно, мощный инструмент, но «несравнима ни с одним другим инструментом» — я вас прошу. Если это именно регулярные выражения, без каких-то хитрых экстеншнов, то у них полно ограничений по определению.
В статье дан хороший пример, по поводу их применимости. Приведите любой другой инструмент для выполнения этой задачи. Буду благодарен.
Скрипт на (подставьте_любой_скриптовый_язык_например_питон)?
Вы не путайте скриптовый язык, для которого надо что-то установить еще в систему (это не всегда возможно) и, допустим, sed, который ныне и присно и родной бинарно, хоть и не pcre.
Или, допустим, grep, который тоже ныне и присно, и тоже pcre может.
Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.
Или, допустим, grep, который тоже ныне и присно, и тоже pcre может.
Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.
>Вы не путайте скриптовый язык, для которого надо что-то установить еще в систему
Чаще всего не надо, питон сейчас, если не ошибаюсь, во многих популярных дистрибутивах стоит по дефолту.
>Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.
Да хоть в десятки раз, если речь идет о миллисекундах — я, как пользователь, все равно этого не замечу :)
А если у вас это дело используется где-то в продакшене, как многократно используемое задание на множестве данных, то там за такие финты нужно сразу стрелять.
Чаще всего не надо, питон сейчас, если не ошибаюсь, во многих популярных дистрибутивах стоит по дефолту.
>Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.
Да хоть в десятки раз, если речь идет о миллисекундах — я, как пользователь, все равно этого не замечу :)
А если у вас это дело используется где-то в продакшене, как многократно используемое задание на множестве данных, то там за такие финты нужно сразу стрелять.
Как раз дело в том, что установка чего-то свыше обычно не очень прокатывает в роутерах, например. Или разных встроенных системах, у которых бывает не очень с доступом в интернет.
В остальных случаях — да не вопрос. Но речь как раз о духе Unix, т.е. о том, что не надо плодить сущности сверх необходимого. И устанавливать, например, PHP из исходников только потому, что мне надо что-то обработать, а я не знаю регулярных выражений — ну как-то глупо, не находите?
В остальных случаях — да не вопрос. Но речь как раз о духе Unix, т.е. о том, что не надо плодить сущности сверх необходимого. И устанавливать, например, PHP из исходников только потому, что мне надо что-то обработать, а я не знаю регулярных выражений — ну как-то глупо, не находите?
>И устанавливать, например, PHP из исходников только потому, что мне надо что-то обработать, а я не знаю регулярных выражений — ну как-то глупо, не находите?
Разумеется, глупо. Как и любая другая крайность, в которую вы вдруг захотите удариться в следующий раз ;)
Разумеется, глупо. Как и любая другая крайность, в которую вы вдруг захотите удариться в следующий раз ;)
А почему глупо? Это как раз не пложение сущностей. Ну или, если угодно, пложение в обоих случаях — или плодите трансляторы языков на винте, или синтаксисы языков у себя в памяти. Минимально необходим вообще только ассемблер, и то в машкодах можно писать.
Perl смотрит на вас с укором.
а на этом (подставьте_любой_скриптовый_язык_например_питон) парсить текст регуляркой, ага ^_^
Мне кажется что задача, например, «провалидейтить IP адрес» гораздо более реальна нежели та синтетика которая указана в статье. Напишите просто так для себя регулярку которая проверяет IP адрес на валидность (и да, при этом не заставляйте людей забивать числа в IP нулями до трехзначности — это задача для машины).
И не забывайте про старую поговорку о двух проблемах (-;
И не забывайте про старую поговорку о двух проблемах (-;
Если на коленке, просто как защита от нечаянных опечаток —
/^\d+\.\d+\.\d+\.\d+$/. А если нужно полноценно проверить, то зачем писать то, что уже давно аккуратно написано:use Regexp::Common qw /net/;
/$RE{net}{IPv4}/
Вот вы, собственно, и привели пример того, как Perl по мощности превосходит чистые regexp-ы — ведь он включает в себя и их, и другие вещи (такие как модули для повторного использования). Что и требовалось доказать (-:
В инструментах, ограниченных только regexp-ами, вроде grep, такую конструкцию не применить.
Более того, есть вещи, которые люди регулярно пытаются делать регулярками, хотя для них это совершенно не уместно. Вроде выпарсывания чего-нибудь из XML. Stackoverflow забит вопросами вроде «как мне заматчить регуляркой открывающий+закрывающий тег в XML» с ответами «не используйте регекспы для парсинга XML!»
В инструментах, ограниченных только regexp-ами, вроде grep, такую конструкцию не применить.
Более того, есть вещи, которые люди регулярно пытаются делать регулярками, хотя для них это совершенно не уместно. Вроде выпарсывания чего-нибудь из XML. Stackoverflow забит вопросами вроде «как мне заматчить регуляркой открывающий+закрывающий тег в XML» с ответами «не используйте регекспы для парсинга XML!»
8 из 9, иногда грешу nano`м :))
раздули тут понимаешь — 10 лет сижу под root и не парюсь за всякие sudo, su и дргую ересь ,-)
rm -rf /
Вы ждете пока сами себе отстрелите ногу, или пока это сделают за вас?
Ох, как повелись некоторые камрады.
Во-первых: на этих машинах как-правило один админ, который как бы знает что и зачем он делает.
Во-вторых: кто-нибудь из выше отписавшихся хоть раз за последние 3-5 лет набирал руками «rm -rf /» для решения каких-либо практических задач (кроме того когда это делалось намеренно чтобы проверить этот 100-летний баян)?
В-третьих: думать головой надо всегда.
Во-первых: на этих машинах как-правило один админ, который как бы знает что и зачем он делает.
Во-вторых: кто-нибудь из выше отписавшихся хоть раз за последние 3-5 лет набирал руками «rm -rf /» для решения каких-либо практических задач (кроме того когда это делалось намеренно чтобы проверить этот 100-летний баян)?
В-третьих: думать головой надо всегда.
А вы что, уже не помните?
-rm -rf /usr /home/.temp/kde
+rm -rf /usr/home/.temp/kde
Такую ошибку может совершить кто угодно. Пальцем пробел задел и привет. А если это не /usr, а допустим /etc /httpd/config.temp
-rm -rf /usr /home/.temp/kde
+rm -rf /usr/home/.temp/kde
Такую ошибку может совершить кто угодно. Пальцем пробел задел и привет. А если это не /usr, а допустим /etc /httpd/config.temp
Эту историю я помню, конечно, но:
1. Для того чтоб не набирать это руками существуют простые вещи типа mc и копирование мышкой, но и это не значит, что не надо думать головой
2. Зачем KDE на веб-сервере?
самое забавное, что за 10 лет моей практики снесли кое-что нужное ОДИН раз, и то из под mc, под юзером (не рутом), и это сделал сам юзер с частью своей же папки. И от невнимательности. Но для этого есть бекап
1. Для того чтоб не набирать это руками существуют простые вещи типа mc и копирование мышкой, но и это не значит, что не надо думать головой
2. Зачем KDE на веб-сервере?
самое забавное, что за 10 лет моей практики снесли кое-что нужное ОДИН раз, и то из под mc, под юзером (не рутом), и это сделал сам юзер с частью своей же папки. И от невнимательности. Но для этого есть бекап
Да причем тут кде? Я же привел пример:
rm -rf /etc /httpd/config.temp вместо rm -rf /etc/httpd/config.temp
rm -rf /etc /httpd/config.temp вместо rm -rf /etc/httpd/config.temp
Да я понял ваш пример :-)
Для того чтоб так не получалось надо иногда включать голову и аргументы некоторых потенциально опасных команд экранировать, к примеру, апострофами, если уж вы по клавишам не попадаете и ничего лишнего не удалится.
rm -rf '/etc /httpd/config.temp'
Для того чтоб так не получалось надо иногда включать голову и аргументы некоторых потенциально опасных команд экранировать, к примеру, апострофами, если уж вы по клавишам не попадаете и ничего лишнего не удалится.
rm -rf '/etc /httpd/config.temp'
в никсах с этим легче так как всегда есть TAB чтобы добраться до файла или диры
в вашем примере не спасет не sudo, не su так как: администраторам все равно приходится делать все административные задачи под root.
Отличный пример тому установщик нвидии который как раз запускался только из под рута
в вашем примере не спасет не sudo, не su так как: администраторам все равно приходится делать все административные задачи под root.
Отличный пример тому установщик нвидии который как раз запускался только из под рута
> с надувным кругом в животе
Как вы начинающих пловцов не любите :)) — «в животе». В оригинале — «Using sudo exclusively is like bowling with only the inflatable bumpers in the gutters».
А про перезагрузку 100 раз верно — мало когда она помогает. Если есть проблема настройки, скажем, веб-сервера, перезагрузка (вбитая в привычку после Windows) вряд ли поможет )
Как вы начинающих пловцов не любите :)) — «в животе». В оригинале — «Using sudo exclusively is like bowling with only the inflatable bumpers in the gutters».
А про перезагрузку 100 раз верно — мало когда она помогает. Если есть проблема настройки, скажем, веб-сервера, перезагрузка (вбитая в привычку после Windows) вряд ли поможет )
Мы уверены, что перезагрузка нужна только в случае изменений ядра или аппаратной части, а решение проблемы при помощи перезагрузки — временное ...
Во фре есть замечательная возможность урезать права руту, но чтобы изменения вступили в силу надо перегрузиться.
Если системная фигня, то да. Часто это помогает. Особенно если проблема как-то связана с взаимодействием с железом. Один раз правда был случай — ни в какую не помогало. Оказалось, что нужно было отрубить что-то в ядре (уже сейчас не помню) и сразу полегчало. А так на дню по несколько паников на пустом месте. В ядре копаться и осознавать что оно говорит уже крайне сложно к сожалению(
А если-бы Линукс был микроядерным, то и перезагрузка была-бы излишним телодвижением. Эх мечты мечты…
sudo tcsh. Потому что не пингвин, а в кедах ;)
Не знаю как у суровых админов, но я как-то не смог себя приучить к vi/vim и каждый раз плююсь, когда приходится с ними работать. При первой возможности ставлю nano/pico. Уже руки под него заточены за 12 лет. Да и админю в основном Фряхи — там я получаю от этого удовольствие, которое в линуксе получить даже рядом не получалось (разве только дебиан по-приятнее всех).
Наверное, я не слишком суров и сликом капризен. Печалька.
Наверное, я не слишком суров и сликом капризен. Печалька.
По поводу споров насчет sudo и su стоит вспомнить статью su или sudo?
Избегаю использования vi и vim.
Emacs для unix-программеров, Vi для unix-админов… Vim — для линуксоидов.
vi — это стандарт де факто для unix-систем. Если вы себя считаете unix-админом в глобальном смысле, а не админом конкретного дистра или unix-системы, то vi надо знать.
Чтобы понять что такое vi, надо немного вникнуть в историю вопроса, понять, что какой была консоль изначально и разобраться с ed и ex. Они тривиальные. Но после этого vi всё встанет на свои места. Просто все учат его не с того конца.
vi — это стандарт де факто для unix-систем. Если вы себя считаете unix-админом в глобальном смысле, а не админом конкретного дистра или unix-системы, то vi надо знать.
Чтобы понять что такое vi, надо немного вникнуть в историю вопроса, понять, что какой была консоль изначально и разобраться с ed и ex. Они тривиальные. Но после этого vi всё встанет на свои места. Просто все учат его не с того конца.
Полгода Фряхи(и никакого линукса) и я суровый админ. Я много раз пытался разные Линуксы ставить(Убунту, Фидору, Центос) но как-то неприятно в них учиться работать было. Поставив Фряху я поразился лаконичности, логичности и стройности применяемых решений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Девять признаков сурового администратора Unix