Хабр vs Пикабу
Решил тут утром, за чашкой кофе почитать что-нибудь техническое. Посмотреть, чем живет сообщество, какие темы в тренде. Ну куда пойти с такой целью? Пойдем на Хабр…
А там все чаще, если отбросить все коммерческие публикации и обзоры, наблюдаю следующую картину: технических статей, отражающих решение одного конкретного вопроса или проблемы практически не осталось. Их заменили полотна текста «как я хотел что-то сделать, что делал и как пришел туда, куда пришел».
Причем эти полотна могут быть очень густо приправлены техническими подробностями: скриптами, конфигами, командами, результатами их выполнения, что создает иллюзию плотного технического текста.
Но на самом деле все это бесполезно, потому что автор не дает готового, воспроизводимого решения, также он не исследует некоторую проблему и даже не пытается проанализировать результаты и сделать какие-то выводы.
Это просто «дорожная история» о том, как я ехал из пункта А в пункт Б, а заехал вообще не пойми куда. С подробным описанием всей поездки. А результат часто бывает либо далек от ожидаемого, либо закрывает какой-то сугубо частный случай, никому, кроме автора не нужный.
Зато статья завершается жизнеутверждающим: ну фигня, конечно, получилась, зато я приобрел опыт и сделал выводы. Причем этот самый «опыт» никому кроме автора и нафиг не нужен.
Кстати, этим грешат не только на Хабре, многие молодые блогеры, особенно подвизающиеся на ниве хоумлабинга, также под видом технических статей по настройке тех или иных продуктов пишут не гайд по настройке, а историю о том, как они этот самый продукт ставили в свою домашнюю лабораторию.
И при попытке повторить такую «инструкцию» быстро выяснится, то сделать это невозможно, разве что, полностью развернув точно такую же домашнюю лабораторию у себя. Потому что сервис А внезапно окажется завязан на сервисы Б, В и Г, часто в очень причудливых сочетаниях.
И чтобы понять почему именно так, а не иначе – нужно прочитать предыдущие «серии» этой истории. Потому что это про историю собственной лаборатории, собственные успехи и неудачи, а не инструкция по настройке сервиса.
Хорошо, подобный жанр тоже имеет право на существование, но вся беда в том, что читатель приходит туда по поисковому запросу, с четкой целью найти техническую статью и полностью оторван от контекста автора.
В итоге все это напоминает дешевый стендап, когда автор говорит: «ну вы же поняли», а залу ничего не понятно. И вроде как где-то тут надо смеяться, но совершенно непонятно где.
Самое главное - практической пользы от этого ноль. Равно как и художественной ценности, если попытаться рассмотреть это как художественное произведение. Максимум – сочинение на тему «как я провел это лето» с никому не нужными подробностями.
А причем тут Пикабу, про который и говорить-то в технических кругах неприлично, не то, что читать? А при том, что Пикабу сразу и прямо заявляет, что они – развлекательный ресурс. И это честно, потому что я не испытываю завышенных ожиданий от контента.
В то же время Хабр любит показательно демонстрировать по поводу и без повода – мы не Пикабу, а по сути качество контента на нем давно приблизилось к Пикабушному. Только под вывеской серьезного технического ресурса.
Почему? Да потому, что производство качественного технического контента – это серьезная работа, в том числе и над собой. Работа с документацией, источниками, стендами. Анализ и осмысление результата.
А написать «я тут не разобрался, но это ерунда, главное – было весело» – это гораздо проще.
Решил тут утром, за чашкой кофе почитать что-нибудь техническое. Посмотреть, чем живет сообщество, какие темы в тренде. Ну куда пойти с такой целью? Пойдем на Хабр…
А там все чаще, если отбросить все коммерческие публикации и обзоры, наблюдаю следующую картину: технических статей, отражающих решение одного конкретного вопроса или проблемы практически не осталось. Их заменили полотна текста «как я хотел что-то сделать, что делал и как пришел туда, куда пришел».
Причем эти полотна могут быть очень густо приправлены техническими подробностями: скриптами, конфигами, командами, результатами их выполнения, что создает иллюзию плотного технического текста.
Но на самом деле все это бесполезно, потому что автор не дает готового, воспроизводимого решения, также он не исследует некоторую проблему и даже не пытается проанализировать результаты и сделать какие-то выводы.
Это просто «дорожная история» о том, как я ехал из пункта А в пункт Б, а заехал вообще не пойми куда. С подробным описанием всей поездки. А результат часто бывает либо далек от ожидаемого, либо закрывает какой-то сугубо частный случай, никому, кроме автора не нужный.
Зато статья завершается жизнеутверждающим: ну фигня, конечно, получилась, зато я приобрел опыт и сделал выводы. Причем этот самый «опыт» никому кроме автора и нафиг не нужен.
Кстати, этим грешат не только на Хабре, многие молодые блогеры, особенно подвизающиеся на ниве хоумлабинга, также под видом технических статей по настройке тех или иных продуктов пишут не гайд по настройке, а историю о том, как они этот самый продукт ставили в свою домашнюю лабораторию.
И при попытке повторить такую «инструкцию» быстро выяснится, то сделать это невозможно, разве что, полностью развернув точно такую же домашнюю лабораторию у себя. Потому что сервис А внезапно окажется завязан на сервисы Б, В и Г, часто в очень причудливых сочетаниях.
И чтобы понять почему именно так, а не иначе – нужно прочитать предыдущие «серии» этой истории. Потому что это про историю собственной лаборатории, собственные успехи и неудачи, а не инструкция по настройке сервиса.
Хорошо, подобный жанр тоже имеет право на существование, но вся беда в том, что читатель приходит туда по поисковому запросу, с четкой целью найти техническую статью и полностью оторван от контекста автора.
В итоге все это напоминает дешевый стендап, когда автор говорит: «ну вы же поняли», а залу ничего не понятно. И вроде как где-то тут надо смеяться, но совершенно непонятно где.
Самое главное - практической пользы от этого ноль. Равно как и художественной ценности, если попытаться рассмотреть это как художественное произведение. Максимум – сочинение на тему «как я провел это лето» с никому не нужными подробностями.
А причем тут Пикабу, про который и говорить-то в технических кругах неприлично, не то, что читать? А при том, что Пикабу сразу и прямо заявляет, что они – развлекательный ресурс. И это честно, потому что я не испытываю завышенных ожиданий от контента.
В то же время Хабр любит показательно демонстрировать по поводу и без повода – мы не Пикабу, а по сути качество контента на нем давно приблизилось к Пикабушному. Только под вывеской серьезного технического ресурса.
Почему? Да потому, что производство качественного технического контента – это серьезная работа, в том числе и над собой. Работа с документацией, источниками, стендами. Анализ и осмысление результата.
А написать «я тут не разобрался, но это ерунда, главное – было весело» – это гораздо проще.
1🔥30👍14❤2👏2🤮2
☝️ 512 МБ хватит всем!
Все течет, все меняется. Особенно интересно смотреть на старые системы, которые тогда были вполне себе "ничего", а сейчас годятся только в музей.
Перед вами "малинка" образца 2013 года. Тогда нам этих плат по рублю за мешок отдали из одного банка. Им было дешевле продать недорого, чем списывать и утилизировать. На них были тонкие клиенты на основе Windows XP Embedded и да, 512 МБ хватало.
Мы же ставили на них Linux и использовали под то, под что сегодня обычно ставят "малинки". В те годы вполне актуальные системы получались.
Сейчас же если только поностальгировать. Ну или RouterOS x86 попробовать поставить. 😉
Все течет, все меняется. Особенно интересно смотреть на старые системы, которые тогда были вполне себе "ничего", а сейчас годятся только в музей.
Перед вами "малинка" образца 2013 года. Тогда нам этих плат по рублю за мешок отдали из одного банка. Им было дешевле продать недорого, чем списывать и утилизировать. На них были тонкие клиенты на основе Windows XP Embedded и да, 512 МБ хватало.
Мы же ставили на них Linux и использовали под то, под что сегодня обычно ставят "малинки". В те годы вполне актуальные системы получались.
Сейчас же если только поностальгировать. Ну или RouterOS x86 попробовать поставить. 😉
👍6😢6❤1👌1
Песенка про дятлов
В обсуждениях ни раз и ни два поднимается вопрос «ненадежности» современной техники с ностальгическими отсылками, что раньше было лучше и что старые добрые модели до сих пор работают.
В частности, это касается накопителей, так как они сейчас активно развиваются и как говорится, находятся на острие прогресса.
Основным типом современного накопителя является NVMe, т.е. диск работающий с использованием указанного протокола по шине PCIe, вне зависимости от форм-фактора и разъема.
Емкости таких дисков, как и скорости постоянно растут, при этом, естественно, появляются различные проблемы и сложности которых раньше не существовало и можно подумать, что вот раньше…
А раньше тоже все было далеко не гладко и безоблачно, а крупные проколы совершали даже лидеры рынка. Давайте вернемся в самое начало нулевых.
Именно в это время IBM выпустил новаторские модели жестких дисков Deskstar 75GXP и 40GV (DTLA) прозванных в народе «дятлами». Диски использовали стеклянные пластины с плотностью записи 20 Гбайт, скорость вращения 7200 оборотов/мин и интерфейс Ultra ATA/100.
IBM в те годы была одним из признанных лидеров рынка, а «дятлы» по совокупности характеристик были одними из лучших моделей дисков, равно как и самыми дорогими. Но ведь это топ от признанного лидера, это примерно, как сегодня SSD от Samsung.
В общем, продажи шли хорошо, но… Все чаще и чаще стали поступать сообщения об отказах DTLA. Диски могли начать издавать странные звуки, стучать головами или просто стремительно сыпаться.
Поначалу серьезного значения этому никто не придал, ну бракованная партия, бывает. Но отказов было все больше и больше и стало понятно, что это не просто производственный брак.
Но сама фирма IBM попыталась сделать хорошую мину при плохой игре и обвинила в этом «неправильную» работу чипсетов Intel 440BX, AMD 751 и VIA KT133A. И если последний действительно имел кое-какие проблемы при работе с накопителями, то вносить в список массовый и популярный 440BX явно было опрометчивым действием.
Тем более что проблемы возникали и с другими чипсетами, и с аппаратными RAID-контроллерами.
Вскоре был найден еще один «виноватый», им назначили ОС семейства Windows 9х/Me, они «слишком быстро» выключали жесткий диск, что он не успевал завершить отложенную запись, что могло привести к порче данных, а в некоторых случаях и самой пластины.
Microsoft в ответ выпустила специальные исправления, но уже практически всем становилось очевидно, что проблема в конструктивных ошибках заложенных на этапе разработки дисков.
Косвенно это подтверждалось и тем, что IBM по гарантии меняла «дятлов» не на новые диски такой же модели, а на винчестеры совсем другой серии 60GXP.
Попутно предлагались совсем беспомощные решения этой проблемы, например, понизить режим с Ultra ATA/100 на Ultra ATA/33, т.е. понизить производительность в три раза и это для топовой модели диска!
А позже стало известно о том, что в апреле 2001 IBM полностью прекратила производство серии DTLA.
Итоги этой истории оказались далеко не радостными. Компания серьезно подорвала свою репутацию и по большому счету так и не оправилась после провала. Вскоре подразделение по производству жестких дисков перешло к Hitachi, а сегодня им владеет Toshiba.
Пользователи не простили компании отказ сразу признать свою ошибку и постоянное вранье с поиском и назначением «виноватых» вместо того, чтобы принять меры к исправлению ситуации. Вот так вот в одночасье жесткие диски IBM из признанных топов превратились в жупел, от которого все шарахались достаточно долгое время.
В обсуждениях ни раз и ни два поднимается вопрос «ненадежности» современной техники с ностальгическими отсылками, что раньше было лучше и что старые добрые модели до сих пор работают.
В частности, это касается накопителей, так как они сейчас активно развиваются и как говорится, находятся на острие прогресса.
Основным типом современного накопителя является NVMe, т.е. диск работающий с использованием указанного протокола по шине PCIe, вне зависимости от форм-фактора и разъема.
Емкости таких дисков, как и скорости постоянно растут, при этом, естественно, появляются различные проблемы и сложности которых раньше не существовало и можно подумать, что вот раньше…
А раньше тоже все было далеко не гладко и безоблачно, а крупные проколы совершали даже лидеры рынка. Давайте вернемся в самое начало нулевых.
Именно в это время IBM выпустил новаторские модели жестких дисков Deskstar 75GXP и 40GV (DTLA) прозванных в народе «дятлами». Диски использовали стеклянные пластины с плотностью записи 20 Гбайт, скорость вращения 7200 оборотов/мин и интерфейс Ultra ATA/100.
IBM в те годы была одним из признанных лидеров рынка, а «дятлы» по совокупности характеристик были одними из лучших моделей дисков, равно как и самыми дорогими. Но ведь это топ от признанного лидера, это примерно, как сегодня SSD от Samsung.
В общем, продажи шли хорошо, но… Все чаще и чаще стали поступать сообщения об отказах DTLA. Диски могли начать издавать странные звуки, стучать головами или просто стремительно сыпаться.
Поначалу серьезного значения этому никто не придал, ну бракованная партия, бывает. Но отказов было все больше и больше и стало понятно, что это не просто производственный брак.
Но сама фирма IBM попыталась сделать хорошую мину при плохой игре и обвинила в этом «неправильную» работу чипсетов Intel 440BX, AMD 751 и VIA KT133A. И если последний действительно имел кое-какие проблемы при работе с накопителями, то вносить в список массовый и популярный 440BX явно было опрометчивым действием.
Тем более что проблемы возникали и с другими чипсетами, и с аппаратными RAID-контроллерами.
Вскоре был найден еще один «виноватый», им назначили ОС семейства Windows 9х/Me, они «слишком быстро» выключали жесткий диск, что он не успевал завершить отложенную запись, что могло привести к порче данных, а в некоторых случаях и самой пластины.
Microsoft в ответ выпустила специальные исправления, но уже практически всем становилось очевидно, что проблема в конструктивных ошибках заложенных на этапе разработки дисков.
Косвенно это подтверждалось и тем, что IBM по гарантии меняла «дятлов» не на новые диски такой же модели, а на винчестеры совсем другой серии 60GXP.
Попутно предлагались совсем беспомощные решения этой проблемы, например, понизить режим с Ultra ATA/100 на Ultra ATA/33, т.е. понизить производительность в три раза и это для топовой модели диска!
А позже стало известно о том, что в апреле 2001 IBM полностью прекратила производство серии DTLA.
Итоги этой истории оказались далеко не радостными. Компания серьезно подорвала свою репутацию и по большому счету так и не оправилась после провала. Вскоре подразделение по производству жестких дисков перешло к Hitachi, а сегодня им владеет Toshiba.
Пользователи не простили компании отказ сразу признать свою ошибку и постоянное вранье с поиском и назначением «виноватых» вместо того, чтобы принять меры к исправлению ситуации. Вот так вот в одночасье жесткие диски IBM из признанных топов превратились в жупел, от которого все шарахались достаточно долгое время.
👍25❤7🤮2🤔1💯1
Обязательное подписывание SMB-пакетов в Windows 11
С выходом Windows 11 24H2 многие пользователи столкнулись с проблемами доступа к сетевым ресурсам при помощи SMB. Виной тому изменение политики подписывания SMB-пакетов, которая по умолчанию стала обязательной.
SMB Signing - это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью.
Такая подпись позволяет гарантировать, что содержимое сообщение не было изменено и проверить подлинность отправителя. Это позволяет предотвратить реализацию SMB атак типа man-in-the-middle и NTLM relay.
Ранее SMB подписывание требовалось только при доступе к сетевым папкам SYSVOL и NETLOGON на контроллерах домена AD.
В дальнейшем данную политику обещают распространить и на другие версии Windows.
При обращении такого клиента к серверу не использующему подписывание пакетов будет появляться ошибка:
Поэтому самое время разобраться с действующими в системе политиками, для этого выполним в консоли PowerShell две команды, которые покажут настройки клиента и сервера SMB:
Например, в версии Windows 11 23H2 для клиента установлены следующие политики:
Политика EnableSecuritySignature для клиента и сервера SMB2+ игнорируется, а так как SMB1 везде по умолчанию отключен, то можем не обращать на нее внимание.
В современных системах для подписывания используется политика RequireSecuritySignature, которая определяет необходимость подписи по принципу логического ИЛИ. Т.е. если хоть одна сторона будет требовать подписывания (клиент или сервер) – пакет будет подписан.
Таким образом, чтобы отключит подписывание, мы должны отключить его и на клиенте, и на сервере.
Для этого можно использовать команды:
Если политику нужно включить, то замените $false на $true.
При этом не следует бежать и отключать требование подписи везде где только можно, потому что это довольно важное средство обеспечения безопасности, а только там, где использование подписи невозможно по техническим причинам.
Так если весь парк ПК состоит из современных систем, то имеет смысл отключать требование подписи только на клиенте, чтобы они могли работать с не умеющими подписывать пакеты серверами и оставлять ее включенной для серверов, что обеспечит использование подписи при наличии такой возможности.
С выходом Windows 11 24H2 многие пользователи столкнулись с проблемами доступа к сетевым ресурсам при помощи SMB. Виной тому изменение политики подписывания SMB-пакетов, которая по умолчанию стала обязательной.
SMB Signing - это одно из средств безопасности средств протокола общего доступа к файлам SMB/CIFS. Когда оно включено, каждое SMB сообщение подписывается в заголовке цифровой подписью.
Такая подпись позволяет гарантировать, что содержимое сообщение не было изменено и проверить подлинность отправителя. Это позволяет предотвратить реализацию SMB атак типа man-in-the-middle и NTLM relay.
Ранее SMB подписывание требовалось только при доступе к сетевым папкам SYSVOL и NETLOGON на контроллерах домена AD.
В дальнейшем данную политику обещают распространить и на другие версии Windows.
При обращении такого клиента к серверу не использующему подписывание пакетов будет появляться ошибка:
0xc000a000 The cryptographic signature is invalid
Поэтому самое время разобраться с действующими в системе политиками, для этого выполним в консоли PowerShell две команды, которые покажут настройки клиента и сервера SMB:
Get-SmbClientconfiguration | fl *sign*
Get-SmbServerconfiguration | fl *sign*
Например, в версии Windows 11 23H2 для клиента установлены следующие политики:
EnableSecuritySignature : True
RequireSecuritySignature : False
Политика EnableSecuritySignature для клиента и сервера SMB2+ игнорируется, а так как SMB1 везде по умолчанию отключен, то можем не обращать на нее внимание.
В современных системах для подписывания используется политика RequireSecuritySignature, которая определяет необходимость подписи по принципу логического ИЛИ. Т.е. если хоть одна сторона будет требовать подписывания (клиент или сервер) – пакет будет подписан.
Таким образом, чтобы отключит подписывание, мы должны отключить его и на клиенте, и на сервере.
Для этого можно использовать команды:
Set-SmbClientConfiguration -RequireSecuritySignature $false
Set-SmbServerConfiguration -RequireSecuritySignature $false
Если политику нужно включить, то замените $false на $true.
При этом не следует бежать и отключать требование подписи везде где только можно, потому что это довольно важное средство обеспечения безопасности, а только там, где использование подписи невозможно по техническим причинам.
Так если весь парк ПК состоит из современных систем, то имеет смысл отключать требование подписи только на клиенте, чтобы они могли работать с не умеющими подписывать пакеты серверами и оставлять ее включенной для серверов, что обеспечит использование подписи при наличии такой возможности.
🤝7👍3❤2🔥1
Подписывание 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, там сторона может либо требовать подписывание для всех, либо нет, режим согласования отсутствует.
👍11🤮1🤝1
Как сервер 1С:Предприятия убивает ваши SSD
Данный заголовок – не кликбейт, а суровая реальность. Если вы решите понаблюдать подробнее за жизнью вашего сервера 1С:Предприятие на Windows, то можете заметить странное: процесс ragent.exe (Агент сервера 1С) постоянно пишет на диск временные файлы.
Причем делает это очень интересно: каждые 5 секунд на диск записывается временный файл размеров 12 000 000 байт и тут же удаляется. И так все время пока процесс активен. Если у вас на сервере два процесса агента (две платформы на разных портах) – то каждые 5 секунд пишутся уже два таких файла.
Что это, баг? Кривая настройка? Нет, это штатный механизм замера производительности для серверов кластера с целью балансирования нагрузки, работающий даже если в кластере всего один рабочий сервер.
Чтобы оценить расходуемый впустую ресурс считаем:
▫️ В сутки (24 часа): 207,36 ГБ
▫️ В месяц (30 дней): 6,22 ТБ
▫️ В квартал (90 дней): 18,66 ТБ
▫️ В год (365 дней): 75,69 ТБ
И если у вас под систему взят небольшой диск объемом 250 ГБ, то сервер 1С:Предприятия в единственном экземпляре устраивает ему практически полую перезапись объема ежедневно. Нетрудно посчитать, что ресурс большинства массовых дисков закончится года так через полтора.
А мы пока дружно говорим спасибо разработчикам 1С:Предприятие за это гениальное решение.
Данный заголовок – не кликбейт, а суровая реальность. Если вы решите понаблюдать подробнее за жизнью вашего сервера 1С:Предприятие на Windows, то можете заметить странное: процесс ragent.exe (Агент сервера 1С) постоянно пишет на диск временные файлы.
Причем делает это очень интересно: каждые 5 секунд на диск записывается временный файл размеров 12 000 000 байт и тут же удаляется. И так все время пока процесс активен. Если у вас на сервере два процесса агента (две платформы на разных портах) – то каждые 5 секунд пишутся уже два таких файла.
Что это, баг? Кривая настройка? Нет, это штатный механизм замера производительности для серверов кластера с целью балансирования нагрузки, работающий даже если в кластере всего один рабочий сервер.
Чтобы оценить расходуемый впустую ресурс считаем:
▫️ В сутки (24 часа): 207,36 ГБ
▫️ В месяц (30 дней): 6,22 ТБ
▫️ В квартал (90 дней): 18,66 ТБ
▫️ В год (365 дней): 75,69 ТБ
И если у вас под систему взят небольшой диск объемом 250 ГБ, то сервер 1С:Предприятия в единственном экземпляре устраивает ему практически полую перезапись объема ежедневно. Нетрудно посчитать, что ресурс большинства массовых дисков закончится года так через полтора.
А мы пока дружно говорим спасибо разработчикам 1С:Предприятие за это гениальное решение.
1😱31😁13👍10🤬5👀5
KSM Sharing в Proxmox
KSM (Kernel Same-page Merging) - специальная технология ядра Linux, позволяющая объединять страницы памяти разных процессов, тем самым добиваясь ее экономии, фактически данный процесс можно назвать дедупликацией оперативной памяти. При наличии большого количества однотипных виртуальных машин эффект от использования KSM может быть достаточно ощутимым.
👉 Обратите внимание! KSM работает только с виртуальными машинами KVM, для контейнеров LXC эта технология не применима.
KSM сразу включен в Proxmox VE, но его настройки могут быть недостаточно оптимальными. Поэтому откроем файл
Начнем с двух опций:
KSM_THRES_COEF - основной параметр, указывающий при каком объеме оставшейся свободной памяти начнет работать KSM. Несложно подсчитать, что для системы с 64 ГБ ОЗУ это произойдет после того, как будут заняты 51,2 ГБ памяти. Второй параметр KSM_THRES_CONST указывает аналогичное значение в МБ, вы можете использовать его для более точного задания порогов, при различных значениях параметров сработает самый низкий порог.
Многим может показаться, что KSM начинает работать слишком поздно, но этому тоже есть своя причина - операция по сравнению и объединению страниц памяти довольно затратна по использованию процессора, поэтому указанные значения - это некоторый разумный компромисс. Если же у вас нет недостатка в процессорных ресурсах, но актуально рациональное использование памяти - можете попробовать изменить эти параметры.
Следующие два параметра в целом отвечают за нагрузку на CPU:
KSM_MONITOR_INTERVAL - задает промежуток между сканированиями в секундах. Сканирование происходит блоками по 16 ГБ, пауза между этими процессами задается опцией KSM_SLEEP_MSEC. Увеличение этих параметров снижает нагрузку на процессор, но уменьшают эффективность работы KSM.
Минимальное и максимальное количество страниц, которые будут просканированы и объединены задается параметрами:
Без особой нужды и понимания того, что вы делаете, редактировать их не следует.
Агрессивность работы KSM задается следующими параметрами:
KSM_NPAGES_BOOST определяет какое количество сканируемых страниц будет прибавлено к текущему значению при превышении порога оставшейся свободной памяти, KSM_NPAGES_DECAY, наоборот, уменьшает количество страниц, когда свободной памяти окажется больше, чем установлено в пороговых значениях. Таким образом достигается баланс между количеством сканируемых и объединяемых страниц и необходимым запасом свободной памяти.
Но приведенные значения совсем не догма и если у вас большое количество однотипных виртуальных машин, то можете поэкспериментировать с настройками KSM, начав с изменения KSM_THRES_COEF.
После внесения изменений не забудьте перезапустить службу командой:
При выборе значений будьте благоразумны, помните, что за уплотнение памяти вы платите повышенной нагрузкой на процессор.
KSM (Kernel Same-page Merging) - специальная технология ядра Linux, позволяющая объединять страницы памяти разных процессов, тем самым добиваясь ее экономии, фактически данный процесс можно назвать дедупликацией оперативной памяти. При наличии большого количества однотипных виртуальных машин эффект от использования KSM может быть достаточно ощутимым.
👉 Обратите внимание! KSM работает только с виртуальными машинами KVM, для контейнеров LXC эта технология не применима.
KSM сразу включен в Proxmox VE, но его настройки могут быть недостаточно оптимальными. Поэтому откроем файл
/etc/ksmtuned.conf и ознакомимся с его содержимым. Все опции в нем закомментированы и содержат значения по умолчанию, если мы хотим изменить значение, то строку надо раскомментировать.Начнем с двух опций:
KSM_THRES_COEF=20
KSM_THRES_CONST=2048
KSM_THRES_COEF - основной параметр, указывающий при каком объеме оставшейся свободной памяти начнет работать KSM. Несложно подсчитать, что для системы с 64 ГБ ОЗУ это произойдет после того, как будут заняты 51,2 ГБ памяти. Второй параметр KSM_THRES_CONST указывает аналогичное значение в МБ, вы можете использовать его для более точного задания порогов, при различных значениях параметров сработает самый низкий порог.
Многим может показаться, что KSM начинает работать слишком поздно, но этому тоже есть своя причина - операция по сравнению и объединению страниц памяти довольно затратна по использованию процессора, поэтому указанные значения - это некоторый разумный компромисс. Если же у вас нет недостатка в процессорных ресурсах, но актуально рациональное использование памяти - можете попробовать изменить эти параметры.
Следующие два параметра в целом отвечают за нагрузку на CPU:
KSM_MONITOR_INTERVAL=60
KSM_SLEEP_MSEC=100
KSM_MONITOR_INTERVAL - задает промежуток между сканированиями в секундах. Сканирование происходит блоками по 16 ГБ, пауза между этими процессами задается опцией KSM_SLEEP_MSEC. Увеличение этих параметров снижает нагрузку на процессор, но уменьшают эффективность работы KSM.
Минимальное и максимальное количество страниц, которые будут просканированы и объединены задается параметрами:
KSM_NPAGES_MIN=64
KSM_NPAGES_MAX=1250
Без особой нужды и понимания того, что вы делаете, редактировать их не следует.
Агрессивность работы KSM задается следующими параметрами:
KSM_NPAGES_BOOST=300
KSM_NPAGES_DECAY=-50
KSM_NPAGES_BOOST определяет какое количество сканируемых страниц будет прибавлено к текущему значению при превышении порога оставшейся свободной памяти, KSM_NPAGES_DECAY, наоборот, уменьшает количество страниц, когда свободной памяти окажется больше, чем установлено в пороговых значениях. Таким образом достигается баланс между количеством сканируемых и объединяемых страниц и необходимым запасом свободной памяти.
Но приведенные значения совсем не догма и если у вас большое количество однотипных виртуальных машин, то можете поэкспериментировать с настройками KSM, начав с изменения KSM_THRES_COEF.
После внесения изменений не забудьте перезапустить службу командой:
systemctl restart ksmtuned
При выборе значений будьте благоразумны, помните, что за уплотнение памяти вы платите повышенной нагрузкой на процессор.
👍10
Случай редкий, а сегодня снова вот понадобилось, хорошо что не поленись и оформили случай как статью.
Админу на заметку - 23. Перед первым входом в систему необходимо сменить пароль. Как это сделать через RDP?
Иногда, казалось бы, простые ситуации ставят в тупик и заставляют искать нестандартные решения. Ну что такого в истекшем пароле? Попросит поменять при следующем входе...
Но не все так просто, если у вас есть только удаленный доступ, то ситуация обещает стать интересной.
В этой короткой заметке мы не будем делать теоретических отступлений, да и отступать тут некуда, сама по себе проблема проста и понятна, только вот необычное сочетание условий заставило искать обходное решение, которое оказалось не менее простым.
✅ Читать далее: https://interface31.ru/post/adminu-na-zametku-23-pered-pervym-vhodom-v-sistemu-neobhodimo-smenit-parol/
Админу на заметку - 23. Перед первым входом в систему необходимо сменить пароль. Как это сделать через RDP?
Иногда, казалось бы, простые ситуации ставят в тупик и заставляют искать нестандартные решения. Ну что такого в истекшем пароле? Попросит поменять при следующем входе...
Но не все так просто, если у вас есть только удаленный доступ, то ситуация обещает стать интересной.
В этой короткой заметке мы не будем делать теоретических отступлений, да и отступать тут некуда, сама по себе проблема проста и понятна, только вот необычное сочетание условий заставило искать обходное решение, которое оказалось не менее простым.
✅ Читать далее: https://interface31.ru/post/adminu-na-zametku-23-pered-pervym-vhodom-v-sistemu-neobhodimo-smenit-parol/
🔥18👌5👎2🤔2👀1
Проблема мелкого прайса
В комментариях регулярно ломаются копья насчет работы с малым бизнесом в небольших населенных пунктах, где коллеги доказывали нам, что кроме как быть там мастером на все руки за мелкий прайс ну никак не выйдет.
И это действительно так, если вы и дальше собрались делать все подряд за мелкий прайс, то так и продолжите постоянно этим заниматься без перспектив и просветов.
Точнее ровно до тех пор, пока физическое здоровье и внешние обстоятельства будут позволять вам физически мотаться между клиентами.
А теперь немного простой арифметики. Допустим ваша цель – 100 000 руб. в месяц. В месяце 30 дней, из них в среднем 21 день рабочий.
Таким образом вам нужно зарабатывать порядка 4 700 руб. в день, что за мелкий прайс означает, что вам нужно успеть окучить не одного клиента. Фактически вы будете бегать как собака с утра до ночи положив язык на плечо.
При этом кроме основной деятельности будете лудить, паять, выполнять услуги курьера и просто развлекать заказчика в надежде что он заплатит всю запрошенную вами сумму и сделает это сегодня, а не скажет зайти в конце недели или месяца.
Ну и ваша ценность в глазах заказчика будет на уровне «мальчика, который делает все подряд». Т.е. уровень разнорабочего на стройке. А вот вы, делая ремонт, кого позовете класть плитку? Плиточника с отзывами, но дорого, или разнорабочего, но за мелкий прайс?
Поэтому не следует удивляться, что крупных заказов у вас нет и не будет. А чтобы они были, нужно изменить собственную ценность и позиционирование на рынке труда.
Летом я много времени проводил в райцентре на 14 000 человек по причине внезапно нарисовавшегося объекта недвижимости по типу «домик в деревне». Мог проживать там неделями, работая удаленно, при этом легко и непринужденно нашел себе еще пару клиентов.
Просто разговаривая с предпринимателями в местных магазинчиках. И они были очень рады что ими займется кто-то из «городских». А почему? А потому что местные все «занимаются всем подряд», ну какие из них специалисты.
Только и этих местных еще найти надо, особенно вечером или в выходной день. А та же розница именно вечером основную кассу делает, и если вы просто способны отвечать часов до 22 - то вам цены не будет.
С другой стороны, те же местные ребята могут быть и достаточно неплохой квалификации, но они сами поставили себя в то положение, когда их всерьез не воспринимают.
И перед тем, как пытаться возражать снова вспоминаем разнорабочего на стройке, доверите вы ему класть дорогую плитку?
Как быть? Повышать свою ценность как специалиста, а именно уходить в более узкий профиль. И не нужно говорить, что нет таких клиентов, они есть, даже среди тех, в среде которых вы сейчас варитесь.
А также есть более крупные и серьезные клиенты, которых вы на данном этапе просто не видите, потому что они не нуждаются в услугах «разнорабочего от IT».
Поэтому говорить, что у меня тут маленький населенный пункт и нет заказчиков другого уровня – это лукавство, в первую очередь перед самим собой. По факту это означает, что я не могу, не имею нужных коммуникационных навыков, квалификации, опыта или просто боюсь работать с таким клиентом.
Получается заколдованный круг. Как из него вырваться? Только единственным образом – прекращать работу за мелкий прайс.
Даже те же ваши нынешние клиенты будут готовы платить вам сопоставимые деньги за те же консультационные услуги по 1С, но в том случае если вы действительно будете понимать предметную часть гораздо глубже своих коллег, что подразумевает более глубокое погружение в предмет, которое исключает беготню по заказчикам за мелкий прайс.
Потому что в провинции и мелких городах остро не хватает экспертизы, т.е. специалистов действительно с узким опытом и глубокими знаниями, и поэтому при возникновении подобных вопросов ваши клиенты приглашают «городских».
Кто мешает их заменить? Узость рынка? Так вы не в вакууме живете, интернет и удаленка, соседние городки и райцентры. Вот вам вполне приличная кормовая база. И без унылой беготни за копейки.
В комментариях регулярно ломаются копья насчет работы с малым бизнесом в небольших населенных пунктах, где коллеги доказывали нам, что кроме как быть там мастером на все руки за мелкий прайс ну никак не выйдет.
И это действительно так, если вы и дальше собрались делать все подряд за мелкий прайс, то так и продолжите постоянно этим заниматься без перспектив и просветов.
Точнее ровно до тех пор, пока физическое здоровье и внешние обстоятельства будут позволять вам физически мотаться между клиентами.
А теперь немного простой арифметики. Допустим ваша цель – 100 000 руб. в месяц. В месяце 30 дней, из них в среднем 21 день рабочий.
Таким образом вам нужно зарабатывать порядка 4 700 руб. в день, что за мелкий прайс означает, что вам нужно успеть окучить не одного клиента. Фактически вы будете бегать как собака с утра до ночи положив язык на плечо.
При этом кроме основной деятельности будете лудить, паять, выполнять услуги курьера и просто развлекать заказчика в надежде что он заплатит всю запрошенную вами сумму и сделает это сегодня, а не скажет зайти в конце недели или месяца.
Ну и ваша ценность в глазах заказчика будет на уровне «мальчика, который делает все подряд». Т.е. уровень разнорабочего на стройке. А вот вы, делая ремонт, кого позовете класть плитку? Плиточника с отзывами, но дорого, или разнорабочего, но за мелкий прайс?
Поэтому не следует удивляться, что крупных заказов у вас нет и не будет. А чтобы они были, нужно изменить собственную ценность и позиционирование на рынке труда.
Летом я много времени проводил в райцентре на 14 000 человек по причине внезапно нарисовавшегося объекта недвижимости по типу «домик в деревне». Мог проживать там неделями, работая удаленно, при этом легко и непринужденно нашел себе еще пару клиентов.
Просто разговаривая с предпринимателями в местных магазинчиках. И они были очень рады что ими займется кто-то из «городских». А почему? А потому что местные все «занимаются всем подряд», ну какие из них специалисты.
Только и этих местных еще найти надо, особенно вечером или в выходной день. А та же розница именно вечером основную кассу делает, и если вы просто способны отвечать часов до 22 - то вам цены не будет.
С другой стороны, те же местные ребята могут быть и достаточно неплохой квалификации, но они сами поставили себя в то положение, когда их всерьез не воспринимают.
И перед тем, как пытаться возражать снова вспоминаем разнорабочего на стройке, доверите вы ему класть дорогую плитку?
Как быть? Повышать свою ценность как специалиста, а именно уходить в более узкий профиль. И не нужно говорить, что нет таких клиентов, они есть, даже среди тех, в среде которых вы сейчас варитесь.
А также есть более крупные и серьезные клиенты, которых вы на данном этапе просто не видите, потому что они не нуждаются в услугах «разнорабочего от IT».
Поэтому говорить, что у меня тут маленький населенный пункт и нет заказчиков другого уровня – это лукавство, в первую очередь перед самим собой. По факту это означает, что я не могу, не имею нужных коммуникационных навыков, квалификации, опыта или просто боюсь работать с таким клиентом.
Получается заколдованный круг. Как из него вырваться? Только единственным образом – прекращать работу за мелкий прайс.
Даже те же ваши нынешние клиенты будут готовы платить вам сопоставимые деньги за те же консультационные услуги по 1С, но в том случае если вы действительно будете понимать предметную часть гораздо глубже своих коллег, что подразумевает более глубокое погружение в предмет, которое исключает беготню по заказчикам за мелкий прайс.
Потому что в провинции и мелких городах остро не хватает экспертизы, т.е. специалистов действительно с узким опытом и глубокими знаниями, и поэтому при возникновении подобных вопросов ваши клиенты приглашают «городских».
Кто мешает их заменить? Узость рынка? Так вы не в вакууме живете, интернет и удаленка, соседние городки и райцентры. Вот вам вполне приличная кормовая база. И без унылой беготни за копейки.
👍14🤮5🥱3🤬2👀1
Стандартные расположения данных
Иерархия файловых систем основных ОС предполагает строгую структуру каталогов, центральное место в которой занимает пользовательская папка. В Linux и UNIX-подобных системах это /home, в Windows - C:\Users.
Предполагается, что пользователь будет хранить свои данные именно там и не будет их располагать в местах откровенно нестандартных и тем более странных.
Только вот есть интересная особенность. В Linux или той же macOS данное правило строго соблюдается, может быть потому, что сами системы не сильно располагают к разбрасыванию пользователем своих данных куда попало.
Причем делают это самым простым и очевидным способом: прав на запись куда-либо за пределы домашней директории у пользователя нет. И ни у кого это не вызывает ни неприятия, ни отторжения.
При этом те же самые люди в Windows как будто специально стараются нарушать соглашение о хранении данных, размещая их буквально где попало.
Отчасти в этом есть вина самой системы: в Windows нет общей иерархии файловой системы, и люди привыкли хранить свои данные на дополнительных логических томах (D:, E: и т.д.) и делать это так, как удобно им.
Очень часто эта практика сохраняется и в том случае, когда логический том один. Такое чаще всего бывает на ноутбуках или моноблоках, а разбивать на разделы единственный быстрый SSD размером в 250-500 ГБ не имеет смысла.
И вот вместо того, чтобы сложить все в папку пользователя и не париться, то тут, то там, чаще всего в корне диска возникают различные пользовательские папки то с играми, то с документами, то с базами 1С (последние почему-то очень не любят размещать в тех же Документах, куда, кстати, сама 1С предлагает их класть по умолчанию).
Что в этом плохого, спросите вы? В ответ я расскажу вам одну поучительную историю.
Третьего дня у одного моего знакомого что-то случилось с системой, то ли сделали что-то не так, то ли скачали что-то не то, но загружаться она перестала.
Ноутбук хороший, брендовый, HP. После пары неудачных загрузок он предложил ему восстановить систему и запустил утилиту Recovery Manager, которая предложила ему восстановление с сохранением программ и данных.
Он внимательно прочитал текст на экране, вставил внешний диск для сохранения данных и запустил процесс. Некоторое время просто наблюдал и, убедившись, что утилита реально сохраняет на внешний диск данные, пошел пить чай, оставив ноутбук восстанавливаться.
Через пару часов все было готово, программы на месте, документы на месте, все работает. Но если все идет хорошо – значит, вы чего-то не заметили.
Это «чего-то» заметила на следующий день его жена, когда запустила 1С, а та ей бодро сообщила, что информационная база не обнаружена.
Как вы уже догадались, лежала база не в профиле пользователя, а в C:\1CBases или чем-то подобным.
Изучив то, что утилита сохранила на внешний диск, выяснилось: из пользовательских данных туда попали только профили из C:\Users (Документы, Рабочий стол, Загрузки и т. д.).
Более никаких папок туда не копировалось, да и, наверное, никогда не предполагалось, потому что разработчики утилиты исходили из того, что и данные, и программы у пользователя будут в стандартных расположениях.
Бекапов, как полагается, не было. Спасло то, что недавно эту базу выгружали на флешку, чтобы передать внешнему бухгалтеру. Так что отделались почти легким испугом, ну и за месяц документы заново руками вбить.
История с HP Recovery Manager поучительна, но точно так же ведут себя штатный «Сброс компьютера» (Reset this PC) в Windows 10/11 с опцией «Сохранить мои файлы», а также Средство переноса данных (USMT) и почти все дефолтные скрипты миграции профилей.
Поэтому храните данные в стандартных расположениях, ну и не забывайте про бекапы.
Иерархия файловых систем основных ОС предполагает строгую структуру каталогов, центральное место в которой занимает пользовательская папка. В Linux и UNIX-подобных системах это /home, в Windows - C:\Users.
Предполагается, что пользователь будет хранить свои данные именно там и не будет их располагать в местах откровенно нестандартных и тем более странных.
Только вот есть интересная особенность. В Linux или той же macOS данное правило строго соблюдается, может быть потому, что сами системы не сильно располагают к разбрасыванию пользователем своих данных куда попало.
Причем делают это самым простым и очевидным способом: прав на запись куда-либо за пределы домашней директории у пользователя нет. И ни у кого это не вызывает ни неприятия, ни отторжения.
При этом те же самые люди в Windows как будто специально стараются нарушать соглашение о хранении данных, размещая их буквально где попало.
Отчасти в этом есть вина самой системы: в Windows нет общей иерархии файловой системы, и люди привыкли хранить свои данные на дополнительных логических томах (D:, E: и т.д.) и делать это так, как удобно им.
Очень часто эта практика сохраняется и в том случае, когда логический том один. Такое чаще всего бывает на ноутбуках или моноблоках, а разбивать на разделы единственный быстрый SSD размером в 250-500 ГБ не имеет смысла.
И вот вместо того, чтобы сложить все в папку пользователя и не париться, то тут, то там, чаще всего в корне диска возникают различные пользовательские папки то с играми, то с документами, то с базами 1С (последние почему-то очень не любят размещать в тех же Документах, куда, кстати, сама 1С предлагает их класть по умолчанию).
Что в этом плохого, спросите вы? В ответ я расскажу вам одну поучительную историю.
Третьего дня у одного моего знакомого что-то случилось с системой, то ли сделали что-то не так, то ли скачали что-то не то, но загружаться она перестала.
Ноутбук хороший, брендовый, HP. После пары неудачных загрузок он предложил ему восстановить систему и запустил утилиту Recovery Manager, которая предложила ему восстановление с сохранением программ и данных.
Он внимательно прочитал текст на экране, вставил внешний диск для сохранения данных и запустил процесс. Некоторое время просто наблюдал и, убедившись, что утилита реально сохраняет на внешний диск данные, пошел пить чай, оставив ноутбук восстанавливаться.
Через пару часов все было готово, программы на месте, документы на месте, все работает. Но если все идет хорошо – значит, вы чего-то не заметили.
Это «чего-то» заметила на следующий день его жена, когда запустила 1С, а та ей бодро сообщила, что информационная база не обнаружена.
Как вы уже догадались, лежала база не в профиле пользователя, а в C:\1CBases или чем-то подобным.
Изучив то, что утилита сохранила на внешний диск, выяснилось: из пользовательских данных туда попали только профили из C:\Users (Документы, Рабочий стол, Загрузки и т. д.).
Более никаких папок туда не копировалось, да и, наверное, никогда не предполагалось, потому что разработчики утилиты исходили из того, что и данные, и программы у пользователя будут в стандартных расположениях.
Бекапов, как полагается, не было. Спасло то, что недавно эту базу выгружали на флешку, чтобы передать внешнему бухгалтеру. Так что отделались почти легким испугом, ну и за месяц документы заново руками вбить.
История с HP Recovery Manager поучительна, но точно так же ведут себя штатный «Сброс компьютера» (Reset this PC) в Windows 10/11 с опцией «Сохранить мои файлы», а также Средство переноса данных (USMT) и почти все дефолтные скрипты миграции профилей.
Поэтому храните данные в стандартных расположениях, ну и не забывайте про бекапы.
👍15❤2🥱1
Установка сервера 1C:Предприятие, PostgreSQL и Apache2 на Astra Linux SE 1.8
Продолжаем тему установки сервера 1С:Предприятие на российские ОС. Сегодня у нас на очереди лидер импортозамещения - Astra Linux SE 1.8, которая широко внедряется во все сферы и вопрос ее использования для 1С:Предприятие стоит достаточно остро.
Несмотря на то, что процесс установки сервера 1С достаточно хорошо документирован, все-таки в каждой операционной системе есть свои особенности, которые могут вызвать затруднения в процессе установки или настройки.
Astra Linux SE 1.8 - коммерческое ПО, не лицензируется для физических лиц и не имеет бесплатных версий. Для использования вы обязаны приобрести лицензию. В настоящее время действует достаточно сложная политика лицензирования и здесь мы не будем касаться этого вопроса во избежание предоставления недостоверной информации.
Для работы системы программ 1С:Предприятие вам понадобится лицензия на сервер 1С:Предприятие или Сервер МИНИ на 5 подключений, лицензию для разработчика на сервер без графического окружения установить не удастся. Также понадобятся отдельные лицензии для клиентских подключений.
Сборка PostgreSQL для 1С от компании Postgres Professional предоставляется бесплатно.
Все команды, если не указано иное, выполняются с правами суперпользователя.
✅ Читать далее: https://interface31.ru/post/ustanovka-servera-1cpredpriyatiya-postgresql-apache2-astra-18se/
Продолжаем тему установки сервера 1С:Предприятие на российские ОС. Сегодня у нас на очереди лидер импортозамещения - Astra Linux SE 1.8, которая широко внедряется во все сферы и вопрос ее использования для 1С:Предприятие стоит достаточно остро.
Несмотря на то, что процесс установки сервера 1С достаточно хорошо документирован, все-таки в каждой операционной системе есть свои особенности, которые могут вызвать затруднения в процессе установки или настройки.
Astra Linux SE 1.8 - коммерческое ПО, не лицензируется для физических лиц и не имеет бесплатных версий. Для использования вы обязаны приобрести лицензию. В настоящее время действует достаточно сложная политика лицензирования и здесь мы не будем касаться этого вопроса во избежание предоставления недостоверной информации.
Для работы системы программ 1С:Предприятие вам понадобится лицензия на сервер 1С:Предприятие или Сервер МИНИ на 5 подключений, лицензию для разработчика на сервер без графического окружения установить не удастся. Также понадобятся отдельные лицензии для клиентских подключений.
Сборка PostgreSQL для 1С от компании Postgres Professional предоставляется бесплатно.
Все команды, если не указано иное, выполняются с правами суперпользователя.
✅ Читать далее: https://interface31.ru/post/ustanovka-servera-1cpredpriyatiya-postgresql-apache2-astra-18se/
👍3👀2👎1🤝1
Пс! Платформа для обмена данными между ИТ-продуктами нужна?
Диасофт открыл доступ к базовому дистрибутиву Digital Q.MessageBroker. Теперь разработчики и ИТ-компании могут скачать базовую версию бесплатно.
Digital Q.MessageBroker создана на базе Apache Kafka. Она решает типовую проблему при переходе от монолитной архитектуры к микросервисной или гибридной + обеспечивает высокую производительность, надежность и безопасность обмена данными.
Инструкция: 4 шага для начала использования Digital Q.MessageBroker ⬇️
1) Скачайте бесплатно Digital Q.MessageBroker.
2) Выполните подключение с помощью полученной ссылки и токена.
3) Создайте свой первый топик.
4) Настройте первый поток сообщений!
📌 И еще факт напоследок: платформа включена в реестр российского программного обеспечения (запись №24351 от 18.10.2024).
#реклама
О рекламодателе
Диасофт открыл доступ к базовому дистрибутиву Digital Q.MessageBroker. Теперь разработчики и ИТ-компании могут скачать базовую версию бесплатно.
Digital Q.MessageBroker создана на базе Apache Kafka. Она решает типовую проблему при переходе от монолитной архитектуры к микросервисной или гибридной + обеспечивает высокую производительность, надежность и безопасность обмена данными.
Инструкция: 4 шага для начала использования Digital Q.MessageBroker ⬇️
1) Скачайте бесплатно Digital Q.MessageBroker.
2) Выполните подключение с помощью полученной ссылки и токена.
3) Создайте свой первый топик.
4) Настройте первый поток сообщений!
📌 И еще факт напоследок: платформа включена в реестр российского программного обеспечения (запись №24351 от 18.10.2024).
#реклама
О рекламодателе
Как Certificate Transparency защищает пользователей и владельцев домена
Вся современная инфраструктура открытых ключей (PKI) стоится на доверии, это очень важный вопрос, потому что, выстраивая отношения доверия с удостоверяющим центром (CA) вы создаете область доверия, соглашаясь безусловно доверять всем его действиям.
На практике это заключается в установке корневого сертификата УЦ, после чего все подписанные им сертификаты также будут считаться доверенными. На практике все конечно немного сложнее, но общий принцип не меняется. Доверяя УЦ, мы доверяем всем выпущенным им сертификатам.
А что, если мы УЦ доверяем, но как бы не до конца, тем более что список корневых сертификатов основных удостоверяющих центров поставляется нам в составе системы. Тем более, что прецеденты уже были, когда удостоверяющие центры по ошибке или злонамеренно выпускали сертификаты без ведома владельца домена.
Такой сертификат позволяет, используя отношения доверия к выпустившему его УЦ совершить атаку человек посередине (MitM), т.е. перехватить, прочитать и/или изменить трафик к легальному ресурсу без ведома пользователя.
Чтобы избежать такого сценария и повысить уровень доверия, а также сделать более прозрачным процесс выдачи сертификатов была придумана и внедрена технология Certificate Transparency.
Certificate Transparency предполагает создание публичных CT-логов, в которых удостоверяющие центры регистрируют все выданные сертификаты. CT-логи построены на основе двоичных деревьев Меркла и допускают только добавление информации, изменить или удалить внесенную запись не получится.
Второй ключевой момент – СT-логи доступны для внешнего аудита и уже сегодня существуют независимые службы, которые занимаются их мониторингом. Это позволяет защитить владельца домена, которого такая служба будет своевременно уведомлять о действиях с его сертификатами.
Допустим, какой-то УЦ «по ошибке» выпустил сертификат без ведома владельца – настоящий владелец получит уведомление об этом и сможет своевременно начать разбирательство, а также уведомить контрагентов, что доверять такому-то сертификату не следует.
Но нас больше интересует каким образом Certificate Transparency защищает пользователей? При регистрации сертификата в CT-логе удостоверяющий центр получает специальную SCT-метку, которую включает в сертификат.
Современные браузеры проверяют не только отношения доверия к выпустившему сертификат УЦ, но и к наличию как минимум двух SCT-меток от разных CT-логов. Ряд браузеров имеет более строгие условия, так Google Chrome или Safari требуют, чтобы одним из CT-логов был лог Google или Apple.
Таким образом информация о любом сертификате добросовестного УЦ будет распространена по большому количеству CT-логов и будет доступна для внешнего аудита, что делает махинации с сертификатами быстро выявляемыми.
Кстати, УЦ Минцифры также поддерживает СТ-логи и выпускает сертификаты только с их поддержкой. С Минцифрой работают службы CT-логов самой Минцифры, Яндекса и ВК.
Может ли УЦ выпустить сертификат, не регистрируя его в CT-логах? Может, но браузеры тут-же пометят такой сертификат не доверенным. Для этого браузеру даже не нужно связываться со службами CT-логов, достаточно отсутствия SCT-меток.
Технически получить STC-метку не регистрируя сертификат в логе можно, для этого нужно знать алгоритм формирования метки и иметь доступ к закрытому ключу лога. И тот же УЦ может провернуть такой фокус со своим CT-логом. Но как быть с остальными?
Сговор? Тоже не поможет, CT-логи публичны и отсутствие там записи для метки будет достаточно быстро обнаружено, что сразу сделает лог недоверенным.
Таким образом Certificate Transparency предоставляет может и не идеальный, но достаточно эффективный инструмент контроля над добросовестностью участников отношений доверия и исходит из принципа – доверяй, но проверяй.
Теперь, даже имея доверительные отношения с УЦ вы можете проверить, что УЦ ведет деятельность прозрачно и регистрирует сертификаты в независимых CT-логах, а при желании можете спокойно ознакомиться с их содержимым.
Вся современная инфраструктура открытых ключей (PKI) стоится на доверии, это очень важный вопрос, потому что, выстраивая отношения доверия с удостоверяющим центром (CA) вы создаете область доверия, соглашаясь безусловно доверять всем его действиям.
На практике это заключается в установке корневого сертификата УЦ, после чего все подписанные им сертификаты также будут считаться доверенными. На практике все конечно немного сложнее, но общий принцип не меняется. Доверяя УЦ, мы доверяем всем выпущенным им сертификатам.
А что, если мы УЦ доверяем, но как бы не до конца, тем более что список корневых сертификатов основных удостоверяющих центров поставляется нам в составе системы. Тем более, что прецеденты уже были, когда удостоверяющие центры по ошибке или злонамеренно выпускали сертификаты без ведома владельца домена.
Такой сертификат позволяет, используя отношения доверия к выпустившему его УЦ совершить атаку человек посередине (MitM), т.е. перехватить, прочитать и/или изменить трафик к легальному ресурсу без ведома пользователя.
Чтобы избежать такого сценария и повысить уровень доверия, а также сделать более прозрачным процесс выдачи сертификатов была придумана и внедрена технология Certificate Transparency.
Certificate Transparency предполагает создание публичных CT-логов, в которых удостоверяющие центры регистрируют все выданные сертификаты. CT-логи построены на основе двоичных деревьев Меркла и допускают только добавление информации, изменить или удалить внесенную запись не получится.
Второй ключевой момент – СT-логи доступны для внешнего аудита и уже сегодня существуют независимые службы, которые занимаются их мониторингом. Это позволяет защитить владельца домена, которого такая служба будет своевременно уведомлять о действиях с его сертификатами.
Допустим, какой-то УЦ «по ошибке» выпустил сертификат без ведома владельца – настоящий владелец получит уведомление об этом и сможет своевременно начать разбирательство, а также уведомить контрагентов, что доверять такому-то сертификату не следует.
Но нас больше интересует каким образом Certificate Transparency защищает пользователей? При регистрации сертификата в CT-логе удостоверяющий центр получает специальную SCT-метку, которую включает в сертификат.
Современные браузеры проверяют не только отношения доверия к выпустившему сертификат УЦ, но и к наличию как минимум двух SCT-меток от разных CT-логов. Ряд браузеров имеет более строгие условия, так Google Chrome или Safari требуют, чтобы одним из CT-логов был лог Google или Apple.
Таким образом информация о любом сертификате добросовестного УЦ будет распространена по большому количеству CT-логов и будет доступна для внешнего аудита, что делает махинации с сертификатами быстро выявляемыми.
Кстати, УЦ Минцифры также поддерживает СТ-логи и выпускает сертификаты только с их поддержкой. С Минцифрой работают службы CT-логов самой Минцифры, Яндекса и ВК.
Может ли УЦ выпустить сертификат, не регистрируя его в CT-логах? Может, но браузеры тут-же пометят такой сертификат не доверенным. Для этого браузеру даже не нужно связываться со службами CT-логов, достаточно отсутствия SCT-меток.
Технически получить STC-метку не регистрируя сертификат в логе можно, для этого нужно знать алгоритм формирования метки и иметь доступ к закрытому ключу лога. И тот же УЦ может провернуть такой фокус со своим CT-логом. Но как быть с остальными?
Сговор? Тоже не поможет, CT-логи публичны и отсутствие там записи для метки будет достаточно быстро обнаружено, что сразу сделает лог недоверенным.
Таким образом Certificate Transparency предоставляет может и не идеальный, но достаточно эффективный инструмент контроля над добросовестностью участников отношений доверия и исходит из принципа – доверяй, но проверяй.
Теперь, даже имея доверительные отношения с УЦ вы можете проверить, что УЦ ведет деятельность прозрачно и регистрирует сертификаты в независимых CT-логах, а при желании можете спокойно ознакомиться с их содержимым.
1👍8
Про ИИ и рынок труда в системном администрировании
В последнее время популярна была точка зрения, что ИИ оставит нас всех без работы, сначала программистов, потом системных администраторов, ну или уронит зарплаты ниже плинтуса. Ну в самом деле, зачем брать на работу дорогого специалиста, если все то же самое сделает вчерашний студент в обнимку с ChatGPT по недорогой подписке?
Но беда пришла откуда не ждали – сегодня что ни день, то ИИ находит очередные критические уязвимости то в том, то в ином продукте. И только успевай латать дыры, хорошо если есть чем.
А с другой стороны, тот же ИИ пишет эксплойты, а ИИ-агенты их применяют. Не успел глазом моргнуть – а тебя уже взломали, и вся твоя инфраструктура превратилась в тыкву, хотя настроил ты все правильно, по самым последним требованиями безопасности.
Только начальству на эти требования плевать с высокой колокольни. У них есть факт инцидента и прямой материальный ущерб. А еще в отечественной корпоративной культуре есть обычай в таких ситуациях не разбираться в причинах и последствиях, а просто искать крайнего.
И хотя системный администратор лицо не материально ответственное, ситуации могут быть самые разные. В лучшем случае неформальный «волчий билет», когда вроде как и разошлись по собственному, но весь город знает, что Вася – косячник, брать его на работу нельзя.
А может быть и совсем по-другому, когда просто нагрузят как верблюда и начнут действовать вне правового поля. Но при этом не нарушая норм УК РФ.
Ну и что делать, куда деваться? Если админ в своей конторе един во всех лицах, то ему придется брать на себя функцию ИБ и постоянно мониторить все уязвимости используемых продуктов и оперативно реагировать на все уязвимости и исправления.
Если есть своя ИБ, то с одной стороны полегче, а с другой и не очень. ИБ – она как КПСС – имеет роль направляющую, а на земле все их рекомендации внедрять именно админу и его же в случае чего назначат крайним.
В итоге получается, что работы серьезно так прибавилось, а зарплата как была, так и осталась. И на все вопросы о ее повышении будет стандартный ответ – а что вы там делаете такого, что утомились? Весь день за компьютером сидите.
А учитывая то, что многие коллеги просто не умеют разговаривать с топами на языке бизнеса, то весь этот лепет про ИИ, уязвимости нулевого дня и прочее бизнес всерьез не воспринимает.
Но админ, если не дурак, прекрасно понимает кто окажется крайним и видит две невеселые альтернативы: или взвалить все на себя без повышения оплаты или идти искать новую отрасль применения своих умений и навыков.
Первый случай хорошо описывается народной поговоркой: сношали до пота, за кружку компота.
Второй тоже не лучше, так как придется уходить с позиции уверенного специалиста на позицию начинающего. Многим это просто морально тяжело. Но в долгую – это спокойнее и безопаснее.
Здесь не будет ни выводов, ни морали. Это ситуация на рынке труда, как ее видим мы. Если у вас иное мнение – ждем в комментариях.
В последнее время популярна была точка зрения, что ИИ оставит нас всех без работы, сначала программистов, потом системных администраторов, ну или уронит зарплаты ниже плинтуса. Ну в самом деле, зачем брать на работу дорогого специалиста, если все то же самое сделает вчерашний студент в обнимку с ChatGPT по недорогой подписке?
Но беда пришла откуда не ждали – сегодня что ни день, то ИИ находит очередные критические уязвимости то в том, то в ином продукте. И только успевай латать дыры, хорошо если есть чем.
А с другой стороны, тот же ИИ пишет эксплойты, а ИИ-агенты их применяют. Не успел глазом моргнуть – а тебя уже взломали, и вся твоя инфраструктура превратилась в тыкву, хотя настроил ты все правильно, по самым последним требованиями безопасности.
Только начальству на эти требования плевать с высокой колокольни. У них есть факт инцидента и прямой материальный ущерб. А еще в отечественной корпоративной культуре есть обычай в таких ситуациях не разбираться в причинах и последствиях, а просто искать крайнего.
И хотя системный администратор лицо не материально ответственное, ситуации могут быть самые разные. В лучшем случае неформальный «волчий билет», когда вроде как и разошлись по собственному, но весь город знает, что Вася – косячник, брать его на работу нельзя.
А может быть и совсем по-другому, когда просто нагрузят как верблюда и начнут действовать вне правового поля. Но при этом не нарушая норм УК РФ.
Ну и что делать, куда деваться? Если админ в своей конторе един во всех лицах, то ему придется брать на себя функцию ИБ и постоянно мониторить все уязвимости используемых продуктов и оперативно реагировать на все уязвимости и исправления.
Если есть своя ИБ, то с одной стороны полегче, а с другой и не очень. ИБ – она как КПСС – имеет роль направляющую, а на земле все их рекомендации внедрять именно админу и его же в случае чего назначат крайним.
В итоге получается, что работы серьезно так прибавилось, а зарплата как была, так и осталась. И на все вопросы о ее повышении будет стандартный ответ – а что вы там делаете такого, что утомились? Весь день за компьютером сидите.
А учитывая то, что многие коллеги просто не умеют разговаривать с топами на языке бизнеса, то весь этот лепет про ИИ, уязвимости нулевого дня и прочее бизнес всерьез не воспринимает.
Но админ, если не дурак, прекрасно понимает кто окажется крайним и видит две невеселые альтернативы: или взвалить все на себя без повышения оплаты или идти искать новую отрасль применения своих умений и навыков.
Первый случай хорошо описывается народной поговоркой: сношали до пота, за кружку компота.
Второй тоже не лучше, так как придется уходить с позиции уверенного специалиста на позицию начинающего. Многим это просто морально тяжело. Но в долгую – это спокойнее и безопаснее.
Здесь не будет ни выводов, ни морали. Это ситуация на рынке труда, как ее видим мы. Если у вас иное мнение – ждем в комментариях.
👍9❤6👎1
Материальная ответственность системного администратора
Продолжаем юридическую серию, направленную на повышение правовой грамотности коллег. Посильную помощь в составлении данного материала мне оказал мой хороший друг – практикующий адвокат.
Начнем с материальной ответственности. Несет ли ее системный администратор? Безусловно несет. Обратимся к Трудовому кодексу:
Статья 238. Материальная ответственность работника за ущерб, причиненный работодателю
Работник обязан возместить работодателю причиненный ему прямой действительный ущерб. Неполученные доходы (упущенная выгода) взысканию с работника не подлежат.
Под прямым действительным ущербом понимается реальное уменьшение наличного имущества работодателя или ухудшение состояния указанного, а также необходимость для работодателя произвести затраты либо излишние выплаты на приобретение, восстановление имущества.
Есть ли случаи, когда администратор может быть освобожден от материальной ответственности? Есть.
Статья 239. Обстоятельства, исключающие материальную ответственность работника
Материальная ответственность работника исключается в случаях возникновения ущерба вследствие непреодолимой силы, нормального хозяйственного риска либо неисполнения работодателем обязанности по обеспечению надлежащих условий для хранения имущества.
Самое интересное в этом пункте - нормальный хозяйственный риск. Что это такое? Читаем:
К нормальному хозяйственному риску могут быть отнесены действия работника, соответствующие современным знаниям и опыту, когда поставленная цель не могла быть достигнута иначе, работник надлежащим образом выполнил возложенные на него должностные обязанности, проявил определенную степень заботливости и осмотрительности, принял меры для предотвращения ущерба, и объектом риска являлись материальные ценности, а не жизнь и здоровье людей.
Т.е. если администратор действовал согласно установленной инструкции, руководству по эксплуатации ПО и т.д. и т.п., то даже если такие действия повлекли ущерб материальной ответственности сотрудник не подлежит.
Следующий тонкий момент – полная материальная ответственность.
Статья 242. Полная материальная ответственность работника
Полная материальная ответственность работника состоит в его обязанности возмещать причиненный работодателю прямой действительный ущерб в полном размере.
Так, секунду, а что есть не полная? Да, есть:
Статья 241. Пределы материальной ответственности работника
За причиненный ущерб работник несет материальную ответственность в пределах своего среднего месячного заработка.
А вот здесь становится действительно интересно, но на помощь нам приходит:
Постановление Минтруда РФ от 31.12.2002 N 85 «Об утверждении перечней должностей и работ, замещаемых или выполняемых работниками, с которыми работодатель может заключать письменные договоры о полной индивидуальной или коллективной ответственности»
Должности системного администратора там нет. Поэтому любая попытка внести такие условия в трудовой договор или иные соглашения с сисадмином являются незаконными.
Но не стоит расслабляться раньше времени:
Статья 243. Случаи полной материальной ответственности
Материальная ответственность в полном размере причиненного ущерба возлагается на работника в следующих случаях:
3) умышленного причинения ущерба;
4) причинения ущерба в состоянии алкогольного, наркотического или иного токсического опьянения;
5) причинения ущерба в результате преступных действий работника, установленных приговором суда;
6) причинения ущерба в результате административного правонарушения, если таковое установлено соответствующим государственным органом;
8) причинения ущерба не при исполнении работником трудовых обязанностей.
Как видим, из правила есть исключения, которые отлично покрывают ситуации «работодатель козел, сменю пароли, поставлю тайм-бомбу, сделаю еще какую-нибудь пакость».
Поэтому будьте благоразумны, не давайте нарушать свои права, но в тоже время не допускайте противоправных действий по отношению к работодателю. Надеемся, данный материал будет вам полезен.
Продолжаем юридическую серию, направленную на повышение правовой грамотности коллег. Посильную помощь в составлении данного материала мне оказал мой хороший друг – практикующий адвокат.
Начнем с материальной ответственности. Несет ли ее системный администратор? Безусловно несет. Обратимся к Трудовому кодексу:
Статья 238. Материальная ответственность работника за ущерб, причиненный работодателю
Работник обязан возместить работодателю причиненный ему прямой действительный ущерб. Неполученные доходы (упущенная выгода) взысканию с работника не подлежат.
Под прямым действительным ущербом понимается реальное уменьшение наличного имущества работодателя или ухудшение состояния указанного, а также необходимость для работодателя произвести затраты либо излишние выплаты на приобретение, восстановление имущества.
Есть ли случаи, когда администратор может быть освобожден от материальной ответственности? Есть.
Статья 239. Обстоятельства, исключающие материальную ответственность работника
Материальная ответственность работника исключается в случаях возникновения ущерба вследствие непреодолимой силы, нормального хозяйственного риска либо неисполнения работодателем обязанности по обеспечению надлежащих условий для хранения имущества.
Самое интересное в этом пункте - нормальный хозяйственный риск. Что это такое? Читаем:
К нормальному хозяйственному риску могут быть отнесены действия работника, соответствующие современным знаниям и опыту, когда поставленная цель не могла быть достигнута иначе, работник надлежащим образом выполнил возложенные на него должностные обязанности, проявил определенную степень заботливости и осмотрительности, принял меры для предотвращения ущерба, и объектом риска являлись материальные ценности, а не жизнь и здоровье людей.
Т.е. если администратор действовал согласно установленной инструкции, руководству по эксплуатации ПО и т.д. и т.п., то даже если такие действия повлекли ущерб материальной ответственности сотрудник не подлежит.
Следующий тонкий момент – полная материальная ответственность.
Статья 242. Полная материальная ответственность работника
Полная материальная ответственность работника состоит в его обязанности возмещать причиненный работодателю прямой действительный ущерб в полном размере.
Так, секунду, а что есть не полная? Да, есть:
Статья 241. Пределы материальной ответственности работника
За причиненный ущерб работник несет материальную ответственность в пределах своего среднего месячного заработка.
А вот здесь становится действительно интересно, но на помощь нам приходит:
Постановление Минтруда РФ от 31.12.2002 N 85 «Об утверждении перечней должностей и работ, замещаемых или выполняемых работниками, с которыми работодатель может заключать письменные договоры о полной индивидуальной или коллективной ответственности»
Должности системного администратора там нет. Поэтому любая попытка внести такие условия в трудовой договор или иные соглашения с сисадмином являются незаконными.
Но не стоит расслабляться раньше времени:
Статья 243. Случаи полной материальной ответственности
Материальная ответственность в полном размере причиненного ущерба возлагается на работника в следующих случаях:
3) умышленного причинения ущерба;
4) причинения ущерба в состоянии алкогольного, наркотического или иного токсического опьянения;
5) причинения ущерба в результате преступных действий работника, установленных приговором суда;
6) причинения ущерба в результате административного правонарушения, если таковое установлено соответствующим государственным органом;
8) причинения ущерба не при исполнении работником трудовых обязанностей.
Как видим, из правила есть исключения, которые отлично покрывают ситуации «работодатель козел, сменю пароли, поставлю тайм-бомбу, сделаю еще какую-нибудь пакость».
Поэтому будьте благоразумны, не давайте нарушать свои права, но в тоже время не допускайте противоправных действий по отношению к работодателю. Надеемся, данный материал будет вам полезен.
👍7