*nix *

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

Приветствую, друзья!
Сегодня я вам не буду рассказывать, почему я люблю Arch Linux, вы сами всё увидите.

Задача

— установить Arch Linux таким образом, чтобы корневой раздел монтировался по сети с Samba-сервера

Решение

Для решения этой задачи нам понадобится:
— установленный Arch Linux (или LiveCD)
— mkinitcpio-mount-hook из AUR (http://aur.archlinux.org/packages.php?ID=40372)
— ещё пара небольших hook-ов: mount.cifs и mount.loop
— extra/devtools (содержит mkarchroot)
— core/mkinitcpio-nfs-utils (в этом пакете находятся утилиты и скрипты для получения IP адреса)
— собирающий скрипт

Так уж случилось, что пару лет назад по долгу службы на команду разработчиков, к которой я отношусь, свалилась неожиданная задача — разработка системы управления оборудованием (в этом-то как-раз неожиданности нет, ибо направление разработок такое) с управляющим PC под Linux.
Разработки линуксовой части велись (да и ведутся) под Ubuntu, в среде Code::Blocks. Но, как показала практика, для качественной работы нужно что-то гораздо более легкое с гарантированным временем отклика. Для работы было достаточно консоли, так как задачи организации пользовательского интерфейса решались на подключаемом по TCP/IP удаленном компьютере.
Тогда и пришла идея использовать дистрибутив Linux собственной сборки, чем (сборкой дистрибутива), собственно, в свободное время я и занялся. Выбор пал на LFS. Про то что такое LFS уже неоднократно писали даже на Хабре, я же опишу решение нескольких дополнительных (кроме простенького Linux'а) задач, вставших передо мной в нашем конкретном случае.
Поначалу такая задача была одна — использовать real-time ядро.
Однако дальше, когда идея USB-флешки с дистрибутивом, пришлась всем по душе, то появились задачи размножения флешек и запуска системы на различных компьютерах (тестовых стендов много, имея свою флешку суешь в карман и иди к любому). Вот тут и появились проблемы — LFS не обладает 100% переносимостью с одного компьютера на другой. Для ее адаптации к конкретному компьютеру нужно править некоторые скрипты, что в условиях команды вчерашних Windows-кодеров проблематично (на виртуалку с Ubuntu некоторые пересели, но консоль и скрипты — это беда). Размножение системы также требует повторения некоторых манипуляций, проделываемых в процессе сборки (тот же GRUB установить).

Однажды, в одном из проектов, мне понадобилось организовать строгий и надежный контроль над всеми сетевыми интерфейсами, таблицами маршрутизации, а так же получать нотификации о каких-либо изменениях. Было принято стратегическое решение — не использовать старые-добрые ioctl netdevice (SIOCGIFMETRIC, SIOCSIFNAME и т.п.) или непосредственные вызовы соответствующих утилит (ifconfig, route и т.д.), а найти более современное и болле удобное решение. Оно было найдено — libnetlink. Это библиотека, предоставляющая большое количество методов для коммуникации с ядром, с помощью механизма netlink. Данная библиотека идеально подходила для моих целей, позволяя решить огромное количество задач. К сожалению, у библиотеки оказался не особо удобный и довольно сложный API, требовавший совершать множество непонятных действий. Особого веселья добавляло практически полное отсутствие документации и вообще любых материалов на эту тему.
Подумав, я решил как следует разобраться в netlink и написать свою библиотеку. В данный момент реализован весь функционал для работы с нотификацией, сетевыми интерфейсами, таблицами маршрутизации, разумеется поддерживаются IPv4 и IPv6. В достаточно скором времени данный проектик будет представлен на суд общественности :) А пока я бы хотел познакомить всех интересующихся с прекрасным миром netlink, на примере простого монитора сетевых интерфейсов.

Собственно попался в руки freenas 0.8 встала проблема установить iperf, простым гуглением нахожу команду pkg_add -r iperf, где -r указывает ставить iperf с репозитория, но во фринасе корень промонтирован только на чтение:
freenas2# mount
/dev/ufs/FreeNASs1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/md0 on /etc (ufs, local)
/dev/md1 on /mnt (ufs, local)
/dev/md2 on /var (ufs, local)
/dev/ufs/FreeNASs4 on /data (ufs, local, soft-updates)
data on /mnt/data (zfs, local)

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

Собственно лечится командой:
mount -o rw /dev/ufs/FreeNASs1a /

И вуаля любой софт можно ставить pkg_add -r.

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

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

Сегодня в рассылке Linux Kernel Линус Торвальдс пишет, что уже выпущено много версий ядра Linux 2.6, и что он может в конечном итоге отметить это как Linux 2.8.0 ядро.

Линус отправил письмо с напоминанием об этапе слияния. Как уже говорилось на прошлой неделе, когда вышло Linux 2.6.39 ядро, создатель ядра Linux ожидает, что этап слияния 2.6.40 ядра займёт меньше времени, чем обычно, из-за своего путешествия, касающегося LinuxCon в Японии в конце месяца. Обычно этап слияния занимает около двух недель после основного выпуска каждого ядра. Cкорее всего, на этот раз он просто будет короче на несколько дней.

Командная оболочка (консоль) — пожалуй, самый архаичный элемент Unix, который остаётся почти в неизменном виде уже тридцать лет. Мы любим его, но кому-то кажется странным сидеть у монитора с миллионами пикселей, ежедневно глядя в консольное окошко образца 70-х годов, когда вся информация на компьютерах была исключительно в текстовом виде.


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

Добрый день. Эта заметка посвящена моей частной борьбе против GRUB'a, ну или за него, это как посмотреть.
Понадобилось поставить grub-загрузчик на freebsd, конечно многие знают про chainloader+1, но этот способ не годился для меня.

Классическая схема инициализации System V, на которой базировались дистрибутивы RedHat Enterprise Linux до шестой версии, была привычной и довольно простой для понимания: init описывал весь процесс загрузки в своем конфигурационном файле "/etc/inittab", откуда вызывались другие программы и скрипты на определенном этапе запуска.
В RHEL 6 ситуация поменялась: на смену System V пришел Upstart, что несколько изменило процедуру конфигурации процесса загрузки операционной системы. Upstart, который изначально разрабатывался для Ubuntu, довольно неплохо вписался и в RedHat системы, заменив собой только часть привычной схемы запуска.
Тем не менее, изменения существенные и мало документированные, поэтому в этой статье я постараюсь внести ясность в новую схему загрузки, и что она привнесла.

В нашей компании давно и успешно работает такая связка: Samba 3.x, установленная на FreeBSD (6.x или 7.x), для доступа к шарам использует аутентификацию пользователей в домене Active Directory. Все клиенты – Windows XP и выше. Домен AD – Windows 2003.
Все было хорошо, пока один из серверов FreeBSD не был обновлен до версии 8.2. После обновления пользователи с кириллическими логинами не смогли получить доступ к расшаренным ресурсам этого сервера. В то же время пользователи с логинами в латинице нормально аутентифицировались. Команды wbinfo -u и wbinfo -g как и положено показывали всех пользователей и группы AD, включая кириллические. Другой сервер FreeBSD 7.3 с такой же версией Samba – 3.4.9 и с таким же конфигом работал нормально с любыми логинами.

Ядро — это та часть операционной системы, работа которой полностью скрыта от пользователя, т. к. пользователь с ним не работает напрямую: пользователь работает с программами. Но, тем не менее, без ядра невозможна работа ни одной программы, т.е. они без ядра бесполезны. Этот механизм чем-то напоминает отношения официанта и клиента: работа хорошего официанта должна быть практически незаметна для клиента, но без официанта клиент не сможет передать заказ повару, и этот заказ не будет доставлен.
В Linux ядро монолитное, т.е. все его драйвера и подсистемы работают в своем адресном пространстве, отделенном от пользовательского. Сам термин «монолит» говорит о том, что в ядре сконцентрировано всё, и, по логике, ничего не может в него добавляться или удаляться. В случае с ядром Linux — это правда лишь отчасти: ядро Linux может работать в таком режиме, однако, в подавляющем большинстве сборок возможна модификация части кода ядра без его перекомпиляции, и даже без его выгрузки. Это достигается путем загрузки и выгрузки некоторых частей ядра, которые называются модулями. Чаще всего в процессе работы необходимо подключать модули драйверов устройств, поддержки криптографических алгоритмов, сетевых средств, и, чтобы уметь это правильно делать, нужно разбираться в строении ядра и уметь правильно работать с его модулями. Об этом и пойдет речь в этой статье.

0. Intro.

Ситуация следующая. Есть винт на 160Гб. На нем 2 раздела — 40Гб и 120Гб. С целью установки убунты как второй системы была произведена разбивка 120Гб -> 100+10+2+8.

Далее, с целью отката изменений, были объединены диски (10, 2 и 8) обратно в один 20Гб и отформатирован в NTFS. В нагрузку к этому, были проведены операции с MBR, результатом которой явилась ее смерть.

Итоги

1. При загрузке системы выводится сообщение MBR helper not found;
2. fdisk показывает один большой 160Гб диск.

Дураку понятно, что это начало веселой ночи.
Далее, под катом, решения вопроса.

В UNIX системах есть одна очень древняя команда, которая называется dd. Она предназначена для того, чтобы что-то куда-то копировать побайтово. На первый взгляд — ничего выдающегося, но если рассмотреть все возможности этого универсального инструмента, то можно выполнять довольно сложные операции без привлечения дополнительного ПО, например: выполнять резервную копию MBR, создавать дампы данных с различных накопителей, зеркалировать носители информации, восстанавливать из резервной копии данные на носители и многое другое, а, при совмещении возможностей dd и поддержке криптографических алгоритмов ядра Linux, можно даже создавать зашифрованные файлы, содержащие в себе целую файловую систему.
Опять же, в заметке я опишу самые часто используемые примеры использования команды, которые очень облегчают работу в UNIX системах.

После трёх лет разработки представлен релиз десктоп-окружения GNOME 3.0. Это самый значительный релиз проекта с момента выпуска GNOME 2.0 девять лет назад.

Все привыкли редактировать текст в текстовых редакторах, блокнотах, веб-формах и т.д. В процессе набора текста мы пользуемся привычными стрелками, кнопками «End» и «Home», более опытные зажимают «Ctrl» и стрелками шагают по словам (что, кстати, не всегда работает). И при переходе на консоль мы ориентируемся на те же самые правила, даже не зная, что bash предлагает очень удобные средства и комбинации клавиш, которые очень упрощают работу и минимизируют количество операций для выполнения задачи. К тому же, в bash есть удобные средства работы с историей, масса различных подстановок и других интересных функций. Самые часто используемые мной и любым опытным администратором я и опишу в этой статье.

В мире железа есть понятие сертификации, которое говорит о том, что данное оборудование сертифицировано для выполнения конкретных задач, работы в конкретных условиях и т.д. Такое же понятие есть в мире ПО, например: операционная система сертифицирована для работа на конкретном оборудовании, или программа сертифицирована выполнять определенные расчеты. Это понятие говорит о том, что клиент (покупатель) может быть уверен в том, что продукт, который он покупает, выполнит его задачи на все 100%.
Точно такое понятие сейчас применимо и к специалистам. Сертификация специалиста — проверка его на наличие необходимых знаний, навыков и опыта для выполнения задач, связанных с технологией или продуктом, для которого он сертифицируется. В случае успешного прохождения сертификации специалист получает сертификат (бумажный или электронный) и, по идее, считается экспертом в данной технологии в рамках направленности и уровню сертификационного экзамена.

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

Прочитав недавно статью «Собираем пакет для Solaris из сорцов» я понял, что функционал SMF вообще никак не освещен на Хабре.
Давайте исправим эту ситуацию и посмотрим что из себя представляет SMF и какие преимущества он дает администраторам.

Введение

Service Management Facility (SMF) — система управления сервисами, которая появилась в Solaris 10. SMF позволяет более гибко управлять процессами, назначать им зависимости и перезапускать при необходимости. В дополнение к этому SMF позволяет делегировать права управления сервисами обычным (non-root) пользователям.
Для управления SMF достаточно «всего» трех команд:

• svcs — проверяет состояние сервисов,
• svcadm — управление состоянием сервисов,
• svccfg — настройка параметров сервиса.

Попробуем разобраться с управлением SMF на примере добавления собственного сервиса.
Недавно мне понадобился nginx под Solaris, пришлось собрать пакет и интергрироваться в общую систему сервисов — на его примере и подсмотрим как может быть оформлен сервис для управления через SMF.

Предисловие

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

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

Задача: Собрать исходный код клиента munin-node под SPARC Solaris и распространить по нескольким серверам.

Весь процесс будет описан на примере операционной системы Solaris 10 SPARC (update, мне кажется особой роли не играет, у меня был и U6, и U9) и свободного распространяего приложения munin (http://munin-monitoring.org/).

Долгое время я мучился ужасно медленным удаленным логином на свои Ubuntu сервера (все 2 ). Ужасно медленно в данном случае — 2-3 секунды. Не то чтобы это было совсем фатально, но когда логин через ключ — хочется чтобы все работало мгновенно — в конце концов, у нас не 486SX.

Длительное гугление приводило только к стандартным решениям:

1. UseDNS no в /etc/ssh/sshd_config — ускоряет логин в случае тормозного DNS. В моём случае стоял локальный кеширующий DNS, потому и так все было быстро.
2. Принудительное указание IPv4 в SSH клиенте — особо не помогло, видимо не у всех тормозит

И на askubuntu.com вопрос c bounty уныло провисел долгие недели без ответа…