Как я внедрял систему учета обращений на бумажном носителе
Я уже рассказывал на данном канале истории из далекой молодости, когда я сразу после окончания высшего учебного заведения попал на работу в сельскохозяйственный НИИ на должность инженера.
Первоначально там предполагались задачи администратора, но постепенно на меня скинули все обязанности типового инженера данной конторы вплоть до газовых баллонов, пневматики и всего такого разного.
Сия организация была бюджетной и руководил ей бывший партийный начальник областного уровня, славный в свое время «подвигами», о которых из уст в уста передавались «легенды».
Контингент той конторы был преимущественно предпенсионного возраста, а «молодежь» были те, кому за тридцать. Ну и я со своими 20 с небольшим числился там за «юношу».
Очень скоро я познал… нет, не дзен, а суровую реальность бюджетной конторы – если можно не работать, то работать не нужно, а ответственность всегда можно спихнуть на кого-то другого.
В результате на собраниях по утрам меня часто вызывали на ковер к директору, потому что какой-то отдел чего-то там вовремя не сделал, а причиной назвал неисправность оборудования.
А дальше был примерно следующий диалог:
- Товарищ инженер, ну что это за дела?
- Товарищ директор, первый раз сейчас слышу.
- А мы тебе говорили!!!
- Когда?
- Когда ты баллон менял в понедельник!!!
- Не было такого!
- Было!!!
- Не было!
- Ты гляди, он еще и огрызается! Я тут 100500 лет работаю, а он без году неделя!!!
В результате подобные совещания заканчивались далеко не в мою пользу и получалось что инженер нефига не делает и вообще крайний.
Понятно, что такое положение дел мне не нравилось. Поэтому я взял толстую тетрадку, разлинеил ее и каждое утро, через полчаса после начала рабочего дня начал делать обход.
Я с этой тетрадкой заходил в каждый кабинет и спрашивал – есть ли вопросы по технике или нарекания. Нет? Отмечал в тетрадке: кабинет – прибор – наличие или отсутствие вопросов, дату и время.
Все обращения записывал туда-же. Дату и время обращения, его суть, коротко причину и принятые меры и время завершения. Или объективную невозможность завершить работы, например, нужно купить запасные части.
Со временем одна тетрадка превратилась во две. Одну я назвал «Журнал учета состояния техники», вторую «Журнал учета обращений». С одной делал обход, в другой фиксировал все заявки.
И потом на подобных совещаниях я просто приходил с тетрадками, открывал их и говорил, что обращений не получал, а если получал, то исправил тогда-то и тогда-то, либо не исправил по объективным причинам, так как…
Вся эта система была выстроена мною где-то за полгода, ну да когда получаешь отнюдь не пряники на каждом совещании – думать и шевелиться начнешь.
А потом она прижилась и тихо стала официальной, теперь уже не только я вел эту тетрадку, но и каждый отдел и расписывались в ней обе стороны.
Я проработал в этом НИИ ровно два года, но эта система осталась там надолго и уже лет через 10-15 при общении с бывшими коллегами я узнавал, что система обходов и журналов там до сих про живее всех живых.
Я уже рассказывал на данном канале истории из далекой молодости, когда я сразу после окончания высшего учебного заведения попал на работу в сельскохозяйственный НИИ на должность инженера.
Первоначально там предполагались задачи администратора, но постепенно на меня скинули все обязанности типового инженера данной конторы вплоть до газовых баллонов, пневматики и всего такого разного.
Сия организация была бюджетной и руководил ей бывший партийный начальник областного уровня, славный в свое время «подвигами», о которых из уст в уста передавались «легенды».
Контингент той конторы был преимущественно предпенсионного возраста, а «молодежь» были те, кому за тридцать. Ну и я со своими 20 с небольшим числился там за «юношу».
Очень скоро я познал… нет, не дзен, а суровую реальность бюджетной конторы – если можно не работать, то работать не нужно, а ответственность всегда можно спихнуть на кого-то другого.
В результате на собраниях по утрам меня часто вызывали на ковер к директору, потому что какой-то отдел чего-то там вовремя не сделал, а причиной назвал неисправность оборудования.
А дальше был примерно следующий диалог:
- Товарищ инженер, ну что это за дела?
- Товарищ директор, первый раз сейчас слышу.
- А мы тебе говорили!!!
- Когда?
- Когда ты баллон менял в понедельник!!!
- Не было такого!
- Было!!!
- Не было!
- Ты гляди, он еще и огрызается! Я тут 100500 лет работаю, а он без году неделя!!!
В результате подобные совещания заканчивались далеко не в мою пользу и получалось что инженер нефига не делает и вообще крайний.
Понятно, что такое положение дел мне не нравилось. Поэтому я взял толстую тетрадку, разлинеил ее и каждое утро, через полчаса после начала рабочего дня начал делать обход.
Я с этой тетрадкой заходил в каждый кабинет и спрашивал – есть ли вопросы по технике или нарекания. Нет? Отмечал в тетрадке: кабинет – прибор – наличие или отсутствие вопросов, дату и время.
Все обращения записывал туда-же. Дату и время обращения, его суть, коротко причину и принятые меры и время завершения. Или объективную невозможность завершить работы, например, нужно купить запасные части.
Со временем одна тетрадка превратилась во две. Одну я назвал «Журнал учета состояния техники», вторую «Журнал учета обращений». С одной делал обход, в другой фиксировал все заявки.
И потом на подобных совещаниях я просто приходил с тетрадками, открывал их и говорил, что обращений не получал, а если получал, то исправил тогда-то и тогда-то, либо не исправил по объективным причинам, так как…
Вся эта система была выстроена мною где-то за полгода, ну да когда получаешь отнюдь не пряники на каждом совещании – думать и шевелиться начнешь.
А потом она прижилась и тихо стала официальной, теперь уже не только я вел эту тетрадку, но и каждый отдел и расписывались в ней обе стороны.
Я проработал в этом НИИ ровно два года, но эта система осталась там надолго и уже лет через 10-15 при общении с бывшими коллегами я узнавал, что система обходов и журналов там до сих про живее всех живых.
👍64🔥21😁18❤2
Про нетехнические особенности работы в бюджетной сфере
В обсуждениях вчера снова возник интересный вопрос, который очень характерен для бюджетной сферы и нынешних госов. Но также может касаться и крупного бизнеса, который действует по аналогичной схеме.
А называется это освоением бюджетов. Общий смысл такой, что на год, полгода, квартал или месяц формируются бюджеты и выделяется целевое финансирование. Если ты его запросил – то должен потратить. Иначе ты работаешь неэффективно и в следующий раз тебе столько не дадут.
При этом финансирование целевое и ты не можешь статью на сайт потратить на картриджи, а деньги на картриджи для покупки сгоревшего коммутатора.
В целом такая система достаточно грамотная и позволяет эффективно планировать ресурсы предприятия, когда отделы заранее подают заявки на финансирование, но в бюджетке все, как всегда. А как известно, даже самую здравую идею всегда можно довести до абсурда.
Степень абсурда разнится от конторы к конторе, но общий смысл действующего подхода такой: если вы не освоили бюджет, то больше вам столько денег не дадут. И там хоть трава не расти.
А как планировать? Хорошо если можно расписать помесячно и запросить в какой-то месяц побольше, в какой-то поменьше и перераспределить общий бюджет между статьями. А когда нет?
Ну и случиться на протяжении бюджетного периода может всякое, на это тоже надо заложиться. В общем принцип там следующий – проси больше, получишь сколько надо.
А потом получается, что деньги к концу бюджетного периода остались и их срочно надо куда-то потратить. А куда? Ну давайте купим что-нибудь нужное, или не совсем нужное, или совсем ненужное.
Хорошо если это железо, можно закупиться впрок и даже можно у поставщика его забрать только через полгода, после неоднократных напоминаний.
Это приводит к тому, что в отдельных конторах могут накапливаться штабеля нового железа, в заводской упаковке, которое никому не нужно. Почему не нужно? Да потому что под новые проекты берутся новые железки, потому что там тоже бюджет и его тоже надо осваивать.
При этом подобные вещи могут самым чудесным образом сосуществовать с полными дровами у пользователей, которые продолжают работать на древних тормозных ПК, просто потому что на его обновление не выделен бюджет. А зачем, работает ведь.
Но… Но там совсем другое дело, там же цифровизация, импортозамещение и всякие разные программы, начиная от федеральных и за них надо отчитывается, поэтому туда бюджеты находятся.
А если ты скажешь, что есть у нас на складе и сервера и все и остальное, давайте на эти деньги обновим ПК сотрудникам, то тебе быстро и доходчиво объяснят – что это нецелевое расходование бюджетных средств и за это может даже быть «садись кибитка – тюрьма поехали».
Но это еще половина беды, практически везде к этой крайне неэффективной практике добавляется личный фактор, который сводится к такому широко известному в узких кругах слову как откат.
Случайных людей в поставщиках или подрядчиках у бюджетки нет, там все свои. То, что можно протащить без торгов – протаскивается так. Что нельзя – конкурсное задание составляется так, чтобы выиграть его гарантированно мог только один, свой, поставщик.
А дальше представители поставщика и заказчика садятся вместе в тихом укромном месте и решают, как и на что они будут пилить бюджет и сколько из бюджетных денег… ну в общем вы поняли. Зарплаты в бюджетке невысокие, а жене надо новую шубу, себе новый авто, летом на юга и т.д. и т.п.
А дальше все зависит от наглости и ловкости, причем эта схема в бюджете поголовно. Да, кого-то ловят и иногда сажают, но в большинстве товарищи годами сидят на теплых местах и осваивают бюджеты.
Отсюда и возникают такие задачи: а давайте… давайте… давайте… внедрим что-нибудь такое, где и железа купить можно и услуг написать побольше…
Внедрили, освоили, разделили. А что нам теперь с этим делать? Да ничего, задвиньте на дальнюю стойку, пусть стоит, небо коптит. Деньги освоили, наверх красиво отчитались. Надо думать как дальше бюджет осваивать, а не эти ваши Заббиксы и Вики.
В обсуждениях вчера снова возник интересный вопрос, который очень характерен для бюджетной сферы и нынешних госов. Но также может касаться и крупного бизнеса, который действует по аналогичной схеме.
А называется это освоением бюджетов. Общий смысл такой, что на год, полгода, квартал или месяц формируются бюджеты и выделяется целевое финансирование. Если ты его запросил – то должен потратить. Иначе ты работаешь неэффективно и в следующий раз тебе столько не дадут.
При этом финансирование целевое и ты не можешь статью на сайт потратить на картриджи, а деньги на картриджи для покупки сгоревшего коммутатора.
В целом такая система достаточно грамотная и позволяет эффективно планировать ресурсы предприятия, когда отделы заранее подают заявки на финансирование, но в бюджетке все, как всегда. А как известно, даже самую здравую идею всегда можно довести до абсурда.
Степень абсурда разнится от конторы к конторе, но общий смысл действующего подхода такой: если вы не освоили бюджет, то больше вам столько денег не дадут. И там хоть трава не расти.
А как планировать? Хорошо если можно расписать помесячно и запросить в какой-то месяц побольше, в какой-то поменьше и перераспределить общий бюджет между статьями. А когда нет?
Ну и случиться на протяжении бюджетного периода может всякое, на это тоже надо заложиться. В общем принцип там следующий – проси больше, получишь сколько надо.
А потом получается, что деньги к концу бюджетного периода остались и их срочно надо куда-то потратить. А куда? Ну давайте купим что-нибудь нужное, или не совсем нужное, или совсем ненужное.
Хорошо если это железо, можно закупиться впрок и даже можно у поставщика его забрать только через полгода, после неоднократных напоминаний.
Это приводит к тому, что в отдельных конторах могут накапливаться штабеля нового железа, в заводской упаковке, которое никому не нужно. Почему не нужно? Да потому что под новые проекты берутся новые железки, потому что там тоже бюджет и его тоже надо осваивать.
При этом подобные вещи могут самым чудесным образом сосуществовать с полными дровами у пользователей, которые продолжают работать на древних тормозных ПК, просто потому что на его обновление не выделен бюджет. А зачем, работает ведь.
Но… Но там совсем другое дело, там же цифровизация, импортозамещение и всякие разные программы, начиная от федеральных и за них надо отчитывается, поэтому туда бюджеты находятся.
А если ты скажешь, что есть у нас на складе и сервера и все и остальное, давайте на эти деньги обновим ПК сотрудникам, то тебе быстро и доходчиво объяснят – что это нецелевое расходование бюджетных средств и за это может даже быть «садись кибитка – тюрьма поехали».
Но это еще половина беды, практически везде к этой крайне неэффективной практике добавляется личный фактор, который сводится к такому широко известному в узких кругах слову как откат.
Случайных людей в поставщиках или подрядчиках у бюджетки нет, там все свои. То, что можно протащить без торгов – протаскивается так. Что нельзя – конкурсное задание составляется так, чтобы выиграть его гарантированно мог только один, свой, поставщик.
А дальше представители поставщика и заказчика садятся вместе в тихом укромном месте и решают, как и на что они будут пилить бюджет и сколько из бюджетных денег… ну в общем вы поняли. Зарплаты в бюджетке невысокие, а жене надо новую шубу, себе новый авто, летом на юга и т.д. и т.п.
А дальше все зависит от наглости и ловкости, причем эта схема в бюджете поголовно. Да, кого-то ловят и иногда сажают, но в большинстве товарищи годами сидят на теплых местах и осваивают бюджеты.
Отсюда и возникают такие задачи: а давайте… давайте… давайте… внедрим что-нибудь такое, где и железа купить можно и услуг написать побольше…
Внедрили, освоили, разделили. А что нам теперь с этим делать? Да ничего, задвиньте на дальнюю стойку, пусть стоит, небо коптит. Деньги освоили, наверх красиво отчитались. Надо думать как дальше бюджет осваивать, а не эти ваши Заббиксы и Вики.
👍55🔥12🥱6💯4
Универсальные инструменты 1С для управляемых форм
Несколько дней назад обнаружили интересный и полезный проект для всех, кто связан с 1С. Данный инструмент содержит самые необходимые обработки для разработчика, администратора или опытного пользователя 1С. Причем большинство обработок в наборе предназначены именно последним.
Инструменты распространяются в виде файла конфигурации, расширения или в портативном варианте в виде внешней обработки.
В целом ничего сверхъестественного там нет, многие из включенных в комплект обработок можно найти на Инфостарте, но здесь все это собрано в одном месте, проверено и доработано.
Что важно, все инструменты работают как под Windows, так и под Linux, а это важно, например, популярная стандартная обработка Выгрузка загрука XML без доработки с Linux серверами не работает. И таких моментов много. А так как основной парк серверов 1С у нас на Linux, то мы по достоинству оценили этот момент.
✅ https://github.com/cpr1c/tools_ui_1c
Несколько дней назад обнаружили интересный и полезный проект для всех, кто связан с 1С. Данный инструмент содержит самые необходимые обработки для разработчика, администратора или опытного пользователя 1С. Причем большинство обработок в наборе предназначены именно последним.
Инструменты распространяются в виде файла конфигурации, расширения или в портативном варианте в виде внешней обработки.
В целом ничего сверхъестественного там нет, многие из включенных в комплект обработок можно найти на Инфостарте, но здесь все это собрано в одном месте, проверено и доработано.
Что важно, все инструменты работают как под Windows, так и под Linux, а это важно, например, популярная стандартная обработка Выгрузка загрука XML без доработки с Linux серверами не работает. И таких моментов много. А так как основной парк серверов 1С у нас на Linux, то мы по достоинству оценили этот момент.
✅ https://github.com/cpr1c/tools_ui_1c
👍48
Как поставить в отраслевую конфигурацию 1С:Предприятие патчи от родительской конфигурации.
Отраслевые конфигурации 1С рассказ отдельный и бесконечно грустный. Многие из тех, кто столкнулись с этим разделом «творчества» предпочтут во множестве ситуаций дорабатывать и сопровождать типовые самостоятельно, нежели еще раз связываться с отраслевыми.
При том что отраслевые сильно дороже, как по стоимости прикладного решения, так и по сопровождению, где-то так раза в два. Казалось бы, вместе с готовыми доработками для отрасли логично получать и своевременную поддержку, хотя бы в виде своевременного исправления ошибок и выпуска исправлений.
На деле же пользователь отраслевой часто получает кучу проблем на ровном месте и полное безразличие со стороны вендора, включая никакую поддержку. Да и сам состав решений очень часто вызывает недоумение, создавая впечатление что разработчики знакомились с отраслью по книжкам для профориентации младших начальных классов.
Чтобы не быть голословными перейдем к 1С:Розница 8. Салон оптики. Это конфигурация на базе типовой 1С:Розница 8 от компании Рарус, у нее там целая линейка подобного творчества на все случаи жизни.
А теперь сравним:
🔹 1С:Розница 8 ПРОФ. Электронная поставка – 17 600 руб.
🔹1С:Розница 8. Салон оптики. Электронная поставка – 31 100 руб.
Для поддержки вам потребуется не только ИТС, но еще и КП отраслевой 2 категории (тарифы на 12 месяцев):
🔹 1С:ИТС Техно – 21 204 руб.
🔹 1С:КП Отраслевой Базовый 2-я Категория – 27 800 руб.
Логично предположить, что за эти деньги покупатель должен получить некоторую дополнительную ценность. Но увы. Мы не будем разбирать состав конкретных отраслевых, а сосредоточимся на поддержке, которая идет отдельной строкой и стоит дороже подписки ИТС.
Итак, на руках у нас имеется обновление 1С:Розница 8. Салон оптики 2.3.21.29 от 25.12.24 (типовая с таким же номером выпущена 12.12.24), т.е. временной лаг между ними где-то две недели.
Данный релиз еще на уровне типовой имеет ряд ошибок, некоторые из них достаточно критичные, например, EF_00_00691163 (патч выпущен 25.12.2024):
▫️ В организации с применением УНС 5%(7%) товары с установленной ставкой: без НДС и НДС0% пробиваются в чек со ставкой 5%(7%).
Ошибка для большинства клиник критичная, так как медицинские услуги оказываемые в рамках медицинской лицензии НДС не облагаются, даже если компания применяет ставки 5/7 % НДС.
И что вы думаете в отраслевой? За которую заказчик отдельно платит вдвое более дорогую поддержку?
А ничего 🍌🍌🍌, фирма Рарус считает, что исправления ошибок для релиза 2.3.21.29 не требуются, в то время как фирма 1С выпустила для типовой 1С:Розница указанного релиза 51 патч.
Можно, конечно, подождать следующего релиза, в котором эти ошибки (возможно) исправят, а новых, неизбежно добавят. Но это не дело, по факту мы получаем сырой и недоработанный продукт и находимся в заведомо более худшей ситуации, чем пользователи типовой.
Как быть? Известно, что спасение утопающих – дело рук самих утопающих, поэтому было принято решение попробовать использовать официальные патчи от типовой конфигурации.
Но если попробовать их загрузить в лоб, в виде архива, то программа откажется их принимать, потому что патчи «не той системы». Поэтому распакуем архив, в котором будет файл расширения и манифест.
Манифест выбрасываем, а расширение устанавливаем стандартным способом через форму работы с расширениями, при этом конфигурация распознает в расширении патч и устанавливает его именно как патч. И в последствии вы будете видеть его в списке исправлений, а не расширений.
Насколько это легально? Скажем честно – не особо, если вы не имеете правомерного доступа к типовой Рознице (т.е. нет купленной конфигурации). Но, с другой стороны, вы платите за поддержку и поддержки не получаете. Поэтому определенное моральное право так поступать имеете. А дальше каждый решает сам.
Если доступ к патчам является критичным, то приобрести лицензию на 1С:Розница 8 ПРОФ будет меньшим из зол, все остальные нужные подписки у вас уже есть.
Отраслевые конфигурации 1С рассказ отдельный и бесконечно грустный. Многие из тех, кто столкнулись с этим разделом «творчества» предпочтут во множестве ситуаций дорабатывать и сопровождать типовые самостоятельно, нежели еще раз связываться с отраслевыми.
При том что отраслевые сильно дороже, как по стоимости прикладного решения, так и по сопровождению, где-то так раза в два. Казалось бы, вместе с готовыми доработками для отрасли логично получать и своевременную поддержку, хотя бы в виде своевременного исправления ошибок и выпуска исправлений.
На деле же пользователь отраслевой часто получает кучу проблем на ровном месте и полное безразличие со стороны вендора, включая никакую поддержку. Да и сам состав решений очень часто вызывает недоумение, создавая впечатление что разработчики знакомились с отраслью по книжкам для профориентации младших начальных классов.
Чтобы не быть голословными перейдем к 1С:Розница 8. Салон оптики. Это конфигурация на базе типовой 1С:Розница 8 от компании Рарус, у нее там целая линейка подобного творчества на все случаи жизни.
А теперь сравним:
🔹 1С:Розница 8 ПРОФ. Электронная поставка – 17 600 руб.
🔹1С:Розница 8. Салон оптики. Электронная поставка – 31 100 руб.
Для поддержки вам потребуется не только ИТС, но еще и КП отраслевой 2 категории (тарифы на 12 месяцев):
🔹 1С:ИТС Техно – 21 204 руб.
🔹 1С:КП Отраслевой Базовый 2-я Категория – 27 800 руб.
Логично предположить, что за эти деньги покупатель должен получить некоторую дополнительную ценность. Но увы. Мы не будем разбирать состав конкретных отраслевых, а сосредоточимся на поддержке, которая идет отдельной строкой и стоит дороже подписки ИТС.
Итак, на руках у нас имеется обновление 1С:Розница 8. Салон оптики 2.3.21.29 от 25.12.24 (типовая с таким же номером выпущена 12.12.24), т.е. временной лаг между ними где-то две недели.
Данный релиз еще на уровне типовой имеет ряд ошибок, некоторые из них достаточно критичные, например, EF_00_00691163 (патч выпущен 25.12.2024):
▫️ В организации с применением УНС 5%(7%) товары с установленной ставкой: без НДС и НДС0% пробиваются в чек со ставкой 5%(7%).
Ошибка для большинства клиник критичная, так как медицинские услуги оказываемые в рамках медицинской лицензии НДС не облагаются, даже если компания применяет ставки 5/7 % НДС.
И что вы думаете в отраслевой? За которую заказчик отдельно платит вдвое более дорогую поддержку?
А ничего 🍌🍌🍌, фирма Рарус считает, что исправления ошибок для релиза 2.3.21.29 не требуются, в то время как фирма 1С выпустила для типовой 1С:Розница указанного релиза 51 патч.
Можно, конечно, подождать следующего релиза, в котором эти ошибки (возможно) исправят, а новых, неизбежно добавят. Но это не дело, по факту мы получаем сырой и недоработанный продукт и находимся в заведомо более худшей ситуации, чем пользователи типовой.
Как быть? Известно, что спасение утопающих – дело рук самих утопающих, поэтому было принято решение попробовать использовать официальные патчи от типовой конфигурации.
Но если попробовать их загрузить в лоб, в виде архива, то программа откажется их принимать, потому что патчи «не той системы». Поэтому распакуем архив, в котором будет файл расширения и манифест.
Манифест выбрасываем, а расширение устанавливаем стандартным способом через форму работы с расширениями, при этом конфигурация распознает в расширении патч и устанавливает его именно как патч. И в последствии вы будете видеть его в списке исправлений, а не расширений.
Насколько это легально? Скажем честно – не особо, если вы не имеете правомерного доступа к типовой Рознице (т.е. нет купленной конфигурации). Но, с другой стороны, вы платите за поддержку и поддержки не получаете. Поэтому определенное моральное право так поступать имеете. А дальше каждый решает сам.
Если доступ к патчам является критичным, то приобрести лицензию на 1С:Розница 8 ПРОФ будет меньшим из зол, все остальные нужные подписки у вас уже есть.
👍30😢4❤2
Подписывание SMB-пакетов в Samba
В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.
SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.
Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.
В Linux также не трудно настроить подписывание пакетов, для этого в секции
Для сервера это
▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
По умолчанию применяется значение disabled.
Для клиента используется опция
▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
Значение по умолчанию: auto.
В современных условиях оптимальными настройками будет изменение режима сервера также на auto:
Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.
В этом плане Samba позволяет более гибко управлять настройками чем SMB в Windows, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.
В нашей предыдущей заметке мы говорили о подписывании SMB пакетов в Windows.
SMB Signing это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью. Это позволяет предотвратить реализацию SMB атак типа MitM и NTLM relay.
Начиная с Windows 11 24H2 клиент будет требовать обязательного подписывания пакетов, в дальнейшем эту политику обещают распространить на все поддерживаемые ОС.
В Linux также не трудно настроить подписывание пакетов, для этого в секции
[global] файла smb.conf потребуется указать две опции.Для сервера это
server signing, которая может принимать следующие значения:▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
По умолчанию применяется значение disabled.
Для клиента используется опция
client signing с доступными значениями:▫️ auto - подписывание SMB предлагается
▫️ mandatory - подписывание SMB обязательно
▫️ disabled - подписывание SMB отключено
Значение по умолчанию: auto.
В современных условиях оптимальными настройками будет изменение режима сервера также на auto:
[global]
server signing = auto
Это позволит работать с современными клиентами, не снижая уровня защиты, но при этом сохраняя совместимость с клиентами не поддерживающими подписывание.
В этом плане Samba позволяет более гибко управлять настройками чем SMB в Windows, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.
👍32
Подборка актуальных материалов по Samba
▫️ Настройка файлового сервера Samba на платформе Debian / Ubuntu
▫️ Настраиваем антивирусную защиту в реальном времени на основе ClamAV On Access Scanning
▫️ Исправляем ошибку подключения Windows к общим ресурсам на сервере Samba Linux
▫️ Включаем отображение Samba-сервера в сетевом окружении Windows
▫️ Настройка файлового сервера ksmbd на платформе Debian / Ubuntu
▫️ Монтирование файловых систем при помощи systemd
▫️ Настройка файлового сервера Samba на платформе Debian / Ubuntu
▫️ Настраиваем антивирусную защиту в реальном времени на основе ClamAV On Access Scanning
▫️ Исправляем ошибку подключения Windows к общим ресурсам на сервере Samba Linux
▫️ Включаем отображение Samba-сервера в сетевом окружении Windows
▫️ Настройка файлового сервера ksmbd на платформе Debian / Ubuntu
▫️ Монтирование файловых систем при помощи systemd
👍41❤2
Самый лёгкий способ попасть в Kubernetes
«Лаборатория Числитель» представила «Штурвал CE» — полнофункциональную community-версию платформы для управления кластерами K8s.
«Штурвал» уже стоит во многих крупных компаниях, а теперь его может поставить каждый.
Лицензионный ключ для установки community-версии придет после заполнения формы на сайте.
А вот тут чат с разрабами, вопросы можно туда.
«Лаборатория Числитель» представила «Штурвал CE» — полнофункциональную community-версию платформы для управления кластерами K8s.
«Штурвал» уже стоит во многих крупных компаниях, а теперь его может поставить каждый.
Лицензионный ключ для установки community-версии придет после заполнения формы на сайте.
А вот тут чат с разрабами, вопросы можно туда.
👍3🔥3❤1
В очередной рассылке Let’s Encrypt уведомила о грядущем прекращении рассылки с напоминанием об окончании срока действия сертификата:
В этом же письме они рекомендовали к использованию сторонний сервис для мониторинга сертификатов: https://redsift.com/pulse-platform/certificates-lite
Сервис достаточно функциональный и позволяет в бесплатной версии наблюдать до 250 сертификатов, что более чем достаточно как для личных, так и для корпоративных нужд.
Но есть ложка дегтя – на территории РФ сервис недоступен, через туннель все работает, проблем с добавлением доменов в зоне RU нет, равно как и получение уведомлений на отечественные почтовые службы.
Кому лень регистрироваться – можно войти через Google или Microsoft.
Мы сообщаем вам, что намерены прекратить рассылку электронных писем с уведомлениями об истечении срока действия. Вы можете узнать больше в этом сообщении в блоге. В ближайшие месяцы вы снова получите это электронное письмо с напоминанием.
В этом же письме они рекомендовали к использованию сторонний сервис для мониторинга сертификатов: https://redsift.com/pulse-platform/certificates-lite
Сервис достаточно функциональный и позволяет в бесплатной версии наблюдать до 250 сертификатов, что более чем достаточно как для личных, так и для корпоративных нужд.
Но есть ложка дегтя – на территории РФ сервис недоступен, через туннель все работает, проблем с добавлением доменов в зоне RU нет, равно как и получение уведомлений на отечественные почтовые службы.
Кому лень регистрироваться – можно войти через Google или Microsoft.
👍22🔥4🤔3👌2
По мотивам реальных событий.
▫️ Вася решил мониторить температуру произвольных устройств.
▫️ Вася решил использовать для этого sensors
▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:
👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.
❓Что не так сделал Вася?
▫️ Вася решил мониторить температуру произвольных устройств.
▫️ Вася решил использовать для этого sensors
▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:
UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'
UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'👉 Некоторое время все было хорошо, потом метрики стали показывать погоду на Марсе.
❓Что не так сделал Вася?
👍5
В чем был не прав Вася?
Итак, давайте разберем творчество нашего Васи и поймем в чем он был не прав. Для этого сначала нам нужно понять, что делает его заклинание.
▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.
▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.
▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.
▫️ Затем это все передается команде awk, где и происходит основная магия.
🔹
🔹
🔹
👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.
Вам достаточно поменять что угодно в аппаратной конфигурации, чтобы изменить набор сенсоров и порядок, и количество строк сразу же поплывут. И на месте третьей и восьмой строки может оказаться все что угодно.
Поэтому не следует парсить любой вывод или файл опираясь только лишь на номера строк, это абсолютно ненадежно.
Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:
Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:
Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:
И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:
Теперь у нас при любых изменениях количества и порядка строк будет выводиться правильная информация. Либо перестанет выводиться вообще, если такой сенсор пропадет. Но погоды на Марсе уже не будет.
Итак, давайте разберем творчество нашего Васи и поймем в чем он был не прав. Для этого сначала нам нужно понять, что делает его заклинание.
▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.
▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.
▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.
▫️ Затем это все передается команде awk, где и происходит основная магия.
🔹
-F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.🔹
{avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.🔹
END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.
Вам достаточно поменять что угодно в аппаратной конфигурации, чтобы изменить набор сенсоров и порядок, и количество строк сразу же поплывут. И на месте третьей и восьмой строки может оказаться все что угодно.
Поэтому не следует парсить любой вывод или файл опираясь только лишь на номера строк, это абсолютно ненадежно.
Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:
nvme-pci-0100
Adapter: PCI adapter
Composite: +37.9°C (low = -0.1°C, high = +114.8°C)
(crit = +119.8°C)
Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:
sensors | grep nvme-pci-0100 -A 2
Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:
sensors | grep nvme-pci-0100 -A 2 | tail -n 1
И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:
sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'Теперь у нас при любых изменениях количества и порядка строк будет выводиться правильная информация. Либо перестанет выводиться вообще, если такой сенсор пропадет. Но погоды на Марсе уже не будет.
👍52😁4
Уже видели новость? Слёрм запускает серию вебинаров с экспертами из бигтеха про вакансии в DevOps.
Они хотят максимально честно показать вакансии и компании, чтобы сократить дистанцию между работодателями и соискателями:
🔴 Что реально важно конкретным лидам, когда они набирают команду?
🔴 Готовы ли компании снизить требования к позиции, чтобы ускорить поиск?
🔴 Если бы каждый пункт в вакансии стоил +20к к офферу, какие бы остались?
📆 Первая встреча: 13 февраля в 19:00
Ведущий: Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
Приглашённый гость: Владимир Федорков, основатель fournines.ru
Далее встречи — два раза в неделю по понедельникам и средам. В феврале ждем в гости эйчаров и лидов из VK Cloud, Kaspersky, Инфосистемы Джет.
Расписание, подробности и ссылки на встречи — в боте 📌
#реклама
О рекламодателе
erid: 2W5zFHUFkK2
Они хотят максимально честно показать вакансии и компании, чтобы сократить дистанцию между работодателями и соискателями:
🔴 Что реально важно конкретным лидам, когда они набирают команду?
🔴 Готовы ли компании снизить требования к позиции, чтобы ускорить поиск?
🔴 Если бы каждый пункт в вакансии стоил +20к к офферу, какие бы остались?
📆 Первая встреча: 13 февраля в 19:00
Ведущий: Вячеслав Федосеев, TeamLead DevOps в «Честном знаке», автор канала «DevOps Bootcamp с Федосеевым»
Приглашённый гость: Владимир Федорков, основатель fournines.ru
Далее встречи — два раза в неделю по понедельникам и средам. В феврале ждем в гости эйчаров и лидов из VK Cloud, Kaspersky, Инфосистемы Джет.
Расписание, подробности и ссылки на встречи — в боте 📌
#реклама
О рекламодателе
erid: 2W5zFHUFkK2
👎1
Вроде это знают все, как оказалось - не все.
Linux - начинающим. Потоки, перенаправление потоков, конвейер
После того, как вы освоили базовые принципы работы с Linux, позволяющие более-менее уверенно чувствовать себя в среде этой операционной системы, следует начать углублять свои знания, переходя к более глубоким и фундаментальным принципам, на которых основаны многие приемы работы в ОС.
Одним из важнейших является понятие потоков, которые позволяют передавать данные от одной программы к другой, а также конвейера, позволяющего выстраивать целые цепочки из программ, каждая из которых будет работать с результатом действий предыдущей.
Все это очень широко используется и понимание того, как это работает важно для любого Linux-администратора.
https://interface31.ru/tech_it/2021/10/linux---nachinayushhim-chast-7-potoki-perenapravlenie-potokov-konveyer.html
Linux - начинающим. Потоки, перенаправление потоков, конвейер
После того, как вы освоили базовые принципы работы с Linux, позволяющие более-менее уверенно чувствовать себя в среде этой операционной системы, следует начать углублять свои знания, переходя к более глубоким и фундаментальным принципам, на которых основаны многие приемы работы в ОС.
Одним из важнейших является понятие потоков, которые позволяют передавать данные от одной программы к другой, а также конвейера, позволяющего выстраивать целые цепочки из программ, каждая из которых будет работать с результатом действий предыдущей.
Все это очень широко используется и понимание того, как это работает важно для любого Linux-администратора.
https://interface31.ru/tech_it/2021/10/linux---nachinayushhim-chast-7-potoki-perenapravlenie-potokov-konveyer.html
👍35
Чтоб ты жил в эпоху перемен
Данную фразу приписывают древним китайцам, хотя другие источники говорят о гораздо более позднем ее возникновении, но определенный смысл в ней все равно есть.
Изменения – это не хорошо и не плохо, это неотъемлемая часть нашей жизни и профессиональной деятельности, но плохо, когда изменений слишком много и все они происходят примерно в одно и тоже время.
Применять изменения в IT – это целая наука и каждый хоть раз на этом обжигался. Поэтому сегодня давайте еще раз вернемся к этому вопросу и попробуем выделить базовые основы этого процесса.
Самая большая ошибка – это выполнить все изменения разом, потому что после этого, если что-то пойдет не так, будет совершенно непонятно, что именно стало причиной такого поведения и за что браться в первую очередь. Получится такой пожар во время наводнения.
Поэтому вносить изменения надо постепенно, даже если они «срочные». Сядьте и распишите все что вам требуется изменить. Обычно это изменения нескольких видов:
Обновить существующее ПО/оборудование
Добавить новое ПО/оборудование
Изменить текущие настройки/включить новые
Выписываем это все в отдельный список. После чего выявляем зависимости изменений друг от друга. Скажем, изменить или включить настройки можно только после обновления ПО. Поэтому строим любым удобным образом схему зависимостей одних изменений от других.
Мы, например, предпочитаем использовать для этого интеллект-карты, где можно легко разбить задачу на этапы и указать зависимости, пример такой карты в скриншоте под данной заметкой.
После чего мы будем понимать какие этапы внесения изменений можно выполнить независимо, а какие зависят от других или требуют целого ряда выполненных условий.
Начинаем с тех изменений, которые можно выполнять независимо и начинаем их вносит по следующему плану: внесли – протестировали – вывялили и устранили проблемы – завершили.
После чего, но не ранее, можно переходить к следующему изменению. Это позволит решать проблемы по мере их поступления, а не все разом. При этом вы всегда будете понимать, с каким именно изменением связана проблема.
Говоря о проблемах следует понимать, что не все из них являются техническими, многие окажутся организационными или просто создадут для конечных пользователей ранее неизвестную им ситуацию, которую они определят как проблему и будут обращаться по этому поводу в поддержку.
В связи с этим важно обеспечить соответствующую работу с пользователями, чтобы своевременно сообщить им обо всех изменениях и новых алгоритмах работы, иначе даже выполнив все технически безупречно вы рискуете провалить внедрение в глазах руководства, потому что вовремя не научили пользователей и не подготовили к новым условиям работы.
После того, как вы последовательно выполнили все изменения текущего уровня переходите к следующим. При этом учитывайте зависимости и всегда оставляйте время на тестирование и выявление ошибок.
Такой подход, даже при достаточно сложных изменениях позволяет сохранить контроль и выполнять поиск возникших проблем точечно, понимая с чем примерно они связаны. Потому что вчера у вас все работало, сегодня вы изменили это и это и получили проблему. Куда смотреть более-менее понятно.
В противном случае вы можете уподобиться герою известного анекдота, который ищет часы не там, где потерял, а там, где светлее.
Даже если проблема комплексная и появляется на пересечении нескольких изменений, то тоже будет примерно понятно это комбо, так как вы всегда будете видеть, какой из добавленных или измененных компонентов привел к проблеме и сможете провести причинно-следственные связи, хотя бы примерно определив предполагаемого виновника.
Ну и не забывайте на каждом этапе документировать все вносимые изменения и полученные при этом результаты, это поможет как вам, так и при возможном обращении в поддержку.
Кстати не стесняйтесь обращаться туда, а откуда еще разработчики должны узнать что в их продукте проблема?
Данную фразу приписывают древним китайцам, хотя другие источники говорят о гораздо более позднем ее возникновении, но определенный смысл в ней все равно есть.
Изменения – это не хорошо и не плохо, это неотъемлемая часть нашей жизни и профессиональной деятельности, но плохо, когда изменений слишком много и все они происходят примерно в одно и тоже время.
Применять изменения в IT – это целая наука и каждый хоть раз на этом обжигался. Поэтому сегодня давайте еще раз вернемся к этому вопросу и попробуем выделить базовые основы этого процесса.
Самая большая ошибка – это выполнить все изменения разом, потому что после этого, если что-то пойдет не так, будет совершенно непонятно, что именно стало причиной такого поведения и за что браться в первую очередь. Получится такой пожар во время наводнения.
Поэтому вносить изменения надо постепенно, даже если они «срочные». Сядьте и распишите все что вам требуется изменить. Обычно это изменения нескольких видов:
Обновить существующее ПО/оборудование
Добавить новое ПО/оборудование
Изменить текущие настройки/включить новые
Выписываем это все в отдельный список. После чего выявляем зависимости изменений друг от друга. Скажем, изменить или включить настройки можно только после обновления ПО. Поэтому строим любым удобным образом схему зависимостей одних изменений от других.
Мы, например, предпочитаем использовать для этого интеллект-карты, где можно легко разбить задачу на этапы и указать зависимости, пример такой карты в скриншоте под данной заметкой.
После чего мы будем понимать какие этапы внесения изменений можно выполнить независимо, а какие зависят от других или требуют целого ряда выполненных условий.
Начинаем с тех изменений, которые можно выполнять независимо и начинаем их вносит по следующему плану: внесли – протестировали – вывялили и устранили проблемы – завершили.
После чего, но не ранее, можно переходить к следующему изменению. Это позволит решать проблемы по мере их поступления, а не все разом. При этом вы всегда будете понимать, с каким именно изменением связана проблема.
Говоря о проблемах следует понимать, что не все из них являются техническими, многие окажутся организационными или просто создадут для конечных пользователей ранее неизвестную им ситуацию, которую они определят как проблему и будут обращаться по этому поводу в поддержку.
В связи с этим важно обеспечить соответствующую работу с пользователями, чтобы своевременно сообщить им обо всех изменениях и новых алгоритмах работы, иначе даже выполнив все технически безупречно вы рискуете провалить внедрение в глазах руководства, потому что вовремя не научили пользователей и не подготовили к новым условиям работы.
После того, как вы последовательно выполнили все изменения текущего уровня переходите к следующим. При этом учитывайте зависимости и всегда оставляйте время на тестирование и выявление ошибок.
Такой подход, даже при достаточно сложных изменениях позволяет сохранить контроль и выполнять поиск возникших проблем точечно, понимая с чем примерно они связаны. Потому что вчера у вас все работало, сегодня вы изменили это и это и получили проблему. Куда смотреть более-менее понятно.
В противном случае вы можете уподобиться герою известного анекдота, который ищет часы не там, где потерял, а там, где светлее.
Даже если проблема комплексная и появляется на пересечении нескольких изменений, то тоже будет примерно понятно это комбо, так как вы всегда будете видеть, какой из добавленных или измененных компонентов привел к проблеме и сможете провести причинно-следственные связи, хотя бы примерно определив предполагаемого виновника.
Ну и не забывайте на каждом этапе документировать все вносимые изменения и полученные при этом результаты, это поможет как вам, так и при возможном обращении в поддержку.
Кстати не стесняйтесь обращаться туда, а откуда еще разработчики должны узнать что в их продукте проблема?
👍35❤1🥱1
Очередная раздача слонов. Принцип прост: кто первый встал - тому и тапки.
Перед тем как воспользоваться данным предложением невиданной щедрости следует уточнить стоимость продления для этой зоны.
Писать об этом в комментариях и ставить дизлайки не надо. Равно как и писать про то, какая нехорошая контора Рег.ру.
Нужно - забираем, не нужно - проходим мимо.
Перед тем как воспользоваться данным предложением невиданной щедрости следует уточнить стоимость продления для этой зоны.
Писать об этом в комментариях и ставить дизлайки не надо. Равно как и писать про то, какая нехорошая контора Рег.ру.
Нужно - забираем, не нужно - проходим мимо.
👍18😁10🤮2🤡1
В комментариях к статье читатели посоветовали еще один конфигуратор для PostgreSQL.
Но это не просто конфигуратор. А разработка отечественных ребят и заточенный именно под 1С (выбираем Нагрузка базы данных - ERP1C).
Внимания однозначно заслуживает, кроме того позволяет выполнять не только базовую, но и гораздо более тонкую настройку.
https://tantorlabs.ru/pgconfigurator
Но это не просто конфигуратор. А разработка отечественных ребят и заточенный именно под 1С (выбираем Нагрузка базы данных - ERP1C).
Внимания однозначно заслуживает, кроме того позволяет выполнять не только базовую, но и гораздо более тонкую настройку.
https://tantorlabs.ru/pgconfigurator
👍34❤11
Сегодня у нас в Белгороде случилась страшная трагедия. BMW X7 в самом центре Белгорода протаранил карету Скорой помощи. Две девушки фельдшера погибли на месте, водитель крайне тяжелый в реанимации.
Я не прошу ни о чем, но кто может - помогите посильно семьям погибших, реквизиты будут в репосте ниже. Кто что может, посильно. Они за небольшую зарплату были фельдшерами скорой и ехали на очередной вызов.
Я не прошу ни о чем, но кто может - помогите посильно семьям погибших, реквизиты будут в репосте ниже. Кто что может, посильно. Они за небольшую зарплату были фельдшерами скорой и ехали на очередной вызов.
😢67🙏9👍1😁1