[FUG-BR] Problema com ftp

2008-11-28 Por tôpico Diego Bulsing
Boa noite a todos,

estou com um problema a respeito do maldito ftp, o velho problema de
não listar arquivos.
Tentei usar tanto o ftp-proxy quanto o pftpx, mas nenhum dos dois deu liga.

No cliente do windows aparece a seguinte mensagem quando eu vou listar arquivos:

200 PORT Command Successful.
500 'ST':command not understood.

Tive este problema com algusn servidores, mas todos foram resolvidos,
este que esta me dando dor de cabeça.

Se alguem tiver alguma luz eu agradeço.

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


Re: [FUG-BR] Tag Vlan

2008-11-28 Por tôpico Andrez
Marcelo,
Os IPs que estão na sk0 estão perfeitos. Ele já existia e estou precisando
colocar mais um link nela.

A porta do switch tem uma vlan ( 200 ) untagged e agora quero colocar uma
tagged ( 60 ). O switch não deixa eu ter 2 vlans untagged na mesma porta.
Então minha primeira escolha é usar como está agora, uma tagged e outra
untagged. É a menor modificação possível que encontrei.

O lance é que parece que o FreeBSD nem tenta achar o outro. O Network
Unrecheable é que tá pegando.


Cada uma das redes é uma rede ( L3 ) distinta mas no mesmo L2. Esse L2 está
de baixo de uma rede radois com vários condominios, sendo cada condominio
uma rede. Isso ficou assim porque os clientes configuram os IPs manualmente,
por isso nem ao mesmo posso juntas as redes em /23. Isso tá sendo mudado.


2008/11/28 Marcelo Veriato Lima <[EMAIL PROTECTED]>

>   agora vi o teu ifconfig com mais calma
>   seguinte
>   tu esta fazendo a sk0 falar o tag 60 pela interface vlan60 e tem varios
>   ips que estao diretamente na sk0, ou tu configura uma native vlan na
>   porta do switch para pacotes sem tag (por padrao a native vlan 'e o tag
>   1) ou cria outras vlans que seria o mais coerente, curiosidade, cada
>   uma das redes 10.x.x.x 'e um link diferente? Caso sim, crie uma vlan
>   para cada link ou se o teu switch suportar private-vlans melhor ainda.
> --
> Marcelo Veriato Lima
> Analista de Redes e Telecomunicações Senior
> Administração de Infra-estrutura de TI
> Confederação SICREDI - Porto Alegre
> +55 (51) 3358-8355
> [1]http://www.sicredi.com.br
>
>   Andrez wrote:
>
> Está sim.
> Com tcpdump os pacotes chegam "tageados".
>
> 2008/11/28 Marcelo Veriato Lima [2]<[EMAIL PROTECTED]>
>
>
> a porta do switch onde este teu freebsd esta conectado esta falando
> 802.1q? (trunk no caso de cisco, tagged para demais)
>
> --
> Marcelo Veriato Lima
> Analista de Redes e Telecomunicações Senior
> Administração de Infra-estrutura de TI
> Confederação SICREDI - Porto Alegre
> +55 (51) 3358-8355
> [3]http://www.sicredi.com.br
>
>
>
>
> Andrez wrote:
>
> Pessoal,
> Tô precisando de uma forma. Fui surrado hoje pelas vlans :).
>
> Seguinte.
>
> A melhor saida pra um problema que tenho é usar vlan ( 802.1q). Até os 5
> primeiros minutos eu tava batendo. configurei a vlan em 3 equipamentos no
> FreeBSD ( 7.0 ). Beleza!!! Bem facinho. Ai o jogo virou.
>
> * Garanto que nos equipaqmentos está certo.
> * Juro que fiz do jeito do man ( ifconfig e vlan ), e de mais uns vinte
> sites.
> * A um aprende o mac do outro ( arp )
>
> * Mas num ping nem a pau.
>
> Fiz isso aqui:
>
> kame# ifconfig vlan60 create vlan 60 vlandev sk0
> kame# ifconfig vlan60 172.16.128.150/30
> kame# ifconfig
> bge0: flags=8843 metric 0 mtu
>
> 1500
>
> options=9b
> ether 00:1a:64:1f:07:7e
> inet 172.16.128.28 netmask 0xff80 broadcast 172.16.128.127
> media: Ethernet autoselect (1000baseTX )
> status: active
> sk0: flags=8843 metric 0 mtu 1500
> options=b
> ether 00:17:9a:7a:69:ab
> inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255
> inet 10.5.0.1 netmask 0xff00 broadcast 10.5.0.255
> inet 10.10.1.1 netmask 0xff00 broadcast 10.10.1.255
> inet 10.20.0.1 netmask 0xff00 broadcast 10.20.0.255
> inet 10.20.1.1 netmask 0xff00 broadcast 10.20.1.255
> inet 10.30.0.1 netmask 0xff00 broadcast 10.30.0.255
> inet 10.30.1.1 netmask 0xff00 broadcast 10.30.1.255
> inet 10.30.2.1 netmask 0xff00 broadcast 10.30.2.255
> inet 10.70.0.1 netmask 0xff00 broadcast 10.70.0.255
> inet 10.70.1.1 netmask 0xff00 broadcast 10.70.1.255
> inet 10.89.0.1 netmask 0xff00 broadcast 10.89.0.255
> inet 10.99.0.1 netmask 0xff00 broadcast 10.99.0.255
> inet 10.199.0.1 netmask 0xff00 broadcast 10.199.0.255
> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
> inet 192.168.13.1 netmask 0xff00 broadcast 192.168.13.255
> media: Ethernet autoselect (1000baseTX )
> status: active
> lo0: flags=8049 metric 0 mtu 16384
> inet 127.0.0.1 netmask 0xff00
> vlan60: flags=8843 metric 0 mtu
>
> 1500
>
> ether 00:17:9a:7a:69:ab
> inet 172.16.128.150 netmask 0xfffc broadcast 172.16.128.151
> media: Ethernet autoselect (1000baseTX )
> status: active
> vlan: 60 parent interface: sk0
>
> ( sei que a sk0 tá linda, não precisa chingar. ela vai melhorar em breve
>
> )
>
> Quando tento pingar:
>
> kame# ping 172.16.128.149
> PING 172.16.128.149 (172.16.128.149): 56 data bytes
> ping: sendto: Network is unreachable
> ping: sendto: Network is unreachable
> ping: sendto: Network is unreachable
> ^C
> --- 172.16.128.149 ping statistics ---
> 3 packets transmitted, 0 packets received, 100.0% packet loss
>
> Deve ter perdido alguma coisa. To fazendo alguma grande?
>
> Segunda coisa.
>
> Investigando isso esbarrei nisso aqui:
>
> kame# netstat -nrss
> routing:
> 10683 destinations found unreachable
> 1 route not in table but not freed
>
> Não to achando nada sobre a última linha. Alguém tem uma dica?
>
> Valeu.
>
>
>
> As informacoes contidas neste e-mail e anex

Re: [FUG-BR] Tag Vlan

2008-11-28 Por tôpico Marcelo Veriato Lima
   agora vi o teu ifconfig com mais calma
   seguinte
   tu esta fazendo a sk0 falar o tag 60 pela interface vlan60 e tem varios
   ips que estao diretamente na sk0, ou tu configura uma native vlan na
   porta do switch para pacotes sem tag (por padrao a native vlan 'e o tag
   1) ou cria outras vlans que seria o mais coerente, curiosidade, cada
   uma das redes 10.x.x.x 'e um link diferente? Caso sim, crie uma vlan
   para cada link ou se o teu switch suportar private-vlans melhor ainda.
--
Marcelo Veriato Lima
Analista de Redes e Telecomunicações Senior
Administração de Infra-estrutura de TI
Confederação SICREDI - Porto Alegre
+55 (51) 3358-8355
[1]http://www.sicredi.com.br

   Andrez wrote:

Está sim.
Com tcpdump os pacotes chegam "tageados".

2008/11/28 Marcelo Veriato Lima [2]<[EMAIL PROTECTED]>


a porta do switch onde este teu freebsd esta conectado esta falando
802.1q? (trunk no caso de cisco, tagged para demais)

--
Marcelo Veriato Lima
Analista de Redes e Telecomunicações Senior
Administração de Infra-estrutura de TI
Confederação SICREDI - Porto Alegre
+55 (51) 3358-8355
[3]http://www.sicredi.com.br




Andrez wrote:

Pessoal,
Tô precisando de uma forma. Fui surrado hoje pelas vlans :).

Seguinte.

A melhor saida pra um problema que tenho é usar vlan ( 802.1q). Até os 5
primeiros minutos eu tava batendo. configurei a vlan em 3 equipamentos no
FreeBSD ( 7.0 ). Beleza!!! Bem facinho. Ai o jogo virou.

* Garanto que nos equipaqmentos está certo.
* Juro que fiz do jeito do man ( ifconfig e vlan ), e de mais uns vinte
sites.
* A um aprende o mac do outro ( arp )

* Mas num ping nem a pau.

Fiz isso aqui:

kame# ifconfig vlan60 create vlan 60 vlandev sk0
kame# ifconfig vlan60 172.16.128.150/30
kame# ifconfig
bge0: flags=8843 metric 0 mtu

1500

options=9b
ether 00:1a:64:1f:07:7e
inet 172.16.128.28 netmask 0xff80 broadcast 172.16.128.127
media: Ethernet autoselect (1000baseTX )
status: active
sk0: flags=8843 metric 0 mtu 1500
options=b
ether 00:17:9a:7a:69:ab
inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255
inet 10.5.0.1 netmask 0xff00 broadcast 10.5.0.255
inet 10.10.1.1 netmask 0xff00 broadcast 10.10.1.255
inet 10.20.0.1 netmask 0xff00 broadcast 10.20.0.255
inet 10.20.1.1 netmask 0xff00 broadcast 10.20.1.255
inet 10.30.0.1 netmask 0xff00 broadcast 10.30.0.255
inet 10.30.1.1 netmask 0xff00 broadcast 10.30.1.255
inet 10.30.2.1 netmask 0xff00 broadcast 10.30.2.255
inet 10.70.0.1 netmask 0xff00 broadcast 10.70.0.255
inet 10.70.1.1 netmask 0xff00 broadcast 10.70.1.255
inet 10.89.0.1 netmask 0xff00 broadcast 10.89.0.255
inet 10.99.0.1 netmask 0xff00 broadcast 10.99.0.255
inet 10.199.0.1 netmask 0xff00 broadcast 10.199.0.255
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
inet 192.168.13.1 netmask 0xff00 broadcast 192.168.13.255
media: Ethernet autoselect (1000baseTX )
status: active
lo0: flags=8049 metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff00
vlan60: flags=8843 metric 0 mtu

1500

ether 00:17:9a:7a:69:ab
inet 172.16.128.150 netmask 0xfffc broadcast 172.16.128.151
media: Ethernet autoselect (1000baseTX )
status: active
vlan: 60 parent interface: sk0

( sei que a sk0 tá linda, não precisa chingar. ela vai melhorar em breve

)

Quando tento pingar:

kame# ping 172.16.128.149
PING 172.16.128.149 (172.16.128.149): 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
^C
--- 172.16.128.149 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Deve ter perdido alguma coisa. To fazendo alguma grande?

Segunda coisa.

Investigando isso esbarrei nisso aqui:

kame# netstat -nrss
routing:
10683 destinations found unreachable
1 route not in table but not freed

Não to achando nada sobre a última linha. Alguém tem uma dica?

Valeu.



As informacoes contidas neste e-mail e anexos podem ser confidenciais e
privilegiadas, protegidas por sigilo legal. Qualquer forma de utilizacao
deste documento depende de autorizacao do emissor, sujeito as penalidades
cabiveis. O emissor utiliza o recurso somente para fins profissionais,
eximindo o empregador de responsabilidades por uso pessoal ou improprio. Se
esta mensagem foi recebida por engano, o conteudo deve ser apagado e o
remetente avisado imediatamente, atraves de resposta a este e-mail.
-
Histórico: [4]http://www.fug.com.br/historico/html/freebsd/
Sair da lista: [5]https://www.fug.com.br/mailman/listinfo/freebsd





As informacoes contidas neste e-mail e anexos podem ser confidenciais e privileg
iadas, protegidas por sigilo legal. Qualquer forma de utilizacao deste documento
 depende de autorizacao do emissor, sujeito as penalidades cabiveis. O emissor u
tiliza o recurso somente para fins profissionais, eximindo o empregador de respo
nsabilidades por uso pessoal ou improprio. Se esta mensagem foi recebida por eng
ano, o conteudo deve ser apagado e o remetente avi

Re: [FUG-BR] Tag Vlan

2008-11-28 Por tôpico Andrez
Está sim.
Com tcpdump os pacotes chegam "tageados".

2008/11/28 Marcelo Veriato Lima <[EMAIL PROTECTED]>

> a porta do switch onde este teu freebsd esta conectado esta falando
> 802.1q? (trunk no caso de cisco, tagged para demais)
>
> --
> Marcelo Veriato Lima
> Analista de Redes e Telecomunicações Senior
> Administração de Infra-estrutura de TI
> Confederação SICREDI – Porto Alegre
> +55 (51) 3358-8355
> http://www.sicredi.com.br
>
>
>
>
> Andrez wrote:
> > Pessoal,
> > Tô precisando de uma forma. Fui surrado hoje pelas vlans :).
> >
> > Seguinte.
> >
> > A melhor saida pra um problema que tenho é usar vlan ( 802.1q). Até os 5
> > primeiros minutos eu tava batendo. configurei a vlan em 3 equipamentos no
> > FreeBSD ( 7.0 ). Beleza!!! Bem facinho. Ai o jogo virou.
> >
> > * Garanto que nos equipaqmentos está certo.
> > * Juro que fiz do jeito do man ( ifconfig e vlan ), e de mais uns vinte
> > sites.
> > * A um aprende o mac do outro ( arp )
> >
> > * Mas num ping nem a pau.
> >
> > Fiz isso aqui:
> >
> > kame# ifconfig vlan60 create vlan 60 vlandev sk0
> > kame# ifconfig vlan60 172.16.128.150/30
> > kame# ifconfig
> > bge0: flags=8843 metric 0 mtu
> 1500
> > options=9b
> > ether 00:1a:64:1f:07:7e
> > inet 172.16.128.28 netmask 0xff80 broadcast 172.16.128.127
> > media: Ethernet autoselect (1000baseTX )
> > status: active
> > sk0: flags=8843 metric 0 mtu 1500
> > options=b
> > ether 00:17:9a:7a:69:ab
> > inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255
> > inet 10.5.0.1 netmask 0xff00 broadcast 10.5.0.255
> > inet 10.10.1.1 netmask 0xff00 broadcast 10.10.1.255
> > inet 10.20.0.1 netmask 0xff00 broadcast 10.20.0.255
> > inet 10.20.1.1 netmask 0xff00 broadcast 10.20.1.255
> > inet 10.30.0.1 netmask 0xff00 broadcast 10.30.0.255
> > inet 10.30.1.1 netmask 0xff00 broadcast 10.30.1.255
> > inet 10.30.2.1 netmask 0xff00 broadcast 10.30.2.255
> > inet 10.70.0.1 netmask 0xff00 broadcast 10.70.0.255
> > inet 10.70.1.1 netmask 0xff00 broadcast 10.70.1.255
> > inet 10.89.0.1 netmask 0xff00 broadcast 10.89.0.255
> > inet 10.99.0.1 netmask 0xff00 broadcast 10.99.0.255
> > inet 10.199.0.1 netmask 0xff00 broadcast 10.199.0.255
> > inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
> > inet 192.168.13.1 netmask 0xff00 broadcast 192.168.13.255
> > media: Ethernet autoselect (1000baseTX )
> > status: active
> > lo0: flags=8049 metric 0 mtu 16384
> > inet 127.0.0.1 netmask 0xff00
> > vlan60: flags=8843 metric 0 mtu
> 1500
> > ether 00:17:9a:7a:69:ab
> > inet 172.16.128.150 netmask 0xfffc broadcast 172.16.128.151
> > media: Ethernet autoselect (1000baseTX )
> > status: active
> > vlan: 60 parent interface: sk0
> >
> > ( sei que a sk0 tá linda, não precisa chingar. ela vai melhorar em breve
> )
> >
> > Quando tento pingar:
> >
> > kame# ping 172.16.128.149
> > PING 172.16.128.149 (172.16.128.149): 56 data bytes
> > ping: sendto: Network is unreachable
> > ping: sendto: Network is unreachable
> > ping: sendto: Network is unreachable
> > ^C
> > --- 172.16.128.149 ping statistics ---
> > 3 packets transmitted, 0 packets received, 100.0% packet loss
> >
> > Deve ter perdido alguma coisa. To fazendo alguma grande?
> >
> > Segunda coisa.
> >
> > Investigando isso esbarrei nisso aqui:
> >
> > kame# netstat -nrss
> > routing:
> > 10683 destinations found unreachable
> > 1 route not in table but not freed
> >
> > Não to achando nada sobre a última linha. Alguém tem uma dica?
> >
> > Valeu.
> >
> >
>
>
> As informacoes contidas neste e-mail e anexos podem ser confidenciais e
> privilegiadas, protegidas por sigilo legal. Qualquer forma de utilizacao
> deste documento depende de autorizacao do emissor, sujeito as penalidades
> cabiveis. O emissor utiliza o recurso somente para fins profissionais,
> eximindo o empregador de responsabilidades por uso pessoal ou improprio. Se
> esta mensagem foi recebida por engano, o conteudo deve ser apagado e o
> remetente avisado imediatamente, atraves de resposta a este e-mail.
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



-- 
Atenciosamente.
Eduardo Andrez de Oliveira.
_
°v°
/(_)\
^ ^
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] Tag Vlan

2008-11-28 Por tôpico Marcelo Veriato Lima
a porta do switch onde este teu freebsd esta conectado esta falando 
802.1q? (trunk no caso de cisco, tagged para demais)

-- 
Marcelo Veriato Lima
Analista de Redes e Telecomunicações Senior
Administração de Infra-estrutura de TI
Confederação SICREDI – Porto Alegre
+55 (51) 3358-8355
http://www.sicredi.com.br




Andrez wrote:
> Pessoal,
> Tô precisando de uma forma. Fui surrado hoje pelas vlans :).
>
> Seguinte.
>
> A melhor saida pra um problema que tenho é usar vlan ( 802.1q). Até os 5
> primeiros minutos eu tava batendo. configurei a vlan em 3 equipamentos no
> FreeBSD ( 7.0 ). Beleza!!! Bem facinho. Ai o jogo virou.
>
> * Garanto que nos equipaqmentos está certo.
> * Juro que fiz do jeito do man ( ifconfig e vlan ), e de mais uns vinte
> sites.
> * A um aprende o mac do outro ( arp )
>
> * Mas num ping nem a pau.
>
> Fiz isso aqui:
>
> kame# ifconfig vlan60 create vlan 60 vlandev sk0
> kame# ifconfig vlan60 172.16.128.150/30
> kame# ifconfig
> bge0: flags=8843 metric 0 mtu 1500
> options=9b
> ether 00:1a:64:1f:07:7e
> inet 172.16.128.28 netmask 0xff80 broadcast 172.16.128.127
> media: Ethernet autoselect (1000baseTX )
> status: active
> sk0: flags=8843 metric 0 mtu 1500
> options=b
> ether 00:17:9a:7a:69:ab
> inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255
> inet 10.5.0.1 netmask 0xff00 broadcast 10.5.0.255
> inet 10.10.1.1 netmask 0xff00 broadcast 10.10.1.255
> inet 10.20.0.1 netmask 0xff00 broadcast 10.20.0.255
> inet 10.20.1.1 netmask 0xff00 broadcast 10.20.1.255
> inet 10.30.0.1 netmask 0xff00 broadcast 10.30.0.255
> inet 10.30.1.1 netmask 0xff00 broadcast 10.30.1.255
> inet 10.30.2.1 netmask 0xff00 broadcast 10.30.2.255
> inet 10.70.0.1 netmask 0xff00 broadcast 10.70.0.255
> inet 10.70.1.1 netmask 0xff00 broadcast 10.70.1.255
> inet 10.89.0.1 netmask 0xff00 broadcast 10.89.0.255
> inet 10.99.0.1 netmask 0xff00 broadcast 10.99.0.255
> inet 10.199.0.1 netmask 0xff00 broadcast 10.199.0.255
> inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
> inet 192.168.13.1 netmask 0xff00 broadcast 192.168.13.255
> media: Ethernet autoselect (1000baseTX )
> status: active
> lo0: flags=8049 metric 0 mtu 16384
> inet 127.0.0.1 netmask 0xff00
> vlan60: flags=8843 metric 0 mtu 1500
> ether 00:17:9a:7a:69:ab
> inet 172.16.128.150 netmask 0xfffc broadcast 172.16.128.151
> media: Ethernet autoselect (1000baseTX )
> status: active
> vlan: 60 parent interface: sk0
>
> ( sei que a sk0 tá linda, não precisa chingar. ela vai melhorar em breve )
>
> Quando tento pingar:
>
> kame# ping 172.16.128.149
> PING 172.16.128.149 (172.16.128.149): 56 data bytes
> ping: sendto: Network is unreachable
> ping: sendto: Network is unreachable
> ping: sendto: Network is unreachable
> ^C
> --- 172.16.128.149 ping statistics ---
> 3 packets transmitted, 0 packets received, 100.0% packet loss
>
> Deve ter perdido alguma coisa. To fazendo alguma grande?
>
> Segunda coisa.
>
> Investigando isso esbarrei nisso aqui:
>
> kame# netstat -nrss
> routing:
> 10683 destinations found unreachable
> 1 route not in table but not freed
>
> Não to achando nada sobre a última linha. Alguém tem uma dica?
>
> Valeu.
>
>   


As informacoes contidas neste e-mail e anexos podem ser confidenciais e 
privilegiadas, protegidas por sigilo legal. Qualquer forma de utilizacao deste 
documento depende de autorizacao do emissor, sujeito as penalidades cabiveis. O 
emissor utiliza o recurso somente para fins profissionais, eximindo o 
empregador de responsabilidades por uso pessoal ou improprio. Se esta mensagem 
foi recebida por engano, o conteudo deve ser apagado e o remetente avisado 
imediatamente, atraves de resposta a este e-mail.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


[FUG-BR] Tag Vlan

2008-11-28 Por tôpico Andrez
Pessoal,
Tô precisando de uma forma. Fui surrado hoje pelas vlans :).

Seguinte.

A melhor saida pra um problema que tenho é usar vlan ( 802.1q). Até os 5
primeiros minutos eu tava batendo. configurei a vlan em 3 equipamentos no
FreeBSD ( 7.0 ). Beleza!!! Bem facinho. Ai o jogo virou.

* Garanto que nos equipaqmentos está certo.
* Juro que fiz do jeito do man ( ifconfig e vlan ), e de mais uns vinte
sites.
* A um aprende o mac do outro ( arp )

* Mas num ping nem a pau.

Fiz isso aqui:

kame# ifconfig vlan60 create vlan 60 vlandev sk0
kame# ifconfig vlan60 172.16.128.150/30
kame# ifconfig
bge0: flags=8843 metric 0 mtu 1500
options=9b
ether 00:1a:64:1f:07:7e
inet 172.16.128.28 netmask 0xff80 broadcast 172.16.128.127
media: Ethernet autoselect (1000baseTX )
status: active
sk0: flags=8843 metric 0 mtu 1500
options=b
ether 00:17:9a:7a:69:ab
inet 192.168.100.1 netmask 0xff00 broadcast 192.168.100.255
inet 10.5.0.1 netmask 0xff00 broadcast 10.5.0.255
inet 10.10.1.1 netmask 0xff00 broadcast 10.10.1.255
inet 10.20.0.1 netmask 0xff00 broadcast 10.20.0.255
inet 10.20.1.1 netmask 0xff00 broadcast 10.20.1.255
inet 10.30.0.1 netmask 0xff00 broadcast 10.30.0.255
inet 10.30.1.1 netmask 0xff00 broadcast 10.30.1.255
inet 10.30.2.1 netmask 0xff00 broadcast 10.30.2.255
inet 10.70.0.1 netmask 0xff00 broadcast 10.70.0.255
inet 10.70.1.1 netmask 0xff00 broadcast 10.70.1.255
inet 10.89.0.1 netmask 0xff00 broadcast 10.89.0.255
inet 10.99.0.1 netmask 0xff00 broadcast 10.99.0.255
inet 10.199.0.1 netmask 0xff00 broadcast 10.199.0.255
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
inet 192.168.13.1 netmask 0xff00 broadcast 192.168.13.255
media: Ethernet autoselect (1000baseTX )
status: active
lo0: flags=8049 metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff00
vlan60: flags=8843 metric 0 mtu 1500
ether 00:17:9a:7a:69:ab
inet 172.16.128.150 netmask 0xfffc broadcast 172.16.128.151
media: Ethernet autoselect (1000baseTX )
status: active
vlan: 60 parent interface: sk0

( sei que a sk0 tá linda, não precisa chingar. ela vai melhorar em breve )

Quando tento pingar:

kame# ping 172.16.128.149
PING 172.16.128.149 (172.16.128.149): 56 data bytes
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
ping: sendto: Network is unreachable
^C
--- 172.16.128.149 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

Deve ter perdido alguma coisa. To fazendo alguma cagada grande?

Segunda coisa.

Investigando isso esbarrei nisso aqui:

kame# netstat -nrss
routing:
10683 destinations found unreachable
1 route not in table but not freed

Não to achando nada sobre a última linha. Alguém tem uma dica?

Valeu.

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


Re: [FUG-BR] RES: RES: [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Bandeira
Da ate desgosto ler essas aulas do Patrick, desde o começo do ano que quero
instalar e voltar estudar FreeBSD mas até hoje o FreeBSD não tem suporte ao
tipo de notebook que uso, uma pena.

Tomara que em janeiro já tenha :)
http://blogs.freebsdish.org/rpaulo/2008/09/03/so-you-want-to-test-the-freebsdi386-efi-boot-loader/
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] Problemas com Cacti - Processo Spine

2008-11-28 Por tôpico Patrick Tracanelli
Thiago Dias de Francisco escreveu:
> Pessoal boa tarde, 
> 
> Por favor estou com problemas em meu servidor de monitoramento (nagios+cacti) 
> ontem e hoje ele esta muito lento, monitorando os processos por meio do top e 
> ps aux eu verifiquei que o daemon spine esta com sobrecarregando o meu 
> servidor, o problema pelo que eu vi no /var/log/messages pode estar no banco 
> sql, embaixo da mensagem esta um print dos erros gerados ao iniciar o spine
> 
> Nov 28 17:35:56 monitoramento1
> Cacti[66084]: CMDPHP: ERROR: SQL Assoc Failed!, Error:'1016',
> SQL:"select  poller_output.output,  poller_output.time,
>  poller_output.local_data_id,  poller_item.rrd_path,
>  poller_item.rrd_name,  poller_item.rrd_num  from
> (poller_output,poller_item)  where
> (poller_output.local_data_id=poller_item.local_data_id and
> poller_output.rrd_name=poller_item.rrd_name)  LIMIT 1
> "Nov 28 17:35:57 monitoramento1 kernel: pid 45022 (httpd), uid 80: exited on 
> signal 11
> Nov 28 17:35:57 monitoramento1
> Cacti[66084]: CMDPHP: ERROR: SQL Assoc Failed!, Error:'1016',
> SQL:"select  poller_output.output,  poller_output.time,
>  poller_output.local_data_id,  poller_item.rrd_path,
>  poller_item.rrd_name,  poller_item.rrd_num  from
> (poller_output,poller_item)  where
> (poller_output.local_data_id=poller_item.local_data_id and
> poller_output.rrd_name=poller_item.rrd_name)  LIMIT 1"Nov 28 17:35:58 
> monitoramento1
> Cacti[66084]: CMDPHP: ERROR: SQL Assoc Failed!, Error:'1016',
> SQL:"select  poller_output.output,  poller_output.time,
>  poller_output.local_data_id,  poller_item.rrd_path,
>  poller_item.rrd_name,  poller_item.rrd_num  from
> (poller_output,poller_item)  where
> (poller_output.local_data_id=poller_item.local_data_id and
> poller_output.rrd_name=poller_item.rrd_name)  LIMIT 1"
> 
> Com base nisso, alguém pode me ajudar a identificar qual o problema esta 
> ocorrendo para 
> o servidor monitoramento estar abrindo todas essas sessões de processos do 
> daemon spine  ?
> Geralmente ele abre mais de 3 sessões do Spine com processos ocupando mais de 
> 30% do meu servidor.
> 
> Versão do FreeBSD eh 7.0 stable
> Agradeço desde já pela atenção de todos.
> 
> Atenciosamente
> NullcK
> 
> 
> 
> 
>   Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd

O problema é no MySQL. Por algum motivo o DB não pode ser aberto pra 
manipulação ou consulta. Pode investigar por esse lado. Diagnóstico 
disso é código de erro 1016. Roda a query do Spine na mão que vai ajudar 
a encontrar o problema.

-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
[EMAIL PROTECTED]
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

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


[FUG-BR] Problemas com Cacti - Processo Spine

2008-11-28 Por tôpico Thiago Dias de Francisco
Pessoal boa tarde, 

Por favor estou com problemas em meu servidor de monitoramento (nagios+cacti) 
ontem e hoje ele esta muito lento, monitorando os processos por meio do top e 
ps aux eu verifiquei que o daemon spine esta com sobrecarregando o meu 
servidor, o problema pelo que eu vi no /var/log/messages pode estar no banco 
sql, embaixo da mensagem esta um print dos erros gerados ao iniciar o spine

Nov 28 17:35:56 monitoramento1
Cacti[66084]: CMDPHP: ERROR: SQL Assoc Failed!, Error:'1016',
SQL:"select  poller_output.output,  poller_output.time,
 poller_output.local_data_id,  poller_item.rrd_path,
 poller_item.rrd_name,  poller_item.rrd_num  from
(poller_output,poller_item)  where
(poller_output.local_data_id=poller_item.local_data_id and
poller_output.rrd_name=poller_item.rrd_name)  LIMIT 1
"Nov 28 17:35:57 monitoramento1 kernel: pid 45022 (httpd), uid 80: exited on 
signal 11
Nov 28 17:35:57 monitoramento1
Cacti[66084]: CMDPHP: ERROR: SQL Assoc Failed!, Error:'1016',
SQL:"select  poller_output.output,  poller_output.time,
 poller_output.local_data_id,  poller_item.rrd_path,
 poller_item.rrd_name,  poller_item.rrd_num  from
(poller_output,poller_item)  where
(poller_output.local_data_id=poller_item.local_data_id and
poller_output.rrd_name=poller_item.rrd_name)  LIMIT 1"Nov 28 17:35:58 
monitoramento1
Cacti[66084]: CMDPHP: ERROR: SQL Assoc Failed!, Error:'1016',
SQL:"select  poller_output.output,  poller_output.time,
 poller_output.local_data_id,  poller_item.rrd_path,
 poller_item.rrd_name,  poller_item.rrd_num  from
(poller_output,poller_item)  where
(poller_output.local_data_id=poller_item.local_data_id and
poller_output.rrd_name=poller_item.rrd_name)  LIMIT 1"

Com base nisso, alguém pode me ajudar a identificar qual o problema esta 
ocorrendo para 
o servidor monitoramento estar abrindo todas essas sessões de processos do 
daemon spine  ?
Geralmente ele abre mais de 3 sessões do Spine com processos ocupando mais de 
30% do meu servidor.

Versão do FreeBSD eh 7.0 stable
Agradeço desde já pela atenção de todos.

Atenciosamente
NullcK




  Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


[FUG-BR] [PROXY] Squid 3.0 + FreeBSD 6.3 erro "acl_access::containsPURGE: returning false "

2008-11-28 Por tôpico Paulo Henrique
Ola a todos da lista.

Estou configurando um proxy-cache e quanto carrego ele com as acls o
seguinte erro é retornado:

ACL::FindByName 'all'
2008/11/28 19:27:21.734| getMyHostname: 'router.poli.com.br' resolved into '
router.poli.com.br.com.br'
2008/11/28 19:27:21.762| acl_access::containsPURGE: invoked for 'http_access
deny all'
2008/11/28 19:27:21.762| acl_access::containsPURGE: can't create tempAcl
2008/11/28 19:27:21.762| acl_access::containsPURGE:   returning false
2008/11/28 19:27:21.763| leave_suid: PID 842 called
2008/11/28 19:27:21.763| leave_suid: PID 842 giving up root, becoming
'squid'
2008/11/28 19:27:21.763| command-line -X overrides: ALL,1
squid: ERROR: No running copy
2008/11/28 19:27:21.774| ACL::~ACL: '

esse eh parte do erro.

Segui as configurações.

FreeBSD router.poli.com.br 6.3-RELEASE-p6 FreeBSD 6.3-RELEASE-p6 #0: Fri Nov
28 13:44:14 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ROUTER
i386

Config Hardware, Pentium 4 2.8ghz Soquete 478, 512Mbs, 80Gbs Pata, XL e SIS

A versão do Squid que estou usando é a SQUID-3.0-STABLE10

segue alguns links no qual apresenta o mesmo problema que o meu.

http://www.mail-archive.com/[EMAIL PROTECTED]/msg52599.html

Até  o momento parece que é erro mesmo do Squid.
se desejarem mais informação mando informações.


Desde Já agradecido.

-- 
Atenciosamente Paulo Henrique.
"Obrigado não, que é do Diabo Capital. Agradecido, que é de bom saber"
"A unica forma de todos sentirem-se bem é adotanto o Regime Socialista,
não teremos tudo que queremos, contudo não veremos mais o que não queremos."
"A real definição sobre deus se dá pelo fato do ser humano ser covarde o
suficiente,
colocando a culpa em algo que não existe para manter a conciência "limpa"".
-
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 TOPIC] PQ Usar esta faixa de IP 7.2.1.1 ou14.7.1.1

2008-11-28 Por tôpico c0re dumped
Existe a mesma coisa em relação a aplicações http.

É simplesmente irritante ver nego escolhendo portas tipo 5111, 2325,
10101,  pra rodar aplicações http. Os órgãos da justiça e órgãos
do governo em geral adora esse tipo de coisa.

Tenho que fazer um monte de acls no squid liberado acesso pra essas
portas em domínios .jus.br e .gov.br.

Será que dá tanto trabalho assim configurar o serviço pra rodar na
porta 80 ou usar um proxy reverso (ou configurar um virtual host) pra
simplificar a vida de todo mundo e aceitar conexoes http apenas na
porta padrão?

A impressão que tenho é que o cidadão escolhe um número aplica um
formula cabalistica e se este número for entre 1025 e 64535, pode ser
usado como porta pra aplicação...

Mas padronizar pra que se pode complicar né

-- 
http://www.webcrunchers.com/crunch/

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


[FUG-BR] RES: RES: RES: Bloco 197/8

2008-11-28 Por tôpico Renato Frederick
Bacana, é isto mesmo.. aliás, seria interessante colocar isto no wiki deles,
se puder sugerir na lista, ia poupar um tempo grande para quem precisar
fazer isto no quagga. :)


Para fechar, sobre as comunidades da cymru, 65333:888 são todos os bogons,
65333:890 "martians" e 65333:892 redes não alocadas, esta documentação tem
no PDF que a cymru apresentou na NANOG:

http://www.nanog.org/mtg-0501/pdf/deitrich.pdf


Fica aí registrado no histórico da lista como referência..

Abraços


> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Edinilson - ATINET
> Enviada em: sexta-feira, 28 de novembro de 2008 13:48
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] RES: RES: Bloco 197/8
> Prioridade: Alta
> 
> OK Renato, tem razao.
> Apos um post la na lista do Quagga uma outra pessoa tambem respondeu
> exatamente igual ao que voce fez (postei abaixo).
> 
> Muito obrigado!
> 
> Edinilson
> -
> ATINET-Professional Web Hosting
> Tel Voz: (0xx11) 4412-0876
> http://www.atinet.com.br
> 
> 
> Edinilson - ATINET wrote:
> > Mr. Steve, I´m using quagga+bgpd on freebsd.
> > I thing that null0 doesn´t work on freebsd.
> 
> A few months back, I had extensive issues with using the null
> interface.
> 
> It seemed like when I applied a non-existent IP address (ie. an IP that
> did not belong to a prefix in use on the box) to a null interface, it
> would not take.
> 
> nullN would work ok if I was using one of my public IP addresses, but I
> didn't want to do that.
> 
> What I ended up doing is thus:
> 
> # ifconfig disc0 create
> # ifconfig disc0 192.168.222.1/32
> 
> Then, in Quagga, for the bogons session:
> 
> ip prefix-list CYMRU-OUT seq 5 deny 0.0.0.0/0 le 32
> 
> ip community-list 10 permit 65333:888
> 
> route-map CYMRU-MAP-IN permit 10
>  description Null route BOGONS learned from Cymru
>  match community 10
>  set ip next-hop 192.168.222.1
> 
> 
> ...and for my IPv6 null route:
> 
> ipv6 route 2607:f118::/32 disc0
> 
> ...and this seems to work ok.
> 
> Cheers,
> 
> Steve
> 

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


Re: [FUG-BR] Certificação BSD

2008-11-28 Por tôpico Bandeira
Ultimo link ta errado.

O certo, http://www.devilstore.com.br/

2008/11/28 Patrick Tracanelli <[EMAIL PROTECTED]>

> Willian Alves escreveu:
> > Salve Patrick
> >
> > Gostaria de saber mais ou menos o que devo estudar pra poder pegar
> > certificação BSD pois estou acabando de pegar minha certificação CCNA e
> como
> > vou ficar parado vou começar a estudar  pra FreeBSD alem do Handbook
> existe
> > algum material mais especifico.
>
> Olá Willian,
>
> - Guia de Referência de Domínios de Estudo
> - Guia de Referência de Comandos
> - DVD de Estudo
> - Livro de Estudo criado pela comunidade (Wikibook)
>
> http://www.bsdcertification.org/certification/
>
> https://register.bsdcertification.org//register/exam-preparation-checklist/checklist
> http://www.devistore.com.br
>
>
> --
> Patrick Tracanelli
>
> FreeBSD Brasil LTDA.
> Tel.: (31) 3516-0800
> [EMAIL PROTECTED]
> http://www.freebsdbrasil.com.br
> "Long live Hanin Elias, Kim Deal!"
>
> -
> 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] RES: RES: Bloco 197/8

2008-11-28 Por tôpico Edinilson - ATINET
OK Renato, tem razao.
Apos um post la na lista do Quagga uma outra pessoa tambem respondeu 
exatamente igual ao que voce fez (postei abaixo).

Muito obrigado!

Edinilson
-
ATINET-Professional Web Hosting
Tel Voz: (0xx11) 4412-0876
http://www.atinet.com.br


Edinilson - ATINET wrote:
> Mr. Steve, I´m using quagga+bgpd on freebsd.
> I thing that null0 doesn´t work on freebsd.

A few months back, I had extensive issues with using the null interface.

It seemed like when I applied a non-existent IP address (ie. an IP that
did not belong to a prefix in use on the box) to a null interface, it
would not take.

nullN would work ok if I was using one of my public IP addresses, but I
didn't want to do that.

What I ended up doing is thus:

# ifconfig disc0 create
# ifconfig disc0 192.168.222.1/32

Then, in Quagga, for the bogons session:

ip prefix-list CYMRU-OUT seq 5 deny 0.0.0.0/0 le 32

ip community-list 10 permit 65333:888

route-map CYMRU-MAP-IN permit 10
 description Null route BOGONS learned from Cymru
 match community 10
 set ip next-hop 192.168.222.1


...and for my IPv6 null route:

ipv6 route 2607:f118::/32 disc0

...and this seems to work ok.

Cheers,

Steve



- Original Message - 
From: "Renato Frederick" <[EMAIL PROTECTED]>
To: "'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)'" 

Sent: Friday, November 28, 2008 11:11 AM
Subject: [FUG-BR] RES: RES: Bloco 197/8


Edinilson,

Quando eu coloco uma rota para o ip do blackrole pela null0, o quagga
aceita, a rota realmente aparece(se eu der um tracert ou ping não responde).

De fato, se de qualquer host interno da rede eu der um tracert para o IP que
eu fiz o blackhole, ele não passa do firewall.

Porém a rota não aparece na tabela bgp, quando eu fizer o route-map, e aí
que fica o problema:

Se eu digitar um "sh ip bgp" não aparece as rotas para os bogons apontando
para o IP blackrole.

Daí veja o que eu fiz no freebsd:

##BlackHole
cloned_interfaces="disc0"
ifconfig_disc0="192.0.2.1 netmask 255.255.255.255"
route_blackhole="10.255.255.254/32 192.0.2.1"
static_routes="blackhole"


a rota "blackhole"acima pode ser substituída dentro do quagga para:
ip route 10.255.255.254/32 192.0.2.1

fica a seu critério.

Daí eu fiz o route-map:


route-map CYMRUBOGONS permit 10
 match community 10
 set ip next-hop 10.255.255.254
 set origin igp

Eu achei muito estranho também, afinal um tracert funcionava mas não
aparecia no BGP... achei que era erro do meu route-map, etc..

até que achei esta discussão:

http://osdir.com/ml/network.quagga.user/2004-10/msg00157.html


e achei interessante esta parte:

FreeBSD has RTF_BLACKHOLE and RTF_REJECT flags in kernel RIB rtentry which
is
triggered by 'ip route a.b.c.d/32 Null0' or 'ip route a.b.c.d/32 reject'
respectively. Linux also provides blackhole capabilities in the kernel
routing subsystem. This is the recommended method.

Otherwise, just route to a network hosted by dummy0 or 'software discard'
e.g.
disc0/ds0 interface.

P.S. And yes there was (or is still?) a bug in zeb|Q bgpd that won't resolve
recursive routes pointed to "Null0|blackhole|reject" next-hops. But I think
there was a recent bug id on that addressing this issue.

Aí o "truque" é que  o nex-hop nao é a null0 propriamente, mas um IP que por
sua vez aponta uma rota para null0 :)




> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Edinilson - ATINET
> Enviada em: sexta-feira, 28 de novembro de 2008 10:51
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] RES: Bloco 197/8
> Prioridade: Alta
>
> Caro Renato, eu participo tambem da lista do Quagga e o pessoal la
> insiste
> que o null0 funciona no freebsd.
> Quais problemas voce teve em utilizar o null0 ?
>
> Obrigado
>
> Edinilson
> -
> ATINET-Professional Web Hosting
> Tel Voz: (0xx11) 4412-0876
> http://www.atinet.com.br
>
>
> - Original Message -
> From: "Renato Frederick" <[EMAIL PROTECTED]>
> To: "'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)'"
> 
> Sent: Thursday, November 27, 2008 10:21 AM
> Subject: [FUG-BR] RES: Bloco 197/8
>
>
> Edinilson,
>
> Sim, uso no quagga.
>
> Primeiro você tem que enviar um email a eles solicitando, no site
> explica o
> formato.. basicamente é falar que não quer autenticação md5 na
> sessão(quagga
> não suporta) e passar seu as e o seu ip para o peering.
>
> Depois é só subir como se fosse uma sessão bgp normal. Como eles usam 2
> peers para a sessão, eu uso peer-group:
>
> [...]
>  neighbor cymru-bogon peer-group
>  neighbor cymru-bogon description BOGUS-SERVER
>  neighbor cymru-bogon ebgp-multihop 255
>  neighbor cymru-bogon update-source lo0
>  neighbor cymru-bogon send-community both
>  neighbor cymru-bogon soft-reconfiguration inbound
>  neighbor cymru-bogon maximum-prefix 100 90
>  neighbor cymru-bogon prefix-list cymru-out out
>  neighbor cymru-bogon route

[FUG-BR] RES: Sendmail quase 100% da CPU

2008-11-28 Por tôpico Renato Frederick
Remova tudo que estiver no mqueue e no rc.conf coloque
sendmail_enable="NONE". NO indica que ele vai não vai ouvir na rede.
Você pode também desabilitar o periodic de enviar os alertas, mas eu
recomendo fortemente configurar um relay para o sendmail enviar estes
alertas,  bem como uma leitura ao menos semanal deles!

> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Welkson Renny de Medeiros
> Enviada em: sexta-feira, 28 de novembro de 2008 13:13
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] Sendmail quase 100% da CPU
> 
> Só complementando a informação:
> 
> [EMAIL PROTECTED] /var/spool/mqueue]# tail -f /var/log/maillog
> 
> Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvD096313:
> to=<[EMAIL PROTECTED]>, delay=3+17:51:57, xdelay=00:00:00,
> mailer=esmtp, pri=16322185, relay=xxx.com.br., dsn=4.0.0,
> stat=Deferred:
> Operation timed out with xxx.com.br.
> Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvM096313:
> to=<[EMAIL PROTECTED]>, delay=3+17:51:53, xdelay=00:00:00,
> mailer=esmtp, pri=16322388, relay=xxx.com.br., dsn=4.0.0,
> stat=Deferred:
> Operation timed out with xxx.com.br.
> Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvN096313:
> to=<[EMAIL PROTECTED]>, delay=3+17:51:53, xdelay=00:00:00,
> mailer=esmtp, pri=16322392, relay=xxx.com.br., dsn=4.0.0,
> stat=Deferred:
> Operation timed out with xxx.com.br.
> 
> Outra coisa que percebi é que tem milhares de arquivos na pasta
> /var/spool/mqueue
> 
> Como falei, não uso servidor de email aqui, deve ser emails
> administrativos
> do BSD... tem como desativar?
> 
> Welkson
> 
> - Original Message -
> From: "Welkson Renny de Medeiros" <[EMAIL PROTECTED]>
> To: 
> Sent: Friday, November 28, 2008 12:07 PM
> Subject: [FUG-BR] Sendmail quase 100% da CPU
> 
> 
> Pessoal,
> 
> Vejam o resultado desse TOP:
> 
> last pid: 79646;  load averages:  0.78,  0.71,  0.60   up 46+04:09:39
> 12:05:23
> 128 processes: 2 running, 126 sleeping
> CPU states:  1.1% user,  0.0% nice, 37.2% system,  0.2% interrupt,
> 61.5%
> idle
> Mem: 741M Active, 843M Inact, 190M Wired, 77M Cache, 112M Buf, 54M Free
> Swap: 2048M Total, 1184K Used, 2047M Free
> 
>   PID USERNAME THR PRI NICE   SIZERES STATE  C   TIME   WCPU
> COMMAND
> 79336 root   1 1130 10968K  7888K CPU0   0   9:34 80.66%
> sendmail
> 
> Engraçado que não uso SMTP nesse servidor (o BSD acho que envia aqueles
> alertas administrativos pelo sendmail)...
> 
> Vejam meu rc.conf:
> 
> # disable email services
> sendmail_enable="NO"
> sendmail_submit_enable="YES"
> sendmail_submit_flags="-L
> sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
> sendmail_msp_queue_enable="YES"
> sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"
> 
> Alguém tem idéia do que pode tá acontecendo? que EMAIL é esse que ele
> tá
> mandando =)
> 
> 
> --
> Welkson Renny de Medeiros
> Focus Automação Comercial
> Desenvolvimento / Gerência de Redes
> [EMAIL PROTECTED]
> 
> 
> 
>   Powered by 
> 
>(__)
> \\\'',)
>   \/  \ ^
>   .\._/_)
> 
>   www.FreeBSD.org
> 
> -
> 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


Re: [FUG-BR] Sendmail quase 100% da CPU

2008-11-28 Por tôpico Wesley Miranda FreeBSD Consult
- Original Message - 
From: "Welkson Renny de Medeiros" <[EMAIL PROTECTED]>
To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" 

Sent: Friday, November 28, 2008 1:12 PM
Subject: Re: [FUG-BR] Sendmail quase 100% da CPU


Só complementando a informação:

[EMAIL PROTECTED] /var/spool/mqueue]# tail -f /var/log/maillog

Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvD096313:
to=<[EMAIL PROTECTED]>, delay=3+17:51:57, xdelay=00:00:00,
mailer=esmtp, pri=16322185, relay=xxx.com.br., dsn=4.0.0, stat=Deferred:
Operation timed out with xxx.com.br.
Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvM096313:
to=<[EMAIL PROTECTED]>, delay=3+17:51:53, xdelay=00:00:00,
mailer=esmtp, pri=16322388, relay=xxx.com.br., dsn=4.0.0, stat=Deferred:
Operation timed out with xxx.com.br.
Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvN096313:
to=<[EMAIL PROTECTED]>, delay=3+17:51:53, xdelay=00:00:00,
mailer=esmtp, pri=16322392, relay=xxx.com.br., dsn=4.0.0, stat=Deferred:
Operation timed out with xxx.com.br.

Outra coisa que percebi é que tem milhares de arquivos na pasta
/var/spool/mqueue

Como falei, não uso servidor de email aqui, deve ser emails administrativos
do BSD... tem como desativar?

Welkson

- Original Message - 
From: "Welkson Renny de Medeiros" <[EMAIL PROTECTED]>
To: 
Sent: Friday, November 28, 2008 12:07 PM
Subject: [FUG-BR] Sendmail quase 100% da CPU


Pessoal,

Vejam o resultado desse TOP:

last pid: 79646;  load averages:  0.78,  0.71,  0.60   up 46+04:09:39
12:05:23
128 processes: 2 running, 126 sleeping
CPU states:  1.1% user,  0.0% nice, 37.2% system,  0.2% interrupt, 61.5%
idle
Mem: 741M Active, 843M Inact, 190M Wired, 77M Cache, 112M Buf, 54M Free
Swap: 2048M Total, 1184K Used, 2047M Free

  PID USERNAME THR PRI NICE   SIZERES STATE  C   TIME   WCPU COMMAND
79336 root   1 1130 10968K  7888K CPU0   0   9:34 80.66%
sendmail

Engraçado que não uso SMTP nesse servidor (o BSD acho que envia aqueles
alertas administrativos pelo sendmail)...

Vejam meu rc.conf:

# disable email services
sendmail_enable="NO"
sendmail_submit_enable="YES"
sendmail_submit_flags="-L
sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
sendmail_msp_queue_enable="YES"
sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"

Alguém tem idéia do que pode tá acontecendo? que EMAIL é esse que ele tá
mandando =)


-- 
Welkson Renny de Medeiros
Focus Automação Comercial
Desenvolvimento / Gerência de Redes
[EMAIL PROTECTED]



  Powered by 

   (__)
\\\'',)
  \/  \ ^
  .\._/_)

  www.FreeBSD.org

-

welkson,
Deve resolver seu problema.

sendmail_enable="NONE"
#sendmail_submit_enable="YES"
#sendmail_submit_flags="-L
#sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
#sendmail_msp_queue_enable="YES"
#sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"

Abraço

Wesley Miranda
FreeBSD Consult
Tel (31) 2526 8616 (31) 9426 4404
DTI - Departamento de Tecnologia da Informação
[EMAIL PROTECTED]
www.freebsdconsult.com.br

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


Re: [FUG-BR] Certificação BSD

2008-11-28 Por tôpico Patrick Tracanelli
Willian Alves escreveu:
> Salve Patrick
> 
> Gostaria de saber mais ou menos o que devo estudar pra poder pegar 
> certificação BSD pois estou acabando de pegar minha certificação CCNA e como 
> vou ficar parado vou começar a estudar  pra FreeBSD alem do Handbook existe 
> algum material mais especifico. 

Olá Willian,

- Guia de Referência de Domínios de Estudo
- Guia de Referência de Comandos
- DVD de Estudo
- Livro de Estudo criado pela comunidade (Wikibook)

http://www.bsdcertification.org/certification/
https://register.bsdcertification.org//register/exam-preparation-checklist/checklist
http://www.devistore.com.br


-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
[EMAIL PROTECTED]
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

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


Re: [FUG-BR] Sendmail quase 100% da CPU

2008-11-28 Por tôpico Welkson Renny de Medeiros
Só complementando a informação:

[EMAIL PROTECTED] /var/spool/mqueue]# tail -f /var/log/maillog

Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvD096313: 
to=<[EMAIL PROTECTED]>, delay=3+17:51:57, xdelay=00:00:00, 
mailer=esmtp, pri=16322185, relay=xxx.com.br., dsn=4.0.0, stat=Deferred: 
Operation timed out with xxx.com.br.
Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvM096313: 
to=<[EMAIL PROTECTED]>, delay=3+17:51:53, xdelay=00:00:00, 
mailer=esmtp, pri=16322388, relay=xxx.com.br., dsn=4.0.0, stat=Deferred: 
Operation timed out with xxx.com.br.
Nov 28 12:08:07 intranet sm-mta[79336]: mAOLDMvN096313: 
to=<[EMAIL PROTECTED]>, delay=3+17:51:53, xdelay=00:00:00, 
mailer=esmtp, pri=16322392, relay=xxx.com.br., dsn=4.0.0, stat=Deferred: 
Operation timed out with xxx.com.br.

Outra coisa que percebi é que tem milhares de arquivos na pasta 
/var/spool/mqueue

Como falei, não uso servidor de email aqui, deve ser emails administrativos 
do BSD... tem como desativar?

Welkson

- Original Message - 
From: "Welkson Renny de Medeiros" <[EMAIL PROTECTED]>
To: 
Sent: Friday, November 28, 2008 12:07 PM
Subject: [FUG-BR] Sendmail quase 100% da CPU


Pessoal,

Vejam o resultado desse TOP:

last pid: 79646;  load averages:  0.78,  0.71,  0.60   up 46+04:09:39
12:05:23
128 processes: 2 running, 126 sleeping
CPU states:  1.1% user,  0.0% nice, 37.2% system,  0.2% interrupt, 61.5%
idle
Mem: 741M Active, 843M Inact, 190M Wired, 77M Cache, 112M Buf, 54M Free
Swap: 2048M Total, 1184K Used, 2047M Free

  PID USERNAME THR PRI NICE   SIZERES STATE  C   TIME   WCPU COMMAND
79336 root   1 1130 10968K  7888K CPU0   0   9:34 80.66%
sendmail

Engraçado que não uso SMTP nesse servidor (o BSD acho que envia aqueles
alertas administrativos pelo sendmail)...

Vejam meu rc.conf:

# disable email services
sendmail_enable="NO"
sendmail_submit_enable="YES"
sendmail_submit_flags="-L
sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
sendmail_msp_queue_enable="YES"
sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"

Alguém tem idéia do que pode tá acontecendo? que EMAIL é esse que ele tá
mandando =)


-- 
Welkson Renny de Medeiros
Focus Automação Comercial
Desenvolvimento / Gerência de Redes
[EMAIL PROTECTED]



  Powered by 

   (__)
\\\'',)
  \/  \ ^
  .\._/_)

  www.FreeBSD.org

-
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] Sendmail quase 100% da CPU

2008-11-28 Por tôpico Welkson Renny de Medeiros
Pessoal,

Vejam o resultado desse TOP:

last pid: 79646;  load averages:  0.78,  0.71,  0.60   up 46+04:09:39 
12:05:23
128 processes: 2 running, 126 sleeping
CPU states:  1.1% user,  0.0% nice, 37.2% system,  0.2% interrupt, 61.5% 
idle
Mem: 741M Active, 843M Inact, 190M Wired, 77M Cache, 112M Buf, 54M Free
Swap: 2048M Total, 1184K Used, 2047M Free

  PID USERNAME THR PRI NICE   SIZERES STATE  C   TIME   WCPU COMMAND
79336 root   1 1130 10968K  7888K CPU0   0   9:34 80.66% 
sendmail

Engraçado que não uso SMTP nesse servidor (o BSD acho que envia aqueles 
alertas administrativos pelo sendmail)...

Vejam meu rc.conf:

# disable email services
sendmail_enable="NO"
sendmail_submit_enable="YES"
sendmail_submit_flags="-L 
sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
sendmail_msp_queue_enable="YES"
sendmail_msp_queue_flags="-L sm-msp-queue -Ac -q30m"

Alguém tem idéia do que pode tá acontecendo? que EMAIL é esse que ele tá 
mandando =)


-- 
Welkson Renny de Medeiros
Focus Automação Comercial
Desenvolvimento / Gerência de Redes
[EMAIL PROTECTED]



  Powered by 

   (__)
\\\'',)
  \/  \ ^
  .\._/_)

  www.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] Certificação BSD

2008-11-28 Por tôpico Willian Alves
Salve Patrick

Gostaria de saber mais ou menos o que devo estudar pra poder pegar 
certificação BSD pois estou acabando de pegar minha certificação CCNA e como 
vou ficar parado vou começar a estudar  pra FreeBSD alem do Handbook existe 
algum material mais especifico. 

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


Re: [FUG-BR] RES: RES: [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Patrick Tracanelli
Patrick Tracanelli escreveu:
> Renato Frederick escreveu:
>> Opa..
>>
>> Obrigado Patrick, agora posso ter um embasamento para justificar o correto
>> dimensionamento do SWAP, que obviamente envolve custo.
>>
>> Sobre outro colega que falou do tamanho do disco, realmente até uma certa
>> quantia de RAM e com poucos discos podemos considerar desprezível alocar
>> 32GB para swap, mas quando está planejando a compra de um novo hardware,
>> esta informação deve ser levada em conta para os pré requisitos enviados ao
>> comercial.
>> No meu caso em particular, o correto dimensionamento do swap irá alterar um
>> pouco  o esquema inicial do RAID, por isto a preocupação em ter referencial
>> do fabricante, evitando desgaste :-)
>>
>> Já levando pro lado prático, não sei se um servidor em condições
>> normais(leia-se, não fazendo swap ou com overload), iria mudar muito com
>> 2xRAM ou 1xRAM ou 1/2vez RAM de SWAP, nunca tive esta curiosidade e também
>> não tenho meios de testar, mas seria um trabalho interessante para alguém
>> voltado ao lado de pesquisa, se interessar, fazer e traria muito peso para
>> estas tomadas de decisões.
> 
> Sim, faz diferença. Não precisei fazer research, na prática exemplo real 
> hoje tenho meu laptop. Costumo dizer em aula que nunca devemos dar 
> atenção a informação "quantidade de swap usada". Não importa, a não ser 
> que esteja crítico demais porque ai o que importa (frequencia de acesso 
> a disco) começa ficar crítica por estarem associados. Mas o FreeBSD 
> tende a consumir bastante SWAP em sistemas de alta carga, o que pode 
> assustar quem ta acostumado com LX ou Windão.
> 
> A gente deve se apegar ao uso da SWAP e não espaço em uso. Na prática o 
> gstat vai mostrar informações da partição de swap, o que importa são o 
> L(q) (Lenght Queue, tamanho da fila de operações em espera) que sob 
> nenhuma hipótese deve ser superior a 1 em qualquer situação em um 
> sistema de produção, e se chegar a 1 tem que ser em "picos" ou situações 
> esporádicas. L(q) em 1 é o limite da degradação de performance que 
> afetará de forma geral o sistema. Os campos ms/r e ms/w (da(s) 
> partição(es) de swap obviamente) também vão informar diretamente a 
> degradação de performance em "tempo" pro usuário de forma geral do sistema.
> 
> E o principal, informação que o gstat não mostra mas o iostat si, é o 
> svc_t que é o tempo médio das transações. Veja, é o médio. Informação 
> precisa pra sabermos o impacto que o uso de SWAP está causando ou não no 
> sistema.
> 
> Na prática meu laptop tem inicialmente 1xRAM (sim eu quis poupar espaço 
> pq tem bastante RAM hehe), se fica com essa quantidade, e minha RAM fica 
> perto do limite vejo que começo ter uma frequência de acesso a swap, 
> mesmo com baixo consumo (8%, 12%) de páginas de swap. Não é nada crítico 
> e acredito que o acesso a SWAP seja preventivo já que o FreeBSD tem 
> conhecimento de Segment Stack e controle a probabilidade uma página de 
> memória precisar ser acessada de acordo com a frequencia de uso de 
> páginas vizinhas ou a proximidade do relacionamento das páginas em 
> segmento, no momento em que páginas saem do estado "disponivel para 
> paginar" e entram em wired (vm.stats.vm.v_wire_count), nesse caso a 
> pagina precisa estar em RAM e não em SWAP mesmo sem uso, ou seja por 
> precaução e não necessidade.
> 
> Criei então um swapfile (swapfile="" no rc.conf) dobrando a SWAP e 
> apesar do consumo total ficar equivalente em páginas de memoria virtual 
> alocadas (o que era 12% vai pra 6% ou 7%), o L(q) e o svc_t indicam 
> menor acesso, de fato acesso só exporádico.
> 
> Porque? Porque tomadas de decisão diferente foram feitas :) Curioso 
> isso. Outra coisa, é tudo muito bem feito. Quando o acesso a SWAP começa 
> gerar L(q) que chegue em 1 (campo wait no iostat) as páginas "once 
> wired" nunca são "paged out" porque o FreeBSD sabe que nesse caso 
> estaria artificialmente causando degradação de performance. As "once 
> wired" passam a ser "coloridas" (hehehe) como (tornam-se) "perm wired". 
> O resultado é mais RAM necessária pras aplicações (e menos RAM 
> disponível para outras coisas), e a primeira "outras coisas" a sentir 
> efeito são os buffers de acesso a disco (recurso oferecido pelo 
> UFS_DIRHASH do kernel), ou seja a performance é degradada em relação a 
> VFS, e podemos medir (visualizar) observando picos e médias inferiores 
> na utilização do (mib sysctl) vfs.bufspace.
> 
> Bem legal isso :D

Alias pra aquelas situações que o usuário vem de Linux e olha o top do 
FreeBSD e se assusta e não tem outra forma de saber como está o consumo 
de memória, segue um scriptinho que usamos internamente:

%svn cat https://svn.bh/svn/bsdapps/trunk/bsdapps/bin/memory-status

#!/bin/sh
# Patrick Tracanell <[EMAIL PROTECTED]>
#
# Obtem informacoes de consumo de memoria e apresenta-as de diversas formas.
#
# Usamos para gerar graficos mem stats no BSDAPPS mas
# pode tambem ser util para tarefas do dia-a-dia quando o top(1) nao

Re: [FUG-BR] RES: RES: [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Patrick Tracanelli
Renato Frederick escreveu:
> Opa..
> 
> Obrigado Patrick, agora posso ter um embasamento para justificar o correto
> dimensionamento do SWAP, que obviamente envolve custo.
> 
> Sobre outro colega que falou do tamanho do disco, realmente até uma certa
> quantia de RAM e com poucos discos podemos considerar desprezível alocar
> 32GB para swap, mas quando está planejando a compra de um novo hardware,
> esta informação deve ser levada em conta para os pré requisitos enviados ao
> comercial.
> No meu caso em particular, o correto dimensionamento do swap irá alterar um
> pouco  o esquema inicial do RAID, por isto a preocupação em ter referencial
> do fabricante, evitando desgaste :-)
> 
> Já levando pro lado prático, não sei se um servidor em condições
> normais(leia-se, não fazendo swap ou com overload), iria mudar muito com
> 2xRAM ou 1xRAM ou 1/2vez RAM de SWAP, nunca tive esta curiosidade e também
> não tenho meios de testar, mas seria um trabalho interessante para alguém
> voltado ao lado de pesquisa, se interessar, fazer e traria muito peso para
> estas tomadas de decisões.

Sim, faz diferença. Não precisei fazer research, na prática exemplo real 
hoje tenho meu laptop. Costumo dizer em aula que nunca devemos dar 
atenção a informação "quantidade de swap usada". Não importa, a não ser 
que esteja crítico demais porque ai o que importa (frequencia de acesso 
a disco) começa ficar crítica por estarem associados. Mas o FreeBSD 
tende a consumir bastante SWAP em sistemas de alta carga, o que pode 
assustar quem ta acostumado com LX ou Windão.

A gente deve se apegar ao uso da SWAP e não espaço em uso. Na prática o 
gstat vai mostrar informações da partição de swap, o que importa são o 
L(q) (Lenght Queue, tamanho da fila de operações em espera) que sob 
nenhuma hipótese deve ser superior a 1 em qualquer situação em um 
sistema de produção, e se chegar a 1 tem que ser em "picos" ou situações 
esporádicas. L(q) em 1 é o limite da degradação de performance que 
afetará de forma geral o sistema. Os campos ms/r e ms/w (da(s) 
partição(es) de swap obviamente) também vão informar diretamente a 
degradação de performance em "tempo" pro usuário de forma geral do sistema.

E o principal, informação que o gstat não mostra mas o iostat si, é o 
svc_t que é o tempo médio das transações. Veja, é o médio. Informação 
precisa pra sabermos o impacto que o uso de SWAP está causando ou não no 
sistema.

Na prática meu laptop tem inicialmente 1xRAM (sim eu quis poupar espaço 
pq tem bastante RAM hehe), se fica com essa quantidade, e minha RAM fica 
perto do limite vejo que começo ter uma frequência de acesso a swap, 
mesmo com baixo consumo (8%, 12%) de páginas de swap. Não é nada crítico 
e acredito que o acesso a SWAP seja preventivo já que o FreeBSD tem 
conhecimento de Segment Stack e controle a probabilidade uma página de 
memória precisar ser acessada de acordo com a frequencia de uso de 
páginas vizinhas ou a proximidade do relacionamento das páginas em 
segmento, no momento em que páginas saem do estado "disponivel para 
paginar" e entram em wired (vm.stats.vm.v_wire_count), nesse caso a 
pagina precisa estar em RAM e não em SWAP mesmo sem uso, ou seja por 
precaução e não necessidade.

Criei então um swapfile (swapfile="" no rc.conf) dobrando a SWAP e 
apesar do consumo total ficar equivalente em páginas de memoria virtual 
alocadas (o que era 12% vai pra 6% ou 7%), o L(q) e o svc_t indicam 
menor acesso, de fato acesso só exporádico.

Porque? Porque tomadas de decisão diferente foram feitas :) Curioso 
isso. Outra coisa, é tudo muito bem feito. Quando o acesso a SWAP começa 
gerar L(q) que chegue em 1 (campo wait no iostat) as páginas "once 
wired" nunca são "paged out" porque o FreeBSD sabe que nesse caso 
estaria artificialmente causando degradação de performance. As "once 
wired" passam a ser "coloridas" (hehehe) como (tornam-se) "perm wired". 
O resultado é mais RAM necessária pras aplicações (e menos RAM 
disponível para outras coisas), e a primeira "outras coisas" a sentir 
efeito são os buffers de acesso a disco (recurso oferecido pelo 
UFS_DIRHASH do kernel), ou seja a performance é degradada em relação a 
VFS, e podemos medir (visualizar) observando picos e médias inferiores 
na utilização do (mib sysctl) vfs.bufspace.

Bem legal isso :D

> 
> Desculpem também se estou fugindo um pouco do tema..
> 
> 
> 
>> Não importa a quantidade de memória RAM, o ideal é 2xSWAP porque os
>> algorítimos de tomada de decisão do VM Subsystem conta com pelo menos
>> essa quantidade para definir o que fazer, sem desvios (e SWAP inferior
>> a
>> 2xRAM seria um desvio, SWAP inferior a 1xRAM é um segundo checkpoint
>> desviado e por último o pior, SWAP inferior a 256M é o terceiro desvio;
>> o quarto desvio é não ter SWAP e um quinto desvio não estudado é com
>> SWAP acima de 2xRAM).
>>
>> Essa é uma racterística do 4.4BSD e muito mais acentuada no FreeBSD
>> onde
>> o McKusick atuou com muita enfase nas melhorias do sistema de arqu

[FUG-BR] RES: RES: [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Renato Frederick
Opa..

Obrigado Patrick, agora posso ter um embasamento para justificar o correto
dimensionamento do SWAP, que obviamente envolve custo.

Sobre outro colega que falou do tamanho do disco, realmente até uma certa
quantia de RAM e com poucos discos podemos considerar desprezível alocar
32GB para swap, mas quando está planejando a compra de um novo hardware,
esta informação deve ser levada em conta para os pré requisitos enviados ao
comercial.
No meu caso em particular, o correto dimensionamento do swap irá alterar um
pouco  o esquema inicial do RAID, por isto a preocupação em ter referencial
do fabricante, evitando desgaste :-)

Já levando pro lado prático, não sei se um servidor em condições
normais(leia-se, não fazendo swap ou com overload), iria mudar muito com
2xRAM ou 1xRAM ou 1/2vez RAM de SWAP, nunca tive esta curiosidade e também
não tenho meios de testar, mas seria um trabalho interessante para alguém
voltado ao lado de pesquisa, se interessar, fazer e traria muito peso para
estas tomadas de decisões.

Desculpem também se estou fugindo um pouco do tema..



> 
> Não importa a quantidade de memória RAM, o ideal é 2xSWAP porque os
> algorítimos de tomada de decisão do VM Subsystem conta com pelo menos
> essa quantidade para definir o que fazer, sem desvios (e SWAP inferior
> a
> 2xRAM seria um desvio, SWAP inferior a 1xRAM é um segundo checkpoint
> desviado e por último o pior, SWAP inferior a 256M é o terceiro desvio;
> o quarto desvio é não ter SWAP e um quinto desvio não estudado é com
> SWAP acima de 2xRAM).
> 
> Essa é uma racterística do 4.4BSD e muito mais acentuada no FreeBSD
> onde
> o McKusick atuou com muita enfase nas melhorias do sistema de arquivos
> e
> gerenciamento de memória. Gerenciamento de memória no FreeBSD sempre
> foi
> mesmo uma questão que deixa quem ta acostumado com outros sistemas um
> pouco confuso porque não fica usando decisões típicas como aplicando
> LRU, MRU, pra decidir o que entra ou sai da swap. Alias não existe
> diferença entre SWAP, RAM ou File System do ponto de vista do usuário
> (apenas o kernel sabe o que é o que).
> 
> De qualquer forma se é preciso apenas uma referência "formal" segue o
> trecho relevante de "man 7 tuning":
> 
> -
> You should typically size your swap space to approximately 2x main
> memory.  If you do not have a lot of RAM, though, you will generally
> want a lot more swap.  It is not recommended that you configure any
> less
> than 256M of swap on a system and you should keep in mind future memory
> expansion when sizing the swap partition.  The kernel's VM paging
> algorithms are tuned to perform best when there is at least 2x swap
> versus main memory.  Configuring too little swap can lead to
> inefficiencies in the VM page scanning code as well as create issues
> later on if you add more memory to your machine.
> -
> 
> Na prática no FreeBSD 3 era ainda ideal 2xRAM divididos em 4 partições
> distintas de SWAP. No 4.x o Matt Dillon (orientado pelo McKusick)
> deixou
> de fazer o Fixed Interleave e conseguiu manter a mesma performance com
> Dynamic Interleave usando pra isso o algorítimo de estrutura de dados
> Radix Tree (árvore Radix, um tipo especial de Trie - árvore ordenada -
> típica coisa que meu professor de E.D. não ensinou na graduação, ele
> preferia complicar em pascal uma fila/lista do que ensinar algorítimos
> que o valham, em linguagem que o valha).
> 
> Uma visão um pouco técnica porém não muito de como o VM subsystem
> funciona pode ser encontrada aqui:
> 
> http://www.freebsd.org/doc/en/articles/vm-design/
> 
> Um trecho introdutório que eu gosto muito:
> 
> "Much of the apparent complexity of the FreeBSD design, especially in
> the VM/Swap subsystem, is a direct result of having to solve serious
> performance issues that occur under various conditions. These issues
> are
> not due to bad algorithmic design but instead rise from environmental
> factors. In any direct comparison between platforms, these issues
> become
> most apparent when system resources begin to get stressed. As I
> describe
> FreeBSD's VM/Swap subsystem the reader should always keep two points in
> mind. First, the most important aspect of performance design is what is
> known as “Optimizing the Critical Path”. It is often the case that
> performance optimizations add a little bloat to the code in order to
> make the critical path perform better. Second, a solid, generalized
> design outperforms a heavily-optimized design over the long run. While
> a
> generalized design may end up being slower than an heavily-optimized
> design when they are first implemented, the generalized design tends to
> be easier to adapt to changing conditions and the heavily-optimized
> design winds up having to be thrown away. Any codebase that will
> survive
> and be maintainable for years must therefore be designed properly from
> the beginning even if it costs some performance."
> 
> Historicamente o principal responsavel pelo gerenciamento de memoria no
> Lin

Re: [FUG-BR] RES: [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Patrick Tracanelli
Renato Frederick escreveu:
> Mas considere que eu desativo o core dump, até porque tive um problema com
> um aplicativo simples(gocr) que dava crash cada vez que escaneava emails(era
> uma lib errada)... acabou por lotar o disco com centenas de dump.. :)
> 
> Concordo com a janela de tempo que um swap oferece, mas ainda não obtive
> nada de concreto sobre valores.. já vi gente usar  swap=RAM, swap=2xRAM...
> eu a partir de 4GB de RAM uso swap=RAM... mas fica só no "acho" mesmo, nada
> oficial
> 
> Abraços
> 
>> Não tenho a explicação oficial, mas eu já passei por algumas situações
>> onde o Free dá pau e é necessário gerar um crash dump da memória, isso
>> quer dizer que quando ocorre algum kernel panic, no proximo reboot o
>> swap é utilizado para "copiar" o conteúdo da memória antes de gerar o
>> crash dump, se você tiver o swap menor ou do tamanho exato da memória
>> você não consegue gerar o dump. Este tipo de crash dump é utilizado
>> para diagnóstico/correção do problema.
>>
>> Outras razão seria estabilidade mesmo, de repente você tem uma
>> aplicação que por algum motivo começa a consumir MUITA memória, você
>> tendo um swap grande vai ter mais tempo para atuar antes de começar a
>> tomar vários erros. Claro que em todo o caso esqueça performance
>> quando o swap é usado, mas isso já é outra historia
>> -
>> 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

Não importa a quantidade de memória RAM, o ideal é 2xSWAP porque os 
algorítimos de tomada de decisão do VM Subsystem conta com pelo menos 
essa quantidade para definir o que fazer, sem desvios (e SWAP inferior a 
2xRAM seria um desvio, SWAP inferior a 1xRAM é um segundo checkpoint 
desviado e por último o pior, SWAP inferior a 256M é o terceiro desvio; 
o quarto desvio é não ter SWAP e um quinto desvio não estudado é com 
SWAP acima de 2xRAM).

Essa é uma racterística do 4.4BSD e muito mais acentuada no FreeBSD onde 
o McKusick atuou com muita enfase nas melhorias do sistema de arquivos e 
gerenciamento de memória. Gerenciamento de memória no FreeBSD sempre foi 
mesmo uma questão que deixa quem ta acostumado com outros sistemas um 
pouco confuso porque não fica usando decisões típicas como aplicando 
LRU, MRU, pra decidir o que entra ou sai da swap. Alias não existe 
diferença entre SWAP, RAM ou File System do ponto de vista do usuário 
(apenas o kernel sabe o que é o que).

De qualquer forma se é preciso apenas uma referência "formal" segue o 
trecho relevante de "man 7 tuning":

-
You should typically size your swap space to approximately 2x main 
memory.  If you do not have a lot of RAM, though, you will generally 
want a lot more swap.  It is not recommended that you configure any less 
than 256M of swap on a system and you should keep in mind future memory 
expansion when sizing the swap partition.  The kernel's VM paging 
algorithms are tuned to perform best when there is at least 2x swap 
versus main memory.  Configuring too little swap can lead to 
inefficiencies in the VM page scanning code as well as create issues 
later on if you add more memory to your machine.
-

Na prática no FreeBSD 3 era ainda ideal 2xRAM divididos em 4 partições 
distintas de SWAP. No 4.x o Matt Dillon (orientado pelo McKusick) deixou 
de fazer o Fixed Interleave e conseguiu manter a mesma performance com 
Dynamic Interleave usando pra isso o algorítimo de estrutura de dados 
Radix Tree (árvore Radix, um tipo especial de Trie - árvore ordenada - 
típica coisa que meu professor de E.D. não ensinou na graduação, ele 
preferia complicar em pascal uma fila/lista do que ensinar algorítimos 
que o valham, em linguagem que o valha).

Uma visão um pouco técnica porém não muito de como o VM subsystem 
funciona pode ser encontrada aqui:

http://www.freebsd.org/doc/en/articles/vm-design/

Um trecho introdutório que eu gosto muito:

"Much of the apparent complexity of the FreeBSD design, especially in 
the VM/Swap subsystem, is a direct result of having to solve serious 
performance issues that occur under various conditions. These issues are 
not due to bad algorithmic design but instead rise from environmental 
factors. In any direct comparison between platforms, these issues become 
most apparent when system resources begin to get stressed. As I describe 
FreeBSD's VM/Swap subsystem the reader should always keep two points in 
mind. First, the most important aspect of performance design is what is 
known as “Optimizing the Critical Path”. It is often the case that 
performance optimizations add a little bloat to the code in order to 
make the critical path perform better. Second, a solid, generalized 
design outperforms a heavily-optimized design over the long run. While a 
generalized design may end up being 

[FUG-BR] RES: RES: Bloco 197/8

2008-11-28 Por tôpico Renato Frederick
Edinilson,

Quando eu coloco uma rota para o ip do blackrole pela null0, o quagga
aceita, a rota realmente aparece(se eu der um tracert ou ping não responde).

De fato, se de qualquer host interno da rede eu der um tracert para o IP que
eu fiz o blackhole, ele não passa do firewall.

Porém a rota não aparece na tabela bgp, quando eu fizer o route-map, e aí
que fica o problema:

Se eu digitar um "sh ip bgp" não aparece as rotas para os bogons apontando
para o IP blackrole.

Daí veja o que eu fiz no freebsd:

##BlackHole
cloned_interfaces="disc0"
ifconfig_disc0="192.0.2.1 netmask 255.255.255.255"
route_blackhole="10.255.255.254/32 192.0.2.1"
static_routes="blackhole"


a rota "blackhole"acima pode ser substituída dentro do quagga para:
ip route 10.255.255.254/32 192.0.2.1 

fica a seu critério.

Daí eu fiz o route-map:


route-map CYMRUBOGONS permit 10
 match community 10
 set ip next-hop 10.255.255.254
 set origin igp

Eu achei muito estranho também, afinal um tracert funcionava mas não
aparecia no BGP... achei que era erro do meu route-map, etc..

até que achei esta discussão:

http://osdir.com/ml/network.quagga.user/2004-10/msg00157.html


e achei interessante esta parte:

FreeBSD has RTF_BLACKHOLE and RTF_REJECT flags in kernel RIB rtentry which
is
triggered by 'ip route a.b.c.d/32 Null0' or 'ip route a.b.c.d/32 reject'
respectively. Linux also provides blackhole capabilities in the kernel
routing subsystem. This is the recommended method.

Otherwise, just route to a network hosted by dummy0 or 'software discard'
e.g.
disc0/ds0 interface.

P.S. And yes there was (or is still?) a bug in zeb|Q bgpd that won't resolve
recursive routes pointed to "Null0|blackhole|reject" next-hops. But I think 
there was a recent bug id on that addressing this issue.

Aí o "truque" é que  o nex-hop nao é a null0 propriamente, mas um IP que por
sua vez aponta uma rota para null0 :)




> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Edinilson - ATINET
> Enviada em: sexta-feira, 28 de novembro de 2008 10:51
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] RES: Bloco 197/8
> Prioridade: Alta
> 
> Caro Renato, eu participo tambem da lista do Quagga e o pessoal la
> insiste
> que o null0 funciona no freebsd.
> Quais problemas voce teve em utilizar o null0 ?
> 
> Obrigado
> 
> Edinilson
> -
> ATINET-Professional Web Hosting
> Tel Voz: (0xx11) 4412-0876
> http://www.atinet.com.br
> 
> 
> - Original Message -
> From: "Renato Frederick" <[EMAIL PROTECTED]>
> To: "'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)'"
> 
> Sent: Thursday, November 27, 2008 10:21 AM
> Subject: [FUG-BR] RES: Bloco 197/8
> 
> 
> Edinilson,
> 
> Sim, uso no quagga.
> 
> Primeiro você tem que enviar um email a eles solicitando, no site
> explica o
> formato.. basicamente é falar que não quer autenticação md5 na
> sessão(quagga
> não suporta) e passar seu as e o seu ip para o peering.
> 
> Depois é só subir como se fosse uma sessão bgp normal. Como eles usam 2
> peers para a sessão, eu uso peer-group:
> 
> [...]
>  neighbor cymru-bogon peer-group
>  neighbor cymru-bogon description BOGUS-SERVER
>  neighbor cymru-bogon ebgp-multihop 255
>  neighbor cymru-bogon update-source lo0
>  neighbor cymru-bogon send-community both
>  neighbor cymru-bogon soft-reconfiguration inbound
>  neighbor cymru-bogon maximum-prefix 100 90
>  neighbor cymru-bogon prefix-list cymru-out out
>  neighbor cymru-bogon route-map CYMRUBOGONS in
>  neighbor 200.x.x.x remote-as 65333
>  neighbor 200.x.x.x peer-group cymru-bogon
>  neighbor 208.x.x.x remote-as 65333
>  neighbor 208.x8.x.x peer-group cymru-bogon
> [...]
> 
> a cymru usa a comunity 65333:888 para enviar a lista de bogus(tem
> outras 2
> comunity com mais granularidade, no site fala).
> 
> Entao, basta fazer um Black role para esta comunidade:
> 
> 
> [...]
> ip community-list 10 permit 65333:888
> route-map CYMRUBOGONS permit 10
>  match community 10
>  set ip next-hop 10.255.255.254
>  set local-preference 200
>  set origin igp
> !
> [...]
> 
> No caso, criei uma rota que entrega o IP 10.255.255.254 para minha
> interface
> "disc0" no freebsd.
> Se fosse cisco você poderia fazer um iproute 10.255.255.254 null0, mas
> o
> quagga apesar de aceitar o comando, não funciona.
> 
> 
> Talvez você precise fazer outro routemap para suprimir algumas redes
> que
> eles te mandam, no meu caso a rede 172.16 pode passar entre meus
> roteadores
> de borda, então tome cuidado.. :)
> 
> Caso você não faça o ip next-hop e entregue o tráfego para o peers
> deles, a
> sessão BGP é cancelada.
> 
> No final minha tabela de rotas fica algo assim:
> 
> *  1.0.0.0  10.255.255.254   0200  0 65333 i
> *>  10.255.255.254   0200  0 65333 i
> *  2.0.0.0  10.255.255.254   0200  0 65333 i
> *>  10.255.255.254  

Re: [FUG-BR] Certificação BSD

2008-11-28 Por tôpico Alexandre Biancalana
On 11/28/08, Patrick Tracanelli <[EMAIL PROTECTED]> wrote:
> Patrick Tracanelli escreveu:
>
> > Alexandre Biancalana escreveu:
>  >> Opa! Eu tb passei ! 605!
>  >>
>  >> e vc Patrick ?
>  >
>  > Parabéns! Eu com 679 :)
>  >
>  > To muito satisfeito, o resultado por Grupo desse exame no brasil é 694
>  > de 700, segundo melhor (segundo exame na alemanha teve Group Max de
>  > 696). Altíssimo nível =) Parabens a todos.
>
>
> O Certificado chegou, super bonito com um selo de autenticidade que
>  brilha no escuro hehehe.

O meu tb já chegou !!

Concordo com o Patrick, Certificado de qualidade e muito bom gosto!
Tem até assinaturas do comite são verdade ! Bem mais show que os
certificados de solaris e lpi!
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] Certificação BSD

2008-11-28 Por tôpico Márcio Luciano Donada
Renato Botelho escreveu:
>
> Quando vai rolar a próxima rodada de provas? Acho que vou tentar
> da próxima vez
>   

Fala Renato,
É uma boa, também quero fazer da próxima.

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


Re: [FUG-BR] RES: [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Alexandre Biancalana
On 11/28/08, Renato Frederick <[EMAIL PROTECTED]> wrote:
> Mas considere que eu desativo o core dump, até porque tive um problema com
>  um aplicativo simples(gocr) que dava crash cada vez que escaneava emails(era
>  uma lib errada)... acabou por lotar o disco com centenas de dump.. :)

Você está confundindo core dump de um programa com o crash dump que me referi.

Um core dump ocorre quando algum programa executa alguma instrução ou
acesso a região de memória ilegal ou quando recebe algum signal para
tal, então o SO gera uma imagem da memória do programa em um arquivo,
que no padrão é gerado no path onde o programa está rodando com o nome
.core, isso pode ser alterado através de parametros do
sysctl.

Um crash dump é quando o kernel executa alguma operação ilegal ou bug
(man crash), ocorre um kernel panic e o sistema reboota. Nesses casos,
o swap pode ser usado para copiar a imagem de TODA a memória do
sistema e para gerar os arquivos vmcore.[0-9] no diretorio /var/crash
(definido pela variavel dumpdir do rc.conf (man dumpdev) ) que são
utilizados para análise da falha.

Você pode tanto desativar os programas de gerarem core dump´s quando
inibir a geração dos vmcore em caso de kernel panic, lembrando que nos
dois casos são comportamentos anormais e deveria-se dar atenção para a
causa do problema, utilizando-se os arquvios gerados para análise e
correção ao invés de simplismente desabilitar a geração dos mesmos.

>
>  Concordo com a janela de tempo que um swap oferece, mas ainda não obtive
>  nada de concreto sobre valores.. já vi gente usar  swap=RAM, swap=2xRAM...
>  eu a partir de 4GB de RAM uso swap=RAM... mas fica só no "acho" mesmo, nada
>  oficial
>

Levando em consideração que os discos hoje tem tamanhos absurdos
(500G, 1TB)  a preços bem baixos, em muitos casos não faz diferença
você ter 16G ou 32G de swap.
Um servidor com 8G, 16G de ram provavelmente não terá um disco menor
que 500G. Mas é claro depende do ambiente.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] RES: Bloco 197/8

2008-11-28 Por tôpico Edinilson - ATINET
Caro Renato, eu participo tambem da lista do Quagga e o pessoal la insiste 
que o null0 funciona no freebsd.
Quais problemas voce teve em utilizar o null0 ?

Obrigado

Edinilson
-
ATINET-Professional Web Hosting
Tel Voz: (0xx11) 4412-0876
http://www.atinet.com.br


- Original Message - 
From: "Renato Frederick" <[EMAIL PROTECTED]>
To: "'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)'" 

Sent: Thursday, November 27, 2008 10:21 AM
Subject: [FUG-BR] RES: Bloco 197/8


Edinilson,

Sim, uso no quagga.

Primeiro você tem que enviar um email a eles solicitando, no site explica o
formato.. basicamente é falar que não quer autenticação md5 na sessão(quagga
não suporta) e passar seu as e o seu ip para o peering.

Depois é só subir como se fosse uma sessão bgp normal. Como eles usam 2
peers para a sessão, eu uso peer-group:

[...]
 neighbor cymru-bogon peer-group
 neighbor cymru-bogon description BOGUS-SERVER
 neighbor cymru-bogon ebgp-multihop 255
 neighbor cymru-bogon update-source lo0
 neighbor cymru-bogon send-community both
 neighbor cymru-bogon soft-reconfiguration inbound
 neighbor cymru-bogon maximum-prefix 100 90
 neighbor cymru-bogon prefix-list cymru-out out
 neighbor cymru-bogon route-map CYMRUBOGONS in
 neighbor 200.x.x.x remote-as 65333
 neighbor 200.x.x.x peer-group cymru-bogon
 neighbor 208.x.x.x remote-as 65333
 neighbor 208.x8.x.x peer-group cymru-bogon
[...]

a cymru usa a comunity 65333:888 para enviar a lista de bogus(tem outras 2
comunity com mais granularidade, no site fala).

Entao, basta fazer um Black role para esta comunidade:


[...]
ip community-list 10 permit 65333:888
route-map CYMRUBOGONS permit 10
 match community 10
 set ip next-hop 10.255.255.254
 set local-preference 200
 set origin igp
!
[...]

No caso, criei uma rota que entrega o IP 10.255.255.254 para minha interface
"disc0" no freebsd.
Se fosse cisco você poderia fazer um iproute 10.255.255.254 null0, mas o
quagga apesar de aceitar o comando, não funciona.


Talvez você precise fazer outro routemap para suprimir algumas redes que
eles te mandam, no meu caso a rede 172.16 pode passar entre meus roteadores
de borda, então tome cuidado.. :)

Caso você não faça o ip next-hop e entregue o tráfego para o peers deles, a
sessão BGP é cancelada.

No final minha tabela de rotas fica algo assim:

*  1.0.0.0  10.255.255.254   0200  0 65333 i
*>  10.255.255.254   0200  0 65333 i
*  2.0.0.0  10.255.255.254   0200  0 65333 i
*>  10.255.255.254   0200  0 65333 i

E o melhor, atualizam sempre que a IANA aloca uma rede.

Voltando ao assunto que gerou esta discussão, liberaram o bloco /20 mas não
deram satisfação de porque bloqueou e nem responderam como fazem para
bloquear, ficou algo bem arbitrário.

Abraços.




> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Edinilson - ATINET
> Enviada em: quinta-feira, 27 de novembro de 2008 09:51
> Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
> Assunto: Re: [FUG-BR] Bloco 197/8
> Prioridade: Alta
>
> Caro Renato, aproveitando o topico: voce utiliza quagga + bgpd no
> Freebsd?
> Se sim, poderia me mandar um exemplo de configuracao do bgpd para
> utilizar
> este servico da Cymru?
>
> Obrigado
>
> Edinilson
> -
> ATINET-Professional Web Hosting
> Tel Voz: (0xx11) 4412-0876
> http://www.atinet.com.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


Re: [FUG-BR] Certificação BSD

2008-11-28 Por tôpico Renato Botelho
2008/11/28 Patrick Tracanelli <[EMAIL PROTECTED]>:
> Patrick Tracanelli escreveu:
>> Alexandre Biancalana escreveu:
>>> Opa! Eu tb passei ! 605!
>>>
>>> e vc Patrick ?
>>
>> Parabéns! Eu com 679 :)
>>
>> To muito satisfeito, o resultado por Grupo desse exame no brasil é 694
>> de 700, segundo melhor (segundo exame na alemanha teve Group Max de
>> 696). Altíssimo nível =) Parabens a todos.
>
> O Certificado chegou, super bonito com um selo de autenticidade que
> brilha no escuro hehehe.

Quando vai rolar a próxima rodada de provas? Acho que vou tentar
da próxima vez

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


Re: [FUG-BR] RES: Squid em 64 bits

2008-11-28 Por tôpico William David FUG-BR
João

o COSS é quem necessita obrigatóriamente de VFS_AIO no kernel
   AUFS é outro método de storedir
quero dizer que se você compila com suporte COSS e AUFS você precisa
também fazer tunning no kernel. para esse módulo em especial. ( COSS )


COSS  == VFS_AIO  == KERNEL

AUFS    KERNEL


eu tilizei as seguintes opções no kernel

options MSGMNB=8192 # max # of bytes in a queue
options MSGMNI=40   # number of message queue identifiers
options MSGSEG=512  # number of message segments per queue
options MSGSSZ=64   # size of a message segment
options MSGTQL=2048 # max messages in system

options SHMSEG=16   # max shared mem id's per process
options SHMMNI=32   # max shared mem id's per system
options SHMMAX=2097152  # max shared memory segment size (bytes)
options SHMALL=4096 # max amount of shared memory (pages)

options VFS_AIO

até agora não tive nenhum problema com o COSS.

2008/11/27 Joao Rocha Braga Filho <[EMAIL PROTECTED]>:
> 2008/11/27 Eduardo Schoedler <[EMAIL PROTECTED]>:
>> Estou montando uma máquina com 8GB RAM e 2 discos de 500GB.
>> Irei utilizar COSS rodando direto na partição (sem filesystem) para arquivos
>> pequenos e (provavelmente AUFS) para arquivos grandes, como você disse no
>> seu e-mail sobre "COSS funciona ?".
>
> Estou tendo problemas com o COSS. Não consigo fazer funcionar.
>
> FreeBSD fire2..br 6.4-PRERELEASE FreeBSD 6.4-PRERELEASE #15: Tue
> Oct  7 14:49:31 BRT 2008   i386
>
>
> Cuidado. Existe uma interação de bibliotecas entre COSS e AUFS, como
> mostra em alguns dos links que passei no meu e-mail. Veja por volta da
> linha 255 do Makefile do /usr/ports/www/squid. Se você compila com a
> opção AUFS não precisa da opção AIO no kernel.
>
> Compilei o kernel com AIO, mas não o instalei, pois é um sistema em
> produção. Tenho que fazer isto de madrugada.
>
>
> João Rocha.
>
>>
>> Abraços,
>> Eduardo.
>>
>>
>> --
>> From: "Joao Rocha Braga Filho" <[EMAIL PROTECTED]>
>> Sent: Thursday, November 27, 2008 8:48 PM
>> To: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)"
>> 
>> Subject: Re: [FUG-BR] RES: Squid em 64 bits
>>
>>> 2008/11/27 Cristiano Maynart Pereira <[EMAIL PROTECTED]>:


 -Mensagem original-
 De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
 nome de Eduardo Schoedler
 Enviada em: quinta-feira, 27 de novembro de 2008 14:54
 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
 Assunto: [FUG-BR] Squid em 64 bits

 Olá lista.

 Alguém aqui utiliza squid com amd64 ?
 Como está se comportando ? Crashes ?
 Qual o storage que está utilizando ?


 Obrigado!

 Eduardo.


 Olá.

 Estou utilizando a quase um ano com FreeBSD 6.3 sem nenhum crash e nem
 sequer um restart, tanto de SO quanto de serviço. Storage, voce se refere
 ao cache_dir? Se sim, utilizo UFS com 15G.
>>>
>>>
>>> Primeiro, desculpe-me para a lista. Dei uma mancada e mandei uma mensagem
>>> vazia.
>>>
>>> Segundo. Acho que pode aumentar este cache tranqüilamente, caso
>>> tenha tráfego que justifique isto. Eu uso em i386 cache de 63 GB sem
>>> problemas, com a máquina tendo só 2 GB de memória.
>>>
>>>
>>> João Rocha.
>>>


 Cristiano Maynart

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

>>>
>>>
>>>
>>> --
>>> "Sempre se apanha mais com as menores besteiras. Experiência própria."
>>>
>>> [EMAIL PROTECTED]
>>> -
>>> 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
>>
>
>
>
> --
> "Sempre se apanha mais com as menores besteiras. Experiência própria."
>
> [EMAIL PROTECTED]
> -
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
>



-- 
- = - = - = - = - = - = - = - = - = -
<.  Of course it runsWilliam David Armstrong
<|==   Bio Systems Security Networking
<'  FreeBSD   MSN / GT  biosystems  gmail . com
 http://biosystems.ath.cx:8080/  http://biosystems.broker.freenet6.net/
--
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


Re: [FUG-BR] Certificação BSD

2008-11-28 Por tôpico Patrick Tracanelli
Patrick Tracanelli escreveu:
> Alexandre Biancalana escreveu:
>> Opa! Eu tb passei ! 605!
>>
>> e vc Patrick ?
> 
> Parabéns! Eu com 679 :)
> 
> To muito satisfeito, o resultado por Grupo desse exame no brasil é 694 
> de 700, segundo melhor (segundo exame na alemanha teve Group Max de 
> 696). Altíssimo nível =) Parabens a todos.

O Certificado chegou, super bonito com um selo de autenticidade que 
brilha no escuro hehehe.

> 
>>
>> On 11/21/08, Patrick Tracanelli <[EMAIL PROTECTED]> wrote:
>>> Tiago N. Sampaio escreveu:
>>>
 Aew galera chegou o resultado do exame..
>>>  > PASSSEI
>>>  > Sou certificado BSD!!!
>>>  > E os outros que fizeram a prova? como foram?
>>>
>>>
>>> Parabens, chegaram todos junto!!!
>>>
>>>  Qual foi seu Scaled Score? O JPB disse que houveram 2 com 679 no Brasil
>>>  hehehe; to impressionado com o nivel no Brasil, so 1 Item de Dominio 
>>> nao
>>>  deu 100% alguem!! E o mais absurdo, o que não deu 100% é o básico 
>>> hehehe
>>>
>>>
>>>
>>>
>>>  --
>>>  Patrick Tracanelli
>>>
>>>  FreeBSD Brasil LTDA.
>>>  Tel.: (31) 3516-0800
>>>  [EMAIL PROTECTED]
>>>  http://www.freebsdbrasil.com.br
>>>  "Long live Hanin Elias, Kim Deal!"
>>>
>>>
>>>  -
>>>  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
> 
> 


-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
[EMAIL PROTECTED]
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

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


[FUG-BR] RES: [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Renato Frederick
Mas considere que eu desativo o core dump, até porque tive um problema com
um aplicativo simples(gocr) que dava crash cada vez que escaneava emails(era
uma lib errada)... acabou por lotar o disco com centenas de dump.. :)

Concordo com a janela de tempo que um swap oferece, mas ainda não obtive
nada de concreto sobre valores.. já vi gente usar  swap=RAM, swap=2xRAM...
eu a partir de 4GB de RAM uso swap=RAM... mas fica só no "acho" mesmo, nada
oficial

Abraços

> 
> Não tenho a explicação oficial, mas eu já passei por algumas situações
> onde o Free dá pau e é necessário gerar um crash dump da memória, isso
> quer dizer que quando ocorre algum kernel panic, no proximo reboot o
> swap é utilizado para "copiar" o conteúdo da memória antes de gerar o
> crash dump, se você tiver o swap menor ou do tamanho exato da memória
> você não consegue gerar o dump. Este tipo de crash dump é utilizado
> para diagnóstico/correção do problema.
> 
> Outras razão seria estabilidade mesmo, de repente você tem uma
> aplicação que por algum motivo começa a consumir MUITA memória, você
> tendo um swap grande vai ter mais tempo para atuar antes de começar a
> tomar vários erros. Claro que em todo o caso esqueça performance
> quando o swap é usado, mas isso já é outra historia
> -
> 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] [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Alexandre Biancalana
On 11/28/08, Renato Frederick <[EMAIL PROTECTED]> wrote:
> Pessoal, bom dia..
>
>  Lendo este artigo, voltado ao Linux:
>
>  http://www.cyberciti.biz/tips/linux-swap-space.html
>
>  Há uma explicação histórica sobre a "convenção" de se usar 2xRAM para swap
>  em parte devido ao gerenciador de memória do Linux, etc, resumindo hoje em
>  dia esta recomendação, ao menos para Linux não faz mais sentido.
>
>  E para o BSD, qual é o mito, qual é a verdade?
>
>  Eu pelo menos, me recuso a perder 16GB de swap em disco se meu servidor
>  tiver 8GB, acho improvável um processo idle ocupar 8GB de RAM para ser
>  despejado para o disco. Melhor explicando, acho difícil haver processos
>  inativos que poderiam ser movidos para o disco até ocupar 16GB, bem como
>  creio não haver razão para se usar >8GB de swap(se houver 8GB de RAM). Se o
>  servidor já está fazendo swap, é hora de adicionar mais RAM ou verificar o
>  que está acontecendo..
>
>  Se alguém tiver uma explicação oficial do time de engenharia do BSD, seria
>  bacana para fins de documentação! :)

Não tenho a explicação oficial, mas eu já passei por algumas situações
onde o Free dá pau e é necessário gerar um crash dump da memória, isso
quer dizer que quando ocorre algum kernel panic, no proximo reboot o
swap é utilizado para "copiar" o conteúdo da memória antes de gerar o
crash dump, se você tiver o swap menor ou do tamanho exato da memória
você não consegue gerar o dump. Este tipo de crash dump é utilizado
para diagnóstico/correção do problema.

Outras razão seria estabilidade mesmo, de repente você tem uma
aplicação que por algum motivo começa a consumir MUITA memória, você
tendo um swap grande vai ter mais tempo para atuar antes de começar a
tomar vários erros. Claro que em todo o caso esqueça performance
quando o swap é usado, mas isso já é outra historia
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


[FUG-BR] RES: Controle de Proxy

2008-11-28 Por tôpico Renato Frederick
Dê uma olhada no patch ZPH do squid:


http://www.fugspbr.org/historico/html/freebsd/2007-08/msg00186.html



> -Mensagem original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
> nome de Cobausque
> Enviada em: sexta-feira, 28 de novembro de 2008 09:46
> Para: 'Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)'
> Assunto: [FUG-BR] Controle de Proxy
> 
> Pessoal gostaria de saber se alguém nesta lista consegue fazer uma
> compensação de acesso tipo .. tenho meu servidor com um squid rodando e
> em
> meus clientes gostaria que arquivos que estivessem no cachê cheguem de
> maneira mais rápida ao cliente  Ex.. um cliente com 300k se as
> informações estiverem em cachê Ele alcance 400k por exemplo .. mas
> estava
> procurando com ipfw... ou alguma regra semelhante... que possa estar
> testando aqui
> 
> 
> -
> 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] Controle de Proxy

2008-11-28 Por tôpico Cobausque
Pessoal gostaria de saber se alguém nesta lista consegue fazer uma
compensação de acesso tipo .. tenho meu servidor com um squid rodando e em
meus clientes gostaria que arquivos que estivessem no cachê cheguem de
maneira mais rápida ao cliente  Ex.. um cliente com 300k se as
informações estiverem em cachê Ele alcance 400k por exemplo .. mas estava
procurando com ipfw... ou alguma regra semelhante... que possa estar
testando aqui 


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


[FUG-BR] [OT?] SWAP 2x RAM

2008-11-28 Por tôpico Renato Frederick
Pessoal, bom dia..

Lendo este artigo, voltado ao Linux:

http://www.cyberciti.biz/tips/linux-swap-space.html

Há uma explicação histórica sobre a “convenção” de se usar 2xRAM para swap
em parte devido ao gerenciador de memória do Linux, etc, resumindo hoje em
dia esta recomendação, ao menos para Linux não faz mais sentido.

E para o BSD, qual é o mito, qual é a verdade?

Eu pelo menos, me recuso a perder 16GB de swap em disco se meu servidor
tiver 8GB, acho improvável um processo idle ocupar 8GB de RAM para ser
despejado para o disco. Melhor explicando, acho difícil haver processos
inativos que poderiam ser movidos para o disco até ocupar 16GB, bem como
creio não haver razão para se usar >8GB de swap(se houver 8GB de RAM). Se o
servidor já está fazendo swap, é hora de adicionar mais RAM ou verificar o
que está acontecendo..

Se alguém tiver uma explicação oficial do time de engenharia do BSD, seria
bacana para fins de documentação! :)

Abraços




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


[FUG-BR] RES: VPN

2008-11-28 Por tôpico Ricardo Augusto de Souza
Voce usa PF?

Voce pode fazer um nat para o range da VPN.

Da uma olhada em minhas regras.

# cat pf.conf|grep vpn
#Tuneis para VPN
vpn_if ="{ tun0, tun1, tun2, tun3, tun4 }"
#range VPN
vpn_net ="{ 10.10.9.0/27 }"
#NAT  para a VPN
nat on $int_if from 10.10.9.0/25 to 10.10.0.0/16 -> $int_if
#libera acesso VPN
pass in quick on $vpn_if all
pass out quick on $vpn_if all
#libera acesso a VPN na rede local
pass in quick on $int_if from $vpn_net to any modulate state
#libera acesso a VPN para rede MPLS
pass in quick on $mpls_if from $vpn_net to any modulate state
#


E qd vc se conecta na VPN sua internet ' para de funcionar ' pq por padrao a 
conexao VPN do windows deixa ativo como default gateway.



-Mensagem original-
De: [EMAIL PROTECTED] em nome de Wesley Miranda FreeBSD Consult
Enviada: sex 28/11/2008 08:09
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] VPN
 
Citando
- Original Message - 
From: "Luan Tasca" <[EMAIL PROTECTED]>
To: 
Sent: Friday, November 28, 2008 1:12 AM
Subject: [FUG-BR] VPN

Tenho um cliente, que tem uma empresa Sede e tem a filial, o ip da sede é 
192.168.5.0 e da filial 192.168.7.0 fiz uma vpn pra conectar os dois pontos 
usando pptp, conecta certinho, se eu usar na filial o ip da rede 192.168.5.0 
ele pinga certinho todas as maquinas da SEDE, mais eu queria que usando o ip 
da rede 192.168.7.0 tbem fizesse isso, como faço pra interligar as duas 
faixas de IP, e outra coisa, to na internet, dai quando conecto a VPN a 
internet para de funcionar!

---
Luan,

Seguinte,
Especifique quais configurações foram feita nas 2 pontas com relação a 
firewall e NAT

Caso estiver utilizando windows nas estações, você precisa mexer nas 
configurações da estação.

1 ° Abrir Conexões de Rede > Propriedades > Rede >  Protocolo TCP IP > 
Propriedades > Avançado
* Desmarque Usar gateway padrão em rede remota

2° O tipo de VPN você coloca PPTP VPN

3° Em segurança você marca a opção AVANÇADA ( Configurações Personalizadas )

Abraço

Wesley Miranda
FreeBSD Consult
Tel (31) 2526 8616 (31) 9426 4404
DTI - Departamento de Tecnologia da Informação
[EMAIL PROTECTED]
www.freebsdconsult.com.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


Re: [FUG-BR] VPN

2008-11-28 Por tôpico Wesley Miranda FreeBSD Consult
Citando
- Original Message - 
From: "Luan Tasca" <[EMAIL PROTECTED]>
To: 
Sent: Friday, November 28, 2008 1:12 AM
Subject: [FUG-BR] VPN

Tenho um cliente, que tem uma empresa Sede e tem a filial, o ip da sede é 
192.168.5.0 e da filial 192.168.7.0 fiz uma vpn pra conectar os dois pontos 
usando pptp, conecta certinho, se eu usar na filial o ip da rede 192.168.5.0 
ele pinga certinho todas as maquinas da SEDE, mais eu queria que usando o ip 
da rede 192.168.7.0 tbem fizesse isso, como faço pra interligar as duas 
faixas de IP, e outra coisa, to na internet, dai quando conecto a VPN a 
internet para de funcionar!

---
Luan,

Seguinte,
Especifique quais configurações foram feita nas 2 pontas com relação a 
firewall e NAT

Caso estiver utilizando windows nas estações, você precisa mexer nas 
configurações da estação.

1 ° Abrir Conexões de Rede > Propriedades > Rede >  Protocolo TCP IP > 
Propriedades > Avançado
* Desmarque Usar gateway padrão em rede remota

2° O tipo de VPN você coloca PPTP VPN

3° Em segurança você marca a opção AVANÇADA ( Configurações Personalizadas )

Abraço

Wesley Miranda
FreeBSD Consult
Tel (31) 2526 8616 (31) 9426 4404
DTI - Departamento de Tecnologia da Informação
[EMAIL PROTECTED]
www.freebsdconsult.com.br

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