вторник, 24 февраля 2015 г.

NFS, quota и rpc.rquotad в Xubuntu 14.04

Исходные данные: 
Xubuntu 14.04 (64 разряда сервер, но с установленной графической подсистемой Xubuntu-desktop и еще один точно такой же сервер в качестве клиента NFS).

Итак 2 сервера 10.0.0.3 и 10.0.0.4. На 10.0.0.4 есть файловая система, соответствующая запись в /etc/fstab:
LABEL=homefs    /home      ext4 defaults,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl   0   2

Специально написал без всяких html-рюшечек чтоб было можно потом и копипастить, и рассматривать... Там же в /etc/exports прописано
/home           10.0.0.0/23(rw,sync,no_root_squash,no_subtree_check)

Соответственно 10.0.0.3 монтирует эту файловую систему. Запись в /etc/fstab
10.0.0.4:/home                            /mnt/dumb/home  nfs     defaults,nofail  0       0

Локальная квота на обоих серверах работает. Между ними NIS. Нужно сделать управление квотой на примонтированной ФС. Разумные мысли были пойманы тут, тут еще.

На 10.0.0.4 (в дальнейшем будем считать его NFS-сервером) в /etc/defults/quota ставим флаг
RPCRQUOTADOPTS="-S"
и перезапускаем rpc.quotad
/etc/init.d/qouta.rpc restart
у нас появляется запущенный демон

rpcinfo -p |grep quota
    100011    1   udp    913  rquotad
    100011    2   udp    913  rquotad
    100011    1   tcp    914  rquotad
    100011    2   tcp    914  rquotad
добавляем в /etc/hosts.allow
rquotad : 10.0.0.3
перезапускаем (мягко) nfs на сервере 
/etc/init.d/nfs-kernel-server reload

Перезапускаем rpcbind на клиенте
initctl restart rpcbind
и (у нас запущен NIS) отвалившийся ypbind
initctl start ypbind
На клиенте смотрим результат (skeluser -- специальный учебно-тренировочный пользователь для опытов)
root@fsrv:/var/log# quota --format=rpc -u skeluser
Дисковые квоты для user skeluser (uid 1002): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
 10.0.0.4:/home  838640  8500000 9900000           3517   35000   70000        
— Соответствует. Теперь пробуем этой квотой манипулировать.
edquota -r -u -F rpc -f /mnt/dumb/home/ skeluser
Меняем что-либо и смотрим результат при помощи quota. Ну, собственно и все!

Замечание относительно стартовых скриптов Xubuntu 14.04.

/etc/init.d/quota приписан по старту на уровень "s" и при нормальном запуске на стартует (это про NFS-сервер). Тонкости надобно еще выяснять, пока сделано следующее:
update-rc.d  -f quota remove
update-rc.d  quota start 35 2 3 4 5 . stop 85 0 1 6 .

и поднял квоту вручную /etc/init.d/quta start.


понедельник, 23 февраля 2015 г.

От VirtualBox к KVM

Исходные данные: 
Xubuntu 14.04 (64 разряда сервер, но с установленной графической подсистемой Xubuntu-desktop).

В связи с лицензионными ограничениями Oracle (и совершенно безумной ценовой политикой) VirtualBox можно совершенно законно эксплуатировать дома и в качестве тестового инструмента в производственных целях. А вот для постоянного применения с очень существенными ограничениями (без usb и удаленного доступа, что ни есть хорошо). Ну и производительность оного оставляет желать лучшего. Пробуем перенести существующие под VirtualBox VM на KVM. Конечно винды. Начнем с Windows-7, она достаточно капризна, потом Server 2008.

Первоисточники.

Статья на русской страничке ubuntu. И английский вариант, он полнее. В итоге ставим вот что. Минимально возможный вариант взят из первого источника:
В Ubuntu 10.04 и позже KVM рекомендуется ставить так:
sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils
Это установка на сервер без X-ов, т. е. не включает в себя графический интерфейс. Установить его можно командой
sudo apt-get install virt-manager
После этого в меню появится пункт «Менеджер виртуальных машин» и, с большой долей вероятности, всё заработает. Если какие-то проблемы всё же возникнут, то нужно будет почитать инструкцию в англоязычной вики....
Вот тут надо перегрузиться, к сожалению пока мне не понятно что и в какой последовательности нужно перезапустить, чтоб этого избежать. В 14.04 обычно возникают проблемы с usb 2.0, но об этом позже. В принципе для запуска VM у нас уже все есть. Более того, при помощи этого набора можно достаточно легко создавать VM, в том числе и из образа, обкатанного в VirtualBox, можно его и запускать для постоянной эксплуатации с небольшим "допиливанием" файла настроек. Т.е. большинство операций можно выполнять при помощи "Менеджера виртуальных машин". Теперь нужно разложить по полочкам как оно устроено и как работает. 

Краткое описание взаимодействия qemu, kvm, libvirtd

Когда мы запускаем virt-manager (он же менеджер ВМ) и создаем новую ВМ (оно  в терминах qemu называется домен, а не ВМ), создается xml-файл в /etc/libvirt/qemu/имя.xml и симлинк в каталог autostart, если нужно взлетать по включению питания. Т. е. мы работаем с libvirtd, он запускает qemu с опцией kvm (если мы правильно все указали). При этом он создает сокет для отображения консоли и много чего еще полезного делает в части настройки сети. Сами образы ВМ (доменов) живут в /var/lib/libvirt. При нехватке места можно воспользоваться симлинком, проверено. Очень поучительно запустить любую, даже кое-как скроенную ВМ, которая даже повиснет на этапе загрузки и посмотреть список процессов ps ax | grep qemu - длинна командной строки и список опций завораживает... Из командной строки с xml - файлом можно работать при помощи virsh, им же можно оперативно запускать - останавливать ВМ. Стандартный порядок действий таков
  1. Создаем ВМ при помощи менеджера или из командной строки при помощи qemu-img.
  2. Пробуем запускать. Делаем выводы относительно тонкой настройки.
  3. Получаем файл настроек при помощи virsh dumpxml имя > файл
  4. Редактируем файл, собственно тонкая настройка ВМ.
  5. Экспортируем настройки при помощи virsh define файл
  6. Запускаем ВМ virsh start имя и смотрим результат.
В ряде случаев ВМ запускают без помощи libvirtd, а напрямую. Вот прекрасный образец готового файла, да и вся переписка достаточно интересна.

Проблема usb 2.0

Процесс собственно создания ВМ или импорта существующей ВМ из VirtualBox вопросов не вызывает и многократно описан. Так же везде и не по разу описан процесс проброса usb-устройства. При использовании графического менеджера это вообще элементарно - выбрать нужное устройство из списка. Что мы наблюдаем при работе ВМ? — Если устройство подключено по протоколу usb 1.1 или 1.0 проблем не возникает, а вот если устройство подключено как usb 2.0, мы будем наблюдать что само устройство пробрасывается, но гостевая ОС его использовать не может. Если иметь ввиду Windows 7, устройство помечается как неисправное (код ошибки 10). Все точно так же как и в VirtualBox с отключенной поддержкой usb 2.0 (не подключен плагин или не стоит соответствующая галочка). Если пристально рассмотреть xml-файл, то мы увидим примерно такой фрагмент.
<controller type='usb' index='0'>

<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>

</controller>

Как мы видим контроллер usb не имеет типа устройства, т.е. что-то там по умолчанию. По умолчанию usb 1.1... Нужно дать ему тип (указать модель). Тут требуется уточнение. Здесь и далее по тексту мы будем вести речь о ВМ, которая в виде процесса выглядит как:
qemu-system-x86_64 -enable-kvm -S -machine pc-i440fx-trusty,accel=kvm
Т.е. мы запускаем 64-х разрядную pc-i440fx-trusty (или pc-i440fx-2.0, она тоже проверялась). Командная строка очень длинная, но смотреть надо именно указанные параметры.
Пути решения.
Указанная ВМ среди прочего поддерживает тип контроллера model='ich9-ehci1' и другие, способные работать с устройствами usb 2.0. Вот пример, который у меня так и не заработал:
<controller type='usb' index='0' model='ich9-ehci1'>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/>
</controller>
<controller type='usb' index='0' model='ich9-uhci1'>
  <master startport='0'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/>
</controller>
Но, была найдена некоторая последовательность действий, которая приводит к успеху. 
  1. Нужно взять исходный xml-файл (virsh dumpxml) и добавить в него указанные в примере строки. 
  2. Загрузить конфигурацию обратно при помощи virsh define.
  3. Потом (не запуская ВМ) открыть графический менеджер ВМ и удалить старый "безродный" контроллер usb. При достаточном навыке можно "вычистить"  старый контроллер руками (поменять старый на пару новых).
В результате получается рабочая конфигурация. При внимательном рассмотрении видно что процессор (я в своих экспериментах использовал "копировать CPU хоста" меняется на kvm-32 (или 64 в зависимости от архитектуры). Другим последствием является изменение аппаратного состава ВМ по сравнению с VirtualBox, и, как следствие, запрос на повторную активацию Windows - нужно быть готовым предъявить все фантики. Было подозрение в том, что существенно просаживается производительность - не подтвердилось. Так что в общем и целом можно пользовать.

"От себя" были установлены еще несколько пакетов - virtinst, ubuntu-virt, ubuntu-virt-mmgt, ubuntu-virt-server. — Видимо напрасно. 

Спустя 5 недель. На "побаловаться" уже достаточно. Все остальное переехало во вторую часть.

суббота, 14 февраля 2015 г.

NIS сервер и клиенты (Xubuntu 14.04)

Исходные данные: 
Xubuntu 14.04 (64 разряда сервер + отдельный сервер LTSP + клиенты в т.ч. бездисковые, в т.ч. винды).

Нужно раздать по сети пароли с тем чтоб не заводить их на всех ресурсах. Идея такова: Заводим их в Самбе при помощи smbpasswd, они одновременно заводятся как linux-пользователи на SAMBA - сервере (в /etc/passwd, /etc/shadow, /etc/groups), это будет "самое главное место для паролей" и оттуда их раздаем при помощи NIS на остальные сервера (еще нужно будет написать два коротеньких скриптика для обновления NIS при заведении нового пользователя или смене пароля и указать их в smb.conf). На самом деле на момент написания материала интересовал всего-навсего еще один сервер на котором "живет" LTSP (там расположены dhcp, tftp, nbd - сервера и домашние каталоги машин-клиентов, монтируемые по NFS). Вот ради него и все пляски-то.
В принципе есть два почти достаточных ресурса SettingUpNISHowTo и http://www.server-world.info.

Отличие совсем небольшие, и только в деталях. По этому коротко-коротко.
1. Проверяем содержимое  /etc/hosts.  IP сервера должен там быть (имеется ввиду нормальные внешний интерфейс, а не  127.0.0.1). NIS должен быть по возможности независим от  DNS .
2.Как написано, так и делаем  -  Add the following line to hosts.allow:
rpcbind ypserv ypbind : list of IP addresses
rpc.yppasswdd : localhost # тут есть о чем подумать, он вообще не очень нужен...
3. Ставим NIS:
sudo apt-get install rpcbind nis
Установочный скрипт спросит имя nis-домена, обычно это название или что-то в этом роде. Например для владельца домена pupkin.ru нормально иметь nis-домен pupkin или vpupkin.
4. В /etc/default/nis пропишите NISSERVER = master
5. В /etc/yp.conf прописываем сервер (лучше IP):
#domain  server 
domain pupkin server 192.168.0.1
6. Правим /var/yp/Makefile. Там инструкция внутри. Реально нужно проверить MINGID.
7. Правим /etc/ypserv.securenets :
host 192.168.1.1
255.255.255.0 192.168.0.0
etc.
Важно!!!: уберите  0.0.0.0 ! - Иначе всем и все!
8. Строим базу, предварительно перезапустив rpcbind :
sudo initctl restart rpcbind
Собственно базы:
sudo /usr/lib/yp/ypinit -m
Будет спрошено про сервера, CTRL-D нас устроит.
9. (Re)start everything:
sudo initctl restart rpcbind
sudo initctl start ypserv
ypcat passwd должен нам показать пароли, все работает
10. Обновление (добавили пользователя или что-то еще):
sudo make -C /var/yp

В плане безопасности не лишне будет прочитать Howto, приведенный в начале. В двух словах... rpc штука дырявая и закрывать ее при помощи iptables обязательно, особенно имея ввиду yppasswd. 

Теперь клиент:

1. Пакеты:
sudo apt-get install rpcbind nis
Отвечаем на вопрос про имя домена. Рекомендуется так же ограничить доступ к rpcbind в /etc/hosts.allow  :
rpcbind : NIS Server IP
2. Разрешаем сервис NIS:
В хвост /etc/passwd добавляем строчку:
+::::::
В  /etc/group аналогично:
+:::
И в /etc/shadow аналогично:
+::::::::
Смотрим что у нас в  /etc/nsswitch.conf это порядок опроса разных источников имен. "compat" означает как раз режим с использованием "родных" файлов и NIS. Остальное прозрачно. 
3. Правим  /etc/yp.conf - прописываем наш сервер (и запасной, если делали):
ypserver 123.45.67.89
ypserver 187.65.43.21
4. (За)пускаем nis
initctl restart ypbind
5. Проверяем так же при помощи ypcat. Остались скрипты для SAMBA.

SAMBA

В /etc/samba/smb.config прописываем "свои" проги
add user script = /usr/local/bin/useradd.local  %u
passwd program = /usr/local/bin/passwd.local %u

Ну и сами эти скриптики.
useradd.local

#! /bin/bash
ADD=/usr/sbin/useradd
#ADD="bash ./fakeuser"
if [ -z "$1" ]; then
    echo "usage: $0 "
    exit 1
fi
CWD=`pwd`
$ADD -s /sbin/nologin $1
# Make a homedir
mkdir /home/$1chown $1.users $1chmod 0700 /home/$1 
cd /var/yp
make
cd $CWD
и passwd.local
#! /bin/bash
ADD=/usr/bin/passwd
if [ -z "$1" ]; then
    echo "usage: $0 "
    exit 1
fi
CWD=`pwd`
$ADD  $1
cd /var/yp
make
cd $CWD
В используемые в хозяйстве иные скрипты для создания и удаления пользователей дописали в хвост make -C /var/yp И на этом вроде все...
И еще мелкое продолжение про Самбу было написано 2 мая 2016.

И добавление одного скрипта (заводит нового пользователя в NIS и в SAMBA) от 21 феврала 2021

#! /bin/bash
# use: bash ./newuser.bash newname newpass realname_f.l.

if [ -z "$3" ]; then 
    echo "usage: $0 <username> <password> <realname_f.l.>"
    exit 1
fi

CWD=`pwd`

echo "Добавляем юзверя $3 как: $1 с паролем $2"
useradd  $1 -G fuse,scanner,vboxusers,audio,cdrom,video,plugdev,lpadmin -m -s "/bin/bash" -c $3
echo $1:$2 | chpasswd
chgrp adm /home/$1
chmod 0750 /home/$1

echo "И в самбу добавим"
echo $2 | tee - | smbpasswd -a -s $1

cd /var/yp
make



воскресенье, 8 февраля 2015 г.

Смена пароля на сервере с Fat-client.

Исходные данные: 
Xubuntu 14.04 (32-LTSP-client и сервер 64 разряда).

Дано: LTSP-Сервер к которому подключено примерно 150 бездисковых станций по принципу fat-client. Нужно сделать смену пароля (входного и samba) удобным для пользователей способом (без терминального захода на сервер, им это не поднять).

Просматривается два варианта - через apache на сервере и посредством чего-то самописного и совсем не сложного. В обоих случаях удобно использовать smbpasswd (локально или с ключиком -r). Для смены входного пароля нужно в smb.conf иметь такой кусочек:


# For Unix password sync to work on a Debian GNU/Linux system, the following
# parameters must be set (thanks to Ian Kahan <<kahan@informatik.tu-muenchen.de>
# sending the correct chat script for the passwd program in Debian Sarge).      
   passwd program = /usr/bin/passwd %u                                          
   passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\
                                                                                
# This boolean controls whether PAM will be used for password changes           
# when requested by an SMB client instead of the program listed in              
# 'passwd program'. The default is 'no'.                                        
   pam password change = no                                                             
В результате smbpasswd будет заодно менять и входной пароль.

Относительно работы через apache и php можно посмотреть примеры:
Change Linux or UNIX system password using PHP script
ROUNDCUBE
Gentoo forum
horde-groupware
Какого-то совсем-совсем готового рецепта там нет. Ну и из пушки по воробьям... Скорее всего это как вариант для более глобальной системы на будущее.

Вариант альтернативный - скрипт на zenity. Вот что получилось:
#! /bin/bash
# Assigments

if [ -z $SERVER ] ; then
   SERVER=10.0.0.3
fi

###########################

FORM=`zenity --forms --title="Смена пароля" \
    --text="Все поля обязательны." \
    --separator="|" \
    --add-password="Старый пароль" \
    --add-password="Новый пароль (не менее 6 символов)" \
    --add-password="Еще раз новый пароль"`

case $? in
    0)
        OLDPW=`echo $FORM | cut -d '|' -f1`
        NEWPW=`echo $FORM | cut -d '|' -f2`
        NEWPW2=`echo $FORM | cut -d '|' -f3`
        if [ ! $NEWPW == $NEWPW2 ] ; then 
          zenity --error --text="Новые пароли не совпадают. Изменения не внесены."
          exit 1
        fi
        echo -ne "$OLDPW\n$NEWPW\n$NEWPW\n" |  smbpasswd -r $SERVER -s
        case $? in
             0)
                zenity --info --text="Пароль успешно изменен."
             ;;
             1)
                zenity --error --text="Попытка не удачна (не верный пароль?) Изменения не внесены. Самая частая ошибка - ввод пароля на русском языке... "
             ;;
             -1)
                zenity --error --text="Внутреняя ошибка 002. Изменения не внесены."
            esac

    ;;

    1)
        zenity --info --text="До свидания."
    ;;
    -1)
       zenity --error --text="Внутреняя ошибка 001. Изменения не внесены."
    ;;
esac

 Положили его в /usr/local/bin/npwd.bash (на самом деле /opt/ltsp/i386/usr/local/bin/npwd.bash) и для запуска создаем элемент меню:
[Desktop Entry]
Version=1.0
Type=Application
Name=Смена пароля
Comment=Смена пароля на сервере
Icon=access
Exec=/usr/local/bin/npwd.bash
Path=/tmp
NoDisplay=false
Categories=Other;menulibre-прочее;
StartupNotify=false
Terminal=false
Обзываем его npwd.desktop и раскладываем каждому юзеру в .local/share/application. Выглядит оное произведение вот так...

Исправления.

Добавлено через пару дней...
Смена пароля работает при наличии в smb.conf строчки
pam password change = no 
Иначе этим будет заниматься pam, а там все куда сложнее...