Неожиданно пров что-то накуралесил у себя с DHCP.
Винда починилась при помощи магии, а именно запуском в безопасном режиме с поддержкой сети. После перезагрузки всё встало на свои места.
С Archlinux проблема решалась перезапуском сетевого демона и последующим ручным поднятием впн для доступа в интернет, но в век автоматизации такой метод дозагрузки не подходит. Решил методом добавление в /etc/rc.local перед строкой запуска VPN запуск dhcpcd.
Как результат вроде как нормальная загрузка сети.
Побочный эффект: увеличение времени загрузки системы т.к. на этапе загрузки network долго висит в состоянии busy, а после ещё dhcpcd получает адреса.
В общем, продолжаем копать…

1. How many packets are involved in the DHCP Lease process?
2. How many of these packet transmission are broadcast transmissions?
3. What are the intervals for renewal when a timed lease is implemented?
4. What is the purpose of DHCP relay?
5. Why is DHCP authorization needed in a domain environment? What rights should a userID have in order to run and authorize and DHCP server?
6. What are the configurable elements of DHCP?
7. Define the following terms in relation to DHCP?
   1. Vendor Class
   2. User Class
8. How does a reservation differ from an exclusion?
9. How is a superscope used?
10. How is a mulicast scope is used?

The first part of today’s lab is to review the assignment from yesterday’s lab assignment. The team leader should take the following steps to prepare their group for the lab.

1. Ensure that all computers are connected to a switch.
2. Make sure group members have their IP addresses configured to use static IPs (you’ll be given a network prior to beginning the lab)
3. Ensure that DHCP is not installed on any machine.
4. Ensure that DHCP Server service is not running on any machine

Once these steps have been taken each group member will configure DHCP and, if necessary, troubleshoot DHCP so that every machine in the group is assigned an IP address from the server acting as the DHCP server. Inidividual group members will be responsible for implementing DHCP ON THEIR OWN in a pre-determined amount of time. This process should be repeated for every member of the team. Have me confirm that DHCP has been properly configured prior to moving on to the next team member.

Wstęp

W wiekszości przypadków ludzie nie mający za wiele wspólnego z systemem Linuks interesują się nim w kontekście prostego serwera dostępowego do sieci Internet.
Nie potrzeba mieć jakiejś szczególnej wiedzy, aby zainstalować dzisiaj Linuksa. W sieci jest pełno dystrybucji przyjaznych dla użytkownika, posiadających konfiguratory i/lub automatycznie konfigurujących siec – to pięknie, ale czasem warto wiedzieć jak coś skonfigurować “z palca”.
Poniżej przedstawiam sposób, w jaki ja, na szybko, ustawiłbym serwer dostępowy.
Podany poniżej przepis działał będzie na pewno na debianie/ubuntu, powinien też działać na klonach RedHat (Centos,Whitebox,Fedora) oraz na większości innych dystrybucji.

Do dzieła

Po zainstalowaniu czystego systemu operacyjnego (najlepiej bez serwera X i innych zbędnych narzędzi) zalecam zaktualizowanie systemu do najnowszej wersji w ramach danego wydania, zainstalować swój ulubiony edytor tekstowy i przygotować się na trochę pisania na klawiaturze .

konfiguracja interfejsów

Aby nasz komputer mógł pracować jako serwer dostępowy do sieci Internet musi posiadać przynajmniej dwa interfejsy sieciowe. Dla celów opisowych przyjmiemy iż:

• eth0 – interfejs od strony sieci lokalnej, na której będzie nasłuchiwał serwer DHCP
• eth1 – interfejs od strony sieci Internet, skonfigurowany automatycznie przez DHCP

Interfejs eth1 jest konfigurowany automatycznie przez DHCP dostawcy Internetu (jak to ma miejsce w większości przypadków u lokalnych dostawców Internetu), ale nie niczemu nie przeszkadza, jeśli statycznie skonfigurujemy ten interfejs.
Konfiguracja interfejsów sieciowych w systemie ubuntu/debian znajduje się w pliku /etc/network/interfaces.
W tej chwili mój plik wygląda następująco:

auto lo
iface lo inet loopback

auto eth1
iface eth1 dhcp

auto eth0
iface eth0 inet static
address 1.1.1.1
netmask 255.255.255.0
network 1.1.1.0
broadcast 1.1.1.255

Interfejs eth1 jest konfigurowany automatycznie, ale można jego deklaracje skasować i ustawić podobnie do tej, z eth0 wypełniając odpowiednio parametry. Należy pamiętać, iż przy ustawianiu statycznym interfejsu od strony Internetu trzeba jeszcze wskazać w pliku /etc/resolv.conf.
Przykład pliku:

search domena.pl
nameserver x.x.x.x
nameserver x.x.x.x

Opcja search powoduje, że w momencie gdy będziemy chcieli odszukać w sieci komputer i nie będzie on możliwy do odnalezienia przy nazwie, która podaliśmy, to do tej nazwy doda domenę i tak zestawioną nazwę hosta postara się odnaleźć.

Parametr nameserver wskazuje adresy IP serwerów nazw dla naszego komputera. Warto je zapamiętać, bo potrzebne będą przy konfiguracji serwera DHCP (o ile nie posiadamy własnego serwera DNS).

Po zmianie w pliku interfaces wydajemy polecenie /etc/init.d/networking restart i aby wszystko sprawdzić, czy się zgadza ifconfig

Konfiguracja DHCP

DHCP służy do automatycznego konfigurowania komputerów w sieci. Przedstawiony tutaj przykład jest bardzo prosty, z samym serwerem DHCP można zrobić dużo, ale to nie jest temat na ten artykuł.
Instalujemy paczkę dhcp3-server za pomocą polecenia apt-get install, a następnie edytujemy dwa pliki.
/etc/default/dhcp3-server
W parametrze INTERFACES wpisujemy “eth0″, lub inny interfejs, na którym serwer DHCP na nasłuchiwać.

/etc/dhcp3/dhcpd.conf
Ustawiamy:

• option domain-name “twoja_domena”;
• option domain-name-servers x.x.x.x,y.y.y.y; – adresy ip serwerów DNS oddzielonych przecinkami

Usuwamy komentarz (znak ‘#’) z sekcji subnet i ustawiamy następująco:

subnet 1.1.1.0 netmask 255.255.255.0 {
range 1.1.1.2 1.1.1.200;
option routers 1.1.1.1;
}

Oczywiście możecie ustawić to w swoich plikach tak, aby odpowiadało waszym zakresom IP.
Parametr “range” wskazuje ile adresów IP będzie przydzielanych przez serwer DHCP, routers przekazuje komputerom klienckim adres IP routera.
Po wszystkich tych czynnościach przeładowujemy serwer DHCP /etc/init.d/dhcp3-server restart.
Jeśli będą wyświetlały się jakieś błędy zobaczcie do pliku konfiguracyjnego czy nie zapomnieliście gdzieś dać średnika ‘;’ lub czy wszystkie nawiasy są zamknięte. Konkretne miejsce znajdziecie w syslogu.

Konfiguracja NAT

NAT w Linuksie konfiguruje się za pomocą iptables.
Ja to robię w następujący sposób:
Tworzę plik o dowolnej nazwie w /etc/init.d i w nim podaję regułki firewall:

echo '1' > /proc/sys/net/ipv4/ip_forward
iptables -t nat -F
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


pierwsza linia pozwala na przekazywanie pakietów między interfejsami, druga czyści łańcuch “nat”, trzecia ustawia maskowanie pakietów – tutaj podajemy nazwę interfejsu od strony Internetu.

Tak przygotowany plik ustawiamy jako wykonywujący (chmod +x nazwa_pliku) oraz linkujemy go do rcx.d (ln -s /etc/init.d/nazwa_pliku /etc/rc2.d/S99nazwapliku). Owe rcx.d jest odpowiedzialne za uruchamianie odpowiednich usług w zależności od trybu działania systemu (wykracza to poza zakres tego artykułu). Jeśli nie jesteście pewni to zlinkujcie ten plik do rc2.d, rc3.d i rc5.d.

Po restarcie systemu sprawdźcie, czy wszystko działa.

He leído en LinuxCáceres, un post, Linux Terminal Server Project o LTSP, que  pongo a continuación, y lo pongo porque llevo tiempo queriendo hacer esto. A ver si ahora en Navidades voy “pal pueblo y con los cacharros viejo me sale algo.

Linux Terminal Server Project o LTSP son un conjunto de aplicaciones servidores que proporcionan la capacidad de ejecutar Linux en computadoras de pocas prestaciones de velocidad o computadoras de bajo costo, permitiendo reutilizar equipos que actualmente resultan obsoletos debido a los altos requerimientos que piden los sistemas operativos. LTSP se distribuye bajo licencia GNU GPL de software libre (Texto sacado de la wikipedia).

Manos a la obra, tengo un ordenador PIII-450 con 128Mb de RAM, un poco desfasado … la verdad. Con este sistema se le puede sacar provecho aún. Aprovechando que tengo un ordenador más potente he montado un servidor de terminales y el PIII tirará de él. Voy a describir los pasos que he seguido para su instalación.

Lo primero de todo … los paquetes que debemos instalar sobre el servidor (todo se hará sobre el servidor, en el cliente no hay que hacer nada … bueno si no tiene arranque por red en bios, sí, pero al final lo describo):

• Paquete ltsp-server
• Un servidor tftp
• Un servidor dhcp
• Un servidor nfs o nbd para exportar la imagen a los clientes

Continua leyendo la entrada completa en: Linux.-Servidor de terminales con LTSP>>LinuxCáceres

Podéis ver la instalación de Chrome enlace: Probando Chrome OS

There was a minor quirk in the original script, as lease dates where being mixed with hostnames in the final output html. As it turns out it was all a matter of what date it was, when I created the script

Line 21 in the original:

$l = $l -replace '[-]{1}\d{2}[/]\d{2}[/]\d{4}',''

matches dates in the following format: -xx/yy/zzzz but not -x/yy/zzzz or for that matter -xx/y/zzzz.

The correct –replace should have been:

$l = $l -replace '[-]{1}\d{1,2}[/]\d{1,2}[/]\d{4}',''

Thanks you for the comments, which was the final spark to get me to fix it in my production environment

After installing the new Ubuntu 9.10 over the weekend, I set about again trying to establish my new DNS server running on the platform. I have found what seems to be a great tutorial for DDNS (i.e. DNS which is updated with DHCP leases) here.

I’m still working through the bugs, but things at least seem to be getting DHCP addresses, so that’s a good start.

A couple of gotchas early one – Ubuntu runs a thing called AppArmor which seems to cause a lot of problems with applications like DHCP wanting to update BIND and all that. The comments on this post at DebianAdmin.com outline the changes that are needed to be made, specifically you have to make one last minor change to /etc/apparmor.d/usr.sbin.dhcpd3:


/etc/bind/ rw,
/etc/bind/** rw,


Title: How to Install and Configure DHCP Server in Ubuntu Server

http://www.ubuntugeek.com/how-to-install-and-configure-dhcp-server-in-ubuntu-server.html

You use netsh dhcp server command to move DHCP database from one server to another server – for example moving DHCP database from Windows Server 2003 to Windows Server 2008.

Please note that you must install DHCP server service on a target server before moving the database.

On a source DHCP server (Windows Server 2003):

1. Open a command prompt
2. Type netsh dhcp server export drive:\dhcp.txt all
3. Copy the file to a network share folder a thumb drive.

On a target DHCP server (Windows Server 2008):

1. Open a command prompt
2. Type netsh dhcp server import drive:\dhcp.txt all
3. Activate the scope if necessary.

That’s it!

Book

• Mastering Windows Server 2003 by Mark Minasi
• Windows Server 2008 Administrator’s Pocket Consultant by William Stanek

*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.

Setelah Pada artikel Sebelumnya saya membahas tentang “Tutorial Membangun administrasi Jaringan kampus dengan Linux Slackware” pada kesempatan kali ini,saya akan membahas Tutorial Membangun administrasi Jaringan Kampus dengan Linux Fedora..

Di era globalisasi ini kemajuan dalam bidang pendidikan sudah semakin maju terutama dalam bidang teknologi informasi yang sekarang ini sudah semakin canggih dan tentunya sedang dibutuhkan oleh perusahaan untuk menjadi pesaing dengan perusahaan lain.Kemajuan teknologi informasi di era globalisasi ini sangat mendukung semua bidang,hanya saja kita sering mengabaikan akan bermanfaatnya ilmu teknologi saat ini.

Kemajuan teknologi informasi sebenarnya dapat memudahkan dalam berkomunikasi, mencari informasi, bahkan kita pun bisa memperoleh uang dengan keahlian yang kita miliki dengan memanfaatkan teknologi yang ada.Untuk membangun server agar bisa mengatur arus dalam jaringan maka dibutuhkan adanya keahlian dalam memanajemen agar client dapat menjalankan komputernya dengan baik dan benar. Namun dalam membangun sebuah server banyak hal yang perlu kita perhatikan terutama bahan-bahan seperti software dan bahan-bahan lainnya. Adapun beberapa kebutuhan lainnya yang akan kita bahas dalam materi ini.

BERIKUT INI DAFTAR ISI DARI TUTORIAL MEMBANGUN DNS,DHCP,FTP,Web Server,Mail Server dan Proxy Server dengan Linux Fedora:

BAB II   LANDASAN TEORI

2.1     Pengertian Jaringan.

2.2     Sistem Operasi Linux.

2.3     DNS (Domain Name Server)

2.4     DHCP (Dynamic Host Configuration Protocol)

2.5     FTP (File Transfer Protokol)

2.6     Web Server

2.5     Mail Server

2.6     Proxy Server

2.7     Samba Server.

BAB III PROSES PRODUKSI

3.1     Waktu dan Tempat Pelaksaan.

3.2     Alat dan Bahan.

3.3     Gambar Kerja.

3.4     Proses Pengerjaan.

3.4.1      Installasi Mail Server.

3.4.2      Installasi Web Server.

3.4.3      Installasi Proxy Server.

3.4.4      Installasi DNS Server.

3.4.5      Installasi FTP Server dan SAMBA Server.

3.5.6      Installasi DHCP Server.

Bagi Yang Menginginkan download Tutorial Lengkap,, dapat

me-request Lewat COment Di bawah

Bagi Yang Telah me-request,, URL FiLe nya akan sy Kirimkan ke Mail

Anda…

Symptoms
Messages are not transferred. Following warning is reported into Event Log:

Report for message xxx of xxx from xxxx.

Delivery report:
Status: Not completed
xxx@xxx:
Not delivered. No such host is known.

Cause
Narawen Inox POP3 Connector used reverse DNS lookup to retrieve mail host name. In some network configurations this query fails with error message ‘No such host is known’.

Solution
Upgrade to the latest release of Narawen Inox POP3 Connector.

Applies to
Narawen Inox POP3 Connector 5.2 SR1 (2008-02-05)
Narawen Inox POP3 Connector 5.2 (2007-11-14)
Narawen Inox POP3 Connector 5.1 SR1 (2006-09-25)
Narawen Inox POP3 Connector 5.1 (2006-06-14)
Narawen Inox POP3 Connector 5.0 (2005-11-10)

DHCP

DHCP (Dynamic Host Configuration Protocol) adalah protokol yang berbasis arsitektur client/server yang dipakai untuk memudahkan pengalokasian alamat IP dalam satu jaringan dan menyewakan alamat  IP tersebut  ke client pada periode waktu tertentu  . Sebuah jaringan lokal yang tidak menggunakan DHCP harus memberikan alamat IP kepada semua komputer secara manual. Jika DHCP dipasang di jaringan lokal, maka semua komputer yang tersambung di jaringan akan mendapatkan alamat IP secara otomatis dari server DHCP. Selain alamat IP, banyak parameter jaringan yang dapat diberikan oleh DHCP, seperti default gateway dan DNS server.

Cara Kerja

Karena DHCP merupakan sebuah protokol yang menggunakan arsitektur client/server, maka dalam DHCP terdapat dua pihak yang terlibat, yakni DHCP Server dan DHCP Client.

• DHCP server merupakan sebuah mesin yang menjalankan layanan yang dapat “menyewakan” alamat IP dan informasi TCP/IP lainnya kepada semua klien yang memintanya. Beberapa sistem operasi jaringan seperti Windows NT Server, Windows 2000 Server, Windows Server 2003, atau GNU/Linux memiliki layanan seperti ini.
• DHCP client merupakan mesin klien yang menjalankan perangkat lunak klien DHCP yang memungkinkan mereka untuk dapat berkomunikasi dengan DHCP Server. Sebagian besar sistem operasi klien jaringan (Windows NT Workstation, Windows 2000 Professional, Windows XP, Windows Vista, atau GNU/Linux) memiliki perangkat lunak seperti ini.

DHCP server umumnya memiliki sekumpulan alamat yang diizinkan untuk didistribusikan kepada klien, yang disebut sebagai DHCP Pool. Setiap klien kemudian akan menyewa alamat IP dari DHCP Pool ini untuk waktu yang ditentukan oleh DHCP, biasanya hingga beberapa hari. Manakala waktu penyewaan alamat IP tersebut habis masanya, klien akan meminta kepada server untuk memberikan alamat IP yang baru atau memperpanjangnya.

DHCP Client akan mencoba untuk mendapatkan “penyewaan” alamat IP dari sebuah DHCP server dalam proses empat langkah berikut:

1. DHCPDISCOVER: DHCP client akan menyebarkan request secara broadcast untuk mencari DHCP Server yang aktif.
2. DHCPOFFER: Setelah DHCP Server mendengar broadcast dari DHCP Client, DHCP server kemudian menawarkan sebuah alamat kepada DHCP client.
3. DHCPREQUEST: Client meminta DCHP server untuk menyewakan alamat IP dari salah satu alamat yang tersedia dalam DHCP Pool pada DHCP Server yang bersangkutan.
4. DHCPACK: DHCP server akan merespons permintaan dari klien dengan mengirimkan paket acknowledgment. Kemudian, DHCP Server akan menetapkan sebuah alamat (dan konfigurasi TCP/IP lainnya) kepada klien, dan memperbarui basis data database miliknya. Klien selanjutnya akan memulai proses binding dengan tumpukan protokol TCP/IP dan karena telah memiliki alamat IP, klien pun dapat memulai komunikasi jaringan.

Empat tahap di atas hanya berlaku bagi klien yang belum memiliki alamat. Untuk klien yang sebelumnya pernah meminta alamat kepada DHCP server yang sama, hanya tahap 3 dan tahap 4 yang dilakukan, yakni tahap pembaruan alamat (address renewal), yang jelas lebih cepat prosesnya.

Berbeda dengan sistem DNS yang terdistribusi, DHCP bersifat stand-alone, sehingga jika dalam sebuah jaringan terdapat beberapa DHCP server, basis data alamat IP dalam sebuah DHCP Server tidak akan direplikasi ke DHCP server lainnya. Hal ini dapat menjadi masalah jika konfigurasi antara dua DHCP server tersebut berbenturan, karena protokol IP tidak mengizinkan dua host memiliki alamat yang sama.

Selain dapat menyediakan alamat dinamis kepada klien, DHCP Server juga dapat menetapkan sebuah alamat statik kepada klien, sehingga alamat klien akan tetap dari waktu ke waktu.

Catatan: DHCP server harus memiliki alamat IP yang statis.

DHCP Scope

DHCP Scope adalah alamat-alamat IP yang dapat disewakan kepada DHCP client. Ini juga dapat dikonfigurasikan oleh seorang administrator dengan menggunakan peralatan konfigurasi DHCP server. Biasanya, sebuah alamat IP disewakan dalam jangka waktu tertentu, yang disebut sebagai DHCP Lease, yang umumnya bernilai tiga hari. Informasi mengenai DHCP Scope dan alamat IP yang telah disewakan kemudian disimpan di dalam basis data DHCP dalam DHCP server. Nilai alamat-alamat IP yang dapat disewakan harus diambil dari DHCP Pool yang tersedia yang dialokasikan dalam jaringan. Kesalahan yang sering terjadi dalam konfigurasi DHCP Server adalah kesalahan dalam konfigurasi DHCP Scope.

DHCP Lease

DHCP Lease adalah batas waktu penyewaan alamat IP yang diberikan kepada DHCP client oleh DHCP Server. Umumnya, hal ini dapat dikonfigurasikan sedemikian rupa oleh seorang administrator dengan menggunakan beberapa peralatan konfigurasi (dalam Windows NT Server dapat menggunakan DHCP Manager atau dalam Windows 2000 ke atas dapat menggunakan Microsoft Management Console [MMC]). DHCP Lease juga sering disebut sebagai Reservation.

DHCP Options

DHCP Options adalah tambahan pengaturan alamat IP yang diberikan oleh DHCP ke DHCP client. Ketika sebuah klien meminta alamat IP kepada server, server akan memberikan paling tidak sebuah alamat IP dan alamat subnet jaringan. DHCP server juga dapat dikonfigurasikan sedemikian rupa agar memberikan tambahan informasi kepada klien, yang tentunya dapat dilakukan oleh seorang administrator. DHCP Options ini dapat diaplikasikan kepada semua klien, DHCP Scope tertentu, atau kepada sebuah host tertentu dalam jaringan.

Dalam jaringan berbasis Windows NT, terdapat beberapa DHCP Option yang sering digunakan, yang dapat disusun dalam tabel berikut.

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 )

The Dynamic Host Configuration Protocol (DHCP) is at the core of almost every enterprise network forming a mission-critical service that is the cornerstone of reliable and simplifies workstation management. Yet, this service is usually configured as a single point of failure with little thought to high availability or disaster recovery. While longer lease durations are often used to provide some cushion in the event of unavailability, this should not be used as the only protection against system failure. Even in modestly-sized environment, the volume of lease requests and the risk associated with the failure of DHCP beg for a better solution.

Technology Overview

What IS DHCP?

When TCP/IP-based networks were first being developed and used, all network configuration was done manually. IP addresses, subnets and the like were all configured on the individual hosts and had to be manually tracked and documented. This worked for small businesses and controlled environments where constant attention by a single network administrator could be provided or where very tight controls on documentation could be achieved. As these networks grew and larger enterprises adopted the technology, the management burden grew to the point of being unmanageable – a centralized, enterprise solution is needed.

The Dynamic Host Configuration Protocol is the answer to this problem. DHCP provides a service to hosts on an enterprise network that allows the hosts to request and receive IP Addresses, subnet information, and other important configuration information. This also acts as a single enterprise database for this information where a network administrator can access all configuration assignments from one place.

The Role of DHCP in the Enterprise

In a large network, this database and the configuration tools surrounding the service act as a single point of management for all of these data. This means that wide-sweeping configuration changes can be controlled and effected from a single location further reducing the management burden on the network administration staff. Imagine trying to make a simple subnet change on 10,000 workstations by hand!

As an environment grows, the load on the DHCP servers will linearly increase and the addition of branch office sites can create the need for additional DHCP servers to manage these sites. While this handles the load, it introduces additional single points of failure to the enterprise.

Finding DHCP Servers and Scopes

When a workstation needs to find a DHCP server, it will send broadcast packets onto the network advertizing its need for a DHCP server. Any DHCP servers that hear this message will respond advertizing their ability to provide configuration information. The first acknowledgement that the Host receives will be the server that the workstation will use for DCHP in this transaction – all following responses from other DHCP servers are ignored. This is important, as we’ll be exploiting this behavior to provide highly-available DHCP service to the workstations.

For more information on the inner workings of the DHCP Protocol see:

• RFC 2131
• Configuring DHCP (Microsoft KB 300429)
• How DHCP Communication Works

IP Helper-Address

There are some limitations though. Since workstations that are requesting configuration information do not yet have valid IP addresses, they have to rely on network broadcasts to find a DHCP server, request an address, and secure a lease. This means that all of these communications occur on Layer-2 of the network and are not routable – at least not without some help from the network infrastructure. Most enterprise-class routers and switches can forward DHCP packets directly to a specified server in another network or subnet. This is called an IP Helper, or just helper address.

In the Cisco product line, this is specified at the network or subnet level as:

    IP Helper-address <Destination IP Address>

The NAK Poisoning Issue

When designing redundant or highly-available DHCP configurations, there is one additional hurdle that we must overcome – the problem of Negative Acknowledgement (NAK) Poisoning. The goal of installing additional DHCP servers is to provide uninterrupted service with a minimum of management overhead. It may seem intuitive that one would just want to configure a second DHCP server and give it a new scope so that workstations would be able to receive configuration information from either server. Unfortunately, this will result in occasional “quirkiness” where some workstations will not be assigned addresses when they try to renew. This leads to frustrating and difficult to track network problems.

When 50% of the license duration is up, the host will attempt to contact the server from which it originally received the license by renewing. If this is not available or unresponsive, the host will try again later. If 87.5% of the lease duration has expired, the host will broadcast on the network again and will bind to any DHCP server that responds to the request (rebinding). If this server cannot renew the lease, the workstation can end up in a state where is does not have a valid address and cannot participate in network communications.

Let’s look at what happens (translated into English for your enjoyment):

(Client) “Hey DHCP Server, I need to renew my address. 87.5% of my lease time is up.” (Rebinding)
(Server) “I can certainly do that for you. What address would you like to renew.”
(Client) “Well, I have been using 10.1.1.53/24. I’d like to keep using that one.”
(Server) “Hmm, I am authoritative for 10.1.2.0/24. Your address is not in my network. I can’t renew that one.” (This is the NAK)
(Client) “I guess I can’t get an address…”

At this point, the workstation is a bit lost as to what to do. It will continue to use its IP address until the lease is up and will try to renew again later. In some cases, the workstation will find the original DHCP server before the address lease expires, but in some cases, the above communication will continue and the workstation will eventually stop communication when it no longer has a valid address.

Avoiding the NAK

The best way to overcome this is to avoid it altogether. Your DHCP servers don’t have to be able to provide addresses for all scopes, but they should be aware of the scopes so that they can serve those clients. To do this reciprocal exclusions should be used to divide the scope into pieces – let’s look at a 50/50 split for the 10.1.1.1/24 subnet as an example:

Now the communication looks like this:

(Client) “Hey DHCP Server, I need to renew my address. 87.5% of my lease time is up.”
(Server 2) “I can certainly do that for you. What address would you like to renew.”
(Client) “Well, I have been using 10.1.1.53/24. I’d like to keep using that one.”
(Server 2) “Hmm, I am authoritative for 10.1.0/24, but I have an exclusion on that address. How about 10.1.1.222?”
(Client) “Thanks! 10.1.1.222 it is.

High-Availability Scenarios

Now we have all the pieces to pull together effective high-availability DHCP solutions to serve our enterprise. Just as there are a number of different network configurations, there are different configurations of DHCP that can be deployed to support them. It should also be noted that that using MSCS clusters to support DHCP isn’t an ideal solution as this tends to work inconsistently and is expensive.

Centralized/ Redundant DHCP

Centralizing DHCP can provide a single point of management for all of your workstation configuration changes and will allow a tightly-focused network administration staff control the whole environment from one point. This kind of configuration works best when you have a single large site or when you are willing to accept the single points of failure associated with your WAN links. Generally, though, this is usually done to provide on-segment redundancy for a single DHCP server.

On a network with only one subnet or router, you will be able to rely on the local network broadcasts to associate servers with workstations – whichever one happens to respond the fastest will become the DHCP server for that request. If you have multiple sites or subnets/ VLANs, you’ll need IP Helper Addresses pointing at both of the servers. Depending on the network hardware, you may find that the order that these are listed has an effect on the balance between the servers. (I have not found this to be the case on Cisco gear though.) In this configuration, you will want to start with a 50/50 split in your exclusions. Over time, you may find that you’ll have to adjust this split to compensate for differences in network speeds and hardware capacity.

Setup Steps:

1. Plan and diagram out your scopes. You generally want to plan for at least a 50% growth margin for DHCP to accommodate network growth as well as a long-term outage of one of your DHCP servers.
2. Configure all scopes on both servers
3. Configure 50/50 reciprocal exclusions on both servers
4. Configure any manual reservations on both servers
5. Test failover by disabling DHCP on each server and forcing a renew on the client (IPConfig /release | IPConfig /renew)

Distributed DHCP

In larger environments with many sites, it is important to provide local DHCP services to clients for immediate response to lease requests, but also to provide a centralized backup that is able to server requests in the event that there is a problem with the local server. This removes the risk associated with relying on the WAN links for a mission-important service like DHCP.

In this scenario, we will be relying on the fact that the WAN link is much slower than the on-segment network. The router/ switch must be configured with an IP helper to route the DHCP request to the centralized server, but the time needed to make this round trip will be significantly longer than the time needed to serve the request on the local network.

The sample scenario to the right is a three-site scenario comprised as a main HQ site and two branch offices. In this configuration, the scopes have been configured in an 80/20 distribution with 80% of the available IP address leases residing on the local network and 20% across the WAN as failover. It should also be noted that since the backup DHCP server is the second local server at the HQ site, it is splitting the DHCP load 50/50.

Often, network engineers will choose to only have a single DHCP server per site, but having a separate server at the main site will allow the load to be controlled and avoids a single point of failure at the HQ site. This may seem a bit complicated, but is relatively simple to configure and allow you to build all additional sites against a common design pattern.

Finally, you should let the network design and WAN connectivity act as a guide for the designing of highly available DHCP configurations. If you are set up as a hub and spoke configuration, the solution will be slightly different that in you have a few main sites with spokes off of each. Just make sure that you are taking the entire topology into consideration as you plan the final solution.

Setup Steps:

1. Plan and diagram out your scopes. You generally want to plan for at least a 50% growth margin for DHCP to accommodate network growth as well as a long-term outage of one of your DHCP servers.
2. Make sure you understand your network topology and plan your DHCP setup to avoid awkward network hops.
3. Configure the Primary DHCP servers for each site
4. Configure all scopes the backup DHCP server
5. Configure 80/20 reciprocal exclusions between the Branch Office DHCP servers and the Backup server.
6. Configure any manual reservations on both servers
7. Configure IP Helper-address commands on the routers/ switches at the branch offices.
8. Test failover by disabling DHCP on each server and forcing a renew on the client (IPConfig /release | IPConfig /renew)

Conclusion

Configuring highly-available DHCP solutions is not complicated or tricky if you understand the technology and plan using your network topology as a guide. Whether it is just configuring a single site failover for DHCP or an enterprise-scoped failover topology, using reciprocal scopes and IP helper-addresses will ensure that DHCP services are always available. One last note, be sure that you are monitoring your DHCP services. Even with HA servers backing up your primary scopes, you want to be sure that you are notified of server problems when then happen so you can react to them quickly. The best failover scenario is one that you never have to use.

Other Links:

• Microsoft DHCP Best Practices
  
• Backing Up DHCP
• Clustering DHCP

This prompt was posted in to my TCP/IP networking class.  This is my response that prompt (I encourage comment):

DHCP is by far the most robust and most “dynamic”, if you’ll excuse the dynamic reference. There are alternatives, each with its pros and cons. Once such alternative is BOOTP which uses UDP and can only be used on IPv4 networks. BOOTP was used primarily for disk-less operating systems. I still remember using BOOTP to boot to a Novell network from floppy just before installing Windows 95 from a network operating system. Another alternative is AUTOIP. The advantage with AUTOIP is that you don’t need a DHCP server.

Should we use it? Well, it depends. Aside from the aforementioned ‘dynamic’ protocols, the only other means to assign IP addresses would be to statically assign them. This is more ’secure’ than DHCP, but becomes a management nightmare. If you are running a network that needs to support 100’s+ users, then I would suggest DHCP. If it is a small office with a fixed number of workstations, a static IP environment might be best.

A few issue with DHCP. You will not want your servers getting IP addresses from DHCP. You either need to statically assign an IP to the server, or setup a DHCP reservation. This goes with printers as well. A DHCP reservation essentially ‘tells’ the DHCP server to always assign the same IP address to a particular MAC.

So I was in a need of having the active leases in my DHCP server exported to an web (html) page:

On the surface this would not present a problem, however as there is only one way to read the DHCP leases, netsh.exe, and the output format of this app is somewhat … I also got the chance to to play with regular expressions (love those) and <string> –replace

Just so everyone can share the pain, this is the netsh command:

netsh dhcp server 1.1.1.1 scope 1.1.1.0 show clients 1

And this is the output:

Changed the current scope context to 1.1.1.0 scope.

Type : N - NONE, D - DHCP B - BOOTP, U - UNSPECIFIED, R - RESERVATION IP
============================================================================================
IP Address      - Subnet Mask    - Unique ID           - Lease Expires        -Type -Name
============================================================================================

1.1.1.5     - 255.255.0.0    - 00-ff-ff-ff-ff-ff   -10/13/2009 12:33:16 AM  -D-  host01.domain.com
:::
::: Lot of lines here
:::
1.1.1.227   - 255.255.0.0    - 00-ff-ff-ff-ff-ff   -10/13/2009 12:42:06 AM  -D-  host10.domain.com

No of Clients(version 4): 355 in the Scope : 1.1.1.0.

Command completed successfully.

So is there any logic here? Double tabs, single tabs from which I can split? No. only spaces…. and hyphens.. and useless data

As I only needed the IP and hostnames in a html table, this is what I ended up with in powershell:

$a = (netsh dhcp server 1.1.1.1 scope 1.1.1.0 show clients 1)

$lines = @()
#start by looking for lines where there is both IP and MAC present:
foreach ($i in $a){
    if ($i -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}"){
        If ($i -match "[0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}"){
            $lines += $i.Trim()
        }
    }
}
$csvfile = @()
#Trim the lines for uneeded stuff, leaving only IP, Subnet mask and hostname.
foreach ($l in $lines){
    $Row = "" | select Hostname,IP
    $l = $l -replace '[0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}[:-][0-9a-f]{2}', ''
    $l = $l -replace ' - ',','
    $l = $l -replace '\s{4,}',''
    $l = $l -replace '--','-'
    $l = $l -replace '-D-','-'
    $l = $l -replace '[-]{1}\d{2}[/]\d{2}[/]\d{4}',''
    $l = $l -replace '\d{1,2}[:]\d{2}[:]\d{2}',''
    $l = $l -replace 'AM',''
    $l = $l -replace 'PM',''
    $l = $l -replace '\s{1}',''
    $l = $l + "`n"
    $l = $l -replace '[,][-]',','
    $Row.IP = ($l.Split(","))[0]
    #Subnet mask not used, but maybe in a later version, so let's leave it in there:
    #$Row.SubNetMask = ($l.Split(","))[1]
    $Row.Hostname = ($l.Split(","))[2]
    $csvfile += $Row
}

#let create a csv file, in case we need i later..
$csvfile | sort-object Hostname | Export-Csv "Out_List.csv"

#Create the HTML formating
$a = "<style>"
$a = $a + "body {margin: 10px; width: 600px; font-family:arial; font-size: 12px;}"
$a = $a + "TABLE{border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}"
$a = $a + "TH{border-width: 1px;padding: 2px;border-style: solid;border-color: black;background-color: rgb(179,179,179);align='left';}"
$a = $a + "TD{border-width: 1px;padding: 2px;border-style: solid;border-color: black;background-color: white;}"
$a = $a + "</style>"

#And create HTML file...
Write-Host "Please contact theadmin@void.null for support" | Out-File "DHCPLeases.html"
$csvfile | sort-object Hostname | ConvertTo-HTML -head $a | Out-File -Append "DHCPLeases.html"

The resulting output, then looks like this:

which is what I wanted. Another great job by powershell.

I hope that this might prove useful to someone else, and a my thanks goes out to the powershell community and all the people who might recognize some of the code, no one mentioned, no one forgotten.

Please do drop a line if you have comments or suggestions to how the script could be optimized. Life is a learning curve and I love climbing

Sui sistemi GNU/Linux esistono vari modi per fare i backup, per mettere al sicuro i nostri dati in caso di eventi (piu’ o meno) catastrofici. Uno di questi sistemi e’ il backup di host GNU/Linux attraverso dhcpd. Il tutto con alcuni semplici script e dhcp3. Vediamo passo passo come fare [1].

Dobbiamo agire sia sul server sia sul (o sui) client. Cominciamo dal server.

SERVER – Dobbiamo configurare dhcp3, apriamo dunque il file di configurazione:
# nano /etc/dhcp3/dhcps.conf
e aggiungiamo queste righe:

---8<---
on commit {
  execute (
    "/etc/dhcp3/startbackup.sh",
    "start",
    binary-to-ascii(10,8,".",leased-address)
  );
}
---8<---

Queste righe richiamano uno script bash che ancora non esiste, creiamolo dunque:
# vi /etc/dhcp3/startbackup.sh
e questo e’ il contenuto:

---8<---
#!/bin/bash
case "$1" in
start)
  sudo -u backup /etc/dhcp3/rsync.sh $2
;;
*)
;;
esac
exit 0

---8<---

In questo primo script se ne richiama un secondo, creiamo dunque anche l’altro:
# vi /etc/dhcp3/rsync.sh
con questo contenuto:

---8<---
#!/bin/bash
nohup rsync -azuvb backup@$1:/home /backup/$1 &

---8<---

Non ci resta che creare la directory che conterra’ i backup:
# mkdir /backup

Aggiungiamo l’utente backup:
# useradd backup
e diciamo (con chown) al sistema di assegnare la directory backup all’utente backup:
# chown backup:backup /backup

Creiamo la chiave SSH (pubblica e privata):
$ ssh-keygen -t rsa
e copiamo la chiave pubblica in tutti gli host di cui vogliamo fare il backup:
$ ssh-copy-id -i ~/.ssh/id_rsa backup@[host]
al posto di host va messo l’hostname o l’indirizzo IP.

Possiamo configurare sudo:
sudo visudo
cosi’:

---8<---
dhcpd ALL=(backup)NOPASSWD: /etc/dhcp3/startbackup.sh, /etc/dhcp3/rsync.sh
---8<---

Cambiamo anche AppArmor:
# vi /etc/apparmor.d/usr.sbin.dhcpd3
la parte che contiene queste righe:

---8<---
/etc/dhcp3/ r,
/etc/dhcp3/** r,
/etc/dhcpd.conf r,
/etc/dhcpd_ldap.conf r,
---8<---

va sostituita con queste:

---8<---
/etc/dhcp3/ r,
/etc/dhcp3/** r,
/etc/dhcp3/startbackup.sh Uxr,
/etc/dhcpd.conf r,
/etc/dhcpd_ldap.conf r,
---8<---

Riavviamo AppArmor e dhcp3:
# /etc/init.d/apparmor restart
# /etc/init.d/dhcp3-server restart

E qui si concludono le operazioni da effettuare sul server. Ora dobbiamo agire sui client.

CLIENT – Ahhiungiamo dunque l’utente backup:
# useradd backup
# usermod -G root

Abbiamo finito, il sistema e’ pronto.

Proviamo dunque a vedere se tutto funziona correttamente, facciamo un backup di prova:
sudo dhclient [interface]
al posto di interface dovete inserire l’interfaccia che ci interessa (eth0 ad esempio).

Finita la procedura nel server avremo un backup del client.

[1] Scopiazzato da: Automated Backups Using dhcpd On Ubuntu. [^]

[^] torna su | post<li> | 

In many cases, it is essential to find the name of a computer over a local network. Such fits well when on a DHCP network, and need to always reach a certain machine.

An easy way to obtain this data, is via the python socket library. The ip of the desired machine is obtained via ipconfig (windows) or ifconfig (linux). For the sake of the example, assume that the ip from the DHCP network is 10.0.0.5.

In the python interpretor, execute the following code:

import socket
true_name = socket.gethostbyaddr("10.0.0.5")[0]
print true_name


The code above prints the true name of the machine, as seen on the network. This name is not always the machine name. For example the machine name could be “saher-desktop”, while the name on the network is “saher-desktop.local”.

This post will provide fault tolerance in case of a router outage and continuously connected on internet, you can choose to configure Windows computers so that they can use multiple default gateways in a multiple router and ISP environment. When you assign multiple gateways, Windows uses the gateway metric to determine which gateway is used. The gateway with the lowest metric indicates the routing cost of using gateway. The gateway with the lowest routing cost, or metric, is used first. If the computer can’t communicate with this gateway, Windows tries to use the gateway with the next lowest metric.

The best way to configure multiple gateways depends on the configuration of your network. If your organization’s companies computers use DHCP, you’ll probably want to configure the additional gateways through settings on the DHCP server. If the computers use static IP address or you want to set gateways specifically, assign them by following these steps:

1. Click Start and then click Network. In Network Explorer, click Network and Sharing Center on the toolbar.

2. In the Network and Sharing Center, click Manage Network Connections. in Network Connections, right click the connection you want to work with and then select Properties.

3. Double-click IPv4 or IPv6 as appropriate for the type of IP address you are configuring.

4. Click Advanced to open the Advance TCP/IP Settings dialog box.

5. The Default Gateways panel shows the current gateways that have been manually configured (if any). You can enter additional default gateways as necessary. Click Add and then type gateway address in the Gateway text box.

6. By default, Windows automatically assigns a metric to the gateway. You can also assign the metric manually. To do this, clear the Automatic Metric check box and then enter a metric in the text box provided.

7. Click Add and then repeat 5-7 for each gateway you want to add.

8. Click Ok and then click Close.