*THIS POSITION HAS CLOSED.  THANK YOU FOR YOUR INTEREST.*

Our client’s growing their Technical Operations team to meet the demands of their rapidly growing user community, and have a terrific opportunity for a DATA CENTER ADMINISTRATOR with strong attention to detail and excellent communication skills. This position is primarily onsite at local data centers, with occasional onsite work in their Oakland, CA offices, and travel to remote data center locations a few times per year. Our client’s team is small, agile and dedicated.  They value diligence and creativity in scaling our infrastructure while consolidating servers as our usage continues to grow.  We are  looking for the right person for this position – someone who’s ready to dig in on day one, with substantial hands-on experience in data centers and a “can-do” attitude.

RESPONSIBILITIES

As a member of our client’s Technical Operations team, you will have primary responsibility for the daily operations of our SAN JOSE, CA and SAN FRANCISCO, CA co-location data centers. Primarily on site in San Jose, you will be the eyes, ears and hands for our client’s team there – coordinating everything from rack mounting servers, performing routine maintenance and hardware troubleshooting to structured cable design, operating system installs, cross-connect installs, vendor deliveries and physical plant maintenance.

REQUIREMENTS

You must be self-motivated, capable of managing your time well, and work efficiently without close supervision. Meticulous and well-documented work is an absolute must. You should be enthusiastic about hardware and cabling installation, diagnostics, and repair. You will be responding to trouble tickets opened by staff members but will also be expected to proactively identify and resolve problems as you gain familarity with our client’s systems.

• 5 years extensive PC Hardware experience and detailed knowledge of components (x86, x86_64 with a strong preference for white/grey box systems)
• Minimum 5 year hands-on UNIX/Linux experience, including solid knowledge of OS install, configuration, and boot
• Experience working in a 24/7 customer-facing environment
• Experience building & maintaining structured cabling
• Strong experience with host-based storage & RAID
• Strong understanding of ethernet networking & TCP/IP
• Reliable transportation between Oakland, San Jose,  and San Francisco (available as needed, 24/7)
• Be able to lift 50lb to a height of 6ft
• Available for occasional off-hours (24/7) on-site data center support

DESIRED SKILLS

• Experience with Debian or Ubuntu
• Experience with enterprise switches (Cisco, Force10, Arista, Foundry)
• Understanding of Load Balancers
• Familiarity with optical networks
• Scripting in BASH, Perl and/or Python
• System monitoring (Nagios, Cacti, Smokeping)
• Understanding of DHCP, PXE and automated system installs

If you are interested, please send us your resume to tsotelo@mindsource.com.

I’ve been into computers for some time now and although nowadays old hardware is considered of no use, I still keep couple of my previous machines.  Oldest one has AMD’s K5 processor which runs at 75 Mhz, 64 MB of memory,  and two PCI cards – USB and ethernet. Well, it may be not impressive, but what I really like about it it’s that CPU only needs heat sink (which is really small, not like some Thermaltake copper towers), also I replaced fan in PSU so that there was hardly any noise coming from case. The only problem was hard disk. Racket coming from spinning platters was unbearable and let be honest, almost all hard disk suffer from this problem. They are often the noisiest part of PC. So that got me thinking, how can I still use that old piece of junk and make it quiet. Answer came almost immediately – pendrive. Idea wasn’t bad but there was little problem, there was no way to make it boot from usb. Another idea – buy a CompactFlash card and device to emulate it as hdd, but I didn’t want to waste money, even if it wasn’t much. I was in dead end, there wasn’t a single thing I could think about that would help me.

After several months I came across something called PXE. It let’s you boot computer using ethernet card, dhcp and tftp server.  It isn’t as easy as normal hdd or floppy booting, but still it’s fairly straightforward. Almost all network cards support PXE booting, but to be on safe side you better check before proceeding.

DHCP Server

Next thing was to set up dhcp and tftp. First tutorial I found mentioned using ISC dhcp server which I had no experience with. I decided to go in different direction, so after getting some courage (in form of two beers), I dig into dnsmasq documentation, which I was using for a long time. I turned out that not only it was capable of providing PXE booting but also had build in tftp server, lucky! Here are the lines that you have to add to dnsmasq.conf (don’t forget to set dhcp-range too)

dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/var/lib/tftpboot

You can put tftp-root wherever you like, I don’t even remember why I decided to put it there. Next thing to do is to get pxelinux.0 ….. to tell you the truth I don’t remember where I found mine, but it turns out that there is one in syslinux-common package in debian, just click on “all” link in table and unpack it with p7zip. After placing pxelinux.0 in tftp it’s time to create some configuration.

cd /var/lib/tftpboot/
mkdir pxelinux.cfg
cd pxelinux.cfg

In that directory create default file using your favourite editor, and put this in it:

default huge
timeout 1000
label huge
kernel bzImg-slack-13
append ro root=/dev/sda1 slowusb rootdelay=15 rootwait

If you ever used lilo you can probably tell that it’s quite similar to lilo.conf. Kernel file defined in fourth line must be placed in tftp root directory. Last line tells kernel where to find root device and what options to use. I had to add rootdelay and rootwait because when it comes to detecting usb devices at boot time it can be quite tricky. On that particular hardware it takes about 5 to 10 seconds to fully detect my pendrive, and if you think that kernel will just politely wait for it, prepare to be surprised.

System

OK, after about 580 words it’s time to prepare that pendrive. There are couple of methods of installing linux on them, but I didn’t really look into any of them, and decided to try one of debian tools called debootstrap. It let’s you install debian in any directory you like in two steps

mkdir /mydebstr
debootstrap lenny /mydebstr http://ftp.us.debian.org/debian

It may take some time, but it’s the easiest way I’ve ever seen of installing linux. After it’s done you have to move it to your pendrive, I don’t know if just moving it will work so I always use tar.

mkfs.ext3 /dev/sda1
mkdir /mnt/pxestick
mount /dev/sda1 /mnt/pxestick
cd /mydebstr
tar -cf - . | tar -xf - -C /mnt/pxestick
cd /
umount /mnt/pxestick
rm -r /mnt/pxestick

Kernel

Almost everything is ready, but we still need a kernel, and not just any kernel. The one we need must have build in usb, ext3, usb storage, and preferably networking support and drivers for your card but it isn’t necessary. Unfortunately most distributions provide small kernel with only a few things build in, and leave rest as modules, then at installation they create initrd with necessary modules and everything is OK. One distribution however offers so called huge kernel – slackware. Just visit one of mirrors and get it from slackware-current/kernels/huge.s/ directory. Just put it in tftp root directory and name it accordingly to default configuration file (mine was called bzImg-slack-13).

Final steps

There are two things left, first, debootstrap doesn’t install udev, so you have to do it yourself. I just put it on pendrive in form of .deb file and then used dpkg -i. It isn’t necessary but …. well, quite useful. Second thing – it’s probable that your ethernet card won’t be in slackware kernel, but fear not. In slackware-current/slackware/a/ there is something called kernel-modules. Just unpack it to / on pendrive also download System.map.gz from kernel directory that I mentioned earlier and place it in /boot directory. After booting you can modprobe your card’s module or make it so that’s done automatically. Slackware uses something called XZ to compress files, which was new to me. There are xz-tools in both portage and in debian repositories and if I remember correctly they replace previous lzma tools you might have had on system. Recent version of p7zip may also have support for that format.

It works … ?

Now if you didn’t make any mistakes you should be able to successfully boot PC with that pendrive and dnsmasq. I think I didn’t miss anything vital too, but if you spot something, don’t forget to mention it in form of a comment or something. I may have mentioned that it’s fairly easy to do this, but it turned out to be quite a long post, and you can’t really call something easy when it takes so many words to describe. Well, maybe so, but if you take the essence, it will be only a few copy/paste while some files are downloading, then put it on pendrive and that’s all.

If you think this is cool then there is even more, you don’t even need a pendrive to boot system, there is something called CONFIG_ROOT_NFS. You can get kernel from PXE and use system directly from nfs share on network, and it doesn’t end there, how about booting whole bunch of computers this way ? It has all sorts of benefits, you don’t have to worry about updating software on each of them because everyone uses the same files, and because of that backup is easy too. But that you have to check yourself.

Enjoy!

BTW, I forgot to mention this but AMD K5 needs about 10 W to run, pendrive, usb and network card almost nothing too, so it’s power consumption is about 10 times less than any normal computer (Some AMD Phenoms need 125 W…)

INSTALL & CONFIGURE TFTP SERVER

*tried on opensuse 11.1 &ubuntu 9.04

1. INSTALL THE REQUIRED PACKAGES

–get them from http://packages.ubuntu.com/search?arch=i386&keywords=tftp (may vary if opensuse)

In CLI:

Sudo su -    (changes mode to super user) –user@ server –very important

: ~# apt-get install xinetd tftpd*   (will give the list of packages avaible &supported) root@server

Download required package

2. Configure tFTP SERVER & make it on

: ~cd

: ~cd /

: ~cd /etc

: ~cd xinetd

: ~VI tftp

{Edit as follows:

Service tftp

{

Disable = no

Socket type = dgram

Protocol = udp

Wait = yes

User = root

Server = /usr/sbin/in.tftpd

server_args = -s /var/tftpboot

}

}

Esc+wq   (to write and save changes)

: ~ cd

: ~cd /

: ~cd /etc/init.d/xinetd restart (to restart xinetd daemon & further view changes)

4. Check that your TFTP SERVER INSTALLED IS RUNNING

: ~cd /

: ~netstat –uap (will show a dialog box containing the details of TFTP SERVER both running or not)

5. SETTING CONF IN DHCP SERVER (package dhcp server needed)

: ~cd

: ~cd /

: ~cd /etc

: ~cd dhcp3

: ~vim dhcpd.conf

{Edit as follows:

Option root-path              "192.168.0.112:/opt/ltsp-4.1/i386";
Filename                      "/lts/vmlinuz-2.4.26-ltsp-2";

Next-server                   192.168.0.254;

}
: ~cd /etc/init.d/dhcpd-server restart

6. TFTP AS INTEGRAL PART OF  PXE BOOT SERVER

We configured TFTP above as the trivial file transfer protocol (TFTP) is a UDP-based file transfer program that is frequently used to allow diskless hosts to boot over the network.

PXE-PREBOOT execution environment is a environment by which we can boot multiple computers through the network.

It used 2 servers: TFTP, DHCP, and HTTP (optional)

The process explains the pxe boot process:

- when the client computer try to boot with PXE, it first emits a DHCP request on the network to get an IP address.

-Then a DHCP server reply with a DHCP offer that contains a new IP address that was not already allocated and the IP address of the TFTP server .

• The client receives this DHCP offer and accept it. It connects to the TFTP server (it received its IP address in the previous stage) to get the boot loader files.

• The TFTP server sends the boot loader files .

• The client displays the pxeboot  prompt, and the user can choose the boot options. It then requests the TFTP server the kernel and initramfs files necessary to boot the system .

• The TFTP server sends the kernel and initramfs files to the client .

• The client boots on this kernel .

• During its initialization the kernel makes a DHCP request again because of the ip=dhcp kernel boot parameters.

• The client downloads the system  file except the kernel into RAM from an HTTP server. The IP address of this web server was sent to the client by the tftp server with the kernel boot options.

• The client mounts system file and it can now complete the boot process.

• At this stage the client holds all the files in memory and it does not require any boot server any more

(System file refers here some OS BOOT file )

Just a friendly reminder here: When you upgrade to DS 6.9 SP3, make sure you either choose to update your PXE server through the SP3 install wizard or go back and relaunch C:\DSSetup\setup.exe (C: can be different in your environment) and choose component installation and choose to install a PXE server to upgrade to the latest build.

Failing to update the PXE server after the DS is running SP3 will result in clients booting into automation only to be struck by a \BOOT\BCD error before downloading the WinPE ISO.

Boot menu

So we’ve been using PXE booting on our network for the last couple of years and it has made life much easier.  We use pxelinux and vesamenu.c32 to have a pretty boot menu show up (specific to the system’s ip address).  Any school computers only see “Boot from hard drive” and “Administrative tools” (and choose the first option after five seconds).  An unknown computer (or a new computer) will get the menu on the right.  Administrative tools is password-locked so students/teachers can’t reinstall the operating system.

This system is incredibly efficient when it comes to imaging a new system (I go to “Administrative tools”, type the password, and then choose “Image system” and walk away).

We have run into several problems, though.  The main one was that several of our newer Intel motherboards have odd BIOS bugs that can occasionally be tripped up by PXE booting.  My favorite was the systems that completely froze when you chose “Boot from hard drive”.  We bought twenty of them.  My theory is that pxelinux is overwriting the RAM that contains the BIOS code for booting off of the hard drive.  And then there were the computers that would hang when trying to access “Administrative tools”.  The worst part is that I couldn’t replace the network boot rom with something from etherboot because I couldn’t find any tools that would allow me to modify Intel BIOSes this way.

It finally got to the point where half of our computers had PXE booting turned off by default, which made life fun when I needed to re-image one of those systems.  Enter gPXE.  gPXE is an open source network bootloader, and is the successor to etherboot.

I was playing around with it one day and came across this page.  I realized that I could cunningly have PXE load the gPXE boot rom over the network, and then replace the manufacturer’s PXE code in memory with gPXE code, which seems to be far more robust.

So, now all of our systems can boot off of the network, and then boot from the hard drive without hanging.  All of our systems can access Administrative tools.  And we even get a few bonuses (data gets loaded over http rather than tftp).

Инсталиране на дебиан от мрежа

HP Vectra (Стара щайга)
Intel Pentium III 733Mhz 256MB RAM
OS: Ще бъде Debian (http://cdimage.debian.org/debian-cd/5.0.3/i386/bt-cd/debian-503-i386-netinst.iso.torrent)
IP: 192.168.1.3 – dynamically allocated

DHCP Server: Linksys WRTGL
OS: dd-wrt
IP: 192.168.1.1
Това е internet routera за локалната мрежа. Играе роля на Firewall,DNS и DHCP server-и

ACCER Aspire 5730Z
OS: Windows XP (blia)
WAN IP: 192.168.1.56 – dynamically allocated

Настойка:
HP Vectra
1. Трябва да се настрои BIOS да опита да зареди операционна система от мрежата
BIOS: Boot/ Boot Device Priority/ Integrated Network/ Трябва да се измести на първо място

Linksys
1. Setup/ Basic Setup/ DHCP/ Enable/ Checked
2. Setup/ Basic Setup/ DHCP/ Use DNSMasq for DHCP/ Checked
3. Services/ DNSMasq/ Additional DNSMasq Options/ dhcp-boot=pxelinux.0,sting,192.168.1.57

ACCER Aspire 5730Z
1. Инсталиране на TFTP daemon: Tftpd32 (freeware http://tftpd32.jounin.net/)
2. Създаване на папка. Пример: <някъде>/tftpboot
3. Сваляне на neetboot пакета (ftp://ftp.debian.org/debian/dists/stable/main/installer-i386/current/images/netboot/netboot.tar.gz)
4. Разархивиране в <някъде>/tftpboot
5. <някъде>/tftpboot трябва да съдържа:
папка: debian-installer
папка: pxelinux.cfg
файл: pxelinux.0
файл: version.info
6. Стартиране на Tftpd32
7. Current Directory на Tftpd32 трябва да съдържа папката: <някъде>/tftpboot
8. Settings/ Advanced TFTP Options/ PXE Compatability/ Checked

Тест: от някаква машина със инсталиран tftp клиент се свързвам към Aspire-a и успявам да издърпам pxelinux.0 без проблеми

Рестартиране на HP, преминава в PXE режим и без проблеми получава IP адрес (192.168.1.3) от DHCP на Linksys устройството. TFTP клиентът се опитва да издърпа pxelinux.0 ядрото, но удря на камък.
След две PXE-E11: Arp Timout съобщения. излиза със PXE-E38: TFTP Error – File not found

След няколко часа главоблъсканици с конфигурацията решавам да използвам Ethernet вместо WiFi интерфейса на ACCER-а за връзка към локалната мрежа. Рестарт на вектрата и VOILA !!! Стана. Издърпа ядрото и показа менюто за инсталацията

Поради някаква причина Linksys рутера, най-вероятно филтрира ARP пакетите между WiFi и LAN. Иначе конфигурацията работи.

“O Netboot.me é um serviço que permite que você inicialize, praticamente, qualquer sistema operacional ou utilitário, em qualquer computador com acesso à internet via rede cabeada (LAN), sem precisar saber, de antemão, o que você precisa inicializar. Se você consegue inicializar pelo Netboot.me, você nunca mais precisará atualizar seu disco de boot de novo.”

Esta é a frase inicial do site Netboot.me (http://www.netboot.me/). Mas o que raios quer dizer isso? A idéia simples: utilizando uma facilidade das BIOS de computadores mais recentes, que permite que estes inicializem um sistema operacional pela rede ethernet (o “famoso” BOOTP – opção de boot pela rede presente em quase todos os setups de BIOS atuais, também conhecido como PXE – Preboot eXecuting Environment). A idéia é usar o PXE para inicializar o computador pela internet, utilizando um kernel Linux básico e enxuto, mas em um ambiente gráfico com opções básicas de instalação de algumas distribuições Linux mais populares. A partir desse ambiente, o usuário poderia instalar qualquer distribuição Linux like, eliminando várias etapas no processo de instalação como baixar um arquivo ISO, gravar um CD/DVD, inicializar pelo CD/DVD e, só depois, dar início ao processo de instalação.

Entretanto, para máquinas que não possuem o recurso de boot pela rede ethernet, o Netboot.me possui uma opção de um CD ou pendrive inicializável. A vantagem disso é que você não precisa mais manter sempre um CD com a última versão da sua distribuição Linux predileta. Você precisa apenas ter um CD com o Netboot.me que buscará no repositório oficial, a última versão disponível. Você pode optar por essa modalidade e inicializar de várias maneiras: CD/DVD, pendrive/memory card, disquete e TFTP.

Outra facilidade do Netboot.me é a possibilidade de inicializar o sistema em um ambiente especialmente configurado para uma determinada tarefa. Por exemplo: imagine que você goste de um jogo, mas tem de alterar configurações de ambiente para rodá-lo, ou ainda, o sistema se torna lento ou instável. O Netboot.me permite a inicialização de um sistema preconfigurado para rodar esse jogo. Extrapolando para outros utilitários, imagine que você precise testaar uma determinada máquina ou um hardware novo, mas não dispõe de um software de teste. Inicialize pelo Netboot.me e rode o sistema de testes pela internet. As possibilidades são bastante grandes mas, embora as facilidades ejam boas, os desenvolvedores do Netboot.me ainda estão pesquisando maneiras de tornar essas transações pela internet seguras o suficiente.

Maiores informações, veja no site http://www.netboot.me/

Ha salido hoy la noticia de que desde el sitio principal donde se distribuye el kernel de Linux kernel.org (The Linux Kernel Archives) ha publicado una herramienta para arrancar distribuciones de Linux directamente desde Internet: BKO.

Our objective is to let users boot their machines with bare minimal requirements on their side, and we will handle most of the problem that you may face in booting. All that user needs is Internet connectivity and a small program (gpxe) to boot the machine. This gpxe program provides network booting facility. You can download these program from our site (available at Downloads section). Also, you can find a list of distributions and tools that can be booted with BKO here. Your small 56KB gpxe program can boot any of these options!

Lo que traducido sería algo así como “Nuestro objetivo es permitir a los usuarios arrancar sus máquinas con los mínimos requisitos, y nosotros nos encargaremos de la mayoría de los problemas que usted puede enfrentar en el arranque. Todo lo que el usuario necesita es conexión a Internet y un pequeño programa (gPXE) para arrancar la máquina. Este programa proporciona gPXE facilidad de arranque en red. Usted puede descargar estos programas en nuestro sitio (disponible en la sección “Descargas”). También, usted puede encontrar una lista de distribuciones y herramientas que se puede arrancar con BKO. Su pequeño programa gPXE de 56KB puede iniciar cualquiera de estas opciones!”

Por ahora existe la posibilidad de arrancar Debian Live, Ubuntu, Damn Small Linux, Knoppix y Fedora Live.

A continuación dejo el tutorial que voy a seguir para probar esta nueva utilidad que seguro dará mucho de que hablar.

Configurações de Servidor para boot PXE

O lado servidor do processo de boot PXE deve possuir serviços que redirecionem o cliente ao servidor de boot apropriado. Os serviços podem ser implementados no próprio servidor DHCP, ou em um outro servidor:

• DHCP implementa o redirecionamento
  • o servidor fornece endereço IP ao cliente de boot PXE e também o redireciona a um servidor de boot (que pode até ser o próprio servidor DHCP).
• DHCP e redirecionamento em separado
  • esta configuração é implementada com um servidor do tipo DHCP proxy (que responde apenas às requisições de clientes de boot PXE).

Nos próximos posts, será explorado o primeiro método, onde o próprio servidor DHCP trata as requisições de cliente PXE e as redireciona a um servidor de boot. Este último, por sua vez, estará executando o serviço de boot implementado através do protocolo TFTP (Trivial File Transport Protocol).

<< Voltar >>

Uma ferramenta interessante é a capacidade de iniciar um microcomputador através de uma imagem de boot localizada em um servidor, ou seja, o boot é feito pela rede. Tal mecanismo serve a diversos propósitos, dentre os quais:

• Instalação de um sistema operacional

Se o cliente não tem um S.O. instalado no disco local (HDD), ou nem possui HDD, efetuar o download de uma imagem de inicialização (Network Bootstrap Program – NBP) de um servidor pode ajudar a automatizar a instalação, bem como outros passos de configuração.

• Ambiente de recuperação

Se o cliente não está iniciando (por defeito de hardware/software), efetuar o download de uma imagem de inicialização com ferramentas para diagnóstico, cópia de segurança, ou mesmo solução do problema.

• Iniciar um sistema

Se o cliente não possui armazenamento local, é possível efetuar o download de um sistema operacional pela rede.

O PXE (Preboot Execution Environment) fornece mecanismos que possibilitam atingir esses propósitos. Em resumo, o protocolo PXE funciona assim: a máquina cliente (que deseja executar o boot pela rede) envia um DHCPDISCOVER por broadcast (este pedido contém um identificador, informando que o cliente implementa o protocolo PXE). Se há na rede um servidor DHCP ou Proxy DHCP que aceite requisições desse tipo, após passos intermediários, o servidor envia ao cliente uma lista de Servidores de Boot. O cliente então descobre um servidor de boot do tipo em questão e recebe o nome de um arquivo executável neste servidor. A seguir, o cliente utiliza o protocolo TFTP para efetuar o download deste executável. Por fim, inicia a execução da imagem de inicialização associada.

<< Voltar >>

In our LoCo team (Ubuntu Massachusetts LoCo) we’ve been configuring a lovely tftp/pxe boot installer system that allows refurbished computers to be installed ridiculously easily via PXE booting. I’ve just completed a redesign of how it looks:

As you can see we have the facility to also install Lab machines with configurations that will use the LDAP and have hand picked and custom packages for the lab (this allows easy repair and setting up of lab machines as well).

There are still quirks and such, we can’t yet get it to install ubuntu restricted extras by default, although we have gotten skype, libdvdcss2 and java to install by default, but once sorted out these OEM machine installs will have all the updates, all the common desktop packages, anything extra we want to add including replacement gdm theme or extra docs / manuals and it’s must less hassle than a CD or USB boot media.

Although it was very easy to set up the xubuntu configuration for older machines. You’d also be surprised at just how many machines support PXE but hide it in some way. Some bios settings seem to put it under boot and some under the legacy device settings (the network card will have on, off and on w/PXE settings).

These settings are delivered by kickstart scripts and we have a local mirror supplying all the packages, so installs can be quite quick even with all the updates. I’ll post things if anything wants them, so far I’m trying to put together something that works once and then expand that to other community centers and learn how to deploy these servers more easily.

So it’s my second day back after a two week leave of absence.  I thought I’d ease myself back in with a relatively straight forward job.  The last two ICT suites need re-imaging.  About 30 PC’s in each room.  Yesterday I rebuilt and inventoried the first room with out any issues what so ever.

Today I image 6 machines and bang the imaging server packs up.  No longer responding to TFTP requests.  Restart the server and it’s fine.  For another 6 machines and then bang, same problem.  Restart and this time WDS is not responding!

The problem here is that it was originally a 2003 R1 server running on VMWare.  It never did like the conversion to 2003 R2 running on Microsoft Virtual Server 2005R2.  It’s been working all this time (even though the msc plugin says otherwhys) under sufference.  It seems it was willing to suffer no more.

End result?  A complete rebuild.

Likely I had the foresight to store the images on a seperate drive.  I only have to rebuild the OS install and I should get my images back.

Unfortunately for me the second room has no CD drives so network booting to the image server is the only option.  Oh hum, time to rebuild the server…

This time instead of installing FreeBSD from magnetic or optical media, I’ve installed it over network with the help of the instructions. For this installation, I’ve used my Arch GNU/Linux box to become server (TFTP server, DHCP server, NFS server). I downloaded the DVD of 8.0-BETA2 version, loop mounted it on my box, and exported it to my local network over NFS. Then I prepared the PXE root and started tftpd, dhcpd and nfs-server services. After this I booted my notebook over PXE and it received an IP address, and started executing pxeboot loader, but then it started giving RPC errors. I did a tcpdump (with udp filter) and noticed that it is expecting server to support NFS verison 1 whereas I’ve disabled version 1 and version 2 in mountd options. So I changed options of mountd and restarted nfs-server service and rebooted my notebook. And viola, it now booted with FreeBSD boot screen showing up . After this I got some errors about readonly filesystem which are expected. I logged-in as the root, loaded gjournal and reformatted / and /usr using newfs . Then I mounted them and extracted all tarballs one by one in DESTDIR, created /etc/fstab, basic rc.conf, etc. After this I unmounted the partitions and rebooted my notebook as usual from HDD and there I’m in 8.0-BETA2 installation. Enjoyed the whole experience.

Siguiendo la saga del post anterior en donde presentaba a dnsmasq como la navaja suiza del arranque remoto para clientes sin disco rígido – lo que se conoce como diskless o thin clients – completo el artículo con una breve explicación acerca de como poner en funcionamiento este sistema para que nos sirva como DHCP server, TFTP server y PXE server.

Englobando un poco la idea general, lo que se persigue es:

1. Nunca mas tener que volver a usar un CD o un diskette para arrancar una PC.
2. Arrancar un ordenador usando únicamente la red (Tenga este disco rígido o no)
3. Disponer de una serie de imágenes para arrancar desde la red entre las que incluyo:

• • Algunas distribuciones de linux (Cualquier versión de Ubuntu y System Rescue CD)
  • Imágenes ISO de cualquier CD Booteable
  • Windows desde la red.
  • Imágenes de Diskette booteables.

Todo esto se consigue combinando tres piezas que tienen que interactuar entre si:

• Dnsmasq
• Grub4Dos
• PXElinux

Dnsmasq:

es el encargado de recibir las peticiones PXE iniciales y pasarle al cliente su número de IP inicial, el nombre del archivo binario desde el cual bootear y la dirección del servidor tftp desde el cual obtener dicho archivo.

En el siguiente paso y teniendo Dnsmasq la capacidad de actuar como tftp server, se encarga de servir al cliente con el archivo binario desde el cual bootear, que será grldr, el grub loader de grub4dos.

Grub4dos:

Se encarga de presentarnos un bonito menú de arraque – con imagen de fondo y todo – desde el cual seleccionar que imagen queremos arrancar y llegado el caso pasarle el control de la pila PXE usando chainload pxelinux para que podamos arrancar diferentes distribuciones de linux.

Pxelinux:

Cumple exactamente la misma función que grub4dos, permitiendo bootear en este caso diferentes distribuciones de linux sin usar el livecd.

Instalación y configuración de dnsmasq:

Usando el gestor de paquetes de su distribución instalen dnsmasq en la pc que hará de servidor PXE. En Gentoo:

emerge dnsmasq

El archivo de configuración se ubica en /etc/dnsmasq.conf. Usando el método para filtrar las líneas comentariadas que expliqué en este otro post voy a dejar visible únicamente lo relevante.

Primero, especificar cual será la interface de red por la cual se servirán peticiones modificando la siguiente línea:

interface=eth0

Si quieren que los clientes tengan un nombre de dominio asociado al nombre de host, modificar la línea:

domain=midominio.com

Y descomentariar esta otra:

expand-hosts

Al hacerlo. Durante el arraque por red o al obtener una dirección de IP desde el servidor DHCP, dnsmasq asignará además el nombre de dominio al hostname con lo que la pc que se anunció a si misma como pepito responderá tanto al nombre de host pepito como a pepito.midominio.com.

Especificar el rango de direcciones de IP que queremos servir, la máscara de subred y el lease time:

dhcp-range=192.168.0.10,192.168.0.20,255.255.255.0,12h

Dnsmasq reservará durante doce horas los números de IP que hubiera asignado y usará el rango de 10 a 20.

Habilitar el tftp server descomentariando esta linea:

enable-tftp

Especificar cual será el directorio raíz desde el cual se servirán imágenes por tftp:

tftp-root=/tftproot

Y el cargador de arranque que se le pasará al cliente:

dhcp-boot=grldr

Siendo grldr el cargador de arraque y al no haber especificado ninguna ruta para el archivo, dnsmasq entiende que la ruta al archivo grldr es /tftproot/grldr.

Y eso es todo! Con esas poquitas líneas dnsmasq ya está configurado para hacer todo el trabajo.

Si en tu red ya existiera otro dhcp server en funcionamiento probablemente te interese descomentariar esta opción:

dhcp-authoritative

Eso hará que dnsmasq se haga cargo de todos los leases asignados por otros servidores dhcp de la red cuando entre en funcionamiento.

Por último, crear el directorio raiz del servidor tftp:

sudo mkdir  /tftproot

sudo chmod 755 /tftproot

E iniciar el servicio:

/etc/init.d/dnsmasq start

Grub4dos:

De la página web del proyecto descargar el siguiente archivo:

grub4dos-0.4.4.zip

Dentro del .zip al descomprimirlo encontrarán el archivo grldr. Copiar este archivo a /tftproot:

cp ruta_al_archivo_comprimido/grldr /tftproot

Crear en archivo menu.lst y editarlo son su editor de texto de cabecera:

touch /tftproot/menu.lst

nano /tftproot/menu.lst

Ahora si, ya podemos empezar a agregar opciones dentro del menú de Grub agregando estas entradas al archivo menu.lst. Empezando por las opciones por defecto:

default 0
timeout 30
splashimage=(pd)/splash.xpm.gz

Default 0 indica cual de todas las entradas del menú iniciará al cabo de 30 segundos, – por timeout 30 -. La entrada cero es la primera de la lista.

Splashimage indica cual será la imagen de fondo que tendrá grub al presentar el menú en formato .xpm.gz. Pueden elegir una de las tantas que hay disponibles en internet o crear una propia a su gusto.

Copien su archivo .xpm.gz a /tftproot.

(pd) por Pxe Device es el formato que usa grub4dos para referirse al servidor tftp.

Ejemplos prácticos de arranque de imágenes:

Bootear una imagen de diskette:

title Mi imagen de diskette de DOS booteable
map –mem (pd)/img/img_diskette.bin (fd0)
map –hook
root (fd0)
chainloader +1

Pueden encontrar unas cuantas imágenes de diskettes de DOS de las cuales servirse en Bootdisk.com. Nuevamente, copiar el archivo de imagen de diskette a /tftproot.

Cargar Memtest86, el testeador de memorias por excelencia:

Esta vez necesitaremos de memdisk, que es parte del paquete syslinux. Primero instalar syslinux (que de paso, instalará también pxelinux que usaremos mas adelante) con el gestor de paquetes de su distribución. En Gentoo:

emerge syslinux

Copiar a continuación memdisk desde la ruta en donde lo instaló syslinux a /tftproot:

cp  /usr/share/syslinux/memdisk /tftproot

Descargar la última versión disponible de memtest86 en versión binaria booteable y copiarla a /tftproot.

Generar la entrada en el menú de grub de esta forma:

title Cargar Memtest86
kernel (pd)/memdisk
initrd (pd)/memtest.igz

Bootear cualquier imágen de CD en formato ISO:

El procedimiento es muy similar al usado al arrancar una imagen de diskette. Copien el ISO a /tftproot y luego generen la entrada en el menú de grub.

title Mi CD Booteable
map –mem (pd)/imagen_de_cd.iso (0xFF)
map –hook
root (0xFF)
chainloader (0xFF)

Acotaciones al margen:

• Este método carga la imagen ISO completa en la memoria RAM. Si van a cargar un archivo .iso de 600 MB necesitarán como mínimo esa cantidad de memoria ram instalada en el sistema.
• No sirve para arrancar imágenes ISO de cd instaladores de windows.
• No sirve para arrancar imágenes de Livecd de distribuciones Linux.

¿Entonces para que sirve?

Se puede usar para arrancar una imagen de Hirens BootCD usando el método anterior por ejemplo.

Como en este Hirens BootCD se incluye dentro de la carpeta /HBCD una versión de Windows XP livecd que usa como cargador el acrhivo XPLOADER.BIN. Podemos arrancarla desde la red también copiando el archivo .iso a /tftproot y agregando esta entrada al menú de Grub:

title Hirens MINI XP
map –mem (pd)/iso/hirens_boot_cd.iso (0xFF)
map –hook
root (0xFF)
chainloader (0xFF)/HBCD/XPLOADER.BIN

PXELinux. Arrancar livecd de Linux desde la red:

Esta es la parte en donde cargaremos un par de livecd de linux desde el servidor TFTP.

Para esto dependiendo de la distribución elegida necesitaremos de un servidor NFS funcionando y con la carpeta que contiene los archivos necesarios exportada.

He estado haciendo algunos experimentos y al parecer todos los livecd de Ubuntu necesitan de un servidor NFS instalado. System Rescue CD puede bootear desde el mismo servidor TFTP.

Si nunca han hecho esto, puede que les interese esta guía o googlear un poco.

En mi caso tengo exportado /tftproot con estas opciones en /etc/export:

/tftproot  192.168.0.0/255.255.254.0(async,no_subtree_check,rw)

Una vez que hayan exportado /tftproot con NFS solo resta poner en funcionamiento pxelinux:

Son necesarios 2 archivos que también instaló syslinux en su momento, pxelinux.0 y menu.c32. Los copiamos a nuestro /tftproot:

cp  /usr/share/syslinux/menu.c32 /tftproot

cp  /usr/share/syslinux/pxelinux.0 /tftproot

Creamos el archivo de configuración de PXELinux:

mkdir /tftproot/pxelinux.cfg

touch  /tftproot/pxelinux.cfg/default

Si queremos un menú colorido agregamos además un archivo graphics.conf:

touch /tftproot/pxelinux.cfg/graphics.conf

Y le agregamos dentro:

menu color tabmsg 37;40 #80ffffff #00000000
menu color hotsel 30;47 #40000000 #20ffffff
menu color sel 30;47 #40000000 #20ffffff
menu color scrollbar 30;47 #40000000 #20ffffff
MENU MASTER PASSWD tupassword
MENU WIDTH 80
MENU MARGIN 22
MENU PASSWORDMARGIN 26
MENU ROWS 6
MENU TABMSGROW 15
MENU CMDLINEROW 15
MENU ENDROW 24
MENU PASSWORDROW 12
MENU TIMEOUTROW 13
MENU VSHIFT 6
MENU PASSPROMPT Ingrese Password:
NOESCAPE 0
ALLOWOPTIONS 1

Toda la sección que menciona el password y la opción ALLOWOPTIONS son para permitir la edición al vuelo del menú (pero protegido por una contraseña). Es útil dejarlo habilitado mientras se están haciendo las pruebas iniciales para poder jugar con las opciones antes de arrancar cada imagen de CD.

Se ingresa al modo edición del menú de pxelinux presionando la tecla TAB.

Agregamos primero las opciones por defecto al menú de pxelinux dentro del archivo  /tftproot/pxelinux.cfg/default:

default menu.c32
prompt 0

menu title Menu para arrancar imagenes de Linux
menu INCLUDE pxelinux.cfg/graphics.conf

Arrancar cualquier versión de Ubuntu:

label xubuntu
menu label XUbuntu 9
kernel /xubuntu/vmlinuz
append initrd=/xubuntu/initrd.gz file=/xubuntu/xubuntu.seed boot=casper verbose netboot=nfs nfsroot=192.168.1.1:/tftproot –

Explicación:

He creado dentro de mi /tftproot un directorio de nombre xubuntu y dentro del mismo un segundo directorio de nombre casper.

Dentro del directorio xubuntu he copiado desde el ISO del livecd de Xubuntu los siguientes archivos:

• casper/initrd.gz => /tftproot/xubuntu/
• casper/vmlinuz => /tftproot/xubuntu/
• casper/filesystem.squash fs => /tftproot/xubuntu/casper/
• preseed/xubuntu.seed => /tftproot/xubuntu

Que traducido en comandos sería:

mkdir -p /mnt/tftproot/xubuntu/casper

sudo mount -t  iso9660 -o loop mi_imagen_de_xubuntu.iso /mnt/cdrom

cp /mnt/cdrom/casper/initrd.gz  /tftproot/xubuntu/

cp /mnt/cdrom/casper/vmlinuz /tftproot/xubuntu/

cp /mnt/cdrom/casper/filesystem.squashfs /tftproot/xubuntu/casper

cp /mnt/cdrom/preseed/xubuntu.preseed /tftproot/xubuntu/

Dentro de la línea append la opción nfsroot=/192.168.1.1:/tftproot especifica el número de IP del servidor que está exportando por NFS todo el contenido del directorio.

Arrancando System Rescue CD desde la red:

label srcd
menu label System Rescue CD
kernel /srcd/rescuecd
append initrd=/srcd/initram.igz netboot=tftp://192.168.1.1/srcd/sysrcd.dat

Si se entendió el arranque de Ubuntu este no necesita mayores explicaciones. De nuevo, he montado el ISO y copiado el kernel, initrd y el archivo sysrcd.dat a un directorio de nombre srcd dentro de /tftproot, solo que en este caso, los tres archivos se sirven por tftp y no es necesario el uso de un servidor NFS.

Por último, solo resta generar una entrada en el menú de grub para que este cargue el menú de PXELinux:

title Menu para arranque de Linux usando PXELinux
pxe keep
chainloader –raw (pd)/pxelinux.0

Y eso es todo!. Pueden usar este método para arrancar sus imágenes de diskette, CD o DVD preferidas por la red, Jugando un poco con el livecd de la distribución que mas les guste pueden hacerla arrancar por la red también.

Si bien he simplificado bastante el proceso explicando como implementar todo en una sola PC de la red, no es necesario que esto sea así. Por ejemplo, en mi red dnsmasq corre sobre la pc que hace de router. El servidor TFTP corre sobre un fileserver y el servidor NFS sobre un segundo fileserver.

Es cuestión de ajustar las rutas para adecuarlas a sus necesidades concretas y listo.

Todas las pc y portátiles medianamente modernas permiten el arraque desde la red pero no todas traen la opción habilitada por defecto en su BIOS. Cada quien sabrá como habilitar dicha opción, que suele llamarse Network Boot o LAN Boot Rom.

Cualquier sugerencia, mejora o comentario al respecto es bienvenida.

Enjoy!

Relatively few people showed up at today’s Ghoss meeting, probably mainly due to the fact that Obama is in town, so many of the roads are blocked. That was okay with me, because I’ve got a bit of malaria so I wasn’t really in the mood for anything too advanced.

Most of the guys who did show up happened to belong to my project group. We are working on setting up apache servers with virtual hosts. Today I wanted the team to practice the whole set-up, from installing Linux to downloading and installing apache to finally configuring the virtual hosts. We had earlier been given a PC to practice on, so I thought it would be a good idea to use it.

That is when the challenges started. It turned out that the CD-Rom drive on the box doesn’t work and the machine doesn’t support USB boot. It does, however, support PXE boot, so I got the guys to starting looking into network installations. After a while they had managed to get a few resources from the net and were following some HOWTO that they found.

It turned into a good exercise in teamwork. The fact that I wasn’t very helpful today also forced the guys to try to figure things out for themselves, which they did. There was a lot of activity coming out of the team today. In the end they ran out of time, but we will continue at the next meeting.

Hola a todos, vuelvo a escribir en el blog porque he empezado un Curso de Administración de Sistemas Linux y puede ser interesante escribir sobre este y otros  temas que vaya aprendiendo.

El primer ejercicio que nos han planteado ha sido como instalar el sistema operativo Debian en un equipo a través de la red, he creado un pequeño manual (How-to) de como poder hacerlo.

REQUISITOS


Para poder realizar esta tarea necesitamos instalar en nuestro servidor:

• Servicio de DHCP, el cual proporcionará una dirección de red IP de manera automática al equipo cliente para conectarse al servidor y establecer la comunicación entre ambos.

• Servicio de TFTP, que será el que le envié la imagen del sistema operativo al equipo cliente para poder realizar la instalación.

Y en el equipo cliente:

• Tarjeta de red con PXE, necesitamos que el equipo cliente tenga la BIOS configurada para que arranque desde la tarjeta de red con PXE.

SERVICIO DHCP

Primero debemos de instalar el paquete correspondiente a DHCP, en esta caso vamos a utilizar el paquete dnsmasq.

Necesitamos que los comandos que vamos a utilizar tengan permisos de administrador, para ello en una terminal (shell) ejecutamos:

Obtendremos los permisos de root e instalaremos el paquete dnsmasq, escribimos:

***********************************************

Si nos da el error No se pudo encontrar el paquete dnsmasq tendremos que añadir los repositorios correspondientes para poder bajarnos los paquetes que necesitamos. Para ello editamos el archivo /etc/apt/sources.list con un editor de texto:

Añadimos la siguiente línea para indicarle que también busque los paquetes en este repositorio:

deb http://http.us.debian.org/debian/ Lenny main non-free

Guardamos el archivo y actualizamos los repositorios:

Ya tenemos actualizados los repositorios y podremos instalar con el comando apt-get install dnsmasq sin problemas.

***********************************************

Abrimos el archivo /etc/dnsmasq.conf:

Quitamos los comentarios (borramos el símbolo #) a las siguientes líneas:

dhcp-range=192.168.2.150,192.168.1.200,12h
dhcp-boot=pxelinux.0
enable-tftp
tftp-root=/var/ftpd

En dhcp-range pondremos el rango en el que vamos a otorgar direcciones IP, en mi caso tengo el servidor en la red 192.168.2.0 y lo configuro de manera que conceda direcciones desde la 192.168.2.150 hasta la 192.168.2.200

Guardamos el archivo y por ultimo reiniciamos el servicio:

SERVICIO TFTP

Instalamos nuestro correspondiente paquete de TFTP tftpd-hpa:

Editamos el archivo de configuración /etc/default/tftpd-hpa:

Y lo modificamos para que nos quede de la siguiente manera:

RUN_DAEMON=”yes”
OPTIONS=”-l -s /var/ftpd”

Guardamos el archivo de configuración e iniciamos el servicio:

ARRANQUE POR PXE

Nos descargamos la imagen del sistema de la url:

http://ftp.es.debian.org/debian/dists/lenny/main/installer-i386/current/images/netboot/netboot.tar.gz

Descomprimimos el archivo en el directorio del tftp /var/ftpd y arrancamos el equipo cliente configurado para que arranque desde la tarjeta de red por PXE.

La tarjeta de red del equipo cliente busca un servidor de direcciones IP (Servidor DHCP), nuestro servidor le concede una dirección entre la 192.168.2.150 y la 192.168.2.200, el servicio TFTP le indica el directorio donde puede cargar la imagen del sistema y se la envía por red.

Manual en PDF || How-to:  Servidor PXE

Fuente || Obsoletos.org

O de como reemplazar 4 aplicaciones por una sola:

Prefacio:

Le tengo que dedicar al menos una mención de honor a Dnsmasq, este pequeño DNS Forwarder que con tan solo 269Kb (de código fuente en un .tar.gz) me ha cambiado la vida.

Como bien dicen en su página web oficial, “Dnsmasq is a lightweight, caching DNS proxy with integrated DHCP server“. Osea, un pequeñísimo proxy para cachear peticiones DNS que no resuelve por su cuenta -como lo haría BIND, por ejemplo- si no que se interpone entre la red y el verdadero DNS server almacenando los requests en memoria para servirlos rápidamente y ahorrar minúsculas cantidades de ancho de banda por petición.

Ya con eso solo me bastaría y sobraría si no fuera por que además hace de DHCP server!

Con un archivo de configuración tan bien comentado que ni hace falta leer el manual, además de proxy DNS, puede servir de DHCP server compitíendole a los mejores de su rubro sin ningún esfuerzo en lo que a configurabilidad se refiere, y la cosa no acaba ahi…

Además puede servir de PXE server! De nuevo, sin ningún esfuerzo mas que descomentar dos o tres líneas, puede servir peticiones PXE a la red para hacer arrancar thin clients de cualquier tipo…

No contento con todo esto, su desarrolador además le ha incorporado TFTP Server! No solo puede servir a clientes PXE con su configuración inicial, además puede servir por TFTP la imagen de arranque necesaria!

Todo esto lo he ido descubriendo de a poco, leyendo el archivo de ocnfiguración y haciendo algunas pruebas.

Para mis necesidades, ha reemplazado 4 aplicaciones diferentes que usaba antes con una sola que es tan (o mas) configurable que las anteriores y mucho mas estable en algunos casos… (Por ejemplo, no he vuelto a tener problemas desde que sirvo imagenes por TFTP usando Dnsmasq, cosa que si me pasaba al servirlas con tftp-hpa, un port del TFTP server de OpenBSD para linux)

Resumiendo, Dnsmasq te cambia la vida. En una sola aplicación:

• DNS Proxy con caché (y control de TXT records si fuera necesario)
• DHCP Server altamente configurable
• PXE Server para diskless clients
• TFTP Server de alta estabilidad y muy buena velocidad de operación.

Una joyita realmente. ¿Que mas se puede pedir de la vida?

Imaginemos que somos los administradores de 100 equipos y nos piden que les pasemos un antivirus (o cinco) o que eliminemos la contraseña de Windows o que los clonemos… Cualquiera de las cosas que puede hacer Trinity Rescue Kit (TRK). Y entonces la pregunta que nos surge es ¿tenemos que hacer 100 copias del Trinity Rescue Kit? La respuesta es bien simple: NO. Para eso el TRK viene con un servidor de arranque que nos va a permitir arrancar un equipo con el TRK y el resto (99 o los que sean) arrancarán desde él a través de la red.

¿Quieres saber cómo podemos hacerlo? Lo vamos a ver paso a paso.
Los pasos a seguir para arrancar un equipo con TRK y que los demás equipos arranquen desde él a través de la red son los siguientes:

1. Arrancamos un equipo con el Trinity Rescue Kit (ya sea con un CD o con una memoria USB).
2. En el menú de arranque del TRK seleccionamos la opción 1 : TRK 3.3 as bootserver to boot other TRK clients (está seleccionada en rojo en la imagen).
   

   Menú de arranque del TRK

   • Si en nuestra red hay un servidor DHCP funcionando, nos habrá asignado una dirección IP y todo habrá ido bien. Por lo que seguiríamos en el paso 3.
   • Si en nuestra red no hay un servidor DHCP funcionando, no tedremos una dirección IP asignada (en la imagen se lee el FAILED claramente) y no estará funcionando el bootserver.
     

     No tenemos asignada una dirección IP

     • Para establecer una dirección IP ejecutamos el siguiente comando:

       setip eth0

       

       Asignamos una dirección IP

     • Para iniciar el servidor de arranque ejecutamos el siguiente comando:

       trkbootserver

       

       Iniciamos el servidor de arranque

     De esta forma ya estamos en la misma situación que si todo hubiese ido correctamente y podemos continuar con el siguiente paso.

3. Arrancamos el resto de equipos seleccionando el arranque desde la red (LAN). Para seleccionar este tipo de arranque se puede hacer desde la BIOS o bien desde un menú que aparece al pulsar F12 durante el arranque o incluso viene activado por defecto en muchos casos.
   

   Elegimos arrancar desde la red de área local (LAN)

4. Si todo va bien, veremos algo parecido a la siguiente imagen.
   

   Arranque correcto desde la red

5. Por último, aparecerá el menú de arranque del Trinity Rescue Kit y seleccionaremos el modo de arranque que necesitemos en cada equipo.
   

   Menú de arranque del TRK

   Una de las más interesantes es la opción 6 en las que arranca el Trinity Rescue Kit y se pone a escanear todas las unidades de disco con todos los antivirus de forma completamente automática.

A seguir disfrutando de esta herramienta.

Artículos relacionados:

• Trinity Rescue Kit (I): arranque y antivirus
• Trinity Rescue Kit (II): quitar contraseña de Windows
• Trinity Rescue Kit (III): instalación en una memoria USB
• Trinity Rescue Kit (V): conar equipos

Linux Jornal is giving FREE digital copy of Linux Journal’s System Administration Special Edition (PDF Download). Go get it!
It has a LOT of interesting stuff.

• Billix
• Zenoss
• Hearthbeat
• Thin Clients
• PXE Booting
• VPNS With IPsec and SSL/TLS
• MySQL 5 Stored Procedures
• And much more!