Записки IT специалиста

Корейские кроссоверы: новые, надёжные, доступные! Kia, Hyundai, Genesis — корейцы делают одни из лучших кроссоверов в мире! И мы привезём их дешевле салона. Наше предложение: • Новые корейские кроссоверы с завода • Экономия до 30% от цен российских дилеров • Полные комплектации — без урезанных версий • Заводская гарантия сохраняется Популярные модели: 🚗 Hyundai Tucson, Santa Fe, Palisade 🚗 Kia Sportage, Sorento, Mohave 🚗 Genesis GV70, GV80 Под ключ: • Заказ на заводе или у дилера • Доставка 20-30 дней • Растаможка, ЭПТС • Русификация и адаптация • Передача с полным пакетом документов Никаких «пакетов на месте» — только честная финалка! ✅ Переходи в Telegram — там актуальные цены, сроки поставки и акции! Подписаться #реклама О рекламодателе

О различных подходах к системному администрированию Данная заметка написана как размышление по поводу одного обсуждения, где промелькнула интересная фраза об «уютном рабочем месте, где много чего есть». Под много чего подразумевается набор всяко-разных инструментов и утилит разной степени полезности. Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами. Казалось, эпоха командной строки навсегда канула в прошлое. На любое, даже самое простое действие всегда можно было найти графическую утилиту и сделать все мышкой. Времена были тогда сильно попроще, и мы смело качали из сети все что под руку попадалось, особо не заморачиваясь ни насчет авторских прав, ни насчет двойного дна в программах. Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем? Потом я начал осваивать мир Linux, естественно начал с графического интерфейса, потому как сразу нырять в глубину терминала классическому виндовому админу тех лет было не с руки. Там сразу кирпичом и на дно… И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты. Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории. Потихоньку выяснялось, что в Linux все есть и практически все это присутствует из коробки, а чего нет – быстро ставится одной командой. Но вот беда, все это было в основном заточено под консоль, что меня и моих коллег, привыкших к окошкам и мышке сильно пугало. Первое, что мы пробовали делать, это искать графические оболочки для консольных утилит, но очень часто они выглядели так, как будто были написаны левым задним копытом в период ломового запоя. Ну и работали соответствующе. Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика. В те времена многие сошли с этого трудного пути и вернулись обратно в простой и понятный, как нам тогда казалось, мир Windows. Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация. Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС. И, как это бывает, из чего-то чужого, непонятного и враждебного терминал превратился в теплую и уютную рабочую среду, где все есть и не нужно ничего искать, ну может сразу подкинуть парочку пакетов. После чего, возвращаясь в мир окон стал возникать вопрос, а можно ли как-то решить эту задачу без привлечения сторонних утилит, средствами системы? И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности. После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено. Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.

Яндекс Музыка до 360 дней бесплатно Яндекс Музыка для вас и 3-х ваших близких. Кинопоиск и Яндекс Книги тоже в подписке. Попробуйте бесплатно❤️ Слушать #реклама 18+ music.yandex.ru О рекламодателе

Как изменить командную оболочку Linux Командная оболочка, она же интерпретатор командной строки – специальная программа, запускаемая при входе в систему и обеспечивающая для пользователя интерфейс командной строки. Самой распространенной и популярной командной оболочкой в Linux является bash, но существуют и другие оболочки. Начинающие пользователи редко задумываются над этим, до тех пор, пока не попадут в непонятную ситуацию. Сегодня за советом обратился молодой коллега, он решил потренироваться в настройке веб-сервера и взял для этих целей бесплатную виртуалку у Cloud.ru о котором мы недавно писали. Его «проблема» оказалась в том, что Linux там (а он установил Debian 12) какой-то непонятный, выглядит не так, стрелки не работают и вообще странно себя ведет. Он уже и систему переустановил, но ничего не помогает. Любой опытный администратор Linux сразу же распознает симптомы и спросит какая командная оболочка установлена для пользователя. Проверить это можно командной:

echo $SHELL

В нашем случае ожидаемо получили ответ:

/bin/sh

В Debian и Ubuntu данный файл является символической ссылкой на dash – минималистическую оболочку Debian Almquist shell портированную Almquist shell (ash) из NetBSD. Она очень легковесна, но не может похвастаться функциональностью и не является полностью POSIX-совместимой. Вполне понятно, что, оказавшись в непривычной командной среде мой коллега растерялся и не сразу понял в чем дело. Но этому горю легко помочь и установить в качестве командного интерпретатора привычный bash или что угодно другое. Прежде всего ознакомимся со списком доступных командных оболочек:

cat /etc/shells

В выводе вы получите что-то вроде:

/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash

Ничего иного в качестве командной оболочки указывать не следует иначе вы просто не сможете войти в систему. Опытный пользователь заметит, что для многих оболочек присутствует два пути, ничего удивительного в этом нет, так как в современных системах каталог /bin является символической ссылкой на /usr/bin и обе записи ведут в одно и тоже место. Чтобы изменить командную оболочку используйте команду:

chsh -s /bin/bash 

В данном случае мы установили себе оболочку bash. Обычный пользователь может изменить оболочку только себе, суперпользователь может сделать это для любого пользователя, например:

chsh -s /bin/bash user1

В данном случае указанная оболочка будет установлена пользователю user1. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.

X-Border - товары из США и Европы. Комиссия 0% Ежедневно мы выкупаем в интернет-магазинах США и возим в РФ более 100 заказов, таких брендов как: Nike, Adidas, Dickies, Lego, Uniqlo и многих других... 💰 Экономьте до 80% на покупках в США. Как это работает? ✅ Присылайте ссылку на любой товар из любого магазина в США в наш telegram-бот; ✅ Мы расчитываем стоимость товара + стоимость доставки в РФ; ✅ Вы оплачиваете удобным для вас способом и ожидаете свой заказ – срок доставки от 14 дней! Подписывайтесь на наш канал 📱 t.me/+BeNt89uVO2I2Njhi и покупайте оригинальную одежду, обувь, аксессуары и многое другое с удовольствием! Узнать больше #реклама О рекламодателе

Почему современные приложения все чаще используют конфигурационные файлы в форматах JSON или YAML Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок. То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями. Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение. Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей. Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе. А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API. Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения. Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную. Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат. Как быть? Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру. Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом. При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры. Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора. Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения. Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение. И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения. Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan. Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера. Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига. Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам. Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно. В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH. Например, VS Code, про который мы рассказывали в нашей недавней статье: 🔹 Настраиваем Visual Studio Code для удаленной работы через SSH

Есть только один правильный способ провести майские тот, что нравится вам. Выбирайте, где отдохнуть, и бронируйте отели, квартиры и загородные дома под себя на Яндекс Путешествиях со скидкой по промокоду MAYSKIE. 😊 Отдохнуть за городом 😊 Скататься в другой город 😊 Умчаться туда, где тепло Забронировать #реклама special.travel.yandex.ru О рекламодателе

Удаленное выполнение команд SSH Сегодня еще немного об SSH, точнее о выполнении команд на удалённом сервере. Чтобы это сделать - необязательно заходить на него, достаточно выполнить:

ssh user@remotehost cat ~/myfile 

И вы получите в локальном терминале вывод указанной команды. Это удобно, если нужно обработать результат локально или быстро узнать статус службы или перезапустить ее. При этом важно понимать, что на удаленном узле выполняется только первая команда, все перенаправления или конвейеры будут работать уже локально. Например:

ssh user@remotehost  mysqldump -uroot-p database > database.sql

Выгрузит дамп MySQL базы на удаленном сервере, но сохранит его локально. Это работает даже на платформе Windows, где уже давно есть встроенный OpenSSH. А вот такая конструкция отлично сработает в Linux, но даст вам ошибку в Windows, так как в ней нет команды grep:

ssh user@remotehost dpkg -l | grep 1c-ent

Это как раз то, о чем мы говорили, при такой записи dpkg выполниться удаленно, а grep - локально. Чтобы выполнить команду полностью на удаленном узле ее нужно взять в одинарные кавычки.

ssh user@remotehost 'dpkg -l | grep 1c-ent'

С другой стороны никто нам не мешает решать часть задач другими инструментами:

ssh user@remotehost dpkg -l | Select-String -SimpleMatch "1c-ent"

Здесь мы получили нужную информацию с удаленного узла и обработали ее при помощи PowerShell

Всё, что вы любите, есть на Wildberries Все мы ищем разное, но всегда находим что-то своё на WB — со скидками и доставкой Перейти на сайт #реклама wildberries.ru О рекламодателе

Настраиваем Forgejo с обратным прокси-сервером Caddy и TLS-защитой Git сегодня плотно вошел в повседневную работу не только разработчиков, но и системных администраторов, особенно если вы придерживаетесь принципа инфраструктура как код или просто хотите хранить собственные скрипты и конфиги в версионированном хранилище. Обычно используются внешние сервисы, тот же GitHub или GitLab, но в современных реалиях внешний сервис может стать точкой отказа или вы не хотите размещать на внешних серверах чувствительную информацию. В этом случае вам потребуется собственный git-сервер и, если вам не требуется монстр вроде Self-hosting GitLab, то есть простые и нетребовательные решения. Одним из них была Gitea, но после перехода ее под контроль коммерческой организации сообщество выразило обоснованные лицензионные опасения. В результате появился ее форк – Forgejo, который со временем стал развиваться самостоятельно и перестал быть полным аналогом Gitea, при этом оставаясь полностью открытым программным обеспечением. Сегодня мы рассмотрим, как быстро поднять свой экземпляр Forgejo с СУБД PostgreSQL и обратным прокси на базе Caddy с TLS-защитой. Это готовое решение, которое вы можете разворачивать в продуктовых средах. Для развертывания мы будем использовать Docker, так как готовых пакетов для проекта нет. Создадим папку проекта, в нашем случае /opt/forgejo и перейдем в него, там создадим следующие файлы с указанным ниже содержимым. Набор переменных - .env, в который внесем:

UID=1000
GID=1000

DOMAIN=git.example.com
SSH_PORT=2222

POSTGRES_DB=forgejo_db
POSTGRES_USER=forgejo_usr
POSTGRES_PASSWORD=forgejo_pwd

Здесь мы указываем домен, порт для SSH (родной 22 занят хостом) и параметры подключения к PostgreSQL и имя базы. Затем создадим файл конфигурации Caddy – Caddyfile:

{$DOMAIN} {
   # tls internal
    reverse_proxy server:3000
}

Опция tls internal отвечает за получение самоподписанного сертификата, раскомментируйте ее для тестовой среды или отладки, если получение сертификата Let’s Encrypt невозможно. И наконец docker-compose.yml:

services:
  caddy:
    image: caddy:latest
    restart: always

    environment:
      - DOMAIN=${DOMAIN}

    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"

    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

    depends_on:
      - server

    networks:
      - forgejo

  server:
    image: codeberg.org/forgejo/forgejo:14
    restart: always

    environment:
      - USER_UID=${UID}
      - USER_GID=${GID}

      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=${POSTGRES_DB}
      - FORGEJO__database__USER=${POSTGRES_USER}
      - FORGEJO__database__PASSWD=${POSTGRES_PASSWORD}

    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro

    ports:
      - "${SSH_PORT}:22"

    depends_on:
      - db

    networks:
      - forgejo

  db:
    image: postgres:17
    restart: always

    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

    volumes:
      - ./postgres:/var/lib/postgresql/data

    networks:
      - forgejo

volumes:
  caddy_data:
  caddy_config:

networks:
  forgejo:

Сохраняем и запускаем командой:

docker compose up -d

Затем переходим по указанному нами доменному имени. Вы попадете на страницу начальной настройки, там все понятно, но обратите внимание на порт SSH, его требуется указать таким, какой вы выбрали в переменных, т.е. 2222. В остальном смотрите сами, первый зарегистрированный пользователь становится администратором, если вы не указали его явно. А теперь вы можете перенести уже готовые репозитории из других сервисов или создать новый. А также управлять собственным git-сервером.

Как строить карьеру в IT и не раствориться в работе. Я backend-разработчик и футбольный энтузиаст с системным подходом к спорту. Играю в разных странах и с разным уровнем соперничества: от локальных матчей до турниров в Азии. В канале пишу: — о личном опыте лида в IT и реальных технических решениях 👨‍🎓 — о развитии своих проектов и о том, чему они учат 📈 — о футбольных движухах в разных странах 🏃‍♂️ — о том, как не терять форму при плотной работе 💪 — о лайфстайле зимовщика 🧘‍♀️ Без мотивационных лозунгов. Без «успешного успеха». Только практика, дисциплина и честные наблюдения. 👉 Футбольный синьор Если вам близка идея баланса между карьерой и личной жизнью и интересно заглянуть за кулисы IT, добро пожаловать на канал.

Статья с пола или распространенные юридические заблуждения В очередной раз столкнулись с распространенным заблуждением коллег, которые считают вполне допустимой ситуацию с уничтожением результата своей работы в отсутствие оплаты от заказчика, мол что такого – я вернул все как было, в исходное состояние. Это очень опасное заблуждение, основанное на неверном применении правил обычной, бытовой логики, в то время как Закон смотрит на эту ситуацию совсем по-другому. Начнем с базового момента: чужая инфраструктура – это чужая собственность и результат ваше работы на этой инфраструктуре тоже принадлежит заказчику, он автоматически становится его собственностью по факту принятия работы. До тех пор, пока заказчик не принял работу вы не вправе требовать с него оплаты – нет основания, нет результата, за который он вам должен заплатить. Да, вы вправе просить аванс, но в этом случае до получения аванса вы не приступаете к работам. Нет аванса – нет работы. Если вы просите оплату за работу, это подразумевает сдачу результата работ заказчику, так как только после этого у него возникает обязанность вам заплатить, но это и означает, что результат работ его собственность. Уничтожение собственности заказчика, неважно, просто вы там все стерли, или просто откатили как было может быть расценен в зависимости от сопутствующих обстоятельств как: ▫️ Самоуправство (ст. 330 УК РФ). Самовольное осуществление своего права (реального или мнимого) вопреки установленному законом порядку. ▫️ Неправомерный доступ к компьютерной информации (ст. 272 УК РФ). Подождите, какой неправомерный, он же сам выдал все пароли и доступы! Но обладание возможностью доступа не говорит о его правомерности. Во-первых, доступ вам выдали для процесса настройки, а не для деструктивных действий. Во-вторых, закончив процесс настройки и сдав работы вы теряете право правомерного доступа. Но даже если вы сильно будете настаивать на правомерности, скажем вы там еще и поддержкой занимаетесь, то свободно получите другую статью: ▫️ Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей (ст. 274 УК РФ). Потому как доступ вам предоставляли не для деструктивных целей, а для поддержки и обслуживания и вы нарушили правила эксплуатации, что привело к деструктивным последствиям. Но и тут не все так просто, потому как в действие вступает Статья 25 УК РФ (Преступление, совершенное умышленно). Потому что есть объект преступления – информационная инфраструктура, принадлежащая заказчику, есть прямой умысел - вы осознаете, что удаляете данные, предвидите вред и желаете его. И есть общественно опасные последствия – прямой или косвенный ущерб заказчику, нарушение работы инфраструктуры. Если заказчик в результате ваших действий понес реальный ущерб: остановились продажи, перестал работать сайт, были удалены или оказались блокированы данные, то тут можно дополнительно поднять еще одну статейку: ▫️ Умышленные уничтожение или повреждение имущества (ст. 167 УК РФ) несмотря на то, что программное обеспечение имуществом (вещью) не является. Логика правоохранительных органов здесь такая: если в результате удаления ПО сервер (вещь) вышел из строя, не обязательно физически, достаточно невозможности использования оборудования по назначению и это принесло реальный ущерб – то это умышленное повреждение имущества. Получается, что наш коллега кругом не прав и не имеет возможности защитить себя от кидка? Имеет, только нужно использовать подходящие для этого нормы права: ▫️ Право подрядчика на удержание (ст. 712 ГК РФ) Согласно которой он имеет право удерживать результаты своего труда до полной его оплаты. Т.е. в нашем случае правомерно не предавать полный доступ (учетную запись администратора) до полного выполнения заказчиком своих обязательств. Но самовольно уничтожать или еще каким-либо образом распоряжаться имуществом заказчика вы не имеете права.

Если при слове «облако» вы думаете не о небе, а об инфраструктуре, сетях и сервисах — вам понравится канал «Кучевые АйТи».В нем команда компании «Облакотека» пишет о развитии облачных технологий и о том, как превратить инфраструктурный хаос в удобные решения для бизнеса. Есть ли место подходу DevOps? Что происходит с компаниями при росте числа сервисов, почему без платформенного подхода становится сложно работать и будет ли подход DevOps востребован в будущем. Читать в канале «Апокалипсис ИИ»: ждать или готовиться? Некоторые считают, что искусственный интеллект полностью заменит офисных сотрудников. Предлагаем снизить градус тревоги и посмотреть на ситуацию здраво. Читать в канале «Мы что-то нажали, и всё исчезло» Документацию и руководства читают примерно так же редко, как и условия лицензионных соглашений. Что делать, если сервисом постоянно пользуются неправильно? Читать в канале 👉 Подписаться: @oblakoteka

Стандартное - Нестандартное В админской среде всегда любили и любят всякое нестандартное, возводя это в достоинство и формируя мнение, что любой админ должен уметь нечто такое, что недоступно остальным и позволит выкрутиться из любой ситуации. В итоге очень и очень многие решения идут вопреки стандартным практикам и фактически представляют из себя костыли и изоленту. Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо. Нет, знания и умения – это однозначно хорошо, но, когда они идут в разрез с общепринятыми практиками – это плохо. Попытка решить стандартные вопросы нестандартными средствами – это плохо. И никакие оправдания тут не могут быть уместны. Исключения – это специфические системы, например, высоконагруженные, но там админы прекрасно понимают, что делают и там у них есть свои стандартные практики, которые всем остальным просто не нужны. Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями. Столь же плохо применение в системах общего назначения каких-то специализированных практик, какими бы они «крутыми» и «навороченными» не казались. Мы не раз сталкивались с нестандартными настройками и твиками, которые вызывали сложности на ровном месте. А когда начинали выяснять что это и зачем, то могли услышать примерно следующее: - Ну это крутые пацаны из High Load рекомендуют? - А у тебя высокая нагрузка? - Нет, но… Или: - Ну это защита от сетевых атак… - Тебя кто-то атакует? - Нет, но… Все это, конечно, может выглядеть круто, но, по сути, это не дает никаких плюсов, а только сплошные минусы. Подобные настройки могут вызывать потенциальные конфликты, приводить к сложностям в поддержке или администрировании и даже стать причиной отказов, если незнакомый с ними администратор применит настройки, явно приводящие к конфликту. Поэтому если у вас самая обычная система, которая не испытывает высоких нагрузок и которую никто не атакует, то и настройки в ней должны быть самые стандартные, сделанные стандартными для этой системы механизмами. И именно это будет хорошо и правильно. Потому что позволит любому знакомому с системой специалисту быстро разобраться в ней и продолжить поддержку в отсутствие ее основного «архитектора». И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем. Потому что все эти костыли и изолента имеют свойство выстреливать в самый неподходящий момент. И делать это достаточно больно. Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу. Если вы вчера сэкономили нестандартным решением десять тысяч рублей, а сегодня, во время вашего отпуска все это упало и разбирались с вашими художествами несколько часов, понеся убытки на сотни тысяч, то ваши мотивы никто из лиц принимающих решения просто не поймет. Со всеми вытекающими оргвыводами. Поэтому, подводя итоги, можно сказать, что следовать стандартным практикам, даже если они не совсем оптимальны – это хорошо. А городить собственные нестандартные решения – плохо. При этом мы не хотим сказать, что нестандартные решения не имеют права на существование. Иногда без них никак. Но при этом они должны быть именно нестандартными и становиться личным стандартом де факто. Но даже применяя нестандартные решения нужно стараться максимально их стандартизовать: использовать стандартные пути размещения файлов, понятные наименования скриптов и переменных в них. Т.е. сделать работу с ними максимально понятной третьему лицу, который увидит это в первый раз. Ну и конечно не забыть все это документировать. И часть документации будет совсем не лишним разместить прямо здесь, лучше всего в комментариях к скрипту или в виде файла где-то рядом.

Всё, что вы любите, есть на Wildberries Все мы ищем разное, но всегда находим на WB что-то своё — со скидками и доставкой. Перейти на сайт #реклама wildberries.ru О рекламодателе

​​Про IPsec для самых маленьких Набор протоколов IPsec широко используется для защиты сетевых соединений, но он же вызывает наибольшее количество затруднений у начинающих пользователей (и не только). Очевидный плюс IPsec – высокий уровень надежности и защиты, а дальше пошли сплошные минусы. Как следует из названия IPsec работает на сетевом уровне и использует протокол IP, что делает его универсальным и прозрачным для любых вышестоящих протоколов. При этом IPsec не плодит никаких лишних сущностей: новых соединений, интерфейсов и т.д. и т.п. Т.е. вы как работали с IP, так и продолжаете работать, а IPsec тихо и незаметно делает свое дело. Это и обуславливает его широкое распространение, вам не нужно думать о поддержке IPsec со стороны своего сетевого приложения, достаточно того, что оно может работать с IP. И это же является основной сложностью для работающих с ним администраторов. Правила обработки трафика IPsec задаются политиками и основаны на адресах источника и назначения пакета. Никаких интерфейсов - только адреса, маршрутизация тоже не работает. Точнее она работает, но там, где должна работать, на принятие решения о том, будет зашифрован IP-пакет или нет она не влияет. IPsec может работать в двух режимах – туннельном и транспортном. Начнем с транспортного, в этом случае шифруется только полезное содержимое IP -пакета, заголовки оставляются в неизменном виде. Это удобно для защиты трафика между узлами, имеющими внешние IP-адреса, что позволяет шифровать только полезное содержимое и исключить дополнительные накладные расходы. В туннельном режиме пакет шифруется полностью, со всеми заголовками и помещается внутрь нового пакета, который отправляется второй стороне, указанной в настройках IPsec соединения. В данном случае IPsec работает как классический туннель с инкапсуляцией пакетов, но то, какие пакеты будут инкапсулированы определяется также политиками, а не маршрутизацией. А далее такой пакет и неважно туннельный или транспортный режим там используется пойдет, как и любой другой по всем правилам брандмауэра и установленным маршрутам. Здесь появляется очередная сложность – избежать дополнительной обработки такого пакета брандмауэром и особенно NAT, в противном случае изменятся его адреса источника / назначения, и он перестанет соответствовать политикам IPsec. Все это решаемо, но требует определенных знаний и понимания. Ну и, наконец, работать IPsec может совершенно на разных уровнях. Например, часто мы говорим, что подняли туннель GRE over IPsec, а кто-то может поднять IPsec over GRE. Казалось бы, какая разница, все равно у нас есть зашифрованный туннель. Но разница есть, и она огромная. GRE over IPsec обозначает что мы поднимаем GRE-туннель не предусматривающий никакого шифрования поверх уже установленного IPsec соединения между узлами. Что это значит? А то, что между узлами А и Б при помощи IPsec будет защищен любой IP-трафик, а не только GRE. Вы можете гонять там что угодно и все это будет также защищено при помощи IPsec. А если мы поднимем IPsec over GRE, то в этом случае мы создаем между узлами А и Б незашифрованный туннель, но все что ходит в этом туннеле и только шифруется с помощью IPsec. Только то, что в туннеле, а не весь трафик между внешними узлами. Причем право на жизнь имеют обе модели, все зависит от задач, но разница между ними более чем существенна и без понимания таких тонкостей можно наделать откровенно странных конструкций или недоумевать, почему сеть работает не так, как «задумано». Поэтому перед тем, как бездумно настраивать IPsec уделите время на хотя бы обзорное знакомство с этим набором протоколов, чтобы вы хотя бы на базовом уровне имели представление как это взаимодействует между собой и почему работает именно так, а не иначе.

🚀 INFRAX 1.0.0 — официальный выход из беты! INFRAX — это единая российская on-premise платформа (ситуационный центр ИТ-инфраструктуры). В одном интерфейсе: мониторинг (ITOM), Service Desk (ITSM), CMDB + ITAM, резервное копирование, удалённый доступ (RPAM), автоматизация, агентный ИИ-помощник и управление виртуализацией. Заменяет зоопарк из 12+ разрозненных систем — всё под рукой, данные не уходят наружу. ✨ Главное в версии 1.0.0 • SNMP-мониторинг • Резервное копирование • SLA • CMDB + ITAM • Поддержка из тикета • Инструменты инженера • Агентный ИИ-помощник INFRAX 1.0.0 — вся ИТ-инфраструктура теперь в одной удобной и мощной системе. Готовы закрыть все боли одним решением? infrax.ru 🔥 #реклама О рекламодателе

Сколько сегодня нужно ОЗУ для нормальной работы Еще одна актуальная тема, которая часто сводится к тому, что раньше деревья были зеленее, небо синее, пиво вкуснее, девушки моложе… Но живем мы не в тех далеких и светлых временах, а в нашей современности, со своими подходами, задачами и технологиями. Если мы посмотрим минимальные требования современных ОС, таких как Windows 11 или Ubuntu 24.04, то увидим там от 4 ГБ и выше. У Windows 10 правда до сих пор стоит 2 ГБ, но это было написано давно и неправда, меньше 4 ГБ ей тоже лучше не предлагать. А вот новая Ubuntu 26.04 вообще порадовала нас минимальными 6 ГБ ОЗУ, вот, как хотите, так это и понимайте… Да куда же им столько??? Все туда, память – это ресурс и последние годы этот ресурс становился все более дешевым и все более доступным, текущий всплеск цен на рынке памяти общую тенденцию не меняет. А если есть ресурс, то его надо использовать, иначе зачем он нам? И его используют, хотя многие инновации остаются под капотом и невооруженным глазом не видны. Хотя есть и хорошие примеры: в Windows 11 инструмент Ножницы обзавелся собственной OCR, теперь чтобы распознать текст со сканера, фото или скриншота вам не нужен сторонний софт. В общем сегодня 4 ГБ — это нижний порог работоспособной системы и не важно, что вы на ней запускаете, Windows или Linux. Потому что основные потребители ОЗУ – это не ОС, а прикладное ПО, в первую очередь браузер. И это мы не говорим про комфортную работу, 4 ГБ это про то, что у нас система просто как-то работает, но мы прямо чувствуем, что ограничены со всех сторон, как старой тесной одеждой, из которой выросли. Если вы собираете сегодня ПК даже с самыми скромными требованиями, то смысла ставить туда менее 8 ГБ памяти нет, если вы только не хотите ежедневно и ежечасно страдать. Именно от 8 ГБ сегодня можно более-менее комфортно работать, но без претензий на что-то большее. Сегодня 8 ГБ – стартовый уровень объема ОЗУ, меньше которого уже просто нет смысла и который уже совсем скоро может стать нижним порогом, смотрите требования Ubuntu 26.04 выше. Если же мы говорим о системе начального уровня, но свободной от ограничений: нормальный офисный ПК, ноутбук для поездок и т.д. и т.п., когда мы хотим нормально работать и отдыхать, но сознательно не предполагаем запуска тяжелых приложений – то 16 ГБ сегодня норма жизни. Игровая станция? Рабочий ПК специалиста? Меньше 32 ГБ даже не думайте, а лучше сразу 64 ГБ. Когда-то это было роскошью и признаком гиков или крутых спецов, которые знали зачем им столько ОЗУ, теперь это просто объективная реальность. Поэтому сегодня берем на вооружение простую формулу: 16 - 32 - 64. Бюджет, средние системы, верхний уровень, при том, что мы указали минимальные рамки. И не нужно говорить, что это дорого, недоступно и все такое прочее. Фарш в обратную сторону не проворачивается, а пользователи привыкли к определенному уровню возможностей ОС и приложений. И затягивать пояса они не готовы. Технологии развиваются, они требуют ресурсов, но благодаря этим ресурсам пользователи получают различные возможности, которых раньше у них не было, хотя могут этого и не замечать. Сегодня любой современный ПК спокойно переварит редактирование 4К видео, хотя еще лет 10 назад под это потребовалась бы мощная многопроцессорная рабочая станция. Поэтому, если мы хотим оставаться в современном мире, то надо шагать в ногу. И выбирать объем ОЗУ не только с оглядкой на сегодня, но и прикинув что будет завтра. А как показывает практика – ОЗУ много не бывает.

На Яндекс Путешествиях отели сами выставляют цену А чтобы ваш отпуск был ещё более выгодным, Яндекс Путешествия: 👍 Предлагают скидки до 20% при бронировании в приложении 👍 Поощряют активных путешественников: участники Программы лояльности получают скидки до 25% на поездки 👍 Запускают промокоды со скидками для ваших выгодных бронирований А вот и один из них: ETO-FACT — промокод даст скидку 3000 ₽ на заказ от 30 000 ₽ Забронировать #реклама special.travel.yandex.ru О рекламодателе

Почему современное ПО такое неоптимизированное Данный вопрос не раз и не два всплывает в обсуждениях, обычно винят во всем современных программистов, которые, мол, не хотят или не умеют в оптимизацию и все такое прочее. Однако мало кто задумывается над другой стороной этой ситуации – современном рынке ПО. Потому что именно рынок обуславливает подходы к разработке и диктует правила. Если мы вернемся в старые добрые времена, то увидим, что цикл разработки ПО был длительным, мажорный релиз – целое событие, которого ждали, к которому готовились. ПО достаточно долго и качественно тестировалось. Но не потому, что раньше нравы были другие или специалисты круче. А потому что рынок ПО в то время был в основном представлен физическими носителями, а это было дорого и медленно. Поэтому если вы накосячили, то вы накосячили и это надолго. Либо рассылайте за свой счет патчи. Что касается оптимизации, то ПО всегда писалось и пишется под средний современный ПК, со всеми вытекающими и если можно относительно безболезненно повысить системные требования, то это будет сделано, поэтому что сильно дешевле, чем оптимизация, которую особо никто не заметит. По мере развития сети интернет дистрибуция ПО начала потихоньку переходить в него, пока полностью не вытеснила физические носители. Теперь программу можно просто скачать, а если можно просто скачать программу, то можно также просто скачать и исправление к ней. Это резко сократило цикл разработки, теперь можно быстро проверить ПО на грубые ошибки, а всякие недоработки закрыть патчами. Да, пользователь тут выступает в роли тестера, но этот недостаток легко перекрывается многими достоинствами. Какие же это достоинство? В основном – короткий цикл разработки и быстрое внедрение фич. Теперь вам не нужно ждать несколько лет следующего мажорного релиза чтобы получить новые функции, они появятся просто в очередном выпуске через несколько месяцев или полгода. Да и само понятие мажорных релизов как-то неожиданно кануло в Лету, большинство программ перешли или на сквозную нумерацию, или по дате выпуска, скажем 2506, где сразу понятно насколько давно выпущен этот релиз. В последние годы крайне серьезным фактором стал ИИ, который значительно ускорил процесс написания кода, а следовательно, позволяет еще сильнее сократить релизный цикл. Погодите, а кто мешает мне сделать все по старинке, качественно и выпустить на рынок действительно серьезный продукт? Никто не мешает, только этот «серьезный» продукт на массовом рынке (а мы говорим именно про массовый рынок) никому не нужен. В чем ценность любого ПО? Оно закрывает какие-то потребности пользователя и должно это делать наилучшим для пользователя образом. А еще оно должно развиваться и соответствовать всем современным требованиям. ПО с длительным циклом разработки конкуренции на современном рынке не выдержит. Никто не будет ждать год пока вы реализуете там новые фичи, пусть даже сделаете это идеально. Есть такая поговорка: лучше плохо ехать, чем хорошо стоять. Она как раз отражает суть происходящего сегодня на рынке ПО. Ваша программа может быть неидеальна, но она уже есть здесь и сейчас и поэтому она найдет своего пользователя. А дальше – проще, набрав пользовательскую базу уже можно развивать и дорабатывать продукт в нужную сторону. Тем более что бизнес уже закрутился, работает. Тем более, что вы видите, как пользователь использует ваш продукт, что ему нравится, что не нравится, что ему хочется, а какие возможности он не использует вообще. И это гораздо лучше, чем вложить в длительную разработку время и деньги, а после выяснить, что вы промахнулись мимо целевой аудитории. Сегодня рынок такого не прощает. Поэтому нравится нам это или не нравится, но современное ПО будет именно таким – на уровне поздней бета версии, с ошибками, недоработками, но при этом будет быстро и динамично развиваться. Что касается ресурсов, то об этом тоже думать никто не будет, как тогда, так и сейчас основной ориентир – средний современный ПК, тянуть старые системы никто не будет.