andrmart @

Перед новым годом мой Samsung размером 1Тб всего полтора года отроду начал каприничать. Сначала вылезло несколько Bad Block, затем и вовсе стучать начал. Каюсь, на мониторинг показателей SMART не обращал внимание.

Диск был куплен в Санрайзе и решение вопроса о замене представлялось мне не разрешимой задачей.

Надо отдать должное службе поддержки Samsung в России. Отреагировали оперативно, направили в сервисный центр, попросили прислать документы и даже на днях перечислили мне компенсацию за окончательно "умерший" диск. Это при том, что на то что называется "платежный документ" нельзя было смотреть без слез - выцветший крочок бумажки.

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

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

P.S. В последнее время стал все чаще слышать жалобы на подержку вендоров. Дескать не могут даже толком вопрос принять. Но это тема отдельного разговора

P.P.S. Кстати по сложным проблемам лучше обращатся не по телефону и не по эл. почте, а через специальный раздел сайта. По крайней мере с Samsung именно так и вышло. Только после заявки на сайте (кропка справа) мной действительно начали заниматься.

Daniel Berrangé в своем блоке опубликовал видео о развитии Cobbler, созданое Michael DeHaan, а также видео о развитии libvirt.

http://berrange.com/personal/diary/2010/01/visualizing-libvirt-development-history

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

P.S. Первое видео мне понравилось больше, из-за сходства с космическими стрелялками ;)

В продолжение эпопеи с webalizer пришлось обновить стандартные политики для того чтобы PPTPd смог авторизовываться через winbind в домене Windows.

( Подробности )

На моем ноутбуке замечена странная тенденция, как ни выходит новая Fedora, так работать в графике с ней первые дней 10 невозможно. Все дело в чудном встроенном видео от ATi. То зависает, то на ровном месте падает, то из sleep не выходит. C kernel-mode-settings вообще не дружит.

Рецепт всегда один - обновить драйвер Xorg для ATi. Ну почему же нельзя эти достадные мелочи выловить до релиза. Bugzilla пестрит жалобами и предложениями.

Кто страдает такой бедой - сделайте "yum --disablerepo=* --enablerepo=updates-testing update xorg-x11-drv-ati.x86_64" и пропишите в параметрах ядра "nomodeset".

С версией "xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.x86_64" уже жить можно.

Сразу после выхода Fedora 12 зачесались руки перейти на новую версию раньше всех, благо доступ к системе зеркалирования Fedora Mirror есть.

Начало было обнадеживающим. На диске доступно 2,5Гб дискового пространства, утилита preupgrade установлена.

Запускаем, подключаемся к ближайшим зеркалам. Preupgrade проверила все зависимости, даже не поперхнулась подключанными репозитариями RpmFusion*. Начаем 1Гб файлов, перезагружаемся и установка началась.

Все хорошо идет, правда немного медленно. Обновление выполняется визуально раза в 3 медленне, чем новая установка. Я безбожно щелкаю по консолям Alt+Ctrl+Fn.

И тут случилось страшное: ошибка инсталятора и перезгрузка. Приехали.... :(

Система загружается, на экране проскочило несколько ошибок. Вход в систему. Интернет есть (проводной и WiFi). Звук не работает.

Смотрю "yum list". На диске установлены пакеты XXX.fc11 и XXX.fc12, и так почти для всего ПО. Обновления показываются только для F11.

Не вдаваясь в детали разбора полетов расскажу как все вылечилось:
# rpm -ihv /var/cache/yum/preupgrade*/packages/*.rpm --replacepkgs

Процесс переустановки всех пакетов, запланированных к обновлению прошел довольно безболезненно.

Проверяем, что в сухом остатке "rpm -qa | grep fc11" - около 10 пакетов. Они не мешают жить и видимо уйдут после следующего набора исправлений к F12.

Хотя можно было бы попробовать програть обновление заново, но уже поздно.

Итоги:
1. Как тебя жизнь ни учит, резервную копию перед обновлением все же делать надо
2. Переход на следующую версию проходит безболезненно (ну почти)
3. Система Fedora живучая, даже сбой обновления ее не сильно вывел из строя
4. Обновление это зло - надо ставить систему заново
5. Наличие скоростного безлимитного интернета избавляет мороки с дисками

P.S. заметка написана несколькими днями позже, просле проверки того, что система в таком состоянии способна корректно работать

Прочитал тут новость про Red Hat Enterprise Virtualisation for Servers и понял - вот оно счастье для обычных админов.

Удобная консоль управления, отказоустойчивость из коробки, миграция виртуальных машин (автоматом и по запросу) - и все это без необходимости разбираться с технологиями.

Есть и минусы - хочешь чтобы все само и сразу, да еще и без головной боли - бери хорошую железку, management карту к ней и нормальное хранилище. Хотя при нормальном бюджете это не проблема. Да, и поддержку оплатите сразу этак года на три.

Можно объявлять новую эру в корпоративном применении Linux`а. Ура, товарищи.

Документацию можно найти тут: http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Virtualization/

Каждый раз на треннинге обсуждая автомонтировщик приходится объяснять почему DEFAULT_BROWSE_MODE выключен и почему автомонтировщик скрывает свои ресурсы.

Наконец-то вышло обновление на утилиту find, которое позволит в будущем это поведение привести в удобный для всех вид.

Теперь при заданной опции -xautofs утилита find не будет пытаться зайти в каталог, обслуживаемый автомонтировщиком, и тем самым не будет дергать внешний ресурс.

https://rhn.redhat.com/rhn/errata/details/Details.do?eid=914

С переходом на Fedora 11 надеялся получить наконец работающий вариант связки Evolution + Evolution MAPI + Exchange 2007.

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

Потом вместо русских букв увидел только пробелы. В общем - сплошное разочарование.

Потратив целую ночь на анализ трафика и просмотр исходного кода нашел причину - "велосипед" перекодировок от автора libmapi.

В итоге родился отчет об ошибке https://bugzilla.redhat.com/show_bug.cgi?id=520062

Ждем реакции.....

После установки Windows 7 на ноутбук с AMD X2 вот уже третий месяц борюсь с проблемой, что зависает система наглухо при работе через WiFi Atheros через 10-30 минут. Надоело сидеть привязанным к розетке уже.

Почти сразу удалось локализовать точку сбоя - WiFi, затем долго и мучительно пытался понять почему это происходит.

В итоге цепь случайностей привела к решению проблемы:
- Установка Fedora 11 показала, что работать через Wifi можно часами - не аппаратная проблема
- Переборка умелыми руками Вовы Пахомова всего теплообмена в ноуте снизило улучшило тепловой режим, но проблема осталась
- Подключение к точке доступа в офисе (честная AP через Ethernet) не привело к зависанию

Вывод - глюки в связке Windows 7 + Atheros + WiFi Acorp + ADSL

Сделал по старинке, как это уже проделывалось тысячи раз со стыкованием технологий передачи данных - зарезал принудительно на WiFi адаптере в Windows 7 MTU=1300. Более 4х часов полет нормальный.

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

P.S. экран был полосатым из-за аппаратного конфликта и видимо память видеоадаптера портилась. Это постоянно сбивало с толку и поддалкивало на неверный путь - выкинуть глючное железо. Оказалось все программно решается.

Решил освоить новый подход к организации мобильного рабочего места.

Взял USB FLASH на 8 Гб, установил на него свежую Fedora 11 и работаю.

В свете того, что все компьютеры в офисе поддерживают загрузку с USB, и железо почти стандартизовано, до адаптация к новому посадочному месту занимает 1-3 минуты.

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

Самое ценное - вместо ноутбука походным весом более 2кг имеем невесомый брелок в нагрудном кармане.

Столкнулся тут с одной особенностью vim. Не то что бы "баг", но очень неприятно получилось.

Создаем ~/.vimrc и прописываем в него одну команду "wq". Вроде бы случайно при выходе торопились и забыли двоетовие набрать и затесалась она в конец.

Так результат почище любого вируса: vim будет удалять содержимое всех файлов, которые открываются на редактирование.  Причем резервная копия в виде файла с тильдой на конце не создается.

Плачевно......

Уже который раз спрашивают как его сделать правильно и быстро.

Позволю себе состаться на когда-то уже данный рецепт, опубликованный в LJ Анатолия Петрова:

По сути, надо в настройки postfix вписать пяток параметров. Правда, указанный пример работает с проверкой подлинности через PAM, а не через базу виртуальных пользователей. Хотя для внутреннего или шлюзового почтового сервера для одного своего домена это как раз правильное решение.

Допишу позже как сделать проверку для межсерверной передачи данных при помощи сертификатов. Ведь неудобно же заводить для  серверов учетные записи с фиксированными паролями для проверки подлинности.

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

http://nfsworld.blogspot.com/2005/06/using-active-directory-as-your-kdc-for.html

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

Решили воспользоваться встроенными средствами шифрации cryptosetup.

Взяли usb-flash, зашифровали его и отформатировали в ext3. Теперь его можно безбоязненно передать с курьером, а получателю достаточно вставить ее в компьютер с RHEL5/Fedora и получить доступ к данным. Все максимально "прозрачно" для пользователя.

1. fdisk -l  - смотрим какое имя получила наша флешка
2. cryptosetup luksFormat /dev/sdb1 - включаем шифрацию
3. Вынимаем и вставляем флешку, вводим пароль для расшифровки
4. mkfs -t ext3 /dev/mapper/luks_crypto_<UUID> - форматируем шифрованное хранилище
5. вынимаем шлешку - она готова к использованию

Плюсы данного решения:
- Пользователю просто и понятно как этим пользоваться
- Шифрация идет на уровне диска, т.е. при потере носителя нашедший увидет "неотформатированную" флешку и первым делом это поправит ;) удалив данные

Минусы:
- нельзя выдергивать флешку "на лету" (иначе будет неизбежный сбой ФС)
- шифрация по умолчанию не очень сильная, завязанная на пароль пользователя

Итог: всем брать на вооружение, если есть вероятность потери данных при перевозке


P.S. А как же коммандная строка:
cryptsetup isLuks /dev/sdb1 && echo "Encrypted" || echo "Not encrypted"

cryptosetup luksOpen /dev/sdb1 ENCRYPTED && mount /dev/mapper/ENCRYPTED /mnt

umount /mnt && cryptosetup luksClose ENCRYPTED

Открыл для себя новую "фенечку" от РЖД: на Ленинградском вокзале поставили 2 автомата для самостоятельного получения билетов, заказанных через Интернет.

Суешь в него штрих код с распечатки в вводишь номер паспорта - вылезает нечто похожее на посадочный билет в самолете с отрывной частью.

Факт - я его завесил, т.к. принтер у них жует бланки ;)

P.S. И все таки возврат билетов делается через одно место: сначала получи физический билет, а потом его сдай.

P.S.S. Заказ через инет не работает, если до поезда менее 3х часов, а тетушки в кассах утомили постоянным желанием всучить тебе страховку ЖАСО за 50руб. И ведь обижаются, когда ты от нее отказываешься.

Встала тут интересная задачка, переименовать VG, на которой лежит корневой раздел.

Я нашел два пути:
1. Без использования rescue CD и с одной перезагрузкой
2. С использованием rescue CD и тремя перезагрузками

Начнем со второго, как более понятного и простого:
- загружаемся в rescue CD с подключением жестких дисков и проделываем
   chroot /mnt/sysimage
   vi /etc/fstab   - меняем название VG в описание точек монтирования
   vi /boot/grub/grub.conf - меняем параметр root=
   exit
   перезагрузка

- загружаемся в rescue CD без подключения дисков системы и проделываем:
  lvm vgchange -an VolGroup00 
  lvm vgrename VolGroup00 VG_new_name
  lvm vgchange -ay VG_new_name
   перезагрузка
 
- загружаемся в rescue CD с подключением жестких дисков и проделываем
   chroot /mnt/sysimage
   mkinitrd /boot/initrd-$(uname -r).img $(uname -r)  - или по желанию подставляем точно версию активного ядра
   перезагрузка

Для любителей экстрима есть вариант более интересный
1. Правим /etc/fstab и /boot/grub/grub.conf
2. распаковываем initrd
     mkdir /tmp/initrd-image
     cd       /tmp/initrd-image
     zcat /boot/initrd-$(uname -r).img | cpio -idmv
     vim init
     Меняем строчку vgchange -ay VolGroup00 на
     vgchange -an VolGroup00
     vgrename VolGroup00 VG_new_name
     vgchange -ay VG_new_name
     
     по необходимости меняем в следующих строках старое имя на новое

 3. собираем свой initrd
      find | cpio -i -o | gzip -9 > /boot/initrd-$(uname -r).new.img
  4. создаем в /boot/grub/grub.conf копию пункта меню загрузки и вписываем в него имя нового initrd

Перезагрузка и проверка, по ходу переименуется LVM, произойдет его активация и все заработает. После этого можно будет удалить новый пункт загрузки, но придется переделать initrd для существующего через "mkinitrd /boot/initrd-$(uname -r).img $(uname -r)"

Если что не так - возвращаемся к ранее описанному варианту с rescue CD.
    

Все наверно знают, что в sudo можно отключить запрос пароля через задание
#tail -n1 /etc/sudoers
andrmart ALL = (root) NOPASSWD: ALL

А вот как этим управлять более изощеренно?

Почитав man sudoers я нашел, что есть переменная timestamp_timeout которая влияет на время между запросами:

timestamp_timeout = XX - задает время между запросами в XX минут (по умолчанию - 5 минут)
timestamp_timeout = 0 - требует запроса пароля каждый раз при использовании sudo
timestamp_timeout = -1 - требует запроса пароля только при первом использовании sudo на этой машине в этом терминале. Даже после logout при восстановлении этого же терминала (tty или pts) sudo снова работает без пароля.

В результате sudo формирует файл метки в /var/run/sudo/ИМЯ_ПОЛЬЗОВАТЕЛЯ/НОМЕР_ТЕРМИНАЛА (/var/run/sudo/andrmart/4 для pts/4 ), и по этому файлу (по времени его создания) отслеживается необходимость повторного запроса пароля.

В итоге для запроса пароля каждые 10 минут для пользователя andrmart наш файл sudoers будет выглядеть так:

Defaults:andrmart timestamp_timeout=10

Как-то все руки не доходили настроить webalizer для прокси сервера.

Попробовал поставить пакет, но cron задание не срабатывает для анализа журналов squid из-за проблем с контекстами selinux.


Пришлось слегка подпилить:

sudo /usr/bin/audit2allow -i /var/log/audit/audit.log -m webalizer > webalizer.module

убрал ошибки от других служб и получил что-то в виде

======================================
======================================

После этого компилируем и загружаем политику SELinux:
checkmodule -M -m -o webalizer.mod webalizer.module && semodule_package -o webalizer.pp -m webalizer.mod && sudo /usr/sbin/semodule -i webalizer.pp

Проверка даем желаемый результат (ошибок открытия журнала не наблюдается):
sudo /etc/cron.daily/00webalizer

P.S. сам конфиг webalizer поменялся немного

В подмосковье становится все больше скоросных электричек "Спутник".

В жаркий день одной из главных заманух является минимум народа и обещанный кондиционер.
Эти два обстоятельства делают поездку с ребенком делом приятным и не напрягающим.

Каково же было мое удивление, когда на этих выходных я обнаружил в Спутнике открытые окна, не работающий кондиционер, и все это при +32 за бортом.

В итоге получили обычные детские сопли......

При попытке построение отказоустойчивого кластера в RHEL5 было обнаружено, что миграция сервиса выполняется не через XEN Live migration, а через простой save/restore виртуальных машин, т.е. по аналогии с "xm migrate DOMU host1.cluster.ru".

Покапавшись стало понятно, что в скрипте /usr/share/cluster/vm.sh забыли добавить параметр "--live" в обработчик события migrate.

В обновлении от RHEL5.2 rgmanager умеет теперь делать live миграцию, только вот придется руками править /etc/cluster/cluster.conf (параметр migrate="live") у ресурса виртуальной машины. И загружать его снова в кластер через "ccs_tool update /etc/cluster/cluster.conf".

N.B. не забываем при ручном обновлении конфигов кластера обновлять и версию файла :)

Статейка по теме Automated failover and recovery of virtualized guests in Advanced Platform