Периодически сталкиваюсь с таким явлением: заказчик давно уже имеет подписку на RHEL, но по каким-то причинам (возможно из-за недоработок того, кто ему в свое время эту подписку продал) не в курсе как, куда и с каким вопросом можно обращаться. А ведь техническая поддержка – это существенная часть комплекса предоставляемых вендором услуг, и заказчик должен по максимуму получить все за что отдал «свои кровные». Благо Red Hat нас не ограничивает числом открытых в тех. поддержке запросов. И уже относительно давно существует «русскоговорящая» 1-я линия поддержки.

Из года в год различные он-лайн и офф-лайн СМИ обещают нам скорый приход Linux на рабочий стол пользователя. Однако думаю, всем давно уже понятно, что не стоит ждать некоего прекрасного момента, когда пользователи вдруг проснутся и начнут искать более экономичную/безопасную/и т.д. альтернативу прекрасно у них работающему (и с каждой версией все лучше и лучше) ПО от Microsoft. Да и не факт, что для каждого конкретного пользователя (организации) альтернативы будут безопаснее или дешевле…

На днях, в связи с возросшей вероятностью в ближайшем времени осуществить “марафонский забег” в виде чтения пяти первых курсов программы Linux Professional Institute (LPI) , сдал второй из экзаменов необходимых для получения сертификата LPI Level 1 (LPIC-1). Чтобы иметь право читать курсы, выбранные заказчиком, осталось досдавать два экзамена на уровень LPIC-2.

Теперь, уже вплотную познакомившись с двумя основными сертификациями по Linux для технических специалистов, от LPI и от Red Hat (первый экзамен Red Hat сдал еще в 2004 году), наверное, могу с полным правом их сравнить. На мой взгляд, если есть желание подтвердить свою квалификацию сдачей экзамена, лучше заказать performance-based тест а не отвечать на вопросы “какая опция отвечает за такую-то функцию”. Зачем помнить сотни опций, если есть man? Поэтому практический экзамен за реальной системой всегда в этом плане предпочтительнее… Кроме того, практический экзамен менее подвержен проблеме дампов. Интересующихся сертификацией от Red Hat, отсылаю к своей статье, опубликованной в “Системном администраторе” в прошлом году.

В новом году Red Hat Magazine переехал на новый сервер и новую CMS. Однако, из кучи заметок (за исключением новых статей из Knowledgebase), эта первая, которая мене показалась интересной. В статье обсуждается прошлое, настоящее и будущее шифрования дисков в Fedora: Cryptsetup, LUKS, шифрование swap-раздела. Также дается ссылка на патч mkinitrd, включающий в образ initrd поддержку шифрованной корневой системы (статья в Bugzilla 124789). Могу только присоединится к автору статьи в надежде, что вслед за патчем в mkinitrd появиться поддержка шифрования корневой ФС в Anaconda.