Ошибка: Не удалось записать RSA сертификат. Попробуйте еще раз

Достаточно редкая ошибка ЕГАИС и не все знают куда бежать и что делать. Прежде всего смотрим в лог, файл utm/transport/l/transport_info.log

И находим там строки:

java.security.KeyStoreException: invalid KeyStore state: found  3 private keys sharing 

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

Проблема достаточно редкая и найти ее описание не просто, хотя оно есть в базе знания Рутокен: https://dev.rutoken.ru/display/KB/RU1009

Суть проблемы в том, что при формировании нового RSA-ключа старый не удаляется и возникает задвоение ключей, о чем и написано в логе. В результате на ключе оказывается три объекта: ГОСТ и 2 RSA ключа. Попытка ручного удаления RSA-ключей также завершается ошибкой.

Если вы будете продолжать попытки формирования ключа с помощью УТМ ЕГАИС дублей станет больше (и число в сообщении лога увеличится).

Решение простое – скачать и применить утилиту, указанную на странице базы знаний Рутокен.

Кто-нибудь мне скажет зачем на простейшей и тупейшей платке переходника со слота PCIe на M.2 эта не несущая никакой смысловой нагрузки иллюминация?

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

хотелось бы узнать у матёрых спецов куда и как правильно бэкапить? Вопрос от малого бизнеса и частных лиц.

Начнем с того, что бекап – это не просто «бери больше – кидай дальше», а целый комплекс мероприятий. Мы об этом уже писали, напомним еще раз: https://interface31.ru/post/kak-pravil-no-organizovat-rezervnoe-kopirovanie-i-spat-spokoyno/

1️⃣ Если коротко. Самый первый бекап должен быть в "шаговой доступности", в формате позволяющем наиболее быстро восстановиться из него и, желательно, без сжатия. Можно, вопреки мемам, хранить на том же самом сервере.

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

3️⃣ Третья копия - в удаленной локации. Облако, NAS дома в чулане и т.д. Это на случай, когда все плохо и первые два бекапа недоступны или уничтожены. Чаще всего они вам не понадобятся, но иметь такую копию нужно.

👆 А теперь о том, чего делать не надо.

Не следует слушать "специалистов", которые любят бросаться фразами: "это не бекап", "это неправильные бекапы" и т.д. и т.п. Любой бекап является правильным, если выполняет свою задачу.

А какая задача бекапа? Быстро восстановить рабочую копию данных. При этом стоимость бекапа (а все имеет свою стоимость) не должна превышать стоимость ущерба от потери рабочей копии данных. Грубо говоря, тратить 1000 руб. на замок, чтобы закрыть лопату за 100 руб. - занятие лишенное всякого смысла.

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

❗️ И еще. Не путайте бекапы с архивами. У них разное назначение и архивы тоже нужно бекапить!

Гладко было на бумаге, но забыли про овраги...

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

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

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

По сценарию учения стартовали во второй половине дня субботы, когда на предприятии остался только линейный персонал. Руководство отсутствует, начальник IT-отдела «в отпуске» (доступен только по телефону).

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

И тут начался реальный мир:

1️⃣ Физический доступ в серверную. Ключ от серверной оказался заперт в кабинете начальника охраны, а сам кабинет — опечатан. Начальник службы безопасности к этому моменту уже благополучно добрался до дачи и успел принять рюмочку.

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

2️⃣ ЗИП под замком. Когда в серверную наконец прорвались, выяснилось: резервные диски и комплектующие лежат на складе. Склад на выходных закрыт, а материально ответственные лица отдыхают. Вскрывать склад даже коллективно под акт желающих не нашлось: дураков нет.

3️⃣ План «Б» и высота. Родилась идея: в цеху висит ненагруженный сервисный NAS, с которого можно безболезненно сдернуть рабочий донорский диск. Побежали в цех. Но телекоммуникационный шкаф смонтирован под самым потолком — снизу руками не дотянуться, нужна стремянка. А где заперта стремянка? Правильно, на том же самом складе…

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

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

Доступ к первичным точкам отказа, аварийный ЗИП «первой линии» и банальный инструмент обязаны быть доступны дежурной смене круглосуточно — без звонков на дачи нетрезвым начальникам охраны.

Бесплатный PAM, который уже используют в крупных компаниях!

Jumpserver PAM -- для компаний любых масштабов.

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

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

JumpServer PAM это:
• Контроль доступа к RDP, SSH, веб-интерфейсам и СУБД
• Фильтрация SQL-запросов и SSH-команд
• Подробный журнал действий
• Встроенный 2FA
• Масштабирование и надёжная кластеризация
• Установка одной командой

Познакомьтесь с JumpServer PAM на вебинаре 17 сентября в 12:00 по Москве
Регистрируйтесь по ссылке: Регистрация на вебинар

И присоединяйтесь к сообществу пользователей (ссылка на телеграм-канал):
• Инструкции и документация
• Кейсы внедрения
• Лучшие практики и рецепты
• Чат с нашими экспертами
#реклама
О рекламодателе

Окончание поддержки WinBox 3

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

И вот эта эпоха подходит к концу, компания производитель сообщила, что начиная с версии RouterOS 7.25 минимально поддерживаемой версией станет WinBox 4.3.

Если говорить про WinBox 4, в общем и целом, то ничего плохого, кроме багов первых версий, сказать нельзя. Инструмент как инструмент, теперь еще и кроссплатформенный, нативно поддерживающий Linux и macOS.

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

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

Остальных ждут забавные квесты по поиску привычных инструментов и различные крайне неприятные «фокусы». Все привыкли, что функции New и Remove шли первыми и обозначались как плюс и минус, а за ними шли Enable и Disable в виде галочки и крестика. Теперь у нас порядок иной New, Enable и Disable, а только потом Remove, как раз с крестиком.

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

VPN и сетевое окружение

Самый часто задаваемый вопрос в комментариях к статьям о VPN звучит примерно так: я настроил VPN, настроил маршрутизацию, компьютеры в удаленной сети пингуются, но в сетевом окружении их не видно, что я сделал не так?

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

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

Примерно также, как человек в лесу ищет другого человека.

Компьютер, если проводить аналогию, громко кричит на всю сеть: «эй, есть здесь кто-нибудь?»

А ему каждый активный узел отвечает: «есть, меня зовут Имярек»

Если говорить сетевым языком, то ПК отправляет широковещательный пакет, на который активные узлы отправляют ответы.

Фактически, каждый раз открывая сетевое окружение вы устраиваете такую перекличку. И кроме вас таких участников сети хватает.

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

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

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

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

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

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

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

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

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

Это снижает объем широковещания, но целиком проблему не снижает.

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

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

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

А для доступа к удаленным узлам используйте IP-адреса или доменные имена.

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

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

Особенности использования точек восстановления в Windows 10/11

Точки восстановления Windows появились в Windows XP и сразу завоевали популярность, особенно у простых пользователей, позволяя выполнить откат изменений и вернуть систему в рабочее состояние.

В Windows 7 – 8.1 этот инструмент получил дальнейшее развитие вместе со средой восстановления Windows, которая стала размещаться на отдельном, защищённом разделе, позволяя загрузить компьютер, не прибегая к сторонним инструментам.

В Windows 7, 8 и 8.1 создание точек восстановления включалось автоматически и точки создавались при установке драйверов, ПО, обновлений.

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

О чем речь? А о том, что у Windows 10/11 может вообще не оказаться точек восстановления! Потому что система защиты будет выключена. И, в отличии от многих других ситуаций, Windows не будет спешить уведомить вас об этом прискорбном факте.

👆 Дело в том, что в Windows 10/11 точки восстановления автоматически включаются только если объем системного раздела превышает 128 ГБ.

Если вы выполнили обновление системы с Windows 7 или 8/8.1 и объем системного диска меньше 128 ГБ, то система защиты будет автоматически выключена, а существующие точки восстановления удалены.

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

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

Рекомендуемый объем выделяемого пространства для разделов менее 64 ГБ – 3%, для более емких – 5%, но не более 10 ГБ.

Windows Me – не то время, не то место…

Еще одна «провальная» ОС от Microsoft - Windows Me (Millennium Edition), которую у нас стали скоро называть «линолеум едишен», а на Западе «Mistake Edition» (версия-ошибка).

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

Если мы вернемся немного назад, к моменту выпуска Windows 98, то уже тогда Билл Гейтс заявил, что это будет последняя система в линейке Win 9x и все следующие ОС будут основаны на линейке NT.

Как раз тогда в разработке находился новый проект NT 5, который станет позже Windows 2000 и в этой линейке первоначально планировалась версия Windows 2000 Home, которая базировалась на проекте Neptune.

Но разработка Neptune задерживалась, а позже и вообще была свернута и объединена с еще одним проектом Odyssey в Whistler, который позже вышел как Windows XP, а пока в Microsoft исходили из того, что им нечего предложить домашним пользователям после выпуска Windows 2000.

Поэтому возникла идея выпустить Neptune «на минималках», взяв за основу привычную Win 9x и перенести туда что получится из проекта Neptune. А так как последний был NT-системой из линейки Windows 2000 (NT 5), то и внешний вид новой системы стал похож на своего старшего брата.

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

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

Но тогда это было что-то действительно новое, скажем Windows Media Player 7.0 или Windows Movie Maker, именно начиная с этой версии встроенные мультимедийные приложения начали выглядеть современно и начали поддерживать современные функции.

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

Но откуда же столько негативных отзывов и эти снисходительные прозвища? А дело в том, что MS решила приблизить новую ОС к линейке NT и убрала из нее реальный режим DOS.

Но напомним, что вся линейка 9х являлась гибридной 16/32 битной ОС на ядре DOS, несмотря на все внешнее великолепие основа этого шикарного особняка покоилась на фундаменте старой халупы.

Все это привело к тому, что в новой ОС стало невозможно просто так запустить приложения, требовавшие реального режима DOS (чаще всего игры), также отвалился огромный пласт старого оборудования, который использовал DOS-драйвера.

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

Но на самом деле Windows Me была вполне стабильна, в том смысле в котором этот термин применим ко всей линейке 9х.

Пользователи с современным железом и периферией не испытывали проблем, а производительность графики в 9x всегда была выше, чем в NT и это делало Me неплохим выбором в качестве игровой системы.

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

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

После чего Windows Me стала никому не нужна, все самое новое и прогрессивное было в новой ОС, а старые системы остались на проверенной временем Windows 98SE такой расклад существовал примерно до середины нулевых.

Хотя в других обстоятельствах Windows Me могла бы избавиться от детских болезней и стать достойной ОС в линейке 9x, но увы, она появилась в совершенно неподходящее время и была выпущена сугубо как страховка от неудачи Windows XP.

По мотивам реальных событий

▫️ Вася решил мониторить температуру произвольных устройств.

▫️ Вася решил использовать для этого sensors

▫️ Вася добавил в конфигурацию агента Zabbix примерно следующие строки:

UserParameter=lm.nvme0Temperature,sensors | tail -n 3 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

UserParameter=lm.nvme1Temperature,sensors | tail -n 8 | head -n 1 | awk -F'[:+°]' '{avg+=$3}END{print avg/NR}'

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

❓Что не так сделал Вася?

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

▫️ Начало понятно, он вызывает команду sensors и потом колдует над ее выводом, передавая его по конвейеру.

▫️ Обработка начинается с команды tail, которая берет указанное количество строк от конца вывода. В нашем случае это три или восемь.

▫️ Этот результат передаем команде head, которая берет оттуда первую переданную строку. Таким образом у нас остается только третья или восьмая строка от конца.

▫️ Затем это все передается команде awk, где и происходит основная магия.

🔹 -F'[:+°]' – делим строку по указанным разделителям, искомое нами значение является третьим полем, так как располагается между плюсом и градусом.

🔹 {avg+=$3} – суммируем третье поле от всех строк в файле, эта конструкция перекочевала сюда из вышестоящей директивы для процессора, где в выводе не было общей температуры, но была температура по ядрам. В итоге мы отбирали количество строк по числу ядер и выводили среднюю.

🔹 END{print avg/NR} – выводит среднее значение разделенное на количество строк в стандартны поток ввода-вывода.

👆 В целом – магия грамотная и особых вопросов к ней нет. Но! Ошибочен сам принцип парсинга вывода команды sensors. Дело в том, что он зависит от количества сенсоров и выводимой ими информации.

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

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

Как быть? Используйте grep. Находим вывод именно нашего сенсора и начинаем плясать он его имени. Допустим у нас есть:

nvme-pci-0100
Adapter: PCI adapter
Composite:    +37.9°C  (low  =  -0.1°C, high = +114.8°C)
                       (crit = +119.8°C)

Нас интересует третья строка, в которое находится искомая температура, поэтому пишем:

sensors | grep nvme-pci-0100 -A 2

Которая выведет нам строку с вхождением и еще две после. Затем откусим нижнюю строку через tail:

sensors | grep nvme-pci-0100 -A 2 | tail -n 1

И уже все это скормим awk, вычисление средней можно убрать, так как значение у нас одно:

sensors | grep nvme-pci-0100 -A 2 | tail -n1 | awk -F'[:+°]' '{print $3}'

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

Раскрашиваем логи при помощи ccze

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

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

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

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

✅ Читать далее: https://interface31.ru/post/adminu-na-zametku-31-rasskrashivaem-logi-pri-pomoshhi-ccze/

Автоматизация платформы не отбирает у вас интересные задачи. Она забирает рутину.

Deckhouse Platform берёт на себя обновление, масштабирование и поддержку инфраструктуры «из коробки». Освободившееся время остаётся вам — на то, что вам действительно нравится.

Обсудите с инженерами Deckhouse, что можно автоматизировать в вашем стеке 👈

Zabbix - основы и базовые понятия

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

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

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

✅ Читать далее: https://interface31.ru/post/zabbix-osnovy-i-bazovye-ponyatiya/

Садись кибитка – тюрьма поехали

Утро пятницы началось не с кофе, а с раннего и путанного звонка одного молодого коллеги, который в начале двадцатых уехал покорять столицу. И одним звонком дело не закончилось. Сначала он искал адвоката, потом деньги.

Что произошло? Ровно то, о чем мы писали в апреле этого года: https://t.me/interface31/5975

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

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

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

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

Бывает такое, особенно если стороны работали без четкого ТЗ и не согласовали заранее критерии приемки результата. Тут, если разобраться, только сам виноват, сэкономил на бюрократии – получил проблемы.

Обычно тут надо или решать вопрос через переговоры, или признать, что тебя кинули и сделать выводы на будущее. Но наш товарищ решил вопрос радикально – он откатил все выполненные работы.

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

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

Сегодня ему утвердили меру пресечения: домашний арест, вернули только личный телефон. Основной работы считай больше нет, средств подработки нет. Ничего нет, денег нет. И стоили этого 80 тыс. руб. по данному контракту?

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

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

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

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

Почему у жесткого диска указан TRIM и что это обозначает?

Итак, откуда у жесткого диска команда TRIM

К сожалению, правильный ответ на вопрос дали немногие читатели. И это действительно диск с SMR, а наличие поддержки TRIM у жесткого диска – 100% признак черепицы.

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

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

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

Более подробно об этом в нашей статье: Что такое черепичная магнитная запись SMR и стоит ли ее избегать?

Настраиваем сетевую файловую систему NFS в Debian и Ubuntu

NFS (Network File System) - сетевая файловая система в Linux и UNIX-like системах позволяющая монтировать сетевые ресурсы удаленного компьютера и работать с ними как с локальными.

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

В этой статье мы рассмотрим, как настроить собственный сервер NFS на базе Debian или Ubuntu, а также как получить к нему доступ из удаленных систем.

✅ Читать далее: https://interface31.ru/post/nastraivaem-setevuyu-faylovuyu-sistemu-nfs-v-debian-i-ubuntu/

Подальше положишь – поближе возьмешь?

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

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

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

А папочка была закреплена как рабочая область в VS Code и ее физическое расположение благополучно забылось.

Ну и дальше все по классике, что-то пошло не так и после очередного обновления VS Code запускаться перестал. Пришлось переустановить.

А где теперь мой пет-проект? А нету его. И найти его в файловой системе он не смог. Поиск тоже ничего внятного не дал, ибо было не очень понятно, что именно искать. Возникла паника и теории заговора, мол VS Code, при удалении папку проекта снес и так далее и все такое прочее.

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

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

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

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

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

Звезда родилась. И у нее уже есть что рассказать.

24 сентября — День “ТризТех” — первое в России мероприятие, посвященное сетевой безопасности, где вендоры, регуляторы и крупнейшие заказчики обсудят текущее состояние, проблемы и перспективы рынка.

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

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

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

📅 24 сентября | 10:30–17:00 | онлайн

➡️ Регистрируйтесь на трансляцию Дня ТризТеха и проходите за эксклюзивом.

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

В оригинале можно ознакомиться здесь: https://learn.microsoft.com/ru-ru/troubleshoot/sql/database-engine/database-file-operations/considerations-autogrow-autoshrink