Re: [FUG-BR] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
Em 14/09/2012 11:54, d4n1 escreveu: > Também acho a performace do clang melhor. Vamos que vamos -:) > Eu não me dei bem com o clang. Há cerca de um mês fui compilar o Chrome 20 e deu um segmentation fault (11) depois de mais de 22 horas de compilação. Usei o gcc46 e foi. Li que o Firefox tem problemas com clang... O único software que consegui compilar com ele foi o LibreOffice. Deve ser porque a minha máquina é modesta. -- http://about.me/paulocavalcanti - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF] Acabou! É o fim!
Em 14/09/2012 13:56, Patrick Tracanelli escreveu: > Eu perguntei sobre isso agora mesmo no GTER hehehe > > Parece que eu deveria ter procurado melhor ehehhe. > > Mas são tão poucos /20 em recuperação hein? A taxa de desperdício é muito > maior :( Pois é Patrick deve ter muita operadora aí com reservas absurdas de /20 e que poderiam estar liberados aí pra gente. Eu já to no meu limite. Só tenho um /24 e meio livre aqui pra mim dos meus: um /20 e dois /21. São quase 8000 clientes conectados simultaneamente em horário de pico. > > >> Já começaram o processo de recuperação de blocos. Tem vários lá para >> recuperar. :) >> >> http://registro.br/provedor/numeracao/recuperacao.html >> - >> 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 > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF] Acabou! É o fim!
* Patrick Tracanelli (eks...@freebsdbrasil.com.br) wrote: > Original Message > Subject: [ncc-services-wg] RIPE NCC Begins to Allocate IPv4 Address > Space From the Last /8 > Date: Fri, 14 Sep 2012 15:40:08 +0200 > From: Axel Pawlik > Reply-To: n...@ripe.net > To: ncc-services...@ripe.net > > Dear colleagues, > > On Friday, 14 September 2012, the RIPE NCC, the Regional Internet > Registry (RIR) for Europe, the Middle East and parts of Central Asia, > distributed the last blocks of IPv4 address space from the available pool. > > This means that we are now distributing IPv4 address space to Local > Internet Registries (LIRs) from the last /8 according to section 5.6 of > "IPv4 Address Allocation and Assignment Policies for the RIPE NCC > Service Region". > > This section states that an LIR may receive one /22 allocation (1,024 > IPv4 addresses), even if they can justify a larger allocation. This /22 > allocation will only be made to LIRs if they have already received an > IPv6 allocation from an upstream LIR or the RIPE NCC. No new IPv4 > Provider Independent (PI) space will be assigned. > > This policy can be found online at: > https://www.ripe.net/ripe/docs/ripe-553 > > Those members with open requests for IPv4 address space will shortly > receive an email regarding the status of their requests. > > It is now imperative that all stakeholders deploy IPv6 on their networks > to ensure the continuity of their online operations and the future > growth of the Internet. > > > Regards, > > Axel Pawlik > > Managing Director > RIPE NCC > > > More Information > - > > Ou seja acabou o v4 disponíveis no Pool. > > Agora os países que já tem suas classes alocadas nos seus devidos orgãos > competentes (NIC.BR no nosso caso) tem um estoque local limitado, e quando o > NIC.BR precisar e não tiver mais não haverá a quem pedir ;-) > > A não ser que coloquem uma estratégia para reciclar e pegar de volta os CIDR > não usados. > > -- > 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 Agora começa o comercio negro do ipv4 rsrsrsrs. cuba, haiti, etc... já estarão logo, logo revendendo seu blocos k só quero ver quando vamos receber ipv6 nos adsl's da vida, acho que ta mais que na hora ! --- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF] Acabou! É o fim!
Eu perguntei sobre isso agora mesmo no GTER hehehe Parece que eu deveria ter procurado melhor ehehhe. Mas são tão poucos /20 em recuperação hein? A taxa de desperdício é muito maior :( >Já começaram o processo de recuperação de blocos. Tem vários lá para > recuperar. :) > > http://registro.br/provedor/numeracao/recuperacao.html > - > 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
[FUG-BR] IPSec (netstat -nsp pfkey)
- Mensagem original - De: "Marcelo Gondim" Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" Enviadas: Sexta-feira, 14 de Setembro de 2012 9:50:45 Assunto: Re: [FUG-BR] IPSec (netstat -nsp pfkey) Em 14/09/2012 06:14, Breno Ribeiro escreveu: > Em 13/09/2012, às 23:45, Saul Figueiredo escreveu: > >> Em 13 de setembro de 2012 23:35, Breno Ribeiro >> escreveu: >> >>> Boa noite. >>> Estou implementando VPN IPsec no FreeBSD 9 com 30 filiais fechando na >>> matriz. Usando racoon e sem interface GIF. >>> Está funcionando a umas 3 semanas, porém o comando abaixo me dá uma saída >>> nada satisfatória, alguém que usa IPSec no FreeBSD poderia me informar se >>> isso também retorna no ambiente de vocês? Ou poderiam me ajudar a entender >>> a saída deste comando? >>> >>> netstat -nsp pfkey >>> >>> pfkey: >>>784 requests sent from userland >>>102640 bytes sent from userland >>>histogram by message type: >>>getspi: 92 >>>update: 90 >>>add: 90 >>>delete: 101 >>>register: 3 >>>dump: 145 >>>x_spdupdate: 180 >>>x_spddelete: 82 >>>x_spddump: 1 >>>0 messages with invalid length field >>>0 messages with invalid version field >>>0 messages with invalid message type field >>>0 messages too short >>>0 messages with memory allocation failure >>>0 messages with duplicate extension >>>0 messages with invalid extension type >>>0 messages with invalid sa type >>>0 messages with invalid address extension >>>5250 requests sent to userland >>>1342056 bytes sent to userland >>>histogram by message type: >>>getspi: 92 >>>update: 90 >>>add: 90 >>>delete: 137 >>>register: 3 >>>dump: 4575 >>>x_spdupdate: 180 >>>x_spddelete: 82 >>>x_spddump: 1 >>>4575 messages toward single socket >>>0 messages toward all sockets >>>36 messages toward registered sockets >>>732 messages with memory allocation failure >>> >>> >>> Breno >>> >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >> >> Boa noite Breno! :p >> >> 0 messages with invalid length field >>0 messages with invalid version field >>0 messages with invalid message type field >>0 messages too short >>0 messages with memory allocation failure >>0 messages with duplicate extension >>0 messages with invalid extension type >>0 messages with invalid sa type >>0 messages with invalid address extension >> >> Olhando desse ponto, não é tão ruim assim a saída. >> >> >> -- >> "Deve-se aprender sempre, até mesmo com um inimigo." >> (Isaac Newton) >> >> Atenciosamente, >> Saul Figueiredo >> Analista FreeBSD/Linux >> Linux Professional Institute Certification Level 2 >> Linux User: #554651 >> saulfelip...@gmail.com >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Saul bom dia e obrigado pelo retorno. > Analisei sobre este aspecto também, mas a saída é composta de 2 blocos e são > semelhantes no trato da informação, mas no segundo é que tem a linha que me > tira o sossego. > > 732 messages with memory allocation failure > > Inclusive esta mesma linha/info tem no primeiro bloco e esta zerada, penso > que pode ser que um bloco trata do server e a outra do client, mas se for > qual é qual? > > Ah agora que vi onde está a sua dúvida. É realmente é estranho. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd De fato e ta dificil buscar alguma documentacao que trate a saida do comando netstat para melhor interpretacao. :-) Breno - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF] Acabou! É o fim!
Em 14/09/2012 13:09, Patrick Tracanelli escreveu: > Original Message > Subject: [ncc-services-wg] RIPE NCC Begins to Allocate IPv4 Address > Space From the Last /8 > Date: Fri, 14 Sep 2012 15:40:08 +0200 > From: Axel Pawlik > Reply-To: n...@ripe.net > To: ncc-services...@ripe.net > > Dear colleagues, > > On Friday, 14 September 2012, the RIPE NCC, the Regional Internet > Registry (RIR) for Europe, the Middle East and parts of Central Asia, > distributed the last blocks of IPv4 address space from the available pool. > > This means that we are now distributing IPv4 address space to Local > Internet Registries (LIRs) from the last /8 according to section 5.6 of > "IPv4 Address Allocation and Assignment Policies for the RIPE NCC > Service Region". > > This section states that an LIR may receive one /22 allocation (1,024 > IPv4 addresses), even if they can justify a larger allocation. This /22 > allocation will only be made to LIRs if they have already received an > IPv6 allocation from an upstream LIR or the RIPE NCC. No new IPv4 > Provider Independent (PI) space will be assigned. > > This policy can be found online at: > https://www.ripe.net/ripe/docs/ripe-553 > > Those members with open requests for IPv4 address space will shortly > receive an email regarding the status of their requests. > > It is now imperative that all stakeholders deploy IPv6 on their networks > to ensure the continuity of their online operations and the future > growth of the Internet. > > > Regards, > > Axel Pawlik > > Managing Director > RIPE NCC > > > More Information > - > > Ou seja acabou o v4 disponíveis no Pool. > > Agora os países que já tem suas classes alocadas nos seus devidos orgãos > competentes (NIC.BR no nosso caso) tem um estoque local limitado, e quando o > NIC.BR precisar e não tiver mais não haverá a quem pedir ;-) > > A não ser que coloquem uma estratégia para reciclar e pegar de volta os CIDR > não usados. > > -- > 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 > Já começaram o processo de recuperação de blocos. Tem vários lá para recuperar. :) http://registro.br/provedor/numeracao/recuperacao.html - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF] Acabou! É o fim!
Em 14/09/2012 13:19, Paulo Henrique - BSDs Brasil escreveu: > Em 14/09/2012 13:09, Patrick Tracanelli escreveu: >> Original Message >> Subject: [ncc-services-wg] RIPE NCC Begins to Allocate IPv4 Address >> Space From the Last /8 >> Date: Fri, 14 Sep 2012 15:40:08 +0200 >> From: Axel Pawlik >> Reply-To: n...@ripe.net >> To: ncc-services...@ripe.net >> >> Dear colleagues, >> >> On Friday, 14 September 2012, the RIPE NCC, the Regional Internet >> Registry (RIR) for Europe, the Middle East and parts of Central Asia, >> distributed the last blocks of IPv4 address space from the available pool. >> >> This means that we are now distributing IPv4 address space to Local >> Internet Registries (LIRs) from the last /8 according to section 5.6 of >> "IPv4 Address Allocation and Assignment Policies for the RIPE NCC >> Service Region". >> >> This section states that an LIR may receive one /22 allocation (1,024 >> IPv4 addresses), even if they can justify a larger allocation. This /22 >> allocation will only be made to LIRs if they have already received an >> IPv6 allocation from an upstream LIR or the RIPE NCC. No new IPv4 >> Provider Independent (PI) space will be assigned. >> >> This policy can be found online at: >> https://www.ripe.net/ripe/docs/ripe-553 >> >> Those members with open requests for IPv4 address space will shortly >> receive an email regarding the status of their requests. >> >> It is now imperative that all stakeholders deploy IPv6 on their networks >> to ensure the continuity of their online operations and the future >> growth of the Internet. >> >> >> Regards, >> >> Axel Pawlik >> >> Managing Director >> RIPE NCC >> >> >> More Information >> - >> >> Ou seja acabou o v4 disponíveis no Pool. >> >> Agora os países que já tem suas classes alocadas nos seus devidos orgãos >> competentes (NIC.BR no nosso caso) tem um estoque local limitado, e quando o >> NIC.BR precisar e não tiver mais não haverá a quem pedir ;-) >> >> A não ser que coloquem uma estratégia para reciclar e pegar de volta os CIDR >> não usados. >> >> -- >> 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 > Esta rolando no Gter desde as 12:26... > > Realmente daqui a pouco ficará dificil de conseguir proxy anonimous, > estarão todos em IPV6, exigindo do pessoal do Brasil ter registro em > tuneis teredo para poder acessa-los !! ! > > > NUU - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] [OFF] Acabou! É o fim!
Em 14/09/12 13:09, Patrick Tracanelli escreveu: > > Ou seja acabou o v4 disponíveis no Pool. > > Agora os países que já tem suas classes alocadas nos seus devidos orgãos > competentes (NIC.BR no nosso caso) tem um estoque local limitado, e quando o > NIC.BR precisar e não tiver mais não haverá a quem pedir ;-) > > A não ser que coloquem uma estratégia para reciclar e pegar de volta os CIDR > não usados. > > Mas o fim do mundo não era em 21/12/2012? hehehehehe :-) Jeito agora é o pessoal acordar e começar a implementar suas redes IPv6, deixar de ficar empurrando com a barriga []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] [OFF] Acabou! É o fim!
Em 14/09/2012 13:09, Patrick Tracanelli escreveu: > Original Message > Subject: [ncc-services-wg] RIPE NCC Begins to Allocate IPv4 Address > Space From the Last /8 > Date: Fri, 14 Sep 2012 15:40:08 +0200 > From: Axel Pawlik > Reply-To: n...@ripe.net > To: ncc-services...@ripe.net > > Dear colleagues, > > On Friday, 14 September 2012, the RIPE NCC, the Regional Internet > Registry (RIR) for Europe, the Middle East and parts of Central Asia, > distributed the last blocks of IPv4 address space from the available pool. > > This means that we are now distributing IPv4 address space to Local > Internet Registries (LIRs) from the last /8 according to section 5.6 of > "IPv4 Address Allocation and Assignment Policies for the RIPE NCC > Service Region". > > This section states that an LIR may receive one /22 allocation (1,024 > IPv4 addresses), even if they can justify a larger allocation. This /22 > allocation will only be made to LIRs if they have already received an > IPv6 allocation from an upstream LIR or the RIPE NCC. No new IPv4 > Provider Independent (PI) space will be assigned. > > This policy can be found online at: > https://www.ripe.net/ripe/docs/ripe-553 > > Those members with open requests for IPv4 address space will shortly > receive an email regarding the status of their requests. > > It is now imperative that all stakeholders deploy IPv6 on their networks > to ensure the continuity of their online operations and the future > growth of the Internet. > > > Regards, > > Axel Pawlik > > Managing Director > RIPE NCC > > > More Information > - > > Ou seja acabou o v4 disponíveis no Pool. > > Agora os países que já tem suas classes alocadas nos seus devidos orgãos > competentes (NIC.BR no nosso caso) tem um estoque local limitado, e quando o > NIC.BR precisar e não tiver mais não haverá a quem pedir ;-) > > A não ser que coloquem uma estratégia para reciclar e pegar de volta os CIDR > não usados. > > -- > 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 Esta rolando no Gter desde as 12:26... Realmente daqui a pouco ficará dificil de conseguir proxy anonimous, estarão todos em IPV6, exigindo do pessoal do Brasil ter registro em tuneis teredo para poder acessa-los !! ! -- Paulo Henrique. BSDs Brasil - FUG-BR site: www.fug.com.br Rip Irado !!! flamers > /dev/null - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] [OFF] Acabou! É o fim!
Original Message Subject: [ncc-services-wg] RIPE NCC Begins to Allocate IPv4 Address Space From the Last /8 Date: Fri, 14 Sep 2012 15:40:08 +0200 From: Axel Pawlik Reply-To: n...@ripe.net To: ncc-services...@ripe.net Dear colleagues, On Friday, 14 September 2012, the RIPE NCC, the Regional Internet Registry (RIR) for Europe, the Middle East and parts of Central Asia, distributed the last blocks of IPv4 address space from the available pool. This means that we are now distributing IPv4 address space to Local Internet Registries (LIRs) from the last /8 according to section 5.6 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". This section states that an LIR may receive one /22 allocation (1,024 IPv4 addresses), even if they can justify a larger allocation. This /22 allocation will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. No new IPv4 Provider Independent (PI) space will be assigned. This policy can be found online at: https://www.ripe.net/ripe/docs/ripe-553 Those members with open requests for IPv4 address space will shortly receive an email regarding the status of their requests. It is now imperative that all stakeholders deploy IPv6 on their networks to ensure the continuity of their online operations and the future growth of the Internet. Regards, Axel Pawlik Managing Director RIPE NCC More Information - Ou seja acabou o v4 disponíveis no Pool. Agora os países que já tem suas classes alocadas nos seus devidos orgãos competentes (NIC.BR no nosso caso) tem um estoque local limitado, e quando o NIC.BR precisar e não tiver mais não haverá a quem pedir ;-) A não ser que coloquem uma estratégia para reciclar e pegar de volta os CIDR não usados. -- 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
Re: [FUG-BR] BGP [OT] entrando mais um AS na brincadeira
Em 14/09/2012 12:13, Otavio Augusto escreveu: > Em 14 de setembro de 2012 12:08, Marcelo Gondim > escreveu: >> Olá pessoal, >> >> Aproveitando a movimentação da lista hoje rsrsrsr sou conhecedor básico, >> bem básico de bgp e estou com uma dúvida. Hoje funciona tudo perfeito >> aqui no provedor e para o provedor. Vou primeiro passar o cenário atual: >> >> Chega link de 2Gbps da Operadora de Upstream no nosso (Router FreeBSD - >> OpenBGP). Fazemos o BGP com a operadora e estaticamente jogo as rotas >> dos blocos IPs para um Firewall em cada cidade que atendemos. Minha >> dúvida é a seguinte: o provedor aqui resolveu vender 500Mbps desse link >> (somente link, sem IP) para outro provedor parceiro nosso, sendo que >> esse outro provedor já tem seu AS. Vamos supor que eu coloque uma outra >> interface de rede no router e interligue com esse outro provedor. Eu >> poderia anunciar blocos desse outro provedor pela minha sessão BGP com a >> operadora ou haveriam problemas? >> > Sim pode Mas a sua operadora provavelmente deve conter Filtros para > que vc nao anuncie nada errado. > Vc deve comunicar a operadora quais blocos do seu seu cliente será > anunciando para que eles configurem os filtros corretamente. > > Tipo ele tem dois /20 vc comunica na operadora que vai anunciar os 2 > /20 mesmo que ele anuncie menos prefixos mas eles deve estar dentro > destes > blocos. Ah sim a operadora hoje faz isso com os meus blocos. Eu precisei informar à eles mesmo porque eles fazem filtro lá. Pelo jeito vou virar trânsito e ver isso com a operadora. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
Em 14/09/2012, às 10:30, Marcelo Gondim escreveu: > Em 14/09/2012 10:03, Gustavo Freitas escreveu: >> amigo, >> >> qual seria a maior vantagem ? segurança ? > > Não é a vantagem o problema é a maldita licença GPLv3 do GCC que foi um > tiro no pé pra muita gente. Não *era* vantagem, agora parece que já é! :-) Vi uma discussão muito boa de usuários LLVM Apple e FreeBSD indicando melhor performance do produto final (objeto compilado) na maioria dos casos, de 68 testes que fizeram o binário clang se mostrou mais eficiente em 42, pior que gcc (mesmo o mais recente, já GPLv3) em 18 testes e deram como empate ou resultado indefinido (variando muito) em outros 8 testes. > Stallman confunde o verdadeiro significado de liberdade querendo obrigar > à todos que façam do jeito dele. Que morra o gcc então! Vida longa ao > LLVM/CLang. Boa. A liberdade por imposição da definição estrita de liberdade; a liberdade como definida por um grupo específico de pessoas. Já vimos e ainda vemos hoje (no oriente) nações inteiras em guerra, devido a esse tipo de "imposição de uma liberdade". A verdade é que a liberdade imposta pela GPL é cerceada; na GPLv3 isso só piora um pouco; Que bom que a adoção de GPL está em rápido declínio ;-) e de licenças BSD, derivadas, ou similares, crescendo na mesma proporção. http://www.itworld.com/it-managementstrategy/233753/gpl-copyleft-use-declining-faster-ever -- 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
Re: [FUG-BR] BGP [OT] entrando mais um AS na brincadeira
Em 14/09/2012 12:11, Eduardo Schoedler escreveu: > Em 14 de setembro de 2012 12:08, Marcelo Gondim > escreveu: > >> Chega link de 2Gbps da Operadora de Upstream no nosso (Router FreeBSD - >> OpenBGP). Fazemos o BGP com a operadora e estaticamente jogo as rotas >> dos blocos IPs para um Firewall em cada cidade que atendemos. Minha >> dúvida é a seguinte: o provedor aqui resolveu vender 500Mbps desse link >> (somente link, sem IP) para outro provedor parceiro nosso, sendo que >> esse outro provedor já tem seu AS. Vamos supor que eu coloque uma outra >> interface de rede no router e interligue com esse outro provedor. Eu >> poderia anunciar blocos desse outro provedor pela minha sessão BGP com a >> operadora ou haveriam problemas? >> > Agora a brincadeira fica séria, pois agora você é trânsito. > > 1) você terá de fechar uma sessão com o AS dele. Faça filtros bem apertados > do que ele irá anunciar! match por AS e bloco; > 2) você terá de solicitar à sua operadora liberação para os blocos do seu > cliente -- isso demora. > > Mais dúvidas sugiro perguntar na lista GTER. > > Abs. > Opa Eduardo, valeu. Era isso que estava em dúvida mesmo. Eu me tornaria trânsito. :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] BGP [OT] entrando mais um AS na brincadeira
Em 14 de setembro de 2012 12:08, Marcelo Gondim escreveu: > Olá pessoal, > > Aproveitando a movimentação da lista hoje rsrsrsr sou conhecedor básico, > bem básico de bgp e estou com uma dúvida. Hoje funciona tudo perfeito > aqui no provedor e para o provedor. Vou primeiro passar o cenário atual: > > Chega link de 2Gbps da Operadora de Upstream no nosso (Router FreeBSD - > OpenBGP). Fazemos o BGP com a operadora e estaticamente jogo as rotas > dos blocos IPs para um Firewall em cada cidade que atendemos. Minha > dúvida é a seguinte: o provedor aqui resolveu vender 500Mbps desse link > (somente link, sem IP) para outro provedor parceiro nosso, sendo que > esse outro provedor já tem seu AS. Vamos supor que eu coloque uma outra > interface de rede no router e interligue com esse outro provedor. Eu > poderia anunciar blocos desse outro provedor pela minha sessão BGP com a > operadora ou haveriam problemas? > Sim pode Mas a sua operadora provavelmente deve conter Filtros para que vc nao anuncie nada errado. Vc deve comunicar a operadora quais blocos do seu seu cliente será anunciando para que eles configurem os filtros corretamente. Tipo ele tem dois /20 vc comunica na operadora que vai anunciar os 2 /20 mesmo que ele anuncie menos prefixos mas eles deve estar dentro destes blocos. > Grande abraço à todos. > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] BGP [OT] entrando mais um AS na brincadeira
Em 14 de setembro de 2012 12:08, Marcelo Gondim escreveu: > Chega link de 2Gbps da Operadora de Upstream no nosso (Router FreeBSD - > OpenBGP). Fazemos o BGP com a operadora e estaticamente jogo as rotas > dos blocos IPs para um Firewall em cada cidade que atendemos. Minha > dúvida é a seguinte: o provedor aqui resolveu vender 500Mbps desse link > (somente link, sem IP) para outro provedor parceiro nosso, sendo que > esse outro provedor já tem seu AS. Vamos supor que eu coloque uma outra > interface de rede no router e interligue com esse outro provedor. Eu > poderia anunciar blocos desse outro provedor pela minha sessão BGP com a > operadora ou haveriam problemas? > Agora a brincadeira fica séria, pois agora você é trânsito. 1) você terá de fechar uma sessão com o AS dele. Faça filtros bem apertados do que ele irá anunciar! match por AS e bloco; 2) você terá de solicitar à sua operadora liberação para os blocos do seu cliente -- isso demora. Mais dúvidas sugiro perguntar na lista GTER. Abs. -- Eduardo Schoedler ESDS Consultoria de TI - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] BGP [OT] entrando mais um AS na brincadeira
Olá pessoal, Aproveitando a movimentação da lista hoje rsrsrsr sou conhecedor básico, bem básico de bgp e estou com uma dúvida. Hoje funciona tudo perfeito aqui no provedor e para o provedor. Vou primeiro passar o cenário atual: Chega link de 2Gbps da Operadora de Upstream no nosso (Router FreeBSD - OpenBGP). Fazemos o BGP com a operadora e estaticamente jogo as rotas dos blocos IPs para um Firewall em cada cidade que atendemos. Minha dúvida é a seguinte: o provedor aqui resolveu vender 500Mbps desse link (somente link, sem IP) para outro provedor parceiro nosso, sendo que esse outro provedor já tem seu AS. Vamos supor que eu coloque uma outra interface de rede no router e interligue com esse outro provedor. Eu poderia anunciar blocos desse outro provedor pela minha sessão BGP com a operadora ou haveriam problemas? Grande abraço à todos. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
Também acho a performace do clang melhor. Vamos que vamos -:) On Sep 14, 2012 10:31 AM, "Marcelo Gondim" wrote: > Em 14/09/2012 10:03, Gustavo Freitas escreveu: > > amigo, > > > > qual seria a maior vantagem ? segurança ? > > Não é a vantagem o problema é a maldita licença GPLv3 do GCC que foi um > tiro no pé pra muita gente. > > Stallman confunde o verdadeiro significado de liberdade querendo obrigar > à todos que façam do jeito dele. Que morra o gcc então! Vida longa ao > LLVM/CLang. > > > > > 2012/9/14 Jack : > >> Buenas Lista! > >> > >> Apenas compartilhando o texto: > >> > http://www.osnews.com/story/26372/FreeBSD_moves_away_from_GCC_embraces_Clang > >> > >> > >> Abraços! > >> Jack > >> > >> > >> > >> > >> > >> - > >> Histórico: http://www.fug.com.br/historico/html/freebsd/ > >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > > > > > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPSec (netstat -nsp pfkey)
- Mensagem original - De: "Renato Frederick" Para: freebsd@fug.com.br Enviadas: Sexta-feira, 14 de Setembro de 2012 10:26:52 Assunto: Re: [FUG-BR] IPSec (netstat -nsp pfkey) Em 14/09/12 06:14, Breno Ribeiro escreveu: > > Saul bom dia e obrigado pelo retorno. > Analisei sobre este aspecto também, mas a saída é composta de 2 blocos e são > semelhantes no trato da informação, mas no segundo é que tem a linha que me > tira o sossego. > > 732 messages with memory allocation failure > > Inclusive esta mesma linha/info tem no primeiro bloco e esta zerada, penso > que pode ser que um bloco trata do server e a outra do client, mas se for > qual é qual? > > Breno > Breno, sua VPN IPSEC está apresentando algum problema? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Renato, blz. Está funcionando. Nas filiais tenho roteadores draytek com ADSL e 3G, cai o ADSL o 3G sobe e quando ADSL volta o 3G pára, se minha percepção estiver certa, isso ajuda a incrementar o erro, a troca de ip's quando há queda, mas acredito não ser o único responsável pelo erro. No final do man ipsec (inclusive tem muita info de parametrizacao) tem a seguinte info: When a large database of security associations or policies is present in the kernel the SADB_DUMP and SADB_SPDDUMP operations on PF_KEY sockets may fail due to lack of space. Increasing the socket buffer size may alleviate this problem. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPSec (netstat -nsp pfkey)
- Mensagem original - De: "Marcelo Gondim" Para: "Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)" Enviadas: Sexta-feira, 14 de Setembro de 2012 9:50:45 Assunto: Re: [FUG-BR] IPSec (netstat -nsp pfkey) Em 14/09/2012 06:14, Breno Ribeiro escreveu: > Em 13/09/2012, às 23:45, Saul Figueiredo escreveu: > >> Em 13 de setembro de 2012 23:35, Breno Ribeiro >> escreveu: >> >>> Boa noite. >>> Estou implementando VPN IPsec no FreeBSD 9 com 30 filiais fechando na >>> matriz. Usando racoon e sem interface GIF. >>> Está funcionando a umas 3 semanas, porém o comando abaixo me dá uma saída >>> nada satisfatória, alguém que usa IPSec no FreeBSD poderia me informar se >>> isso também retorna no ambiente de vocês? Ou poderiam me ajudar a entender >>> a saída deste comando? >>> >>> netstat -nsp pfkey >>> >>> pfkey: >>>784 requests sent from userland >>>102640 bytes sent from userland >>>histogram by message type: >>>getspi: 92 >>>update: 90 >>>add: 90 >>>delete: 101 >>>register: 3 >>>dump: 145 >>>x_spdupdate: 180 >>>x_spddelete: 82 >>>x_spddump: 1 >>>0 messages with invalid length field >>>0 messages with invalid version field >>>0 messages with invalid message type field >>>0 messages too short >>>0 messages with memory allocation failure >>>0 messages with duplicate extension >>>0 messages with invalid extension type >>>0 messages with invalid sa type >>>0 messages with invalid address extension >>>5250 requests sent to userland >>>1342056 bytes sent to userland >>>histogram by message type: >>>getspi: 92 >>>update: 90 >>>add: 90 >>>delete: 137 >>>register: 3 >>>dump: 4575 >>>x_spdupdate: 180 >>>x_spddelete: 82 >>>x_spddump: 1 >>>4575 messages toward single socket >>>0 messages toward all sockets >>>36 messages toward registered sockets >>>732 messages with memory allocation failure >>> >>> >>> Breno >>> >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >> >> Boa noite Breno! :p >> >> 0 messages with invalid length field >>0 messages with invalid version field >>0 messages with invalid message type field >>0 messages too short >>0 messages with memory allocation failure >>0 messages with duplicate extension >>0 messages with invalid extension type >>0 messages with invalid sa type >>0 messages with invalid address extension >> >> Olhando desse ponto, não é tão ruim assim a saída. >> >> >> -- >> "Deve-se aprender sempre, até mesmo com um inimigo." >> (Isaac Newton) >> >> Atenciosamente, >> Saul Figueiredo >> Analista FreeBSD/Linux >> Linux Professional Institute Certification Level 2 >> Linux User: #554651 >> saulfelip...@gmail.com >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Saul bom dia e obrigado pelo retorno. > Analisei sobre este aspecto também, mas a saída é composta de 2 blocos e são > semelhantes no trato da informação, mas no segundo é que tem a linha que me > tira o sossego. > > 732 messages with memory allocation failure > > Inclusive esta mesma linha/info tem no primeiro bloco e esta zerada, penso > que pode ser que um bloco trata do server e a outra do client, mas se for > qual é qual? > > Ah agora que vi onde está a sua dúvida. É realmente é estranho. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd De fato e ta dificil buscar alguma documentacao que trate a saida do comando netstat para melhor interpretacao. :-) Breno - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Flow Table ou route cache No Freebsd 9
Não fiz pois não achei necessário fazer flush no firewall. Mas posso testar. Agora quanto flush nas rotas eu achei como fazer isto somente no route cache. se é que existe no freebsd. No linux um ip route cache flush resolvia. este tipo de coisa. Agora vai outra pergunta Existe Route Caching no FreeBSD 9 ? E o Flowtable sumiu no FreeBSD 9 ? Lembrando que única coisa que fiz no kernel foi compilar o pf built in ao inves de carregar o módulo. Em 14 de setembro de 2012 10:38, Marcelo Gondim escreveu: > Em 14/09/2012 10:37, Marcelo Gondim escreveu: >> Você já experimentou fazer um flush nas regras de firewall e na tabela >> de rotas quando muda de gateway? >> > > A foi mal pelo top post, tava distraído aqui. :( > Mas tenta fazer isso que falei. > >> Em 14/09/2012 10:04, Otavio Augusto escreveu: >>> Mesmo quando a conexao foi encerrada e aberta outra ele insiste ir >>> pela caminho "errado". >>> Isto que me perturba >>> >>> >>> Em 14 de setembro de 2012 10:02, André Otta >>> escreveu: Otavio, Provavelmente ocorre devido ao BSD manter o estado das conexões ativas. Abs André Otta Em 14 de setembro de 2012 09:59, Otavio Augusto escreveu: > Galera estou com um problema que ainda não achei a direção do mesmo. > > Tenho 4 roteadores todos usando Freebsd 9 que se comunicam entre sim > com links redundantes. Não é internet e sim uma intranet > > No geral funciona bem, quando um link cai um script troca o gateway e > ele começa o transito pelo link reduntante. > Até ai tudo bem. Mas quando volta para o link principal várias > máquinas continuam trafegando pelo link antigo. > Se eu reiniciar o roteador volta ao normal > Notei que isto fica neste estado considerando que as portas de destino > são as mesmas. Mesmo fechando a conexao e abrindo outra. > O mesmo ocorre com icmp ( ping ). > > Primeiro fui procurar por flowtable mas não achei nada no sysctl para > esta opção. > E segundo route cache mas ão achei documentação falando disto para o > FreeBSD. ( Venho do linux) > > Alguém sabe por onde posso começar. Isto ja começou a me perturbar. > > Desde já agradeço. > > > > > -- > Otavio Augusto > - > Consultor de TI > Citius Tecnologia > 31 37761866 > 31 88651242 > http://www.citiustecnologia.com.br > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Att. André Otta - 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 -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Flow Table ou route cache No Freebsd 9
Em 14/09/2012 10:37, Marcelo Gondim escreveu: > Você já experimentou fazer um flush nas regras de firewall e na tabela > de rotas quando muda de gateway? > A foi mal pelo top post, tava distraído aqui. :( Mas tenta fazer isso que falei. > Em 14/09/2012 10:04, Otavio Augusto escreveu: >> Mesmo quando a conexao foi encerrada e aberta outra ele insiste ir >> pela caminho "errado". >> Isto que me perturba >> >> >> Em 14 de setembro de 2012 10:02, André Otta >> escreveu: >>> Otavio, >>> >>> Provavelmente ocorre devido ao BSD manter o estado das conexões ativas. >>> >>> Abs >>> >>> André Otta >>> >>> Em 14 de setembro de 2012 09:59, Otavio Augusto >>> escreveu: >>> Galera estou com um problema que ainda não achei a direção do mesmo. Tenho 4 roteadores todos usando Freebsd 9 que se comunicam entre sim com links redundantes. Não é internet e sim uma intranet No geral funciona bem, quando um link cai um script troca o gateway e ele começa o transito pelo link reduntante. Até ai tudo bem. Mas quando volta para o link principal várias máquinas continuam trafegando pelo link antigo. Se eu reiniciar o roteador volta ao normal Notei que isto fica neste estado considerando que as portas de destino são as mesmas. Mesmo fechando a conexao e abrindo outra. O mesmo ocorre com icmp ( ping ). Primeiro fui procurar por flowtable mas não achei nada no sysctl para esta opção. E segundo route cache mas ão achei documentação falando disto para o FreeBSD. ( Venho do linux) Alguém sabe por onde posso começar. Isto ja começou a me perturbar. Desde já agradeço. -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >>> >>> -- >>> Att. >>> >>> André Otta >>> - >>> 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] Flow Table ou route cache No Freebsd 9
Você já experimentou fazer um flush nas regras de firewall e na tabela de rotas quando muda de gateway? Em 14/09/2012 10:04, Otavio Augusto escreveu: > Mesmo quando a conexao foi encerrada e aberta outra ele insiste ir > pela caminho "errado". > Isto que me perturba > > > Em 14 de setembro de 2012 10:02, André Otta escreveu: >> Otavio, >> >> Provavelmente ocorre devido ao BSD manter o estado das conexões ativas. >> >> Abs >> >> André Otta >> >> Em 14 de setembro de 2012 09:59, Otavio Augusto escreveu: >> >>> Galera estou com um problema que ainda não achei a direção do mesmo. >>> >>> Tenho 4 roteadores todos usando Freebsd 9 que se comunicam entre sim >>> com links redundantes. Não é internet e sim uma intranet >>> >>> No geral funciona bem, quando um link cai um script troca o gateway e >>> ele começa o transito pelo link reduntante. >>> Até ai tudo bem. Mas quando volta para o link principal várias >>> máquinas continuam trafegando pelo link antigo. >>> Se eu reiniciar o roteador volta ao normal >>> Notei que isto fica neste estado considerando que as portas de destino >>> são as mesmas. Mesmo fechando a conexao e abrindo outra. >>> O mesmo ocorre com icmp ( ping ). >>> >>> Primeiro fui procurar por flowtable mas não achei nada no sysctl para >>> esta opção. >>> E segundo route cache mas ão achei documentação falando disto para o >>> FreeBSD. ( Venho do linux) >>> >>> Alguém sabe por onde posso começar. Isto ja começou a me perturbar. >>> >>> Desde já agradeço. >>> >>> >>> >>> >>> -- >>> Otavio Augusto >>> - >>> Consultor de TI >>> Citius Tecnologia >>> 31 37761866 >>> 31 88651242 >>> http://www.citiustecnologia.com.br >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >> >> -- >> Att. >> >> André Otta >> - >> 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] raid 0 em intel DH77EB
Estou usando o 8.3, instalação normal. Quanto ao raid coloque como raid na bios e criei o array atrabes do utilitarios que vem. Obs estou usando mirror e não stripe. Não confio em fake raid stripe, prefiro isso via gstripe ou controlado dedicada. Att. -Mensagem original- De: Allan Patrick Ksiaskiewcz Enviado: 13/09/2012, 22:15 Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR) Assunt.: Re: [FUG-BR] raid 0 em intel DH77EB Via hardware? Usou algum metodo de instalação diferenciado? No caso da BIOS coloco os HDS como RAID e somente isso. Em 13 de setembro de 2012 21:13, Paulo Henrique - BSDs Brasil escreveu: > Em 13/09/2012 20:04, Allan Patrick Ksiaskiewcz escreveu: >> To tentando instalar raid0 via hardware em placa intel com 9.0 amd64. >> Invez de reconhecer somente 01 disco ele mostra dois. >> >> No Debian uso o parametro dmraid=true xor-true e no Ubunbu server ele >> carrega libdmraid e reconhece corretamente. >> >> Tem algum modulo que eu possa carregar no boot do BSD para que >> reconheça o hardware como se fosse um HD somente, sendo que estou >> usando raid via hardware numa placa Intel DH77EB >> >> Obrigado >> >> >> > Por acaso é raid Intel ( ICH sobre AHCI ) ou é Marvel ( Sata 6 ) > Estou com uma DX58OG ( DX58SO ) aqui com raid tanto sobre a ICH como > sobre a Marvel e está funcionando !! > > > Att. > > > -- > Paulo Henrique. > BSDs Brasil - FUG-BR > site: www.fug.com.br > > Rip Irado !!! > flamers > /dev/null > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Atenciosamente, Allan Patrick Ksiaskiewcz (42) 9108-2614 - Vivo (42) 8854-1331 - Claro (42) 3036-0686 http://www.advantagenet.com.br Guarapuava/PR - 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] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
Em 14/09/2012 10:03, Gustavo Freitas escreveu: > amigo, > > qual seria a maior vantagem ? segurança ? Não é a vantagem o problema é a maldita licença GPLv3 do GCC que foi um tiro no pé pra muita gente. Stallman confunde o verdadeiro significado de liberdade querendo obrigar à todos que façam do jeito dele. Que morra o gcc então! Vida longa ao LLVM/CLang. > > 2012/9/14 Jack : >> Buenas Lista! >> >> Apenas compartilhando o texto: >> http://www.osnews.com/story/26372/FreeBSD_moves_away_from_GCC_embraces_Clang >> >> >> Abraços! >> Jack >> >> >> >> >> >> - >> 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] IPSec (netstat -nsp pfkey)
Em 14/09/12 06:14, Breno Ribeiro escreveu: > > Saul bom dia e obrigado pelo retorno. > Analisei sobre este aspecto também, mas a saída é composta de 2 blocos e são > semelhantes no trato da informação, mas no segundo é que tem a linha que me > tira o sossego. > > 732 messages with memory allocation failure > > Inclusive esta mesma linha/info tem no primeiro bloco e esta zerada, penso > que pode ser que um bloco trata do server e a outra do client, mas se for > qual é qual? > > Breno > Breno, sua VPN IPSEC está apresentando algum problema? - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
Caríssimos On Fri, Sep 14, 2012 at 10:11 AM, vic wrote: > Em 2012-09-14 10:03, Gustavo Freitas escreveu: > > amigo, > > > > qual seria a maior vantagem ? segurança ? > > > > > Licença. O clang/llvm também tem se mostrado mais rápido e usar menos > memória na compilação que o gcc[1]. > > > Além disto, esta estagnação com o gcc42 causa problemas práticos. Não é raro eu ter de compilar programas específicos (química quãntica) que normalmente requerem uma versão mais atualizada do gfortran (que é instalado junto com o gcc). Para manter a compatibilidade e conseguir êxito na compilação, uso a estratégia de fazer um link simbólico do gcc apontar para a versão mais nova do compilador (ln -s /usr/local/bin/gcc48 /usr/bin/gcc). Claro, antes eu renomeio o gcc padrão do sistema para gcc422. Apesar de simples, esta gambiarra às vezes faz com que eu me perca (junto com o sistema) por conta das lib chamadas na hora da compilação. De houver um compilar independente para o sistema (mesmo que ele possa ser usado para compilar ports), seria uma grande simplicação na vida do usuário. Um abraço a todos Edu [1]: > > http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036380.html > > -- > vic > http://choppnerd.com > http://donttrack.us | http://dontbubble.us > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Eduardo Lemos de Sa Associated Professor Level 3 Dep. Quimica da Universidade Federal do Paraná fone: +55(41)3361-3300 fax: +55(41)3361-3186 Voip Number call to (41) 33613600 (listen to the message and type 10531185) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
Em 2012-09-14 10:03, Gustavo Freitas escreveu: > amigo, > > qual seria a maior vantagem ? segurança ? > Licença. O clang/llvm também tem se mostrado mais rápido e usar menos memória na compilação que o gcc[1]. [1]: http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036380.html -- vic http://choppnerd.com http://donttrack.us | http://dontbubble.us - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Flow Table ou route cache No Freebsd 9
Mesmo quando a conexao foi encerrada e aberta outra ele insiste ir pela caminho "errado". Isto que me perturba Em 14 de setembro de 2012 10:02, André Otta escreveu: > Otavio, > > Provavelmente ocorre devido ao BSD manter o estado das conexões ativas. > > Abs > > André Otta > > Em 14 de setembro de 2012 09:59, Otavio Augusto escreveu: > >> Galera estou com um problema que ainda não achei a direção do mesmo. >> >> Tenho 4 roteadores todos usando Freebsd 9 que se comunicam entre sim >> com links redundantes. Não é internet e sim uma intranet >> >> No geral funciona bem, quando um link cai um script troca o gateway e >> ele começa o transito pelo link reduntante. >> Até ai tudo bem. Mas quando volta para o link principal várias >> máquinas continuam trafegando pelo link antigo. >> Se eu reiniciar o roteador volta ao normal >> Notei que isto fica neste estado considerando que as portas de destino >> são as mesmas. Mesmo fechando a conexao e abrindo outra. >> O mesmo ocorre com icmp ( ping ). >> >> Primeiro fui procurar por flowtable mas não achei nada no sysctl para >> esta opção. >> E segundo route cache mas ão achei documentação falando disto para o >> FreeBSD. ( Venho do linux) >> >> Alguém sabe por onde posso começar. Isto ja começou a me perturbar. >> >> Desde já agradeço. >> >> >> >> >> -- >> Otavio Augusto >> - >> Consultor de TI >> Citius Tecnologia >> 31 37761866 >> 31 88651242 >> http://www.citiustecnologia.com.br >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > > -- > Att. > > André Otta > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
amigo, qual seria a maior vantagem ? segurança ? 2012/9/14 Jack : > Buenas Lista! > > Apenas compartilhando o texto: > http://www.osnews.com/story/26372/FreeBSD_moves_away_from_GCC_embraces_Clang > > > Abraços! > Jack > > > > > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Gustavo Freitas - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Flow Table ou route cache No Freebsd 9
Otavio, Provavelmente ocorre devido ao BSD manter o estado das conexões ativas. Abs André Otta Em 14 de setembro de 2012 09:59, Otavio Augusto escreveu: > Galera estou com um problema que ainda não achei a direção do mesmo. > > Tenho 4 roteadores todos usando Freebsd 9 que se comunicam entre sim > com links redundantes. Não é internet e sim uma intranet > > No geral funciona bem, quando um link cai um script troca o gateway e > ele começa o transito pelo link reduntante. > Até ai tudo bem. Mas quando volta para o link principal várias > máquinas continuam trafegando pelo link antigo. > Se eu reiniciar o roteador volta ao normal > Notei que isto fica neste estado considerando que as portas de destino > são as mesmas. Mesmo fechando a conexao e abrindo outra. > O mesmo ocorre com icmp ( ping ). > > Primeiro fui procurar por flowtable mas não achei nada no sysctl para > esta opção. > E segundo route cache mas ão achei documentação falando disto para o > FreeBSD. ( Venho do linux) > > Alguém sabe por onde posso começar. Isto ja começou a me perturbar. > > Desde já agradeço. > > > > > -- > Otavio Augusto > - > Consultor de TI > Citius Tecnologia > 31 37761866 > 31 88651242 > http://www.citiustecnologia.com.br > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Att. André Otta - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Flow Table ou route cache No Freebsd 9
Galera estou com um problema que ainda não achei a direção do mesmo. Tenho 4 roteadores todos usando Freebsd 9 que se comunicam entre sim com links redundantes. Não é internet e sim uma intranet No geral funciona bem, quando um link cai um script troca o gateway e ele começa o transito pelo link reduntante. Até ai tudo bem. Mas quando volta para o link principal várias máquinas continuam trafegando pelo link antigo. Se eu reiniciar o roteador volta ao normal Notei que isto fica neste estado considerando que as portas de destino são as mesmas. Mesmo fechando a conexao e abrindo outra. O mesmo ocorre com icmp ( ping ). Primeiro fui procurar por flowtable mas não achei nada no sysctl para esta opção. E segundo route cache mas ão achei documentação falando disto para o FreeBSD. ( Venho do linux) Alguém sabe por onde posso começar. Isto ja começou a me perturbar. Desde já agradeço. -- Otavio Augusto - Consultor de TI Citius Tecnologia 31 37761866 31 88651242 http://www.citiustecnologia.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] FreeBSD mudará seu compilador default do GCC para o Clang em novembro
Buenas Lista! Apenas compartilhando o texto: http://www.osnews.com/story/26372/FreeBSD_moves_away_from_GCC_embraces_Clang Abraços! Jack - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPSec (netstat -nsp pfkey)
Em 14/09/2012 06:14, Breno Ribeiro escreveu: > Em 13/09/2012, às 23:45, Saul Figueiredo escreveu: > >> Em 13 de setembro de 2012 23:35, Breno Ribeiro >> escreveu: >> >>> Boa noite. >>> Estou implementando VPN IPsec no FreeBSD 9 com 30 filiais fechando na >>> matriz. Usando racoon e sem interface GIF. >>> Está funcionando a umas 3 semanas, porém o comando abaixo me dá uma saída >>> nada satisfatória, alguém que usa IPSec no FreeBSD poderia me informar se >>> isso também retorna no ambiente de vocês? Ou poderiam me ajudar a entender >>> a saída deste comando? >>> >>> netstat -nsp pfkey >>> >>> pfkey: >>>784 requests sent from userland >>>102640 bytes sent from userland >>>histogram by message type: >>>getspi: 92 >>>update: 90 >>>add: 90 >>>delete: 101 >>>register: 3 >>>dump: 145 >>>x_spdupdate: 180 >>>x_spddelete: 82 >>>x_spddump: 1 >>>0 messages with invalid length field >>>0 messages with invalid version field >>>0 messages with invalid message type field >>>0 messages too short >>>0 messages with memory allocation failure >>>0 messages with duplicate extension >>>0 messages with invalid extension type >>>0 messages with invalid sa type >>>0 messages with invalid address extension >>>5250 requests sent to userland >>>1342056 bytes sent to userland >>>histogram by message type: >>>getspi: 92 >>>update: 90 >>>add: 90 >>>delete: 137 >>>register: 3 >>>dump: 4575 >>>x_spdupdate: 180 >>>x_spddelete: 82 >>>x_spddump: 1 >>>4575 messages toward single socket >>>0 messages toward all sockets >>>36 messages toward registered sockets >>>732 messages with memory allocation failure >>> >>> >>> Breno >>> >>> - >>> Histórico: http://www.fug.com.br/historico/html/freebsd/ >>> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >>> >> >> >> Boa noite Breno! :p >> >> 0 messages with invalid length field >>0 messages with invalid version field >>0 messages with invalid message type field >>0 messages too short >>0 messages with memory allocation failure >>0 messages with duplicate extension >>0 messages with invalid extension type >>0 messages with invalid sa type >>0 messages with invalid address extension >> >> Olhando desse ponto, não é tão ruim assim a saída. >> >> >> -- >> "Deve-se aprender sempre, até mesmo com um inimigo." >> (Isaac Newton) >> >> Atenciosamente, >> Saul Figueiredo >> Analista FreeBSD/Linux >> Linux Professional Institute Certification Level 2 >> Linux User: #554651 >> saulfelip...@gmail.com >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > Saul bom dia e obrigado pelo retorno. > Analisei sobre este aspecto também, mas a saída é composta de 2 blocos e são > semelhantes no trato da informação, mas no segundo é que tem a linha que me > tira o sossego. > > 732 messages with memory allocation failure > > Inclusive esta mesma linha/info tem no primeiro bloco e esta zerada, penso > que pode ser que um bloco trata do server e a outra do client, mas se for > qual é qual? > > Ah agora que vi onde está a sua dúvida. É realmente é estranho. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPSec (netstat -nsp pfkey)
Em 13/09/2012 23:45, Saul Figueiredo escreveu: > Em 13 de setembro de 2012 23:35, Breno Ribeiro > escreveu: > >> Boa noite. >> Estou implementando VPN IPsec no FreeBSD 9 com 30 filiais fechando na >> matriz. Usando racoon e sem interface GIF. >> Está funcionando a umas 3 semanas, porém o comando abaixo me dá uma saída >> nada satisfatória, alguém que usa IPSec no FreeBSD poderia me informar se >> isso também retorna no ambiente de vocês? Ou poderiam me ajudar a entender >> a saída deste comando? >> >> netstat -nsp pfkey >> >> pfkey: >> 784 requests sent from userland >> 102640 bytes sent from userland >> histogram by message type: >> getspi: 92 >> update: 90 >> add: 90 >> delete: 101 >> register: 3 >> dump: 145 >> x_spdupdate: 180 >> x_spddelete: 82 >> x_spddump: 1 >> 0 messages with invalid length field >> 0 messages with invalid version field >> 0 messages with invalid message type field >> 0 messages too short >> 0 messages with memory allocation failure >> 0 messages with duplicate extension >> 0 messages with invalid extension type >> 0 messages with invalid sa type >> 0 messages with invalid address extension >> 5250 requests sent to userland >> 1342056 bytes sent to userland >> histogram by message type: >> getspi: 92 >> update: 90 >> add: 90 >> delete: 137 >> register: 3 >> dump: 4575 >> x_spdupdate: 180 >> x_spddelete: 82 >> x_spddump: 1 >> 4575 messages toward single socket >> 0 messages toward all sockets >> 36 messages toward registered sockets >> 732 messages with memory allocation failure >> >> >> Breno >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > Boa noite Breno! :p > > 0 messages with invalid length field > 0 messages with invalid version field > 0 messages with invalid message type field > 0 messages too short > 0 messages with memory allocation failure > 0 messages with duplicate extension > 0 messages with invalid extension type > 0 messages with invalid sa type > 0 messages with invalid address extension > > Olhando desse ponto, não é tão ruim assim a saída. > > Concordo com o Saul, pelo que estou vendo a saída está muito boa. Você queria que tivesse dando memory allocation failure? rsrsrsrr Porque só em ler essas mensagens já vejo que todas elas seriam ruins se tivessem acusando. Não entendi onde está o "nada satisfatório". :) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Squid: "No forward-proxy ports configured" E "Forwarding loop detected for"
Valeu pelo feedback! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] IPSec (netstat -nsp pfkey)
Em 13/09/2012, às 23:45, Saul Figueiredo escreveu: > Em 13 de setembro de 2012 23:35, Breno Ribeiro > escreveu: > >> Boa noite. >> Estou implementando VPN IPsec no FreeBSD 9 com 30 filiais fechando na >> matriz. Usando racoon e sem interface GIF. >> Está funcionando a umas 3 semanas, porém o comando abaixo me dá uma saída >> nada satisfatória, alguém que usa IPSec no FreeBSD poderia me informar se >> isso também retorna no ambiente de vocês? Ou poderiam me ajudar a entender >> a saída deste comando? >> >> netstat -nsp pfkey >> >> pfkey: >> 784 requests sent from userland >> 102640 bytes sent from userland >> histogram by message type: >> getspi: 92 >> update: 90 >> add: 90 >> delete: 101 >> register: 3 >> dump: 145 >> x_spdupdate: 180 >> x_spddelete: 82 >> x_spddump: 1 >> 0 messages with invalid length field >> 0 messages with invalid version field >> 0 messages with invalid message type field >> 0 messages too short >> 0 messages with memory allocation failure >> 0 messages with duplicate extension >> 0 messages with invalid extension type >> 0 messages with invalid sa type >> 0 messages with invalid address extension >> 5250 requests sent to userland >> 1342056 bytes sent to userland >> histogram by message type: >> getspi: 92 >> update: 90 >> add: 90 >> delete: 137 >> register: 3 >> dump: 4575 >> x_spdupdate: 180 >> x_spddelete: 82 >> x_spddump: 1 >> 4575 messages toward single socket >> 0 messages toward all sockets >> 36 messages toward registered sockets >> 732 messages with memory allocation failure >> >> >> Breno >> >> - >> Histórico: http://www.fug.com.br/historico/html/freebsd/ >> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd >> > > > > Boa noite Breno! :p > > 0 messages with invalid length field > 0 messages with invalid version field > 0 messages with invalid message type field > 0 messages too short > 0 messages with memory allocation failure > 0 messages with duplicate extension > 0 messages with invalid extension type > 0 messages with invalid sa type > 0 messages with invalid address extension > > Olhando desse ponto, não é tão ruim assim a saída. > > > -- > "Deve-se aprender sempre, até mesmo com um inimigo." > (Isaac Newton) > > Atenciosamente, > Saul Figueiredo > Analista FreeBSD/Linux > Linux Professional Institute Certification Level 2 > Linux User: #554651 > saulfelip...@gmail.com > > - > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Saul bom dia e obrigado pelo retorno. Analisei sobre este aspecto também, mas a saída é composta de 2 blocos e são semelhantes no trato da informação, mas no segundo é que tem a linha que me tira o sossego. 732 messages with memory allocation failure Inclusive esta mesma linha/info tem no primeiro bloco e esta zerada, penso que pode ser que um bloco trata do server e a outra do client, mas se for qual é qual? Breno - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
