ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Метки статьи: ‘FreeBSD’

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Все кто ставил браузер google chrome под FreeBSD и обновил его до последней версии столкнулся с проблемой: «run google chrome as root»

Браузер перестал запускаться под пользователем root.

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

Ну да ладно, есть способ это пофиксить, расскажу о нем.

Идем в порт с хромом:

# cd /usr/ports/www/chromium

Делаем clean (на всякий случай):

# make clean

Затем делаем:

# make extract

После выполнения должна появиться папка work. У меня версия chrome 11.0.696.57,  идем в папку work и далее:

# cd work/chromium-courgette-redacted-11.0.696.57/chrome/browser

В этой папке ищем файл browser_main_gtk.cc, найдя откройте его на редактирование вашим любимым редактором, перейдите к строке 77 или найдите поиском строчку:

if (geteuid() == 0) {

Замените цифру ноль (это ID пользователя root):

# id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)

на любой другой ID, который не пользуется в вашей системе, ну скажем 12345, получится строка:

if (geteuid() == 12345) {

После этого возвращаемся в корень порта:

# cd /usr/ports/www/chromium

Выполняем сборку и инсталл:

# make && make install

После этих действий google chome запустился от пользователя root.

(либо можно закоментировать весь этот IF полностью)

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

Продолжая тему туннелей привожу ещё один способ поднять туннель между серверами под OS FreeBSD — это netgraph туннели.

Netgraph туннель как и OpenVPN туннель позволяет выбрать порт и протокол по которому будет устанавливаться туннель.

Их основное отличие в том, что netgraph туннель реализован на уровне ядра системы и использует все доступные ядра CPU, а OpenVPN реализован в userland`е и использует только одно ядро CPU.

Задача

Поднять netgraph туннель между двумя FreeBSD серверами и пророутить через туннель некоторые подсети.

Дано

  • Внешний IP-адрес сервера FreeBSD1: 1.1.1.1
  • Внешний IP-адрес сервера FreeBSD2: 2.2.2.2
  • Тунельный IP-адрес сервера FreeBSD1: 10.0.0.1
  • Тунельный IP-адрес сервера FreeBSD2: 10.0.0.2

Настройка

Туннель устанавливается между двумя внешнему IP-адресами по выбранному нами порту 2000 и протоколу UDP,  на туннеле назначаются IP-адреса из серой подсети 10.0.0.0/30.

Я приведу настройку только одной стороны, т.к. вторая сторона это просто зеркальное отражение первой.

Создадим интерфейс ng:
# ngctl mkpeer iface dummy inet

Укажем что будем использовать протокол UDP:
# ngctl mkpeer ng0: ksocket inet inet/dgram/udp

Укажем внешний IP сервера FreeBSD-1 (с которого мы и начали настройку) и зададим порт:
# ngctl msg ng0:inet bind inet/1.1.1.1:2000

Укажем внешний IP сервера FreeBSD-2 и порт, на которой мы и устанавливаем туннель:
ngctl msg ng0:inet connect inet/2.2.2.2:2000

Назначим IP-адреса на сам туннель (созданный интерфейс ng0):
ifconfig ng0 10.0.0.1 10.0.0.2 netmask 255.255.255.252

Теперь можно посмотреть что получилось:

# ifconfig ng0

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xfffffffc

Туннель с одной стороны готов, настройте зеркально вторую сторону (сервер FreeBSD-2) и вы должны «увидеть» (пинговать) туннельные IP-адреса с обоих сторон.
После чего можно уже роутить что угодно через установленный вами туннель.

Команда для уничтожения netgraph туннеля:

# ngctl shutdown ng0:

Внимание ! Символ двоеточия в конце это не очепятка, как многие думают, он должен там быть.

Для автозапуска туннеля заглянем в предоставленный нам пример /usr/share/examples/netgraph/udp.tunnel и создадим свой стартовый скрипт /usr/local/etc/rc.d/ng_tun_start.sh

#!/bin/sh

case "$1" in
stop)
        if ifconfig ng0 >/dev/null 2>&1; then
                ifconfig ng0 inet down delete >/dev/null 2>&1
                ngctl shutdown ng0:
                echo "tunnel ng0 was destroyed";
        fi
        ;;
start)
        LOC_EXTERIOR_IP=1.1.1.1
        REM_EXTERIOR_IP=2.2.2.2

        LOC_INTERIOR_IP=10.0.0.1
        REM_INTERIOR_IP=10.0.0.2

        UDP_TUNNEL_PORT=2000
        if ifconfig ng0 >/dev/null 2>&1; then
                echo "tunnel ng0 already up";
        else
                ngctl mkpeer iface dummy inet
                ngctl mkpeer ng0: ksocket inet inet/dgram/udp
                ngctl msg ng0:inet bind inet/${LOC_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
                ngctl msg ng0:inet connect inet/${REM_EXTERIOR_IP}:${UDP_TUNNEL_PORT}
                ifconfig ng0 ${LOC_INTERIOR_IP} ${REM_INTERIOR_IP} netmask 255.255.255.252
        fi
        ;;
*)
        echo "Usage: `basename $0` {start|stop}" >&2
        ;;
esac

Теперь при старте сервера туннель будет автоматически создан и у вас есть возможность в ручную стартовать туннель:
# /usr/local/etc/rc.d/ng_tun_start.sh start

или разрушать его:
# /usr/local/etc/rc.d/ng_tun_start.sh stop

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Панфилов Алексей (lehis (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 1, среднее: 4,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

NetFlow — Netflow — протокол 5 (сеансового) уровня сетевой модели OSI, разработанный компанией Cisco и предназначенный для сбора информации об IP-трафике.

Стандартный пакет flow-tools, помимо приложений, которые показывают содержимое файлов статистики, содержит еще и две интересные службы flow-capture и flow-fanout.
Flow-capure служит для сохранения полученной статистики. Flow-fanout служит для дублирования статистики на разные машины. Обовсем подробнее.

Программно-аппаратное обеспечение
1. ПК P4 — CPU 2.4 GHz, RAM 512 Mb, HDD 1Tb.
2. ОС — FreeBSD 7.2, swap 4 Gb

Установка
1. Обновляем порты:

# portsnap fetch update

или если вы используете команду portsnap впервые:

# portsnap fetch extract

2.  Устанавливаем порт:

# cd /usr/ports/net-mgmt/flow-tools
# make install clean

Настройка

Правим файл /etc/rc.conf:

Так настраивается flow-capture:

# Запускаем flow-capture
flow_capture_enable=»YES»

# Указываем ip-адрес на котором слушается соединение (принимается поток)
flow_capture_localip=»IP_ADDRESS«
вместо IP_ADDRESS укажите IP-адрес сервера, пример: 10.0.0.1

# Указываем ip с которого принимать поток (по умолчанию 0.0.0.0 — принимать с любого ip)
flow_capture_remoteip=»0.0.0.0″

# Указываем порт на который будет приниматься поток
flow_capture_port=»9998″

# указываем путь, по которому будем складывать статистику
flow_capture_datadir=»/usr/local/_dump/ng»

# Параметры работы демона
flow_capture_flags=»-keyvalue»

Так настраивается flow-fanout:


#Включаем flow-fanout
flow_fanout_enable=»YES»

# Указываем ip-адрес на котором слушается соединение(принимается поток)
flow_fanout_ip=»IP_ADDRESS«

# Указываем ip с которого принимать поток (по умолчанию 0.0.0.0 — принимать с любого ip)
flow_fanout_remoteip=»0.0.0.0″

# Указываем порт на который будет приниматься поток
flow_fanout_port=»PORT_NUMBER«

# Указываем правила экспорта статистики
flow_fanout_export=»<source_ip1>/<det_ip1>/<dest_port1> <source_ip2>/<det_ip2>/<dest_port2>»

Перед настройкой следует определиться, каким образом будет осуществляться хранение статистики и её получение.
Вариантов существует по меньшей мере 2:

  • непосредственно принимать поток при помощи flow-capture и сохранять на этой же машине
  • принимать поток при помощи flow-capture и дублировать этот же поток на другую машину

Рассмотри оба варианта на примере использования mpd5 в связке с netflow.

Первый вариант

Допустим, mpd5 и flow-capture у нас работают на одной машине.

Эти параметры следует прописать в mpd.conf:
set iface enable netflow-in
set iface enable netflow-out

set netflow peer 127.0.0.1 9996 #Кому передаем
set netflow self 127.0.0.1 65500 #свой порт, от которого будет происходить передача

Это прописываем в /etc/rc.conf:
flow_capture_enable=»YES»
flow_capture_localip=»127.0.0.1″
flow_capture_remoteip=»0.0.0.0″
flow_capture_port=»9998″
flow_capture_datadir=»/usr/local/_dump/»
flow_capture_flags=»-S60 -z9 -n95 -N0″

Таким образом демон mpd5 будет скидывать, с порта 65500, на порт 9996, flow-capture, информацию о входящем и исходящем трафике,

а flow-capture, в свою очередь, будет складывать её по пути /usr/local/_dump .

Второй вариант
Допустим, mpd5 и flow-fanout у нас работают на одной машине, а flow-capture на другой и нам нужно сливать поток как на коллектор flow-capture, так и на еще одну стороннюю машину.

  • mpd5 и flow-fanout — IP 10.10.0.1
  • flow-capture — ip 10.10.0.2
  • сторонняя машина — ip 10.10.0.3

Сервер 1:
mpd.conf берем из предыдущего примера:
set iface enable netflow-in
set iface enable netflow-out

set netflow peer 127.0.0.1 9996 #Кому передаем
set netflow self 127.0.0.1 65500 #свой порт, от которого будет происходить передача

А вот в /etc/rc.conf настраиваем уже flow-fanout:
flow_fanout_enable=»YES»
flow_fanout_ip=»127.0.0.1″
flow_fanout_remoteip=»127.0.0.1″

# Укажу свой loopback, т.к. нет смысла слушать «с любого адреса»
flow_fanout_port=»9996″
flow_fanout_export=»10.10.0.1/10.10.0.2/9997 10.10.0.1/10.10.0.3/9998″

Сервер 2:
Именно на нем поднимаем flow-capture:
flow_capture_enable=»YES»
flow_capture_localip=»10.10.0.2″
flow_capture_remoteip=»10.10.0.1″

# Можно указать и 0.0.0.0
flow_capture_port=»9997″
flow_capture_datadir=»/usr/local/_dump/»
flow_capture_flags=»-S60 -z9 -n95 -N0″

Сервер 3:
Любое приложение которое принимает flow-поток, будь то биллинг, другой сервер статистики или что-то еще.

Объясню что происходит во втором случае:
Демон mpd5 будет скидывать, с порта 65500, на порт 9996, flow-fanout, информацию о входящем и исходящем трафике. Flow-fanout, в свою очередь, будет сливать это на второй сервер, на котором настроен flow-capture, на порт 9997, и так же он будет сливать эту статистику на третий сервер, порт 9998.

Связка flow-capture И flow-fanout довольно гибкая и позволяет работать с flow-потоком так, как это нужно в зависимости от сложившейся ситуации.

Ключи к flow-capture можно посмотреть в соответствующем man’е.

После всего проделанного запускаем используемые нами сервисы:

# /usr/local/etc/rc.d/flow_capture start

# /usr/local/etc/rc.d/flow_fanout start

Литература и ссылки:
Википедия

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Автор: Andrey

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (Еще не голосовали)
Загрузка...
Отправить на почту Отправить на почту

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

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

На просторах тырнета с помощью гугла была найдена статейка «Ставим VirtualBox на FreeBSD без использования X11«, собственно хорошая статья для старта разборок с виртуализацией.

Приведу копию статьи с моими дополнениями после нее.

Текущая актуальная версия порта VirtualBox — 3.2.4. Начиная, с 3.1.0 версии порт разбит на два: virtualbox-ose-kmod (модули ядра) и virtualbox-ose (сам virtualbox).

 

В текущей версии порта решена проблема с установкой VirtualBox без X11 и со встроенным vnc сервером. Поэтому процесс установки сводится к стандартным действиям.
Действия по шагам:
# cd /usr/ports/net/libvncserver
# make
# make install
# cd /usr/ports/emulators/virtualbox-ose-kmod
# make
# make install

После этого ставим непосредственно VirtualBox:
# cd /usr/ports/emulators/virtualbox-ose
# make config

далее, выбираем нужные нам опции:

# make
# make install

Добавляем загрузку модуля VirtualBox и запуск скрипта для возможности работы адаптера виртульной машины в bridge-режиме (без нее — только NAT):
# echo ‘vboxdrv_load=»YES»‘ >> /boot/loader.conf
# echo ‘vboxnet_enable=»YES»‘ >> /etc/rc.conf

Чтобы лишний раз не перезагружаться, вручную грузим модуль и скрипт:
# kldload vboxdrv
# /usr/local/etc/rc.d/vboxnet start

Создание и настройка виртуальной машины

 

Создаем виртуальную машину (посмотреть все возможные ostype: VBoxManage list ostypes)

# VBoxManage createvm --name MicroXP --ostype WindowsXP --register --basefolder /usr/vbox

Задаем парамерты виртуалки (bridgeadapter1 указывает адаптер хоста, к которому привязываем виртуалку)

# VBoxManage modifyvm MicroXP --memory 512 --floppy disabled --audio none --nic1 bridged --bridgeadapter1 em0 --vram 4 --accelerate3d off --boot1 disk --acpi on --cableconnected1 on

Создаем жесткий диск, размер указывается в мегабайтах

# VBoxManage createhd --filename /usr/local/vbox/iso/MicroXP.vdi --size 1000 --register

Создаем контроллер на виртуалке

# VBoxManage storagectl MicroXP --name "IDE Controller" --add ide

Подключаем диск к контроллеру

# VBoxManage storageattach MicroXP --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /usr/local/vbox/MicroXP.vdi

Подключаем установочный образ к контроллеру

# VBoxManage storageattach MicroXP --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /usr/local/vbox/MicroXP-v0.82.iso

Устанавливаем загрузку с установочного образа

# VBoxManage modifyvm MicroXP --boot1 dvd

Далее, запускаем машину и указываем ей параметры vnc:

# VBoxHeadless -s MicroXP -n -m 5900 -o password

Подключаемся любым vnc-клиентом (например, RealVNC или UltraVNC) и ставим ОС.

—————————————————

Добавлено 24.01.2013

Внимание.

Virtualbox с версии 4.2 изменил работу виртуалок с VNC. Теперь вместо ключа -n нужно запускать так:

# VBoxManage setproperty vrdeextpack VNC
# VBoxManage modifyvm MicroXP --vrdeproperty VNCPassword=password
# VBoxManage modifyvm MicroXP --vrdeauthlibrary null
# VBoxManage modifyvm MicroXP --vrdeport 5900
# VBoxHeadless --startvm MicroXP

Ссылки:

—————————————————

Затем нужно поставить guest additions в виртуалку, без них vnc сервер иногда глючит:

# VBoxManage storageattach MicroXP --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium /usr/local/lib/virtualbox/additions/VBoxGuestAdditions_3.2.4.iso

После этого, виртуальная машина готова к использованию.

Правда, несмотря на установленные guest additions, заставить работать курсор мыши мне не удалось.

—————————

Мои дополнения/заметки

Вышеописанным способом мне удалось установить две виртуальные машины с OS:

  1. FreeBSD 8.1 — в кач-ве сервера
  2. Windows XP — в кач-ве клиента

Запускать с vnc нужно тогда когда необходим доступ к консоли сервера, т.е. получается как удаленная KVM.
Если нужно просто запустить уже готовую и настроенную виртуальную машину, то пользуем:

# VBoxManage startvm MicroXP --type headless

Останавливаем виртуальную машину  через acpi:

# VBoxManage controlvm MicroXP acpipowerbutton

или более жестко:

# VBoxManage controlvm MicroXP poweroff

Выставляем hdd как загрузчик, послее того как установили OS:

# VBoxManage modifyvm MicroXP --boot1 disk

Отцепить установочный диск:

 # VBoxManage storageattach MicroXP —storagectl «IDE Controller» —port 1 —device 0 —medium none

Просмотр всех запущенных машин:

# VBoxManage list runningvms

Просмотр всех зарегистрированных машин:

# VBoxManage list vms

Просмотр информации о виртуальной машине:

# VBoxManage showvminfo MicroXP

Backup

Бекап виртуальных машин можно сделать через команду export, перед выполнением команды export необходимо выключить виртуалку или поставить сделать сохранение состояния:

Выключение:

# VBoxManage controlvm MicroXP poweroff
Сохранение состояния:
# VBoxManage controlvm MicroXP savestate

После чего можно выполнить export:

# VBoxManage export MicroXP -o /usr/WinXP.ovf

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

Недавно я заморочился над темой автоматического резервного копирование виртуальных машин Virtualbox, чтобы они сами ежедневно бекапились. Почитал в Инете каждый «во что горазд» делает. Кто то через export, кто то через clonehd, а кто то через snapshot.

Поразмыслив я для себя все же остановился на варианте с export. Для выполнения задачи резервного копирования виртуальных машин Virtualbox я накатал скрипт на PERL, который запихнул в /etc/crontab OS FreeBSD.

Кому интересно, то вот исходник скрипта для backup`а всех запущенных виртуальных машин: http://subnets.ru/files/virtualbox_backup.pl.txt

Что делает скрипт автоматического backup`а для virtualbox машин:

  • получает листинг всех запущенных виртуальных машин, которые и будут подвергаться бекапу
  • создает директорию для backup`а: /some/path/backup/год/месяц/день/имя_виртуальной_машины
  • создает в backup дире файл readme.txt куда помещает вывод команды showvminfo по бекапируемой виртуалке
  • выполняет savestate виртуальной машины
  • выполняет export виртуальной машины
  • выполняет запуск виртуальной машины
  • после завершения бекапирования всех запущенных машин, скрипт выполняет удаление папки с бекапом месячной давности

Import

Импорт виртуальных машин:
Может понадобиться или при восстановлении из backup`а или просто при переносе на другой физический сервер.
По умолчанию каталог для хранения виртуальных машин является home каталогом юзера под котором вы вошли в систему, чтобы изменить местоположение выполним:

# mkdir -p /usr/vbox/machines
# mkdir /usr/vbox/hdd
# VBoxManage setproperty machinefolder /usr/vbox/machines
# VBoxManage setproperty hdfolder /usr/vbox/hdd

Сначала проверим как оно импортнется:

# VBoxManage import /usr/WinXP.ovf --dry-run

Если все ОК, то теперь можно импортить:

# VBoxManage import /usr/WinXP.ovf

Отныне все виртуалки будут «жить» в каталоге /usr/vbox.

Добавить ещё сетевуху можно командой:

# VBoxManage modifyvm MicroXP --nic2 bridged --bridgeadapter2 vlan4 --cableconnected2 on

Этим мы добавили вторую сетевую карту, забриджевали её с vlan4 на реальном сервере.
Все последущие карты добавляются/изменяются/удаляются так же с указанием —nicX, где X это номер карты

Махнуть MAC-адрес на втором адаптере можно командой:

# VBoxManage modifyvm MicroXP --macaddress2 auto

MAC-адрес будет выбран автоматически, либо можно самому задать мак:

# VBoxManage modifyvm MicroXP --macaddress2 444444444444

Удалить любую сетевуху из виртуалки можно по её номеру, мы удалим вторую, которую создали выше:

# VBoxManage modifyvm MicroXP --nic2 none

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

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

Например мы собирали тестовый стенд из 3-х виртуалок и гоняли на них BGP с использованием Quagga.

—————————

Добавлено 24.01.2013

Внимание. Virtualbox с версии 4.2 инсталит свои модули в папку с ядром /boot/kernel вместо папки /boot/modules:

# ls -la /boot/kernel/vbox*
-r-xr-xr-x  1 root  wheel  243579 24 янв 17:38 /boot/kernel/vboxdrv.ko
-r-xr-xr-x  1 root  wheel  639853 24 янв 17:38 /boot/kernel/vboxdrv.ko.symbols
-r-xr-xr-x  1 root  wheel    9075 24 янв 17:38 /boot/kernel/vboxnetadp.ko
-r-xr-xr-x  1 root  wheel   48281 24 янв 17:38 /boot/kernel/vboxnetadp.ko.symbols
-r-xr-xr-x  1 root  wheel   23080 24 янв 17:38 /boot/kernel/vboxnetflt.ko
-r-xr-xr-x  1 root  wheel   76126 24 янв 17:38 /boot/kernel/vboxnetflt.ko.symbols

Поэтому если вы апгрейднули версию Virtualbox и у вас полезли ошибки такого плана:

# /usr/local/etc/rc.d/vboxnet start
/usr/local/etc/rc.d/vboxnet: WARNING: Can't load vboxnetflt module.

А в /var/log/messages у вас появилось:

kernel: link_elf: symbol ng_free_item undefined

То вам необходимо:

  • выгрузить vboxdrv.ko если он загружен: # kldunload vboxdrv.ko
  • пересобрать virtualbox-ose-kmod
  • загрузить vboxdrv: # kldload vboxdrv.ko
  • # /usr/local/etc/rc.d/vboxnet start

Если и это не помогает, то нужно пересобрать ядро, а потом снова повторить вышеописанную процедуру.

Пересбор ядра:

# cd /usr/src
# make kernel KERNCONF=YOUR_KERNEL_NAME

И с этого момента не забывайте, что если вы по какой то причине пересобирали ядро, то вам нужно после этого пересобирать и virtualbox-ose-kmod.

Ссылки:

—————————

Ссылки

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

 

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 3, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту

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

  1. ISO-образ будущей устанавливаемой системы
  2. Пакет утилит mfsBSD

Приступим к созданию загрузочного имиджа.

Создадим рабочую директорию:
# mkdir /usr/zzz
# cd /usr/zzz

Выкачиваем ISO:
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/ISO-IMAGES/8.1/FreeBSD-8.1-RELEASE-amd64-disc1.iso
Выкачиваем mfsBSD:
#fetch http://people.freebsd.org/~mm/mfsbsd/mfsbsd-latest.tar.gz
распаковываем и переходим в получившующся диру:
# tar xvzf mfsbsd-1.0-beta1.tar.gz
# cd mfsbsd-1.0-beta1/conf/

Тюним конфиги под свои реалии:
# cp loader.conf.sample loader.conf

geom_uzip_load="YES"
mfs_load="YES"
mfs_type="mfs_root"
mfs_name="/mfsroot"
tmpfs_load="YES"
vfs.root.mountfrom="ufs:/dev/md0"
mfsbsd.rootpw="123456"

# cp rc.conf.sample rc.conf

hostname="mfsbsd"
defaultrouter="192.168.109.14"
ifconfig_em0="inet 192.168.109.35 netmask 255.255.255.0" #т.к. сетевая карта известна, то можно ее явно указать

varmfs="YES"
varsize="64m"

sshd_enable="YES"
sendmail_enable="NONE"
cron_enable="NO"

# echo «nameserver 8.8.8.8» >resolv.conf
Монтируем ISO-шник в диру /cdrom
# mdconfig -a -t vnode -f ../../FreeBSD-8.1-RELEASE-amd64-disc1.iso md0
# mount_cd9660 /dev/md0 /cdrom/
# make BASE=/cdrom/8.1-RELEASE/

Extracting base and kernel ... done
Removing unnecessary files from distribution ... done
Installing configuration scripts and files ... done
Generating SSH host keys ... done
Configuring boot environment ... done
Creating usr.uzip ... done
Copying user packages ... done
Creating and compressing mfsroot ... done

Вот и готова наша палочка-выручалочка:
# ls -la *.img

-rw-r--r--  1 root  493  45088768 Nov 11 19:30 mfsboot.img

заливаем ее на удаленную машинку:
# scp mfsboot.img user@remotehost:~/

Далее, заходим на наш удаленный тазик.

Т.к. конфигурацию партиций менять не планировалось, то получаем информацию о текущих партициях:
# bsdlabel /dev/ad0s1 > ~/label.txt

которую нужно где-то сохранить
# scp ~/label.txt user@remotehost:~/

туда же отправляем /etc/fstab
# scp /etc/fstab user@remotehost:~/

Едем дальше:

Осталось записать наш имидж в начало диска:
# dd if=mfsboot.img of=/dev/ad0 bs=1m

dd: /dev/ad0: Operation not permitted

Вот нас и посетила розовая птица обломинго… Но не все так безнадежно — нам поможет в решении этой засады:

# sysctl kern.geom.debugflags=16

kern.geom.debugflags: 0 -> 16

# dd if=mfsboot.img of=/dev/ad0 bs=1m

43+0 records in
43+0 records out
45088768 bytes transferred in 2.797733 secs (16116181 bytes/sec)

Все, мы «закатали» наш временный загрузочный образ и можем ребутаться:
# shutdown -r now

после ребута заходим на наш тазик по ssh сразу под рутом и продолжаем:
Т.к. у sysinstall есть проблемы с созданием устройств в devfs, то сделаем это за него.

В начале пометим системный диск как пустой:
mfsbsd# dd if=/dev/zero of=/dev/ad0 count=2

2+0 records in
2+0 records out
1024 bytes transferred in 0.001632 secs (627369 bytes/sec)

Создадим слайс, размером во весь диск с записью загрузочного кода в сектор 0:
mfsbsd# fdisk -BI /dev/ad0

******* Working on device /dev/ad0 *******
fdisk: invalid fdisk partition table found
fdisk: Class not found

Создаем стандартную метку для диска (включая загрузочный код):
mfsbsd# bsdlabel -wB /dev/ad0s1

Возвращаем обратно инфу о партициях:
scp user@remotehost:/home/user/label.txt .

и реанимируем их:
mfsbsd# bsdlabel -R /dev/ad0s1 label.txt

Форматируем наши партиции:
mfsbsd# newfs /dev/ad0s1a

/dev/ad0s1a: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd# newfs /dev/ad0s1e

/dev/ad0s1e: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd# newfs /dev/ad0s1d

/dev/ad0s1d: 512.0MB (1048576 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 128.02MB, 8193 blks, 16448 inodes.
super-block backups (for fsck -b #) at:
160, 262336, 524512, 786688

mfsbsd#  newfs /dev/ad0s1f

/dev/ad0s1f: 5631.0MB (11532192 sectors) block size 16384, fragment size 2048
using 31 cylinder groups of 183.77MB, 11761 blks, 23552 inodes.
super-block backups (for fsck -b #) at:
160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144,
6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720

Подготавливаем плацдарм для будущей ОС:
mfsbsd# mount /dev/ad0s1a /mnt/
mfsbsd# mkdir /mnt/var
mfsbsd# mkdir /mnt/usr
mfsbsd# mkdir /mnt/tmp
mfsbsd# mount /dev/ad0s1d /mnt/var/
mfsbsd# mount /dev/ad0s1e /mnt/tmp/
mfsbsd# mount /dev/ad0s1f /mnt/usr/

Все, работу по подготовке к инсталляции FreeBSD через сеть мы закончили.
Настало время sysinstall — запускаем его и выбираем пункт меню Custom. В пункте Options ОБЯЗАТЕЛЬНО меняем значение Install Root на /mnt .
Далее посещаем Distributions с выбором там опции Minimal. В Media выбираем ближайший к нам ftp. Финализируем Commit’ом.

Если все хорошо, то появится заветный вопрос «Visit the general configuration menu for a chance to set any last options?», ответ на который зависит от вас.
Мы же продолжаем дальше:

mfsbsd# cp /etc/resolv.conf /mnt/etc/
mfsbsd# cp /etc/rc.conf /mnt/etc/

после чего удалите из него все лишнее.
Опционально:
mfsbsd# cp /etc/ssh/sshd_config /mnt/etc/ssh/

Возвращаем назад fstab:
# scp user@remotehost:/home/user/fstab /mnt/etc

Чрутимся в /mnt:
mfsbsd# chroot /mnt
копируем на место ядро и его модули:

mfsbsd# cp -Rp /boot/GENERIC/* /boot/kernel
Меняем пасс на рута:
mfsbsd# passwd root

Changing local password for root
New Password:
Retype New Password:

Финальный ребут:
# shutdown -r now

Скрестив пальцы, молимся великому пингу и ожидаем поднятия сервера с новой осью 🙂

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Панфилов Алексей (lehis (at) subnets.ru)

Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 4, среднее: 5,00 из 5)
Загрузка...
Отправить на почту Отправить на почту