Безопасное извлечение устройства в Windows 10 и 11

Что такое безопасное извлечение устройства знают все, правда не все знают для чего именно оно нужно. Некоторые ошибочно считают, что безопасное отключение предназначено для предотвращения физического повреждения устройства. Однако это не так.

При безопасном извлечении в Windows XP действительно отключалось питание устройства, потом от этой практики отказались и с электрической точки зрения безопасное извлечение ничем не отличается от обычного.

Основное назначение безопасного отключения – это предотвратить потерю данных принудительно сбросив на устройство кеш записи, который использовался для ускорения работы с внешними накопителями.

Однако начиная с Windows 10 1809 кеширование для внешних накопителей по умолчанию отключено и для них используется политика Быстрое удаление (Quick removal), это означает что все внешние накопители можно безопасно извлекать без использования одноименной процедуры.

Такой подход несколько снижает производительность, но делает работу с флешками более простой и надежной, поэтому мы не видим смысла менять эту политику.

Другое дело, когда вы используете внешние диски и сценарий работы с ними отличается от подключил – скопировал – отключил. В этом случае имеет смысл вернуть кеширование включив политику Оптимальная производительность (Better performance).

Почему после внесения изменений в конфигурацию брандмауэра лучше перезагрузить роутер

Эта история произошла на днях с одним коллегой. В очередной раз внося изменения в конфигурацию брандмауэра Mikrotik он обнаружил правила, которые, согласно комментариям, относились к IPsec, который уже давно не использовался.

Он сбросил на них счетчики и несколько дней понаблюдал – счетчики не менялись. После чего он просто выключил эти правила. Ничего не сломалось и все продолжило работать как работало. На том он благополучно и забыл об этой истории.

Напомнила она о себе совсем недавно. Менеджеры стали жаловаться, что обмен с некоторыми точками происходит ну очень медленно.

Стали разбираться и выяснилось, что не так давно отвалились все входящие L2TP-соединения от точек и трафик для них пошел по медленному резервному пути.

А почему отвалились? Потому что не смогли собрать IPsec, по причине выключенных правил брандмауэра.

Так погодите, но работало же все? Правила еще когда изменились, а случилось все только сейчас.

Но это вполне нормальное поведение, в любом правильно настроенном брандмауэре на базе iptables, включая Mikrotik, первым в цепочках стоит правило, разрешающее уже установленные соединения – ESTABLISHED. И все существующие соединения будут проходить именно через него, не двигаясь по цепочкам дальше.

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

В нашем случае триггером стала перезагрузка роутера. После чего L2TP соединения, которые из установленных стали новыми устанавливаться перестали.

Поэтому, если вы не хотите неприятных неожиданностей в самый неподходящий момент – после внесения изменений в брандмауэр обязательно перезагрузите роутер. Возможно, узнаете много интересного.
 
Альтернативой этому может послужить сброс соединений в Connection Tracker, но для этого еще нужно знать, какие соединения сбрасывать. Или сбросить вообще все, что фактически равноценно перезагрузке роутера. Поэтому лучше и надежнее все-таки перезагрузить.

Вектор развития

Дискуссия на тему развития сотрудника и развития инфраструктуры предприятия - тема вечная. Многие ставят между этими понятиями знак равенства, хотя это совсем не так.

Мы уже много раз писали на эту тему, поэтому не будем повторяться, но акцентируем внимание на ключевых тезисах. Сотрудник ≠ Бизнес (как бы иногда бизнесу и не хотелось продвинуть иную мысль).

Бизнес занимается зарабатыванием денег, в чем его основной интерес. Сотрудник продает свое время и квалификацию за деньги – и никак иначе. А как по-другому? Бизнес его содержать в случае чего будет? Ага, держите карман шире.

Поэтому интересы у сотрудника и бизнеса разные, в чем-то они совпадают, в чем-то расходятся. И это нормально. Не нормально, когда одна из сторон начинает путать собственные интересы с интересами контрагента, ни к чему хорошему это не приводит.

Начнем с интересов бизнеса. Основной интерес- это получение прибыли. Прибыль – основа стабильной работы и развития предприятия. Падение прибыли приводит к экономии, в том числе и на ФОТ, сокращению рабочих мест и т.д. и т.п.

В этом плане интересы сотрудника и бизнеса совпадают, сотрудник также заинтересован в нормальном функционировании бизнеса, иначе он потеряет в деньгах и, возможно, лишится рабочего места.

Бизнес также заинтересован в удержании сотрудников, особенно тех, кого нельзя просто заменить с улицы. Но этот момент нужно понимать правильно, бизнес – не благотворительность. Если на линейную должность на улице стоит очередь – то и оклад там будет по нижней планке и выжимать будут все соки.

А вот если это ключевой квалифицированный сотрудник, на которого завязаны многие важные бизнес-процессы, то подход будет совершенно иной. Потому что у бизнеса здесь прямой интерес, совпадающий с интересом сотрудника.

Но вернемся к IT – это такая сфера, которая никогда не стоит на месте и если мы хотим быть актуальными на рынке труда – то нужно постоянно развиваться. Никому не нужен сотрудник или подрядчик, который владеет технологиями десятилетней давности, пусть даже и в совершенстве.

Поэтому интерес сотрудника развиваться вполне естественен и понятен. И еще ему хочется совместить приятное с полезным, а именно развиваться в рамках собственного предприятия за его счет и на его ресурсах.

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

Вместо современных технологий может внедряться разные сложные и специфичные вещи, которые сотруднику не интересны. Ну не видит он куда их можно применить за воротами именно этого работодателя и кому продать их на рынке труда.

А бизнесу, в свою очередь, могут быть не нужны все эти докеры, куберы и прочие современные технологии, у него другие задачи и потребности.

В результате возникает расхождение интересов, вектор развития предприятия не совпадает с вектором развития сотрудника и это нормально.

Для примера возьмем известную сеть Красное и Белое, информационная система у них до сих пор построена на устаревшей платформе 1С:Предприятие 7.7. Можно ли при этом сказать, что инфраструктура компании не развивается?

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

Но это курс бизнеса, который не совпадает с курсом сотрудника. Кому нужен в 2026 году специалист по «клюшкам» (жаргонное название 1Сv77)? Никому. Да, отнесутся с уважением, мол «монстр», но не более, на рынке труда спроса на таких специалистов нет.

Какой выбор у сотрудника? А выбор невелик, либо связать свою карьеру именно с этой компанией и развиваться в общем направлении, понимая, что за забором перспектив нет, или начать движение по собственному вектору, приобретая знания и навыки, востребованные современным рынком.

Допустимые типы контента для хранилищ Proxmox

Собрали в небольшую, но полезную таблицу допустимые типы контента для разных типов хранилищ.

С ее помощью можно быстро оценить какой тип хранилища лучшим образом подходит для ваших задач.

Вся информация взята из официальных источников.

Поводом для создания подобной таблички послужили злоключения молодого коллеги, который потратил время на установку и настройку iSCSI-таргета, но только подключив его к Proxmox обнаружил, что оно не поддерживает LXC-контейнеры.

Вектор развития. Продолжение

Читатели задали очень хороший вопрос: а в чем смысл развития сотрудника по собственному вектору, вне трека предприятия? Ведь работодателю нужны не знания, а опыт – и он совершенно прав.

Что такое знания? Это просто теория. А опыт – это умение применять знания на практике. И платят хорошему специалисту именно за опыт, а не за знания. Так что получается? Менять работу?

Разные гуру и коучи бодро скажут – да! Не бойся меняться, отбрось страхи и неуверенность и вперед к новым вершинам! Но языком истории рассказывать, это не мешки разгружать, поэтому вернемся в суровую реальность.

Что значит поменять работу ради перспектив развития? Вы уходите с крепкой позиции (мидл или даже сеньор) в своем стеке на позицию начинающего (джуниора) в новом стеке, проседая как в зарплате, так и в разных прочих плюшках, включая ценность вас в глазах работодателя.

И хорошо если вам 20 с хвостиком и у вас за плечами нет детей, кредитов, ипотек, жены, тещи и стареньких родителей.

А в ином раскладе эта авантюра является именно авантюрой, с непонятным итоговым результатом. Оставить все как есть? Тоже опасно. В этом случае вы станете заложником вашего работодателя, особенно если он поймет, что за его воротами вы по факту «человек без профессии».

Как быть? Что делать? К счастью, мы живем в современном мире и не связаны именно своей локацией. Если вы понимаете, что вам надо развиваться, но в рамках своего рабочего места вы не можете этого сделать – то к вашим услугам сеть.

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

А работодатель вполне может оценить вашу активность в проекте и прикинуть возможный опыт, который перекроет ваш опыт с прошлой работы. Мол, да, на старом месте он со всякой ерундой работал, но вот же проект вел, активно. Нам такие нужны.

Другой вариант – пет-проекты, это тоже хороший способ рассказать о себе и показать свои умения. Особенно если этот проект имеет практическое применение. А для этого можно найти себе какое-нибудь небольшое предприятие, на котором это обкатывать в свободное от работы время.

Малый бизнес он вообще не избалован вниманием и стеснен в средствах и если вы ему за сумму малую предложите стать «подопытным кроликом» и выгоды для него будет больше чем возможного убытка – он согласится.

Также не забывайте про профессиональные сообщества. Если брать мир 1С, то тот же Инфостарт. Написали отчет или обработку? Опубликуйте. И не важно, что там есть уже сотни таких же, важен сам факт публикации. Из которых потом соберется ваше портфолио.

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

И не стесняйтесь продвигать себя везде, где это возможно. Есть возможность что-то написать или опубликовать в техническом сообществе – напишите и опубликуйте. Есть возможность поехать на конференцию – езжайте.

В общем – чем больше вы засветитесь в профессиональных тусовках – тем лучше. Это та же самая строчка в резюме про опыт. Да, вы работали с устаревшим стеком, но в сообществе вас знают как грамотного специалиста по новому стеку. И это будет ваш плюс при смене работы.

Теперь вы сможете поменять рабочее место примерно с равной позиции на равную. Но, главное, вы должны быть, а не казаться. Иначе может быть очень больное приземление, когда вы уже не там и не здесь. И куда теперь идти – непонятно.

Но если вы реально втянулись в новую тему, активны в профессиональных сообществах, имеете публикации и проекты, то всем будет все равно на ваш бэкграунд, вас будут воспринимать как современного специалиста с опытом, что вам и надо.

Спрашивают – отвечаем

Вопрос вот в чем: есть энтерпрайз SSD за очень много денег, там все ок. А как быть бедным, кто ставит nvme в лучшем случае из топа потребительских? Что выбрать, на что смотреть?

Начнем с того, что выбрать можно все что угодно, даже не из топа, все зависит от доступного бюджета. Но перед выбором нужно внимательно посмотреть.

Начнем с того, что пишут в спецификациях. А именно с ресурса. Это основной показатель, от которого зависит как часто вы будете менять диски. Соизмеряем его с текущей нагрузкой и прикидываем затраты. Может оказаться так, что взять более дорогой диск будет выгоднее.

А может произойти ровно наоборот. Иногда выгоднее чаще менять дешевые диски, чем дорогие, но реже.

При этом следует понимать, что никакой серебряной пули в потребительском сегменте нет. Все упирается в ресурс. Это для настольного компьютера вы покупаете топовый Samsung и несколько лет радуетесь жизни.

В случае серверного применения ресурс дорого Samsung будет тратиться также быстро, как и ресурс более дешевого аналога. А если все равно через год менять, то можно не выпендриваться и взять что-нибудь попроще.

Дальше смотрим на еще один важный параметр: модель работы SLC-кеша. В описаниях его нет, тут помогут только обзоры. Например, есть полностью аппаратно одинаковые диски, но с разными вариантами кеширования и разным поведением под нагрузками.

Грубо говоря, есть два основных варианта. В первом под кеш отдается все свободное место (33% от свободной емкости накопителя TLC), который пишется на максимальной скорости. А вот потом наступает самый плохой для диска сценарий – контроллер одновременно пишет и уплотняет данные и скорость там может упасть до неприлично низких значений.

Второй вариант – небольшой кеш и потом достаточно высокая и стабильная скорость записи, но далеко уже не та, что указана в спецификациях диска.

Тут нельзя однозначно сказать, что хорошо, а что плохо, смотрите по своим задачам и нагрузкам. Где-то лучше себя покажет одна модель кеширования, где-то другая.

Определились, хорошо. Теперь обращаем внимание на потребительские характеристики. В частности, на теплоотвод и возможность его снять без потери гарантии. Лучше всего брать модели, где теплоотвод сразу не приклеен, ну или понимать, что гарантии на диск у вас не будет.

Почему? Да потому что серверная нагрузка сильно отличается от настольной и вашему диску в обязательном порядке нужен хороший теплоотвод, иначе он постоянно будет находится в состоянии перегрева или близкого к нему.

Чтобы оградить себя от внезапного отказа в обязательном порядке собираем RAID. И в этом случае нам важно добиться идентичных режимов работы у обоих дисков.

Если вы используете разъемы на материнской плате – убедитесь, что к ним подведено одинаковое количество линий PCIe и одинакового поколения.

Иначе ваш массив будет работать на скорости самого медленного диска и это в лучшем случае.

Также очень важно еще и соблюдать идентичность скоростных характеристик дисков, в частности режимов кеширования. Если один диск продолжает принимать данные на полной скорости, а второй ее резко снизил, то есть ненулевые шансы, что такой диск выкинет из массива, хотя он будет полностью исправен.

Либо мы получим резкую деградацию производительности, иногда буквально «на ровном месте».

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

Если это невозможно – меняйте оба диска. Также не следует сочетать в одном массиве диски на разных поколениях шины PCIe, итоговая скорость записи может упасть ниже скорости самого медленного диска.

Ну и постоянный мониторинг. Температуры, ресурса и свободного места на массиве. Не допускайте заполнения более 60-70%, лучше всего иметь запас примерно на 50%, иначе задумайтесь о приобретении более емких моделей.

Также заведите за правило менять диски раз в три года (средний срок гарантии) даже если с ними все в порядке. Кстати это касается не только NVMe.

Особенности использования райзеров для M.2 NVMe дисков

В комментариях подняли интересную тему – райзеры для M.2 дисков, что это такое? Говоря простым языком – это плата переходник, которая позволяет подключиться к штатному слоту PCIe x16 материнской платы и на полной скорости от процессора подключить до 4 NVMe дисков.

Но не все так просто в нашем мире. Нет, сама идея райзера хороша, вы не только получаете 4 диска на полной пропускной способности шины, но еще и выносите их в сторону от горячих участков материнской платы, а многие модели райзеров, как показанная на рисунке модель от ASRock, обеспечивают еще и отличное охлаждение.

Основная проблема кроется в линиях PCIe, которые конечны и которые должны быть правильно сконфигурированы. Самые распространенные райзеры – пассивные, т.е. просто плата переходник с одного разъема на другой. Без какого-либо преобразования.

И тут нам нужно не просто подать туда PCIe x16, а заставить контроллер (который в процессоре) работать в режиме x4/x4/x4/x4. Только в этом случае у нас будут видеться и работать все четыре диска райзера.

А дальше уже все не так просто и сильно зависит от железа. Начнем с процессоров AMD.

Процессоры AMD старших серий предоставляют пользователю 24 линии PCIe, 16 из них идут на первый слот для видеокарты, еще 4 линии на разъем M.2, остальные разводятся по дополнительным разъемам в самых разных вариациях.

Но если процессор содержит встроенное видеоядро, которому самому нужны PCIe линии, то решается это по-разному, в сериях AM4 (Ryzen 3000G / 4000G / 5000G) вместо PCIe 4.0 вы получите те же 24 линии PCIe 3.0.

А вот в новых сериях AM5 (Ryzen 8000G) линии сильно урезаны. На старших моделях (8700G/8600G) под основной GPU-слот выделено только 8 линий PCIe 4.0. На младших (8500G/8300G) — всего 4 линии на основной слот.

Но при этом процессоры AMD, если это реализовано в BIOS материнской платы поддерживают бифуркацию до x4/x4/x4/x4, никаких проблем с этим нет.

Кроме процессора линии PCIe может предоставлять чипсет, но он связан с процессором 4 линиями PCIe и может служить узким горлышком, особенно если вы используете сеть 2,5 G и выше или прочие линии от чипсета.

Поэтому нормальная практика в том, что чипсет предоставляет линии предыдущего поколения, если у процессора поддержка PCIe 4.0, то чипсет будет отдавать линии PCIe 3.0 и вряд ли вы найдете платы, где чипсет отдает 16 линий.

Если перейти в стан их конкурентов, то у Intel не все так радужно. Если мы берем процессоры LGA1700 — Core 12, 13, 14 поколений, то там пользователю доступно 20 линий PCIe, 16 на основной слот, 4 для NVMe.

Для LGA1851 — Core Ultra 200S / Arrow Lake количество линий было увеличено до 24 и делятся они как 16 линий на основной слот, а остальные 8 на два M.2 разъема.

Но процессоры Intel не поддерживают бифуркацию до x4/x4/x4/x4, максимум x8/x4/x4, что не дает возможности полноценно использовать пассивные райзеры.

Из хороших новостей: для общения с чипсетом процессор использует шину DMI 4.0 x8, что аналогично восьми линиям PCIe 4.0 и чипсетные линии не являются узким горлышком, ну а как и кто их развел – это уже надо спрашивать с производителей плат.

Если ваша плата или процессор не поддерживают полноценную бифуркацию до x4/x4/x4/x4, то вам нужен активный райзер, на котором установлен дополнительный чип PCIe коммутатора (моста) и который сам разложит поступившие ему 16 линий на 4 набора по 4 линии, но такие райзеры дороже.

Поэтому нельзя просто так купить и поставить райзер, а надо изучить структуру своей материнской платы, процессора и их совместные возможности, иначе можно очень сильно разочароваться.

Деградация данных

Деградация данных (bitrot, битовое гниение) – это достаточно актуальный в настоящее время тип разрушения цифровых данных вследствие накопления некритичных ошибок на запоминающем устройстве.

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

С бед-блоками достаточно эффективно позволяет справляться RAID, когда в случае ошибки чтения блок заменяется резервным, а его содержимое считывается с исправной копии. Да, возможен эффект появления скрытых бед-блоков, но он решается периодическом перечитыванием содержимого массива.

Проблема битового гниения лежит глубже и именно этот термин представляется нам наиболее удачным. Как и обычное гниение он медленно и незаметно повреждает данные до тех пор, пока разрушения не перейдут в критическую фазу.

Причинами битового гниения становятся ошибки в процессе записи, не связанные с повреждением непосредственно ячеек, они могут даже произойти в оперативной памяти и при отсутствии ECC ваши данные также могут быть незаметно повреждены.

Чаще всего деградация данных происходит при длительном хранении, вследствие деградации заряда ячейки или уровня намагниченности сектора. Ошибок чтения с накопителя это не вызывает, но приводит к нарушению целостности данных.

Как правило большинство современных форматов данных имеют избыточность и изменение одного бита может быть откорректировано встроенными средствами, но для этого эти данные нужно хотя бы открыть.

В противном случае подобные ошибки могут накапливаться и в определенный момент привести к невосстановимому повреждению данных. При этом процесс битового гниения не сопровождается ошибками чтения с накопителя и может происходить на полностью исправном диске.

А так как нет никаких ошибок, то и RAID вам ничем не поможет, особенно уровни без четности. Так, например, в случае зеркала у нас могут оказаться изменены биты в произвольных местах обеих копий. И чем больше по размеру файл и реже обращения к нему – тем вероятнее такое развитие событий.

Некоторую защиту могут предоставлять массивы с четностью (RAID 5 и 6), но здесь многое зависит от контроллера или программной реализации, главное у которых – уметь производить такую проверку в фоновом режиме.

В таком случае имея одну правильную копию и целые данные четности массив может проверить целостность данных и автоматически восстановить их.

Но оптимальным решением проблемы будет вынос таких проверок на уровень файловой системы, так как это позволяет действовать наиболее эффективно и с наименьшей нагрузкой на систему.

Современные системы с контролем целостности – это ZFS, btrfs и ReFS – и именно они рекомендуются для систем хранения больших объемов информации. Каждая из них умеет в фоновом режиме проверять целостность файлов и восстанавливать поврежденные фрагменты используя контрольные суммы (при наличии избыточности, разумеется).

И именно по этой причине тот же Proxmox категорически не рекомендует использование mdadm для хранилищ виртуальных машин в производственных средах.

Почему доступ в интернет по белым спискам это плохая идея

Каждый раз, когда обсуждается вопрос ограничения доступа в интернет поднимается тема белых списков. Казалось бы, что там сложного? Запретил все и разрешил нужное, теперь можно спать спокойно.

Сделать это можно несколькими способами. При помощи списков адресов, когда адрес назначения сравнивается с заранее составленным списком и либо разрешается, либо блокируется. Пример такой настройки на оборудовании Mikrotik вы можете найти в статье:

🔹 Настройка черного и белого списков в роутерах Mikrotik

Второй вариант – это настройка собственного фильтрующего DNS-сервера. Принцип работы его схож с первым методом, но производится на уровне DNS-запросов, еще до того, как браузер попытается открыть страницу.

Для разрешенных доменов имя исправно разрешается в IP-адрес, для всех иных сервер отвечает, что такого домена не существует. Более подробно это описано в статье:

🔹 Создаем собственный фильтрующий DNS-сервер на базе Pi-hole

Но если попытаться реализовать указанными способами белый список, то вам придется столкнуться с многими сложностями.

Дело в том, что современный сайт – это технически сложный программный продукт и далеко не все его компоненты расположены на одном с ним домене.

Первая сложность настигнет вас буквально сразу, браузер не сможет проверить сертификат. Почему? Потому что ему нужен доступ с CRL (списку отозванных сертификатов), адрес которого указан в сертификате.

Его нужно выяснить и добавить в белый список. Причем таких адресов может быть несколько и для следующего сайта с сертификатом этого же УЦ адрес может быть иным.

Ок, с сертификатами разобрались, но почему вместо сайта белая страница? Или он очень долго загружается?

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

Для чего так делается? По нескольким причинам. Основная – скорость доставки, скрипты расположенные на CDN доставляются пользователю одинаково быстро в любой точке мира, не загружают канал сайта и не оказывают нагрузки на сервер.

Вторая – это поддержание актуальных версий скриптов используя общедоступные репозитории, где они будут автоматически обновляться в пределах текущей версии при обнаружении багов или уязвимостей.

Ладно, нашли эти адреса и добавили. Но что это? Почему он так выглядит? Что это за кошмар?

Все просто, со сторонних ресурсов также подтягиваются шрифты и элементы оформления. И что? И снова ищем откуда и снова добавляем, добавляем, добавляем…

Нет картинок и мультимедийного содержимого? Снова ищем с каких CDN они распространяются, а их может быть и не один адрес. Т.е. сегодня все показывает нормально, а завтра в коде страницы другой CDN и снова начинайте сначала.

Ну вроде победили… Но радоваться рано. Пробуем войти на сайт и ничего не работает. Потому что вход реализован через сторонние сервисы вроде ЕСИА, соцсетей, Яндекса и т.д.

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

И таких проблем может быть очень много и не все из них всплывут сразу. Поэтому заниматься подобной ерундой не имеет никакого практического смысла. В реальности достаточно заблокировать десяток сайтов – пожирателей времени, если вопрос именно в этом.

Единственный вариант, когда белый список оправдан, это когда криво работающий сайт будет наименьшим злом, по сравнению с открывшимся сторонним. Такой подход актуален, например, в образовании, где если проверка откроет не тот сайт, то проблем не избежать.

В остальном будьте благоразумны и ищите адекватные решения для поставленных задач.

Форматируем раздел как ReFS в Windows 10/11

Файловая система ReFS была представлена в 2012 году и имеет ряд существенных преимуществ над своей предшественницей – NTFS. Также она имеет ряд особенностей и ограничений.

Например, на ReFS не может быть расположен загрузочный том, поэтому установить систему на эту ФС не удастся.

Подробнее обо всем этом можно почитать в первоисточнике: https://learn.microsoft.com/ru-ru/windows-server/storage/refs/refs-overview

Первоначально ReFS была доступна без ограничений как в клиентских, так и серверных выпусках ОС Windows, но это продолжалось недолго.

Начиная с выпуска 1709 в Windows 10 убрали поддержку ReFS для всех редакций кроме Professional for Workstation и Enterprise.

Но убрали ее по-хитрому: просто отключили возможность форматировать разделы в ReFS, сама же поддержка этой файловой системы была сохранена в полноценном виде.

Это, кстати, вполне объяснимо: ломать совместимость для пользователей уже успевших отформатировать диски в ReFS никто не рискнул.

Да и толку от этой затеи немного, поддержка файловых систем реализована на уровне ядра и выпилить ее полностью – задача непростая. А все остальное достаточно легко обходится различными твиками.

В общем Microsoft поступили в своем репертуаре, сначала дали попробовать, потом спрятали.

Но они бы не были собой, если бы с последними обновлениями Windows 11 не случилось второго пришествия ReFS под видом «дисков для разработки», о чем мы писали в дневной заметке.

Однако, если вам нужна ReFS не следует бежать за Windows 11 и срочно обновлять ее. Можно поступить проще.

Энтузиастом создана утилита mkrefs, которая позволяет быстро и просто отформатировать любой том в ReFS в любых выпусках Windows 10 и 11.

Скачать ее можно с репозитория разработчика на Github: https://github.com/0xbadfca11/mkrefs

Чтобы использовать утилиту вам потребуется создать том и присвоить ему букву, можно без форматирования, либо переформатировать уже существующий.

Чтобы получить справку просто запустите утилиту без ключей. В самом простом виде, с параметрами по умолчанию, можем отформатировать том под ReFS так:

mkrefs E: /X

Ключ /X используется для форсирования форматирования, полезно если вы переформатируете уже существующую файловую систему, на которой могут быть открытые файловые дескрипторы.

Также доступны ключи:

▫️ /V:label – метка тома, задаем произвольно, при наличии пробелом заключаем в кавычки

▫️ /A:{4096 | 64K} – размер блока файловой системы, по умолчанию 4К

▫️ /I:{enable | disable} – включение проверки целостности файловой системы, по умолчанию выключено

Например:

mkrefs E: /X /V:”My ReFS Vol” /A:64K /I:enabled

После чего в вашей системе появится диск с файловой системой ReFS который вы сможете полноценно использовать.

Также существует альтернативный способ с правкой реестра, но мы не рекомендуем его использовать, так как после такой правки у некоторых пользователей наблюдались проблемы с пробросом

Длина имени файла и абсолютного пути

Вопрос, на первый взгляд простой, но с регулярной периодичностью возникают ситуации, когда неверное понимание этого вопроса приводит к разного рода недоразумениям. Особенно в мультиплатформенных средах.

☝️ Начнем с Windows. Классическая длина имени – 255 символов, максимальная длина пути – 260 символов.

Обратите внимание – символов, максимальная длина имени директории – 244 символа, так как система резервирует часть пути для файла в формате 8.3.

Однако начиная с Windows 10 1607 и Server 2016 эти ограничения можно отключить, в этом случае лимит имени файла или абсолютного пути будет определяться файловой системой, для NTFS это 32767 символов, для ReFS - 32000 символов.

👉 Теперь Linux. Имена файлов в Linux могут быть длиной до 255 байт. Полная длина пути не должна превышать 4096 байт. В отличие от Windows в ограничениях используются не символы, а байты. А кодировка UTF-8 для символов национальных алфавитов предусматривает до 4 байт на 1 символ.

Таким образом длина имени у нас может неожиданным образом оказаться ограниченной 63 символами, а максимальный путь стать 1024 символа.

Кириллица занимает 2 байта на символ, поэтому в Linux вы будете ограничены 127 символами в имени файла и 2048 символами в пути.

Смешивая различные символы, вы получите различные варианты лимитов между максимальными и минимальными.

Обычно это вызывает сложности при копировании или распаковке файлов из систем с кодировками CP-1251 или KOI-8.

Еще одна особенность связана с использованием криптографических файловых систем, таких как eCryptFS , в этом случае длина пути будет ограничена 143 байта или 71 символ на кириллице.

Безопасность? Нет, не слышали…

Попросили третьего дня одни заказчики проверить действительно ли были удалены все доступы уволившегося сотрудника. Сотрудник был важный и ушел не очень хорошо, поэтому руководство попросило нас перепроверить за своими сотрудниками.

Доступы у нас были, но особо в чужие дела мы нос не совали, но вот пришлось. Хотя лучше бы мы этого не делали. Потому что ситуация показала все недра бардака в сфере безопасности. Впрочем, так оно практически везде, где нет отдельной службы информационной безопасности и админы сами себе хозяева.

Нет, плохого про них ничего сказать не хочу, но человек такое существо, что если его не поддерживать в тонусе, постоянно пиная палкой, то постепенно он перейдет к политике наименьшего сопротивления, ну а зачем делать сложно, если можно сделать просто.

Расписывать все не будем, коснемся основных косяков, от которых у нас задергался глаз:

🔷 Предсказуемая система паролей, построенная по принципу постоянная часть + уникальная, в виде ФИО. Т.е. если уволенный человек не дурак и ему надо зайти – он зайдет под любым сотрудником.

🔷 OpenVPN без списка отзыва сертификатов, сертификаты на 10 лет, эти же сертификаты используются для доступа еще к некоторому количеству сервисов (мы насчитали пять).

🔷 Пароли от сервисов расшарены через корпоративную файлопомойку в виде отдельного файла-блокнота OneNote, кроме паролей там также логины, IP-адреса и прочая информация уровня «явки-пароли.

Папка доступна только IT-отделу, но мы все прекрасно понимаем, что одно неловкое движение – и все это будет достоянием общественности.

🔷 Секреты от тестовой среды, залитые на Git вместе с композами и плейбуками внезапно подошли к проду.

🔷 Сертификаты руководителей и сотрудников с МЧД просто лежали в общедоступной папке, потому что нужны почти везде, задолбались с ними. И установлены прямо в реестр целевых ПК.

🤷‍♂️ В общем отчет мы написали, и он не понравился ни руководству, ни админам. Но тут уж извините, если мы отрапортуем, что все хорошо, а завтра их сломают – вопросы будут уже к нам.

Продление сертификата

В IT существуют и активно используются множество терминов, которые либо неверно отражают суть происходящих процессов, либо являются неудачным переводом зарубежных терминов.

Один из таких терминов – это широко используемое «продление» сертификата, которое вводит в ступор многих начинающих, которые изучив документацию к собственному CA не находят там такой функции.

И не найдут, потому что у сертификата нет такой функции – продлить. Почему нет? Да потому что не предусмотрена.

Что такое сертификат? Это еще один пример не лучшего использования термина, но из песни, как говорится, слов не выкинешь.

Говоря сертификат чаще всего, подразумевается ключевая пара: закрытый и открытый ключ. Сертификат – это открытый ключ плюс некоторая дополнительная информация о владельце, которые подписаны ключом CA, что позволяет убедиться в их подлинности.

Закрытый ключ является секретным, а сертификат – публичным. С его помощью наши контрагенты могут убедиться, что мы – это действительно те, за кого себя выдаем или проверить подлинность нашей электронной подписи, начать защищенный сеанс связи с нами и т.д. и т.п.

Поэтому важной частью сертификата является его владелец (юридическое или физическое лицо, доменное имя или сетевой узел), который указан в поле Common Name (CN).

В настоящий момент это поле считается устаревшим и для размещения данных о владельце сертификата используется поле Subject Alternative Name (SAN), которое может содержать сразу несколько значений. Это может быть как несколько доменных имен, так и доменные имена вместе с IP-адресами, что позволяет защищать объекты с разным набором доступных имен и разными вариантами обращений.

При этом поле Common Name продолжает поддерживаться для сохранения обратной совместимости и там принято указывать «основное» имя владельца.

Кроме владельца сертификат имеет срок действия. Причем это не срок действия самого сертификата, это срок действия ключевой пары.

Почему нельзя сделать сертификат бессрочным? Можно, но крайне нежелательно с точки зрения безопасности. Ключ может быть потерян, утрачен, скомпрометирован и т.д. и т.п. Причем владелец об этом может и не знать. Поэтому короткий срок действия ключа снижает такие риски.

А также повышает доверие к такому ключу, так как говорит о том, что CA довольно регулярно проверяет владельца этого ключа и доверяет ему.

Так как же продлить сертификат с закончившимся сроком действия? Никак. Он закончился и никакой волшебной силы, способной продлить срок его жизни, сохранив ему доверие, не существует.

Что нужно сделать? Выпустить новый сертификат (читай ключевую пару) для тех же самых значений CN и SAN. Таким образом сертификат будет новый, но владелец старый и все, кто доверял ему продолжат это делать.

Таким образом следует крепко запомнить – никакой операции «продления» сертификата не было, нет и никогда не будет. Можно только выпустить новый сертификат для прежнего владельца.

Так откуда же пошел этот странный термин? Наше мнение – из маркетинга. Когда клиенту, получившему коммерческий сертификат и обратившемуся повторно для его перевыпуска делали скидку.

Отсюда и придумали термин «продление», чтобы отличать от обычного «выпуска». А потом пошло-поехало. Вот такой вот маркетинг, бессмысленный и беспощадный.

Почему у нас все так плохо с безопасностью?

В продолжение вчерашней заметки хочется рассмотреть более широкий вопрос: почему там, где нет отдельного отдела информационной безопасности – с безопасностью плохо, хотя внешне все может выглядеть хорошо.

Коллеги могут утверждать обратное, но исходя из собственного опыта и опыта коллег, с которыми успел пообщаться, могу сказать, что в большинстве случаев системное администрирование и безопасность идут где-то параллельными курсами, вроде и есть, но не пересекаются.

Почему? Да потому что их пересечение порождает массу проблем и не всегда виноваты в этом администраторы. Хотя скажем честно, большинство администраторов имеют скудные и обрывочные знания в этой области.

Типичный набор «безопасности» от администратора:

🔹 Закрыть периметр и (возможно) наиболее критичные узлы брандмауэром.

🔹 Настроить политику паролей согласно формальных требований (часто по минимуму)

🔹 Нарезать доступ по группам, спискам, адресам и т.д.

🔹Время от времени ставить обновления (да и то не факт)

Вроде бы грамотно, но вроде бы. Понятие периметра сегодня сильно размыта, и угроза может прийти даже из доверенного сегмента. Пароли могут оказаться шаблонными, словарными или откровенно слабыми, хотя формально будут удовлетворять политике.

Но даже грамотно настроенная система обязательно будет деградировать. Почему? Потому что требования безопасности часто идут в разрез с требованиями к системному администратору.

Задача администратора – это поддержание рабочего состояние информационной инфраструктуры, которая должна работать без сбоев и сложностей. Безопасность – это как раз про сложности и затруднения.

Вот придумал администратор всем действительно сложные пароли. Уже завтра половина их забыла, половина не может правильно ввести с первого раза. Послезавтра они появляются на листочках у монитора.

А через три месяца их надо поменять, это если по уму. А после такой замены у кабинета руководителя состоится митинг недовольных пользователей и админу это поставят на вид. Мол нам работать надо, а не твои пароли разгадывать.

И чего не коснись – везде будет так. А у админа нет ни рычагов, ни оправданий – его брали чтобы работать было проще, а не наоборот. Другое дело – безопасник, его брали именно для того, чтобы бдел и жить нерадивым сотрудникам мешал.

Да и самим админам нафиг это надо, особенно когда все работает. Один пароль на все сервисы? А что такого, это наши, админские сервисы.

Один SSH-ключ на всех устройствах – так проще и удобнее. Общие пароли в тесте и проде? Так удобнее тестировать, все равно это наш тест и наш прод.

И так далее в том же духе. В итоге еще непонятно, где окажется более дырявое решето – с клиентской части или с серверной. Особенно с классической нелюбовью к обновлениям, мол чего заморачиваться, это сугубо внутренний сервис.

Про установку программ и утилит из неизвестных источников, бинарников с гита или скриптов оттуда-же я вообще промолчу.

В результате имеем что имеем. И, повторимся, вовсе не потому, что админы такие плохие, а потому, что это не их вид деятельности.

Это, совсем другая профессия, с другими подходами и другими методами, которым администраторов не учили и многие из которых идут в разрез с привычными им нормами.

И снова о выборе мыши

Сегодня снова пришлось покупать новую мышь, и посему будет полезно в очередной раз вспомнить какие основные показатели влияют на эргономику работы с мышью.

Начнем с того, что мышь - это некий физический прибор, преобразующий движение руки в пространстве в движение курсора на экране. И хороший манипулятор должен позволять это делать с наибольшим удобством для человека.

Сегодня основной размер экранов в пикселях – это FHD, так, для 1920 x 1080 диагональ экрана составит 2202 px, а для 2K экрана – уже 2937 px.

Много это или мало? Все зависит от того, как далеко нам нужно передвинуть физическую мышь чтобы пройти это расстояние курсором на экране.

Для этого существует понятие разрешения мыши, которое обычно выражают в DPI, на самом деле это не совсем верно, но в рамках рассматриваемой нами темы вполне приемлемо.

Возьмем дешевую мышь с разрешением 800 dpi, это значит, что при движении мыши на 1 дюйм в физическом пространстве курсор пройдет на экране 800 px.

Нетрудно посчитать, что для того, чтобы переместить курсор из одного конца диагонали FHD экрана в другой нам нужно физически передвинуть мышь на 2,75 дюйма или почти 7 см.

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

Но если мы увеличим разрешение мыши вдвое, то нам потребуется для этого всего 3,5 см физического расстояния, а если взять мышь с разрешением 2400 dpi, то получим весьма комфортные 2,33 см.

Хотя здесь начинает проявляться другой эффект – мышь становится слишком быстрой и не все могут комфортно работать с такой скоростью. Ведь малейшее движение – и мышь улетела на другую сторону экрана.

Также высокое разрешение требует более высокого качества сенсора мыши. Мышь с плохой точностью сенсора будет двигаться хаотично, рывками. Обычно это характерно для дешевых мышей, где высокое разрешение сенсора может быть достигнуто программными средствами и к этому мы еще вернемся.

В то же время качественная мышь с увеличением разрешения до комфортных человеку уменьшает количество физических движений, что приводит к меньшей усталости и увеличивает комфорт работы за счет более точного позиционирования.

Почему так происходит? Все просто, обычная геометрия. Допустим, человек прикинул, что ему нужно подвинуть мышь на 45 градусов, но человек не робот и он на самом деле подвинул ее на 43 градуса.

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

И это вне зависимости от характеристик сенсора мыши. Чем больше расстояние физического перемещения мыши, тем больше погрешность позиционирования на экране.

Это приводит к тому, что человеческий глаз замечает это несоответствие и человек предпринимает действия для коррекции, т.е. это новые дополнительные движения рукой и дискомфорт от низкой точности мыши.

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

Вроде бы так. Но вот мышь – тоже не идеальное устройство и имеет свою точность. Грубо говоря даже строго подвинув мышь на 45 градусов, мы не получим идеальной прямой. А получим тот же круговой сектор, в котором может оказаться курсор мыши.

Чем точнее мышь, тем уже угол данного сектора, а площадь сектора – это набор точек пространства, где может оказаться курсор. Только вот площадь сектора растет не в прямой, а в геометрической пропорции от радиуса.

Так увеличив радиус всего на 10, мы увеличим площадь на 100. В нашем случае 10 – это скорость, а 100 – точность. Ну это совсем ни в какие ворота. И именно этим страдают дешевые мыши, где разрешение подняли программно.

Почему IT всегда проигрывает?

Сегодня мы поднимем одну больную, но актуальную тему, которая не понравится многим нашим коллегам. А именно, почему при возникновении конфликтных ситуаций между IT и пользователями – руководство обычно становится на сторону пользователей.

На самом деле никакого секрета тут нет, достаточно вспомнить основную цель бизнеса – заработать денег. Именно заработать, а не потратить и не спустить на благотворительность. Поэтому бизнес-процессы, приносящие фирме прибыль будут всегда иметь наивысший приоритет.

Потому что если эти самые пользователи, которые могут знать компьютер через пень-колоду не заработают денег, то платить зарплату IT будет ничем, а то и вообще фирма закроется и все пойдут по миру.

И тут можно услышать классический контраргумент – мол ну-ну, посмотрим мы чего они там без IT наработают. В этом есть доля истины, но следует понимать, что IT нужен фирме для того, чтобы помогать пользователям зарабатывать деньги, а не чтобы мешать и создавать различные затруднения.

Тем более, что IT это исключительно расходная статья, даже если это IT-фирма, внутреннее IT в ней точно также будет сугубо расходным.

Чтобы понять роль и место IT в фирме проведем простую аналогию. Вот у нас есть стадо овец, пастух и овчарка. Прибыль у нас исключительно с овец (шерсть и мясо), а овчарка только ест, с нее ни шерсти, ни мяса.

Но хорошая овчарка выполняет две важные функции: защищает стадо от внешних угроз (волков) и занимается внутренним микроменеджментом – не позволяет стаду разбегаться, а отдельным особям отбиться или забрести в реку или овраг.

После чего пастуху остается только вовремя перегонять стадо на новое пастбище, где трава сочнее, не отвлекаясь на непосредственное управление стадом и его охрану.

Так и в бизнесе. Овцы – это пользователи, зарабатывающие деньги. Пастух – руководство, которое занимается стратегическим планированием. А овчарка – сопровождающие службы, включая IT.

И как хорошая овчарка, хорошее IT должно пользователей оберегать и направлять, не мешая выполнять основные обязанности.

А если собака окажется «дурной», будет весь день бегать, лаять, кусать овец за ноги? В результате овцы перестанут нормально пастись, и пастух перестанет такую овчарку кормить, а то и вообще выставит на мороз.

Тоже самое происходит и в случае сильно мешающего IT, если его требования начинают мешать непосредственно рабочему процессу, то после ряда жалоб руководство поставит вопрос: а зачем нам такое IT? Которое не помогает, а только мешает.

При этом у руководства есть вполне понятные цифры и факты. Скажем, вчера торговый Иванов не смог вовремя оформить заявку, потому что не смог подключиться к информационной системе из-за 2FA, в результате заказчик недоволен, прямой убыток такой-то.

И если дальше так пойдет, то мы начнем терять клиентов и обороты. А это снова вполне конкретные суммы в рублях.

После чего на разговор вызывается IT. Вопрос простой: зачем вы это сделали? Чтобы не сломали. А нас ломают? Вроде нет, но… Хорошо, какая вероятность что сломают? Ну или сломают или нет…

То же самое касается и выхода из строя оборудования, и прочих моделей IT-рисков. Там все как в анекдоте про блондинку и динозавра. Или сломается или нет, 50/50.

Естественно, бизнесу такие размытые вероятности совсем не нравятся, потому что он знает, что, если станет снабжение – запасов хватит на три дня. Если бухгалтерия не перечислит до среды оплату – товар не отгрузят. Если не сдаст вовремя отчет – получим такой-то штраф и блокировку счета.

Причем этот вполне конкретные события, которые наступят со 100% вероятностью. IT ничем таким похвастаться не может, там или произойдет или нет. Скорее всего нет, потому что давно ничего такого не происходило.

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