Considerações sobre o Squid.

[Claudio]

Continuando um papo que estava rolando no forum de wireless:

Boa Noite Pessoal!

Mestre Claudio não quer alterar o boot do BrazilFW para ser sequencial?
assim elemina os problemas de Wireless e do Squid, não é difícil introduzir isso
no BrazilFW, vai ficar um boot igual a qualquer linux!

Mestre Mazzei.

Esse problema da sequência dos módulos não tem relação com o problema do squid, os scripts são executados um de cada vez e na sequencia correta, a questão é que eu os executo baseados em um for sobre o comando ls que lista os arquivos em ordem alfabética. No caso mod.bridge estava sendo executado antes do mod.wireless e a interface ainda não estava disponível para ser utilizada pela bridge, renomeando o arquivo para mod.zzzbridge resolveu.

Como eu pretendo "oficializar" a bridge ela será configurada dentro do rc.inet e esse problema vai acabar.

Eu tenho certeza que o bfw já executa os scripts de forma sincrona, o problema do squid é que ele é um executável que roda em background, assim os scripts continuam enquanto ele ainda não terminou totalmente de rodar. Ou seja: quem é assincrono é o próprio squid.

De qualquer forma, você sabe bem que o bfw não é meu, é nosso. Se você precisa alterar qualquer coisa que facilite o seu trabalho, basta falarr. O que eu devo alterar?

Bom dia Pessoal!

Mestre Claudio estou preparando o material para enviar ao Mestre, dei uma pausa pois eu comprei
o Fedora 4 e estou alterando meu sistema, a idéia que eu tive é criar o boot (rc.d) já sequencialmente
(01, 02, 03 e etc..) e redirecionar os arquivos que vão ser executados (tipo um alias) para essa
sequencia pré-definida, as distribuições Mandriva e SuSe fazem assim, quando se altera uma
sequencia (tipo mod.xxx) para um outro numero só altera um arq., sobre o squid é que ele
tem umas rotinas para retirar arquvos server de porta (rotina interna) ou alteramos o bicho
(não recomendo) ou colocamos ele para ser executado antes dos ssh, webAdmin (já está) e etc...
pois o o rc.squid que eu fiz ele espera mais ou menos 5 segundos para o squid terminar as rotinas
em background para testar se o WebAdmin está no ar, se for colocar outro server (FTP, e-mail)
vai ter que ficar alterando o rc.squid, se não tem previsão de colocar nenhum server a mais no
BrazilFW o rc.squid pode ficar como está.

[Claudio]

Mas mestre....

O problema é que o squid é assyncrono. Cuidar para que o script dele seja iniciado primeiro é fácil, o problema é que, uma vez dentro do script o squid é inicializado e a thread continua. Essa solução que você deu parece muito boa, mas não dá para prever quanto tempo vai levar.

Eu tenho uma ideia melhor: Dentro do próprio script do squid (para não precisar mecher no bfw) a gente bota o bicho para rodar, e procura por algum sinal de que ele já está pronto (ex: alguma coisa no comando ps, ou a existencia de algum arquivo que ele crie DEPOIS de ter derrubado os outros serviços)

Enquanto esse sinal não aparece o próprio script do squid fica em loop esperando, neste caso não teriamos mais problemas de "quanto-tempo-o-squid-leva-para-carregar". E eu cuido para que todos os outros serviços sejam iniciados depois, aliás, isso é fácil é só chamar o rc.squid de algo tipo rc.aaaaa-squid.

Claro que esse mecanismo precisa de um time-out porque se der algum erro não prenderia o boot do bfw para sempre. O que o mestre acha desta idéia? Se o mestre souber que sinal eu devo procurar é só dizer que eu implemento o loop no script, estou mechendo no squid.tgz mesmo.


Paralelo a isso, eu estou pensando em oficializar aquele loopzinho que fica verificando se o webadmin está no ar (wa_patch.tgz) e extender essa procura pelo ssh tambem. Por um lado, ganhamos em segurança, nenhum add-ons vai tirar esses serviços basicos do ar mais, por outro lado é mais um processo rodando. O que o mestre acha? Eu ainda não decidi se uso aquele toy que você fez ou se deixo com o sleep, o que é melhor? e porque?



Mais algumas coisinhas sobre o squid:

1 - Eu acho uma boa idéia disparar o squid -z automaticamente. Basta olhar dentro da partição, se a estrutura não estiver lá é porque precisa ser criada. É melhor fazer isso do que deixar mais uma preocupação manual para os usuários, eu sempre busco fazer os pacotes do tipo: põe-o-arquivo-lá-e-pronto. Alguma coisa contra? (alem do tempo de carga, é claro).

2 - Alguns usuários estão tendo problemas porque esquecem de instalar o pacote de idiomas, eu acho uma boa idéia, deixar o idioma default (inglês) direto dentro do squid.tgz e o usuário só precisa acrescentar outro se quizer, só vai usar o squid quem tiver hd, logo os poucos kb que seriam desperdicados não seriam problema.

3 - No pacote do polipo, e recentemente no tinyproxy eu criei um chain no iptables para manipular o proxy transparente. Eu fiz isso para que o usuário tivesse controle sobre quais ips ele quer redirecionar e quais ele não quer. Pensei em aplicar esse metodo no pacote do squid. O que você acha?

O nossos proxys transparentes estão by-passando as regras do firewall simplificado, eu sei. Estou cuidando disso tambem.



Preciso da sua opnião sobre uma série de outros planos que eu tenho. Acho que vou criar um forum de desenvolvimento para esse tipo de discussão.

[Ewerton Romulo]

"Acho que vou criar um forum de desenvolvimento para esse tipo de discussão"

Valeu Claudio!! \0/ \0/ \0/ \0/

[Marcos do Vale]

Mestres,

Algumas opiniões de um simples mortal:

"Paralelo a isso, eu estou pensando em oficializar aquele loopzinho que fica verificando se o webadmin está no ar (wa_patch.tgz) e extender essa procura pelo ssh tambem. Por um lado, ganhamos em segurança, nenhum add-ons vai tirar esses serviços basicos do ar mais, por outro lado é mais um processo rodando. O que o mestre acha? Eu ainda não decidi se uso aquele toy que você fez ou se deixo com o sleep, o que é melhor? e porque?"

Sobre isto, tive a maior dor-de-cabeça pq uso o rrdtool/rrdstat q tb dispara o httpd ... se possível verifiquem isto.

"Preciso da sua opnião sobre uma série de outros planos que eu tenho. Acho que vou criar um forum de desenvolvimento para esse tipo de discussão."

Seria ótimo ...

[mazzei]

Boa Noite Pessoal!

Eu tenho uma ideia melhor: Dentro do próprio script do squid (para não precisar mecher no bfw) a gente bota o bicho para rodar, e procura por algum sinal de que ele já está pronto (ex: alguma coisa no comando ps, ou a existencia de algum arquivo que ele crie DEPOIS de ter derrubado os outros serviços)

Mestre Claudio tem vários sinais e 2 arquivos de log que ele cria no final,
vou fazer um teste para ver qual é a ultima tarefa que ele executa e posto
aqui os resultados.

Claro que esse mecanismo precisa de um time-out porque se der algum erro não prenderia o boot do bfw para sempre. O que o mestre acha desta idéia? Se o mestre souber que sinal eu devo procurar é só dizer que eu implemento o loop no script, estou mechendo no squid.tgz mesmo.

OK Mestre a idéia é boa, vou testar!

Paralelo a isso, eu estou pensando em oficializar aquele loopzinho que fica verificando se o webadmin está no ar (wa_patch.tgz) e extender essa procura pelo ssh tambem. Por um lado, ganhamos em segurança, nenhum add-ons vai tirar esses serviços basicos do ar mais, por outro lado é mais um processo rodando. O que o mestre acha? Eu ainda não decidi se uso aquele toy que você fez ou se deixo com o sleep, o que é melhor? e porque?

O sleep, como é nativo do busybox não vai ocupar espaço, como as tarefas que
o Mestre está pretendendo fazer é na parte de boot, o busybox carrega mais
na memória na inicialização (cada comando acrescentado ele aumenta e
diminue dependendo da tarefa). O Mestre pode usar aquele toy especifico
para uma tarefa que vai ser executada durante o funcionamento do root mas
para inicialização pode usar o sleep, o pacote (BrazilFW) fica menor e não
tem carga no final, aquele toy pode é substituir as chamadas de time do
IPTables, pois pode ser alterado para dias, semanas e etc... que com o cron
(Que tem no busybox mas aumenta o mesmo tamanho do toy) a galera ainda
não sabe usar direito!

1 - Eu acho uma boa idéia disparar o squid -z automaticamente. Basta olhar dentro da partição, se a estrutura não estiver lá é porque precisa ser criada. É melhor fazer isso do que deixar mais uma preocupação manual para os usuários, eu sempre busco fazer os pacotes do tipo: põe-o-arquivo-lá-e-pronto. Alguma coisa contra? (alem do tempo de carga, é claro).

Não tenho nada contra, na realidade no rc.squid eu não coloquei pois achava
que descobririamos uma solução melhor, é que toda vez que vai reeniciar o
BFW e consequentimente o squid o cache de um dia vai pro vinagre, como
o router é para ficar 24 horas no ar, é uma instrução desnecessaria, só
precisa dela uma vez, depois o próprio squid se encaregava de gerenciar o
cache e o detalhe do tempo é que já fiz "fritar" um HD de 60 GB e demorou
para criar o cache 38 segundos.

2 - Alguns usuários estão tendo problemas porque esquecem de instalar o pacote de idiomas, eu acho uma boa idéia, deixar o idioma default (inglês) direto dentro do squid.tgz e o usuário só precisa acrescentar outro se quizer, só vai usar o squid quem tiver hd, logo os poucos kb que seriam desperdicados não seriam problema.

Mestre este problema me desculpe mas é só a galera que diz pois o squid
funciona sem mensagem de erro nenhuma, por isso que fiz o pacote de
linguagem separado pois o squid para o Coyote nem tinha isso e funcionava.

3 - No pacote do polipo, e recentemente no tinyproxy eu criei um chain no iptables para manipular o proxy transparente. Eu fiz isso para que o usuário tivesse controle sobre quais ips ele quer redirecionar e quais ele não quer. Pensei em aplicar esse metodo no pacote do squid. O que você acha?

O nossos proxys transparentes estão by-passando as regras do firewall simplificado, eu sei. Estou cuidando disso tambem.

Nem o squid nem o MZProxy precisa disso, só precisa de uma regra na IPTables
e fica transparente, a regra como eu fiz, usando o lu.squid vai ser executada
após as regras de MAC, QoS e etc... não sei se tem vantagem nisso, pois
como o Mestre disse o polipo depois das novas mudanças ficou pior para
a galera trabalhar!

Preciso da sua opnião sobre uma série de outros planos que eu tenho. Acho que vou criar um forum de desenvolvimento para esse tipo de discussão.

Conte comigo, só parei essas duas semanas para acertar problemas particulares
e fazer os testes do MZProxy 1 e 2 e o Super QoS, estou usando o novo
fedora, e por enquanto meu sistema ficou mais estável!