Быстрая установка Wordpress + PHP-FPM + Caddy с кешированием Redis в Docker
Сегодня заказчик поставил вопрос – а можно ли сделать сайт на Wordpress «нормально», без постоянной свистопляски с версиями PHP и прочего. Потому как не все хостеры предоставляют VPS на свежих версиях системы, а ручное обновление PHP часто приводит к проблемам.
Можно, конечно, только придется пойти другим путем, с использованием Docker, который все свое носит с собой. И не важно какие там версии в репозиториях.
В качестве веб-сервера вместо привычного NGINX мы давно выбираем Caddy, за более простую и прозрачную работу с шифрованием, которая снимает с администратора эту головную боль.
Ну и раз мы решили все делать по-современному, то почему бы сразу не добавить объектный кеш на Redis?
В итоге получился такой файл
Там же создаем файл с переменными окружения
Файл конфигурации веб-сервера
И файл кастомных параметров PHP-FPM
Запускаем все это командой:
Ждем пока все соберется и поднимется, потом переходим по доменному имени и выполняем стандартную установку Wordpress, чтобы заработал объектный кеш – установите плагин
На этом все, мы получили быстрый и современный Wordpress, который будет всегда использовать последние версии PHP рекомендуемые разработчиками вне зависимости от вашей хостовой системы.
Сегодня заказчик поставил вопрос – а можно ли сделать сайт на Wordpress «нормально», без постоянной свистопляски с версиями PHP и прочего. Потому как не все хостеры предоставляют VPS на свежих версиях системы, а ручное обновление PHP часто приводит к проблемам.
Можно, конечно, только придется пойти другим путем, с использованием Docker, который все свое носит с собой. И не важно какие там версии в репозиториях.
В качестве веб-сервера вместо привычного NGINX мы давно выбираем Caddy, за более простую и прозрачную работу с шифрованием, которая снимает с администратора эту головную боль.
Ну и раз мы решили все делать по-современному, то почему бы сразу не добавить объектный кеш на Redis?
В итоге получился такой файл
docker-compose.yml:services:
db:
image: mariadb:10.11
container_name: wp_db
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
MYSQL_DATABASE: ${MYSQL_DATABASE}
MYSQL_USER: ${MYSQL_USER}
MYSQL_PASSWORD: ${MYSQL_PASSWORD}
volumes:
- db_data:/var/lib/mysql
redis:
image: redis:alpine
container_name: wp_redis
restart: always
command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
wordpress:
image: wordpress:fpm
container_name: wp_app
restart: always
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: ${MYSQL_USER}
WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}
WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
WORDPRESS_CONFIG_EXTRA: |
define('WP_REDIS_HOST', 'redis');
volumes:
- wp_data:/var/www/html
- ./php.ini:/usr/local/etc/php/conf.d/php.ini
depends_on:
- db
- redis
caddy:
image: caddy:latest
container_name: wp_caddy
restart: always
ports:
- "80:80/tcp"
- "443:443/tcp"
- "443:443/udp"
environment:
MY_DOMAIN: ${MY_DOMAIN}
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- wp_data:/var/www/html
- caddy_data:/data
- caddy_config:/config
depends_on:
- wordpress
volumes:
db_data:
wp_data:
caddy_data:
caddy_config:
Там же создаем файл с переменными окружения
.env:MYSQL_ROOT_PASSWORD=your_secure_root_password
MYSQL_DATABASE=wordpress
MYSQL_USER=wp_user
MYSQL_PASSWORD=wp_password
MY_DOMAIN=example.com
Файл конфигурации веб-сервера
Caddyfile, если для тестирования нужен самоподписанный сертификат, то раскомментируйте опцию tls internal:{$MY_DOMAIN} {
#tls internal
root * /var/www/html
php_fastcgi wordpress:9000
file_server
# Сжатие
encode zstd gzip
# Кэширование статики (картинки, шрифты, стили, скрипты)
@static {
file
path *.ico *.css *.js *.gif *.jpg *.jpeg *.png *.svg *.woff *.woff2 *.webp
}
header @static Cache-Control "public, max-age=31536000, must-revalidate"
header {
X-Frame-Options "SAMEORIGIN"
X-Content-Type-Options "nosniff"
Referrer-Policy "strict-origin-when-cross-origin"
}
}И файл кастомных параметров PHP-FPM
php.ini, в котором мы переопределили лимиты загрузки файлов и лимит памяти.upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
Запускаем все это командой:
docker compose up -d
Ждем пока все соберется и поднимется, потом переходим по доменному имени и выполняем стандартную установку Wordpress, чтобы заработал объектный кеш – установите плагин
Redis Object Cache и активируйте его. На этом все, мы получили быстрый и современный Wordpress, который будет всегда использовать последние версии PHP рекомендуемые разработчиками вне зависимости от вашей хостовой системы.
👍21🔥6⚡1
Где лежат пределы уместности Docker
Такой интересный вопрос задали нам читатели и однозначного ответа на него нет. Потому что Docker имеет существенные отличия от классического подхода и их следует учитывать.
Но перед тем, как продолжить дальше, мы вспомним принцип бритвы Оккама, общая суть которого сводится к смыслу: не стоит множить сущности без необходимости. Это универсальное правило, для любых сфер деятельности.
Поэтому перед тем, как взять в руки любую технологию надо подумать: а что она мне даст? Какие задачи позволит решить лучше, быстрее, проще. И что вы потеряете в ее отсутствие.
Перед тем как переходить к Docker мы рассмотрим классический способ управления ПО в Linux – это пакеты. Пакеты – это надежно. Пакеты родных репозиториев непосредственно интегрированы в систему и риски что-то сломать минимальные.
Но здесь у нас появляется и другая сторона, пакеты привязаны к системе, если мейнтейнер не собрал для вашей версии ОС новую версию пакета, то у вас ее не будет. Вы можете подключить сторонний репозиторий или собрать ее сами, но это очень плохие практики в продуктовых системах, чреватые потерей стабильности и сбоями.
Классическая виртуализация ничего не меняет в этой схеме, просто позволяет разделить одну систему на несколько, каждая из которых будет выглядеть как полноценная ОС на полноценном наборе железа, со своим ядром, кастомными настройками и т.д. и т.п.
Контейнеризация на базе LXC это уже несколько иной уровень, хотя внешне такие контейнеры очень похожи на виртуальную машину, но на самом деле никакой виртуализацией тут и не пахнет.
Процессы и библиотеки LXC запускаются непосредственно на хосте и используют ядро и ресурсы хоста, просто ограничены своими пространствами имен (namespaces) и лимитами ресурсов (cgroups).
При этом LXC предоставляет контейнеризацию на уровне системы, в контейнере воспроизводится окружение любого необходимого дистрибутива Linux, доступен пакетный менеджер и большинство системных настроек.
Но ничего нового в работе с ПО у нас пока не появилось, просто теперь мы можем выбирать в разных контейнерах разные окружения, исходя их требований нашего ПО. Принципы управления и администрирования остаются классическими.
Docker же предлагает совершенно иной подход: один контейнер – один процесс. Окружение – только необходимые для работы процесса зависимости и библиотеки. А сам контейнер – сущность одноразовая, которая создается при запуске и уничтожается при остановке.
Все настройки и пользовательские данные хранятся в подключаемых томах на хосте, которые динамически монтируются в запущенный контейнер, также как и динамически создается сетевая инфраструктура.
В основе контейнера лежит атомарный образ, который собирается один раз и потом многократно используется, внесения изменений в образ «на ходу» не допускаются.
Все это достаточно непривычно и после классического подхода вызывает массу вопросов, особенно если нам нужно понимать многоконтейнерные связки. Но тут нам на помощь приходят оркестраторы, самый простой из которых Docker Compose.
Они позволяют описать конфигурацию приложения в виде кода, который расскажет какие контейнеры надо запустить, что к ним подключить, как связать между собой. Фактически переводя работу с системой на уровень «инфраструктура как код».
Теперь нам не нужно ставить пакеты, зависимости, проверять их версии, решать проблемы совместимости. Нам нужен только Docker, он сам скачает нужные образы, создаст указанные нами контейнеры, применит указанные нами настройки и все это будет работать.
Надо перенести на другую систему, легко – переносим файлы с описанием инфраструктуры и пользовательские данные. Все снова работает. Без оглядки на версию хостовой ОС. Это удобно, особенно когда приложение требует целый стек, причем определенных версий.
И требования приложения могут меняться. В этом случае просто меняем версию образа в докер и перезапускаем систему. Классическая проблема версии PHP, которой нет в дистрибутиве решается быстро и безопасно, легким движением руки.
Продолжение следует.
Такой интересный вопрос задали нам читатели и однозначного ответа на него нет. Потому что Docker имеет существенные отличия от классического подхода и их следует учитывать.
Но перед тем, как продолжить дальше, мы вспомним принцип бритвы Оккама, общая суть которого сводится к смыслу: не стоит множить сущности без необходимости. Это универсальное правило, для любых сфер деятельности.
Поэтому перед тем, как взять в руки любую технологию надо подумать: а что она мне даст? Какие задачи позволит решить лучше, быстрее, проще. И что вы потеряете в ее отсутствие.
Перед тем как переходить к Docker мы рассмотрим классический способ управления ПО в Linux – это пакеты. Пакеты – это надежно. Пакеты родных репозиториев непосредственно интегрированы в систему и риски что-то сломать минимальные.
Но здесь у нас появляется и другая сторона, пакеты привязаны к системе, если мейнтейнер не собрал для вашей версии ОС новую версию пакета, то у вас ее не будет. Вы можете подключить сторонний репозиторий или собрать ее сами, но это очень плохие практики в продуктовых системах, чреватые потерей стабильности и сбоями.
Классическая виртуализация ничего не меняет в этой схеме, просто позволяет разделить одну систему на несколько, каждая из которых будет выглядеть как полноценная ОС на полноценном наборе железа, со своим ядром, кастомными настройками и т.д. и т.п.
Контейнеризация на базе LXC это уже несколько иной уровень, хотя внешне такие контейнеры очень похожи на виртуальную машину, но на самом деле никакой виртуализацией тут и не пахнет.
Процессы и библиотеки LXC запускаются непосредственно на хосте и используют ядро и ресурсы хоста, просто ограничены своими пространствами имен (namespaces) и лимитами ресурсов (cgroups).
При этом LXC предоставляет контейнеризацию на уровне системы, в контейнере воспроизводится окружение любого необходимого дистрибутива Linux, доступен пакетный менеджер и большинство системных настроек.
Но ничего нового в работе с ПО у нас пока не появилось, просто теперь мы можем выбирать в разных контейнерах разные окружения, исходя их требований нашего ПО. Принципы управления и администрирования остаются классическими.
Docker же предлагает совершенно иной подход: один контейнер – один процесс. Окружение – только необходимые для работы процесса зависимости и библиотеки. А сам контейнер – сущность одноразовая, которая создается при запуске и уничтожается при остановке.
Все настройки и пользовательские данные хранятся в подключаемых томах на хосте, которые динамически монтируются в запущенный контейнер, также как и динамически создается сетевая инфраструктура.
В основе контейнера лежит атомарный образ, который собирается один раз и потом многократно используется, внесения изменений в образ «на ходу» не допускаются.
Все это достаточно непривычно и после классического подхода вызывает массу вопросов, особенно если нам нужно понимать многоконтейнерные связки. Но тут нам на помощь приходят оркестраторы, самый простой из которых Docker Compose.
Они позволяют описать конфигурацию приложения в виде кода, который расскажет какие контейнеры надо запустить, что к ним подключить, как связать между собой. Фактически переводя работу с системой на уровень «инфраструктура как код».
Теперь нам не нужно ставить пакеты, зависимости, проверять их версии, решать проблемы совместимости. Нам нужен только Docker, он сам скачает нужные образы, создаст указанные нами контейнеры, применит указанные нами настройки и все это будет работать.
Надо перенести на другую систему, легко – переносим файлы с описанием инфраструктуры и пользовательские данные. Все снова работает. Без оглядки на версию хостовой ОС. Это удобно, особенно когда приложение требует целый стек, причем определенных версий.
И требования приложения могут меняться. В этом случае просто меняем версию образа в докер и перезапускаем систему. Классическая проблема версии PHP, которой нет в дистрибутиве решается быстро и безопасно, легким движением руки.
Продолжение следует.
👍38❤5🔥2🤮1
Где лежат пределы уместности Docker. Продолжение
В прошлой заметке мы разобрали основные технические отличия Docker и LXC, а также подходы к управлению и администрированию. Сегодня же попытаемся понять, кому и зачем это надо. Сразу говорим, что мы не будем касаться разработки, CI/CD, а будем рассматривать его применение в продакшене.
Основная парадигма Docker: одно приложение – один контейнер. Любой сложный программный продукт – набор взаимосвязанных контейнеров, с минимальным влиянием друг на друга.
Это избавляет нас от проблем взаимозависимостей элементов стека и обеспечивает стабильную повторяемость результата при разных внешних условиях.
Если мы хотим обновить или заменить какой-то элемент стека – мы заменяем только один контейнер и не трогаем остальные, риски того, что обновление поломает весь стек – минимальны.
При классическом подходе серьезное обновление (например PHP 7 -> PHP 8) может потребовать пересборки всего стека или несет серьезные риски сломать его.
Для развернутой в Docker системы в этом нет никакой проблемы, причем такое обновление мы можем выполнить буквально на лету, качаем или собираем новый образ, уничтожаем старый контейнер, создаем и запускаем новый. Это занимает секунды. Никто и не заметит.
Это свойство одно из ключевых для технологии непрерывного развертывания. Когда ПО в продуктивной среде автоматически обновляется без крупных перерывов в обслуживании.
Но даже если у вас не стоит такой цели, то подобный подход резко позволяет снизить простой на обслуживание. А возможность представить инфраструктуру как код – упростить развертывание.
Но у всего должны быть разумные пределы и у Docker тоже, потому что в последнее время прослеживаются тенденции упаковывать в контейнеры все что нужно и все что не нужно, включая одиночные бинарники.
Следует понимать, что при всех своих плюсах Docker – это сложное ПО, еще один слой абстракции и еще одна точка отказа или человеческой ошибки.
Кроме того, Docker, как и любая технология, требует набора базовых знаний, иначе compose-файл будет для вас китайской грамоты, а первый же сбой заставит бегать по потолку.
Итак, где Docker не нужен совсем? Там, где можно поставить один-два пакета из репозитория плюс зависимости или скачать и запустить единственный бинарный файл. Юнит systemd легко пишется на коленке и никаких проблем с управлением службами сегодня нет.
Также достаточно сомнительна необходимость Docker для ПО, которое собирается и сопровождается под конкретную версию дистрибутива на всем протяжении его жизненного цикла.
В качестве примера можно привести Zabbix, да его тоже можно запустить в Docker, но смысл? Ставится двумя командами, стек поддерживается на уровне репозитория дистрибутива и никаких объективных причин его пересобирать на протяжении жизненного цикла релиза не возникнет.
Мажорное же обновление меняет схему СУБД и откат без восстановления базы из бекапа невозможен. Так что Docker тут вам ничем не поможет, если что-то пойдет не так.
Другое дело внешние приложения, тот же Wordpress, который мы получаем непосредственно от разработчика, и разработчик выставляет системные требования. Решил поднять версию PHP – садитесь и думайте, как жить дальше, скорее всего придется пересобирать весь стек.
Вот тут Docker и позволяет разделить структуру на микросервисы, каждый со своими зависимостями и управлять ими отдельно. Надо новый PHP – будет новый PHP, при этом мы никак не повлияем на соседние проекты.
Также в Docker так и просятся приложения на Python, Node JS и т.п., если вы, конечно, не хотите развести в системе бардак из библиотек разных версий и решать веселые квесты зависимостей и конфликтов между ними.
А также если вы хотите быстро и без лишних заморочек переносить такие приложения. Без оглядки на версии библиотек и доступные репозитории.
И не забываем, что Docker – это как молоток, всего лишь инструмент. Им хорошо забивать гвозди, а если нужно закручивать саморезы, то лучше взять отвертку. Будьте рассудительны и благоразумны.
В прошлой заметке мы разобрали основные технические отличия Docker и LXC, а также подходы к управлению и администрированию. Сегодня же попытаемся понять, кому и зачем это надо. Сразу говорим, что мы не будем касаться разработки, CI/CD, а будем рассматривать его применение в продакшене.
Основная парадигма Docker: одно приложение – один контейнер. Любой сложный программный продукт – набор взаимосвязанных контейнеров, с минимальным влиянием друг на друга.
Это избавляет нас от проблем взаимозависимостей элементов стека и обеспечивает стабильную повторяемость результата при разных внешних условиях.
Если мы хотим обновить или заменить какой-то элемент стека – мы заменяем только один контейнер и не трогаем остальные, риски того, что обновление поломает весь стек – минимальны.
При классическом подходе серьезное обновление (например PHP 7 -> PHP 8) может потребовать пересборки всего стека или несет серьезные риски сломать его.
Для развернутой в Docker системы в этом нет никакой проблемы, причем такое обновление мы можем выполнить буквально на лету, качаем или собираем новый образ, уничтожаем старый контейнер, создаем и запускаем новый. Это занимает секунды. Никто и не заметит.
Это свойство одно из ключевых для технологии непрерывного развертывания. Когда ПО в продуктивной среде автоматически обновляется без крупных перерывов в обслуживании.
Но даже если у вас не стоит такой цели, то подобный подход резко позволяет снизить простой на обслуживание. А возможность представить инфраструктуру как код – упростить развертывание.
Но у всего должны быть разумные пределы и у Docker тоже, потому что в последнее время прослеживаются тенденции упаковывать в контейнеры все что нужно и все что не нужно, включая одиночные бинарники.
Следует понимать, что при всех своих плюсах Docker – это сложное ПО, еще один слой абстракции и еще одна точка отказа или человеческой ошибки.
Кроме того, Docker, как и любая технология, требует набора базовых знаний, иначе compose-файл будет для вас китайской грамоты, а первый же сбой заставит бегать по потолку.
Итак, где Docker не нужен совсем? Там, где можно поставить один-два пакета из репозитория плюс зависимости или скачать и запустить единственный бинарный файл. Юнит systemd легко пишется на коленке и никаких проблем с управлением службами сегодня нет.
Также достаточно сомнительна необходимость Docker для ПО, которое собирается и сопровождается под конкретную версию дистрибутива на всем протяжении его жизненного цикла.
В качестве примера можно привести Zabbix, да его тоже можно запустить в Docker, но смысл? Ставится двумя командами, стек поддерживается на уровне репозитория дистрибутива и никаких объективных причин его пересобирать на протяжении жизненного цикла релиза не возникнет.
Мажорное же обновление меняет схему СУБД и откат без восстановления базы из бекапа невозможен. Так что Docker тут вам ничем не поможет, если что-то пойдет не так.
Другое дело внешние приложения, тот же Wordpress, который мы получаем непосредственно от разработчика, и разработчик выставляет системные требования. Решил поднять версию PHP – садитесь и думайте, как жить дальше, скорее всего придется пересобирать весь стек.
Вот тут Docker и позволяет разделить структуру на микросервисы, каждый со своими зависимостями и управлять ими отдельно. Надо новый PHP – будет новый PHP, при этом мы никак не повлияем на соседние проекты.
Также в Docker так и просятся приложения на Python, Node JS и т.п., если вы, конечно, не хотите развести в системе бардак из библиотек разных версий и решать веселые квесты зависимостей и конфликтов между ними.
А также если вы хотите быстро и без лишних заморочек переносить такие приложения. Без оглядки на версии библиотек и доступные репозитории.
И не забываем, что Docker – это как молоток, всего лишь инструмент. Им хорошо забивать гвозди, а если нужно закручивать саморезы, то лучше взять отвертку. Будьте рассудительны и благоразумны.
👍31🔥2🤮1
Явки, пароли, утюги на подоконнике
Проблема документирования, точнее недостаточного документирования – это классика жанра. Даже если документацию начинают вести, то рано или поздно на нее забивают, мол и так все помним, и так все знаем.
Но давно известно, что «тупой карандаш лучше острой памяти», потому как человек имеет свойство забывать, пропадать с радаров и, в конце концов, может даже попасть под автобус.
Сегодня обсуждали с одним заказчиком новое внедрение, ресурсы вроде бы есть, целый старый гипервизор, с него все перенесли, забирайте, переустановите, пустим в дело.
ОК, железку выключили, забрали. Хорошо, что сразу не стали ничего переустанавливать, есть у нас опыт, такая железка должна пару дней отлежаться.
И точно, уже на второй день, после обеда поступила заявка не проходит синхронизация с парой-тройкой точек. А почему не проходит? А потому что шла через этот самый узел, который выключили и вручили нам под новый проект.
Ну как так? А вот так, не записали, забыли, не помнили. Но синхронизация – это ерунда, куда хуже снести таким образом какую-нибудь БД или архив. Мало ли чего там может быть.
Другой случай, звонит коллега и спрашивает, мол ты не в курсе где у нас FTP для 1С-ки? Так ты же ее ставил, не мы. Ну так найти не могу, она в каком-то контейнере, на каком-то гипервизоре, их 11 штук, руками перебирать что ли?
Ну тут только руками. Хотя и мы сами часто инспектируя доступные ресурсы не раз и не два задавались вопросом: а что именно делает этот сервер (виртуалка, VPS) и т.д., что именно тут развернуто и могу ли я… Или лучше не надо…
На самом деле это серьезная проблема, которая нуждается в отдельном внимании. Своего рода складской учет в IT. Что где лежит, зачем и почему.
Чтобы, глядя на сервер или виртуалку вы могли быстро ответить: что именно здесь работает, с какими настройками и зачем.
Последнее тоже очень важно, так как мы неоднократно встречали сервера с которых перенесли рабочую нагрузку, но заглянув на который видели рабочие процессы и просто считали его еще одним рабочим узлом.
В идеале было бы неплохо завести документацию, хотя бы на уровне Excel: на каком физическом узле что стоит, где он физически находится, какие виртуалки подняты, какие роди выполняют.
Поменяли назначение ролей – изменили документацию. И очень хорошо, если вы ее дополните физическими схемами расположения оборудования и схемой разводки портов на патч-панели.
Иначе можно долго и увлекательно играть в квест: а давай выдернем этот патч-корд и посмотрим кто отвалится.
А еще хуже, если в разгар рабочего дня выключили или выдернули совсем не то, что предполагалось.
Как раз похожими развлечениями мы занимаемся почти месяц у одного из заказчиков, который выкупил из франшизы несколько торговых точек и теперь наводит там порядок.
По-хорошему, там надо все выбросить и сделать заново, но бизнес сейчас не в том положении, поэтому приводим в чувство то, что имеем, и постоянно документируем, документируем, документируем.
Маркируем устройства, кабели, соединения, порты. И заносим все это в таблицу, чтобы завтра можно было посреди ночи встать и сказать в какой порт коммутатора присоединен телевизор в торговом зале.
Что касается нас, то мы всю такую документацию храним в Joplin, интегрируя туда схемы их draw io, которыми можем всегда поделиться с заказчиком или просто изучить их на объекте.
А также не пренебрегаем возможностями комментировать непосредственно в самом ПО, в том же Proxmox всегда можно написать подробный комментарий к каждой виртуалке.
Что думаете по этому поводу вы? Какие подходы используете?
Проблема документирования, точнее недостаточного документирования – это классика жанра. Даже если документацию начинают вести, то рано или поздно на нее забивают, мол и так все помним, и так все знаем.
Но давно известно, что «тупой карандаш лучше острой памяти», потому как человек имеет свойство забывать, пропадать с радаров и, в конце концов, может даже попасть под автобус.
Сегодня обсуждали с одним заказчиком новое внедрение, ресурсы вроде бы есть, целый старый гипервизор, с него все перенесли, забирайте, переустановите, пустим в дело.
ОК, железку выключили, забрали. Хорошо, что сразу не стали ничего переустанавливать, есть у нас опыт, такая железка должна пару дней отлежаться.
И точно, уже на второй день, после обеда поступила заявка не проходит синхронизация с парой-тройкой точек. А почему не проходит? А потому что шла через этот самый узел, который выключили и вручили нам под новый проект.
Ну как так? А вот так, не записали, забыли, не помнили. Но синхронизация – это ерунда, куда хуже снести таким образом какую-нибудь БД или архив. Мало ли чего там может быть.
Другой случай, звонит коллега и спрашивает, мол ты не в курсе где у нас FTP для 1С-ки? Так ты же ее ставил, не мы. Ну так найти не могу, она в каком-то контейнере, на каком-то гипервизоре, их 11 штук, руками перебирать что ли?
Ну тут только руками. Хотя и мы сами часто инспектируя доступные ресурсы не раз и не два задавались вопросом: а что именно делает этот сервер (виртуалка, VPS) и т.д., что именно тут развернуто и могу ли я… Или лучше не надо…
На самом деле это серьезная проблема, которая нуждается в отдельном внимании. Своего рода складской учет в IT. Что где лежит, зачем и почему.
Чтобы, глядя на сервер или виртуалку вы могли быстро ответить: что именно здесь работает, с какими настройками и зачем.
Последнее тоже очень важно, так как мы неоднократно встречали сервера с которых перенесли рабочую нагрузку, но заглянув на который видели рабочие процессы и просто считали его еще одним рабочим узлом.
В идеале было бы неплохо завести документацию, хотя бы на уровне Excel: на каком физическом узле что стоит, где он физически находится, какие виртуалки подняты, какие роди выполняют.
Поменяли назначение ролей – изменили документацию. И очень хорошо, если вы ее дополните физическими схемами расположения оборудования и схемой разводки портов на патч-панели.
Иначе можно долго и увлекательно играть в квест: а давай выдернем этот патч-корд и посмотрим кто отвалится.
А еще хуже, если в разгар рабочего дня выключили или выдернули совсем не то, что предполагалось.
Как раз похожими развлечениями мы занимаемся почти месяц у одного из заказчиков, который выкупил из франшизы несколько торговых точек и теперь наводит там порядок.
По-хорошему, там надо все выбросить и сделать заново, но бизнес сейчас не в том положении, поэтому приводим в чувство то, что имеем, и постоянно документируем, документируем, документируем.
Маркируем устройства, кабели, соединения, порты. И заносим все это в таблицу, чтобы завтра можно было посреди ночи встать и сказать в какой порт коммутатора присоединен телевизор в торговом зале.
Что касается нас, то мы всю такую документацию храним в Joplin, интегрируя туда схемы их draw io, которыми можем всегда поделиться с заказчиком или просто изучить их на объекте.
А также не пренебрегаем возможностями комментировать непосредственно в самом ПО, в том же Proxmox всегда можно написать подробный комментарий к каждой виртуалке.
Что думаете по этому поводу вы? Какие подходы используете?
👍48❤1👏1
История создания и развития IBM PC
На рынок персональных компьютеров руководство IBM обратило внимание в начале 80-го года, когда он был плотно занять такими признанными игроками Apple, Atari, Tandy и Commodore. Они выпускали 8-битные компьютеры для любителей писать программы на языке Бейсик.
Основным разработчиком Бейсик-продуктов была небольшая компания Microsoft, которую возглавлял недоучившийся студент Гарварда Билл Гейтс.
Бизнес по производству ПК в то время не представлялся руководству IBM имеющим настоящее, не говоря уже о будущем, но тем не менее компания считала нужным свое присутствие на этом рынке.
Команде разработчиков были поставлены самые жесткие сроки – менее года, а провал проекта грозил серьезными оргвыводами, поэтому были приняты многие решения, о которых компания впоследствии сильно пожалела.
Сжатые сроки означали, что система должна была строиться на основе уже существующих технологий и в качестве процессора был выбран 16-разрядный процессор 8088 от компании Intel.
Руководитель проекта, Дональд Эстридж, настоял на том, чтобы сделать архитектуру будущего IBM PC открытой, это позволяло воспользоваться силами сторонних производителей для выпуска периферии для нового компьютера, чтобы сразу обеспечить ее широкий ассортимент.
Вторая роковая ошибка была в том, что IBM позволило Билу Гейтсу самостоятельно продавать новую операционную систему под именем MS-DOS. Но тут деваться было некуда.
Первоначально Эстридж хотел использовать уже существующую CP/M, но руководитель Digital Research Гари Килдалл отказался подписать соглашение о неразглашении и проект зашел в тупик. Также версию CP/M для 16-разрядных компьютеров еще только предстояло разработать.
Ограничение по времени было очень жестким и тогда Гейтс и Эстридж пошли на авантюрное решение.
У Пола Аллена был знакомый Тим Паттерсон, который в начале 80-года начал писать CP/M совместимую систему для Intel 8086, назвав ее QDOS
Гейтсу осталось только перекупить QDOS за скромные 50 тыс. долларов и силами того же Тима довести до ума.
Это решение, несмотря не все его недостатки, фактически созданное в невероятной спешке на коленках стало для Эстриджа палочкой-выручалочкой, позволившей получить в срок операционную систему для будущего компьютера.
IBM PC (IBM 5150, процессор Intel 8088) был представлен публике 12 августа 1981 года и неожиданно стал пользоваться огромным успехом, если изначально компания планировала продать 250 тыс. ПК в течении пяти лет, то очень скоро она начала продавать такое же количество ПК ежемесячно.
Эстридж, как грамотный инженер, получил то, что хотел – ПК практически сразу стал поддержан большим количеством периферии, но компания получила еще один неприятный момент – клоны.
Действительно, любой мог купить процессор от Intel и операционную систему от Microsoft и уже в 1982 некая компания-выскочка Compaq представила клон IBM PC, а к 1984 году на рынке IBM-совместимых ПК конкурировали как новички, так и известные компании.
Но IBM сохраняло за собой лидерство, выпустив в 1983 году IBM PC XT, в состав которого впервые входил жесткий диск, а в 1984 PC AT на базе процессора 286.
Лидерство ускользнуло в 1986, когда Compaq первым представил 32-разрядный компьютер на базе процессора 386. Несмотря на то, что технически это клон AT, все-таки это был самый быстрый и современный ПК и выпустила его не IBM.
Тем временем компания готовила «ответный удар» в виде нового поколения ПК PS/2, для которого учла ошибки прошлого и которое базировалась на закрытой, обложенной патентами архитектуре.
Но несмотря на мощную рекламную компанию PS/2 провалился и термин IBM-совместимые компьютеры стал просто неуместен и все бывшие клоны IBM PC превратились просто в ПК или персональные компьютеры.
А компании IBM так и не смогла вернуть себе лидерство на рынке персональных компьютеров.
Эта история закончилась в декабре 2004 г. продажей IBM за 1,75 млрд. долл. своего подразделения ПК китайской компании Lenovo.
На рынок персональных компьютеров руководство IBM обратило внимание в начале 80-го года, когда он был плотно занять такими признанными игроками Apple, Atari, Tandy и Commodore. Они выпускали 8-битные компьютеры для любителей писать программы на языке Бейсик.
Основным разработчиком Бейсик-продуктов была небольшая компания Microsoft, которую возглавлял недоучившийся студент Гарварда Билл Гейтс.
Бизнес по производству ПК в то время не представлялся руководству IBM имеющим настоящее, не говоря уже о будущем, но тем не менее компания считала нужным свое присутствие на этом рынке.
Команде разработчиков были поставлены самые жесткие сроки – менее года, а провал проекта грозил серьезными оргвыводами, поэтому были приняты многие решения, о которых компания впоследствии сильно пожалела.
Сжатые сроки означали, что система должна была строиться на основе уже существующих технологий и в качестве процессора был выбран 16-разрядный процессор 8088 от компании Intel.
Руководитель проекта, Дональд Эстридж, настоял на том, чтобы сделать архитектуру будущего IBM PC открытой, это позволяло воспользоваться силами сторонних производителей для выпуска периферии для нового компьютера, чтобы сразу обеспечить ее широкий ассортимент.
Вторая роковая ошибка была в том, что IBM позволило Билу Гейтсу самостоятельно продавать новую операционную систему под именем MS-DOS. Но тут деваться было некуда.
Первоначально Эстридж хотел использовать уже существующую CP/M, но руководитель Digital Research Гари Килдалл отказался подписать соглашение о неразглашении и проект зашел в тупик. Также версию CP/M для 16-разрядных компьютеров еще только предстояло разработать.
Ограничение по времени было очень жестким и тогда Гейтс и Эстридж пошли на авантюрное решение.
У Пола Аллена был знакомый Тим Паттерсон, который в начале 80-года начал писать CP/M совместимую систему для Intel 8086, назвав ее QDOS
Гейтсу осталось только перекупить QDOS за скромные 50 тыс. долларов и силами того же Тима довести до ума.
Это решение, несмотря не все его недостатки, фактически созданное в невероятной спешке на коленках стало для Эстриджа палочкой-выручалочкой, позволившей получить в срок операционную систему для будущего компьютера.
IBM PC (IBM 5150, процессор Intel 8088) был представлен публике 12 августа 1981 года и неожиданно стал пользоваться огромным успехом, если изначально компания планировала продать 250 тыс. ПК в течении пяти лет, то очень скоро она начала продавать такое же количество ПК ежемесячно.
Эстридж, как грамотный инженер, получил то, что хотел – ПК практически сразу стал поддержан большим количеством периферии, но компания получила еще один неприятный момент – клоны.
Действительно, любой мог купить процессор от Intel и операционную систему от Microsoft и уже в 1982 некая компания-выскочка Compaq представила клон IBM PC, а к 1984 году на рынке IBM-совместимых ПК конкурировали как новички, так и известные компании.
Но IBM сохраняло за собой лидерство, выпустив в 1983 году IBM PC XT, в состав которого впервые входил жесткий диск, а в 1984 PC AT на базе процессора 286.
Лидерство ускользнуло в 1986, когда Compaq первым представил 32-разрядный компьютер на базе процессора 386. Несмотря на то, что технически это клон AT, все-таки это был самый быстрый и современный ПК и выпустила его не IBM.
Тем временем компания готовила «ответный удар» в виде нового поколения ПК PS/2, для которого учла ошибки прошлого и которое базировалась на закрытой, обложенной патентами архитектуре.
Но несмотря на мощную рекламную компанию PS/2 провалился и термин IBM-совместимые компьютеры стал просто неуместен и все бывшие клоны IBM PC превратились просто в ПК или персональные компьютеры.
А компании IBM так и не смогла вернуть себе лидерство на рынке персональных компьютеров.
Эта история закончилась в декабре 2004 г. продажей IBM за 1,75 млрд. долл. своего подразделения ПК китайской компании Lenovo.
1👍13❤2😢1🤮1
Что почитать в субботу вечером?
Предлагаем сегодня отойти от рабочих тем и почитать про экзотику, то, что не увидишь на работе, да и сам вряд ли, когда столкнешься. Но такие системы есть и за ними стоят свои разработчики и свое комьюнити.
Начнем мы с BeOS, крайне прогрессивной системы для своего времени, но так и не снискавшей должной популярности. И причин тому было несколько, от маркетинговых просчетов руководства, до прямого противодействия конкурентов, в частности Microsoft.
🔹 BeOS - система опередившая время
Но у нее остались свои последователи, создавший открытую бинарно совместимую с BeOS систему – Haiku, которая ныне вполне себе живет и развивается. О ней в нашей следующей статье.
В ней же мы еще расскажем о ReactOS, еще одном проекте создания бинарно совместимой системы, только уже с Windows. И если Haiku является вполне стабильной ОС, которую можно применять в повседневной деятельности, то ReactOS скорее тестовая площадка, ни о какой стабильности в нем пока речи не идет.
🔹 Haiku и ReactOS - экзотические операционные системы
И напоследок можно почитать про helloSystem – попытку создать аналог macOS на базе FreeBSD.
При этом преследуется не бинарная совместимость, а воспроизведение как можно более точно основных способов взаимодействия c пользователем, заложенных в macOS (UX) чтобы пользователь сразу попадал в привычную среду и мог полноценно использовать накопленный пользовательский опыт.
Начинание смелое, но пока еще далекое от практического применения. Однако посмотреть на него интересно.
🔹 helloSystem или BSD со вкусом яблока
Да, чуть не забыли, если вас неудержимо тянет в прошлое, когда небо было синее, трава зеленее, а пиво вкуснее, то готовьтесь:
🔹 Zenwalk - встреча с динозавром
Какой практический смысл в этом всем? Никакого, но хорошего специалиста всегда должен отличать широкий кругозор, особенно в своей области.
Предлагаем сегодня отойти от рабочих тем и почитать про экзотику, то, что не увидишь на работе, да и сам вряд ли, когда столкнешься. Но такие системы есть и за ними стоят свои разработчики и свое комьюнити.
Начнем мы с BeOS, крайне прогрессивной системы для своего времени, но так и не снискавшей должной популярности. И причин тому было несколько, от маркетинговых просчетов руководства, до прямого противодействия конкурентов, в частности Microsoft.
🔹 BeOS - система опередившая время
Но у нее остались свои последователи, создавший открытую бинарно совместимую с BeOS систему – Haiku, которая ныне вполне себе живет и развивается. О ней в нашей следующей статье.
В ней же мы еще расскажем о ReactOS, еще одном проекте создания бинарно совместимой системы, только уже с Windows. И если Haiku является вполне стабильной ОС, которую можно применять в повседневной деятельности, то ReactOS скорее тестовая площадка, ни о какой стабильности в нем пока речи не идет.
🔹 Haiku и ReactOS - экзотические операционные системы
И напоследок можно почитать про helloSystem – попытку создать аналог macOS на базе FreeBSD.
При этом преследуется не бинарная совместимость, а воспроизведение как можно более точно основных способов взаимодействия c пользователем, заложенных в macOS (UX) чтобы пользователь сразу попадал в привычную среду и мог полноценно использовать накопленный пользовательский опыт.
Начинание смелое, но пока еще далекое от практического применения. Однако посмотреть на него интересно.
🔹 helloSystem или BSD со вкусом яблока
Да, чуть не забыли, если вас неудержимо тянет в прошлое, когда небо было синее, трава зеленее, а пиво вкуснее, то готовьтесь:
🔹 Zenwalk - встреча с динозавром
Какой практический смысл в этом всем? Никакого, но хорошего специалиста всегда должен отличать широкий кругозор, особенно в своей области.
👍13❤1🤮1
Анекдот на злобу дня
Идет урок. Учительница спрашивает:
— Дети, кем работают ваши папы?
Аня:
— Мой папа — строитель, он построил много красивых зданий.
Петя:
— Мой папа работает в банке, он защищает наши деньги от мошенников.
Ваня:
— Мой папа — водитель автобуса, вовремя всех привозит на работу и домой.
Вовочка:
— Мой папа — стриптизёр в ночном клубе…
Учительница в смущении быстро сменяет тему, а после урока просит Вовочку остаться.
— Вова, у тебя правда отец работает там, где ты сказал?
— Мария Ивановна, ну как я мог перед всем классом признаться, что у меня отец — сотрудник Роскомнадзора?
Идет урок. Учительница спрашивает:
— Дети, кем работают ваши папы?
Аня:
— Мой папа — строитель, он построил много красивых зданий.
Петя:
— Мой папа работает в банке, он защищает наши деньги от мошенников.
Ваня:
— Мой папа — водитель автобуса, вовремя всех привозит на работу и домой.
Вовочка:
— Мой папа — стриптизёр в ночном клубе…
Учительница в смущении быстро сменяет тему, а после урока просит Вовочку остаться.
— Вова, у тебя правда отец работает там, где ты сказал?
— Мария Ивановна, ну как я мог перед всем классом признаться, что у меня отец — сотрудник Роскомнадзора?
3😁100👎3🤮1
Вчера, 28 марта вышел очередной релиз SystemRescue 13 – специализированный дистрибутив на базе Arch Linux для восстановления компьютеров. В новой версии новое ядро 6.18.20, добавлена поддержка bcachefs и серьезно обновлен софт.
В целом нельзя назвать SystemRescue 13 чем-то новым или оригинальным, все те же операции можно сделать и при помощи любого загрузочного диска с любым Linux, но есть один момент.
На данном диске уже собрано все, что вам может понадобиться, поддержка mdadm, LVM, ZFS и различных файловых систем, включая NTFS, а также собраны все необходимые утилиты и добавлена подробная оффлайн справка.
В общем бери и работай, при необходимости можно поискать информацию через интернет, браузер также есть в комплекте.
А загрузившись с обычного инсталляционного диска вам сначала придется все необходимые библиотеки и утилиты сначала установить, а только потом начать работать. И это если есть доступ в сеть, а ее может и не быть.
Система сделана хорошо, добротно и удобна в работе. Кроме Linux администраторов она может быть полезна и их Windows коллегам, на скриншотах как раз разделы Windows системы, которую мы подключили автоматическим скриптом mountall, который находит и монтирует все поддерживаемые разделы ПК.
А в документации даже есть отдельный раздел, как сохранить данные с Windows ПК если он не загружается.
Поэтому рекомендуем данный дистрибутив иметь в своем наборе инструментов.
В целом нельзя назвать SystemRescue 13 чем-то новым или оригинальным, все те же операции можно сделать и при помощи любого загрузочного диска с любым Linux, но есть один момент.
На данном диске уже собрано все, что вам может понадобиться, поддержка mdadm, LVM, ZFS и различных файловых систем, включая NTFS, а также собраны все необходимые утилиты и добавлена подробная оффлайн справка.
В общем бери и работай, при необходимости можно поискать информацию через интернет, браузер также есть в комплекте.
А загрузившись с обычного инсталляционного диска вам сначала придется все необходимые библиотеки и утилиты сначала установить, а только потом начать работать. И это если есть доступ в сеть, а ее может и не быть.
Система сделана хорошо, добротно и удобна в работе. Кроме Linux администраторов она может быть полезна и их Windows коллегам, на скриншотах как раз разделы Windows системы, которую мы подключили автоматическим скриптом mountall, который находит и монтирует все поддерживаемые разделы ПК.
А в документации даже есть отдельный раздел, как сохранить данные с Windows ПК если он не загружается.
Поэтому рекомендуем данный дистрибутив иметь в своем наборе инструментов.
👍39❤3⚡1🤮1
И снова про мощность точки доступа
Мнение, что чем выше мощность точки доступа – тем лучше бытует не только среди обывателей, но и среди коллег, которые считают ее залогом качественной и стабильной беспроводной связи. Однако это совсем не так.
Начнем, как всегда, плясать от печки, т.е. теории. Для передачи данных в беспроводной среде используется аналоговый сигнал – электромагнитная волна, имеющая в идеале форму синусоиды (точнее двух синусоид, но это не так важно).
Чтобы передать какую-либо информацию мы определенным образом искажаем форму волны – этот процесс называется модуляцией. Причем искажаем мы форму не абы как, а строго на определенную физическую величину.
Чем сильнее мы искажаем форму волны – тем больше информации мы можем передать за единицу времени, но тем меньше физическая разница между уровнями искажения, а значит тем ниже помехоустойчивость.
Почему? Потому что электромагнитная волна при распространении взаимодействует с другими электромагнитными волнами, что также приводит к взаимным искажениям формы, этот процесс называется интерференцией (вспоминаем школу и круги на воде).
Чем меньше физическая разница между уровнями модуляции, тем легче их исказить так, что передаваемое значение окажется искажено. Кроме того, по мере распространения волны уровень сигнала падает, а следовательно он еще сильнее подвергается искажениям.
В результате при отдалении на некоторое расстояние мы уже не сможем без ошибок демодулировать волну (т.е. расшифровать переданную информацию) и тут нам нужно или усиливать сигнал, или использовать более простую, а следовательно, более медленную модуляцию.
Ну вот же, видите! Сами написали про повышение уровня сигнала. Но на самом деле не все так просто. Мощность сигнала ограничивается регламентированными значениями и если путем некоторых манипуляций мы можем повысить сигнал точки доступа, то уровень мощности оконечных устройств мы повысить не можем. Более того, все официально продаваемые в стране устройства будут соответствовать нормативам на мощность излучения передатчика.
А теперь вспоминаем еще одну аксиому – все решения в беспроводной сети принимает клиент. Клиент – довольно умное устройство и более-менее знает свои способности. И в голове у него есть некая «табличка», где указаны уровни сигнала точки доступа и доступные уровни модуляции.
Если клиент находится в зоне уверенного приема (синий круг на картинке), то он начинает использовать быструю модуляцию, мощности его передатчика также хватает на уверенную связь с точкой и точка его прекрасно слышит. В этом случае все хорошо. Связь быстрая и стабильная.
Но чем дальше мы отходим от точки, тем слабее становится уровень сигнала и клиент начинает переходить на более простые уровни модуляции, в результате чего скорость падает.
Что будет если мы повысим мощность передатчика? Клиент увидит, что уровень сигнала точки высокий и снова выберет сложную модуляцию. Но точка находится вне зоны уверенного покрытия передатчика клиента и слышит его плохо, ну или вообще не слышит.
В первом случае у нас начнутся потери пакетов, звук начнет заикаться, картинка рассыпаться. Во втором все еще хуже, сигнал есть – связи нет.
Как видим, от увеличения мощности стало только хуже. Но и при номинальной мощности может оказаться так, что эфир достаточно зашумлен и устройства начинают использовать медленную модуляцию.
В этом случае имеет смысл уменьшить мощность точки доступа и увеличить их количество. Таким образом мы сократим зону уверенного приема до того уровня, где можно использовать быстрые уровни модуляции и клиенты вместо того, чтобы переходить на медленные уровни будут переключаться на соседнюю точку.
Почему это важно? Потому что полоса передачи в беспроводной сети делится на всех и делится по количеству переданных пакетов. И даже один медленный клиент будет влиять на работу более быстрых занимая большее эфирное время. Подробнее мы об этом писали здесь: https://t.me/interface31/4023
Если коротко – уменьшайте мощность, увеличивайте количество точек, других вариантов нет.
Мнение, что чем выше мощность точки доступа – тем лучше бытует не только среди обывателей, но и среди коллег, которые считают ее залогом качественной и стабильной беспроводной связи. Однако это совсем не так.
Начнем, как всегда, плясать от печки, т.е. теории. Для передачи данных в беспроводной среде используется аналоговый сигнал – электромагнитная волна, имеющая в идеале форму синусоиды (точнее двух синусоид, но это не так важно).
Чтобы передать какую-либо информацию мы определенным образом искажаем форму волны – этот процесс называется модуляцией. Причем искажаем мы форму не абы как, а строго на определенную физическую величину.
Чем сильнее мы искажаем форму волны – тем больше информации мы можем передать за единицу времени, но тем меньше физическая разница между уровнями искажения, а значит тем ниже помехоустойчивость.
Почему? Потому что электромагнитная волна при распространении взаимодействует с другими электромагнитными волнами, что также приводит к взаимным искажениям формы, этот процесс называется интерференцией (вспоминаем школу и круги на воде).
Чем меньше физическая разница между уровнями модуляции, тем легче их исказить так, что передаваемое значение окажется искажено. Кроме того, по мере распространения волны уровень сигнала падает, а следовательно он еще сильнее подвергается искажениям.
В результате при отдалении на некоторое расстояние мы уже не сможем без ошибок демодулировать волну (т.е. расшифровать переданную информацию) и тут нам нужно или усиливать сигнал, или использовать более простую, а следовательно, более медленную модуляцию.
Ну вот же, видите! Сами написали про повышение уровня сигнала. Но на самом деле не все так просто. Мощность сигнала ограничивается регламентированными значениями и если путем некоторых манипуляций мы можем повысить сигнал точки доступа, то уровень мощности оконечных устройств мы повысить не можем. Более того, все официально продаваемые в стране устройства будут соответствовать нормативам на мощность излучения передатчика.
А теперь вспоминаем еще одну аксиому – все решения в беспроводной сети принимает клиент. Клиент – довольно умное устройство и более-менее знает свои способности. И в голове у него есть некая «табличка», где указаны уровни сигнала точки доступа и доступные уровни модуляции.
Если клиент находится в зоне уверенного приема (синий круг на картинке), то он начинает использовать быструю модуляцию, мощности его передатчика также хватает на уверенную связь с точкой и точка его прекрасно слышит. В этом случае все хорошо. Связь быстрая и стабильная.
Но чем дальше мы отходим от точки, тем слабее становится уровень сигнала и клиент начинает переходить на более простые уровни модуляции, в результате чего скорость падает.
Что будет если мы повысим мощность передатчика? Клиент увидит, что уровень сигнала точки высокий и снова выберет сложную модуляцию. Но точка находится вне зоны уверенного покрытия передатчика клиента и слышит его плохо, ну или вообще не слышит.
В первом случае у нас начнутся потери пакетов, звук начнет заикаться, картинка рассыпаться. Во втором все еще хуже, сигнал есть – связи нет.
Как видим, от увеличения мощности стало только хуже. Но и при номинальной мощности может оказаться так, что эфир достаточно зашумлен и устройства начинают использовать медленную модуляцию.
В этом случае имеет смысл уменьшить мощность точки доступа и увеличить их количество. Таким образом мы сократим зону уверенного приема до того уровня, где можно использовать быстрые уровни модуляции и клиенты вместо того, чтобы переходить на медленные уровни будут переключаться на соседнюю точку.
Почему это важно? Потому что полоса передачи в беспроводной сети делится на всех и делится по количеству переданных пакетов. И даже один медленный клиент будет влиять на работу более быстрых занимая большее эфирное время. Подробнее мы об этом писали здесь: https://t.me/interface31/4023
Если коротко – уменьшайте мощность, увеличивайте количество точек, других вариантов нет.
💯22👍12❤3
Про танки. Начало
Есть такая игра – Мир танков, в нее играют многие наши коллеги, в том числе и я. В игре я давно, с декабря 2011 года и уже давно бродили некоторые мысли, которые хочется высказать.
Начнем с того, что любая игра, особенно онлайн, должна чем-то удерживать игроков, заставлять их возвращаться, максимально вовлекать их в игровой процесс для получения максимальной прибыли с микротранзакций.
Так работают не только танки, так работает любая онлайн игра. Но именно танки сумели сделать игровой процесс максимально токсичным и заставить игроков ходить на него как на работу.
И вместо того, чтобы отвлекать, развлекать и дарить положительные эмоции игра все чаще и чаще доставляет негатив и заставляет ее закрывать в раздраженном состоянии. И они хотят, чтобы за это мы еще платили деньги?
Как вообще должен функционировать данный проект? Основная цель геймплея – прокачка веток, от слабых танков к сильным и крутым. Но прокачка тесно связана с экономикой проекта. Потому что нельзя просто так брать и качать.
Ваш ключ к прокачке – опыт, чем активнее и эффективнее вы действуете в бою, тем больше опыта получаете, тем быстрее вы сможете прокачаться. Но опыт — это еще не все, после прокачки новые модули и новую технику нужно купить, на это требуются кредиты, которые тоже можно заработать в бою.
Чем выше уровень, тем больше опыта и кредитов вы вывозите за бой, но и тем выше ваши накладные расходы. В былые времена уже начиная с 8-го уровня играть в плюс было проблематично даже при победе, а десятки стабильно уходили в минус.
Это нормально, потому что в экономической модели игры предусмотрен премиум-аккаунт, немного живых денег в месяц и вот вы уже играете в плюс на восьмерках и в ноль на десятках.
А хотите немного пофармить или прокачать пересаженный экипаж – вот вам премиум техника, тоже за реальные деньги, она немного хуже прокачиваемой, но дает повышенные кредиты и опыт. Первые премы именно такими и были.
И все шло как бы себе неплохо, пока где-то там наверху не решили, что нужно больше золота. И приняли крайне сомнительные решения.
Старожилы должны помнить «песок» - уровни от первого по четвертый, где были быстрые тачанки, скоротечные бои и всякая веселая дичь. Но так или иначе, в песке было весело и там же начинающие осваивали основы игры практически в аркадном режиме.
Теперь же начинающий, после официального «цикла подготовки» появляется сразу на пятом, а опыт у него – только пострелять по ботам.
Теперь там новый «песок», с пятого по седьмой. Многим нравится, многие там играют. Но настоящий песок увы потерян, хотя там были и есть интересные машинки, но сегодня там делать нечего.
Если мы сунемся выше, то тоже увидим, что начиная с восьмого уровня бал правят премы, их много, их раздавали за всякие активности, марафоны, ящики, и они, внезапно, лучше прокачиваемых машин.
Я сам играю на премах, потому что они есть, потому что они неплохи, потому что они экономически выгодны.
А прокачка? А зачем? Старые ветки откровенно устарели, они не могут составить конкуренцию ни новым веткам, ни премам. Качать их – сродни садомазохизму.
Новые ветки качнуть можно, но что значит «качнуть»? Открыть за чертежи, серебро и свободку, чего у каждого обычно с запасом. Но при это помнить, что все это ненадолго и скоро новые «имбы» просто понерфят.
Именно так произошло с огнеметами, которые после их появления были просто фановыми и разрывали рандом, а теперь пойди найди огнемет в команде.
И таких историй великое множество. Или ты успел в числе первых или опоздал на праздник жизни.
А если я просто хочу пройтись по исторической ветке? Попробовать танки, которые реально ездили и воевали? Забудь, это просто корм для новых машин. Беспомощные и ни на что не способные: не попал в броню, не пробил, рикошет…
Вот не собирался дальше играть, а подкинули еще 6 дней према, ну будем заходить…
Есть такая игра – Мир танков, в нее играют многие наши коллеги, в том числе и я. В игре я давно, с декабря 2011 года и уже давно бродили некоторые мысли, которые хочется высказать.
Начнем с того, что любая игра, особенно онлайн, должна чем-то удерживать игроков, заставлять их возвращаться, максимально вовлекать их в игровой процесс для получения максимальной прибыли с микротранзакций.
Так работают не только танки, так работает любая онлайн игра. Но именно танки сумели сделать игровой процесс максимально токсичным и заставить игроков ходить на него как на работу.
И вместо того, чтобы отвлекать, развлекать и дарить положительные эмоции игра все чаще и чаще доставляет негатив и заставляет ее закрывать в раздраженном состоянии. И они хотят, чтобы за это мы еще платили деньги?
Как вообще должен функционировать данный проект? Основная цель геймплея – прокачка веток, от слабых танков к сильным и крутым. Но прокачка тесно связана с экономикой проекта. Потому что нельзя просто так брать и качать.
Ваш ключ к прокачке – опыт, чем активнее и эффективнее вы действуете в бою, тем больше опыта получаете, тем быстрее вы сможете прокачаться. Но опыт — это еще не все, после прокачки новые модули и новую технику нужно купить, на это требуются кредиты, которые тоже можно заработать в бою.
Чем выше уровень, тем больше опыта и кредитов вы вывозите за бой, но и тем выше ваши накладные расходы. В былые времена уже начиная с 8-го уровня играть в плюс было проблематично даже при победе, а десятки стабильно уходили в минус.
Это нормально, потому что в экономической модели игры предусмотрен премиум-аккаунт, немного живых денег в месяц и вот вы уже играете в плюс на восьмерках и в ноль на десятках.
А хотите немного пофармить или прокачать пересаженный экипаж – вот вам премиум техника, тоже за реальные деньги, она немного хуже прокачиваемой, но дает повышенные кредиты и опыт. Первые премы именно такими и были.
И все шло как бы себе неплохо, пока где-то там наверху не решили, что нужно больше золота. И приняли крайне сомнительные решения.
Старожилы должны помнить «песок» - уровни от первого по четвертый, где были быстрые тачанки, скоротечные бои и всякая веселая дичь. Но так или иначе, в песке было весело и там же начинающие осваивали основы игры практически в аркадном режиме.
Теперь же начинающий, после официального «цикла подготовки» появляется сразу на пятом, а опыт у него – только пострелять по ботам.
Теперь там новый «песок», с пятого по седьмой. Многим нравится, многие там играют. Но настоящий песок увы потерян, хотя там были и есть интересные машинки, но сегодня там делать нечего.
Если мы сунемся выше, то тоже увидим, что начиная с восьмого уровня бал правят премы, их много, их раздавали за всякие активности, марафоны, ящики, и они, внезапно, лучше прокачиваемых машин.
Я сам играю на премах, потому что они есть, потому что они неплохи, потому что они экономически выгодны.
А прокачка? А зачем? Старые ветки откровенно устарели, они не могут составить конкуренцию ни новым веткам, ни премам. Качать их – сродни садомазохизму.
Новые ветки качнуть можно, но что значит «качнуть»? Открыть за чертежи, серебро и свободку, чего у каждого обычно с запасом. Но при это помнить, что все это ненадолго и скоро новые «имбы» просто понерфят.
Именно так произошло с огнеметами, которые после их появления были просто фановыми и разрывали рандом, а теперь пойди найди огнемет в команде.
И таких историй великое множество. Или ты успел в числе первых или опоздал на праздник жизни.
А если я просто хочу пройтись по исторической ветке? Попробовать танки, которые реально ездили и воевали? Забудь, это просто корм для новых машин. Беспомощные и ни на что не способные: не попал в броню, не пробил, рикошет…
Вот не собирался дальше играть, а подкинули еще 6 дней према, ну будем заходить…
🤣29💯7❤6🤮3👍1
Полезная команда tee в Linux
Любой Linux-администратор, активно работающий в консоли, должен знать и умело использовать эту команду.
Как и все классические утилиты
Например:
Это удобно для фиксации промежуточного результата, особенно в целях логирования или отладки.
По умолчанию tee перезаписывает указанный файл, если же мы хотим его дописать, то следует использовать ключ
Для чего это нужно? Допустим вы запустили какую-то длительную команду, результат которой вам нужно записать в файл, а потом решили ее прервать по
Любой Linux-администратор, активно работающий в консоли, должен знать и умело использовать эту команду.
Как и все классические утилиты
tee выполняет одну задачу, но делает ее хорошо. Ее смысл можно представить в виде буквы Т - команда принимает на вход стандартны поток ввода и выдает его же в стандартный поток вывода, одновременно записывая его содержимое в один или несколько файлов.Например:
command | tee file1.log
file1.log. Это удобно для фиксации промежуточного результата, особенно в целях логирования или отладки.
command1 | tee file1.log | command2
По умолчанию tee перезаписывает указанный файл, если же мы хотим его дописать, то следует использовать ключ
-a:command1 | tee -a file1.log
-i, который предписывает игнорировать команды завершения, такие как Ctrl + C. Для чего это нужно? Допустим вы запустили какую-то длительную команду, результат которой вам нужно записать в файл, а потом решили ее прервать по
Ctrl + C, при наличии данного ключа tee продолжит работу и корректно завершит запись в файл.
ping ya.ru | tee -i ping_ya.txt
tee - это повышение прав для записи в системные файлы. Например:
sudo echo "строка_текста" > /etc/myconf.conf
echo "строка_текста" | sudo tee /etc/myconf.conf
tee - простая, но весьма удобная и функциональная команда.👍21👌11🔥8❤4⚡3
Как быстро вычислить отвечающие на Ping узлы подсети в терминале Linux
Такая задача встречается довольно часто, когда вам нужно получить список «живых» узлов подсети, неважно с какими целями и сделать это нужно быстро и просто.
Вам поможет утилита fping, для ее установки воспользуйтесь командой:
Затем запустите ее с ключами:
Разберем части команды подробнее:
▫️Ключ -a – предписывает вывести узлы, которые отвечают на ping
▫️Ключ -g – генерировать узлы назначения из указанного диапазона, можно указать начальный и конечный адреса через пробел или CIDR, как в нашем случае
▫️ 2>/dev/null – подавляет вывод потока ошибок, чтобы не выводить сообщения о недоступных узлах
Как видим, поставленная нами задача решена просто и быстро.
Но это еще не все, рекомендуем ознакомиться со всеми возможностями fping выполнив:
Кстати, советуем регулярно обращаться к справке даже тех утилит, которые вы знаете, это поможет узнать что-то новое (новые ключи) или вспомнить некоторые забытые возможности.
Такая задача встречается довольно часто, когда вам нужно получить список «живых» узлов подсети, неважно с какими целями и сделать это нужно быстро и просто.
Вам поможет утилита fping, для ее установки воспользуйтесь командой:
apt install fping
Затем запустите ее с ключами:
fping -a -g 192.168.172.0/24 2>/dev/null
Разберем части команды подробнее:
▫️Ключ -a – предписывает вывести узлы, которые отвечают на ping
▫️Ключ -g – генерировать узлы назначения из указанного диапазона, можно указать начальный и конечный адреса через пробел или CIDR, как в нашем случае
▫️ 2>/dev/null – подавляет вывод потока ошибок, чтобы не выводить сообщения о недоступных узлах
Как видим, поставленная нами задача решена просто и быстро.
Но это еще не все, рекомендуем ознакомиться со всеми возможностями fping выполнив:
fping -h
Кстати, советуем регулярно обращаться к справке даже тех утилит, которые вы знаете, это поможет узнать что-то новое (новые ключи) или вспомнить некоторые забытые возможности.
1👍45🤝3❤2
Логическая бомба
Казалось бы, на эту тему все говорено-переговорено, но с завидным постоянством наблюдаю как даже опытные коллеги регулярно создают логические бомбы.
Логическая бомба – это код, который при наступлении некоторых условий, которые можно заранее просчитать и предвидеть, производит некоторые деструктивные действия. И здесь трудно сослаться на случайность или недосмотр.
Почему же так происходит? На наш взгляд – это классическое «и так сойдет» и тот же самый русский авось. Т.е. надежда на то, что обстоятельства, приводящие к срабатыванию логической бомбы, не произойдут или находятся под контролем.
Рассмотрим классический пример, очистка устаревших данных, например, бекапов:
Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.
1️⃣ Самая очевидная. Если у нас по какой-либо причине перестанут создаваться резервные копии, то через 90 дней у нас не останется ни одной. И тут ошибочно полагаться на мониторинг или иные средства контроля, так как сбой может произойти в любой части схемы.
Сначала сломался мониторинг, потом перестали создаваться копии – вот и все, привет горячий.
2️⃣ Далее. Команда работает без привязки к конкретному расположению. Если кто-то случайно переместит скрипт, то он подметет вообще случайные данные. Поэтому никаких относительных путей в подобных конструкциях быть не должно. Только абсолютные.
3️⃣ Теперь – самое неочевидное –
Поэтому постараемся сразу учесть эти моменты. Удалять всегда нужно привязываясь не ко времени или еще каким-то внешним параметрам, а по количеству остающихся копий, в этом случае даже если у вас перестанут создаваться копии, то последние всегда останутся. Во многих случаях это гораздо лучше ситуации, когда копии нет вообще.
Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).
Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:
Конструкция стала сложнее, мы, как и прежде ищем файлы, но сразу указываем директорию поиска, а список выводим построчно, в каждой строке размещая временную метку файла и его имя, взятое в кавычки.
Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.
Однозначно стало лучше, но не совсем. Что будет, если в эту папку попадут другие файлы? Они также будут удалены, при этом мы снова легко можем остаться без бекапов. Что будет если кто-то случайно закинет туда 100 новых файлов?
Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.
Допустим, наши бекапы имеют имя
Или даже
Чем более строгое совпадение в шаблоне – тем безопаснее, но во всем нужно видеть меру и вовремя остановиться, потому что если увлечься, то можно погрязнуть в проверках для совсем уже маловероятных условий или событий.
Да, и не забывайте логировать все что делают подобные скрипты, чтобы в случае какой-либо нештатной ситуации вы хотя бы могли выполнить работу над ошибками.
Казалось бы, на эту тему все говорено-переговорено, но с завидным постоянством наблюдаю как даже опытные коллеги регулярно создают логические бомбы.
Логическая бомба – это код, который при наступлении некоторых условий, которые можно заранее просчитать и предвидеть, производит некоторые деструктивные действия. И здесь трудно сослаться на случайность или недосмотр.
Почему же так происходит? На наш взгляд – это классическое «и так сойдет» и тот же самый русский авось. Т.е. надежда на то, что обстоятельства, приводящие к срабатыванию логической бомбы, не произойдут или находятся под контролем.
Рассмотрим классический пример, очистка устаревших данных, например, бекапов:
find -type f -mtime +90 -exec rm -rf {} \;Что делает эта команда? Тупо ищет файлы старше 90 дней и удаляет их. И логических бомб тут сразу несколько.
1️⃣ Самая очевидная. Если у нас по какой-либо причине перестанут создаваться резервные копии, то через 90 дней у нас не останется ни одной. И тут ошибочно полагаться на мониторинг или иные средства контроля, так как сбой может произойти в любой части схемы.
Сначала сломался мониторинг, потом перестали создаваться копии – вот и все, привет горячий.
2️⃣ Далее. Команда работает без привязки к конкретному расположению. Если кто-то случайно переместит скрипт, то он подметет вообще случайные данные. Поэтому никаких относительных путей в подобных конструкциях быть не должно. Только абсолютные.
3️⃣ Теперь – самое неочевидное –
find, который не рекомендуется использовать в скриптах в силу ряда особенностей. В частности, если нам попадется файл с пробелами в имени, то строка будет разбита на две, что приведет к неожиданным последствиям. Чаще всего удаление не произойдет, но может случиться разное.Поэтому постараемся сразу учесть эти моменты. Удалять всегда нужно привязываясь не ко времени или еще каким-то внешним параметрам, а по количеству остающихся копий, в этом случае даже если у вас перестанут создаваться копии, то последние всегда останутся. Во многих случаях это гораздо лучше ситуации, когда копии нет вообще.
Т.е. оставляем не копии за последние 90 дней, а 90 последних копий (или более, если в день создается более одной копии).
Жестко привязываемся к путям и учитываем возможность появления пробелов в имени файла:
find /mnt/backup/ -type f -printf '%T@ "%p"\n' | \
sort -n | \
head -n -90 | \
awk '{print $2}' | \
xargs -I {} rm {}
Конструкция стала сложнее, мы, как и прежде ищем файлы, но сразу указываем директорию поиска, а список выводим построчно, в каждой строке размещая временную метку файла и его имя, взятое в кавычки.
Сортируем от самых старых к самым новым и отбрасываем последние 90 записей. Затем для каждой строки получаем второй аргумент (имя файла в кавычках) и передаем его на удаление.
Однозначно стало лучше, но не совсем. Что будет, если в эту папку попадут другие файлы? Они также будут удалены, при этом мы снова легко можем остаться без бекапов. Что будет если кто-то случайно закинет туда 100 новых файлов?
Правильно – из них останется только 90 самых последних и ни одного бекапа, ну или самый последний. Это видно на берегу? Видно. Значит это очередная логическая бомба и надо от нее избавляться.
Допустим, наши бекапы имеют имя
base1-YYYY-MM-DD.dump, поэтому добавляем в строку поиска новое условие: find /mnt/backup/increment/ -type f -name "base1*.dump" -printf '%T@ "%p"\n'
Или даже
find... -name "base1-*-*-*.dump"...
Чем более строгое совпадение в шаблоне – тем безопаснее, но во всем нужно видеть меру и вовремя остановиться, потому что если увлечься, то можно погрязнуть в проверках для совсем уже маловероятных условий или событий.
Да, и не забывайте логировать все что делают подобные скрипты, чтобы в случае какой-либо нештатной ситуации вы хотя бы могли выполнить работу над ошибками.
👍27❤12👀2
This media is not supported in your browser
VIEW IN TELEGRAM
Шутки в IT бывают разные: бывают достаточно безобидные, а бывают очень злые и деструктивные.
Поэтому мы за первые. Старая добрая шутка на 1 апреля.
🤯🤯🤯
А какие IT-шутки знаете вы?
Поэтому мы за первые. Старая добрая шутка на 1 апреля.
🤯🤯🤯
А какие IT-шутки знаете вы?
😁28🤷♂3🤔1👌1🌭1
А в розетку включить не пробовали?
В продолжение первоапрельской темы расскажу реальный случай. Было это в начале нулевых и работал я в компьютерной фирме. Был у нас один достаточно крупный дилер из области и неплохой мужик сам по себе, назовем его Юра.
Так вот, Юра купил навороченный компьютер и что-то там его не совсем устраивало, поэтому он заранее с нами договорился, мол привезу свой комп, посмотрите, магарыч с меня.
В общем привез, подключили мы его с моим начальником Колей и стали смотреть, а там совсем беда, не стартует… И так и эдак, ну никак.
Зовем Юру, мол попал ты пацан, мать мертвая, мать в гарантию, а это недели две, а то и месяц, мать то не простая, понтовая.
Юра в шоке, ведь утром еще все включалось, зовем посмотреть самого – убеждается, то матери карачун. Далее стадия принятия и все такое.
И тут подходит к нам другой сотрудник техотдела Женя, внимательно на нас смотрит, а потом задает единственный, но меткий вопрос:
- А в розетку включить не пробовали?
Оказалось, что лежащий на столе удлинитель типа «пилот» оказался никуда не подключен, ну как-то так исторически сложилось.
В итоге оказалось, что проблемы Юры совсем не проблемы, мы быстро все решили и он поехал домой довольный. А Женя получил на домашний адрес большую пиццу.
В продолжение первоапрельской темы расскажу реальный случай. Было это в начале нулевых и работал я в компьютерной фирме. Был у нас один достаточно крупный дилер из области и неплохой мужик сам по себе, назовем его Юра.
Так вот, Юра купил навороченный компьютер и что-то там его не совсем устраивало, поэтому он заранее с нами договорился, мол привезу свой комп, посмотрите, магарыч с меня.
В общем привез, подключили мы его с моим начальником Колей и стали смотреть, а там совсем беда, не стартует… И так и эдак, ну никак.
Зовем Юру, мол попал ты пацан, мать мертвая, мать в гарантию, а это недели две, а то и месяц, мать то не простая, понтовая.
Юра в шоке, ведь утром еще все включалось, зовем посмотреть самого – убеждается, то матери карачун. Далее стадия принятия и все такое.
И тут подходит к нам другой сотрудник техотдела Женя, внимательно на нас смотрит, а потом задает единственный, но меткий вопрос:
- А в розетку включить не пробовали?
Оказалось, что лежащий на столе удлинитель типа «пилот» оказался никуда не подключен, ну как-то так исторически сложилось.
В итоге оказалось, что проблемы Юры совсем не проблемы, мы быстро все решили и он поехал домой довольный. А Женя получил на домашний адрес большую пиццу.
🤣26👍17🥱4😁1
Free или Available memory в Linux
В очередной раз сталкиваюсь с тем, что администраторы не понимают разницу между этими двумя показателями оперативной памяти в Linux.
Например, команда
Почему так? Для этого нужно углубиться в принципы организации памяти в Linux. Кроме занятой процессами памяти –
Можем ли мы сбросить буферы и очистить кеш? Да, можем, но когда после этого приложению потребуется какие-то данные или вызов библиотеки – то все это снова будет подгружено с жесткого диска и вполне может оказаться, что сделали мы только хуже, так как производительность системы на некоторое время упрется в производительность дисков, пока снова не будет заполнен кеш.
Поэтому в данной ситуации рассчитывать на 22,5 ГБ доступной памяти будет крайне неосмотрительно. В лучшем случае система может посчитать, что ей выгоднее сбросить страницы приложений в своп, вместо очистки кеша.
А в худшем в вовсе может решить, что сохранить кеш важнее, нежели сохранить процесс и застрелит его при помощи OOM Killer.
Кстати, системы мониторинга, тот же Zabbix будут смотреть именно на свободную память и выдавать вам алерты при ее исчерпании, хотя доступной памяти может быть еще много.
Также рекомендуем прочесть следующие статьи:
🔹 Linux - начинающим. Что такое пространства подкачки и как они работают
🔹 Linux - начинающим. Что такое OOM Killer и как он работает
В очередной раз сталкиваюсь с тем, что администраторы не понимают разницу между этими двумя показателями оперативной памяти в Linux.
Например, команда
free -m может дать нам такой вывод:
total used free shared buff/cache available
Mem: 60169 27996 9001 8472 23171 22576
Почему так? Для этого нужно углубиться в принципы организации памяти в Linux. Кроме занятой процессами памяти –
used в системе присутствует еще буферы и кеш - buff/cache, которые содержат разделяемые библиотеки, буферы ввода-вывода и т.д. и т.п., что позволяет системе меньше обращаться к диску. Можем ли мы сбросить буферы и очистить кеш? Да, можем, но когда после этого приложению потребуется какие-то данные или вызов библиотеки – то все это снова будет подгружено с жесткого диска и вполне может оказаться, что сделали мы только хуже, так как производительность системы на некоторое время упрется в производительность дисков, пока снова не будет заполнен кеш.
Поэтому в данной ситуации рассчитывать на 22,5 ГБ доступной памяти будет крайне неосмотрительно. В лучшем случае система может посчитать, что ей выгоднее сбросить страницы приложений в своп, вместо очистки кеша.
А в худшем в вовсе может решить, что сохранить кеш важнее, нежели сохранить процесс и застрелит его при помощи OOM Killer.
Кстати, системы мониторинга, тот же Zabbix будут смотреть именно на свободную память и выдавать вам алерты при ее исчерпании, хотя доступной памяти может быть еще много.
Также рекомендуем прочесть следующие статьи:
🔹 Linux - начинающим. Что такое пространства подкачки и как они работают
🔹 Linux - начинающим. Что такое OOM Killer и как он работает
👍20❤3🤮2👌1
tcpdump – сеть как на ладони
При диагностике сетей очень важно убедиться в том, что нужные пакеты приходят на нужный узел и не просто приходят, а соответствуют критериям, которые вы указали в правилах фильтрации.
Иначе можно долго гадать, что происходит и почему не работает то, что «по идее» должно работать. Поэтому не будем гадать, а просто посмотрим трафик своими глазами, в этом нам поможет утилита
Для ее установки выполните:
После чего запустите ее с ключом -D, чтобы посмотреть какие интерфейсы в системе она видит и откуда может слушать трафик.
Далее мы можем просто запустить:
И сразу утонем в количестве информации, разобраться в которой будет решительно невозможно, поэтому, чтобы получить выжимку мы будем использовать фильтры, самые популярные из них:
▫️port
▫️host
▫️src
▫️dst
▫️tcp
▫️udp
▫️icmp
Например, мы хотим посмотреть все пакеты с портом назначения
Указанную нами конструкцию следует читать как: протокол UDP - порт назначения 34567.
Теперь утилита нам покажет все пакеты, которые соответствую данному критерию: у которых транспортный протокол UDP и в поле порт назначения стоит 34567.
А если мы хотим посмотреть пакеты только от определенного узла, чтобы понять доходит к нам на сервер он него что-нибудь или нет. Усложним фильтр и добавим в него две группы условий. Для их соединения можно использовать логические выражения:
▫️AND
▫️OR
Отдельно для отрицания условия можно использовать
▫️NOT
Например:
Здесь мы фильтруем по двум условиям: хост источник и протокол - порт назначения пакета.
Вот здесь может возникнуть вопрос, а почему нельзя написать так:
Вроде бы как пол логике вещей условия все равно соединяются как-бы по логическому И, однако это неверно. tcpdump требует явного указания условии соединения различных примитивов.
В нашем условии два примитива: хост и порт. Общий синтаксис примитива можно описать выражением:
В нашем случае примитивы взяты в фигурные скобки, каждый примитив должен явно соединяться через логический оператор. Например, наоборот, все пакеты, кроме определенного узла:
Если мы хотим захватить определенное количество пакетов, то используйте ключ
Данная команда захватит строго 50 пакетов, соответствующих условию.
Чтобы увеличить количество выводимой информации добавьте ключ
При работе tcpdump пытается разрешать адреса в DNS-имена, а порты в имена служб, чтобы предотвратить такое поведение используйте ключ
Но все это диагностика в реальном времени, а как быть, если мы хотим изучить полученный дамп подробно, в спокойной обстановке? Все просто, нужно записать его в файл, для этого предназначена опция
Теперь 50 пакетов, попадающих под фильтр, будут записаны в файл mydump.pcap, если вы не указали количество, то в файл запишется все, что tcpdump успел захватить, пока вы не прервали его работу через Ctrl+C.
Записанный файл можно открыть любым подходящим ПО, наиболее популярным является открытый анализатор пакетов Wireshark.
При диагностике сетей очень важно убедиться в том, что нужные пакеты приходят на нужный узел и не просто приходят, а соответствуют критериям, которые вы указали в правилах фильтрации.
Иначе можно долго гадать, что происходит и почему не работает то, что «по идее» должно работать. Поэтому не будем гадать, а просто посмотрим трафик своими глазами, в этом нам поможет утилита
tcpdump. Для ее установки выполните:
apt install tcpdump
После чего запустите ее с ключом -D, чтобы посмотреть какие интерфейсы в системе она видит и откуда может слушать трафик.
tcpdump -D
Далее мы можем просто запустить:
tcpdump -i enp3s0
И сразу утонем в количестве информации, разобраться в которой будет решительно невозможно, поэтому, чтобы получить выжимку мы будем использовать фильтры, самые популярные из них:
▫️port
▫️host
▫️src
▫️dst
▫️tcp
▫️udp
▫️icmp
Например, мы хотим посмотреть все пакеты с портом назначения
UDP 34567:tcpdump -i enp3s0 udp dst port 34567
Указанную нами конструкцию следует читать как: протокол UDP - порт назначения 34567.
Теперь утилита нам покажет все пакеты, которые соответствую данному критерию: у которых транспортный протокол UDP и в поле порт назначения стоит 34567.
А если мы хотим посмотреть пакеты только от определенного узла, чтобы понять доходит к нам на сервер он него что-нибудь или нет. Усложним фильтр и добавим в него две группы условий. Для их соединения можно использовать логические выражения:
▫️AND
▫️OR
Отдельно для отрицания условия можно использовать
▫️NOT
Например:
tcpdump -i enp3s0 src host 203.0.113.11 and udp dst port 34567
Здесь мы фильтруем по двум условиям: хост источник и протокол - порт назначения пакета.
Вот здесь может возникнуть вопрос, а почему нельзя написать так:
tcpdump -i enp3s0 src host 203.0.113.11 udp dst port 34567
Вроде бы как пол логике вещей условия все равно соединяются как-бы по логическому И, однако это неверно. tcpdump требует явного указания условии соединения различных примитивов.
В нашем условии два примитива: хост и порт. Общий синтаксис примитива можно описать выражением:
[протокол] [направление] {host|net|port|portrange} значениеВ нашем случае примитивы взяты в фигурные скобки, каждый примитив должен явно соединяться через логический оператор. Например, наоборот, все пакеты, кроме определенного узла:
tcpdump -i enp3s0 udp dst port 34567 and not src host 203.0.113.11
Если мы хотим захватить определенное количество пакетов, то используйте ключ
-с:tcpdump -i enp3s0 -с 50 src host 203.0.113.11 and udp dst port 34567
Данная команда захватит строго 50 пакетов, соответствующих условию.
Чтобы увеличить количество выводимой информации добавьте ключ
-v[v], чем больше v вы указали, тем на более глубокий уровень будет разбираться информация пакета, но не обольщайтесь, если пакет не содержит дополнительных подробностей, но ничего нового вы не увидите.При работе tcpdump пытается разрешать адреса в DNS-имена, а порты в имена служб, чтобы предотвратить такое поведение используйте ключ
-n:tcpdump -i enp3s0 -n src host 203.0.113.11 and tcp dst port 22
Но все это диагностика в реальном времени, а как быть, если мы хотим изучить полученный дамп подробно, в спокойной обстановке? Все просто, нужно записать его в файл, для этого предназначена опция
-w:tcpdump -i enp3s0 -c 50 src host 203.0.113.11 and tcp dst port 22 -w mydump.pcap
Теперь 50 пакетов, попадающих под фильтр, будут записаны в файл mydump.pcap, если вы не указали количество, то в файл запишется все, что tcpdump успел захватить, пока вы не прервали его работу через Ctrl+C.
Записанный файл можно открыть любым подходящим ПО, наиболее популярным является открытый анализатор пакетов Wireshark.
👍45