Ответы пользователя по тегу Системное администрирование
  • Как избавиться от ошибки с кодировкой при создании контейнера?

    @hx510b
    "Я знаю, что ничего не знаю"
    Попробуйте добавить в конфиг файл mysql, например так:
    [mysqld]
    init_connect='SET collation_connection = utf8mb4_unicode_ci'
    collation-server=utf8mb4_unicode_ci

    Чтобы прокинуть конфиг во внутрь docker образа используйте опцию -v
    -v /local/path/to/hosts/config/collation.conf:/etc/my.cnf.d/collation.conf
    Ответ написан
    Комментировать
  • Где целесообразно использовать LXC/LXD?

    @hx510b
    "Я знаю, что ничего не знаю"
    LXC удобно использовать для отвязки от ОС хоста, как современный аналог OpenVZ (OpenVZ устарел, т.к. не поддерживается новыми ядрами и дистрибутивами). Мы использовали LXC для виртуализации Linux сервисов. LXC значительно эффективнее расходует ресурсы, чем KVM.
    LXC внутри больше похож на виртуальную машину, чем Docker. В LXC почти все привычные инструменты работают как обычно. Но изолированно от хост системы. Можно ставить пакеты, менять настройки etc, запускать демоны и использовать стандартные инструменты Linux среды и т.д. Для LXC можно подтянуть специфичные для дистрибутивов шаблоны. Например, на хосте с Ubuntu поднять гостя с Centos. При желании гостя можно держать на виртуальном диске.

    Еще про разницу между LXC и docker написано тут: https://vps.ua/blog/docker-and-linux-containers/
    Ответ написан
  • BASH: как удалить огромное количество директорий, содержащих директории и файлы?

    @hx510b
    "Я знаю, что ничего не знаю"
    find /pathto [ options ] -delete
    удаляет то, что задано и быстрее всех
    причем без ключа -delete можно проверить, что список тот который хотелось.
    Ответ написан
    1 комментарий
  • Как эффективно защитится от брут-форса на VPS сервере?

    @hx510b
    "Я знаю, что ничего не знаю"
    На мой взгляд надо заставить веб-клиента делать какую-то работу, например, ставить куку и смотреть, что он ее предъявил, с помощью javascript на стороне клиента проводить простые вычисления, но не предсказуемые вычисления, которые он должен предъявить.
    Брутфорс наверняка идет в отношении конкретного аккаунта, можно на каждую неудачную попытку увеличивать время ответа, чтобы разительно снижать темп перебора.
    Можно начать показывать CAPTCHA в случае детектирования таких проблем.
    Можно сделать блокировку учетной записи в случае N неудачных попыток за период времени.
    Возьмите за образец логику PIN кодов банковский карт - 3 неудачных попытки - блокировка карты. Поэтому даже весьма простой 4-х численный PIN код становится не подбираемым брутфорсом.
    Существуют различные практики приблизительной деанонимизации веб-клиента, которые позволят установить, что с разных адресов идет один и тот же веб-клиент.
    Ответ написан
  • Как интерпретировать load average?

    @hx510b
    "Я знаю, что ничего не знаю"
    Сложное объяснение, но видимо методически правильное есть в статье https://habr.com/company/mailru/blog/335326/
    Как показывает практика - LA связан не только с вычислительной нагрузкой на CPU, но зависит и от ввода вывода и других факторов состояния системы.
    При определенных обстоятельствах вполне можно наблюдать LA в несколько тысяч, при фактически не загруженных процессорах и обычном количестве и состоянии процессов.

    Я для себя LA интерпретирую как комплексный показатель нагрузки на систему.
    Упрощенно можно воспринимать как некий эфемерный показатель длины очереди процессов на исполнение - это условное заведомо неверное толкование, но вполне применимое в реальной работе.
    Интерпретация значений LA:
    Где значения от 0 до 1 указывают на не нагруженную систему близкую к простою.
    Значения от 1 до 10 - как умеренно нагруженную систему. Все нормально.
    Значения от 10 до 30 - как высоконагруженную систему. Не следует добавлять нагрузку. Можно подумать о поиске оптимизации нагрузки. Оптимизация рекомендуется.
    Значения от 30 до 100 - как чрезмерно нагруженную систему, например, причиной может быть большая доля iowait из-за перегрузки - большое количество потоков ввода вывода на одно блочное устройство, аномально медленная работа блочного устройства из-за неисправности, другие подобные причины, связанные с возникновением "бутылочного горлышка" в системе, которое надо расшивать - при таких значениях LA - производительность неэффективная. Оптимизация необходима.
    Значения выше 100 - следует воспринимать как аварийное состоянии системы с точки зрения производительности. Нужно принимать меры безотлагательно.
    Значения выше 1000 - и дальнейший рост LA ведут к падению ядра, как правило, падение системы происходит в течении ближайших нескольких часов. Требуется экстренная реакция для избежания отказа систем и потери данных.
    Границы указаны примерные на основе своего опыта.
    Ответ написан
    Комментировать
  • Как исправить ошибку: Lost connection to MySQL server during query?

    @hx510b
    "Я знаю, что ничего не знаю"
    Судя по:
    Error in `/usr/sbin/mysqld': malloc(): memory corruption: 0x00007fcbfc124080

    1. сделать копию /var/lib/mysql на другой накопитель

    2. Исследуем и решаем:
    2.1. вариант1 - битая память - прогнать memtest, может перегрев системы? устраняем или, если обе проблемы не подтверждаются, то идем дальше. Хотя тут похоже сторонний виртуальный сервер. Но проблема может быть.
    Если проблема с ОЗУ, то протестировать внутри ОС можно созданием сжатых архивов и проверкой их целостности, в случае проблем с ОЗУ рано или поздно появятся ошибки контрольных сумм.

    2.2. вариант2 - либо испорчены файлы данных, и mysql становится плохо из-за кривого кода. файлы могут быть испорчены некорректным завершением работы сервера либо проблемами с блочным устройством:

    2018-08-20T05:10:47.359613Z 0 [ERROR] InnoDB: Could not find a valid tablespace file for `kubium/game`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.
    2018-08-20T05:10:47.359626Z 0 [Warning] InnoDB: Ignoring tablespace `kubium/game` because it could not be opened.

    - это может быть косвенным признаком проблем с файлами.
    2.2.1. проверяем состояние блочных устройств smartctl - наличие offline uncorrectable или relocated sectos - могут быть причиной порчи данных - замена накопителя. Для чужого хостинга это недоступно. Можно косвенно проверить чтением блочного устройства /dev/vda
    2.2.2. проверяем fsck файловую систему, наличие ошибок в файловой системы может указывать на повреждение содержания файлов БД. чиним и молимся, что важнейшие файлы не были задеты.
    2.2.3. проверяем структуру innodb/myisam файлов, для этого используем штатные средства диагностики или вспомогательные утилиты, например "Percona Data Recovery Tool for InnoDB can help recover corrupted or deleted InnoDB tables. https://launchpad.net/percona-data-recovery-tool-f..." если проблемы - пытаемся чинить.
    Простой старый способ решения некоторых проблем - это dump базы в sql файл , и импорт заново в базу. старую можно переименовать.
    2.2.4. проблема может быть вызвана повреждением файлов индексов, в этом случае пересоздание индексов может все решить.

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

    На машине немного памяти - 1Гб, при исчерпании свободного ОЗУ в системе запускается OOM Killer, который убивает процессы в системе, вполне мог убить процесс mysql прямо посередине критичного изменения файлов БД. Это можно найти в логах.
    Ответ написан
    1 комментарий
  • Как обеспечивается совершенно бесперебойная работа сервера?

    @hx510b
    "Я знаю, что ничего не знаю"
    Вариант №1 - создание отказоустойчивого кластера - два физических сервера работают в паре, при этом один сервер выполняет работу, а второй сервер работает в резерве, при этом получает актуальные копию данных с первого сервера, делается разными инструментами. В случае гибели первого сервера, второй берет нагрузку на себя.
    Вариант №2 - применим для веб-сайтов - пользовательские запросы направляются на сервера по определенным правилам на несколько серверов, в случае выход из строя одного из серверов - нагрузка вырастает на оставшиеся.
    Вариант №3 - географически разнесенные дубликаты сервисов - самый надежный вариант, но кластер на длинных расстояниях сделать очень сложно - возникают проблемы с пропускной способностью, задержкой передачи и временными перерывами связи - не все протоколы, работающие в локальной сети способны справиться с этой проблемой.
    В целом задача решается с применением известных решений с учетом специфики решаемой задачи и существующей архитектуры сервиса.
    Простого решения - панацеи от всех проблем нет.
    Ответ написан
    2 комментария
  • Какую ФС выбрать для бэкапов?

    @hx510b
    "Я знаю, что ничего не знаю"
    Под такие задачи вполне хватит EXT4
    Не надо хранить на одном большом томе миллионы файлов - этим потом управлять сложно - долго копировать и даже долго удалять.
    Храните в файлах архивов или образах дисков виртуальных (loop devices) за счет sparse можно получить такую же плотность размещения.
    Ответ написан
    Комментировать