https://prudnitskiy.pro/Recent blog posts on Инфраструктурный блогHugo (https://gohugo.io)ru-ruSat, 04 Mar 2023 11:00:00 +0800https://prudnitskiy.pro/ru/post/2023-01-24-books/Sat, 04 Mar 2023 11:00:00 +0800 Должен признаться – я люблю книги. Сейчас это не модно, потому, что книги отнимают очень много времени для прочтения, а результативность под вопросом. Ту же самую информацию можно получить в Google за 5 минут поиска. Тем не менее я считаю пользу книг сильно недооцененной. Поиск в Google дает ответ на очень узкий конкретный вопрос (и ответ, часто, не оптимальный, а может и вовсе неверный). Хорошая, качественная книга дает обзор проблемы с разных точек зрения и показывает, как части связываются в единое целое. В этой статье я собрал лучшие (на мой взгляд) книги для хорошего инфраструктурного инженера (cloud engineer, system administrator, devops, site reliability engineer, как вам больше нравится). Топ получился больше, чем я планировал, потому он разделен на 2 части. В первой части будут книги по техническим знаниям, во второй - по нетехническим, но все равно важным. Я специально отсортировал книги по алфавиту по имени автора, чтобы снизить предвзятость своей оценки. Должен добавить, что я верю в эффект Линди и потому не удивляйтесь, что здесь есть сравнительно не новые книги. Шанс того, что не прошедшая испытание временем книга окажется хорошей, по моему мнению - невысок.https://prudnitskiy.pro/ru/post/2023-01-24-books/https://prudnitskiy.pro/ru/post/2022-02-16-CKA/Wed, 16 Feb 2022 20:00:00 +0800 Экзамен Kubernetes Certified Administrator (CKA) по праву считается самым сложным из “базовых”. Интернет буквально заполнен жалобами людей, которые заплатили 400$ за попытку и не смогли его сдать. Linux Foundation предлагает одну дополнительную попытку и тестовый вариант экзамена (аж 3 тестовых сессии). Это не помогает все равно - LFS сначала сделали упрощенный вариант CKAD (Certified Kubernetes Application Developer), а потом - еще более упрощенный CKAN. Я этот экзамен сдал. С первой попытки и на 86% (то есть я сделал одну ошибку в одном сложном вопросе). Вся подготовка заняла пол-года (на момент старта знания у меня были только теоретические). В этой статье я расскажу, как я готовился, зачем это вообще надо и на что обращать внимание.https://prudnitskiy.pro/ru/post/2022-02-16-CKA/https://prudnitskiy.pro/ru/post/2021-01-15-k8s-pod-distribution/Fri, 15 Jan 2021 08:16:22 +0800 Kubernetes иногда называют “операционной системой для дата-центров” – и в этом есть логика. K8s позволяет представить группу серверов (условный ЦОД) как единое вычислительное пространство. Оператор просто бросает задания в K8s, а тот сам выбирает, где тот или иной контейнер лучше разместить. Чаще всего делает это он хорошо. Но иногда появляется необходимость как-то управлять этим процессом. Об этом я и расскажу.https://prudnitskiy.pro/ru/post/2021-01-15-k8s-pod-distribution/https://prudnitskiy.pro/ru/post/2020-06-23-restic-quickstart/Tue, 23 Jun 2020 23:00:00 +0800 Restic - это простой, надежный, быстрый и эффективный способ резервного копирования. Простой в установке и настройке, с поддержкой большого количества бэкендов хранения, надежным шифрованием и дедупликацией. Это прекрасный инструмент для резервного копирования в современном ИТ-ландшафте. Тут я расскажу, зачем он нужен, как его поставить и начать им пользоваться.https://prudnitskiy.pro/ru/post/2020-06-23-restic-quickstart/https://prudnitskiy.pro/ru/post/2019-07-24-wireguard/Wed, 24 Jul 2019 12:00:00 +0800 VPN придуман давно (IPSec - в 1998 году, например) и имеет множество областей применения - безопасный доступ для удаленных сотрудников, прозрачное объединение корпоративных сетей, безопасный доступ в интернет поверх небезопасных каналов, даже - уклонение от корпоративной и государственной цензуры. Протоколов VPN - целый выводок, а реализации (программы, ПАК, даже чистые аппаратные решения без ПО есть) - еще больше. При этом каждый каждый стандарт имеет свои недостатки. WireGuard - это очередной протокол VPN, попытка эти проблемы решить. При всех плюсах WG (про них - ниже) - он мало известен и на удивление плохо документирован. Эта статья - попытка устранить эти недостатки.https://prudnitskiy.pro/ru/post/2019-07-24-wireguard/https://prudnitskiy.pro/ru/post/2018-12-14-cfssl/Fri, 14 Dec 2018 12:00:00 +0800 TLS - один из самых распространенных стандартов шифрования и аутентификации в современном интернете. Используется исключительно широко - взаимодействие с пользователем (HTTPS), межпрограммное общение (RPC over HTTPS, gRPC), даже VPN (OpenVPN) и телефония (SIPoTLS). Он обеспечивает шифрование (симметричным ключом), авторизацию (PKI), проверку целостности переданной информации (HMAC). Важная часть TLS - PKI (инфраструктура публичных ключей). Любой публичный ключ в TLS должен быть подписан (публичный ключ с подписью и набором определенных атрибутов называется сертификатом). Центр сертификации – критически важная часть работы TLS, так как он управляет доверием к приложению или сервису (цепочки доверия). В этой статье я расскажу о том, как запустить свой собственный CA на основе CFSSL. Введение получилось неожиданно большим, так что если вам нужна практика - вам сюдаhttps://prudnitskiy.pro/ru/post/2018-12-14-cfssl/https://prudnitskiy.pro/ru/post/2018-08-22-repmgr/Wed, 22 Aug 2018 12:00:00 +0800 PostgreSQL - это мощная и очень развитая база данных, функциональная и дружелюбная. В комплект входит надежный и очень удобный механизм потоковой репликации (я писал о нем здесь). Не смотря на мощь и удобство – этот инструмент сложен в настройке и не всегда понятен, особенно, если серверов баз много. Все становится еще хуже, если у вас сложная схема репликации с каскадами (master > slave > slave of slave). Чтобы облегчить жизнь DBA в таких ситуациях – известные специалисты по консалтингу Postgres, компания 2ndQuadrant придумали repmgr – специальный инструмент для управления настройками репликации для PostgreSQL.https://prudnitskiy.pro/ru/post/2018-08-22-repmgr/https://prudnitskiy.pro/ru/post/2018-08-02-yubikey-gpg/Thu, 02 Aug 2018 09:00:00 +0800 Требования к безопасности непрерывно растут, так как взломщики постоянно эволюционируют и все лучше умеют красть данные. Доступ к данным становится все более ценным - это могут быть живые деньги, секретная информация или доступ в инфраструктуру, интеллектуальную собственность или пользовательские данные (которые эта инфраструктура обрабатывает). А это – очень большие деньги. А иногда и вовсе вопрос жизни и смерти целой структуры. Простой системы логин/пароль уже недостаточно, чтобы обеспечить надежную защиту, и даже система с ассиметричными ключами имеет уязвимости: ключ можно выкрасть. Он будет шифрован, но пароль можно подобрать. Это медленный процесс, но взломщику может повезти, особенно, если у него есть какая-то информация об особенностях пароля. Например, он знает его точную длинну. Для того, чтобы ключ можно было использовать - он должен быть расшифрован. Обычно расшифрованый ключ хранится в оперативной памяти, но при наличии доступа к памяти его можно украсть. Атака сложная, но если ключ по-настоящиему ценный - реальная.https://prudnitskiy.pro/ru/post/2018-08-02-yubikey-gpg/https://prudnitskiy.pro/ru/post/2018-01-24-systemd-quickstart/Wed, 24 Jan 2018 21:00:00 +0800 При работе в операционной системе нужно постоянно запускать разные программы. Следить за их состоянием. Перезапускать упавшее. Существует целый пласт утилит, который решает эту задачу (от простейшего init.d до навороченного svc). Сейчас в Linux стандартом де-факто стал systemd – его используют все современные дистрибутивы. Это – очень короткое и очень простое введение в systemd. Минимум текста – максимум пользы.https://prudnitskiy.pro/ru/post/2018-01-24-systemd-quickstart/https://prudnitskiy.pro/ru/post/2018-01-05-pgsql-replica/Fri, 05 Jan 2018 21:00:00 +0800 PostgreSQL – великолепная база данных, во многом – лучше MySQL. При этом у PostgreSQL довольно мало документации (кроме официальной) – MySQL раньше стал популярен и сейчас элементарно чаще встречается. Руководств по настройке репликации в MySQL - полный интернет, а для PostgreSQL на русском я пошаговых инструкций просто не видел. Это – именно такая инструкция.https://prudnitskiy.pro/ru/post/2018-01-05-pgsql-replica/https://prudnitskiy.pro/ru/post/2017-09-30-duplicity/Sat, 30 Sep 2017 20:50:10 +0800 Как гласит старинная шутка, системные администраторы делятся на две группы: те, которые не делают бэкапы, и те, которые уже делают бэкапы. Систем резеревного копирования существует великое множество, от простейшего самописного скрипта до огромных монстров ценой в “боинг”. Все системы нужны для разных целей и выполняют разные задачи.https://prudnitskiy.pro/ru/post/2017-09-30-duplicity/https://prudnitskiy.pro/ru/post/2017-09-15-jekyll/Fri, 15 Sep 2017 21:40:00 +0800 Согласно статстике W3Tech 98.5% современных сайтов – это динамические сайты. Строго говоря – это программы (порой – большие и сложные программы), мощные многоэтажные системы, связаные со сложными системами хранения данных. Каждое посещение такого сайта – это выполнение кода, что требует ресурсов сервера и времени. При этом реально в большинстве случаев вся эта мощь не используется – большинство сайтов довольно компактные и редко обновляются. А значит – мощная, сложная, гибкая, многокомпонентная, что самое страшное – потенциально ненадежная система, в общем-то, не нужна. Перевод сайта с динамики на статику – это простой и удобный способ обойтись без сложностей, не потеряв гибкости и удобства.https://prudnitskiy.pro/ru/post/2017-09-15-jekyll/https://prudnitskiy.pro/ru/post/2016-04-21-xtrabackup/Thu, 21 Apr 2016 00:20:10 +0800 MySQL - сверх-популярный сервер баз данных. Его используют (или использовали) практически все. Одна из самых популярных задач в системном администрировании - бэкап (и восстановление). Или, как подвид - миграция данных (бэкап + последующее восстановление). Это делают практически все. И практически все используют для mysql_dump, что категорически неправильно и часто просто опасно. В этой статье я расскажу, почему mysql_dump - это плохое решение и что с ним можно сделать.https://prudnitskiy.pro/ru/post/2016-04-21-xtrabackup/https://prudnitskiy.pro/ru/post/2015-11-26-pinba/Thu, 26 Nov 2015 16:21:06 +0800 PHP - исключительно популярный язык программирования, до сих пор огромное количество проектов пишется именно на нем. Язык ругают за отвратительный дизайн, неудобный синтаксис, кривое поведение в спорных случаях, отсутствие нормальных средств отладки - но его популярность это никак не снижает. Самое страшное для админа - ситуация, когда на сильно нагруженном проекте начинает тормозить код. Стандартные средства отладки (xprof, xdebug) роняют производительность языка в яму (накладные расходы - вплоть до пятикратного падения скорости), и как отлаживать сложный код на живую - совершенно неясно. Именно для борьбы с такими проблемами придумана PINBA - расширение для мониторинга скорости кода. Тут я расскажу, как установить PINBA (клиент, сервер и интерфейс) на debian и что с ними потом делать.https://prudnitskiy.pro/ru/post/2015-11-26-pinba/https://prudnitskiy.pro/ru/post/2015-09-06-mongo-shard/Sun, 06 Sep 2015 00:13:48 +0800 По сути - это не статья, а, скорее, просто памятка, чтобы самому не забыть. MongoDB - популярный документо-ориентированный движок управления базой. Штатно он имеет две разных технологии кластеризации: репликационные наборы (replica set) и шардирование (shard). Разница проста - в случае реплики на всех узлах данные одинаковы и любой узел может выступать источником данных (внимание, mongodb не является CAP-полной базой, так что точность данных тут под большим вопросом!), что обеспечивает отказоустойчивость. В случае шардирования данные “размазаны” по всему набору шарда, но каждый сервер внутри шарда имеет только свои данные. За счет этого распределяется нагрузка (например, с трех узлов данные можно читать параллельно), но снижается надежность - упавший узел означает потерю части данных шарда. В данной статье будет описание, как переехать с единичной монги на репсет не потеряв при этом данные.https://prudnitskiy.pro/ru/post/2015-09-06-mongo-shard/https://prudnitskiy.pro/ru/post/2015-05-01-xtradb-quickstart/Fri, 01 May 2015 22:13:22 +0800 MySQL - одна из самых ходовых, распространенных и простых во внедрении СУБД. Этот СУБД использует, наверное, половина всех проектов веба. Исключительная простота установки и внедрения, распространенность, поддержка “из коробки” во всех ходовых языках программирования для веб (perl, PHP, ruby, python, JS/node). Из-за мнимой простоты внедрения на потенциальные проблемы внедрения внимания просто не обращают - 90% проектов не доживут до того момента, когда заботливо разложенные авторами MySQL грабли больно ударят по лбу. Одна из серьезных грабель MySQL - серьезные проблемы с производительностью и надежностью. Тюнинг MySQL сложен, так, как изначально MySQL задуман для быстрого внедрения в небольшом проекте. Кроме того, имея серьезный, высоконагруженный проект, хочется снизить риск отказа базы данных (согласно закону Паркинсона, все, что может сломаться - сломается, и частно - в самый неудачный момент). В данной статье я распишу, как мигрировать одиночный MySQL на кластер из трех равновесных машин (для надежности - отказ любого сервера не оставит вас без базы) с автоматическим распределением нагрузки.https://prudnitskiy.pro/ru/post/2015-05-01-xtradb-quickstart/https://prudnitskiy.pro/ru/post/2014-12-25-debian-to-mdraid/Thu, 25 Dec 2014 12:23:35 +0800 Современные жесткие диски - чудо инженерии и техники. Пластины из магниево-алюминиевого сплава несутся со скоростью 120 оборотов в секунду, при этом считывающую голову от поверхности диска отделяет расстояние в 1/10 толщины человеческого волоса. Сама голова перемещается в любую точку всего за 2мс, что вызывает боковую перегрузку в фантастические 550G. Современные диски обладают впечатляющим объемом, большой линейной скоростью (что на чтение, что на запись) и минимальной задержкой поиска. И платят они за это (кроме цены) серьезным падением надежности. Старенькие Seagate Barracude и Quantum Fireball 6-10 гигабайт объемом без каких-либо нареканий жили десятилетиями, еще более старинные IBM на сотни мегабайт можно было безопасно вскрыть и закрыть в домашних условиях без специальной подготовки. Современные модели крайне чувствительны к вибрациям, тряске, углу наклона, удару и даже шуму (sic!). Средний срок жизни современного террабайтника - три года, если он эксплуатируется не слишком активно. Диски для серверов и NAS живут год-два. Если раньше RAID считался дорогой экзотикой серверного мира (по типу SCSI), то сейчас программный soft-raid - абсолютная необходимость, без которого сервер просто нельзя устанавливать.https://prudnitskiy.pro/ru/post/2014-12-25-debian-to-mdraid/https://prudnitskiy.pro/ru/post/2014-10-24-smokeping/Fri, 24 Oct 2014 10:48:00 +0800 Как-то мне (в очередной раз) потребовалось настроить мониторинг доступности клиентского сервиса через интернет. В процессе настройки я обнаружил, что не смотря на существование очень простого, понятного и удобного инструмента под названием SmokePing, по нему практически нет документации на русском (а документация на английском очень ограничена и запрятана в странном месте). Поэтому я решил написать эту небольшую вводную статью.https://prudnitskiy.pro/ru/post/2014-10-24-smokeping/https://prudnitskiy.pro/ru/post/2014-09-17-practical-paranoia/Wed, 17 Sep 2014 16:08:23 +0800 Кто-то, возможно, не поверит, но написать эту статью я собирался довольно давно. Недавние события (утечка личных фотографий звезд и 7 миллионов почтовых паролей от google и yandex) не была поводом, но подтолкнула меня к перу. Безопасности в интернете (и вообще - в ИТ) обычный пользователь уделяет на диво мало внимания, не в пример безопасности физической. Кто-то не хочет ничего делать потому, что лень, кто-то считает, что ему “как честному человеку скрывать нечего” (да-да, я встречал такой лозунг неоднократно, особенно, когда вводили цензуру в интернете на территории 1/5 части суши).https://prudnitskiy.pro/ru/post/2014-09-17-practical-paranoia/https://prudnitskiy.pro/ru/post/2013-11-14-monitoring-comparsion/Thu, 14 Nov 2013 22:31:58 +0800 Мониторинг (отслеживание состояния сервисов), наряду с резеврным копированием является, наверное, одной из самых старых и популярных задач для системного администратора. Разумеется, существует великое множество различных инструментов для ее выполнения. В этом развесистом великолепии с трудом ориентируются даже бывалые специалисты. В данном тексте я собрал основные системы мониторинга с кратким описанием и сравнением плюсов, минусов и особенностей. Разумеется, статья не претендует на всеобъемлющее описание всех систем мониторинга планеты (их слишком много), но поможет хотя бы соориентироваться и понять, куда искать.https://prudnitskiy.pro/ru/post/2013-11-14-monitoring-comparsion/https://prudnitskiy.pro/ru/post/2013-06-20-rails-on-uwsgi/Thu, 20 Jun 2013 19:49:52 +0800 Для лично-рабочих нужд я активно использую task-tracking system под названием Redmine. Redmine практически всем хорош из открытых трекеров, но очень любит память. Традиционно он запускается через rails server (WEBRick) или rails-specific сервер thin. Во второй конфигурации у меня он жрал 300Мб оперативной памяти, а среднее время генерации страницы было близко к секунде, что совершенно неприемлимо. По этой причине я решил использовать uwsgi - совершенно прекрасный appserver, который я активно использую для своего творчества на python. Uwsgi работает очень быстро (действительно - очень!), достаточно экономно относится к памяти, обладает широчайшими возможностями конфигурирования - просто-таки мечта, а не сервер. До недавнего времени он умел работать только с python (под который интерфейс uWSGI, строго говоря, и создавался), но теперь умеет обрабатывать ruby и даже PHP. Минусом uwsgid является, во-первых, тот факт, что он находится на переднем крае разработок, а значит - может работать ой как своеобразно. Не менее своеобразно он настраивается, и документации по нему очень мало.https://prudnitskiy.pro/ru/post/2013-06-20-rails-on-uwsgi/https://prudnitskiy.pro/ru/post/2013-06-13-cloud-atlas/Thu, 13 Jun 2013 10:10:55 +0800 Неоднократно замечал, что многие мои коллеги (или просто знакомые) часто путают разные варианты модного сейчас набора концепций под собирательным названием “вычислительные облака”. Я решил набросать очень-очень краткий путеводитель по облакам, с примерами и анализом сильных и слабых сторон.https://prudnitskiy.pro/ru/post/2013-06-13-cloud-atlas/https://prudnitskiy.pro/ru/post/2013-05-21-brave-new-world/Tue, 21 May 2013 09:56:00 +0800 Катастрофическое отсуствие времени в сочетании с любовью к Django и перфекционизмом привело к тому, что я решил отказаться от написания самостоятельного движка блога и перейти на Marcus от Ивана Сагалаева и Михаила Андреева. Движок, конечно, не 100% идеал (а есть ли вообще 100% идеал? Логика подсказывает, что такой невозможен), но близок к прекрасному. В ближайшее время вытащу сюда свои старые статьи и добавлю новых.https://prudnitskiy.pro/ru/post/2013-05-21-brave-new-world/https://prudnitskiy.pro/ru/post/2011-11-21-munin-install/Mon, 21 Nov 2011 05:07:29 +0800 В данной статье рассматривается такой инструмент мониторинга, как Munin. Этот инструмент существует под xNIX (Linux, xBSD, Solaris) и Windows и позволяет централизовано отслеживать и наглядно отображать состояние подшефных систем. Изначально используется для отрисовки графиков, но также его можно использовать как чистое средство для наблюдения. Большой плюс Munin - гибкость (все графики рисуются плагинами, активными на целевых системах, и никто не запрещает использовать только те плагины, которые нужны) и возможность с одного сервера собирать информацию о множестве других. Соответственно, нагрузка на наблюдаемом сервере минимальна. Интересно? Добро пожаловать под катhttps://prudnitskiy.pro/ru/post/2011-11-21-munin-install/https://prudnitskiy.pro/ru/post/2011-08-18-debian-update-distro/Thu, 18 Aug 2011 05:28:30 +0800 В свете выхода нового стабильного релиза любимого мною дистрибутива Debian (Squeeze, 6.0) - краткая инструкция по обновлению дистрибутива до нового релиза.https://prudnitskiy.pro/ru/post/2011-08-18-debian-update-distro/https://prudnitskiy.pro/ru/post/2011-06-23-monit-howto/Thu, 23 Jun 2011 08:16:22 +0800 Monit - самостоятельный демон, работающий от пользователя root. Демон работает на Linux, Free/Net/OpenBSD, SUN Solaris и некоторых других UNIX-системах. Это OpenSource проект, у которого есть “старший брат” - коммерческий проект MMonit. Последний обладает более широким функционалом в вопросе массового мониторинга, межсетевого взаимодействия и составления отчетов. Идея авторов проста - для одиночного сервера используем Monit, для большой сетевой фермы - MMonit.https://prudnitskiy.pro/ru/post/2011-06-23-monit-howto/https://prudnitskiy.pro/ru/post/2011-06-20-efs-disc-encryption/Mon, 20 Jun 2011 07:20:36 +0800 Linux в целом - достаточно защищенная система. При условии сложных паролей и своевременных обновлений (а также - нормального firewall-а) сломать его с целью получения данных достаточно трудно. Однако в случае физического доступа к машине достаточно просто загрузится с другого диска (например, с диска Slax) – и с файловой системой можно делать все, что угодно. Дабы противостоять такой атаке – придумана шифрованая файлсистема. В данной статье пошагово описано создание шифрованой файлсистемы (шифр - AES128) на отдельном разделе диска, авторизация по паролю (keyword). Статья писалась под Xubuntu linux (Debian), хотя в принципе для других версий Linux принципиальных различий не будет.https://prudnitskiy.pro/ru/post/2011-06-20-efs-disc-encryption/https://prudnitskiy.pro/ru/post/2009-07-11-juniper-emu/Sat, 11 Jul 2009 18:04:41 +0800 И снова доброго утречка. В данной статье я рассажу о своем опыте эмуляции Juniper M-серии в домашних условиях и о тех трудностях, которые ждут экспериментаторов. Замечу, что данная статья является творческой компиляцией из этого, этого и вот этого, щедро сдобреного собственным опытом и несколько лишенным воды. Если этой статьи вам мало - добро пожаловать в первоисточники :)https://prudnitskiy.pro/ru/post/2009-07-11-juniper-emu/https://prudnitskiy.pro/ru/post/2005-01-14-openssh-key-auth/Fri, 14 Jan 2005 08:35:00 +0800 OpenSSHd имеет очень немалое количество механизмов аутентификации, которые в принципе базируются на двух парадигмах - симметричного ключа (пароль) и несимметричного (сертификат). Разница в этих парадигмах довольно незамысловата: в случае использования симметричного ключа копию этого ключа надо хранить на сервере, чтобы при авторизации сравнить хранимое значение со значением, отправленным пользователем. В случае, если значения одинаковы - пароль считается верным и пользователя авторизуют, если значения разные - то нет. Минус пароля в том, что его можно перехватить, после чего пользоваться им без ограничений. Идея сертификата (несимметричного ключа) - более свежая. Она создавалась позже системы на базе пароля и учитывает вышеуказанную уязвимость. Работает эта система на базе двух связанных между собой ключей - открытого и закрытого. Используя открытый ключ, можно зашифровать сообщение, но расшифровать его - нельзя. Расшифровать сообщение можно только закрытым ключом. При этом имея закрытый ключ - можно создать открытый, однако имея открытый - нельзя восстановить закрытый. Кроме того, закрытым ключом можно не только зашифровать, но подписать сообщение - добавить к нему некоторое значение, которое однозначно идентифицирует сообщение. Подписаное сообщение нельзя изменить, при изменении подпись нарушается. При этом, имея открытый ключ можно совершенно однозначно идентифицировать, что подписано сообщение было совершенно определенным закрытым ключом. Но восстановить закрытый ключ или подписать открытым ключом сообщение - снова нельзя. Надеюсь, я не слишком сильно усложнил статью этим кратким экскурсом в практическую криптографию :) Итак, поехали, только практика и ничего кроме практикиhttps://prudnitskiy.pro/ru/post/2005-01-14-openssh-key-auth/https://prudnitskiy.pro/ru/about/Mon, 01 Jan 0001 00:00:00 +0800 Меня зовут Павел Рудницкий и это – мой персональный сайт. Так получилось, что с 2001 года я работаю с компьютерами – строю системы, поддерживаю, чиню, помогаю с ними работать. Сначала это называлось “системный администратор” (а иногда - “администратор локальной сети”), потом “devops”, сейчас - SRE. По большей части я работаю с сетями и UNIX-системами (в первую очередь - с Debian Linux). Я не работаю с Microsoft Windows и вообще продуктами от Microsoft. Последнее время занимаюсь тем, что называется HighLoad, а так же – виртуальными машинами, контейнерами и CI. Раньше я сопровождал очень крупный интернет-магазин, работал в интернет-провайдерах фиксированной связи и помогал в примирении идей системного интегратора с реальным миром. О моем профессиональном пути можно подробно почитать на LinkedIN.https://prudnitskiy.pro/ru/about/