Создать зеркало обновлений для Eset Nod32?

Однажды я уже писал об этом, но с того момента над скриптом было проведено не мало работы. Скажу более — он был переписан чуть менее чем полностью, и как следствие — выяснились некоторые очень «интересные» моменты. Один из них заключается в том, что старая версия скрипта хоть и работала, но совсем не так, как надо.

Если подробнее — то она не подходила для версий антивируса старше четвертой. Как оказалось — нод не умеет самостоятельно определять под-директорию из которой ему следует обновиться, и как следствие все пытались обновиться из корня — и как следствие обновлялась только «четверка». Далее — старая версия не умела обновлять компоненты антивируса. Далее — в итоговое зеркало не попадали все необходимые «модули». Ещё — был чертовски кривой веб-интерфейс.

Так же просмотрел значительное количество решений других разработчиков. Забавно то, что 90% из них написаны на php, и состоят из одного файла с лютым хардкодом всего что можно, и чего нельзя. Да и не поддерживаются совсем.

А что же теперь? А теперь мне удалось избавиться и от этих проблем, и попутно (с момента публикации этого поста уже произошли какие-то изменения, однозначно) повысить стабильность. Не получилось пока реализовать авто-обновление, но я над этим думаю. Традиционно скрипт умеет сам искать ключи.

Подробнее под катом

LEMP + CentOS = ❤

Данный пост скорее заметка для самого себя, дабы не забыть чего при новой итерации. Нового в ней ничего нет, ставим пакеты да настраиваем. У нас имеется новый и девственно чистый сервер под управлением CentOS 7.2 (minimal). Задача — поставить на него nginx + php + php-fpm + mysql и чтоб всё это шустро работало, да обновлялось самостоятельно из репозиториев (при возможности). Так же необходим тот же phpMyAdmin и настроенная отправка почты с сервера. В общем — минимальный web-stack, на котором хоть разработкой занимайся, хоть что-то вордпресо-подобное разворачивай. Сервер, к слову, располагается на hetzner.de.
Подробнее под катом

CentOS — обновляем php до 5.6

Задался вопросом — при разработке web-приложений под какую версию php их «затачивать»? Ответ оказался проще некуда — достаточно посмотреть на календарь релизов и понять, что на данный момент поддерживаемой является версия 5.6.19:

PhpCurrentlySupportedVersions

И ну никак не та (5.4.16), что встала из репозитория epel «по умолчанию». Для того чтоб исправить сложившуюся ситуацию выполним совсем не сложные действия, описанные ниже.

Подробнее под катом

Настройка хостинга на RU-Center (nic.ru)

Так уж сложилось, что время от времени приходится поднимать сайты на хостинге руцентра. Как правило это небольшие сайты-визитки или проекты, для которых реализация на дедике характеризуется как «жирно будет».

Итак, отбросим причины в сторону. Первым делом — что нам понадобится для того чтоб всё сделать «под ключ», т.е. владельцем домена/хостинга был заказчик (как физ.лицо), а ты был лишь лицом, которое выполняет работу? От заказчика тебе потребуется:

  • Фотографии/сканы разворота паспорта и страницы с пропиской;
  • Логин/пароль от почтового ящика, который будет фигурировать при регистрации;
  • Необходимая сумма денег для оплаты требуемых услуг.

Вопрос: При регистрации домена может сразу встать вопрос — делегировать домен на руцентр или, например, сразу же на DNS-хостинге от Яндекса?

Ответ: На руцентр. Так как для делегирования на Яндекс потребуется подтвердить права на владение доменом. И проще всего это сделать с помощью проверки наличия определенного файла с кодом в корне сайта. Поэтому — смело всё делай по дефолту, потом переделегируем, если потребность такая возникнет.

Сразу скажу — если «с сайта» будут отправляться письма и при этом хостить DNS у Яндекса — возникнут проблемы с отправкой писем. DKIM настроить на Яндекс будет невозможно, а у руцентра он принципиально не настраиваемый. Поэтому считай это тонкостью использования руцентра в целом.

Итак, считаем что аккаунт у нас заведен, домен — зарегистрирован, хостинг — заказан. Не забудь а «Личных данных» приложить сканы/фотографии паспорта клиента для верификации личности, так правильнее будет.

Подробнее под катом

RSS → Bash → Transmission

Нахрен долгое вступление. Если на вопрос «Нравится автоматизировать и любишь посмотреть кино?» ты неосознанно ответишь положительно, то то что здесь написано — тебе понравится. Итак, наверняка у тебя есть своя железяка, которая стоит дома/офисе где-то в уголочке и выполняет роль файлошары/торрентокачалки и Джа знает ещё чего.

Железяка (4 фотки в 1)
Hardware:
Мать MSI C847IS-P33
Камень Распаян на плате, Intel(R) Celeron(R) CPU 847 @ 1.10GHz / 2 ядра
Память DDR3 @ 2 Gb
SDD (система) Kingston @ 8 Gb
HDD (данные) WG Green @ 2 Tb

Что такое RSS torrent?

Это RSS лента, в которой вместо привычных новостей публикуются ссылки на .torrent файлы выбранной тобой тематики. Придумали это давно, и прогрессивный народ активно этим пользуется. Есть даже сервисы, такие как:

Которые этим и живут. Конечный пользователь приходит, выбивает интересный ему контент, получает ссылку на свою ленту, кормит её своему торрент-клиенту (который в свою очередь должен поддерживать torrent rss) — получая в конечном счете новые серии любимых сериалов/фильмов определенной тематики почти без задержки и лишних действий. Пиздец как удобненько.

Подробнее под катом

MikroTik — режем рекламу (ADBlock) с помощью DNS

У данного поста имеется продолжение, позволяющее автоматизировать и значительно упростить весь процесс, описанный в этой записи. Располагается оно по этой ссылке.

Прочитав пост тов. 4aba о том, как с помощью dnsmasq на прошитом роутере можно вполне успешно резать рекламные баннеры на всех устройствах, которые подключены к нашей точке доступа возник резонный вопрос — а можно ли реализовать аналогичное на маршрутизаторе Mikrotik hAP lite? Железка довольно таки достойная (650MHz @ RAM 32 Mb), но у нас нет полноценного linux-шелла на ней. Оказывается — можно, и результате было реализовано довольно простое, но эффективное решение.

Пришлось пойти немного другим путем, а именно — прописать статичные DNS маршруты, которые при запросе «рекламного домена» переадресовывали наш запрос на 127.0.0.1.

Списки «рекламных доменов» мы возьмем из открытых источников, таких как http://pgl.yoyo.org/adservers/ и https://adaway.org/hosts.txt (с легкостью можно изменить на любые другие), приведем их в подобающий вид и оформим в виде скрипта для нашего Mikrotik-а, чтоб с помощью одной команды все их ему и «скормить».
Подробнее под катом

Маленькая хитрость iptables

При сканировании портов целевой системы можно довольно часто наблюдать результат вида:

...
8080/tcp  filtered http-proxy
...

Что говорит нам о том что порт наверняка используется системой, но «прикрыт» извне. Не смотря на то что работать с ним врятли будет возможно — он всё же дает исследуемому дополнительную информацию о исследуемой системе.

Как проще всего прикрыть порт извне используя iptables?

$ iptables -A INPUT -p tcp --dport %номер_порта% -j DROP

А как можно прикрыть его так, чтоб он был недоступен только лишь извне, да ещё и не отображался в результатах nmap как filtered?

$ iptables -A INPUT ! -s 127.0.0.1/8 -p tcp --dport %номер_порта% -j REJECT --reject-with tcp-reset

Если по-человечески, то это означает:
Для всех входящих пакетов (кроме локального хоста (127.0.0.1/8)), приходящих по протоколу tcp на порт %номер_порта% ответить ICMP уведомлением tcp-reset, после чего пакет будет «сброшен»

Так же возможны варианты ICMP ответа: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited и icmp-host-prohibited

После чего не забудьте выполнить:

$ service iptables save; service iptables restart

Для выполнения $ service iptables save в системе должен присутствовать пакет iptables-services

Если в системе работает fail2ban обязательно перед выполнением $ service iptables save остановите его, выполнив $ service fail2ban stop