DHCP failover / load balancing (and synchronization) with CentOS 6

DHCP is a wonderful piece of software. It keeps our networks running smoothly. For small networks, probably 100 machines or so, one server is enough, but to larger networks, is not a bad idea to have another one, just in case the firts one fails or the load is just to much..

DHCP has some configurations for load balancing and failover, the – failover declaration – that allows us to configure it.

The Servers:

Primary IP address: 10.1.2.1

Secondary IP address: 10.1.2.2

To keep things simple, you can create a new file, and then just insert it in the global dhcpd.conf (configuration below)

Primary DHCP server

Open a new file and put the following lines in it:

vi /etc/dhcp/dhcpd.failover

# Failover specific configurations

failover peer “dhcp” {
primary;
address 10.1.2.1;
port 647;
peer address 10.1.2.2;
peer port 647;
max-response-delay 60;
max-unacked-updates 10;
mclt 600;
split 128;
load balance max seconds 3;
}
Now, in the secondary DHCP server, just to the same:
Secondary Server
failover peer “dhcp” {
secondary;
address 10.1.2.2;
port 647;
peer address 10.1.2.1;
peer port 647;
max-response-delay 60;
max-unacked-updates 10;
load balance max seconds 3;
}
After creating the files, just add the configuration to the global config file (in both servers), somewhere before (groups | share networks | host) definitions
include “/etc/dhcp/dhcpd.failover”;
Now, to the definitions.
To take advantage of the new definitions, we need to create a pool. You can put it in any (subnet| shared-network|etc..) declaration:
 
 
network 10.1.2.0 netmask 255.255.0.0 {
option routers 10.1.2.254;
option subnet-mask 255.255.0.0;
option broadcast-address 10.1.255.255;
pool {
failover peer “dhcp”;
range 10.1.2.1 10.1.254.254;
}
}
 
Note: If you have static declarations (i have all my clients in static declarations), to avoid warnings in the log about dynamic and static mappings, reduce the range to only one client. It’s mandatory the range declaration
IMPORTANT: Is of utmost importance to have both servers with the same date and time. If they are not, DHCP will complain and the secondary server (the whole server) will not work well… You can accomplish this with ntpdate
If you are getting this messages in syslog:
Failover CONNECT to dhcp rejected: Connection rejected, time mismatch too great.

Then the time is not the same.

If you want to know more about the configuration parameters in the failover declarations, go to the ipamworldwide web site
Synchronization
DHCP doesn’t have a synchronization mechanism (as far as i know – please correct me if i’m wrong), so changes you’ll make to the primary server will not reflect in the secondary server. This could be done using scripting or yourself manually copying the changed file over to the secondary server. But sometimes, in the heat of the moment, because something important happened or someone is waiting for your attention, you forget…
There’s a small program that can accomplish the synchronization without you even remember that you must copy the files…
iwatch is a small program that monitors wherever you want (files, directories) and upon changes, it can perform several actions.
A few months ago i wrote about iwatch and how’s installed and configured (portuguese), but i’ll replicate the steps here, using the DHCP files has an example.
The CentOS minimal installation doesn’t have rsync and wget installed, so we need to install those.
yum install rsync wget
 
Note: The steps above are only required in the primary server. The changes are made here and then replicated to the secondary server.
Install the rpmforge repositories. You can get the rpm and instructions here
Install the required perl packages
yum install perl-Event perl-Mail-Sendmail perl-XML-SimpleObject perl-XML-Simple perl-Linux-Inotify2
 
After installing, we can finally install iwatch.
Download it from sourceforge
After download, untar it:
tar -zxvf iwatch-0.2.2.tgz
A new directory is created
cd iwatch
 
In there, you’ll find a few files.
Let’s copy the files to the proper places
cp iwatch /usr/local/bin/
cp iwatch.xml /etc/
cp iwatch.dtd /etc/
A few considerations before continuing:
We want to synchronize changes in the DHCP configurations, so, we’ll monitor the /etc/dhcp directory for:
  • Creation of files
  • changes in files
  • deleting of files
  • add an exception for dhcpd.failover (those are different in the servers – depending of primary or secondary server)
Now that we know what we want, let’s proceed:
Before we edit the configuration file, so we can execute iwatch as a daemon, let’s execute it in command line and edit a file so we can see what’s happening. Open two terminals: One will be used to execute iwatch and some arguments, the other will be to edit a file.
First terminal:
Execute iwatch and see some output:
/usr/local/bin/iwatch -e modify,create,close_write -c “touch /tmp/someaction” -r -v /etc/dhcp/
 

output:
Watch /etc/dhcp
Watch /etc/dhcp/Configs
Watch /etc/dhcp/dhclient.d

 
Second terminal
Let’s edit a file in the watched directory and see what’s happening in terminal 1. You can just open it, no changes, but save the file and watch the output in Terminal 1.
vi /etc/dhcp/dhcpd.conf
In terminal 2, you’ll see:
[14/Mar/2012 16:18:34] IN_CREATE /etc/dhcp/Configs/.dhcp.vlan.swp
[14/Mar/2012 16:18:34] * Command: touch /tmp/someaction
[14/Mar/2012 16:18:34] IN_CREATE /etc/dhcp/Configs/.dhcp.vlan.swx
[14/Mar/2012 16:18:34] * Command: touch /tmp/someaction
[14/Mar/2012 16:18:34] IN_CLOSE_WRITE /etc/dhcp/Configs/.dhcp.vlan.swx
[14/Mar/2012 16:18:34] * Command: touch /tmp/someaction

Now that we saw it working, let’s configure the daemon part.

Edit the file /etc/iwatch.xml. The file syntax is XML. Here’s an example of my configuration.
You can read more in iwatch sourceforge page.
<?xml version=”1.0″ ?>
<!DOCTYPE config SYSTEM “/etc/iwatch.dtd” ><config charset=”utf-8″>

<guard email=”informatica@ulscb.min-saude.pt” name=”IWatch”/>

<watchlist>

<title>DHCP Sync</title>
<contactpoint email=”sysadmin@domain.com” name=”Administrator”/>
<path type=”recursive” syslog=”on” alert=”off” events=”create,delete,close_write” exec=”/root/scripts/syncFiles”>/etc/dhcp</path>
<path type=”regexception”>b4913b</path>
<path type=”exception”>/etc/dhcp/dhcpd.failover</path>
<path type=”exception”>/etc/dhcp/dhclient.d</path>

<path type=”regexception”>.*.swp*</path>

<path type=”regexception”>.*~</path>

</watchlist>

</config>

Now, edit that file and make the changes you want

I’ve added a few exceptions, because there are files i don’t need to sync.

Also, vi creates a few temporary files (directory 4913 and backups with ~ | swp extensions) when you’re editing, and those don’t mind.

We are not also using modify, because if a file is closed with write, it was modified, right ?

The exec  parameter tells iwatch what to do when any of the events occurs. I have a script (syncFiles) that synchronizes with the secondary server and sends and email

#!/bin/bash
# Script to synchronized dhcp changes
# This script will be called by iwatch
# DO NOT EXECUTE THIS SCRIPT – IT WILL BE EXECUTED AUTOMATICALLY
# 15/12/2011
log=”/tmp/synclog.log”
echo “Syncing dhcp from primary server to secondary server” >> $log
# Using rsync so it can only copy different files – Low on bandwith/usr/bin/rsync -avz –delete -e ssh /etc/dhcp/ –exclude dhcpd.failover root@secondary:/etc/dhcp >> $log
# Restart the service with the new configurations
ssh root@secondary -C “service dhcpd restart” >> $log
service dhcpd restart >> $log
# Email
if [ -a $log ]; then
mail sysadmin@domain.com -s “Sync dhcp ” < $log
rm -f $log
fi

I use rsync to perform the copy. I exclude dhcpd.failover because the files are not the same and they depend on the server (primary or secondary)

Notes: A few security issues. iwatch is executed with root privileges – it’s started by /etc/rc.local

If you do nothing, every time the script is executed, you’ll have to give the root password of the secondary server. You can prevent this (if you want) by adding the ssh key to the authorized keys and have a password-less ssh configuration between those two servers (using only keys)

Now, just put iwatch executing when the machine start:

vi /etc/rc.local
# Exec iwatch
/usr/local/bin/iwatch -d

Execute iwatch as daemon

/usr/local/bin/iwatch -d

Now you have a dhcp failover instalation and synchronization

Hope it helps anyone

References

http://www.lithodyne.net/docs/dhcp/dhcp-4.html

http://www.madboa.com/geek/dhcp-failover/

http://www.ipamworldwide.com/dhcp-failover-a-load-balancing/declarations.html

Install logwatch Centos 6

Logwatch is a wonderfull Linux tool that informs us (by email if you like) to what happened to a server during the previous day (configurable).

EDIT: I’ve just tried with CentOS 6.3 minimal install, with the default mirrors configured and logwatch (yum install logwatch) installed just perfectly.

In CentOS 6, there’s a problem installing it (at least in all my servers with CentOS 6 i had it) because of perl-Date-Manip, with the error:

http://mirrors.nfsi.pt/CentOS/6.2/os/i386/Packages/perl-Date-Manip-6.24-1.el6.noarch.rpm: [Errno -1] Package does not match intended download.

I guess it’s because of the version…

The solution: Get perl-Date-Manip-5.54-4.el6.noarch.rpm from the internet (ie rpm.pbone.net) and before installing it, install all it’s dependencies.

NOTE: This version is i686. For x86_64 just replace the arch.

Go to http://rpm.pbone.net/index.php3/stat/4/idpl/17455805/dir/centos_6/com/perl-Date-Manip-5.54-4.el6.noarch.rpm.html and download it.

Edit (new package): http://rpm.pbone.net/index.php3/stat/4/idpl/17468903/dir/centos_6/com/perl-Date-Manip-6.24-1.el6.noarch.rpm.html

Before installing, install all it’s dependencies:

yum install mailx perl perl-Module-Pluggable perl-Pod-Escapes perl-Pod-Simple perl-YAML-Syck perl-libs perl-version

And then, install perl-Date-Manip that we have downloaded before:

rpm -ivh perl-Date-Manip-5.54-4.el6.noarch.rpm

and next, we can install logwatch:

yum install logwatch

This way, logwatch is installed

2012/07/03

If you want to have logwatch mailed to you, you need to install sendmail (or postfix). According to logwatch.conf, only sendmail (and mailers that support output stream) can be used

From logwatch.conf:

# By default we assume that all Unix systems have sendmail or a sendmail-like system. # The mailer code Prints a header with To: From: and Subject:. # At this point you can change the mailer to any thing else that can handle that output # stream. TODO test variables in the mailer string to see if the To/From/Subject can be set # From here with out breaking anything. This would allow mail/mailx/nail etc….. -mgt

Installing sendmail

yum install sendmail

Configuring the email address

Now, we have two choices – or we just put our email address in logwatch configuration file – or we put it in /etc/aliases, thus receiving all email to root from the system. The latter is better, since we catch all email from our system.

Editing aliases

vi /etc/aliases

Go to line 96, uncomment the line (remove the ‘#’) and change the name to your email address:

# Person who should get root’s mail
root: youremail@yourdomain.com

Save and run:

newaliases

Start sendmail

/etc/init.d/sendmail start

and you can see how things are going by watching /var/log/maillog

tail -f /var/log/maillog

 Note: If you get an error because of Perl-Date-Manip and the timezone, that’s a problem and i couldn’t find a solution.

Configurar http proxy com filtro de conteúdos (dansguardian)

Activar repositórios necessários.

rpmforge

wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

rpm -ivh rpmforge-release-0.5.2-2.el5.rf.x86_64.rpm

Instalar a chave GPG de DAG

rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

EPEL

O Repositório EPEL (Extra Packages for Enterprise Linux) é um repositório construído por voluntários do projecto do Fedora para criar um repositório de pacotes adicionais de grande qualidade que complementa o Red Hat Enterprise Linux e distribuições compatíveis (tipo o CentOS). Este repositório fornece muitos pacotes para CentOS/RHEL, que não são parte dos repositórios oficiais, mas que são desenhados para trabalhar com estas distribuições.

wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm

rpm -ivh epel-release-5-4.noarch.rpm

Verificar os repositorios

yum repolist

Após o comando anterior, vão aparecer os repositórios disponiveis e a quantidade de pacotes em cada um deles.

Instalar o Squid e o dansguardian

yum install squid dansguardian

Squid

Editar o squid.conf

vi /etc/squid/squid.conf

O ficheiro de configuração do squid parece extenso, mas está muito bem documentado. De qualquer forma, as unicas linhas necessárias para uma minima configuração do squid são:

 

http_port 3128

#Definicao de ACLS

# Redes permitidas
acl AllowedNetworks src 192.168.100.0/24

# Se preferirem, em vez de colocar as redes separadas por espaco, podem ser colocadas num ficheiro e adicionadas aqui:
# acl <nome_da_acl> src "ficheiroComRedes"

# Maquinas sem acesso - Se quiserem que maquinas nao tenham acesso a internet
acl Nonet src "ficheiroIPsSemAcesso"

# Sites nao autorizados 
acl sitesDeny dstdom_regex "ficheiroComListaSitesParaNaoAcederemAEles"

#Permitir / Negar ACLS definidas em cima

# Redes
http_access allow AllowedNetworks

# Localhost
http_access allow localhost

# Sites negados
http_access deny sitesDeny

# Negar tudo o resto
http_access deny all

icp_access allow AllowedNetworks
icp_access allow all

hierarchy_stoplist cgi-bin ?

#Cache stuff
cache_replacement_policy lru

# Definicao da cache - tamanho (ate 80% do espaco disponivel) NumerodeDirectoriasPrimeiroNivel NumeroDirectoriasSegundoNivel
cache_dir ufs /cache/cache1 16384 16 256
cache_dir ufs /cache/cache2 16384 16 256

store_dir_select_algorithm round-robin

# Qual o tamanho maximo de objectos a guardar na cache
maximum_object_size 31457280 KB

access_log /var/log/squid/access.log squid
acl QUERY urlpath_regex cgi-bin ?

cache deny QUERY
refresh_pattern ^ftp:           1440    20%     10080
refresh_pattern ^gopher:        1440    0%      1440
refresh_pattern .               0       20%     4320
acl apache rep_header Server ^Apache
broken_vary_encoding allow apache

visible_hostname <hostname da maquina visivel>
cache_mgr <email gestor da maquina>
cache_effective_user squid
cache_effective_group squid

coredump_dir /var/spool/squid

Guardar o ficheiro.
Para iniciar a cache (antes de arrancar com o squid):
squid -z 
Arrancar com o squid:
/etc/init.d/squid start
Para ter a certeza que este inicia aquando de um reboot ao servidor:
chkconfig --levels 35 squid on

Dansguardian

O Dansguardian é um filtro de conteúdos bastante bom. Também podem filtrar conteúdos com o squid, mas o Dansguardian foi criado só para isso, e é muito bom. Mantendo a filosofia de Unix – Write programs that do one thing and do it well.
Os ficheiros de configuração encontram-se em /etc/dansguardian
A configuração do dansguardian é efectuada em dansguardian.conf
As opcoes mais relevantes são:

filterip =  
filterport = 8080
proxyip = 127.0.0.1
proxyport = 3128
As opções:
  • filterip diz respeito ao IP onde o dansguardian deverá escutar por pedidos. Se deixado em branco, escuta em todos os IPs que a máquina tiver. Preencham sempre.
  • filterpor a porta onde escutar. Esta é porta que devem configurar nos clientes
  • proxyip o IP onde o squid está à escuta. Por defeito, é a propria maquina. Se o squid estiver numa maquina diferente, coloquem aqui o IP.
  • proxyport a porta onde o SQUID escuta. Configurada no squid como http_port . Não deverá ser a mesma que o dansguardian.

No ficheiro dansguardianf1.conf encontram-se algumas opções relativamente à filtragem de conteúdos.

Tenham atenção à opção naughtynesslimit.

As listas de conteúdos para filtrar, vamos retirar de URLBlacklist.com. Vão a download e retirem o ficheiro.

Assim que tiverem o ficheiro, descomprimam para /etc/dansguardian/. Automaticamente é criada a directoria blacklists. A configuração das listas que desejam que o dansguardian filtre é feita em vários ficheiros:

  • bannedsitelist
  • bannedurllist

Nestes ficheiros encontram-se linhas comentadas que podem ser descomentadas. Atenção que, um dos ficheiros diz respeito a sites e outro aos URLs. Tenham atenção a isso. A seguinte listagem exemplo é do ficheiro bannedurllist.

#.Include</etc/dansguardian/blacklists/ads/urls>

#.Include</etc/dansguardian/blacklists/adult/urls>

#.Include</etc/dansguardian/blacklists/aggressive/urls>

#.Include</etc/dansguardian/blacklists/audio-video/urls>

#.Include</etc/dansguardian/blacklists/chat/urls>

#.Include</etc/dansguardian/blacklists/drugs/urls>

#.Include</etc/dansguardian/blacklists/entertainment/urls>

#.Include</etc/dansguardian/blacklists/frencheducation/urls>

#.Include</etc/dansguardian/blacklists/gambling/urls>

#.Include</etc/dansguardian/blacklists/government/urls>

#.Include</etc/dansguardian/blacklists/hacking/urls>

Descomentem as que desejarem.  Se desejarem, podem adicionar, seguindo as mesmas linhas. Podem haver categorias nas blacklists que não estejam aqui.
Dentro da directoria blacklists encontram um ficheiro chamado CATEGORIES que contém as categorias todas das listas e o conteúdo.
Quando efectuarem alguma alterção com o dansguardian em execução, para que ele leia novamente a configuração:
dansguardian -r
Para iniciar o dansguardian:
/etc/init.d/dansguardian start
Para se certificarem que ele arranca aquando de um reboot do servidor:
chkconfig --levels 35 dansguardian on

Ligação entre dansguardian e squid.

Para que exista ligação entre o dansguardian e o squid, é necessário activar algumas opções:

No squid, existem duas linhas de configuração que temos que activar:

# Para permitir o dansguardian

acl_uses_indirect_client on

# Se nao funcionar, experimentem, na linha seguinte, alterar localhost para o nome da acl para as vossas redes permitidas

follow_x_forwarded_for allow localhost 

No Dansguardian, as linhas são as seguintes:

# if on it adds an X-Forwarded-For: <clientip> to the HTTP request

# header.  This may help solve some problem sites that need to know the

# source ip. on | off

forwardedfor = on

# if on it uses the X-Forwarded-For: <clientip> to determine the client

# IP. This is for when you have squid between the clients and DansGuardian.

# Warning - headers are easily spoofed. on | off

usexforwardedfor = on

Desta forma, os vossos clientes ligam-se ao Dansguardian, onde é efectuada a filtragem de conteúdos e é passada para o squid a informação dos clientes, nomeadamente o IP e os headers necessários.
Neste momento, já deverão ter o squid e o dansguardian em perfeita sintonia.
Nota: Em vez de configurar IPTABLES para negar ligações directas à porta do squid (3128 por defeito), é mais simples, na tag de configuração do squid http_port, escrever:
http_port 127.0.0.1:3128
Desta forma, apenas a máquina local (neste caso o dansguardian; 127.0.0.1 o dispositivo de loopback) pode efectuar ligações directas. Simples e eficaz.
Configuração usando IPTABLES
Até agora, nada impede (a não ser politicas de domínio ou outras restrições) que os vossos clientes chegem ao browser e troquem a porta do proxy, deixando de se ligar ao dansguardian e ligando directamente ao squid, passando assim a filtragem de conteúdos. Para evitar isso, usem a seguinte regra de IPTABLES que nega ligações à porta 3128 excepto do localhost (funciona se o squid e o dansguardian estiverem na mesma maquina – Se assim não for, troquem o ip 127.0.0.1 pelo IP do vosso dansguardian):
Primeiro, permitimos ligações à porta do squid (3138) da própria maquina – Se o Dansguardian estiver noutra maquina, troquem o IP:
iptables -A INPUT -i eth0 -s 127.0.0.1 -p tcp --destination-port 3128 -j ACCEPT
Seguidamente, negamos todas as ligações:
iptables -A INPUT -i eth0 -p tcp --destination-port 3128 -j DROP
Desta forma, se alguém se tentar ligar directamente à porta do squid, não vai conseguir ligação.

Referências

http://wiki.centos.org/AdditionalResources/Repositories/RPMForge

http://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_install_the_packages_from_the_EPEL_software_repository.3F

http://www.cyberciti.biz/tips/how-do-i-enable-remote-access-to-mysql-database-server.html

SVN (Subversion) Proxy Settings

Para quem usa subversion para retirar ficheiros, ou mesmo efectuar o upload de ficheiros, e está por trás de um proxy, não consegue.

Existe uma forma em Linux de usar um proxy, que é exportar variáveis de ambiente:

export http_proxy=http://proxy.dominio.com:porta/

export ftp_proxy=http://proxy.dominio.com:porta/

e colocar estas variáveis no ~/.bashrc para o utilizador ou em /etc/profile para o sistema. Embora funcione para muitas aplicações de linhas de comandos, o subversion (svn) não usa.

Assim, é necessário um pequeno truque para "obrigar" o subversion a usar um proxy.

Basta editar o ficheiro servers e configurar as variáveis com os valores correctos.

vi ~/.subversion/servers

[global]
http-proxy-exceptions = *.dominio.com
http-proxy-host = proxy.dominio.com
http-proxy-port = porta_proxy

Guardar e experimentar novamente. Desta vez o subversion já irá funcionar.

No mesmo ficheiro também encontram variáveis para preencher caso precisem de um utilizador e uma password

Referências:

http://blogs.sun.com/venu/entry/svn_proxy_settings

Problemas com apt-get e proxy (squid)

Recentemente começei a usar o apt para actualizar a minha distribuição (Caixa Mágica 15) e instalar pacotes, e desde então começei a ter problemas quando fazia apt-get update (para actualizar a listagem de pacotes), devolvendo-me sempre isto:

Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main32 pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_main32_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib32 pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib32_updates pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free pkglist
  The http server sent an invalid reply header
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free_updates pkglist
  Connection failed
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free32 pkglist
  The http server sent an invalid reply header
Hit http://ftp.caixamagica.pt media_info/synthesis.hdlist_non-free32_updates pkglist
Err http://ftp.caixamagica.pt media_info/synthesis.hdlist_contrib pkglist
  The http server sent an invalid reply header

Pensei que fosse alguma coisa com os mirrors da Caixa Mágica, mas em minha casa não acontece nada disto. No meu local de trabalho uso um proxy (Squid 3.1) e pensei que fosse este o problema, então comecei a investigar.

Existe uma opção no Squid que controla como gerir um tipo de pedido – "If-Modified-Since" – dos clientes. Por defeito, o Squid responde baseado na idade do objecto que tem na cache e não no objecto real na página web. Os comentários no ficheiro de configuração do squid indicam que alguns clientes usam pedidos IMS quando pedem uma actualização. – APT é um desses clientes.

Assim, é necessário alterar uma opção no squid para que este, quando detecte um pedido destes, envie a ultima versão do objecto pedido.

Um pedido IMS – If-Modified-Since" é um mecanismo de revalidação na especificação 1.1 do HTTP que garante que os dados em cache estão actualizados.

vi /etc/squid/squid.conf

e acrescentar/alterar

refresh_all_ims on

squid -k reconfigure

Desta forma, os erros já não aparecem.

 

Referências:

http://veejoe.net/blog/2009/05/trouble-with-apt-get-and-squid/

http://www.squid-cache.org/Doc/config/refresh_all_ims/

http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Net_caching.html

DNS Performance Test

Muitas vezes discuto com colegas meus como seria o ataque perfeito à Internet. Muitos falam em DOS (Denial Of Service) a uns quantos servidores mais utilizados, outros seria ARP Poison, etc…

Existe uma pequena proeza que, se realizada, terminava com a Internet. Um ataque ao DNS…

(more…)

Configurar o bonding em OpenSuse 10.2

O driver de bonding é um método em Linux de agregar várias interfaces físicas de rede numa única interface lógica. O melhor que este método tem é que as interfaces de rede não têm que ser do mesmo fabricante, pois alguns fabricantes fornecem drivers para Linux para realizar esta tarefa.

O comportamento da interface lógica depende do método configurado. É aconselhado configurar este driver como módulo, pois neste momento é a única forma de passar argumentos ao módulo e configurar diversas interfaces.

Para configurar o bonding é necessário que esteja instalado o utilitário ifenslave, pois é através deste que são agregadas as placas de rede. Este utilitário é fornecido juntamento com as sources do kernel, e encontra-se em Documentation/networking/ifenslave.c.

Em OpenSuSE 10.2, este utilitário já se encontra instalado e não é necessário executar os passos descritos em baixo. É necessário também que o kernel tenha sido compilado com suporte de bonding.

Para instalar:

    # gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave
    # cp ifenslave /sbin/ifenslave

Se as sources do kernel não estiverem instaladas em /usr/src/linux então, substituir o caminho.

Agora que temos o programa instalado, vamos configurar o OpenSuSE 10.2

Ambiente testado:

  • OpenSuSE 10.2
  • Kernel 2.6.18.8-0.5-bigsmp

Em primeiro lugar, vamos ter a certeza que o modulo é carregado sempre que reiniciar-mos o nosso sistema operativo. Para isso, editamos o ficheiro /etc/modprob.conf.local que é o local mais indicado para colocar-mos os nossos modulos.

Um pouco de explicação do bonding

O bonding, acima de tudo, vais-nos permitir configurar o computador com uma politica chamada 802.3ad. Também conhecido como Link Aggregation, permite agrupar diversas portas ethernet em paralelo, permitindo assim aumentar a velocidade para além dos limites dados por apenas uma porta ethernet, aumentando também a disponibilidade criada pela redundância.

Existem diversos modos de operação, sendo eles:

  • 0 – Balanceamento (round robin): Politica por defeito – envia os pacotes sequencialmente, desde o primeiro "escravo" até ao ultimo.
  • 1 – Backup activo: Apenas um "escravo" está activo. Um escravo diferente entra em actividade apenas se o "escravo" activo falhar. Fornece tolerância a falhas.
  • 2 – Politica XOR: Transmite baseado na politica de hash selecionada. Este modo fornece tolerância a falhas e balanceamento.
  • 3 – Broadcast: Transmite tudo em todos os "escravos". Este modo fornece tolerância a falhas.
  • 4 – 802.3ad – IEEE 802.3ad Dynamic Link Aggregation: Cria grupos agregados que partilham a mesma velocidade e modo. Utiliza todos os "escravos" segundo a especificação 802.3ad

Editar o ficheiro /etc/modprob.conf.local e adicionar as seguintes linhas:

  • alias bond0 bonding
  • options bond0 mode=4 miimon=100

Neste caso, optou-se pelo modo 4 (802.3ad), mas que, para que funcione, é necessário ter as interfaces ligadas a um switch que suporte este protocolo, porque senão não irá funcionar.

Após editar o ficheiro, vamos criar um ficheiro de configuração para a interface bond0. Entrar na directoria /etc/sysconfig/network. Copiar um ficheiro de uma interface já configurada e editar o ficheiro para realizar as alterações:

  • cp ifcfg-eth-XXXX ifcfg-bond0

Editamos o ficheiro recentemente criado e alteramos as opções:

vi ifcfg-bond0

opções de rede (alterar consoante as necessidades):

    BOOTPROTO=’static’
    BROADCAST=’192.168.100.255′
    IPADDR=’192.168.100.2′
    NETMASK=’255.255.255.0′
    NETWORK=’192.168.100.0′
    STARTMODE=’onboot’

opções do bonding

    BONDING_MASTER=’yes’
    BONDING_MODULE_OPTS=’mode=4 miimon=100′

listagem das interfaces "escravas"
    BONDING_SLAVE0=’eth0′
    BONDING_SLAVE1=’eth1′

Guardamos as alterações. Para o seguinte passo temos duas opções. Ou removemos os ficheiros de configuração das interfaces ou renomeamos para outro nome para que não sejam interpretados no proximo reboot.

  • rm -f ifcfg-eth-bus-XXXX:XX:XX.X (remover para todas as interfaces)

Agora, basta testar a nossa configuração:

  • ifdown ethX (fazer para todas as interfaces existentes e configuradas)
  • ifup bond0

A partir deste momento, temos a nossa interface bond0 configurada e em funcionamento. Resta neste momento adicionar a rota para a nossa gateway. Para testes, podemos executar na consola, mas é aconselhado através do YAST adicionar a rota permanentemente.

  • route add default gw 192.168.100.254 netmask 255.255.255.0

Verificar o nosso ficheiro /etc/resolv.conf e verificar se os servidores de nomes e o nome da rede estão bem configurados. Após garantirmos, testamos com um ping.

/sbin/ifconfig

bond0     Link encap:Ethernet  HWaddr 00:30:05:1B:05:3A
          inet addr:192.168.100.2  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::230:5ff:fe1b:53a/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:3538 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2544 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2115556 (2.0 Mb)  TX bytes:290026 (283.2 Kb)

eth0      Link encap:Ethernet  HWaddr 00:30:05:1B:05:3A
          inet6 addr: fe80::230:5ff:fe1b:53a/64 Scope:Link
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:1237 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2059 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:130279 (127.2 Kb)  TX bytes:236566 (231.0 Kb)

eth1      Link encap:Ethernet  HWaddr 00:30:05:1B:05:3A
          inet6 addr: fe80::230:5ff:fe1b:53a/64 Scope:Link
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:2301 errors:0 dropped:0 overruns:0 frame:0
          TX packets:485 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1985277 (1.8 Mb)  TX bytes:53460 (52.2 Kb)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:111 errors:0 dropped:0 overruns:0 frame:0
          TX packets:111 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9896 (9.6 Kb)  TX bytes:9896 (9.6 Kb)

O output em cima mostra as interfaces configuradas. reparem que apenas a interface bond0 contém um IP definido (reparem nos MAC Address).

Possíveis problemas

Após um reboot à máquina, é possivel que surjam alguns problemas. Aqui ficam algumas soluções que podem tentar caso isso se verifique.

Ocasionalmente foi experimentado que algumas placas de rede não arrancam depois de um reboot. Para prevenir, os modulos dessas placas devem ser colocados em memoria mais cedo. Para tal, editar o ficheiro /etc/sysconfig/kernel, procurar a linha MODULES_LOADED_ON_BOOT="" e adicionar os modulos das nossas placas de rede. Realizar novo reboot.

Caso não resolva a alteração descrita em cima, retirar as alterações e editar a seguinte linha (no mesmo ficheiro): INITRD_MODULES="(lista de modulos)"  e acrescentar os modulos das placas. Executar o comando mkinitrd e realizar novo reboot.

Outro processo que também pode ajudar é alterar o seguinte ficheiro: /etc/sysconfig/network/config, procurar a linha WAIT_FOR_INTERFACES="XX" onde XX será o tempo em segundos.

Após isto tudo, se mesmo assim não resolver, vejam o ficheiro /var/log/messages, identificar algum erro que possa surgir e google for it.