OpenBSD и Kubuntu

14.08.2006 18:41:44

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

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

Начать надо с того, что PowerNow на моем ноуте работать под управлением OpenBSD отказался. Это означает постоянный шум и ненужный перегрев процессора. И это плохо. Видел некоторые довольно свежие патчи, возможно, какой-то из них помог бы в этой беде, но ядро собирать я более не хочу вообще (тем более в любых BSD, где процесс надо бы еще познать). Вообще говоря, этого уже достаточно, чтобы сходу снести систему, но я решил, что это не так существенно и продолжил.

Установка пакетов, настройка X — несложно, подъемно, работает хорошо. Далее я решил озаботиться шифрованием и занялся чтением «man vnconfig». Не увидел возможности передать пароль через stdin или из файла. И крепко задумался.

Шифрование, ведь, штука такая. Можно взять пароль в качестве ключа и шифровать. И оно будет работать. Проблема — пароли надо периодически менять. И в этой схеме надо перешифровывать диск. Что нереально. Тогда можно взять случайного мусора из /dev/random и использовать это в качестве ключа, но этот ключ зашифровать паролем и открывать по мере необходимости. Пароли меняются тогда легко, а главный ключ никто никогда не видит. А ведь еще может быть несколько шифрованных дисков (я планировал /home и /tmp), вводить два пароля? Фигушки, надо создать один маленький шифрованный виртуальный диск в файле, который будет хранить пароли их /dev/random в файлах. Но для всего этого этого нужно иметь возможность передать произвольные данные откуда угодно расшифровщику. Но именно этого нет в vnconfig.

Хотя есть патчи для vnconfig с этой функциональностью, которым уже несколько лет. Но их нет в OpenBSD по умолчанию. А перекомпилировать что-либо я сам себе запретил, поскольку это траты времени. Плюс ко всему, я с очень большим подозрением отношусь к отображению дисков на файлы (для постоянного использования), cryptoloop в Linux давал о себе знать при аварийных выключениях. Да и примечания в скрипте cryptfs не радовали. Все это имеет неприятный запах, известный как layering violation, нарушение, так сказать, слоистой структуры.

От криптографии в самой защищенной ОС пришлось отказаться, поскольку собственное душевное равновесие дороже. Про vnconfig я читал в воскресенье, тогда же перетащил свои данные (Ext2 монтируется нормально), запустил KDE. Кратко? Медленно. Очень медленно. Реакция системы отнюдь не мгновенная, KMail с почти 90000 писем в одном каталоге стал очень задумчив.

Это меня остановило? Нет. Воскресенье я потратил на изучение списка пакетов и портов, а также возможности использования UTF-8 в OpenBSD. В списке не значились git, convmv, ext2fstools (это навскидку). Что означало компиляцию. От которой я как раз лечусь.

UTF-8 я так и не нашел. Прыгал вокруг да около, пробовал всякое, но нет, за пол-дня мне ничего сделать не удалось. KOI8-R? Увольте. А более половины дня тратить на настройку системы для себя я не могу чисто физически, других дел хватает, в том числе требующих наличия рабочей системы.

Как результат вечером OpenBSD пошла под нож, а на винчестере ожил уже неплохо знакомый мне Kubuntu. Что характерно, я решил потратить немного времени на шифрование и тут меня ждал наиприятнейший сюрприз — год назад я довольно аккуратно, но все-таки врезался в схему загрузки Ubuntu для того, чтобы обеспечить необходимое (рас)шифрование из своих скриптов. А сегодня? «man crypttab» и «vim /etc/crypttab». Это не решение для шифрования /, но для /home, swap, /tmp или еще чего — запросто.

И оно не требует никаких особых шаманств, cryptsetup-ом создаем разделы, а потом прописываем их в /etc/crypttab и все (ну а swap всегда работает со случайным ключом — от его содержимого после перезагрузки нет никакого толку). Если пароль — спросит при загрузке, если файл — смонтирует тихо. Из коробки, в общем-то. Только что в инсталляторе еще не обозначено никак. А работает. Спасибо, Debian.

В остальном говорить нечего — Kubuntu встал, зашифровался и пошел работать. Пакеты на месте, UTF-8 тем паче. Вот, стало быть, пишу. Кстати, под /tmp я сначала выделил место, а потом сделал его монтирование из tmpfs и расширил своп (который, ясен пончик, зашифрован), вроде бы работает. И это радует.

Плоха ли OpenBSD после этого? Отнюдь. Я знаю, что я поставлю на сервер, если таковой когда-нибудь у меня образуется. Возможно, когда OpenBSD подпатчит PowerNow, доинтегрирует CITRUS, обзаведется новой системой шифрования дисков, а я обзаведусь новым ноутбуком, это будет система для моего ноутбука. На сегодня нет.

Много комментариев (8) к заметке “OpenBSD и Kubuntu”

  1. ddc:

    Хммм… У меня сейчас OpenBSD/amd64 стоит в качестве единственной ОС на ноутбуке (который — мой единственный компьютер), и, знаешь ли, я очень рад этому переходу, возвращаться на Linux не планирую…

  2. ddc:

    У меня OpenBSD сейчас в роли единственной ОС установлена. Полностью счастлив…

  3. Роман:

    Рад за тебя.

  4. estet:

    у меня IBM ноутбук, на нем установлена единственной ОС openbsd 4.2. Не жалуюсь. Все работает.

  5. Роман:

    Рад за Вас.

  6. olt:

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

    По поводу того, что UTF якобы не поддерживается. Вообще-то поддержка поддержка многобайтных символов на уровне ядра — это не более чем рекламные понты. С «точки зрения» как ядра, так и другого ПО, строки — это всего лишь массивы байт. Их преобразование к человеческому виду — это дело прикладного ПО на уровне представления. И циклы перекодировки многобайтных символов на уровне ядра — это пустая трата процессорного времени на уровне ядра, времени, которое лучше отдать драйверам, планировщику процессов и т.п. Именно поэтому разработчики OpenBSD и не торопятся усложнять ядро всякими ненужными заморочками.

    В OpenBSD utf перкрасно поддерживается на уровне приложений, ничуть не хуже, чем в других системах, о чем можно много прочитать в сети. Ну разве что нельзя имена файлов в FFS нельзя создавать в utf. Однако это мало кого волнует, содержимое файлов от этого не страдает. И опять таки, это скорее можно решить на прикладном уровне и даже должно так решаться, если действительно необходимость возникнет. Потому как ядру все равно в какой кодировке ему имя файла передали, и как эти байты интерпретировать. Кроме служебных символов, которые в случае utf8 и так соответствуют основному набору ascii.

  7. Роман:

    > Ну разве что нельзя имена файлов в FFS нельзя создавать в utf. Однако это мало кого волнует
    Меня волнует. Очень.

  8. olt:

    >>Ну разве что нельзя имена файлов в FFS нельзя создавать в utf. Однако это мало кого волнует, содержимое файлов от этого не страдает. Потому как ядру все равно в какой кодировке ему имя файла передали, и как эти байты интерпретировать.
    >Меня волнует. Очень.
    В этом случае, как я писал, этот вопрос решается на прикладном уровне, индивидуально и без особых проблем. Естественно это относится только к тем, у кого было достаточно причин, чтобы остановить свой выбор на OpenBSD. А в других ОСях это решается на уровне ядра.

Закомментировать

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