Далее монтируем этот образ и устанавливаем пакет ltsp-utils.0.11-o.noarch.rpm

После чего мы получаем утилиты командной строки ltspadmin и ltspcfg. Первая утилита используется для настройки установки и самой установки LTSP, вторая – для конфигурации уже установленного терминального сервера. Запускаем утилиту ltspadmin.

Первым делом нам необходимо сконфигурировать установщик, соответственно мы выбираем пункт меню Configure the installer options. Первым вопросом нам предлагается определить откуда мы будем получать пакеты. Можно использовать сайт самого проекта, но разумнее указать путь к смонтированному нами образу. В моем случае это file:///media/CDROM/. Обратите внимание, что в пути используется именно 3 слеша, на что указывается и в документации по установке.

Следующий вопрос – путь куда будет установлен LTSP. По умолчанию он указывает на /opt/ltsp. Его изменять я не вижу смысла. Если же вы указали в качестве пути к местоположению пакетом http адрес (который задан по умолчанию) тогда вам необходимо указать адрес http (или же ftp, если пакеты лежат на ftp) прокси-сервера. В конце подтверждаем правильность настроек и нас возвращает к предыдущему пункту меню. Теперь мы можем приступать к установке терминального сервера.

После установки мы будем иметь:

• пакеты LTSP в папке /opt/ltsp
• файлы, необходимые для загрузки PXE клиентов в папке /tftpboot/lts/

Установка DHCP и TFTP серверов.

Для загрузки по сети наших тонких клиентов нам необходимы DHCP и ТFTP сервера. TFTP сервера в дистрибутиве CentOS я не нашел, а DHCP решил поставить вручную – так надежнее. Соответственно устанавливаем их:

# yum install dhcp.x86_64 tftp-server.x86-64

Далее необходимо открыть 69 порт для UDP протокола в фаерволе нашего терминального сервера. Для этого используем консольную утилиту system-config-securitylevel-tui. Жмем кнопку «Уточнить» и настраиваем правила нашего firewall’a

В моем случае у меня на сервере 2 интерфейса: один смотрит в сеть классов – второй является managment-интерфейсом. Выбираем интерфейс, через который наши тонкие клиенты будут стучаться к tftp-серверу и добавляем его к доверенным, а так же открываем для него 69 порт.

Конфигурация LTSP

Для конфигурации мы можем воспользоваться пунктом меню Configure LTSP утилиты ltspadmin или же напрямую вызвать ltspcfg. В появившемся меню выбираем ручную настройку:

Проходимся по всем 11 пунктам. Пункт 8 можно в принципе пропустить. После завершения — у нас будут настроено практически все необходимое.
Стоит уделить внимание пунктам 3 и 7. В пункте 3 будет создан файл примера конфигурации DHCP сервера (/etc/dhcpd.conf.sample), который необходимо отредактировать. После изменений – у меня он приобрел следующий вид:

Хочу обратить внимание на то, что в путь к PXE загрузчику указывается не полный, т.к. в RedHat и CentOS он запускается с ключем –s, соответственно папку tftp-сервера в пути мы опускаем. Так же возникла проблема с тем, что по-идее опцию next-server необходимо указывать только тогда, когда DHCP и TFTP сервера находятся на разных серверах. Но без этой опции загрузка глохла, пока я не продублировал самого себя в качестве next-server’a.

На этом этапе я обрадовался, что настройка завершена и попытался загрузиться с тонкого клиента. Но не тут то было! В итоге запускались Иксы, но подключения к терминальному серверу не происходило. Как оказалось стандартным менеджером сеансов в CentOS являеться gdm (Gnome), а так как Gnome у меня вообще отсутствовал – kdm даже и не пробовал запускаться. Для того, что бы ОСь использовала kdm необходимо внести некоторые изменения в файл конфигурации, а именно - /etc/sysconfig/desktop (если файл отсутствует – его необходимо создать):

DISPLAYMANAGER="KDE"

Следующим огорчением было то, что при запуске иксов на терминальном клиенте – они падали, т.к. сервер тупо отвергал любые попытки открыть удаленные сеансы. Изменить это не проблема, проблемой для меня стало то, что я не мог найти стандартных файлов конфигурации KDE. В CentOS они «спрятаны» совершенно в другом месте. В итоге его местоположение можно определить следующим образом:

# locate Xaccess

Далее в указанном файле ищем строчку

#* #any host can get a login window

И раскомментируем ее. Перезапускаем Иксы, бутаем наш тонкий клиент – и вуаля! Все работает!

1) Сначала установим ssh-сервер для организации связи между компьютерами в сети

  sudo apt-get install ssh

2) Затем устанавливаем сам LTSP-сервер

  sudo apt-get install ltsp-server-standalone

3) Далее нужно создать конфигурационные файлы для тонких клиентов

  sudo ltsp-build-client

4) Организуем поддержку сетевой файловой системы NFS

  sudo apt-get install nfs-kernel-server

5) Установим TFTP-сервер

  sudo apt-get install tftpd-hpa

6) В конец файла /etc/exports добавляем следующую строчку

  /opt/ltsp *(ro,no_root_squash,async,no_subtree_check)

7)  Перезапускаем сервисы NFS, inetd и tftpd

sudo invoke-rc.d openbsd-inetd restart
sudo invoke-rc.d nfs-kernel-server restart
sudo invoke-rc.d tftpd-hpa restart

 Настроим конфигурационный файл сервера DHCP /etc/ltsp/dhcpd.conf

authoritative;
  subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.70 192.168.1.230;
option domain-name 1example.ru»;
option domain-name-servers 192.168.1.1;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;
option root-path «/opt/ltsp/i386″;
if substring( option vendor-class-identifier, 0, 9 ) = «PXEClient» {
filename «/ltsp/i386/pxelinux.0″;
}

else

     {
filename «/ltsp/i386/nbi.img»;
}
}

9) Настраиваем сетевое соединение (Система -> Параметры-> Сетевые соединения). Здесь выбираем нужное подключение, например Auto eth0 и в параметрах IPv4 указываем те же значения, что мы указали в файле/etc/ltsp/dhcpd.conf. Или так: Профиль: Вручную; Адрес: 192.168.1.1; Маска подсети: 255.255.255.0; Шлюз: 192.168.1.1;  Домены поиска: 192.168.1.1; ID клиента DHCP: 192.168.1.1.

10) В конец файла /etc/dhcp3/dhcpd.conf добавляем строку:

  include «/etc/ltsp/dhcpd.conf»;

11)  Включаем XDMCP (X Display Manager control protocol):

  sudo cp /usr/share/doc/gdm/examples/custom.conf /etc/gdm/

И после копирования добавляем в /etc/gdm/custom.conf:

  [xdmcp]
  Enable=true
  DisplaysPerHost=2

12) Перезапускаем GDM

  sudo restart gdm

13) Запускаем DHCP

  sudo /etc/init.d/dhcp3-server start

14) И/Или перезапускаем DHCP

  sudo invoke-rc.d dhcp3-server restart

На этом настройка LTSP-сервера окончена. Теперь можно включить тонкие клиенты, выбрав загрузку PXE (Preboot Execution Environment). Часто функцию загрузки по сети необходимо разрешить в BIOS (посмотрите в параметрах устройств PCI).
В будущем, после обновления сервера может потребоваться обновить ключи для ssh и образ ltsp:

   sudo ltsp-update-sshkeys

   sudo ltsp-update-image —arch i386

/vmfs/volumes/nfs-backup — соответственно nfs диск где будут лежать бэкапы
/vmfs/volumes/datastore1 — хранилище виртуальных машин

бэкапы старше 5 дней удаляются.

Основываясь на «белом списке», можно сделать не плохую защиту от малвари. Чтобы его создать нужно выполнить, как минимум, два шага:

В ветке реестра HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVerson\Policies\Explorer нужно создать параметр RestrictRun типа DWORD (REG_DWORD) со значением 1.
В ветке HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\ создать ключ RestrictRun, а в нем параметр 01 типа STRING (REG_SZ) со значением regedit.exe.

Чтобы изменения вступили в силу, нужно перезагрузить компьютер.
ВАЖНО! Если выполнить пункт 1, но НЕ выполнить пункт 2, то после перезагрузки вы не сможете запустить никакую программу. Чтобы это исправить, вам нужно будет войти под другим пользователем с админскими правами, открыть редактор реестра, найти в ветку HKEY_USERS, выделить ее, выбрать меню Файл -> Загрузить куст…, в диалоге открытия файла найти файл NTUSER.DATв каталоге юзера, под именем которого был сделан этот косяк, и нажать кнопку «Открыть». После чего найти и удалить параметр RestrictRun либо присвоить ему значение 0, а потом перезагрузиться.

В дальнейшем можно добавлять программы в HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\RestrictRun аналогично пункту 2. При этом перезагрузка уже не нужна, изменения вступают в силу сразу.
Чтобы не лезть в редактор реестра каждый раз, я создал reg-файл, в который занес список программ и в дальнейшем, по мере необходимости, подправлял его, а после правки запускал.

Ниже приведу небольшой кусочек этого файла:

Пусть ноды с данными будут node1.host.ru и node2.host.ru, а управляющая нода mgmt.host.ru. DNS настроен, все ноды видят друг друга как по IP так и по FQDN. Так же необходимо чтобы на нодах данных был открыт порт 3306 для всех нод-участников кластера, а на ноде управления открыт порт 1186.

Допустим IP адреса у серверов такие:

node1 192.168.1.1
node2 192.168.1.2
mgmt 192.168.1.3

Добавим кластерную конфигурацию, создадим конфигурационный файл /etc/my.cnf со следующими парамметрами:

Далее создадим на каждой ноде каталог /var/lib/mysql-cluster/
Ставим из портов /usr/ports/misc/compat6x

Создаем пользователя и группу mysql

Скачиваем последнюю версию дистрибутива 5.0 с сайта разработчика (в версиях 5.1 и 6.0 кластерная составляющая отсутствует, к тому же в коллекции портов FreeBSD даже в версии 5.0 ее тоже нет) и распаковываем архив в /usr/local/

переименовываем папку в mysql чтобы получилось /usr/local/mysql
идем туда и создаем системные базы данных

scripts/mysql_install_db —user=mysql

Меняем права на папки (находясь в каталоге /usr/local/mysql):

копируем стартстопный скрипт

cp support-files/mysql.server /usr/local/etc/rc.d/mysql.server

Запускаем его

создаем файл etc/rc.local и добавляем туда скрипты старта кластера

Меняем пароли root сервера mysql:

node1:

node2:

Оставим пока сервера данных и займемся нодой управления:

Ставим из портов /usr/ports/misc/compat6x

Нам нужны консоль и демон управления ndb_mgm и ndb_mgmd соответственно. Взять их можно из архива дистрибутива mysql в каталоге /bin. Распаковываем эти два файла в /usr/local/bin

Создаем каталог /var/lib/mysql-cluster/ и создаем в нем конфигурационный файл для управления config.ini:

Стартуем демон управления(для автозапуска при загрузке сервера эту строку нужно добавить в /etc/rc.local):

#/usr/local/bin/ndb_mgmd -f /var/lib/mysql-cluster/config.ini

Запускаем проверку работоспособности консоли:

/usr/local/bin/ndb_mgm

в окне приглашения вводим show, и видим следующую картину:

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

На ноде управления снова проверяем работу кластера через ndb_mgm:

Если в строках id1 id2 id3 id4 и id5 видно работающие, отвечающие демоны как это видно выше, то все ок и кластер работает. Если нет — еще раз смотрим эту документацию.

Проверяем отказоустойчивость кластера:

Допустим на первой ноде заходим в mysql и создаем табличку в базе test:

Теперь на второй ноде делаем SELECT из базы test:

Как видим, на второй ноде у нас уже есть данные, которые были на первой, а значит кластер работает. Можно еще проверить записав в таблицу значение на второй ноде и запустить SELECT на первой — увидим все данные.

Теперь перезапустим например node2
при этом пока нода будет перезагружаться в ndb_mgm мы последовательно будем видеть такие ее состояния:
нода выключена:

id=3 (not connected, accepting connect from 192.168.1.2)

потом когда mysql на ней запустится станет:

id=3 @192.168.1.2 (Version: 5.0.85, starting, Nodegroup: 0)

потом когда кластер войдет в рабочий режим:

id=3 @192.168.1.2 (Version: 5.0.85, Nodegroup: 0)

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

Как видно, база данных не потерялась а продолжает работать и без одной ноды. Теперь проверим восстанавливаемость кластера, подключив к сети отключенную ранее ноду и сделав на ней SELECT из этой же базы:

Все работает!

mount – показывает смонтированные подразделы и флаги из монтирования

df – показывает смонтированные подразделы, их размер и свободное место на нихfdisk /dev/ad0 – показывает информацию о диске ad0 и разделах на нем

disklabel /dev/ad0s1 – показывает список подразделов в первом разделе диска ad0

swapinfo – показывает список подразделов свопинга на дисках и их использование

fstat – показывает список открытых файлов (имена файлов не выводятся)

pstat -f – выводит список открытых файлов (имена файлов не выводятся)

systat -vmstat n – каждые n секунд выводит количество транзакций с диском в секунду, объем записанных/считанных данных на диск в секунду, средний размер транзакции и процент времени в течение которого диск был занят работой)

iostat – выводит информацию, аналогичную systat -vmstat, но не выводит занятости диска по времени и может выводить среднюю статистику с момента загрузки.

vmstat – выводит количество операций на диске в секунду

/stand/sysinstall – можно посмотреть и изменить разметку диска и монтирование

less /etc/fstab – таблица монтирования при загрузке

systat -vmstat n – вывод показателей загрузки (number of jobs in the run queue averaged over 1, 5 and 15 min), состояния памяти (в страницах), количества процессов в группах, количество вызовов специальных функций ядра (traps, interrupts, system calls, network software interrupts), использование процессора, трансляции имен, активность свопа, прерывания, а также информацию по использованию диска (см)

top – аналогичная информация в сокращенном виде + использование памяти и свопа в мегабайтах, список процессов, отсортированных по использованию процессора.

ps afx – список запущенных процессов и время процессора на каждый

ifconfig – список сетевых интерфейсов с ip-адресами, масками, mac-адресами, типами карт и их статусами (названия карточек можно посмотреть в файле конфигурации ядра)

systat -ifstat n – объем трафика за n секунд на всех сетевых интерфейсах

netstat – вывод активных сетевых соединений (сокетов)

systat -netstat n – аналог netstat в реальном времени

systat -ip n – таблица IP-пакетов и ошибок по типам за n секунд

systat -tcp n – таблица TCP-пакетов и ошибок по типам за n секунд

systat -icmp n – таблица ICMP-пакетов и ошибок по типам за n секунд

netstat -ibt – список интерфейсов, разбитых по ip-адресам (!) с объемом трафика на каждом, количеством ошибок, коллизий, значением watchdog-таймера

netstat -r – таблица маршрутизации

arp -a – таблица ARP

tcpdump -i rl0 host 192.168.1.2 and port 21 – сниффер пакетов на интерфейсе rl0, фильтрующий пакеты, содержащие адрес 192.168.1.2 и порт 21

trafshow -i rl0 – программа для сортировки и вывода сетевых потоков (устанавливается дополнительно пакетом или из портов)

date – текущее время и дата

w – выводит, сколько времени назад система загрузилась и залогиненных пользователей

last – выводит историю перезагрузок и входов пользователей

host1 (192.168.1.2) и host2 (192.168.1.1)
На каждом сервере диски: ad0 с системой, ad1 — неразмеченный.

ad1 будет под контролем HASTd и ZFS, на которой будет работать JAIL.
Сервера скоммутированы на свиче в одну подсеть (мой случай — 192.168.1.0/24), 1 Gbit/s интерфейс.
Между серверами будет поднят виртуальный (carp) IP 192.168.1.5, принадлежащий jail-у.

Пишем /etc/rc.conf.

На host1:

На host2:

Пишем конфиг ядра GENERIC-CARP для поддержки carp(4) ( есть впрочем вариант userland-ового net/ucarp ).

На обеих нодах:
Архитектура i386, соотв. /sys/i386/conf/GENERIC-CARP:

device carp

Компилируем и перезагружаемся, на обеих машинах.

make buildkernel KERNCONF=GENERIC-CARP;make installkernel KERNCONF=GENERIC-CARP;reboot

Пишем на обеих машинах одинаковый /etc/hast.conf:

Запускаем hastd (на обеих машинах):

/etc/rc.d/hastd restart

Создаем файловую систему для Jail/HASTd (делается только на одной машине, вторая получит все это добро через реплику) и сообщаем HAST-у, что он у нас будет мастером.

Настроил ezjail на обеих машинах:

Добавим новый джэйл на host1:

ezjail-admin create -s 10G -c zfs vm1 192.168.1.5
скопируем конфиг /usr/local/etc/ezjail/vm1 на host2.

Содержимое /root/carp_sw скрипта, ответственный за переключение (не забыть chmod +x /root/carp_sw):

Также, чтобы упавшая и поднявшаяся машина не пыталась запускать jail, скажем ей что она теперь Slave. Содержимое /etc/rc.local на обеих машинах:

Остается все это позапускать (на обеих нодах):

На host1:

На host2:

Что получили в результате этой работы:

На carp-овом IP работает JAIL, который может содержать все что душе угодно — почтовый сервис, WEB приложение и пр. Как только обслуживающая этот jail физическая машина падает, работу на себя автоматически подхватывает второй сервер, который запускает JAIL на состояние максимально близкое к времени падени ноды. При этом HAST конфигурируется как MASTER. Когда-нибудь возвратившаяся упавшая машина становится SLAVE-ом, подхватывает реплику и готовится подстраховать MASTER-а

система создаcт raid1 массив но на него пока ничего не бдует писаться.

Но статус у него READY:

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

Попробуем обмануть систему.

Теперь у нас есть целостный RAID1 который состоит из одного диска с системой.

Теперь нужно прописать ar0 в fstab

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

После окончания пересборки(rebuild) система готова к использованию.

При сборке ядра выводятся следующие ошибки:
kernel/built-in.o: In function `getnstimeofday’:
(.text+0xe34b): undefined reference to `__umoddi3′
kernel/built-in.o: In function `do_gettimeofday’:
(.text+0xe3ec): undefined reference to `__udivdi3′
kernel/built-in.o: In function `do_gettimeofday’:
(.text+0xe409): undefined reference to `__umoddi3′
kernel/built-in.o: In function `do_timer’:
(.text+0xf109): undefined reference to `__udivdi3′
kernel/built-in.o: In function `do_timer’:
(.text+0xf126): undefined reference to `__umoddi3′
Причина

Сборка ядра не поддерживается ваш компилятор.

Решение

$ cd /usr/src/linux/

поменять значение CFLAGS_KERNEL в Makefile на CFLAGS_KERNEL    = -fno-tree-scev-cprop

Ключевые улучшения VirtualBox 4.0.0:

• Значительно переработан пользовательский интерфейс (который теперь называется «Менеджер VirtualBox»):
  • Окно настроек содержит экскизы экранов виртуальных машин, которые обновляются в режиме реального времени;
  • Добавлен режим работы виртуальной машины «масштабирование», который позволяет растянуть окно до нужного размера (например, в случае, когда гостевое приложение не поддерживает родное разрешение экрана, можно просматривать его в полный экран);
  • Добавлена поддержка создания и запуска виртуальных машин с помощью соответствующих ярлыков (расширение файла .vbox);
  • Список гостевых ОС можно отсортировать;
  • Стало возможным удалить гостевую машину полностью, включая все снапшоты, а также при желании удалить присоединенные устройства хранения;
• Новый формат для файлов с настройками и дисковыми образами, измененный с целью повышения переносимости виртуальных машин;
• Поддержка формата архивов OVA (Open Virtualization Format Archive), созданного с целью стандартизации поставки образов виртуальных машин и формирования пакетов конечных приложений, предназначенных для запуска в различных виртуальных окружениях. Пакеты OVA универсальны и не привязаны к определенной архитектуре и системе виртуализации. Пакеты представляют собой обычный TAR-архив с набором дополнительной мета-информации, хранимой в подкаталоге OVF;
• Расширены возможности контроля за ресурсами: добавлена возможность установки ограничения на потребляемое виртуальной машиной процессорное время и на пропускную способность ввода/вывода;
• Обеспечена возможность изменения размера VDI и VHD образов;
• Обеспечена возможность выделения гостевым окружениям более 2 Гб ОЗУ на 32-разрядных хост-системах;
• Добавлена поддержка эмуляции для гостевых систем чипсета Intel ICH9 с тремя PCI-шинами, PCI Express и системой MSI (Message Signaled Interrupts);
• Добавлена поддержка эмуляции для гостевых систем звуковой подсистемы Intel HD Audio;
• Для iSCSI, VMDK, VHD и дисковых образов Parallels добавлена поддержка асинхронного ввода/вывода;
• Подготовлен унифицированный набор Java-биндингов, поддерживающих как локальный API COM/XPCOM, так и удаленный API SOAP;
• Для Windows подготовлена функция автоматического обновления пакета паравиртуальных драйверов и дополнений Guest Additions;
• Для гостевых окружений на базе Linux и Solaris в Guest Additions добавлена возможность создания нескольких виртуальных экранов (драйвер поддерживает X.Org server 1.3 или более новую версию);
• В Guest Additions добавлена поддержка копирования файлов в гостевую файловую систему.

Готовые установочные пакеты доступны для Linux (Ubuntu, Fedora, openSUSE, Debian, Mandriva, SLES, RHEL), Solaris, MacOS X и Windows.