[FUG-BR] RES: tproxy/cacheboy
Eduardo Schoedler
eschoedler em viavale.com.br
Sexta Julho 10 10:36:15 BRT 2009
Aproveitando a discussão...
Como eu faço para criar as regras de 'fwd' no IPFW e também usar o dummynet
para controlar banda dos clientes ???
Segundo o site do patch do tproxy para freebsd [1], são necessárias algumas
regrinhas para que funcione.
ipfw add fwd 200.200.200.1,3128 tcp from 200.200.200.0/24 to any 80 in via
em0
ipfw add fwd 200.200.200.1 tcp from any 80 to 200.200.200.0/24 in via fxp0
Até onde eu sei, se eu colocar uma regra de pipe antes dessas do tproxy,
elas nem vão ser executadas.
Também sei que existe um parâmetro no kernel que muda o funcionamento do
ipfw, fazendo com que o pacote continue percorrendo as demais regras mesmo
depois de um match.
Pergunto? Bastaria setar esse parâmetro (net.inet.ip.fw.one_pass) para zero
?
Funcionaria o exemplo abaixo:
ipfw pipe delete 1
ipfw pipe 1 config buckets 256 bw 500Kbit/s mask src-ip 0xffffffff
ipfw add pipe 1 ip from 200.xxx.xxx.0/24 to any in via em0
ipfw pipe delete 2
ipfw pipe 2 config buckets 256 bw 1Mbit/s mask dst-ip 0xffffffff
ipfw add pipe 2 ip from any to 200.xxx.xxx.0/24 out via em0
// Exemplo do Tproxy
ipfw add fwd 200.200.200.1,3128 tcp from 200.200.200.0/24 to any 80 in via
em0
ipfw add fwd 200.200.200.1 tcp from any 80 to 200.200.200.0/24 in via fxp0
// Algumas regras de NAT ==> podem atrabalhar?
ipfw -q add divert natd all from 192.168.1.0/24 to any out via fxp0
Obrigado !!!
[1] http://tproxy.no-ip.org/
----- Original Message -----
From: "Daniel Menezes" <dm em viavale.com.br>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
<freebsd em fug.com.br>
Sent: Thursday, July 09, 2009 4:16 PM
Subject: Re: [FUG-BR] RES: tproxy/cacheboy
Em AMD64 é possível setar o cache_mem para mais de 4GB RAM, a limitação era
no x86.
Sds,
Daniel
----- Original Message -----
From: "Renato Frederick" <frederick em dahype.org>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
<freebsd em fug.com.br>
Sent: Tuesday, July 07, 2009 4:15 PM
Subject: [FUG-BR] RES: tproxy/cacheboy
Creio que deva ser limitacao do Squid 32bits, tente compilar em 64bits.
> -----Mensagem original-----
> De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> nome de Daniel Menezes
> Enviada em: terça-feira, 7 de julho de 2009 15:47
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] tproxy/cacheboy
>
> Renato.
>
> Consegui instalar seguindo suas dicas, obrigado.
>
> Aproveitando, surgiu uma dúvida, tenho uma máquina com 8GB RAM
> compilados
> via PAE.
> Tentei colocar um cache_mem de 6GB [6000 MB] e ele não aceitou,
> acredito ser
> uma limitação da plataforma x86 que instalei.
>
> Pergunto, se reinstalasse em AMD64, o Squid consegueria alocar os 6GB
> ou
> esta limitação é do prórpio Squid?
>
> Att,
> Daniel
> ----- Original Message -----
> From: "Renato Frederick" <frederick em dahype.org>
> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> <freebsd em fug.com.br>
> Sent: Tuesday, July 07, 2009 11:49 AM
> Subject: [FUG-BR] RES: RES: RES: RES: RES: RES: tproxy/cacheboy
>
>
> Squid Versao 3.0.
>
> Verifique o hardware e o tunning, como falei o tproxy é bastante
> exigente
> quanto aos recursos de máquina, o 'salto' que os gráficos de
> CPU/memória/io
> dão quando ele ativo para mim foram marcantes.
>
> Não custa lembrar, verificar se o I/O do disco está OK, já tive
> cenários em
> que o RAID aplicado a partição do squid era muito lento, ou ainda se
> fazia
> raid via software com discos IDE...
>
> Sobre o squid, no meu ultimo csup, que levou o port do WWW/squid30
> para
> squid-3.0.16 o patch freebsd-tproxy-squid.patch falhava para aplicar
> patch
> ao src/http.cc
>
> Resolvi da seguinte maneira:
>
> Apliquei o patch freebsd-tproxy-port.patch no port www/squid30(este
> patch
> serve para alterar o Makefile e aparecer a opção TPROXY no make config.
>
> Dei um make config e marquei TPROXY,
> Dei um make extract
>
> Editei o makefile e comentei a linha
>
> EXTRA_PATCHES+= ${PATCHDIR}/freebsd-tproxy-squid.patch para
> evitar
> que o patch fosse aplicado ao squid.
>
> Apliquei o patch freebsd-tproxy-squid.patch manualmente em
> /usr/ports/www/squid30/work/squid-3.0.STABLE16
>
> Daí make install.
>
> O squid foi compilado normalmente com o tproxy ativo.
>
> Estou sem tempo algum, mas arrumar este pequeno detalhe não deve ser
> complicado. Talvez seja até ordem que os patchs são aplicados, já que o
> .rej
> volta algumas linhas erradas só, de um "||"
>
>
>
>
>
> > -----Mensagem original-----
> > De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br] Em
> > nome de Daniel Menezes
> > Enviada em: terça-feira, 7 de julho de 2009 11:38
> > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > Assunto: Re: [FUG-BR] RES: RES: RES: RES: RES: tproxy/cacheboy
> >
> > Renato
> >
> > Fiz testes com o cacheboy 1.6 e lusca-head, ambos funcionaram porém
> > notei
> > lentidão para navegar.
> > Pode ser a máquina ou tunning, não sei, preciso testar as
> > possibilidades.
> >
> > Ainda não consegui instalar o squid 3.0, conforme o howto em
> > http://tproxy.no-ip.org/.
> > Sabe dizer qual é a versão exata naquela instalação? No meu ports
> está
> > a
> > 3.0.16.
> >
> > Segue o erro nesta versão:
> >
> > make all
> > ===> Vulnerability check disabled, database not found
> > ===> Found saved configuration for squid-3.0.16
> > ===> Extracting for squid-3.0.16
> > => MD5 Checksum OK for squid3.0/squid-3.0.STABLE16.tar.bz2.
> > => SHA256 Checksum OK for squid3.0/squid-3.0.STABLE16.tar.bz2.
> > => MD5 Checksum OK for squid3.0/b9052.patch.
> > => SHA256 Checksum OK for squid3.0/b9052.patch.
> > ===> squid-3.0.16 depends on file: /usr/local/bin/perl5.8.9 - found
> > ===> Patching for squid-3.0.16
> > ===> squid-3.0.16 depends on file: /usr/local/bin/perl5.8.9 - found
> > ===> Applying distribution patches for squid-3.0.16
> > ===> Applying extra patch
> > /usr/ports/www/squid30/files/freebsd-tproxy-squid.patch
> > 1 out of 1 hunks failed--saving rejects to src/http.cc.rej
> > *** Error code 1
> >
> > Stop in /usr/ports/www/squid30.
> > *** Error code 1
> >
> > Stop in /usr/ports/www/squid30.
> >
> > ----------------
> >
> > cat http.cc.rej
> >
> > ***************
> > *** 1167,1173 ****
> >
> > comm_remove_close_handler(fd, httpStateFree, this);
> > fwd->unregister(fd);
> > - #if LINUX_TPROXY
> >
> > if (orig_request->flags.tproxy)
> > client_addr = &orig_request->client_addr;
> > --- 1167,1173 ----
> >
> > comm_remove_close_handler(fd, httpStateFree, this);
> > fwd->unregister(fd);
> > + #if LINUX_TPROXY || BSD_TPROXY
> >
> > if (orig_request->flags.tproxy)
> > client_addr = &orig_request->client_addr;
> >
> > abraços,
> > Daniel
> >
> > ----- Original Message -----
> > From: "Renato Frederick" <frederick em dahype.org>
> > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> > <freebsd em fug.com.br>
> > Sent: Monday, July 06, 2009 3:57 PM
> > Subject: [FUG-BR] RES: RES: RES: RES: RES: tproxy/cacheboy
> >
> >
> > A mensagem não sei.
> >
> > Mas tente usar o squid 3.0 e veja se a mensagem desaparece. Como se
> vê
> > o
> > lusca tem alguns bugs :(
> >
> > A lentidão você pode ter porque o servidor é bem mais exigido, afinal
> > todas
> > as conexões são 'spoofadas' pelo freebsd. Se você tiver 800 conexoes
> á
> > porta
> > 80 vinda dos clientes, o bsd terá que abrir 800 conexoes fake, passar
> > pelo
> > ipfw e por fim jogar ao Mac apropriado na rede.
> >
> > Dando continuidade ao meu problema, até agora, com squid 3.0 não
> obtive
> > mais
> > os problemas relatados, com apeox. 1515 conexoes.
> >
> >
> >
> > #sockstat | grep squid | wc
> > 1515 3605 38651
> >
> > Mas já dá para sentir que o squid consome mais recursos que o lusca.
> >
> > Aproveitando, tentei rodar o 'thundercache' em outro squid, mas ele
> > também
> > não gostou muito da idéia, até faz cachê de youtube a afins, mas do
> > nada o
> > loader.php morre e os downloads se interrompem ao fim.
> >
> >
> > Vi no Google dizendo que tem alguns problemas com freebsd, mandei
> email
> > pro
> > autor, mas se alguém souber...
> >
> > Creio que tproxy+thundercache economizaria banda enorme.
> >
> >
> > Abraços.
> >
> >
> >
> > > -----Mensagem original-----
> > > De: freebsd-bounces em fug.com.br [mailto:freebsd-bounces em fug.com.br]
> Em
> > > nome de Daniel Menezes
> > > Enviada em: segunda-feira, 6 de julho de 2009 15:14
> > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > Assunto: Re: [FUG-BR] RES: RES: RES: RES: tproxy/cacheboy
> > >
> > > Obrigado pela ajuda, consegui levantar o tproxy + cacheboy 1.6 no
> 7.2
> > > STABLE.
> > > Usei também o site http://tproxy.no-ip.org, muito útil.
> > >
> > > Porém, notei a navegação aparentemente mais lenta e uma mensagem
> > > estranha no
> > > access.log.
> > > 2009/07/06 14:54:46| clientNatLookup: NAT open failed: (2) No such
> > file
> > > or
> > > directory
> > >
> > > Nem o google sabe .. alguém já passou por isso?
> > >
> > > Estou iniciando testes com o lusca-head, para ver se a mensagem se
> > > repete.
> > >
> > > Att,
> > > Daniel
> > >
> > >
> > > ----- Original Message -----
> > > From: "Renato Frederick" <frederick em dahype.org>
> > > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> > > <freebsd em fug.com.br>
> > > Sent: Friday, July 03, 2009 5:06 PM
> > > Subject: [FUG-BR] RES: RES: RES: RES: tproxy/cacheboy
> > >
> > >
> > > Acho que não, a receita de bolo é mais para quem atualiza o sistema
> > > para a
> > > versão stable e já faz o patch do tproxy.
> > >
> > > O importante é que o kernel tenha a opção ativa.
> > >
> > > > -----Mensagem original-----
> > > > De: freebsd-bounces em fug.com.br [mailto:freebsd-
> bounces em fug.com.br]
> > Em
> > > > nome de Daniel Menezes
> > > > Enviada em: sexta-feira, 3 de julho de 2009 17:00
> > > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > > Assunto: Re: [FUG-BR] RES: RES: RES: tproxy/cacheboy
> > > >
> > > > Renato
> > > >
> > > > Existe alguma diferença em recompilar o kernel sem executar o
> 'make
> > > > buildworld'?
> > > > Este passo eu pulei, fiz 'make buildkernel KERNCONF=xx' ...
> > > > Também não fiz o 'make installworld' e 'mergemaster', alguma
> chance
> > > de
> > > > funcionar?
> > > >
> > > > Att,
> > > > Daniel
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Renato Frederick" <frederick em dahype.org>
> > > > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> > > > <freebsd em fug.com.br>
> > > > Sent: Friday, July 03, 2009 4:06 PM
> > > > Subject: [FUG-BR] RES: RES: RES: tproxy/cacheboy
> > > >
> > > >
> > > > Daniel, eu tive este problema quando o meu sistema atual não
> tinha
> > o
> > > > patch
> > > > aplicado.
> > > >
> > > > Você fez todo o processo?
> > > >
> > > > #cd /usr/src
> > > > #patch < freebsd-tproxy-sys.patch
> > > > #make buildworld
> > > >
> > > > (adicionar a linha options IP_NONLOCALBIND ao seu
> > kernel)
> > > >
> > > > #make buildkernel KERNCONF=SEUKERNEL
> > > > #make installkernel KERNCONF=SEUKERNEL
> > > > #make installworld
> > > > #mergemaster
> > > > #reboot
> > > >
> > > > Depois de tudo isto feito, aí sim você pode voltar a compilar o
> > lusca
> > > > pelo
> > > > port www/cacheboy16.
> > > >
> > > >
> > > >
> > > > > -----Mensagem original-----
> > > > > De: freebsd-bounces em fug.com.br [mailto:freebsd-
> > bounces em fug.com.br]
> > > Em
> > > > > nome de VIAVALE - Daniel Menezes
> > > > > Enviada em: sexta-feira, 3 de julho de 2009 15:49
> > > > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > > > Assunto: Re: [FUG-BR] RES: RES: tproxy/cacheboy
> > > > >
> > > > > Renato.
> > > > >
> > > > > Acabei de fazer o que vc disse e está ocorrendo um problema com
> > > > > 'IP_NONLOCALOK'.
> > > > > O kernel já está compilado com os patches, porém, não sei como
> > ver
> > > se
> > > > > está
> > > > > iniciado ou não, já que no dmesg ele não aparece ...
> > > > >
> > > > > Alguma dica?
> > > > >
> > > > > Obrigado.
> > > > >
> > > > >
> > > > > ----
> > > > > cc -DHAVE_CONFIG_H -I. -I../include -O2 -fno-strict-
> aliasing
> > -
> > > > pipe
> > > > > -D_REENTRANT
> > > > > -MT comm_ips_tproxy2.o -MD -MP -MF
> > > > > .deps/comm_ips_tproxy2.Tpo -c -o comm_ips_tproxy2.o
> > > > comm_ips_tproxy2.c
> > > > > mv -f .deps/comm_ips_tproxy2.Tpo .deps/comm_ips_tproxy2.Po
> > > > > cc -DHAVE_CONFIG_H -I. -I../include -O2 -fno-strict-
> aliasing
> > -
> > > > pipe
> > > > > -D_REENTRANT
> > > > > -MT comm_ips_tproxy4.o -MD -MP -MF
> > > > > .deps/comm_ips_tproxy4.Tpo -c -o comm_ips_tproxy4.o
> > > > comm_ips_tproxy4.c
> > > > > mv -f .deps/comm_ips_tproxy4.Tpo .deps/comm_ips_tproxy4.Po
> > > > > cc -DHAVE_CONFIG_H -I. -I../include -O2 -fno-strict-
> aliasing
> > -
> > > > pipe
> > > > > -D_REENTRANT
> > > > > -MT comm_ips_freebsd.o -MD -MP -MF
> > > > > .deps/comm_ips_freebsd.Tpo -c -o comm_ips_freebsd.o
> > > > comm_ips_freebsd.c
> > > > > comm_ips_freebsd.c: In function 'comm_ips_bind':
> > > > > comm_ips_freebsd.c:27: error: 'IP_NONLOCALOK' undeclared (first
> > use
> > > > in
> > > > > this
> > > > > function)
> > > > > comm_ips_freebsd.c:27: error: (Each undeclared identifier is
> > > reported
> > > > > only
> > > > > once
> > > > > comm_ips_freebsd.c:27: error: for each function it appears in.)
> > > > > *** Error code 1
> > > > >
> > > > > Stop in /usr/ports/www/cacheboy16/work/cacheboy-1.6-
> > r13601/libiapp.
> > > > > *** Error code 1
> > > > >
> > > > > Stop in /usr/ports/www/cacheboy16/work/cacheboy-1.6-r13601.
> > > > > *** Error code 1
> > > > >
> > > > > Stop in /usr/ports/www/cacheboy16.
> > > > > *** Error code 1
> > > > >
> > > > > Stop in /usr/ports/www/cacheboy16.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Att,
> > > > > Daniel
> > > > > ----- Original Message -----
> > > > > From: "Renato Frederick" <frederick em dahype.org>
> > > > > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> > > > > <freebsd em fug.com.br>
> > > > > Sent: Friday, July 03, 2009 3:29 PM
> > > > > Subject: [FUG-BR] RES: RES: tproxy/cacheboy
> > > > >
> > > > >
> > > > > Opa..
> > > > >
> > > > > Para o squid você precisa aplicar os patches que tem em [1]
> > > > >
> > > > > Para o lusca(que nos ports esta como WWW/cacheboy16), basta no
> > > > > makeconfig
> > > > > selecionar tproxy, desde que o sistema esteja 'patcheado' com
> os
> > > > > patches
> > > > > existentes em [1]
> > > > >
> > > > >
> > > > > [1] http://tproxy.no-ip.org
> > > > >
> > > > >
> > > > > > -----Mensagem original-----
> > > > > > De: freebsd-bounces em fug.com.br [mailto:freebsd-
> > > bounces em fug.com.br]
> > > > Em
> > > > > > nome de Eduardo Schoedler
> > > > > > Enviada em: sexta-feira, 3 de julho de 2009 15:20
> > > > > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > > > > Assunto: Re: [FUG-BR] RES: tproxy/cacheboy
> > > > > >
> > > > > > Renato.
> > > > > >
> > > > > > Aproveitando o email, o link do Tproxy em Freebsd [1] fala em
> > > > Squid.
> > > > > > Você teria algum howto de como fazer isso com cacheboy/lusca
> ?
> > > > > > Poderia nos informar as versões de cada pacote em uso ?
> > > > > > Alguma configuração diferente a ser feita na hora de compilar
> ?
> > > > > >
> > > > > > Obrigado!
> > > > > >
> > > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Renato Frederick" <frederick em dahype.org>
> > > > > > To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
> > > > > > <freebsd em fug.com.br>
> > > > > > Sent: Friday, July 03, 2009 11:16 AM
> > > > > > Subject: [FUG-BR] RES: tproxy/cacheboy
> > > > > >
> > > > > >
> > > > > > Luiz, acho que é alguma ctls mesmo, apliquei o novo patch +
> > lusca
> > > > > head
> > > > > > e
> > > > > > esta mensagem fica aparecendo quando o numero de endereços
> > > > > > 'fake'(mostrados
> > > > > > pelo netestat) passa de 2k.
> > > > > > Parece que estes dias pegaram algum vírus que abre dezenas de
> > > > > conexões
> > > > > > HTTP
> > > > > > a hosts comprometidos.
> > > > > >
> > > > > > Vou começar a fazer o monitoramento das sysctl e dou um
> retorno
> > a
> > > > > você
> > > > > > na
> > > > > > lista.
> > > > > >
> > > > > > A propósito, o novo patch que você tinha postado funcionou
> > 100%.
> > > > > >
> > > > > >
> > > > > > > -----Mensagem original-----
> > > > > > > De: freebsd-bounces em fug.com.br [mailto:freebsd-
> > > > bounces em fug.com.br]
> > > > > Em
> > > > > > > nome de Luiz Otavio O Souza
> > > > > > > Enviada em: sexta-feira, 3 de julho de 2009 09:38
> > > > > > > Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> > > > > > > Assunto: Re: [FUG-BR] tproxy/cacheboy
> > > > > > >
> > > > > > > > Pessoal,
> > > > > > > >
> > > > > > > > Desde a disponibilização do patch tproxy+cacheboy pro
> > freebsd
> > > > eu
> > > > > > > estou
> > > > > > > > usando sem problemas.
> > > > > > > >
> > > > > > > > Porém de 3 dias para cá esta mensagem aparece
> > repentinamente
> > > e
> > > > só
> > > > > > > > reiniciando o squid que volta:
> > > > > > > >
> > > > > > > > TPROXY comm_ips_bind failed? Why?
> > > > > > > >
> > > > > > > >
> > > > > > > > Vocês tem alguma idéia? Aumentar alguma sysctl?
> > > > > > >
> > > > > > > Renato,
> > > > > > >
> > > > > > > Eu dei uma revisada no código e encontrei apenas um ou dois
> > > > pontos
> > > > > > que
> > > > > > > podem
> > > > > > > produzir esse erro, mas a causa ainda é desconhecida
> > > (precisamos
> > > > de
> > > > > > > mais
> > > > > > > informações para rastrear).
> > > > > > >
> > > > > > > Verifique se não há qualquer outra informação nos logs do
> > lusca
> > > > > > > (cache.log
> > > > > > > ?) e também nos logs do servidor (messages, all.log).
> > > > > > >
> > > > > > > Os ctls que você tem que monitorar são esses:
> > > > > > >
> > > > > > > kern.ipc.maxsockets: 25600
> > > > > > > kern.ipc.numopensockets: 101
> > > > > > > kern.maxfiles: 65536
> > > > > > > kern.maxfilesperproc: 11095
> > > > > > > kern.openfiles: 258
> > > > > > >
> > > > > > > A falta de sockets ou file descriptors podem causar esses
> > > erros,
> > > > > > então
> > > > > > > fique
> > > > > > > atento.
> > > > > > >
> > > > > > > Se o problema persistir, por favor me avise.
> > > > > > >
> > > > > > > Att.,
> > > > > > > Luiz
> > > > > > > PS: Veja esse link com o lusca+tproxy COM FreeBSD fazendo
> > proxy
> > > > de
> > > > > um
> > > > > > > link
> > > > > > > de satelite de 100Mb/s - cute ;)
> > > > > > > http://lusca-cache.blogspot.com/2009/06/lusca-head-pushing-
> > > > 100mbit-
> > > > > > > in.html
Mais detalhes sobre a lista de discussão freebsd