Насколько вреден Wi-Fi
Недавно снова был задан подобный вопрос, и он не является праздным, особенно если вы используете оборудование Mikrotik или альтернативные прошивки, скажем, OpenWRT, позволяющие поднять мощность передатчика выше разрешенного предела.
Напомним, что законодательно установленное ограничения для Wi-Fi передатчиков это 100 мВт для диапазона 2,4 ГГц и 200 мВт для 5 ГГц.
Данные ограничения накладываются на эквивалентную изотропно-излучаемую мощность (ЭИИМ), которая рассчитывается с учетом коэффициента усиления антенны.
Следует понимать, что сама антенна является пассивным устройством и не может увеличивать мощность сигнала, но она перераспределяет излучение в пространстве таким образом, что уровень излучения в определенной точке пространства становится аналогичным излучению передатчика более высокой мощности.
Если у нас есть передатчик с мощностью 20 дБм (100 мВт) и антенна с усилением 3 дБи, то ЭИИМ такой системы будет 200 мВт (23 дБм), для передатчика с мощностью 1 Вт ЭИИМ с такой антенной составит 2 Вт.
Таким образом для оборудования имеющего мощность передатчика 1 Вт и антенну с усилением 3-4 дБи мы можем смело получить ЭИИМ 2 - 2,5 Вт. И такое оборудование есть, например, некоторые модели Mikrotik (подчеркнем – именно некоторые, не все).
Закономерный вопрос- насколько это вредно. Мы нашли исследование Роспотребнадзора для домашних роутеров диапазона 2,4 ГГц, которое показало, что излучаемая ими мощность не превышает допустимой на любых расстояниях.
Для оценки воздействия излучения на организм человека используется показатель плотности потока энергии (ППЭ), который измеряется в мкВт/см2, предельно допустимым уровнем (ПДУ) для граждан является 10 мкВт/см2, для работников сферы связи – 18 мкВт/см2.
Максимальное значение ППЭ при котором допускается находиться без средств индивидуальной защиты – 1000 мкВт/см2.
Для расчета времени пребывания в местах с превышением ПДУ ППЭ существует еще один показатель - энергетическая экспозиция потока плотности энергии, предельное значение которой 200 мкВт/см2 в час.
❗️ Т.е. при значении ППЭ в 1000 мкВт/см2 там можно находиться не более 12 минут.
Все это хорошо, но как связать эти значения с мощностью роутера? Мы выполнили упрощенный расчет ППЭ, который показал цифры близкие к значениям полученным Роспотребнадзором и которые, на наш взгляд можно использовать для примерной оценки.
На расстоянии 50 см и ближе ПДУ ППЭ превышают передатчики с мощностью от 300 мВт выше, но если отойти уже на метр, то превышение нормы будет только у передатчика в 2 Вт.
👉 Общее правило просто – ППЭ падает пропорционально квадрату расстояния от антенны передатчика и если не сидеть с ним в обнимку, то даже серьезно превышающие законодательные нормы передатчики не окажут на организм заметного вреда.
При этом наша формула не учитывала наличия препятствий на пути сигнала, многолучевого распространения и отражений. На практике это может как снизить, так и увеличить ППЭ в конкретной точке пространства, но, в общем и целом, вычисления остаются справедливы.
Недавно снова был задан подобный вопрос, и он не является праздным, особенно если вы используете оборудование Mikrotik или альтернативные прошивки, скажем, OpenWRT, позволяющие поднять мощность передатчика выше разрешенного предела.
Напомним, что законодательно установленное ограничения для Wi-Fi передатчиков это 100 мВт для диапазона 2,4 ГГц и 200 мВт для 5 ГГц.
Данные ограничения накладываются на эквивалентную изотропно-излучаемую мощность (ЭИИМ), которая рассчитывается с учетом коэффициента усиления антенны.
Следует понимать, что сама антенна является пассивным устройством и не может увеличивать мощность сигнала, но она перераспределяет излучение в пространстве таким образом, что уровень излучения в определенной точке пространства становится аналогичным излучению передатчика более высокой мощности.
Если у нас есть передатчик с мощностью 20 дБм (100 мВт) и антенна с усилением 3 дБи, то ЭИИМ такой системы будет 200 мВт (23 дБм), для передатчика с мощностью 1 Вт ЭИИМ с такой антенной составит 2 Вт.
Таким образом для оборудования имеющего мощность передатчика 1 Вт и антенну с усилением 3-4 дБи мы можем смело получить ЭИИМ 2 - 2,5 Вт. И такое оборудование есть, например, некоторые модели Mikrotik (подчеркнем – именно некоторые, не все).
Закономерный вопрос- насколько это вредно. Мы нашли исследование Роспотребнадзора для домашних роутеров диапазона 2,4 ГГц, которое показало, что излучаемая ими мощность не превышает допустимой на любых расстояниях.
Для оценки воздействия излучения на организм человека используется показатель плотности потока энергии (ППЭ), который измеряется в мкВт/см2, предельно допустимым уровнем (ПДУ) для граждан является 10 мкВт/см2, для работников сферы связи – 18 мкВт/см2.
Максимальное значение ППЭ при котором допускается находиться без средств индивидуальной защиты – 1000 мкВт/см2.
Для расчета времени пребывания в местах с превышением ПДУ ППЭ существует еще один показатель - энергетическая экспозиция потока плотности энергии, предельное значение которой 200 мкВт/см2 в час.
❗️ Т.е. при значении ППЭ в 1000 мкВт/см2 там можно находиться не более 12 минут.
Все это хорошо, но как связать эти значения с мощностью роутера? Мы выполнили упрощенный расчет ППЭ, который показал цифры близкие к значениям полученным Роспотребнадзором и которые, на наш взгляд можно использовать для примерной оценки.
На расстоянии 50 см и ближе ПДУ ППЭ превышают передатчики с мощностью от 300 мВт выше, но если отойти уже на метр, то превышение нормы будет только у передатчика в 2 Вт.
👉 Общее правило просто – ППЭ падает пропорционально квадрату расстояния от антенны передатчика и если не сидеть с ним в обнимку, то даже серьезно превышающие законодательные нормы передатчики не окажут на организм заметного вреда.
При этом наша формула не учитывала наличия препятствий на пути сигнала, многолучевого распространения и отражений. На практике это может как снизить, так и увеличить ППЭ в конкретной точке пространства, но, в общем и целом, вычисления остаются справедливы.
👍21👌5❤4🤡2
И снова почему не надо работать на выходные и праздники
Про то, что выходные, а тем более праздничные дни – не время для работы, мы говорим давно. Причины здесь просты – в случае любой нештатной ситуации вы останетесь с проблемой один на один.
Сегодня произошел еще один подобный случай, в котором наш коллега получил себе целый набор проблем на ровном месте.
Торговая сеть среднего размера, офис находится в бывшей промзоне на закрытой территории и охраняется отдельным ЧОП, пропускной режим достаточно строгий.
Чтобы прийти пораньше и или задержаться – нужно писать и заверять у руководителя заявление. Чтобы пройти в выходные и праздничные дни нужна или предварительная заявка, или запрос непосредственно от руководителя.
Четверг, 30 апреля, вечер. Офис ушел домой на все праздники, магазины закрылись. Местный админ, назовем его Вася, решил массово обновить гипервизоры Proxmox, которых там целых три штуки.
Два обновились нормально, а на третьем у Васи дрогнула рука и вместо Reboot он нажал Shutdown. Бывает…
В этот момент все еще можно было исправить, время было еще не слишком позднее, примерно 22:30, свяжись с руководителем, объясни ситуацию, попроси пропуск, там делов то на минуту.
Не можешь связаться – напиши в мессенджере, чтобы шеф прочитал, когда проснется и принял меры. Ну и сам будь готов сорваться с раннего старта утром пораньше.
Но Вася решает пойти иным путем, мол он тут не причем и вообще, так ситуация сложилась, а он, наоборот, бросил все в выходные и помчался устранять внезапный сбой.
В целом тот сервер сильно никому не нужен, магазины могут торговать и без него, но там синхронизация, заявки поставщикам и все такое прочее.
Первый звоночек прозвучал часа в три дня, когда одна из точек, оценив торговлю решила оперативно дозаказать товар и не смогла. В рабочем чате тут же пошла волна – центральная база не работает.
Тогда уже к проблеме и подключился Вася, который выждал какое-то время на диагностику и уже около 16 часов порадовал шефа, мол так и так, надо ехать в офис.
Надо ли говорить, как эта новость обрадовала шефа? Который уже успел выпить коньячка и пожевать шашлычка за городом?
А так как просто звонком эта задача не решалась, ему пришлось вызванивать арендодателя, который тоже уже вкусил прелестей отдыха, а потом вместе искать руководителя ЧОП.
В общем Васю таки на территорию пустили и сервер он включил. Но шеф, которого вырвали из отдыха и нирваны праздничного дня жаждал найти крайнего. И Вася тупо перевел стрелки на подрядчиков, т.е. нас, мол это 1С, это не ко мне вопросы.
Шеф решил, что если суетиться – так по полной и набрал нас с претензией и требованием предоставить отчет об инциденте сразу после праздников.
Нам тоже такая предъява на ровном месте не понравилась, поэтому мы подключились к инфраструктуре и первым делом посмотрели Zabbix, который четко сказал, что поменялась версия ядра, причем сразу не всех серверах.
Ага, обновление. Далее смотрим, когда пропал с радаров искомый гипервизор, находим по времени нужный кусок лога и отдаем его ИИ, чтобы тот поискал какие-либо аномалии.
ИИ бодро рапортует, что у тебя все в порядке, кто-то штатно выключил узел и тот без ошибок отработал выключение. А днем штатно включил.
Вообще, мы как бы не любители подковерных игр и переводов стрелок, но раз пошла такая пьянка. Сохраняем логи и звоним шефу, суетиться – так по полной, и приводим наш анализ ситуации. И говорим, что готовы подтвердить все документально.
Проходит еще час и вечер праздничного дня окончательно перестает быть томным, звонит Вася, бьется в истерике и вопрошает – а зачем мы его так подставили?
Но история на этом не закончена и после праздников будет подробный разбор полетов и оргвыводы, которые Васе, скорее всего не понравятся.
Про то, что выходные, а тем более праздничные дни – не время для работы, мы говорим давно. Причины здесь просты – в случае любой нештатной ситуации вы останетесь с проблемой один на один.
Сегодня произошел еще один подобный случай, в котором наш коллега получил себе целый набор проблем на ровном месте.
Торговая сеть среднего размера, офис находится в бывшей промзоне на закрытой территории и охраняется отдельным ЧОП, пропускной режим достаточно строгий.
Чтобы прийти пораньше и или задержаться – нужно писать и заверять у руководителя заявление. Чтобы пройти в выходные и праздничные дни нужна или предварительная заявка, или запрос непосредственно от руководителя.
Четверг, 30 апреля, вечер. Офис ушел домой на все праздники, магазины закрылись. Местный админ, назовем его Вася, решил массово обновить гипервизоры Proxmox, которых там целых три штуки.
Два обновились нормально, а на третьем у Васи дрогнула рука и вместо Reboot он нажал Shutdown. Бывает…
В этот момент все еще можно было исправить, время было еще не слишком позднее, примерно 22:30, свяжись с руководителем, объясни ситуацию, попроси пропуск, там делов то на минуту.
Не можешь связаться – напиши в мессенджере, чтобы шеф прочитал, когда проснется и принял меры. Ну и сам будь готов сорваться с раннего старта утром пораньше.
Но Вася решает пойти иным путем, мол он тут не причем и вообще, так ситуация сложилась, а он, наоборот, бросил все в выходные и помчался устранять внезапный сбой.
В целом тот сервер сильно никому не нужен, магазины могут торговать и без него, но там синхронизация, заявки поставщикам и все такое прочее.
Первый звоночек прозвучал часа в три дня, когда одна из точек, оценив торговлю решила оперативно дозаказать товар и не смогла. В рабочем чате тут же пошла волна – центральная база не работает.
Тогда уже к проблеме и подключился Вася, который выждал какое-то время на диагностику и уже около 16 часов порадовал шефа, мол так и так, надо ехать в офис.
Надо ли говорить, как эта новость обрадовала шефа? Который уже успел выпить коньячка и пожевать шашлычка за городом?
А так как просто звонком эта задача не решалась, ему пришлось вызванивать арендодателя, который тоже уже вкусил прелестей отдыха, а потом вместе искать руководителя ЧОП.
В общем Васю таки на территорию пустили и сервер он включил. Но шеф, которого вырвали из отдыха и нирваны праздничного дня жаждал найти крайнего. И Вася тупо перевел стрелки на подрядчиков, т.е. нас, мол это 1С, это не ко мне вопросы.
Шеф решил, что если суетиться – так по полной и набрал нас с претензией и требованием предоставить отчет об инциденте сразу после праздников.
Нам тоже такая предъява на ровном месте не понравилась, поэтому мы подключились к инфраструктуре и первым делом посмотрели Zabbix, который четко сказал, что поменялась версия ядра, причем сразу не всех серверах.
Ага, обновление. Далее смотрим, когда пропал с радаров искомый гипервизор, находим по времени нужный кусок лога и отдаем его ИИ, чтобы тот поискал какие-либо аномалии.
ИИ бодро рапортует, что у тебя все в порядке, кто-то штатно выключил узел и тот без ошибок отработал выключение. А днем штатно включил.
Вообще, мы как бы не любители подковерных игр и переводов стрелок, но раз пошла такая пьянка. Сохраняем логи и звоним шефу, суетиться – так по полной, и приводим наш анализ ситуации. И говорим, что готовы подтвердить все документально.
Проходит еще час и вечер праздничного дня окончательно перестает быть томным, звонит Вася, бьется в истерике и вопрошает – а зачем мы его так подставили?
Но история на этом не закончена и после праздников будет подробный разбор полетов и оргвыводы, которые Васе, скорее всего не понравятся.
💯40👀10🔥7🤮5❤4
Стоит ли бравировать собственным невежеством?
Конечно же нет, скажет любой взрослый здравомыслящий человек. Но стоит только завести разговор в админской среде об 1С:Предприятие и коллег как будто подменяют.
Взрослые серьезные (вроде-бы) люди начинают наперебой рассказывать про то, какой это хлам, что это совсем не IT и как они максимально дистанцированы от этого, пусть сами 1С-ники в ней и ковыряются, заодно отказывая специалистам по 1С в звании настоящих айтишников.
Мол ваша 1С – недоделанная, и сами вы недоделанные, не специалисты, не программисты и вообще сидите с краю, когда серьезные люди о серьезных вещах разговаривают.
Но стоит копнуть чуть глубже и понимаешь, что никаких современных знаний о платформе у ее хейтеров нет, а оперируют они мифами и страшилками времен первых выпусков «восьмерки», когда действительно не было нормального сервера и платформа страдала кучей детских болезней.
И очень часто у таких товарищей видишь монолит в виде терминального сервера, на котором сразу и пользователи, и сервер 1С, и SQL-сервер в одной куче. А на вопрос «зачем?» - просто разводят руками: «Ну это же 1С…»
А дальше начинаются сплошные открытия, о том, что давно есть тонкий клиент, веб-публикация, что 1С отлично работает на Linux и т.д. и т.п.
И хорошо если это произойдет до того, как этот терминальный сервер взломают и зашифруют.
А кто будет в этом виноват? Недоспециалист 1С-ник или ТруЪ-админ? На самом деле виновата будет «кривая 1С, которая нормально не умеет в сервер и ее только вот так, через костыли», ну и «тупые пользователи, которые запускают все что попало».
Но руководству не интересно все это словоблудие, у него авария, причем глобального масштаба. Которую надо сначала ликвидировать, а потом найти крайнего, кто все это безобразие допустил.
И жесткость оргвыводов зависит уже от того, как далеко лежали бекапы и насколько они были актуальны, ну и как быстро их сумеют развернуть.
Если же копнуть глубже, то все это безобразие стало возможным исключительно благодаря невежеству, когда вместо того, чтобы изучить все возможности платформы для нее сделали костыль, утративший актуальность лет пятнадцать назад, и сказали, мол и так пойдет, по-другому не получится.
Но если мыслить рационально, то такое поведение только удивляет. На постсоветском пространстве 1С:Предприятие – стандарт учетной системы де-факто. А бухгалтерия и 1С – практически слова синонимы. 1С в том или ином виде вы встретите везде, от небольшой фирмы до крупного предприятия.
И нежелание изучать работу с платформой на уровне ее администрирования вызывает только недоумение, граничащее с абсурдом. Особенно когда это выливается в постоянные конфликты с бухгалтерией и 1С-никами по поводу неудовлетворительной работы программы.
А можно и с размаха лаптями в жир влететь, опять-таки сугубо по незнанию и нежеланию советоваться с профильными специалистами.
В прошлом году нас пригласили в качестве внешних экспертов на проект по внедрению нового сервера 1С, который никак не хотел работать как надо. Но, к сожалению, пригласили уже поздно после того, как уже ничего не помогало.
Нам достаточно было просто глянуть на характеристики процессора, чтобы выдать вердикт – выкрасить и выбросить. Потому что в мире 1С любой знает – для сервера 1С нужны процессоры с максимальной частотой, не ниже 3 ГГц, а лучше всего 4 ГГц и выше.
В том же проекте админ, причем опытный и достаточно грамотный дядечка лет под 50, отлично знающий Linux купил для сервера 1С Intel Xeon Silver 2,1ГГц, зато серверный, зато Xeon, все по-взрослому.
Куплено это было взамен старенького Core i5 с максимальной частотой на обычной настольной платформе, и основная проблема была в том, что уперлись в лимит 64 ГБ оперативной памяти на материнке.
Вопрос, а почему не купили Ryzen R9 был сразу отвергнут, мол он не труЪ и не серверный. А на новом сервере ко всему прочему стояла «старая добрая терминалка». Занавес!
Конечно же нет, скажет любой взрослый здравомыслящий человек. Но стоит только завести разговор в админской среде об 1С:Предприятие и коллег как будто подменяют.
Взрослые серьезные (вроде-бы) люди начинают наперебой рассказывать про то, какой это хлам, что это совсем не IT и как они максимально дистанцированы от этого, пусть сами 1С-ники в ней и ковыряются, заодно отказывая специалистам по 1С в звании настоящих айтишников.
Мол ваша 1С – недоделанная, и сами вы недоделанные, не специалисты, не программисты и вообще сидите с краю, когда серьезные люди о серьезных вещах разговаривают.
Но стоит копнуть чуть глубже и понимаешь, что никаких современных знаний о платформе у ее хейтеров нет, а оперируют они мифами и страшилками времен первых выпусков «восьмерки», когда действительно не было нормального сервера и платформа страдала кучей детских болезней.
И очень часто у таких товарищей видишь монолит в виде терминального сервера, на котором сразу и пользователи, и сервер 1С, и SQL-сервер в одной куче. А на вопрос «зачем?» - просто разводят руками: «Ну это же 1С…»
А дальше начинаются сплошные открытия, о том, что давно есть тонкий клиент, веб-публикация, что 1С отлично работает на Linux и т.д. и т.п.
И хорошо если это произойдет до того, как этот терминальный сервер взломают и зашифруют.
А кто будет в этом виноват? Недоспециалист 1С-ник или ТруЪ-админ? На самом деле виновата будет «кривая 1С, которая нормально не умеет в сервер и ее только вот так, через костыли», ну и «тупые пользователи, которые запускают все что попало».
Но руководству не интересно все это словоблудие, у него авария, причем глобального масштаба. Которую надо сначала ликвидировать, а потом найти крайнего, кто все это безобразие допустил.
И жесткость оргвыводов зависит уже от того, как далеко лежали бекапы и насколько они были актуальны, ну и как быстро их сумеют развернуть.
Если же копнуть глубже, то все это безобразие стало возможным исключительно благодаря невежеству, когда вместо того, чтобы изучить все возможности платформы для нее сделали костыль, утративший актуальность лет пятнадцать назад, и сказали, мол и так пойдет, по-другому не получится.
Но если мыслить рационально, то такое поведение только удивляет. На постсоветском пространстве 1С:Предприятие – стандарт учетной системы де-факто. А бухгалтерия и 1С – практически слова синонимы. 1С в том или ином виде вы встретите везде, от небольшой фирмы до крупного предприятия.
И нежелание изучать работу с платформой на уровне ее администрирования вызывает только недоумение, граничащее с абсурдом. Особенно когда это выливается в постоянные конфликты с бухгалтерией и 1С-никами по поводу неудовлетворительной работы программы.
А можно и с размаха лаптями в жир влететь, опять-таки сугубо по незнанию и нежеланию советоваться с профильными специалистами.
В прошлом году нас пригласили в качестве внешних экспертов на проект по внедрению нового сервера 1С, который никак не хотел работать как надо. Но, к сожалению, пригласили уже поздно после того, как уже ничего не помогало.
Нам достаточно было просто глянуть на характеристики процессора, чтобы выдать вердикт – выкрасить и выбросить. Потому что в мире 1С любой знает – для сервера 1С нужны процессоры с максимальной частотой, не ниже 3 ГГц, а лучше всего 4 ГГц и выше.
В том же проекте админ, причем опытный и достаточно грамотный дядечка лет под 50, отлично знающий Linux купил для сервера 1С Intel Xeon Silver 2,1ГГц, зато серверный, зато Xeon, все по-взрослому.
Куплено это было взамен старенького Core i5 с максимальной частотой на обычной настольной платформе, и основная проблема была в том, что уперлись в лимит 64 ГБ оперативной памяти на материнке.
Вопрос, а почему не купили Ryzen R9 был сразу отвергнут, мол он не труЪ и не серверный. А на новом сервере ко всему прочему стояла «старая добрая терминалка». Занавес!
1👍16😁11🤮5🔥2🍌1
Админы сдают позиции
Классический образ ТруЪ админа рисует утро с чашки кофе и чтения логов. Где опытный специалист цепким взглядом быстро выявляет все аномалии и принимает необходимые меры.
На самом деле логи редко кто читает, потому как занятие это в крайней степени монотонное и муторное, особенно если четко не знаешь, что именно тебе в них надо. Какие там аномалии…
Обычно к логам обращаются в момент возникновения каких-либо проблем или уже сильно потом, чтобы разобраться и понять, а что вообще это было.
И любой, кто занимался гаданием по логам знает, насколько это занятие малоэффективно, можно часами листать лог, пока глаз зацепится за нужную запись. Если зацепится.
И это дальше уже можно парсить, ухватившись за ниточку, но ведь ее еще нужно найти…
В последнее время правила игры существенно поменялись, появился ИИ, который даже сейчас, даже на бесплатном тарифе способен проглотить за раз достаточно большой кусок лога и сказать все ли там в порядке.
А если не все и не совсем, то он же скажет вам, какой кусок лога ему нужен и сам подскажет вам нужные фильтры, чтобы сделать выжимку только нужного.
ИИ, в отличие от человека, рассеянностью не страдает и способен вдумчиво проанализировать каждую строку, сколько бы их не было. Его глаз не притупляется, он не устает.
И если не считать различных «староверов», которые априори отрицают ИИ, то я практически не знаю коллег, которые бы парсили логи руками и читали глазами. Зачем, если есть отличный искусственный помощник.
Данную позицию человек сдал ИИ без боя, да и зачем, если ИИ тут гораздо быстрее и эффективнее человека. А человек всегда был склонен к разумной лени, зачем напрягаться самому, когда можно напрячь кого-либо другого?
С этим можно соглашаться, можно не соглашаться, но факт остается фактом – ИИ разбирает логи значительно быстрее и эффективнее человека.
Но это не все, что ИИ делает быстрее и лучше, хотя на других направлениях со стороны людей имеется нешуточное сопротивление. Например, написании кода.
Программный код ИИ тоже пишет лучше человека, особенно если есть подробное техническое задание. Только в отличие от чтения логов здесь задевается достаточно обширная и чувствительная прослойка человеков, которые зарабатывают на жизнь написанием кода буквами по готовому техническому заданию.
Сами себя они гордо величают программистами, но на самом деле их ценность примерно на уровне разнорабочих на стройке. Как и прочего младшего околоайти персонала.
Для них настали плохие времена: ИИ быстрее, эффективнее и дешевле. Хотите выжить и остаться в индустрии – развивайтесь, иначе вас скоро заменит искусственный болванчик, который может даже и тупее вас, но работает 24/7 и не требует социалки и повышения заработной платы.
Бизнес – он про деньги, а не про все остальное. Если вы полезны бизнесу – бизнес готов вам платить, нет – ничего личного, до свидания.
А мораль сей басни проста: ИИ плотно вошел в нашу жизнь и тот, кто его изучит и будет применять получит фору перед теми, кто его отрицает и игнорирует.
Классический образ ТруЪ админа рисует утро с чашки кофе и чтения логов. Где опытный специалист цепким взглядом быстро выявляет все аномалии и принимает необходимые меры.
На самом деле логи редко кто читает, потому как занятие это в крайней степени монотонное и муторное, особенно если четко не знаешь, что именно тебе в них надо. Какие там аномалии…
Обычно к логам обращаются в момент возникновения каких-либо проблем или уже сильно потом, чтобы разобраться и понять, а что вообще это было.
И любой, кто занимался гаданием по логам знает, насколько это занятие малоэффективно, можно часами листать лог, пока глаз зацепится за нужную запись. Если зацепится.
И это дальше уже можно парсить, ухватившись за ниточку, но ведь ее еще нужно найти…
В последнее время правила игры существенно поменялись, появился ИИ, который даже сейчас, даже на бесплатном тарифе способен проглотить за раз достаточно большой кусок лога и сказать все ли там в порядке.
А если не все и не совсем, то он же скажет вам, какой кусок лога ему нужен и сам подскажет вам нужные фильтры, чтобы сделать выжимку только нужного.
ИИ, в отличие от человека, рассеянностью не страдает и способен вдумчиво проанализировать каждую строку, сколько бы их не было. Его глаз не притупляется, он не устает.
И если не считать различных «староверов», которые априори отрицают ИИ, то я практически не знаю коллег, которые бы парсили логи руками и читали глазами. Зачем, если есть отличный искусственный помощник.
Данную позицию человек сдал ИИ без боя, да и зачем, если ИИ тут гораздо быстрее и эффективнее человека. А человек всегда был склонен к разумной лени, зачем напрягаться самому, когда можно напрячь кого-либо другого?
С этим можно соглашаться, можно не соглашаться, но факт остается фактом – ИИ разбирает логи значительно быстрее и эффективнее человека.
Но это не все, что ИИ делает быстрее и лучше, хотя на других направлениях со стороны людей имеется нешуточное сопротивление. Например, написании кода.
Программный код ИИ тоже пишет лучше человека, особенно если есть подробное техническое задание. Только в отличие от чтения логов здесь задевается достаточно обширная и чувствительная прослойка человеков, которые зарабатывают на жизнь написанием кода буквами по готовому техническому заданию.
Сами себя они гордо величают программистами, но на самом деле их ценность примерно на уровне разнорабочих на стройке. Как и прочего младшего околоайти персонала.
Для них настали плохие времена: ИИ быстрее, эффективнее и дешевле. Хотите выжить и остаться в индустрии – развивайтесь, иначе вас скоро заменит искусственный болванчик, который может даже и тупее вас, но работает 24/7 и не требует социалки и повышения заработной платы.
Бизнес – он про деньги, а не про все остальное. Если вы полезны бизнесу – бизнес готов вам платить, нет – ничего личного, до свидания.
А мораль сей басни проста: ИИ плотно вошел в нашу жизнь и тот, кто его изучит и будет применять получит фору перед теми, кто его отрицает и игнорирует.
❤12⚡7🤮7💯6😢4
Здесь должна была быть непереводимая игра слов…
Минпромторг России исключил из перечня товаров для параллельного импорта компьютерную технику и запоминающие устройства от ведущих иностранных производителей. Изменения вступают в силу 27 мая 2026 года.
В приказе ведомства № 4769 от 26 сентября 2025 года под ограничение попадают компьютеры и запоминающие устройства таких брендов, как Acer, Adata, AIC, Apacer, Asus, Cisco, Fujitsu, Hewlett Packard (HP), Hitachi, HPE, Hynix, IBM, Inspur, Intel, Kingston, Samsung, Sandisk, Toshiba, Transcend, xFusion.
И это не про обход западных санкций, а про их поддержку, теперь уже с нашей стороны. Ведомство решило, что рынок достаточно насыщен отечественными продуктами и продуктами дружественных стран, поэтому самое время наказать супостата рублем.
А по факту если благодаря параллельному импорту мы еще могли купить что-то приличное, то теперь на прилавках останется только китайский товар далеко не первого эшелона, ну и «наш», который тот же китайский в большинстве своем.
В общем, время еще есть, кто хотел купить, но еще этого не сделал имеет шанс заскочить в последний вагон.
Минпромторг России исключил из перечня товаров для параллельного импорта компьютерную технику и запоминающие устройства от ведущих иностранных производителей. Изменения вступают в силу 27 мая 2026 года.
В приказе ведомства № 4769 от 26 сентября 2025 года под ограничение попадают компьютеры и запоминающие устройства таких брендов, как Acer, Adata, AIC, Apacer, Asus, Cisco, Fujitsu, Hewlett Packard (HP), Hitachi, HPE, Hynix, IBM, Inspur, Intel, Kingston, Samsung, Sandisk, Toshiba, Transcend, xFusion.
И это не про обход западных санкций, а про их поддержку, теперь уже с нашей стороны. Ведомство решило, что рынок достаточно насыщен отечественными продуктами и продуктами дружественных стран, поэтому самое время наказать супостата рублем.
А по факту если благодаря параллельному импорту мы еще могли купить что-то приличное, то теперь на прилавках останется только китайский товар далеко не первого эшелона, ну и «наш», который тот же китайский в большинстве своем.
В общем, время еще есть, кто хотел купить, но еще этого не сделал имеет шанс заскочить в последний вагон.
🤬56❤1😁1😱1👌1
C:\Deb - каждый сходит с ума по своему
Видели мы многое, видели мы всякое, но такое...
И ладно бы он воспроизводил лучшие практики мира Windows, но ReactOS крайне далека как от стабильности, так и от современных технологий и развивается более как исследовательский проект, так еще стилизация под Windows 9x.
И выпустили его не на первое апреля, чтобы было бы объяснимо и воспринято с пониманием, а первого мая, в день весны и труда.
Только вот подобный труд вызывает у нас недоумение. Пользы с него никакого (правда и вреда тоже), монетизировать его невозможно, к чему все это? Хобби? Возможно, хотя эту энергию да в продуктивное русло.
✅ Посмотреть своими глазами: https://github.com/cusdeb-com/os
Видели мы многое, видели мы всякое, но такое...
C:\Deb — это система Win32/Linux, созданная на базе Debian 13 и Wine, с заимствованным пользовательским пространством из ReactOS, ориентированная на беспроблемную поддержку Windows‑приложений без отказа от традиционного ПО для Linux.
И ладно бы он воспроизводил лучшие практики мира Windows, но ReactOS крайне далека как от стабильности, так и от современных технологий и развивается более как исследовательский проект, так еще стилизация под Windows 9x.
И выпустили его не на первое апреля, чтобы было бы объяснимо и воспринято с пониманием, а первого мая, в день весны и труда.
Только вот подобный труд вызывает у нас недоумение. Пользы с него никакого (правда и вреда тоже), монетизировать его невозможно, к чему все это? Хобби? Возможно, хотя эту энергию да в продуктивное русло.
✅ Посмотреть своими глазами: https://github.com/cusdeb-com/os
👍9❤2🤣2👀1
Перенос сертификатов и закрытых ключей CryptoPro хранящихся в реестре
КриптоПро один из наиболее широко используемых криптопровайдеров на территории Российской Федерации, он широко используется в системах электронного документооборота, сдачи отчетности и взаимодействия с государственными органами, поэтому встретить его можно практически в любой организации.
По этой причине у системных администраторов часто встает вопрос его переноса на другой ПК. А так как криптография является для многих сложной и непонятной областью, то эта простая задача может вызвать некоторые затруднения.
При переносе обычно возникает несколько проблем:
🔹 Узнать серийный номер установленного экземпляра КриптоПро
🔹 Перенести ключи расположенные в реестре
🔹 Перенести пользовательские сертификаты
Несмотря на то, что налоговая давно выпускает неэскортируемые сертификаты эта проблема давно и успешно решается, а хранение в реестре по-прежнему распространено.
✅ Как это сделать можно прочитать в нашей статье: https://interface31.ru/post/perenos-sertifikatov-i-zakrytyh-klyuchey-cryptopro-hranyashhihsya-v-reestre
Но чтобы ускорить данный процесс можно использовать специальный скрипт, который мы подготовили специально для этой задачи.
👉 Скрипт состоит из двух файлов: собственно PS-скрипта и BAT-вфайла для его запуска. Поместите их в одном расположении и запустите с правами Администратора.
В результате его работы вы получите:
🔹Текстовый файл с серийным номером Крипто-Про
🔹Файл реестра с закрытыми ключами
🔹Архив с сертификатами из хранилища пользователя
Чтобы не запутаться в имена файлов добавлены последние четыре цифры серийного номера.
👇👇👇 Файлы скрипта можно скачать в первом комментарии
КриптоПро один из наиболее широко используемых криптопровайдеров на территории Российской Федерации, он широко используется в системах электронного документооборота, сдачи отчетности и взаимодействия с государственными органами, поэтому встретить его можно практически в любой организации.
По этой причине у системных администраторов часто встает вопрос его переноса на другой ПК. А так как криптография является для многих сложной и непонятной областью, то эта простая задача может вызвать некоторые затруднения.
При переносе обычно возникает несколько проблем:
🔹 Узнать серийный номер установленного экземпляра КриптоПро
🔹 Перенести ключи расположенные в реестре
🔹 Перенести пользовательские сертификаты
Несмотря на то, что налоговая давно выпускает неэскортируемые сертификаты эта проблема давно и успешно решается, а хранение в реестре по-прежнему распространено.
✅ Как это сделать можно прочитать в нашей статье: https://interface31.ru/post/perenos-sertifikatov-i-zakrytyh-klyuchey-cryptopro-hranyashhihsya-v-reestre
Но чтобы ускорить данный процесс можно использовать специальный скрипт, который мы подготовили специально для этой задачи.
👉 Скрипт состоит из двух файлов: собственно PS-скрипта и BAT-вфайла для его запуска. Поместите их в одном расположении и запустите с правами Администратора.
В результате его работы вы получите:
🔹Текстовый файл с серийным номером Крипто-Про
🔹Файл реестра с закрытыми ключами
🔹Архив с сертификатами из хранилища пользователя
Чтобы не запутаться в имена файлов добавлены последние четыре цифры серийного номера.
👇👇👇 Файлы скрипта можно скачать в первом комментарии
👍39❤3
Особенности эксплуатации CA на роутерах Mikrotik: резервное копирование, экспорт и импорт сертификатов
Mikrotik предоставляет пользователям достаточно широкие возможности, одна из них - создание на роутере собственного центра сертификации (CA), который позволяет управлять собственной инфраструктурой открытых ключей (PKI).
Благодаря этому вы можете выпускать, подписывать и отзывать сертификаты, а также поддерживать доверительные отношения без использования дополнительных технических и программных средств.
Это удобно, но эксплуатация CA на базе Mikrotik имеет свои особенности и подводные камни, которые нужно четко представлять и учитывать при выборе такого решения.
Коротко напомним, что такое инфраструктура открытых ключей (PKI), это область доверия, где каждый участник может доверять другому участнику, не имея никаких предварительных данных о нем. В основе PKI лежит центр сертификации (CA), авторитет CA неоспорим, а доверие к нему не подвергается сомнению.
При создании CA генерируется ключевая пара из закрытого ключа и корневого сертификата, который содержит открытый ключ. Закрытый ключ является секретным и должен храниться как зеница ока, потому как его компрометация дает возможность злоумышленнику выпускать сертификаты от имени вашего CA, а следовательно, получить доступ к вашей области доверия.
Корневой сертификат, наоборот, должен быть широко распространен на узлах вашей области доверия, так как именно он позволяет убедиться в подлинности выпущенных сертификатов.
При этом любой пользователь или узел, располагающий корневым сертификатом, может в любой момент времени убедиться в подлинности предъявленного ему сертификата другого пользователя или узла, а так как доверие к CA не подвергается сомнению, то автоматически возникают доверительные отношения с предъявителем действующего сертификата.
Также корневой сертификат содержит адрес CRL - списка отозванных сертификатов, что позволяет дополнительно убедиться, что предъявленный сертификат не был отозван.
Следует понимать, что после того, как CA выпустил сертификат и передал его клиенту, он больше не может его контролировать и в случае компрометации его можно только отозвать.
Между тем отозванный сертификат будет успешно проходить проверку подлинности при помощи корневого сертификата и проверить его на отзыв можно только при помощи списка CRL, который должен быть опубликован для общего доступа. Если CRL отсутствует или недоступен, то проверить сертификат на отзыв будет невозможно, а следовательно, такой сертификат будет принят как действительный.
✅ Читать далее
Mikrotik предоставляет пользователям достаточно широкие возможности, одна из них - создание на роутере собственного центра сертификации (CA), который позволяет управлять собственной инфраструктурой открытых ключей (PKI).
Благодаря этому вы можете выпускать, подписывать и отзывать сертификаты, а также поддерживать доверительные отношения без использования дополнительных технических и программных средств.
Это удобно, но эксплуатация CA на базе Mikrotik имеет свои особенности и подводные камни, которые нужно четко представлять и учитывать при выборе такого решения.
Коротко напомним, что такое инфраструктура открытых ключей (PKI), это область доверия, где каждый участник может доверять другому участнику, не имея никаких предварительных данных о нем. В основе PKI лежит центр сертификации (CA), авторитет CA неоспорим, а доверие к нему не подвергается сомнению.
При создании CA генерируется ключевая пара из закрытого ключа и корневого сертификата, который содержит открытый ключ. Закрытый ключ является секретным и должен храниться как зеница ока, потому как его компрометация дает возможность злоумышленнику выпускать сертификаты от имени вашего CA, а следовательно, получить доступ к вашей области доверия.
Корневой сертификат, наоборот, должен быть широко распространен на узлах вашей области доверия, так как именно он позволяет убедиться в подлинности выпущенных сертификатов.
При этом любой пользователь или узел, располагающий корневым сертификатом, может в любой момент времени убедиться в подлинности предъявленного ему сертификата другого пользователя или узла, а так как доверие к CA не подвергается сомнению, то автоматически возникают доверительные отношения с предъявителем действующего сертификата.
Также корневой сертификат содержит адрес CRL - списка отозванных сертификатов, что позволяет дополнительно убедиться, что предъявленный сертификат не был отозван.
Следует понимать, что после того, как CA выпустил сертификат и передал его клиенту, он больше не может его контролировать и в случае компрометации его можно только отозвать.
Между тем отозванный сертификат будет успешно проходить проверку подлинности при помощи корневого сертификата и проверить его на отзыв можно только при помощи списка CRL, который должен быть опубликован для общего доступа. Если CRL отсутствует или недоступен, то проверить сертификат на отзыв будет невозможно, а следовательно, такой сертификат будет принят как действительный.
✅ Читать далее
👍18❤2
Что не так с Base64?
Вчера в комментариях один из читателей предложил закодировать полезную нагрузку PowerShell при помощи Base64 и поместить ее непосредственно в BAT-файл. На что мы справедливо заметили, что такой скрипт лучше всего сразу удалить не запуская.
Что не так с Base64 и почему для админа его наличие является своеобразной красной тряпкой. Начнем с того, что такое вообще Base64 — это стандарт кодирования двоичных данных при помощи только 64 символов ASCII.
Изначально Base64 использовался для передачи вложений посредством текстовых сообщений в электронной почте и продолжает широко использоваться для подобных целей сейчас.
Так в чем же его опасность? А в том, что никакой потребности использовать Base64 в скриптах нет. Любую бинарную нагрузку мы можем разместить рядом со скриптом в его рабочей папке, или использовать самораспаковывающийся архив, который также легко проконтролировать.
А теперь представьте себе, что в скрипте или где-то еще вам встретилась команда:
Ничего не понятно, но очень интересно. Вы знаете, что она обозначает? Можете быстро сказать безопасно ли запустить это или нет?
Обычно такие вещи используются для обфускации кода, чтобы затруднить его чтение и понимание.
В данном случае ничего страшного тут нет, просто закодировано:
Но кто может поручиться, что в следующий раз вам таким образом не подкинут вредоносное содержимое? Тем более, что данная методика как раз и используется для распространения вредоносов и выполнения деструктивных действий.
Да, все это несложно расшифровать, но перед этим всегда надо задать себе вопрос – а с какой целью это закодировали. Ну не будет никто заниматься этим просто так, из любви к искусству. Потому что через неделю ты и сам забудешь, что здесь написано.
Поэтому увидев Base64 там, где его в принципе не должно быть: скрипте, тексте веб-страницы, выполняемых командах – сразу следует насторожиться и, лучше всего, отказаться от выполнения. Либо тщательно проверить что именно там закодировано и сделать выводы.
Вчера в комментариях один из читателей предложил закодировать полезную нагрузку PowerShell при помощи Base64 и поместить ее непосредственно в BAT-файл. На что мы справедливо заметили, что такой скрипт лучше всего сразу удалить не запуская.
Что не так с Base64 и почему для админа его наличие является своеобразной красной тряпкой. Начнем с того, что такое вообще Base64 — это стандарт кодирования двоичных данных при помощи только 64 символов ASCII.
Изначально Base64 использовался для передачи вложений посредством текстовых сообщений в электронной почте и продолжает широко использоваться для подобных целей сейчас.
Так в чем же его опасность? А в том, что никакой потребности использовать Base64 в скриптах нет. Любую бинарную нагрузку мы можем разместить рядом со скриптом в его рабочей папке, или использовать самораспаковывающийся архив, который также легко проконтролировать.
А теперь представьте себе, что в скрипте или где-то еще вам встретилась команда:
eval "$(echo c3VkbyBhcHQgdXBkYXRlIC15ICYmIHN1ZG8gYXB0IGZ1bGwtdXBncmFkZSAteQ== | base64 -d)"
Ничего не понятно, но очень интересно. Вы знаете, что она обозначает? Можете быстро сказать безопасно ли запустить это или нет?
Обычно такие вещи используются для обфускации кода, чтобы затруднить его чтение и понимание.
В данном случае ничего страшного тут нет, просто закодировано:
sudo apt update -y && sudo apt full-upgrade -y
Но кто может поручиться, что в следующий раз вам таким образом не подкинут вредоносное содержимое? Тем более, что данная методика как раз и используется для распространения вредоносов и выполнения деструктивных действий.
Да, все это несложно расшифровать, но перед этим всегда надо задать себе вопрос – а с какой целью это закодировали. Ну не будет никто заниматься этим просто так, из любви к искусству. Потому что через неделю ты и сам забудешь, что здесь написано.
Поэтому увидев Base64 там, где его в принципе не должно быть: скрипте, тексте веб-страницы, выполняемых командах – сразу следует насторожиться и, лучше всего, отказаться от выполнения. Либо тщательно проверить что именно там закодировано и сделать выводы.
🤝19❤9👍8💯5
Самохостинг
Про самосбор мы уже не раз говорили, пришла пора поговорить еще об одном излюбленном явлении – самохостинге.
Что это такое? Это публикация во внешнюю сеть определенных ресурсов для доступа к ним, как личного, так и широких масс желающих из любой точки всемирной сети. Ключевой момент здесь – это доступ, он должен быть постоянный и из любого места.
Поэтому, когда мы говорим о хостинге, то основным требованием к нему является доступность. У хостеров одним из основных параметров является SLA (Service Level Agreement или соглашение об уровне сервиса), который регламентирует допустимое время простоя и обычно его значения начинаются с 95-99%.
На самом деле это достаточно большие цифры, так 95% допускает простой 18,25 суток в год, а 99% - 3,65 суток.
А что нам может предложить самохостинг? Обычно здесь все начинается с того, что мол не нужен мне этот SLA, мне нужно просто получить доступ к моим данным для дома, для семьи откуда-то извне, причем время от времени. Ну и фоточки куда с телефона слить.
Поэтому для многих самохост является также и точкой размещения определенных данных и часто в единственном экземпляре (не считая мобильных устройств).
При этом греет душу, что все это бесплатно, на своем сервере, который тихо жужжит где-то в чулане.
Ок, давайте просто прикинем. Сервер из неоткуда не берется, его надо купить. Давайте прикинем стоимость платформы на N100 с дисками на 1 ТБ.
Такая машинка по актуальным ценам обойдется плюс-минус в 60 000 рублей.
Определим ей срок полезного использования в пять лет. В результате получим стоимость владения (не считая затрат на содержание) в размере 12 000 рублей в год или 1 000 рублей в месяц.
1 ТБ на Яндекс Диске стоит без скидок 250 руб./мес., со скидками еще меньше, и голова не болит.
На оставшиеся 750 рублей можно купить VPS начального уровня, которой будет достаточно для хостинга всего остального домашнего добра.
При этом у вас больше не болит голова насчет всей этой кухни. А болеть там на самом деле есть чему.
Надежность? С этим все плохо. Запчастей нет, любой выход из строя комплектующих – это длительный простой, пока будут решаться вопросы гарантии или дополнительные расходы.
Пожары, затопления, аварии на электросетях и прочий форс-мажор, включая тупое «кошка бежала, хвостиком вильнула, включенный сервер упал со шкафа на пол».
Также не сбрасываем со счетов возможный брак, когда оба ваших диска в RAID решат отправиться в страну вечной охоты одновременно (привет муха CC) и диски вам может и поменяют по гарантии, но вот на данные гарантия не распространяется.
Доступность? Тут тоже все плохо. Выключили электричество, пропал интернет – и все, стоим, ждем. И хорошо если там просто личные данные, а не что-то нужное здесь и сейчас. При этом обеспечить себе резервные мощности для самохостинга практически невозможно.
Ну или это будет стоить совсем других денег…
При этом не забываем, что наше оборудование коптит небо, расходует ресурс, стареет, что рано или поздно потребует его замены. У хостера это делает сам хостер, вы просто оплачиваете услугу по тарифу.
Ну ладно, то про дом, а теперь про работу. Так тут ровно все тоже самое. Да, нежелание выкладывать корпоративные данные в публичные облака понятно. Но кто мешает поднять свое облако на публичном хостинге?
По деньгам это будет плюс-минус стоимость самохостинга, но вы получите в разы более высокую надежность и доступность.
При этом контроль над системой у вас как был, так и остается. Но не болит голова по железу, ремонту, запчастям, электроснабжению, интернету и многому-многому другому.
Единственный вариант, когда самохостинг оправдан – это требования к безопасности и хранению данных, когда размещать их на внешних ресурсах может быть явно запрещено или обложено таким количеством требований, что проще как-нибудь самим.
Но это уже не про широкий доступ и вопрос доступности тут вообще может уходить на задний план.
В остальном самохостинг – это дорого и ненадежно. Оправдан только если вы просто хотите в это все поиграться с целью получить некоторый опыт.
Про самосбор мы уже не раз говорили, пришла пора поговорить еще об одном излюбленном явлении – самохостинге.
Что это такое? Это публикация во внешнюю сеть определенных ресурсов для доступа к ним, как личного, так и широких масс желающих из любой точки всемирной сети. Ключевой момент здесь – это доступ, он должен быть постоянный и из любого места.
Поэтому, когда мы говорим о хостинге, то основным требованием к нему является доступность. У хостеров одним из основных параметров является SLA (Service Level Agreement или соглашение об уровне сервиса), который регламентирует допустимое время простоя и обычно его значения начинаются с 95-99%.
На самом деле это достаточно большие цифры, так 95% допускает простой 18,25 суток в год, а 99% - 3,65 суток.
А что нам может предложить самохостинг? Обычно здесь все начинается с того, что мол не нужен мне этот SLA, мне нужно просто получить доступ к моим данным для дома, для семьи откуда-то извне, причем время от времени. Ну и фоточки куда с телефона слить.
Поэтому для многих самохост является также и точкой размещения определенных данных и часто в единственном экземпляре (не считая мобильных устройств).
При этом греет душу, что все это бесплатно, на своем сервере, который тихо жужжит где-то в чулане.
Ок, давайте просто прикинем. Сервер из неоткуда не берется, его надо купить. Давайте прикинем стоимость платформы на N100 с дисками на 1 ТБ.
Такая машинка по актуальным ценам обойдется плюс-минус в 60 000 рублей.
Определим ей срок полезного использования в пять лет. В результате получим стоимость владения (не считая затрат на содержание) в размере 12 000 рублей в год или 1 000 рублей в месяц.
1 ТБ на Яндекс Диске стоит без скидок 250 руб./мес., со скидками еще меньше, и голова не болит.
На оставшиеся 750 рублей можно купить VPS начального уровня, которой будет достаточно для хостинга всего остального домашнего добра.
При этом у вас больше не болит голова насчет всей этой кухни. А болеть там на самом деле есть чему.
Надежность? С этим все плохо. Запчастей нет, любой выход из строя комплектующих – это длительный простой, пока будут решаться вопросы гарантии или дополнительные расходы.
Пожары, затопления, аварии на электросетях и прочий форс-мажор, включая тупое «кошка бежала, хвостиком вильнула, включенный сервер упал со шкафа на пол».
Также не сбрасываем со счетов возможный брак, когда оба ваших диска в RAID решат отправиться в страну вечной охоты одновременно (привет муха CC) и диски вам может и поменяют по гарантии, но вот на данные гарантия не распространяется.
Доступность? Тут тоже все плохо. Выключили электричество, пропал интернет – и все, стоим, ждем. И хорошо если там просто личные данные, а не что-то нужное здесь и сейчас. При этом обеспечить себе резервные мощности для самохостинга практически невозможно.
Ну или это будет стоить совсем других денег…
При этом не забываем, что наше оборудование коптит небо, расходует ресурс, стареет, что рано или поздно потребует его замены. У хостера это делает сам хостер, вы просто оплачиваете услугу по тарифу.
Ну ладно, то про дом, а теперь про работу. Так тут ровно все тоже самое. Да, нежелание выкладывать корпоративные данные в публичные облака понятно. Но кто мешает поднять свое облако на публичном хостинге?
По деньгам это будет плюс-минус стоимость самохостинга, но вы получите в разы более высокую надежность и доступность.
При этом контроль над системой у вас как был, так и остается. Но не болит голова по железу, ремонту, запчастям, электроснабжению, интернету и многому-многому другому.
Единственный вариант, когда самохостинг оправдан – это требования к безопасности и хранению данных, когда размещать их на внешних ресурсах может быть явно запрещено или обложено таким количеством требований, что проще как-нибудь самим.
Но это уже не про широкий доступ и вопрос доступности тут вообще может уходить на задний план.
В остальном самохостинг – это дорого и ненадежно. Оправдан только если вы просто хотите в это все поиграться с целью получить некоторый опыт.
👎32🤮18👍10🤔8❤5
Небольшой «лайфхак» для WireGuard на Mikrotik
Стабильная работа WireGuard, даже на внутренних каналах сегодня под большим вопросом, как и любых других туннельных протоколов. Поэтому наш способ, выясненный эмпирическим путем, возможно, кому-то пригодится.
Как это бывает, WireGuard работал-работал и вдруг перестал. А так как это протокол без сохранения состояния, то проверить его работу просто посмотрев на список интерфейсов мы не можем, если пир сконфигурирован без ошибок, то интерфейс всегда будет поднят.
И единственный способ определить работу туннеля – это послать пакет на его другую сторону. Косвенным признаком того, что что-то пошло не так является время последнего рукопожатия, которое не должно превышать двух минут.
Если в этой колонке стоят нули или время превысили две минуты, то это означает, что или рукопожатия не было вообще или оно перестало проходить некоторое время назад. Но даже наличие активного рукопожатия не является гарантией работы туннеля, мы не раз сталкивались с ситуацией, когда рукопожатия проходили, а трафик – нет.
На Mikrotik, столкнувшись с внезапной неработоспособностью туннеля можно попробовать следующий способ: на вкладке WireGuard открыть свойства интерфейса и изменить значение Listen Port.
Поставить можно любое другое, главное – чтобы каждый интерфейс имел уникальный порт для своего экземпляра службы. После этого часто все начинает отлично работать, до следующего подобного раза.
Причины и следствия такого поведения мы разбирать не будем, так как это сегодня лежит вне плоскости публичного обсуждения.
Стабильная работа WireGuard, даже на внутренних каналах сегодня под большим вопросом, как и любых других туннельных протоколов. Поэтому наш способ, выясненный эмпирическим путем, возможно, кому-то пригодится.
Как это бывает, WireGuard работал-работал и вдруг перестал. А так как это протокол без сохранения состояния, то проверить его работу просто посмотрев на список интерфейсов мы не можем, если пир сконфигурирован без ошибок, то интерфейс всегда будет поднят.
И единственный способ определить работу туннеля – это послать пакет на его другую сторону. Косвенным признаком того, что что-то пошло не так является время последнего рукопожатия, которое не должно превышать двух минут.
Если в этой колонке стоят нули или время превысили две минуты, то это означает, что или рукопожатия не было вообще или оно перестало проходить некоторое время назад. Но даже наличие активного рукопожатия не является гарантией работы туннеля, мы не раз сталкивались с ситуацией, когда рукопожатия проходили, а трафик – нет.
На Mikrotik, столкнувшись с внезапной неработоспособностью туннеля можно попробовать следующий способ: на вкладке WireGuard открыть свойства интерфейса и изменить значение Listen Port.
Поставить можно любое другое, главное – чтобы каждый интерфейс имел уникальный порт для своего экземпляра службы. После этого часто все начинает отлично работать, до следующего подобного раза.
Причины и следствия такого поведения мы разбирать не будем, так как это сегодня лежит вне плоскости публичного обсуждения.
👍11❤10👌2💯2
Lithnet Password Protection for Active Directory (LPP)
Lithnet Password Protection for Active Directory (LPP) – приложение с открытым исходным кодом, который добавляет в Active Directory дополнительный фильтр паролей, который позволяет контролировать соответствие паролей пользователей расширенным требованиям.
Для чего это нужно? Стандартная политика паролей Windows позволяет задавать лишь общие требования к паролям и не позволяет выполнять их дополнительную проверку, например, политике будет полностью соответствовать такой пароль: Pa$$word1
Это позволяет пользователям обходить формальные требования и использовать фактически слабые пароли. LPP позволяет решить эту проблему используя внутреннюю базу запрещенных слов, при этом будут учитываться все типовые замены и обфускации.
Например, если мы добавим в базу слово password то программа заблокирует такие варианты как Pa$$word1, P@ssw0rd, pa55word! Или password123456!'
Для тех, кто хочет большего, можно подключить внешнюю базу Have I Been Pwned (HIBP), которая содержит скомпрометированные пароли, для этого вам понадобится около 8 ГБ свободного места.
После чего вы можете проверить уже имеющиеся пароли на их компрометацию, для этой проверки не требуется интернет и хеш пароля не покидает контроллер домена. Для параноиков поясняем – вся работа со скачанной базой производится сугубо локально.
Любите использовать регулярные выражения? Здесь тоже есть широкое поле, укажите регулярки под которые должен или наоборот не должен попадать пароль.
Также вы можете установить разные требования для паролей разной длинны, скажем требовать для коротких паролей обязательного наличия специальных символов, а для более длинных достаточно будет только цифр и букв.
Можно также использовать бальную систему, когда за определенные символы и комбинации присваивается некоторое количество баллов и пользователь должен получить не менее некоторого минимального значения.
Продукт полностью интегрирован с PowerShell и удобно управляется с его помощью, а также поставляется с набором собственных групповых политик, позволяющих гибко применять его возможности в домене.
И все это, как мы уже говорили – бесплатно, по лицензии MIT.
✅ Страница проекта: https://github.com/lithnet/ad-password-protection
Lithnet Password Protection for Active Directory (LPP) – приложение с открытым исходным кодом, который добавляет в Active Directory дополнительный фильтр паролей, который позволяет контролировать соответствие паролей пользователей расширенным требованиям.
Для чего это нужно? Стандартная политика паролей Windows позволяет задавать лишь общие требования к паролям и не позволяет выполнять их дополнительную проверку, например, политике будет полностью соответствовать такой пароль: Pa$$word1
Это позволяет пользователям обходить формальные требования и использовать фактически слабые пароли. LPP позволяет решить эту проблему используя внутреннюю базу запрещенных слов, при этом будут учитываться все типовые замены и обфускации.
Например, если мы добавим в базу слово password то программа заблокирует такие варианты как Pa$$word1, P@ssw0rd, pa55word! Или password123456!'
Для тех, кто хочет большего, можно подключить внешнюю базу Have I Been Pwned (HIBP), которая содержит скомпрометированные пароли, для этого вам понадобится около 8 ГБ свободного места.
После чего вы можете проверить уже имеющиеся пароли на их компрометацию, для этой проверки не требуется интернет и хеш пароля не покидает контроллер домена. Для параноиков поясняем – вся работа со скачанной базой производится сугубо локально.
Любите использовать регулярные выражения? Здесь тоже есть широкое поле, укажите регулярки под которые должен или наоборот не должен попадать пароль.
Также вы можете установить разные требования для паролей разной длинны, скажем требовать для коротких паролей обязательного наличия специальных символов, а для более длинных достаточно будет только цифр и букв.
Можно также использовать бальную систему, когда за определенные символы и комбинации присваивается некоторое количество баллов и пользователь должен получить не менее некоторого минимального значения.
Продукт полностью интегрирован с PowerShell и удобно управляется с его помощью, а также поставляется с набором собственных групповых политик, позволяющих гибко применять его возможности в домене.
И все это, как мы уже говорили – бесплатно, по лицензии MIT.
✅ Страница проекта: https://github.com/lithnet/ad-password-protection
👍24❤3
С Днем радио!!!
Сегодня мой профессиональный праздник и не только мой, но и многих коллег, особенно старшего возраста.
Это сейчас путь в IT открыт сразу и напрямую, в наше время путь к вычислительной технике начинался с радиолюбительства и программируемых калькуляторов.
Позже все это плавно перетекало в наиболее близкие профессии, связанные с электроникой. А электроника в свое время была неразлучно связана с связью (вот такой вот каламбур вышел).
И, следует сказать, радиолюбительское прошлое и профильное образование связиста сильно пригодилось впоследствии. Прежде всего инженерным мышлением, умением читать схемы и навыками диагностики и выявления неисправностей.
Появившиеся позднее компьютеры кто-то сделал помощниками в инженерных расчетах, а кто-то связал с ними свою профессию.
Поэтому всех причастных, настоящих и бывших связистов, хотя связисты, а тем более радиолюбители, бывшими не бывают, с праздником!
🥃🥃🥃
Сегодня мой профессиональный праздник и не только мой, но и многих коллег, особенно старшего возраста.
Это сейчас путь в IT открыт сразу и напрямую, в наше время путь к вычислительной технике начинался с радиолюбительства и программируемых калькуляторов.
Позже все это плавно перетекало в наиболее близкие профессии, связанные с электроникой. А электроника в свое время была неразлучно связана с связью (вот такой вот каламбур вышел).
И, следует сказать, радиолюбительское прошлое и профильное образование связиста сильно пригодилось впоследствии. Прежде всего инженерным мышлением, умением читать схемы и навыками диагностики и выявления неисправностей.
Появившиеся позднее компьютеры кто-то сделал помощниками в инженерных расчетах, а кто-то связал с ними свою профессию.
Поэтому всех причастных, настоящих и бывших связистов, хотя связисты, а тем более радиолюбители, бывшими не бывают, с праздником!
🥃🥃🥃
10👍43🤝14🔥7❤2👏2
Что нужно знать перед миграцией на Ubuntu 26.04 LTS
В тестовой среде протестировали несколько серверных систем, обновленных до Ubuntu 26.04 LTS, и проверили основные изменения в системе, которые могут оказаться критичными и должны обязательно учитываться при планировании миграции.
🔹 DSA-ключи в OpenSSH не поддерживаются. Хостовые DSA-ключи больше не генерируются. Если в
По умолчанию включен постквантовый алгоритм обмена ключами mlkem768x25519-sha256, если вторая сторона его не поддерживает, то будет согласован один из классических алгоритмов. Для критичных систем имеет смысл перегенерировать ключи.
🔹 Вместо systemd-timesyncd теперь по умолчанию используется Chrony, для приведения обновленных систем к единому стандарту выполните:
🔹 SSSD работает под пользователем sssd, а не root, проверьте, что новый пользователь sssd имеет доступ к необходимым ресурсам (keytab-файлы, сертификаты).
🔹 cgroup v1 удален. Контейнеры, настроенные на legacy/hybrid cgroup работать больше не будут. Под угрозой: Debian 9/10, Ubuntu 16.04/18.04, CentOS 7, старые Alpine.
🔹 apt-key удален – все сценарии с его использованием работать перестанут, переходите на новую систему управления ключами. Подробнее: https://interface31.ru/post/apt-key-is-deprecated-ili-upravlenie-klyuchami-v-sovremennyh-vypuskah-debian-i-ubunt/
🔹 Вместо классического sudo используется sudo-rs, который не 100% совместим, протестируйте свою конфигурацию перед применением.
🔹 Директория /tmp теперь монтируется в tmpfs, по умолчанию верхний предел выделяется в размере 50% доступного размера ОЗУ. Если ваши сценарии предполагают закидывание в /tmp больших объемов данных, проверьте их на предмет неприятных сюрпризов с памятью.
🔹 В данном релизе последний раз поддерживаются скрипты System V init, если они у вас остались, то самое время переводить их на юниты systemd. В следующем LTS поддержка System V init будет удалена.
🔹 Вместо initramfs-tools используется Dracut, но при необходимости можно вернуться назад, оба варианта поддерживаются.
В тестовой среде протестировали несколько серверных систем, обновленных до Ubuntu 26.04 LTS, и проверили основные изменения в системе, которые могут оказаться критичными и должны обязательно учитываться при планировании миграции.
🔹 DSA-ключи в OpenSSH не поддерживаются. Хостовые DSA-ключи больше не генерируются. Если в
~/.ssh/known_hosts или authorized_keys остались DSA-ключи — они перестанут работать. По умолчанию включен постквантовый алгоритм обмена ключами mlkem768x25519-sha256, если вторая сторона его не поддерживает, то будет согласован один из классических алгоритмов. Для критичных систем имеет смысл перегенерировать ключи.
🔹 Вместо systemd-timesyncd теперь по умолчанию используется Chrony, для приведения обновленных систем к единому стандарту выполните:
apt-mark auto systemd-timesyncd
apt install chrony
🔹 SSSD работает под пользователем sssd, а не root, проверьте, что новый пользователь sssd имеет доступ к необходимым ресурсам (keytab-файлы, сертификаты).
🔹 cgroup v1 удален. Контейнеры, настроенные на legacy/hybrid cgroup работать больше не будут. Под угрозой: Debian 9/10, Ubuntu 16.04/18.04, CentOS 7, старые Alpine.
🔹 apt-key удален – все сценарии с его использованием работать перестанут, переходите на новую систему управления ключами. Подробнее: https://interface31.ru/post/apt-key-is-deprecated-ili-upravlenie-klyuchami-v-sovremennyh-vypuskah-debian-i-ubunt/
🔹 Вместо классического sudo используется sudo-rs, который не 100% совместим, протестируйте свою конфигурацию перед применением.
🔹 Директория /tmp теперь монтируется в tmpfs, по умолчанию верхний предел выделяется в размере 50% доступного размера ОЗУ. Если ваши сценарии предполагают закидывание в /tmp больших объемов данных, проверьте их на предмет неприятных сюрпризов с памятью.
🔹 В данном релизе последний раз поддерживаются скрипты System V init, если они у вас остались, то самое время переводить их на юниты systemd. В следующем LTS поддержка System V init будет удалена.
🔹 Вместо initramfs-tools используется Dracut, но при необходимости можно вернуться назад, оба варианта поддерживаются.
👀16🔥7❤4👍3👎2
USB 3.x и Wi-Fi 2,4 ГГц
Что у них общего? На первый взгляд ничего, где USB и где Wi-Fi, абсолютно разные технологии.
Но если копнуть немного глубже, то перед нами электронные устройства, предназначенные для скоростной передачи данных, а следовательно, работающие на высоких частотах и способные производить помехи другим электронным устройствам.
USB 3.x не исключение, частотный спектр сигнала которого пересекается с диапазоном Wi-Fi 2,4 ГГц и способен серьезно нарушить работу последнего, вплоть до полного пропадания связи.
Это, например, коротко описано в разделе техподдержки TP-LINK:
Согласно спецификации интерфейса USB 3.0, передача данных по данному стандарту затрагивает частотный диапазон в 2,4-2,5 ГГц.
В результате, большое количество шумов или интерференций сигнала возникает на частоте 2,4 ГГц, и как следствие, мешает корректной работе роутера.
Если устройство USB 3.0 расположено близко к антеннам роутера, роутер пользователя может испытывать серьезные воздействия на частоте 2,4 ГГц.
Кому интересны подробности – могут ознакомиться с более детальным документом: https://www.usb.org/sites/default/files/327216.pdf
Выводы из него просты: если вы используете USB 3.x устройства с недостаточным экранированием кабелей или самих устройств, то можете получить серьезные проблемы с работой Wi-Fi в диапазоне 2,4 ГГц.
Особенно это касается роутеров, к которым пользователи любят присоединять накопители делая из них мини-медиацентры. Уровень широкополосного шума от USB 3.0 жесткого диска показан на картинке к посту.
Можно увидеть, что в среднем он на 20 дБм превышает фоновый шум, что является серьезной помехой, вызывающей различные негативные эффекты.
Аналогичный эффект могут испытывать клиентские устройства, такие как ноутбуки. Активное USB устройство, вставленное со стороны размещения беспроводного адаптера или его антенн может существенно ухудшить условия приема.
Также кроме Wi-Fi могут страдать и иные беспроводные устройства, например, беспроводные клавиатуры и мыши, также работающие в диапазоне 2,4 ГГц.
Поэтому если ваши устройства ввода вдруг начали вести себя неадекватно, то проверьте, не воткнул ли кто-то рядом с ними USB 3.x устройство.
Чтобы убедиться, что это не теоретическая вероятность, а суровая правда жизни могу привести реальный пример, когда человек столкнулся с подобным эффектом от углового адаптера порта: https://mysku.club/blog/aliexpress/99897.html
При этом на диапазон 5 ГГц устройства USB 3.х никакого негативного влияния не оказывают, на него приходится минимум помех, а следующая гармоника проявит себя уже в диапазоне 7,5 ГГц, но это уже совсем другая история.
Что у них общего? На первый взгляд ничего, где USB и где Wi-Fi, абсолютно разные технологии.
Но если копнуть немного глубже, то перед нами электронные устройства, предназначенные для скоростной передачи данных, а следовательно, работающие на высоких частотах и способные производить помехи другим электронным устройствам.
USB 3.x не исключение, частотный спектр сигнала которого пересекается с диапазоном Wi-Fi 2,4 ГГц и способен серьезно нарушить работу последнего, вплоть до полного пропадания связи.
Это, например, коротко описано в разделе техподдержки TP-LINK:
Согласно спецификации интерфейса USB 3.0, передача данных по данному стандарту затрагивает частотный диапазон в 2,4-2,5 ГГц.
В результате, большое количество шумов или интерференций сигнала возникает на частоте 2,4 ГГц, и как следствие, мешает корректной работе роутера.
Если устройство USB 3.0 расположено близко к антеннам роутера, роутер пользователя может испытывать серьезные воздействия на частоте 2,4 ГГц.
Кому интересны подробности – могут ознакомиться с более детальным документом: https://www.usb.org/sites/default/files/327216.pdf
Выводы из него просты: если вы используете USB 3.x устройства с недостаточным экранированием кабелей или самих устройств, то можете получить серьезные проблемы с работой Wi-Fi в диапазоне 2,4 ГГц.
Особенно это касается роутеров, к которым пользователи любят присоединять накопители делая из них мини-медиацентры. Уровень широкополосного шума от USB 3.0 жесткого диска показан на картинке к посту.
Можно увидеть, что в среднем он на 20 дБм превышает фоновый шум, что является серьезной помехой, вызывающей различные негативные эффекты.
Аналогичный эффект могут испытывать клиентские устройства, такие как ноутбуки. Активное USB устройство, вставленное со стороны размещения беспроводного адаптера или его антенн может существенно ухудшить условия приема.
Также кроме Wi-Fi могут страдать и иные беспроводные устройства, например, беспроводные клавиатуры и мыши, также работающие в диапазоне 2,4 ГГц.
Поэтому если ваши устройства ввода вдруг начали вести себя неадекватно, то проверьте, не воткнул ли кто-то рядом с ними USB 3.x устройство.
Чтобы убедиться, что это не теоретическая вероятность, а суровая правда жизни могу привести реальный пример, когда человек столкнулся с подобным эффектом от углового адаптера порта: https://mysku.club/blog/aliexpress/99897.html
При этом на диапазон 5 ГГц устройства USB 3.х никакого негативного влияния не оказывают, на него приходится минимум помех, а следующая гармоника проявит себя уже в диапазоне 7,5 ГГц, но это уже совсем другая история.
👍28❤2🤔1
Однострочный веб-сервер на Bash
Часто бывает нужно отслеживать некоторые показатели целевого сервера или контролировать ход работы какого-либо сервиса. Все это можно сделать командами, но постоянно вызывать их в консоли – занятие утомительное.
Но есть способ проще, создать специальную страничку в браузере и вывести на нее все необходимые показатели. Причем нам не потребуется устанавливать никакого софта, все можно сделать силами bash.
И в этом нам поможет команда netcat (nc), мы не будем подробно разбирать ее применение, а просто покажем примеры.
Например, мы хотим видеть свободную память:
Здесь следует обратить внимание на опции -p – порт и q – время в секундах до закрытия соединения, если у вас там выполняется сложная команда, то возможно его придется увеличить.
Таким же образом можно просматривать логи:
Возьмем задачу немного сложнее, вывести сразу несколько показателей, ок, прямо не выходя из терминала выполним:
Но если всего этого недостаточно, то вы можете написать скрипт, который будет выводить нужную вам информацию и запускать его нашим однострочным веб-сервером:
Просто? Да. Удобно? Да. И только bash и никаких дополнительных инструментов!
Часто бывает нужно отслеживать некоторые показатели целевого сервера или контролировать ход работы какого-либо сервиса. Все это можно сделать командами, но постоянно вызывать их в консоли – занятие утомительное.
Но есть способ проще, создать специальную страничку в браузере и вывести на нее все необходимые показатели. Причем нам не потребуется устанавливать никакого софта, все можно сделать силами bash.
И в этом нам поможет команда netcat (nc), мы не будем подробно разбирать ее применение, а просто покажем примеры.
Например, мы хотим видеть свободную память:
while true;
do echo -e "HTTP/1.1 200 OK\n\n$(free)" \
| nc -l -k -p 8080 -q 1;
done
Здесь следует обратить внимание на опции -p – порт и q – время в секундах до закрытия соединения, если у вас там выполняется сложная команда, то возможно его придется увеличить.
Таким же образом можно просматривать логи:
while true;
do echo -e "HTTP/1.1 200 OK\n\n$(tail -n 15 logfile)" \
| nc -l -k -p 8080 -q 1;
done
Возьмем задачу немного сложнее, вывести сразу несколько показателей, ок, прямо не выходя из терминала выполним:
cmd1=$(free)
cmd2=$(ss -tpln)
body="$cmd1\n$cmd2"
while true;
do echo -e "HTTP/1.1 200 OK\n\n$body" \
| nc -l -k -p 8080 -q 1;
done
Но если всего этого недостаточно, то вы можете написать скрипт, который будет выводить нужную вам информацию и запускать его нашим однострочным веб-сервером:
while true; do { \
echo -ne "HTTP/1.1 200 OK\r\n"; sh my_script.sh; } \
| nc -l -k -p 8080 -q 1; \
doneПросто? Да. Удобно? Да. И только bash и никаких дополнительных инструментов!
👍31🔥6❤2
Пятничное, о жизни. Свекольный сахар
Третьего дня был у одного клиента в офисе, перед этим заехал на пункт выдачи и забрал несколько пачек турецкого Атом Чая. Это такой травяной чай в кубиках, просто залить кипятком, при этом состав там нормальный, без всякой нездоровой химии.
Я его обычно с черным или зеленым чаем мешаю, как аналог всяких вкусовых добавок или ароматизаторов, на ночь можно и чистого заварить, чтобы без всяких бодрящих веществ. Ну и обещал я там народ как-то этим чаем угостить.
Вот приехал и угощаю. А в той организации есть одна мадам, дама не глупая, хороший такой, опытный главный бухгалтер, годочков 35, семья, двое деток. Но есть у нее бзик – здоровое питание.
В общем берет она коробку и начинает изучать состав, а там, ясен перец, все на турецком. Но кого это сегодня смущает? Наводим камеру телефона и читаем перевод.
- Класс, свекольный сахар!
Я немного не понимаю восторга, ну свекольный и чего?
- Те не понимаешь, это же круто, это натуральный состав, тут не простой сахар, а свекольный.
Мягко интересуюсь, а какой еще сахар она знает, ну кроме тростникового, разумеется.
А дальше вроде бы умный и грамотный человек начинает нести лютую дичь. Мол сахар бывает с завода, а бывает натуральный, скажем, тростниковый или свекольный. Мол почему тростниковый так дорого стоит?
Аргумент, что его везут с другого полушария, не прокатывает. А свекольного у нас, по ее мнению, просто нет, потому что это дорого и невыгодно.
Но из чего же тогда магазинный сахар? Ну да, тоже из свеклы, но он заводской, химической переработки, поэтому на нем и не пишут свекольный, потому что он не натуральный, поэтому свекольный на нем писать нельзя.
Переубеждать кого-то в таком случае бесполезно, но я тут сразу вспомнил одну историю:
🔹 Крафтовый Ethernet
А заодно и бизнес-идея появилась, берем обычный сахар, сильно не очищаем, чтобы пах как надо и имел соответствующий привкус, кто жил в деревне и имел со свекольной патокой дело – знает.
После чего продаем его как супер-пупер натуральный крафтовый свекольный сахар.
Ну и бурачный самогон без очистки тоже можно как крафтовый продавать, а кому не зашло – тот просто не понял и не проникся всей натуральностью продукта.
Третьего дня был у одного клиента в офисе, перед этим заехал на пункт выдачи и забрал несколько пачек турецкого Атом Чая. Это такой травяной чай в кубиках, просто залить кипятком, при этом состав там нормальный, без всякой нездоровой химии.
Я его обычно с черным или зеленым чаем мешаю, как аналог всяких вкусовых добавок или ароматизаторов, на ночь можно и чистого заварить, чтобы без всяких бодрящих веществ. Ну и обещал я там народ как-то этим чаем угостить.
Вот приехал и угощаю. А в той организации есть одна мадам, дама не глупая, хороший такой, опытный главный бухгалтер, годочков 35, семья, двое деток. Но есть у нее бзик – здоровое питание.
В общем берет она коробку и начинает изучать состав, а там, ясен перец, все на турецком. Но кого это сегодня смущает? Наводим камеру телефона и читаем перевод.
- Класс, свекольный сахар!
Я немного не понимаю восторга, ну свекольный и чего?
- Те не понимаешь, это же круто, это натуральный состав, тут не простой сахар, а свекольный.
Мягко интересуюсь, а какой еще сахар она знает, ну кроме тростникового, разумеется.
А дальше вроде бы умный и грамотный человек начинает нести лютую дичь. Мол сахар бывает с завода, а бывает натуральный, скажем, тростниковый или свекольный. Мол почему тростниковый так дорого стоит?
Аргумент, что его везут с другого полушария, не прокатывает. А свекольного у нас, по ее мнению, просто нет, потому что это дорого и невыгодно.
Но из чего же тогда магазинный сахар? Ну да, тоже из свеклы, но он заводской, химической переработки, поэтому на нем и не пишут свекольный, потому что он не натуральный, поэтому свекольный на нем писать нельзя.
Переубеждать кого-то в таком случае бесполезно, но я тут сразу вспомнил одну историю:
🔹 Крафтовый Ethernet
А заодно и бизнес-идея появилась, берем обычный сахар, сильно не очищаем, чтобы пах как надо и имел соответствующий привкус, кто жил в деревне и имел со свекольной патокой дело – знает.
После чего продаем его как супер-пупер натуральный крафтовый свекольный сахар.
Ну и бурачный самогон без очистки тоже можно как крафтовый продавать, а кому не зашло – тот просто не понял и не проникся всей натуральностью продукта.
😁20🔥16🤣6💯3👎2
Некоторые размышления по поводу интеграций с различными ГИС
Вот уже, хотел написать – несколько недель, а на самом деле уже несколько месяцев мы неспеша работаем над интеграцией учетной системы заказчика на 1С в одну ГИС.
Имена пока называть не будем, но кажется мне, что там везде ситуация плюс-минус идентичная. И знали бы мы это на берегу, то сто раз подумали бы, а нужен ли нам этот блудняк.
Сначала, как говорится, ничто не предвещало беды. Задача понятная, документация увесистая, по технологиям ничего необычного: SOAP. Не самый приятный вариант, но вполне рабочий, реализуемый.
Работы, поначалу, казалось на месяц-полтора, с учетом верификации со стороны ГИС и сдачи проекта. Но жизнь поставила все на свои места.
Проблемы посыпались с самого начала как из рога изобилия. Потому что ничего не работало, вообще. Хотя сделано все было строго по документации. ИИ тоже не нашел никакого криминала (а писали мы вместе с ним в плотной кооперации).
Ладно, ИИ может придумывать, но внимательно изучив отправляемые на сервер запросы пришлось признать, что ИИ прав и запросы полностью соответствуют документации. Так в чем причина?
Поддержка на помощь не спешит и отвечает четко по регламенту – на ответ отводится 24 часа, вот как раз на следующий день она и ответит, какой-нибудь ерундой, с предложением почитать документацию, а следующий ответ будет еще через сутки. А к самой мякотке если через неделю доберемся, то это будет очень хорошо.
В общем где-то через месяц мы их таки забодали, и они прислали нам «сокровенную» ссылку на страницу с примерами в документации. Сказать, что мы знатно изумились, это ничего не сказать.
В запросах использовались некие дополнительные пространства имен, о которых в основной документации было ни сном, ни духом. Но это половина беды. Для реализации одного из модулей предполагалось три метода: создать, обновить и получить запись.
Логично, что они должны быть полностью идентичными по структуре и отличаться только параметрами.
А вот и не угадали, складывается впечатлении, что методы писали совершенно разные люди, не знакомые друг с другом. Потому что метод получить разительно отличался от создать и обновить как заголовками, так и используемыми пространствами имен.
Унификация? Нет, не слышали. Поддержка? Нет, не в курсе. И вообще, складывается впечатление, что ее основная задача – футболить по регламенту, мол идите, читайте документацию.
А саму документацию, складывается впечатление, писали третьи люди, проекта в глаза не видевшие. Все многословно, путано и тонет в канцеляризмах. Примеров нет, XSD-схем нет, куча недомолвок и белых пятен.
Заказчик одно время начал нажимать и возмущаться, мол чего так долго и когда будет результат. Пришлось познакомить его с работой поддержки и уведомить, что реальные условия существенно отличаются от изначальных, в связи с чем имеем полное право договор расторгнуть с компенсацией уже потраченного времени.
При этом он не дурак и трезво оценив ситуацию дал добро на дальнейшие работы, попросив только не пустить его по миру. Хотя ему без вариантов, к сентябрю или ты интегрируешься или вешаешь на дверь замок.
Перспективы? Они там есть, только вот далеко не радостные, с учетом предполагаемого развития этой самой ГИС. Альтернативы? Тоже есть, только ценой и стоимостью поддержки совсем не радуют, при качестве на уровне дешевого любительского поделия. Ну отраслевая 1С – она такая.
А у нас остался один вопрос, да и тот – философский. Пробовали ли они сами по своей документации и по своей поддержке реализовать интеграцию? И видя поток обращений в поддержку не кажется ли им, что что-то у них не так?
Вот уже, хотел написать – несколько недель, а на самом деле уже несколько месяцев мы неспеша работаем над интеграцией учетной системы заказчика на 1С в одну ГИС.
Имена пока называть не будем, но кажется мне, что там везде ситуация плюс-минус идентичная. И знали бы мы это на берегу, то сто раз подумали бы, а нужен ли нам этот блудняк.
Сначала, как говорится, ничто не предвещало беды. Задача понятная, документация увесистая, по технологиям ничего необычного: SOAP. Не самый приятный вариант, но вполне рабочий, реализуемый.
Работы, поначалу, казалось на месяц-полтора, с учетом верификации со стороны ГИС и сдачи проекта. Но жизнь поставила все на свои места.
Проблемы посыпались с самого начала как из рога изобилия. Потому что ничего не работало, вообще. Хотя сделано все было строго по документации. ИИ тоже не нашел никакого криминала (а писали мы вместе с ним в плотной кооперации).
Ладно, ИИ может придумывать, но внимательно изучив отправляемые на сервер запросы пришлось признать, что ИИ прав и запросы полностью соответствуют документации. Так в чем причина?
Поддержка на помощь не спешит и отвечает четко по регламенту – на ответ отводится 24 часа, вот как раз на следующий день она и ответит, какой-нибудь ерундой, с предложением почитать документацию, а следующий ответ будет еще через сутки. А к самой мякотке если через неделю доберемся, то это будет очень хорошо.
В общем где-то через месяц мы их таки забодали, и они прислали нам «сокровенную» ссылку на страницу с примерами в документации. Сказать, что мы знатно изумились, это ничего не сказать.
В запросах использовались некие дополнительные пространства имен, о которых в основной документации было ни сном, ни духом. Но это половина беды. Для реализации одного из модулей предполагалось три метода: создать, обновить и получить запись.
Логично, что они должны быть полностью идентичными по структуре и отличаться только параметрами.
А вот и не угадали, складывается впечатлении, что методы писали совершенно разные люди, не знакомые друг с другом. Потому что метод получить разительно отличался от создать и обновить как заголовками, так и используемыми пространствами имен.
Унификация? Нет, не слышали. Поддержка? Нет, не в курсе. И вообще, складывается впечатление, что ее основная задача – футболить по регламенту, мол идите, читайте документацию.
А саму документацию, складывается впечатление, писали третьи люди, проекта в глаза не видевшие. Все многословно, путано и тонет в канцеляризмах. Примеров нет, XSD-схем нет, куча недомолвок и белых пятен.
Заказчик одно время начал нажимать и возмущаться, мол чего так долго и когда будет результат. Пришлось познакомить его с работой поддержки и уведомить, что реальные условия существенно отличаются от изначальных, в связи с чем имеем полное право договор расторгнуть с компенсацией уже потраченного времени.
При этом он не дурак и трезво оценив ситуацию дал добро на дальнейшие работы, попросив только не пустить его по миру. Хотя ему без вариантов, к сентябрю или ты интегрируешься или вешаешь на дверь замок.
Перспективы? Они там есть, только вот далеко не радостные, с учетом предполагаемого развития этой самой ГИС. Альтернативы? Тоже есть, только ценой и стоимостью поддержки совсем не радуют, при качестве на уровне дешевого любительского поделия. Ну отраслевая 1С – она такая.
А у нас остался один вопрос, да и тот – философский. Пробовали ли они сами по своей документации и по своей поддержке реализовать интеграцию? И видя поток обращений в поддержку не кажется ли им, что что-то у них не так?
1😢25❤6👍2🤮1🤣1
Про ТС ПИоТ
Просили тут написать про ТС ПИоТ, поэтому пишем. Все сказанное ниже является исключительно частным мнением и не претендует на истину в последней инстанции.
Но начнем немного издалека. Любой хороший админ или внедренец знает, что любое изменение или решает какие-то проблемы системы или добавляет ей новую функциональность. Либо и то и другое сразу.
Это язык понятный бизнесу и именно за это бизнес платит деньги, если вы предложите изменение, основной смысл которого в розовых котиках – вас пошлют лесом и денег не дадут.
Система маркировки – не исключение, несмотря на отдельные перекосы и технические проблемы все предыдущие действия и нововведения были разумны и рациональны.
Как помним, начиналось все с уведомительного режима в самом простом его варианте, марка просто считывалась на кассе в чек, если марка валидна – все хорошо. Никаких проверок марки не происходило.
Потом добавили проверку ОИСМ при помощи кассы и ОФД, это те самые буквы [M], но такая проверка была, во-первых, не быстрой, а во-вторых, не давала понимания причины отказа. Поэтому такую марку можно было продать при согласии покупателя.
Далее в ход пошли онлайн-проверки разрешительного режима (РР), теперь система уже принимала окончательное решение, либо с маркой все хорошо и ее продать можно, или нельзя, с указанием причины запрета.
Попутно осуществлялся переход с объемно-сортового учета (ОСУ), на поэкземплярный, когда каждую марку стало возможно отследить в онлайн режиме от производителя и до прилавка.
В завершение это все дополнили локальным модулем, который в случае невозможности выполнить онлайн проверку выполнял проверку марки локально, по внутреннему «черному списку» и либо давал решение на продажу, либо запрещал ее.
Плохо ли, хорошо, но эта система как-то работала, рынок приспособился, адаптировался и принял новые правила игры.
Сама система в данном виде серьезных изъянов не имеет и поставленные задачи достаточно эффективно решает, особенно с переходом на поэкземплярный учет.
Но осенью прошлого года как снег на голову свалился тот самый ТС ПИоТ, процитируем официальный источник:
Ага, а до этого официальный API Честного знака не был единым, стандартизированным и сертифицированным?
И что значит «сам решал, как проверять»? Способ был для всех один – РР или ЛМ при отсутствии ответа онлайн.
Что поменяется с приходом ПИоТ? Ничего, совсем ничего, просто API РР заменится на API ПИоТ, больше ничего в логике торгового приложения не изменится.
А все его заявленные «достоинства», скажем честно, притянуты за уши. Никаких насущных проблем Розницы ПИоТ не решает, никаких новых возможностей не предоставляет, ни участникам рынка, ни самой системе.
Возможно, именно поэтому ПИоТ оказался не готов в срок, который потом несколько раз переносили, потому что разработчики этого недоразумения сами не понимали, что он должен делать и как.
Зато это не бесплатно, от 5 000 рублей в год, умножьте на количество касс в стране, ну да, неплохой профит на ровном месте, можно сказать из воздуха.
Ну а что, сели государевы мужи, посмотрели, подумали. Работает маркировка, плохо, хорошо, но работает, поставленные задачи решает. А потом вдруг хлопнули себя по лбу, мол как же так, братцы, а почему это все бесплатно???
Поэтому на текущий момент ни бизнес, ни обслуживающие организации ставить ПИоТ не спешат, просто не видят смысла, с учетом его сырости и отвратительной работы по немногочисленным отзывам.
Какая-то ясность появится уже в июне, когда будет понятно, перенесут еще раз сроки или нет.
Просили тут написать про ТС ПИоТ, поэтому пишем. Все сказанное ниже является исключительно частным мнением и не претендует на истину в последней инстанции.
Но начнем немного издалека. Любой хороший админ или внедренец знает, что любое изменение или решает какие-то проблемы системы или добавляет ей новую функциональность. Либо и то и другое сразу.
Это язык понятный бизнесу и именно за это бизнес платит деньги, если вы предложите изменение, основной смысл которого в розовых котиках – вас пошлют лесом и денег не дадут.
Система маркировки – не исключение, несмотря на отдельные перекосы и технические проблемы все предыдущие действия и нововведения были разумны и рациональны.
Как помним, начиналось все с уведомительного режима в самом простом его варианте, марка просто считывалась на кассе в чек, если марка валидна – все хорошо. Никаких проверок марки не происходило.
Потом добавили проверку ОИСМ при помощи кассы и ОФД, это те самые буквы [M], но такая проверка была, во-первых, не быстрой, а во-вторых, не давала понимания причины отказа. Поэтому такую марку можно было продать при согласии покупателя.
Далее в ход пошли онлайн-проверки разрешительного режима (РР), теперь система уже принимала окончательное решение, либо с маркой все хорошо и ее продать можно, или нельзя, с указанием причины запрета.
Попутно осуществлялся переход с объемно-сортового учета (ОСУ), на поэкземплярный, когда каждую марку стало возможно отследить в онлайн режиме от производителя и до прилавка.
В завершение это все дополнили локальным модулем, который в случае невозможности выполнить онлайн проверку выполнял проверку марки локально, по внутреннему «черному списку» и либо давал решение на продажу, либо запрещал ее.
Плохо ли, хорошо, но эта система как-то работала, рынок приспособился, адаптировался и принял новые правила игры.
Сама система в данном виде серьезных изъянов не имеет и поставленные задачи достаточно эффективно решает, особенно с переходом на поэкземплярный учет.
Но осенью прошлого года как снег на голову свалился тот самый ТС ПИоТ, процитируем официальный источник:
ТС ПИоТ — это Техническое Средство получения Информации о товаре.
С 28 декабря 2025 года оно обязательно для всех, кто продаёт маркированные товары через кассу.
Зачем оно нужно?
Раньше каждый поставщик ПО сам решал, как проверять коды маркировки. Это приводило к ошибкам, потере данных и даже продаже поддельных товаров.
ТС ПИоТ — это единый, стандартизированный и сертифицированный способ взаимодействия с системой «Честный знак».
Ага, а до этого официальный API Честного знака не был единым, стандартизированным и сертифицированным?
И что значит «сам решал, как проверять»? Способ был для всех один – РР или ЛМ при отсутствии ответа онлайн.
Что поменяется с приходом ПИоТ? Ничего, совсем ничего, просто API РР заменится на API ПИоТ, больше ничего в логике торгового приложения не изменится.
А все его заявленные «достоинства», скажем честно, притянуты за уши. Никаких насущных проблем Розницы ПИоТ не решает, никаких новых возможностей не предоставляет, ни участникам рынка, ни самой системе.
Возможно, именно поэтому ПИоТ оказался не готов в срок, который потом несколько раз переносили, потому что разработчики этого недоразумения сами не понимали, что он должен делать и как.
Зато это не бесплатно, от 5 000 рублей в год, умножьте на количество касс в стране, ну да, неплохой профит на ровном месте, можно сказать из воздуха.
Ну а что, сели государевы мужи, посмотрели, подумали. Работает маркировка, плохо, хорошо, но работает, поставленные задачи решает. А потом вдруг хлопнули себя по лбу, мол как же так, братцы, а почему это все бесплатно???
Поэтому на текущий момент ни бизнес, ни обслуживающие организации ставить ПИоТ не спешат, просто не видят смысла, с учетом его сырости и отвратительной работы по немногочисленным отзывам.
Какая-то ясность появится уже в июне, когда будет понятно, перенесут еще раз сроки или нет.
🔥15❤4😢4🤝3🥱1
🗝 Про "замочек" на базе 1С:Предприятие
Очередной раз сталкиваемся с тем, что и пользователи, и обслуживающий персонал не придают особого значения нахождения конфигурации на поддержке.
Визуально это отображается в виде замка и иногда говорят, что конфигурация "на замочке".
Обычно "замочек" снимают для доработок. Но с этим получают ряд сопутствующих осложнений.
📐 Во-первых, вырастет размер базы. В базе на поддержке две конфигурации: основная и БД. В снятой с поддержки три: основная, поставщика и БД.
⏱ Во-вторых, резко увеличивается время на обновление, так как вместо того, чтобы просто загрузить изменения база всегда будет делать сравнение и объединение.
☝️Поэтому не стоит снимать базу с поддержки без крайней на то необходимости. Для доработки используйте внешние отчеты и обработки, а для более сложных вещей есть расширения.
🤔 Если "замочек" с базы снят, то для того, чтобы вернуть его снимите базу с поддержки и загрузите в нее CF того же релиза или более старшего, на который доступно обновление.
Очередной раз сталкиваемся с тем, что и пользователи, и обслуживающий персонал не придают особого значения нахождения конфигурации на поддержке.
Визуально это отображается в виде замка и иногда говорят, что конфигурация "на замочке".
Обычно "замочек" снимают для доработок. Но с этим получают ряд сопутствующих осложнений.
📐 Во-первых, вырастет размер базы. В базе на поддержке две конфигурации: основная и БД. В снятой с поддержки три: основная, поставщика и БД.
⏱ Во-вторых, резко увеличивается время на обновление, так как вместо того, чтобы просто загрузить изменения база всегда будет делать сравнение и объединение.
☝️Поэтому не стоит снимать базу с поддержки без крайней на то необходимости. Для доработки используйте внешние отчеты и обработки, а для более сложных вещей есть расширения.
🤔 Если "замочек" с базы снят, то для того, чтобы вернуть его снимите базу с поддержки и загрузите в нее CF того же релиза или более старшего, на который доступно обновление.
👍12🥱2