Re: [FUG-BR] Lusca + bridge + tproxy

2011-07-22 Por tôpico Patrick Tracanelli
Aqui por enquanto funcionou Luiz. Vou testar agora um cenario mais real, e te 
reporto. Muuito obrigado :) 

Enviado via iPad

Em 21/07/2011, às 23:58, Luiz Otavio O Souza  escreveu:

> Hello folks,
> 
> Eu (finalmente) tenho o lusca funcionando em modo bridge com o tproxy. Antes 
> que eu acredite que isso funcionou, alguem mais pode testar o patch abaixo ?
> 
> http://loos.no-ip.org/lusca_tproxy.diff
> 
> No meu ambiente de teste eu tinha:
> 
> Clientes (192.168.0.0/24) -> xl0 -> bridge -> vr0 -> internet
> 
> Então precisei criar duas regras para acomodar o vai-e-vem dos pacotes:
> 
> # Direciona os pacotes da rede interna para o proxy
> ipfw add 127.0.0.1,3128 tcp from 192.168.0.0/24 to any 80 via xl0
> 
> # Direciona o retorno dos pacotes para o S.O.
> ipfw add 127.0.0.1 tcp from any 80 to 192.168.0.0/24 via vr0
> 
> Liguei o ipfw para os pacotes da bridge:
> 
> sysctl net.link.bridge.ipfw=1
> 
> e modifiquei o http_port do lusca para:
> 
> http_port 3128 tproxy transparent
> 
> Pronto, tudo funcionou :-) Alguem mais confirma ?
> 
> O patch em si é uma variação do outro patch que já fazia o lusca funcionar no 
> modo transparente também em bridge (mas ainda não com o tproxy).
> 
> A idéia do patch (permitir checar os pacotes no ipfw não apenas na saída mas 
> também na entrada) foi dada pelo Patrick já faz algum tempo, mas só agora 
> consegui colocar ela em prática (Patrick, mais uma vez obrigado !).
> 
> Att.,
> Luiz
> 
> PS: esse patch inclui um segundo patch que faz o tproxy do lusca funcionar 
> sem precisar de qualquer alteração (não precisa ser executado como root), 
> talvez depois eu deixe ele separado para evitar confusões.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] Lusca + bridge + tproxy

2011-07-22 Por tôpico Patrick Tracanelli
Ahh pra mim o patch do bindany aplicou mas n funcionou, precisei rodar como 
root. Novo cenario testo de novo ate o final do dia.

Enviado via iPad

Em 21/07/2011, às 23:58, Luiz Otavio O Souza  escreveu:

> Hello folks,
> 
> Eu (finalmente) tenho o lusca funcionando em modo bridge com o tproxy. Antes 
> que eu acredite que isso funcionou, alguem mais pode testar o patch abaixo ?
> 
> http://loos.no-ip.org/lusca_tproxy.diff
> 
> No meu ambiente de teste eu tinha:
> 
> Clientes (192.168.0.0/24) -> xl0 -> bridge -> vr0 -> internet
> 
> Então precisei criar duas regras para acomodar o vai-e-vem dos pacotes:
> 
> # Direciona os pacotes da rede interna para o proxy
> ipfw add 127.0.0.1,3128 tcp from 192.168.0.0/24 to any 80 via xl0
> 
> # Direciona o retorno dos pacotes para o S.O.
> ipfw add 127.0.0.1 tcp from any 80 to 192.168.0.0/24 via vr0
> 
> Liguei o ipfw para os pacotes da bridge:
> 
> sysctl net.link.bridge.ipfw=1
> 
> e modifiquei o http_port do lusca para:
> 
> http_port 3128 tproxy transparent
> 
> Pronto, tudo funcionou :-) Alguem mais confirma ?
> 
> O patch em si é uma variação do outro patch que já fazia o lusca funcionar no 
> modo transparente também em bridge (mas ainda não com o tproxy).
> 
> A idéia do patch (permitir checar os pacotes no ipfw não apenas na saída mas 
> também na entrada) foi dada pelo Patrick já faz algum tempo, mas só agora 
> consegui colocar ela em prática (Patrick, mais uma vez obrigado !).
> 
> Att.,
> Luiz
> 
> PS: esse patch inclui um segundo patch que faz o tproxy do lusca funcionar 
> sem precisar de qualquer alteração (não precisa ser executado como root), 
> talvez depois eu deixe ele separado para evitar confusões.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


[FUG-BR] This kernel will not be updated: you MUST update the kernel manually

2011-07-22 Por tôpico Otacílio
Caros,

Estou atualizando o sistema da minha máquina e após executar o

freebsd-update -r 8.2-RELEASE upgrade

Uma das mensagens diz o seguinte:


WARNING: This system is running a "squitch" kernel, which is not a
kernel configuration distributed as part of FreeBSD 8.1-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install".

Só que no manual fala que quando você executa o

freebsd-update -r 8.2-RELEASE upgrade

O sistema ainda não foi alterado.

Note: The system is not being altered yet, all patching and merging is
happening in another directory. When all patches have been applied
successfully, all configuration files have been merged and it seems the
process will go smoothly, the changes will need to be committed by the user.

Ai vem minha dúvida. Se eu compilar o kernel novamente e instalar o
mesmo, que kernel eu estou compilando, o velho ou o novo? Eu pensava que
era o novo, mas como o manual diz que o sistema ainda não foi
efetivamente alterado antes de um

freebsd-update install

Estou na dúvida.

[]s
-Otacílio
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] This kernel will not be updated: you MUST update the kernel manually

2011-07-22 Por tôpico Marcel Bonnet
2011/7/22 Otacílio :
> Caros,
>
> Estou atualizando o sistema da minha máquina e após executar o
>
> freebsd-update -r 8.2-RELEASE upgrade
>
> Uma das mensagens diz o seguinte:
>
>
> WARNING: This system is running a "squitch" kernel, which is not a
> kernel configuration distributed as part of FreeBSD 8.1-RELEASE.
> This kernel will not be updated: you MUST update the kernel manually
> before running "/usr/sbin/freebsd-update install".
>
> Só que no manual fala que quando você executa o
>
> freebsd-update -r 8.2-RELEASE upgrade
>
> O sistema ainda não foi alterado.
>
> Note: The system is not being altered yet, all patching and merging is
> happening in another directory. When all patches have been applied
> successfully, all configuration files have been merged and it seems the
> process will go smoothly, the changes will need to be committed by the user.
>
> Ai vem minha dúvida. Se eu compilar o kernel novamente e instalar o
> mesmo, que kernel eu estou compilando, o velho ou o novo? Eu pensava que
> era o novo, mas como o manual diz que o sistema ainda não foi
> efetivamente alterado antes de um
>
> freebsd-update install
>
> Estou na dúvida.
>
> []s
> -Otacílio
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>

Por acaso esse kernel não teria sido compilado por alguém
(personalizado) e agora vc estaria tentando fazer atualização sobre um
binário que não é o binário RELEASE do BSD, mas sim um binário
"customizado" (compilado por alguém) ?
[]s

-- 
Marcel Bonnet
"No princípio era o caos... e no meio também."
[música  ] www.monovox.net.br
[música  ] twitter.com/mono_vox
[música  ] http://soundcloud.com/monovox
[qq coisa] twitter.com/marbonfly
[Best OS] freebsd.org
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] This kernel will not be updated: you MUST update the kernel manually

2011-07-22 Por tôpico Otacílio
On 22/07/2011 13:33, Marcel Bonnet wrote:
> 2011/7/22 Otacílio :
>> Caros,
>>
>> Estou atualizando o sistema da minha máquina e após executar o
>>
>> freebsd-update -r 8.2-RELEASE upgrade
>>
>> Uma das mensagens diz o seguinte:
>>
>>
>> WARNING: This system is running a "squitch" kernel, which is not a
>> kernel configuration distributed as part of FreeBSD 8.1-RELEASE.
>> This kernel will not be updated: you MUST update the kernel manually
>> before running "/usr/sbin/freebsd-update install".
>>
>> Só que no manual fala que quando você executa o
>>
>> freebsd-update -r 8.2-RELEASE upgrade
>>
>> O sistema ainda não foi alterado.
>>
>> Note: The system is not being altered yet, all patching and merging is
>> happening in another directory. When all patches have been applied
>> successfully, all configuration files have been merged and it seems the
>> process will go smoothly, the changes will need to be committed by the user.
>>
>> Ai vem minha dúvida. Se eu compilar o kernel novamente e instalar o
>> mesmo, que kernel eu estou compilando, o velho ou o novo? Eu pensava que
>> era o novo, mas como o manual diz que o sistema ainda não foi
>> efetivamente alterado antes de um
>>
>> freebsd-update install
>>
>> Estou na dúvida.
>>
>> []s
>> -Otacílio
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
> 
> Por acaso esse kernel não teria sido compilado por alguém
> (personalizado) e agora vc estaria tentando fazer atualização sobre um
> binário que não é o binário RELEASE do BSD, mas sim um binário
> "customizado" (compilado por alguém) ?
> []s
> 

Por acaso não, eu mesmo fiz isso. Mas a minha preocupação é
desnecessária, pois é só utilizar o nextboot -k para setar o próximo
boot para a versão GENERIC (que foi atualizada), rodar o freebsd-update
install e depois recompilar o novo kernel com os novos fontes.

Em todo o caso, obrigado

-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


[FUG-BR] ZFS para cache de páginas

2011-07-22 Por tôpico Marcelo Gondim
Pessoal,

Ainda não usei o ZFS e estava pensando em fazer testes com ele e o 
lusca. Pensei em criar um pool usando RAID-Z com 4 discos SATA II de 
500Gb. Alguém saberia me dizer se a performance realmente será boa ou 
nesse caso o ufs ainda vai ser mais vantajoso? O servidor que vou fazer 
o teste tem 24Gb de ram e pelo que vi memória é importante. Outra 
questão: devo usar compressão nesse fs que vou criar no pool para 
aumentar a performance?

Grande abraço à todos.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd