{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Sumpira Live #blogek", "_rss_description": "#blogek, Sumpira, Live, Sumpira-service, Alexsoft, Blog", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.sumpira.space\/blogek\/", "feed_url": "https:\/\/www.sumpira.space\/blogek\/?go=rss%2F", "icon": "https:\/\/www.sumpira.space\/blogek\/pictures\/userpic\/userpic@2x.jpg?1690232400", "authors": [ { "name": "Alex Sumt", "url": "https:\/\/www.sumpira.space\/blogek\/", "avatar": "https:\/\/www.sumpira.space\/blogek\/pictures\/userpic\/userpic@2x.jpg?1690232400" } ], "items": [ { "id": "40", "url": "https:\/\/www.sumpira.space\/blogek\/?go=all\/pochtovy-server-est-li-smysl\/", "title": "Почтовый сервер: есть ли смысл?", "content_html": "

После переезда на домашний хостинг стало понятно, что почты, привязанной к домену, просто нет.<\/p>\n

Поэтому решено было поднимать на сервере, которым является одна из самых дешевых версий NAS. Очень хочется продолжить получать письма на собственный домен, несмотря на то, что многие источники рекомендуют этого не делать (об этом чуть ниже).
\nВ самой системе от производителя был предоставлен почтовый сервис, который очень легко настраивался и, даже в отсутствие удобоваримых инструкций на родном языке, смог поработать какое-то время. Я получил бесценный опыт и разобрался, как устроена работа почти всех почтовых серверов (а не просто рассылка информационных писем в один конец). Пришлось изучить такие понятия, как MX, SPF, DMARC, DKIM и прочие, какие надо сделать DNS записи у регистратора домена, какие настройки на самом сервере, а также что попросить у провайдера. На удивление, встроенная программа оказалась нетребовательной, хоть и устаревшей (мне для 1-3 писем в неделю с одного ящика этого хватило бы с лихвой), но не тут то было. Производитель захотел сделать другой сервис, но платный (ох уж этот ненавидимый мною вид развода: платные подписочки<\/b>). И новая разработка получилась довольно ёмкой и ресурсозатратной, поэтому для моего дешевенького NAS было придумано... просто удалить в новой версии прошивки старый сервис без возможности установки нового<\/i>.
\nВыхода было два: либо остаться без обновлений, либо без почтовика... Я выбрал второе, ведь кроме почтs там работает много других сервисов, для которых важны обновления (как ни странно, но это влияет на безопасность). Правда, такой выбор меня оставил в покое ненадолго. Ну не бывает же так все плохо...
\nЧто мы имеем? Сервер на каком-то обрезанном Unix, наверняка он что-то ещё поддерживает кроме встроенных приложений. Ответ был найден: Docker<\/b>. В системе нашелся Менеджер контейнеров<\/b>, который позволил запускать Docker-приложения.
\nУ меня уже было поднято несколько докеров, поэтому ресурсы в виде памяти и загрузки процессора были на вес золота. Но читать кучу мануалов просто не было времени, поэтому я обратился за помощью к ИИ. Выбрал несколько, чтобы сверять их ответы. И мне агентами было предложено несколько докеров: mailserver, stalwart, mox<\/b> и maddy<\/b>. Это самые легкие варианты, но, скажу сразу, при их кажущейся легкости, Mox умирал сразу после старта, mailserver на следующий день, остальные тупили, нагружая сервер своим присутствием. Stalwart ещё оставил дыру, через которую полезли спамеры, и я получил blacklist у spamhaus и его собратьев.
\nЯ не верил слепо предложениям ИИ, проверяя их по нескольку раз. В результате построил сервер на maddy, отказавшись от визуала (называемого веб-мордой, как у stalwart), и общаясь с сервером через менеджер или терминал. А далее просто подключил почтовый клиент, и работаю с корреспонденцией через него.
\nСамое сложное было — грамотная настройка DNS записей у регистратора домена, чтобы сервер был принят как полноценный и не попадал в черные списки, то есть, нужно было заботиться о репутации. Крупные бесплатные почтовые сервисы, вроде GMail, Outlook<\/i>, не любят маленьких конкурентов, и письма от них получать не хотят. Бывает, проскочит несколько писем, а потом тебя отправляют в блок. ИИ советует использовать SMTP-relay<\/b>, то есть релей (или сторонний сервер) с хорошей репутацией, через который будет происходить отправка писем (получение же идет напрямую без проблем). Но это мы запускаем в систему посторонних участников, без которых я решил обходиться. Один из ИИ предложил настроить работу доменной почты вообще на стороннем сервере — Cloudflare<\/b>, то есть все записи отправить на этот облачный сервер и работу сайта тоже прогонять через него. Всё выглядит красиво, и этот облачный сервис даже не единственный, кто предлагает такие услуги, если бы не одно НО<\/b>: российские ТСПУ<\/i>, которые просто их блочат.
\nСразу скажу, что я искал именно бесплатные варианты, которые работают, и где есть либо полное перенаправление на сторонние сервисы, либо релей. И среди бесплатных сервисов много несуразностей, вроде отсутствия IMAP, использования только собственных приложений и прочих других идиотских ограничений. Именно эти моменты побудили острое желание поднять собственный сервис без посредников.
\nMaddy<\/b> оказался неплохим докером, умеющим работать с сертификатом сервера, перераспределять поступающие письма, выдавать DKIM, блочить спамеров и не пускать посторонних. Он не так крут, как родное приложение от производителя NAS, но лучше из представленных выше для такой маломощной системы с 1 гигом памяти. Другие докеры, перечисленные выше (mox и mailserver) очень похожи по функционалу, и я бы остановился на каком-нибудь из них, если бы они не сваливались в глушняк с остановом и полной очисткой.
\nЕсли бы мне потребовалось заходить на веб-морду сервера и проверять письма там, то для этого есть решение, тоже докер: Snappy<\/b>. Ставил, удобно, можно визуал сильно менять, но ресурсы будут уходить.<\/p>\n

\n\"\"\n<\/div>\n", "date_published": "2026-10-06T12:13:59+03:00", "date_modified": "2026-10-06T13:52:41+03:00", "tags": [ "безопасность", "домен", "почта", "сайт", "техника" ], "image": "https:\/\/www.sumpira.space\/blogek\/pictures\/37885127.png", "_date_published_rfc2822": "Tue, 06 Oct 2026 12:13:59 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "40", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.sumpira.space\/blogek\/pictures\/37885127.png" ] } }, { "id": "38", "url": "https:\/\/www.sumpira.space\/blogek\/?go=all\/bezopasnik-chto-za-zver\/", "title": "Безопасник — что за зверь?", "content_html": "

Сторож или вахтер не в тему, смотрим IT сферу — благо или вред для организации такой человек в штате?<\/p>\n

Говорил ранее с коллегой из другого города, он похвастался новой системой безопасности «Соболь»<\/i> в одном из компьютеров учреждения, при этом сразу пожаловался: «Система так шифрует данные, что в случае поломки или какой ошибки оборудования, извлечь данные смогут только спецы, которые её установили. То есть, компьютер придется везти к ним». Я сразу осудил такую систему, потому что сам сисадмин должен уметь извлекать данные, либо эти самые спецы должны в течении двух часов примчаться и всё починить (ссылаясь на регламенты одного известного мне учреждения). Либо сисадмин должен суметь сам взломать эту систему. И тут я получил волну негодования и непонимания, ведь это плохо — нельзя ломать такие системы.<\/p>\n

А я считаю, что надо. Надо знать как устроена система, данная под твоё управление как сисадмину. Сисадмин также является ответственным за безопасность в своей сфере. И если системой руководит кто-то извне, и не дает тебе инструменты для оперативного устранения проблем, то это сильно снижает саму же безопасность.<\/p>\n

Сам термин «безопасность» у многих читающих и тех, кто насаждает её «сверху», ассоциируется со злыми хакерами и мошенниками, желающими завладеть вашими данными, да выведать секреты, и прикарманить ценности. Но в IT сфере это лишь немногие аспекты безопасности, поскольку тут самая важная безопасность — это сохранение данных, бесперебойного доступа к ним и устойчивая работа оборудования и систем.<\/p>\n

А зачем эта самая «безопасность» в виде неприступной крепости с самонаводящимися пулеметами, реагирующими на полёт мухи, но способная пропустить бревно в свои ворота? Перефразируя другими словами: у вас суперзащищенный комп с последней системой защиты, всякими физическими ключами доступа и цифровыми токенами, который потеряет всё что на нём есть в случае пропажи напряжения в сети. Людям нужно работать, а тут свет моргнул, ИБП не выдержал, и комп на процессе дешифрации потерял питание и не хочет включаться по ведомой только ему причине. Все кричат «караул, работать надо», а сисадмин разводит руками: «везти к „спецам“ надо, только у них нужные инструменты». По сути эти самые «спецы» нарушили безопасность работы учреждения, поскольку утратился бесперебойный доступ к данным.<\/p>\n

И если сисадмин сможет обойти защиту такой системы самостоятельно, без обращения к спецам, по сути взламывая её для благих целей (экономия времени и быстрое восстановление работы учреждения), то он лучший безопасник. Он знает, как эту систему можно взломать и всякие хитрости, как её обойти. Если знает он, то это могут знать и другие пользователи, а также злоумышленники. Значит он может контролировать этот процесс, наблюдая, не прознали ли пользователи об этой возможности. Настоящий сисадмин знает, что самый страшный вирус-троян на машине — это сам пользователь. Никто, кроме самого пользователя не запустит вредоносную утилиту, перейдя по ссылочке, или открывая картинку с котиками, к примеру. Поэтому работая с пользователями, он сам ставит им рамки, чтобы пользователи не запускали ненужных сюрпризов и не переводили данные куда не надо. А планку ему задаёт сам руководитель организации. То есть, если фирма ничем на занимается особым, не имеет никакой тайны, то сисадмину достаточно следить за бесперебойностью работы всех систем и отсекать вредоносный код снаружи. Если фирма имеет тайну или директору хочется более жестких условий для сотрудников (никаких соцсетей и фоточек на машинах, только работа), то сисадмин делает соответствующую среду для пользователей.<\/p>\n

И всё вышеописанное сводится к ещё одному моменту, почему сисадмин в этом плане «безопасник»<\/i>. Он имеет доступ ко всем системам организации. Именно он понимает, к чему имеет доступ и что он «охраняет». Все системы, на которых работают люди, имеют, скажем так, «ворота», через которые они выходят в сеть, а сама машина коммуницирует с другими устройствами, иногда таких ворот несколько. Ключи от всех ворот есть у сисадмина, и они нужны ему для работы, чтобы пользователи делали своё дело. И когда пользователи используют рабочую машину для личных целей — сисадмин это тоже видит. Порядочный страж сети и машин ничего не скажет по поводу личных фото и видео на рабочих машинах, но будет возмущаться, когда ему придется восстанавливать машину с переносом драгоценных для пользователя данных (тут процесс копирования может затянуться на часы). Что будет делать сисадмин, видя личные данные пользователя? Если руководитель не давал запретительных распоряжений, то — ничего. Ведь он дорожит своей репутацией и копаться в чужих вещах точно не будет — ему это незачем (про злые умыслы и прочие вещи говорить не будем, это исключения из правил, которые по сути являются уголовным преступлением — от неприкосновенности личной жизни до шантажа). А если руководитель задавал планку «ничего личного», то сисадмин предупредит пользователя, а в случае отсутствия реакции от него, доложит наверх — таковы правила.<\/p>\n

А чем безопасник-сисадмин (если он один в штате и не выведен в штатную единицу, занимающуюся только IT-безопасностью, что бывает редкостью) отличается от сторожа и безопасника (охранника, а не того, кто отвечает за безопасность труда) организации? Много чем, и прежде всего подходом. Ведь у сисадмина чаще всего инженерное мышление, это уже предопределяет подход к работе. Охранник или сторож на входе смотрит, чтобы с организации ничего не вынесли, а снаружи не зашли нехорошие личности, иногда ему даётся и другая работа. И плох тот сторож, который не знает все входы-выходы, не контролирует свою территорию. Ведь он должен понимать, как сотрудники могут вынести что-то за пределы, где есть слабые места. У сисадмина схожесть в работе только в этом: чтобы не ушли данные организации куда не надо, чтобы снаружи был не получен доступ к внутренней сети. На этом сходства заканчиваются, и начинаются инженерные тонкости в работе, поскольку он большей частью смотрит за работой устройств, а не людей.<\/p>\n

В конце я делаю личный вывод из всего вышеописанного, что многие видят безопасность только в каких-то ограниченных спектрах. Это какие-то меры против воров, злоумышленников, бандитов и прочих личностей, которые хотят навредить или украсть. Но если взять автомобиль, то там безопасность учитывается в виде выживаемости после ДТП, за что отвечают подушки и каркас безопасности, различные системы в виде АБС и контроля слепых зон. Есть антиугонная и антикражная безопасность в виде сигнализации и иммобилайзера. И нормальные автопроизводители не экономят на этих параметрах — это всё входит в базовую комплектацию. В бытовых приборах есть система защиты от удара током — тоже безопасность. Так почему же в IT сфере насаждается безопасность только от несанкционированного доступа? Где же средства на саму безопасность (неудаление) данных и бесперебойного доступа к ним в виде надежных хранителей информации, устройств бесперебойного питания, высокоскоростных надежных роутеров? Почему только защитные девайсы, да антивирусы с файрволами? И если смотреть дальше, то зачем включают пресловутые «белые списки» и не отключают сразу, а то и вовсе замедляют все остальные ресурсы? Последнее точно не про безопасность, точнее про ментальную безопасность отдельных лиц.<\/p>\n

«Всем известно, что самый безопасный компьютер отключен от сети, не имеет проводов, хранится в сейфе в решетке Фарадея на дне Марианской впадины. И у меня все равно есть сомнения, что безопасность будет полной. Пользователей, кстати, у такого компьютера тоже нет».<\/i><\/p>\n

Будем жить. Всем мира, любви и пусть никто не уйдет обиженным!<\/p>\n", "date_published": "2026-08-10T11:27:32+03:00", "date_modified": "2026-08-10T11:27:21+03:00", "tags": [ "безопасность", "сисадминство", "техника" ], "_date_published_rfc2822": "Mon, 10 Aug 2026 11:27:32 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "38", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "37", "url": "https:\/\/www.sumpira.space\/blogek\/?go=all\/saytostroenie\/", "title": "Сайтостроение", "content_html": "

Из-за незаконных требований рэкаэн назрел перенос сайта на другой домен.<\/p>\n

Как бы не печально было принимать решение по поводу ухода с домена «.su»<\/b>, но вопрос назрел до такой степени, что решение нужно было принимать срочно. Первый звоночек появился, когда в сети появились новости о скором прекращении поддержки целого домена «SU»<\/b>, поскольку нет такой страны (SU — Soviet Union, то бишь СССР, который канул в лету)<\/i>, то нет смысла и домен содержать, и всё равно, что на нём крутятся сайты. Прекращение поддержки должно было произойти к 2030 году, и времени ещё оставалось много (может и проект закрылся бы раньше)<\/i>. Но тут от хостинга прилетает письмецо, с требованием верифицировать свои данные через госуслуги, дабы продолжать пользоваться сайтом на этом доменном имени.<\/p>\n

Вопрос даже не в том, что в проекте могло быть что-то запрещенное (там нет ничего кроме страницы-заглушки со ссылками и данный блог, но что сегодня разрешено, а завтра запрещено, и что сочтет запрещенным «тащ майор», увидевший игру «Симс 3»?)<\/i>, сколько важен сам момент: а зачем это нужно? Чтобы потом подпадать под действие других законов (вроде закона о СМИ)<\/i>? Чтобы накладывались ограничения на работу? Чтобы кто-то потом захотел поиметь ещё больше денег за какие-нибудь регистрационные действия в каком-нибудь новом проекте по отбору денег у населения? Пусть купят себе чупа-чупс и идут в баню<\/i>. Поэтому решено уходить с любых доменов, связанных с этой страной.<\/p>\n

Поиск нового домена труден, и не с позиции цены, сколько с позиции названия. хотелось бы «SUM»<\/b>, но такого нет и регистрировать такое тоже нельзя. И тогда я подумал, а что есть «Sumpira»<\/b>? На той же странице-заглушке написано, что это название космического корабля из неизданной книги. Значит, надо поместить его в космос! То есть, в «SPACE»<\/b>, как космос по-английски, и что ещё будет означать моё пространство<\/i>! Узнав, что такой домен существует, сразу решил переносить туда. Регистрация была пройдена успешно, но остался вопрос с хостингом. Я не планировал большой проект, но хотелось, чтобы то, что я творю, было со мной, и никто не говорил мне, что это можно хранить, это нельзя, а это должно быть такого размера, а всего должно быть столько штук, а теперь мы недоступны — сорри чувак. Поэтому выбор пал на собственный сервер — тут я сам себе хозяин.<\/p>\n

Я не буду упоминать сложности и тонкости работы домашнего сервера, поскольку это «почти»<\/i> доступно каждому. Его можно сделать хоть на собственном роутере для интернета, было бы желание.<\/p>\n

И когда решились вопросы с доменом и хостингом, я решил обновить уже сам проект, поскольку он уже выглядел тяжелым, медленным и устаревшим (bootstrap — красиво, но мы за простоту)<\/i>. Я ещё в процессе переделки сайта, его механики, и внутренних взаимосвязей. И, думаю, этот момент только больше вдохновил меня на работу в этом направлении, желании узнать больше нового. «Не было бы счастья, да несчастье помогло»<\/i> — цитата в тему.<\/p>\n

Поэтому на этом всё, счастья всем, и пусть никто не уйдет обиженным. И вставлю для красоты флаг, нарисованный мной на заре дизайнерских проб в «Photoshop».<\/p>\n

\n\"\"\n<\/div>\n", "date_published": "2026-07-31T10:27:57+03:00", "date_modified": "2026-07-31T10:27:22+03:00", "tags": [ "домен", "космос", "сайт", "техника" ], "image": "https:\/\/www.sumpira.space\/blogek\/pictures\/1-1.jpg", "_date_published_rfc2822": "Fri, 31 Jul 2026 10:27:57 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "37", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.sumpira.space\/blogek\/pictures\/1-1.jpg" ] } }, { "id": "36", "url": "https:\/\/www.sumpira.space\/blogek\/?go=all\/chernobyl-sobytiya-chaes-40-let-spustya\/", "title": "Чернобыль. События ЧАЭС 40 лет спустя...", "content_html": "

Станция на месте, саркофаг не разобран, НБК вроде функционирует, но не так как должен.<\/p>\n

Многих Участников тех событий уже нет в живых, поэтому есть видео интервью с теми немногими, кто имел отношение к станции, правда уже после тех событий:<\/p>\n

\n