Когда Nmap не справляется (практичные альтернативы)

Nmap тормозит на большой сети?

🛠 Есть решения быстрее и тише.

1️⃣ Masscan: самое быстрое сканирование интернета. Асинхронный движок.
- Для чего: когда нужно просканировать /16 или больше за минуты.
- Команда: masscan -p1-65535 10.0.0.0/16 --rate=100000

2️⃣ RustScan: modern-альтернатива на Rust. Находит открытые порты, а затем передает их в Nmap для детального анализа.

- Для чего: сочетание скорости Masscan и мощи Nmap.
- Команда: rustscan -a <target> -- -A -sC // Найдет порты RustScan, просканирует Nmap

3️⃣ Naabu: еще один быстрый сканер портов на Go, часто используется в связке с другими инструментами пентеста.
- Для чего: для интеграции в автоматизированные пайплайны.

🏁 Итог: используйте Nmap для точечного и детального анализа. Для сканирования огромных диапазонов — masscan или rustscan.

🌐 @helcode | #bash #masscan #rustscan #альтернативы #производительность

Telegram-бот для алертов — просто и бесплатно

Telegram — идеальный канал для уведомлений:
1. Мгновенные push-уведомления
2. Бесплатно
3. Простая интеграция

🔧 Пример отправки алерта на Python:

python  
requests.post(f"https://api.telegram.org/botTOKEN/sendMessage",  
              json={"chat_id": "ID", "text": "🚨 CPU > 90%!"})  

Что можно мониторить?
✔️ Загрузка CPU/диска
✔️ Ошибки в логах
✔️ Изменения конфигов (inotifywait)

👉 Настроив бота, вы будете первым узнавать о проблемах!

🌐 @helcode | #telegram #bot

Выбор инструмента для работы с API: requests, httpx или aiohttp?

Стандартный подход к работе с внешними API часто начинается с функции requests.get(). Однако в продакшене возникают дополнительные требования: обработка ошибок, повторные попытки подключения, асинхронные вызовы и поддержка современных протоколов. Правильный выбор библиотеки позволяет повысить надежность и эффективность кода.

👨‍🔬 Рассмотрим три популярные библиотеки для работы с HTTP-запросами в Python.

1. requests (Стандарт для синхронных запросов)
Оптимальное решение для большинства синхронных задач.

import requests
response = requests.get('https://api.example.com/data', timeout=5)
data = response.json()

➕ Преимущества: простота использования, интуитивный синтаксис.

➖ Ограничения: требуется самостоятельная реализация повторных попыток и кэширования.

2. httpx (Современный синхронный и асинхронный клиент)
Поддерживает современные стандарты, включая HTTP/2 и асинхронные операции.

import httpx
# Асинхронный режим
async with httpx.AsyncClient() as client:
    response = await client.get('https://api.example.com/data')
    data = response.json()

➕ Преимущества: совместимость с синхронным и асинхронным кодом, высокая производительность.

➖ Ограничения: для использования асинхронного режима требуется понимание принципов async/await.

3. aiohttp (Специализированная библиотека для асинхронных задач)*
Предназначена для построения высокопроизводительных асинхронных приложений.

import aiohttp
import asyncio

async def fetch_data():
    async with aiohttp.ClientSession() as session:
        async with session.get('https://api.example.com/data') as resp:
            return await resp.json()

# Запуск асинхронной функции
data = asyncio.run(fetch_data())

➕ Преимущества: максимальная производительность при работе с большим количеством одновременных запросов.

➖ Ограничения: требует глубокого понимания асинхронного программирования.

Критерии выбора:
* Стандартные синхронные задачи: requests
* Современные проекты с поддержкой HTTP/2: httpx
* Высоконагруженные асинхронные приложения: aiohttp

Какой подход к работе с API вы используете в своих проектах?
1. requests (синхронный подход)
2. httpx (современное решение)
3. aiohttp (асинхронная обработка)
4. Другое (укажите в комментариях)

P.S. Сравнительный анализ библиотек помогает выбрать оптимальное решение для конкретных задач разработки, учитывая требования к производительности и масштабируемости.

Как мониторить логи в реальном времени?

⏳ Не ждите, пока пользователи пожалуются — ловите ошибки сразу!

Мониторинг Nginx/Apache:

tail -f /var/log/nginx/error.log | grep --line-buffered "error\|failed" | while read line; do  
  echo "Warning! $line" | send_to_telegram.sh  
done  

Отслеживание системных ошибок (journalctl):

journalctl -f -u your_service | grep -i "critical\|error"  

Инструмент inotifywait для отслеживания изменений файлов:

inotifywait -m /etc/nginx -e modify | while read path action file; do  
  echo "Файл $file изменён! Проверьте конфиг!"  
done  

👉 Так вы узнаете о проблемах раньше пользователей.

🌐 @helcode | #bash #мониторинг #логи

Как работать с JSON в PowerShell?

🔧 Парсим, создаём и преобразуем JSON без боли!

PowerShell легко конвертирует объекты в JSON и обратно.

👨‍🔬 Преобразование объекта в JSON

$user = @{
    name = "Alice"
    age = 30
    hobbies = @("coding", "gaming")
}
$user | ConvertTo-Json -Depth 3

# Результат:
# {
#   "name": "Alice",
#   "age": 30,
#   "hobbies": ["coding", "gaming"]
# }

📖 Чтение JSON из файла

$data = Get-Content -Path "config.json" -Raw | ConvertFrom-Json
$data.name

Работа с вложенными свойствами

$response = Invoke-RestMethod -Uri "https://api.github.com/users/octocat"
$response.login
$response.created_at

💬 Обсуждение:
Какие самые интересные задачи с JSON вам приходилось решать в PowerShell?



P.S. Если ConvertFrom-Json ругается на глубину, увеличьте параметр -Depth

🌐 @helcode | #powershell #json #автоматизация

try-except: спасательный круг или тихий убийца вашего кода?

⚙️ Конструкция try-except — первый инструмент, который приходит на ум для обработки ошибок. Но ее неаккуратное использование может скрыть критические проблемы, привести к неожиданному поведению программы и затруднить отладку. Слишком широкий except — все равно что лечить все болезни обезболивающим: симптомы уйдут, а причина останется.

Рассмотрим частые ошибки и способы их избежать.

⚠️ Ошибка 1: слишком широкий обработчик исключений
Такой код перехватит все исключения, включая системные (например, KeyboardInterrupt).

# ПЛОХО: Перехватывает вообще всё
try:
    risky_operation()
except:  # <- Ничего не указано!
    print("Что-то пошло не так")

✅ Решение: явно указывайте типы исключений, которые вы ожидаете и можете обработать.

# ХОРОШО: Точечная обработка
try:
    risky_operation()
except (ValueError, IndexError) as e:  # <- Конкретные исключения
    print(f"Обработали ожидаемую ошибку: {e}")

⚠️ Ошибка 2: "глухой" обработчик (silent failure)
Код проглатывает ошибку, и программа продолжает работать в невалидном состоянии.

# ОПАСНО: Ошибка просто исчезает
try:
    save_to_database(data)
except:
    pass  # Ничего не происходит. Данные не сохранены, а мы и не знаем.

✅ Решение: всегда как минимум логируйте исключение.

# ЛУЧШЕ: Фиксируем проблему
import logging

try:
    save_to_database(data)
except DatabaseError as e:
    logging.error(f"Ошибка записи в БД: {e}")  # Сообщение в лог
    # Возможно, здесь стоит повторно бросить исключение или выполнить иное действие

⚠️ Ошибка 3: непреднамеренная обработка исключений в цикле
Одно исключение внутри цикла может остановить всю обработку, если перехватывать его неправильно.

# Осторожно: Одна ошибка прервет весь цикл
data = [1, 2, "three", 4, 5]  # Строка вызовет TypeError при сложении
total = 0
for num in data:
    try:
        total += num
    except TypeError:
        # Обработали для элемента "three", цикл продолжается
        print(f"Элемент {num} не является числом")
print(total)  # 12

Ключ к эффективному использованию try-except — предсказуемость. Обрабатывайте только те ошибки, которые вы можете корректно исправить или проинформировать о них систему логирования. Все остальные исключения лучше позволить всплыть наверх, где их обработает более общий обработчик или где разработчик увидит понятный traceback.

P.S. Правильно настроенная обработка исключений — это не про то, чтобы скрыть проблемы, а про то, чтобы управлять ими предсказуемо и предоставлять четкую информацию для диагностики.

🌐 @helcode | #python #автоматизация

Самовосстановление — как скрипты могут чинить сервера?

🚨 Проблема: сервис упал, диск переполнен, а вас нет на месте.

🛠 Решение: скрипты, которые не только мониторят, но и исправляют!

Авторестарт сервиса, если он упал:

if ! systemctl is-active --quiet nginx; then  
  systemctl restart nginx  
  curl -X POST "https://api.telegram.org/.../sendMessage" -d "chat_id=...&text=NGINX перезапущен!"  
fi  

Очистка диска при нехватке места:

if [ $(df / --output=pcent | tail -1 | tr -d '%') -gt 90 ]; then  
  find /var/log -type f -mtime +7 -delete  
fi  

Блокировка IP при атаке (fail2ban альтернатива):

grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | awk '$1 > 3 {print $2}' | while read ip; do  
  iptables -A INPUT -s $ip -j DROP  
done  

👉 Настроил и забыл — скрипты работают за вас!

🌐 @helcode | #bash #скрипты

Лучшие модули для DevOps

🛠 Набор must-have инструментов для каждого инженера!

Вот список модулей, которые реально экономят время.

1. PSWindowsUpdate

Install-Module -Name PSWindowsUpdate -Force
Get-WindowsUpdate -Install -AcceptAll -AutoReboot

2. Az (Azure PowerShell)

Install-Module -Name Az -Force
Connect-AzAccount
Get-AzVM

3. DBATools (для работы с БД)

Install-Module -Name dbatools -Force
Get-DbaDatabase -SqlInstance "server01" | Where-Object Name -eq "mydb"

4. PSScriptAnalyzer (проверка качества кода)

Install-Module -Name PSScriptAnalyzer -Force
Invoke-ScriptAnalyzer -Path .\MyScript.ps1

5. ImportExcel (работа с Excel без Excel)

Install-Module -Name ImportExcel -Force
Get-Process | Export-Excel -Path "processes.xlsx"

Вопрос:
Какие ваши любимые модули PowerShell? Дополните список!



P.S. Если модуль не устанавливается, проверьте политику выполнения: Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

🌐 @helcode | #powershell

Куда смотрят логи? Настраиваем логирование для cron

Молчащий cron — самый опасный. Выполнилась задача или упала с ошибкой? Без грамотного логирования вы никогда не узнаете.

По умолчанию cron пытается отправить вывод на почту (MAILTO), но это часто не работает.

Берём логирование в свои руки!

Перенаправляем вывод (stdout + stderr) в файл:
* * * * * /path/to/script.sh >> /var/log/myscript.log 2>&1

Можно и раздельно:
* * * * * /path/to/script.sh >> /var/log/myscript.log 2>> /var/log/myscript.error.log

Профи-фишка: Логи с датой в названии для ротации.
0 0 * * * /path/to/daily_backup.sh >> "/var/log/backup_$(date +\%Y\%m\%d).log" 2>&1

❗️Важно: экранируйте `%` знаками обратного слеша, чтобы `cron` их не воспринял как перенос строки!

🌐 @helcode | #linux #cron #logging #debugging

PowerShell vs. Bash: битва титанов терминала. Кто победит в скорости?

⚔️ Вечный спор: что выбрать для автоматизации под Windows/Linux? Старый добрый Bash или современный PowerShell? Один славится своей лаконичностью и скоростью на родных сервисах, другой — мощной объектной моделью и кроссплатформенностью. Но что объективно быстрее? Спойлер: ответ — «это зависит от задачи».

Давайте разберем на примере, где каждый силен.

Посчитать количество файлов с расширением .log в директории и ее поддиректориях.

Bash (Linux/macOS/WSL):

find /path/to/dir -name "*.log" | wc -l

➕ Плюсы: максимально близко к ядру ОС. Минимальные накладные расходы. Невероятно быстр для таких системных задач.
➖ Минусы: работает с текстом. Если нужно проанализировать атрибуты файлов — сложно.

PowerShell (Windows/Linux/macOS):

(Get-ChildItem -Path C:\path\to\dir -Filter *.log -Recurse -File).Count

➕ Плюсы: возвращает не текст, а объекты файлов. Дальнейшая обработка (например, по дате создания или размеру) проще и не требует парсинга.
➖ Минусы: запуск полноценного .NET runtime имеет свою стоимость. Для простых задач может быть медленнее.

Постараюсь структурировать и объяснить:
👉 Bash быстрее в чисто файловых операциях, текстовой обработке (grep, sed, awk) и запуске других процессов, потому что это нативный язык оболочки в UNIX-подобных системах.
👉 PowerShell быстрее (и точно проще), когда нужно работать со структурированными данными: объектами, JSON, XML, API. Его конвейер передает объекты, а не текст, что исключает ошибки парсинга.

Вердикт: если вам нужно быстро «выполнить и забыть» — Bash может быть шустрее. Если вы строите сложный скрипт с богатой логикой обработки данных — PowerShell выиграет за счет читаемости и мощи.

А что вы чаще используете для своих задач автоматизации?
1. Bash (старая добрая классика)
2. PowerShell (объектная мощь)
3. Python / Другое (уже перешел на скрипты)
4. Зависит от ОС и задачи (использую тот инструмент, который лучше подходит)

P.S. Идеального инструмента нет. Есть задача и есть инструмент, который для нее лучше всего подходит. Главное — знать сильные стороны каждого!

🌐 @helcode | #bash #powershell #битва

Анализ логов auditd: находим угрозы
Как читать логи и создавать отчёты?

1. Утилиты:
- Поиск по метке:

  sudo ausearch -k sudo_usage
  

- Отчёт по файлам:

  sudo aureport -f
  

2. Пример лога:

type=SYSCALL msg=audit(...): uid=0 comm="rm" key="file_deletion"

👉 Что было: пользователь с UID=0 запустил rm.

🌐 @helcode | #bash

Ты используешь PowerShell на 10%? Раскрываем скрытые возможности 7-й версии! 🚀

Многие до сих пор представляют PowerShell как просто более мощную командную строку Windows. Но это уже давно не так. PowerShell 7 — это кроссплатформенный (Windows, Linux, macOS), современный движок для автоматизации, который таит в себе фичи, способные сэкономить часы работы.

Вот несколько скрытых жемчужин, о которых вы могли не знать:

1. Параллельное выполнение с ForEach-Object -Parallel
Забудьте о медленном последовательном переборе. Теперь можно легко распараллелить задачи.

# Старое: последовательно (медленно)
1..10 | ForEach-Object { Start-Sleep -Seconds 1; "Обработан элемент $_" }

# Новое: параллельно (быстро!)
1..10 | ForEach-Object -Parallel {
    Start-Sleep -Seconds 1
    "Обработан элемент $_ в потоке $($env:OS)"
} -ThrottleLimit 5 # Ограничиваем число одновременных потоков

2. Условный оператор && и || (как в Bash)
Наконец-то! Знакомый синтаксис для выполнения команд по условию.

# Выполнить вторую команду, только если первая успешна
Get-Process -Name "SomeApp" && Write-Host "Процесс найден!"

# Выполнить команду, если первая провалилась
Get-Process -Name "NonExistentApp" || Write-Error "Процесс не найден"

3. Оператор нулевого слияния ?? и присваивания ??=
Пришли из C#. Идеальны для работы с потенциально $null переменными.

# Если $name is $null, использовать значение по умолчанию
$displayName = $name ?? "Неизвестный пользователь"

# Присвоить значение переменной, только если она $null
$config ??= Get-Content "config.json" | ConvertFrom-Json

4. Автодополнение на TAB для -WhatIf и -Confirm
Просто нажмите Tab после параметра -Confirm или -WhatIf, чтобы быстро выбрать $true или $false.

Эти фичи делают код не только мощнее, но и лаконичнее и читаемее. Параллелизм, удобные операторы и безопасная работа с $null — признаки современного языка скриптинга.

А вы уже перешли на PowerShell 7? Какая фича нравится больше всего?

P.S. PowerShell 7 — это как найти у своей старой собаки новые трюки. Очень крутые трюки. Советуем обновиться!

🌐 @helcode | #powershell

Когда cron уже не enough? Смотрим в сторону systemd.timer

Cron — классика, но для сложных сценариев есть более мощная альтернатива — systemd.timer.

В чем его суперсила?

🎯 Точность до секунд (в cron — только минуты)
🎯 Запуск после пропуска: Сервер был выключен? cron пропустит задачу. systemd.timer с опцией Persistent=true — выполнит при следующем включении!
🎯 Зависимости: Можно указать, чтобы задача запускалась только после старта сети (After=network-online.target) или другого сервиса.
🎯 Встроенное логирование в journalctl: все логи задачи в одном месте

Пример таймера для ежедневного бэкапа в 3:00:
/etc/systemd/system/backup.timer

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

Вывод: для простых задач — cron. Для сложных, надежных и интегрированных в систему — systemd.timer.

🌐 @helcode | #bash #linux #systemd #cron #automation

ForEach vs. ForEach-Object: раскладываем по полочкам скорость и применение!

В PowerShell есть два основных способа перебора коллекций, и выбор между ними — это не просто вопрос стиля, а вопрос эффективности и правильного применения. Непонимание разницы может привести к значительному замедлению скриптов, особенно при работе с большими объемами данных.

Давайте разберем два главных участника гонки.

1. ForEach (оператор языка)
Это оператор языка PowerShell. Он работает *быстрее*, но загружает всю коллекцию в память *до начала* обработки.

# Синтаксис оператора ForEach
$result = foreach ($item in $largeCollection) {
    # Обработка каждого элемента
    $item * 2
}

✅ Плюсы:
- Высокая скорость выполнения. Идеален для операций в памяти.
- Удобочитаемость. Легко читается и понимается.

⛔️ Минусы:
- Потребляет больше памяти. Вся коллекция должна поместиться в оперативной памяти.

2. ForEach-Object (cmdlet в конвейере)
Это cmdlet, который чаще всего используют в конвейере (с символом |). Он обрабатывает элементы *по одному*, что экономит память.

# Синтаксис cmdlet ForEach-Object в конвейере
$result = $largeCollection | ForEach-Object -Process {
    # Обработка каждого элемента
    $_ * 2
}

✅ Плюсы:
- Экономия памяти. Обрабатывает элементы потоком, не загружая все сразу. Критично для больших данных.
- Интеграция с конвейером. Можно легко встраивать в цепочки обработки.

⛔️ Минусы:
- Относительно медленнее. Из-за накладных расходов на передачу объектов по конвейеру.

🧑‍⚖️ Вердикт:
- Скорость и маленькие коллекции? Выбирайте оператор foreach.
- Большие файлы, результаты командлетов или экономия памяти? Выбирайте ForEach-Object в конвейере.

Наглядный тест:

$testData = 1..10000

Measure-Command { $r1 = foreach ($i in $testData) { $i * 2 } } | Select-Object TotalMilliseconds
Measure-Command { $r2 = $testData | ForEach-Object { $_ * 2 } } | Select-Object TotalMilliseconds

Результаты покажут, что foreach оператор заметно быстрее на таких операциях.

А вы замечали разницу в скорости? Какой метод используете чаще?
1. foreach (оператор) — скорость важнее!
2. ForEach-Object (конвейер) — привычка и удобство конвейера
3. Зависит от ситуации — использую оба, в зависимости от задачи
4. .ForEach({}) метод — есть же еще и третий вариант!

P.S. Есть еще и третий, менее известный способ — метод .ForEach({}) у коллекций. Он быстрее конвейера, но медленнее оператора. Но это уже тема для отдельного поста!

🌐 @helcode | #powershell

3 простых скрипта для автоматизации

1. Мониторинг доступности сайта (Python)

if requests.get("https://example.com").status_code != 200:  
    print("Сайт лежит!")  

2. Парсинг логов Nginx + алерты в Telegram (Bash)

grep "error" /var/log/nginx/error.log | tail -n 5 | curl -X POST в Telegram...  

3. Автоочистка диска

if [ $(df -h / | awk 'NR==2 {print $5}' | tr -d '%') -ge 90 ]; then  
    find /var/log -name "*.log" -mtime +7 -delete  
fi  

👉 Добавляем в cron — и мониторинг работает сам!

🌐 @helcode | #python #bash #скрипты #автоматизация

Мониторим CPU и память — простые скрипты для Linux и Windows

🤔 Проблема: Сервер тормозит, но вы не знаете, в чём причина.

✅ Решение: Скрипты для мониторинга нагрузки.

Linux (Bash + Python):

# Загрузка CPU  
top -bn1 | grep "Cpu(s)" | awk '{print "CPU: " 100 - $8 "%"}'

python  
# Загрузка памяти  
import psutil  
print(f"RAM: {psutil.virtual_memory().percent}%")  

Windows (PowerShell):

powershell  
# CPU  
Get-CimInstance Win32_Processor | Select LoadPercentage  
# Память  
Get-CimInstance Win32_OperatingSystem | Select FreePhysicalMemory, TotalVisibleMemorySize  

👉 Добавьте алерты в Telegram — и вы всегда будете в курсе перегрузок!

🌐 @helcode | #bash #python #powershell

Скрипт упал в 3 часа ночи. Как он может сам отправить алерт в Slack или Telegram?

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

Отправка сообщений через популярные мессенджеры via API — это проще, чем кажется. Вот готовые рецепты.

1. Отправка в Slack через Incoming Webhook

Шаг 1: создаем входящий вебхук в вашем Slack-рабочем пространстве (Settings & administration -> Manage apps -> Incoming Webhooks).

Шаг 2: используем Invoke-RestMethod в PowerShell:

$Uri = "https://hooks.slack.com/services/your/unique/webhook/url" # Ваш URL вебхука
$Body = @{
    text = "✅ Скрипт `Backup-Database` успешно завершился на сервере $($env:COMPUTERNAME) в $(Get-Date)"
} | ConvertTo-Json

# Отправляем сообщение
Invoke-RestMethod -Uri $Uri -Method Post -Body $Body -ContentType 'application/json'

2. Отправка в Telegram через Bot API

Шаг 1: создаем бота через @BotFather и получаем его API-токен. Узнаем свой chat_id (можно написать боту, а затем вызвать https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates).

Шаг 2: пишем скрипт для отправки:

$BotToken = "1234567890:Your_Bot_Token_Here"
$ChatID = "123456789" # Ваш chat_id

# Текст сообщения
$Message = "⚠️ Внимание! Скрипт `DataProcessing` на $($env:COMPUTERNAME) завершился с ОШИБКОЙ: $($Error[0].Exception.Message)"

# Формируем URL и отправляем запрос
$TelegramAPIUrl = "https://api.telegram.org/bot$BotToken/sendMessage"
$Body = @{
    chat_id = $ChatID
    text = $Message
    disable_notification = $false
} 

Invoke-RestMethod -Uri $TelegramAPIUrl -Method Post -Body $Body -ContentType 'application/x-www-form-urlencoded'

Оба способа используют REST API и встроенный командлет Invoke-RestMethod, который идеально подходит для таких задач. Главное — надежно храните токены и URL вебхуков (например, в переменных окружения или зашифрованных конфигах).

А куда вы отправляете алерты и мониторите выполнение задач?
1. Slack — мой лучший друг по оповещениям
2. Telegram — удобно все получать в телефон
3. Email — старый добрый Send-MailMessage
4. Microsoft Teams — корпоративный стандарт
5. Другое (Grafana, PagerDuty, etc.) — мониторинг прокачан до предела

P.S. Настроив такие оповещения, вы сможете спокойно пить кофе (или спать), пока ваши скрипты сами докладывают о результатах своей работы. Это следующий уровень автоматизации!

🌐 @helcode | #powershell

А что если...? Мифы про автоматизацию мониторинга

Миф 1: "Автоматизация — это сложно и дорого".
➜ На самом деле: Bash/Python-скрипты пишутся за 10 минут и работают без лишних затрат.

Миф 2: "Готовые системы (Zabbix) всегда лучше".
➜ На деле: Для 1-5 серверов скрипты часто эффективнее.

Миф 3: "Скрипты ненадёжны".
➜ Реальность: Если их тестировать и добавлять в cron/systemd, они работают годами.

Миф 4: "Telegram-боты — это ненадёжно".
➜ Практика: Боты слабо зависят от инфраструктуры и приходят даже при частичных сбоях.

👉 Вывод: Не бойтесь начинать с малого — даже простые скрипты экономят часы работы!

🌐 @helcode | #миф #автоматизация

Почему Out-File и > могут подставить свинью с кодировкой?

Казалось бы, что может быть проще команды Get-Content file.txt | Out-File result.txt или dir > files.txt? Но потом вы открываете файл и видите вместо кириллицы кракозябры � или странные символы. В чем подвох? Всё дело в кодировке, которую PowerShell выбирает по умолчанию.

Проблема кроется в «умолчаниях». PowerShell (до 7-й версии) по умолчанию использует кодировку UTF-16LE (которая в мире Windows часто называется Unicode). Это широко распространенная кодировка, но у нее есть два больших минуса:
1. Она использует два байта на символ, что увеличивает размер файла.
2. Многие внешние инструменты (например, классический notepad.exe, системы Linux) ожидают увидеть кодировку UTF-8 или ASCII.

Пример проблемы:

# Записываем строку с кириллицей
"Привет, мир!" > test.txt

Откройте test.txt в Блокноте (Notepad) — вы увидите текст корректно. Но попробуйте посмотреть его в консоли Linux с помощью cat или обработать другим скриптом — высока вероятность увидеть проблемы.

❔ Как это исправить? Явно указываем кодировку с помощью -Encoding.

1. Для максимальной совместимости (особенно с другими ОС и инструментами) используйте UTF-8:

"Привет, мир!" | Out-File -FilePath .\test.txt -Encoding utf8
# Или для PowerShell 7.2+, где есть UTF-8 без BOM (самый современный вариант):
"Привет, мир!" | Out-File -FilePath .\test.txt -Encoding utf8NoBOM

2. Если вам нужна обратная совместимость со старыми приложениями Windows (например, для файлов конфигурации .ini), используйте ASCII или UTF-8 с BOM:

Get-Process | Out-File proc_list.txt -Encoding ascii # Только англ. символы
Get-Service | Out-File services.txt -Encoding utf8 # UTF-8 с меткой (BOM)

3. Если вы работаете исключительно в среде Windows и вам нужна поддержка Unicode — тогда используйте стандартную кодировку:

# Тот самый вариант по умолчанию
Get-Content input.log | Out-File output.log -Encoding unicode

Метка (BOM) в начале файла помогает редакторам понять кодировку, но некоторые инструменты (например, скрипты на Linux) могут ее не понимать. Поэтому utf8NoBOM — это часто самый универсальный выбор для новых проектов.

А вы сталкивались с проблемами кодировки? Какую предпочитаете использовать?
1. utf8NoBOM (современно и универсально)
2. utf8 (с меткой, для уверенности в Windows)
3. ascii (только для английского текста)
4. Не заморачиваюсь, использую стандартную (пока не прижмет) 😅
5. Другая (поделитесь опытом в комментариях!)

P.S. Правильно выбранная кодировка — это как отправить письмо на языке, который адресат точно поймет. Out-File по умолчанию говорит на диалекте, который понимают не все. Всегда указывайте -Encoding для важных файлов!

🌐 @helcode | #powershell

"А если сервер упадёт?" — Мониторим сам мониторинг

🤔 Проблема: А кто следит за тем, чтобы сами скрипты мониторинга работали?

✅ Решение: Простые проверки:

Проверка, что скрипт запущен (Bash):

if ! pgrep -f "monitor_script.sh"; then  
  /path/to/monitor_script.sh &  
  echo "Скрипт упал и был перезапущен!" | send_to_telegram  
fi  

Логирование работы скрипта:

*/5 * * * * /path/to/script.sh >> /var/log/monitoring.log 2>&1  

Внешний "наблюдатель" (например, UptimeRobot):
➜ Бесплатно мониторит доступность сервера и шлёт SMS/email, если он не отвечает.

👉 Теперь ваш мониторинг действительно надёжен!

🌐 @helcode | #bash #логи #мониторинг