Записки IT специалиста

V2V миграция при помощи Vinchin Backup & Recovery   Виртуализация сегодня – норма жизни, даже в среде малого бизнеса. Но за последние несколько лет рынок виртуализации серьезно изменился. Прошлые лидеры отправились на покой, а их место заняли новые, молодые системы.   Так для последнего бесплатного Hyper-V Server 2019 поддержка заканчивается в январе 2029 года, а новый владелец VMware – Broadcom полностью закрутил гайки переведя всех на платную подписную модель с совершенно не гуманным ценником.   В итоге вопрос из стадии «куда пойти податься» переходит в стадию «а куда мы можем быстро мигрировать».   Потому как в эпоху ИИ, которая находит уязвимости пачками и также быстро клепает к ним эксплойты вопрос взлома неподдерживаемой системы остается только вопросом времени.   Классическая схема: конвертируем диск – создаем новую VM – запускаем, проверяем, тестируем подходит только если у вас виртуальных машин штучное количество. В противном случае это будет неконтролируемый растянутый по времени процесс, все время которого бизнес будет находиться в подвешенном состоянии.   Почему в подвешенном? Так сломают нас или не сломают, и какие новые косяки вылезут при переезде очередной виртуальной машины? Все это время работа нарушается, прибыль падает, руководство нервничает.   Лучше быстро перенести все за один раз, а потом уже решать вопросы в рабочем порядке. И тут нужны совсем другие инструменты.   И тут на помощь нам приходят наши китайские друзья со своим Vinchin Backup & Recovery, про него мы уже писали: ✅ Vinchin Backup & Recovery - универсальная система резервного копирования уровня предприятия   Да, это коммерческая система, но бизнес говорит на языке денег, если инструмент стоит дешевле, чем возможный простой или упущенная прибыль – деньги на него найдутся.   Так вот, данный продукт умеет в кроссплатформенное восстановление виртуальных машин, а список поддерживаемых платформ виртуализации там куда как велик, включая и все отечественные системы.   Сам процесс очень про

До первого сервис-пака не ставить   На фоне некоторых коллег, которые бегут ставить свежий софт сразу после его выпуска, невзирая на то, что разработчик за неделю выпустил семь минорных релизов вспоминаются старые добрые времена, когда интернет был по талонам по карточкам с почасовой тарификацией и никакой мгновенной доставки софта быть не могло.   В те годы софт распространялся на физических носителях: дискеты, а позже и компакт-диски. И все косяки, доработки и прочее копились большой массой чтобы быть исправленными или добавленными в большом обновлении, которое называлось сервис-пак.   Выпускали их, когда быстро, когда не очень. В зависимости от критичности выявленных проблем и ожиданий пользователей.   Так для NT 4 было выпущено целых шесть сервис-паков, не считая Service Pack 6a и Post Service Pack 6a Security Rollup. И самая жесть состояла в том, что, поставив чистую NT 4 с лицензионного носителя вы должны были все эти обновления (числом 8 штук) накатить последовательно.   Для Windows 2000 было выпущено четыре сервис-пака и один Update Rollup для закрытия выявленных уязвимостей, для Windows XP сервис-паков было три. Потом этот процесс пошел на убыль.   Windows Vista получила всего два сервис-пака, а Windows 7 – один. Но к этому времени широкополосный интернет стал нормой жизни и все изменения и исправления стало можно свободно распространять через Windows Update.   Времена прошли, но привычки остались. Любой администратор, заставший те времена помнит, что установка сервис-пака часто была сродни обновлению системы. Менялось многое, добавлялись новые функции, исправлялись ошибки.   Поэтому и возникло правило: до первого сервис-пака в прод не ставим. Пусть там все оттестируют, исправят, а тогда уже и мы подтянемся.   А мотивация была проста – с косяками нам придется жить и жить долго, пока тот самый сервис-пак не выпустят. И зачем это надо? Совсем не надо! Поэтому посидим на старой версии, пока на новую все исправления не выпустят.

Как узнать все смонтированные файловые системы? Раньше можно было сказать: загляните в /etc/fstab, но сегодня изучение этого файла уже не даст полного представления о всех смонтированных ФС. Можно использовать команду mount, но ее вывод недостаточно удобочитаем. Но есть способ лучше - findmnt, данная команда выведет все смонтированные файловые системы в удобном древообразном виде. А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом --real. Чтобы получить больше информации воспользуйтесь ключом --help.

Горе от ума или причины упадка FreeBSD Каждый раз, когда заходит речь про FreeBSD, обязательно появляются фанаты и поклонники системы, которые рассказывают какая она передовая и продвинутая, не то, что эти все ваши «линухи» и т.д. и т.п. Тут, конечно, хочется задать классический вопрос: если ты такой умный, то почему такой бедный? А применительно к ОС хочется спросить, а где ее пользовательская база? И почему так получилось, что из технологического лидера FreeBSD очень быстро превратилась в маргинальную и нишевую систему. Я почитал материалы 2011 года, когда от FreeBSD отказались два отечественных IT-гиганта – Яндекс и Рамблер. Тогда было сломано много копий, но были и вполне разумные выводы и высказывания, которые, к сожалению, оказались не услышанными. Основная проблема FreeBSD – это ее происхождение, а появилась она в университете Беркли и разрабатывалась в первую очередь в этой самой университетской среде. Это сразу задало стиль разработки – строим величественный собор под руководством грамотных архитекторов. С одной стороны – это правильно, это хорошо. Но с другой – страшно далеки они от народа, эти все архитекторы, равно как и научная, университетская среда от обычной жизни. Linux строился по принципу караван-сарая. Надо – сделаем, вот тут с боку прилепим, ну и что, что неказисто, зато работает. И, что более важно, в разработке Linux использовался инженерный подход, а не научный. В этом и заключается самая большая разница и самая большая проблема BSD. Любой инженер знает, что теория проверяется практикой и никак иначе. Если какая-то идея хорошо выглядит на бумаге, но нормально не работает – это плохая идея и ее следует отвергнуть. Также любой инженер знает, что такое эксплуатация, изделие может быть сколь угодно технически продвинутым, но, если оно требует трехмесячных курсов и работы в белых перчатках – это плохое изделие. Хорошее изделие должно быть эффективным, простым и недорогим в обслуживании. А еще инженер знает, как важна обратная связь с эк

Развод и кухня пополам На этой неделе в очередной раз столкнулись с нехорошей и некрасивой ситуацией. Один из наших заказчиков нехорошо разошелся со своим бухгалтером. Бухгалтер была на аутсорсе, предоставляла услуги как ИП. Договор? Да какой там договор, стандартная рыба из интернета на одну сторону листа с очень и очень общими фразами. Ну и часть суммы оплачивалась не на расчетный счет, а на карту. Такая вот «налоговая оптимизация». В результате бухгалтер с начала текущего месяца разорвала с заказчиком все отношения, базу 1С:Предприятие передавать отказалась, мотивируя это тем, что база – результат ее интеллектуального труда. Взамен передала оборотно-сальдовую ведомость, да состояние регистров учета за 9 месяцев, все исключительно на бумаге, чтобы посильнее насолить заказчику. Причем здесь она полностью в своем праве, в отличие от художеств многих обиженных системных администраторов, которые просто рискуют поднять с пола статью. База – действительно результат интеллектуального труда. Все, на что может претендовать заказчик – это первичные документы (которые и так у него есть) и текущее состояние учета (которое ему передали). По роду работы я давно и прекрасно знаю обе стороны конфликта, также успел выслушать и прочитать трактовку событий с каждой стороны. И что тут можно сказать? Претензии у обеих сторон - по существу и достаточно обоснованные. Многое – результат взаимного недопонимания и различного представления о том, какую именно работу должен выполнять бухгалтер и сколько это должно стоить. В общем, классическая история про развод с битьем посуды и делением совместно нажитого имущества. Только в бизнесе. И обе стороны одновременно и правы, и виноваты. Однозначно хороших и однозначно плохих в этой истории нет. Что могло помочь нашим фигурантам? Договор, только нормальный, а не формальная рыба из интернета. В котором бы четко были прописаны все взаимоотношения. Объем работ, порядок их сдачи-приемки, оплата. А также такие вопросы, как принадлежнос

Мифы и легенды Active Directory – откуда ноги растут Как мы уже неоднократно говорили, администраторы Active Directory очень часто подвержены множественным заблуждениям, из которых уже сформировался устойчивый набор мифов и легенд. Как водится, происхождение всего этого мифотворчества уходит своими корнями в далекие времена Windows NT, т.е. до 2000 года. Фактически уже выросло второе поколение специалистов, которые эту самую NT в глаза не видели, но тем не менее подвержены распространенным заблуждениям. Поэтому предлагаем вам немного окунуться в историю и понять, чем являлся домен NT и что изменилось с приходом Active Directory. Домен NT (NTDS) являлся реализаций службы каталогов от Microsoft доступный в серверной операционной системе Windows NT Server. И состоял из одного первичного контроллера домена – PDC (Primary Domain Controller) и неограниченного количества резервных – BDC (Backup Domain Controllers). Именно на первичном контроллере хранилась основная база домена и все изменения в нее могли вноситься только на нем. Затем эта база реплицировалась на остальные резервные контроллеры, после чего они тоже могли начать обрабатывать клиентские запросы. Если первичный контроллер выходил из строя, то домен фактически переходил в режим «только чтение». При его окончательной утере первичным можно было сделать один из резервных контроллеров. Но это была достаточно непростая задача, учитывая, что выбор роли определялся только на этапе установки и его нельзя было изменить без переустановки системы. Т.е. мы не могли добавить уже существующему серверу роль контроллера или понизить его до рядового. Также сделав резервный контроллер основным, нельзя было снова изменить его роль на резервный. Чтобы понять все сложности, с которыми сталкивались администраторы тех лет следует вспомнить, что виртуализация в те времена была чем-то из области научной фантастики и сервера были железными. И было их обычно не очень много, поэтому кроме роли контроллера они совмещали в себе ещ