from:"gondim"


On 18-09-2015 15:34, Vinícius Zavam wrote:

2015-09-18 15:03 GMT-03:00 Marcelo Gondim :


On 18-09-2015 14:41, Vinícius Zavam wrote:


2015-09-18 12:00 GMT-03:00 Marcelo Gondim :

On 18-09-2015 11:49, Vinícius Zavam wrote:

2015-09-18 11:06 GMT-03:00 Vinícius Zavam :


2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

On 17-09-2015 16:54, Marcelo Gondim wrote:


On 17-09-2015 16:44, Vinícius Zavam wrote:


2015-09-17 15:22 GMT-03:00 Marcelo Gondim :


On 17-09-2015 11:51, Luiz Otavio O Souza wrote:

2015-09-15 11:59 GMT-03:00 Marcelo Gondim:

Opa Danilo,

Pois é e a única coisa que tenho é a revisão que funciona perfeito

no
10.1-stable. Não sei se é simples achar a mudança entre as
versões
que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito
tempo.
Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
colocar
essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu
roteamento
para completamente. Só reiniciando a máquina. Agora me diga
porque
o
roteamento para de funcionar quando faço um ifconfig vlanX create
se
eu
não
tiver o gateway_enable no rc.conf? Onde que isso está escrito?
Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que
isso
não
é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum
isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2
interfaces
de
rede
pra fazer o roteamento de um lado pra outro e setem umas vlans.
Sem o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau.
Agora
se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans
sem
problemas.

São essas coisas que matam a gente.

[1]

http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html

Opa Gondim,

Nós entendemos e sabemos o quanto é frustante aguardar (sem um

ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com
voluntários,
há
muita pouca gente lá que é paga pra fazer algum serviço ou para
ser
responsável por determinada area, então mesmo com toda frustração
é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a
comunidade e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se,
é
tudo uma questão de como você interage com o projeto. O projeto
esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem
muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos),
reporte
um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto,
apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever
essa
sysctl e a única forma de você instruir os scripts para fazer a
coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele
seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e
claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)

Só desanima mas continuo na guerra rsrsrsrs


Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando
pra
1
não
voltava à funcionar. Uma doideira mesmo. Só voltava o sistema
quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de
parar.

Abrs,

gondim,


certamente tu já deves ter visto algum desses conteúdos, mas ...

+


https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui,
algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran
in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that
something
is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE


On 18-09-2015 15:30, Vinícius Zavam wrote:

2015-09-18 15:18 GMT-03:00 Marcelo Gondim :


On 18-09-2015 15:02, Vinícius Zavam wrote:


2015-09-18 11:52 GMT-03:00 Marcelo Gondim :

On 18-09-2015 11:06, Vinícius Zavam wrote:

2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

On 17-09-2015 16:54, Marcelo Gondim wrote:


On 17-09-2015 16:44, Vinícius Zavam wrote:


2015-09-17 15:22 GMT-03:00 Marcelo Gondim :


On 17-09-2015 11:51, Luiz Otavio O Souza wrote:

2015-09-15 11:59 GMT-03:00 Marcelo Gondim:

Opa Danilo,

Pois é e a única coisa que tenho é a revisão que funciona perfeito

no
10.1-stable. Não sei se é simples achar a mudança entre as versões
que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito
tempo.
Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
colocar
essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu
roteamento
para completamente. Só reiniciando a máquina. Agora me diga
porque o
roteamento para de funcionar quando faço um ifconfig vlanX create
se
eu
não
tiver o gateway_enable no rc.conf? Onde que isso está escrito?
Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que
isso
não
é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum
isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2
interfaces
de
rede
pra fazer o roteamento de um lado pra outro e setem umas vlans.
Sem
o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau.
Agora
se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1]
http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html

Opa Gondim,

Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA

definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários,
há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a
comunidade
e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto
esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte
um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever
essa
sysctl e a única forma de você instruir os scripts para fazer a
coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele
seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)

Só desanima mas continuo na guerra rsrsrsrs


Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando
pra 1
não
voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de
parar.

Abrs,

gondim,


certamente tu já deves ter visto algum desses conteúdos, mas ...

+


https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui,
algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something
is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho

que
essa revisão [1] deve reso

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE


On 18-09-2015 15:02, Vinícius Zavam wrote:

2015-09-18 11:52 GMT-03:00 Marcelo Gondim :


On 18-09-2015 11:06, Vinícius Zavam wrote:


2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

On 17-09-2015 16:54, Marcelo Gondim wrote:

On 17-09-2015 16:44, Vinícius Zavam wrote:

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :

On 17-09-2015 11:51, Luiz Otavio O Souza wrote:


2015-09-15 11:59 GMT-03:00 Marcelo Gondim:


Opa Danilo,


Pois é e a única coisa que tenho é a revisão que funciona perfeito
no
10.1-stable. Não sei se é simples achar a mudança entre as versões
que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito
tempo.
Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
colocar
essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu
roteamento
para completamente. Só reiniciando a máquina. Agora me diga porque o
roteamento para de funcionar quando faço um ifconfig vlanX create se
eu
não
tiver o gateway_enable no rc.conf? Onde que isso está escrito?
Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que isso
não
é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2 interfaces
de
rede
pra fazer o roteamento de um lado pra outro e setem umas vlans. Sem
o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau. Agora
se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1]
http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html

Opa Gondim,


Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários,
há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a comunidade
e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte
um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever
essa
sysctl e a única forma de você instruir os scripts para fazer a coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele
seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)

Só desanima mas continuo na guerra rsrsrsrs

Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando pra 1
não
voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de parar.

Abrs,

gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+

https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui,
algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something
is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?


Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho
que
essa revisão [1] deve resolver o meu problema. Ela saiu esses dias. Vou
testar hoje à noite mas estou bem otimist

Re: [FUG-BR] ipfw table list reportando endereçamento errado. // era "Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE"


On 18-09-2015 14:41, Vinícius Zavam wrote:

2015-09-18 12:00 GMT-03:00 Marcelo Gondim :


On 18-09-2015 11:49, Vinícius Zavam wrote:


2015-09-18 11:06 GMT-03:00 Vinícius Zavam :



2015-09-17 19:20 GMT-03:00 Marcelo Gondim :

On 17-09-2015 16:54, Marcelo Gondim wrote:

On 17-09-2015 16:44, Vinícius Zavam wrote:

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :

On 17-09-2015 11:51, Luiz Otavio O Souza wrote:


2015-09-15 11:59 GMT-03:00 Marcelo Gondim:


Opa Danilo,


Pois é e a única coisa que tenho é a revisão que funciona perfeito
no
10.1-stable. Não sei se é simples achar a mudança entre as versões
que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito
tempo.
Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
colocar
essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu
roteamento
para completamente. Só reiniciando a máquina. Agora me diga porque
o
roteamento para de funcionar quando faço um ifconfig vlanX create
se
eu
não
tiver o gateway_enable no rc.conf? Onde que isso está escrito?
Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que isso
não
é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum
isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2
interfaces
de
rede
pra fazer o roteamento de um lado pra outro e setem umas vlans.
Sem o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau.
Agora
se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1]
http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html

Opa Gondim,


Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários,
há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a
comunidade e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte
um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever
essa
sysctl e a única forma de você instruir os scripts para fazer a
coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele
seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)

Só desanima mas continuo na guerra rsrsrsrs

Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando pra
1
não
voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de
parar.

Abrs,

gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+

https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui,
algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something
is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?


Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho
que essa revisão [1] deve resolver o meu problema. Ela saiu esses
dias. Vo

Re: [FUG-BR] ipfw table list reportando endereçamento errado. // era "Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE"


On 18-09-2015 11:49, Vinícius Zavam wrote:

2015-09-18 11:06 GMT-03:00 Vinícius Zavam :



2015-09-17 19:20 GMT-03:00 Marcelo Gondim :


On 17-09-2015 16:54, Marcelo Gondim wrote:


On 17-09-2015 16:44, Vinícius Zavam wrote:


2015-09-17 15:22 GMT-03:00 Marcelo Gondim :

On 17-09-2015 11:51, Luiz Otavio O Souza wrote:

2015-09-15 11:59 GMT-03:00 Marcelo Gondim:

Opa Danilo,

Pois é e a única coisa que tenho é a revisão que funciona perfeito no
10.1-stable. Não sei se é simples achar a mudança entre as versões
que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito
tempo.
Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
colocar
essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu
roteamento
para completamente. Só reiniciando a máquina. Agora me diga porque o
roteamento para de funcionar quando faço um ifconfig vlanX create se
eu
não
tiver o gateway_enable no rc.conf? Onde que isso está escrito? Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que isso
não
é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2 interfaces
de
rede
pra fazer o roteamento de um lado pra outro e setem umas vlans. Sem o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau. Agora
se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1]
http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html

Opa Gondim,

Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários, há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a comunidade e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever essa
sysctl e a única forma de você instruir os scripts para fazer a coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)


Só desanima mas continuo na guerra rsrsrsrs

Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando pra 1
não
voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de parar.

Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+
https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui,
algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho
que essa revisão [1] deve resolver o meu problema. Ela saiu esses dias. Vou
testar hoje à noite mas estou bem otimista em relação à isso.  :)

[1] https://svnweb.free

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE


On 18-09-2015 11:06, Vinícius Zavam wrote:

2015-09-17 19:20 GMT-03:00 Marcelo Gondim :


On 17-09-2015 16:54, Marcelo Gondim wrote:


On 17-09-2015 16:44, Vinícius Zavam wrote:


2015-09-17 15:22 GMT-03:00 Marcelo Gondim :

On 17-09-2015 11:51, Luiz Otavio O Souza wrote:

2015-09-15 11:59 GMT-03:00 Marcelo Gondim:

Opa Danilo,

Pois é e a única coisa que tenho é a revisão que funciona perfeito no
10.1-stable. Não sei se é simples achar a mudança entre as versões que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito
tempo.
Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não
colocar
essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu
roteamento
para completamente. Só reiniciando a máquina. Agora me diga porque o
roteamento para de funcionar quando faço um ifconfig vlanX create se
eu
não
tiver o gateway_enable no rc.conf? Onde que isso está escrito? Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que isso
não
é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2 interfaces
de
rede
pra fazer o roteamento de um lado pra outro e setem umas vlans. Sem o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau. Agora
se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1]
http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html

Opa Gondim,

Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários, há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a comunidade e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever essa
sysctl e a única forma de você instruir os scripts para fazer a coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)


Só desanima mas continuo na guerra rsrsrsrs

Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando pra 1
não
voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de parar.

Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+
https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui, algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive
messages
from the switch, and only took a channel down if the link state went
down. "

" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. "
(sys/net/ieee8023ad_lacp.c)

[ ] ' s


Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho que
essa revisão [1] deve resolver o meu problema. Ela saiu esses dias. Vou
testar hoje à noite mas estou bem otimista em relação à isso.  :)

[1] https://svnweb.freebsd.org/base?view=revision&revision=287723

Ab

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE


On 17-09-2015 16:54, Marcelo Gondim wrote:

On 17-09-2015 16:44, Vinícius Zavam wrote:

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :


On 17-09-2015 11:51, Luiz Otavio O Souza wrote:


2015-09-15 11:59 GMT-03:00 Marcelo Gondim:


Opa Danilo,

Pois é e a única coisa que tenho é a revisão que funciona perfeito no
10.1-stable. Não sei se é simples achar a mudança entre as versões 
que

saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito 
tempo.

Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não 
colocar

essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu 
roteamento

para completamente. Só reiniciando a máquina. Agora me diga porque o
roteamento para de funcionar quando faço um ifconfig vlanX create 
se eu

não
tiver o gateway_enable no rc.conf? Onde que isso está escrito? Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que 
isso não

é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2 
interfaces de

rede
pra fazer o roteamento de um lado pra outro e setem umas vlans. Sem o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau. 
Agora se

colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1] 
http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html



Opa Gondim,

Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários, há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a comunidade e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever essa
sysctl e a única forma de você instruir os scripts para fazer a coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)

Só desanima mas continuo na guerra rsrsrsrs

Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando pra 
1 não

voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de parar.

Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+ 
https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html

+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da 
freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui, 
algumas

palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive 
messages
from the switch, and only took a channel down if the link state went 
down. "


" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. " 
(sys/net/ieee8023ad_lacp.c)


[ ] ' s



Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho 
que essa revisão [1] deve resolver o meu problema. Ela saiu esses 
dias. Vou testar hoje à noite mas estou bem otimista em relação à 
isso.  :)


[1] https://svnweb.freebsd.org/base?view=revision&revision=287723

Abrs,
Gondim 
É não adiantou. Coloquei a stable mais re

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE


On 17-09-2015 16:44, Vinícius Zavam wrote:

2015-09-17 15:22 GMT-03:00 Marcelo Gondim :


On 17-09-2015 11:51, Luiz Otavio O Souza wrote:


2015-09-15 11:59 GMT-03:00 Marcelo Gondim:


Opa Danilo,

Pois é e a única coisa que tenho é a revisão que funciona perfeito no
10.1-stable. Não sei se é simples achar a mudança entre as versões que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito tempo.
Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não colocar
essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu roteamento
para completamente. Só reiniciando a máquina. Agora me diga porque o
roteamento para de funcionar quando faço um ifconfig vlanX create se eu
não
tiver o gateway_enable no rc.conf? Onde que isso está escrito? Fiquei
meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que isso não
é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2 interfaces de
rede
pra fazer o roteamento de um lado pra outro e setem umas vlans. Sem o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau. Agora se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1] http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html


Opa Gondim,

Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários, há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a comunidade e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever essa
sysctl e a única forma de você instruir os scripts para fazer a coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.

Grande LooS  :)

Só desanima mas continuo na guerra rsrsrsrs

Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando pra 1 não
voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando
reiniciado e como estava em produção não deu pra fazer mais testes,
infelizmente. Só achei estranho isso acontecer.
Não sei se ele altera alguma outra sysctl que seria o motivo de parar.

Abrs,


gondim,

certamente tu já deves ter visto algum desses conteúdos, mas ...

+ https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037738.html
+ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=185967

chegou a aplicar algumas das alterações sugeridas na thread da freebsd-net@,
ou na página do bugzilla pelos próprios desenvolvedores? // aqui, algumas
palavras do scottl@ na thread da lista freebsd-net:

" The difference between FreeBSD 9.x and 10 is that in 9.x, it ran in
“optimistic” mode, meaning that it didn’t rely on getting receive messages
from the switch, and only took a channel down if the link state went down. "

" The ‘flapping’ message is intentional, it points out that something is
wrong with heartbeat exchange with the switch. " (sys/net/ieee8023ad_lacp.c)

[ ] ' s



Opa Egypcio tranquilo?

Então tava olhando o log das modificações do ieee8023ad_lacp.c e acho 
que essa revisão [1] deve resolver o meu problema. Ela saiu esses dias. 
Vou testar hoje à noite mas estou bem otimista em relação à isso.  :)


[1] https://svnweb.freebsd.org/base?view=revision&revision=287723

Abrs,
Gondim


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

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE


On 17-09-2015 13:32, Luiz Otavio O Souza wrote:

2015-09-15 6:28 GMT-03:00 Marcelo Gondim:

Olá meus amigos,

Não sei se sou azarado ou o que. Um ano atrás tive problemas com as
interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que ficar
dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano com esse
problema. Tentei as listas e cheguei à fazer até um PR e nada. Um belo dia
atualizei o router no STABLE e pronto, problema resolvido. O que foi feito
não faço ideia mas resolveu depois de 1 ano de sofrimento de ter trocado
todo o hardware e achando que era temperatura interna da X520-SR2.

Patrick até tentou me ajudar nessa época mas o jeito foi deixar um script
testando e levantando a interface sempre que caía. Pura gambiarra, coisa
feia de se ver em um sistema.  rsrsrsrsrs

Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí então
resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido às melhorias da
10.1 para a 10.2 e mais uma vez me decepcionei com o sistema.

Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava no
horário de pico e subia o tráfego nesses laggs, simplesmente meu load subia
pra 40.x à 53.x, minha sessão BGP de um desses laggs com a operadora caía e
levantava de 5 em 5 minutos me gerando grande problema aqui no provedor.


A partir dessa revisão que você colocou (r281235) houveram apenas 3
commits no if_lagg.c:

https://svnweb.freebsd.org/base/stable/10/sys/net/if_lagg.c?view=log

Isso se o problema for realmente no lagg e não em algum outro ponto do
sistema (driver da placa de rede, etc, etc, etc).

Sei que é difícil testar em produção, mas se você pudesse verificar
qual desses commits introduziu o problema que esta vendo isso seria
ótimo!

[]'s
Luiz
Pois é eu mandei lacp porque essa mensagem de flapping está no fonte do 
sys/net/ieee8023ad_lacp.c mas é como você disse pode estar relacionado 
com outro problema.
Hoje vou bootar com o 10.2-STABLE, que baixei de ontem, para ver se já 
não foi corrigido nesse meio tempo.


Estou torcendo para que já esteja corrigido pelo menos no STABLE porque 
usar o CURRENT é doideira demais. :)


Agora essa do ipfw o Melifaro até hoje não fez uma MFC e isso tá desde o 
10.0. Só vejo 2 motivos para isso não ter ocorrido ainda: deve ser 
complexo de mudar na 10.2 ou vai afetar o POLA. Eu instalei o 11 aqui 
para ver e realmente o ipfw ficou bem legal porque inclusive não 
precisei mudar meus scripts de firewall e porque agora podemos dar nomes 
nas tables.  :)  Espero ver logo uma MFC do ipfw no stable. rsrsrsr


Abrs e darei notícias,






Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping

Aí pensei comigo... estava tudo funcionando e não vou cometer o mesmo erro
que cometi com a X520-SR2. Voltei para o 10.1-STABLE r281235 e pronto! Tudo
voltou à funcionar como era antes. Assim fica difícil confiar na
estabilidade e robustez de um sistema. Só Deus sabe agora quando que isso
será resolvido no sistema. 1 ano? 2 anos? Bem, vou começar à pensar em algo
como Juniper porque pelo menos vou poder cobrar de alguém quando isso
acontecer. Uns anos atrás saí do Linux para FreeBSD porque este resolveu
meus problemas, coisas que o Linux não me atendia mas que agora está me
deixando chateado com essas coisas. Saí do problema do ksoftirq do Linux
para outros problemas de instabilidade no FreeBSD.

Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem PR, já
comentei na freebsd-stable? Tudo bem que pode não afetar o sistema mas já
acertaram na CURRENT faz tempo, pelo menos foi o que me disseram na lista. É
uma coisa feia demais para um sistema tão bem trabalhado:

Experimentem fazer:

# ipfw table 100 add 0.0.0.0/8

Agora o resultado:

  # ipfw table 100 list
::/8 0

iptables pode ser estranho ou difícil de aprender mas nunca vi algo assim
nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e cá estamos no
10.2 e continua esse bug horrendo.

Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando que isso
vai ser resolvido porque ao meu ver isso é sério e muita gente usa lagg no
sistema e com certeza é um problema porque voltei a versão e tudo
normalizou. Fiquei 3 dias com esse proble

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE


On 17-09-2015 11:51, Luiz Otavio O Souza wrote:

2015-09-15 11:59 GMT-03:00 Marcelo Gondim:

Opa Danilo,

Pois é e a única coisa que tenho é a revisão que funciona perfeito no
10.1-stable. Não sei se é simples achar a mudança entre as versões que
saíram mas algo mudou nesse meio do caminho destruiu meu cenário.

Outra recente também que descobri e que sofri por muito mas muito tempo. Não
sei se lembram dessa thread [1] que abri em abril do ano passado.
Sabe qual era a solução desse problema?

Colocar um simples: gateway_enable="YES" no /etc/rc.conf

Ou seja, mesmo colocando o net.inet.ip.forwarding=1 se você não colocar essa
instrução no rc.conf e mandar criar uma vlan, simplesmente seu roteamento
para completamente. Só reiniciando a máquina. Agora me diga porque o
roteamento para de funcionar quando faço um ifconfig vlanX create se eu não
tiver o gateway_enable no rc.conf? Onde que isso está escrito? Fiquei meses
com esse problema e agora não tenho mais.

Pior é que os caras que me responderam isso na lista acham que isso não é um
bug. Só teve 1 que achou que era um bug. Não faz sentido algum isso.
Podem fazer esse teste. Peguem um FreeBSD 10.x coloquem 2 interfaces de rede
pra fazer o roteamento de um lado pra outro e setem umas vlans. Sem o
parâmetro acima experimentem fazer um simples:

# ifconfig vlan200 create

Depois tentem pingar de uma rede pra outra. Não vai nem à pau. Agora se
colocarem o parâmetro acima no rc.conf vocês podem criar vlans sem
problemas.

São essas coisas que matam a gente.

[1] http://www.fug.com.br/historico/html/freebsd/2014-04/msg00154.html

Opa Gondim,

Nós entendemos e sabemos o quanto é frustante aguardar (sem um ETA
definido) uma resposta ou uma correção nesses casos (eu também já
estive nessa posição).

É sempre importante lembrar que o projeto trabalha com voluntários, há
muita pouca gente lá que é paga pra fazer algum serviço ou para ser
responsável por determinada area, então mesmo com toda frustração é
importante manter uma atitude positiva.

Pessoas com a atitude positiva se relacionam melhor com a comunidade e
se relacionando bem as pessoas vão se lembrar de você. Lembre-se, é
tudo uma questão de como você interage com o projeto. O projeto esta
sempre acompanhando as pessoas, todo contribuidor eventual é um
possível desenvolvedor.

Mesmo com todos esses problemas, eu aposto que você ainda tem muito
mais chances de ter o seu problema resolvido no FreeBSD do que no
mikrotik ou no Windows (mesmo os últimos dois sendo pagos), reporte um
problema lá e depois me diga quando foram resolvidos ;-)

Bom, quanto a esse problema do gateway_enable, esta correto, apenas
adicionando o net.inet.ip.forwarding=1 não é o bastante para que o
sistema funcione, existem casos onde os scripts rc vão reescrever essa
sysctl e a única forma de você instruir os scripts para fazer a coisa
certa é através da variável gateway_enable.

O roteamento para de funcionar porque quando você cria a vlan ele seta
a sysctl de volta pra 0, pode fazer o teste. Basta setar a sysctl
novamente para tudo voltar a funcionar, não precisa reiniciar.

Contribua com a documentação do projeto, deixe isso escrito e claro
para que outras pessoas não tenham a mesma dificuldade.


Grande LooS  :)

Só desanima mas continuo na guerra rsrsrsrs

Então pois é. Eu vi que a sysctl voltava pra 0 mas mesmo setando pra 1 
não voltava à funcionar. Uma doideira mesmo. Só voltava o sistema quando 
reiniciado e como estava em produção não deu pra fazer mais testes, 
infelizmente. Só achei estranho isso acontecer.

Não sei se ele altera alguma outra sysctl que seria o motivo de parar.

Abrs,


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

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

2015-09-16 Por tôpico Marcelo Gondim


Opa Eduardo,

On 16-09-2015 02:11, Eduardo Schoedler wrote:

Em quarta-feira, 16 de setembro de 2015, Marcelo Gondim <
gon...@bsdinfo.com.br> escreveu:


É complicado eu fazer isso pois o router segura a Internet de 4 cidades.
São quase 4.5Gbps de tráfego e mais de 20.000 assinantes.


É muita loucura deixar todo esse tráfego somente em 1 router.

Devia ter, pelo menos, mais um... e cada um deles deve suportar sozinho
todo o tráfego, para caso um caia (ou você precise reiniciar).
Nós temos outro equipamento idêntico pronto para entrar, para o caso do 
principal apresentar algum problema.







- Investir uma grana em Juniper MX5.


No patamar de tráfego que você está, já devia estar no seu planejamento de
curto prazo, ainda mais se você é provedor.
Já está na minha planilha mas não para o momento, pois estamos 
terminando de construir nosso prédio sede onde teremos nosso HeadEnd de 
IPTV. Esperamos que fique pronto até dezembro e até o momento o 
equipamento tem suportado tranquilamente. se não fossem esses problemas 
que surgiram.




--
Eduardo Schoedler





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

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

2015-09-15 Por tôpico Marcelo Gondim


On 15-09-2015 22:08, Giovanni Tirloni wrote:

On 09/15/2015 06:28 AM, Marcelo Gondim wrote:
Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava 
no horário
de pico e subia o tráfego nesses laggs, simplesmente meu load subia 
pra 40.x à
53.x, minha sessão BGP de um desses laggs com a operadora caía e 
levantava de 5

em 5 minutos me gerando grande problema aqui no provedor.

Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped
DISTRIBUTING, possible flapping


Ola Marcelo,

 Não sei até que ponto você está disposto a investigar esse problema, 
mas se puder voltar para o 10.2 e iniciar a maquina em verbose mode 
[1], pode ser que outras mensagens ajudem a elucidar esse problema.


 Você poderia enviar a saída do ifconfig das interfaces ixb/lagg, a 
configuração do link aggr switch, as informações físicas da interface 
(pciconf -lv) e de boot (egrep ´(lagg|igb)' /var/run/dmesg.boot)?


 Desde a 10.1-RELEASE, o driver igb teve muitas mudanças. É difícil 
dizer exatamente o que pode ter causado essa regressão sem mais detalhes.


[1] - 
https://www.freebsd.org/doc/handbook/boot-introduction.html#boot-init

Opa Giovanni,

É complicado eu fazer isso pois o router segura a Internet de 4 cidades. 
São quase 4.5Gbps de tráfego e mais de 20.000 assinantes.
Se eu fizer isso vou ter muitos cancelamentos tendo em vista que já 
fiquei uns 3 dias apresentando esse problema e achando que era uma das 
Operadoras de trânsito. Não posso colocar um ambiente desse em testes, 
infelizmente.


Por isso informei a revisão que estava usando sem problemas, para tentar 
ajudar à descobrir o que foi alterado nesse espaço de tempo e que possa 
estar causando isso.
Com relação ao fato de que o próprio pessoal do projeto usa o FreeBSD 
11, eu vejo isso como um grande erro. O current deveria ser testado sim 
mas antes de mais nada deveria ser usado a versão de produção que é a 
10.x e torná-la mais estável e robusta ainda. Somente usando o sistema, 
é que se encontram as falhas.


Para mim os nomes deveriam ser diferentes então: STABLE deveria se 
chamar TESTING, RELEASE de UNSTABLE e o CURRENT de RELEASE. Ouvi muito 
sobre a organização em que é feito o sistema. A versão 8.x na qual 
comecei à ver FreeBSD era excelente e me ajudou bastante. Mas 
sinceramente nesses últimos anos me deparo com algumas coisas que parece 
coisa de "universitário" mesmo. Me lembra o RouterOS da Mikrotik onde 
mexem em uma coisa e estraga outra e vai mexendo e tentando acertar.


As versões de produção deveriam ser a mais rock solid possível, ainda 
lembro dessa frase. No entanto cada vez que atualizo para uma release, 
algo acontece e coisas param de funcionar ou passam à funcionar meia 
boca. Mesmo acontecendo essas coisas faço a minha parte que é abrir um 
PR e mandar e-mail para as listas freebsd-stable ou freebsd-net mas sem 
evolução do problema.


Mesmo com todos esses problemas o FreeBSD ainda é o sistema que aguenta 
e segura o meu tráfego e gostaria de vê-lo melhorar cada vez mais. 
Continuar levantando essa bandeira mas é preciso que o pessoal do core 
ou alguém lá acorde para esses problemas. Hoje minha realidade é a seguinte:


- Ficar fazendo testes com o sistema em produção, derrubando os 
assinantes até descobrir onde está o problema.
- Esperar que alguém passe pelo mesmo problema e consiga reproduzir o 
erro para que seja corrigido em algum momento virando uma MFC.
- Mudar para STABLE e ficar atualizando o source de tempo em tempo, 
torcendo para que alguém descubra algo errado e corrija. Como foi meu 
caso com a X520-SR2.
- Mudar para o CURRENT e ficar correndo riscos mas pelo jeito é o que o 
Projeto FreeBSD está usando em produção.
- Aprender à programar em C, estudar o código do source, corrigir e 
disponibilizar o patch.

- Contratar um programador C para estudar o problema e resolver.
- Investir uma grana em Juniper MX5.

Não estou vendo muitas opções boas mas são essas aí.
Estou muito desanimado com o sistema mas agora tenho que manter até onde 
eu consiga.


[]'s
Gondim

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

Re: [FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

2015-09-15 Por tôpico Marcelo Gondim


On 15-09-2015 11:41, Danilo Egea Gondolfo wrote:

On 09/15/2015 06:28, Marcelo Gondim wrote:

Olá meus amigos,

Não sei se sou azarado ou o que. Um ano atrás tive problemas com as 
interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que 
ficar dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano 
com esse problema. Tentei as listas e cheguei à fazer até um PR e 
nada. Um belo dia atualizei o router no STABLE e pronto, problema 
resolvido. O que foi feito não faço ideia mas resolveu depois de 1 
ano de sofrimento de ter trocado todo o hardware e achando que era 
temperatura interna da X520-SR2.


Patrick até tentou me ajudar nessa época mas o jeito foi deixar um 
script testando e levantando a interface sempre que caía. Pura 
gambiarra, coisa feia de se ver em um sistema.  rsrsrsrsrs


Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí 
então resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido às 
melhorias da 10.1 para a 10.2 e mais uma vez me decepcionei com o 
sistema.


Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava 
no horário de pico e subia o tráfego nesses laggs, simplesmente meu 
load subia pra 40.x à 53.x, minha sessão BGP de um desses laggs com a 
operadora caía e levantava de 5 em 5 minutos me gerando grande 
problema aqui no provedor.


Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface 
stopped DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface 
stopped DISTRIBUTING, possible flapping


Aí pensei comigo... estava tudo funcionando e não vou cometer o mesmo 
erro que cometi com a X520-SR2. Voltei para o 10.1-STABLE r281235 e 
pronto! Tudo voltou à funcionar como era antes. Assim fica difícil 
confiar na estabilidade e robustez de um sistema. Só Deus sabe agora 
quando que isso será resolvido no sistema. 1 ano? 2 anos? Bem, vou 
começar à pensar em algo como Juniper porque pelo menos vou poder 
cobrar de alguém quando isso acontecer. Uns anos atrás saí do Linux 
para FreeBSD porque este resolveu meus problemas, coisas que o Linux 
não me atendia mas que agora está me deixando chateado com essas 
coisas. Saí do problema do ksoftirq do Linux para outros problemas de 
instabilidade no FreeBSD.


Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem 
PR, já comentei na freebsd-stable? Tudo bem que pode não afetar o 
sistema mas já acertaram na CURRENT faz tempo, pelo menos foi o que 
me disseram na lista. É uma coisa feia demais para um sistema tão bem 
trabalhado:


Experimentem fazer:

# ipfw table 100 add 0.0.0.0/8

Agora o resultado:

 # ipfw table 100 list
::/8 0

iptables pode ser estranho ou difícil de aprender mas nunca vi algo 
assim nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e 
cá estamos no 10.2 e continua esse bug horrendo.


Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando 
que isso vai ser resolvido porque ao meu ver isso é sério e muita 
gente usa lagg no sistema e com certeza é um problema porque voltei a 
versão e tudo normalizou. Fiquei 3 dias com esse problema me 
ferrando, para não dizer outra coisa, aqui no provedor.


 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031

Desculpem o desabafo mas puts essa me deixou chateado demais com o 
sistema, ainda mais pela importância que ele tem para o meu negócio 
hoje.


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


Fala Gondim,

esse tipo de problema é osso mesmo...

Pelo que leio e ouço, esses problemas nas releases se devem a pelo 
menos duas coisas: boa parte dos desenvolvedores não usam FreeBSD em 
seus computadores principais (Mac!) (ouçam o adrian@ desabafando no 
bsdnow 101 sobre comer sua própria comida de cachorro) e boa parte dos 
que usam FreeBSD usam o CURRENT (tipo eu :P). Então nós mesmos 
acabamos não vendo os problemas que saem nas releases e acabamos não 
tendo a mesma experiência que os usuário tem, e isso está muito errado...


Outra zica é que esses problemas as vezes são difíceis de se 
reproduzir, pelo pouco que olhei no google aqui parece que seu 
problema está relacionado com lagg + igb + condições de tráfego. As 
vezes se o cara não tiver acesso ao mesmo cenário fica foda achar o

[FUG-BR] Problema sério com link aggregation LACP no FreeBSD 10.2-RELEASE

2015-09-15 Por tôpico Marcelo Gondim


Olá meus amigos,

Não sei se sou azarado ou o que. Um ano atrás tive problemas com as 
interfaces Intel X520-SR2 que do nada elas morriam e eu tinha que ficar 
dando down e up pra elas voltarem à vida. Fiquei mais de 1 ano com esse 
problema. Tentei as listas e cheguei à fazer até um PR e nada. Um belo 
dia atualizei o router no STABLE e pronto, problema resolvido. O que foi 
feito não faço ideia mas resolveu depois de 1 ano de sofrimento de ter 
trocado todo o hardware e achando que era temperatura interna da X520-SR2.


Patrick até tentou me ajudar nessa época mas o jeito foi deixar um 
script testando e levantando a interface sempre que caía. Pura 
gambiarra, coisa feia de se ver em um sistema.  rsrsrsrsrs


Estava eu usando o router funcionando no 10.1-STABLE r281235 e aí então 
resolvi passar o mesmo para o FreeBSD 10.2-RELEASE-p2 devido às 
melhorias da 10.1 para a 10.2 e mais uma vez me decepcionei com o sistema.


Eu tenho 2 laggs nesse router e depois que atualizei, quando chegava no 
horário de pico e subia o tráfego nesses laggs, simplesmente meu load 
subia pra 40.x à 53.x, minha sessão BGP de um desses laggs com a 
operadora caía e levantava de 5 em 5 minutos me gerando grande problema 
aqui no provedor.


Nos logs ficavam aparecendo:

/var/log/messages:Sep  9 19:21:43 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:21:44 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:27:01 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:13 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:29:14 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:10 rt01 kernel: igb5: Interface stopped 
DISTRIBUTING, possible flapping
/var/log/messages:Sep  9 19:46:11 rt01 kernel: igb4: Interface stopped 
DISTRIBUTING, possible flapping


Aí pensei comigo... estava tudo funcionando e não vou cometer o mesmo 
erro que cometi com a X520-SR2. Voltei para o 10.1-STABLE r281235 e 
pronto! Tudo voltou à funcionar como era antes. Assim fica difícil 
confiar na estabilidade e robustez de um sistema. Só Deus sabe agora 
quando que isso será resolvido no sistema. 1 ano? 2 anos? Bem, vou 
começar à pensar em algo como Juniper porque pelo menos vou poder cobrar 
de alguém quando isso acontecer. Uns anos atrás saí do Linux para 
FreeBSD porque este resolveu meus problemas, coisas que o Linux não me 
atendia mas que agora está me deixando chateado com essas coisas. Saí do 
problema do ksoftirq do Linux para outros problemas de instabilidade no 
FreeBSD.


Querem ver outra coisa feia que desde o FreeBSD 10.0 existe e já tem PR, 
já comentei na freebsd-stable? Tudo bem que pode não afetar o sistema 
mas já acertaram na CURRENT faz tempo, pelo menos foi o que me disseram 
na lista. É uma coisa feia demais para um sistema tão bem trabalhado:


Experimentem fazer:

# ipfw table 100 add 0.0.0.0/8

Agora o resultado:

 # ipfw table 100 list
::/8 0

iptables pode ser estranho ou difícil de aprender mas nunca vi algo 
assim nele. Venho desde o FreeBSD 10.0 falando na lista sobre isso e cá 
estamos no 10.2 e continua esse bug horrendo.


Bem eu abri o PR sobre o problema do LACP e agora vamos ver quando que 
isso vai ser resolvido porque ao meu ver isso é sério e muita gente usa 
lagg no sistema e com certeza é um problema porque voltei a versão e 
tudo normalizou. Fiquei 3 dias com esse problema me ferrando, para não 
dizer outra coisa, aqui no provedor.


 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203031

Desculpem o desabafo mas puts essa me deixou chateado demais com o 
sistema, ainda mais pela importância que ele tem para o meu negócio hoje.


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

[FUG-BR] Sobre Netmap

2015-08-15 Por tôpico Marcelo Gondim


Bom dia pessoal,

Está tendo uma thread interessante rolando na GTER "ServerU L-800 - 
Primeiros Passos" onde perguntaram sobre o netmap e como fariam para usá-lo.
Sei que ele precisa ser adicionado ao kernel e compilado, que precisamos 
usar drivers que suportem o netmap como o igb e o ixgbe. Fazendo isso já 
teríamos automaticamente mais performance no tráfego dos pacotes?
Também vi que existe um ipfw específico para o netmap. O que mudaria 
usar esse ipfw e não usar esse ipfw?


Alguém por aqui, Patrick, Jean, LooS, Araújo, alguém poderia elucidar 
isso aí pra gente? Creio que existam mais pessoas com essas dúvidas. 
Dependendo da resposta já coloco até no blog pra mais gente poder ler e 
se inteirar.  :)


[]'s
Gondim


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

Re: [FUG-BR] Ajuda servidor deu "rollback"

2015-08-12 Por tôpico Marcelo Gondim


On 12-08-2015 11:38, Denis Granato wrote:

Isso mesmo SAUL.

Tenho 2 HDs, o HD 0, deu pau, o servidor bootou pelo HD 1 .
Pela datas dos logs o sync entre eles parou a 15 dias.

Fiz muita coisa nesses 15 dias :(
Puts que bosta heim Denis. Pior que não tem jeito não. Se eles tivessem 
sincronizados mesmo depois das suas modificações, você estaria salvo.
Eu sou daqueles mais antigos que mesmo tendo RAID 1 ou RAID 10, ainda 
gosto dos meus backups tar.gz.


Uma vez, isso já tem alguns anos, montei uns Firewalls para uma emissora 
de TV que não posso comentar o nome e depois que havia passado uns dias 
fazendo e testando toda a configuração, aconteceu o seguinte:


- Desliguei o equipamento da bancada e levei para o DC. Quando liguei 
nem boot tinha. Não havia mais nada no servidor. Era um servidor Dell e 
estava com RAID 1.


Bem não preciso dizer que perdi o trabalho de dias porque não fiz o 
backup antes de por em produção. Não acaba por aqui... refiz todo o meu 
trabalho que ainda estava fresquinho na minha cabeça e em tempo recorde. 
Só que dessa vez fiz um backup do sistema todo no meu tar.gz e joguei 
pra outra máquina em produção.
Desliguei e liguei e adivinha! Estava tudo lá. Desliguei e levei para o 
DC e quando liguei poof! Sumiu tudo novamente. O problema era quando 
tirava o cabo de força e a controladora perdia tudo. O suporte da Dell 
foi lá e trocou a controladora e resolveu o problema.


Por isso não confio 100% nessas coisas rsrsrsrsrsrs

É duro mas a gente sempre aprende assim.  :(


COloquei o HD defeituoso em outro slot no servidor, Vou tentar ler alguma
coisa

Alguma dica?  É um HP velhinho ML 350

tail -f /var/log/messages

Aug 12 11:50:14 hp-fw kernel: ciss0: *** Hot-plug drive inserted: SCSI port
1 ID 4








2015-08-12 11:07 GMT-03:00 Saul Figueiredo :


ação direta com o
disco em minha opinião; Pode ser que em algum momento, ficou pendente algum
Write no disco, que ficou sendo empilhado, empilhado, empilhado, até
esgotar todos os buffers e reiniciar.  Por costume, eu uso sempre o comando
sync[1], mesmo hoje em dia não sendo necessário hoje, após qualquer
modificação...  verifique a controladora, status dos discos, logs do iDra


-
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] Ajuda servidor deu "rollback"

2015-08-12 Por tôpico Marcelo Gondim


On 12-08-2015 10:48, Denis Granato wrote:

Bom dia Senhores,

Algo muito estranho acabou de acontecer.

Tenho um servidor free 9.1, onde rodo apache, etc,etc.

Na semana passada, instalei o mrtg entre outras coisas. Criei
algumas paginas para utilizar o weathermap aqui na rede ,etc.

Hoje o servidor rebootou sozinho, e acessando ele agora, não
está mais nada lá, como se tivesse voltado em algum ponto de restauração,

não tem o mrtg instalado, nem nada do que fiz nos últimos dias

Alguma luz?

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

Rapaz quero imaginar que esse servidor seria uma VM e alguém voltou o 
snapshot de antes de você fazer isso tudo. Porque tirando isso só posso 
acreditar que alguém teve acesso ao seu sistema e fez a limpa.


[]'s
Gondim


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

[FUG-BR] Interface Intel X520 [OFF-Topic]

2015-08-08 Por tôpico Marcelo Gondim


Buenas pessoal,

Compramos umas 6 interfaces Intel X520-SR2 (10GbE) só que quando 
chegaram na etiqueta da placa veio X520-DA2. Eu acredito ser a mesma 
interface e o que diferencia são as gbics que vem nela. Como pedimos sem 
gbic, porque já tenho, resolvi experimentar as interfaces.
Peguei 2 servidores Dell R720, coloquei uma interface em cada com as 
gbics Intel SR de 850nm e liguei uma na outra. Ao ligar os 2 servidores 
as leds acenderam na cor amarela, que segundo o manual, significa que 
está em 1GbE. Verde indicaria que negociou em 10GbE.


Instalei o FreeBSD 10.2-RC2 nas 2 máquinas e coloquei o iperf nas duas.
Em uma coloquei 192.168.1.1/24 na ix1 e rodei:

# iperf -s

Na outra coloquei 192.168.1.2/24 na ix1 e rodei:

# iperf -c 192.168.1.1 -i 1 -t 30

Nesse momento mesmo com as leds indicando 1GbE consegui bater 9.42Gbps 
de transferência, mas um tempo depois fui repetir o teste e batia entre 
2Gbps e 3Gbps. Não passava mais disso.


Troquei as placas, troquei de máquina, troquei os cabos multimodo e não 
consegui mais passar de 4Gbps.


Minhas dúvidas são:

- Será que essa interface etiquetada como X520-DA2 é mesmo igual a que 
seria X520-SR2?
- Por que no primeiro teste consegui bater 9.42Gbps e depois não 
consegui mais?

- Por que as interfaces não negociaram 10GbE e ficaram com as leds verdes?

Alguém já possou por isso?

[]'s
Gondim

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

[FUG-BR] Fwd: [FreeBSD-Announce] FreeBSD 8.4 and 8-STABLE end-of-life

2015-07-31 Por tôpico Marcelo Gondim



É pessoal adeus Freeba 8.x. Foi o primeiro FreeBSD que usei realmente em 
produção.  :)


 Forwarded Message 
Assunto:[FreeBSD-Announce] FreeBSD 8.4 and 8-STABLE end-of-life
Data:   Sat, 1 Aug 2015 00:56:21 + (UTC)
De: FreeBSD Security Officer 
Responder a:freebsd-secur...@freebsd.org
Para:   freebsd-annou...@freebsd.org



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear FreeBSD community,

FreeBSD 8.4 and 8-STABLE have reached their end-of-life and will no longer be
supported by the FreeBSD Security Team.  Users of FreeBSD 8.x are strongly
encouraged to upgrade to a newer release as soon as possible.

The currently supported branches and releases and their expected
end-of-life dates are:

 ++
 |   Branch  |   Release  |  Type  |   Release Date   | Estimated EoL |
 +---+++--+---+
 |stable/9   |n/a |n/a |n/a   |last release + 2 years |
 +---+++--+---+
 |releng/9.3 |9.3-RELEASE |Extended|July 16, 2014 |December 31, 2016  |
 +---+++--+---+
 |stable/10  |n/a |n/a |n/a   |last release + 2 years |
 +---+++--+---+
 |releng/10.1|10.1-RELEASE|Extended|November 14, 2014 |December 31, 2016  |
 ++

Please refer to https://security.freebsd.org/ for an up-to-date list of
supported releases and the latest security advisories.

- --
Xin Li
FreeBSD Security Officer
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.1.6 (FreeBSD)

iQIcBAEBCgAGBQJVvBgUAAoJEO1n7NZdz2rn48QP/RZZd0ijZb1PQOuFdQuwUBcA
jyYCIoY+bsmypuOKpArR8icUIefvlQ+9Sty+IZrcac5dS71kZjY3tX95ReEz1KaK
ZoxCl6eUg12g3J5nkNYnaH2gC/H+FClR07vmgpn6SBGh+tZOESEehfTn8HZO/DsV
cwhnDm/xat5ZWst10xm+QaXyM/hzIwkxEfORXHCs0cdSmazvHmiqp/bKNn3l2bzI
GoBlMNB/I8gHBSGMQSWfFOFTs5F1N/CyZ+hY1/cg15qXe66Zmq9HmxyruNgkSJbn
Q34Nt9RvUA6F8EsxRxhEsOy2h8iJcqebQ7BnCGaGkbtS/AaGgzJW4U8UFgNSc36p
7zyYo1oPDs34u+BmgFtiFdcER7bsGQDovKLhNLYbpl2msZGTy+q8FeERfLRnXQ6M
xgrOL11KcuuKqdtV/9Xhv+SuzCSIAlJ6KvrMHCkmywveYBiCvzVyADGC+UaRsBHd
uEHJ8h3RIpMR5Qwdrd/rBAQNl8bovhoj3BICBY8HQpOwJYNZ+IdBa3T3I8oWXTZy
LHWJhoAlnDduHg/QkAv+XuAuD4kyEo/x4DtLqXvTVDUUBkUhYM4Casqee/Bxt7gS
GsjJ/iEiyBGwRK4vVSFhI7PvQlJ/gNaL15ROfuNBY8BBmeNnqirwIaWu5kDmmwFX
K2u9SsWaBeTwtT2yAvZu
=EnmG
-END PGP SIGNATURE-
___
freebsd-annou...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-announce
To unsubscribe, send any mail to "freebsd-announce-unsubscr...@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] Qual procedimento correto para atualizar os softwares instalados?


On 28-07-2015 13:38, Kaio Rafael wrote:

Como é que você faz para listar essas opções?

Achei massa! ;)


Já instalado:
pkg info -f 

No repositório:
pkg search -f 

:D



Em 28 de julho de 2015 12:29, Marcelo Gondim  escreveu:

On 28-07-2015 13:11, Marcelo Gondim wrote:

On 28-07-2015 12:34, Kaio Rafael wrote:

Bom dia!

Essa máquina é exclusiva para Media Center (kodi, vlc,  etc), tem
vários pacotes que tive que fazer mudanças na opção de build. Usei o
portmaster mesmo, não deu nenhum galho.

Valeu o susto :)

É então nunca use o pkg pra fazer upgrade nessa máquina. rsrsrsrs
Você tá em boas mãos com o portmaster. :)

Peguei um exemplo aqui bom até mesmo para quem ainda tiver dúvidas:
Imagina que você instalou seu servidor de e-mail com postfix, suporte à
mysql e tá tudo funcionando redondo. Aí na vontade de atualizar rápido manda
um upgrade pelo pkg. O pacote binário do mail/postfix vem assim:


  postfix-2.11.5,1
Name   : postfix
Version: 2.11.5,1
Origin : mail/postfix
Architecture   : freebsd:10:x86:64
Prefix : /usr/local
Repository : FreeBSD
[pkg+http://pkg.FreeBSD.org/FreeBSD:10:amd64/latest]
Categories : mail ipv6
Licenses   : IPL10
Maintainer : oha...@freebsd.org
WWW: http://www.postfix.org/
Comment: Secure alternative to widely-used Sendmail
Options:
 BDB: off
 CDB: off
 DOCS   : on
 DOVECOT: off
 DOVECOT2   : off
 INST_BASE  : off
 LDAP   : off
 LDAP_SASL  : off
 LMDB   : off
 MYSQL  : off
 NIS: off
 PCRE   : on
 PGSQL  : off
 SASL   : off
 SASLKMIT   : off
 SASLKRB5   : off
 SPF: off
 SQLITE : off
 TEST   : off
 TLS: on
 VDA: off

Repare que as bases de dados estão todas desligadas. Bem aí nesse momento
seu servidor de e-mail vai parar assim que você reiniciar o postfix. :(

[]'s
Gondim







Em 28 de julho de 2015 10:40, Marcelo Gondim 
escreveu:

On 28-07-2015 00:34, Kaio Rafael wrote:

Desculpem se a pergunta é recorrente:

Tenho uma dúvida que já destruiu meu sistema antes ;) e por isso, não
quero fazer novamente.

Estou usando freebsd versão 10 e tenho instalado pacotes via pkg
install  e através dos ports.

Já atualizei o sistema com freebsd-update, agora preciso atualizar os
softwares instalados.

Qual é o melhor método 'pkg upgrade' ou portmaster -a ? Por exemplo,
instalei o XFCE4 pelo 'pkg install'

Pelo comando 'pkg upgrade' tenho
Installed packages to be UPGRADED:
   xfce4-desktop: 4.12.2 -> 4.12.3

enquanto no portmaster
===>>> xfce4-desktop-4.12.2
   ===>>> New version available: xfce4-desktop-4.12.3

Aparentemente não tem problema, mas não sei qual devo usar. No
Handbook eles frisam que o upgrade deve ser através desses ports

`To perform the actual upgrade, use either Portmaster or Portupgrade.`

[]'z

Bom dia Kaio,

Sugiro você usar ou pkg e instalar os binários ou fazer tudo pelo ports.
Lógico que se não forem coisas complexas como instalar um bash seria
tranquilo. O problema começa quando você instala algo pelo ports e você
faz
mudanças nas options de compilação daquele pacote e monta seu ambiente
todo
em cima disso com novas libs e tudo. Aí está tudo funcionando e você
manda
um pkg upgrade e acaba com teu sistema porque os binários atualizados
não
terão as mesmas options que você havia setado no anterior.

Uma vez fiz isso com o PC-BSD, instalei ele e comecei à instalar
programas
pelo ports, no final tava tudo quebrado. Porque foi atualizando algumas
coisas que precisavam que outras fossem recompiladas. Isso acontece
muito
com libs rsrsrsrs

Nesse seu exemplo se você não fez nenhuma mexida no xfce4-desktop
acredito
que não te dê dor de cabeça fazer pelo pkg ou pelo ports. rsrs mas entre
portupgrade e portmaster eu gosto muito mais do portmaster :)

Tem que ter cuidado mesmo. :)

[]'s
Gondim




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

Re: [FUG-BR] Qual procedimento correto para atualizar os softwares instalados?


On 28-07-2015 13:11, Marcelo Gondim wrote:

On 28-07-2015 12:34, Kaio Rafael wrote:

Bom dia!

Essa máquina é exclusiva para Media Center (kodi, vlc,  etc), tem
vários pacotes que tive que fazer mudanças na opção de build. Usei o
portmaster mesmo, não deu nenhum galho.

Valeu o susto :)

É então nunca use o pkg pra fazer upgrade nessa máquina. rsrsrsrs
Você tá em boas mãos com o portmaster. :)

Peguei um exemplo aqui bom até mesmo para quem ainda tiver dúvidas:
Imagina que você instalou seu servidor de e-mail com postfix, suporte à 
mysql e tá tudo funcionando redondo. Aí na vontade de atualizar rápido 
manda um upgrade pelo pkg. O pacote binário do mail/postfix vem assim:



 postfix-2.11.5,1
Name   : postfix
Version: 2.11.5,1
Origin : mail/postfix
Architecture   : freebsd:10:x86:64
Prefix : /usr/local
Repository : FreeBSD 
[pkg+http://pkg.FreeBSD.org/FreeBSD:10:amd64/latest]

Categories : mail ipv6
Licenses   : IPL10
Maintainer : oha...@freebsd.org
WWW: http://www.postfix.org/
Comment: Secure alternative to widely-used Sendmail
Options:
BDB: off
CDB: off
DOCS   : on
DOVECOT: off
DOVECOT2   : off
INST_BASE  : off
LDAP   : off
LDAP_SASL  : off
LMDB   : off
MYSQL  : off
NIS: off
PCRE   : on
PGSQL  : off
SASL   : off
SASLKMIT   : off
SASLKRB5   : off
SPF: off
SQLITE : off
TEST   : off
TLS: on
VDA: off

Repare que as bases de dados estão todas desligadas. Bem aí nesse 
momento seu servidor de e-mail vai parar assim que você reiniciar o 
postfix. :(


[]'s
Gondim









Em 28 de julho de 2015 10:40, Marcelo Gondim  
escreveu:

On 28-07-2015 00:34, Kaio Rafael wrote:

Desculpem se a pergunta é recorrente:

Tenho uma dúvida que já destruiu meu sistema antes ;) e por isso, não
quero fazer novamente.

Estou usando freebsd versão 10 e tenho instalado pacotes via pkg
install  e através dos ports.

Já atualizei o sistema com freebsd-update, agora preciso atualizar os
softwares instalados.

Qual é o melhor método 'pkg upgrade' ou portmaster -a ? Por exemplo,
instalei o XFCE4 pelo 'pkg install'

Pelo comando 'pkg upgrade' tenho
Installed packages to be UPGRADED:
  xfce4-desktop: 4.12.2 -> 4.12.3

enquanto no portmaster
===>>> xfce4-desktop-4.12.2
  ===>>> New version available: xfce4-desktop-4.12.3

Aparentemente não tem problema, mas não sei qual devo usar. No
Handbook eles frisam que o upgrade deve ser através desses ports

`To perform the actual upgrade, use either Portmaster or Portupgrade.`

[]'z

Bom dia Kaio,

Sugiro você usar ou pkg e instalar os binários ou fazer tudo pelo 
ports.

Lógico que se não forem coisas complexas como instalar um bash seria
tranquilo. O problema começa quando você instala algo pelo ports e 
você faz
mudanças nas options de compilação daquele pacote e monta seu 
ambiente todo
em cima disso com novas libs e tudo. Aí está tudo funcionando e você 
manda
um pkg upgrade e acaba com teu sistema porque os binários 
atualizados não

terão as mesmas options que você havia setado no anterior.

Uma vez fiz isso com o PC-BSD, instalei ele e comecei à instalar 
programas

pelo ports, no final tava tudo quebrado. Porque foi atualizando algumas
coisas que precisavam que outras fossem recompiladas. Isso acontece 
muito

com libs rsrsrsrs

Nesse seu exemplo se você não fez nenhuma mexida no xfce4-desktop 
acredito
que não te dê dor de cabeça fazer pelo pkg ou pelo ports. rsrs mas 
entre

portupgrade e portmaster eu gosto muito mais do portmaster :)

Tem que ter cuidado mesmo. :)

[]'s
Gondim


-
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] Qual procedimento correto para atualizar os softwares instalados?


On 28-07-2015 12:34, Kaio Rafael wrote:

Bom dia!

Essa máquina é exclusiva para Media Center (kodi, vlc,  etc), tem
vários pacotes que tive que fazer mudanças na opção de build. Usei o
portmaster mesmo, não deu nenhum galho.

Valeu o susto :)

É então nunca use o pkg pra fazer upgrade nessa máquina. rsrsrsrs
Você tá em boas mãos com o portmaster. :)




Em 28 de julho de 2015 10:40, Marcelo Gondim  escreveu:

On 28-07-2015 00:34, Kaio Rafael wrote:

Desculpem se a pergunta é recorrente:

Tenho uma dúvida que já destruiu meu sistema antes ;) e por isso, não
quero fazer novamente.

Estou usando freebsd versão 10 e tenho instalado pacotes via pkg
install  e através dos ports.

Já atualizei o sistema com freebsd-update, agora preciso atualizar os
softwares instalados.

Qual é o melhor método 'pkg upgrade' ou portmaster -a ? Por exemplo,
instalei o XFCE4 pelo 'pkg install'

Pelo comando 'pkg upgrade' tenho
Installed packages to be UPGRADED:
  xfce4-desktop: 4.12.2 -> 4.12.3

enquanto no portmaster
===>>> xfce4-desktop-4.12.2
  ===>>> New version available: xfce4-desktop-4.12.3

Aparentemente não tem problema, mas não sei qual devo usar. No
Handbook eles frisam que o upgrade deve ser através desses ports

`To perform the actual upgrade, use either Portmaster or Portupgrade.`

[]'z

Bom dia Kaio,

Sugiro você usar ou pkg e instalar os binários ou fazer tudo pelo ports.
Lógico que se não forem coisas complexas como instalar um bash seria
tranquilo. O problema começa quando você instala algo pelo ports e você faz
mudanças nas options de compilação daquele pacote e monta seu ambiente todo
em cima disso com novas libs e tudo. Aí está tudo funcionando e você manda
um pkg upgrade e acaba com teu sistema porque os binários atualizados não
terão as mesmas options que você havia setado no anterior.

Uma vez fiz isso com o PC-BSD, instalei ele e comecei à instalar programas
pelo ports, no final tava tudo quebrado. Porque foi atualizando algumas
coisas que precisavam que outras fossem recompiladas. Isso acontece muito
com libs rsrsrsrs

Nesse seu exemplo se você não fez nenhuma mexida no xfce4-desktop acredito
que não te dê dor de cabeça fazer pelo pkg ou pelo ports. rsrs mas entre
portupgrade e portmaster eu gosto muito mais do portmaster :)

Tem que ter cuidado mesmo. :)

[]'s
Gondim


-
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] Qual procedimento correto para atualizar os softwares instalados?


On 28-07-2015 00:34, Kaio Rafael wrote:

Desculpem se a pergunta é recorrente:

Tenho uma dúvida que já destruiu meu sistema antes ;) e por isso, não
quero fazer novamente.

Estou usando freebsd versão 10 e tenho instalado pacotes via pkg
install  e através dos ports.

Já atualizei o sistema com freebsd-update, agora preciso atualizar os
softwares instalados.

Qual é o melhor método 'pkg upgrade' ou portmaster -a ? Por exemplo,
instalei o XFCE4 pelo 'pkg install'

Pelo comando 'pkg upgrade' tenho
Installed packages to be UPGRADED:
 xfce4-desktop: 4.12.2 -> 4.12.3

enquanto no portmaster
===>>> xfce4-desktop-4.12.2
 ===>>> New version available: xfce4-desktop-4.12.3

Aparentemente não tem problema, mas não sei qual devo usar. No
Handbook eles frisam que o upgrade deve ser através desses ports

`To perform the actual upgrade, use either Portmaster or Portupgrade.`

[]'z

Bom dia Kaio,

Sugiro você usar ou pkg e instalar os binários ou fazer tudo pelo ports. 
Lógico que se não forem coisas complexas como instalar um bash seria 
tranquilo. O problema começa quando você instala algo pelo ports e você 
faz mudanças nas options de compilação daquele pacote e monta seu 
ambiente todo em cima disso com novas libs e tudo. Aí está tudo 
funcionando e você manda um pkg upgrade e acaba com teu sistema porque 
os binários atualizados não terão as mesmas options que você havia 
setado no anterior.


Uma vez fiz isso com o PC-BSD, instalei ele e comecei à instalar 
programas pelo ports, no final tava tudo quebrado. Porque foi 
atualizando algumas coisas que precisavam que outras fossem 
recompiladas. Isso acontece muito com libs rsrsrsrs


Nesse seu exemplo se você não fez nenhuma mexida no xfce4-desktop 
acredito que não te dê dor de cabeça fazer pelo pkg ou pelo ports. rsrs 
mas entre portupgrade e portmaster eu gosto muito mais do portmaster :)


Tem que ter cuidado mesmo. :)

[]'s
Gondim


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

Re: [FUG-BR] Nossos brasileiros presentes no FreeBSD Project

2015-07-27 Por tôpico Marcelo Gondim


Em tempo olha o Marcelo Araújo aí no bhyve  :)


   Marcelo Araujo and Allan Jude created a rough patch to make bhyve parse
   a config file to replace the existing method of configuration by
   command line invocation. The rapid pace of advancement in bhyve
   resulted in requiring a much more complex config file. A new design for
   the config file, with support for the plugin architecture that will
   eventually be introduced into bhyve, is now being discussed.


On 27-07-2015 13:04, Marcelo Gondim wrote:
É muito bom ver que temos pessoas brilhantes ajudando a comunidade e 
melhor ainda ver que temos brasileiros presentes nesse desenvolvimento.
Valeu Luiz Otavio O Souza (LooS) por dedicar seu tempo à melhorar o 
que já é bom, meu amigo.  :)
Um parabéns para todos os outros brasileiros que ajudam, mesmo não 
aparecendo mas que importam para o projeto.


Trecho do 2º Trimestre de trabalhos no Projeto FreebSD:

   In addition to the enhancements to the virtual machine build tools, a
   significant amount of work went into refactoring the build code 
used to

   produce FreeBSD/arm images.

   With much of the logic resembling how the Crochet utility (written by
   Tim Kientzle) works, and a significant amount of work, input, and
   advice from Ian Lepore, Warner Losh, Andrew Turner, Luiz Otavio O 
Souza,

   and a large number of contributors on thefreebsd-...@freebsd.org
   mailing list, the FreeBSD Release Engineering tools now natively
   support producing FreeBSD/arm images without external build tools.

   At present, the build tools support building FreeBSD/arm images for:
 * BEAGLEBONE
 * CUBOX/HUMMINGBOARD
 * GUMSTIX
 * RPI-B
 * RPI2 (FreeBSD-CURRENT only)
 * PANDABOARD
 * WANDBOARD


[]'s
Gondim
-
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] Nossos brasileiros presentes no FreeBSD Project

2015-07-27 Por tôpico Marcelo Gondim

É muito bom ver que temos pessoas brilhantes ajudando a comunidade e 
melhor ainda ver que temos brasileiros presentes nesse desenvolvimento.
Valeu Luiz Otavio O Souza (LooS) por dedicar seu tempo à melhorar o que 
já é bom, meu amigo.  :)
Um parabéns para todos os outros brasileiros que ajudam, mesmo não 
aparecendo mas que importam para o projeto.


Trecho do 2º Trimestre de trabalhos no Projeto FreebSD:

   In addition to the enhancements to the virtual machine build tools, a
   significant amount of work went into refactoring the build code used to
   produce FreeBSD/arm images.

   With much of the logic resembling how the Crochet utility (written by
   Tim Kientzle) works, and a significant amount of work, input, and
   advice from Ian Lepore, Warner Losh, Andrew Turner, Luiz Otavio O Souza,
   and a large number of contributors on thefreebsd-...@freebsd.org
   mailing list, the FreeBSD Release Engineering tools now natively
   support producing FreeBSD/arm images without external build tools.

   At present, the build tools support building FreeBSD/arm images for:
 * BEAGLEBONE
 * CUBOX/HUMMINGBOARD
 * GUMSTIX
 * RPI-B
 * RPI2 (FreeBSD-CURRENT only)
 * PANDABOARD
 * WANDBOARD


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

Re: [FUG-BR] Monitoramento de rede.

2015-07-19 Por tôpico Marcelo Gondim


On 19-07-2015 09:11, Junior Pires wrote:

Bom dia!

Pessoal, tenho um Nagios implementado na minha rede, que funciona bem.
Porém, o chefe me falou do PRTG, que é uma ferramenta paga. Alguém conhece
uma ferramenta free, que tenha mais funções que o Nagios ?

Grato,

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


Buenas Junior,

Então, eu estive no FISL esse ano e pude ver de perto o Zabbix [1] e é 
uma ferramenta sensacional para monitoramento. O PRTG é muito bom mas 2 
coisas me incomodaram nele: roda somente no windows e é caro pra burro. :)


O próprio criador Alexei Vladishev palestrou no evento, pessoa 
extramente simpática por sinal, e deu uma palha sobre a nova versão e o 
que virá de bom.


[1] http://www.zabbix.com/


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

Re: [FUG-BR] Vulnerabilidade do MySQL 5.5

2015-07-18 Por tôpico Marcelo Gondim


On 18-07-2015 12:49, Paulo Olivier Cavalcanti wrote:

On 18/07/2015 10:25, Marcelo Gondim wrote:

Buenas pessoal,

Alguém reparou que tá demorando à sair a atualização do MySQL 5.5 no 
ports devido à essa última vulnerabilidade do SSL?

To quase trocando pro MariaDB 10.0  :(



Pois é, na segunda atualizamos o MySQL para 5.6.25 e na terça ele já 
foi marcado como vulnerável. Só usamos o MySQL internamente, para 
desenvolvimento de software, portanto não estamos muito preocupados. 
Sabe se a transição para MariaDB é tranquila?



Opa Paulo,

Fui ver e a versão do MariaDB no ports também está vulnerável. Quanto à 
migração, eu fiz um teste aqui em um servidor e foi de boa. Só é bom ver 
a equivalência e compatibilidade no site do MariaDB [1].


[1] https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibility/

[]'s
Gondim

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

[FUG-BR] Vulnerabilidade do MySQL 5.5

2015-07-18 Por tôpico Marcelo Gondim


Buenas pessoal,

Alguém reparou que tá demorando à sair a atualização do MySQL 5.5 no 
ports devido à essa última vulnerabilidade do SSL?

To quase trocando pro MariaDB 10.0  :(

[]'s
Gondim

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

Re: [FUG-BR] Placa de Rede 10Gbits

2015-07-03 Por tôpico Marcelo Gondim


On 03-07-2015 16:17, Fernando Perassoli wrote:

Boa tarde.

Gostaria de saber sobre a compatibilidade e desempenho das interfaces 
de rede INTEL X520-DA2 10GBE DUAL ( E10G42BTDA ) com o FreeBSD.


Desde já agradeço.

Att"

Fernando

Opa Fernando,

Essa não usei mas uso a X520-SR2 perfeitamente com o FreeBSD 10.1-STABLE 
revisão 281235. Inclusive segurando tráfego de quase 5Gbps atualmente.


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

Re: [FUG-BR] OpenBGP tcp md5sig

2015-07-03 Por tôpico Marcelo Gondim


On 03-07-2015 12:40, Patrick Tracanelli wrote:




On 03/07/2015, at 10:22, Marcelo Gondim  wrote:

On 02-07-2015 18:13, Felipe N. Oliva wrote:


On 7/2/15 18:08, Patrick Tracanelli wrote:

Felipe,

São coisas diferente, ou voce usa ipsec ou usa o OpenBGP. No fim a proposta é 
similar o que o OpenBGP vai fazer pra você é instalar um túnel ipsec de 
qualquer forma, mas fazer ambos não pode. Se voce estiver em modo passivo 
apenas ipsec com cisco vai te atender, se estiver ativo e voce quem inicia a 
sessão BGP pode precisar do OpenBGP iniciar a md5sig, mas seu OpenBGP esta sem 
suporte. Enviei aqui na lista um PR e patch pra corrigir isso no OpenBGP. Então 
ou vc aplica o patch ou desliga toda conf do OpenBGP e faz apenas em kernel com 
ipsec.




On 02/07/2015, at 16:20, Felipe N. Oliva  wrote:

Boa tarde pessoal,

Vejam se podem me ajudar, estou tentando fechar uma sessão BGP com "tcp md5sig".

Comecei tentando fechar com um CISCO, não foi, ai fiquei na duvida e fui pro 
Mikrotik, nada!

Ai fui pra tentativa mais fácil, openbgp x openbgp, e nada.

Detalhe, FreeBSD 10.1-RELEASE-p14.

Passos que segui:

Kernel:
options IPSEC# SUPORTE A IPSEC (REQUER crypto)
device  crypto# SUPORTE A CRIPTOGRAFIA
options TCP_SIGNATURE # SUPORTE A RFC 2385

ipsec.conf:
add -4 192.168.88.246 192.168.88.245 tcp 0x1000 -A tcp-md5 "secret";

bgpd.conf:
AS 65001
router-id 192.168.88.246
listen on 192.168.88.246

group TESTE {
remote-as 65002
neighbor 192.168.88.245 {
descr "BGP2"
tcp md5sig password secret
}
}

/var/log/messages:
Jul  2 17:08:53 bgp bgpd[874]: neighbor 192.168.88.245 (BGP2): pfkey setup 
failed

No outro peer a mesma coisa, mas ao contrario.

Alguém vê o erro?

Desde já grato,

--
Felipe N. Oliva
Administração de Redes e Sistemas
Skype: felipe.no88

-
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
316...@sip.freebsdbrasil.com.br
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

Valeu Patrick, eu consegui.

Lembro desse seu patch, mas não consegui pesquisar no histórico da lista, se 
for possível reenvia.

Att,


Po Patrick,

Não tem como mandar lá pro povo já colocar ele no FreeBSD 10.2?  :)
Esses dias tive que fechar o md5sig e só consegui usando o ipsec porque pelo 
OpenBGP não tava funcionando ainda.


Ja mandei PR… ta la parado hehehe.

Alguém do pfSense tinha mandado também uma versão antes. Vários reports de 
usuário de sucesso ja. O mantenedor do port que ta dormindo no ponto :D

Nem mandei o PR do allow as in pra não acumular, quando/se aprovar esse eu 
mando o proximo.

O proprio garga ja deu um follow-up la, n sei se precisa de um tapa a mais no 
port mas ta la:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184545#c2

Acho que ninguém se importa pq md5sig não vale nada. É segurança apenas 
psicológica e a maioria tem ciência disso e fecha sem senha mesmo. Alem de 
overhead causado pelas validações. ttl-security é mais simples e mais funcional 
pra evitar sequestro de sessão bgp hehe mas enfim tem gente que “exige” pra 
fechar peering que seja com assinatura, erroneamente chamada de chave ou 
senha...



--
Patrick Tracanelli

FreeBSD Brasil LTDA.
Tel.: (31) 3516-0800
316...@sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"

Pois é eu fechei sessão com os caras do Cymru [1] pra usar o UTRS e lá 
eles exigem isso. Aí tive que fazer rsrsrsrsrsr


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

Re: [FUG-BR] OpenBGP tcp md5sig

2015-07-03 Por tôpico Marcelo Gondim


On 02-07-2015 18:13, Felipe N. Oliva wrote:



On 7/2/15 18:08, Patrick Tracanelli wrote:

Felipe,

São coisas diferente, ou voce usa ipsec ou usa o OpenBGP. No fim a 
proposta é similar o que o OpenBGP vai fazer pra você é instalar um 
túnel ipsec de qualquer forma, mas fazer ambos não pode. Se voce 
estiver em modo passivo apenas ipsec com cisco vai te atender, se 
estiver ativo e voce quem inicia a sessão BGP pode precisar do 
OpenBGP iniciar a md5sig, mas seu OpenBGP esta sem suporte. Enviei 
aqui na lista um PR e patch pra corrigir isso no OpenBGP. Então ou vc 
aplica o patch ou desliga toda conf do OpenBGP e faz apenas em kernel 
com ipsec.




On 02/07/2015, at 16:20, Felipe N. Oliva  
wrote:


Boa tarde pessoal,

Vejam se podem me ajudar, estou tentando fechar uma sessão BGP com 
"tcp md5sig".


Comecei tentando fechar com um CISCO, não foi, ai fiquei na duvida e 
fui pro Mikrotik, nada!


Ai fui pra tentativa mais fácil, openbgp x openbgp, e nada.

Detalhe, FreeBSD 10.1-RELEASE-p14.

Passos que segui:

Kernel:
options IPSEC# SUPORTE A IPSEC (REQUER crypto)
device  crypto# SUPORTE A CRIPTOGRAFIA
options TCP_SIGNATURE # SUPORTE A RFC 2385

ipsec.conf:
add -4 192.168.88.246 192.168.88.245 tcp 0x1000 -A tcp-md5 "secret";

bgpd.conf:
AS 65001
router-id 192.168.88.246
listen on 192.168.88.246

group TESTE {
remote-as 65002
neighbor 192.168.88.245 {
descr "BGP2"
tcp md5sig password secret
}
}

/var/log/messages:
Jul  2 17:08:53 bgp bgpd[874]: neighbor 192.168.88.245 (BGP2): pfkey 
setup failed


No outro peer a mesma coisa, mas ao contrario.

Alguém vê o erro?

Desde já grato,

--
Felipe N. Oliva
Administração de Redes e Sistemas
Skype: felipe.no88

-
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
316...@sip.freebsdbrasil.com.br
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

Valeu Patrick, eu consegui.

Lembro desse seu patch, mas não consegui pesquisar no histórico da 
lista, se for possível reenvia.


Att,


Po Patrick,

Não tem como mandar lá pro povo já colocar ele no FreeBSD 10.2?  :)
Esses dias tive que fechar o md5sig e só consegui usando o ipsec porque 
pelo OpenBGP não tava funcionando ainda.


Abração,
Gondim


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

Re: [FUG-BR] Watchdog nas interfaces emX nas VMs [mitigado]

2015-07-02 Por tôpico Marcelo Gondim

On 01-07-2015 14:05, Edinilson - ATINET wrote:
- Original Message - From: "Marcelo Gondim" 

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

Sent: Wednesday, July 01, 2015 10:17 AM
Subject: Re: [FUG-BR] Watchdog nas interfaces emX nas VMs
On 20-04-2015 15:11, Edinilson - ATINET wrote:
- Original Message - From: "Marcelo Gondim" 

To: 
Sent: Monday, April 20, 2015 2:43 PM
Subject: Re: [FUG-BR] Watchdog nas interfaces emX nas VMs
On 20/04/2015 13:42, Edinilson - ATINET wrote:
- Original Message - From: "Marcelo Gondim" 

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

Sent: Monday, April 20, 2015 9:30 AM
Subject: [FUG-BR] Watchdog nas interfaces emX nas VMs
Pessoal,
Estou com um VMware 5.5.0 em um Dell R420 e nele instalei umas 4 
VMs FreeBSD 10.1-STABLE. Em todas as VMs, com algum tráfego, estou 
pegando as mensagens de watchdog abaixo.
Alguém tem alguma dica ou pode ser problema com o hardware mesmo? 
Todas as VMs estão com kern.hz=100.

Apr 17 02:36:24 mail kernel: em0: Watchdog timeout -- resetting
Apr 18 04:20:46 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 04:27:47 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 09:20:22 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 13:39:20 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 13:39:21 mail kernel: em0: Watchdog timeout -- resetting
Apr 20 06:01:54 mail kernel: em0: Watchdog timeout -- resetting
[]´s
Gondim

Caro Gondim, qual é o chipset da placa de rede? Pois as que 
utilizavam driver em tinham problema com o MSIX da bios, só 
acertaram a partir do chipset 82574.
Já nas igb (82575 e acima), todas são compativeis com MSIX e 
multi-queue.

Opa Edinilson,
É uma broadcom BCM5720 quem vem nesse Dell PowerEdge R420.
Muito estranho mesmo. Ele tá ligado em uma swicth Dell PowerConnect 
5548 e troquei o cabo de rede agora. Estou aguardando aqui pra ver 
se vai acontecer novamente.
Eu tenho uma Intel I350-T2 também nesse equipamento e com ela está 
acontecendo outra coisa estranha: do nada a interface para 
totalmente apagando a porta da switch e só volta à funcionar se eu 
reiniciar o VMWare. To começando à desconfiar do Dell em si.

[]´s
Gondim

Caro Gondim, poderia ativar o debug na interface, por exemplo:
sysctl dev.em.0.debug=1
e ver SE aparece alguma mensagem importante (eu, particularmente, 
nunca tive sorte com este debug na interface).

Voce pode ir acompanhando com:
sysctl -a | grep em.0

Eu tambem arriscaria atualizar a bios da maquina. É arriscado, mas 
TALVEZ possa ajudar.

Infelizmente, um problema bem chato de ser resolvido.

Edinilson
--
ATINET
Tel Voz: (0xx11) 4412-0876
http://www.atinet.com.br
Bom dia pessoal,
Depois de um longo período voltei à ver esse problema. rsrsrsr 
Edinilson troquei aqui de servidor Dell, agora é um R720 e mesmo 
assim continuam as mensagens.

Essa sysctl não tem mais aqui no 10-stable.
To procurando algo aqui no Google. Alguma outra dica aí pessoal?
O VMWare é esse aqui: VMware ESXi, 5.5.0, 1623387
Me parece que o problema é do VMWare com o FreeBSD.
[]'s
Gondim

Caro Gondim, este Bug report foi voce quem abriu?
https://www.mail-archive.com/freebsd-bugs@freebsd.org/msg22477.html

Pergunto pois é exatamente este problema que voce está reportando.

Fora isto, sinceramente não saberia te dizer mais o que poderia ser 
feito.
Infelizmente eu não tenho aqui um ambiente igual a este seu para te 
ajudar.

Opa,

Resolveu mudando o driver "em" para o do vmware no kernel (vmx) e no 
VMWare fiz o mesmo.

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

Re: [FUG-BR] Watchdog nas interfaces emX nas VMs

2015-07-01 Por tôpico Marcelo Gondim

On 01-07-2015 10:17, Marcelo Gondim wrote:

On 20-04-2015 15:11, Edinilson - ATINET wrote:
- Original Message - From: "Marcelo Gondim" 

To: 
Sent: Monday, April 20, 2015 2:43 PM
Subject: Re: [FUG-BR] Watchdog nas interfaces emX nas VMs
On 20/04/2015 13:42, Edinilson - ATINET wrote:
- Original Message - From: "Marcelo Gondim" 

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

Sent: Monday, April 20, 2015 9:30 AM
Subject: [FUG-BR] Watchdog nas interfaces emX nas VMs
Pessoal,
Estou com um VMware 5.5.0 em um Dell R420 e nele instalei umas 4 
VMs FreeBSD 10.1-STABLE. Em todas as VMs, com algum tráfego, estou 
pegando as mensagens de watchdog abaixo.
Alguém tem alguma dica ou pode ser problema com o hardware mesmo? 
Todas as VMs estão com kern.hz=100.

Apr 17 02:36:24 mail kernel: em0: Watchdog timeout -- resetting
Apr 18 04:20:46 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 04:27:47 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 09:20:22 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 13:39:20 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 13:39:21 mail kernel: em0: Watchdog timeout -- resetting
Apr 20 06:01:54 mail kernel: em0: Watchdog timeout -- resetting
[]´s
Gondim

Caro Gondim, qual é o chipset da placa de rede? Pois as que 
utilizavam driver em tinham problema com o MSIX da bios, só 
acertaram a partir do chipset 82574.
Já nas igb (82575 e acima), todas são compativeis com MSIX e 
multi-queue.

Opa Edinilson,
É uma broadcom BCM5720 quem vem nesse Dell PowerEdge R420.
Muito estranho mesmo. Ele tá ligado em uma swicth Dell PowerConnect 
5548 e troquei o cabo de rede agora. Estou aguardando aqui pra ver 
se vai acontecer novamente.
Eu tenho uma Intel I350-T2 também nesse equipamento e com ela está 
acontecendo outra coisa estranha: do nada a interface para 
totalmente apagando a porta da switch e só volta à funcionar se eu 
reiniciar o VMWare. To começando à desconfiar do Dell em si.

[]´s
Gondim

Caro Gondim, poderia ativar o debug na interface, por exemplo:
sysctl dev.em.0.debug=1
e ver SE aparece alguma mensagem importante (eu, particularmente, 
nunca tive sorte com este debug na interface).

Voce pode ir acompanhando com:
sysctl -a | grep em.0

Eu tambem arriscaria atualizar a bios da maquina. É arriscado, mas 
TALVEZ possa ajudar.

Infelizmente, um problema bem chato de ser resolvido.

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

Bom dia pessoal,

Depois de um longo período voltei à ver esse problema. rsrsrsr 
Edinilson troquei aqui de servidor Dell, agora é um R720 e mesmo assim 
continuam as mensagens.

Essa sysctl não tem mais aqui no 10-stable.

To procurando algo aqui no Google. Alguma outra dica aí pessoal?
O VMWare é esse aqui: VMware ESXi, 5.5.0, 1623387

Me parece que o problema é do VMWare com o FreeBSD.

[]'s
Gondim

Pessoal,

Fiz o seguinte: habilitei o device vmx no meu kernel, estou usando a 
interface vmx0 e no VMWare mudei para VMXNet 3.

Vamos ver se esses watchdog param. Se parar eu posto aqui avisando.

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

Re: [FUG-BR] Watchdog nas interfaces emX nas VMs

2015-07-01 Por tôpico Marcelo Gondim

On 20-04-2015 15:11, Edinilson - ATINET wrote:
- Original Message - From: "Marcelo Gondim" 

To: 
Sent: Monday, April 20, 2015 2:43 PM
Subject: Re: [FUG-BR] Watchdog nas interfaces emX nas VMs
On 20/04/2015 13:42, Edinilson - ATINET wrote:
- Original Message - From: "Marcelo Gondim" 

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

Sent: Monday, April 20, 2015 9:30 AM
Subject: [FUG-BR] Watchdog nas interfaces emX nas VMs
Pessoal,
Estou com um VMware 5.5.0 em um Dell R420 e nele instalei umas 4 VMs 
FreeBSD 10.1-STABLE. Em todas as VMs, com algum tráfego, estou 
pegando as mensagens de watchdog abaixo.
Alguém tem alguma dica ou pode ser problema com o hardware mesmo? 
Todas as VMs estão com kern.hz=100.

Apr 17 02:36:24 mail kernel: em0: Watchdog timeout -- resetting
Apr 18 04:20:46 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 04:27:47 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 09:20:22 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 13:39:20 mail kernel: em0: Watchdog timeout -- resetting
Apr 19 13:39:21 mail kernel: em0: Watchdog timeout -- resetting
Apr 20 06:01:54 mail kernel: em0: Watchdog timeout -- resetting
[]´s
Gondim

Caro Gondim, qual é o chipset da placa de rede? Pois as que 
utilizavam driver em tinham problema com o MSIX da bios, só acertaram 
a partir do chipset 82574.
Já nas igb (82575 e acima), todas são compativeis com MSIX e 
multi-queue.

Opa Edinilson,
É uma broadcom BCM5720 quem vem nesse Dell PowerEdge R420.
Muito estranho mesmo. Ele tá ligado em uma swicth Dell PowerConnect 
5548 e troquei o cabo de rede agora. Estou aguardando aqui pra ver se 
vai acontecer novamente.
Eu tenho uma Intel I350-T2 também nesse equipamento e com ela está 
acontecendo outra coisa estranha: do nada a interface para totalmente 
apagando a porta da switch e só volta à funcionar se eu reiniciar o 
VMWare. To começando à desconfiar do Dell em si.

[]´s
Gondim

Caro Gondim, poderia ativar o debug na interface, por exemplo:
sysctl dev.em.0.debug=1
e ver SE aparece alguma mensagem importante (eu, particularmente, 
nunca tive sorte com este debug na interface).

Voce pode ir acompanhando com:
sysctl -a | grep em.0

Eu tambem arriscaria atualizar a bios da maquina. É arriscado, mas 
TALVEZ possa ajudar.

Infelizmente, um problema bem chato de ser resolvido.

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

Bom dia pessoal,

Depois de um longo período voltei à ver esse problema. rsrsrsr Edinilson 
troquei aqui de servidor Dell, agora é um R720 e mesmo assim continuam 
as mensagens.

Essa sysctl não tem mais aqui no 10-stable.

To procurando algo aqui no Google. Alguma outra dica aí pessoal?
O VMWare é esse aqui: VMware ESXi, 5.5.0, 1623387

Me parece que o problema é do VMWare com o FreeBSD.

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

Re: [FUG-BR] postfix SASL - smtpd_sasl_auth_enable is true, but SASL support is not compiled

2015-06-30 Por tôpico Marcelo Gondim


On 30-06-2015 09:50, Renato Sousa wrote:

Bom dia amigos da lista!


Após um tempo distante do FreeBSD por razoes particulares, hoje pude
(tentar!!!) implementar um servidor de email postfix SASL em um FreeBSD
10.1 previamente instalado.
Existe algum problema na autenticação, pois percebo a mensagem " warning:
smtpd_sasl_auth_enable is true, but SASL support is not compiled in" no log
de email e o usuário não consegue enviar emails.

Observando os pacotes instalados tenho:
# pkg info | grep postfix
postfix-logwatch-1.40.03   Postfix MTA log parser
postfix-tls-2.11.3_3,1 Secure alternative to widely-used Sendmail

O curioso é que o search não encontra o pacote postfix-tls:
# pkg search postfix-tls

Aí fica a dúvida!!! O sistema de pacotes é exatamente igual ao ports ?
Quando optar por um ou outro?

Abraços,

Renato


Olá Renato,

Você pode pesquisar os pacotes binários e como eles foram compilados 
usando o comando abaixo. Dessa forma você pode saber antes de instalar.
O que você compilou, gerou e instalou  pelo ports também pode ser visto 
apenas trocando o search, pelo info.


pkg search -f 

Exemplo:

# pkg search -f apache22

apache22-2.2.29_5
Name   : apache22
Version: 2.2.29_5
Origin : www/apache22
Architecture   : freebsd:10:x86:64
Prefix : /usr/local
Repository : FreeBSD 
[pkg+http://pkg.FreeBSD.org/FreeBSD:10:amd64/latest]

Categories : www ipv6
Licenses   :
Maintainer : apa...@freebsd.org
WWW: http://httpd.apache.org/
Comment: Version 2.2.x of Apache web server with prefork MPM.
Options:
ACTIONS: on
ALIAS  : on
ASIS   : on
AUTHNZ_LDAP: off
AUTHN_ALIAS: on
AUTHN_ANON : on
AUTHN_DBD  : off
AUTHN_DBM  : on
AUTHN_DEFAULT  : on
AUTHN_FILE : on
AUTHZ_DBM  : on
AUTHZ_DEFAULT  : on
AUTHZ_GROUPFILE: on
AUTHZ_HOST : on
AUTHZ_OWNER: on
AUTHZ_USER : on
AUTH_BASIC : on
AUTH_DIGEST: on
AUTOINDEX  : on
BUCKETEER  : off
CACHE  : on
CASE_FILTER: off
CASE_FILTER_IN : off
CERN_META  : on
CGI: on
CGID   : off
CHARSET_LITE   : on
DAV: on
DAV_FS : on
DAV_LOCK   : off
DBD: off
DEFLATE: on
DIR: on
DISK_CACHE : on
DUMPIO : on
ENV: on
EXPIRES: on
EXT_FILTER : off
FILE_CACHE : on
FILTER : on
HEADERS: on
IMAGEMAP   : on
INCLUDE: on
INFO   : on
IPV4_MAPPED: off
LDAP   : off
LOGIO  : on
LOG_CONFIG : on
LOG_FORENSIC   : off
MEM_CACHE  : off
MIME   : on
MIME_MAGIC : on
NEGOTIATION: on
OPTIONAL_FN_EXPORT: off
OPTIONAL_FN_IMPORT: off
OPTIONAL_HOOK_EXPORT: off
OPTIONAL_HOOK_IMPORT: off
PROXY  : off
PROXY_AJP  : off
PROXY_BALANCER : off
PROXY_CONNECT  : off
PROXY_FTP  : off
PROXY_HTTP : off
PROXY_SCGI : off
REQTIMEOUT : on
REWRITE: on
SETENVIF   : on
SPELING: on
SSL: on
STATUS : on
SUBSTITUTE : off
SUEXEC : off
SUEXEC_RSRCLIMIT: off
SUEXEC_USERDIR : off
UNIQUE_ID  : on
USERDIR: on
USERTRACK  : on
VERSION: on
VHOST_ALIAS: on
Shared Libs required:
libpcre.so.1
libgdbm.so.4
libexpat.so.1
libdb-5.3.so.0
libaprutil-1.so.0
libapr-1.so.0
Annotations:
cpe: 
cpe:2.3:a:apache:http_server:2.2.29:freebsd10:x64:5

Flat size  : 15.6MiB
Pkg size   : 2.44MiB
Description:
The Apache HTTP Server Project is an effort to develop and maintain an
open-source HTTP server for various modern desktop and server operating
systems, such as UNIX and Windows NT. The goal of this project is to
provide a secure, efficient and extensible server which provides HTTP
services in sync with the current HTTP standards.
The 2.x branch of Apache Web Server includes several improvements like
threading, use of APR, native IPv6 and SSL support, and many more.

WWW: http://httpd.apache.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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa


On 09-06-2015 15:48, Herberson Miranda wrote:

Uma dúvida como você está monitorando a performance do servidor?
basicamente load do sistema e i/o de disco. O i/o é baixíssimo ainda 
mais porque está rodando embaixo de uma controladora Raid 10.

O hardware é esse abaixo:

1U 5017R-MTF Xeon E5 4bay
Intel 6core E5-2620V2 2.1Ghz 80W
4 x Kingston 16GB DDR3 1600Mhz ECC REG
Onboard IPMI/KVM with Dedicated LAN
Without DVD player
350W Gold Level Power Supply
4 x Seagate SAS ST3300657SS 300GB 15K
LSI MegaRAID SAS 9260-4i 6Gb/s
RAID-10

Network:
1Gigabit Uplink
10TB Traffic
2IPv4


On 09-06-2015 15:15, Marcelo Gondim wrote:

Opa Matheus,

On 08-06-2015 20:34, Matheus Weber da Conceição wrote:

Gondim, já tentou setar o limite máximo de memória na conf do
mysql/mariadb?

Limite máximo? Esse não vi não. A configuração atual consome uns 26Gb.
Usei esse link aqui [1] pra cálculo.

[1] http://www.mysqlcalculator.com/


-Matheus

2015-06-07 22:00 GMT-03:00 Marcelo Gondim :


On 07-06-2015 02:07, Nilton Jose Rizzo wrote:


Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu


On 05-06-2015 18:26, Nilton Jose Rizzo wrote:


  Gondim,

 E ai já portou tudo para o FreeBSD?

já viu  este link?

https://wiki.apache.org/httpd/PHP-FPM


Grande Rizzo,

Nada hehe mas o que pega e o que pegou no passado está relacionado
ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70%
e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a
mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta
performance que o mysql vai à 800%, estoura a memória e aí cai tudo.
Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo
novamente até 800% rsrsrsrs

A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá
aguentando a enxurrada ahahahaha
Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando
digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian.

Pelo que percebi não é o Apache o limitador mas o mysql.


 Já experimentou trocar o banco?
  por ou o posgre ou o maria-db?

  Talvés" possa ter uma gerencia melhor dos recuros ou ver um
tunning mais afiado para o mysql ... sei lá ...

   Agora que me veio uma ideia na cuca ... tem uma variável
no mysql que é o time out da conexão, que ele fecha quando
percebe que a conexão ficou aberta sem um fechamento explícito
coisas que programadores de php geralmente fazem ... ai fica as
conexões abertas e sócaem com o timeout X.  Dá uma olhada nisso
e me diz, ok?


Boa ideia Rizzo,

Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por
esse parâmetro.

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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

On 09-06-2015 11:23, Willien BSD wrote:

On 09/06/2015 10:59, Marcelo Gondim wrote:

On 07-06-2015 15:43, Nilton Jose Rizzo wrote:

Em Sun, 7 Jun 2015 02:07:12 -0300, Nilton Jose Rizzo escreveu

Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu

On 05-06-2015 18:26, Nilton Jose Rizzo wrote:

Gondim,

E ai já portou tudo para o FreeBSD?

Olha este link aqui

http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server

Opa Rizzo,

Esse mesmo que eu peguei :)
Então. Eu tive que migrar pro Datacenter novo usando o Debian mesmo.
Mas não desisti ainda. Vou pegar um Dell R720 aqui, colocar uns 32Gb
de ram nele e aí é muito simples de fazer os testes porque usamos a
CloudFlare. Só entro lá e mudo o IP de destino e é instantâneo pra
fazer o teste. :)

Assim que acertar isso aqui eu posto os resultados.

já viu este link?

https://wiki.apache.org/httpd/PHP-FPM

Grande Rizzo,

Nada hehe mas o que pega e o que pegou no passado está relacionado
ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70%
e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a
mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta
performance que o mysql vai à 800%, estoura a memória e aí cai tudo.
Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo
novamente até 800% rsrsrsrs

A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá
aguentando a enxurrada ahahahaha
Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando
digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian.

Pelo que percebi não é o Apache o limitador mas o mysql.

Já experimentou trocar o banco?
por ou o posgre ou o maria-db?

Talvés" possa ter uma gerencia melhor dos recuros ou ver um
tunning mais afiado para o mysql ... sei lá ...

Agora que me veio uma ideia na cuca ... tem uma variável
no mysql que é o time out da conexão, que ele fecha quando
percebe que a conexão ficou aberta sem um fechamento explícito
coisas que programadores de php geralmente fazem ... ai fica as
conexões abertas e sócaem com o timeout X. Dá uma olhada nisso
e me diz, ok?

Estou interessado nos resultados tb.
Vai nos informando dos seus testes.
Podia sortear uns convites do manicomio-share pra galera. hehehe

Abs,

ahahahah se eu conseguir fazer isso vou sortear mesmo :)

Assim que tiver mais resultados posto aqui.

[]'s

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

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa


Opa Matheus,

On 08-06-2015 20:34, Matheus Weber da Conceição wrote:

Gondim, já tentou setar o limite máximo de memória na conf do mysql/mariadb?

Limite máximo? Esse não vi não. A configuração atual consome uns 26Gb.
Usei esse link aqui [1] pra cálculo.

[1] http://www.mysqlcalculator.com/



-Matheus

2015-06-07 22:00 GMT-03:00 Marcelo Gondim :


On 07-06-2015 02:07, Nilton Jose Rizzo wrote:


Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu


On 05-06-2015 18:26, Nilton Jose Rizzo wrote:


 Gondim,

E ai já portou tudo para o FreeBSD?

já viu  este link?

https://wiki.apache.org/httpd/PHP-FPM


Grande Rizzo,

Nada hehe mas o que pega e o que pegou no passado está relacionado
ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70%
e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a
mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta
performance que o mysql vai à 800%, estoura a memória e aí cai tudo.
Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo
novamente até 800% rsrsrsrs

A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá
aguentando a enxurrada ahahahaha
Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando
digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian.

Pelo que percebi não é o Apache o limitador mas o mysql.


Já experimentou trocar o banco?
 por ou o posgre ou o maria-db?

 Talvés" possa ter uma gerencia melhor dos recuros ou ver um
tunning mais afiado para o mysql ... sei lá ...

  Agora que me veio uma ideia na cuca ... tem uma variável
no mysql que é o time out da conexão, que ele fecha quando
percebe que a conexão ficou aberta sem um fechamento explícito
coisas que programadores de php geralmente fazem ... ai fica as
conexões abertas e sócaem com o timeout X.  Dá uma olhada nisso
e me diz, ok?


Boa ideia Rizzo,

Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por
esse parâmetro.

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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

On 07-06-2015 15:43, Nilton Jose Rizzo wrote:

Em Sun, 7 Jun 2015 02:07:12 -0300, Nilton Jose Rizzo escreveu

Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu

On 05-06-2015 18:26, Nilton Jose Rizzo wrote:

Gondim,

E ai já portou tudo para o FreeBSD?

Olha este link aqui

http://www.rackspace.com/knowledge_center/article/how-to-change-the-mysql-timeout-on-a-server

Opa Rizzo,

Esse mesmo que eu peguei :)
Então. Eu tive que migrar pro Datacenter novo usando o Debian mesmo. Mas
não desisti ainda. Vou pegar um Dell R720 aqui, colocar uns 32Gb de ram
nele e aí é muito simples de fazer os testes porque usamos a CloudFlare.
Só entro lá e mudo o IP de destino e é instantâneo pra fazer o teste. :)

Assim que acertar isso aqui eu posto os resultados.

já viu este link?

https://wiki.apache.org/httpd/PHP-FPM

Grande Rizzo,

Pelo que percebi não é o Apache o limitador mas o mysql.

Já experimentou trocar o banco?
por ou o posgre ou o maria-db?

Talvés" possa ter uma gerencia melhor dos recuros ou ver um
tunning mais afiado para o mysql ... sei lá ...

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

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

2015-06-07 Por tôpico Marcelo Gondim


On 07-06-2015 02:07, Nilton Jose Rizzo wrote:

Em Sat, 06 Jun 2015 10:30:59 -0300, Marcelo Gondim escreveu

On 05-06-2015 18:26, Nilton Jose Rizzo wrote:

Gondim,

   E ai já portou tudo para o FreeBSD?

já viu  este link?

https://wiki.apache.org/httpd/PHP-FPM

Grande Rizzo,

Nada hehe mas o que pega e o que pegou no passado está relacionado
ao mysql. Lá no Debian as conexões levantam e ficam sempre entre 70%
e 120% de uso. Segura de boa e não estoura os 64Gb de ram. Agora a
mesma conf no FreeBSD parece que o Freeba libera o acesso com tanta
performance que o mysql vai à 800%, estoura a memória e aí cai tudo.
Aí preciso reiniciar o apache pra fechar as conexões e aí sobe tudo
novamente até 800% rsrsrsrs

A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá
aguentando a enxurrada ahahahaha
Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando
digo mysql, na verdade estou usando o MariaDB 10.0 igual no Debian.

Pelo que percebi não é o Apache o limitador mas o mysql.

   Já experimentou trocar o banco?
por ou o posgre ou o maria-db?

Talvés" possa ter uma gerencia melhor dos recuros ou ver um
tunning mais afiado para o mysql ... sei lá ...

 Agora que me veio uma ideia na cuca ... tem uma variável
no mysql que é o time out da conexão, que ele fecha quando
percebe que a conexão ficou aberta sem um fechamento explícito
coisas que programadores de php geralmente fazem ... ai fica as
conexões abertas e sócaem com o timeout X.  Dá uma olhada nisso
e me diz, ok?

Boa ideia Rizzo,

Vou olhar isso sim. Eu tentei com o MariaDB também mas vou procurar por 
esse parâmetro.


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] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

2015-06-06 Por tôpico Marcelo Gondim


On 05-06-2015 18:26, Nilton Jose Rizzo wrote:


   Gondim,

  E ai já portou tudo para o FreeBSD?

já viu  este link?

https://wiki.apache.org/httpd/PHP-FPM

Grande Rizzo,

Nada hehe mas o que pega e o que pegou no passado está relacionado ao 
mysql. Lá no Debian as conexões levantam e ficam sempre entre 70% e 120% 
de uso. Segura de boa e não estoura os 64Gb de ram. Agora a mesma conf 
no FreeBSD parece que o Freeba libera o acesso com tanta performance que 
o mysql vai à 800%, estoura a memória e aí cai tudo. Aí preciso 
reiniciar o apache pra fechar as conexões e aí sobe tudo novamente até 
800% rsrsrsrs


A impressão é que o FreeBSD tá abrindo a bica e o mysql não tá 
aguentando a enxurrada ahahahaha
Ou que o mysql chupa mais memória no FreeBSD, que no Linux. Quando digo 
mysql, na verdade estou usando o MariaDB 10.0 igual no Debian.


Pelo que percebi não é o Apache o limitador mas o mysql.


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

Re: [FUG-BR] Uso de opções do tar no FreeBSD

2015-05-30 Por tôpico Marcelo Gondim


Buenas Eduardo,

On 28-05-2015 11:01, Eduardo Lemos de Sa wrote:

Caríssimos(as)

É um tanto embaroçoso confessar, depois de muito tempo usando o comando tar
para comprimir e arquivar diretórios, que eu estou apanhando da sintaxe;

tar -zcvf fontes-10.1.tgz /usr/src /usr/obj

funciona muito bem quando eu arquivo os fontes e os binários gerados em um
atualização (a ideia é replicar isto para outras máquinas, sem ter de fazer
um svn, make buildworld e make buildkernel em cada uma delas). O problema é
que o arquivo gerado é grande (1.2 Gbyte) e engloba os arquivos fontes que
estão no /usr/src/.svn . Como eu não preciso deles nas outras máquinas, eu
gostaria de não incluí-los no fontes-10.1.tgz, então eu digitei:

tar -zxvf fontes-10.1.tgz /usr/src /usr/obj --exclude /usr/src/.svn
Pode tentar assim. O -C eu digo que quero extrair em algum lugar, nesse 
caso na raiz.  :)
Eu normalmente uso o exclude na criação mas faz na extração aí pra gente 
ver.


tar -xvzpf fontes-10.1.tgz --exclude=usr/src/.svn/ usr/src/ usr/obj/ -C /



e as suas variantes (mudando a posíção do --exclude /usr/src/.svn na linha
de comando). Em todos os casos, os arquivos que estão no /usr/src/.svn
aparecem na tela enquanto o tar está arquivando. Por favor, alguém poderia
dizer-me o que eu estou fazendo errado?

Obrigado pela atenção

Um abraço

Eduardo





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

Re: [FUG-BR] Particionamento FreeBSD 10.1

2015-05-19 Por tôpico Marcelo Gondim


On 19-05-2015 14:04, Patrick Tracanelli wrote:

On 18/05/2015, at 20:20, Samuel .  wrote:

Mais uma dúvida, o SSD que tenho aqui é um Kingston V300, será que aguenta o 
rojão?

Vixi… eu poderia dizer que é o famoso gato por lebre hehehe. Mas é pior. :( É 
um grande e vermelho piscante NAO USE PRA SERVIDOR!

Vamos aos fatos:

O modelo era bom, mas a Kingston mudou o chip da NAND no meio do jogo sem mudar 
o modelo do produto (DELL fazendo escola) e o que era bom ficou regular mas a 
um custo mais acessível. Ainda assim é melhor que um HDD de 7200rpm mas não 
será a experiência de um SSD. Se for numa porta SATA2 vai tirar todo proveito 
da porta mas se for SATA3 o SSD vai patinar antes da interface em termos de 
performance.

Enfim melhor que um HDD mas não é lá essas coisas de SSD. Além disso é MLC e 
não SLC (exatamente pra ser mais barato) então espere aquele cenário da vida 
útil em 80% do esperado pra um HDD, enquanto um SLC teria mais performance e 
mais vida útil.

Mas olhe pro lado bom, é um SSD. E olhe o lado bom 2, já tem tem um recurso da 
Kingston chamado SSDNow VPlus que faz um Wear Leveling muito bom 
automaticamente, eles chamam de Wear Range Delta e da pra monitorar até via 
S.M.A.R.T. os indicadores de wear leveling (rescrita do mesmo arquivo ocupando 
regiões diferentes da memória, de forma eficiente) o que garante que realmente 
a vida útil vai pra 80% ou mais dos ciclos de escrita esperados em um HDD.

Agora a luz vermelha e pq vc n deve usar em um servidor: esse SSD tem um outro 
recurso da Kingston chamado Data Life Protection (DLP) e esse DLP trava o disco 
pra operações de escrita paralela após um súbito aumento na taxa de escritas 
paralelas do disco. Segundo a Kingston essa proteção DLP é pra evitar virus e 
outros perfis de uso que não batem com o esperado pra uma estação de trabalho, 
e bla bla bla, bale ble ble que resulta em uma proteção anti paralelismo.

Basicamente o SSD espera poucas operações simultâneas de alto desempenho e não 
várias simultâneas. Ao entrar em modo DLP o paralelismo cai e junto cai a 
performance. Ou seja em ambiente servidor voce esta falando de multi-usuário 
portanto está falando de paralelismo portanto está falando de um cenário que 
provavelmente vai ativar a proteção DLP e degradar a performance.

Mais detalhes em:

http://ssdendurancetest.com/ssd-endurance-test-report/Kingston-SSDNow-V300-60

Resumindo: esse SSD não é pra server.

Opa Patrick,

E o Samsung 850 EVO? Esse presta pra server?

[]'s










Att,
Samuel .


From: lista.freebsd.bra...@outlook.com
To: freebsd@fug.com.br
Date: Mon, 18 May 2015 20:15:08 -0300
Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1

Eita, quanta informação preciosa!
Que dilema! rs
O buraco do tutu é bem mais em baixo que eu imaginava..
Agora que lembrei, esse servidor irá virtualizar um windows pra gravação de 
câmeras (agora ferrou!).
Confesso que estou com dó de usar esse SSD, por mim colocaria ele dentro de 
compartimento de vidro em cima da minha mesa (risos...)
Mas vou fazer isso que você disse Patrick!
Muitíssimo obrigado!







Att,
Samuel .


From: eks...@freebsdbrasil.com.br
Date: Mon, 18 May 2015 19:58:45 -0300
To: freebsd@fug.com.br
Subject: Re: [FUG-BR] Particionamento FreeBSD 10.1



On 18/05/2015, at 19:18, Samuel .  wrote:

Patrick, todos sabem, você é o cara! Muitíssimo obrigado pelo comentário.

Hahaha não sou não, só me coloquei na situação de usuário do seu servidor :D


Com base nessas informações, vou reformular totalmente o cenário aqui.
Não abusando da sua boa vontade. Mas eu tenho um SSD de 120 GB e um HDD de 250, 
queria poder usar os dois para ter espaço sobrando.
Qual layout de particionamento você recomenda?

Minha recomendação principal, o que eu faria, foi oq mencionei em uns e-mails 
pra trás, levantar quais estruturas existem mais operações e colocar esses 
pontos de montagem no SSD. Ou seja o layout de mount points deve ser apontado 
por esse levantamento…

Mas como eu mencionei também antes, se voce ja sabe que é samba o serviço 
principal você ja deve ter alguma ideia, mesmo sem olhar estatísticas, de quais 
shares são os mais críticos em termos de performance.

Então eu teria todas as partições no HDD, incluindo o /usr/home e teria um 
outro volume (se for zfs) ou ou mpoint se for UFS, digamos /usr/home2 e esse 
com o SSD. Todos os shares críticos em termos de performance estaria no SSD, 
digamos (um chute) /usr/home2/producao, /usr/home2/desenvolvimento, e os demais 
no HDD mesmo.

Ou seja difícil sugerir sem conhecer a estrutura funcionam da empresa, mas com 
certeza voce tem subsídios pra mapear e descobrir isso.

Se ja existir um server com essa função hoje, faça o levantamento estatístico 
no atual.

Por exemplo, olhando com fstat no servidor aqui da empresa eu vejo que a maior 
parte das operações de I/O acontecem no /usr/home e no /nfs. O “top -mio -o 
total” me confirma essa noção, mostrando que os processos que mais fazem I/O 
são httpd, nfsd e sshd (nego adora scp

Re: [FUG-BR] Problema estranho com sessão ssh e parece ser buffer

2015-05-14 Por tôpico Marcelo Gondim


On 14-05-2015 08:13, Nenhum_de_Nos wrote:

On Tue, 12 May 2015 15:22:15 -0300
Marcelo Gondim  wrote:


On 12-05-2015 13:10, Nenhum_de_Nos wrote:

On Tue, 12 May 2015 11:28:12 -0300
Marcelo Gondim  wrote:

Valeu Eduardo, vou ver aqui.
O estranho é porque isso só acontece com acessos de dentro daqui da rede
local e quando acesso de casa o problema não acontece.
Vou fazer um teste aqui :)

Gondim,

isso me lembra problema com o roteador (ou os roteadores) no caminho e não no 
servidor (cliente que abre a conexão ssh, servidor é quem a recebe).

Já vi roteadores destes simples, de operadora ou esses dlink's simples da vida, 
terem sua memória para conexões esgotada. Daí eles começam a sacrificar as 
conexões já existentes. Com roteador destes, não consigo deixar um ssh aberto 
sem que aconteça timed out.

Ele pode sacrificar a conexão por muito tempo sem atividade, ou por ter sessão 
demais.

Não é o mesmo comportamento da tela não atualizar, mas pode ajudar no caso das 
conexões reiniciadas pelo peer :)

matheus


Opa Matheus,

To desconfiado aqui da máquina proxy. Ela é bem antiga e só dá o
problema atrás dela.
Vou tentar trocar ela aqui pra ver se para isso.

Gondim,

não sei se entendi correto. O ssh passa pelo proxy ? Você usa algum tipo de 
túnel (http_tunnel, corkscrew) ?

att,

matheus

Opa não. Não passa pelo serviço proxy e sim pela máquina que tem um 
proxy rodando.  :)

[]'s


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

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

2015-05-13 Por tôpico Marcelo Gondim


On 13-05-2015 15:36, Rafael Henrique Faria wrote:

Verdade, bem lembrado pelo Nilton.

Durante a utilização do servidor, fique acompanhando o "iostat -x 1"

Veja a porcentagem de uso do disco  (ultima coluna). Se estiver
travado em 100%, o gargalo pode estar aí.
Opa boa vou checar isso também. O servidor de teste tem um SSD de 250Gb 
EVO da Samsung.

Vou olhar isso.



Eu não sei como pode estar funcionando esse seu sistema.
Mas como é um tracker privado, imagino que ele deve fazer os seguintes
procedimentos:
- ele recebe a requisição informando um hash do torrent, e também um
hash do passkey. Com isso o programa precisará realizar 2 consultas ao
banco de dados, uma para verificar o hash do torrent, e obter as
informações do mesmo, e a segunda consulta para verificar o acesso da
passkey.
- em seguida será atualizada a quantidade de bytes enviados e
recebidos por aquele passkey (daquele usuário em questão), para
contabilização. Será um update em alguma tabela do banco.
- e ele pode também estar fazendo uma verificação de quantas pessoas
estão realizando o seeding e o leeching deste torrent, assim
atualizando outra tabela.
Em média serão 2 acessos de leitura ao banco, e 2 acessos de gravação.
Isso para cada requisição.

O mariadb está no mesmo servidor? Quantas conexões ele está
configurado para receber? Lembre de manter sempre em sincronia a
quantidade de threads que o apache possui com a quantidade de conexões
que o seu banco pode receber.
O mariadb está no mesmo servidor. Eu usei uma vez aqueles programas pra 
optimizar o acesso à base.
Depois vou colar aqui o my.cnf que agora to sem acesso ao servidor de 
testes.




Essa é uma das vantagens de se utilizar o php-fpm, você consegue
manipular melhor essa relação de instâncias do servidor de aplicação X
conexões ao banco de dados.

Você chegou a monitorar a quantidade de queries que o mariadb está
recebendo no momento que o servidor não aguenta mais?

Qual o tempo de processamento de cada uma destas aplicações (mariadb e apache)?

Boa sorte aí.

Abraço.

2015-05-13 15:06 GMT-03:00 Nilton Jose Rizzo :

Em Tue, 12 May 2015 19:47:03 -0300, Marcelo Gondim escreveu

On 12-05-2015 18:17, Tiago Ribeiro wrote:

Em 12/05/2015, à(s) 17:36, Marcelo Gondim  escreveu:

On 12-05-2015 17:06, Fabricio Lima wrote:

consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra
nos?

enquanto o DNS está virando gradualmente na internet, o site chega a abrir?
e so depois q 'frita' q passa a nao abrir mais?

quanto tem de memoria?

Vou fazer um teste mais tarde. O teste é instantâneo porque uso a

cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer com os
DNS. :)

Altero o IP e aí é só contar até 10 rsrsrsrs
Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar aqui?

[]'s



Pega o netstat -LnAa | grep f800079cb800

sendo o f800079cb800 a saída do sonewconn, você
vai conseguir pegar se é o apache mesmo que está fazendo a fila.

Não conheço nada do Nginx, mas vale dar uma olhada sobres estes tunings do
FreeBSD pra rodar com ele, neste link[1] .

[1] http://nginx.org/en/docs/freebsd_tuning.html



Fiz um teste agora e o resultado aí abaixo:

# netstat -m
90991/8954/99945 mbufs in use (current/cache/total)
90990/1376/92366/1013816 mbuf clusters in use
(current/cache/total/max) 90990/1355 mbuf+clusters out of packet
secondary zone in use (current/cache) 0/300/300/506907 4k (page size)
  jumbo clusters in use
(current/cache/total/max) 0/0/0/150194 9k jumbo clusters in use
(current/cache/total/max) 0/0/0/84484 16k jumbo clusters in use
(current/cache/total/max) 204727K/6190K/210918K bytes allocated to
network (current/cache/total) 0/0/0 requests for mbufs denied
(mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed
(mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters
delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied
(4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs
delayed 140 requests for I/O initiated by sendfile

May 12 19:39:28 www kernel: sonewconn: pcb 0xf80229096930:
Listen queue overflow: 30001 already in queue awaiting acceptance
(20368 occurrences)

Pois é não aparece esse endereçamento sonewconn saca só abaixo:

# netstat -LnAa
Current listen queue sizes (qlen/incqlen/maxqlen)
TcpcbProto Listen Local Address
f804401e6800 tcp4  33/0/5 186.193.48.14.443
f802a0d05400 tcp4  20358/2/5  186.193.48.14.80
f8000de95800 tcp4  0/0/128*.4321
f8000de95c00 tcp6  0/0/128*.4321
f8000dd74000 tcp4  0/0/150127.0.0.1.3306
Some tcp sockets may have been created.
unix  0/0/150/tmp/mysql.sock
unix  0/0/1024   /var/run/memcached.sock
unix  0/0/4  /var/run/devd.pipe
unix  0/0/4  /var/run/devd.seqpacket.pipe

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



   God

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

2015-05-13 Por tôpico Marcelo Gondim


On 13-05-2015 11:12, Fabricio Lima wrote:

Vc informou anteriormente:

# sysctl kern.ipc.nmbclusters
kern.ipc.nmbclusters: 1013816

Cada cluster consome 2K de memoria.
como vc ja ta com 1milhao de mbufs. o q daria 2GB ram.

Como essa maquina é amd64, vamos aumentar isso. ___dobra este valor.__ poe
2048000
Esse servidor precisa ter no minimo 8gb.  serao 4gb so pra entregar as
conexoes pro apache!
e uns 4gb pra banco/apache.
Então essa máquina de teste tem 16Gb de ram mas o servidor em produção 
tem 48Gb e usa quase toda ela.
Quanto ao tráfego é muito pouco em torno de 5Mbps com cloudflare e 
30Mbps sem cloudflare. O lance mesmo são a quantidade de conexões 
simultâneas que temos por causa do tracker. Olha a estatística:



Informações de Usuários

Online no Momento2461
Online nas Últimas 24 Horas24174
Último Membro Registradomarlomattos
Registros Hoje30
Total de Registrados139,317
Pendentes0
Homens122,463
Mulheres14,799
Sexo Indefinido2,055
Advertidos1,027
Total Upado158.33 PB

Informações de Torrents

Total de Torrents174,151
Torrents Ativos88,273
Torrents reciclados 4,759
Torrents na Moderação3
Peers584,893
Seeders556,548
Leechers28,345
Conectáveis Sim251,581
Conectáveis Não333,253

Status de Registro Mensal

MêsUsuarios
2015-05526
2015-041348
2015-031312
2015-021230
2015-011355
2014-121311
2014-111272


altera tb os pontos abaixo, achei seus valores muito 'fraquinhos' e outros
tunaram pro proprio valor default:

kern.ipc.maxsockbuf=4194304 #este é o valor indicado pra gigabit, mesmo q
vc esteja em 100mbit, creio q vc ta topando esta placa, o q lhe deixaria
elegivel pra usar este valor.

net.inet.tcp.sendbuf_max=4194304  # (default 2097152)
net.inet.tcp.recvbuf_max=4194304  # (default 2097152)

kern.ipc.soacceptqueue=1024 # backlog queue depth for accepting new TCP
connections
net.inet.tcp.mssdflt=1460  # maximum segment size (largest payload)

net.inet.tcp.recvspace: 262144  # estava em 128k
net.inet.tcp.sendspace: 262144  # estava no default 32k

agora quero ver esse cabrunco nao aguentar...


Vou checar com essas confs valeu!!! :)


mesmo eskema, aplica estes valores, vira o IP, e na hora q der crash pega o
nestat -m e aquele outro q sugeriram q tem tanta letra q nao consigo
decorar heheeh -Lapnmasdfhasdflasd

[ ]'s
Fabricio Lima
Sendmail administration is not black magic. There are legitimate technical
reasons why it requires the sacrifice of a live chicken.

Em 13 de maio de 2015 05:44, Fabricio Lima 
escreveu:


Blz
Ta mole
Aumenta mbufs e bytes allocated to network

To no cel


Em terça-feira, 12 de maio de 2015, Marcelo Gondim 
escreveu:


On 12-05-2015 18:17, Tiago Ribeiro wrote:


Em 12/05/2015, à(s) 17:36, Marcelo Gondim 

escreveu:

On 12-05-2015 17:06, Fabricio Lima wrote:


consegue virar o site pra ele, dar um netstat -m deixar fritar e colar
pra
nos?

enquanto o DNS está virando gradualmente na internet, o site chega a
abrir?
e so depois q 'frita' q passa a nao abrir mais?

quanto tem de memoria?


Vou fazer um teste mais tarde. O teste é instantâneo porque uso a
cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer com
os DNS. :)
Altero o IP e aí é só contar até 10 rsrsrsrs
Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar
aqui?

[]'s


  Pega o netstat -LnAa | grep f800079cb800

sendo o f800079cb800 a saída do sonewconn, você
vai conseguir pegar se é o apache mesmo que está fazendo a fila.

Não conheço nada do Nginx, mas vale dar uma olhada sobres estes tunings
do
FreeBSD pra rodar com ele, neste link[1] .

[1] http://nginx.org/en/docs/freebsd_tuning.html


  Fiz um teste agora e o resultado aí abaixo:

# netstat -m
90991/8954/99945 mbufs in use (current/cache/total)
90990/1376/92366/1013816 mbuf clusters in use (current/cache/total/max)
90990/1355 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/300/300/506907 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/150194 9k jumbo clusters in use (current/cache/total/max)
0/0/0/84484 16k jumbo clusters in use (current/cache/total/max)
204727K/6190K/210918K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
140 requests for I/O initiated by sendfile

May 12 19:39:28 www kernel: sonewconn: pcb 0xf80229096930: Listen
queue overflow: 30001 already in queue awaiting acceptance (20368
occurrences)

Pois é não aparece esse endereçamento sonewconn saca só abaixo:

# netstat -LnAa
Current listen queue sizes (qlen/incqlen/maxqlen)
TcpcbProto Listen Local Address
f804401e6800 tcp4  33/0/5 186.193.48.14.443

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

2015-05-13 Por tôpico Marcelo Gondim


On 13-05-2015 15:06, Nilton Jose Rizzo wrote:

Em Tue, 12 May 2015 19:47:03 -0300, Marcelo Gondim escreveu

On 12-05-2015 18:17, Tiago Ribeiro wrote:

Em 12/05/2015, à(s) 17:36, Marcelo Gondim  escreveu:

On 12-05-2015 17:06, Fabricio Lima wrote:

consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra
nos?

enquanto o DNS está virando gradualmente na internet, o site chega a abrir?
e so depois q 'frita' q passa a nao abrir mais?

quanto tem de memoria?

Vou fazer um teste mais tarde. O teste é instantâneo porque uso a

cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer com os
DNS. :)

Altero o IP e aí é só contar até 10 rsrsrsrs
Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar aqui?

[]'s



Pega o netstat -LnAa | grep f800079cb800

sendo o f800079cb800 a saída do sonewconn, você
vai conseguir pegar se é o apache mesmo que está fazendo a fila.

Não conheço nada do Nginx, mas vale dar uma olhada sobres estes tunings do
FreeBSD pra rodar com ele, neste link[1] .

[1] http://nginx.org/en/docs/freebsd_tuning.html



Fiz um teste agora e o resultado aí abaixo:

# netstat -m
90991/8954/99945 mbufs in use (current/cache/total)
90990/1376/92366/1013816 mbuf clusters in use
(current/cache/total/max) 90990/1355 mbuf+clusters out of packet
secondary zone in use (current/cache) 0/300/300/506907 4k (page size)
  jumbo clusters in use
(current/cache/total/max) 0/0/0/150194 9k jumbo clusters in use
(current/cache/total/max) 0/0/0/84484 16k jumbo clusters in use
(current/cache/total/max) 204727K/6190K/210918K bytes allocated to
network (current/cache/total) 0/0/0 requests for mbufs denied
(mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed
(mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters
delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied
(4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs
delayed 140 requests for I/O initiated by sendfile

May 12 19:39:28 www kernel: sonewconn: pcb 0xf80229096930:
Listen queue overflow: 30001 already in queue awaiting acceptance
(20368 occurrences)

Pois é não aparece esse endereçamento sonewconn saca só abaixo:

# netstat -LnAa
Current listen queue sizes (qlen/incqlen/maxqlen)
TcpcbProto Listen Local Address
f804401e6800 tcp4  33/0/5 186.193.48.14.443
f802a0d05400 tcp4  20358/2/5  186.193.48.14.80
f8000de95800 tcp4  0/0/128*.4321
f8000de95c00 tcp6  0/0/128*.4321
f8000dd74000 tcp4  0/0/150127.0.0.1.3306
Some tcp sockets may have been created.
unix  0/0/150/tmp/mysql.sock
unix  0/0/1024   /var/run/memcached.sock
unix  0/0/4  /var/run/devd.pipe
unix  0/0/4  /var/run/devd.seqpacket.pipe

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



   Godim  essas requisições são para o apache, corretp?
mas e se não for o apache o problema e sim o mysql?  Já pensou
que cada requisição precisa realizar uma query no banco, será que seu
sistema de arquivos / disco não está suportando o mysql?

Opa Rizzo,

Então nos testes ontem, depois que enviei esse e-mail eu achei um 
parâmetro no apache que faltava configurar e depois disso tive a 
mensagem de falta de memória pro mysql. Acredito que agora seja isso e 
como não tenho como aumentar a memória aqui nesse meu server de teste, 
vou deixar para fazer os últimos testes no servidor que ficará em 
produção mesmo. Esse aqui:


1U 5017R-MTF Xeon E5 4bay
Intel 6core E5-2620V2 2.1Ghz 80W
4 x Kingston 16GB DDR3 1600Mhz ECC REG
Onboard IPMI/KVM with Dedicated LAN
Without DVD player
350W Gold Level Power Supply
4 x Seagate SAS ST3300657SS 300GB 15K
LSI MegaRAID SAS 9260-4i 6Gb/s

Network:
1Gigabit Uplink
10TB Traffic
2IPv4

Acredito que esse irá suportar muito bem rsrsrsrs aí lá vai ser a vera.

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

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa


On 12-05-2015 18:17, Tiago Ribeiro wrote:

Em 12/05/2015, à(s) 17:36, Marcelo Gondim  escreveu:

On 12-05-2015 17:06, Fabricio Lima wrote:

consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra
nos?

enquanto o DNS está virando gradualmente na internet, o site chega a abrir?
e so depois q 'frita' q passa a nao abrir mais?

quanto tem de memoria?

Vou fazer um teste mais tarde. O teste é instantâneo porque uso a cloudflare e 
aí só mudo o IP de destino. Dessa forma não preciso mexer com os DNS. :)
Altero o IP e aí é só contar até 10 rsrsrsrs
Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar aqui?

[]'s



Pega o netstat -LnAa | grep f800079cb800

sendo o f800079cb800 a saída do sonewconn, você
vai conseguir pegar se é o apache mesmo que está fazendo a fila.

Não conheço nada do Nginx, mas vale dar uma olhada sobres estes tunings do
FreeBSD pra rodar com ele, neste link[1] .

[1] http://nginx.org/en/docs/freebsd_tuning.html



Fiz um teste agora e o resultado aí abaixo:

# netstat -m
90991/8954/99945 mbufs in use (current/cache/total)
90990/1376/92366/1013816 mbuf clusters in use (current/cache/total/max)
90990/1355 mbuf+clusters out of packet secondary zone in use (current/cache)
0/300/300/506907 4k (page size) jumbo clusters in use 
(current/cache/total/max)

0/0/0/150194 9k jumbo clusters in use (current/cache/total/max)
0/0/0/84484 16k jumbo clusters in use (current/cache/total/max)
204727K/6190K/210918K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
140 requests for I/O initiated by sendfile

May 12 19:39:28 www kernel: sonewconn: pcb 0xf80229096930: Listen 
queue overflow: 30001 already in queue awaiting acceptance (20368 
occurrences)


Pois é não aparece esse endereçamento sonewconn saca só abaixo:

# netstat -LnAa
Current listen queue sizes (qlen/incqlen/maxqlen)
TcpcbProto Listen Local Address
f804401e6800 tcp4  33/0/5 186.193.48.14.443
f802a0d05400 tcp4  20358/2/5  186.193.48.14.80
f8000de95800 tcp4  0/0/128*.4321
f8000de95c00 tcp6  0/0/128*.4321
f8000dd74000 tcp4  0/0/150127.0.0.1.3306
Some tcp sockets may have been created.
unix  0/0/150/tmp/mysql.sock
unix  0/0/1024   /var/run/memcached.sock
unix  0/0/4  /var/run/devd.pipe
unix  0/0/4  /var/run/devd.seqpacket.pipe


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

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa


On 12-05-2015 17:06, Fabricio Lima wrote:

consegue virar o site pra ele, dar um netstat -m deixar fritar e colar pra
nos?

enquanto o DNS está virando gradualmente na internet, o site chega a abrir?
e so depois q 'frita' q passa a nao abrir mais?

quanto tem de memoria?


Vou fazer um teste mais tarde. O teste é instantâneo porque uso a 
cloudflare e aí só mudo o IP de destino. Dessa forma não preciso mexer 
com os DNS. :)

Altero o IP e aí é só contar até 10 rsrsrsrs
Vou fazer isso e mando aqui na lista. Mais alguma saída pra eu postar aqui?

[]'s




[ ]'s
Fabricio Lima
Sendmail administration is not black magic. There are legitimate technical
reasons why it requires the sacrifice of a live chicken.

Em 12 de maio de 2015 17:04, Marcelo Gondim 
escreveu:


On 12-05-2015 16:48, Fabricio Lima wrote:


PHP puro ou com APC,  eAccelerator ou FPM?

Recomendo ativar um deles... vai fazer cache de compilaçao do php..
grandes
ganhos.

nginx é imprescindivel.. incrivel estar funcionando no linux atual..
mas entendo sua desmotivaçao em migrar qndo ja ha tudo funcionando no
apache.. ja evitei de migrar uns tb.
legal é começar no nginx.. migrar é um porre. mas tente!! pior é ativar
mod_security... em algo q ja ta rodando.

proximo passo, manda um netstat -m  com seu ambiente tunado pra vermos
como
está, pra ver se da pra identificar ONDE está faltando tunar.


Opa Fabricio,

PHP com memcache. Pois é sempre fiquei indignado do site rodar bem e
rápido em um Debian com kernel generic e não conseguir rodá-lo em um
FreeBSD. :(




[ ]'s
Fabricio Lima
Sendmail administration is not black magic. There are legitimate technical
reasons why it requires the sacrifice of a live chicken.

Em 12 de maio de 2015 16:16, Marcelo Gondim 
escreveu:

  On 12-05-2015 15:40, Rafael Henrique Faria wrote:

  Boa tarde Gondim,

quais problemas você teve com o nginx? O sistema é em PHP, ou alguma
outra linguagem do tipo?

Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o
Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar
de 6k req/s sem dar muita carga no servidor.

O nginx é um pouco chato de se configurar, principalmente por ele ter
muito mais opções para melhorar a performance, mas no final o
resultado é excelente.

Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga
muito alta, com o nginx, usando php-fpm, você consegue uma grande
quantidade de req/s.

  Boa tarde Rafael,

Concordo contigo mas mudar para o nginx seria meu próximo passo. Primeiro
estou tentando colocar o ambiente atual funcionando no FreeBSD mesmo
porque
são menos variáveis para me preocupar. Mas pode ter certeza que
conseguindo
fazer essa migração, será meu próximo passo. O ambiente hoje é em php.

[]'s


   2015-05-12 15:31 GMT-03:00 Marcelo Gondim :


On 12-05-2015 14:34, Luiz Otavio O Souza wrote:

  2015-05-12 11:56 GMT-03:00 Marcelo Gondim:

  On 12-05-2015 11:24, Marcelo Gondim wrote:

  On 12-05-2015 11:07, Ricardo Campos Passanezi wrote:

  On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote:

  Bom dia à todos,

HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que
na
época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable.
Hoje
ele roda em cima de Debian e estou novamente com um ambiente aqui
para
tentar fazer essa bagaça rodar no FreeBSD. :)

O problema pelo visto são as milhares de requisições por segundo
que é
feito pelo tracker. Site começa à entrar e então despenca. O load
quando
inicio o apache vai à uns 400 e depois vai caindo e a única coisa
que
vejo bastante nos logs é isso:

   ...


   Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem


uma
ideia sobre isso acima? Estou catando aqui Google alguma
esperança.
Porque dia 20 mudaremos de Datacenter e se até lá não conseguir
fazer
isso funcionar, vou ter que apelar novamente para o Debian
rsrsrsrsr

Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O
Freeba
é
esse aqui:

FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE
#0
r281836: Wed Apr 29 12:21:07 BRT 2015
r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS  amd64

   Talvez usando o apache 2.4 te ajuda. Não pode testar com o
nginx?


   Tentei com o nginx mas de cara já deu pau. Como meu ambiente
atual


é com
apache, eu não perdi muito tempo e parti pra ele. Mas seria uma
mesmo.
Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje
funciona com apache 2.2 e não tenho problemas.
Mas pode ser outra tentativa embora acredite que seja algum tunning
do
sistema que esteja faltando pra essa quantidade toda de requisição.


   Achei essa thread [1] aqui na lista mas também não houve uma
solução


do
problema.

[1]
http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html

Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao
Jorge o
que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não
adiantou.
Soda rsrsrsrsr

[]'s
Gondim

  Gondim,

O sysc

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa

On 12-05-2015 16:48, Fabricio Lima wrote:

PHP puro ou com APC, eAccelerator ou FPM?

Recomendo ativar um deles... vai fazer cache de compilaçao do php.. grandes
ganhos.

nginx é imprescindivel.. incrivel estar funcionando no linux atual..
mas entendo sua desmotivaçao em migrar qndo ja ha tudo funcionando no
apache.. ja evitei de migrar uns tb.
legal é começar no nginx.. migrar é um porre. mas tente!! pior é ativar
mod_security... em algo q ja ta rodando.

proximo passo, manda um netstat -m com seu ambiente tunado pra vermos como
está, pra ver se da pra identificar ONDE está faltando tunar.

Opa Fabricio,

PHP com memcache. Pois é sempre fiquei indignado do site rodar bem e
rápido em um Debian com kernel generic e não conseguir rodá-lo em um
FreeBSD. :(

[ ]'s
Fabricio Lima
Sendmail administration is not black magic. There are legitimate technical
reasons why it requires the sacrifice of a live chicken.

Em 12 de maio de 2015 16:16, Marcelo Gondim
escreveu:

On 12-05-2015 15:40, Rafael Henrique Faria wrote:

Boa tarde Gondim,

quais problemas você teve com o nginx? O sistema é em PHP, ou alguma
outra linguagem do tipo?

Aqui usavamos um sistema bem pesado, em PHP, que quando rodando com o
Apache não conseguia mais de 2k req/s, com o nginx conseguimos passar
de 6k req/s sem dar muita carga no servidor.

O nginx é um pouco chato de se configurar, principalmente por ele ter
muito mais opções para melhorar a performance, mas no final o
resultado é excelente.

Se o sistema for em PHP, usar apache com modulo PHP é sempre uma carga
muito alta, com o nginx, usando php-fpm, você consegue uma grande
quantidade de req/s.

Boa tarde Rafael,

Concordo contigo mas mudar para o nginx seria meu próximo passo. Primeiro
estou tentando colocar o ambiente atual funcionando no FreeBSD mesmo porque
são menos variáveis para me preocupar. Mas pode ter certeza que conseguindo
fazer essa migração, será meu próximo passo. O ambiente hoje é em php.

[]'s

2015-05-12 15:31 GMT-03:00 Marcelo Gondim :

On 12-05-2015 14:34, Luiz Otavio O Souza wrote:

2015-05-12 11:56 GMT-03:00 Marcelo Gondim:

On 12-05-2015 11:24, Marcelo Gondim wrote:

On 12-05-2015 11:07, Ricardo Campos Passanezi wrote:

On Tue, May 12, 2015 at 08:54:27AM -0300, Marcelo Gondim wrote:

Bom dia à todos,

HAHAHa pois é estou aqui novamente tentando fazer essa proeza, que
na
época das 2 primeiras tentativas ainda era o FreeBSD 9.x o stable.
Hoje
ele roda em cima de Debian e estou novamente com um ambiente aqui
para
tentar fazer essa bagaça rodar no FreeBSD. :)

O problema pelo visto são as milhares de requisições por segundo
que é
feito pelo tracker. Site começa à entrar e então despenca. O load
quando
inicio o apache vai à uns 400 e depois vai caindo e a única coisa
que
vejo bastante nos logs é isso:

...

Tentei aumentar o kern.ipc.somaxconn mas não adiantou. Alguém tem

uma
ideia sobre isso acima? Estou catando aqui Google alguma esperança.
Porque dia 20 mudaremos de Datacenter e se até lá não conseguir
fazer
isso funcionar, vou ter que apelar novamente para o Debian rsrsrsrsr

Hoje está instalado o mariadb 10.0 + apache 2.2 + memcached. O
Freeba
é
esse aqui:

FreeBSD www.manicomio-share.com 10.1-STABLE FreeBSD 10.1-STABLE #0
r281836: Wed Apr 29 12:21:07 BRT 2015
r...@www.manicomio-share.com:/usr/obj/usr/src/sys/MS amd64

Talvez usando o apache 2.4 te ajuda. Não pode testar com o nginx?

Tentei com o nginx mas de cara já deu pau. Como meu ambiente atual

é com
apache, eu não perdi muito tempo e parti pra ele. Mas seria uma mesmo.
Será que o apache 2.4 vai dar tanta diferença assim? O ambiente hoje
funciona com apache 2.2 e não tenho problemas.
Mas pode ser outra tentativa embora acredite que seja algum tunning do
sistema que esteja faltando pra essa quantidade toda de requisição.

Achei essa thread [1] aqui na lista mas também não houve uma solução

do
problema.

[1] http://www.fug.com.br/historico/html/freebsd/2014-08/msg00103.html

Não sei se o LooS vai estar vendo essa mensagem mas ele respondeu ao
Jorge o
que seria o erro. LooS eu aumentei o kern.ipc.somaxconn e não adiantou.
Soda rsrsrsrsr

[]'s
Gondim

Gondim,

O sysctl kern.ipc.somaxconn foi renomeado para kern.ipc.soacceptqueue,
mas como foi mantido o antigo para efeitos de compatibilidade não faz
diferença pratica.

Esse knob seta apenas o limite máximo do kernel, a aplicação é quem
determina o limita para cada socket criado no momento em que ela chama
o listen(2) (veja o parâmetro backlog).

No apache você pode setar isso com o parametro ListenBacklog (detalhes
em http://httpd.apache.org/docs/2.2/mod/mpm_common.html).

O uso do accept filters pode ajudar, mas além de carregar os modulos
você precisa ativar eles no apache, veja essa thread (como um
exemplo):

https://forums.freebsd.org/threads/apache-failed-to-enable-the-httpready-accept-filter.27303/

HTH,
Luiz
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair

Re: [FUG-BR] Tentando migrar o manicomio-share pra FreeBSD - 3ª tentativa