Начинайте думать



    Доброго времени суток дорогой %username%!
    Хотелось бы поздравить с праздником всех админов и в честь этого накатило на меня написать пост. По роду своей деятельности (*nix админ), ко мне обращаются знакомые с различными просьбами о помощи по серверам. Обычно просьбы в духе — у нас стал тормозить сайт, или что-то у нас повисло и т.п. Очень часто, проблемы возникают из-за действий программистов, которые не всегда понимают что делают, либо не понимают последствий того, что они делают. Посмотрев на это все, я решил поделиться с вами некоторыми случаями и наставлениями.

    Изначально, думал назвать пост «прекратите админить» и собрать в нем типичные ошибки программистов админов, однако мысль пошла немного иначе, поэтому заголовок получился такой. Заранее хочу извиниться за сумбурность поста, просто накатило что-то написать и как мысль пошла, так и написал.


    Случай 1.

    — “Антон, у нас стал тормозить сайт. Посмотри?”
    Формулировка достаточно стандартная, поэтому для получения какого-либо понимания о происходящем лезу по ssh на сервер.
    Заглядывая в top, вижу php процесс, съедающий кучу ресурсов. Что же это? Никакого криминала лишь — remove_old_thumbs.php. Как можно догадаться, он удаляет старые миниатюры изображений. И все бы ничего, но делает это он очень активно.
    iotop рассказывает о том, что скрипт очень активно мучает жесткий диск. Оно и понятно, шерстить по папкам и удалять тысячи файлов дело ресурсоемкое, особенно на виртуалках. Решение?
    ionice -c3 php remove_old_thumbs.php
    Так-как процедура удаления старых миниатюр не критичная, и не требует высокого приоритета, можно ее запустить с низким I/O приоритетом. Запускаем — процесс пошел более тихо, сайт перестал тормозить, миниатюрки потихоньку удаляются — все счастливы.

    Случай 2.

    — “Антон, мы тут миниатюры начали делать, но что-то все тормозит”
    Чтож, посмотрим. Вот те на. Ссылки на миниатюры выглядят таким образом. thumb.php?image=images/12311.jpg. Чтож, тут приходится поковыряться в коде.

    — Картинки для миниатюр лежат в одной папке, а их под миллион. Незачем насиловать fs.
    — Скрипт не сохраняет сгенерированные миниатюры. На каждое обращение он генерирует новую миниатюру — не комильфо господа!
    — Генерация миниатюр для всех картинок займет продолжительное время.

    Разбираем случай. Для начала, хорошо бы разложить все картинки по папкам. Предложено раскладывать по дате, дату брать из публикации. С этим особых проблем нет, все прозрачно и понятно. И получилось у нас как-то так: images/2013/08/12311.jpg.
    Чтобы убить последние 2 пункта, было предложено сделать адреса миниатюр такими thumbs/2013/08/12311.jpg, а в nginx настроить правило, проверяющее наличие файла по указанному url и в случае отсутствия перенаправлять запрос на thump.php. В свою очередь thumb.php генерирует миниатюру, показывает ее клиенту и складывает на диск по нужному адресу. Таким образом мы разгрузили cpu и fs, а сайт залетал.

    Случай 3.

    — “Антон, у нас стал тормозить сайт. Посмотри?”
    В процессах висит 10 процессов remove_old_thumbs.php. Ребят, ну давайте в скриптах, запущенных про крону, делать проверку на запущенность? Хотябы создавая lock-файл в /tmp, а при завершении скрипта с помощью register_shutdown_function вызывать функцию, удаляющую этот файл. Быстро и просто.

    Случай 4.

    Сильно подробно я не буду на этом останавливаться, тема хоть и очень актуальна, но каждый случай строго индивидуален. На память я пример не воспроизведу, но если коротко то:
    «SELECT * FROM posts» — мы вытянули всю базу постов, со всеми описаниями и почим мусором и активно работаем с этим массивом данных, хотя из всего массива нужен лишь id и poster_url.
    «SELECT description FROM posts WHERE post_time > '2013-01-01' AND post_moderated = '1' ORDER BY name DESC» — Представьте этот запрос с кучей join'ов и весьма массивным. И почему он вдруг тормозит? А все потому что нет индекса по полю name, а про EXPLAIN новые программисты не слыхали.

    Чтож. Приведенные случаи тянут на ошибки программистов. В чем же можно упрекнуть админов?


    Для начала вот этим:
    ssh://root:om7ooS3righoob4Xe7ri@hostname

    В 90% случаев, удаленный доступ к серверам осуществляется от пользователя root и практически сразу, эти сервера начинают брутфорсить. Это не есть правильно.
    Что можно сделать? Для начала создать пользователя, под которым потом заходить по ssh. А затем, запретить авторизацию от рута (PermitRootLogin no — запретит авторизацию от рута) в sshd_config. Чтобы получить права рута под юзером, можно набрать “su -” или настроить sudo. Не сложно же?
    Что можно сделать еще? Можно запретить доступ к ssh с неизвестных IP и не обязательно писать пачку правил для iptables, достаточно подправить пару файлов.

    hosts.deny
    sshd: all

    hosts.allow
    sshd: 123.231.132.213

    И все! Мы запретили ходить на сервер по ssh всем, кроме 123.231.132.213.

    Ок, что еще?
    [root@localhost ~]# ps auwx | grep php
    root 795 0.0 0.5 321152 9948? Ss июл22 0:10 php-fpm: master process (/etc/php-fpm.conf)
    root 884 0.0 0.3 321696 6724? S июл22 0:00 php-fpm: pool www
    root 885 0.0 0.3 321696 6644? S июл22 0:00 php-fpm: pool www
    root 886 0.0 0.3 321696 6720? S июл22 0:00 php-fpm: pool www
    root 887 0.0 0.3 321728 6720? S июл22 0:00 php-fpm: pool www
    root 888 0.0 0.3 321728 6728? S июл22 0:00 php-fpm: pool www

    Зачем php скриптам выполняться от рута? Зачем?! Все равно что оставлять ключи от машины, в самой машине. Решение в каждом случае будет разное, в данном случае в конфиге php-fpm.conf юезер меняется на нужного.

    Те, кто не стал запускать скрипты от рута, грешит другим — chmod 777. Не буду расписывать последствия и способы лечения, скажу лишь одно. Выставляйте права на файлы обдумав свои действия. И никогда не выставляйте их подобным образом
    “chmod 777 -R. “. Волею судьбы, вы можете поломать ОС, запустив команду не в той папке.

    Множество админов грешат тем, что компилят софт и ставят его в систему. Не возьмусь сказать, что это огромное зло, но все же это зло. Знакомо ./configure && make && make install? Ребят, не поленитесь найти пакет. Если нет пакета, попробуйте воспользоваться тем же checkinstall.

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

    Comments 96

      +1
      С праздником!!! =)

      <zanuda_mode>
      Чтобы запустить fpm пулы от рута, недостаточно просто указать user/group root в конфиге пула ( который, между прочим, принято держать не в общем php-fpm.conf а отдельным конфигом в pool.d ), а нужно еще в инит скрипте в список DAEMON_ARGS добавить "-R", ибо стандартно пул под рутом у вас запуститься не должен.
      </zanuda_mode>
        0
        Ну это если говорить про debian/ubuntu.
        +5
        Действительно, сумбурно -). Однако, для дня системного администратора подборка случаев получается интересной тематичностью дня (возможно, в комментариях имеет смысл продолжить своими случаями с описаниями более лучшей практики?)

        По первому пункту, ionice, на мой взгляд, не лучшее решение. Для больших дисковых операций лучше использовать pv, одна из самых вкусных возможностей которой с ключом "-L" — позволяет ограничить скорость чтения с диска. В случае ionice жесткий диск все равно будет использоваться под завязку. Просто с немного измененной очередью и моментная задача прочесть более-менее большой объем все таки затормозится пока не будет окончена текущая фаза работы. А с pv мы можем выделить пул скорости.

        График, на котором ограничены ресурсы при создании архива на сотни гигабайт
        image


        В копилку полезностей — используйте fail2ban. Простая возможность ограничить брутфорс паролей к вашему серверу.
          +2
          При первом заходе на свой сервер отключаю парольную авторизацию ( PermitRootLogin without-password ), генерирую сертификат и далее уже никогда не вспоминаю про брутфорс.
            +1
            Сертификаты — замечательно! Безопасность можно увеличивать практически бесконечно -). Поэтому инструменты обеспечения безопасности выбираются из специфики условий использования и соотношением уровня паранои к продуктивности работы с ней. Дабы ваш ответ не был из ряда «а я лучше», а мой бесполезным для других читателей ответом — приведу эту ссылочку на частный случай настройки авторизации по ключу к Ubuntu серверу с Windows машины.
              0
              Есть мнение что сертификат менее безопасен чем пароль — его «увести» легко.
              А вот сертификат с(под) паролем — вот это дело полезное.
                0
                Если на компьютере пользователя вирус — не спасет ни пароль ни сертификат. А против брутфорса сертификат — это выход, подобрать его в разы сложнее, чем пароль.
              +3
              В копилку полезностей — НЕ используйте fail2ban. Он не знает про IPv6 и умеет замечательно DoS'ить сервер, пока борется с брутфорсом.
                0
                Какие есть живые альтернативы?
                  0
                  psad+snort+таблицы фаирвола.
                    0
                    Совсем из другой оперы.

                    Из аналогов знаю mf2b, но выглядит он пока сыровато.
                      0
                      Опера одна и та-же, цель не допустить вторжения на свои сервера, а что мы делаем лог парсим или попытки этого самого вторжения сути не меняет, ваш f2b, при знании что он установлен, замечательно валится генерацией спуфленых пакетов от имени вышестоящего сервера либо просто забиваем весь его лог попытками соединения с кучи разных IP.
                    0
                    Для SSH — sshguard.
                      0
                      Кроме ssh много чего бывает. Нужно универсальное.
                        0
                        Не бывает универсального. Точнее, есть — fail2ban — и оно плохо работает именно тогда, когда нужно, чтобы работало хорошо. Проблема глубже лежит к сожалению.
                          0
                          Это не отменяет наличие задач, которые им как-то да решаются. Я не защищаю, сам ищу вменяемую альтернативу :-)
                            0
                            Есть обходные пути с запуском анализа логов и блокированием после достижения определённого лимита неудачных попыток аутентификации. Но это требует от приложений сообщать о таких событиях с минимальными накладными расходами, что не всегда возможно. Насколько я знаю, вменяемых альтернатив нет. Да и на мой взгляд если писать универсальное средство, то всё в итоге упирается в парсинг логов, что, мягко говоря, процесс небыстрый. Вот если бы был какой-то общепринятый стандарт сигнализации для приложений, но это была бы совсем другая вселенная.
                        0
                        Он не только для ssh, а еще для кучи всего. Не вводите evg_krsk в заблуждение.
                          0
                          Спасибо, посмотрю. Никому нельзя верить :-)
                        +1
                        csf+lfd
                          0
                          Спасибо, выглядит интересно.
                        0
                        Можно, пожалуйста, поподробнее про DoS? Так как для IPv6 я его почти в порядке изучения питона доработал взяв за основу информацию из их wiki.
                          –1
                          Логи пишутся с ужасающей скоростью, демон начинает загребать и без того малодоступные ресурсы под себя, чтобы всё это распарсить, и в итоге помогает уложить сервер. Сразу скажу, я такое видел один раз только, но осадочек остался.
                            0
                            Ну не надо парсить логи, которые могут писаться с ужасающей скоростью. А те котороые парсить настраивать только то, что нужно для fail2ban'а.
                              0
                              Свежая идея. Но что же делать, если это уже был отдельный лог только с ошибками Авторизации именно для fail2ban? Ещё более как-то его настроить? Кстати, тоже пробовали. Писать только каждую десятую неудачную попытку, например. Помогло по началу, но «с той стороны» тоже не идиоты сидели.
                      0
                      Со всем согласен, кроме установки пакетов. Почему и сорцов ставить софт хуже? Лниуксы не админил, только Фряху.
                        +1
                        дальнейшая поддержка актуальности пакета, поставленного не из репозиторев под большим вопросом, если таких пакетов больше нуля.
                          +1
                          Нет ничего плохого в установке пакетов из исходников. Однако, вопрос как именно их ставить. Стандартно через make install — не лучшее решение. Особенно после ситуации, когда пакет оказывается потом ненужным. Все установленое «рассасывается» по системе непонятно куда. Поэтому есть решение получше — собрать свой пакет из исходников, который затем устанавить. Пример статьи как это делается на примере Ubuntu.
                            +2
                            Потому что не у всех пакетов есть нормальное правило для make uninstall.
                            [facepalm]Я буду обновлять комментарии прежде чем писать свой[/ facepalm]
                              0
                              На FreeBSD из сырцов — только через ports. Потому что иначе управлять всем этим вручную скомпилированным зоопарком со всеми зависимостями и т.п. становится нереально через какое-то время. Ну, и гораздо проще ведь сделать
                              cd /usr/ports/<chapter>/<tool_name> ; make install clean
                              И получить через какое-то время установленный по всем правилам софт со всеми зависимостями, фряшными стартовыми скриптами и т.п.
                                +1
                                На Linux, если вы не на слаке (хотя там тоже появился пакетный менеджер говорят), подавляющее большинство работает с пакетами. Если же админ на Linux ставит приложение из сырцов, то он как правило знает что делает…
                                Должно соблюдаться простое правило: Из сырцов собираем пакет и его уже устанавливаем… Ставить на прямую минуя штатный пакетный менеджер — это гарантированная попаболь в будущем…
                                Для FreeBSD c некоторых пор придерживаемся того же правила…
                                Более того, мы делаем локальные репозитории пакетов ставим им самый большой приоритет. Если в локальных репозиториях пересобранных пакетов нет, то ищем в публичных…
                                +2
                                Не вижу ничего страшного в брутфорсе, если пароль вменяемый (сгенерирован ГСЧ, имеет достаточную длину). Создавать отдельного юзера, чтобы первым же действием заходить по рута — ну просто не понимаю смысл этого действия.
                                  +2
                                  Например, небольшой смысл в том, что брутфорсеры «любят» подбирать пароли именно к «root» имени. Есть меньшая вероятность подбора пароля к пользователю «superuservasya».
                                    0
                                    Выключить логин от рута и снизить вероятность брутфорса его до нуля. Ну и заходить сразу под рутом не обязательно, если, конечно, задача того не требует.
                                      +6
                                      Сбрутфорсить имя вашего юзера + пароль, а потом сбрутфорсить пароль рута теоретически возможно. А практически невозможно как это, так и просто брутфорс 12-символьного случайного пароля, например. Смысл от меня по прежнему ускользает.

                                      Если вы выделяете задачи для этого отдельного пользователя, которые потом запускаются, например, по sudo, это другой вопрос и с этим подходом я согласен. Но создавать юзера-прокси для того, чтобы потом сделать su/sudo -i я смысла не вижу. Лишний шаг, не улучшающий безопасность никоим образом.
                                      0
                                      Заходить строго своим юзером нужно для порядка. Заходишь на сервер — представься, пожалуйста.
                                      Другая причина — менять пароль рута бывает страшно на продакшене (что может внезапно отвалиться, никто не знает). Поэтому пароль не меняют. Увольняется админ Вася — блокируем учётку vasya. И пароль рута менять не надо, и нет головной боли, что кто-то может зайти, используя информацию от уволившегося сотрудника.

                                      Впрочем, если у сервера один админ, запрет входа рутом это лишнее.
                                      –1
                                      О первых трех случаях хочется сказать, что эти программисты дебилы.
                                        +6
                                        Не дебилы, просто у них нет достаточного опыта.
                                          0
                                          Eще в далеком 2008 году, когда еще и не было намека на border-radius и css3, а я верстал простенькие сайты и ходил в 9 класс, я уже знал, что не стоит складировать изображения пачками в папках, и кешировать все трудоемкие операции если не хотите получить джумлу. Об этом даже Фленов помоему писал, которого так не любили на винграде. А сейчас что? У нас парнишка в Днепропетровске прошел курс в академии Шаг и плати ему теперь по 800 долларов за элементарный форм билдер на jQuery Mobile.
                                          +2
                                          Скорее студенты…
                                            0
                                            О, и имя им легион. Часто сталкиваюсь с таким говнокодом, причем обычно это продукт «известных» и «уважаемых» веб-студий и им подобных.
                                              0
                                              Да ладно, обычное дело, если аутсорс)
                                                0
                                                Просто каждый должен заниматься своим делом…
                                                0
                                                Случай 3.
                                                При запуске скрипта создался файл.
                                                Скрипт по каким-то причинам не откработал до конца и лок-файл не удалился.
                                                Больше скрипт не запускается, т.к. лок-файл существует.
                                                Приплыли?
                                                  +1
                                                  Случай 3.
                                                  pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.

                                                  Лок-файлы не умное решение.
                                                    +4
                                                    С лок-файлами уже всё давно придумано за нас. flock (man 1 flock) достаточно умный. Грепать по списку процессов — вот где не умное решение. Вместе с неидемпотентными скриптами такой подход может произвести совершенно феерические спецэффекты.
                                                      0
                                                      Дополню про греп имени процесса.
                                                      Был у нас замечательный скриптик бэкапа/рестора файрбердовских баз, здоровенный, умный.
                                                      И отслеживал он свою запущенность именно грепая свое имя в списке процессов.
                                                      И однажды, на свежеустановленной системе, он работать перестал, потому что при грепе в вывод стал попадать и сам греп.
                                                      Т.е. с точки зрения скрипта он был запущен всегда.
                                                      После этого переехали на генерацию/проверку pid файлов, а потом уже и на лок файлы.

                                                      (PS: а про pgrep никто тогда не вспомнил)
                                                    +4
                                                    Лок файл в скрипте открывается на эксклюзивную запись, если скрипт умер — ядро блокировку само снимет.
                                                    Если залочить на эксклюзивную запись удалось — значит работаем, не удалось — кто то другой работает, отваливаемся.
                                                      0
                                                      Register_shutdown_function выполняет функцию после того как скрипт отработал, даже если выполнение прервалось по ошибке или даже die. А на случай ребута, хорошо бы класть этот локфайл в tmpfs (хорошо нынче в linux он практически везде есть). Возможно конечно есть тут подводные камни и есть вероятность, что схема отработает коряво, но я пока такого ни разу не встретил за свои годы.
                                                        +1
                                                        Можно и без tmpfs:

                                                        flock($GLOBALS[__FILE__] = fopen($_SERVER['PHP_SELF'], "r"), LOCK_EX | LOCK_NB) or exit(-1);

                                                        В этом случае для работы блокировки больше ничего не нужно делать.
                                                      +8
                                                      WhiteList для доступа на сервер? Серьёзно? А если провайдер вам IP поменяет, что делать будете? А если ещё и предупредит (как это всегда делается) только на сайте и вы об этом узнаете постфактум, когда сервер скажет «обломинго»?
                                                        0
                                                        Port knock. Jump server. Сменить провайдера. На выбор.
                                                          0
                                                          Ну Port knock — годное решение. Jump server не защищён в полной мере от этой проблемы (хотя уже на порядок лучше, согласен). При смене провайдера IP поменяется сразу (покажите мне того провайдера, который вообще никогда не поменяет IP, если он был жёстко прописан в договоре/доп. соглашении?)
                                                            –2
                                                            byfly / Белтелеком уже четыре года не менял мне IP.
                                                          0
                                                          Да ладно, что вы паникуете! Всегда есть вариант «кусать локти»))
                                                            0
                                                            Прочитайте заголовок статьи! Если есть вероятность того, что провайдер сменит IP — думайте. У меня на серверах указано несколько IP, с которых я могу зайти. Если есть опасность потерять IP, впишите туда hostname который заведете на no-ip.
                                                              0
                                                              Не имейте дело с халявщиками. Иначе людей, которые держат отсветственные сервера на халявных аккаунтах, по которым провайдер может сменить ip без соответствующего уведомления, не назовёшь.…
                                                              Если провайдер сменит ip без уведомления, вам отсутствие whitelist'а ничем не поможет. Вообще такой фигней теоретически могут страдать разве что хостеры, но там услугу virtual console никто не отменял…
                                                                0
                                                                Извините, а при чём тут ip сервера? Речь идёт о ip, которым разрешено доступ по ssh. А вот с провайдерами для физ лиц (а в статье не было различия между потенциальным стартапом, который делает один человек и под это дело сервер заказал, и компанией, которая под определённые нужды берёт себе сервер. Вот для компании (даже сравнительно мелкой) можно достаточно легко (в договоре) добиться стабильного выходного ip с нормальным уведомлением в случае если по какой-то причине его придётся менять. А жёстко прописанные в договоре с ФЛ внешние IP я встречал всего пару раз и было это довольно давно (и были они в доп. соглашении).
                                                                  0
                                                                  Э=э… Про клиентскую сторону я вообще проблем не вижу… Просто прописывать нужно больше, чем один адрес…
                                                                  Для администрирования откуда-нибудь издалека, где не пойми какой ip, мы используем прокси внутри нашей рабочей сети…

                                                                  У меня, физлица, дома прописан реальный ip. Как раз именно для таких целей. Мне вообще никакого труда не составило объяснить админам провайдера для чего мне реальный ip…
                                                                    0
                                                                    И какие гранатии, что вам этот IP не сменят, какие гарантии, что при смене объявят как-то иначе, чем у себя на сайтики? В общем чтобы не поиметь проблем от нежданчика нужно иметь схему отличную от вайт-листа. Примеры — предложенный порт-кнок, проксирующий vpn,… Одновременно с бонусами защиты от потери мы получаем защиту от прицельного спуфа ip с попыткой продолбиться.
                                                                      0
                                                                      В этом мире вообще никаких гарантий нет. Гарантии что-то типа «честного слова», которые дают не очень доверяющие друг другу люди…
                                                                      Поиметь, как вы пишите, «нежданчика» можно при любой схеме обеспечения безопасности. Безопасность — это всегда ограничения, а значит потенциальные проблемы доступа… Точно также провайдер может вдруг «озаботиться» безопасностью и заблокировать «левый», по его мнению, трафик на «левые» порты, и всё вы приехали со своими порт-кноками и vpn'ами…
                                                                      Вопрос лишь в том, предусматриваете ли вы у себя альтернативные варианты доступа или полагаетесь на какой-то один. Если последнее, то вы сами себе злобный буратино…
                                                                0
                                                                А если провайдер вам IP поменяет, что делать будете

                                                                зайду со второго IP, два сразу вряд ли поменяют, правда ведь? А если мне нужно попасть срочно из очень необычного места, где нет возможности пробросить свой привычный IP — ребут сервера, после ребута есть несколько минут для доступа всем. Этакий костыль «на всякий случай»
                                                                  +1
                                                                  Тот ещё костыль… Имхается мне упомянутый первым ответившим мне человеком PortKnock куда более эффективнаня штука, позволяющая несколько увеличить секурность и при этом иметь куда большее удобство.
                                                                +1
                                                                Случай 2.
                                                                Лучше картинки разбивать по папкам не по датам, а, скажем, по первым нескольким символам хеша и по нескольким уровням, чтобы более равномерно распределить их по папкам.

                                                                Случай 3.
                                                                pgrep 'scriptname_regular_expression' || php 'scriptname' решает проблему в 99% случаев.

                                                                Странные у вас программисты какие-то, не умные.
                                                                  0
                                                                  2. Кому как. Кому-то нужно по этим файлам потом ориентироваться.
                                                                  3. Реализация может быть любой. Главное, чтобы скрипт не запускался в нескольких экземплярах.

                                                                  Не опытные.
                                                                  0
                                                                  > В 90% случаев, удаленный доступ к серверам осуществляется от пользователя root

                                                                  Какая у вас жуткая реальность.
                                                                  В моей реальности в 100% случаев под рутом не ходят.
                                                                  Пароли? Забудьте о паролях, откройте для себя чудесный мир ключей!

                                                                  И, с праздником, коллега!
                                                                    0
                                                                    Такова моя статистика. :(
                                                                    Я открыл для себя ключи давным давно. Просто не всегда есть возможность ими пользоваться. Хотя вы правы, если есть возможность и условия позволяют — ключи тоже отличный вариант.
                                                                    С праздником! ;-)
                                                                      +1
                                                                      Не могу себе представить ситуацию когда нельзя пользоваться ключами.
                                                                      Что бы это могло быть?
                                                                        +1
                                                                        Вот мне тоже стало интересно. Что такое может быть, что нельзя ключи юзать.
                                                                    +1
                                                                    Знакомые какие все ситуации :). Насчет sudo/su имхо с ключами вход по руту (а если призывают админа, то 100% придется делать что-то от рута) намного удобней.

                                                                      +2
                                                                      мои 5 копеек.

                                                                      Иногда приходят и говорят «а-а-а!!! место на диске закончилось! мы все умрём!». И тут начинается веселье.

                                                                      1. Лезешь на сервер — места до фига, но некоторые замечательные программисты считают ненужным подтирать за собой сессионные файлы. вот inod'ы и заканчиваются.
                                                                      2. Лезешь на сервер — места до фига. И айнодов полно. После пыток пользователей выясняется, что вот только что удалили огромный файл, а место всё равно не освободилось. про процессы, использующие эти файлы, можно не помнить.
                                                                      3. Лезешь на сервер — а места и правда нет (:
                                                                        0
                                                                        Первая проблема, мягко говоря, надумана. Но если такое действительно было, то надо по рукам надавать и программистам, и админу. Первым за разгильдяйство и свинарник, вторым — за использование файловых систем для локалхостов на проде.
                                                                          0
                                                                          А еще, люди забывают ставить логи в ротацию или логируют все подрят. И блин….куда же делось место…
                                                                            +1
                                                                            На пункт 2. А как это у вас до фига свободного места, если огромный файл до сих пор на диске, пусть и анлинкнутый? du покажет 0 свободного места, как ему и положено.
                                                                          • UFO just landed and posted this here
                                                                              0
                                                                              > SELECT * FROM posts субъективно будет работать быстрее чем SELECT id, poster_url FROM posts

                                                                              простите, почему это? длинный текст поста, лежащий где-то в недрах TOAST-таблиц, постгресу вытаскивать сильно медленнее, чем быстро отдавать короткий урл и id.
                                                                              • UFO just landed and posted this here
                                                                                  +1
                                                                                  Кажется, вы не знакомы с тем, как базы хранят данные.

                                                                                  В PostgreSQL, к примеру, поля длиннее 8 кб сначала пытаются скомпрессироваться, чтобы влезть в 8 кб, а потом выносятся во внешние, спрятанные от юзера TOAST-таблицы:
                                                                                  www.postgresql.org/docs/9.3/interactive/storage-toast.html

                                                                                  Таким образом, вычитка звёздочки приводит к множественным seek-ам на диске.

                                                                                  После этого данные надо отдать в ваше приложение, в лучшем случае — записав в сокет и вычитав из него (ещё два копирования в памяти), а если у вас используется какая-то ORM — то ещё и происходит раскладывание полей по объекту.

                                                                                +1
                                                                                SELECT * FROM posts субъективно будет работать быстрее чем SELECT id, poster_url FROM posts


                                                                                Забудьте о звездочке, всегда перечисляйте только те поля, которые действительно нужны. База сама выберет, какую стратегию чтения выбрать, плюс сможет задействовать покрывающие индексы.
                                                                                0
                                                                                >hosts.allow
                                                                                >sshd: 123.231.132.213
                                                                                >И все! Мы запретили ходить на сервер по ssh всем, кроме 123.231.132.213.

                                                                                Замена SSH порта на любой из upper range отлично справляется с брутом. Ограничение по IP все-же сильно влияет на возможности доступа.
                                                                                • UFO just landed and posted this here
                                                                                    0
                                                                                    > Замена SSH порта на любой из upper range отлично справляется с брутом

                                                                                    За исключением тех случаев, когда брутят конкретно тебя и настоящий порт успешно высканен нмапом.
                                                                                    +3
                                                                                    запретить авторизацию от рута (PermitRootLogin yes) в sshd_config.

                                                                                    Это как раз разрешает её)
                                                                                      0
                                                                                      Я так подозреваю, что человек скопировал строчку из дефолтного конфига просто, забыл сменить на no :)
                                                                                        +2
                                                                                        У человека, нависавшего данную статью априори не должно быть дефолтных конфигов!

                                                                                        Может, тонкая ирония, или как)
                                                                                          +1
                                                                                          Статья выдает в коллеге новичка, так что думаю, что ошибка при копировании.
                                                                                          Вот эти «90% случаев ходят под рутом» выдают новичка с головой.
                                                                                            0
                                                                                            Автору 27, сомневаюсь, что он новичок :)
                                                                                              0
                                                                                              Всякое бывает :)
                                                                                              0
                                                                                              Ошибаетесь. Первый линукс я скачивал в далеком 2002-м по dialup соединению. А плотно работаю с linux серверами с 2006-го. А то, что у меня такая статистика — не говорит о моем опыте ни слова, лишь говорит об опыте моих знакомых.
                                                                                          +1
                                                                                          А я не говорил что строчка запрещает рута, я лишь привел опцию которая в ответе за это. Но давайте исправлю, раз так подумали. :-)
                                                                                            0
                                                                                            Именно так оно и читалось)
                                                                                            Спасибо за исправление. И за ionice, кстати!
                                                                                          0
                                                                                          Кейсы 2 — 4 — жесть какая-то, и про работу от рута тоже. Имхо надо не думать призывать этих ребят, а просто держаться от них подальше.
                                                                                            +1
                                                                                            Не будьте так категоричны.
                                                                                            После разбора этих проблем, ребята выросли над собой и подобных ошибок не допускают.
                                                                                            Все мы когда-то учились набивая шишки.
                                                                                            0
                                                                                            К каждой команде программистов нужно приставлять админа с металлической линейкой, чтоб бил по пальцам.

                                                                                            У них просто в другом режиме работает голова – замечал даже по себе: если начинаешь писать что-то посерьезнее наколеночного скрипта, то мозг, находясь в programmer mode, банально решает другие задачи и может легко допустить косяк, на который в admin mode мгновенно бы среагировал.
                                                                                              0
                                                                                              Если в случае 2 у вас есть nginx, его же можно заставить самого и кэшировать миниатюрки. Плюсы — можно ограничить общий объём кэша и автоматически выбрасывать из него старье, которое никто не запрашивает.
                                                                                                +1
                                                                                                В 90% случаев, удаленный доступ к серверам осуществляется от пользователя root и практически сразу, эти сервера начинают брутфорсить. Это не есть правильно.
                                                                                                Что можно сделать? Для начала создать пользователя, под которым потом заходить по ssh. А затем, запретить авторизацию от рута (PermitRootLogin no — запретит авторизацию от рута) в sshd_config.


                                                                                                Настолько же спорное, насколько и популярное мнение (я не использую слово «неверное», так как уж очень оно популярное, а я не люблю себя считать умнее других). Не знаю как у других, но большинство работ на сервере из консоли у меня, как у администратора сервера требуют доступа суперпользователя. Поэтому работаю я под ним, просто приучил себя думать прежде, чем жать enter и аккуратно копипастить в консоль.

                                                                                                Как же обеспечить доступ суперпользователя? Прямой логин, su или sudo. Рассмотрим все три варианта. Я приверженец первого.

                                                                                                Прямой логин Вам не нравится брутфорсом? Антибрутер (sshguard или простенький самописный или что еще) + PermitRootLogin without-password убирают какую-либо вероятность брута. Для особенных параноиков могу предложить поднять openvpn и разрешить логин только из приватной сети или внедрить максимально IPv6 (на клиентах через туннели), а на серверах его много уже где дают, хотя можно и туннели, и вешать SSH на какой-то один специально выделенный IPv6 из выданного Вам диапазона (обычно конечному клиенту выдают диапазон /64).

                                                                                                su мне не нравится тем, что обеспечивает возможность повышения полномочий регулярного пользователя. И завязывает на наличие пароля у рута, который можно брутить локально, сломав какой-нибудь сервис запущенный от регулярного пользователя. Да, я знаю, что обычно возможность использовать su до рута залочена на специальную группу (обычно wheel) через PAM, но зачем вносить такую сложную цепочку в безопасность Вашей системы?! Тогда как у меня на серверах сделано либо passwd -l root, либо просто восклицательный знак вместо пароля у рута в /etc/shadow.

                                                                                                sudo в принципе не серверная вещь имхо. Она широко известна в узких кругах уязвимостью, просуществовавшей в ней на протяжении несколько лет (хоть и неизвестной большую часть этого времени публично). Да, такие уязвимости бывают в ней не часто, но если можно избежать потенциально дырявого ПО, то зачем его использовать? Желающие ссылку, пожалуйста, посмотрите в гугле уязвимости sudo сами.

                                                                                                Примечание: я говорю про ситуацию, когда только один админ (ну или несколько с одинаковым суперпользовательским доступом) имеют доступ на сервер по SSH. Когда их несколько, да еще и доступ суперпользователя дробится на несколько кусков, то без sudo\selinux\rbac не обойтись, к сожалению.

                                                                                                Only users with full accounts can post comments. Log in, please.