Пользователь
96,6
рейтинг
9 сентября 2013 в 17:43

Администрирование → Девять признаков сурового администратора Unix перевод

Я, к сожалению, не нашел русского перевода этого текста, хотя мне он показался крайне… просветляющим, что ли.

Признак 1: мы не используем sudo


Как CAPS LOCK — «круиз-контроль для крутотенюшки», так и sudo — «костыль для сомневающихся». Если нам нужно сделать что-то от имени root, мы используем su, а не фигню навроде sudo. Если какая-то из Unix-подобных операционных систем заставляет нас использовать sudo, то первое что мы делаем — sudo su и устанавливаем пароль для пользователя root, чтобы комфортно пользоваться su в дальнейшем. Постоянное использование sudo можно сравнить с плаванием c надувным кругом в животе — это безопаснее, да, но лишает необходимости обдумывания поступков.

Признак 2: мы используем vi, а не emacs, и уж точно не pico или nano


Несмотря на то, что emacs близок и люб сердцам многих администраторов Unix, на самом деле это эквивалент Microsoft Word для Unix. Vi — а в особенности vim — настоящий инструмент сурового Unix гуру, которому нужно быстро делать то, что ему нужно без всякой ерунды, которую таскает с собой emacs. В emacs встроен чертов тетрис, чтобы было чем заняться, да.

Я неохотно признаю, что все эти свистелки и перделки в vim, такие как сворачивание кода и синтаксическая подсветка воспринимаются совершеннейшей фигней, но когда мозг уже слабо работает, концепция модального редактирования в vi очень помогает. А малый размер и существование для всех платформ в итоге создает Единственный Истинный Редактор. Спасибо, Билл, спасибо, Брэм.

Признак 3: регулярные выражения — наше оружие


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

Признак 4: мы ленивы по сути своей


Когда решение проблемы требует от нас множества повторяющихся рутинных действий, то мы всегда предпочтем написать код, который это сделает. Обычно это занимает меньше времени, нежели рукопашный метод, но не всегда. Все равно, мы скорее займемся созданием того, что мы можем использовать повторно потом, нежели будем решать проблему здесь и сейчас. Обычно это пригождается потом, через несколько лет, когда мы встречаем схожую проблему и можем вытащить из рукава несколько сотен строчек кода на Perl, лежащих в нашей домашней директории, решить проблему за несколько минут и вернуться к улучшению нашего кода. Или к незаконченному на три звезды уровню в Angry Birds.

Признак 5: мы предпочитаем элегантные решения


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

Признак 6: мы уверены, что ответ на вопрос зависит от вопрошающего


Достижение определенного уровня Unix-просветления заключается в абсолютной уверенности в Ваших фундаментальных знаниях. Это также означает, что мы никогда не верим в проблему, пока не увидим ее сами. Скажите суровому администратору Unix, что файл «исчез» — и получите в ответ презрительную насмешку. Докажите, что это действительно произошло — и он погрузится в решение проблемы без оглядки, копая до тех пор, пока не найдет подходящее осмысленное объяснение причины и подходящее решение. Многие считают, что это признак высокомерия или заносчивости. Так и есть, однако смиритесь, мы это заслужили.

Признак 7: мы ближе к патологоанатомам, нежели к докторам


Столкнувшись с большой проблемой, мы проведем гораздо больше времени анализируя произошедшее, нежели решая проблему прямо сейчас. Пока у нас есть хотя бы минутка времени, мы должны знать каждую причину, вызвавшую проблему. Нет никакой магии в работе сурового администратора Unix; каждое событие должно произрастать из определенной логической точки, которую можно отследить. Если говорить кратко, у всего есть причина и мы отработаем все варианты развития событий, чтобы ее найти.

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

Признак 8: мы знаем о Windows больше, чем показываем


Даже несмотря на то, что на наших машинах не установлен Windows и мы ни капельки не беспокоимся о серверах с Windows, обычно мы неплохо умеем диагностировать и исправлять проблемы Windows. Это потому, что мы сталкивались с этими проблемами, когда они просачивались в зону нашей ответственности. Однако мы не любим признавать это, поскольку в большей части случаев Windows не разделяет глубоко логичные принципы Unix, и это нам не нравится. См. также признаки 5 и 6 выше.

Признак 9: перезагрузка — не наш метод


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

Если некоторые из этих принципов кажутся асоциальными или трудными для понимания с позиции простого смертного, то это как раз потому, что так оно и есть. Там, где другие видят невнятные, слишком сложные методы, мы видим просветление, рожденное годами обучения, опыта и, что важнее всего, логики.
Перевод: Paul Venezia
@prometheus_ru
карма
40,0
рейтинг 96,6
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (191)

  • +8
    О да, я суровый unix-админ, хотя не админю уже много лет :)
    • +117
      Программеры — они толстые. Потому что они сидят. А админы — они тощие. Потому что бегают. Впрочем, бывают тощие программеры. Hо не надо думать, что это исключение из правил — это переученные админы. Также встречаются и толстые админы. Это обленившиеся программеры.

      Программеры курят быстро, потому что мысль. Потому что она уйдет и придется думать ее снова. У админов мыслей нет, поэтому они курят медленно. Они делают это в те моменты, когда все работает и ничего не падает. Поэтому они курят редко.

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

      Программеры уходят с работы ночью. Потому что мысль. Hекоторые из них уходят вечером и думают мысль дома. Hекоторые, у которых есть ноутбук, думают ее в метро. Админы домой не ходят. Потому что если они пойдут домой, что-нибудь упадет. И придется идти на работу. А на работу они ходить не любят. И не ходят. Они там живут. У них обычно есть отдельное гнездо за отдельной дверью, часто запираемой на отдельный замок.

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

      Программеры пьют пиво. В основном светлое и много. Потому что мысль. Пока она плавает — ее можно думать. Главное, чтобы не утонула. Админы тоже пьют пиво. Потому что если что-нибудь упадет, им будет пофиг. Админы любят когда им пофиг. И программеры любят, когда им пофиг. Поэтому часто они пьют пиво вместе. И им вместе пофиг. После этого они спят. Hо не вместе. Админы спят в гнезде, а программеры — на клаве. Когда они просыпаются, они снова пьют пиво. Потому что хочется. Потому что они админы. И программеры.
      • –3
        удалено
        • +1
          И правильно, что не читали, т.к. текст ориентирован на людей с чувством юмора.
      • +31
        По поводу толщины админов

      • +1
        Это лучший коммент, который я читал на хабре.
        • +18
          Это лучший коммент, который я читал на хабре.
          Да, я когда это лет 15 назад прочитал тоже хохотал)
          • +7
            Ага. И хотя шутка весьма плоская, но как же хорошо она подана стилистически!

            Ведь и даже этот топик можно же было перевести по-сути, а не по содержанию:

            > Когда решение проблемы требует от нас множества повторяющихся рутинных действий, то мы всегда предпочтем написать код, который это сделает. Обычно это занимает меньше времени, нежели рукопашный метод, но не всегда. Все равно, мы скорее займемся созданием того, что мы можем использовать повторно потом, нежели будем решать проблему здесь и сейчас. Обычно это пригождается потом, через несколько лет, когда мы встречаем схожую проблему и можем вытащить из рукава несколько сотен строчек кода на Perl, лежащих в нашей домашней директории, решить проблему за несколько минут и вернуться к улучшению нашего кода. Или к незаконченному на три звезды уровню в Angry Birds.

            Админ не делает рутину. Рутину делает скрипт. И даже если написание скрипта займет больше времени, чем нужно на рутину, админ все равно будет делать скрипт. Потому что админ не делает рутину. Свои скрипты админы хранят годами, даже кривые, даже неработающие. Особенно бережно каждый админ хранит свой Самый Первый Скрипт, ну или то, что он считает таковым. И каждый админ верит, что однажды он сможет, как волшебной палочкой, махнуть своим сприптом, во всю его двухсотстрочную perl'овую длину, и за секунду выполнить то, на что должно было бы уйти сутки. И тогда он снова вернется к отладке кода своего скрипта, который делает скрипты для рутины. Этот скрипт очень нужен, потому что админ любит спать, и любит играть, и очень не любит работу, особенно рутину.
  • +8
    то первое что мы делаем — sudo su

    Ну почему? Почему не sudo -s?
    • +1
      Проще набирать?
      • +16
        Рискую получить по шапке за трудолюбие, но всё равно:
        sudo su -
        Upd: насколько я помню, так правильно запускается процедура входа в систему как root — сиречь, с правильными переменными окружения, запуском .bashrc, .profile, et cetera.
        • +4
          Я тоже так всегда делаю. Черточка — важная деталь при использовании su.
          • +2
            su='echo «Always use /bin/su -»; /bin/su -' ^_^
        • +23
          Ещё есть sudo -i.
          • +2
            Это и использую.
            • 0
              Извините, но почему бы просто не использовать «su -», без sudo?
              • +1
                в убунте не пройдёт по дефолту.
                • 0
                  Сам su там есть, как говорят, «искаропки», и все что нужно однократно сделать — это sudo passwd.
                  • +2
                    Знаю, знаю, но меня не напрягает. Мне кажется легче на всех серверах писать sudo -i, нежели помнить где пароль на рута уже стоит, а где нет… Помнить пароли ещё нужно, а это совсем не то же самое, если назначить руту такой же пароль, что и у локального пользователя. Для локального пользователя иметь менее строгий пароль намного менее опаснее, чем для рута.
                    Это, конечно, всё может свестить к холивару, поэтому просто остановлюсь на «мне почти всё равно, привык к sudo -i и меня не напрягает».
                    • 0
                      Для локального пользователя иметь менее строгий пароль намного менее опаснее, чем для рута.

                      Поделили на ноль. Если после дефейса будет скомпрометирован пароль пользователя, то никто не помешает зайти под этим пользователем и ввести «sudo -i». Пароль то запросится не рутовский, а пользовательский.
                      • +1
                        Ну, как вариант, можно запретить ssh по паролю, и использовать только ключи.
                        Хотя все равно, рутовый пароль и запрет sudo выглядят более безопасно, особенно если еще и MFA прикрутить.
                        • 0
                          Пользователи могут и не знать свой пароль, если авторизация происходит по ключу. Скрепя сердце, можно даже в sudoers некоторым пользователям дать NOPASSWD для узкого списка приложений, хотя это тоже потенциальная дыра.
                          • +2
                            А зачем пользователям в принципе знать свой пароль? Там можно вообще рандом выставить на 20 символов, запретить его смену, и пускать на сервак только по ключу с ключевой фразой или же без неё.
              • +2
                убунтупривычки, в моём debian sudo по дефолту не установлен, а если его устанавливатт так он ещё и настройки требует…
              • +3
                sudo спрашивает пароль текущего пользователя. Для использования su нужно знать пароль root. Ну, как минимум, так по дефолту.
        • 0
          sudo -i делает тоже самое.
    • +5
      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

      Отсюда
    • +7
      Тогда уж -i. -s не выставляет переменные окружения как надо.
      • +3
        «как надо» у всех разное, мне вот удобнее -s. Для кого-то ваш вариант оправдан.
    • +4
      У меня -i
    • 0
      Я обычно делаю:
      sudo passwd
      чтобы сходу задать пароль рута :)
    • 0
      sudo -i на самом деле
    • +6
      Потому что речь про Unix, а не про ваш хипстерский Linux с его хипстерским sudo. В 90-х на AIX у sudo не было всех этих хипстерских флагов!
  • +5
    Спасибо за возможность потешить ЧСВ, почти соответствую этим признакам. Хотя я и вовсе не unix админ.
    • +1
      «Почти» — это не про vi(m) ли случайно? :) Вот у меня получается именно так, т.е. я тоже не админ, но соответствую всему, кроме vim-а.
      • +8
        Я так и не научился из него выходить )
        • +1
          ZZ, хотя и я в смысле vim не суровый админ. ;)
          • 0
            Или более безопасное ZQ))
        • +3
          :wq
          • 0
            У меня чувство, что это смайлик, и вы надо мной (или vim над миром) смеётесь. )
          • +2
            Плохой совет, лучше :q!
            • 0
              Тогда лучше :cq
            • 0
              Почему?
              • +1
                Сохранит всё, что испортил пока бибикал :)
          • 0
            зачем, когда можно короче на треть.

            :x

      • +1
        Не, vim как раз использую, очень удобный редактор.
  • –24
    Иногда ЧСВ юниксоидов/линуксоидов у меня вызывают такое же отвращение как и ЧСВ яблоко/андроид фанатов.
    «Мы единственные боги/профессионалы/элита, а вы быдло».

    На мой взгляд настоящий профессионал(не только юникс, как в статье) использует ВСЕ инструменты для эффективной работы, а не хвалится, что он только в vi работает.
    • +2
      Суровый — не значит «лучше всех».
      • –3
        Увы, из моих 4-ых знакомых они думают как раз именно так.
        Да и в интернетах на форумах такие часто попадаются.
        • 0
          Это проблема личности конкретного человека. Не стоит обобщать.
          Или как говорит один мой знакомый, «это их личные половые трудности».)
          • 0
            Эм. Вообще мнение человека о профессии, составляются из реального общения с представителями этой профессии.

            Если 6 сантехников, с кем приходилось иметь дело, пьянь, значит о сантехниках сложилось мнение, что они пьянь.
            Если 7 программистов на работе не следят за собой и ходят в рванье и с сальными волосами, значит мнение о программистах соответствующее.
            Если 4 знакомых юниксоида считают себя богами, значит у любителей никсов завышено ЧСВ,

            У тебя как то иначе складывается мнение о профессии? Ты обязательно ищешь сразу человек 50-100 для более объективной оценки?
            Обобщение, это если я один раз увидел в жизни программиста, запомнил какой он есть и теперь думаю, что все они такие.
            Поправь меня, если я ошибаюсь.

            • +4
              Вы ошибаетесь, сударь. Сейчас поясню.
              Если взять абсолютно любое количество человек с какой-то одной общей характеристикой (пусть специальность, место работы, что хотите). Затем как-то эту характеристику измерить (достаточно даже «нравится/не нравится», допустим нам интересно «нравится»), то полученный опыт говорит только о том, что большинство человек из этой выборки вам нравится. Но это абсолютно ничего не говорит о человеке, который только что присоединился к этой выборке, потому что вы о нем сейчас ничего не знаете. Вы можете предположить, однако это и останется предположением до тех пор, пока вы не проверите «нравится/не нравится».

              В этом случае, корректно говорить, что «большинство людей с такой-то характеристикой вам нравятся». Но не очень корректно говорить «все люди с такой характеристикой мне нравятся». Ошибка как раз в слове «все».

              Эти довольно простые выводы следуют из простых понятий теории вероятности.
              Если она вам знакома, то я поясню.
              Берем N повторений какого-то опыта (можно взять N объектов, любых) проверим выполнение какого-то события в этой выборке (для объектов это будет скажем наличие какого-нибудь свойства). Пусть у K объектов выполнилось.
              Дак вот после проверки мы получим вероятность p = K / N — это вероятность возникновения данного события в этой выборке.
              Предположим, что p=1, т.е. все повторения дали одинаковый результат (объекты из данной выборки обладают выбранным свойством).
              Если мы повторим опыт (возьмем еще один объект), то вероятность p с уверенностью позволяет только предположить, что произойдет выбранное событие (объект будет обладать нужным свойством).

              Дак вот, чтобы с уверенностью говорить про всех, нужно посмотреть всех.

              По поводу ваших вопросов.
              Да, чем больше людей я знаю, тем объективнее оценка. Однако моя оценка никак не влияет на мое мнение о человеке, которого я вижу в первый раз. Максимум что я могу делать в этом случае — предполагать. Но, опять же, мой опыт предположений говорит, что лучше не стоит ибо каждый человек — отдельная личность.

              ЗЫ: извините за занудство если что…
              • 0
                Да, это занудство =)
              • +1
                Не бойтесь занудства, лучше возьмите M объектов, а не N. Или M повторений. Ну вы поняли.
    • +2
      Не воспринимайте этот список буквально. В нем очень много такого, что сложно понять со стороны. Тут не сколько «юниксойд/линуксойд», нежели понимание природы вещей и гармония этих самых вещей с операционной системой.

      Особенно это хорошо раскрыто в пункте про регулярные выражения.
      • +2
        На данном сайте давным давно никого не интересует чужое мнение и даже легкая критика. Тут всем интересны лишь юморные комментарии и похвала автору/теме.
        • 0
          Мне кажется на хабре живут боты которые автоматически минисуют комментарии со словами «яблоко», «андроид» и т.п. ;)
          Критика хорошая, хотя чуть резкая. Такая илита в любой креативной профессии есть. Всем нравится чувствовать себя «просветленными».
          • 0
            У тебя же есть adblock?
            Поставь себе фильтр «habrahabr.ru##.score» и ты увидишь как может быть максимально красивым этот сайт.
            Мне почему то кажется, что половина старожилов с данного сайта так себе сделали. Сразу все объективно оцениваешь.
            • +1
              Добра вам, добрый человек, за эту подсказку.
          • +2
            тест: яблоко, андроид.
            • +3
              «Кармический» вес слова «тест» у ботов перевешивает холиварные.
    • +3
      Я вот кстати люблю nano, хотя могу, пожалуй, себя отнести к «суровым админам»
      • 0
        Каждый выбирает то, что ему поможет максимально быстро и эффективно сделать свою работу.

        Если человек выбирает vi, значит он готов потратить 1-10 часов на изучение данного редактора.
        Если человек выбирает nano, значит он не готов тратить лишнее время, и готов освоить nano за 1-5 минут.
        • +1
          > потратить 1-10 часов

          Какие часы? Базовые знания (как редактировать/сохранить/выйти) можно получить за 5 минут. Остальное потихоньку набирается в дальнейшем, и времени почти не занимает.
          • +1
            Набирается если уделять время набору.
            • +1
              Точно так же набирается и с nano/etc.
              Я вот, например, не знаю как там включить и использовать работу с блоками (visual mode в vim) или поиск/замену по регекспам.
              Если мне приспичит это узнать — мне нужно будет воскурить маны или гуглить (и соотв. тратить время).
              Так с любым более-менее сложным инструментом, не нужно тут vi(m) выделять в какую-то особую категорию.
              Знаний для «просто поправить конфиг» там нужен самый минимум, те самые 5 минут.
              • 0
                Я лишь сказал, что само оно не набирается, как можно подумать из коммента выше. Я уже много лет использую vim именно в режиме редактировать/сохранить/выйти плюс простейший поиск. Больше ничего не набралось.
                • 0
                  А, ясно, теперь понял.
          • 0
            Ну ок, не прав, не в часах измерять. Но разве нет ощущения, что человек, никогда(или мало) работающий в консоли, быстрее изучит нано, чем ви?
            • 0
              Думаю, это никак не связано. Vim мало общего имеет с работой в консоли.
              • 0
                Ну помимо того, что vi и vim прежде всего консольные, а не графические текстовые редакторы, то да, ничего не связано.
                • 0
                  Ну справедливости ради, есть еще и gvim. Емнип, уже очень давно как есть.
                  • 0
                    А про них в статье и не сказано =)
                • 0
                  Не консольные (в смысле CLI), а экранные (TUI).
            • 0
              А вот фиг его знает, от много чего зависит. По личным наблюдениям — основная проблема при начале работы с vi — это понимание концепции режима редактирования. После этого — проблем уже нет никаких.
      • 0
        Нано тоже раньше пользовался, но эти неочевидные и разрывающие шаблон клавиатурные сочетания сохранить и закрыть… В общем, в какой-то момент vim для меня стал удобнее nano.
    • 0
      Раньше даже в резюме писали — «верстаю только в Notepad.exe».
      • +1
        Это говорит о том, что человек не знает других инструментов, которые ускорят его работу и сделают гораздо комфортнее.
        Это не говорит о том, что он профессионал.
        • 0
          Да. Я просто несколько лет назад таких на работу верстальщиков собеседовал. Интересно было.
      • 0
        Покажите им тот выпуск xkcd, где про эффект бабочки. Пусть осознают, как они далеки от реальной крутизны.

        А вообще, за такие откровения в резюме нужно говорить «спасибо»! … и «до свидания» :]
  • +10
    Спасибо, да. Именно так. Насчёт 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`».

    Как-то так.
    • 0
      tee частично работает для '>>', его можно звать через |&
    • +27
      Приму удар на себя:

      Имхо переход с однострочника на многострочный код это не личное поражение, а победа команды людей в которой закрался такой вот любитель писать что-то вроде этого:)
      • +2
        Какое дело команде до того, что я пишу в командной строке? Речь не про программы, а про то, что я пишу в шелле, когда мне нужно что-то от компьютера.
        • 0
          Зато history потом смотреть страшно.
          • 0
            А зачем вам смотреть _мой_ хистори?
            • 0
              А вы команды только на локалхосте выполняете?
              • 0
                Если на сервере бывает кто-то, кроме меня, то команды выполняются с sudo и опять же, это _моя_ history. Если я работаю от root'а, значит, там только я бываю, и это, опять же, _моя_ хистори.
                • 0
                  Понятно. Дальнейший спор будет просто идеологическим.
    • +1
      Если не секрет, что делает эта команда? Мой парсер сломался, насчитав нечётное количество символов " ` ".
      • +1
        Что-то мне подсказывает, что это набор команд от балды. Хотя бы по стартовому echo -n `for a in $(seq 1 20)`;

        Ну либо парсер — лох.
        • +1
          Лишняя '`' после скобки, да. А так — примерно похоже на правду — двойной параллельный цикл по результатам выполнения цикла.
    • +2
      но он не работает для '>>'

      tee -a
      или для '<'

      sudo cat
      • 0
        В zsh можно так: echo text >> file | cat.
        И даже так: echo text | cat < /etc/passwd
  • +2
    Спасибо за пост! Совпадение 9 из 9. Подняло настроение.
  • +12
    Признак 10: борода.
    • +7
      тогда уж и признак 11: свитер, 12: кот
      • –4
        Признак 13: Слака в качестве рабочей системы. ;)
    • 0
      Это клеше и штампы.
      Все настоящие профессионалы которых я знаю и с которыми довелось работать не имеют этих фрик атрибутов, а очень опрятны и вежливы в общении.

      PS: настоящие ПРО(10-15 лет опыта в крупных системах) большую часть времени работают под su, иначе считай сидят под рутом.
      • +4
        Всё зависит от ситуации.

        На сервере где админит несколько человек требование выполнять все команды через 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 я дома использую исключительно в скриптах.
        • 0
          Sudo очень полезен для запуска отдельных команд под рутом, для скриптов, в частности. :)
        • +1
          Дома у не очень опытного пользователя запуск через sudo — имеет смысл хотя бы ради того, чтобы он не делал от рута то, что можно сделать от пользователя.


          Кого вы обманываете? На sudo стоит суидный бит и овнер рут, и никакого обычного пользователя в этом случае нет.

          Я админю линух уже лет 20
          Ядру Linux исполнилось 22 года ;)
          • +3
            Я начинал на слаквари, примерно в 94-м. Мой фидошный босс (тогда у меня ещё своей ноды не было) пришёл в гости, и помог установить, за пиво, разумеется.
        • 0
          Не холивара ради, но из любопытства: почему именно много терминалов, а не один со screen в нём?
          • 0
            Переключаться мышкой? Или, хотя бы, видя визуальное представление.
          • 0
            Одна из причин — в тех терминалах, в которых запущена ssh на сервера запущен и screen (на сервере). Другая — screen всё-таки не идеален, он не является полноценным аналогом терминала, некоторые приложения использовать в screen не так удобно (например из-за конфликтов по горячим клавишам), плюс моя рабочая среда сложилась очень много лет назад, когда screen работал не так хорошо, как сейчас. Третья — используя виртуальные рабочие столы вместо screen я получаю единообразный способ переключения между всеми приложениями (включая графические: pidgin/opera/etc.) и возможность запускать рядом (на том же рабочем столе) с конкретным терминалом связанные с решаемой в нём задачей приложения.
        • 0
          А зачем «постоянно открыта пара rxvt с su -»? В штатной работе, если система нормально настроена, то нет никакой необходимости в постоянно открытом root'е. Достаточно прописать себя в операторские группы…

          Для меня постоянное сидение под root'ом — это признак непрофессионализма Unix-администратора. Ну, кроме случаев когда админ занимается вводом в эксплуатацию новых систем

          Я использую sudo для запуска пакетного менеджера для обновления системы, реже для манипуляций процессами init.d|systemd, ну изредка что-то поправить в /etc…
          • +1
            А я вместо использования для этого sudo просто нажимаю одну кнопку (из дополнительных user-defined кнопок) и попадаю в рутовый терминал, где все эти команды набирать значительно удобнее.

            Что касается «постоянного сидения под root». Если под рутом делать обычную работу (запускать X-ы, писать скрипты и документы, смотреть фильмы) — да, это признак непрофессионализма. А если где-то там, в фоне, в неиспользуемом виртуальном рабочем столе заранее открыт рутовый терминал, который используется только когда надо обновить систему или что-то настроить — в чём же тут непрофессионализм?
            • 0
              Вариант… У меня одно время рутовый терминал тоже автоматом запускался… Потом стало просто лень…
      • +1
        Это что же, борода теперь считается признаком неопрятности? Посыпаю голову пеплом тогда.
        • 0
          я просто оставлю это тут дабы порадовать собратьев с растительностью на лице www.youtube.com/watch?v=KlgbKIswpzI
          • +2
            Борода — наше всё!
        • 0
          Пепел на голове — это уж точно признак неопрятности.
      • 0
        Ну, скажем так, если система не слишком бизнес-критичная, то можно и под рутом работать независимо от квалификации, достаточно уметь думать головой, не торопиться и быть внимательным. Когда речь идёт о живом продакшне… а собственно туда и лезть не нужно, если он работает. Для мониторинга статуса можно использовать любимую систему, а в случае серьезных проблем уже не так важно под кем вы сидите.
      • +1
        Ога. Я когда в начале 2000 начал работать в одной провайдерской конторе, где линукс и фря были наше фсе увидел такую же картину. Сидят постоянно под рутом. Если не нужен рут, то зачем вообще запущена консоль, нефик там делать.
        Причем ламерами ну никак их назвать было нельзя, олдскульные товарищи.
  • +5
    Стыдно признать, но использую mcedit для лёгкой правки конфигов. Привычка наверное. Хотя без проблем владею vi или странным nano, если нет mcedit. А если уж и этого нет, то cat | sed — вполне себе редактор файлов.
    В остальном всё совпало по пунктам. Хороший пост.
    И кстати согласен с amarao по поводу однострочных скриптов.
    • –1
      Я, наверно, совсем странный: редактирую файлы локально в системе контроля версий редактором Sublime Text, а потом даю команду на pull изменений на сервера.

      И даже команды, если они нетривиальные, подготавливаю в этом же редакторе, потом копирую-вставляю их в шелл. Делаю так, потому что удобно писать многострочный код, и файл с историей команд и комментариями можно сохранить себе на будущее, дав ему красивое имя.
  • +2
    У меня 8 из 9. Пока только начинаю познавать дао регэкспов.

    Можно добавить 11: мы всегда делаем бекапы конфигов перед правкой.
    • +3
      Бекапы? Только реал-тайм, только хардкор :)
      Что сломалось все в scrollback buffer.
      Или курить маны и понимать конфиги.
      Короче говоря, если что сломал, то значит хреново конфиги знаешь.
      • +1
        В vim недавно появилась фича «постоянный undo» — т.е. возможность сделать undo даже после того, как ты записался и вышел из редактора. Она вполне заменила необходимость бэкапить конфиги перед правкой.
        • 0
          Мечта Темы Лебедева — прийти через год и сделать Ctrl-Z ;-)

          Спасибо за наводку.
        • +1
        • 0
          Надеюсь, эта фича сохраняет в истории изменений хеши изменённых файлов, иначе страшно представить, что будет при отмене правок в файле, который после них правили в другом редакторе.
    • 0
      Аналогично с вами у меня 8/9, хоть и не админ вовсе по профессии, но к регуляркам отношусь крайне отрицательно, но пользоваться научусь, нужно знать врага в лицо.
    • 0
      > Можно добавить 11: мы всегда делаем бекапы конфигов перед правкой.
      git init; git commit -a -m «initial commit»

      Нет, правда. Программы должны лежать в пакетах, а конфиги — в репозиториях.
      • +1
        В теории — да. А на практике от использования git/hg получается значительный оверхед без заметной отдачи. При наличии ежедневных бэкапов в облако и persistent undo в vim у меня на куче машин за много лет было всего несколько случаев, когда очень хотелось узнать, когда и зачем именно были внесены какие-то изменения в конфиги. И во всех этих случаях в результате выяснялось, что сейчас, спустя много времени, эти изменения уже неактуальны. Что характерно, и бэкапы и undo работают автоматически, не требуя от меня ни выполнения дополнительных команд после каждого изменения конфигов ни введения описаний сделанных изменений.
        • 0
          Ну, скорей всего у нас несколько разные практики :)

          В моей у серверов администраторов несколько и прямого доступа в интернет у них нет (по правде говоря, мне вообще кажется немыслимой идея бэкапить конфиги серверов с весьма чувствительной информацией в облако в открытом виде).
          • 0
            А кто сказал «в открытом виде»? Всё шифруется через gpg.
    • 0
      svn и git — и не надо мусорить бэкапами. Так и делаю.
  • +14
    Без дао sed, nc и awk, а еще shell script на legacy sh список слабоват.
  • +1
    Насчет sudo vs. su — не совсем согласен. Должно быть и то и другое. Например, в «sudo apt-get install...» su явно лишнее.
    • 0
      apt-get тоже лишнее, когда есть aptitude.
    • 0
      Что-что?
      sudo su apt-get install
      

      Может так:
      sudo su
      apt-get install
      
      ?
      • +5
        Ну вот банальная ситуация: сижу под пользователем, понадобилась какая-то утилитка, а ее нет, нужно установить. 2 варианта:

        1.
        $ sudo su
        (ввести пароль)
        # aptitude install blahblah
        # exit (да, возвращаемся из рута обратно)


        2.
        $ sudo aptitude install blahblah
        (ввести пароль)


        Вопрос: зачем использовать более длинный способ, если есть возможность использовать более короткий?
        • 0
          И это вполне в духе юниксоида. Иначе лишний раз нажимать на кнопки… ;)
          • +3
            Так в том-то и дело, что хорошего юниксоида отличает здоровая лень, и я до сих пор не вижу причины, по которой кто-то использовал бы первый вариант, а не второй, кроме полной упоротости «суровости» :)
        • +2
          у меня обычно aptitude install blahblah, потом мат, потом sudo!!!
          • +2
            Через некоторое время входит в привычку. Ну, по крайней мере у меня вошло, я уже на полном автомате набираю sudo aptitude, причем даже когда это не нужно, например sudo aptitude search :)
          • +1
            Много восклицательных знаков. Должно быть sudo!!!

            UPD… sorry парсер лох
            sudo !!
          • 0
            Почему бы алиас не использовать?
            • 0
              лень же. да и программы ставятся чаще на начальном этапе а там ещё даже судо не настроен
        • 0
          Потому что su -c
  • +1
    спасибо. потешил самолюбие :D
  • +3
    Я понимаю что текст намеренно «сенсационный» и «просветляющий» (тонкий юмор, да), но тем не менее немного раздражает когда личное мнение подается под соусом единственно верного пути гуру. Это я про пункты 1, 2. Думаю все понимают что однозначного ответа на вопрос «sudo vs su» и «Emacs vs vim» нет. Кому как удобно.

    Остальное — да, прописные истины.

    * Здесь должен быть комикс XKCD о текстовых редакторах, но так как он всем уже порядком поднадоел — гуглите сами *
  • +2
    Бытует мнение, что лучше быть осторожным и эффективным, а не суровым.
    • +1
      Для кого лучше?
  • –3
    Регекспы, конечно, мощный инструмент, но «несравнима ни с одним другим инструментом» — я вас прошу. Если это именно регулярные выражения, без каких-то хитрых экстеншнов, то у них полно ограничений по определению.
    • 0
      В статье дан хороший пример, по поводу их применимости. Приведите любой другой инструмент для выполнения этой задачи. Буду благодарен.
      • +1
        Скрипт на (подставьте_любой_скриптовый_язык_например_питон)?
        • 0
          Вы не путайте скриптовый язык, для которого надо что-то установить еще в систему (это не всегда возможно) и, допустим, sed, который ныне и присно и родной бинарно, хоть и не pcre.

          Или, допустим, grep, который тоже ныне и присно, и тоже pcre может.

          Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.
          • +2
            >Вы не путайте скриптовый язык, для которого надо что-то установить еще в систему

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

            >Думаю, что скорость (желающие могут сравнить) будет отличаться в разы.

            Да хоть в десятки раз, если речь идет о миллисекундах — я, как пользователь, все равно этого не замечу :)
            А если у вас это дело используется где-то в продакшене, как многократно используемое задание на множестве данных, то там за такие финты нужно сразу стрелять.
            • –1
              Как раз дело в том, что установка чего-то свыше обычно не очень прокатывает в роутерах, например. Или разных встроенных системах, у которых бывает не очень с доступом в интернет.

              В остальных случаях — да не вопрос. Но речь как раз о духе Unix, т.е. о том, что не надо плодить сущности сверх необходимого. И устанавливать, например, PHP из исходников только потому, что мне надо что-то обработать, а я не знаю регулярных выражений — ну как-то глупо, не находите?
              • +2
                >И устанавливать, например, PHP из исходников только потому, что мне надо что-то обработать, а я не знаю регулярных выражений — ну как-то глупо, не находите?

                Разумеется, глупо. Как и любая другая крайность, в которую вы вдруг захотите удариться в следующий раз ;)
              • 0
                А почему глупо? Это как раз не пложение сущностей. Ну или, если угодно, пложение в обоих случаях — или плодите трансляторы языков на винте, или синтаксисы языков у себя в памяти. Минимально необходим вообще только ассемблер, и то в машкодах можно писать.
              • 0
                Perl смотрит на вас с укором.
        • +1
          а на этом (подставьте_любой_скриптовый_язык_например_питон) парсить текст регуляркой, ага ^_^
          • 0
            Не обязательно :)
      • +1
        Мне кажется что задача, например, «провалидейтить IP адрес» гораздо более реальна нежели та синтетика которая указана в статье. Напишите просто так для себя регулярку которая проверяет IP адрес на валидность (и да, при этом не заставляйте людей забивать числа в IP нулями до трехзначности — это задача для машины).

        И не забывайте про старую поговорку о двух проблемах (-;
        • 0
          Если на коленке, просто как защита от нечаянных опечаток — /^\d+\.\d+\.\d+\.\d+$/. А если нужно полноценно проверить, то зачем писать то, что уже давно аккуратно написано:
          use Regexp::Common qw /net/;
          /$RE{net}{IPv4}/
          
          • +1
            Вот вы, собственно, и привели пример того, как Perl по мощности превосходит чистые regexp-ы — ведь он включает в себя и их, и другие вещи (такие как модули для повторного использования). Что и требовалось доказать (-:

            В инструментах, ограниченных только regexp-ами, вроде grep, такую конструкцию не применить.

            Более того, есть вещи, которые люди регулярно пытаются делать регулярками, хотя для них это совершенно не уместно. Вроде выпарсывания чего-нибудь из XML. Stackoverflow забит вопросами вроде «как мне заматчить регуляркой открывающий+закрывающий тег в XML» с ответами «не используйте регекспы для парсинга XML!»
  • 0
    8 из 9, иногда грешу nano`м :))
    • +3
      Тоже сначала им пользовался, пока vim не выучил. Недавно запустил nano и подумал: «блин, как из этой хреновины выйти так чтобы все сохранилось» :)
      • 0
        у меня вот как-то с nano не сложилось. наткнулся на joe раньше, чем на него. а потом и vi освоил в достаточной для сносного использования степени.
      • +2
        А я вот на заре освоения unix выходил из vi ресетом :)
      • 0
        Ctrl+X, Y, Enter
  • –9
    раздули тут понимаешь — 10 лет сижу под root и не парюсь за всякие sudo, su и дргую ересь ,-)
    • +1
      rm -rf /
      • +4
        rm -rf --no-preserve-root /
        fixed
      • +1
        Камрад Бармин и его патч наше всё! :)
    • +2
      Вы ждете пока сами себе отстрелите ногу, или пока это сделают за вас?
      • 0
        Ох, как повелись некоторые камрады.
        Во-первых: на этих машинах как-правило один админ, который как бы знает что и зачем он делает.
        Во-вторых: кто-нибудь из выше отписавшихся хоть раз за последние 3-5 лет набирал руками «rm -rf /» для решения каких-либо практических задач (кроме того когда это делалось намеренно чтобы проверить этот 100-летний баян)?
        В-третьих: думать головой надо всегда.
        • +3
          А вы что, уже не помните?
          -rm -rf /usr /home/.temp/kde
          +rm -rf /usr/home/.temp/kde

          Такую ошибку может совершить кто угодно. Пальцем пробел задел и привет. А если это не /usr, а допустим /etc /httpd/config.temp
          • –3
            Эту историю я помню, конечно, но:
            1. Для того чтоб не набирать это руками существуют простые вещи типа mc и копирование мышкой, но и это не значит, что не надо думать головой
            2. Зачем KDE на веб-сервере?

            самое забавное, что за 10 лет моей практики снесли кое-что нужное ОДИН раз, и то из под mc, под юзером (не рутом), и это сделал сам юзер с частью своей же папки. И от невнимательности. Но для этого есть бекап
            • 0
              Да причем тут кде? Я же привел пример:
              rm -rf /etc /httpd/config.temp вместо rm -rf /etc/httpd/config.temp
              • 0
                Да я понял ваш пример :-)
                Для того чтоб так не получалось надо иногда включать голову и аргументы некоторых потенциально опасных команд экранировать, к примеру, апострофами, если уж вы по клавишам не попадаете и ничего лишнего не удалится.
                rm -rf '/etc /httpd/config.temp'
              • 0
                в никсах с этим легче так как всегда есть TAB чтобы добраться до файла или диры
                в вашем примере не спасет не sudo, не su так как: администраторам все равно приходится делать все административные задачи под root.
                Отличный пример тому установщик нвидии который как раз запускался только из под рута
                • 0
                  Не, я говорил про сидение из-под рута.
  • –1
    > с надувным кругом в животе

    Как вы начинающих пловцов не любите :)) — «в животе». В оригинале — «Using sudo exclusively is like bowling with only the inflatable bumpers in the gutters».

    А про перезагрузку 100 раз верно — мало когда она помогает. Если есть проблема настройки, скажем, веб-сервера, перезагрузка (вбитая в привычку после Windows) вряд ли поможет )
  • 0
    Мы уверены, что перезагрузка нужна только в случае изменений ядра или аппаратной части, а решение проблемы при помощи перезагрузки — временное ...

    Во фре есть замечательная возможность урезать права руту, но чтобы изменения вступили в силу надо перегрузиться.
    • 0
      Зачем? Если хочется граничить права самому себе, то проще забыть пароль рута…
  • 0
    А если случалась неведомая фигня, надо обновить ядро… так на всякий случай на рефлексах) Примерно как в винде перезагрузить.
    • 0
      Если системная фигня, то да. Часто это помогает. Особенно если проблема как-то связана с взаимодействием с железом. Один раз правда был случай — ни в какую не помогало. Оказалось, что нужно было отрубить что-то в ядре (уже сейчас не помню) и сразу полегчало. А так на дню по несколько паников на пустом месте. В ядре копаться и осознавать что оно говорит уже крайне сложно к сожалению(
    • 0
      А если-бы Линукс был микроядерным, то и перезагрузка была-бы излишним телодвижением. Эх мечты мечты…
  • 0
    sudo tcsh. Потому что не пингвин, а в кедах ;)
  • +2
    Не знаю как у суровых админов, но я как-то не смог себя приучить к vi/vim и каждый раз плююсь, когда приходится с ними работать. При первой возможности ставлю nano/pico. Уже руки под него заточены за 12 лет. Да и админю в основном Фряхи — там я получаю от этого удовольствие, которое в линуксе получить даже рядом не получалось (разве только дебиан по-приятнее всех).
    Наверное, я не слишком суров и сликом капризен. Печалька.
    • 0
      В Фряхе есть ee и не нужны наны да пики :).
      Сам vi/vim не терплю, хотя стаж тоже 12 лет.
      АХаххахаха, Махмуд, ты оказывается :).
  • –1
    По поводу споров насчет sudo и su стоит вспомнить статью su или sudo?
  • –1
    Избегаю использования vi и vim.
  • +1
    Emacs для unix-программеров, Vi для unix-админов… Vim — для линуксоидов.
    vi — это стандарт де факто для unix-систем. Если вы себя считаете unix-админом в глобальном смысле, а не админом конкретного дистра или unix-системы, то vi надо знать.
    Чтобы понять что такое vi, надо немного вникнуть в историю вопроса, понять, что какой была консоль изначально и разобраться с ed и ex. Они тривиальные. Но после этого vi всё встанет на свои места. Просто все учат его не с того конца.
  • 0
    Полгода Фряхи(и никакого линукса) и я суровый админ. Я много раз пытался разные Линуксы ставить(Убунту, Фидору, Центос) но как-то неприятно в них учиться работать было. Поставив Фряху я поразился лаконичности, логичности и стройности применяемых решений.
    • 0
      примерно то же ощущение было когда первый раз поставил Gentoo. лет эдак 10 назад.

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