Umas das "maravilhas" de usar solução "livre", alardeado pelos xiitas e afins é a possibilidade de contribuir quando não há o que precisamos.. o caso do tproxy X FreeSBD é o exemplo clássico disto, desenvolveram pro Linux porque não existia(como não existe pro FreeBSD) e é muito bem aceito.
Uma boa contribuição para a "comunidade" do FreeBSD seria, além de ajudar nos ports e mantê-los atualizados em todas as versões, portar estas aplicações que exigem um "hackerismo" no Kernel e afins. Afinal, nada adianta chorar as mágoas que não existe e blábláblá e não tentar fazer a parte. Cito o exemplo do softfail, que Patrick fez, que acompanhei de perto e o ports do spamcontrol, pelo garga. Ambos muito apreciados e disponíveis em milhares de RPM para Linux(qmailrocks, qmailtoaster) e não existentes pro Free. Os 2 fizeram o port, e está aí, ajudando milhares de pessoas, inclusive eu. Infelizmente esta carapuça serve para mim, sinto falta de muita coisa para o Free mas não contribuo com nada porque não tenho tempo e também não sei fazer nem um "hello world" em BASIC, só sugo o projeto.. hehehhee Desculpem mais uma vez por mais um OFF, mas creio que reclamar não resolve, cabe ao técnico/consultor encontrar a melhor solução dentre os diversos sistemas operacionais existentes e adequá-la ao ambiente. Abraços > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Luiz Otavio O Souza > Sent: Tuesday, August 26, 2008 9:59 AM > To: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) > Subject: Re: [FUG-BR] Kerberos no Debian e > noFreeBSD:Enormedesapontamentocomo Free > > ----- Original Message ----- > > Victor.... ola amigo > > Bem, veja bem cara, eu entendo seu desapontamento eu nao conseguir o > que quer com o FreeBSD, mas, vamos aos fatos: > > * Se existe no linux mas nao no freebsd, eh pq algum developer de > linux sentiu a necessidade e desenvolvou. > * Portanto, se nao existe (ainda) no freebsd, eh pq nao sentiram tanta > necessidade assim > * Agora, se vc sentiu essa necessidade, manda bala no desenvolvimento, > nao precisa fazer sozinho, entra em contato com a galera q tem o mesmo > interesse > > 2008/8/25 Victor <[EMAIL PROTECTED]>: > > Infelizmente não. Eles apenas redirecionam, não "mascaram". O tproxy > > funciona pois é um diff pro Kernel do Linux aonde ele faz um tipo de > > spoof. > > > > > > -- > > Atenciosamente, > > Victor Gustavo Volpe > ------------------------- > > Victor e Mario, > > O tproxy do squid usa NAT para fazer o que faz, assim o servidor pode > multiplexar as requisições do cliente real e do squid no IP do cliente sem > o > risco de haver conflitos (o squid utilizar um par IP/porta que o cliente > também esta utilizando). > > Por isso todo o trafego (a classe IP dos clientes) tem que passar pelo > servidor com o squid/tproxy, para que esse NAT posso funcionar a contento. > > O Squid faz o seguinte, cria um novo socket e pede que o kernel faça o > source nat dessa conexão para o IP do cliente, simples porém eficiente. > Foram criadas apenas as funções no kernel que o squid utiliza para amarrar > um novo socket a um IP para origem da conexão. Fora isso o linux conta com > uma rotina de nat no kernel que parece ser mais evoluida que a nossa > libalias. > > No FreeBSD o nat é feito via libalias ou via kernel (libalias too), mas os > dados que vão ser nateados precisam vir através do divert, então o cenário > é > um pouco diferente do linux. > > A solução para o FreeBSD na minha opnião pode ser feita com base na > libalias > (que precisará de regras no firewall para funcionar - divert), mas > funcionaria. > > A solução pode ser +/- assim: > > Uma parte do natd precisa ser portada para o squid e rodar em uma segunda > thread (aqui começam os problemas... não sei como o squid se comportaria > adicionando outra thread). > > Assim o squid rodaria duas threads, a principal aonde o squid funciona e > outra para rodar o libalias (userland) para fazer o tproxy. Como isso > funciona? simples: > > Qaundo o squid abrir uma conexão ele envia uma mensagem para a thread do > libalias/tproxy informando o par IP/PORTA de origem da conexão e o IP a > ser > utilizado no nat (IP do cliente). > > A thread do libalias/tproxy de posse dessa informação faz a configuração > dinamica para atender a essa unica conexão (bem como os pacotes que > voltarão). > > Uma regra no firewall também será necessária (básica) para passar todos os > pacotes pela porta de divert utilizada pela thread libaliad/tproxy. > > Outra possibilidade seria criar alguma outra forma de comunicar a libalias > padrão de cada NAT utilizado pelo squid e dai não precisariamos de > adicionar > outra thread, nem o código da libaliad no squid, mas a comunicação > inter-processos pode ser dificil de ser implementada (principalmente em > servidores de alta demanda). > > Se alguem quiser trocar mais idéias... > > []'s > -luiz > > ------------------------- > 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