Re: [FUG-BR] qmail Sender Throttling

[Luiz Gustavo S. Costa]

Se usa freebsd, pode usar o proprio firewall PF para isso, limite o nr
de conexoes (estados) por ip de origem para a porta 25 do servidor.

http://www.cyberciti.biz/faq/freebsd-openbsd-pf-stop-ftp-bruteforce-attacks/

O site ai mostra como fazer para o ftp (porta 21), é só adaptar para o
seu caso (porta 25).

Rapido e eficaz ;)

Abraços

Em 10 de junho de 2010 03:24, Marcelo da Silva
 escreveu:
> Ola a Todos, preciso de alguma solucao para bloquear usuarios infectados
> que usa o servidor de email para fazer spam.
> estes usuario se conecta e *autentica* no smtp do servidor de email...
>
>
> to usando  qmail + spamdyke + simcan + spamassassin..
>
> Preciso de algum software que limite a quantidade de msg por minuto/hora
> que um usuario
> autenticado pode enviar...
>
> Abracos;;
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



-- 
Luiz Gustavo Costa (Powered by BSD)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
mundoUnix - Consultoria em Software Livre
http://www.mundounix.com.br
ICQ: 2890831 / MSN: cont...@mundounix.com.br
Tel: 55 (21) 2642-3799 / 7582-0594
Blog: http://www.luizgustavo.pro.br
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] qmail Sender Throttling

[Marcelo da Silva]

Ola a Todos, preciso de alguma solucao para bloquear usuarios infectados
que usa o servidor de email para fazer spam.
estes usuario se conecta e *autentica* no smtp do servidor de email...


to usando  qmail + spamdyke + simcan + spamassassin..

Preciso de algum software que limite a quantidade de msg por minuto/hora
que um usuario
autenticado pode enviar...

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

Re: [FUG-BR] [OFF] Balanceamento Apache

[Ricardo Katz]

Olá:

O Varnish, até onde eu saiba é mais Cache do que balanceamento de cargas :)

Estava pesquisando um pouco sobre ele esses dias, e vi que é uma boa
combinação com o Pound (http://www.apsis.ch/pound/).

nunca testei a combinação dos dois em um BSD, mas pode ser uma bela
solução também.

Atente para o seguinte no site:

"Warning: as Pound is a multi-threaded program it requires a version
of OpenSSL with thread support. This is normally the case on Linux and
Solaris (for example) but not on *BSD. If your system has the wrong
library please download, compile and install OpenSSL (from
http://www.openssl.org) with threads support."



Em 9 de junho de 2010 22:46, Leo Garcia  escreveu:
> Teste o VARNISH
> http://varnish-cache.org/
>
> A globo.com usa!
> -
> 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] [OFF] Balanceamento Apache

[Leo Garcia]

Teste o VARNISH
http://varnish-cache.org/

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

Re: [FUG-BR] [OFF] Balanceamento Apache

[Ricardo Katz]

Fernando, boa noite:

Não sei se o Jetty suporta protocolo AJP, como você mencionou o
Tomcat, existe um conector para ele chamado Mod_JK.

O Mod_jk fala nativamente com o Tomcat (e JBoss, e demais), por padrão
na porta 8009, e entre alguma de suas capacidades está o balanceamento
de carga / redundância.

Enfim: http://tomcat.apache.org/connectors-doc/

Pelo que eu vi da Doc do jetty, eles não recomendam o uso de AJP com o
mesmo ("AJP is NOT recommended. Use HTTP and mod_proxy instead (see
above" - http://docs.codehaus.org/display/JETTY/Configuring+AJP13+Using+mod_jk),
mas eu uso ele e nunca me apresentou nenhum problema.

Ats

Em 9 de junho de 2010 11:15, Luiz Gustavo S. Costa
 escreveu:
> Bom dia !
>
> Será que não é interessante usar um relayd entre o apache (para usar o
> certificado) e os seus Jetty 
>
> da uma estudada nisso:
>
> [r...@desktop] /usr/ports/net/relayd# cat pkg-descr
> relayd is a daemon to relay and dynamically redirect incoming connections
> to a target host.  Its main purposes are to run as a load-balancer,
> application layer gateway, or transparent proxy.  The daemon is able to
> monitor groups of hosts for availability, which is determined by checking
> for a specific service common to a host group.  When availability is con-
> firmed, Layer 3 and/or layer 7 forwarding services are set up by relayd.
>
> Layer 3 redirection happens at the packet level; to configure it, relayd
> communicates with pf(4).
>
> WWW: http://spootnik.org/relayd/
>
> Abraços
>
> Em 9 de junho de 2010 14:42, Fernando Nadir da Silveira
>  escreveu:
>> Bom Dia,
>>
>> Tenho a seguinte configuracao: 1 Apache fazendo proxy_balanced para 2 Jetty,
>> hoje meu certificado SSL esta instalado no Apache, e neste caso soh preciso
>> de um certificado SSL. O caso que quando 1 Jetty sai do Ar, o apache ainda
>> envia algumas requisicoes para esta maquina, demora muito para ele notar q
>> este jetty nao esta respondendo.
>>
>> Queria saber se alguem tem alguma coisa parecida com jetty ou tomcat, o que
>> utiliza para um grande volume de acesso diario. Qual uma estrutura boa para
>> atender "n" Jettys com aplicação em JAVA.
>>
>> Obrigado
>> Fernando Silveira
>> -
>> Histórico: http://www.fug.com.br/historico/html/freebsd/
>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>>
>
>
>
> --
> Luiz Gustavo Costa (Powered by BSD)
> *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
> mundoUnix - Consultoria em Software Livre
> http://www.mundounix.com.br
> ICQ: 2890831 / MSN: cont...@mundounix.com.br
> Tel: 55 (21) 2642-3799 / 7582-0594
> Blog: http://www.luizgustavo.pro.br
> -
> 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] Dúvida Pfsense

[João Tobias]

Olá Amigos, boa noite ! tudo bem ?

 

Primeiramente parabens pelo projeto.

 

Estou iniciando as atividades com o Pfsense, porém estou com dificuldade em
encontrar um bom material em português, alguém tem alguma dica ?

 

Atenciosamente,

 



 

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

Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( I PFW + SQUID )

[Rodrigo]

Boa Noite Celso,

Então. na realidade nao vejo muito vantagem nao, já que existe a 
nova maneira que é essa que vc usa, porem dessa forma que vc faz com o 
"config, make depend, make e make install" é um costume meu que vem la 
dos primórdios Free 3.x, 4.x. rsrsrs

Mas experimente fazer dessa forma, mesmo sabendo que pode ser que tambem 
nao funcione.. tem determinadas linhas no código do Kernel que não 
podem ser apagadas, mesmo que elas façam referencias ao que vc deseja, 
como no caso da "ISA", como por exemplo essa:

device npx0 at isa? port ``IO_NPX'' irq 13 vector npxintr
npx0 e a interface para a unidade de ponto flutuante do co-processador 
matematico. NAO REMOVA ESTA LINHA!!!

Não sei se vc ja olhou nesse link, mas caso nao tenha olhado da uma 
olhadinha, vai que aki pode lhe dizer mais coisas.

http://www.primeirospassos.org/sessao4_1.html

Tem esse aki tb, que se refere a todas as linhas do kernel, quem sabe 
neste também nao te solucione alguma coisa

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html

Qualquer coisa me avise.

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

Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( I PFW + SQUID )

[Celso Viana]

Em 9 de junho de 2010 13:22, Rodrigo
 escreveu:
> Boa Tarde Amigo
>
> Então, vamos fazer  o seguinte, vou lhe passar a  forma com que faço
> para compilar o kernel, atualmente existem 2 formas, uma mais nova e a
> mais antiga, eu nunca me dei muito bem com a opção nova, por isso
> prefiro sempre a antiga. rsrsrs
>
> Bom funciona assim:
>
> 1º) Acessar o diretório do Kernel:
>       #/usr/src/sys/i386/conf
>
> 2º) Fazer uma cópia do Kernel atual para um novo kernel:
>       Ex: cp -p GENERIC KERNEL_CUSTOMIZADO
>
> 3º) Fazer a edição do conteudo no arquivo que voce acabou de copiar.
>
> 4º) Agora vamos começar o processo de compilação do novo Kernel.
>       Executar o comando para ele gerar os arquivos que vao ser
> re-compilados.
>       Comando: #/usr/sbin/config "NOME_NOVO_KERNEL".
>       OBS.: Executar o comando dentro da pasta onde está o novo Kernel.
>
> 5º) Ir até o diretório onde ele colocou o conteudo que sera re-compilado.
>        #cd ../../compile/
>
> 6º) Usar os seguintes comandos:
>       a) make depend
>       b) make
>       c) make install
>
> 7º) Depois do kernel compilado, faz o seguinte copie o ANTIGO Kernel,
> para uma pasta em algum lugar NAO APAGUE, pois se der algum problema vc
> pode volta-lo ao lugar original que o sistema ira funcionar normalmente.
>
> Certo, comigo isso já é o suficiente para funcionar, agora vc me disse
> que esta usando o Free 8 neh, entaum tive muitos problemas com ele na
> parte de compilação de kernel, atualmente aki na minha empresa estou
> usando somente o 7.3 Release
>
> Bom qualquer coisa me avise...
>
> Att,
> Rodrigo.
> RC Soluções Inteligentes em TI.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>

Rodrigo,

Sempre compilo o kernel do FreeBSD da seguinte maneira:

- copio o GENERIC para um outro arquivo NOVO_KERNEL e faço as
alterações necessárias
- adiciono a entrada KERNCONF=NOVO_KERNEL em /etc/make.conf
- estando em /usr/src executo "make -j4 -s buildkernel" e depois "make
installkernel"

Já li que as vezes a opção "-j" pode gerar erro durante a compilação.

Existe alguma vantagem em se compilar usando "config, make depend,
make e make install"?

Thanks!!!

-- 
Celso Vianna
BSD User: 51318
http://www.bsdcounter.org

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

[FUG-BR] Fwd: Import of clang/LLVM about to start

[Danilo Egea]

Agora sim!!!


 Original Message 
Subject:Import of clang/LLVM about to start
Date:   Wed, 9 Jun 2010 19:45:16 +0200
From:   Roman Divacky 
To: curr...@freebsd.org



Hi,

The import of clang/LLVM is about to start. I'll announce when the import
is finished.

It would be nice if you didn't commit while the import is in progress.

thank you

Roman Divacky




Attached Message Part
Description: PGP signature
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( I PFW + SQUID )

[Rodrigo]

Boa Tarde Amigo

Então, vamos fazer  o seguinte, vou lhe passar a  forma com que faço 
para compilar o kernel, atualmente existem 2 formas, uma mais nova e a 
mais antiga, eu nunca me dei muito bem com a opção nova, por isso 
prefiro sempre a antiga. rsrsrs

Bom funciona assim:

1º) Acessar o diretório do Kernel:
   #/usr/src/sys/i386/conf

2º) Fazer uma cópia do Kernel atual para um novo kernel:
   Ex: cp -p GENERIC KERNEL_CUSTOMIZADO

3º) Fazer a edição do conteudo no arquivo que voce acabou de copiar.

4º) Agora vamos começar o processo de compilação do novo Kernel.
   Executar o comando para ele gerar os arquivos que vao ser 
re-compilados.
   Comando: #/usr/sbin/config "NOME_NOVO_KERNEL".
   OBS.: Executar o comando dentro da pasta onde está o novo Kernel.

5º) Ir até o diretório onde ele colocou o conteudo que sera re-compilado.
#cd ../../compile/

6º) Usar os seguintes comandos:
   a) make depend
   b) make
   c) make install

7º) Depois do kernel compilado, faz o seguinte copie o ANTIGO Kernel, 
para uma pasta em algum lugar NAO APAGUE, pois se der algum problema vc 
pode volta-lo ao lugar original que o sistema ira funcionar normalmente.

Certo, comigo isso já é o suficiente para funcionar, agora vc me disse 
que esta usando o Free 8 neh, entaum tive muitos problemas com ele na 
parte de compilação de kernel, atualmente aki na minha empresa estou 
usando somente o 7.3 Release

Bom qualquer coisa me avise...

Att,
Rodrigo.
RC Soluções Inteligentes em TI.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] Incompatibilidade com HP DL 120 G6

[Felipe Nolasco]

Apenas para informaçao de todos, baixei a
versao FreeNAS-amd64-LiveCD-0.7.2.5226.iso e reconheceu as placas de rede
(HP NC 107i).

bge0 e bg1

-- 
Felipe Nolasco aka 'xfnolx'
ICQ: 120505047
MSN: felipenolasco at gmail.com
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( I PFW + SQUID )

[renato martins]

coloca o seu kernel ai no email que fica mais facil do pessoal te ajudar

Em 9 de junho de 2010 09:51, Anderson Eduardo escreveu:

> Nem tinha lido a thread completa.
> Mas no seu caso realmente é a USB que precisa do 802.11.
>
> -
> 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] [OFF] Balanceamento Apache

[Luiz Gustavo S. Costa]

Bom dia !

Será que não é interessante usar um relayd entre o apache (para usar o
certificado) e os seus Jetty 

da uma estudada nisso:

[r...@desktop] /usr/ports/net/relayd# cat pkg-descr
relayd is a daemon to relay and dynamically redirect incoming connections
to a target host.  Its main purposes are to run as a load-balancer,
application layer gateway, or transparent proxy.  The daemon is able to
monitor groups of hosts for availability, which is determined by checking
for a specific service common to a host group.  When availability is con-
firmed, Layer 3 and/or layer 7 forwarding services are set up by relayd.

Layer 3 redirection happens at the packet level; to configure it, relayd
communicates with pf(4).

WWW: http://spootnik.org/relayd/

Abraços

Em 9 de junho de 2010 14:42, Fernando Nadir da Silveira
 escreveu:
> Bom Dia,
>
> Tenho a seguinte configuracao: 1 Apache fazendo proxy_balanced para 2 Jetty,
> hoje meu certificado SSL esta instalado no Apache, e neste caso soh preciso
> de um certificado SSL. O caso que quando 1 Jetty sai do Ar, o apache ainda
> envia algumas requisicoes para esta maquina, demora muito para ele notar q
> este jetty nao esta respondendo.
>
> Queria saber se alguem tem alguma coisa parecida com jetty ou tomcat, o que
> utiliza para um grande volume de acesso diario. Qual uma estrutura boa para
> atender "n" Jettys com aplicação em JAVA.
>
> Obrigado
> Fernando Silveira
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



-- 
Luiz Gustavo Costa (Powered by BSD)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+
mundoUnix - Consultoria em Software Livre
http://www.mundounix.com.br
ICQ: 2890831 / MSN: cont...@mundounix.com.br
Tel: 55 (21) 2642-3799 / 7582-0594
Blog: http://www.luizgustavo.pro.br
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

[FUG-BR] [OFF] Balanceamento Apache

[Fernando Nadir da Silveira]

Bom Dia,

Tenho a seguinte configuracao: 1 Apache fazendo proxy_balanced para 2 Jetty,
hoje meu certificado SSL esta instalado no Apache, e neste caso soh preciso
de um certificado SSL. O caso que quando 1 Jetty sai do Ar, o apache ainda
envia algumas requisicoes para esta maquina, demora muito para ele notar q
este jetty nao esta respondendo.

Queria saber se alguem tem alguma coisa parecida com jetty ou tomcat, o que
utiliza para um grande volume de acesso diario. Qual uma estrutura boa para
atender "n" Jettys com aplicação em JAVA.

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

Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( IPFW + SQUID )

[Anderson Eduardo]

Nem tinha lido a thread completa.
Mas no seu caso realmente é a USB que precisa do 802.11.

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

Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( IPFW + SQUID )

[Anderson Eduardo]

Tem drivers usb que necessitam do 802.11.
ural por exemplo.

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

Re: [FUG-BR] DNS

[Luan Tasca - FUG]

Será que isso via resolver pra mim? porque o endereco que quero acessar 
é www.site.com.br/pasta e nao diretamente o site, e ali onde tá 
200.x.x.x seria o ip do www.site.com.br ?


> Luiz Gustavo S. Costa wrote:
>
> Então, duas opções:
>
> - Dns views (terá que forçar os seus clientes de rede usarem o seu DNS)
> - Usar um redir da vida (fica transparente para os clientes)
>
> instala o rinetd (/usr/ports/net/rinetd), e configura o arquivo de 
> configuração:
>
> # echo '127.0.0.1 10080 192.168.0.x 80' >> /usr/local/etc/rinetd.conf
> # echo 'rinetd_enable="YES"' >> /etc/rc.conf
> # /usr/local/etc/rc.d/rinetd start
> * Onde 192.168.0.x é o ip do servidor interno para acesso através dos 
> clientes.
>
> criar uma regra de firewall:
>
> IPFW:
> # ipfw add 100 fwd 127.0.0.1,10080 tcp from 192.168.0.0/24 to
> 200.x.x.x 80 (me corrijam se tiver errado, tem um bom tempo que não
> uso ipfw)
> PF:
> # rdr on $if_int proto tcp from 192.168.0.0/24 to 200.x.x.x port 80 ->
> 127.0.0.1 port 10080
>
> pronto, fica transparente para os clientes
>
> É bonito isso ??? não, não acho, mas é mais funcional do que usar
> views do bind e outra, seria bonito se o conceito de DMZ realmente
> fosse usado, servidor em uma classe de ip diferente da lan, via outra
> interface ou vlan... mas como eu disse em um email anterior... nem
> sempre o mundo é perfeito !
>
> é isso...
>
>
> Em 9 de junho de 2010 14:55, Luan Tasca - FUG  escreveu:
>   
>> Marco Botelho wrote:
>> 
>>> Luiz, bom dia!
>>>
>>> Independente do endereçamento IP do DNS, seja privado ou público, ou mesmo
>>> cliente móvel ou fixo em sua rede LAN, ele deveria configurar o DNS para
>>> responder conforme a origem do resolver, utilizando para isto views. Com
>>> esta sugestão ele resolveria a parte do problema referente a resolução de
>>> nomes interna ou externa.
>>>
>>> Fazendo desta forma não haverá necessidade de fazer redirecionamento de LAN
>>> para LAN. Os clientes internos e o servidor estão na mesma rede, só não
>>> sabem disso. :)
>>>
>>> Isto foi o que entendi do esquema de rede passado anteriormente. Minhas
>>> observações nesta thread são referentes ao redirecionamento de LAN para LAN.
>>> As conexões externas, originadas na Internet, ele terá que continuar a fazer
>>> o redirecionamento para o servidor interno.
>>>
>>> Até mais.
>>>
>>> Marco Botelho
>>> http://twitter.com/botelho
>>>
>>> Em 9 de junho de 2010 01:08, Luiz Gustavo S. Costa <
>>> luizgust...@luizgustavo.pro.br> escreveu:
>>>
>>>
>>>   
 Boa noite !...

 vamos lá, como já dizia o famoso "Jack", vamos por partes

 Marco, concordo e não concordo (explica tudo né :p)... assim

 Fazer o redirecionamento através de views ou outra coisa qualquer
 relativo a DNS é a solução perfeita ?... não, definitamente.. o mundo
 não é tão perfeito assim, pelo o que eu entendi do email anterior do
 colega em relação a duvida, o email do Mario tem sua funcionalidade,
 veja bem, vou destacar que o que eu entendi, é que existem DUAS redes
 diferentes, entre a LAN e a DMZ e não MESMA REDE (o que torna o
 firewall um roteador entre essas redes, portanto, passa tudo por ele),
 como voce recomenda na leitura do RDR (eu já chego ai e te explico que
 mesmo nessa situação o DNS não é o mundo perfeito.). Portanto, efetuar
 um rdr a partir da interface LAN de uma rede completamente diferente
 da DMZ para a DMZ em si é totalmente valido e a principio não vejo
 problemas para aplicar tal regra.

 Bom, agora vamos supor que as redes são iguais, algo como:

 1 - IP do cliente = 192.168.1.50
 2 - IP do gateway (fw) = 192.168.1.1
 3 - IP do Servidors = 192.168.1.100 (200.x.x.1 via rdr no fw)

 Fica claro ai que se o cliente requisitar uma conexao para 200.x.x.1 e
 existir o rdr no firewall, ele ate vai redirecionar, mas vai haver
 confusão no momento da resposta, já que o cliente esta na mesma rede
 do servidor, etc... isso é visivel e teoricamente um DNS view
 resolveria o problema em parte, resolvendo o nome do serviço com o IP
 direto do servidor.

 Porque digo "em parte" ? ... bom, ai entra a questão do DNS, imagine
 uma situação de um cliente da rede que utilize notebook, como ele é
 movel, precisa estar conectado em varios tipos de redes diferentes.. e
 conheço muita gente que deixa um ip de dns publico já configurado no
 mesmo. Conclusão: isso falharia para o caso do DNS, já que exige que a
 maquina tenha o DNS que contenha as views.

 Portanto, dependendo do caso (já tive que fazer isso e ainda bem que
 existem ferramentas assim), tive que fazer escutar o serviço no
 firewall, para redirecionar para o servidor. Para esses casos, existe
 essas ferramentas:

 [r...@desktop] /usr/ports/net/rinetd# cat pkg-descr
 rinetd redirects TCP connections from one IP address and port to another.
 rinetd is a single-process server which ha

Re: [FUG-BR] DNS

[Luiz Gustavo S. Costa]

Então, duas opções:

- Dns views (terá que forçar os seus clientes de rede usarem o seu DNS)
- Usar um redir da vida (fica transparente para os clientes)

instala o rinetd (/usr/ports/net/rinetd), e configura o arquivo de configuração:

# echo '127.0.0.1 10080 192.168.0.x 80' >> /usr/local/etc/rinetd.conf
# echo 'rinetd_enable="YES"' >> /etc/rc.conf
# /usr/local/etc/rc.d/rinetd start
* Onde 192.168.0.x é o ip do servidor interno para acesso através dos clientes.

criar uma regra de firewall:

IPFW:
# ipfw add 100 fwd 127.0.0.1,10080 tcp from 192.168.0.0/24 to
200.x.x.x 80 (me corrijam se tiver errado, tem um bom tempo que não
uso ipfw)
PF:
# rdr on $if_int proto tcp from 192.168.0.0/24 to 200.x.x.x port 80 ->
127.0.0.1 port 10080

pronto, fica transparente para os clientes

É bonito isso ??? não, não acho, mas é mais funcional do que usar
views do bind e outra, seria bonito se o conceito de DMZ realmente
fosse usado, servidor em uma classe de ip diferente da lan, via outra
interface ou vlan... mas como eu disse em um email anterior... nem
sempre o mundo é perfeito !

é isso...


Em 9 de junho de 2010 14:55, Luan Tasca - FUG  escreveu:
> Marco Botelho wrote:
>> Luiz, bom dia!
>>
>> Independente do endereçamento IP do DNS, seja privado ou público, ou mesmo
>> cliente móvel ou fixo em sua rede LAN, ele deveria configurar o DNS para
>> responder conforme a origem do resolver, utilizando para isto views. Com
>> esta sugestão ele resolveria a parte do problema referente a resolução de
>> nomes interna ou externa.
>>
>> Fazendo desta forma não haverá necessidade de fazer redirecionamento de LAN
>> para LAN. Os clientes internos e o servidor estão na mesma rede, só não
>> sabem disso. :)
>>
>> Isto foi o que entendi do esquema de rede passado anteriormente. Minhas
>> observações nesta thread são referentes ao redirecionamento de LAN para LAN.
>> As conexões externas, originadas na Internet, ele terá que continuar a fazer
>> o redirecionamento para o servidor interno.
>>
>> Até mais.
>>
>> Marco Botelho
>> http://twitter.com/botelho
>>
>> Em 9 de junho de 2010 01:08, Luiz Gustavo S. Costa <
>> luizgust...@luizgustavo.pro.br> escreveu:
>>
>>
>>> Boa noite !...
>>>
>>> vamos lá, como já dizia o famoso "Jack", vamos por partes
>>>
>>> Marco, concordo e não concordo (explica tudo né :p)... assim
>>>
>>> Fazer o redirecionamento através de views ou outra coisa qualquer
>>> relativo a DNS é a solução perfeita ?... não, definitamente.. o mundo
>>> não é tão perfeito assim, pelo o que eu entendi do email anterior do
>>> colega em relação a duvida, o email do Mario tem sua funcionalidade,
>>> veja bem, vou destacar que o que eu entendi, é que existem DUAS redes
>>> diferentes, entre a LAN e a DMZ e não MESMA REDE (o que torna o
>>> firewall um roteador entre essas redes, portanto, passa tudo por ele),
>>> como voce recomenda na leitura do RDR (eu já chego ai e te explico que
>>> mesmo nessa situação o DNS não é o mundo perfeito.). Portanto, efetuar
>>> um rdr a partir da interface LAN de uma rede completamente diferente
>>> da DMZ para a DMZ em si é totalmente valido e a principio não vejo
>>> problemas para aplicar tal regra.
>>>
>>> Bom, agora vamos supor que as redes são iguais, algo como:
>>>
>>> 1 - IP do cliente = 192.168.1.50
>>> 2 - IP do gateway (fw) = 192.168.1.1
>>> 3 - IP do Servidors = 192.168.1.100 (200.x.x.1 via rdr no fw)
>>>
>>> Fica claro ai que se o cliente requisitar uma conexao para 200.x.x.1 e
>>> existir o rdr no firewall, ele ate vai redirecionar, mas vai haver
>>> confusão no momento da resposta, já que o cliente esta na mesma rede
>>> do servidor, etc... isso é visivel e teoricamente um DNS view
>>> resolveria o problema em parte, resolvendo o nome do serviço com o IP
>>> direto do servidor.
>>>
>>> Porque digo "em parte" ? ... bom, ai entra a questão do DNS, imagine
>>> uma situação de um cliente da rede que utilize notebook, como ele é
>>> movel, precisa estar conectado em varios tipos de redes diferentes.. e
>>> conheço muita gente que deixa um ip de dns publico já configurado no
>>> mesmo. Conclusão: isso falharia para o caso do DNS, já que exige que a
>>> maquina tenha o DNS que contenha as views.
>>>
>>> Portanto, dependendo do caso (já tive que fazer isso e ainda bem que
>>> existem ferramentas assim), tive que fazer escutar o serviço no
>>> firewall, para redirecionar para o servidor. Para esses casos, existe
>>> essas ferramentas:
>>>
>>> [r...@desktop] /usr/ports/net/rinetd# cat pkg-descr
>>> rinetd redirects TCP connections from one IP address and port to another.
>>> rinetd is a single-process server which handles any number of connections
>>> to
>>> the address/port pairs specified in the file /etc/rinetd.conf. Since rinetd
>>> runs as a single process using nonblocking I/O, it is able to redirect a
>>> large number of connections without a severe impact on the machine. This
>>> makes it practical to run TCP services on machines inside an IP
>>> masquerading
>>> firewall. rinet

Re: [FUG-BR] DNS

[Luan Tasca - FUG]

Marco Botelho wrote:
> Luiz, bom dia!
>
> Independente do endereçamento IP do DNS, seja privado ou público, ou mesmo
> cliente móvel ou fixo em sua rede LAN, ele deveria configurar o DNS para
> responder conforme a origem do resolver, utilizando para isto views. Com
> esta sugestão ele resolveria a parte do problema referente a resolução de
> nomes interna ou externa.
>
> Fazendo desta forma não haverá necessidade de fazer redirecionamento de LAN
> para LAN. Os clientes internos e o servidor estão na mesma rede, só não
> sabem disso. :)
>
> Isto foi o que entendi do esquema de rede passado anteriormente. Minhas
> observações nesta thread são referentes ao redirecionamento de LAN para LAN.
> As conexões externas, originadas na Internet, ele terá que continuar a fazer
> o redirecionamento para o servidor interno.
>
> Até mais.
>
> Marco Botelho
> http://twitter.com/botelho
>
> Em 9 de junho de 2010 01:08, Luiz Gustavo S. Costa <
> luizgust...@luizgustavo.pro.br> escreveu:
>
>   
>> Boa noite !...
>>
>> vamos lá, como já dizia o famoso "Jack", vamos por partes
>>
>> Marco, concordo e não concordo (explica tudo né :p)... assim
>>
>> Fazer o redirecionamento através de views ou outra coisa qualquer
>> relativo a DNS é a solução perfeita ?... não, definitamente.. o mundo
>> não é tão perfeito assim, pelo o que eu entendi do email anterior do
>> colega em relação a duvida, o email do Mario tem sua funcionalidade,
>> veja bem, vou destacar que o que eu entendi, é que existem DUAS redes
>> diferentes, entre a LAN e a DMZ e não MESMA REDE (o que torna o
>> firewall um roteador entre essas redes, portanto, passa tudo por ele),
>> como voce recomenda na leitura do RDR (eu já chego ai e te explico que
>> mesmo nessa situação o DNS não é o mundo perfeito.). Portanto, efetuar
>> um rdr a partir da interface LAN de uma rede completamente diferente
>> da DMZ para a DMZ em si é totalmente valido e a principio não vejo
>> problemas para aplicar tal regra.
>>
>> Bom, agora vamos supor que as redes são iguais, algo como:
>>
>> 1 - IP do cliente = 192.168.1.50
>> 2 - IP do gateway (fw) = 192.168.1.1
>> 3 - IP do Servidors = 192.168.1.100 (200.x.x.1 via rdr no fw)
>>
>> Fica claro ai que se o cliente requisitar uma conexao para 200.x.x.1 e
>> existir o rdr no firewall, ele ate vai redirecionar, mas vai haver
>> confusão no momento da resposta, já que o cliente esta na mesma rede
>> do servidor, etc... isso é visivel e teoricamente um DNS view
>> resolveria o problema em parte, resolvendo o nome do serviço com o IP
>> direto do servidor.
>>
>> Porque digo "em parte" ? ... bom, ai entra a questão do DNS, imagine
>> uma situação de um cliente da rede que utilize notebook, como ele é
>> movel, precisa estar conectado em varios tipos de redes diferentes.. e
>> conheço muita gente que deixa um ip de dns publico já configurado no
>> mesmo. Conclusão: isso falharia para o caso do DNS, já que exige que a
>> maquina tenha o DNS que contenha as views.
>>
>> Portanto, dependendo do caso (já tive que fazer isso e ainda bem que
>> existem ferramentas assim), tive que fazer escutar o serviço no
>> firewall, para redirecionar para o servidor. Para esses casos, existe
>> essas ferramentas:
>>
>> [r...@desktop] /usr/ports/net/rinetd# cat pkg-descr
>> rinetd redirects TCP connections from one IP address and port to another.
>> rinetd is a single-process server which handles any number of connections
>> to
>> the address/port pairs specified in the file /etc/rinetd.conf. Since rinetd
>> runs as a single process using nonblocking I/O, it is able to redirect a
>> large number of connections without a severe impact on the machine. This
>> makes it practical to run TCP services on machines inside an IP
>> masquerading
>> firewall. rinetd does not redirect FTP, because FTP requires more than one
>> socket.
>>
>> rinetd also supports basic allow/deny access control and logging.
>>
>> [r...@desktop] /usr/ports/net/redir# cat pkg-descr
>> Redir is a port redirector. It can run under inetd or standalone. Redir
>> also supports tcp wrappers.
>>
>> WWW: http://sammy.net/~sammy/hacks/ 
>>
>> Não é muito bonito ter que recorrer a isso, mas quebra o galho quando
>> o cenário não ajuda muito e é inevitavel que tenha que colocar redes
>> diferentes ou mesmo configurar uma vlan e não vai ter jeito, sendo o
>> firewall o gateway da rede, a requisição vai ter que passar por ele !
>>
>> é isso
>>
>> abraços
>>
>>
>> Em 9 de junho de 2010 02:26, Marco Botelho 
>> escreveu:
>> 
 On Tuesday 08 June 2010 23:11:20 Marco Botelho wrote:
 
> Boa noite!
>
> Na minha opinião, não faz muito sentido você usar uma solução de
> redirecionamento onde servidor e clientes estão no mesmo segmento de
>   
 rede.
 
> Basta uma resolução de nome correta para seus clientes. Nesta solução
>   
>> de
>> 
> redirecionamento, você está deixando seus clientes ire

Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( I PFW + SQUID )

[CPD]

Olá Rodrigo, bom dia...

Então.. estou usando o mesmo Kernel GENERIC do cd de instalação do FreeBSD 
8.0
só que com algumas modificações para o IPFW funcionar com o SQUID e alguns 
dispositivos
como ISA, Wireless, etc, desabilitados, porém o erro está dando em 
dispositivos que não possuo,
e foram desabilitados do Kernel.

Tentei recompilar o mesmo Kernel GENERIC do cd de instalação somente com as 
linhas sobre o IPFW
pra ver se conseguia, mesmo assim o erro persistiu.

Eu acho que devo estar fazendo algo errado no processo.

Se alguem puder me auxiliar no "passo a passo" ficaria grato.

Acho que precisa dar um clean no esquema e começar de novo... mas acho que 
não to sabendo onde dar esse clean, ou
pra ser mais especifico.. as pastas para dar o CONFIG, MAKE DEPEND e o tal 
do MAKE

O erro esta dando sempre no make...

Abraço


- Original Message - 
From: "Rodrigo" 
To: ""Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"" 

Sent: Tuesday, June 08, 2010 4:58 PM
Subject: Re: [FUG-BR] COMPILAÇÃO KERNEL FREEBSD 8.0 ( IPFW + SQUID )


Olá Amigo boa tarde, passei por um problema parecido uma vez...

O que aconteceu comigo foi o seguinte eu estava tentando recompilar uma
versao de um kernel "IA64", enquanto estava usando um "AMD64", isso foi
um total descuido meu, pode ser que seja esse o seu problema, verifique
se não pode ser isso.

Att,
Rodrigo
-
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] Controladora HP Smart Array P410

[Ari Arantes Filho]

Pessoal,

Bom dia.

Estamos avaliando a compra de um servidor HP que vem com a placa
controladora Smart Array P410. Vi na HCL que é suportada pelo FreeBSD
normalmente, mas gostaria de saber se alguém já usa essa placa e se
der problema em algum HD do RAID ou se sacar algum HD, a máquina avisa
no dmesg ou algo assim? Pois com servidores IBM, se sacar algum HD do
RAID, por exemplo, o sistema continua funcionando, mas nenhuma
mensagem é enviada ao dmesg e é transparente p/ o FreeBSD. Isso é
muito perigoso, pois a máquina fica no datacenter e não tem gente
olhando direto para o servidor...

Obrigado,

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