Установка linux через wds

Добавляем WDS универсальности

Добрый день, уважаемые хабра-жители!

Целью данной статьи является написание небольшого обзора возможностей по развертыванию различных систем через WDS (Windows Deployment Services)
В статье будут приводиться краткие инструкции для развертывания Windows 7 x64, Windows XP x86, Ubuntu x64 и добавление таких полезных инструментов в загрузку по сети как Memtest и Gparted.
История будет рассказывать в порядке приходящих мне в голову идей. И начиналось все с Microsoft…

А теперь сама история:
Не так давно мне пришла в голову здравая идея разворачивать на работе системы с помощью WDS. Если за нас кто-то делает работу, это приятно. А если при этом мы узнаем что-то новое — это приятно в двойне. Не буду очень подробно останавливаться на описании установки роли WDS — Microsoft все сводит к Далее-Далее-Далее и статей на эту тему — горы. И кратко расскажу про работу с образами Windows с остановкой на тех моментах, которые вызвали у меня затруднения. Боле подробно будут описаны системы не от Microsoft (ради чего статья и затевалась).
Приступим.
Сервер, который будет выступать в роли хранилища образов и координатора действий имеет Windows Server 2008 R2 на борту. Для корректной работы этой службы необходимы такие роли как DHCP и DNS. Ну и AD — для ввода машинок в домен. (Все эти роли не обязательно держать на одной машине, они могут быть размазаны по всей структуре. Главное, чтобы корректно работали)

1. Настройка WDS

2. Универсальный загрузчик

DEFAULT vesamenu.c32
PROMPT 0
NOESCAPE 0
ALLOWOPTIONS 0
# Timeout in units of 1/10 s
TIMEOUT 300
MENU MARGIN 10
MENU ROWS 16
MENU TABMSGROW 21
MENU TIMEOUTROW 26
MENU COLOR BORDER 30;44 #20ffffff #00000000 none
MENU COLOR SCROLLBAR 30;44 #20ffffff #00000000 none
MENU COLOR TITLE 0 #ffffffff #00000000 none
MENU COLOR SEL 30;47 #40000000 #20ffffff
MENU BACKGROUND pxelinux.cfg/picture.jpg #picture 640×480 for background
MENU TITLE Choose your destiny!

LABEL wds
MENU LABEL Windows Deployment Services (7, XP, Boot images)
KERNEL pxeboot.0

LABEL local
MENU DEFAULT
MENU LABEL Boot from Harddisk
LOCALBOOT 0
Type 0x80

3. Обучаем орленка летать

Memtest

label MemTest
menu label MemTest86+
Kernel memdisk iso raw
initrd Linux/mt420.iso

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

Gaprted

LABEL GParted Live
MENU LABEL GParted Live
KERNEL Distr/Gparted/vmlinuz
APPEND initrd=Distr/Gparted/initrg.img boot=live config union=aufs noswap nopromt vga=788 fetch=http://192.168.10.10/Distr/Gparted/filesystem.squashfs

Ubuntu 12.04

LABEL Ubuntu
KERNEL Distr/Ubuntu/linux
APPEND priority=low vga=normal initrd=Distr/Ubuntu/initrd.gz

LABEL Ubuntu Auto Install
KERNEL Distr/Ubuntu/linux
APPEND initrd=Distr/Ubuntu/initrd.gz ksdevice=eth0 locale=ru_RU.UTF-8 console-setup/layoutcode=ru url=http://192.168.10.10/Distr/Ubuntu/preseed.txt

Полезность на будущее

Просматривая материал по теме и ища ответы на свои вопросы, была обнаружена замечательнейшая статья от Alexander_Erofeev с описанием загрузки Kaspersky Rescue Disk по сети. К сожалению, у меня не взлетело. Но инструмент действительно полезный (нет-нет, да схватят особенно рьяные пользователи чего-нибудь эдакого… Полезно иметь такой инструмент под рукой)

Источник

Automating Ubuntu Installs Via WDS + Active Directory Authentication

Table of Contents

Introduction

If you don’t already know, I work at a small Racine County school district in Wisconsin as the sole IT sysadmin. I started there about a year ago, and ever since I’ve been trying to figure out how to make my job easier while providing the necessary equipment to students and staff. One of the biggest things I’ve noticed is students rarely use Windows for anything other than accessing Google Apps via Chrome (and games, but that’s a story for another time). I started thinking to myself how we might be able to better utilize our existing hardware without spending a dime, and that’s when I came up with the idea to install Ubuntu on a limited number of machines. If you want to read on how I think that things like Ubuntu can get students more interested in technology, I’ve created a separate post here.

pxelinux – Messing with WDS’s TFTP PXE server

To start off with what we need to do is get WDS to push out the syslinux derivative pxelinux — a lightweight bootloader designed to be used with PXE booting. If you’re unaware, WDS is basically the Windows installer disc (Windows PE) designed to work over the network plus some PXE-specific bootloaders. For my example I will be adding Ubuntu 13.04 with using Windows Server 2008 R2 as my WDS server.

Hint: I basically just followed the official syslinux wiki: http://www.syslinux.org/wiki/index.php/WDSLINUX

That should be it. Usually I like the idea of restarting the WDS service and then just verifying all of my options and make sure my files are in the correct place. Now you can PXE boot your client. Hopefully instead of the normal WDS bootloader you now get a bootloader with a gray background. Choose the Ubuntu option, give it a couple minutes, and then you should see the Ubuntu live desktop!

Active Directory Authentication

I may end up revising this section due to the fact that right now I am using likewise-open for AD auth but it works. Grab yourself an install of Ubuntu and follow along:

1. Open up Terminal
2. Install Likewise Open and our OpenSSH server for testing
   sudo apt-get install likewise-open openssh-server
3. Join our domain substituting “ad.example.com” for the FQDN of your AD domain and “domainadmin” for an AD user that has privileges to join computers to the domain (note: likewise-open will bind to your domain using the hostname. Configure this first if you need to)
   sudo domainjoin-cli join ad.example.com domainadmin
4. Input the password for the user you specified
5. Woot! Your computer is now joined to the domain. Check your domain to confirm that AD sees the computer.
6. If you were to test authentication right now, it won’t work unless you do insert the domain before the username (ADadmin) so let’s fix that:
   sudo lwconfig AssumeDefaultDomain true
7. Reboot the machine
8. Test AD auth. Open up an SSH client on another machine and try logging into your Ubuntu client using AD credentials
9. If #8 worked you’re good to go. If you notice, however, if you try logging in on the Ubuntu client, you only have the options of logging in via your local user(s), guest, or remote login. Run the commands below and then reboot to fix this:
10. Try logging in again via the login GUI

Using preseed to automate Ubuntu installs

This was the section I had the most issues with. Documentation is thin, and usually in engineer-ese. Just follow the steps below and if you want to know anything, feel free to leave a comment.

I guess I should kick off by saying what preseed is. When you preseed you basically create a configuration file that answers questions that you are asked during the install of modern Debian Linux distros. You can do things such as specify partitioning settings, locale, keyboard layout, and packages that you may want to install along the way. You can also run scripts which we will be doing in the last section. If you want to check out what a preseed file may look like, scroll down a bit or check out the one from 12.04’s documentation.

1. Since we’ll be loading our preseed file from http, we need an http server. I like Apache. Many places use Apache for other purposes too. If you want to use a current Apache server, please please please restrict it only to the network you will be preseeding on. If you do not have an Apache server already, you will need a machine running Ubuntu Server. Straight Debian will work too.
2. Just for good measure, under the root of your Apache site (usually /var/www ) make a directory named preseed
3. Create a new file named ubuntu.seed and type the following lines in it:

• Make sure you change the account information in the file to something to your liking
• Remember that file name default under %wdsroot%/boot//pxelinux.cfg ? Open that up again and append the following to the bottom:
• We need to change the installer for Ubuntu. The default live installer doesn’t work for preseed well. Luckily Canonical is there to help us out. You’ll need to download the Ubuntu Netboot Installer archive. If you are using 13.04 and x86 I’ve linked it here.
• Extract the folder ubuntu-installer located in the archive to %wdsroot%/boot//linux/ubuntu/13.04-desktop/
• That’s it!

Hopefully now if you PXE boot again you will have the option for preseeding at the bottom. Try it out on a machine and see how the install goes. If it’s all good, we’ll move onto the next part for setting up a cache to speed up the install process.

Setting up an APT cache

So anyone that’s installed packages before on Debian with a slow connection knows how long it can take. Multiply that by X number of machines you want to deploy and it can add up fast. Hell, even the Ubuntu installer loads tons of packages from the internet. We can cut the install time in half just by setting up a package cache.

If you’ve installed Ubuntu before and paid attention to how many packages it downloads, you probably know how much this will help. I noticed after setting up the cache I was able to eliminate around 650MB of package downloading from the internet. That’s a nice big number.

To set up the cache we will be utilizing apt-cacher-ng:

1. Install apt-cacher-ng on your Ubuntu server
2. Reboot just for fun.
3. That’s it. No, really. All we need to do now is configure our client
4. Since we’ve already done preseed, we can modify our ubuntu.seed file to use our cacher as a proxy. Find the following lines:

Insert this line under that section:
d-i mirror/http/proxy string http:// :3142/

Done!

To test you will have to run the installer at least twice. Once for downloading the initial packages, a second time for doing an install via the cache. Time both of them too! I went from a 10 minute install on the non-cached install to less than 5 minutes on the cached install!

Tying it all together

Okay, so far we’ve got our PXE server set up to boot Ubuntu Live and our Ubuntu preseeded installer. We’ve seen how we can join a machine to AD with working authentication. And finally we have our apt cache set up to save us precious amounts of time. The final step then is to tie everything together so when we want to install Ubuntu our steps will look like this:

1. PXE boot the client, choose the preseed installer option
2. Input a couple of important fields we don’t want to skip (hostname and partitioning)
3. Wait for the base system to install
4. Install some packages that we want
5. When the installer is done, the machine will reboot automatically
6. Run some scripts on the first start up so we can join our AD domain and customize the login screen, along with setting up our apt cache as a proxy on our client

Alright, it’s getting late (3:30AM) so let’s wrap this up:

1. Modify your ubuntu.seed file again and throw this at the bottom:
   d-i preseed/late_command string sed -i ‘/exit 0/ d’ /target/etc/rc.local; echo «sh /home/sysprep.sh» >> /target/etc/rc.local; echo «exit 0» >> /target/etc/rc.local; wget -O — http://webserver.com/preseed/scripts/sysprep.sh >> /target/home/sysprep.sh
   All this does is grab our script file from our web server and modifies rc.local on our install so it will run on the first boot. The script will run once because it will delete itself.
2. On your Apache server in the preseed directory make another directory called scripts
3. Put these lines into a file named sysprep.sh

• That’s it! Preseed will grab that script from your Apache server on each install and run it on the first boot. The script will auto delete itself and will reboot the computer when it is done running.

I think that’s it for now. It should cover pretty much everything. I’m going to hit publish on this post, but I’ll be back around for cleaning it up a bit.

Источник

Полезные советы IT-администратору: развертывание различных ОС с помощью Windows Deployment Services

Мой коллега Гэри Уильямс – системный администратор с большим опытом работы – поделился советами о том, как можно использовать Windows Deployment Services для развертывания не только ОС Windows. И сегодня я предлагаю его рекомендации вашему вниманию.

Windows Deployment Services (WDS) – полезное дополнение к платформе Windows. Для развертывания виртуальных машин с гостевой ОС Windows этот инструмент можно использовать прямо «из коробки». А после нескольких ловких движений руками он вполне в состоянии справиться с задачей развертывания серверов Linux и VMware при помощи загрузочного меню Preboot eXecution Environment (PXE).

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

Я использую настроенный WDS для развертывания Windows, CentOS и ESXi, про что и расскажу в этом посте. Думаю, что пользователи других платформ найдут здесь идеи и для их развертывания.

Для нашего примера возьмем чистый сервер Windows с диском С: на 60 ГБ под ОС и диском WDS на 300 ГБ для различных файлов WIM, которые нам понадобятся для установки Windows и Linux.

Этап 1: развертывание сервера WDS

Установить на сервере Windows Deployment Services и IIS. Это можно сделать через Server Manager или с помощью PowerShell:

Затем нужно внести изменения в пул DHCP. В частности, можно добавить к нашему серверу еще NIC и настроить выделенную сеть, но я обычно так не делаю, а вместо этого настраиваю основной сервер DHCP – указываю дополнительные атрибуты WDS DHCP. Вот какие настройки я использую:

—Boot Server Host Name — ввожу IP-адрес сервера WDS.
—Bootfile Name – указываю исполняемый файл WDS, который хочу запускать на клиенте.

Остальные 3 настройки имеют стандартные значения для DHCP.

На сервере WDS запустить мастер конфигурации и завершить настройку.

Пара изменений, которые я могу посоветовать внести в сетап:

— Можно интегрировать сервер с Active Directory, т.к. на этом этапе мы задаем настройки Windows, но я предпочитаю отдельно стоящий сервер:

Согласно указываемой настройке, он будет отвечать на запросы клиентских машин и не потребует никаких «танцев» с AD:

— Обычно я меняю путь с C:\RemoteInstall на E:\RemoteInstall, где E: — это упомянутый выше второй диск, который я предназначил для файлов WIM, Linux и пр.

Затем нужно внести изменения в меню PXE – для этого понадобится запустить UI установки WDS, кликнуть правой кнопкой на нашем сервере и в его свойствах на вкладке Boot сменить опцию Require the user to press F12 key to continue the PXE boot на Always continue the PXE boot:

После этого можно добавить файлы .WIM на наш сервер WDS. Берем файлы boot.wim и install.wim с Windows 2016 ISO – и наш сервер подготовлен к развертыванию машин с ОС Windows.

Теперь можно загрузить виртуальную машину с помощью PXE, увидев стандартный для Windows экран загрузки WDS. Это стоит сделать для того, чтобы убедиться, что все работает, поскольку далее мы будем вносить изменения в основную функциональность WDS.

Этап 2: замена загрузчика Windows Deployment Services

Итак, наш сервер WDS готов к развертыванию образов Windows, но мы хотим, чтобы можно было развертывать и образы Linux. Для этого мы поменяем загрузчик WDS на Linux PXE.

Для начала нам потребуется копия sysLinux.

Важно! Версия должна не превышать 3.86, иначе она не будет работать с ESXi (поскольку его инсталлятор базируется аж на 3.26).

Распаковываем sysLinux 3.86. zip во временный каталог и затем выполняем следующие шаги:

Проверяем наличие файлов

core\pxeLinux.0
com32\menu\vesamenu.c32
com32\modules\chain.c32

Переименовываем файл pxeLinux.0 в pxeLinux.com.

Копируем файлы в каталоги remoteinstall\boot\x64 и remoteinstall\boot\x86.

В каталогах x86 и x64 переименовываем pxeboot.n12 в pxeboot.0

Затем из командной строки запускаем следующие команды, чтобы поменять загрузчик на Linux PXE loader:

После этого в каталогах x86 и x64 создаем подкаталог с именем pxeLinux.cfg, а в нем создаем файл с именем default и копируем в него следующее:

Этап 3: редактирование настроек IIS

IIS нужен нам для файлов установки CentOS и ESXi. Я обычно создаю вот такую файловую структуру web-сервера на VMDK с данными:

—E:\web – корневая папка, на которую указывает IIS
—E:\web\centos\7.x\7.1 – установочные файлы CentOS 7.1
—E:\web\vmware\6.5 – установочные файлы VMware 6.5

В настройках IIS нужно включить опцию просмотра файловой структуры, чтобы инсталляторы Linux и VMware могли обратиться к соответствующим файлам.

Для этого запускаем консоль управления IIS, выбираем нужный сервер, выбираем его Default site и включаем Directory browsing командой Enable.

Также можно включить работу по HTTPS.

Этап 4: добавление Linux

Теперь можно добавить возможность установки Linux. Обычно я выполняю вот такие шаги:

1. Скачать самую «лёгкую» версию ISO с CentOS, смонтировать ISO и скопировать содержимое в каталог E:\web\centos\7.x\7.[version] (или другой с таким же понятным названием).
2. После этого можно будет добавить, например, файл запуска (kickstart file) для пущей автоматизации. Например, лично я добавляю в дефолтный файл pxeLinux.cfg вот такой кусок:

Этап 5: добавление VMware

В завершение давайте добавим возможность установки ESXi 6.5.

Источник

Читайте также:  Где находятся иконки приложений linux