... 10ые форточки так и норовят создать свой "раздел восстановления". Даже если мне он нафиг не нужен.
Переносил тут систему "Шиндошс 10" с одного привода на другой. Как выяснилось, проще всего это сделать при помощи утилиты "partclone", предварительно порезав целевой накопитель на разделы нужного раздела. Потом можно запустить какого-нибудь "стрельца" и иже с ним и восстановить bootmanager. Всё вышесказанное справедливо для UEFI-режима, на MSDOS не пробовал.
Так вот, в процессе переноса я старательно выкорчевал пресловутый recovery-раздел. И таки знаете шо? При ближайшем же мажорном обновлении не в меру вумные форточки самостоятельно отчекрыжили от системной партиции полгигабайта и создали там этот богомерзкий recovery.
Нет, я конечно понимаю, сто рублей не деньги полгигабайта — не объём. Но мне, например, принципиально жалко отдавать их ни пойми на что, когда я мог бы положить туда лишние пару серий порнухи ещё сотню фотографий. Всё, это больше не ваш компьютер. Это компьютер виндовс.
... Попутно выяснил, что свитчи в моей системе домашнего видеонаблюдения не виноваты. Поменял на другие — проблема осталась. Как только в кадре начинается движение, приложение начинает активно сбрасывать на HDD буфер. В этот момент загрузка CPU резко подскакивает, и похоже, что на обработку прерываний от сетевого интерфейса ресурсов уже не остается. Вообще загадочно всё это, ибо одна камера генерирует что-то около 3...4 МБит/с трафика, а у меня их там всего четыре. То есть ни о чём. А в настройках приложения я явно указал "писать на диск без транскодирования". Что-то мне подсказывает, что разработчики накосячили в какой-то очередной из версий. Технически, можно попробовать откатиться на какую-то из более старых. Вопрос только, на какую.
Попробую теперь более мощный комп туда поставить что ли в качестве "регистратора". Не знаю как подтвердить или опровергнуть свои предположения.
... Долго и мучительно разбирался как же настроить запись логов с кластера из двух Juniper SRX-345 на rsyslog-сервер. Это какая-то песТня. Несмотря на то, что они представляют собой цельные "коробочки", там внутри всё равно присутствует логическое разделение на Control-Plane (типа якобы шасси) и Data-Plane (собственно, обработчик пакетов). И часть логов можно снимать только с contol-plane, а часть только с data-plane. Так-то вообще они умеют коммуницировать друг с другом (сюрприз, да?), но тут мы вспоминаем, что у нас сука-кластер. И какая-то одна из двух нод всегда будет неактивной.
А коли она неактивна, то так называемый Routing Engine на ней будет заведомо остановлен. И значит что-то осмысленное можно от неё получить только через management-интерфейс (FXP0), больше никак.
Дальше начинаются традиционные искусственные ограничения и приколы. В пределах одного routing instance у Juniper-а не может существовать двух разных интерфейсов (не алиасов, а именно интерфейсов), находящихся в одной и той же IP-подсети. FXP-интерфейсы нельзя выносить ни в какой routing instance помимо базового "inet.0". Если у тебя routing engine запущен, то маршрутизация происходит в соответствии с общими настройками. Если остановлен — то для FXP-интерфейсов (management) будет использоваться так называемый "backup-router", а остальные интерфейсы вообще потухнут (я, конечно, несколько упрощаю картину, но в самых общих чертах так). То есть ты заранее не знаешь как, каким маршрутом и откуда полетят пакетики на твой rsyslog-сервер. Поэтому приходится:
- Создавать на rsyslog-сервере два логических интерфейса с двумя разными IP-адресами: для взаимодействия с data-plane и с control-plane по отдельности.
- Выделять на коммутаторах отдельный VLAN для FXP-интерфейсов.
- Совать FXP-интерфейсы в один VLAN с rsyslog-сервером и какой-нибудь reth-интерфейс маршрутизировать на другой адрес rsyslog-сервера.
- Настраивать всё это безобразие. Помнить о том, что маршруты до приёмника логов с control-plane надо писать два раза: в общем конфиге и как backup-router. А с data-plane разговор отдельный.
Я худею. Usability на грани фантастики. А если не выливать логи куда-то по сети, то по умолчанию они будут писаться на локальную флешку, чем довольно быстро её ушатают (максимум года за три-четыре). Интересный нюанс. Внутрь этих Juniper-ов можно поставить полноценный SATA SSD, но... загрузиться с него нельзя. Это чисто для логов. Логи, логи, логи... их так любят всякие "специалисты по безопасности". Но покажите мне хоть одного, кто бы их (логи) всерьёз читал.
... Попробовал настроить RSTP в сети, где присутствуют одновременно коммутаторы Juniper и Cisco. Сделал несколько попыток (разумеется, с rollback-ом по таймауту 1 минута), с какой-то из них полностью на*** положил всю сеть. Хотя включал RSTP не везде, а прицельно только на паре "экспериментальных" портов. В конце концов махнул рукой и сказал "ну нахер". Надо на кошках сперва потренироваться. А подходящих кошек, шосукахарактерно, нет.
... Вообще, оказалось сюрпризом, что на некоторых моделях Cisco на интерфейсах по умолчанию включен Proxy ARP. И плевать, что это один и тот же физический интерфейс, на который навешано несколько IP из разных подсетей, даже без VLANов. Всё равно будет проксировать. Ох сколько крови оно нам выпило... Еле нашли где косяк. Пидорство. Еще на них же по умолчанию включен VTP и их собственная реализация STP под названием PVST. Тоже, блин, сюрприз. Кстати, забавно. Если отключить VTP, то Cisco 9200 начинает писать и отображать VLANы прямо в общем running-config. Неожиданно. Либо я чего-то не так понимаю.
... Вообще, конечно, умиляет и раздражает одновременно насколько железки разных производителей исповедуют совершенно разную философию. Например, в коммутаторах имени Juniper применяется "стандартный" RFС-шный STP/RSTP. В цисках вместо него служит проприетарный PVST/PVST+. Якобы полностью совместимый. Но Федот, да не тот. Когда дело доходит до транков, тушите свет, сливайте воду. Или другой пример. По умолчанию cisco не вешает метку на native vlan в транке, а Juniper — вешает. Пока допёр, пару часов потратил.
Нафиг так жить?
P.S. Кстати, кто-то у меня раньше в комментах спрашивал, почему не делают Linux-based и прочих OpenSource-коммутаторов. На самом деле делают. Такие коробочки называются "WhiteBoxes". Типа, вот тебе data-plane, вот тебе API, а control-plane программируй сам как тебе нравится. Самые известные из ныне существующих делает Mellanox. На них, кстати, по большей части работает QRator. Ещё Intel выпустил (скупил разработчиков) программируемые сетевые контроллеры (матрицы, ASIC-и, кому как нравится) под названием [Barefoot] Tofino. Их можно программировать на языке относительно высокого уровня "P4". Так что чисто технически в современном мире вполне возможно взять и разработать свой собственный Opensource-коммутатор или маршрутизатор. Вопрос только в цене.
Я так понимаю (мои личные суждения), что широкому кругу это нафиг не нужно (не у каждого дома или в офисе крутится HighLoad уровня того же ВКонтактика). А бизнесу проще купить готовую проприетарную железку и "типа сертфицированного" спеца к ней, нежели проводить собственные R&D. Поэтому тема и непопулярна.