O “problema” é que muitas vezes se deseja utilizar os pacotes que estão no DVD de instalação do Red Hat e não os da Internet (nem todos tem uma assinatura da RHN) e o yum não está configurado para utilizar o DVD como repositório.

Não é algo muito difícil de se fazer, basta criar um repositório e adicionar o caminho correto para o DVD.

Então crie o arquivo /etc/yum.repos.d/dvd.repo (não é necessário que o nome seja dvd.repo, pode-se escolher qualquer nome desde que a extensão seja mantida) e adicione o seguinte conteúdo:
[dvd]
mediaid=1250663123.136977*
name=DVD do RHEL5
baseurl=file:///media/RHEL_5.4%20i386%20DVD/Server
enabled=1
gpgcheck=0

Feito isto, o yum irá reconhecer o DVD como repositório de pacotes de instalação. As únicas observações são que valor para o mediaid está contido no arquivo .discinfo que está na raiz do DVD de instalação e que a baseurl eventualmente precisará ser ajustada, dependendo da versão do Red Hat que se tem disponível.

Primeiro, o que gerou esta motivação?

Acompanho a lista fedora-users-br e vi este email do Ricardo Vendramini: http://lists.fedoraproject.org/pipermail/br-users/2010-November/013615.html

Para reduzir o uso de banda, surgiu a ideia de se configurar um proxy squid. Quando uma máquina for se atualizar, ela baixa os pacotes e o squid os armazena em cache. Quando uma segunda máquina buscar esta mesma atualização, o squid irá entregar o arquivo do cache ao invés de baixar novamente, economizando tempo (rede interna provavelmente é mais rápida que Internet) e banda.

O problema: o yum tem uma lista de mirrors possíveis e, a cada vez, ele pode utilizar um mirror diferente da última. Com isso, o squid terá diversas cópias de um mesmo arquivo mas vindo de domínios diferentes. Assim, além de não reduzir o uso da banda (ideia inicial) ainda se ocupa espaço de disco do cache que poderia ser melhor utilizado com outros arquivos.

Solução? “Forçar” o yum a baixar sempre de um mesmo mirror.
Para isso, deve-se configurar os repositórios “updates” e “fedora” (assim tanto os updates como eventuais instalações de pacotes serão armazenados no cache do squid). Então, edite o arquivo “/etc/yum.repos.d/fedora-updates.repo“, comente a linha “mirrorlist” e descomente “baseurl“. Em “baseurl“, coloque o endereço de um dos mirrors. Como sugestão, estou utilizando o mirror da Universidade Federal do Paraná que normalmente é bem rápido para usuários no Brasil.

[updates]
name=Fedora $releasever – $basearch – Updates
failovermethod=priority
baseurl=http://fedora.c3sl.ufpr.br/linux/updates//$releasever/$basearch/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

Também deve-se editar o “/etc/yum.repos.d/fedora.repo“:

[fedora]
name=Fedora $releasever – $basearch
failovermethod=priority
baseurl=http://fedora.c3sl.ufpr.br/linux/releases/$releasever/Everything/$basearch/os/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

Repita o procedimento em todas as máquinas com Fedora na rede. Feito isto, basta utilizar novamente o comando “yum update” para que todas as instalações e atualizações venham sempre do mesmo mirror.

Outra ideia para melhorar o desempenho, desabilitar o uso do plugin “yum-presto”. O presto utiliza o conceito de deltarpm para reduzir o tamanho dos pacotes de atualização. O deltarpm é um diff binário entre duas versões de rpm. Basicamente você baixa somente a diferença entre duas versões de um mesmo pacote e não mais o pacote todo. Ex: é liberada uma atualização do OpenOffice onde apenas um arquivo foi modificado. Este arquivo tem 1 Mbyte enquanto o pacote todo tem 50. O deltarpm teria aproximadamente 1 Mbyte e se teria uma economia de 49 Mbytes de download. Veja um outro artigo que escrevi sobre o yum presto aqui.

Mas como desabilitar o yum-presto melhora o desempenho? Como você terá todos os pacotes (ou pelo menos os mais utilizados) no cache do squid, você não estará fazendo o download de um pacote grande, você estará utilizando uma cópia localizada no cache na rede interna. Assim, o download será rápido e não precisará de tempo para reconstruir os pacotes de atualização, o que normalmente leva alguns minutos. Só para reforçar, yum-presto economiza muito download, mas aumenta o tempo de atualização devido a reconstrução do pacote. Se o tempo de download é muito baixo (rede interna), provavelmente não compensa o tempo de reconstrução, por isso a sugestão de desabilitar o yum-presto.

E como fazer isso? Basta editar o arquivo “/etc/yum/pluginconf.d/presto.conf” e configurar “enabled=0“. Pronto, da próxima vez que utilizar o yum, o plugin presto não será carregado.

Nota: esta tabela foi traduzida de http://www.ice2o.com/bash_quick_ref.html

Como sei que esta pode ser uma dúvida para mais pessoas, resolvi publicar este mini artigo com o resumo da conversa.

Pergunta: tem algum comando rápido e fácil de unix pra dividir um arquivo em vários?
Resposta: split
Resposta: split -b 100M arquivo_origem destino
Resposta: vai quebrar o arquivo_origem em arquivos de 100 mbytes e o prefixo do nome será “destino”
Pergunta: tem como ser pela quantidade de linhas?
Resposta: split -l 100 arquivo_origem destino
Resposta: vai quebrar em arquivos de 100 linhas

Acho que pelo resumo do diálogo já é possível que se tenha uma ideia básica do funcionamento do comando split. Caso tenha mais dúvidas, consulte o help:

$ split --help

Usage: split [OPTION] [INPUT [PREFIX]]

Output fixed-size pieces of INPUT to PREFIXaa, PREFIXab, ...; default

size is 1000 lines, and default PREFIX is `x'.  With no INPUT, or when INPUT

is -, read standard input.

Mandatory arguments to long options are mandatory for short options too.

-a, --suffix-length=N   use suffixes of length N (default 2)

-b, --bytes=SIZE        put SIZE bytes per output file

-C, --line-bytes=SIZE   put at most SIZE bytes of lines per output file

-d, --numeric-suffixes  use numeric suffixes instead of alphabetic

-l, --lines=NUMBER      put NUMBER lines per output file

--verbose           print a diagnostic to standard error just

before each output file is opened

--help     display this help and exit

--version  output version information and exit

SIZE may have a multiplier suffix:

b 512, kB 1000, K 1024, MB 1000*1000, M 1024*1024,

GB 1000*1000*1000, G 1024*1024*1024, and so on for T, P, E, Z, Y.

Você gera um certificado SSL para colocar no seu webserver favorito (espero que seja o Apache, mas se não for, sem problemas), configura tudo corretamente e, quando o reinicia tem que digitar a passphrase? Ótimo, segurança sempre é bom né? Mas e se faltar energia (e o nobreak não der conta), ou se você precisar reiniciar o servidor remotamente e “esquecer” de ativar a console remota na máquina? Vai ter que ir fisicamente na máquina para digitar a passphrase para o Apache terminar de iniciar, certo?

Não! Para evitar isso execute (claro, depois de fazer um backup da sua key):

openssl rsa -in www.seudominio.com.br.key -out www.seudominio.com.br.key

Este comando deverá pedir a passphrase atual e então irá gerar um novo arquivo key, SEM passphrase. Ótimo para pessoas que não querem estar na frente de todos os servidores que tiverem que ser reiniciados :)

Otimizar uma distribuição Linux é uma tarefa que pode variar de simples, onde qualquer usuário acostumado com Linux poderá fazer, até o nível extremamente complicada, onde mesmo os experientes podem ter dores de cabeça.

Um método relativamente simples de otimizar o desempenho de uma distribuição é desabilitando serviços não utilizados.

No Fedora, podemos utilizar a ferramenta “system-config-services” para isso:

Tela do system-config-services no Fedora 8

Nesta ferramenta, basta desmarcar os serviços que não precisamos, salvar as alterações e no próximo boot o Fedora não irá mais carregar estes serviços, diminuindo com isso o tempo de boot e liberando recursos, como memória e ciclos de cpu.

Uma dica é manter apenas os serviços realmente necessários, de acordo com o uso da máquina (notebook, desktop, servidor, etc).

Para meu Desktop, mantenho apenas os serviços ConsoleKit, acpid, auditd, avahi-daemon, cpuspeed, haldaemon, messagebus, network, nvidia-96xx, restorecond, rsyslog, setroubleshoot, udev-post e yum-updatesd. Sei que poderia desabilitar mais alguns, mas os mantive para manter certas facilidades no Desktop (ConsoleKit, para manter a troca rápida de usuário, e yum-updatesd, para me avisar de atualizações). Aqui tem uma lista, em inglês, com explicações sobre boa parte dos serviços disponíveis para o Fedora 8 (sugestão de link enviada por Paulo Cavalcanti, da lista fedora-users-br).

Como sou aficcionado por segurança, também mantenho o SELinux habilitado, mas caso não utilizasse, também não iria precisar dos serviços setroubleshoot e restorecond. Desabilitar o SELinux em um Desktop não torna a máquina vulnerável, apenas diminui um pouco a segurança (para uso doméstico muita segurança pode ser paranóia, é o meu caso). Desabilitar o SELinux também melhora o desempenho da máquina pois o kernel não precisa fazer diversas verificações que o SELinux exige.

Para desabilitar o SELinux, edite o arquivo /etc/sysconfig/selinux e mude a linha que contém SELINUX para SELINUX=disabled e reinicie a máquina.

Para facilitar a vida do usuário, o Fedora também carrega alguns programas automaticamente junto ao Gnome ou KDE, como exemplo, gerenciador para dispositivos Bluetooth. No Gnome, você pode utilizar o Gerenciador de Sessões para desabilitar esses serviços.

Gerenciador de Sessões do Gnome no Fedora 8

Para acessar o Gerenciador de Sessões, vá no menu Sistema, Preferências, Pessoal e Sessões.

Nele, desabilite o que não utilizar. Aqui eu desabilitei somente o Gerenciador Bluetooth mas se não usasse o SELinux e o setroubleshoot não iria precisar do SELinux Troubleshooter também. Caso tivesse desabilitado o yum-updatesd, também poderia desabilitar o Notificador de Atualização de Programas.

Desabilitando alguns desses serviços, o Gnome irá iniciar mais rapidamente e também irá utilizar menos recursos da máquina.

Ainda no Desktop, podemos parar de utilizar os Efeitos 3D. Eles são bonitos, impressionam quem vê, mas ocupam muitos recursos da máquina. Para desabilitar, basta entrar no menu Sistema, Preferências, Visual e Comportamento e Efeitos da Área de Trabalho e “desclicar” o botão Habilitar Efeitos da Área de Trabalho.

Para quem gosta de se aventurar um pouco mais (ou de economizar alguns kbytes extras), ainda pode-se desabilitar os terminais virtuais do console (ou modo texto, como queiram). Para isso, basta editar o arquivo /etc/inittab, e comentar (adicionar um “#” no começo) as linhas dos ttys (as que contém 6:2345:respawn:/sbin/mingetty tty1) e executar o comando init -q. Normalmente eu mantenho somente 2 ttys ativos (comento do 3 ao 6) e com isso eu economizo uns 400Kbytes por tty desabilitado.

Pode-se obter algum desempenho extra alterando alguns parâmetros no sistema de arquivos Ext3, editando os scripts de inicialização, recompilando alguns pacotes … mas isto ficará pra um próximo artigo :)

Todos os exemplos daqui podem ser testados bastando apenas salvar o arquivo em formato ASCII (pode-se usar qualquer editor de texto para isso, vi ou emacs por exemplo) e dar a permissão de execução ao arquivo do script (com chmod u+x nome-do-script).

A essência da programação em scripts pode ser resumida em saber lidar bem com pipes (se pronuncia páipes), redirecionamentos e pouco mais que uma dúzia de comandos.

Eu pretendo com este (futuro) conjunto de textos passar um exemplo simples e explicar os detalhes dele seja novos comandos ou mesmo o porque de um redirecionamento ao invés de um pipe. Além disso, pretendo explicar alguns conceitos como por exemplo como fazer um laço num script e etc.

O uso de Pipes No primeiro exemplo, vamos ver um script que simplesmente conta quantos são os usuários cadastrados no sistema.

#!/bin/bash
cat /etc/passwd |wc -l

A primeira linha (#!/bin/bash) apenas informa ao sistema qual shell usar e a segunda, lê o arquivo com informações do usuário e repassa estas informações por pipe para o comando wc -l, que apenas conta o número de linhas recebidas pela entrada padrão (stdin).

O pipe nada mais é que o símbolo | e este faz com que tudo o que for saída padrão (stdout) do comando antes do pipe seja repassado para a entrada padrão do comando após o pipe. O comando cat neste exemplo irá direcionar o conteúdo do arquivo /etc/passwd para sua saída padrão (este arquivo nada mais é do que o banco de dados de usuários de um sistema Unix e cada usuário é representado por exatamente uma linha deste arquivo). Sabendo que cada usuário ocupa uma linha, basta contarmos quantas linhas tem este arquivo para sabermos quantos usuários o sistema possui. É aí que o comando wc entra. Com o parâmetro -l, wc conta o número de linhas recebidas resultando neste caso no número de usuários do sistema. Simples não ?

Após salvarmos o arquivo (que vou chamar de script.sh), damos a permissão de execução para o arquivo com chmod u+x script.sh e o executamos com ./script.sh. A saída dele deve ser apenas um número, como 35.

Aqui começam os problemas: você sabe que existem 35 usuários no sistema, mas e o seu chefe (aquele mesmo que tem dificuldade até para mudar o papel de parede daquele sistema operacional), ele vai saber o que este número sem lógica significa ?

Expansão de comandos Agora que já vimos como usar pipes, vamos começar a deixar nossos scripts mais amigáveis.

#!/bin/bash
echo “Existem `cat /etc/passwd |wc -l` usuarios no sistema”

Neste exemplo, usamos o comando echo que simplesmente irá ecoar tudo o que estiver entre as aspas para a saída padrão mas, antes disso, o bash irá executar os comandos entre as crases e retornar para o echo a saída do comando. O echo vai receber entre as aspas algo como Existem 35 usuarios no sistema e irá ecoar isso (agora o seu chefe vai saber o que o seu script faz !).

Trabalhando com variáveis Nosso pequeno script até agora apenas executa comandos, ele não armazena informação alguma. Se precisarmos do número de usuários cadastrados no sistema em algum outro momento, teremos que executar os comandos novamente ou podemos armazenar o resultado dele em uma variável:

#!/bin/bash
tmp=`cat /etc/passwd | wc -l`
echo “Existem $tmp usuarios no sistema”

No exemplo anterior, armazenamos o número de usuários do sistema numa variável chamada tmp e a passamos como parâmetro para o echo (o shell expande as variáveis antes de executar o comando, neste exemplo a variável foi tratada pelo shell como se o próprio comando entre crases tivesse sido executado novamente, mas isto não foi preciso pois o shell “lembrou” do resultado da última execução). O shell sabe que é uma variável porque colocamos um $ antes do nome dela.

Trabalhando com laços para (for) Podemos incrementar nosso script fazendo, por exemplo, ele contar quantas vezes um usuário conectou ao sistema. Neste caso, usaremos o comando last, que retorna todos os logins que obtiveram sucesso no sistema desde a instalação do mesmo (ou desde que o log foi rotacionado pela última vez) e o comando cut, que serve para cortar parte de uma linha:

#!/bin/bash
for user in `cat /etc/passwd|cut -d “:” -f 1`;do
cont=`last|grep $user|wc -l`
echo “usuario $user conectou $cont vezes”
done

Explicando com detalhes: o cut recebe cada linha do comando cat e retorna apenas o primeiro campo (-f 1) usando “:” como separador de campos (se você executar apenas cat /etc/passwd poderá observar que o primeiro campo corresponder ao nome dos usuários no sistema). O for construído desta maneira, irá montar um vetor (referenciado pela variável user ) onde cada posição contém o nome de um usuário do sistema. Além disso, cada passo do laço será exatamente o nome de um usuário.

Dentro do laço, a variável count receberá a saída da execução do comando last (para obter uma lista de todo mundo que se logou no sistema) passando a saída por pipe para grep (onde iremos filtrar para mostrar apenas as linhas com o usu&aaute;rio user) e finalmente irá repassar, também por pipe, para wc (onde iremos contar quantas linhas aparece o nome do usuário, ou seja, quantas vezes ele se logou no sistema).

Ainda no laço, iremos ecoar o nome do usuário que estamos lendo da lista naquele momento e a valor atual de cont. Para finalizar o laço, usamos done.i

Testes de condições (if / else) No script anterior, vimos que vários usuários se conectaram 0 vezes ao sistema. A maioria deles é usuário do sistema que nunca terá login algum (se tiver, é bom se analisar o motivo, pode ser alguma falha de segurança sendo explorada).

Mas e se eu não quiser mostrar quem nunca se conectou ? Poderíamos apenas fazer um teste para ver se a variável cont esta com valor 0 e, se não estiver, imprimimos a mensagem.

#!/bin/bash
for user in `cat /etc/passwd|cut -d “:” -f 1`;do
cont=`last|grep $user|wc -l`
if [ $cont -ne 0 ]; then
echo “usuario $user conectou $cont vezes”
fi
done

Neste script, adicionamos o teste se (if) onde verificamos se a variável cont é diferente ( -ne, not equal) de zero. Se for diferente, o script executa o bloco entre o if e o fi (fi finaliza um bloco if) e a mensagem informando o número de logins do usuário será mostrada.

Além disso, poderíamos colocar uma mensagem informando que o usuário nunca se logou ao sistema (ao invés de informar que ele se logou zero vezes).

#!/bin/bash
for user in `cat /etc/passwd|cut -d “:” -f 1`;do
cont=`last|grep $user|wc -l`
if [ $cont -eq 0 ]; then
echo “usuario $user nunca conectou ao sistema”
else
echo “usuario $user conectou $cont vezes”
fi
done

Neste exemplo, mudamos o teste para se igual (-eq, equal) a zero, então mostre a mensagem e adicionamos um senão ( else), mostre outra mensagem.

Este tutorial não pretende ser um guia completo para uma configuração avançada
de Squid, ele apenas vai mostrar como fazer algumas configurações simples mas
que permitirão que se tenha um servidor atuando como gateway de uma rede
fazendo cache de http.

Algumas convenções usadas neste tutorial:

Sempre que uma linha começar com um “#”, significa que ela contém um (ou
mais)
comando(s) e que ela deverá ser executada como usuário root.

Sempre que uma linha começar com um “$”, significa que ela contém um (ou
mais)
comando(s) e que ela deverá ser executada como qualquer usuário, comum ou
root.

O que é um servidor proxy ?

Podemos resumir o significado de servidor proxy como uma espécie de “cache
comunitário”, onde toda página que um usuário visualizar ficará armazenada e
quando outro (ou o mesmo) usuário requisitar a mesma página, ela não será
trazida da Internet novamente, simplesmente será lida do disco e entregue,
economizando tráfego de rede (isso se a página não tiver sido modificada na
origem, caso isto tenha acontecido, ela será trazida da Internet novamente).
Um proxy pode, além disso, fazer o controle de conteúdo, barrando o acesso a
certos sites, por exemplo.

O que é o Squid ?

Squid nada mais é que um software para servidor proxy que vem na maioria das
distribuições Linux.

Como sei se o Squid está instalado na minha máquina ?

Se seu Linux for RedHat ou equivalente (Fedora, Conectiva, etc), digite num
terminal:

$rpm -q squid

Se a resposta for algo do tipo: squid-2.4.STABLE7-4 significa que você tem o
Squid instalado na sua máquina.

Se a resposta for algo do tipo: package squid is not installed significa que
você não tem o Squid instalado na sua máquina e terá que instalá-lo.

Não tenho Squid instalado na máquina, como instalar ?

Para RedHat ou equivalente, o meio mais fácil é acessar http://rpmfind.net,
fazer uma busca por “squid”, encontrar a versão disponível para sua
distribuição, baixar e executar:
#rpm -ivh squid*

(para um RedHat 8.0, o download direto é
ftp://rpmfind.net/linux/redhat/8.0/en/os/i386/RedHat/RPMS/squid-2.4.STABLE7-4.i386.rpm)

Neste passo, pode acontecer do sistema reclamar da falta de algum pacote,
neste caso, copie o nome de cada arquivo que foi reclamado, volte ao
rpmfind.net e faça uma busca por este arquivo, baixe o pacote rpm que o
contém,
instale e refaça este passo até que não tenhamos mais pendências.

Para facilitar a vida, pode usar o apt (http://apt.freshrpms.net).
Com ele instalado, simplesmente execute:
#apt-get update
#apt-get install squid

Com isto, você terá a última versão do squid instalada no seu sistema e
todas
as dependências terão sido resolvidas “automagicamente” :)

Como configurar minha máquina para atuar como gateway da rede ?

A primeira coisa a fazer, é permitir que todos os pacotes possam ser
reencaminhados (forward de pacotes) pela máquina:

#echo 1 > /proc/sys/net/ipv4/ip_forward Ou, numa maneira mais “elegante”:
#sysctl -w net.ipv4.ip_forward=1

Após um boot, esta configuração se perde, para torná-la permanente, coloque
este comando para ser executado após cada boot (pode colocar, por exemplo, no
final do /etc/rc.d/rc.local) ou, numa maneira mais “elegante”, edite
/etc/sysctl.conf e procure por “net.ipv4.ip_forward = 0″, substitua o “0″ por
“1″ e esta alteração já estará permanente. Após isto, configure o gateway das
estações para apontar para o IP desta máquina. Se as estações navegarem
normalmente, seu gateway está funcionando :)

Como configurar o Squid ?

A configuração do Squid, por padrão é toda feita dentro do arquivo
/etc/squid/squid.conf. Tudo o que for exemplificado nesta seção estará neste
arquivo.
As principais alterações a serem feitas para o Squid atuar como proxy
transparente, são:

Descomentar (eu digitar) as linhas (no arquivo original, do RedHat 8, estão
próximas a linha 1680 do squid.conf. Para se deslocar até esta linha, no
“vi”, digite “:1680″ no modo de comandos.):
httpd_accel_port 80
httpd_accel_host virtual
httpd_accel_uses_host_header on
httpd_accel_with_proxy on

Além disso, é bom colocarmos alguma segurança no proxy, algo para evitar que
pessoas de outras redes acessem nosso servidor, consumindo nossa banda.
Próximo a linha 1460 estão definidas as “acls” (Access Control List). Nelas
definimos algumas regras que posteriormente serão usadas para liberar ou
bloquear acesso.
Ex:
acl minharede src 192.168.0.0/255.255.255.0
acl minhamaquina src 192.168.0.1/255.255.255.255
acl umsite dstdomain .sitequalquer.com.br

Aqui criamos três acls, uma para a rede, outra para uma máquina e por
último,
uma para um site qualquer.
Usamos o comando “http_access” para negar ou permitir o acesso a uma rede.
Por padrão, o Squid já vem com uma acl para todas as redes do mundo
(acl all src 0.0.0.0/0.0.0.0) e nega o acesso desta rede ao nosso proxy
(http_access deny all).
Vamos supor que na nossa rede (acl minharede), todo mundo pode navegar em
qualquer site, exceto em “sitequalquer.com.br”, mas uma máquina desta rede
(acl minhamaquina) poderá navegar em qualquer site, inclusive em
sitequalquer.com.br.
Teríamos que colocar as regras da seguinte maneira:
http_access allow minhamaquina
http_access deny umsite
http_access allow minharede
http_access deny all
Observe que “deny all” sempre terá que ser por último.
O Squid por padrão, vai seguindo as regras uma a uma, até encontrar uma
regra
que satisfaça sua condição, aí ele permite ou não o acesso, dependendo do
que
foi colocado em http_access.
Por exemplo, se eu estiver na máquina com IP 192.168.0.1 e quiser acessar
qualquer site, o Squid irá ler a primeira regra e verá que este IP pertence
a acl “minhamaquina” e existe uma regra “allow minhamaquina”, então ele
permitirá o acesso a qualquer site.
Se eu estivesse numa máquina com IP 192.168.0.2 e quisesse acessar um site
A,
o Squid irá ler a primeira regra e verá que esta máquina não pertence a
“minhamaquina”, lerá a segunda regra e verá que o site A não tem o domínio
de
destino (dstdomain) igual a “sitequalquer.com.br”, então por fim irá ler a
última regra e verá que este IP pertence a “minharede” e que ele está
autorizado (allow) a navegar.
Se esta mesma máquina tentasse acessar “sitequalquer.com.br”, o Squid iria
bloquear o acesso na segunda regra, pois existe um “deny umsite”.
Se qualquer máquina fora da rede 192.168.0.0/24 tentasse acessar este proxy,
o acesso seria negado devido a última regra ser “deny all”.

Como configurar o sistema para fazer Proxy transparente ?

Tendo configurados o Squid e o reencaminhamento de pacotes, precisamos apenas
fazer com que todos os pacotes que chegam ao gateway pela porta 80 sejam
redirecionados para a porta 3128 (a porta padrão do Squid). Para isto, vamos
usar uma regra de firewall extremamente simples:

#iptables -t nat -A PREROUTING -i eth0 -p tcp –dport 80 -j REDIRECT
–to-port 3128

Esta regra simplesmente faz com que todo o tráfego da porta 80 (http padrão) e
que vier pela interface eth0, seja redirecionado para o Squid (porta 3128).

Para deixar esta regra permanente, adicione no final de /etc/rc.d/rc.local (ou
crie um /etc/rc.d/rc.firewall, adicione todas as regras de firewall que tiver
nele e adicione apenas uma chamada a este arquivo em /etc/rc.d/rc.local, na
prática terá o mesmo efeito, mas ficará muito mais “legível” :)

Qualquer dúvida ou problema, entre em contato comigo.

Parte do que escrevi aqui foi baseado no documento Release Notes do Fedora Core 6, onde obtive links e alguns detalhes sobre algumas ferramentas.

Resumo: Minha avaliação foi bastante positiva, tanto que já migrei meu notebook e meu desktop para a nova versão do Fedora (ok, já usava o Fedora Core 5, uma migração dessas é menos traumática). No Desktop eu fiz a instalação “do zero”, formatei a partição e instalei o Linux. No notebook, atualizei utilizando o yum (onde aproveitei e escrevi este tutorial). Recomendo a migração para quem já usa outra versão do Fedora e recomendo um teste para quem usar outra distribuição de Linux.

O primeiro ponto que me chamou a atenção já foi durante a instalação. O anaconda (nome do instalador) está com suporte a repositórios rpm. Agora é possível escolher pacotes que estão no Extras ou mesmo adicionar outro repositório manualmente, como o livna por exemplo.

Outra ponto que chamou a atenção foi a mudança da fonte padrão do sistema, desde o instalador até o Gnome, para o DejaVu. Na minha opinião, ficou bem mais legível, principalmente no notebook.

Assim que comecei a usar, fui verificar coisas óbvias, como a tradução que, apesar de ter algumas ferramentas que ficaram sem tradução, ficou melhor que nas outras versões. Isso provavelmente foi devido a um maior comprometimento da comunidade seja traduzindo ou revisando traduções (sugiro aos interessados participar da lista de tradução do Fedora).

Outro ponto que mostra um comprometimento maior é quando se fala dos repositórios não oficiais do Fedora. Os três principais (livna, atrpms e freshrpms) já suportavam a versão nova no máximo 24 horas após o anuncio oficial do lançamento.

Algo que foi pedido e foi atendido é o applet que avisa quando tem updates novos (a tela abaixo eu capturei na versão test 3, não teve tanta atualização assim na versão final ainda :)

Outro ponto que foi bastante melhorado é a granularidade das dependências. Na versão anterior do Fedora, não era possível instalar o evince sem instalar o nautilus, bem como instalar o beagle sem o evolution e também instalar o NetworkManager sem o bind e o caching-nameserver.

No meu notebook de trabalho (um Dell Inspiron 5100) eu vi pela primeira vez um Linux com suspender/hibernar funcionar “de fábrica” ! Qualquer outro Linux que já testei eu tive que configurar algo. Em alguns aplicar patches, em outros mudar arquivos de configuração para buscar o parametro correto. Mas nesta versão do Fedora, funcionou sem ter que alterar nada.

Se sua placa de video for compatível (este artigo tem uma tabela com fabricantes e modelos de placas compatíveis) e tiver com o driver instalado, basta clicar num botão para ter o AIGLX funcionando. Muito mais simples que instalar vários pacotes e executar vários comandos, como foi o XGL.

O system-config-printer foi reescrito para suportar o CUPS 1.2. Além de ter ficado bem mais rápido, ficou mais intuitivo configurar uma impressora.

Na administração do sistema, o Fedora agora tem o virt-manager que é uma interface gráfica para gerenciar o XEN. Como não uso o XEN, não vou entrar em detalhes aqui. Ainda na administração, agora o sistema dispõe de um gerenciador gráfico para o LVM (Logical Volume Manager) onde com poucos cliques se pode verificar/modificar o seu arranjo de volumes lógicos.

Na segurança do sistema, o Fedora agora dispõe do setroubleshoot que é uma ferramenta gráfica para analisar logs do SELinux. Muitos administradores acabavam desabilitando o SELinux por não saber lidar com ele. O setroubleshoot informa qual aplicação gerou erro, porque gerou o erro e como fazer para que o erro não aconteça mais, se isso for desejável. Dan Walsh escreveu um artigo que mostra o funcionamento desta ferramenta. Vale lembrar que o que ela faz já era possível fazer antes, mas em modo texto, usando as ferramentas audit2why e audit2allow.

Para quem gosta ou está acostumado a usar o sudo, o Fedora traz um arquivo /etc/sudoers muito bem preconfigurado com sugestões para restrições de comandos administrativos.

Algo que gostei foi ver o GnuCash ter voltado para o Core da distribuição. É uma ferramenta boa para gerenciar finanças, vale a pena conhecer. Outra mudança foi o Mozilla não ser mais incluído no Core (e nem no Extras). No Core ele foi substituído pelo Firefox e pelo Thunderbird mas, para quem preferir a suíte completa, o SeaMonkey está no Extras pronto para ser instalado pelo yum.

Para finalizar, vou escrever sobre o desempenho do sistema. O Fedora inicializa aplicações até 50% mais rápido devido ao uso do DT_GNU_HASH. Na prática, observei grande melhoria, mas não posso afirmar que chegou a 50%, só posso afirmar que o OpenOffice agora está abrindo num tempo aceitável. O sistema parece responder melhor que versões anteriores, os menus abrem mais rápido. Provavelmente devido a nova versão do Gnome (não vi em nenhum lugar citando o motivo disto). O uso de memória ram está um pouco mais baixo que na versão anterior (isto realmente é devido ao Gnome) e finalmente, um ponto que muitos reclamaram, o parser xml do yum foi otimizado e agora está bem mais rápido utilizar o yum.

Concluindo: valeu a pena atualizar o sistema e recomendo esta atualização para quem já usa outras versões de Fedora. Quem está mais acostumado com outros Linux, pode não gostar do jeito fácil de configurar as coisas no Fedora, são várias ferramentas que auxiliam o processo graficamente. Mesmo assim eu recomendo fazer um teste nesta versão do Fedora. Quem sabe você não muda de opinião e migra para esta distribuição ? ; )

Yum-presto é um plugin para o yum que, quando disponível, utiliza deltarpms ao invés de rpms. Isto permite que os downloads de atualizações sejam muito menores do que se tivesse utilizando somente pacotes rpms.

Um Deltarpm é a diferença entre dois arquivos rpms. Por exemplo, se você tem o pacote-1.0 instalado e existe uma atualização chamada pacote-1.1, o yum-presto irá fazer o download do deltarpm pacote-1.0 => pacote-1.1 ao invés de baixar o rpm completo do pacote-1.1. Então, ele irá reconstruir o pacote-1.1 usando o pacote-1.0, que você já tem instalado, e o deltarpm que acabou de baixar.

Quando o yum-presto está sendo utilizado, ele mostra quanto se economizou de download ao final de uma atualização sendo que, nos meus testes, normalmente economizo entre 30% e 70% no tamanho do download dos pacotes. Isto varia dependendo do tamanho dos pacotes (quando maior um pacote original, maiores as chances de economizar) e do próprio pacote instalado. A imagem abaixo mostra que fiz o download de 3.9 MB e que sem utilizar o yum-presto teria que fazer o download de 23 MB, uma economia de 84% !

A instalação do yum-presto no Fedora 7 é simples. Para isso, basta executar como root:

# yum install yum-presto

Neste comando, o yum irá baixar o yum-presto e todas as dependências necessárias (normalmente só o pacote deltarpm).

Após este passo, deve-se configurar o uso de deltarpms nos repositórios do yum. Para o Fedora 7, basta adicionar deltaurl=http://lesloueizeh.com/f7/i386/updates no bloco corresponde ao repositório updates, que fica no arquivo /etc/yum.repos.d/fedora-updates.repo. Abaixo, como ficou a configuração no repositório updates:

# cat /etc/yum.repos.d/fedora-updates.repo
[updates]
name=Fedora $releasever – $basearch – Updates
#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/updates/$releasever/$basearch/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora
deltaurl=http://lesloueizeh.com/f7/i386/updates

Também existe suporte para a arquitetura x86_64. Basta alterar a deltaurl para deltaurl=http://lesloueizeh.com/f7/x86_64/updates (agradecimentos a Jonathan Dieter pela informação).

Caso sua versão do Fedora seja o Core 6, o procedimento é o mesmo do Fedora 7, exceto que a deltaurl a ser adicionada é deltaurl=http://lesloueizeh.com/fc6/i386/updates.

Após ter salvo este arquivo, qualquer atualização que for feita utilizando o yum irá automaticamente utilizar os pacotes deltarpm disponíveis ao invés dos pacotes completos ocasionando assim uma boa economia no tempo e tamanho dos seus downloads.

Caso não queira utilizar o plugin temporariamente, basta utilizar o parâmetro –disablepresto na linha de comandos do yum, assim:

# yum update –disablepresto

Ou ainda, se não for utilizar o yum-presto por um tempo maior, desabilite o plugin diretamente no seu arquivo de configuração. Para isto, basta editar o arquivo /etc/yum/pluginconf.d/presto.conf e mudar a linha enabled=1 para enabled=0. Assim, o yum-presto só irá funcionar quando retornar esta configuração para o valor original.

O yum-presto também pode ser utilizado em outras distribuições, desde que elas utilizem o yum como ferramenta de atualização. Abaixo, segue como instalar o yum-presto no CentOS 5 (escrito usando este post como base):

# cd /etc/yum.repos.d
# wget http://www.lesbg.com/jdieter/presto/presto-centos.repo
# yum install yum-presto

A configuração é semelhante ao Fedora 7, mudando apenas o nome do arquivo do repositório para /etc/yum.repos.d/CentOS-Base.repo e a linha informando onde estão os deltarpms, que é deltaurl=http://lesloueizeh.com/centos5/i386/updates. O arquivo do repositório no CentOS 5 ficou assim:

# cat /etc/yum.repos.d/CentOS-Base.repo
[updates]
name=CentOS-$releasever – Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
deltaurl=http://lesloueizeh.com/centos5/i386/updates
gpgcheck=1
gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

Para concluir, venho utilizando o yum-presto praticamente desde o lançamento e não tive nenhum tipo de problema com ele. Alias, recomendo sua utilização para todos que tem como distribuição o Fedora e/ou o CentOS.