Renato voce falou tudo, e infelizmente esta carapuca serve para 99,9% (incluindo-me,inclusive) da nossa comunidade brasileira. Precisamos refletir sobre sermoes como esse todos os dias. Como diz um amigo meu "se tudo fosse e tivesse sido sempre perfeito, estariamos ate hoje nas cavernas."
Obrigado. On Tue, 26 Aug 2008 10:40:25 -0300, "Renato Frederick" <[EMAIL PROTECTED]> wrote: > 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 ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd